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).
Systemd supports both:
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.
Speaking of fast boot, systemd is so fast that when configuring a static network interface, it will try to add the default route before the interface is up
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.
You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.
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.
more traditional systems have started to similarly fragment things, what with things like udev rules
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.
It means no such thing. You need to learn about spwan and fork, then get back to us.
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.
. The kernel does not run " in an equally critical context" at all
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.
There is nothing more inherently complex about systemd than any other init system
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.
Who cares? Do you really think it needs to be ported to Windows?
Do you really not acknowledge the existance of FreeBSD, NetBSD, OpenBSD, AIX, Solaris, HP-UX, and more?
If you like that old garbage, you are free to use it.
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.