You Got Your Windows In My Linux

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."

Comments

What's wrong with Windows Server?

[recoiledsnake]

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?

[Virtucon]

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.
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:What's wrong with Windows Server?

[machineghost]

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?

[taustin]

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?

[gandhi_2]

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?

[DoomSprinkles]

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.

Re:What's wrong with Windows Server?

[Anonymous Coward]

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.

Do you have any backing for that?

With windows server core the OS doesn't really take up any cycles. No gui, just a console and remote admin.

Re:What's wrong with Windows Server?

[Anonymous Coward]

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?

[DoomSprinkles]

Correct but I think the reason there's so much pushback is because it wont be long before it's not just an alternative with backward compatibility and it becomes the only way. Stepping us in that direction.

Re:What's wrong with Windows Server?

[GigaplexNZ]

It definitely makes a difference when I tested software RAID at home, but I doubt "real" servers bother with the Windows storage software stack. It also used a bit more RAM under load, but not enough to be a dealbreaker.

Re:What's wrong with Windows Server?

[magamiako1]

You still have to license RHEL if you intend to have support. I suppose if you don't mind going at it your own...

Re:What's wrong with Windows Server?

[magamiako1]

Holy fuck a Linux/Unix guy I'd shake hands with. This is the correct answer, folks :P The minute you get into a "get off my lawn" approach to technology is the day you sign your career's death warrant.

Re:What's wrong with Windows Server?

[Atzanteol]

Oh the horror! Imagine skills that transfer across Linux distributions! I won't LIVE in such a world!

Re:What's wrong with Windows Server?

[whoever57]

Rather than have an /etc/init.d/myservice restart all related services to ensure a "clean" environment, I can list dependencies and triggers and rely on the system to do what is appropriate.

So it solves a problem that Gentoo solved years ago in its script-driven init system?

Re:What's wrong with Windows Server?

[PRMan]

I've never used the "Support" on any Linux box yet. And almost never on Windows either. It's quicker to look it up yourself. In fact, out of the 3 times I called Microsoft Support, twice I got refunded for figuring it out while on the phone with the "experts".

Re:What's wrong with Windows Server?

[Korgan]

You still have to license RHEL if you intend to have support. I suppose if you don't mind going at it your own...

You're not licensing RHEL, you're licensing a support agreement for 12 months. There's a pedantic difference.

The difficulty with RHEL is that if you want to run it without support, you have to compile it yourself. They do not release binaries outside of their support agreements. Which is why CentOS (and others) exists in its current implementation.

Re:What's wrong with Windows Server?

[geekoid]

"puts this wall between you and that sweetness"
The best thing about Windows discussion /. is the Windows ignorance.

Re:What's wrong with Windows Server?

[rahvin112]

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?

[Korgan]

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:What's wrong with Windows Server?

[msauve]

It's not so much "get off my lawn," as "have your dog crap in your own yard."

Re:What's wrong with Windows Server?

[Anonymous Coward]

Yep. One of the things you can always count on from Poettering & co. is an almost complete lack of awareness of preexisting projects solving the same problem that they've decided to tackle.

If an eighth of the effort that went into systemd was spent on removing the rough edges from OpenRC, Debian Jessie would be using OpenRC now instead of systemd.

Re: What's wrong with Windows Server?

[machineghost]

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?

[SumDog]

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?

[BlackHawk-666]

I use Debian you insensitive clod!

Re: What's wrong with Windows Server?

[Provocateur]

good, because the use of we're raises some concern...

Re:What's wrong with Windows Server?

[machineghost]

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 try by "forum points", not their beliefs
4) You think that someone getting a flamebait vote is some kind of great kharmic vengence

I'd encourage you to challenge those assumptions; in my view none of them are true.

Re:What's wrong with Windows Server?

[Zeromous]

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?

[Anonymous Coward]

systemd changed the long-standing behavior of unmounting an rbind-mounted mount.

Since time immemorial, on every Linux system, if you rbind-mounted a directory (A) that had contained mount (B) into some other directory (C), did work in C, and then umounted C, A and B would be untouched. The systemd folks took it upon themselves to ensure that when you unmounted C, systemd would also unmount B.

Why? I guess the old way was too old-fashioned.

See
http://lkml.iu.edu/hypermail/linux/kernel/1303.3/02566.html
and
http://lkml.iu.edu/hypermail/linux/kernel/1303.3/03254.html

Re:What's wrong with Windows Server?

[nabsltd]

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:What's wrong with Windows Server?

[Anonymous Coward]

If I have a headless server with no GUI, how the hell am I supposed to read binary logs?

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.

And before you spin it into a Windows Server diss, also remember that Windows allows powershell via winrs which is essentially the ssh for windows (or you can install ssh and tada same interface). So now that you have powershell access you have full access to the entire event-based binary log system. At the command line.

    And before you bash Windows for not allowing you to run your bash script to parse that binary log file, enter cygwin which gives you a posix compliant environment that can run windows executables.

Re:What's wrong with Windows Server?

[r_naked]

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?

[jedidiah]

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?

[Aboroth]

I'm really sick of reading that excuse. Whenever somebody doesn't like something new on computers, the people who do like the new thing immediately jump to "well it's just because you don't like changing."

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?

[elgatozorbas]

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?

[psyclone]

I was thinking the same thing. Gentoo has decent support for dependencies, better than Upstart in my opinion, and was working years earlier.

Looks like Gentoo will also support systemd.

Re: What's wrong with Windows Server?

[Volguus Zildrohar]

So you want the standard view instead of the extended as the default? It's easy to do if you're willing to have your own msc file - run mmc, add the services snap-in, and customise the view. Once done, save the msc file and open that instead of services.msc.

Once it's exactly as you like, use File > Options to turn off author mode, and prevent saving changes to the view.

This is most useful if you have a couple of other annoying MMC snap-ins with bad defaults. Make yourself a single 'control center' set up just how you like it.

Re: What's wrong with Windows Server?

[Anonymous Coward]

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?

[Grishnakh]

Teslas, from what I've read, are pretty open compared to other carmakers. You can connect an Ethernet cable to them and access the main computer's Linux prompt pretty easily. Most other makes require special tools to do anything at all involving the computer.

Re:What's wrong with Windows Server?

[Grishnakh]

>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.

Maybe you haven't heard of the X Window System, introduced over 25 years ago. It allows you to run graphical applications remotely, so the system with the application does not need a GUI at all.

Re:What's wrong with Windows Server?

[Korgan]

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?

[Culture20]

This is what I was saving my mod points for. Too bad they expired.

Re:What's wrong with Windows Server?

[ArhcAngel]

I haven't used it and I love it!
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?

[Kabukiwookie]

Or maybe you have never used the last command to parse the binary log file which is wtmp either.

The wtmp, utmp and btmp files are the biggest pain in the ass when it comes to setting up centralised logging. In my view putting authentication info in these binary logs is one of the bigger mistakes made in Unix' murky past. And now we have someone repeating the same mistake with systemd

Re: What's wrong with Windows Server?

[phantomfive]

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?

[Mr_Wisenheimer]

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).

Re: What's wrong with Windows Server?

[biohazard123]

It still requires you to run X on your server even if you are using a remote client. I agree with the OP; anyone running X on a server is a fucking idiot.

You don't need a local X server in order to launch a GUI application over the network on a remote X server.

Re:What's wrong with Windows Server?

[Rich0]

Looks like Gentoo will also support systemd.

Gentoo already supports systemd - that webpage is a year old and wasn't a great comparison at the time it was created (and systemd was already available on Gentoo back then). SystemD on Gentoo is old news already - about the only thing left is to strip sysvinit out of the default install and have use user pick whatever implementation they prefer (much as they already pick kernels, cron, syslog, etc implementations). The whole point of Gentoo is to try to leave the choice up to the user and at this point you'd be hard-pressed to find software on Gentoo that doesn't work about as well on both OpenRC and SystemD.

Re:What's wrong with Windows Server?

[dbIII]

I think it's more "so you've reinvented the wheel - why does it have fucking corners? I'll stick with my old wheel for the moment thanks" instead of "get off my lawn".

Re:What's wrong with Windows Server?

[Virtucon]

don't run RHEL run CENTOS if you don't want to "pay" for anything.

Re:What's wrong with Windows Server?

[Rich0]

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?

With systemd you just stick a drop-in in /etc and it will only override that one setting in the default unit - and there is no file collision. That's the beauty of declarative programming.

Re:What's wrong with Windows Server?

[gladish]

services.msc is the Microsoft Management Console snap-in for controlling the service control manager. It's really not the thing that's similar to systemd. I think the service control manager (SCM) itself is similar, but it also has an API for control and a couple command line interfaces (dos and powershell). I've actually worked on a project on FreeBSD (closed source) where the concept of an SCM type application always came up. In theory it could have provided a nice consistent interface to our "services" to do things like stop, start, query status, logging, etc. All the boiler plate stuff then looks the same from the outside, instead of being more adhoc. I guess with initd and all the shell scripts, you get a few logging utilities and then shell error codes. Other than that, it's pretty much open season.

Anyone who has written a service for windows knows a few things. First, you always need a way to run it as a normal windows console app or debugging it is a royal pain. Second, you better write it so that it shuts down properly or you'll be getting tons of questions about warnings and errors in the event log. Installing and un-installing can also be painful. I can't be certain how/why, but automating the installation, upgrade, and removal of the service was sometimes problematic if someone logged in and left the SCM control panel running.

Once you have all the kinks ironed out, it's really nice. Admins can start and stop things, install/run your service as different users both domain or local. They can also do things like restrict access to the network, etc. and it's all familiar to them. It does take some cooperation on the developer's part. It is possible to write a service that totally sucks. By sucks, I mean it's buggy and therefore doesn't play nicely with the SCM. Leaves cruft in the registry, and so on.

