Well, explicit stated dependencies are there. If you mean something beyond that, I get very concerned.

caching of input/output.

What i/o are you referring to? I/O generally is already cached as intelligently as the filesystem or block subsystem can manage. At filesystem or lower or inside the application are your opportunities to enhance things, not much room in between. If you mean cache data that is piped around or networked around, that is absolutely a horrible idea that is really infeasible unless it's in the application (it is impossible for an infrastructure to ascertain whether cached result is good enough in a generic fashion since it isn't in the middle of the transactions or understanding the flow.

This would be horrible. If it is a process that reads config only at startup, you have no idea of knowing when the changed on-disk copy is 'ready'. You cannot graft magic onto such a daemon. On the fly reconfiguration is already available even in standard libraries if applications want to do that. This is another problem that cannot be reasonably added in a sensible way without cooperation of the managed applications.

Something is very very very wrong in your case. Updates sometimes are more practical to reboot to just be sure that stale copies of vulnerable libraries are surely out (and certain platforms require a reboot to replace open files at all), but no reconfiguration necessitates a reboot short of reconfiguring very particular kernel/driver settings.

Being paid to do anything by definition makes you a professional. Professional does not mean 'better', it just carries the connotation since frequently someone who cannot get paid for their work where another can is due to things that lack. In coding, sometimes being 'professional' versus 'amatuer' really boils down to being loud enough to get taken seriously.

People have reported corrupt log files. The result is all the data is unrecoverable. The complaints have been answered 'as designed'.

When things are right, it works as intended. When things are bad, it can go far off the rails. Considering it is the system log used to debug what is wrong when things are off the rails, a full binary log is a dubious proposition.

There are benefits to binary log, but they could have been done to varying degrees with structured text and/or external binary metadata, rather than a corruptable binary blob.

I would argue that the raid is useless. Better to use the excess drive capacity for rsnapshot external with off site backup.

If theft or fire takes out your place, then that data is safe. Such an event would still be traumatic, but at least the data would be intact.

No,VHS itself is getting harder to get a recorder for.

No VHS notoriously looks worse and worse over time. Digital tolerates bit rot losslessly up to a threshold, then starts getting artifacts. Those artifacts are frequently no worse than how terrible VHS looks by that point of degradation

Sure keep the analogs since there is no harm, but don't expect them to fare better than digital backups

I have two external disks on alternating cadences of backup. At any given time, one or both of them are in a desk drawer at work (while I work, I keep both there, and take home the one that needs to be run that night).

Cloud for me is impractical as the price structure is pretty steep at these capacities. Even if it wasn't, my bandwidth is inadequate for the task. Offsite backup to my desk drawer is adequate.

You can encrypt the backups if you are concerned about the privacy of such a setup (the desk drawer locks, but the employer has keys).

I don't think Karl Marx would look at China and say 'yes, that's communism'. You have a pretty much capitalist economy in effect in China.

I'm pretty sure communism has manifested without tyranny. The issue is that human nature in practice doesn't let it scale to notable levels. Small communities being communist without tyranny happens ever so often. When you have the human connection face to face and there is not really any practical opportunity for some subset of the community to be overwhelmingly better off than the rest even if they had capitalism or tried, communism can work. However once one man is far enough from others to be somewhat apathetic toward them and/or perceive a chance for unreasonably better standard of living at the expense of others, the good facets of humanity that would enable communism go out the window.

Of course the risk for a benevolent 'commune' with nice principles to turn to 'cult' seems pretty high, so I guess even this assessment gives human nature too much credit...

That also addresses another concern, about people bringing in unapproved data preprogrammed in the calculators. If the calculators are provided, this isn't an issue.

Note that when I was in school, this is precisely how graphing calculators were handled. The school had a box of TI-81s shared amongst a few classrooms.

You are saying each educator must do a thorough evaluation of whatever device a student brings in, and assume that educators would be able to make an accurate assessment.

An approved list of models is significantly more feasible here. But no one other than TI seems to care. Presumably because the moment there is a viable alternative, the market will drop to thanklessly low margins.

Well technically the DK2 also has a touchscreen controller... There it's even sillier because it's never to be used and just on there since it's more trouble to rip it off than to leave it in the Samsung phablet part that's in there today.

At least here the device can be pulled out and used independent of the headset, so it makes more sense.

As a 50 dollar accessory for a note 4, it would be within the realm of reason. More than that and they are insane.

If I were in the market for a phone right now and the pricing for that accessory were announced and reasonable, I'd probably get a Note 4.

For one to call this 'nonsense' might be a tad unfair. This has some value. I personally want the equipment geared better for interactive gaming, but for non-gaming applications this could fit the bill fine (note they didn't even pretend to show a game, for good reason).

This may be related to the facebook acquisition. It might have been pre-deal influence by Facebook or the thing Facebook found out to make them buy Oculus. I could see facebook betting a bit more money on laying claim to a company that seems to be building a software ecosystem around them with more than one vendor. I wouldn't be surprised if Facebook approaches the likes of Asus, evga, Dell, Lenovo, et al to try to have them take ownership of the PC hardware piece to leave their focus on software enablement.

It's going to be a tough call if they can provide decent ROI on the 2 billion dollar acquisition. They'll need revenue from multiple fronts for something as invasive as this (VR won't be nearly as mainstream as the likes of Zynga games, it's just more of a burden than anything that has really lasted in the industry for the casual user).

If I booted a rescue disk, I could chroot in no problems. Now I need to make sure that I can spawn a new container rather than just chroot. systemd-nspawn is not that horrible, but it isn't as simplistic as chroot. Some people used chroot for security isolation for which it is inadequate, but it is a pretty decent debug facility/build tool. systemd could have done a better job of degrading capability for obvious debug scenarios.

This is generally the sort of problem that a project runs into when they decide that some ecosystem decades in the making can reasonably be so well characterized that they can model everything perfectly. Things will be missed. Additionally, it assumes the service being started understands it's dependencies all the time. In SysV scheme, an administrator or other application had a pretty easy time of pre-empting other well known services to alter behavior before them without modifying them. That's not so straightforward in systemd.

If I am into virtualization (basically having quick start firmware in arbitrarily small chunks of system), I already had amazingly fast boot with traditional OSes because each VM was more special purpose and only started very few init processes. RHEL6 upstart and RHEL7 are booting in about the same time for me in the VMs I've been doing.