HN user

ised

162 karma
Posts0
Comments87
View on HN
No posts found.

Can anyone define "succeed" in this context? Is it purely popularity? What if a language is inferior but popular?

If a language is effective for its user(s), then is it a "success"?

Is there some minimum number of users that delineates a threshhold for "success/failure"?

What about DSL's that might have a limited number of users?

I like that the author recognized the "success" of shell and C as tied to the "success" of UNIX . But he forgot others, such as sed.

Some my favorite and most powerful languages are not widely used. I have no idea what "succeed" means to others in the context of programming languages, but these languages have "succeeded" for me. They get the job done. Efficiently.

Nothing has surpassed Snobol for pattern matching. (If you are in doubt, post a pattern matching challenge and let's see how the solutions in various languages stack up.)

Meanwhile other implementations of pattern matching have become more popular (=successful?)

Perhaps the word "succeeded" here simply means "succeeded in becoming popular?" If so, then I apologize for the gibberish.

Whenever this gets posted, comments seem to focus on what to use going forward. It seems obvious for most projects there are better alternatives.

However whenever I see autotools documentation I think of only one thing: it's worth learning how this old system works because, even if you will never yourself use it for your own projects, so much code written by others over past decades requires autoconf, automake, often libtool, and sometimes pkg-config.

For me, understanding how these old hacks work is very important in getting a large majority of open source software projects to compile after I make modifications, e.g., removing code.

Oftentimes I think that people who use autotools do not truly understand _how it works_, they have only figured out _how to use it_. This is reasonable but the problem is that autotools is very brittle, and if it breaks they have little idea how to fix it.

To the author: I could not agree more. In the long term history of computing, I would hope this stage we are in now is not the height of the "revolution".

In my humble opinion, to which I am entitled, current Apple hardware is still well-designed like the Apple hardware of the past, but none of it resembles a "bicycyle for the mind".

These phones and tablets are "computers" but are programmable only by permission; they are consumption instruments that are meant to support some plan to dominate the communications, media, entertainment industries. Not my idea of a programmable, pocket-sized, networked computer.

All due respect to Apple and their wild commercial success, but looking to the future, I get more excited about my RPi or Teensy than I do about my Apple devices.

I have little interest in paying for a license to a bloated, complex, proprietary IDE (Xcode) and seeking approval from an "app store" when I can write ARM assembly from a netbook or laptop using a free and open source assembler and run it instantly on the RPi.

The revolution is yet to come. I hope. kparc.com/o.htm

"...serving a dummy page."

It could also be less than a page. It could be a dummy resource. For example, in the case of an ad server and a smartphone app that has some screen space reserved for ads. You might want your own resource to appear in that space instead.

Another example is reverse engineering API's and protocols for popular web services, social media, storage, etc. In that case you might want a "dummy server" that serves certain responses.

"... but it is not how anyone in their right mind writes C."

If I were going to place blame (I think a better approach is to skip that and just solve the problem), then I would blame developers, not the language.

To me, the code you are criticizing is very "regular" -- it follows predictable patterns. I find it easier to follow than most other C code I read.

More importantly I believe it is worth following. Obviously he is doing something right as reliability, performance and paucity of bugs shows.

All this despite not being in the "right mind", whatever that means.

I wish all the programs I am forced to use were written with such care.

The question is: what is listening on 127.0.0.1?

For example, do you have an httpd listening on 127.0.0.1? Do you bind any other daemons to 127.0.0.1 or the broadcast address?

If you operate your own root you can reassign the authoritative nameservers for doubleclick.net to nameservers you control. You may or may not choose to return "A" records.

If sites start moving to HTTP/2, is it true the untrustworthy code can be inserted into the same stream as the "content"?

Everything could be coming from the same domain/IP? This might make blocking ads and tracking more complicated?

My solution as HTTPS spreads is to MITM my own connections so I can see what is being sent and received over the wire. As the article says, it is a PITA. But it is necessary.

"...as close as possible to the creepy line."

Great stuff.

Blog posts are just too boring most of the time. We need more direct quotes from the people toeing the creepy line.

That is the behavior that should be tracked. What do you think these "engineers, designers and policy makers" get up to each day? Maybe lots of "pretending to believe" they are doing something meaningful?

The last line from the article you quote is spot on.

Why are alleged "services" provided for "free"?

One group will tell you it's because advertisers are picking up the costs for "content". Another group will tell you that it's because no user (cf. advertiser) would pay if a "fee" were charged to use the www.

Of course, no "free" business model will dare test the theory of the later group, so I guess we'll never know how the user values these "services". Instead the investors and advertisers set the value. Grossly inflated.

In the early days of the internet as I remember it the real (non-hardware) costs for the internet were tolls on telephone calls (dial-up). Organizations picked up the tab for employees who used the internetwork. Tuition-paying students also got access.

Then came UUnet and "ISP's". And then people had their own personal computer, at home, with a network card.

As far as I'm concerned, the internet connection fee is still the only real cost.

I think the browser you allude to is possible. But I think some changes in thinking in how information is structured and presented on the www is needed. If we let the www be shaped solely by web developers with a lust for layers of abstraction and increased complexity and being given carte blanche to run code on others' computers, then it forces the "browser" to be something that is far too complex and too much trouble for any open source volunteer programmer to deal with.

Make the www easier to parse and then the www "browser" becomes easier to replicate. This is only my opinion. Others would certainly disagree.

"The next step... is to merge the different components by using basic computers and have software turn it into servers, storage devices or routers as needed."

This statement is rather enticing because I have been executing this exact process for years using one of the free, open source kernel/userland options available for download. The "OS" is kept small and runs entirely in RAM. Works well enough for my purposes.

It is also interesting to juxtapose this statement against the usual negative comments on HN anytime the discussion turns to building home routers using "basic computers".

But maybe the meaning of "basic computers" by the journalist here is not what I think it is.

"a controversial topic"

My observation: The "discussion" never seems to focus on systemd. Instead it usually turns to comments on the former sysvinit system or other init systems.

That avoidance is perhaps something to ponder. And maybe it's why this author felt the urge to put some focus on systemd itself.

Love the quote from djb. In sum, the best interface is no interface. Parsing amounts to high margin for error and often an incredible nuisance.

In another thread today I wrote about the command line interface and "expecting a reponse". Truthfully, djb's utilities that simply return an exit value and no output are the best ones I have ever used.

(It seems djb himself is a systemd user. Not sure what if anything that means.)

Imagine if the information dissiminated via www was as easy to "parse" as text0. Writing a simple "web browser" might be easy enough that programmers would not need to be paid to do it.

"Want to know why the command line is hard for plebs?"

Not really.

These type of comments are almost always pure speculation, based on one's own experience.

Here's one thing that is true: Everyone who uses the command line was once a "pleb".

Txt'ing is what its name implies. Typing short lines of text. (And anticipating a quick response.) Seems reasonable to make a comparison to using the command line.

IRC, or today's "chat", is also arguably similar. Typing short lines of text, and expecting a quick response.

I have wondered about this for years as SMS and later Twitter, and now "enterprise chat", i.e., typing short lines of text, became popular.

But winning a popularity contest for how people interact with a computer is not something that really interests me.

My prediction based on last 30 years of computing history is that command line interface is never going to disappear (that is one reason I stick with it). It is there for whomever may discover and choose to use it.

"They don't even know what they don't know."

Exactly.

And yet countless GUI lovers/CLI haters continually ask us to believe that some hypothetical user would _choose_ not use a command line interface when they do not even know that such a thing exists; they were never given a real choice.

Who cares what other users want to use? It is their choice, not yours.

Give them a choice a see what happens.

Experiment.

"Performance is just the story they are selling in exchange of absolute control of the Web."

To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information).

Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter.

