That's not due to better design, but more use of cheaper and softer materials. They're not built to last anymore. Give me a 10 year old Lian-Li case and band-aids any day over today's cheap plastic.
You just claimed your SysV init scripts are helping your software take advantage of cgroups.
If that's what you read, you need to practice your reading skills, cause they suck.
What I pointed out is that cgroups are separate from the init process, and can and do indeed run on sysv init systems too. cgroups has nothing to do with init, and runs separate from init no matter what you use for init.
When you brought up cgroups as an argument, it appeared to be from a false belief that systemd was needed for cgroups to work - in fact, it's the other way around!
And when systemd uses cgroups, it takes them over for its own purpose, which lessens the value of cgroups compared to systems where you are free to use cgroups from scratch. Freedom to choose - that's what makes Unix great. Poetterware takes away that freedom.
TCP isn't noticably more secure than UDP - the extra fields in TCP are unsigned and can be spoofed too. There are even a couple of attacks that only works with TCP, like source congestion. The only "security" TCP buys you is if you have a dynamic real-time alerting system for tcp sequence errors and similar likely to be seen in spoof attacks. You don't have such an alerting system.
Thus, security is implemented on top of the transport layer, where it works just as well for udp as tcp. The advantage of udp then is that you get more payload per encrypted or signed unit, thus higher speed.
That said, the main use of nfs is within secure perimeters, where speed and transparency is the main goal. In which case all you need is a honor system access control, designed to prevent users and apps from doing bad things no matter who they (say they) are. I.e. the focus is on what is shared, and what's allowed, not who you share it to.
Where Windows is very user focused in its trust based security model, Unix is very data focused.
A typical Windows share will allow any user to write and execute whatever they like. The users don't understand the "Advanced Security" properties anyhow, so implementing it will just lead to complaints. If a client is compromised, so is the share..
A typical Unix share will only allow users write and execute access to specific directories, no matter who they say they are. Remote root users typically get even less access, not for security but to prevent accidents. If a client is compromised, the shares should be safe.
NFS is crap too and in my testing also slower.
But nfs does not take over and cripple your dns server.
It's the hooks into and taking over parts that work fine on their own that's the problem with domain controllers and systemd. It goes directly against the Unix toolbox approach, and stifles innovation because now you have to do everything within the context of the super-program.
(As for your testing, did you try with jumbo packets? NFS supports it, and CIFS doesn't. It makes a tremendous difference, especially for writes to remote RAIDs or disks with a 4k block size. Also, avoid distros that set up NFS to use tcp instead of the default udp. That's a huge performance killer, and not needed unless you use hubs instead of switches or need to tunnel the traffic.)
Are you insulting the samba project ?
No, not at all. They produce the very finest shit eating utensils in the world. It's not the utensil that is the problem.
cgroups reduces overall system complexity by providing a means of managing process groups. cgroups are a new feature in the linux kernel. It exists for real reasons. I guess you think it would reduce complexity and keep it simple to just tack on cgroups to what SysV init already did, right?
What does cgroup have to do with anything? I run several systems with cgroup and sysv init. The two are separate, and there is no need for systemd for that.
None of your complaints are actual problems with systemd. It is just repeated propaganda.
Actually, they're all mine - no repeat at all. I have been a system administrator since the early 90s, and know what problems Unix like systems have. sysv init has not been anywhere near the top of that list. It was a great improvement over starting apps directly from inittab, and is something that has been working and has kept on working, precisely because it's so simple.
I guess you'd have to resort to comparisons that claim that SysV is even easier than DOS, because learning bash scripting and the standard SysV sh libraries is so much easier than learning that an
I say this with feeling: You are an idiot.
The problem is obviously not "learning that an
I get seasickness from some fps games. Strange enough I always get them from console FPS games. Only sometimes from PC FPS games. Maybe it's the framerate?
No, more the rubberbanding. Consoles don't have mice that can easily change acceleration and start and stop instantly, so to make games playable with a controller, the movements are not synchronized with the stick - when you let go of the stick, you don't instantlly stop, but your movement slows down to a halt over a small period of time. So your actions don't match your movements.
That's also seen in bad console ports, by the way.
That depends on whether the sickness is caused by the lack of leg movement or not. It think there's a good chance the problem is tied to the inner ear (or more precisely your sense of movement vs. visual feedback), or possibly something else, in which case a treadmill might not help at all.
Indeed - the Virtuex Omni is more likely to make things worse. Your eyes say one thing, your feet another[*], and your inner ear disagrees with the two.
Think about it - when you drive a car, you don't have to move your feet like a mad runner in order to avoid feeling sick. Your inner ear gets the cues from the accelerations, and those match what you see, as long as you look out the windows. If, on the other hand, you're a kid that reads or play in the back seat, your visual cues don't match your inner ear, and you may get sick. No matter what your feet do.
[*]: Unless adjusted so 1 m in the game is exactly 1 m on the treadmill, and unless you only move on flat surfaces, it is safe to say that your legs will disagree with your eyes.
They may slow down the world if this gets hyped to the point that it sells.
The problem is T.ANSTAAFL. This is Yet Another Implementation that seeks to reduce the average latency, without thought to the fact that what really hurts is the worst case latency bottleneck. This, like many other approaches before it, will worsen the worst case in order to buy the average case lunch.
You either have to come up with a solution that reduces the worst case, which is what really hurts, or make Pareto improvements, i.e. those that hurts no-one, even in corner cases.
This is not it. And yes, I have looked at it.
If they were in released software, well, it is normal that SysV get replaced eventually
I guess that depends on your definition of eventually. Good working designs don't have to be replaced any time soon.
We still have steering wheels on cars, despite some people in the 70s thought that joysticks and hand controlled throttles would be much better. Most of my clothes have buttons, despite Velcro and Ziploc. Heck, even zippers did not replace buttons.
Change for the change of change is seldom a recipe for success. The number of admins who complained about sysv init and not having an octopus program with hooks into everything were not really high. In fact, most admins have praised the toolbox approach where mounting is a completely separate thing from starting a daemon, and where nothing is truly integrated but everything is as separate as possible. The Unix mantra is "do just one thing but do it well".
I don't really care whether systemd shaves twenty seconds off the boot. My systems run for years, and take ten or more minutes from power-up doing hardware checks and RAID enumerations until they even start booting. That the boot process isn't abstracted and can be troubleshot by a human is far more important. So is the ability to easily have different systems with the same installation base do different things. Or make changes that you know won't take effect immediately. Or replace one thing without replacing ten more. Or use config files that you can do a simple search/replace on, unlike MSDOS
K.I.S.S., and avoid abstractions like the plague it is.
No, generally emacs users are happy with systems that have both emacs and vi, and emacs won't prevent vi (and all the tools depending on ex/ed) from working.
This is more like replacing ISC bind with samba domain controller. It's incomplete, broken by design, and has so many levels of abstractions that no sane person can admin it without specialized tools.
I'm already boycotting Red Hat 7 because of the poetterification that changes simple things that work to complex things that don't. Now Xorg will have to go too.
There already is a generator.
Expect the first planet to be named Lave, and be famous for its vast rain forests and Laveian tree grub.
The ONLY thing required for this to happen is secure communications.
That's like saying "the ONLY thing required is world peace".
What admins and engineers have known for a long time, and which people like Snowden provided evidence for is that secure communication is not a given, and highly unlikely to be an option for the masses.
If the government won't let people have a shadow economy they can't monitor or control, expect physical alternatives to take their place. There's plenty of precedence for turning to valuable metals when the currency cannot be trusted. And there are examples of governments banning both gold and silver trade as a kneejerk reaction, but that just moves the market to something else.
I'm switching out my lightbulbs - to halogen lights.
I can't stand the visible flickering of LED lights, nor that they don't light in a continuous spectrum. Some colors will show stronger and some less in LED light, which irritates me.
It's like listening to music with an 18-band equalizer, and three random knobs turned all the way up, and the rest down.
Halogen lights don't have that problem, and you can get them in many color temperatures. They're far more efficient than regular incandescent bulbs, while still having the advantages of an unbroken spectrum and little flickering. They're also safer for the environment to dispose of than LEDs.
Out of the 2 Android phones that I have had, zero of them came with Facebook preinstalled. I blame the mobile phone provider.
Your blame is at least partially misplaced. Manufacturers also bundle software, regardless of the carrier. The last two Android phones I had were bought directly from the manufacturer as never-locked phones (not to be confused with unlocked, which means the carrier lock has been removed). Yet there still was plenty of bundled and uninstallable software, including Facebook, Twitter, Google+, Drive, Hangout and Picasa apps and integration for pretty much everything. I have disabled more than 20 bundled apps.
The manufacturer assumes that everyone uses the big social media sites and want to tell their friends (and their friends) about everything they do, including what music (or audio books) they play, what pictures they take, and where they currently are.
It's good that social exhibitionism became acceptable (thanks to Jennifer Ringley more than anyone), but that it became the norm to the point that it's bundled is something I strongly object to. It's like buying a toilet and finding out that it (unadvertised) comes with wan connected crotch cams that can't be removed, just temporarily disabled.
Say "twenty-three-skiddoo" to logout.
