Well, then pretty soon those people so lacking in self control will do all their acting behind bars.

An obvious application for storing configuration in a database is when you have a cluster. Suppose I have an application with 400 settings. I have 10,000 nodes. Some settings are unique to each node, some are unique to a group of nodes, and some settings are common across all of them.

With a normalized database you could store every value once, and make one change to have it propagated to all your nodes. If you have a pile of text files in /etc then you either:
1. Really have the database storing the true values and just regenerate all your text files, which is really just the database design with a text-file compatibility layer.
2. Come up with some way of editing 10,000 text files across 10,000 systems to make the right changes to each one, trying to stay on top of all of them if that really is the master source of configuration for each one.

Most of the new configuration management paradigms are built around the concept that systems are not hand-built, but they're machine-built on-demand.

FTFY.

True, but still an utter red herring.

Tend to agree. The US wouldn't have any problem with the rebel forces, but just about anybody else would. Now that Russia is pulling out all the stops even the US would take care before intervening - they have some serious air defenses that are potentially effective against even stealth aircraft. I suspect the US could still overwhelm them, but it wouldn't be bloodless even if limited to an air war, and I doubt any battles would remain contained to the region.

Like the virus that attacked Iran's nuclear centrifuge?

My point is that using text files vs something else is a design decision with both pros and cons. I can understand why individuals have their preferences, but that does not make either design outright wrong.

I'm sure everybody has both made plans and is pretending to be surprised. That's just politics. Nobody says what they really think.

Does Germany want Russia invading the Ukraine? I'm sure the answer is no. If push comes to shove are they going to put principle above gas prices? Probably not, but we'll see. The downing of the airliner was taken seriously because so many of the dead were EU citizens, but even then it was just sanctions.

I'm not entirely convinced the US/EU would commit to warfare if Russia invaded Lithuania, which is a NATO member. I'm very skeptical that they're going to do more than sanctions over Ukraine. A shooting war with Russia means the entire US East and West coasts are within range of sub-launched cruise missiles, completely setting aside the doomsday scenarios. There was an uproar over closing a few lanes of bridges into Manhattan last year - imagine what will happen if key bridges along coastal rivers are destroyed? It doesn't take much disruption to have a huge impact on the economy.

There is actually a deeper issue than corporate security competence.

Imagine that a bunch of soldiers stormed the front door to their datacenter with APCs, tanks, and artillery support. They then removed hard drives and proceeded across the border to some other country. Would you consider this a bank security problem?

Banks don't have this problem because the government provides physical security against these kinds of threats. Sure, the bank is expected to lock the doors and have some guards, but they aren't expected to stop an attack of arbitrary determination.

With the internet we benefit from the free exchange of data across national borders. However, at the same time this means that computer security can be subjected to attacks of arbitrary sophistication, and national governments have generally not intervened.

Now, I'm sure more could be done to secure the average corporate network, the reality is that state actors are free to develop more and more sophisticated attacks free of interference. If I wanted to hack into some foreign bank I probably would have the FBI kicking down my doors before I got too far with it. The same is not true of an NSA agent doing the same thing.

I think the only real solution to this sort of problem involves border control. Establish agreements with nations to cooperate on prosecuting computer crime, and heavily firewall communications or block them entirely at the borders. Parties to the agreement would agree to not accept traffic from countries that aren't parties to the agreement. The downside to such a policy is obvious - far less freedom of communication, and that will probably support dictatorships and such abroad since we'll effectively be providing the firewalls for them.

Either that, or we just accept that data stored on networked computers is going to be insecure. There is no reason to think that security is a game where the defenders can ever win - that certainly hasn't been our experience in physical security.

I actually wonder how relevant CISC even is to people doing assembly programming these days. There is no reason you can't pull an LLVM-like move and target something other than the native instruction set when you are programming.

That is basically all the x86 does anyway - convert CISC instructions into microcode. There is no reason that an assembler couldn't do the same thing, further blurring the lines between assembly and compiled code. If the whole point of writing assembly is to optimize your code, and a RISC processor could run your code faster after low-level-compilation than a CISC processor could run it natively, then RISC is what you really want anyway.

Do you actually want to discuss this? If so, please do so politely.

You said "If /etc becomes a database, you lose the ability to use your standard tools on it, which, gasp, tend to work on text files, because it's the one single truly universal /and/ human-digestable format."

My point is that there is nothing human-digestible about a couple of magnetic domains in a sea of trillions of magnetic domains on a piece of metal. You need a lot of software to access it, and most of it isn't particularly interchangeable.

Sure, text files have certain advantages, but they have lots of disadvantages as well. If I'm spawning 3 million instances of some application server, and they all have slight configuration tweaks, it makes more sense for them all to check in with some kind of configuration management server or receive their state information at boot, rather than building a unique disk image for each one just so that I can stick a text file on it.

The problem with things like Ebola and such is that this is true today, and maybe there is a 95% chance that it will be true 5 years from now as well. The problem is that if there ever is a major outbreak we're going to be stacking the bodies in the streets. It is almost certainly worth having a treatment available, even if it never turns out to be necessary.

The same is true about having reserve antibiotics. They should ideally never be used, so you'll never see private dollars spent on them (who develops a product with the intent to not sell it?). However, if we do get some outbreak of antibiotic-resistant whatever we can now do something about it.

This is really the ideal domain of government - developing drugs that have the potential to benefit everybody but for which no market exists today.

I think it is probably worth having both models. Don't get rid of the patent system, but go ahead and have public end-to-end R&D with the government holding the patents and offering free licenses to US-based manufacturers (or those in countries that reciprocate and make comparable investments).

Private companies could still invest in Viagra and sell it for $5/pill, and if the government drops the ball then at least people have an expensive option instead of no option at all. When the government eventually comes out with its own cure, then prices will fall.

Interesting. Hopefully it can be toggled on/off. In any case, it still isn't part of PID 1, and you can run systemd without running resolved.