the barista fumbled with the card for a few swipes, unplugged and replugged the card swipy thingy and then after a few more swipes and apologies, much as one would whack a misbehaving laundry machine with broom a bit, the magic went through. I paid with cash. I guess a few of the vendors at the farmer's market also take those swipy thingies as well (slowly...connection? no?).

The tight couplings to the power system and lord knows what all else is doubtless a Normal Accident waiting to happen, but the power is always on, packets always flow, and the data centers always run, right? — resilient. That's the word I'm looking for.

There is alien life. I believe they are called "Hungarians."

"Have You Ever Heard of Plato? Aristotle? Socrates?" ... "Morons!" "Really."

One problem with renewable generation would be the order-of-magnitude higher costs Germany has shelled out for renewables (same cost as building the entire French nuclear fleet) mostly to just replace the German nukes while still retaining a hefty appetite for Carbon. Another problem is the oops-not-yet-invented-nor-even-a-path-to-market of whatever your "better energy storage" might be (pumped storage is, well, the Tenn. Valley Authority were rather shy about the efficiency numbers of such when a coworker asked, and I guess there's a lot of battery research going on but that invention thing and being viable in the marketplace are still two rather important hurdles). Otherwise, I've certainly heard much of Hydrogen since those Caltech folks wheeled a Hydrogen car around their parking lot back in the 1970s, then shelved it. In related news, TEPCO is proposing a new coal plant for Fukushima, China in 2011 had 79% coal burn for their energy, and Carbon consumption since the 1990s has grown at a faster rate than renewable usage has.

A businessman and governor can certainly come to some sort of mutually willing and beneficial agreement regarding the management of, say, coal fly ash on the property of said business, perhaps in the area of how well all those expensive regulations and inspections are carried out, and Governor Pat McCrory did work for Duke Energy all those years. Oh, your downstream water is now a little polluted? Whoops, tee-hee! No crime, just two willing folks who came to an understanding, uh-huh.

The high cost of oil and low interest rates (and being completely and totally addicted to oil) are more compelling reasons why America went bonkers for Bakkenpuffs; the recent price dip should be a good test to determine just how resilient those producers are, and to see who is out swimming sans skivvies. Also, the population density is rather higher in Europe, which may nix or upsize the costs of any fracking, depending on where those hypothetical fields might be located (there was a recent 96% slaughter of the reserves projected for the Monterey Shale, fluffy optimism and bad data being hallmarks of this field), and the land usage rights would also need delving into. So whatever "new" methods there might be may not fly at all in the EU, assuming that there is profitable oil to be had—for example, how are those fields in Poland panning out? Hmm, hmm, "Fracking Setback in Poland Dims Hope for Less Russian Gas." Righty, then. Consider also the brutal decline rates of fracked wells; Rune Likvern has written several times on the "Red Queen Running" state required to keep the tight oil party flowing.

'The technology revolution that is "fracking"' is a curious claim (some would call it a lie), given that the technology is something like four to six decades old, and has been used to drill oil well before the recent high cost of oil (how about that global conventional crude oil peak back in 2005?) caused fracking to actually more than break even. Granted, "The high cost of oil revolution" would probably not sell copy, and the recent slide of prices will mostly put the hurt on one of the few bright spots (flaring pun included) in an otherwise stagnant or declining oil industry (the oil majors as recently as March were muttering something about the new "age of austerity" and "loosing their shirts" in natural gas).

Let's see, let's see...

02:15 AM cron job that did not run one Sunday, some important scheduled payments thingy, with other things then running expecting it had run, oh lord the manhours cleaning up and correcting after that disaster. Yep, servers were in US/Pacific, nice little time bombs left laying around for months until the pointless time wobble sets them off...good luck testing for that, hence the modern "just put it in UTC" to eliminate that class of problems. Alas, many servers still get placed in stupid timezones, or being so cannot be fixed (risk too high, bitrot, etc).

Then, at another company, the on-call got woken up each and every DST wiggle, because, you know, credit card latency was now 3600.00049996 seconds, or something, and hey! send pages! at who knows what hour; can't fix that software, legacy stack you see. On a positive note, the next version did run everything in UTC, thank goodness, but not after a few years of pointless, stupid, dumb pages.

Finally, there was the 2005 or so "energy savings" act, when they changed when the time wobble happened, and then everyone was spelunking around all the codebases, finding out how many custom date-time libraries had crawled into the systems (hint: lots) that all then needed updating. Maybe they found 'em all? Who knows, some reports might still be off by an hour, sometimes. Worst was the Exchange system, good fun post-change as they eventually threw up their hands and said "here's your new, empty calendar, good luck" and then 10,000+ folks were scavenging through old email invites to try to figure out who had been going to what meeting that was no longer there.

Probably seemed a good idea at the time. Isn't.

Incorrect, sir, I've RHEL6 systems with the traditional init that do sometimes randomly hang on NFS or tmp or lord knows what and need to be power-button-poked to get them to reboot, as requested. So, feature parity with systemd in that regard, if your claim is true. I have not yet moved anything to RHEL7, as there's been zero demand or need for it (Windows 8 on surface seems popular with the users; but hey there's always next year for Linux on the desktop, right?), and I think only earlier this week they fixed a local RHN satellite issue preventing access to necessary additional packages, plus there's that happy bundle of commercial CAD apps that would need to be got working on RHEL7, the typical sort of Augean shoveling the graduate student they probably aren't paying enough somehow isn't in a hurry to get neck deep into.

Startup time matters? Hmm. Let's see.

    15:11 up 39 days, 13:13, 5 users, load averages: 1.09 1.11 1.41

well that's my laptop, can't remember what I was doing 39 days ago or why I'd care how long it takes to boot, I could go make tea, or read a book, or whatever. Really not at all important.

Servers? Well, they may spend anywhere from ~2-5 minutes doodling around in the BIOS, so shaving a few seconds or whatever from the system boot time means they take about ~2-5 minutes still doodling around in the BIOS. If you've done servers right, there will be redundancy, so who cares how long server A takes to reboot when servers X, P, Q, M, and R are chirping merrily away. Sorry, but I'm just not seeing the need for speed.

    valen% uptime
3:22PM up 168 days, 14:53, 47 users, load averages: 0.58, 0.36, 0.34

Oh no! My slow OpenBSD server will reboot slowly when I upgrade to 5.6. Oh, the humanity!

The tired buggy whip trope is hilariously out-of-touch with the present situation. Switching from moseying horses about to wiggling a wheel, well, most anyone could and did make that change. Now, updating from mere wheel wiggling to data analytics or database administration or such, why that there probably requires a wee bit more spare time and training and learning and brainpower, and fewer will make that cut to those fewer jobs. I think some folks have been making noises about structural unemployment or the like, and the bell curve suggests that not everyone will via some magic whisk of a well-funded education wand meet those high skill jobs. What to do about such predicaments, well, the rich folks of Rhodes used to given direct cash payments to the poor, and there was the Roman "bread and circus" model ("The Economy of the Greek Cities", Léopold Migeotte), or there's always the social darwinism approach (mmm, cake!) and nothing particularly resolved yet from the "Discourses on Salt and Iron" days, but so these things go.

As for inefficient practices, I need only point to the lobster industry, whose hilariously inefficient capture process as compared to, say, the net-'em-all factory farming of fish (whose previously thought infinite stocks are somehow now collapsing) indicates that mere increased efficiency is not always the best of choices. Nor is forced inefficiency a good thing—I think Milton Friedman made some particularly boneheaded remarks in this area—but there are 7+ billion people who are usually happy to find and do meaningful work, even if it involves a shovel.

Selinux a must have? Hardly. Look at the security bulletins. Note the stupidly large number of exploits. Tally up how many would be prevented by selinux and where selinux would even be relevant to an attacker (who are your attackers, by the way?). Why not instead dedicate that time to fixing and auditing the code (see e.g. OpenBSD), and then only if there is spare time after all that work, only then consider the dubious benefit of a RBAC system. Consider two companies, 3-tier, sell stuff on the web, blah blah database blah blah email blah. One spends time setting up selinux, the other audits their code. An attacker desires customer data, and breaks into the selinux company via a code flaw (permitted by selinux) and reads the customer data from the database (permitted by selinux) and mails it off somewhere (permitted by selinux). The company that instead audited their code does not have the embarrassing flaw, because they found and fixed it, and were not hacked. Or what if the attacker, again via some local flaw, simply turns off selinux, and then does what they need to do? Again, time would have been better spent auditing and fixing the code, and not pouring manhours into the RBAC system.

Now let's say there is selinux AND the attacker cannot simply bypass selinux AND there is some customer data that selinux would prevent access to—say by not allowing a shell to run. This could be implemented in other ways (isolation of that customer data, so that even if they get a shell on some front-end machine, the critical data is simply not available there) that benefit the setup regardless of whether selinux is around. Oh but defense in depth, come the cries? Well, if you think you need a Maginot line off in the Pacific, or have some Potemkin policy that requires it, have fun!

The observed jadedness might perhaps stem from failed promises of energy "too cheap to meter," ah, yes, here's James E. Akins writing in "Foreign Affairs" in the 1970s on that:

    "Having argued throughout this article that the oil crisis is a reality that compels urgent action, let me end on a note of hope. The current energy problem will not be a long one in human terms. By the end of the century oil will probably lose its predominance as a fuel. The measures we have the capacity to take to protect ourselves by conserving energy and developing alternative sources of energy should enable us, our allies, and the producer nations as well, to get through the next 25 years reasonably smoothly. They might even bring us smiling into the bright new world of nuclear fusion when all energy problems will be solved. This final note would ring less hollow if we did not remember the firm conviction of the late 1940s that the last fossil fuel electricity generating plant would have been built by 1970; and that in this new golden age, the home use of electricity would not even be measured. It would be so cheap, we were told, that the manpower cost of reading meters would be greater than the cost of the energy which the homeowners conceivably could consume. But perhaps in 2000..."

coupled with the periodic media ado about cold fusion (debunked. again. Next!) and otherwise fusion running neck and neck with Mickey Mouse actually entering the public domain ("in 20 years", or five, or whatever), well, I am shocked, shocked and amazed that some humans might somehow have grown a mite bit jaded after decades of such antics.

Uh, CUPS made things new, but darned if I can figure out the magic of how its filters work compared to, say, LPRng, and the last time I went spelunking around in the CUPS code, well, I've since shutdown that print server and have outsourced printing to groups who are about as enthusiastic to support printing (oh boy, random software programs being thrown at random software execution environments, plus a real-world interface that jams when that room gets humid so ya gotta prop the door open, see?) as we were.

                                ptype = (cups_ptype_t) atoi(dests[i].options[j].value); // ewwww. But whatever.

"This is related to another aspect of changing the problem. I was once solving on a digital computer the first really large simulation of a system of simultaneous differential equations which at that time were the natural problem for an analog computer—but they had not been able to do it and I was doing it on an IBM 701. The method of integration was an adaptation of the classical Milne’s method, and was ugly to say the least. I suddenly realized of course, being a military problem, I would have to file a report on how it was done, and every analog installation would go over it trying to object to what was actually being proved as against just getting the answers— I was showing convincingly on some large problems the digital computer could beat the analog computer on its own home ground. Realizing this, I realized the method of solution should be cleaned up, so I developed a new method of integration which had a nice theory, changed the method on the machine with a change of comparatively few instructions, and then computed the rest of the trajectories using the new formula. I published the new method and for some years it was in wide use and known as “Hamming’s method”. I do not recommend the method now further progress has been made and the computers are different. To repeat the point I am making, I changed the problem from just getting answers to the realization I was demonstrating clearly for the first time the superiority of digital computers over the current analog computers, thus making a significant contribution to the science behind the activity of computing answers."
  — "The Art of Doing Science and Engineering" by Richard W. Hamming.

He has other positive quotes about analog systems, which do have uses.