cbd1984

Aside from marketing, which you mentioned, the quality McDonald's pays for is standardization.

Standardization is why chain restaurants exist at all. They give people a way to get a meal they know is going to be of a certain quality at a certain price with a sufficiently low probability of being surprised. Surprises are, on the whole, generally negative: Good restaurants are few and far between, especially at the fast food price point, and a sufficiently bad surprise can have health implications. There's a reason one of the first chains was White Castle: White implies purity and a standard of cleanliness, as opposed to the local greasy spoon cafe where the only assurance of quality is that it hasn't been shut down yet.

So McDonald's pays for processes and materials that it can blast out into a million little restaurants, all the same, secure in the knowledge that minimum-wage workers can be sufficiently skilled and motivated to carry out those processes and use those materials the right way. Doing anything better might lead to a much improved experience in some restaurants but it will reliably lead to total disaster in others, which is utterly contrary to the business model.

By that standard, McDonald's is fairly high quality.

Please stop disrupting conversations.

OK, this goes from DNS, to email, to... something which is not Usenet, which surprised me, because Usenet fulfills most of the goals of being a social network much better than either DNS or email can.

Usenet can, in fact, be built on top of an email delivery mechanism, such as UUCP, which is the store-and-forward dial-up network both Usenet and Unix email ran on top of before Unix was allowed to sit at the big-kids table of networking (Arpanet). We have NNTP now, of course, and a number of NNTP servers you can run on a laptop because it somehow fails to be 1995 anymore and most of the people reading this have better network connections and more disk space than most of the servers which ran NNTP in the heyday of Usenet.

Near as I can figure, the goal is to build your own Linux distro to run as a guest in a virtual machine (hypervisor virtual machine, not bytecode virtual machine).

If you want to make your own distro, this is certainly friendlier than the old way, which was "do it all on a standalone machine and hope you don't break anything or wedge it into a difficult-to-debug state".

I think the usual rule is that the size of a variable's name should be a function of the size of the scope in which it's visible: If it's a global, it should have a long, descriptive name, perhaps with_underscores or CamelCase or similar. If it's a class member, abbreviate it some. Function locals get even shorter names, and loop indices or temporary variables only used in one part of the function can be single-character.

Historically, i wasn't even an abbreviation: It was the first variable name which would be assumed to be integer by FORTRAN compilers which implicitly assigned types to variables based on name. The choice was probably further influenced by longstanding mathematical tradition, which uses i and j as indices.

(You could declare types and the compiler would respect it, leading to the old truism "GOD is REAL, unless declared INTEGER".)

(If you think that's the weirdest thing old FORTRAN did, look up the arithmetic IF statement sometime. Then, look up assigned GOTO.)

Everyone forgets about ltrace: Like strace, but for calls to dynamic libraries.

It gets you something closer to what the program looks like at the source code level: You get calls to printf (well, __printf_chk on a modern Linux) instead of write, for example. The downside is that ltrace doesn't (and can't) know as much about every single function in every single dynamic library, so, while the names are there, the arguments are typically less convenient to work with and may be incorrect. (For example, it doesn't dereference pointers to print out nice strings, and it might not know how many arguments a function takes.)

JANET, which routed email to Czechoslovakia, as the legend goes...

Back then mainly the Computer Science departments had email, so they'd have domain names beginning with a cs. in the ARPA scheme, but, since JANET did it backwards, you'd have to rearrange the domain name so it ended with a .cs for that network. If you did that and didn't reverse it back, the domain name would have a ccTLD of .cs, which is what Czechoslovakia used.

(The .cs ccTLD existed until 1995, years after Czechoslovakia ceased to. The .su ccTLD (Soviet Union) still exists.)

You're the one spoiling HN with your insults and disruption.

This is how atheists define atheism.

> I can be productive in bash, but I think we all agree "stringly typed" is not as good as most other approaches to programming language design.

That depends on the language, and how central text is to what it does.

And now you're disagreeing by downvoting.

> The problem is, most of the dynamic proponents know next to nothing about the PL theory anyway.

This is either a "triumph" of theory over reality, or an insult of a whole group of people.

In short: A lot of people like dynamic typing, and can be productive in it. If the "theory" you cite says static typing is better, the "theory" needs to be changed to reflect reality. If, on the other hand, you're wrong about the theory and/or about dynamic typing enthusiasts knowing it, you should apologize.

This kind of moderatorial bickering does not belong on HN.