The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information.

As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web".

The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users.

I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback.

Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need.

To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.

"Wikipedia-over-IPFS"

Interesting example. I have Wikipedia as a local database on my own secondary storage.

As long as there are mirrors of the data dumps, I only occasionally need an internetwork. (To download data dumps.)

"For some people..."

I think there are a lot of people who share a similar perspective.

For every Gates and Jobs, there are many other equally talented programmers and marketers who were not and will not be as lucky as these two.

But if these other talented programmers and marketers conducted themselves in the manner of Gates and Jobs, would anyone forgive them?

It's tempting to retort with some rhetorical rationale like "the ends justify the means," but then no one has any proof that behaving like Gates or Jobs has any causal link to the level of success they experienced.

Microsoft and today's Apple are what they are. Some people love these companies' products. The word "cult" is sometimes used and people get quite defensive about their computer preferences, too. Effective marketing I guess.

But not everyone has been so impressed.

For people in the later group, there is little reason to celebrate Gates or Jobs, unless one is on the receiving end of some of their cash, whereby it can be put to beneficial use.

What I find amusing about this is that in addition to taking the money on the table by serving mobile ads, the carriers are also charging their customers for "data".

All the mobile ad and other cruft just increases the amount of data used by the customer.

Imagine if customers were only charged for the actual content. Is CSS, fonts and Javascript "content"? I guess it depends who you ask.

As a user, I rarely turn on Javascript, yet I still download heaps of it (then filter it out client-side). For me, this is totally unnecessary data usage.

"Documents are littered with commas."

It's trivial to change all those commas to something else before making the CSV file and importing into the database.

They can then be converted back to commas by processing the query result.

This type of conversion before storage is routinely done with other characters, such as newlines, quotes, etc. For example, look at the JSON for the 10mHNComments data dump.

Personally, from a readability standpoint, tabs drive me nuts. I am glad TSV is not the default.

"There is no such thing as an unmaintainable/illegible basic regex..."

To someone who knows BRE. I am one of those people. It's ERE and PCRE I do not understand very well.

Sharing solutions to common problems using BRE on HN always seems to trigger (unwarranted) criticism using either of the exact words you mention, or synonyms for them. "Unmaintainable" (by who?). "Illegible" (to who?).

I "maintain" 100's of BRE scripts. They are perfecty legible to me. None of them are so complex I cannot re-write them in a short time. It is the structure of the input that is complex and which takes time to recall.

I also use lex, a common utility found on almost all UNIX derived OS; this article seems to ignore that option. I like to think it's faster than Perl or Python, but I cannot say for sure.

But I never suggested any of those statements you are making.

What I was referring to is that Google's "product" is offered free to the user.

What you refer to highlights the importance of the question: if their "product" is not free to produce, then why don't they charge users for it?

No matter how well Google delivers your search results and email, if they cannot serve ads, they are in trouble. They have hundreds of millions of loyal users of these websites, but Google does not ask users for money.

If they did, would you pay?

I accept session cookies only, I keep Javascript turned off except when I am forced to turn it on (banking, etc.), and I really do not like frames.

If there is some site with frames that I willingly use regularly, I just bust out of the frame and access the contents directly.

Hence what you are describing does not sound like something I desperately need to do.

The only way I can answer your question is if you give me an example: a website with ads to block. Then I'll test it.

I should note though that cookies are not ads; the original topic was blocking ads - you are shifting the goalposts.

For blocking, I use zone files, not the HOSTS file.

I can select specific subdomains; I can also use wildcards.

I doubt there is anything an ad blocker can block that I cannot block using DNS. But if you have examples, post them and let's see.