You Got Your Windows In My Linux 613
snydeq writes: Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD, writes Deep End's Paul Venezia. "Although there are those who think the systemd debate has been decided in favor of systemd, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise. I've seen many declarations of victory for systemd, now that Red Hat has forced it into the enterprise with the release of RHEL 7. I don't think it's that easy. ... Go ahead, kids, spackle over all of that unsightly runlevel stuff. Paint over init and cron, pam and login. Put all of that into PID1 along with dbus. Make it all pretty and whisper sweet nothings about how it's all taken care of and you won't have to read a manual or learn any silly command-line stuff. Tune your distribution for desktop workloads. Go reinvent Windows."
What's wrong with Windows Server? (Score:5, Insightful)
What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?
Re:What's wrong with Windows Server? (Score:5, Insightful)
Nothing really. It's just different. All of this sounds remotely familiar to the System V wars aka UNIX wars of the late 80s and early 90s. [wikipedia.org]
That didn't solve much either except it allowed a company from Washington dominate servers and high-end desktops for awhile because it wasn't caught up in all of the holy war shit.
Re: (Score:3, Insightful)
Ummmm ... it's closed source. I'm sure there are lots of other good reasons, but do you really need anything more than that?
Re:What's wrong with Windows Server? (Score:5, Insightful)
Closed source isnt even the bar anymore. GPL lunatics crib about CDDL and a whole host of other licenses. I'd rather have closed source that works than open half-bake.
systemd is breaking UNIX tradition - which is things may suck, but they suck simply. Now its a horrible mess. We now have (1) scripts, (2) openrc, (3) upstart and (4) systemd. What a sick joke.
And the best thing I've seen so far to replace startup scripts is Sun's SMF... NIH alert! We couldnt have copied that - something that actually worked - no we need to have yet another method of starting things.
Worse thing is eth0 is now en0p1FuK0001, drivers are modprobbed in random order, stuff gets renamed and moved around, and NetworkMangler aka NetworkManager is shoved down our throats.
Its horrible. And its very desktop-ish.
What do you expect from a guy whose magnum opus was a sound framework for linux. Yeah, thats the guy you want re-writing how everything starts and stops. Dont copy the guys who invented NFS or ZFS or stuff like that, copy the junk the sound guy comes up with.
Re:What's wrong with Windows Server? (Score:5, Insightful)
Closed source isnt even the bar anymore. GPL lunatics crib about CDDL and a whole host of other licenses. I'd rather have closed source that works than open half-bake.
systemd is breaking UNIX tradition - which is things may suck, but they suck simply. Now its a horrible mess. We now have (1) scripts, (2) openrc, (3) upstart and (4) systemd. What a sick joke.
And the best thing I've seen so far to replace startup scripts is Sun's SMF... NIH alert! We couldnt have copied that - something that actually worked - no we need to have yet another method of starting things.
Worse thing is eth0 is now en0p1FuK0001, drivers are modprobbed in random order, stuff gets renamed and moved around, and NetworkMangler aka NetworkManager is shoved down our throats.
Its horrible. And its very desktop-ish.
What do you expect from a guy whose magnum opus was a sound framework for linux. Yeah, thats the guy you want re-writing how everything starts and stops. Dont copy the guys who invented NFS or ZFS or stuff like that, copy the junk the sound guy comes up with.
Not just the sound guy, the sound guy that wrote the broken sound framework. Pulseadio is a horrible horrible system. I have taken to just purging it and using alsa and I then have audio system that doesn’t shit itself and become a zombie process when I unplug my headphones or try to run a program in w.i.n.e.. As for his other endevors network manager, has had major issues on several network cards have used so I ususaly scrap it and use wicd. From what I have seen SystemD does not look like anything I want on my systems either so when the time comes I will be considering my alternitives.It may just be the motivation I need to try out openBSD on my server, my desktop though I may go so far as to try out something like Gentoo or slackware.
Comment removed (Score:5, Insightful)
Re: (Score:3)
Considering the post is about design and usability, being closed source is not what the GP was looking for in terms of an answer.
So yes, we're going to need more than that. Specifically, Linux seems to be moving more towards the design of Windows, at least according to this retarded article. Is that bad, and if so explain yourself.
Otherwise, you're just not helping here.
Re: What's wrong with Windows Server? (Score:5, Informative)
I'm not either, but that's hardly the point. Let's say something isn't documented properly and doesn't work the way I expect: just being able to read the source code can be extremely helpful.
But it goes even beyond that, because open source software naturally forms communities around it. Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. I can ask someone who's read the code how it works on Stack Overflow. Or when someone uses that source as a basis for an entirely new and improved version, I can switch to that.
Re: What's wrong with Windows Server? (Score:5, Insightful)
Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. [...]
I am also in favour of Open source myself and get your point. However, after the OpenSSL bug, my belief in this "someone else" has significantly lowered. If too many people rely on "someone else" fixing a problem in his/her spare time you are worse off than when people are paid to fix closed source software. If the problem is important ($$$) enough, it wil be fixed.
Re: What's wrong with Windows Server? (Score:4, Insightful)
I am also in favour of Open source myself and get your point. However, after the OpenSSL bug, my belief in this "someone else" has significantly lowered.
Think how bad the OpenSSL bug was. Now realize that proprietary code is often just as bad, but no one can look at it.
Re: What's wrong with Windows Server? (Score:5, Insightful)
Think how bad the OpenSSL bug was. Now realize the possibility that proprietary code could be just as bad, but no one can look at it.
FTFY, a more measured approach more consistent with reality. While the potential is there, we have not seen anything as bad as the OpenSSL bug.
The latest set of Microsoft security patches fix a vulnerability that could plausibly be exploited to remotely execute code and which has affected all versions of Internet Explorer since 6.0. This probably has significantly worse impact than Heartbleed did, and is such a regular occurrence that nobody has bothered pointing it out for special attention. Heartbleed was news simply because we expect open source to do better.
Re: What's wrong with Windows Server? (Score:5, Insightful)
Heartbleed could expose server side private keys to the attacker. I seriously doubt that any IE bug could possibly be that bad.
who needs a bug? (Score:3)
Re: (Score:3, Informative)
Even if I were to never even look at a single line of the source, the fact that it's availble to others adds value for me. I can go download a patch someone else wrote that fixes a bug MS hasn't bothered to fix. [...]
I am also in favour of Open source myself and get your point. However, after the OpenSSL bug, my belief in this "someone else" has significantly lowered. If too many people rely on "someone else" fixing a problem in his/her spare time you are worse off than when people are paid to fix closed source software. If the problem is important ($$$) enough, it wil be fixed.
Heartbleed was a subtle bug that was fixed after 2 years and 1 month of being in the release branch of openssl. Looking at the "critical" and "important" bugs in the latest round of Windows patches, I see one that has been open since IE6 was released (13 years), one for windows 8 (21 months), OneNote 2007 SP3 (35 months), SQL Server 2008 SP3 (35 months), Windows 2003 (11 years) x2, SharePoint Server 2013 (18 months), and .NET Framework 2.0SP2 (5 years).
It looks to me like open source is working just fine h
Re: What's wrong with Windows Server? (Score:4, Insightful)
If something isn't documented properly, and doesn't work the way I expect... I'm not going to dig into the source code and try to decipher it... I'm going to RUN SOMETHING ELSE.
I have a job-- it's making sure the systems work, not reading your crappy code.
I like open source, I truly do, but with today's frameworks, it's very rare I'll dig into source code.
Re: What's wrong with Windows Server? (Score:4, Insightful)
If something isn't documented properly, and doesn't work the way I expect... I'm not going to dig into the source code and try to decipher it... I'm going to RUN SOMETHING ELSE.
I wish I lived in your world where there was always an alternative that's well-documented and sane... in fact, I'd settle for well-documented OR sane ;-)
Re: (Score:3)
Well software doesnt degrade over time due to use [...]
No. It degrades over time for entirely different reasons. But it *does* degrade over time. There's plenty of software I used to use which I now cannot for various reasons (e.g. contains known unpatched vulnerabilities; not compatible with modern hardware; suffers from Y2K-related bugs; depends on operating systems that contain known unpatched vulnerabilities; depends on operating systems that are not compatible with modern hardware). Were it open source, I doubt this would have happened.
Re: (Score:3)
Zoho, Scantool, OBD Autodoctor, AutoEnginuity, Ease, Windows OBDII, I can keep going.
When I was an apprentice, the difference from the handheld tool was which cartridge you plugged in. At the end of the day we settled on a laptop which used Snap-on's proprietary software since it could be auto-updated by dialing into a local number.
Re: (Score:3)
Have you ever noticed how sometimes when people say something about someone else, it winds up revealing more about them than the person being talked about?
Here's what your post seems to reveal to me:
1) You think insulting (and not even cleverly at that) random people on the internet is a good use of your time
2) You think that there is no legitimate reason to support open source software, and therefore all support for it is "ass-kissing"
3) You think Slashdot posters are motivated to post what they write to t
Re: (Score:3)
The only legitimate complaint is that Windows requires beefier hardware to do the same job. Other than that, it's a matter of preference, and advantages for specific tasks.
Re:What's wrong with Windows Server? (Score:5, Insightful)
Not having to manage licensing... is a gift all its own. I'm not talking about not buying licenses, I mean not having to deal with ANY of that shit for servers... a blessing.
Re:What's wrong with Windows Server? (Score:4, Interesting)
Not having to manage licensing... is a gift all its own. I'm not talking about not buying licenses, I mean not having to deal with ANY of that shit for servers... a blessing.
THIS is the reason I build so many linux servers. When you compare costs of a typical Windows based small business server vs a linux server, linux wins hands down. Unless there is a very specific reason to run a windows based server, I always run linux servers. No licenses to keep track of, no extra up front software expenses.
Re:What's wrong with Windows Server? (Score:5, Interesting)
Re:What's wrong with Windows Server? (Score:5, Insightful)
By contrast, UNIX/LINUX servers are much more difficult to configure and generally require a lot more man-hours and a more experienced (and expensive) staff.
This is a fallacy. There are numerous studies that have shown that a single Unix admin is able to manage more Unix/Linux/BSD servers than a single Windows Admin. It is far more cost effective, in larger environments, to run Unix servers than Windows servers when it comes to ongoing maintenance. It is also well documented that a Unix/Linux server build can be online and running significantly faster than a comparable Windows build.
Simply put, how long does it take to get something like an Oracle DB up, running and usable on Windows vs Linux? What is the cost of that build, including the licensing and the time it takes to put together? I can image a Linux based server with only the stuff I need significantly faster than I can do the same in Windows Server 2012.
The fact that Windows Server is still able to survive on expensive license fees when Linux and BSD are free is pretty telling. Companies are doing a cost-benefit comparison and finding that they are saving more money going with the paid solution than the free solution.
No, generally cost has nothing to do with whether a company chooses Windows over Unix/Linux or not. Convenience plays a huge part in it. Most small and medium sized businesses probably don't even realise they have options. Windows is often picked as the default because that is what the kids from the past 20 years have been taught or all they've managed to pick up through school. Again, convenience and knowledge over cost.
It also comes down to ease of management. Its a lot easier to implement Active Directory for user and device management than to do the same with OpenLDAP. Many companies pick Windows because they can do simple tasks like manage users themselves and not need to pay an admin to do that kind of thing for them.
It is very similar to what you see happening on the desktop with the domination of easy-to-use and configure Mac and Windows over KDE or Gnome, except on the server-side it is mainly an issue of the ease of use for the system administrator, and the fact that a good Unix admin is much more expensive and harder to find than an MCSE certified admin.
A good Unix admin can manage a larger pool of servers, off-setting the cost of having to hire multiple Windows admins. However, the cost of Unix admins is not significantly different from the cost of Windows admins. In fact, most Unix Admins are also very capable Windows Admins and so you get a two-for when they're hired.
Easy-to-configure Windows and Mac are a strawman. Gnome and KDE are no more difficult to configure than Windows or Mac. The difference is in actually having taken the time to learn them. Arguably you have more control over the Gnome and KDE environments. What puts Windows up there is that through the 90s no one had a choice when buying from OEMs, so everyone learned the basics of Windows. That then bled into the 2000s where it was easier to stick with the devil you knew rather than learn everything over again.
It has very little to do with the cost of the systems and far more to do with people being comfortable with what they know. Look at how badly Windows 8.x and Windows Server 2012 are doing at the moment. They are such major changes that require significant relearning of some major fundamentals, that people are simply not switching to them. Windows 7 and Windows Server 2008 R2 still dominate the corporate/business market. People aren't upgrading to Win8/2012 for the same reason they're not switching to Linux. They have to make a significant effort learn how to use the systems.
Re:What's wrong with Windows Server? (Score:5, Insightful)
In the first part of your post, you talk about how Unix is just as easy to administer, then later, you talk about how Active directory is easier to administer than OpenLDAP.
Also, I tend to disagree about Linux end-users being as easy to administer. Installing commercial software, for instance, on Mac and Windows Desktops is relatively easy but a simple install a Linux machine can be a nightmare. You see this crop up a lot with similar tasks because Windows and OSX have a single centralized installation management system while Linux is fragmented.
Installing a simple program like Matlab is easy on OSX, Windows, and Windows server but can turn into a nightmare on Linux servers and desktops.
If end users were really so scared to learn something new, they would not be switching to OSX in droves or between Android and iOS. OSX is about as different from Windows as it is from Linux, but it is also easy to use and manage, unlike the various Linux desktop managers and problems are typically easier to solve.
Linux is great for a server environment in some circumstances (so is Windows in some circumstances). It is not so great as a desktop OS for the vast majority of users. Outside of very technical areas, Linux desktop is pretty much a non-starter and even in a lot of those fields, you find people adopting OSX over Linux or Windows, even though Linux is arguably much easier to get open source UNIX tools up and running on than OSX or Windows Unix environments (for instance, Debian has repositories of binaries for almost all major open source tools in science, engineering, and computer science whereas you often have to build your own on OSX and in Windows UNIX or CYGWIN).
Comment removed (Score:4, Informative)
What's wrong with Windows Server? (Score:5, Informative)
Re: (Score:3)
Re:What's wrong with Windows Server? (Score:5, Funny)
Re:What's wrong with Windows Server? (Score:4, Insightful)
Re:What's wrong with Windows Server? (Score:5, Insightful)
So it solves a problem that Gentoo solved years ago in its script-driven init system?
Re: (Score:3, Interesting)
Almost everyone I've asked that has expressed hatred of SystemD hasn't actually used it. The vast majority either hate the creator or read some blog post, all but one had never used it or tried to understand it. I attribute much of the hatred to a "I hate change" attitude that is unfortunately common in the *Nix sphere.
Re:What's wrong with Windows Server? (Score:5, Insightful)
Almost everyone I've asked that has expressed hatred of SystemD hasn't actually used it.
I've used it. I hate it.
Ignoring the very real problem that putting so damn much in PID 1 is dangerous for system stability and security, systemd is generally OK for all distribution-supplied packages. But, if you have anything at all that the packagers didn't think of, it's a pain in the ass. For example, getting sendmail to not start until the clamd server is ready to accept connections isn't easy using systemd, but trivial using a standard init script.
Also, despite the fact that dependencies are baked-in to systemd, it's not at all uncommon for a service that depends on an something else (service, NFS mount, etc.) to still start up before the dependency is fully ready, simply because the default systemd is to assume the dependency is fulfilled as soon as whatever "starts" it returns.
Next, there is no easy way to copy existing dependencies to another service (which would be the best way to start creating your own), mostly because the systemd docs and examples simply suck.
Last, the dependency system absolutely screams for a GUI interface to be able to follow and configure it, but when one finally is created (if it hasn't been already), it'll be useless on servers, because nobody with brains installs a GUI on the server.
Re: (Score:3)
>Ignoring the very real problem that putting so damn much in PID 1 is dangerous for system stability and security,
From what I've read, this isn't true, but I don't have an authoritative source for it. But, here's the really dumb part of your response:
>Last, the dependency system absolutely screams for a GUI interface to be able to follow and configure it, but when one finally is created (if it hasn't been already), it'll be useless on servers, because nobody with brains installs a GUI on the server.
M
Re: (Score:3)
That still requires a metric assload of libraries to be installed on the server. The bandwidth and latency requirements work OK enough for routine operation, but it really sucks when the problem you're trying to solve involves poor connectivity.
And it absolutely won't work over a serial console.
Re: (Score:3)
nobody with brains installs a GUI on the server.
And will someone PLEASE tell IBM and Oracle that?
I like Systemd in concept. It potentially allows setting up dependencies from the outside, much as Inversion of Control does in software. Meaning that the systems don't need to know as much about other systems because it's wired into the overall system configuration. And, unlike init scripts, you can make the management of subsystems dependent on the actual state of other subsystems, not simply assume that because one was scheduled to come up before another t
Re: (Score:3)
Simply being the "new shiny shiny" means that it is untested and unproven. That's not something you just can casually gloss gloss over.
This adversity to change is common to ALL professionally managed systems. It has nothing to do with Unix in particular.
If it is anything like Upstart then it is a bunch of added complexity for no real gain.
Re:What's wrong with Windows Server? (Score:5, Insightful)
This was easily the loudest, most repeated response to somebody hating the Metro interface on their desktop, and it should be clear by now that sometimes, avoiding change isn't the primary reason why craploads of people hate something new. Sometimes the new thing just... sucks.
Re:What's wrong with Windows Server? (Score:5, Insightful)
Re:What's wrong with Windows Server? (Score:5, Funny)
Watching the VI EMACS holy war has grown long in the tooth and we really needed a new holy war to spice up the community!
LONG LIVE SystemD!
Re:What's wrong with Windows Server? (Score:5, Insightful)
I've used it and could list SystemD's various technical issues, but that isn't and never has been the point.
The complaints we have about SystemD - and the Poettering cabal in geneal - is not about any technical issues. Bugs can be fixed; bad design, antisocial not-invented-here attitudes, and disregard/blindness to any use case outside their experience are what we have been complaining about. After about 2 years of arguing the topic, we've had to add rudeness, blatant propaganda, and attempts to bully opposing views to the list of complaints.
Typically, SystemD defenders - such as yourself - spend a lot of time and effort disrupting forums and discussion threads by posting strawmen, non-sequiters, or simply praising SystemD as it applies to very narrow use-cases. Recently, the tactic has bene what you are doing right now: accuse the opposition of being "old" or "luddite" or "hating change". It is quite telling, actually: a big complaint against SystemD's development style (as mentioned in this article if you bothered to RTFA) is that they don't bother to understand how people outside their immediate group actually use their computers, or what their needs are. Comments like this are exactly what we're talking about.
Nobody has been saying systemd should be banned or that you wanting to use it is bad. Nobody has said OpenRC or sysvinit should be the only option. If some tool solves problems for you or make your life easier - or even if you just like the tool's style/asthetics - then use it. What we're complaining about, more than anything else, is the tight coupling that SystemD has been doing, as it prevents everbody else from having that same freedom of choice.
Once, a very long time ago (internet years) when an image of a certain borg-ified CEO was common, there was a phrase that was commonly used to describe Microsoft's monopolistic actions against competing technologies: embrace, extend and extinguish [wikipedia.org]. Many discussions on slashdot warned about how Microsoft was trying to "embrace and extend" various standards such as Kerberos [drdobbs.com].
So instult us if you like - it makes our arguments against SystemD's attitude for us. You can even sit in ignorance, if you desire, while Poettering embraces and extends linux so he can remove all the useful parts form it. The rest of us that have watched this happen before will continue using Free Software that preserves freedoms such as the freedom to choose your init system. We have been marginalized and a social outcast in the past and are used to crap like this. Just remember that it was that same freedom of choice that provided a place for SystemD to be developed in the first place.
Re:What's wrong with Windows Server? (Score:5, Insightful)
The damned thing insists on being PID 1. The more crap it kitchen sinks into itself, the more often and likely it will need a security update. That's a reboot. If I wanted to reboot every day, I'd run Windows 95.
The dsame services runninmg seperately and not as pid 1 can easily be updated/upgraded at will and restarted without messing with the whole system.
The 'old' init is a very simple program. It does what it must do and no more. It doesn't see a lot of change at all. As a result, it doesn't cause any problems It just stays out of the way quietly listening for a command to change runlevels, respawning the occasional getty and dealing with child processes that lose their parent.
Systemd COULD have been implemented as pid2, spawned from init. Of course that wouldn't have supported the hidden agenda to take over everything. Surely you don't think it's a coincidence that the gnome desktop suddenly developed a hard dependency on systemd when it has been running without it for years.
Re:What's wrong with Windows Server? (Score:4, Insightful)
I doubt it. Then you just have the old init call the rc scripts as normal and tell systemd to start/stop/watch/ nothing and if it crashes, who cares.
Re:What's wrong with Windows Server? (Score:5, Informative)
If it was just replacing the /etc/init.d mess, that'd be fine.
My main problem with SystemD is that it is turning into this massive black hole that's trying to replace many different systems in one. And not very well at that.
Why replace pam.d, crond, init, and add complexities like dbus in a single package that runs at PID1 when it doesn't need to? So now a single flaw in its crond could allow a vector that lets dbus provide a way to trick pam.d into letting users escalate their privileges? Sure, it hasn't happened yet, but when you start intertwining these apps into a single super app....
Worse, the logging it provides is next to useless. If I have a headless server with no GUI, how the hell am I supposed to read binary logs? It doesn't even give me useful information during the boot process. At least my old init scripts could do that much.
It completely goes against the core principles of UNIX in general. Do one thing, and do it damn well. Make it interoperable with other processes. Log to text. Configure with text.
I don't want this massive beast of a process that replaces my options. And I especially don't want one that isn't even very good at performing the original single task its supposed to be replacing, let alone all the franken-tasks its taken on.
If this were just about replacing init, I doubt I'd be anywhere near as bothered. But as an active admin, this bothers me significantly more than just having to redo my startup scripts.
Re: (Score:3)
Now this is it. Do it once and do it well every Unix prof i know used to say. Damn kids. Im selfish though I just want portable scripts.
Re:What's wrong with Windows Server? (Score:5, Insightful)
Because confident young men in a hurry to make their own mark on the world have little time for learning the tools or the lessons of the past.
Re:What's wrong with Windows Server? (Score:5, Insightful)
LOL. Maybe with the command line based log reader? Or maybe you have never used the last command to parse the binary log file which is wtmp either.
Have you ever had to monitor server logs remotely?
Explain to me how to easily set up an alert to trigger on an event in a binary log? I can handle that easily in a syslog text log, but I'd love to know how *you* easily do that with a binary log. Could you give me the awk script for it? No? How about just a simple regexp for locating a single type of event that I can have running against the stream of log data as it gets logged into the file?
Binary logs are basically useless to me. I cannot automate them in real time. I cannot filter them easily in a script. I essentially have to parse them manually, or dump them to text and then filter them. What a huge waste of time.
I can leave a script running against a syslog text log, tracking everything as it gets streamed into the file, and I can instantly trigger an alert against an event. Very easily. Very simply.
I cannot do that with systemd binary logs.
Re: (Score:3)
This might be a dumb question but isn't what you're looking for simply... journalctl --no-pager -f | grep blah blah etc ? I'm genuinely curious about your response. I've recently installed ArchLinux ARM on a small server and it uses SystemD (my first experience with it) so far, it's been different, but I havn't found anything that I can't get working in it. I'm not carrying a torch for either the for or against camp here; here's what I've learned setting up my first SystemD server so far.
On the face of it,
Re:What's wrong with Windows Server? (Score:4, Insightful)
FAIL!
He's looking for a replacement to 'tail -f /var/log/messages | grep "something"' and you offer a half-baked API and a link to a python module that WRITES but doesn't read log entries (it says so ruingt in the synopsis).
Debian's approach is the best short of tossing systemd and gnome out on their ears. They lobotomized systemd and chained it's still breathing shell to the wall.
Re: (Score:3)
Does systemctl have a -f mode? That is, it outputs anything appended to the file as it happens?
Re: (Score:3)
To be fair we have a few other "binary" logs: wtmp(x), btmp(x), utmp(x).
Re: (Score:3)
It seems like that problem would be most simply solved by creating a command line tool called 'parallel' that lets you run several commands in parallel, and then returns when it is done. Something like 'parallel cmd1 cmd2 cmd3.'
A wrapper, which can be written as a shell script itself, would look for dependency information in the init scripts, probably in a comment or perhaps in a variable. When the wrapper runs, it checks the status of any required init scripts which share the same first line, using the functionality built into each init script. If they are all running then it fires off the daemon and exits. Else, it blocks if it is critical or not if it is optional, and either way it loops and waits for deps for a decent amount o
Re: (Score:3)
The SystemD developers are self-described unix-haters, who have very strong feeling against ever having to use a "shell script".
Aside from that, this is one of the big problems with the systemd evangelists: they assert that there was some set of missing features that "nobody was willing to implement" outside of Poettering's cabal. They never mention that they were the ones to make up most of those problems, and the few they didn't make up were already solved by existing tools.
(auto-restart was solved ages
Re:What's wrong with Windows Server? (Score:5, Informative)
But OpenRC (Gentoo) does dependency management without having to replace init.
Now systemd does give you a lot of advantages when it comes to fully managing processes, respawing and dbus/alerting. But that's also part of the problem. It connects to EVERYTHING. And if one of those things breaks or has a security flaw, you could pass messages around and compromise systems.
Not to mention the command line tools SUCK.
Sys V: /etc/init.d/ (stat|stop|restart)
Upstart: (start|stop|restart)
Systemd: systemctl restart .service
And you get ZERO output. You have to run journalctl -n or systemctl status right after it. Who the fuck thought that was a good idea?! A widows developer?
Re:What's wrong with Windows Server? (Score:5, Interesting)
I hate posting a "me too" post, but you nailed it. Who the FUCK thought that having to run a separate command to find out if your service started was a good idea?!?
I work in a shop that has ~2000 Red Hat servers / VMs, and my advice will be to switch to something else unless Red Hat gets their heads out of their asses, and gets rid of systemd. Unfortunately we don't really have the option of moving to FreeBSD (tooooo much code to port), but I am sure their will be a distro that fills the void. At least we have a few years to worry about it since 6.x is supported for a few more years -- hell I might fork the final 6.x release.
Re:What's wrong with Windows Server? (Score:5, Informative)
Uhm... cp has the exact same behaviour as systemd. Examples from my system: /bin2
: cp -ar bin bin2
: cp -ar bin
cp: cannot create directory ‘/bin2’: Permission denied
: echo $?
1
: systemctl start dmraid.service
: systemctl start imaginary.service
Failed to issue method call: Unit imaginary.service failed to load: No such file or directory.
: echo $?
6
:
So, systemctl behaves exactly the same as cp - error message and non-zero return on failure. Perhaps you were thinking of the verbose option for cp, which some people alias in permanently but is very non-unixy?
Re:What's wrong with Windows Server? (Score:5, Funny)
Oh the horror! Imagine skills that transfer across Linux distributions! I won't LIVE in such a world!
Re: (Score:3)
Until systemd pissed in the soup, /etc/init.d/servicename (start|stop) worked in every linux distro. Now, who the hell knows.
Re:What's wrong with Windows Server? (Score:5, Informative)
Re: (Score:3)
What us geeks dislike about it is much the same reason we dislike systemd: its an abstract layer between you and the configuration of your services/daemons. We like init.d in that we can script those daemons and even add on to those init scripts if we choose. Where as windows services puts this wall between you and that sweetness. And systemd is pushing us in that direction and OP's last comment in the summary is ringing more and more true.
Uh, tell me how to adjust an init.d script such that: 1. You add support for running the daemon with an ionice level which was missing from the original script. AND 2. The next distro upgrade won't blow your changes away, and you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks?
I'll tell you how - the way smart admins have always done it, by keeping their changes in a different file stored in version control that get's merged with whatever's in /etc after a dist-upgrade. Seriously:
1. The server isn't getting a dist-upgrade every few weeks unless the admin is stupid already, in which case he's probably *for* systemd and not against it
2. It's all text files, hence easy to manage merges with scripts and view differences
and...
3. It's text files, hence a svn/git repo is going to c
Re: (Score:3)
What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?
In windows nothing because it fits the windows way of doing thing but it is horrible when you have a OS based on the UNIX philosophy, well not so much. The Unix design philosophy as described by Doug McIlroy (the hacker that wrote the unix pipes)
(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.
(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. (later he summarized this as "Write programs to handle text streams, because that is a universal interface")
(iii) Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
SystemD violates every single tenet of Unix system design, for no benefit.
Instead of doing one thing start a system like System V init, SystemD takes the kitchen sink approach and does many things badly.
instead of using interoperable text streams for output log and
Too late, we already bailed. (Score:5, Funny)
Some of us stopped using Red Hat when the NetworkManager mess came out with RHEL 6.
Why would we expect RHEL 7 to be any better?
You RedHat fans have fun with your "RedHat Vista" release. :P
Re:Too late, we already bailed. (Score:5, Interesting)
The King is dead, long live the King!
The Future! (Score:5, Insightful)
Oh day of days! Now it needs to statically link in gconf and we'll all have a registry too!
Is anyone really concerned about this? Let me put on my prophetic wizard hat and predict how this is going to go from here:
I'm really not trying to be flip but this is just the FOSS process at work here. It's messy sometimes but so is anything that involves people. Embrace the ecosystem that makes this whole argument possible! If Apple or Microsoft decided they want some polorizing system like Systemd to be the new hotness in their OS offerings there's literally fuck all we could do about it. At least with the FOSS environment we have the freedom to make our own decisions
Re:The Future! (Score:5, Insightful)
Great! That is all we need. More fragmentation in the community! As if choosing a distro wasn't confusing enough as it is for newcomers!
THIS is the reason why Linux will never be a mainstream desktop.
Re: (Score:3, Insightful)
The fragmentation argument is a terrible one, and always was. User's who aren't too technically literate don't know about any linux distro but the one they're using. Hell, how many people out there know what ubuntu is but have no idea what linux is? How would these people even know that a new distro came out which doesn't use systemd, if they're not already a huge nerd? As for newcomers who are more technically literate, just pick ubuntu. It works. Or one of the other big ones if you really want to tr
Re: (Score:3)
I run Gentoo, one of the less-used distributions. I chose it exactly because it was a geeky, nuts-and-bolts distribution. After all, at the time Linux was a hobby, and if you're in it for that kind of fun, go for it.
At the same time, I generally advise against using Gentoo. Unless you know why you want to use it, don't. New users should use something like Ubuntu, which I've installed for several people, or more recently Mint, which I've also done. We use RedHat at work because it's "Enterprise" and has
Re:The Future! (Score:5, Insightful)
I respectfully disagree. Fragmentation impacts both developers and the end users.
Developers:
There are a finite pool of people that have the knowledge to improve/write software. That group is further divided down into those that have the time and motivation to contribute to the open-source software. From there they are further divided among the competing projects that are doing the same thing. Example: GNOME 3 vs Cinnamon vs MATE vs KDE vs Trinity. Debian vs Red Hat vs Arch vs Suse vs Slackware. Therefore this fragmentation needlessly reduces the pool of available contributors.
Also, any software package needs to be maintained for so many different configurations. A very good example is the package management: Debian, Red Hat, Gentoo, Slackware each have their own package format. This fragmentation adds more boring workload on the maintainers. Now that we will have distributions with or without systemd, it means that if the software deals with the area affected, TWO versions need to be developed! Doing something twice is again wasted effort.
End User:
Fragmentation adversely affects the user because the software he/she needs may not be available for the configuration that it being used. It is hard to come up with example for systemd since it is such a system-level system. Much easier to use an example of window-manager fragmentation: A certain package may look terrible on the one that the user chose.
Even if the software is available, documentation may be only written for another distribution.
Finally, the user needs to choose a distribution to start with. The choice is literally overwhelming. Have a look at this timeline: Distribution Timeline [wikimedia.org]. Now imagine it exploding even further into systemd using/rejecting versions. That much amount of choice is paralyzing.
In the end, fragmentation just wastes resources on doing the same things more than once. It is necessary if the constrain is quite severe, but right now in the community forks happen over something as trivial as library versions or the visual look!
Re: (Score:3)
The fact that systemd is causing fragmentation - arguably worse fragmentation than any previous disagreement in the Linux community - is a valid (though not particualrly interesting) argument, because a primary design goal of systemd is conformity. Poettering has stated many times that his goal is to force distirbutions to use his one-true-way, and he often uses the supposed complexity of having to write portable code as an argument for why systemd and nobody else should be the software that manages the "co
Re: (Score:3)
THIS is the reason why Linux will never be a mainstream desktop.
No I think it's a strength. When MS forced Me, vista, Win8 on it, we recoiled and puked, but some people were forced to use it because they lacked options.
When Ubuntu forced Unity on us, we all just dropped Ubuntu and carried on. There has definitely been a loss to the community, Ubuntu was a solid distro for a while, but it's gone, and we still have options.
For Mom and the unwashed mashes, the iPad does what they need it to do (i.e. very littl
Lots of people (i.e. me) aren't in it for the (Score:3)
ecosystem, but for working tools. Democratic messiness is great when it results in working tools. But as an end in itself, in software development? Meh.
Re:The Future! (Score:5, Insightful)
If Apple or Microsoft decided they want some polorizing system like Systemd to be the new hotness in their OS offerings there's literally fuck all we could do about it.
Would that be "fuck all" as in "buy something else", "don't buy at all" or "insist on the old version"? Tanking sales tend to have a very correcting effect on for-profit companies, assuming there's competition to speak of. Sure, I can't decide what that company will do but I can't decide what that OSS project will do either and while I can theoretically fork and maintain my own version it's not really a practical possibility 99.9% of the time. If there happens to be enough people dissatisfied with the direction it's taking to make a fork that's fortunate for me but really outside my control too.
I've been watching Gnome/KDE trying to battle Windows now for the last 15 years or so and making so little progress YotLD has become the running joke around here ever since Duke Nuke'm Forever shipped. Then I look at Android which is more cathedral than bazaar and it's gone from nothing to 85% world wide market share in 6 years. And the absolutely greatest success the Linux kernel is run like anything but a bazaar, lieutenants are from military hierarchy and it has one general on top - or benevolent dictator for life if that sounds better. Sometimes picking one direction - even if it's not the absolutely best one - beats taking no direction or pulling in ten different directions. Heresy, I know.
Dun matter (Score:3, Insightful)
What do we need systemd for? (Score:5, Interesting)
My main problem is that the old init system was dead simple to administer. You only needed to know basic shell scripting as well as grep and you could figure out most things you ever encountered. Systemd again is a horribly complicated program that probably no one except the developers understand inside out.
It seems to me like this whole systemd/upstart etc. nonsense started when someone wanted to make machines boot up faster. The problem is that in today's world how fast a machine boots is completely irrelevant. On VM's you can clone a running machine, so how the OS starts is unimportant. A classic server is always on and rarely gets booted. Laptops, which seemed like the obvious target, are typically just suspended to disk, so they rarely run through the whole boot process. Desktops are typically sleeping too when not in use.
In other words, I still haven't figured out why anyone would need systemd. I've never had a reason to need it. I've only had reasons to hate it when something that used to be very simple is now hidden behind some complicated shell commands.
Re: (Score:3)
You bring up a very good point when you say that the boot time is irrelevant, even on most desktops and laptops. All of my personal desktops and laptops, regardless of OS, reboot only when system updates or software have to be installed. Otherwise, the machine goes to sleep or suspend to disk, often going weeks without a reboot.
"Fast boot" is now often being used as an excuse to push otherwise unpalatable technology. Not just in Linux. I have heard many times from Windows 8 apologists "but it boots faster",
Edit much? (Score:5, Funny)
"Although there are those who think the systems debate has been decided in favour of systems, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise.
"Although there are those who think bacon is tasty, a loud protests I've posted recently on message boards, forums, and here on /. over the past two weeks would indicate otherwise."
(Yeah, I've been here long enough to know that nobody at /. does any actual editing. Still, can I make fun of the submitter for making it sound like (s)he's the one who is going around and posting all the loud protests, and then trying to make it seem like some sort of movement?)
Yaz
Lennart Poetterings rebuttal (Score:5, Interesting)
I would be interested in the anyone's response to Lennart Poetterings rebuttal [0pointer.de] to the common complaints about systemd.
I'm too n00b to know who's right.
Re:Lennart Poetterings rebuttal (Score:5, Interesting)
Overall a good read for people who are against systemd, in case they are against it for the wrong reasons. However for me it rings hollow:
monolithic:
" we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.". The design of all of them is inexorably linked. The component that lives as pid 1 is more complicated than what formerly lived as pid 1.
speed:
whether intended or side effect is a moot point. This should in no way be held as a point against systemd. I presume he's trying to address how dismissive some people are about systemd. He's right, it isn't about speed, it's about more complex issues.
boot speed is needless for servers:
Yes, there are some use cases where boot speed can be good in a server context. There are many more cases where it does not matter. It's silly to tell someone that boot time isn't a big deal to them that it really is. A sysadmin knows damn well which case his falls under.
systemd and init scripts:
"We just don't use them for the boot process, because we believe they aren't the best tool for that specific purpose" Here he misses the point. The complaint is not that people cannot use their own shell scripts, it's that they are now repsonsible for supporting third-party non-scripts by others more than they already have to.
systemd is difficult:
This is a point where it's nearly impossible to retain perspective. as the archtect of systemd of *course* it all makes sense to him. The issue is that other people who are not in that position take issue with it. His rebuttal basically boils down to 'nuh uh, I understand it fine!'
systemd is not modular: .." I think that speaks voulmes right there... Compile time modularity is not the worrisome demonstrative facet, runtime modularity is.
" At compile time you
systemd is only desktops:
true, their intent covers servers and in fact some features that only really appeal in a server. Much of the sysadmin base disagrees, but this is a subjective matter.
Myth: systemd was created as result of the NIH syndrome
They tried somehting else first before thoring up their hands and going NIH. Again, a moot point, the results matter more than the beginnings.
systemd is a fdo project:
Who the hell cares whether it is or isn't?
systemd is not unix:
strictly the myth is true, but linux is not unix either. The statement being addressed is that systemd is a departure form the unix-like ways. This is undeniably true, just differnt audiences have different opinions on the value of that.
systemd is complex:
He made it, so he understands it better than the stuff he did not make.
systremd is bloated:
What moist people mean here is feature creep, not resource consumption
not nice to BSDs:
the complaint is really not nice to people who administer both platforms, not that BSDs are themselves maligned,
there are a lot of oversimplifications about porting it to other places, but I think people don't WANT it ported, so that's a lot of evangelizing to a group that does not exist.
not debuggable:
it is debuggable... if you are a developer.. again failure to keep perspective of many sysadmins.
Re: (Score:3)
Re:Lennart Poetterings rebuttal (Score:5, Insightful)
I would be interested in the anyone's response to Lennart Poetterings rebuttal [0pointer.de] to the common complaints about systemd.
I'm too n00b to know who's right.
Full disclosure: I do not like systemd, although that judgment is based on its merits as I see them relative to my needs.
There seemed to be a pretty concerted determination not to get the point in Lennart's long spiel defending the system. As someone who has been using Unices in anger since the early '90s, I've pretty much seen Linux grow from its infancy. I've seen this kind of attitude before in technology — in Windows, Linux and elsewhere. The article is clearly written (and written clearly) by someone who's clever, articulate and... far too concerned with being right. It's not a healthy perspective.
Being technically correct is not generally optional. It's just not ever nearly as conclusive as some people think it is.
Having the humility to accept an imperfect universe — and to admit that it's imperfect in a particular way for a large number of particular reasons — is a virtue that fewer and fewer people seem to possess these days.
(It's the lack of this virtue that makes people say, for example, 'less and less' where I used 'fewer and fewer' and when someone corrects them, they trot out the grammar nazi epithet and say, 'Everybody knows what I mean. Deal with it.' And the lack of this virtue as well that will make people pick on the triviality of this example to discard my entire post. The temerity of such an approach cannot be explained to those who suffer from it.)
Systemd is clearly not change for change's sake. Lennart and the dozen and a half others who have commit rights are clearly scratching an itch. But regardless of the technical merits of the system, it is horribly, horribly wrong to impose this new system —any new system— on Linux wholesale without a significant maturing process. And by significant, I mean years.
And this is where Lennart's most completely mistaken. He thinks that the technical arguments are the decisive ones, in spite of the fact that technical merit is not why systemd is going to become prevalent. He therefore tries to write a technical opus in defence of the indefensible, which requires more than a few straw men (binary config files? shyeah....), several big ommissions (binary log files) and a clearly unwilled but nonetheless unforgivable ignorance of the fact that he's winning because he's RedHat, not because he's better. (Yeah yeah yeah, it's not all RH; it's others too, you're technically awesome - I read that part and remain utterly unconvinced by the argument.)
Paul Venezia's screed, on the other hand, is just plain substance-free. He's not arguing either technical merit or political power. He's simply looking at a looming mess and saying, well, that it's going to be messy. And to that extent, he's right. Systemd is going to make a mess, and that's precisely because its proponents think that they're perfectly within their rights to claim, 'Well, nobody's forcing anything on anyone.'
What they don't realise is that that is not how cooperation works. And believing you're better or righter than others is an absolutely shit way of improving your own software.
Re:Lennart Poetterings rebuttal (Score:5, Insightful)
Here we go:
1: If it *ISN'T* monolithic, why won't Gnome work wiothout it and why aren't the pieces available seperately?
2: If it isn't about speed, why is that all people talk about? What is so 'right' about the way systemd does things?
3: Servers start fast enough without systemd. In the cases where they need to start faster than is typical, they also tend to run ONLY the critical sevrice (ans so already start fast) OR they start the critical service first (and so it's also not a problem). The argument about VMs is entirely specious. The same services must be started either way, so the same I/O and CPU load has to happen one way or another.
And as for 'socket activated containers', it's called (x)inetd and we've had it for decades now.
4: The problem is that often server admins just need to make a small change to the standard shell script that starts a daemon in init.d. Except with systemd, there may not be one unless the distro was smart enough to effectively sidestep systemd by making it start rcS only and sticks with the scripts.
5: Are you freaking kidding me? Where's the howto? Where's the overview? Where's the freaking manual? Most of it is of the nature of 'absolutely true thing isn't REALLY true because OHH look, a bunny! (run away)".
6: I'd rather not recompile every time I want to re-configure my system, thank you very much. The modularity we're after happens at runtime, not compile time. Kinda like in the kernel, I don't have to load the modules I don't want.
7: It all kinda falls apart once 1-6 are dispelled. It adds unwanted complexity and dependencies to the server. A perfect recipe for disaster when things are going badly and the server is hours away by car.
8: Nothing systemd does couldn't have been done using a few helper apps. Had it been done that way, nobody would have a single objection to it. So why wasn't it done that way? That's right, NIH.
9:Well, let's see. It's hosted there, it's developers talk the same talk, and it's all been snarled together into a single dependency ball......
10: Only someone who never grasped that Unix is about small parts that do one thing well tied together through scripts and file-like objects could have written that.
11: A few big honking packages is certainly not simpler than a series of small and largely independent packages. It's a question of how much you have to know in order to do a simple thing. Small packages always win that question.
12: How big is init? Because in Unix, that's the part that has to be loaded. All the rc scripts do their thing they go away. They don't stick around after they do their job. In systemd, most of it insists on staying for some reason.
13: The problem is that it creates a moral hazard. It invites other unrelated things to become dependent on it (like gnome of all things) and so, not compatible with BSD. And BTW, a lot of us Linux folks don't want it either and don't appreciate the dependency trap being used in an attempt to cram it down our throats.
14: You're ACTUALLY arguing that since they worked so hard, what's a bit more? REALLY?!?
15: So there's so many dependencies it's even trapped itself? That doesn't sound like a feature to me... I thought you said it was modular, not complex and not difficult!And didn't you claim it was Unix? BSD is Unix and you're telling me it is intrinsically incompatible? You say there are far too many dependencies and it is all too complex to port? Do YOU even believe what you write?
16-17, no comment
18: So in other words, it IS feature creep!
19:Heh Heh. It's not like you HAVE to breath or anything. You could always hold your breath forever if you don't like my farts. I'm sure it is pure coincidence that other freedesktop projects have developed a hard dependency on systemd when they clearly never needed it befiore.
21: Yeah, it's all perfectly compatible as long as you do it our way rather than the way you did it before.
24: Compared to init, that IS buggy and unstable
Re: (Score:3)
Talking to a megalomaniac is a waste of time. You are not going to reach him, regardless of the validity of your arguments. The whole systemd discussion amply demonstrates this. This guy thinks he is Linus reincarnated and since he cannot do a new kernel, he has fixated on the next best thing.
Which worked out oh so well in the whole PulseAudio fiasco a few years ago.
You'd have thought that one thing alone would have taught Red Hat a thing or two about the guy they're trusting to manage the very core functionality of their primary business product.
I'll use a "server" distro on my laptop... (Score:3)
Moving to FreeBSD is probably more a ZFS thing (Score:3)
the problem with Windows... (Score:3)
The problem with Windows isn't what it is trying to do but how it is trying to do it: the highly interdependent object-oriented libraries, the widespread use of C++ for basic services, bloated functionality in everything from the file system to the mouse. Even if every single daemon and server in Windows were superior to Linux individually, the entire system would still be crap because of that.
I don't understand the hate for SystemD (Score:3)
Init was simple, but it left me pining for proper dependencies among daemons. I mean, more than simply trying to stipulate a runlevel loading order by numbering symlinks.
For example, I don't want samba to start unless iscsi is successfully up, etc, etc, and I don't want to code a bunch of one-off scripting in various daemon script files. There are many more instances just like this, and init doesn't handle the use case.
Services are one thing (dependencies, monitoring service status, etc) thar Windows got right. I didn't like the glue / bootstrap code and installation for services, but it's far closer to what I want than init. Solaris' approach also seemed nice, at least upon cursory examination.
Anyhow, systemd gives me what I have always wanted, at the cost of me having to learn a new approach. That's a fair trade.
I hate Gnome 3, Unity, Metro, the last 3 years of "improvements" to Google services UX, etc. Conversely, systemd honestly feels like an upgrade in practically every way.
Seriously, can someone tell me what horrors caused by systemd that I have overlooked?
Re:Troll much? (Score:4, Interesting)
systemd reminds me of Solaris' svcs, and I DO NOT WANT.
Re:Troll much? (Score:5, Insightful)
What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
Init runs as PID 1. Systemd runs as PID 1.
Most init systems have a negligible amount of code running as pid 1, meaning init itself is unlikely to ever cause a blip at runtime. The complaint is what the implication for the complexity and volume of code in systemd approach. A better counter argument would be that the kernel itself has even more complex needs and runs in an equally critical context. That's a bit more defensible, though adding more complexity under that excuse is still a weak one.
Claiming that "lots of people don't like systemd equates to anything other than lots of people don't understand systemd, but will complain anyway is just stupid
No, lot's of people who know well enough how systemd works and still don't like it for valid reasons. No one claims it is not capable of things that classic init could not really do, but the question is the relative value of those features and what is given up in the pursuit of those capabilities. systemd is more monolithic in design, involves more compiled code beyond the reach of the typical shell capabilities of a sysadmin, and is more complex in its underpinnings in general. If your boot went off the rails in a classic init system, you can work through it using shell debug because it is comprised of a tiny bit of c code that hasn't changed in an eternity jumping into a sea of plain old shell scripts.. You can chroot and play around a non-booting image if needed. If systemd goes off the rails, it requires a much more complicated debug effort. You pretty much have to start up a container rather than just chroot (admittedly systemd provides a facility to mitigate the complexity of that task, but it is more complex than just chroot). It has a high likelihood of landing in some code a sysadmin is helpless in the face of compared to the same task in classic init scripts. A local mistake can escalate to systemd debug assistance more quickly. This is very much like Windows (which has it's qualities as well) where if things go off the rails very far, it's nearly a lost cause to sort out what happened and how to come back from it unless you have Microsoft developers ready to answer the call to debug it (and they almost never are).
Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well.
And there are tons of carburetor platforms in the wild for brand new products. Try finding a leaf blower with fuel injection. The cost and complexity of a fuel injection system is too high in many applications. If cost and complexity were equal, then *everything* would be fuel injected, but cost and complexity are not equal. This is actually a very good analogy for systemd, capable of inarguably fancier tricks but the universe of mechanics who can repair it when broken versus throwing the whole thing out is much different. The relative merit though is more questionable (everyone benefits from lower fuel consumption and reduced uncombusted gasoline in the atmosphere, not everyone really benefits meaningfully from the advances in systemd).
What systemd advocates fail to recognize is that not everyone should have to be an application developer to administer systems. They assume minor configuration mistakes are all sysadmins have to contend with and thus they don't understand why a sysadmin might need to follow the flow of the init system in more detail and yet not have the ability to easily cope with systemd code. The 'DevOps' buzzword may embolden assumptions in some circles, but it does not mean that good sys admins have magically changed, just th
Re: (Score:3)
What I don't understand is why systemd advocates continue to not understand the perspective of those against it. Critics tend to recognize what systemd brings to the table and debate from that point. Advocates just call those people idiots, curmudgeons, and so on rather than understanding the perspective of the opposing viewpoint. It's quite maddening.
I think it is megalomania. Not a good basis for trusting these people. The only alternative I see is that they know their thing is really a disaster waiting to happen.
Re:Troll much? (Score:5, Insightful)
I must fess up. I've used Unix since 1978. I cut my teeth on System V and I just fell in love with it's init.d system, where I could control an entire 80 port modem bank enable/disable with a simple change of the init state. telinit 5 - multiuser, telinit 6 - multiuser and modem banks. Heck you could even put that in a cron job. The init system of SYSV was simple, easy, powerful and logical. It is the UNIX WAY.
Fast forward to this labor day weekend, and I had to go into work for a 'Webserver Down' call. Sure enough a hardware failure, so I rebuilt a new system using the *Latest and Greatest* linux distro that was systemD. I needed Apache to fire up with an init.d script, when run-level 5 was hit. Oh wait, how do you do that? Well this is clearly explained so clearly and idiot could do it. It's in /etc/systemd in systemd.conf? Nope! Is it in /etc/systemd/system? Nope! Which one is it? I find a softline from system.default to /lib/systemd/system/runlevel5.target. I 'cat' and it says:
---
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
Wants=display-manager.service
AllowIsolate=yes
---- /etc/rc initialization method. At least it's readable and understandable. All I want is add is Apache_special_ctl start in the initialization to multiuser mode. Were are the readable BASH scripts at? I'll try to emulate IRQBalance, When I drill down soft-link after soft-link I finally find this;
In other words this is a damn maze of BS! Some windows wanker wrote this puzzle to destroy Linux I'm convinced. I'm tempted to switch to BSD just to enjoy the
-----
[Unit]
Description=irqbalance daemon
After=syslog.target
[Service]
EnvironmentFile=/etc/sysconfig/irqbalance
ExecStart=/usr/sbin/irqbalance --foreground $IRQBALANCE_ARGS
[Install]
WantedBy=multi-user.target
----
Hang on, where did the variable $IRQBALANCE_ARGS come from? Grep? nope, more grep? nope! More google searches? Nope.
This is BS. I don't care if you can do a parallel start up (fundamentally you can't anyway, but in init you could use '&' idiots). The complexity added to the system start up and the 'telinit' process is inexcusable and is the worst computer science or computer engineering I have ever seen! It should be tossed into a dumpster! Seriously! Even young programmers will never figure systemd out. It's an undocumented programming maze of gotcha's.
Needless to say my efforts failed and I tossed the machine across the room for the fun of it.
Systemd developers deserves the finger for such an programmer unfriendly pile of trash that replaced elegance and simplicity.
Re:Troll much? (Score:5, Insightful)
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.
This is BS. "Learning" SYSV configuration takes 15 minutes to explain run levels and that everything is scripts and (usually) symlinks. You could even learn what you need by recursively grepping /etc for a process name and the script it's in is readable to anyone with programming experience. GP pointed out that a config file for systemd is sitting in /lib. WTF?
Re:Troll much? (Score:4, Insightful)
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.
Re: (Score:3)
Well, are you a nice troll too! Anyways, no monolitic, crappy, uninformed and anti-UNIX monstrosities will ever make it into my PID 1.
Re:Troll much? (Score:5, Interesting)
Except we don't see systemd solving any problems. It is a solution searching for a problem.
Re:Troll much? (Score:5, Informative)
Well it does solve some problems, just not problems many server administrators largely cared about while creating problems some systems administrators really do care about.
-Services cannot reparent themselves out of the launching context, meaning init system *always* knows how many processes it is and resources it consumes. It's nice and structured, too bad that ps axf and grep largely serve the same purpose when things went south, but the systemd approach is certainly more structured. Of course it means that you can't try out a systemd controlled service start in a chroot, since it can't take pid 1 and how could we have *possibly* ever lived starting services as anything but pid 1.
-Bake in more advanced log processing to mitigate the need for log analysis tools. The problem of course being that those log analysis tools tend to work well enough while leaving the plain text behind in a manner that can be trivially opened and perused in Windows or whatever.
-Starting up /bin/sh hundreds of times during boot is wasteful and slows boot. Systemd mitigates that by enabling more lightweight service start. However you'd have to care something about boot times, which is rarely even in the mobile category (android phones take forever to boot, but people don't seem to mind since they almost never reboot them), and not mind that more opaque binary code is handling stuff that a common sysadmin cannot trace.
-Sequential startup of services is silly when many can be started in parallel. Of course now you have to debug a less deterministic boot process to enable such a thing, with the same inscrutable code paths for the sake of a faster boot very few people needed.
Re: (Score:3)
-Bake in more advanced log processing to mitigate the need for log analysis tools.
What was wrong with log analysis tools? One can bang them out with perl in a minute or two.
Starting up /bin/sh hundreds of times during boot is wasteful and slows boot.
No, it really isn't. Process creation is cheap on Unix, and the shell will not only be cached during boot, but one or more copies of it will be present in memory at all times. Running the shell hundreds of times today is a triviality compared to running the shell dozens of times on Unix machines from the 1980s, on which that was in fact not a big deal, because process creation is cheap on Unix. This is just not a real
Re:server admins moving to FreeBSD (Score:4, Insightful)
Re: (Score:3)
The situation is pretty simple.
1) Gnome and then more software depends on systemd
2) Debian doesn't want to fix those problems
ergo: easiest solution is to make systemd the default for Debian.
This would be a fight and Debian decided not worth it.
Re: Debian general resolution needed (Score:4, Informative)
There was no general resolution selecting systemd, you smug liar. Someone reported the fact that systemd was not default as a bug and the eight man technical committee (tech-ctte) decided for systemd in a tie broken split decision. An end run was done around the rest of the debian devs. Anyone who opposes systemd is labeled a troll and banned from the mailing lists now.
Re:if systemd forces it's way into gentoo (Score:5, Funny)
Wow, something so awful even some Gnome 3 users can't take it.