I had an opportunity to write code on windows (c++ and c#) for about 5-6 years after working exclusively on Linux, FreeBSD, IRIX, HP-UX, and Solaris for about 10 years. I really liked it a lot. I worked on win2k3 and xp, and then win2k8 and win7. I thought win2k8/win7 were both really nice. I was actually blown away about how good the MS IDE and debugger is. The shell still sort of sucks (powershell). I wish someone would write a 'native' shell for windows that was cool. I'd event settle for a dos prompt you can resize like an xterm.

Re:What's wrong with Windows Server?

[gladish]

Here: http://msdn.microsoft.com/en-u...

Re:What's wrong with Windows Server?

[phantomfive]

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 would add that the main problem they seem to be solving is slow bootup times, which are slow because you can't run startup processes in parallel.

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.'

Obviously it could be more complex than that, but it wouldn't need to be much more complex. Most of the other problems with init could be solved with similar simplicity.

Re:What's wrong with Windows Server?

[Korgan]

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: What's wrong with Windows Server?

[dylan_-]

It still requires you to run X on your server even if you are using a remote client.

No it doesn't, that's not how X works. Try it for yourself. Create a new VPS on your favourite provider and do:

ssh -X somemachine
sudo apt-get install x11-apps

Note it doesn't install X11 itself. Type 'xcalc' and notice that xcalc starts in a window on your local machine. It's really that easy.

Re: What's wrong with Windows Server?

[Mashiki]

If special tools mean making your own OBDII cable, and loading one of the dozen or more software packages onto a PC or laptop to interface with the onboard computer...I guess so. Then again I must be old, after all, I remember when people looked at making their own OBDII connectors because it was fun.

Re:What's wrong with Windows Server?

[ObsessiveMathsFreak]

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?

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?

[Anonymous Coward]

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.

Re: What's wrong with Windows Server?

[Grishnakh]

>f special tools mean making your own OBDII cable, and loading one of the dozen or more software packages onto a PC or laptop to interface with the onboard computer..

You can probably buy the appropriate OBDII cable, but what software packages are you talking about? This probably varies enormously by automaker. Doing anything advanced on my Volvo requires buying a "VIDA" unit; you can get Chinese-made clones for $150-200 on Ebay, but there's still a bunch of procedures and updates that seem to require an online account with Volvo which costs a fortune.

Re:What's wrong with Windows Server?

[skids]

Which makes me think SYSTEMD is probably alpha software, being thrust into production

I have to kind of agree to that point. I'd give it maybe BETA, but definitely the burden seems to now be on the community while the eventual credit will juice the egos of the originators as they move on to piss on other trees. I think systemd has potential to be a significant improvement as the larger community gets into it, debugs the things the core team left untested, undoes some of the crap decisions, and eventually forces democracy into the development process through a process of acrimonious forking and distro foot dragging on versions. The SYSV systems that have been at the heart of distros are not more capable/maintainable, they are just more mature. The fact that there was some consideration given to alternative viewpoints (like not wanting your service controlled by dbus) makes it less evil than it's made out to be by some, and it does address more modern concerns that were not around when SYSV set some things in stone.

If the community has enough patience to get systemd up to snuff I'll just learn to live with the crappy ArbitraryVariableNames and INI-format flat grammars that fail to hide necessary complexity behind HeirarchicyInArbitraryVariableNames.

Re: What's wrong with Windows Server?

[exomondo]

We're you planning to edit the source? I wasn't.

If you don't change your own spark plugs, would you buy a car with the hood welded shut?

Well software doesnt degrade over time due to use so if the spark plugs in my car were the same I would never need to replace them and yes having the hood welded shut (assuming all the components were like that too) would probably be just fine.

Re:What's wrong with Windows Server?

[mysidia]

What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?

One of the biggest issues, is that in case I want to run a service as a certain local user --- login credentials have to be entered and saved in an insecure fashion (Yes... there are tools that can extract the password used to run a service from the "secure credentials store); in UNIX you don't have this problem --- you can run a service as any user, just SU in the startup script -- no password needed.

If a kerberos credential is needed in unix? No problem.... kinit a service credential and configure the service with the proper ticket cache directory. Again, no user passwords need to be leaked into an insecure format!

Next, For starters... I can't control+click and choose Stop, Start, or Restart, Enable, or Disable, on multiple services at the same time.

If I send a Start or Stop command using services.msc; I can't use it to send any other Start or Stop commands until my first command is done, including all dependent services ---- I guess the service control manager is "locked" until the operation is done.

Nothing like the concept of init runlevels or commands in a shell script.

Next..... it's really quite a mess to attempt to go add or remove a service from services.msc. I have to pull out a registry editor and go through a bunch of complicated steps.

In CentOS5 it was simply a matter of create a script in /etc/init.d and do chkconfig --add blah. Easy as pie.

Next we have the issue of checking the status of a service and getting a simple status code that can be readily used in a script to take arbitrary actions.

The relatively limited nature of choices in services.msc of what to do if a service fails.

Re:What's wrong with Windows Server?

[jaminJay]

I thought it returned nothing if it succeeded and displayed a message for any other exit mode (just like a UNIX command should)?

Re:What's wrong with Windows Server?

[Zeio]

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?

[Anonymous Coward]

> And the best thing I've seen so far to replace startup scripts is Sun's SMF

Dan J Bernstein's 'daemontools' was actually pretty good. Unfortunately, 'djb' insisted on an 'you can read my code, but you cannot modify one line of it and ship binaries', anyone who cared even to follow the "file system hierarchy" and lay out daemntool's directories sensibly could not include the modified software. It was a classic case of 'half-baked "my ego is bigger than yours, so I'll invent a license that no one else can stand" wins out over solid software design' situation.

So instead, the systemd authors cribbed the daemontools architecture and overwhelmed it with a lot of unwelcome debris. I begin to see, better, why Dan didn't want people modifying his source.

Re:What's wrong with Windows Server?

[drinkypoo]

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 of time. If it is critical the boot process is interrupted, if it is optional then something else happens (script-dependent.) Dependency information could also be stored in a variable in a config file (e.g. in /etc/default) and when not present, the daemon can be treated as critical and blocking. All the other elements of the system remain unchanged, down to symlinks establishing daemon launch order. This requires changes only to init scripts, and even then only for daemons which are expected to launch in parallel. Is there some obvious reason why this wouldn't work?

Re: What's wrong with Windows Server?

[MikeBabcock]

No you don't, you just need to install the X application you want to run and the xorg-x11-xauth package so you can run 'ssh -X remote command-name'

That's all.

Your GUI point aside though, I agree that systemd is way too big for a PID 1 process.

Re:What's wrong with Windows Server?

[phantomfive]

Maybe the primary reason they made systemd is because they thought init scripts were too complicated?

Other than the parallel problem (which we've shown has multiple solutions), I think the only thing missing is the 'auto-restart daemon' problem. If you fix the parallel, the complexity, and the restart, then systemd has no use in the world.

Re: What's wrong with Windows Server?

[phantomfive]

While the potential is there, we have not seen anything as bad as the OpenSSL bug.

Wow, go look through a vulnerability list some time

Re:What's wrong with Windows Server?

[MikeBabcock]

Imagine if you ran "cp -ar stuff /somewhere/else/" and it returned true, and you had to continually run 'cpcheck' to see if the copy succeeded or not.

The default behaviour should be to return whether the service started or not when you start a service.

Re:What's wrong with Windows Server?

[Wolfrider]

> ...my advice will be to switch to something else unless Red Hat gets their heads out of their asses, and gets rid of systemd

--You might want to look into SuSE; a bit of googling found me this:

https://en.opensuse.org/openSU...
^ Tells you how to get rid of it ;-)

Re:What's wrong with Windows Server?

[Wolfrider]

> The shell still sort of sucks (powershell). I wish someone would write a 'native' shell for windows that was cool. I'd event settle for a dos prompt you can resize like an xterm.

--Ever heard of 4dos? Check this one out:

http://jpsoft.com/

--No affiliation, just satisfied user. 1st ran into it back in the 90's when Norton Utilities bundled Ndos. The TCC/LE version is free.

Re:What's wrong with Windows Server?

[jbolden]

There are several GUIs the big 2 are: Kcmsystemd (KDE) and Systemd-ui (low dependencies).

Re:What's wrong with Windows Server?

[Bite The Pillow]

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?

[jbolden]

I doubt systemd will be needed for the kinds of tasks you'll be running on a server that has no GUI. But if you want to read the logs, mount or copy them to a machine with a GUI.

Re:What's wrong with Windows Server?

[Kazoo the Clown]

So much for tail -f | grep

Re:What's wrong with Windows Server?

[jbolden]

http://www.freedesktop.org/sof...
People are already starting on wrapping it: http://search.cpan.org/~lkundr...
so far writes log.

Re:What's wrong with Windows Server?

[Anonymous Coward]

$ cat /var/log/syslog | ./your_filtering_script.sh

- or -

$ journalctl -f | ./your_filtering_script.sh

Was that so hard?

Re:What's wrong with Windows Server?

[lister king of smeg]

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.

Re:What's wrong with Windows Server?

[ustolemyname]

Uhm... cp has the exact same behaviour as systemd. Examples from my system:
: cp -ar bin bin2
: cp -ar bin /bin2
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?

[techno-vampire]

Gnome and KDE are no more difficult to configure than Windows or Mac.

True, but not relevant, at least in a server environment. Most of your servers probably won't have a GUI, or even a monitor, being administered by ssh and a CLI. For those few boxes that need a GUI, you're much better off with Xfce, Enlightenment or some other lightweight DE that doesn't suck up such a large percentage of your RAM and CPU cycles, leaving you with more resources to devote to work. And, even if they do take a little more time to configure, so what? It's a one time task, and trivial to copy from one box to another as needed.

Re:What's wrong with Windows Server?

[Endymion]

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. Many discussions on slashdot warned about how Microsoft was trying to "embrace and extend" various standards such as Kerberos.

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?

[julesh]

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 here; Hearthbleed appears to have been fixed much faster than an average important security flaw in a closed source package.

Re:What's wrong with Windows Server?

[goose-incarnated]

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 contain all the configuration anyway, unless the admin is stupid already, in which case he's probably for systemd (again).

With systemd you just stick a drop-in in /etc and it will only override that one setting in the default unit - and there is no file collision. That's the beauty of declarative programming.

They say the same thing about excel spreadsheets. Most spreadsheets are still a hideous mess to maintain. I think you just proved the "against" argument.

Re: What's wrong with Windows Server?

[julesh]

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?

[julesh]

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:What's wrong with Windows Server?

[lister king of smeg]

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 debugging the use a binary format.
They now can't throw out all of there brokenness like rule 3 says because they didn't fallow the other rules, because sytemD is also cron and also a volume manager, network manager, handles disc encryption, handles power management... throwing it out means instead of having to replace/fix one small broken util they have to redo everything.

Then there is the developer community from SystemD that blames all there bugs of others or just tell people to get over it. It has gotten so bad the Linus Torvalds has had to ban code from Pottering the head Dev of SystemD because it keeps breaking shit. There is nothing good coming of SystemD.

Re: What's wrong with Windows Server?

[julesh]

I'm afaid it is _exactly_ how X works. The X "server" needs to reside on your local host to see remote X applications displayed locally.

The X 'server' does not need to reside on the remote machine, but the components for X are so interwoven on most remote host environments that it's quite risky to pick and choose components.

Right. Local machine is the admin's desktop, running the X server, and the remote machine is the network server, running the X clients. I don't see the problem with this setup. It doesn't leave the server running X, and there's no security implications because you need to be able to connect to the server via ssh to get anything to work.

Re:What's wrong with Windows Server?

[Endymion]

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 ago with DJB's daemontools)

Re:What's wrong with Windows Server?

[sjames]

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:What's wrong with Windows Server?

[sjames]

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?

[NerveGas]

Reboot for Windows updates. Yay.

Re:What's wrong with Windows Server?

[sjames]

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:What's wrong with Windows Server?

[sjames]

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?

[rl117]

Or in the case of init, we could call it "startpar" and allow the init scripts to start in parallel based upon the LSB dependency information. We already had this parallel startup with sysvinit for years in SuSE and Debian.

Re:What's wrong with Windows Server?

[Prune]

What's wrong with services.msc on a Windows Server machine? Any serious answers from people who actually used it?

Nothing, they're just different. And having written both Windows services and systemd ones, I don't get the impression that systemd somehow reinvents what Windows is doing, unless something as generic as "not using init scripts" is equivalent to reinventing Windows (hint: it's not, and TFA is flamebait).

Re:What's wrong with Windows Server?

[Barsteward]

i hope you've reported the bug....

Re:What's wrong with Windows Server?

[jaminJay]

If you background the cp process like I'm now imagining we're suggesting systemd does, then I follow, otherwise you're describing expected behaviour.

Re:What's wrong with Windows Server?

[DrXym]

On Windows services.msc is the snap-in GUI for services. It's the thing that tells you what is running, has options to stop / start them and property sheet to see what user they're run as and what they depend on. It's not a pretty GUI but it does its job. The biggest issue with Windows services is there are too damned many of them. I think Microsoft should implement some kind of higher level grouping so that it's easier to figure out what can be safely turned off. Another tangential peeve is MMC isn't hi-dpi aware which means all the snap-ins are blurry on my laptop.

I don't see that it has much bearing to systemd or init beyond implementing the same basic concept of having system processes that can be started and stopped (and a manual or automatic method of ordering their launch). Unix daemon monitoring GUIs have had start/stop buttons and status for the fundamental reason that Windows does.

Re:What's wrong with Windows Server?

[serviscope_minor]

That still requires a metric assload of libraries to be installed on the server.

I checked on my machine. The agregate size of libX* excluding Xm and Xaw in /usr/lib is 3.5M. Add in a widget toolkit like fltk and you get another 1.2M. 4.7M is hardly a metric assload.

Re: What's wrong with Windows Server?

[goarilla]

And what if the binary logs are corrupted and journalctl breaks on it ?
To be fair we have a few other "binary" logs: wtmp(x), btmp(x), utmp(x).

Re:What's wrong with Windows Server?

[GenomeX]

*upvote*
Yes. Exactly. All of the above and especially; the UNIX philosophy is the way it is for a reason.

Re:What's wrong with Windows Server?

[sjames]

But most of the tools are using GTK and gnome as well. Especially if it's a project from freedesktop. They certailny won't be using fltk.

Of course, if you think you might ever have to work on it from a crashcart (for example, if you want to see why networking isn't coming up), you'll need X too. That will also apply if you want to do it remotely and use a KVM through IPMI if you can get it to actually work. Serial over lan through the BMC is a much better bet but that's text only (curses at best).

Re: What's wrong with Windows Server?

[jeremyp]

Heartbleed could expose server side private keys to the attacker. I seriously doubt that any IE bug could possibly be that bad.

Re:What's wrong with Windows Server?

[Anonymous Coward]

"Maybe you haven't heard of the X Window System, introduced over 25 years ago. It allows you to run graphical applications remotely, so the system with the application does not need a GUI at all."

Don't worry, the same thought processes that results in systemd is trying to remove this capability.

Re:What's wrong with Windows Server?

[marcello_dl]

I too would be wary of whatever comes out the likes of the pulseaudio guy, but this is an ad hominem. Systemd has already many questionable aspects without having to bring in Lennart's previous artwork.

As of now, knoppix works on all my hardware, boots as fast as systemd distro (if not faster), so I plan to wait 'till systemd does the damage it was designed for (I know, others call it "innovation", by the fruit...), before NOT switching to it :)

Re: What's wrong with Windows Server?

[jeremyp]

No it doesn't. You need the X client libraries installed, but no X server needs to run on the server.

Re: What's wrong with Windows Server?

[jeremyp]

The X server runs on your client PC.

That's how X works.

Re:What's wrong with Windows Server?

[jeremyp]

How do you propose getting an ssh connection to fix the issue with the CLI equivalent?

Re:What's wrong with Windows Server?

[RabidReindeer]

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 that that's what actually happened.

However, the one thing you should absolutely positively NEVER do is replace a major product with one that lacks critical commonly-used functions of the original product, and that's the fatal problem with not only systemd, but Gnome 3, and some would argue various versions of Nautilus.

And when developers ignore the angry mobs, tell them that they're unappreciative or stupid, or otherwise incapable of recognizing a Superior Product when they see it doesn't do any good for anyone. If your new shiny toy doesn't cut it, you either need to add those critical functions before shoving the old system off the pier or admit that your design is too flawed to handle it and go back to the drawing board.

I like systemd in concept and am prepared to become a full convert. But only when it restores the essential functions that systemd provided.

However, I totally loathe systemd's partner in crime journalctl and frankly don't see myself ever learning to love it. Too much replacing simple functions with complex commands and too much opacity in the log storage itself.

Re: What's wrong with Windows Server?

[Mashiki]

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:What's wrong with Windows Server?

[Antique Geekmeister]

> 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?

Usualy, you make such changes in /etc/sysconfig/[daemon]. If you need to completely rewrite the daemon init script, you turn off the old script, write a new script with a new name such as 'daemon-ionice', make sure it has a 'Provides: daemon' line, and use that for init options. This is also the common approach if you need to run multiple copies of the same daemon, running on alternative configurations, such as SSH or Tomcat.

Re:What's wrong with Windows Server?

[jbolden]

Cut the nonsense. The GP pretty specifically asked how he was supposed to read binary logs. Computers don't have problems with binary formats raw, humans do. For that sort of work you don't use a regex you just work directly with the binary. Things are easier not harder.

But even if you did want to translate the binary format into ascii using a computer you just have a journal parser do it. systemd comes with one systemctl and you can use that and ask it to pass you information meeting certain conditions. There is a separate api and the scripting languages are moving towards being able to read the format.

Re:What's wrong with Windows Server?

[jbolden]

He's looking for a replacement to 'tail -f /var/log/messages | grep "something"'

Then just use systemctl and have it read the format. For that matter just write the trigger in systemd and skip the whole issue of reading the logs.

Re:What's wrong with Windows Server?

[marcello_dl]

Next, go to an israeli forum and ask what's wrong with Hitler's EndlÃsung? only serious answers from people who actually enjoyed mein kampf please.

Re: What's wrong with Windows Server?

[Anonymous Coward]

I'd rate these up there

http://en.m.wikipedia.org/wiki/SQL_Slammer
http://en.m.wikipedia.org/wiki/Blaster_(computer_worm)
http://en.m.wikipedia.org/wiki/Code_Red_worm

Re:What's wrong with Windows Server?

[Eunuchswear]

Not just the sound guy, the sound guy that wrote the broken sound framework. Pulseadio is a horrible horrible system.

Sound on Linux was useless before pulseaudio.

Initial pulseaudio was crap.

Now it works.

Re:What's wrong with Windows Server?

[squiggleslash]

We have four attempts to solve the same problem because we keep doing things badly. Script based services management, in my view, isn't a good thing, and it's also not a good thing to have multiple different clusters of service managers, init, inetd, etc.

Let's look at the status quo that many systemd rioters want to keep: service management scripts generally have to track at least one process, and frequently clusters of them, and usually as the process gets more and more complex, have to be shored up with additional supporting code in the binaries themselves (think Apache's apachectl and BIND's rndc) obliterating any advantage you might have had in having a "user readable" shell script in the first place. Meta data is stored in the most unlikely places - anywhere from /etc configuration files to "comments" in the init script itself (think runlevels.) The kernel itself keeps advancing, with the wonderful cgroups system providing new and better ways to improve security, but we're stuck with chrooting and setuiding daemons because we leave the security decisions to our cross platform binaries.

I'm not suggesting systemd is perfect (XML FFS?), but I think it's a rational response to what is actually a massive kludge and arguably one of the very few serious mistakes in *ix. Are there proprietary alternatives that are better? Maybe. Their proprietary nature means we haven't been exposed to their potential good points, if any, which is a great argument against proprietary software if you want to influence the world for the better.

Were I to design systemd, it'd probably look slightly different. At the same time, I can't argue:

1. With the need for systemd and the feature set it implements.
2. That the status quo is worth keeping. It isn't.
3. Superficial "This isn't the Unix way" arguments. Kludges are not the Unix way either. This is one area we need a change in.

Finally, you didn't mention it, so not addressing your comment but addressing the other major criticism of systemd: Yes, the developers have social interaction problems. So does Linus, and half a dozen other major "personalities" we've always worked with. Hell, one key developer whose work was on the verge of being adopted by the FOSS world (and was adopted by at least one major distro) even killed his wife. I'll slam FOSS developers for their poor social skills if I think it's deserved, and even suggest in extreme cases that a fork might be desirable, but the code they write is there for the using, and if it's a good idea we use it, we should use it.

In the mean time, let's not let the perfect be the enemy of the good enough. Is something that implements the featureset systemd implements necessary? Yes. Are there any non-proprietary alternative projects that implement the same necessary features? No. Does systemd do anything genuinely terrible that makes it impractical to use or worse than the status quo? No. It's good enough, let's adopt it, and let's make it better.

Re:What's wrong with Windows Server?

[squiggleslash]

I completely disagree with the notion systemd is "How Windows does things", but still, let's suppose that's true: is it really true Windows requires beefier hardware to "do the same job"?

services.exe has been around since Windows NT 3.x. On my Windows 7 64 machine right now it's occupying four megabytes of memory. init, running on a 12.04LTS box, is using six.

I'm going to say I think both are within the same ballpark, which is what you'd expect, both are simply tracking processes (kinda, in the case of init) and stopping/starting them. You really don't need huge amounts of memory or CPU to do that, and it would take a pretty weird algorithm/feature set for any init/services equivalent to start gobbling serious amounts of memory.

Re:What's wrong with Windows Server?

[Rich0]

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.

I keep my /etc in git. My distro also automatically renames modified files in /etc and I have an automated tool that does 3-way merging of changes when new changes come along that handles these updates without any intervention about 90% of the time, and the other 10% of the time it pops up meld for a manual 3-way merge which is usually pretty trivial.

I STILL think systemd does it better.

They say the same thing about excel spreadsheets. Most spreadsheets are still a hideous mess to maintain. I think you just proved the "against" argument.

Your argument is:
1. SystemD uses a declarative programming model.
2. Excel uses a declarative programming model.
3. Excel sucks.
4. Therefore systemd sucks?

The problem with Excel is that it tends to involve a LOT of inter-cell dependencies, which turns it into a rats nest, and "variables" are typically unnamed. Neither of those issues applies to systemd - variables all have meaningful names, and they rarely depend on each other.

I do get that boot order is non-deterministic, and that can make it more complex to deal with. On the other hand, if you have a lot of services I'd probably prefer a dependency-oriented approach to trying to figure out manually what order to load them all in. I haven't used a distro that just numbers all of its init scripts in a decade - it feels like the days of having line numbers in BASIC and hoping you leave enough room in-between them.

Re:What's wrong with Windows Server?

[Rich0]

> 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?

Usualy, you make such changes in /etc/sysconfig/[daemon]. If you need to completely rewrite the daemon init script, you turn off the old script, write a new script with a new name such as 'daemon-ionice', make sure it has a 'Provides: daemon' line, and use that for init options. This is also the common approach if you need to run multiple copies of the same daemon, running on alternative configurations, such as SSH or Tomcat.

So, if you disable the distro-supplied script then it would not meet the criteria "you won't have to manually re-combine your changes with their new init script which adds some new feature yours lacks." I was well-aware of the approach you state when I posted that.

The problem is that traditional sysvinit scripts are just that, scripts - they are turing-complete and in general it isn't easy to blindly merge changes to code without causing issues. Systemd units are just a list of variables and their settings, and each variable just does one thing. That means that you can override a single variable and usually you get predictable and contained behavior. Sure, there are some variables where that isn't as safe, but ionice isn't one of them.

With systemd you can still override the entire script if you want to, but this usually isn't the right way to do things, since it has all the downsides of doing the same thing with sysvinit - you basically forked the script off of your distro and you don't benefit from later work done by your distro.

Re:What's wrong with Windows Server?

[sjames]

Does systemctl have a -f mode? That is, it outputs anything appended to the file as it happens?

Re:What's wrong with Windows Server?

[sjames]

Only init itself has to run as pid1. Everything else that systemd does including startup could be done when called by init.

Re:What's wrong with Windows Server?

[sjames]

You should submit a patch. I'm sure the systemd guys will love it.

Re:What's wrong with Windows Server?

[drinkypoo]

Maybe the primary reason they made systemd is because they thought init scripts were too complicated?

Well, they were wrong. Init scripts are gloriously simple compared to systemd.

Re:What's wrong with Windows Server?

[Megol]

So sad that almost everything actually running on Unix systems doesn't follow that philosophy... From the kernel up.

In fact one could argue (yes this is far fetched but bear with me) that Windows follows the philosophy closer via the component based design used in many subsystems - but that is of course stretching it quite a bit.

Re:What's wrong with Windows Server?

[bmajik]

Nothing.

One critical difference: services.msc isn't actually responsible for orchestrating system startup on windows.

Services.msc is an administrative tool meant for interactive use. It is one of several administrative surfaces for interacting with windows service configuration. The commandline tool "sc" still exists and is still functional, and powershell undoubtedly has a more robust suite of tools for manipulating system startup.

The actual inner plumbing of starting up a windows machine is in some way abstracted from the management surfaces used. For instance, during the Windows XP era, a bunch of work was done on making bootup faster. Part of that work was done by allowing some parts of system startup to happen in parallel that were previously serial.

In versions of windows since XP, other subtle changes have been made to windows startup behavior to positively impact performance. The measure people most care about is how long until you can see your desktop, so some startup services have been moved into Deferred groups if they aren't implicated in giving you a login desktop.

All of these changes have been possible without critically altering the different management surfaces that exist for windows administrators. Service dependency chains, run levels, etc have been in the NT family since early days.

New features show up in these experiences over time; e.g. once upon a time every single service ran as the SYSTEM credential; now there are lots of pre-built discrete identities with different rights to effect some degree of privsep. But these were new values showing up on combo boxes in the existing tooling; not throwing away everything you knew and asking you to start over with something entirely foreign.

One key difference between Windows and rc/sysV is that the latter makes it much easier to promote a random shell script into something the unix startup orchestration knows about.

Windows services have a richer interface contract (start, stop, query status, etc) that is based on C-style calling conventions (iirc). Implementing something as a windows service as a practical matter requires knowing that's what you want it to be before you start coding.

The downside of the unix flexibility is that people ship broken ass shit like Ubuntu LTS where half your stuff is reasonable and half your stuff tells you, "hey, i'm an upstart job! So what you tried won't work any more for some reason that has no fucking bearing on your life! fuck you buddy!"

I got my start on linux in the a.out binary days, and simultaneously worked on Solaris and IRIX machines about 20 years ago. I've added other unicies since then. I'm very comfortable with both rc and sysV. Recent follow-ons like "upstart" have jut felt like hacky shit to me that unceremoniously throws out what met my needs and provides a fundamentally worse experience.

I spent a great deal of time debugging OSX startup a while back (http://blogs.msdn.com/b/mattev/archive/2004/06/21/161770.aspx) and that system was at least sensical and consistently implemented.

If you want the real deal on windows internals, the Windows Internals Books with Mark Russinovich are excellent, and explain the internal kernel concepts and data structures in tremendous detail. System startup is also covered, including the orchestration between smss.exe, lsass.exe, csrss.exe, and all other associated friends.

Re:What's wrong with Windows Server?

[nabsltd]

Maybe you haven't heard of the X Window System, introduced over 25 years ago. It allows you to run graphical applications remotely, so the system with the application does not need a GUI at all.

Except that the system with the application still needs 273* extra packages installed to allow it to run X client applications.

That's 273 extra code bases that need to be secured to keep the server safe.

* Although not the actual number, it's not far from the truth.

Re:What's wrong with Windows Server?

[sjames]

So you're saying the non-smartass actually helpful answer is 'yes'?

Re:What's wrong with Windows Server?

[jbolden]

Yes, the AC is right. But more importantly the reason you do that sort of thing is to create a trigger. systemd is designed to automatically trigger.

Re: What's wrong with Windows Server?

[Parker Lewis]

Oh, come on... several IE bugs allow remote access on the machine. I'm not saying that Heartbleed is not that bad, just saying your comparison is bad.

Re:What's wrong with Windows Server?

[nabsltd]

A reasonable dependency system would define exactly what "available" means and have the manager (systemd) run code from the definition that is a test for the required condition.

An example would be to connect to a MySQL database and see if you get a response. A better test would be a user-defined query that should return a known value.

Re:What's wrong with Windows Server?

[devman]

You can install syslog on a system that uses systemd if you really want text logs. I'm not familiar with journald myself but I've heard there are 'follow' commands for the log file. https://wiki.archlinux.org/ind...

Re:What's wrong with Windows Server?

[nabsltd]

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.

In sendmail.service:
After=clamd.service

This still doesn't fix the problem I had, which was that the clamd socket wasn't accepting connections when sendmail actually started, so sendmail failed.

Also, you can't edit sendmail.service and have the changes stick, as it is located at /usr/lib/systemd/system/sendmail.service and will be overwritten the next time sendmail is updated. I know there is a poorly documented mechanism for overriding the built-in version of a *.service file, but could never figure out how it really works. OTOH, editing /etc/init.d/sendmail works really well and isn't overwritten by a package update, because packagers know files in /etc/init.d are often changed.

Re:What's wrong with Windows Server?

[aethelrick]

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, SystemD works OK, it does what it promises and for my limited use cases it is fine

I found it unintuitive for an admin used to using System V init

I read more about it and the authors claim that they provide many small programs that each do one thing well, they however have improved the integration between these, they seem to have admirable goals, I'm not convinced one way or the other about their implementations. What can I say, nothing has crashed so far for me, but I'm not sure I like the idea of one team trying to supplant quite so many binaries with their own versions.

I'm not sure I notice a whole hell of a lot of difference for my headless server, except the new network card naming stumped me at first. It boots, it runs and it does what it is supposed to. As for "EVERYTHING" being loaded into PID 1 this does not seem to be the case on my machine, I see different processes for the different apps that came with SystemD only the /sbin/init process is on PID 1, things like journal and dbus and logind are all running on other processes.

Personally, while I understand the concerns many have when others mess with our beloved Linux, I don't have any evidence from my own experience that things are in any way more bloated or insecure as is being claimed here. What I do know is that most distros are providing support for SystemD and a lot seem to be using it as the default now or in their next version. It looks like I'll have to learn it one way or the other so it may as well be now.

I remain confident that if in time we (the Linux community) find out that SystemD is utter crap for whatever reason, then we'll either improve it, rewrite it or move to something else entirely, such is the way of open source.

Re: What's wrong with Windows Server?

[psmears]

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:What's wrong with Windows Server?

[Rich0]

The problem is that volunteer effort isn't fungible. You can't force people to invest in something that exists instead of creating something new, and much of the progress in the FOSS world actually comes from reinventing the wheel. This is less of a problem for non-volunteer-dominated projects, since they can just pay people to work on something boring.

OpenRC has its own limitations as well.

Systemd uses a very different approach to solving the problem than the solutions it replaces. That will introduce its own set of limitations, but it also can help it to surmount fundamental limitations that aren't easily handled by other solutions.

Re:What's wrong with Windows Server?

[Wrath0fb0b]

Which is why clamd should provide a systemd.socket, unit in which case the init system installs the sockets and then hands them off to the spawned process as soon as the respective daemon is to be started.

It's just as easy to to do this in systemd as it is to bung together shell that does it, but it's not as familiar. In a few years, most system admins will be able to mash out a systemd.socket unit in their sleep.

Re:What's wrong with Windows Server?

[Rich0]

you mean journalctl -f | grep?

Re:What's wrong with Windows Server?

[Rich0]

I agree with your point, but a problem is that many units use the simple model. That means that systemd considers launching the daemon to be a success, even if it terminates with an error 1ms later. There isn't a simple solution to this with any init system - if the daemon doesn't fork then there is no way to know how long to wait to see if it is going to stay alive.

If you use the forking model and the process doesn't fork, or if you use one of the more sophisticated models then systemd can capture errors in launching a daemon.

I suspect that these sorts of problems will take care of themselves as systemd becomes more common and upstream projects start integrating with it. Forking isn't actually the cleanest solution either - it is much better to just have the process check in when all sockets are ready to use.

Re:What's wrong with Windows Server?

[Anonymous Coward]

Dog poop doesn't make a good fertilizer. That is generally true for carnivores.

Re:What's wrong with Windows Server?

[sjames]

Now the real question is can I then remove journald since I have no use for it?

Re:What's wrong with Windows Server?

[sjames]

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?

[sjames]

A trigger for what? Perhaps I'm just watching the console.

Re: What's wrong with Windows Server?

[jbmartin6]

It is a question of scope. An IE bug may or may not affect a million users, just to pick a number. Many of those run firefox or chrome. And each one needs to be exploited individually, through various mechanisms (bogus email, fake website/search poison, etc.) which have a low overall success rate. Compare this to Heartbleed, which could impact the same million users at a single point with a single operation.

Re: What's wrong with Windows Server?

[jbmartin6]

You forgot to mention, you will only run something else if the flaws in the original cost you more than the costs of switching to the alternative. Assuming the alternative can be proven to not have equivalent flaws. In most cases, this means people stay with the original and put up with the flaws.

Re:What's wrong with Windows Server?

[jbolden]

Mostly the reason you tail is to take action X if Y happens. That's precisely what systemd is designed to do. So 95% of the reason watch logs just get absorbed. But if you just want to see whatever junk happens in time sequence journalctl does it.

Re:What's wrong with Windows Server?

[ButchDeLoria]

Say hello to Wayland, X's replacement with no graphical forwarding.

Re:What's wrong with Windows Server?

[sjames]

Alas, it appears they are drinking the cool-aid. They USED to use only the init scripts, log only to syslog, and in-general paper over it every way they could so you don't have to notice it.

Re: What's wrong with Windows Server?

[dylan_-]

I'm afaid it is _exactly_ how X works. The X "server" needs to reside on your local host to see remote X applications displayed locally.

The AC thought you needed the X Server installed on the remote machine and considered it a security risk. That is exactly how it does *not* work. As you have just stated: the X Server runs on the local machine, not the remote server.

I know it's a little confusing referring to the 'server' and the 'X Server' as two separate entities, but I'd hoped my example - specifically stating which machine didn't have the X Server installed - would make it clear enough?

Re:What's wrong with Windows Server?

[drinkypoo]

If you want to know the real reason all the major distro's love systemd it is the manpower savings they get on not having to maintain and tailor initscripts.

Seriously? Because frankly, they are just not that complicated. I'm actually pretty surprised that nobody has yet come up with an init script processor that isn't a shell, because most scripts boil down to a small handful of functions, especially given that most of the options are now in /etc/default. I haven't looked at a unit file yet (reading) It appears there's really no reason why you couldn't hashbang a simple processor at the top of your unit file that would source /etc/default/$0 if present, then source the unit file so you get expansions from your config file, and finally run a standard init stub that would use the resulting variables to start, stop, etc your service. That processor can, again, be a simple shell script. So why, again, do we need systemd to handle this problem?

Re:What's wrong with Windows Server?

[Dr_Barnowl]

You need tools that futz with low-level stuff and insert hooks into the process, like procexp.

Having to use tools that do things that you'd ordinarily associate with rootkits isn't really a good answer.

And svchost.exe can host the DLLs for multiple services at once... you can't kill the process without killing all of them. A terrible design, compensating for the heavyweight nature of Windows processes.

Re:What's wrong with Windows Server?

[sjames]

Surely for the sake of realism, the latter should be: journalctl -fu sendmail

Re:What's wrong with Windows Server?

[meta-monkey]

Bravo. You said it perfectly.

I personally don't have a problem with SystemD. It annoyed me the first time I installed a distro I didn't realize used it (Fedora...14 maybe?) and I had to spend a few hours reading docs to figure out a whole new way of doing the same shit I'd been doing without thinking for 15 years. The software itself is fine, it makes sense to me now, and I don't mind using it. But I do hate this attitude that SystemD IS THE FUTURE AND MUST BE USED.

Re: What's wrong with Windows Server?

[psmears]

yes, it's called FreeBSD, or any of the BSDs. Top notch documentation, and sane userland.

... and is a suitable replacement for every piece of software ever? Wow!

Re: What's wrong with Windows Server?

[TangoMargarine]

code rot

Re:What's wrong with Windows Server?

[Espectr0]

I agree with some of the criticism regarding systemd, but reading logs is not one of them. Just learn the systemctl and journalctl syntax before you ask silly questions regarding reading logs.

Also, read http://0pointer.de/blog/projec...

Re: What's wrong with Windows Server?

[Anonymous Coward]

Good post. Just one thing, there is no XML in systemd. It uses ini files.

Re:What's wrong with Windows Server?

[fluffynuts]

The biggest issue I have with the Windows service model is that certain services are run in the same shared process, which means that if you want to take one down, they all come tumbling down.
Secondary to that is the flakiness of the install/uninstall process -- I've found it far too easy to get the services subsystem into a dodgy state where a service is scheduled for deletion, but not actually deleted until you restart, even though it's no longer running or in use. Which means that you can't re-install a newer version of the service until you reboot because your new version shares the same name.
Tertiary to that is the fun and games that you have to endure to be able to run an application as a service but also run it once-off for debugging / development. Hence the birth of projects like this: http://www.nuget.org/packages/... (full disclosure: I wrote it and (a) I'm sure it's not a unique solution and (b) there are probably better ways of doing it but (c) I found I needed to do this far too often). Much of this hinges around how messages (start/stop/pause/resume etc) are sent to the service -- and these are also (IMO) far less elegant than *nix signals. It's also this architecture which makes a flaky service gain the ability to cause havoc with your system by not responding to requests properly, etc.
In addition, programming a service for install / uninstall is a mission in and of itself -- even the "standardised" .net way is well unintuitive. Again, this is solved in my shell, using http://www.nuget.org/packages/... (again, full disclosure, written by me), but basically involves telling the system where to find entry points in your service code; in other words, forget the standard main(), there are other entry points that the Windows service system uses. Coming from another platform, you'd expect services to be easier to write -- they're just regular, daemonized processes launched from an init script (which you can find a template for easily enough).

All of that doesn't mean that I could have done better or that it's absolute shit. It's just that it takes time to figure this stuff out -- many burned fingers before you start getting it right. And I still get the feeling (oodles of services later) that I'm missing something. Because I probably am.

I sincerely hope that systemd doesn't foist this same mess on us. I haven't investigated it enough to know much about it, but the facts that I have read (primarily who the dev team are and my experience with their prior fuckups and most especially how they like to shift blame after royally fisting someone else but also how they don't give two shits about user problems or reinventing stuff that didn't need reinventing) don't give me that warm fuzzy feeling.
PulseAudio is a great example: pretends (poorly) to be ALSA and then the devs blame userland software when audio gets choppy (even when audio wasn't choppy on ALSA). It also poorly implements features like simultaneous output to multiple physical devices and devs don't take bug reports on that shit -- I tried and was shut down for using a feature I apparently wasn't supposed to be using (ie, simultaneous output). They'd rather leave broken shit in place than fix or remove it.

Re:What's wrong with Windows Server?

[lister king of smeg]

Not just the sound guy, the sound guy that wrote the broken sound framework. Pulseadio is a horrible horrible system.

Sound on Linux was useless before pulseaudio.

Initial pulseaudio was crap.

Now it works.

Tell that to my laptop where it used to (before I replaced it with alsa) crap out when things like head phones were unplugged, or where I would have to go kill the pulse audio’s daemon every few hours because it decided to just start garbling sound for no reason.

Re:What's wrong with Windows Server?

[Uncle Warthog]

I would add that the main problem they seem to be solving is slow bootup times, which are slow because you can't run startup processes in parallel. .

That was the original reason for systemd before they decided to start the feature bloat. The fact though is that you can run startup processes in parallel and could without systemd. SUSE linux was able to do this and did a good job of it long before they switched to systemd while still using standard init scripts. On my system, the switch from that to systemd actually _slowed_ my boot process by about 10% because systemd insists on waiting for things that don't need to be waited for. Through some careful tuning, I've managed to get that slowdown to about 4-5% but it's still slower than the old parallel-run init scripts were.

Re:What's wrong with Windows Server?

[Endymion]

Ahh, and here comes the shill, with the usual personal attacks and strawmen. Yes, go ahead and praise Poettering's cult of personality and ignore the many people in this very thread who rebutted the nonsense that there was a need to replace "init scripts". By focusing on that point alone you get to pretend that systemd is "just an in init system", and hasn't embraced and extended a long list of other tools.

Evidence? LOL. More evidence that you are either lying to push propaganda, or shockingly ignorant of what Poettering himself has said about the state and future of systemd. Or do you not consider the creator and manager of systemd to be a reliable source? Do you want to still pretend this issue is about "just an init system"? Because that would essentially be calling Poettering a liar.

I'm sure you won't bother properly understanding this... at least in public. Obviously, the goal is to simply bully the people who disagree with you. Sorry, no, we aren't going to simply shut up, and stop pointing out how Linux worked just fine, despite your unsubstantiated assertions.

You want a suggestion on how to fix things? Stop breaking everybody else's code! Any minor problem that sysvinit had has been vastly overshadowed by the breakage systemd has caused.

Re:What's wrong with Windows Server?

[ustolemyname]

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.

No, he said there exists N such that managing > N linux servers is easier than managing > N windows servers. Then he went on to compare them in single server environments, and discussed why windows is often used in small businesses as their only server.

As to installing proprietary software: honestly, my experience says that this tends to suck equally on all platforms. Had to maintain a small CS2 deployment years back, standard operating procedure when it fucked up was to reinstall the OS. I've never had to resort to such levels to clean reinstall proprietary software on linux, but I've also had difficulties with some proprietary software on Linux. I really think that tends to be a quality of the vendor thing more so than the underlying OS.

Re:What's wrong with Windows Server?

[Virtucon]

Well you bring up a lot of good points but unfortunately for the past 20 or so years some of these features are less differentiating than we had hoped. It's all driven by the software that runs on top of all of this, not the underlying operating system and its features. Solaris for example has outstanding features but its been languishing while Microsoft still keeps plugging away and Windows Server. Don't get me wrong, I still love Solaris but my customers care about lowest cost platform that delivers the service they need and whether or not their developers have some sort of holy alliance to a particular operating system. That drives what gets installed more than what the sysadmins want.

Re:What's wrong with Windows Server?

[Mr_Wisenheimer]

I don't really blame the vendor for Linux programs being difficult to install.

Windows and MacOS have a centralized installation routine that vendors can use and they have only minor variations across builds.

The installation routines for Linux are fragmented across distributions and there is no single Linux-wide installation routine. Most vendors have to create their own scripts to install software and, even if they extensively test the script on all the major distributions, are likely to run into problems with future releases of those same distributions.

I know a lot of researchers, many of them older people who cut their teeth on UNIX in the 70's-90's, most of whom would never bother with Linux because it takes so much administration time and it can be extremely difficult to install commercial software.

Most of them have switched to OSX, even though some of the packages they use require compiling and tweaking, simply because the overall administration time and learning curve of Linux (not to mention the simple fact that many industry standard commercial programs have OSX versions but no Linux version). Outside of servers, the usage of Linux among researchers has dropped precipitously. Most have switched to OSX.

Re: What's wrong with Windows Server?

[stoatwblr]

"While the potential is there, we have not seen anything as bad as the OpenSSL bug"

The X auth bug was pretty bad and that was only found recently.

Re:What's wrong with Windows Server?

[david_thornley]

Do Windows and Mac OSX have a single distribution management system, or are there two of them, one for Windows and one for OSX? It would be interesting, given that the commercial software available for each of those is different.

And, in a managed environment, why would Linux be fragmented? A business can require the use of certain distros just as easily as it can require the use of Windows.

Re:What's wrong with Windows Server?

[Mr_Wisenheimer]

Obviously Windows and OSX have their own installation services.

Linux is not going to be fragmented on managed computers (unless the system administrator allows it), but it is fragmented across all distributions, which means that a commercial software developer faces a daunting challenge in getting his program to install and run correctly on all current and future installation of Linux.

There have only been four new major releases of Windows since Windows 2000 was released and after the big upgrade to the codebase made in Vista, Microsoft was careful to include the ability to run and install software in legacy mode. Heck, if you had the 32 bit version of Windows, you could still run most 16 bit DOS programs from back in the 1980's.

Look at Ubuntu alone and how many major new revisions it gets. Look at how many desktop managers it has. It can be a nightmare just to make the installation routine of one program compatible with all major past and future installations of Ubuntu, much less all of Debian, much less all of the other distros out there.

Linux's greatest strength (it's diversity and ease of modification) is also its greatest weakness.

Re: What's wrong with Windows Server?

[fluffynuts]

And I'm not trying to spew vitriol about Windows or services in that platform, though I'm sure you might expect that here and I might even have appeared to be doing just that (: I was just answering your question (:
I've come to understand that all tools have their rough edges. I make my living from writing software for the Windows stack and most likely will continue to do so for many years to come.

Re: What's wrong with Windows Server?

[Virtucon]

No, there's things I like about Windows and hate about it. Just like Solaris has it's quirks but more often than not the software solution drives the platform, not the other way round.

Re: What's wrong with Windows Server?

[squiggleslash]

You appear to be correct, I'm not sure where I got it from that systemd uses XML...

Re: What's wrong with Windows Server?

[exomondo]

Maybe you should make sure you read and understand what you're linking to before you post.

"Software rot, also known as code rot, bit rot, software erosion, software decay or software entropy describes the perceived "rot" which is either a slow deterioration of software performance over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or otherwise called "legacy" and in need of upgrade. This is not a physical phenomenon: the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides."

As in it is nothing to do with the software itself but the system and environment in which it is run, changing the software won't change the system it runs on.

Re: What's wrong with Windows Server?

[exomondo]

No. It degrades over time for entirely different reasons. But it *does* degrade over time.

No, it doesn't degrade, it stays the same. If you change the environment or system it runs on that is a different story.

Were it open source, I doubt this would have happened.

There are plenty of open source products that are platform dependent, even the most popular ones like Android and Java. Open source has its advantages but it can't magically make software do anything and run anywhere, that requires a *lot* of effort and even the most popular and widely used ones struggle with it. Conceivably you could do it but in most cases it is prohibitively expensive.

Out of interest, what are some of these software packages that you used to use but now can not?

Re:What's wrong with Windows Server?

[Lotana]

Very true. I have encountered similar situation many times. No idea why you are modded to -1.

However the scenario is a failure of the initial admin not the software. Quite often they are young, inexperienced, "Open source is the best for everything" junior who is often a friend or a relative of someone in the company. This is because those small businesses are trying to save money on the IT and so they don't want to spend money on a professional consultant. Some inexperienced kid will make just as much of a unmaintainable mess with Windows servers.

  A properly setup system with documentation and training for the user will work just fine regardless of what OS is in use.

Re:What's wrong with Windows Server?

[RockHammer]

I'm not sure if this meets your expectation, but a test can be accomplished using the option ExecStartPost. This method is being used in the current Fedora package for MariaDB to test for active database using an additional script called mariadb-wait-ready.

ExecStartPre=, ExecStartPost=
Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially.

If any of those commands (not prefixed with "-") fail, the rest are not executed and the unit is considered failed.

systemd.service

mariadb-wait-ready described as:

# This script waits for mysqld to be ready to accept connections
# (which can be many seconds or even minutes after launch, if there's
# a lot of crash-recovery work to do).
# Running this as ExecStartPost is useful so that services declared as
# "After mysqld" won't be started until the database is really ready.

The mariadb-wait-ready script uses the following command:

/usr/bin/mysqladmin --no-defaults --socket="$socketfile" --user=UNKNOWN_MYSQL_USER ping

Re: What's wrong with Windows Server?

[CaptnZilog]

No it doesn't. You need the X client libraries installed, but no X server needs to run on the server.

Correct. The X-server is effectively the "display side" of the equation - you'd run it on your desktop/laptop to connect to the 'client' (your Linux/Unix server).

Nobody in their right mind really wants to be running an X-*server* on their actual Linux/Unix server - usually the server doesn't even have a real display on it anyways (and it's been years since I've really looked, but all the datacentrer-type KVM stuff I've seen sucked at even handling 1024x768 for 100's of servers - although my 8-port KVM on my desk works ok for the 4 boxes I have hooked up to it - but monitor/cables/pc's are all within 8 feet of each other).

Re:What's wrong with Windows Server?

[AntiSol]

systemd is written by the pulseaudio guy?!?

I totally didn't care about this debate until I read that, now I just want systemd away from me. eew!

Pulseaudio is indeed a really terribly horribly bad system. My favourite thing about pulseaudio is that even when you have a multichannel audio card capable of playing more than one sound simultaneously (i.e a good pro-audio card, or any 15 year old creative labs card), pulseaudio still does the mixing in software, because using my CPU to do something not-quite-as-well as the purpose-built hardware I have in my machine is a great idea. Another excellent feature of pulseaudio is the network transparency, because I love clogging up my LAN with uncompressed audio data, and jack didn't already do a better job of it.

Granted, it has gotten better - at least it works now, most of the time. 3 years ago it was the number 1 reason for me to reboot my system.

Based on my pulseaudio experience I don't want to be using systemd until at least 2030.

Re:What's wrong with Windows Server?

[phantomfive]

That's so depressing.

Re:What's wrong with Windows Server?

[Bigon]

Euh, are you aware that clamav-daemon can be socket activated (at least on debian) and that if any program is trying at access the socket will automatically start the daemon. Therea are a lot of other daemon that can be socket activated (syslog-ng, pcscd,...) that then requires (in most of the cases) no explicit dependencies and will only be started on demand. Also, systemd actually includes a lot of mechanism to know about the readiness of a service (see: http://www.freedesktop.org/sof...) and the different states are way more fine grained that what LSB initscripts could provide. It also has knowledge of the different mountpoint on the system (.mount unit files) and they can be used as dependencies.

Re:What's wrong with Windows Server?

[Finite9]

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.

Shame you chose Oracle as your example because it's actually much quicker to install on Windows than Linux/UNIX because you have to faff about creating users/groups and setting kernel parameters and checking you've got all the correct dependency versions. Oracle Linux makes it easier by providing a meta package, but RedHat it's all manual. But your point was still bang on the money. --speaking as an Oracle DBA

Re: What's wrong with Windows Server?

[julesh]

No, it doesn't degrade, it stays the same. If you change the environment or system it runs on that is a different story.

In any realistic deployment of computer systems, the environment changes. There is practically nothing that can be done to prevent this.

There are plenty of open source products that are platform dependent

Sure there are. But how many open source platforms are there that cannot be used with modern hardware, or cannot be used at all due to widespread security vulnerabilities or bugs that haven't been patched?

Out of interest, what are some of these software packages that you used to use but now can not?

Ones that spring to mind: Borland Pascal 7. The drivers for several pieces of hardware that I used to use. An administration program for a router that depends on an obsolete and insecure version of Java and will not run with more recent ones. There are more, but most of them are so long ago I no longer recall exactly what they were.

Re: What's wrong with Windows Server?

[TangoMargarine]

Okay, yes, it's the degradation of the experience as a whole, not the actual program itself. The spark plug analogy is a bit off...it'd be more like transplanting the engine from one car into another and just kind of hooking up all the tubes and wires and hoping for the best.

As in it is nothing to do with the software itself but the system and environment in which it is run, changing the software won't change the system it runs on.

But updating the software to accommodate system changes will get it working again (probably).

Or you could just stay on the same OS forever (the life of the software), I suppose.

Re: What's wrong with Windows Server?

[Lonewolf666]

No. It degrades over time for entirely different reasons. But it *does* degrade over time.

No, it doesn't degrade, it stays the same. If you change the environment or system it runs on that is a different story.

And that is what happens to most environments, even if the user does not desire it.
Sometimes because the vendor of a (software) part of the environment stops supporting it and the need for support dictates going along with the switch.
Sometimes because hardware becomes obsolete and disappears from the market. Then you can't get replacement parts for your existing machines anymore and eventually they will "die out" from defects. Switching to a different system becomes a necessity.

Recent example:
End of life for Windows XP, users move to Vista / Windows 7 / Windows 8 because using unpatched XP on the internet is considered a bad idea.
Some sloppy programming practices using the installation folder as data storage don't work anymore, because Microsoft has added "virtualization" (hidden redirection to the user profile, Vista and Windows 7) or put a UAC dialog before write access (Windows 8 IIRC). Sloppily programmed software works no longer as it used to. Granted, those programs were bad ones to start with but here is your case of "indirect degradation".

Re: What's wrong with Windows Server?

[exomondo]

In any realistic deployment of computer systems, the environment changes. There is practically nothing that can be done to prevent this.

If you do make a breaking change you can replicate the environment virtually.

Sure there are. But how many open source platforms are there that cannot be used with modern hardware, or cannot be used at all due to widespread security vulnerabilities or bugs that haven't been patched?

Maemo/Meego, webOS, etc ... it's only the popular ones that do and it is prohibitively expensive to convert older ones. There are many older versions of the Linux kernel with security vulnerabilities such that you have to use newer versions just like there are with Windows.

Ones that spring to mind: Borland Pascal 7. The drivers for several pieces of hardware that I used to use. An administration program for a router that depends on an obsolete and insecure version of Java and will not run with more recent ones.

Of course but you make it sound as though open source somehow does all this porting for you magically or that it's just a recompile away, that is not reality. Open source is great and has a lot of advantages but it is not to be sold on the promise that it is a silver bullet and a cure-all.

Re: What's wrong with Windows Server?

[exomondo]

Most people do update their software, whether they pay a vendor to do it (and that may be open or closed source) or they spend time doing it themselves.

Re: What's wrong with Windows Server?

[exomondo]

But you always have options, whether that is virtual environments or updating software to the latest version. I know the defeatist attitude is popular when it comes to evangelizing one ideology over another (closed vs open, restrictive vs permissive) but you know there are ways around almost every obstacle, that's what creative thinkers do and in the absence of open source software ruling the world I'd rather look for solutions rather than throw my hands up and cry that it's hopeless.

Re:What's wrong with Windows Server?

[jwhitener]

They were only talking about servers as far as I can tell. The desktop is a completely different story.

Re:What's wrong with Windows Server?

[jwhitener]

All systemd logging can be forwarded to syslog for plain text format if you'd rather not learn about the new ways to read/parse/search the binary log files.

Re: What's wrong with Windows Server?

[tendrousbeastie]

It is though in part an issue of reputation - nobody claims that IE6 + 7 and older were secure; even Microsoft accepts that they are insecure.

But OpenSSL gets/got an implicit guarantee of security from its OSS nature.

Everyone knew IE6 was awful at security. People just trusted that OpenSSL was OK because of the OSS argument.

"Many eyes make all bugs shallow" is true, but relies on there being many eyes looking our for all of the bugs (not just those in the most obvious of systems).

Too late, we already bailed.

[jerpyro]

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.

[Zocalo]

Likewise. In the process of migrating a considerable proportion of a large RHEL estate over to BSD here. A general lack of satisfaction with RHEL6 started our look at alternatives - including other Linux distros - but SystemD was our deciding factor in the making the slightly more drastic leap from Linux to BSD. Despite the dream of Linux on the Desktop, most of us are actually running Linux on servers with (hopefully) competent personnel, so we don't really need some cuddly desktop OS that needs to pander to the lowest level of luser or the additional cruft and abstraction layers that brings, let alone the mess of package dependencies that seems to be afflicting Linux at present. In some cases we're seeing significant perfomance gains for what, in theory, should be the same basic set of code so for us it's more performance for less cost, and possibly an interesting call with our RHEL rep when the first tranche of RHEL licenses come up a renewal we are not going to need...

The King is dead, long live the King!

Re:Too late, we already bailed.

[MikeBabcock]

I'm still installing CentOS 5 on almost all systems right now, I can't believe the mess that systemd causes me in testing...

Re:server admins moving to FreeBSD

[Anonymous Coward]

nope. not evah. no way.

What, your acting like it's dead or something...

The Future!

[elysiuan]

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:

1. Systemd isn't going anywhere. The distros that use it will largely continue to use it.
2. Enough people hate Systemd enough the motivation to create some distros that absolutely do not use it will be very high.
3. Such distros will be created (Maybe use nixos/nix/guix as the base for extra change-it-up-ability.).
4. Much like Mate/Cinnamon vs Gnome 3: people will use both the systemd distros and the systemd-less distros.
5. Much gnashing of teeth will ensue for years to come. A la emacs vs vim, kde vs gnome, gnome 3 vs gnome 2, etc ad nausem

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!

[Lotana]

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:The Future!

[elysiuan]

How many consumers do you know of who give two shits about the OS that runs on their system? They use what comes with the computer. When they buy Steamboxen it'll come with SteamOS and they'll use it as endusers use anything. If you honestly think the vast majority of people are going to weigh the pros and cons of various linux distros AT ALL much less down to the level of detail of their INIT SYSTEMS I honestly don't think we can have much of a conversation.

Some super windows-fied linux systemd based distro would most likely be a net positive for the whole 'linux on the desktop' bugbear. That doesn't mean I shouldn't have the freedom to chose differently for myself however.

Re:The Future!

[silviuc]

Newcomers don't mess around with init systems genius. The debate pro/against systemd is something that power users/sysadmins have, not grandma and cousing Louie.

Re:The Future!

[Kjella]

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.

Re:The Future!

[Skarjak]

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 try things out. This is really not a big deal. Fragmentation is also not an issue for developpers. They claimed it was the reason they wouldn't port games to linux for a while, but then they realised they can just say they're targeting ubuntu and the communities for different distros will figure out what libraries are required. That's what they're doing and it works perfectly. I'm gaming on archlinux. It is officialy supported by exactly 0 developpers out there. Ask me if fragmentation is an issue.

Fragmentation doesn't hurt anyone. The many distros just give power users more choice. It's also in the spirit of open source software. The maitainers for all those distros don't owe anything to anyone. They don't have to tattoo the penguin on their forehead and march in line with the rest of the linux crowd to "advance the cause of linux". They do this because they like it. And they're not hurting anyone.

Re:The Future!

[Austerity Empowers]

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 little). For people getting work done, we need choices, we're willing to suffer a little to avoid suffering a lot.

Re:The Future!

[duke_cheetah2003]

THIS is the reason why Linux will never be a mainstream desktop.

You say that like it's a bad thing... I am content to have linux remain the not so user friendly power user OS it is. I'm not exactly jumping up and down for dumbing things down. Having had my first exposures to Windows 8 recently, I gotta say, it's getting frustrating how Windows is really dumbing things down and burying the fine tuning I'm used to having within easy reach.

So I really don't care if Linux makes it 'mainstream desktop' or not, especially if doing that will involve dumbing it down to Windows level.

Re:The Future!

[Maltheus]

Good! The reason I'm using Linux is precisely because I've seen every one-size-fits-all solution fail. If that's what you're looking for, stick with Windows, Apple or the borg.

Re:The Future!

[dpilot]

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 a support contract, which bean-counters like.

But if Linux were a monoculture which kept me isolated from the nuts-and-bolts, I'd be running something else.

Re:The Future!

[dpilot]

Get your hands off of MY computer!

Please, by all means run a Cathedral OS on your own - it can even use the Linux kernel - I don't mind.

But quit insisting that I do so, too.

Re:The Future!

[Type44Q]

THIS is the reason why Linux will never be a mainstream desktop.

Yep! and I'll add: if human beings don't stop competing with each other, we'll never become the dominant lifeform on the planet...

:p

Re:The Future!

[Grishnakh]

>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.

And did that cause Microsoft to lose their desktop monopoly? Nope. People kept using it anyway, despite the puking. The only thing that's put a dent in MS's desktop market is MacOS, which is basically the same thing (single-source, proprietary) only worse, and the iPad (also single-source and proprietary).

>For people getting work done, we need choices, we're willing to suffer a little to avoid suffering a lot.

Apparently, most people are perfectly happy funneling their money to MS and Apple, because those two have been highly successful with the consumer markets, while Linux has not. Regular consumers do NOT want choices; they want to be told what to do and buy.

Re:The Future!

[Bing Tsher E]

The 'cathederal' being criticised in Raymond's essay was gnu emacs.

It's weird how many people don't seem to know this.

Re:The Future!

[Skarjak]

Meh, reports of ubuntu's death are premature. Lots of people quote distrowatch numbers but they don't really matter. I'd say the average non-nerd who runs linux is probably still using ubuntu. It's still a good distro. If I weren't using a tiling window manager, I'd probably be running unity. Never understood why people don't like it.

Re:The Future!

[dbIII]

I haven't touched Gentoo in ages so don't know how it evolved but it appears to me that the FreeBSD ports collection is the very practical embodiment of what was being aimed at.

We use RedHat at work because it's "Enterprise" and has a support contract, which bean-counters like.

Sadly when you are running commercial software on *nix you have to be running whatever exact platform the vendors like or you get stuck in a first level phone support loop where they will blame your platform for everything - though CentOS is close enough to RHEL so long as there are no actual platform related problems. So it's not just the bean counters.

Re:The Future!

[drinkypoo]

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!

It should be relatively simple to create tools to permit systemd to automagically support normal Unixlike config files.

THIS is the reason why Linux will never be a mainstream desktop.

The truth is that nobody but Ubuntu has ever really tried for the mainstream desktop, and they have serious flaws involving ignoring their users; Microsoft and Apple already fill that niche.

Re:The Future!

[Lotana]

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. 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:The Future!

[Culture20]

Newcomers don't mess around with init systems genius. The debate pro/against systemd is something that power users/sysadmins have, not grandma and cousing Louie.

GP didn't say willfully-ignorant. Newcomers come in all shapes and sizes. The ones newly coming to Linux are usually still power users and sysadmins in the other operating systems they're used to. I remember starting out with Linux. It was weird compared to SunOS, but it wasn't as weird as IRIX. Being new back then meant learning a few oddities and moving on. A decade and a half later, Apple's version of Unix is doing annoyingly convoluted stuff with xml and binary config files, and Linux seems to want to follow into the giggle weeds. Nobody wants to keep it simple any more.

Re:The Future!

[mister_playboy]

3 big issues with Unity as I see it:

Unity was pushed out before it was ready, just like pulseaudio, KDE 4 or Slashdat Beta was. People object to have their personal desktop turned into a dev testing lab. Even when/if the bugs are worked out, the bad first experience colors perceptions permanently.

Unity changed lots of aspects of how Ubuntu worked for no particular reason other than an eye towards touch screen usage. This is the same issue people have with Metro.

Unity's introduction also coincided with the "Amazon lens" feature that sent all local searches to Amazon's servers. This sort of invasive monetization is anathema to Linux users and seem like a blatant money grab by Canonical.

Re:The Future!

[j127]

Much gnashing of teeth will ensue for years to come. A la emacs vs vim, kde vs gnome, gnome 3 vs gnome 2, etc ad nausem

In all those other debates, they were pretty evenly matched with both being sensible options. The only exception in your list is GNOME 3 which was a disaster. I don't know much about it, but this is interesting: http://boycottsystemd.org/

Re:The Future!

[Endymion]

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 "core system".

This fragmentation means systemd is failing at it's own goals.

Re:The Future!

[CptJeanLuc]

It's messy sometimes but so is anything that involves people.

That sentence has the potential to become one of my frequently used quotes going forward, along with "it is what it is".

Re:The Future!

[Anonymous Coward]

Android as a platform is shitty beyond belief. No good Linux people work on it. It's not a good example of things going right.

Re:The Future!

[Eunuchswear]

I doubt it.

The systemd haters are whiners, not doers.

Re:The Future!

[jbolden]

2 comments.

First almost all distributions already go with systemd. Gentoo is the only major holdout and that's harmless since Gentoo is fairly self supporting. Gentoo also doesn't use init they use a very good upgrade called OpenRC. There is no systemd fork going on. I think there are a small group of people who would like a fork but they aren't going to get it.

Second, for the End Use it is fairly easy to imagine what would happen for distributions without systemd. Right now in init people kludge together systems which restart daemons when they have problems or monitor them. Most likely those kludges don't get written when systemd is ubiquitous on the major distributions. Which means end users on init based systems will have daemons go down and stay down or ask for resources and not get them. They'll experience a much more buggy unreliable system. "You have to reboot Linux every couple days otherwise too much stuff doesn't work".

_____

As for the rest reducing the pool of available developers for most choices. This is where it gets tricky. You can look at the distributions overtime and see big differences. Take for example the original (in the USA) big 3 Linuxes of 20 years ago:

Debian -- heavy focus on open source. Willing to be hard to use. Server focused
RedHat -- moderate focus on open source. Aimed to be easy for hobbyists. Workstation focused
Caldera -- indifferent to open vs. closed source. Aimed for commercial functionality, especially desktop using a Novell LAN.

OK let's go back to that point in time. How do you prevent the original fork? Clearly those distributions served different needs they have different users in mind. Now let's look today

Debian -- meta distribution that is key end users are distributions who distribute free desktop Linuxes or embedded systems. Focused on being the leader in keeping Linux open and free.
RedHat -- Enterprise server and infrastructure. Just starting to refocus on embedded.
SUSE -- Meta distribution designed to allow for containerized custom OSes for VMs.
Android -- Meta distribution for touch enabled ARM hardware

Again very distinct user bases. Arguably on that list SUSE and RedHat could merge. But beyond that, where do you a merge potential?

Re:The Future!

[jbolden]

What fragmentation? The only distribution not moving towards systemd is Gentoo and their users are self supporting.

Re:The Future!

[Rich0]

I haven't touched Gentoo in ages so don't know how it evolved but it appears to me that the FreeBSD ports collection is the very practical embodiment of what was being aimed at.

It should be, since that was what inspired the design of Gentoo. :)

From what I understand, FreeBSD Ports does not support USE flags, and I don't believe that FreeBSD is quite as flexible around overall configuration. Gentoo generally supports to some degree swapping out just about any component of the system. Heck, you can run it under OSX as non-root.

Re:The Future!

[Skarjak]

I don't agree with you that this diminushes ressources for projects. As I wrote above, many people contribute to open source projects because they just feel like it, not as a job. The different environments you quote above are all trying to do different things, as are the distros you mention. Would the arch maintainers even consider working on debian if arch didn't exist? That's not obvious to me. There is also the fact that while these projects may be going for different things, they can still at times come back together and integrate features from the other ones. Systemd is actually a very good example of this: it had competing init systems, but it has now been adopted by all the major distros. This competition was useful, and we arguably wouldn't have an init system to standardize on if people hadn't been allowed to go off on their own to try their solution.

For the user, again, this is terribly overblown. Just pick ubuntu. Or mint if you really want something a little bit more traditional. There is no reason to recommend a newcomer go for anything else. These are tried and tested distributions that are clearly designed to be easy to use. If the user wants to go further from there, they will have had enough experience with these beginner distros to make an informed choice. If they're more pragmatic and only use linux to get work done, they'll probably be satisfied and won't even need to look at the other distros. Again, the average user will never even hear about 95% of the distros on that timeline. They can't be paralyzed by options they don't know about.

It's true that some software works better in certain environments, and may require some work to appear native in other ones. I don't think that's a big deal since there is almost always an alternative that is native to your environment. It usually follows your environment's design principles, which would make it a superior choice anyway.

I think doing things more than once is good as long as you're doing it differently everytime. Those distros can sometimes be solving similar problems, but they usally have different solutions. Just look at all the people who complained about unity. Aren't they glad that XFCE exists? And now there's MATE if they really want the old school experience. Those products are clearly serving different custormers, and this parallel work can be useful for linux as a whole, as developpers can learn from the successes and failures of other projects.

Re:The Future!

[lister king of smeg]

2 comments.

First almost all distributions already go with systemd. Gentoo is the only major holdout and that's harmless since Gentoo is fairly self supporting. Gentoo also doesn't use init they use a very good upgrade called OpenRC. There is no systemd fork going on. I think there are a small group of people who would like a fork but they aren't going to get it.

Second, for the End Use it is fairly easy to imagine what would happen for distributions without systemd. Right now in init people kludge together systems which restart daemons when they have problems or monitor them. Most likely those kludges don't get written when systemd is ubiquitous on the major distributions. Which means end users on init based systems will have daemons go down and stay down or ask for resources and not get them. They'll experience a much more buggy unreliable system. "You have to reboot Linux every couple days otherwise too much stuff doesn't work".

_____

As for the rest reducing the pool of available developers for most choices. This is where it gets tricky. You can look at the distributions overtime and see big differences. Take for example the original (in the USA) big 3 Linuxes of 20 years ago:

Debian -- heavy focus on open source. Willing to be hard to use. Server focused
RedHat -- moderate focus on open source. Aimed to be easy for hobbyists. Workstation focused
Caldera -- indifferent to open vs. closed source. Aimed for commercial functionality, especially desktop using a Novell LAN.

OK let's go back to that point in time. How do you prevent the original fork? Clearly those distributions served different needs they have different users in mind. Now let's look today

Debian -- meta distribution that is key end users are distributions who distribute free desktop Linuxes or embedded systems. Focused on being the leader in keeping Linux open and free.
RedHat -- Enterprise server and infrastructure. Just starting to refocus on embedded.
SUSE -- Meta distribution designed to allow for containerized custom OSes for VMs.
Android -- Meta distribution for touch enabled ARM hardware

Again very distinct user bases. Arguably on that list SUSE and RedHat could merge. But beyond that, where do you a merge potential?

No gentoo is not the only holdout there is slackware, for example that doesn't.

Re:The Future!

[Skarjak]

Oh I can see why these might cause frustration. I was also bothered by the first implementation of it. But it seems like people don't like the concept, which is what I don't understand. They claim unity is good for touchscreens, but I'm not so sure about that honestly. Last time I was using unity, I was relying exclusively on the launcher and the dash search functions to start programs. With the launcher on auto-hide and the taskbar merging with the titlebars, it gives you the most screen space for your programs of any environment I've tried, and accessing programs and files from the dash is extremely fast. It allows you to control your computer almost entirely with the keyboard, which I like very much, while still being very accessible if you're just slouched in your chair, browsing with only the mouse. It strikes a nice balance. I'm used to awesomeWM now and it is better for coding, but unity is the most usable out of the environments I've tried.

I don't understand the folks who say you can't get work done on ubuntu. So many people were doing research on ubuntu with unity at my last university. You just need to use the keyboard more than you're used to in other environments, which is a good thing for me. Menus are a pain in the ass.

Re:The Future!

[jbolden]

I'm not sure Slackware is major anymore. They haven't really done much to innovate since the mid 1990s. Moreover there are already lots of things that don't run on Slackware. So breaking compatibility won't matter as much. But if you want to count them,, Slackware users are also self supporting.

Re:The Future!

[Dr_Barnowl]

I agree that Unity had a teething period... but I spend most of my time using applications and terminals, not the window manager.

I actually like things like the HUD menu, where you can tap alt and type something and find a menu item buried deep in the tree with a few keystrokes. And the movement of the close button makes sense at the top left, if that's where your "open an app" tool is - it's usually the next thing you'll do. Windows puts it as far away as you can get, and OSX is barely better.

Especially if you learn a few key shortcuts, it's entirely usable. And shouldn't represent more than a fraction of 1% of your time using an OS anyway.

Re:The Future!

[david_thornley]

Tanking sales don't seem to slow Microsoft down. Despite strong feedback from all their public test version users and slumping sales, they still haven't issued a version of Windows 8 with a straight Windows 7 interface (which would probably be an excellent OS).

Re:The Future!

[dbIII]

From what I understand, FreeBSD Ports does not support USE flags

You can set global compiler options so it's almost the same thing, at least if you are compiling for specific hardware with some processor extensions but not others somewhere between the usual defaults.

Re:The Future!

[Rich0]

From what I understand, FreeBSD Ports does not support USE flags

You can set global compiler options so it's almost the same thing, at least if you are compiling for specific hardware with some processor extensions but not others somewhere between the usual defaults.

USE flags are less about CFLAGS/LDFLAGS, and more about compiling kde without baloo support, or building openssh with or without the high-performance patches, or building openssl with or without tls heartbeat support. Many upstream packages have behavior that is modifiable at compile time. Doing so might eliminate dependencies, or perhaps it changes behavior that isn't otherwise configurable.

On Gentoo every package has its defaults, and then there are profiles like desktop/minimal/etc that have their own layer of defaults, and then everything is user-overridable either globally or per-package. I can disable SSL support system-wide and install just about any of the usual daemons without having either openssl or gnutls on my system. It can be especially useful for embedded systems, but there are other things it can be useful for as well.

Re:The Future!

[dbIII]

Good point. FreeBSD has the dialogs to choose options which is a different way to do it and most likely not as "fine-grained".

Re:The Future!

[Rich0]

Thanks. I'm not very familiar with the original FreeBSD ports implementation. If it is menu-driven I'd think that the obvious limitations would be:

1. No way to just set a flag once at the system level and have it apply to many packages automatically. With Gentoo I could switch a flag at the system level and have it rebuild everything in one operation that is affected by the change.

2. No way to express dependencies on how a package is configured. With Gentoo package A can depend on package B being configured in a particular way. Then when you install A the system will automatically propose reconfiguring B for you. For example, the initramfs builder dracut requires that kmod be configured with --enable-tools.

Source-based distros aren't everybody's cup of tea, but there are quite a few things that Gentoo does to automate things like this which you will be very hard-pressed to find elsewhere.

Re:The Future!

[bingoUV]

It is still a strength. Perhaps extracting money or making people genuflect is the purpose for which it is not a strength. But guess what - that is not everyone's purpose.

If the purpose is to give people a useful / fun / powerful / cheap piece of software, it is a strength.

Re:The Future!

[Grishnakh]

>If the purpose is to give people a useful / fun / powerful / cheap piece of software, it is a strength.

It's a strength, but it doesn't do that much good if no one except a few statistical outliers actually bother to use it, and 99.9% of people prefer to genuflect and empty their bank accounts.

Re:The Future!

[bingoUV]

How much good exactly (in kilograms?) is "that much good"? And why does " that much good " matter?

It is a strength, and helps achieve one's purpose.

Re:if systemd forces it's way into gentoo

[erice]

I'll just say fuck it and switch to windows 100%

It is already in gentoo if you run Gnome3, which is most people. It is pretty messy too since the documentation has not caught up.

What's wrong with Windows Server?

[BrianBeaudoin]

My experiences with systemd have been good and I can see how it can eliminate some of the kludges I've relied on in the past. Rather than have an /etc/init.d/myservice restart all related services to ensure a "clean" environment, I can list dependencies and triggers and rely on the system to do what is appropriate. It doesn't eliminate the ability to create or use System V init scripts, it just provides administrators with an alternative. Given the distribution creators have put a lot of effort into converting their scripts we have a lot of examples to work from. I've been working with UNIX since the 80's and rather than adopt a "get off my lawn" mentality I'm looking forward to embracing solutions to modern problems and see this as a positive step forward.

Dun matter

[Conceptualizing]

"[...] the exceedingly loud protests on message boards, forums" - and all other places that don't matter

Re:Dun matter

[gweihir]

You do know, Linux mostly gets developed on these "places that don't matter".

Re:if systemd forces it's way into gentoo

[BluPhenix316]

Funtoo has patched GNOME 3 to work without systemd.

Troll much?

[Zero__Kelvin]

". 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. ... Tune your distribution for desktop workloads. Go reinvent Windows."

Posting this uninformed drivel as a valid submission is a new low for Slashdot. Init runs as PID 1. Systemd runs as PID 1. In other words systemd renames Init to systemd. Does this idiot not get that systemd is essentially just a powerful universal init system that beats SysV and BSD style init?

Hint: A bunch of people still think Windows is great. 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. Systemd works great, and most of the major distributions have chosen to switch to it for good reason.

Some people don't like them new fangled fuel injectors and still think a carburetor is the way to go as well. For those people, the old init systems are still available, but fighting progress with FUD is the Microsoft way, and while nobody is reinventing Windows here, these "systemd suxors" idiots are becoming the new FUD machine.

Re:Troll much?

[Bill, Shooter of Bul]

Exactly. SystemD is more than just init, but not all of it is in PID 1. The whole desktop thing is just crazy. Its pretty clear thats as accurate as crazy tea partiers who think Obama is a Muslim. No rigor, no research, no thought from those people.

Now there may be some very legitimate complains about systemd. However, they get drowned out by the BS. It would also help if someone who doesn't like SystemD to actually work on an alternative Services management system that solved some of the same problems that systemD does.

Re:Troll much?

[X0563511]

systemd reminds me of Solaris' svcs, and I DO NOT WANT.

Re:Troll much?

[armanox]

Except we don't see systemd solving any problems. It is a solution searching for a problem.

Re:Troll much?

[Junta]

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:Troll much?

[Zero__Kelvin]

"It only runs on Linux, and will only ever run on Linux."

Who cares? Do you really think it needs to be ported to Windows?

"Upstream has vociferously declared that any attempts to merge patches to port to other systems will be denied, unless those other systems are feature-for-feature compatible with Linux."

Yes. In the field of software engineering we call this good engineering practice. If a different OS wants to fork it and use it they can, but none of the non-linux incompatible cruft is going to be folded back into the main branch. Your complaint boils down to: OMFG! The systemd folks insist on following solid engineering practices!

"That we have to ask these questions is reason enough to be angry about systemd."

No. It isn't. They haven't cracked into the SysV and BSD init repos and deleted everything, so you have no reason to be angry. If you like that old garbage, you are free to use it. Being angry that others choose to use a better system while giving you the freedom to use what you want is just plain stupid.

Re:Troll much?

[Junta]

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:Troll much?

[Junta]

Who cares? Do you really think it needs to be ported to Windows?

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

If you like that old garbage, you are free to use it.

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

Re:Troll much?

[Junta]

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:Troll much?

[Zero__Kelvin]

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

Do you not acknowledge OS X, Windows, BeOS, C-64 DOS, CP/M, PS/2, VMS, MVS, Amiga DOS, Apple DOS, etc.!!!!?????

I guess you don't get that there are lots and lots of OSes that aren't Linux, and trying to be one system to rule them all is a fools errand? Again, you don't know anything about software engineering so stop complaining when the people who do make the right choice. When I said systemd is universal that means in a Linux conext, and your attempts to paint it as otherwise are not "cute" or "insightful".

" Just because something does the job and hasn't been mucked with in years does not mean it should be presumed garbage and replaced."

Your statement shows how much you don't know about init systems. every init system has been mucked with constantly. Again, your delusion that there is a single (or even two) init systems that "haven't been mucked with" blasts your complete lack of understanding of init systems to the world at high volume (and the bass is way to frigging loud.)

Re:Troll much?

[gweihir]

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?

[gweihir]

Actually, I expect it to cause lots and lots of problems (it is already well on its way), which it than can proceed to solve over the next few decades. Reminds me of some other OS companies business model. I, for one, will be watching from the sidelines. As soon as there is real pressure in Debian to use systemd, I will be moving away.

Re:Troll much?

[gweihir]

Good summary. Enough reason to avoid it. Maybe in 10 or 20 years when it has some level of stability and on machines where I have zero need to customize my boot-process (at the moment I do not have any of those), but not before.

Re:Troll much?

[gweihir]

Well, if it becomes the only alternative, I will move to the BSD's. Network stack and firewall are superior there anyways. Just will have to select hardware more carefully.

Re:Troll much?

[gweihir]

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?

[Anonymous Coward]

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

----
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 /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;
-----
[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?

[Rich0]

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.

Systemd supports both:
1. Running as PID 1 in a container using a separate process namespace (which is at least as good as running in a chroot).
2. Running as non-root - you can use it to manage your own services under your own uid.

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.

What are you going to be tracing in the init system anyway?

And if you want to stop a container, snapshot it, and restart it, you would definitely prefer that this operation takes place in about 100ms and not in 30 seconds. PID 1 doesn't just run after disks spin up and the POST completes.

You missed a bunch of other features, like native support for namespaces/containers, or not leaving orphans lying around when a service stops, which would certainly be interest to somebody running a server.

Re:Troll much?

[Rich0]

What I don't understand is why systemd advocates continue to not understand the perspective of those against it.

This suffers a bit from the "everybody in the world would agree with me if they only understood everything as well as I do" school of thought...

It is entirely possible that they understand the counter-arguments, but simply do not agree with them.

Re:Troll much?

[Bob9113]

Outstanding post. Thank you for your time and effort!

Re:Troll much?

[ObsessiveMathsFreak]

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.

Well, if the project really is an NSA backed obfuscation of Linux a la SELinux, then confusing sysadmins and hampering their ability to control their own systems would be less of a bug and more of a feature.

Re:Troll much?

[drinkypoo]

-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 consideration for any modern system, especially given the plethora of lightweight shells available for low-memory or otherwise limited systems.

Sequential startup of services is silly when many can be started in parallel.

This is really the argument that something new was needed, but frankly, it would have been simple enough to handle this without a whole new init system. A shell script wrapper would probably have done this job. Some distributions are already recording dependencies in init scripts; sequence information would be simple enough to add. If this is the best argument for systemd, and so far as I can tell it is that, then it's a really crap argument.

Re:Troll much?

[skids]

It only runs on Linux, and will only ever run on Linux

Good. It can use the benefits of Linux without having to cripple itself to conform to portability abstractions.

Way to much blood sweat and tears have been spilled at the portability altar.

Re:Troll much?

[Culture20]

-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 [...]

-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.

Especially in the server world. The OS boot time is a fraction of my server's boot process. Starting out, you've got POST with RAM tests et al. The RAID array spins up and does its dance. Maybe IPMI gets in the mix. The NICs might have their own prompt for configuration changes lasting a few seconds. And sometimes the BIOS decides to give a detailed list of events with a ten second countdown (bypassable with a keystroke). Then some particularly silly BIOSes complain for a few seconds about a lack of keyboard. Finally, the MBR is touched. systemd will never speed up the slowest part of the boot process, so it's useless for that purpose in a server environment.

Re:Troll much?

[sjames]

Fully agreed and more!

All the starting of /bin/sh isn't really all that costly since it is already in memory. It just has to be mapped into place

The big time waster in a boot is the BIOS. After it farts around for 2 minutes, a fast boot is already out the window. An extra minute for init and the scripts hardly matters. The big potential killers like a forced fs check of a daemon that takes a long time to come up isn't fixed by systemd.

More amusing, there are several rc systems that drop in to SysV init to parallellize init scripts already. There is no need to re-invent the world just for that and the other drop-ins that manage it are proof.

Personally, I think something based on make would be interesting, but I don't have a big enough ego to try to cram it down people's throats and frankly, it's not sufficiently interesting to get me to work on it beyond idle thoughts.

Re:Troll much?

[sjames]

I have checked it out in Debian. It's really kind of amusing. They lobotomized it down to the brainstem in Jessie. IMHO, short of tossing it and Gnome 3 out the window, it's the right thing.

Re:Troll much?

[Electricity Likes Me]

Who cares? Do you really think it needs to be ported to Windows?

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

OpenBSDs entire development philosophy is to develop only for BSD, and let porting take place as patchsets on top of it.

That's why LibreSSL has has support for Windows stripped out, despite it being an important SSL platform.

Re:Troll much?

[goarilla]

Just as you don't understand fork and spawn, you clearly don't understand how privilege segmenting works in Linux. Much of the kernel runs in Ring 0 for example. It can disable interrupts and do all kinds of things that systemd cannot because ... wait for it ... it runs in user space.

Since we're talking about LInux don't you mean clone ?

Re:Troll much?

[Rich0]

Failed boot, which coincidently has started happening more under systemd than I ever remember with Linux.

Typically this is the result of incorrect unit files. This sort of thing can happen with any init system, and the only reason you haven't encountered it with more traditional sysvinit implementations is that you probably haven't adopted distros before they have become popular. New (non-derivative) distros have this kind of problem all the time, but they tend to gain word-of-mouth popularity after these kinds of growing pains have passed.

The other issue is that systemd starts services MUCH more quickly so race conditions tend to become more apparent. If you have some process that takes 100ms to initialize then in the bash days that probably wouldn't have caused problems, but now that systemd is launching a process every 10ms it becomes a problem if the launching unit terminates before the process has created all of its sockets/etc.

The other problem I've tended to run into is when you have non-typical dependencies between services due to your configuration. Maybe in 90% of cases there is no dependency between two services, but you have one of them configured in a way that creates a dependency. My biggest problem tends to be with DNS, because most people don't host other services on a DNS server, and nobody supplies a BIND unit that waits until the server is running yet and I haven't had time to hack one together myself.

Compile an update to a systemd managed service that includes a library upgrade, then restart the service. Watch those containers and namespaces without orphans work out real well for you as systemd hangs on to the now defunct filehandle for the now missing, upgraded library and frantically tries to restart the service that half the server and by extension the users depend on.

It isn't clear to me exactly what you're doing here. I've yet to have problems with updating libraries that are used by services, and I'm running Gentoo which breaks ABI all the time. Also, I was talking about containers and half the point of containers is to keep them self-contained. Typically I shut them down, snapshot them, and start them up before doing an upgrade (all of this takes about 100ms), then I test the functionality of that container to make sure that it works (which is usually easy since that container doesn't provide 47 different services). If for some reason it doesn't work I can just roll back the snapshot.

Instead of fixing the broken code, broken apps and moving forward I get to diagnose yet another startup problem on a server that, before systemd ,had 4+ years of uptime.

Honestly, this sounds like an issue with deploying a major change into a production environment before it was fully tested. If you have a well-oiled datacenter running on sysvinit it is unlikely that simply replacing that with systemd across the board is going to be issue-free.

Re:Troll much?

[Culture20]

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?

[Junta]

You do have to put a fraction of the time you did in 30+ years of learning your way around SYSV systems into actually learning systemd in order to expect the same level of proficiency.

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

more traditional systems have started to similarly fragment things, what with things like udev rules

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

Re:Troll much?

[Junta]

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

Re:Troll much?

[Junta]

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

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

Re:Troll much?

[Junta]

If I am into virtualization (basically having quick start firmware in arbitrarily small chunks of system), I already had amazingly fast boot with traditional OSes because each VM was more special purpose and only started very few init processes. RHEL6 upstart and RHEL7 are booting in about the same time for me in the VMs I've been doing.

Re:Troll much?

[Junta]

Speaking of fast boot, systemd is so fast that when configuring a static network interface, it will try to add the default route before the interface is up

This is generally the sort of problem that a project runs into when they decide that some ecosystem decades in the making can reasonably be so well characterized that they can model everything perfectly. Things will be missed. Additionally, it assumes the service being started understands it's dependencies all the time. In SysV scheme, an administrator or other application had a pretty easy time of pre-empting other well known services to alter behavior before them without modifying them. That's not so straightforward in systemd.

Re:Troll much?

[Junta]

Systemd supports both:

If I booted a rescue disk, I could chroot in no problems. Now I need to make sure that I can spawn a new container rather than just chroot. systemd-nspawn is not that horrible, but it isn't as simplistic as chroot. Some people used chroot for security isolation for which it is inadequate, but it is a pretty decent debug facility/build tool. systemd could have done a better job of degrading capability for obvious debug scenarios.

Re:Troll much?

[Rich0]

Oh, I understand what you're saying. There are plenty of trolls to go around, and I don't think that some of the key systemd devs help things. There are also plenty of level-headed folks on either side who see the pros and cons and make reasonable contributions to the debate. I just try to be the latter... :)

Re:Troll much?

[Rich0]

I'll agree that I have seen issues where the default dependencies don't always catch everything. I run DNS and NFS on the same box, and I have DNS names in my exports, and often nfsd tries to do its job before DNS is running, and by default DNS isn't required for network-online, and even network-online is fairly new so many things don't use it.

It is still pretty rough around the edges all around.

It isn't that hard to add a dependency to a service though - you can do this with a drop-in.

Re:Troll much?

[thule]

Did you know that systemd will run standard sysV scripts? You could have done that. If you were making your own script. I don't know why you would want to make your own script since the package includes one.

Did you notice the line above ExecStart? EnvironmentFile= points to a possible place that IRQBALANCE_ARGS is located. This is a normal place for things like that in a RedHat/CentOS/Fedora system. Nothing new here.

Since you wanted apache to start up at boot, did you try '/sbin/chkconfig httpd on'? This is the normal RHEL/Fedora way. It will *tell* you the systemd way when you run it on a systemd system (Note: Forwarding request to 'systemctl enable httpd.service'.)

Maybe you aren't familiar with the RHEL tools and filesystem layout?

Re:Troll much?

[ustolemyname]

The line immediately above:

EnvironmentFile=/etc/sysconfig/irqbalance

If you can't figure out that an "Environment FIle" might contain these things known as "Environement Variables," I question your claim to have been using Unix since 1978.

The environment file sets all the environment variables the service sees. It sees no more or less than what is in that file by default, which is both more secure and maintainable.

Re:Troll much?

[skids]

Well, actually I wouldn't say I'm an advocate more than I just recognize that's it's got enough good points and enough traction that it'll be part of my life in the future whether I end up liking it or not.

Re:Troll much?

[skids]

This is BS. "Learning" SYSV configuration takes 15 minutes to explain run levels

...and an understanding of shell scripting including obscure parts you normally don't use on the CLI ...and familiarity with many commandline utilities. ...and understanding how your package manager handles upgrades that touch the init scripts ...and eventually figuring out why half of the setup of facility FOO is in 51-pre-FOO and the other half is in 99-post-FOO ...and then figuring out that you could get away to moving that to 50-pre-foo so it gets run before 51-pre-bar, 49-pre-FOO won't work ...and the options to your system's start-stop-daemon or equivalent ...and how to get all the stuff called from the init script to belch debug info on demand, if that's even supported.

While personally I think all of the above is still preferable to memorizing what exactly things like RestartPreventExitStatus and ReloadPropagatedFrom mean, and being able to remember their names when you need to use them, it's a difference of margins not a giant difference.

Re:Troll much?

[CaptnZilog]

Especially in the server world. The OS boot time is a fraction of my server's boot process. Starting out, you've got POST with RAM tests et al. The RAID array spins up and does its dance. Maybe IPMI gets in the mix. The NICs might have their own prompt for configuration changes lasting a few seconds. And sometimes the BIOS decides to give a detailed list of events with a ten second countdown (bypassable with a keystroke). Then some particularly silly BIOSes complain for a few seconds about a lack of keyboard. Finally, the MBR is touched. systemd will never speed up the slowest part of the boot process, so it's useless for that purpose in a server environment.

Yeah, in all honestly OS boot time has never been an issue for me on startup - it's all the other stuff... the BIOS memory test on a 64GB machine, followed by by probing all the cards for their BIOS's and delays for disks to spin up, etc. When the machine takes 5 minutes to get past the BIOS/hardware level stuff, the 30-60 seconds it takes to actually boot Linux up to a login prompt (especially w/o X setup for logins) is minimal.

Re:Troll much?

[Zero__Kelvin]

Great point. If someone on the team isn't doing something correctly it means everything done by anyone on the team is automatically bad practice.

Re:server admins moving to FreeBSD

[Anonymous Coward]

something something netcraft?

Oh, the humanity!

[Spasmodeus]

I have some apprehensions about systemd and the direction it is pushing Linux, but the bug-eyed histrionics from the systemd haters is so comically absurd that it doesn't exactly make me want to join their cause.

Lots of people (i.e. me) aren't in it for the

[aussersterne]

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:Lots of people (i.e. me) aren't in it for the

[elysiuan]

That's totally valid. It still is nice we have the freedom to choose the tools in your toolbox though. I worked on Gnome for a few years and was a Gnome foundation member: I fully appreciate the position of not wanting to deal with democratic messiness and just consuming the output of such.

so annoying

[mrguitar1]

snydeq please stop bitching. Comparing systemd and the new proposal to windows is asinine and you know it. You're acting like a spoiled child. There are better more appropriate methods for voicing your opinion than here.

What do we need systemd for?

[Anonymous Coward]

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:What do we need systemd for?

[gweihir]

Good summary of the overall situation. The thing is a gigantic KISS violation for minor and often irrelevant benefits. But there are enough morons without a shred of actual engineering or system administration experience that do not know that complexity kills everything in the end and must be avoided at all cost.

Re:What do we need systemd for?

[Endymion]

While the obvious answer is that Poetternig/RedHat wants a windows alternative they can sell to "big" software developers, a more cynical (and mildly speculative) answer is that systemd is an outstanding way to shoehord into linux all the things that linux users would never normally allow. PID 0 is an important spot to control; if it wants to, it can control what programs are started and under what permissions. There are a few groups that really want this capability, or at least the capability to add something optional that can later be a forced dependency in GNOME or some other popular package.

The first group that comes to mind are the people who want DRM and a protected media path. A monoculture that forces features on users whever it wants to change things is the only way you'd get around the problem of having distributions simply compiling out or otherwise ignoring your DRM. Systemd has effectively raised the costs of not using whatever future "upgrade" is mandated, because the tight integration means you have to replace all the other software you now use as well.

Another group that would really like it if a buggy, alpha-quality, horribly overcomplicated, uncommented, unproven, monolithic black-box of software was a required to use Linux is... the NSA. Simplicity is important when it comes to key services like PID 0. I'm sure it's just a coincidence that the NSA is one of RedHat's larger customers, and that the NSA - while suberting NIST, Cisco, etc - submitted various pateches through redhat. I have no proof, of course, but you don't get security by assuming eveybody is being "nice". I strongly suggest listening to PHK's talk on this subject.

Finally, I'll link a post I just made over at HN. The reason systemd is causing emotions to run high is because it is trying to do to linux what has been done to many other tools: dumb it down and hide how it works. There are a lot of people trying to do that right now, because the idea of open computing that *cannot be limited* (see: "turing complete"). Welcome to the Civil-War On General Purpose Computing.

Re:What do we need systemd for?

[guacamole]

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", as if the fast boot can make up for all the other shortcomings.

Re:What do we need systemd for?

[walterbyrd]

> The main issue we get reported is the loooooong boot process compared to Windows

Not my experience at all. Far *far* from it in fact.

In my experience, CentOS 6.5 is up and running long before Windows 7. And that is even before Windows 7 begins to bog down, which usually only takes a few days.

Which version of Windows are you using?

You guys know that there are other things in life

[sweffymo]

...That are more worth getting mad about than this, right?

Edit much?

[Yaztromo]

"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

Re:Edit much?

[sjames]

There's this thing called a quotation mark. We use it when we're repeating something someone else said. For example, in the summary, it is quoting TFA. If you had READ TFA, you might have known that.

So you may direct your complaints to Mr. Venezia or his editors.

create abstraction

[Twillerror]

I often wonder why the community does not create more tools that abstract away the differences as much as possible.

Every distro has it's package manager and with it different syntax. Imaging if you had a tool like "install-it mysql" which on Ubuntu goes to apt-get install, or pacman's syntax, or yum or whatever.

The thing I mostly worry about is packages. Say what you will about Windows and Mac, but developing an app for them generally has a limited set of ways. There is only one way to do services in Windows, etc.

It is hard to get say Webcam apps to get ported to Linux because the poor devs have to figure out webcams in 10 different distros. Everyone in the boards say "ubuntu 14 +1", .... no no Arch first!!! and so on. Should it matter as much app to app? Shouldn't distros at least have some level of uniformity...a layer of it.

Re:create abstraction

[goarilla]

Every distro has it's package manager and with it different syntax. Imaging if you had a tool like "install-it mysql" which on Ubuntu goes to apt-get install, or pacman's syntax, or yum or whatever.

Has been tried before https://en.wikipedia.org/wiki/... by many systems.
The problem as I see it is that Linux software ecosystem is chaos. There's a lot of movement which breaks stuff regularly

The thing I mostly worry about is packages. Say what you will about Windows and Mac, but developing an app for them generally has a limited set of ways. There is only one way to do services in Windows, etc.

That's not really true. You can start services/daemons as a service* (under svchost or on its own), as a logon batch job, via a user's startup folder, on demand, ...
Windows has had its fair set of installers as well: Installshield, nullsoft, Macrovision, ...

It is hard to get say Webcam apps to get ported to Linux because the poor devs have to figure out webcams in 10 different distros. Everyone in the boards say "ubuntu 14 +1", .... no no Arch first!!! and so on. Should it matter as much app to app? Shouldn't distros at least have some level of uniformity...a layer of it.

Just use the proper kernel subsystems and sysfs.

Re:create abstraction

[sjames]

Yes, it's so confusing deciding if it's going to be 'apt-get install foo' or 'yum install foo'.

Re:I'm switching to an OS designed for the cloud

[TechyImmigrant]

So you just wanted to pop in and say something about Plan 9 then?

Kthxbye.

Actually he would bind his explanation into your file system name space.
   

abstraction layers cause problems...

[Junta]

The complaint about systemd is that it adds complexity to the base function of the OS, not that it fails to do what it advertises. It's not that people take issue with the way you deal with systemd, it's that when things don't go according to plan, it's a mess compared to the alternative.

For the services, you do have SysV for example still. You write one SysV script and systemd can make use of it just like the other init systems can.

Debian general resolution needed

[Anonymous Coward]

A general resolution against systemd as the debian default needs to be raised. Please go to debian-user and debian-vote and debian-dev and get the six votes needed to start a general resolution. The systemd people will of purse try to have you banned and your messages deleted as trolling.

Re: Debian general resolution needed

[Anonymous Coward]

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: Debian general resolution needed

[Anonymous Coward]

And yet for all that, apparently 6 of them haven't been able to get together to get the six votes needed to start a general resolution?

Sounds like the people against systemd are a loud, obnoxious minority to me if they can't even get six people to say "yes, it needs a broader vote."

Maybe you should consider whether your essentially "pro-book-burning" stance of actually *banning* the use of a piece of software is tied to your fear of change, rather than any technical merit whatsoever.

Re:Debian general resolution needed

[jbolden]

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

[jbolden]

The Gnome foundation which owns the trademark on the word Gnome, the foot logo and all project assets asserts that Gnome3 is the new Gnome. Yes it is Gnome.

Re: Debian general resolution needed

[blivit42]

If the Debian maintainers / committees are anything like Ubuntu, then I'm not at all surprised. For many years, grep -P didn't work in Ubuntu. It took them *FOUR YEARS* to fix it, with a rather bizarre discussion in the mean time. A core UNIX utility is broken and it takes four years to fix it? The earliest discussed solution, which remained the preferred solution for quite some time, was to retcon the documentation to cover it up! After 7 months, it was somehow demoted back down to "unconfirmed", and it took another 1.5 years after that re-acknowledge it was broken, after many voices of sanity finally prevailed.

After experiencing this level of cluelessness and severe disconnect with reality, I swore off Ubuntu forever. If other Linux distros are anything like the Ubuntu maintainers, I can only imagine what poor reasoning and justifications have been put forward regarding switching to systemd....

Why didn't depinit gain more popularity?

[Art3x]

Judging from this description in an older story, I'm wondering why the Linux community didn't embrace depinit.

Lennart Poetterings rebuttal

[Art3x]

I would be interested in the anyone's response to Lennart Poetterings rebuttal to the common complaints about systemd.

I'm too n00b to know who's right.

Re:Lennart Poetterings rebuttal

[Anonymous Coward]

In Lennart's eyes nobody but him is right, and even if you are he'll just ignore you if you don't communicate it in just the right way, so why bother writing a rebuttal?

Re:Lennart Poetterings rebuttal

[gweihir]

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.

Re:Lennart Poetterings rebuttal

[Anonymous Coward]

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:
" At compile time you .." I think that speaks voulmes right there... Compile time modularity is not the worrisome demonstrative facet, runtime modularity is.

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:Lennart Poetterings rebuttal

[psyclone]

Interesting, it's nice to know that you can still use syslog along side systemd's journald. From the limited remarks, it appears you still get full syslog output.

Re:Lennart Poetterings rebuttal

[Korgan]

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.

Re:Lennart Poetterings rebuttal

[phantomfive]

Using a little logic, there's enough there that you should be able to understand. To pick some examples:

Myth: systemd is difficult.
This also is entire non-sense.......systemd certainly comes with a learning curve.

Myth: systemd is a freedesktop.org project.
yes, we host our stuff at [freedesktop.org]

Myth: systemd is not UNIX.
There's certainly some truth in that.

Myth: systemd is complex.
There's certainly some truth in that.

Myth: systemd is a feature creep.
Well, systemd certainly covers more ground that it used to......

Re:Lennart Poetterings rebuttal

[Anonymous Coward]

It's relatively straightforward point by point.
Just by way of disclaimer, I don't consider myself a systemd hater; but I think that it has massively overreached. At best, it creates a new issue of dependencies (where applications are tightly coupled to systemd versions, and systemd versions are tightly coupled to kernel versions, creating a dependency where none existed before). Most likely, it's just an attempt to re-invent Windows (under the control of Red Hat). At worst, it's ... well, the haters will tell you the "at worst."

Overall I would say that in situations where facts are in dispute, he is generally right; but the conclusions are completely wrong.

Point 1, monolithic. The point is not the number of binaries. The point is the number of things running in PID 1 (too many) and the fact that so many applications must be changed to work with systemd. And, what's worse, that it's increasingly hard to work both with systemd and without it. GNOME 3 is the best example here. If systemd started services and that's all, that would be great.

Point 2, all about speed. I guess I don't really see this as a valid criticism in the first place. Oh no, it's faster! I think speed is actually one of the best things about systemd. It's just that the speed improvements could have been realized without creating so many other problems.

Point 3, boot time is irrelevant for servers. People say that because it's true. Sure, systemd might save ten seconds or even thirty seconds in service boot time, maybe. More likely it is not that fast. But as a server admin, the hour I spent troubleshooting a problem is much more important to the overall downtime than the ten seconds I saved when everything was happy.

Because systemd requires rebooting so much more often, I think the average server admin will probably spend more time booting with systemd than without it.

Point 4, incompatibility with shell scripts. This is a misrepresentation of the actual problem. The actual problem is not that systemd lacks some theoretical capability to run shell scripts, because that is not the case. The problem is that the service configurations actually deployed with systemd are in fact not shell scripts and therefore cannot easily be reconfigured. Effectively, if you need to do something different than what was conceived of by the systemd authors, you don't just have to make a small change to an existing shell script, you have to basically start from scratch. This makes things harder, not easier.

Point 5, difficulty. I guess this is too nebulous to argue with really. I guess I would say that users are typically either professional admins and software developers, who should be expected to know how to write shell scripts, and desktop users who are never going to change their init configuration anyway. The idea of breaking the traditional configurability in the pursuit of some improved approachability benefits no one because there are no real-world users who benefit from that. And as we all know from Microsoft, making things look simple is not the same as making them easy. It is quite the opposite in fact, as the simple UI gets in the way of the more capable users while nevertheless still being impossible for the casual users to get right.

I would draw a parallel with programming. People who don't program usually assume the hard part is learning the syntax, and therefore a language with simpler syntax is an easier language to learn. Sometimes even people who do program make this mistake. But in the end, it turns out that C and Ruby and Scala are better than COBOL and BASIC and Java. Not only more powerful - just plain better, start to finish.

Point 6, modularity. I'm not sure that's a real complaint that I've heard, at least not in the way he takes it. Nobody really cares how many compile-time options systemd has. Only Gentoo and FreeBSD users ever actually recompile their init system, and they, generally speaking, don't use systemd (It's possible with Gen

Re:Lennart Poetterings rebuttal

[grcumb]

I would be interested in the anyone's response to Lennart Poetterings rebuttal 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

[samuX]

http://comments.gmane.org/gman...
* journald will no longer forward all local data to another running syslog daemon. This change has been made because rsyslog (which appears to be the most commonly used syslog implementation these days) no longer makes use of this, and instead pulls the data out of the journal on its own. Since forwarding the messages to a non-existent syslog server is more expensive than we assumed we have now turned this off. If you run a syslog server that is not a recent rsyslog version, you have to turn this option on again (ForwardToSyslog= in journald.conf).

Re:Lennart Poetterings rebuttal

[sjames]

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:Lennart Poetterings rebuttal

[devent]

Oh please cry me a river. Impose systemd on others? Did Lennart own Ubuntu, Debian, RedHat and Suse now? It was deceided by the developers of those distributions to replace the old sysv init with systemd, and the alternatives were concidered. In Debian it was a democratic process by voting. RedHat is a company so clearly they will not bet on a broken system. Almost all of the arguments against systemd are not valid on technical grounds, and now you want to muddy the waters by attacking Lennart directly.

Systemd sypports text files just fine, you do the straw man here. Fedora have systemd since F18 (I think), today I'm using F20, and I still have all my log text files in the same location. Debian *voted* on the issue and decided that the alternatives (upstart, etc.) are not good enough technically compared to systemd, and sysv init was obolete. If you are thinking that Debian is now owned by Lennart, you really need to get your tin hat.

Systemd is not a mess. Many of the points are just false. Like your straw man with binary log files.

Re:Lennart Poetterings rebuttal

[Eunuchswear]

Which worked out oh so well in the whole PulseAudio fiasco a few years ago.

You mean that fiasco that finaly gave us working sound?

Re:Lennart Poetterings rebuttal

[Eunuchswear]

3: Servers start fast enough without systemd.

No they don't.

They don't start fast enough with systemd either, but that's not systemd's fault.

Re:Lennart Poetterings rebuttal

[sjames]

If you want it much faster than they start already, you'll need coreboot.

Re:Lennart Poetterings rebuttal

[gweihir]

I had working sound before that. And after, as I did never downgrade to PulseAudio.

Re:Lennart Poetterings rebuttal

[lister king of smeg]

Oh please cry me a river. Impose systemd on others? Did Lennart own Ubuntu, Debian, RedHat and Suse now? It was deceided by the developers of those distributions to replace the old sysv init with systemd, and the alternatives were concidered. In Debian it was a democratic process by voting. RedHat is a company so clearly they will not bet on a broken system. Almost all of the arguments against systemd are not valid on technical grounds, and now you want to muddy the waters by attacking Lennart directly.

Systemd sypports text files just fine, you do the straw man here. Fedora have systemd since F18 (I think), today I'm using F20, and I still have all my log text files in the same location. Debian *voted* on the issue and decided that the alternatives (upstart, etc.) are not good enough technically compared to systemd, and sysv init was obolete. If you are thinking that Debian is now owned by Lennart, you really need to get your tin hat.

Systemd is not a mess. Many of the points are just false. Like your straw man with binary log files.

No he doesn't own them but he sure tied they're hands by making it a dependacy form gnome.

Re:Lennart Poetterings rebuttal

[devent]

Oh, Lennart own Gnome now?
That is exactly the type of comments I read from critiques of systemd.

Re:Lennart Poetterings rebuttal

[lister king of smeg]

Oh, Lennart own Gnome now?
That is exactly the type of comments I read from critiques of systemd.

Own no, but you would have to be very dense to beleive there is no conection.

Where do many of the gnome devs work? redhat.
Where does Pottering work?... redhat.
Where is gnome hosted? freedesktop.org
Where is systemd hosted? freedesktop.org.

Its the same people working on both.

From the braindead, community ignoring, development team the borked gnome 3
And lead by the guy the wrote the most broken sound system in all of unix and the buggyness that is network-manager
comes SystemD...

Re:Lennart Poetterings rebuttal

[grcumb]

Oh please cry me a river. Impose systemd on others? Did Lennart own Ubuntu, Debian, RedHat and Suse now? It was deceided by the developers of those distributions to replace the old sysv init with systemd, and the alternatives were concidered. In Debian it was a democratic process by voting. RedHat is a company so clearly they will not bet on a broken system. Almost all of the arguments against systemd are not valid on technical grounds, and now you want to muddy the waters by attacking Lennart directly.

No, you ignorant little shit, I am not attacking Lennart directly. If I were attacking him directly, I would question his character and his motivations. I would suggest that he, like you, is of questionable (probably canine) parentage, and that his reading comprehension is at such a disastrously low level that he (like you) indulges in exactly the mistakes that I warn about in my critique.

So you see, if I were attacking Lennart, I would have written a paragraph or two like that one. But I didn't.

You, on the other hand, deserve no such forbearance because you fucking still don't fucking get it. Fuck.

Being technically correct is not - and never has been - sufficient for technology to become successful.

There is a time and a place to stomp on the desires of others when better answers to old problems is concerned. It is a common sin of the young that they think they know where that time and place actually is. In reality, they seldom do, because it's an insight that comes from experience.

Nobody is going to stop you on your path to self-destruction. All we ask is that you let us antiquated geezers (who actually have, you know, systems to run) alone. Is that too much for you to get your tiny little head around, you strident, inexperienced little twerp?

(P.S. If I've overdone the name-calling in the pursuit of a certain tone, please accept my apology. I have no idea whether you're actually little or not.)

HTH HAND

Re:Well... does it matter?

[jedidiah]

NOTHING that is managed by init is the sort of thing that any random clueless rube has any business going near.

Not that any of the replacements are actually any easier to deal with.

Re: I'm switching to an OS designed for the cloud

[itomato]

I love when people mention Plan9 in the same sentence as another unix-like, and hint to some sort of viability.

Re:server admins moving to FreeBSD

[fisted]

Did that. Not regretting it.

Re:Bah Humbug

[Anonymous Coward]

Um, FreeBSD is transitioning to pkg_ng, a from scratch implementation that is intended to give the functionality of apt/rpm for their ports database. It works with both source and binaries. It has been shaping up really well, and is the default in the last 9.x and 10.x releases. You should give it a try, and report problems that don't past muster with your use cases.

Re:server admins moving to FreeBSD

[FatdogHaiku]

nope. not evah. no way.

What, your acting like it's dead or something...

Obligatory Monty Python (with cameo by The King):
https://www.youtube.com/watch?v=dGFXGwHsD_A

Re:if systemd forces it's way into gentoo

[Galactic Dominator]

Wow, something so awful even some Gnome 3 users can't take it.

Cyclical logic much?

[Quarters]

I'm glad the author cites the blog posts he's written against the idea as supporting evidence that there is a groundswell against the idea....

Re:Cyclical logic much?

[MikeBabcock]

Google supports his argument. "systemd sucks" has over 35 thousand results right now.

He wrote another blog post, another in a long line of blog posts by people who are annoyed by or don't want or actually hate systemd for one reason or another. Ignoring them all doesn't make it not true -- there are a lot of users who are unhappy with systemd.

More importantly, there are a *lot* of users who wouldn't know the difference and who haven't had a reason to notice the change at all. Those people can't be cited as 'supporters' because they couldn't care less if its rc.d or systemd or djb's svscan.

Meantime....

[bagboy]

I'll keep using OSX - Windows 7 in Fusion for desktop and getting shit done...

What the...?

[thieh]

I thought you got slackware and probably gentoo if you don't like systemd? You don't have to swallow if you don't like it. And then there is Hurd...

I'll use a "server" distro on my laptop...

[Culture20]

I'll use a "server" distro on my laptop before I'll ever use systemd.

In gentoo...

[buckfeta2014]

I gave the new udev as well as systemd (and their initrd requirement) the middle finger, and uninstalled udev and installed eudev in its place. Business as usual.

Re:if systemd forces it's way into gentoo

[Grishnakh]

You're wrong about that. There's lots of Gnome3 users. I see them in message forums all over, like /r/linux, and of course /r/gnome. Of course, I can't explain why anyone would want to use it, but there really are a lot of people who do. Similarly, there's a lot of people who use and like Windows8/Metro, despite the fact that it's total crap.

Re:if systemd forces it's way into gentoo

[reub2000]

I still don't understand why a desktop environment would need to interact with an init system. I get that gdm would need it it to start at boot, and for things like shutting down and restarting. But why would the DE itself require a specific init system?

Re:I'm switching to an OS designed for the cloud

[viperidaenz]

It's called Plan 9. And it was ready for The Cloud before we were calling it The Cloud.

(no, I'm not really switching, as it's not production ready. but it made some really interesting design decisions that Linux and FreeBSD missed)

WTF?

derp

[Randle_Revar]

>Paint over init and cron, pam and login. Put all of that into PID1 along with dbus

Init is in PID 1 with systemd, and it is pretty natural for an init system that can already trigger on various events to also support triggering on absolute and relative times. As for dbus, PID 1 does expose a private dbus interface, but it is NOT the system dbus daemon. Logind, journald, PAM, the dbus daemon - those are NOT in PID 1

That line just shows you are completely ignorant or a troll, or both.

It is fine to have some issues with systemd, I do myself, despite being overall in favor of it, but at least have them be real issues...

not just servers

[dltaylor]

Granted, I AM my own "system admin", but BSD goes into my home systems next time I build or upgrade (2-3 weeks, most likely). Can't use Debian or RedHat, so might as well go back BSD (used to run it on my Amiga).

Systemd is yet another example of "fashionista" development (Gnome 3). Ignore the people who really use the system, because "they're idiots", and (attempt to) stuff your favorite fashion du jour down their throats.

I've got a choice, and systemd is NOT going to be part of it.

systemd...

[fustakrakich]

I don't know what they have to say
It makes no difference anyway
Whatever it is, I'm against it!

Looks like Slackware and Gentoo are the last of the faithful. The rest are infidels...

Re:systemd...

[Rich0]

Looks like Slackware and Gentoo are the last of the faithful. The rest are infidels...

Uh, systemd works just fine on Gentoo, though openrc comes pre-installed at this point.

Re:systemd...

[Rich0]

Oh, I doubt openrc will go away completely, as long as somebody cares to maintain it. Gentoo never really turns away oddball configurations entirely. What you might find is more and more packages that lack an openrc script - even before systemd came along you could find the oddball package that lacked a script, and if many devs switch over you might find a lower level of support for openrc.

But, nobody is going to tell you, "you're not allowed to run openrc." Despite all the noise people make publicly, the reality is that within Gentoo the maintainers of systemd, udev, eudev, and openrc work fairly closely together to try to keep things running smoothly. Heck, there was just a discussion about whether systemd should support being able to switch back-and-forth with openrc by default, and the answer was yes, even though it involves installing a few files that are otherwise unneeded by systemd. Current policy is that when it comes to installing stuff like init scripts both systems should be supported by default so that people who want to switch either way don't have to rebuild half the system just to get some scripts. Of course, if you're talking about stuff like gnome3 you're not going to find equal support for both.

Moving to FreeBSD is probably more a ZFS thing

[dbIII]

Currently ZFS on FreeBSD is rock solid with high performance, while on linux it's not up to that point as of mid-2014. In the space of file servers that's a good reason to change for now.

Re:Moving to FreeBSD is probably more a ZFS thing

[Wolfrider]

--I would dispute you on this. I was running my main backup RAIDZ2 server on PCBSD, and had to break a ports upgrade compile. Ports was irrecoverably broken after that. After about a year I switched to Linux + ZFS, and it runs with BETTER speed on the same hardware. And on top of that, Linux has a better disk-naming system -- as well as a functional fdisk -l.

Re:Moving to FreeBSD is probably more a ZFS thing

[ByTor-2112]

I've been on FreeBSD since 1999, and went "all in" on ZFS about 7 or 8 years ago. I can attest to the robustness of the system; it's incredibly stable. Definitely a reason to look beyond Linux. Most code should be pretty portable unless you are looking in /proc for a bunch of things, something which I has always appalled me.

PC = Personal Computer = (!network computer)

[raymorris]

Windows, and DOS before it, was designed and built as the anti-server.
Before DOS, there were network operating systems like Unix, where one server serviced many users. Didk Operating System (DOS) got it's very name and identity from bring the opposite - not a network operating system, but one based on everything running from the local disk. It ran on PERSONAL computers (PCs), so called because they were the opposite of the shared enterprise computers that came before. Microsoft did a great job of making a personal computer with all resources on the disk.

After the nice Windows desktop, Microsoft invested a billion dollars developing and deploying a technology called COM. The basic idea of COM was that you could embed documents from one program inside documents from another program, and that did cool things. Rhen the WWW came along, with the img tag. That approach threatened Microsoft's billion dollar investment, so up through Windows 98 they tried fighting against the internet trend.

That's over half of Microsoft's existence that they spent building the perfect opposite of a server. Linux was built to be like Unix, which was designed and built as a server from day one. Not surprisingly, Linux is good at what it was made for (network computing) and Windows is good at what it was designed to do - user-friendly local desktop work.

Re:PC = Personal Computer = (!network computer)

[benjymouse]

That's over half of Microsoft's existence that they spent building the perfect opposite of a server. Linux was built to be like Unix, which was designed and built as a server from day one. Not surprisingly, Linux is good at what it was made for (network computing) and Windows is good at what it was designed to do - user-friendly local desktop work.

Sorry, but this is BS. At best it is true for the Win 9x strain of Windows. Windows NT was a clean implementation of a new operating system with the Win32 API reimplemented to support backwards compatibility with Win9x.

Windows NT was built as a network OS from the start, whereas Unix (and Linux) was built as a multiuser OS. The difference is evident when you look at how e.g. a user account has been represented: In Windows a user (or group) account always includes the authority responsible for the account.

In Unix/Linux there is no such concept: users and groups are identified by integers and are implicitly users of the local machine.

Windows user accounts are global in nature: Every time you has a reference to a user, you have the reference to the authority as well. Unix/Linux user accounts needs to be mapped using all kinds of strange tricks especially on networked resources, because it was never perceived in the original design that you other machines would work with the local machine trough a trust relationship.

This is actually why the biggest reason to go with Windows servers is Active Directory: It was trivial to integrate the established user/account regime with something like AD, since AD simply became an "authority" - for which Windows NT already had support. Unix at the time had to resort to strange quirks such as NIS domains.

In general, it has *always* been a pain to share user accounts across Unix/Linux systems, while on Windows you could set up an AD (or a domain before AD), and software did not have to be rewritten just to pass credentials from machine to machine.

After the nice Windows desktop, Microsoft invested a billion dollars developing and deploying a technology called COM. The basic idea of COM was that you could embed documents from one program inside documents from another program, and that did cool things.

You don't know what COM is. What you are referring to here is called OLE - Object Linking and Embedding. OLE is/was built on top of COM - but COM was *never* about being able to embed objects.

COM is a language-neutral binary object model, which ensures that the system has a common object model where objects can be consumed regardless of what language was used to develop them. It is still very much at the core of Windows, mainly because it is so efficient (being a binary standard it has extremely little overhead - especially for in-proc objects).

Re:PC = Personal Computer = (!network computer)

[recoiledsnake]

I said Windows Server, not Windows. It's based on Windows NT.

http://en.wikipedia.org/wiki/W...

Re:if systemd forces it's way into gentoo

[Rich0]

SystemD works just fine on Gentoo whether you use Gnome 3 or not. It is just a required dependency if you run Gnome 3 since that is the direction Gnome is moving in.

As long as people take care of OpenRC I'm sure that will always be an option. I wouldn't be surprised if at some point the install tarballs stop bundling sysvinit/openrc - much as they do not bundle cron, syslog, or even a kernel, leaving the choice of what sysvinit to install up to the user.

Reminds me of a Stargate in-joke

[dbIII]

On a Stargate episode power is restored thirty seconds before the gate is needed for a life or death situation, and the computer controlling the gate starts booting up. Cut to a Solaris boot screen.
We used to call it "Slowaris" for a reason.
A lot of the time is consumed doing hardware self-checks on SPARC gear which can not entirely be blamed on Solaris but "is this thing really on?" is a normal reaction with the prolonged wait during boot with a lot of Solaris systems.

Re:Reminds me of a Stargate in-joke

[X0563511]

My favorite is when it (randomly, as far as I can tell) kicks you into maintenance mode, whining that a restart is required to ensure boot archive is consistent.

Fucking thing... it's also a complete pain in the ass to use 4096-aligned storage when you've a Sol10 ZFS-root installation. You simply -cannot- align the fucker and it trashes your storage with 8x the I/O.

Agh! So much anger.

Re:why is this on slashdot

[damn_registrars]

This is *the* stupidest thing I've ever read on Slashdot.

You must be new here. What sites were you reading yesterday before you stumbled into slashdot for the first time?

the problem with Windows...

[silfen]

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.

Enterprise

[Princeofcups]

I guess people still haven't come to the realization that enterprise level stability and uptime are neither simple nor easy.

Re:Enterprise

[HuguesT]

man screen. Or man tmux if you prefer.

Re:Enterprise

[Cederic]

So you use a new OS for the first time, expect it to act like a previous OS, spend no time learning or configuring it, and blame it for doing something you didn't expect?

I'm not sure the OS is the issue here.

it's the pulseaudio guy

[louden obscure]

Um yeah, uh, no thanks. I hate pulseaudio, prolly cuz I didn't want it, it just showed up an upgrade or so ago on debian..
At least I can remove it and just rely on alsa, systemd prolly not so much. Quit fucking with debian. debian is not ubuntu. Why can't you just leave well enough alone? I'll just have to hang onto Wheezy as long as I can.

I don't understand the hate for SystemD

[stoploss]

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?

The Unix Way

[emblemparade]

It's the "Unix way" to make one tool do one thing well. The "systemctl" tool is not meant to show status.

The point in Unix is that tools are building blocks. You can create a higher-level tool (using a simple shell script) that uses these tools together to do cool things that the devs have not thought of.

What do we need systemd for?

[Anonymous Coward]

It was only dead simple to administer if everyone else did the work for you.

Once you had to write init.d scripts, a lot of that simplicity vanished. Systemd is no different, in fact the same 4 commands (turn on, turn off, configure to start automatically, remove configuration to start automatically) exist in both environments, so it's not like it is harder to administer.

Different kinds of servers

[HuguesT]

FreeBSD is great as a file server, web server, etc. ZFS is totally awesome and stable under freeBSD. It is making progress in Linux (I use it daily) but it is not quite there yet. On the other hand, a compute server or virtual hypervisor does not look too great right now in BSD, because of incomplete NUMA and lack of VM options. Also Linux is not monolithic and Init+runlevels is alive and well. Vote with your feet and choose a distro without systemd or at least init as an option. I'm sure Debian will keep init forever.

Two solutions

[russbutton]

For those who object to systemd, why not fork off your own distribution and bring back init? It's not like that sort of thing hasn't been done before.

For y'all who are systemd proponents, if you actually want it to be adopted, then spend some money on a good tech writer and document the damn thing. I've read what documentation there is and it sucks. Really.

I'm pretty agnostic when it comes to things like this. The big issue for me is whether I can get it to do what I want. Is the documentation sufficient for me to understand how to use it and how to get it to do what I want? In this case, not only do I need to know how to start/stop system services, I want to be able to add new system services. Doing so was very easy in REHL/CentOS with init and chkconfig.

Most of us really don't care two cents for the reasons y'all want systemd, and I'm sure there are good reasons. What we want is to be able to know how to use it, and that only comes from good documentation.

Of course this may be a case of some a**holes feeling they're more clever than everyone else, and because they know better, this not only gets pushed own everyone's throat, they get to feel superior because they know how it works and nobody else does. This is the same kind of ego inflating attitude that guaranteed UNIX and Linux would (and will) always take a back seat to Windows and MacOS (which is doggy doo of a different kind, but doggy doo nonetheless).

Re:Two solutions

[Rich0]

For y'all who are systemd proponents, if you actually want it to be adopted, then spend some money on a good tech writer and document the damn thing. I've read what documentation there is and it sucks. Really.

Seems like systemd isn't really hurting for people to adopt it. Just about every major linux distro already is doing so. Documentation tends to lag features on FOSS - I doubt that will change anytime soon, but I'm sure the docs will come. I too have been a bit annoyed having to reverse-engineer systemd features.

Your prophetic hat is broken

[m.alessandrini]

You just described the present!

Bad data point with the ports failure

[dbIII]

You can break ports without any filesystem problems at all. Not hard to scrap what you have and fetch it again though.

After about a year I switched to Linux + ZFS, and it runs with BETTER speed on the same hardware

I'm sure the ZFS developers on linux, although undoubtedly happy to hear such cheerleading, would see it as the bullshit it is. I've got a couple of linux systems in relatively heavy use with very recent ZFS in addition to a pile of freebsd ones so I'm not speaking from ignorance. One of those is my home system so I'd like it to be as good as you suggest, however it isn't. Mirroring is reasonable if not quite as quick as on other platforms, raidz/raidz2 among other things gave me unrecoverable corruption on every disk on a pool of 24 disks only two months ago when I thought I'd give it a shot again in linux with a controller I can't boot freebsd from. Fortunately that was after I'd copied most of the data onto the thing but before it went live, so I stuck the OS drives on the onboard SATA and have the thing running raidz2 happily on freebsd10 and fully saturating 2x1Gb/s connections when required. I do have a reliable raidz setup on a linux box as an offsite copy for some filesystems (anything that can be logged into and erased is not a true backup so it's a copy that's quicker to get to than the real backups on tape), but it's speed compares very poorly to ZFS on freebsd at the moment. That is changing.

Haters gonna hate

[YoungManKlaus]

Seriously, most of systemd debate seems to be driven by FUD and being scared of new stuff. Like "we can't run our old init scripts any more" (which is wrong) ... jeah, but nobody is gonna miss your unreadable bash-crap anyhow!

Zombie Processes

[Marrow]

Do current distros (systemd or not) still allow for zombie process to remain in the process table? Does systemD fix that problem now?

Re:Zombie Processes

[Rich0]

Usually that sort of thing is the result of a kernel bug. Both init and systemd will wait for zombies, but if there is a kernel bug that doesn't always work.

Linux doesn't always handle resources becoming unavailable in a graceful manner. Sure, you can delete an in-use file and that is clever, but try to do the same thing with a mountpoint, or hardware device, and you end up with zombieland, BUGs, or even PANICs.

Oracle v. Google

[tepples]

And the best thing I've seen so far to replace startup scripts is Sun's SMF [...] Dont copy the guys who invented NFS or ZFS or stuff like that

I was under the impression that it was unwise to copy Oracle because of copyright issues.

Really?

[Dcnjoe60]

Really? Redhat network administrators didn't know systemd was coming in RH7? Then they should be fired. Now, debian administrators, that's a different story. That decision was just recently made. But even so, why rant about RH? It's been common knowledge for a long time that systemd was coming.

who needs a bug?

[freezin fat guy]

This shows how old I am but when I first started in web development I was mortified to find out IE would let me erase the visitor's hard drive with a web page.

Heretic!

[Dareth]

That was the EMACS vs VI war. You always put the winner first!

Who needs Gnome?

[walterbyrd]

Gnome used to great. Now Gnome is, by far, the crappiest DE out there.

Why do people think Debian needs Gnome? Use XFCE, it blows Gnome out of the water.

Re:Who needs Gnome?

[jbolden]

Debian aims to be a meta distribution. Gnome is the most popular Linux distribution. Debian not supporting Gnome would be a very very big deal.

Remember Gnome was essentially born from Debian not supporting KDE and the acrimony from that lasted a decade.

Re:Who needs Gnome?

[akc]

That might be your opinion, but for me its the opposite.

I have two monitors, and despite me trying to configure other Desktop Environments to behave in the same way, it has only been GNOME3 where I can have a fixed window in one workspace (generally mail), and other things going on on my main monitor each in their own workspace, whereby I can switch between them, and not also have the secondary monitor switch at the same time. I tried stuff like Linux Mint's Desktop, KDE and even XFCE, but I couldn't figure out how to make any of them work that way.

And now I am used to it, I love the lack of a taskbar panel. I just flick my mouse over to the corner to get an immediate views of the various windows I could switch to. I love the dock, with the apps I use 99% of the time immediately available, and a quite good incremental search for anything else I need

Of course there are some downsides/bugs - like some flakeyness around full screen apps (I use WIndows 7 inside virtual box a lot and Mythtv) where there occassional lockups. But I am running Debian Stable, so I presume I don't have the latest and greatest version.

Re:Who needs Gnome?

[stoatwblr]

gnome is a UI, not a distro.

I'm using multimonitor XFCE and enjoying it.

Re:Who needs Gnome?

[jbolden]

I understand Gnome is a UI. But Debian can't not support Gnome for all the distributions that depend on it. I get you may like XFCE but you liking it and Debian mandating it are worlds apart. Mandating systemd is one thing. Mandating Gnome sunk projects like Progeny and UserLinux. I have to assume that mandating XFCE would be far more controversial for something like Debian. It is simply beyond the realm of possibility.

Re:Who needs Gnome?

[stoatwblr]

I'm not asking that Debian drop gnome. I simply want support for XFCE/LXDE. Not every system out there is running (or needs) 4Gb+ and a 3GHz i5-class CPU.

I have a number of older low powered boxes. Gnome got too fat to run on them a long time ago.

Re:Who needs Gnome?

[jbolden]

They've had that for years. It is fully supported. The issue above is whether to support Gnome or not, no one is arguing for not supporting XFCE.

Re:Who needs Gnome?

[DavorDux]

There's one downside to it. I'm using Debian Wheezy with Gnome 3 which should be stable, but I'm getting occasional lock-ups and I have to reset the computer. Interestingly, that doesn't happen with either Gnome classic nor Xfce. Go figure. I do like Gnome 3, too, but the stability of Xfce is really enticing, to say the least.

Re:Who needs Gnome?

[akc]

I have enabled control-alt-backspace. Don't need to reset the computer

I find the normal reason that there is a lockup is because virtual box whilst running windows in full screen mode, and windows has put up a dialog box or the alt key has put up the start button menu.

This seems to cause the hotspot or the alt key to stop responding in gnome3. This gets into a deadly embrace where you can't switch to the virtual box window.

Re:server admins moving to FreeBSD

[Aaden42]

And in-tree ZFS support, the performance of which beat Linux by a goodly margin last time I tested it. Admittedly that was several years ago and ZoL has come a long way since then. Still, having baked-in ZFS support instead of being stuck (due to GPL/CDDL licensing issues) with your root filesystem in a kernel module was a GoodThing.

What's wrong with Linux desktop?

[walterbyrd]

IMO: Linux desktop blows away everything since XP.

Except for one, possible, important thing: Windows runs more apps.

Why not Slackware instead of BSD?

[walterbyrd]

I would think it would be easier to move to Slackware. At least Slackware is still Linux.

Maybe somebody should make a commercial version of Slackware?

You should go to Washington

[raymorris]

You're very careful about extracting just the right words from a quote, and avoiding the words right before, in order to pretend you're arguing against someone by saying precisely the same thing they just said.

I said:
> up through Windows 98 they tried fighting against the internet trend. That's over half of Microsoft's existence

Your reply:
Sorry, but this is BS. At best it is true for the Win 9x strain of Windows.

Ok, so what I said about Windows 9x is only true of Windows 9x (and it's predecessors)? So in other words, it's precisely wtf I just said.
PS - There entire philosophy and corporate culture didn't do a 180 overnight. They did realize that if they fought the internet, the internet would win, but even on phones and tablet their STILL trying to make it disk-based rather than network based, with multi-GB software packages installed and running locally on the tablet. This year, 2014, they are still doing that with their current tablets. Local computing is their thing.

> You don't know what COM is.

Ever altered a foreign object's vtable to point to your own component instead, by calculating the offset of a method pointer and using RtlMoveMemory to hijack the system object's method? Come back when you can pull that off successfully and we can talk about how COM works.

> COM is a language-neutral binary object model, which ensures that the system has a common object model where objects can be consumed regardless of what language was used to develop them.

You keep repeating that the components don't need to be written in the same language, as if not having a stupid requirement were the purpose of COM. Not so much. Microsoft did talk that up as a selling point since their previous approach did have stupid requirements, but that's kind of like saying the purpose of a car is to not require a specific brand of gas. According to you, a car isn't transportation, it's "an gasoline-brand-neutral machine". Have you thought about what you mean by "objects can be consumed"? That means a program can use the facilities of another, separately developed program. In other words, one program can be embedded in another. "but COM was *never* about being able to embed objects". Yeah, that's pretty much what is does. That winsock control you include in your program using COM? It's an object, embedded in your program. An object embedded. Instead of embedding it, if you want to use an object provided by something large, like Excel.exe, you might link to it. So using COM you can either embed an object (winsock) or link to an object (Excel). You can do object linking, and object embedding. In other words, Object Linking and Embedding. Add "on the internet" to that and you can rename it ActiveX.

> It is still very much at the core of Windows, mainly because it is so efficient (being a binary standard it has extremely little overhead - especially for in-proc objects).

It's pretty efficient IF early binding is used. When late binding is needed, that's a thousand times slower.

    you pointed out, the two programs don't need to be written in the same language.

Re:why is this on slashdot

[TangoMargarine]

Yeah, discussing the boot process is for script kiddies. Now get off my damn lawn so I can go back to programming with a magnetized needle and a steady hand!

Reading Logs / Binary and Text

[efitton]

I know next to nothing about systemd. I can't argue for or against. However, at most I will have one system at home running linux. Before on the rare occasion I had a problem I could type "less log" and look at the log. With systemd I have to do something more complicated. It might be better for an admin but I just don't have the time or inclination to learn syntax for reading a log, even assuming a shallow learning curve. It isn't my occupation, vocation or interest; especially as I hope to be looking at the logs no more often than once every year or two. Possibly the text logs are propagated automagically and most of my argument happily goes up in smoke; however, why the hell is it a binary log in the first place?

Re:Reading Logs / Binary and Text

[Espectr0]

The only reason i can think to justify a binary log is to save disk space.

Re:Reading Logs / Binary and Text

[efitton]

Given the size of text logs I am guessing this isn't the actual reason. But the best I can come up with is: "Oh, Shiny!"

Much ado over nothing

[ebvwfbw]

Come on guys, we're not helpless Windows type people. Stuff changes. Go with it. I'm old guard, as in I used to make my own filesystems from a prototype old. Today you just mk*fs. Partitions are easy, even X11 is automatic to the point people probably don't even know they're running X11.

I loved the old stuff. Made a lot of money with it. Old, dated. Like with aircraft, autos, etc, time moves on. Adapt or be left behind.

The new way it boots, there's no question it's better. Just learn the new way.