charles-salvia

If we were to somehow perform a Principal Component Analysis on the amorphous, contradictory mess of "hippie ideals", we could probably distill them down to something like a call to implement a post-scarcity, socialistic society with few restrictions on human social behavior.

Of course, that kind of radical change isn't achieved by smoking pot and playing the guitar in downtown San Francisco. It's achieved by major technological changes that would make such a society even functionally possible, like practically-unlimited renewable energy sources. Needless to say, nobody involved in the 1960s counter-culture movements was in any position to actually implement the kind of changes needed to realize the grand vision of an ideal hippie society. (Some of them tried to do the next best thing, and form their own mini-societies in communes out in the country, all of which ultimately turned out to suck.)

I would also note that another 1960s icon, Gene Rodenberry, at least seemed to realize that the kind of changes needed to implement a hippie utopia would likely only be possible after many other practical societal problems were solved via technology.

>> What concentration camps reveal is that modern people are squeamish about killing.

Well, there's a difference between exterminating a foreign and/or conquered city-state, and isolating/quarantining undesirable sub-groups from within a larger civilization (often for reasons that are more ideological than political). What the Mongols, Romans, Assyrians, etc., did was less like isolating an ethnic sub-group and more like inflicting punishment upon a city-state for not paying tribute. (Also, I think the Assyrians would also export the population of a city-state and resettle them elsewhere, to remove their national identity, just as often as they would kill and/or skin-alive everyone in a targeted city-state.)

It's probably worth noting that what happened recently to the Yazidis in North Iraq was closer to what used to happen in antiquity.

The C++ delete[] operator doesn't take a size parameter either. This is neither here nor there, and unrelated to the problem the blog post is talking about.

>> Our brains are fallible, and so only approximately equivalent to Turing machines; and even ignoring that can only compute every computable thing given both infinite error-free storage capacity (which they don't have internally or externally) and sufficient time to execute the necessary steps of the computation.

So are actual computers. They're just "less fallible" and closer to a Universal Turing Machine than human brains in certain ways. A Commodore 64 is also incapable, in practice, of computing certain computable functions, due to memory limitations and what have you, but nobody would really claim a Commodore 64 is not Turing complete.

The practical difference is that with async I/O, there's less overhead because you don't need a separate thread for each blocking I/O operation. It's the difference between using a single-threaded event loop to demultiplex between 10,000 sockets, and using 10,000 threads to read one socket each. The former strategy has way less overhead.

Of course, many high-performance, I/O intensive applications like web-servers can effectively make use of a combination of multiple threads and I/O demultiplexing as well.

k, along with j, is also often an index.

Of course, this mathematical convention carried over into programming as well, with i,j, and k serving as index variables.

> It's odd how this is portrayed as a negative aspect of Japan's militarism, when the Allies were fighting the same war with the same attitude.

That's not the point, obviously. The point is Japan's militarism combined with their utter over-the-top brutality and expansionist agenda.

The "lone genius" is somewhat of a myth, but also has a certain amount of truth to it. For example, Einstein was certainly a lot smarter than the average person - indeed, probably a lot smarter than most highly-accomplished scientists and engineers. However, he also was at the right place at the right time, and would never have come up with General Relativity had it not been for the work of his predecessors, such as, e.g., Riemann, who enabled Einstein to think of space-time in non-Euclidean terms, etc.

I think the biggest problem with the "lone genius" mentality is that it encourages the popular notion that "if it wasn't for Einstein, we'd never have General Relativity." But of course, this is most certainly false. If Einstein never existed, someone else would have eventually noticed problems with Newtonian mechanics over large distances, and ultimately applied Reimannian geometry to spacetime as a solution. It may have happened years or decades later, but overall scientific progress is very rarely strictly dependent on one individual.

Ethics aside, at a certain point, you realize you can make a lot more money legally and legitimately using your technical skills than through any sort of "clever" technical scheme that involves hacking odometers or scamming people in some way.

Okay, well - never knew this. But that example seems really cherry-picked. Many NY street names are just numbers, even in other boroughs outside Manhattan. Many streets in the Bronx are just a number (130-something street to 230-something street, carrying over from upper Manhattan).

I've lived in NY my whole life, but am not familiar with this stereotype about unpronounceable names. Apart from Kosciuszko there aren't too many difficult to pronounce names of bridges/tunnels/express-ways, etc. Kosciuszko is a Polish name - the bridge is named after a Revolutionary War general, not a local New York politician. Most other bridges/tunnels/express-ways are named after famous American politicians (Washington/Lincoln/RFK), or are just named obvious descriptive things like "Brooklyn-Queens Expressway". Every now and then some bridge gets renamed (Triboro -> RFK), but nobody cares. AFAIK the only bridge named after a local New York politician is the "Ed Koch" bridge, but nobody calls it that anyway.

Basically, the main problem with signalfd is a problem with the Linux implementation of signals in general: if your program requires some kind of logic where each individual signal delivery somehow "counts" in some way, you may run into a problem because the kernel may coalesce/collapse multiple identical signals delivered consecutively into a single signal delivery. So if your program has some kind of logic that relies on responding to each individual signal, you may have a problem. (Note that this problem does not apply to POSIX real time signals.)

But as far as I know, the only reason you'd ever care to actually count individual signal delivery events is with SIGCHLD. So when waiting for SIGCHLD, using signalfd is not sufficient. You'd need to also use one of the wait/waitid/waitpid variants to ensure that you can respond appropriately to each individual SIGCHLD delivered.