Then over the next 15 years we managed to push the clock-speed boundary up another, what 3-4x? That looks an awful lot like hitting a brick wall to me.

It could be. Then again, it may just be the improvements that gave rapid increases in clock speed were the low-hanging fruit at the time, and once increasing clock speed further became difficult (but let's not say "impossible") then other low-hanging fruit came along.

Maybe it's a brick wall, and maybe not, but the industry has a long history of "probably not" when it comes to telling them what they can or can't do.

There is some debate among people if 5nm will make sense or even be reasonable to do...

It's not a new discussion by any means. It was an old debate when people were asking whether a 100MHz bus was as fast as we could get, and 45nm was considered ridiculously small. The GHz barrier on clock speeds seemed insurmountable.

Didn't stop anyone, did it?

If it can be done, someone's going to try. If it can be done profitably, we'll see it on our desks or in our pockets in a few processor generations. That's just how it is.

I should have no reasonable expectation that a farmer (Nye wrote "regular software writers and farmers") would have expertise in astrophysics for example.

I'd expect farmers to have a far better background in and a more intuitive understanding of science than software writers. Farming is, at its core, applied science. It may not be as rigorous or structured, but for thousands of years people have lived and died based on how well farmers hypotheses have panned out.

Software writing and computer "science" in general falls more under mathematics than science. In mathematics, once something is proven it stays proven, not matter how sloppy or random the process of getting to the proof might be.

I guess that opens a philosophical discussion of whether writing device drivers counts as "kernel coding" at all.

writing device drivers is debatable; the kernel side of it is frequently just cut and paste from elsewhere and most of the "real work" is on the device side. A strong argument can be made that maintaining them in the longer term is true kernel coding as there's a bigger need to track changes to the kernel side of things.

Then again, it might've gotten easier. I haven't maintained drivers since the 1.3/2.0 days.

No, they fund things that have a military application, some of which are interesting. But it's not like the good old days, when they'd fund things that were interesting, regardless of military value.

If you're going to go around reading Wikipedia pages, you may as well finish reading them before citing them.

Here's what the very same Wikipedia page says, one paragraph after the one you quoted:

The ARPANET incorporated distributed computation (and frequent re-computation) of routing tables. This was a major contribution to the good survivability that the ARPANET had, in the face of significant destruction - even by a nuclear attack. Such auto-routing was technically quite challenging to construct at the time. The fact that it was incorporated into the early ARPANET made many believe that this had been a design goal.

The ARPANET was in fact designed to survive subordinate-network losses, but the principal reason was that the switching nodes and network links were unreliable, even without any nuclear attacks. About the resource scarcity that spurred the creation of the ARPANET, Charles Herzfeld, ARPA Director (1965â"1967), said:

The ARPANET was not started to create a Command and Control System that would survive a nuclear attack, as many now claim. To build such a system was, clearly, a major military need, but it was not ARPA's mission to do this; in fact, we would have been severely criticized had we tried.

Which agrees nicely with what I said in my earlier comment.

You then went on to say:

No, they weren't the only place with money. But ARPA was founded in 1958, and it wasn't until 1973 that they were required to only spend money on defense-related projects. Before that, they had a habit of giving money to all sorts of interesting projects. JCR Licklider, an obscure, yet tremendously important person in computing history, wanted to build computer networks and was a higher-up at ARPA in the 60's. His successor was Ivan Sutherland, who should need no introduction, and Sutherland brought in Bob Taylor, who finally got a network funded and built. Since you like Wikipedia, here's a passage from Taylor's entry:

Among the computer projects that ARPA supported was time-sharing, in which many users could work at terminals to share a single large computer. Users could work interactively instead of using punched cards or punched tape in a batch processing style. Taylor's office in the Pentagon had a terminal connected to time-sharing at MIT, a terminal connected to the Berkeley Timesharing System at the University of California at Berkeley, and a third terminal to the System Development Corporation in Santa Monica, California. He noticed each system developed a community of users, but was isolated from the other communities.

Taylor hoped to build a computer network to connect the ARPA-sponsored projects together, if nothing else to let him communicate to all of them through one terminal.

When ARPA got out of the business of spending money on interesting work, the National Science Foundation was supposed to pick up the slack, but this never happened. While I can understand how some people might cast aspersions on projects that used military funding, even if they're not meant for military applications, the money spends well enough.

No it wasn't; that's just an urban legend. The ARPAnet was a way of allowing researchers to share resources. Thus, a user in San Francisco could use a computer in Los Angeles, and wouldn't even need a new, dedicated terminal to do it. Its resilience has more to do with the poor state of telecommunications at the time demanding it, and certain design features that allowed for a useful combination of efficiency and flexibility.

As for why it was funded by DARPA, that was where there was money.

8. moving parts can be lubricated with either gun oil or maple syrup.
9. bayonet lug will accept a non-lethal Shawinigan Handshake module
10. Canadian flag on the butt to ensure that our troops aren't mistaken for Americans ... this stuff practically writes itself.

A VERY vocal minority do not want Systemd on ideological grounds (although I suspect it is more a matter of the new and different scares them, no matter what advantages it may offer)

"new and different" actually is a huge problem, combined with what appears to be a very atypical adoption process happening in a very short period of time (in Debian, within a single release cycle).

Now, ignore the vocal minority. There's always a vocal minority. Sometimes they're right, most times they're just loud, but in the bigger picture they're still a minority.

It's the silent majority you need to be worried about, and the silent majority don't want systemd. This has nothing to do with the technical merit of systemd. They don't want any substantial deep changes. They want small, piecemeal, trackable and revertable changes. The very conservative people who's livelihoods depend on Linux "just working" are looking at this systemd business and flat-out wondering if the distros have lost their collective minds?

My group, who are usually pretty near the bleeding edge by our corporate standards (we generally track current stable releases and and deviate from stock as little as possible) normally track Debian stable and we're seriously considering bypassing/delaying Jessie. I can't imagine selling systemd to the other parts of the organization who have deep mods to the distro and reams of detailed documentation that'll have to be completely gutted.

Basically, all this discussion is pointless noise. Watch the adoption rates for the next couple of release cycles of the more "conservative" distros who have been pulled into the systemd gravity well. Particularly adoption rates where there might be a desktop/server breakdown. That's the silent majority passing judgement. I don't think it's going to be good.

Online shops is the obvious place to enforce this. No packaging for simple stuff like cables, plain bags for non-breakable loose stuff, plain boxes for everything else. People are buying from pictures and reviews and shoplifting is a non-issue, so packaging only needs to be minimally functional. I think AmazonBasics products use this approach, and it'd be nice to see Amazon push it back a bit on their suppliers.

Ideally, it should be the responsibility of the retailer to display the product attractively rather than the job of the package, but blame Walmart. They've done a pretty solid job of unloading a lot of traditional retailer jobs back on the manufacturers.

There is no way for the policeman to scan the QR code while the phone is in your possession in your car.

Hold your QR code up to the always-on camera on his chest?

There is no justification for using paramilitary police action on non-violent petty crime.

I generally agree, but I'd definitely grant an exception in the case of these swatting pranksters. "Live by the sword", etc.

And just to get the joke out of the way, "You wouldn't shoot a policeman. And then steal his helmet. You wouldn't go to the toilet in his helmet. And then send it to the policeman's grieving widow. And then steal it again!"

Well, of course not. What kind of sick fuck would steal a helmet full of shit?

if this action by ABP is in fact happening, a fork of the project should most certainly be considered as this 'whitelisting' violates an expected feature or function of the application by its community of users (and possibly developers.)

It's actually pretty old news.

That being said, I don't recall ever seeing one of those acceptable ads due to the other measures I use like noscript/scriptsafe, so I can't really comment on how acceptable they are.

Apple made products that people finally liked to use, and could use it easily enough, and fairly intuitively.

... and, to maintain the karmic balance, they made iTunes.