SoylentNews is people
SoylentNews
The good people over at Infoworld have published a story outlining why they feel systemd is a disaster.
Excerpt from Infoworld:
While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux—which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system—from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.
This discussion has been archived.
No new comments can be posted.
systemd: Harbinger of the Linux Apocalypse.
|
Log In/Create an Account
| Top
| 98 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
If the thunder don't get you, then the lightning will.
(Score: 5, Insightful) by VLM on Tuesday August 19 2014, @12:25PM
Its a fairly good super non-technical discussion of the inner platform software design anti-pattern.
So... we don't like some aspect of the OS. I know, I'll do a half ass job reimplementing it in something new and incompatible. Why not move everything else outside the reimp into the reimplementation. But due to inexperience, stuff that "didn't seem necessary at the time" will have to be redone in the new, inner platform. Eventually you'll have everything inside the reimplementation, exactly like the system was architected outside the inner platform, except less well designed, less battle hardened, and more buggy. Its a huge waste of time. If you want to run linux encapsulated in a new container, try LXC or KVM or vmware or make your own new container. Or if you want to reimplement linux slowly and difficultly, just do it. But don't screw everyone else's stuff up because you know nothing about architecture and can't figure out how to fork.
Another possible model is EEE embrace extend extinguish. Whoops I guess forcing everything in linux into violating Microsofts 1995 binary registry patent wasn't a very smart idea after all when after the move was complete MS decided to pivot into patent trolling. Well, I'm sure someone will make a lot of money both forcing this on everyone else while being bribed to do it, not to mention the lawyers, and the MS license salesmen.
There is also the incompetence model. Anyone who's been around the block knows monoliths are a pretty dumb design pattern by almost all metrics, and the internet just "loves" some of the systemd devs past products like pulseaudio so I'm sure systemd will be of equally high utility, reliability, and usefulness. They may just literally have no idea how misguided they are architecturally. Hopefully the whole project will crash and burn before it takes all of the linux community with it.
I'm curious how the (perhaps not public yet) non-systemd forks are doing. Obviously everyone (as in the general public of admins, etc, including myself of course) will move to the systemd-free forks given the choice. Nobody wants systemd except for a couple corporates (doing EEE?) and their paid astroturfers.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @02:51PM
i'm still hold a fading hope that debian sticks with sysvinit as default
if not, it will always be an option
(Score: 2, Informative) by bucket58 on Tuesday August 19 2014, @03:47PM
Be scared. The Debian systemd package maintainers and their friends are doing a fine job at extinguishing any means to run non-systemd init in Debian.
(Score: 3, Interesting) by FatPhil on Wednesday August 20 2014, @08:44AM
I've been Debian-only for 14 years. My next install (one of my servers needs replacing soon, I'd like it to be replaced in a controlled fashion rather than a panic) will be something else, definitely something non-systemd. Perhaps Gentoo, but I've not liked their way of unrolling loops in the past. But to be honest, I might even leave the Linux fold and hit one of the BSDs.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Informative) by cykros on Tuesday August 19 2014, @07:35PM
Debian may let you down, but there's always that distro that's even older than Debian kicking around, and I really don't see Patrick Volkerding giving us a Slackware that uses systemd. We're still using lilo, ALSA, and sysvinit here in the slack world...though you don't hear about us as much, because our documentation and organized, accessible system really minimizes the need for massive forums over every little thing someone might want to do with the "user friendly" "easy" modern systems that have been fed to the masses.
And, failing that, there's always the BSD world. With Linux distros racing to abandon the Unix philosophy, people who like the Unix way are being left with little choice other than to return to Unix. I'll be sticking with Slack personally, but definitely am a bit less hopeful about the future of Linux than I was 10 years ago with all of these recent trends.
(Score: 5, Informative) by VLM on Tuesday August 19 2014, @12:28PM
Here's the wikipedia summary of the linked article:
http://en.wikipedia.org/wiki/Inner-platform_effect [wikipedia.org]
And I directly quote wikipedia: "The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered by William J. Brown et al. to be examples of an anti-pattern."
Another example I can provide is see the "wayland" project pitifully attempting to replace X as another example.
(Score: 2, Interesting) by epitaxial on Tuesday August 19 2014, @12:45PM
I agree systemd is a pile of shit that needs to go but X really does need a ground up rewrite. We're dealing with 30 years of legacy bullshit and slowness.
(Score: 5, Insightful) by VLM on Tuesday August 19 2014, @01:13PM
And by a study of the inner platform effect I guarantee the loudly trumpeted solution to "bullshit and slowness" will inevitably slowly buggily and ineffectively eventually reimplement the same "bullshit and slowness". Just watch, it'll be fun.
Just ask yourself, whats changed in the use case? Oh, nothing? Well then.
(Score: 5, Insightful) by forsythe on Tuesday August 19 2014, @02:30PM
I agree with your appraisal of X (and systemd, for that matter), but I'm also growing increasingly wary of ``This is broken, let's rewrite it to be awesome because we're geniuses!''. Systemd (vs. init), Pulse (vs. ALSA, OSS), Wayland (vs. X) any new DE (vs. the previous version), new udev (vs. old udev), etc. all leave a bad taste in my mouth. X certainly has the best argument for replacement, but I'm not convinced that Wayland is the necessary replacement.
Libressl (from the OpenBSD folks) is the only major rewrite project (that I can think of right now) which I'm actually anxious to use.
(Score: 5, Informative) by PinkyGigglebrain on Tuesday August 19 2014, @07:00PM
Lets not forget GRUB, it used to be great, everything in one config file. Want to change the default wait time, a kernel argument or add an entry all you had to do was edit one file and reboot. Done. Now you have to find the right "configlet" file, among 20+ other files in different directories, edit that file, then call some utility that takes all the configlets and creates the single config file that you can't edit directly anymore. And the documentation is a steaming pile. The improvements added between the versions didn't warrant a complete rewrite of the configuration process. First thing I do on a new install is purge it and install grub-legacy. I can live without being able to boot from an ISO in grub, I've got VMs for that.
"Beware those who would deny you Knowledge, For in their hearts they dream themselves your Master."
(Score: 3, Informative) by zafiro17 on Tuesday August 19 2014, @07:43PM
Glad to hop on this bandwagon. OP is totally right. I just downloaded and installed LinuxBBQ the other day (www.linuxbbq.org) and by default it installs LILO and I found myself gushing over how simple and easy LILO is compared to Grub legacy, too. I accepted Grub over LILO because it did away with the risk of forgetting to re-run lilo and borking your system. But it was never clear to me why Grub needed to be updated. In fact somewhere out there is a little utility you could run on a floppy disk that would let you boot Linux or a dozen other OSes. Forget what it's called, but in theory it provided more improvements over grub than the new version of grub ever did. Fooey on all this "improvement." Get offa my lawn, while you're at it.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 1, Interesting) by Anonymous Coward on Tuesday August 19 2014, @10:03PM
a little utility you could run on a floppy disk that would let you boot Linux or a dozen other OSes
Sounds like you're talking about PLoP Boot Manager.
Smart Boot Manager is another that is commonly mentioned.
There's a scad of them. [wikipedia.org]
-- gewg_
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:28PM
If, instead of replacing your working kernel, you added a second kernel entry at the end of your LILO config, then if you forget to rerun LILO the worst that happens is you have to boot into your old kernel, run lilo, then reboot.
(Score: 2) by Pav on Wednesday August 20 2014, @11:59PM
more complicated without adding much (directly related) benefit = breakage
(Score: 2) by Subsentient on Saturday August 23 2014, @05:44AM
Use syslinux, you swine. Syslinux will crush you all!
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by cykros on Tuesday August 19 2014, @07:46PM
I'm not sure it's fair to compare pulse to ALSA/OSS, as they operate on separate levels and really aren't there to do the same thing at all. If anything, it's worth blaming the distros for really going out of their way time and again to break things.
I personally use Pulse on Slackware (making me in a very small minority). Because Pulse allows me to do things (using ALSA) that ALSA cannot do by itself, such as output my music from one sound card (speakers) while another audio stream (perhaps a private video call) to a headset, all at the same time.
Thing is, Pulseaudio works fairly reasonably for what it tries to do (once ALSA is reasonably configured to output to it). The biggest issue with it seems to be that distros are assuming that people need this functionality badly enough to make user after user spend hours figuring out why they're getting no sound at all from a fresh install that is more complicated than it actually needs to be in the first place. While it's gotten better over the years, it still seems nuts considering that most users really just would be fine with a working ALSA configuration using dmix for hardware mixing, and if they needed pulse, should be able to just grab it themselves (just like people do with Jack...).
As for most of the rest of your examples though, I'll mostly agree. While I don't mind the exercise of making new tools to try to do it better, or just increase the options out there, it is a little scary watching as the distros line up to all adopt the same thing as all of the rest regardless of the fact that it's unnecessary and adds more confusion and general bugginess to the mix. Whatever happened to "if it's not broke, don't fix it"?
(Score: 3, Insightful) by NCommander on Tuesday August 19 2014, @02:10PM
There are legitimate design issues with the X11 protocol that makes things much more difficult than they should be. THe reason screen flicker is such a problem on Linux is due to this in part. With Wayland, the problem is the improvements can only been seen by those familiar with X11 and its "pitfalls", a pretty good explination is available on Phoronix [phoronix.com]
My problem with systemd is its upstream is an ass in the sense of "the my way or the highway". Unlike most folks, I actually find PulseAudio tends to improve life vs. make it more painful (but I use bluetooth headphones a lot; try making those without Pulse (aka, raw ALSA) and not ripping your hair out), but I accept the initial implementations were half-baked, and there are still a lot of issues though I see this more a fact that sound on Linux is braindamaged more than anything else (ALSA's APIs are horrorifying to say the least; given OSS is now GPLv2 licensed, I *really* wish the kernel folks would at least consider a move back).
Personally, I never understood the obsession with cold boot time; in Ubuntu, before we had several dev cycles focused on it, our boot time was ~30-45 seconds. I *kinda* get the point of it, but I feel that if a user has to reboot more than once a month (for kernel upgrades/etc), then we've done something wrong. In the server space, you usually have 5-10 minutes of firmware time dealing with RAIDs/SCSI/etc on a cold reboot before the OS even gets a crack at starting up. Now, I do agree sysvinit was getting long in the tooth; it was far too easy to hang a system due to dependency loops and such; I love when a system failed to boot because the network was down, and Canonical took up the challenge with upstart, written primarily Scott James Remnant, which was fully sysvinit compatible, a drop in replacement for init (something launchd, the other candidate wasn't), and it does one job and does it well.
I don't think I've ever seen anyone complain about upstart at any significant length. I was truly sad that Debian chose to adopt systemd, but I don't think they had much choice int he matter; they don't have the resources to patch GNOME and other userspace stuff that wants to depend on systemd. I accept a lot of things systemd is trying to fix, like logging, is stuff that could be improved, but you improve it by patching rsyslogd, not putting it all in PID 1. Honestly, at this point, I think the only thing that's going to kill this brain damage is if Linus does something insane to replace it, but systemd has RH backing it all the way, and doing everything to entrench it as much as possible.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @02:23PM
I wonder: X11 was a successor of X10. So why not simply make an X12 which fixes the main problems of X11 while keeping the good parts of X?
(Score: 3, Informative) by forsythe on Tuesday August 19 2014, @02:37PM
That thought [x.org] has been tossed around a bit. I would be heavily in favor of it. Unfortunately for me, it looks like most recent effort is going into Wayland.
(Score: 2) by tangomargarine on Tuesday August 19 2014, @04:31PM
For those not wanting to Google it themselves, X11 was released in September 1987. X11 actually refers to the protocol it uses to get stuff done so if we were to follow the naming terminology X12 would be a protocol that may not be backwards-compatible (?).
Doesn't sound like a bad idea to me.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by No.Limit on Wednesday August 20 2014, @11:33AM
From NCommander's link (1st page bottom) [phoronix.com]:
Really good article, very recommendable.
(Score: 1) by cesarb on Tuesday August 19 2014, @02:56PM
Think desktops.
Arrive at work at morning, turn desktop on. Leave work at night, turn desktop off.
Also for laptops, if you're not going to use it for more than a few hours, it's better for the battery to turn it off completely.
The logging (systemd-journald) lives on a different PID, not PID 1.
(Score: 1) by cout on Tuesday August 19 2014, @03:08PM
And what do you do when you need to log something before the logger daemon has been started?
I have as strong a distaste for the systemd monolith as the next guy, but I kinda see why the devs are wanting to move in that direction. It's wrong, but natural.
(Score: 3, Informative) by NCommander on Tuesday August 19 2014, @03:30PM
Thanks for the correction on what goes in PID 1, systemd isn't QUITE as abraindead as I thought it is, but I've recently had my first RL experiences with it on Fedora (helping a friend managle postfix into working), and it managed to cause nothing but frustration in detecting new service files, and then confirming they run. I don't understand how it can be hard to do any of this; half the time, I was fighting systemd to get shit to properly enable (not knowing I had to tell it to rebuild its internal index), and then getting misleading messages from status.
What a mess.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @03:49PM
Solved by a working hibernate to disk. Arrive at work, hit "on" button, unhibernate, work.
Leave at night, hibernate back to disk, power down, wait for morning.
Also solved by a working hibernate and working suspend.
Am I going away from it for 60 minutes - hibernate to disk.
Am I powering it off to take it through TSA's body cavity search? Hibernate to disk.
The solution is not to "cold boot faster". The solution is "never need to cold boot, ever".
If all this effort spent on rewriting an init had been spent on fixing issues with suspend/hibernate, image where Linux's suspend/hibernate would be now.
(Score: 5, Funny) by forsythe on Tuesday August 19 2014, @05:07PM
Tongue in cheek, I can imagine. We'd have ``hibernated'' running on PID 1 and it would be slowly engulfing cron, video drivers, input devices, udev, network management, and a host of other things. I don't think I want ``all this effort'' to be spent on anything close to what I use, actually. Effort is good, but not this effort.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @05:37PM
That's YOUR solution(*). Not everone elses.
*) and currently mine as well. this thing wakes up from suspend under a second. if hibernate was an option i'd rather reboot since 16 gigabytes is a whole lot of shit to read from disk.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:34PM
Except that, unless you are doing something really weird, most of that 16gigabytes is cached filesystem data. So step one in a hibernate is: sync dirty disk caches out to their backing files. After syncing all the cached filesystem data, what's left to actually write to disk is often far less data than 16G (on the order of 2-4G). That's a lot faster than a reboot, which entails restarting your "desktop" (in whatever form it is) as well as restarting any running programs and getting back to where you were in those running programs.
(Score: 0) by Anonymous Coward on Saturday August 23 2014, @07:18AM
Even 2-4GB is a gargantuan amount of data. Not only the actual working set of whatever you are doing is way less than that but most of it is also redundant. If we didn't have as braindamaged systems as we do, the computer could very well boot "instantly" to the point where you could continue doing whatever you were when you shut it down. You've just learned to accept that it doesn't.
Heck, even PCs used to do that pretty fast at some point. The slowest part might have very well been turning on the CRT since it needed some physical warm-up time to be usable.
(Score: 2) by VLM on Tuesday August 19 2014, @03:00PM
No coincidence the two lines below are found in the same post about upstart. They should have just stolen the name and started calling themselves "sysvinit 2.0"
"it does one job and does it well."
"I don't think I've ever seen anyone complain about upstart at any significant length."
There are some architectural issues with upstart. The vulnerability and reliability surface of "lets run us some bash scripts" is immensely smaller and better debugged and better reviewed than a big ole event driven state machine, so its inherently always going to be worse than sysvinit for all tasks other than rebooting quickly which isn't an issue anyway. Then again the bash scripts have their own interesting surface of vulnerability and NIH and repeated (sometimes buggy) implementation of the same tasks so the net result is probably about as bad. Or the TLDR is the security problems with upstart are not likely to be worse overall than bash scripts, but would be somewhat different.
The systemd guys need to read this line from the upstart docs
"This design is sensible and clean: the init system itself must not be compromised since if it fails, the kernel panics. Therefore, any functionality which is not considered "core" functionality is farmed out to other daemons."
And realize the only thing worse than a kernel panic is getting owned. Trying to shove more eggs in one basket, systemd style, is just dumb from a security perspective. And now they want to wedge logging in there to make it harder to trust the logs when you get owned. Thats great. Just great. I'm sure the KGB wants all IDS and firewall stuff in there too. Its almost like the NSA or the .ru people or microsoft are paying the systemd people to screw security up.
Fundamentally init of whatever system is just a batch operations queueing system where some jobs run forever, others are restarted, others run after other jobs successfully complete, etc. This is not exactly new tech in IT land. Someone should unify that experience between system and user (preferably without including emacsd and syslog and probably a mp3 player like the systemd guys would do) and make a really good universal batch system. A really good batch system in all machines would be quite helpful in my line of work because I just end up installing "torque" or something anyway on my data-processor-nodes. I am pretty sure torque would not be the ideal /bin/init replacement, given how well it jams itself and how poorly it recovers from problems, but the general idea stands. Or rephrased upstart could be hacked into a weirdly usable batch processing system in userspace. Every time I swear at torque I'll think of how I'd rather be using some userspace variant of upstart. Likely because upstart hasn't crashed and jammed and pissed me off (although in production with random user submitted jobs maybe it would)
(Score: 2) by WillR on Tuesday August 19 2014, @03:15PM
(Score: 4, Insightful) by VLM on Tuesday August 19 2014, @05:18PM
LOL thats kind of the point, if bash has a priv esc hole, its going to be found probably well before it becomes an "init system" issue. Also if it has a hole it was probably found in December of 1995 which is great seeing as I've kept up with patches since them. Systemd, probably none of the above. You'll find your bugs the hard way.
"that only one or two maintainers really understand" No they're not that hard. And fairly well standardized. Much simpler to learn and understand than the internals of the replacements. Which is scary.
(Score: 4, Funny) by mrider on Tuesday August 19 2014, @07:31PM
Because all-new code is bug free, while old code accumulates bugs like barnacles.
Doctor: "Do you hear voices?"
Me: "Only when my bluetooth is charged."
(Score: 2) by NCommander on Tuesday August 19 2014, @03:23PM
There are legitimate problems with sysvinit, specifically, dependency tracking is a hack and fragile at best, requiring ordering by hand to make sure things come up right. A dependency based system like launchd/upstart is worth it in my opinion since it drastically reduces boot fragility. Upstart DOES have some issues (try using Ubuntu in a chroot without replacing initctl with /bin/true), but all things considered, it was the "right" approach. Debian experimented with replacing sysvinit with upstart, and nearly did so right about the time systemd started becoming a thing.
Once I'm free and clear of professional obligations, I'm going to take to running FreeBSD for awhile, and try to get some perspective on things.
Still always moving
(Score: 1) by cout on Tuesday August 19 2014, @03:05PM
I agree that the big benefit of pulseaudio is bluetooth support. But I'm yet to use any bluetooth device under desktop linux in A2DP mode that doesn't drop out due to overflow. And while that's likely the fault of bluez or blueman or whatever and not pulseaudio, it means that bluetooth support isn't a particularly convincing argument for me to have all the additional latency imposed by pulseaudio.
(Score: 2) by NCommander on Tuesday August 19 2014, @03:28PM
A lot of the experience is just being able to sanely reroute audio from point to point; on my desktop, sending some streams to headphones while other to HDMI is a breeze with pulse. The fact though is we shouldn't need pulse to do this, almost everything pulse does with the exception of network audio routing can be done directly by ALSA; the problem is the API is poorly documented, and what few tools are even worse. In my little bubble of the world though, pulse has been relatively trouble free, and it does solve some actual problems.
Still always moving
(Score: 2) by Nerdfest on Tuesday August 19 2014, @04:04PM
Likewise. I use PA heavily, including its BlueTooth support. I use BlueTooth headphones and a BlueTooth receiver on my stereo and it works very well other than dropping the signal when I walk between the machine and the receiver sometimes. Apparently I'm very radio opaque.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @12:30PM
didnt read the link even the last time but seems I was spot on:
nobody cares if we can invoke the *nix spirit early on in the boot process, that is running mutiple programs at the same time and if using mutiple terminal even being able to start different programs at the same time. this good.
but it should be: "do one thing and do it well", in this case the one thing would be "system boot really quickly"?
too much is too much maybe?
but why was it adopted so rapidly by all distros then? it seems in the scramble to bring linux to desktop some people put some stones in the way ...like maybe gnome3 needs systemd to work?
so charging full steam ahead to the linux desktop the "other general" is outflanking us and not nuking the spearhead but the supply lines -aka- the linux boot process itself. who cares if the linux desktop then wins if the boot process turns into an abomination?
boot meet ass.
(Score: 3, Informative) by Anonymous Coward on Tuesday August 19 2014, @04:15PM
Politics. The "right" people in the right place with the right agenda. SELECT * FROM maintainer, systemd_dev WHERE maintainer.name=systemd_dev.name OR maintainer.name=systemd_dev.buddy.
Another thing that happened slowly and people didn't see coming is that other tools were introduced in all distros and then after a while the dev said "oh well, now we depends on systemd, if you don't like it, find yourself a replacement tool". Of course the devs were also systemd's, or closely tied with them. Think Red Hat.
same kind of thing that made Debian pick libav over ffmpeg. The choice wasn't technical, the maintainer was on libav side.
now get off my tinfoil hat!!
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @12:44PM
as someone who had to maintain ffmpeg software on Debian, the changing and breaking of the api with every minor version was getting to be a major pain in the ass. ifdefs around minor version numbers everywhere. I can't say if libav will be any better, time will tell, but I hope so.
(Score: 5, Informative) by Anonymous Coward on Tuesday August 19 2014, @04:29PM
Because the group of autistic savants that are creating systemd are also the same group of autistic savants who create gnome. So they tied gnome and systemd together so tightly that you can't use gnome without using systemed. And so, all the folks who think they need gnome now believe they "need" systemd, because gnome needs systemd.
If it were a for-profit business it would be kind of like tying one's internet browser so tightly to one's operating system that the browser can't be separated from the OS without breaking the OS, and the OS can't be separated from the browser without breaking the browser.
Oh, wait, there was a corporation that did try that. And, hmm, they were found guilty of illegal, anti-competitive tying for having done so.....
(Score: 5, Insightful) by tangomargarine on Tuesday August 19 2014, @04:47PM
Another reason that I'm glad I jettisoned GNOME over the Unity/GNOME3 debacle. I find XFCE much cleaner.
I expect the problem though is that GNOME is "that thing Ubuntu uses" so people gravitate towards it without thinking.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @05:06PM
GNOME chose to isolate itself from users and it has made itself reliant on systemd? Now the majority of the distributions are kowtowing to them and switching to systemd? Should just leave systemd out and let them whither away alone on their imaginary perch atop it all.
(Score: 2) by Magic Oddball on Wednesday August 20 2014, @03:55AM
What the hell do systemd/GNOME 3 have to do with whether a person's autistic or not?
Oh, I see, you meant that "I disagree with what these developers did, so I decided to call them 'autistic' to show how much I hate them, since it's not considered cool to say they're girls, black or gay anymore."
You can make your point without referring to other 'kinds' of people as a slur -- please do so.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:07PM
"nobody cares if we can invoke the *nix spirit early on in the boot process" - bullsh!t. Many people care which is why many are against systemd. One for one.
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @03:03AM
this was a *jab at the fact that if something works and works well then nobody "cares" as in "up in arms with flaming pitchforks".
if it works we mostly just use it (maybe with a small smile) but we hardly ever say "thank you"...
(Score: 5, Interesting) by Lagg on Tuesday August 19 2014, @12:35PM
The summary at least (didn't really care for article to be honest) describes exactly how I've been feeling as of late. I liked the technical concept from the beginning and in the first release I was in heaven. We finally got rid of the ugly bloated out bash script hacks that people for some reason think is in line with the unix philosophy and instead we went to simple .ini file formats and very neat daemon control with a beautiful parallel start implementation.
Then the next releases started happening.
Then the forceful cramming of feature after feature.
Then came the attempt to replace mounts.
Then came the half-cron replacement (it really isn't a replacement though, which is worse in some ways)
Then came networkd
Then came udevd and the bizarre can of worms that was the dbus situation.
It's depressing, honestly. And I'm pretty goddamned generous towards systemd since I actually like the simple DHCP and NTP implementations as well as the socket file replacements for [x]inetd. I also like the highly granular log control and metadata. But it's getting to be too much...
I do however think there's still hope. I think that there's a real possibility that they can fix it, refactor it and decouple everything such that it's all modular and separately packaged and systemd can instead be an umbrella project of sorts. That fixing will likely have to start with expelling the current maintainers (not necessarily Lennart, but certain ones) particularly the jackasses that think they own the system from the kernel up. The arrogance shown in that kernel command line thread on the mailing list blew me away.
http://lagg.me [lagg.me] 🗿
(Score: 5, Insightful) by Anonymous Coward on Tuesday August 19 2014, @01:20PM
It's poorly engineered crap, talk about throwing out the baby with the bathwater!
Systemd needs exorcising while we still have the chance. Replacing a traditional unix init is not a difficult task but replacing systemd is already a non-trivial undertaking.
(Score: 4, Informative) by cafebabe on Tuesday August 19 2014, @01:28PM
systemd is supposed to replace sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd. As noted in https://lists.fedoraproject.org/pipermail/devel/2012-October/172163.html [fedoraproject.org] via https://soylentnews.org/comments.pl?sid=3380&cid=81660 [soylentnews.org], systemd also includes a QRCode generator and a webserver (running a root?) so that the (easily corrupted) binary logs can be viewed.
The one thing that isn't glommed into this design is PulseAudio.
1702845791×2
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @01:43PM
Heh, it's only a matter of time; although it will undoubtedly be an incompatible fork of pulse audio.
(Score: 2) by Anonymous Coward on Tuesday August 19 2014, @02:31PM
How long until they move Gnome into systemd? After all, it already depends on it ...
But then, just wait for the next step: Moving things into the kernel. A kernel is not complete without a kernel space web server to control kernel parameters! ;-)
(Score: 3, Insightful) by Lagg on Tuesday August 19 2014, @02:41PM
and now you've instantly fell into the political bullshit that stops sincere criticisms from going anywhere and at least for me nullified whatever point you may have had. The "webserver" is systemd-journal-gatewayd, not only a separate binary but one that is disabled by default and actually a potentially useful method of sending journal records to another system. I don't know why I bother trying to initiate discussion and encourage critical thinking for a topic like this. People just fall into lemming-like parroting of false information that only became moreso as it went up the grapevine. I don't get why people think of this as some kind of bizarre government proprietary software. You can look at this shit yourself and give feedback if you can handle doing it sincerely.
and no, the fucking thing doesn't run as root. It runs as systemd-journal-gateway. Way to go guys with modding informative. Because that's what we have here. A post jam packed of informative info.
http://lagg.me [lagg.me] 🗿
(Score: 1, Insightful) by Anonymous Coward on Tuesday August 19 2014, @04:33PM
I'm sure I heard of something like this once... I think it was called syslogd. This was back before the dark times, before systemd.
(Score: 2) by Lagg on Tuesday August 19 2014, @06:15PM
Yes I've seen this smartass argument too. Problem is, log forwarding was nothing like this and all things considered was less robust due to it being both an ad-hoc protocol (okay, it was technically based on the syslog rfc but so much crap has diverged from it that it may as well be ad-hoc) and not having a really easily deserialized format like json that can be easily read by something that isn't another logger daemon. But of course when have facts like this stopped people from claiming that the journal gateway is somehow reinventing syslog's forwarder despite being nothing like it whatsoever and intended to be more than just forwarding to another daemon.
http://lagg.me [lagg.me] 🗿
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @09:56PM
Right, let's make this easy. I was debunking the quoted section and specifically your claim that the webserver is "a potentially useful method of sending journal records to another system".
As for json, yes it's much cleaner and more expressive than ini files -- consider...
... because systemd authors didn't. And it may also make sense as a serialisation format for logging, along with a new RFC for remote logging. And basic log tampering on the local machine could be prevented with checksumming just as effectively as it is prevented by a binary log format. Only the json for configuration stuff has anything to do with a pid 1 replacement though!
(Score: 1) by wantkitteh on Tuesday August 19 2014, @02:34PM
I can think of a good idea - take the bits that consensus of opinion likes* and fork them into their own package for people who don't like bloat.
*I never said it would be easy.
(Score: 4, Informative) by zafiro17 on Tuesday August 19 2014, @12:43PM
Hello, is that you, FreeBSD?
:Yeah, it's me.
What's up, buddy? What do you want to say?
: "Ha ha, suckers!"
Seriously, make fun of BSD being dead, etc., but in fact FreeBSD is highly suspicious of major architectural changes like this, loves its init scripts, doesn't worry about boot time etc., and in sum has been insulated from all this crap. And that's why I like it.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 1) by GeminiDomino on Tuesday August 19 2014, @01:06PM
Has FreeBSD fixed its packaging dependencies yet, so I can install a *AMP server and not inexplicably end up with Xorg and a desktop, without having to compile it all from ports?
(And no, this isn't a dig aimed at flaming at FreeBSD, it's a check against suitability of purpose)
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 3, Informative) by zafiro17 on Tuesday August 19 2014, @01:24PM
Short answer: yes. Not sure what packages you installed, but I run several servers that are all mixes of LAMP and Postgresql, and not a single one of them installed even X.org, not to mention a desktop. You seem to have not learned enough about the OS before getting started.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 1) by GeminiDomino on Wednesday August 20 2014, @06:14PM
Actually, when I was a "junior sysadmin" back around the turn of the century, we had several FreeBSD servers (I think we were on 4-STABLE then). We had few enough then that "Make buildworld" on the heterogeneous servers was doable, and I always loved working with it.
The set up I have to deal with, now, though, is almost an order of magnitude larger, and so having to compile everything for every update is a dealbreaker. I'm not sure how that's "not learning enough about the OS", unless that was just an unneeded swipe because you think, despite my explicitly disclaimer, that I was bashing it. I had to stop using it for logisitical reasons, and so asked those who might be more up-to-date on it whether an issue had been addressed.
"We've been attacked by the intelligent, educated segment of our culture"
(Score: 4, Insightful) by VLM on Tuesday August 19 2014, @01:21PM
"doesn't worry about boot time"
This is the weirdest systemd argument of all. I guess their plan is to crash and kernel panic so often, that boot times will start to matter. What are they doing that they have to reboot so much, and given how hard/ssd drive and CPU technology only gets faster, the boot process is naturally faster every year anyway. And the init stack is immensely smaller than, say, samba, so if you're spending most of your boot time waiting for samba to load and settle down, then as a rounding error, who cares about the init system as long as its reliable, simple, easy to use, and doesn't screw up (aka not systemd?)
Its a world of virtualized servers on big iron that boot seemingly instantly, and 2 watt raspberry pi that are never powered off because thats only $2 of electricity per year, and non-virtualized servers that never need rebooting, and laptops/desktops/tablets/phones that sleep not reboot.
Why do all that work and screw up so many things just to make a meaningless metric of something that doesn't matter, better?
(Score: 4, Insightful) by ticho on Tuesday August 19 2014, @01:25PM
Because it looks good on a powerpoint slide.
(Score: 2) by VLM on Tuesday August 19 2014, @01:33PM
And that feeds right back into the argument of no one wants it unless they're subject to direct corporate influence, and as soon as systemd-free forks are inevitably released, they'll be a stampede away by everyone not subject to direct corporate overlordship.
(Score: 3, Informative) by zafiro17 on Tuesday August 19 2014, @01:53PM
No need for a stampede. There are a hell of a lot of distros out there, and now or soon there will be distros that specialize in not having systemd. Choose one, and live happily ever after. Gentoo was mentioned by name. Head to distrowatch.org and see what you can find. It means you won't be using one of the big/classic distros like Fedora (obviously) or SUSE, but there have got to be other Linux distro packagers who decide to buck the systemd trend. And if there aren't any now, there will be some soon. Meanwhile, as I mentioned, there's always FreeBSD on the server, and PC-BSD on the desktop (which is really just FreeBSD underneath anyway). If PC-BSD likes your hardware (it didn't like my network card, for example), it's a decent KDE desktop with lots of other stuff waiting in the repositories to be installed.
Dad always thought laughter was the best medicine, which I guess is why several of us died of tuberculosis - Jack Handey
(Score: 2) by DECbot on Wednesday August 20 2014, @03:22PM
I know when support runs out for Ubuntu/Xubuntu 12.04 LTS, I'll be looking at Slackware and Gentoo for my servers, desktop, and laptop. Of course, I'd consider other distros that are systemd free, using the apt package manager would be a boon. Sure I could go Debian and select the init packages, but after reading the install process and the need for the systemd shim, I'd rather just learn a new package manager or compile from source.
cats~$ sudo chown -R us /home/base
(Score: 3, Insightful) by Thexalon on Tuesday August 19 2014, @01:52PM
I believe they're aiming at tablets and the like, which for some reason they think boot rather than sleep regularly.
Heck, I boot up my home desktop not infrequently, not because I couldn't keep it running, but because I don't really need it to be and am sometimes switching host OS's, and even pre-systemd the process takes less than a minute.
Systemd screams "solution looking for a problem" to me.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 4, Insightful) by MrNemesis on Tuesday August 19 2014, @02:57PM
This is what, to me, a mostly server-only user, is so bloody annoying about systemd. It seems to be primarily only beneficial to desktop users, although I've never seen the boot process (excluding applications) take longer than 30s since I started using SSDs in 2009.
A new init system that's better suited for desktop tasks? Absolutely brilliant, great, fantastic! Super quick boot, parallel startup, event-based doohickeys... superb.
But even on the server, where most of the benefits of systemd are non-existent from my PoV, this is being forced down people's throats as it's become the *only* supported init because it seems to have been designed to not just stick its fingers in all the pies but to make all other pies untouchable by non-systemd fingers and inedible by non-systemd digestive tracts. It tries it's hardest to push you towards a binary log format (bye-bye grep, tail and all t'other friendly tools - thankfully debian still seem to be using systemd as a mere passthrough to standard logging tools) and a boot process that, when it fails, fails hard and requires /usr being immediately available post-initramfs (lots of servers use a shared read-only /usr over NFS). The binary log thing is especially stupidly onerous - the only secure way to avoid log tampering (apparently the sole justification behind the binary log format) is to have your logs duped off to a couple of remote syslog servers, if your box is compromised then yes, shock horror, even binary log files can be tampered with and thus can't be relied on. So IMHO the whole binary log thing is a non-solution in search of a problem that's already impossible to solve on a single system.
On top of that, there seem to be a whole distro's worth of stupid camel-cased'd replacements for network, cron, NTP, fstab and all the other baseline system functions coming down the pipeline that I don't think should have anything to do with init. svchostd for linux indeedd.
Even for my "desktop" machines (mostly a couple of HTPC builds), the improvement in boot time is negligible, and dwarfs into comparison with application startup time. I benched this with my HTPC running on a DH77DF, debian jessie; BIOS boot + SysV init went from power button to desktop in 10s. UEFI boot + systemd takes that down to 7s. Large enough to be noticeable but not enough to make any real difference (it takes longer for the screen to come out of standby). Resume from S3 is instantaneous regardless of the init system used.
Now I know this all sounds like "stupid old neckbeard wants linux on the desktop to suck" but I've still not seen a good reason why systemd can't co-exist with older, slower but more flexible inits.
*shrugs*
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 1, Flamebait) by evilviper on Tuesday August 19 2014, @05:47PM
Most of systemD's improvements benefit servers, not desktop users.
Tracking service startup dependencies and ordering/waiting for things correctly.
Automatically just restarting any service that crashes.
Improving syslog.
etc.
Those are all things any admin would kill for, that has always been such a half-assed mess. Debugging a system, and/or rebooting it every time it comes up and a network file system didn't mount in-time... Getting paged at 3AM every day, because after 2 years of uptime, crond happened to crash and across hundreds of servers, it's a daily occurrence... etc. These are all very important to any server admins, and hardly matter to desktop users.
Hydrogen cyanide is a delicious and necessary part of the human diet.
(Score: 1, Insightful) by Anonymous Coward on Tuesday August 19 2014, @06:25PM
This is not the opinion of any server admin I've spoken with.
This was never an issue until parallel startup - boot times remain insignificant on servers. Would you thank the guy who boards up your window when you just witnessed him smash it?
That isn't a 'feature'. On a networked server or multi user machine I want a crashed daemon to stay that way until I have investigated.
If that was their intent they failed completely. As the GP explained, log tampering can only be fixed by logging to a remote machine. Binary log formats do not solve that problem, least of all when log corruption is considered not a bug [freedesktop.org]
Sure - it's "a daily occurrence" "after 2 years of uptime" "across hundreds of servers" - but apparently only for you! I've not noticed this, perhaps I need to change my medication or I just selectively forget these incidents whilst vividly remembering dealing with hard drives that burst into flames and shit?
(Score: 5, Insightful) by MrNemesis on Tuesday August 19 2014, @08:33PM
Well, the AC above has already said most of what I was going to say but here's my slightly-differently-worded take on it.
An impenetrable boot process does not benefit servers. Needing /usr available after initrd does not benefit servers... unless of course having /usr over NFS is "holding it wrong". Even on slow-arse 2x7200rpm RAID1's, bootup time is about 10% of what POST time is... well, OK, 20% of PST time if this is a throwaway dev physical and you're cheaping out on softraid. Boot time on a server, as long as it's under a few minutes, is an utterly meaningless metric in my world. Even using appallingly stone-aged SysV init our virtuals boot in less than 30s, out physicals POST in 5mins... and boot for 30s.
Maybe I'm just being stupid, but distros seem to have already made this a solved problem since forever ago. It's almost as if init had a concept of the varying levels at which things should run... I forget what it's called... jogfloors? Saunterplanes? Scamperdecks? Dash-storeys? Scurrytiers?
Like the AC, there's no way in hell you'd do this in our environment, and it's frowned on in windows as well other than for *really* flaky services that would generate excessive amounts of admin overhead otherwise (and already have exceptions in place for escalations). Our "important" prod boxes have some vastly expensive software on them to fulfil this purpose, our non-important boxes use common tools like monit (does the same thing but without the supposed benefit of a support contract)... but *none* of them will just restart a service without reporting it, judging impact and escalating if need be. For most important systems, if a daemon fails one of the other servers takes over services until the duty engineer(s) can have a look at it and explain why it fell over in the first place - half the time when a service does fall over it's because of a non-transient error, so restarting will just lead to another crash and this achieves nothing but filling up your inbox and making your line manager have a minor freakout. Isolate the box and bring the service up elsewhere. Linux is one of the few OS'es where that's *easy*.
There's nothing improved against bog standard syslog that I can see. In fact, it's gone backwards. It's *less* useful on a systemd/journald system because you can't use standard tools to read it. When boot fails I don't even get to see a log.
Well, we don't keep our systems up for 2yrs at a time for a start, we reboot at the very longest at least once a month and yet we're still somehow at over five nines for the last three years. RHEL and debian system updates and admins tinkering with various bits of the system are still frequent enough that you're better of testing the server comes up cleanly on a very regular basis, not when you're forced to by seventeen pending kernel updates. We've never had a "half-assed mess"; hey, if the NFS mount doesn't come up in time the boot process waits until it does, if it takes 2x longer than it usually does then the duty engineer gets a beep and if it takes more than 10mins the duty engineer is going to get several loud phone calls from the escalation engineers. But... lo and behold... that almost never happens, and when it does it's always been due to hardware failure rather than services starting in the wrong order. Like AC said... parallel startup might solve problems on the desktop but for servers it's inconsequential when it doesn't happen and frequently problematic when it does.
So... again... in the server space at least, what problems is it that systemd's solving that haven't already been solved?
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:38PM
Thank you. I'm far too busy and annoyed over the purported benefits (ie: coprophagia - "it's good for you") of systemd to move beyond heart-felt if sarcasm laced rebuttals. I hope your reasoned technical explanation of the real-world problems we face will result in the faces of a few people flushing the same color as their hat ;P
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @04:41PM
And, again, "boot time" is not the metric that should be used here. PALM solved this issue in 1996 (note, 18 years ago now). How? The "on/off" button on a PALM didn't actually "shutdown" a PALM (not in the context of Linux "shutdown -h" type of shutdown). It just powered down everything except the RAM, which was kept on trickle so its contents remained unchanged.
Then an "on" button press resulted in "instant-on". In fact it was even better than that. You could be half way through entering something in an entry field, hit the "off" button, walk around all day, take it back out of your pocket, hit the "on" (same button) button, and it would instantly power back up, right exactly where you left off entering in the entry field.
This is what tablets should aspire to. A "sleep mode" that is so fast to enter, and so fast to leave, that it appears to be "instant-on" to any user. A "reboot" should never be necessary.
FWIW, Palm Pilots had a reboot button. It was inside a ballpoint pen sized hole hidden on the rear of the device. It would initiate a cold reboot (and the device would take some seconds to actually go through the boot process). It was almost never, ever, needed. The only time it was needed was usually the result of installing some not-quite-debugged app. that crashed something (no memory protection in a palm) by misbehaving.
(Score: 1) by Refugee from beyond on Wednesday August 20 2014, @07:49AM
Don't know whose that "their plan" is, but fast boot time is not a design priority of systemd. At least that what Lennart claimed.
Instantly better soylentnews: replace background on article and comment titles with #973131.
(Score: 3, Informative) by gallondr00nk on Tuesday August 19 2014, @02:37PM
Since there's no need for pulseaudio either, we could possibly go as far as saying that FreeBSD is Lennart free. Or at least his more abominable creations.
(Score: 2) by mrider on Tuesday August 19 2014, @02:42PM
Just because Netcraft has confirmed it doesn't mean that *BSD is dead. Debian has been my goto distribution for ages. But my next upgrade is going to be to one of the BSDs. The original goal of SystemD was laudable, but the current implementation is execrable.
Doctor: "Do you hear voices?"
Me: "Only when my bluetooth is charged."
(Score: 2) by Pav on Thursday August 21 2014, @12:43AM
Desktop BSD was embraced, extended and near extinguished when Apple grabbed a large portion of their devs. Has this situation changed? I've been in I.T too long to bother with anything except GPL (preferably GPL3 these days). The generation before me picked new/inferior Linux over a mature and superior *BSD in the early 90's for good reason.
After saying that, I still have no idea how to deal with this needless complexity creep. Perhaps some academic needs to come up with a complexity vs functionality metric so we can rank the suckage and name/shame the worst offenders.
(Score: 2, Insightful) by MrGuy on Tuesday August 19 2014, @01:45PM
From TFA:
I'd argue this isn't just an inelegance. It's a barrier to entry, as is the general linux federated model of small tools that do one thing.
It's incredibly flexible, incredibly powerful, and lets someone who knows what they're doing do almost anything, without needing to bring anything else along for the ride. But it also exposes a lot of low-level OS implementation details to the user. Where does your distribution of choice put certain utilities? Which version of package Y are you running, and how does it need to be invoked? All of these need to be known by SOMEONE to get certain higher-level user functionality (run an actual application) to work.
The current model is (as TFA notes) to have different configuration scripts for each standard distribution, which works as long as you're using a standard distribution, configured in a standard way, and it's a distro the author considered "important enough" to support. If not? You're on your own. The advice on most support forums is "go muck around with the initi script until it works."*
Linux is stuck between wanting to be an ultra-configurable advanced-user-only OS and a mainstream OS. "Linux on the desktop is a viable alternative to Windows!" has been "a year or two away" for over a decade now. It never gets over the hump, and in my view it's largely because of issues like this - the obscure incantations necessary to get everything to work that don't work everywhere and are impenitrable to non-experts. Remember Windows 3.1 when we had to go muck around in config files by hand sometimes to get stuff to work? Linux can be that times 10. It's not EVERYTHING - most stuff works fine (especially if you're on the latest version of a standard distro). But the things that DON'T work, REALLY don't work.
So, yeah. This isn't ao much about programmer convenience, or faster boot times. It's about USER convenience - I just want it to WORK without having to muck around in a shell script. I WANT the OS details to be abstracted for me. I DON'T CARE about how elegant the internals are for a programmer, or whether the architecture offends. I want the damn thing to WORK. And if Linux truly aspires to be an OS for non-OS experts, it needs to care more about non-expert user convenience than it does today.
I'm not saying systemd is THE solution - as noted, there are strong questions about whether systemd is actually well-written code that does the job it claims to do well. But a solution LIKE systemd is, in my mind, inevitable if linux wants to get out of the narrow niche of "an OS servers and programmers."
* Technically, the advice on MOST support forums is "LOL you suck newb. Learn how Linux works and come back when you're less of an idiot."
(Score: 3, Insightful) by bart9h on Tuesday August 19 2014, @02:09PM
You say
The current model is (as TFA notes) to have different configuration scripts for each standard distribution, which works as long as you're using a standard distribution, configured in a standard way, and it's a distro the author considered "important enough" to support.
and then
It's about USER convenience - I just want it to WORK without having to muck around in a shell script.
Well, the user who just want it to work will pick a mainstream distribution (or, more likely, have it picked for them, like a computer that has Ubuntu per-installed, or something) that just works, and will have a working init script for that software.
The rest of us who want to run Slackware, can still understand and fix what's wrong by hand.
(Score: 3, Insightful) by Anonymous Coward on Tuesday August 19 2014, @02:32PM
I and many others are fine with the "ultra-configurable advanced-user-only OS".
there is your problem, now it's about what *you* want.
Linux doesn't want to. Politics, news, some very vocal people and/or some distribution want it to for reason not yet clear to anyone. Linux is doing fine with it's 1% market share and all this mess happens because some Very "Smart" People have an agenda.
And that's why I like it. I came late to Linux (2006), I *never* was called "LOL you suck newb" on any forum. You know why? because I did my homeworks *before* asking silly questions ("Lol war iz the registry editor?"). I'm still learning new stuffs every day. It made me *understand* (or at least try to) how things work. And I'm not even a developer. You got a brain. Use it!
I don't want my Debian to be dumbed down to increase market share for idiots that will come ask the most stupid questions without even thinking twice (have you ever read a forum for Windows users ? it's appalling ... ). We don't give a fuck about market share.
I'm so fucking tired of the Eternal September and the crappy mess this is all slowly becoming because of some people with an agenda that I'm actually considering switching to a sanely well-engineered BSD ...
(Score: 1, Flamebait) by Hairyfeet on Tuesday August 19 2014, @06:56PM
But you aren't getting an "ultra-configurable advanced-user-only OS" what you are getting is a corporate controlled "ultra-configurable advanced-user-only OS" which is why stank like systemd and pulse can be forced from on high and you WILL take it or be stuck on "Bob's distro" with low user numbers, overworked devs, and lousy support.
The reason why even guys like you should want Linux to become useful to the masses is simple...it benefits YOU through better hardware support (because it will be harder for OEMs to ignore Linux with a strong userbase), more devices that are Linux friendly OOTB and most importantly more money for Linux development that isn't tied to a corp who only gives a shit about one or two niche applications like LAMP. For a perfect example of how different things could be for Linux with better mainstream support one only has to look at Android. Android now has devices of every shape and form, from tiny thumbsticks to full blown desktops, from phones to watches. Also look at the amount of Android compatible hardware coming out daily, its growing by leaps and bounds.
So having better mainstream support is better for everybody, it means less control by corps that only want to use Linux for a few niche roles, more hardware and software support, its just better all around.
ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @08:44PM
I beg to differ on (at least) one point: we got into the corporate-controlled thingy *because* Linux was becoming more mainstream, in the first place. Someone saw a potential cash-cow and now the corps (Red Hat, Canonical, (Google ?) etc.) want it to become even *more* mainstream because it means more money in for them. It's in their interest (I don't blame them that's what they exist for, making money) not mine. I wish it was that simple: more user == more drivers/support, but that's only part of the bigger picture. The more users we have, the more the Big Corps will want to be the only guardians of the True Linux and relegate us into, as you put it correctly, lousy "Bob's distro". Which we don't really want ...
Until now, we had the non-corporate Debian to turn to, but now it's taking the systemd way when they should give exactly zero fuck about it. And don't get me started on the "but systemd is only optional in Debian". We all know very well how *that's* gonna end.
(Score: 4, Insightful) by morgauxo on Tuesday August 19 2014, @03:19PM
Linux is supposed to be about options. Distros are making it hard to NOT use systemd.
I want to see Linux be a major player on the desktop. Why? Because I use Linux and I want to be sure that the 'mainstream' software I want is/remains available to me. For that we need a market. For example, for years there was no up to date Flash player. Flash sucks but unfortunately at the same time a great deal of internet content required Flash. There were options for Linux but none of them was perfect. Today that is not an issue but I would like to see things like Netflix, Amazon, etc... working on MY desktop.
Apparently to be popular we need something like Systemd? I don't get it. Using an openrc based distro I don't remember having to edit config files, startup scripts, etc to do desktop stuff. I only did that when I was setting up server processes. Whatever... we had multiple startup systems to chose from for years. Why does it suddenly have to be just one, systemd!?!?
I see no problem with desktop 'normal user' based distros using something like Systemd. Just don't take away my option to use one of the more Unixy ways. This really should be low level stuff. Applications shouldn't care and I should still be able to use all the same applications as the 'normal user'.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @03:33PM
Apparently to be popular we need something like Systemd?
If you want any traction with this OS the answer to that is yes.
MS used to have the *exact same problem*. I remember well autoexec/config.sys/win.ini hell. All of the 'old' ways are still there (see autoruns). But MS makes it pretty clear what the 'right way' is. It makes it extremely easy to program to as the API is known and well documented. Honestly, at this point (having used linux since it fit on a couple of floppies) it is embarrassing. The big distros are just starting to 'hey maybe we should look similar for things like steam'. My synology uses one way to init something my android another my tv yet another and my desktop another and my servers yet another way. I can not program to that and have a well tested product. Which is sad as linux/bsd have a very rich programming environment. But it takes lots of tinkering to get to the point where things run on all systems. Time I could be better spending adding something cooler to my product.
(Score: 2) by morgauxo on Tuesday August 19 2014, @04:09PM
Nope, still don't get it.
What are you setting up? Most modern end-user oriented distros autodetect everything! It just works!
Or, if it doesn't it almost always means you have unsuported hardware. Systemd can't fix that!
What is Systemd replacing that a 'normal' computer user would EVER have touched or even seen?
If you are spending hours configuring openrc or some other startup scripts you must be doing something that this new target audience will not be interested in anyway!
(Score: 3, Informative) by morgauxo on Tuesday August 19 2014, @03:59PM
"Technically, the advice on MOST support forums is "LOL you suck newb. Learn how Linux works and come back when you're less of an idiot."
I'm a bit skeptical of you here. Have you experienced this or are you just repeating old FUD? Personally I don't ask a lot of questions but I do Google them. I almost always find other people have already asked it and... even more have answered! On the rare occasion I see an RTFM comment it is one reply among several and the others are more helpful. If people are just answering with "LOL you suck newb" then where are these forum threads that have helped me coming from? That is my anecdotal experience.
However... maybe forums are not best for everyone. I think many of the masses will never get there answers through a search engine. It is too impersonal. They want someone to hold their hand. Personally this baffles me. When I have a problem I don't want to wait for an answer. I don't want to chat. I want a fix! When I need social interaction I have friends for that.
But.. I've worked in tech support. (been a while since then thankfully) Some people just don't care that the answer is right there for them to grab. They want someone to hand it to them! Throughout the day they interact with people who they are paying money to. They get smiles and friendly banter from their grocery clerk, bank teller, etc... They call their ISP or their computer manufacturer when they have a problem and expect the person on the phone to treat them like gold. One way or another they paid those people! They don't really like them. They don't really enjoy what they are doing. They are acting the part that gets them paid!
People answering questions on forums are NOT getting paid. They just for their own reasons want to see that piece of software be used and so they are filling the gaps where documentation might not have been enough for someone. Once that gap is filled they don't want to keep repeating themselves. That makes it a job!!
Does that mean Linux can't be good for these socialy needy people? No not at all. If you can buy someone to hold your hand through Windows you can buy someone to hold your hand through Linux. Just get a paid distro and someone at the company you bought it from should pretend to like you too!
Sound a bit like prostitution... well... if you don't like that then just Google it!
(Score: 3, Insightful) by tibman on Tuesday August 19 2014, @06:07PM
You actually don't want your application/service to depend on any specific init system. You just write your service and let other distro managers repackage your stuff for their distro. They may provide only one init config file or maybe all of them.. doesn't really matter to you. You can merge all the various init configs back up into your master branch with some detection logic.. but that would be kind of you.
Linux is not windows. There is not just one service for each need. There is a multitude of competitors with various api differences (unfortunately). The best win because they are adopted more than the others. If a better replacement comes along then the old is swapped out. Good luck doing any of that with systemd. In a few years it will begin rotting and you won't be able to just swap it out with a better solution.
TL;DR: If you tie yourself to systemd then you will die with it.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by Magic Oddball on Wednesday August 20 2014, @06:38AM
I'm not talented/trained in any STEM discipline, began using Linux full-time in Spring 2008, and I call bullshit on your post.
The only place I noticed users being rude to newcomers asking for help was the Debian discussion area. *How* the other forums were helpful varied (some gave answers outright, some led the newbie to figure out the solution, some suggested where/what they should look for likely answers) but they were friendly about it. In fact, many remained calm & still tried to be helpful even when the newbie was being an asshat.
Systemd & stuff like GRUB2 makes things a thousand times WORSE for regular users like me, let alone the newbies. With the old setup, when stuff broke (almost always because I was experimenting, to be clear) I would search the web and eventually find some simple command or text file I could edit to fix things. It was as newbie-friendly as an OS could get.
With systemd, things are breaking for reasons I can't fathom, and web searches reveal such oh-so-helpful hints as "in the past, we fixed this by changing permissions, but that was before systemd." It's like going back to 2001: "your modem won't work, because Linux does not like winmodems." So far, all I can do is keep updating my system and hope something will magically "fix" it for me. It's like trying to fix my mother's Windows machine when things just as mysteriously stop working on it.
I feel like the programmers behind this mess are taking the same paternalistic attitude towards everyone that many guys had towards women 100 years ago: “oh, don't worry your little head about it, *we'll* handle this for you.” Same obnoxious attitude when it comes to system GUI changes, whether it's Unity, GNOME 3, Firefox Australis, or other things: “now, now, I know you think you'll hate it, but that's really just your fear of change speaking.” Talk about arrogant!
It's also a complete load of crap to claim that this is for the users or for Linux's popularity. That would require them to actually ask in the first place -- and in many cases, not only did they not ask or consult any studies, one team openly told users to STFU when users became too vocal to ignore. Go read the developers' discussions on any of the various projects I've named. You'll see that they're doing it because new projects are fun & exciting (merely fixing bugs is boring hard work), they're enthralled by newness in general, and because they believe they're superior to past devs on the team.
Distros are leaping to systemd purely because it's new -- the same stupid reason that they jumped the gun in embracing KDE 4 and GNOME 3 long before they were ready for daily use.
(Score: 2) by kaszz on Tuesday August 19 2014, @01:55PM
If SystemD is a piece of shit. Why not just remove it or re-factor the code? In particular making sure it does what it supposed to and nothing else with clearly defined API:s.
And if SystemD is causing numerous kernel crashes. Where is the kick-boot??
(Score: 3, Insightful) by tangomargarine on Tuesday August 19 2014, @04:43PM
Like trying to change the tires on a moving vehicle?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by kaszz on Tuesday August 19 2014, @08:20PM
Well the first order of the day is to stop the octopussy from growing (seems Linus has done some moves towards this). Next either many small steps is taken to fix this or one stop the "vehicle" and do the big axing. Linux kernel seems to have these big change events now and then anyway.
(Score: 0) by Anonymous Coward on Tuesday August 19 2014, @02:34PM
that article is nothing but a simple "muh Unix" rant. parroting the same shit over and over doesn't change the fact that distro developers as well as the silent majority give no fucks about which init system they use, so long as their facebook works. come back with a real argument that has nothing to do with Unix and you get people to listen, until then stop shitting up this site with these autistic ramblings.
(Score: 3, Insightful) by Anonymous Coward on Tuesday August 19 2014, @02:57PM
Fair enough, here are some:
- systemd is supposed to be an init system. It's not.
- systemd is broken by design
- systemd is a trojan horse
- systemd is hard to replace by another init once in place.
- systemd's key developers are obnoxious assholes
your turn.
(Score: 4, Insightful) by tangomargarine on Tuesday August 19 2014, @04:49PM
In the comments above, people explain that systemd doesn't even really accomplish any of the things it claims to do, and manages to shit up the whole place in the process. How much worse can you get?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by present_arms on Tuesday August 19 2014, @04:02PM
is that I'm glad I don't have systemd installed, it's not even in the repos. using pclinuxos 64 bit. It seems it uses systemV init which I much prefer.
http://trinity.mypclinuxos.com/
(Score: 3, Insightful) by Rich on Tuesday August 19 2014, @11:35PM
Nice clickbait article. Booting indeed needs attention. In the ancient days, a nice debian SysV init would scroll along, with lots of [OK], the odd [failed], and eventually the GUI would start. These days, on a current distro, all kinds of WTF-moments keep surprising me, mostly with silent failures indistinguishable from long delays when no DHCP lease is found or mount thinks an fsck is due.
Now here we go: The three much-discussed components (systemd, pulseaudio, and Wayland) are all born out of the idea to rip off what the Mac does with launchd, coreaudio, and WindowServer. (I just notice even to the point of the first letter capitalization.) The blueprints are followed to where the result is borderline bearable, quirks then get added to satisfy a Red Hat middle manager's pet peeve or just the developer's ego.
I don't follow the majority opinion with pulseaudio, it indeed seemed to expose a number of ALSA bugs, and these had to be fixed. The reasoning behind arbitrary PCM span lengths is also perfectly fine, where a lot of CPU cycling can be avoided on mobile. However, not considering Pro-Audio needs (and going for a unified solution with Jack) is where the mediocrity rears its ugly head. Also, from a system architectural view, putting certain audio drivers into the application layer mixer was outright braindead.
So, following the launchd concept isn't too bad either. The Mac works and it boots reasonably fast. However, mindless feature creep seems to ruin this one, again seemingly driven by Red Hat's day-to-day operational needs. I think such a boot system can hardly be reliably designed incrementally. It will need a through concept that implementers AND users understand and can agree upon. That also means seriously good documentation. There are fringe cases (e.g. Audio over IP, but IP over Audio (Softmodem): which comes first, if Audio is not layered or staged?) that have to be cleanly architected out, instead of including everything and the kitchen sink to cover all eventualities. I fear systemd is moving or has already moved past the point of sanity.
But is there a solution? Obviously Red Hat does what it does to make stockholders happy and community whining is considered as a slightly milder annoyance than a swat-evading-fly buzzing around in their offices. Shuttleworth has given up on fixing Bug 1 and only does mobile/cloud now. No more surprises like how well Dapper or Hardy worked compared to other distros of their time. Besides that, the Ubuntu experience past Hardy was also chasing the Mac like Red Hat, just with even more superficial engineering.
It would need a white knight out appearing out of nowhere, laying down a clean architecture AND amassing such a following that the wider community pushes Red Hat's momentum back. Which is not going to happen. So we probably have to get used to the new stuff as they give it to us or get into retro computing. But then, with retro, Firefox 2.0 still had a sane Look & Feel :)
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @06:50AM
I agree with most of your post, but I'd like to point out that I feel Wayland is exactly what must be done. I used to think the same way as you because "hey, everyone on the Internet opposes it, so it must be crap" but then I read this http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 [phoronix.com] and saw that presentation:
https://youtu.be/cQoQE_HDG8g [youtu.be]
TL;DR: most Wayland developers and supporters have been the X11/X.Org developers for many years and they know exactly what they're doing. See Wayland as what X12 should have been but never will.
It's a bit like OpenBSD guys rewriting OpenSSL into LibreSSL: they know what they're doing and they're doing it well.
The guys writing systemd seem to be doing just what Red Hat wants, not caring about consequences or crappy design.
(Score: 1) by Rich on Wednesday August 20 2014, @02:25PM
Bit of a late reply... I didn't elaborate on Wayland because I didn't want to stray too far off topic. I'm entirely with you here. I occasionally jest that X11 should be replaced with TCP/IP. The latter is much leaner yet provides roughly the same support for modern desktops. Wayland going for the WindowServer model (layered client bitmaps) is probably the universally most reasonable choice. Though if I had to architect a desktop myself, I'd go for the Be model with a policy bound application server and CarbonEvents-like network transparency at that layer, for a maximum of "teh snappy".
I think the most important "feature" of the new graphics stack is that drivers are separated from the window server. A window server is a high school project compared to getting accelerated GL on a modern GPU. With separate drivers, alternative approaches get a chance.
(Score: 0) by Anonymous Coward on Wednesday August 20 2014, @09:57AM
For many programming is fun and easy to get into and people want to do it.
However, programming alone is nothing - it needs to be applied to something, and this something usually requires other skills such as creativity, analytic ability perhaps maths, physics or other branches of science.
Also in the field of computing, much of the easy stuff is done. All the basic algorithms are all known and understood (sorting, datastructures etc...) and most fundamental software exists to a high quality and being readily available (OSes, editors, compilers, programming languages, utilities).
So, as a programmer we have a few options left:
1) Work on something new, difficult or very specific.
2) 'Re-invent' something that already exists.
Choice 1 may require some very specific skills, perseverance, hard work, funding and may not ever achieve much recognition outside some small niche.
Choice 2, is sadly the easier path for many. So what we see is a constant re-arranging of pixels and processes for very little benefit, and normally at the expense of maturity, stability and complexity.
It's not just Linux which is bad at this either. Microsoft shafted the UI for Win8, Google shafted Maps, Slashdot made Beta etc...
The sad thing for Linux is that with these re-inventions, a significant portion of the documentation and community created HOWTOs, guides and forum postings are made irrelevant, along with portions of the userbase's knowledge, and it often takes a long time for this to be rebuilt.