HN user

cbd1984

2,237 karma
Posts4
Comments1,558
View on HN

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.

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.)

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.

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.

Frankly, I'm kind of interested in the prospect of specialized hardware coming back.

The trend since the mid-1980s, when the Intel 80386 was introduced, has been for specialized chips to be replaced due to commodity chips beating them comprehensively in single-core speed; problems which once required specialized hardware and core designs were either solved or obviated by massive improvements in scalar hardware.

Now that this brute force method is starting to peter out, we might see a rise of new, specialized designs once again, to solve specific problems which gain substantial speedups from very specific kinds of parallelism. Systolic arrays are one example. We're already doing something like this by pressing GPUs into service as computational hardware, but it can go farther.

Atheists frequently evangelize. It is a religious belief.

It isn't, and it's insulting to say so: You're imposing a category on people based on deliberately misunderstanding their worldview. Atheists say their lack of belief isn't a belief, and saying otherwise is insulting.

FidoNet was and is an interesting system, but it relies on a system which is a public utility and/or publicly subsidized in most of the world: the telephone network. Dial-up networks like FidoNet only work if there's enough phone service to bother with.

He actually tries to justify (or deflect) stealing the Let's Encrypt trademark by claiming LE stole the concept of a 90-day cycle. Ridiculous.

You can patent business methods, but saying a 90-day cycle is an "inventive concept" would likely cause a competent attorney to take you to one side and quietly convince you to not point that fifty-caliber BMG at your leg.

https://en.wikipedia.org/wiki/Business_method_patent

"Intellectual copyrights", wtf is that?

Either someone who doesn't know the law trying to look smart, or someone who does know the law trying to bullshit their way into being able to own more than the union of copyright law, patent law, and trademark law actually allow them to own. Believe it or not, the law doesn't recognize "It's mine because I scream loudly enough" as a valid concept.

Why do you think other networks wouldn't have grown global?

Because privately-run networks have to turn a profit by the end of the fiscal year, if not sooner. It's too easy for a company to engage in profit-seeking behavior which harms long-term growth, like demanding fees to interoperate with it. The core Internet protocol suite, OTOH, is completely specified by RFCs which are free to read and implement.

Changes in the environment screw it up, too. As an obvious case, if your software is screen-scraping a website and the website's layout changes, your software's just rotted even though your code hasn't changed one bit.

Another example is software which interfaces with hardware: Swapping one specific piece of hardware out for "the same" hardware made by a different manufacturer can cause rot, because "the same" hardware isn't necessarily the same in every respect. If your software tickles it the right way, it can expose differences which can cause your software to fail in new and exciting ways. Nothing changed, yet everything's different.

As you expand the universe of things your code has to interact with, this kind of change becomes inevitable. As always, the more points of attachment, the more potential for future pain.

How much has the Internet done for your business that a smaller, proprietary network wouldn't have?

Metcalfe's Law only kicks into high gear when everyone is capable of joining the same network. If there are three or four proprietary networks with limited and expensive communications between them, growth is hobbled.

Or, to take another tack, how much has access to clean water done for you? How much has access to a house that isn't burgled done for you?

Just because you personally never received a check doesn't mean the government hasn't given you benefit.

They're alike enough that you could probably make a mashup with just those few chords and it'd sound nice, but the entire rest of the songs are utterly different.

To amplify your point:

You can mash up "Hot In Here" by Nelly and "Stayin' Alive" by the Bee Gees and that sounds good. (In that: Even if it isn't your taste in music, it works in some objective sense. It sounds like what that kind of music is supposed to sound like. Can you tell I don't know anything about music theory?)

https://www.youtube.com/watch?v=ekwod6Py1RI

Anyway, my point is that on a basic, mechanical level, all music is derivative. That's part of what a 'genre' is. That's part of what a 'musical tradition' is, why Mozart sounds different from Chinese Opera.

Infringement has to be based on something more.

That's nice, except the BMP doesn't encode all of Chinese, and it includes a number of weird control characters for compatibility with ASCII. Like Vertical Tab. Who uses Vertical Tab anymore?

The dream of a 16-bit Unicode washed up on the rocks of CJK scripts. It's dead and it isn't going to be revived. You can argue for a simpler standard, with fewer assigned codepoints, but the original BMP isn't it and was never going to be it.