Forgot your password?
typodupeerror
Operating Systems Windows Linux

You Got Your Windows In My Linux 613

Posted by Soulskill
from the entirely-uncontroversial-opinions dept.
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."
This discussion has been archived. No new comments can be posted.

You Got Your Windows In My Linux

Comments Filter:
  • by Brian Beaudoin (2848525) on Tuesday September 02, 2014 @05:30PM (#47811701)
    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.
  • by DoomSprinkles (1933266) on Tuesday September 02, 2014 @05:36PM (#47811755)
    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.
  • by Korgan (101803) on Tuesday September 02, 2014 @06:11PM (#47812147) Homepage

    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.

  • by machineghost (622031) on Tuesday September 02, 2014 @06:19PM (#47812209)

    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.

  • by SumDog (466607) on Tuesday September 02, 2014 @06:19PM (#47812217) Homepage Journal

    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:Troll much? (Score:5, Informative)

    by Junta (36770) on Tuesday September 02, 2014 @06:36PM (#47812345)

    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.

  • by Anonymous Coward on Tuesday September 02, 2014 @07:48PM (#47812973)

    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:Troll much? (Score:2, Informative)

    by Rich0 (548339) on Tuesday September 02, 2014 @09:14PM (#47813439) Homepage

    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.

  • by Anonymous Coward on Tuesday September 02, 2014 @11:25PM (#47814103)

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

    - or -

    $ journalctl -f | ./your_filtering_script.sh

    Was that so hard?

  • by ustolemyname (1301665) on Tuesday September 02, 2014 @11:55PM (#47814191)

    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?

  • by julesh (229690) on Wednesday September 03, 2014 @01:10AM (#47814381)

    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.

  • by squiggleslash (241428) on Wednesday September 03, 2014 @06:35AM (#47815403) Homepage Journal

    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.

Truth is free, but information costs.

Working...