The alien terrorists are bombing us. We need body cavity searches at all airports and major highway intersections!

It's a good thing it didn't hit the US. If I've learned nothing else from Hollywood, I've learned this... If any object strikes another object moving faster than about 20 feet per second, there will be a huge explosion.

Except for the very very rare incidents which are strictly for comedic value.

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.

I didn't say they would agree. I think I understand what they want and what they do get out of it, and don't agree with them. I don't call them idiots or anything, they have their perspective, I have mine. I see their points and will acknowledge and explain why my perspective doesn't agree with the value.

In this particular thread, there has been some people saying 'right on' and there have been some pretty angry sounding posts calling me a troll. There was a pretty level headed systemd advocate as well, so I guess not all of them are that way, just some of the most vociferous, but maybe that's just the nature of the beast in any discussion.

I do also want to say that your post is a credit to systemd advocacy. Level headed discussion of the issues rather than senseless ranting.

While there is a grain of truth, the rules are a bit more straightforward in SYSV. SYSV was created by people that were largely starting out and did KISS out of necessity. So one needed only to understand some relatively basic bourne shell and you could figure it out from there as needed, even if you didn't know it. In his example, environment variable fell out of the sky. In init script, you know it had to be set *SOMEWHERE* from that script. It sourced another file, bingo, there it is in plain text. There are some things in SYSV that are a little weird (runlevels being arbitrary numbers, but there's a handful of them and inittab was a relatively short file), but generally it was quite discoverable given relatively simplistic understand of shell scripting. In systemd, if the config files pan out right, then they are simpler than the SYSV scripts. When things go wrong beyond what the author had intended, sysadmin is less likely able to figure out what the developer did wrong and correct. This I think is the fundamental breaking point. systemd adds some features that I can't readily imagine being acheivable from shell scripts, but it's harder for a layman to dig into something that went wrong. This means software vendors can deliver more service automation and such more easily under something like systemd, so many software developers appreciate it. Sysadmins on the other hand cede the ability to be able to look under the hood themselves. It's a tricky walk.

udev is actually another beast that could use a lot of improvement, alongside DBUS. dbus, systemd and udev start straying from 'everything is a file' and start creating invisible constructs in a namespace that isn't really explorable. 'Everything is a file' sentiment has been lost. What people forget is that everything is a file really just means a pretty straightforward yet capable organizationed model that a client can explore. It's like RESTful in webservices are supposed to be (though that facet is also frequently unusable in some web frameworks, many do get it right).

Your results called out the Piledriver explicitly as 'per module' rather than 'per core' to make the numbers match. It basically validates the point you respond to. In practice, it's more complicated and can outshine hyperthreading in some cases, but in your specific citation the processor measures up if you pretend module==core rather than saying it is an 8 core system.

That scenario doesn't involve the special nature of pid 1 at all. Any pid can screw up a system. Traditional init is a handful of lines of compiled code and systemd is significantly more to assure services cannot escape their cgroup and other such tricks.

If pid 1 crashes, the only thing I can really do is sysrq. The division between kernel space and user space pid 1 is largely academic for a sysadmin afflicted by a crashing bug in either one of them. Yes there are thnigs kernel c code can do beyond the reach of user space code, but that was really not the point of the discussion.

If that were the case, why would systemd exist at all? Systemd exists because they wanted to pull off some tricks they couldn't do in an init system that could be followed by a simple 'set -x' in key locations. Like Windows, when things work, they appear simple enough on the surface. Like Windows when things go wrong, you are pretty well in a weird world.

Do you really not acknowledge the existance of FreeBSD, NetBSD, OpenBSD, AIX, Solaris, HP-UX, and more?

If the people who like straightforward init scripts don't bitch, then their preferences will go unheeded. It's better to bitch than be silent as your perspective is steamrolled out of the way. It's not 'old garbage' no more than the wheel is 'old garbage'. Just because something does the job and hasn't been mucked with in years does not mean it should be presumed garbage and replaced.