Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Operating Systems Windows Linux

You Got Your Windows In My Linux 613 613

snydeq writes: Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD, writes Deep End's Paul Venezia. "Although there are those who think the systemd debate has been decided in favor of systemd, the exceedingly loud protests on message boards, forums, and the posts I wrote over the past two weeks would indicate otherwise. I've seen many declarations of victory for systemd, now that Red Hat has forced it into the enterprise with the release of RHEL 7. I don't think it's that easy. ... Go ahead, kids, spackle over all of that unsightly runlevel stuff. Paint over init and cron, pam and login. Put all of that into PID1 along with dbus. Make it all pretty and whisper sweet nothings about how it's all taken care of and you won't have to read a manual or learn any silly command-line stuff. Tune your distribution for desktop workloads. Go reinvent Windows."
This discussion has been archived. No new comments can be posted.

You Got Your Windows In My Linux

Comments Filter:
  • by recoiledsnake (879048) on Tuesday September 02, 2014 @06:20PM (#47811597)

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

  • by Virtucon (127420) on Tuesday September 02, 2014 @06:24PM (#47811641)

    Nothing really. It's just different. All of this sounds remotely familiar to the System V wars aka UNIX wars of the late 80s and early 90s. [wikipedia.org]
    That didn't solve much either except it allowed a company from Washington dominate servers and high-end desktops for awhile because it wasn't caught up in all of the holy war shit.

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

    Ummmm ... it's closed source. I'm sure there are lots of other good reasons, but do you really need anything more than that?

  • The Future! (Score:5, Insightful)

    by elysiuan (762931) on Tuesday September 02, 2014 @06:28PM (#47811681) Homepage

    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

  • Dun matter (Score:3, Insightful)

    by Conceptualizing (3785843) on Tuesday September 02, 2014 @06:32PM (#47811725)
    "[...] the exceedingly loud protests on message boards, forums" - and all other places that don't matter
  • by gandhi_2 (1108023) on Tuesday September 02, 2014 @06:34PM (#47811749) Homepage

    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:The Future! (Score:5, Insightful)

    by Lotana (842533) on Tuesday September 02, 2014 @06:43PM (#47811843)

    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.

  • by Anonymous Coward on Tuesday September 02, 2014 @06:45PM (#47811865)

    This is *the* stupidest thing I've ever read on Slashdot. Holy crap. Can we mark this as spam and delete it?

  • Oh, the humanity! (Score:2, Insightful)

    by Spasmodeus (940657) on Tuesday September 02, 2014 @06:47PM (#47811895)

    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.

  • Re:The Future! (Score:2, Insightful)

    by elysiuan (762931) on Tuesday September 02, 2014 @06:48PM (#47811907) Homepage

    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.

  • by whoever57 (658626) on Tuesday September 02, 2014 @06:53PM (#47811941) Journal

    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:The Future! (Score:5, Insightful)

    by Kjella (173770) on Tuesday September 02, 2014 @07:16PM (#47812183) Homepage

    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! (Score:3, Insightful)

    by Skarjak (3492305) on Tuesday September 02, 2014 @07:21PM (#47812231)

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

    by Junta (36770) on Tuesday September 02, 2014 @07:21PM (#47812235)

    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

  • by nabsltd (1313397) on Tuesday September 02, 2014 @07:34PM (#47812331)

    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.

  • by Aboroth (1841308) on Tuesday September 02, 2014 @07:43PM (#47812419)
    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:Troll much? (Score:4, Insightful)

    by Junta (36770) on Tuesday September 02, 2014 @07:49PM (#47812489)

    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.

  • by fisted (2295862) on Tuesday September 02, 2014 @08:04PM (#47812631)
    Did that. Not regretting it.
  • by elgatozorbas (783538) on Tuesday September 02, 2014 @08:08PM (#47812683)

    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.

  • by Anonymous Coward on Tuesday September 02, 2014 @08:30PM (#47812865)

    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.

  • by Korgan (101803) on Tuesday September 02, 2014 @09:08PM (#47813071) Homepage

    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.

  • by Culture20 (968837) on Tuesday September 02, 2014 @09:34PM (#47813213)
    This is what I was saving my mod points for. Too bad they expired.
  • by phantomfive (622387) on Tuesday September 02, 2014 @09:55PM (#47813319) Journal

    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.

  • by Mr_Wisenheimer (3534031) on Tuesday September 02, 2014 @09:58PM (#47813333)

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

  • by dbIII (701233) on Tuesday September 02, 2014 @10:00PM (#47813345)
    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:Troll much? (Score:5, Insightful)

    by Anonymous Coward on Tuesday September 02, 2014 @10:08PM (#47813389)

    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.

     

  • by Korgan (101803) on Tuesday September 02, 2014 @10:13PM (#47813425) Homepage

    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.

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

  • by Zeio (325157) on Tuesday September 02, 2014 @10:48PM (#47813621)

    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:The Future! (Score:5, Insightful)

    by Lotana (842533) on Tuesday September 02, 2014 @11:08PM (#47813731)

    I respectfully disagree. Fragmentation impacts both developers and the end users.

    Developers:
    There are a finite pool of people that have the knowledge to improve/write software. That group is further divided down into those that have the time and motivation to contribute to the open-source software. From there they are further divided among the competing projects that are doing the same thing. Example: GNOME 3 vs Cinnamon vs MATE vs KDE vs Trinity. Debian vs Red Hat vs Arch vs Suse vs Slackware. Therefore this fragmentation needlessly reduces the pool of available contributors.

    Also, any software package needs to be maintained for so many different configurations. A very good example is the package management: Debian, Red Hat, Gentoo, Slackware each have their own package format. This fragmentation adds more boring workload on the maintainers. Now that we will have distributions with or without systemd, it means that if the software deals with the area affected, TWO versions need to be developed! Doing something twice is again wasted effort.

    End User:
    Fragmentation adversely affects the user because the software he/she needs may not be available for the configuration that it being used. It is hard to come up with example for systemd since it is such a system-level system. Much easier to use an example of window-manager fragmentation: A certain package may look terrible on the one that the user chose.

    Even if the software is available, documentation may be only written for another distribution.

    Finally, the user needs to choose a distribution to start with. The choice is literally overwhelming. Have a look at this timeline: Distribution Timeline [wikimedia.org]. Now imagine it exploding even further into systemd using/rejecting versions. That much amount of choice is paralyzing.

    In the end, fragmentation just wastes resources on doing the same things more than once. It is necessary if the constrain is quite severe, but right now in the community forks happen over something as trivial as library versions or the visual look!

  • by grcumb (781340) on Tuesday September 02, 2014 @11:33PM (#47813853) Homepage Journal

    I would be interested in the anyone's response to Lennart Poetterings rebuttal [0pointer.de] to the common complaints about systemd.

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

    Full disclosure: I do not like systemd, although that judgment is based on its merits as I see them relative to my needs.

    There seemed to be a pretty concerted determination not to get the point in Lennart's long spiel defending the system. As someone who has been using Unices in anger since the early '90s, I've pretty much seen Linux grow from its infancy. I've seen this kind of attitude before in technology — in Windows, Linux and elsewhere. The article is clearly written (and written clearly) by someone who's clever, articulate and... far too concerned with being right. It's not a healthy perspective.

    Being technically correct is not generally optional. It's just not ever nearly as conclusive as some people think it is.

    Having the humility to accept an imperfect universe — and to admit that it's imperfect in a particular way for a large number of particular reasons — is a virtue that fewer and fewer people seem to possess these days.

    (It's the lack of this virtue that makes people say, for example, 'less and less' where I used 'fewer and fewer' and when someone corrects them, they trot out the grammar nazi epithet and say, 'Everybody knows what I mean. Deal with it.' And the lack of this virtue as well that will make people pick on the triviality of this example to discard my entire post. The temerity of such an approach cannot be explained to those who suffer from it.)

    Systemd is clearly not change for change's sake. Lennart and the dozen and a half others who have commit rights are clearly scratching an itch. But regardless of the technical merits of the system, it is horribly, horribly wrong to impose this new system —any new system— on Linux wholesale without a significant maturing process. And by significant, I mean years.

    And this is where Lennart's most completely mistaken. He thinks that the technical arguments are the decisive ones, in spite of the fact that technical merit is not why systemd is going to become prevalent. He therefore tries to write a technical opus in defence of the indefensible, which requires more than a few straw men (binary config files? shyeah....), several big ommissions (binary log files) and a clearly unwilled but nonetheless unforgivable ignorance of the fact that he's winning because he's RedHat, not because he's better. (Yeah yeah yeah, it's not all RH; it's others too, you're technically awesome - I read that part and remain utterly unconvinced by the argument.)

    Paul Venezia's screed, on the other hand, is just plain substance-free. He's not arguing either technical merit or political power. He's simply looking at a looming mess and saying, well, that it's going to be messy. And to that extent, he's right. Systemd is going to make a mess, and that's precisely because its proponents think that they're perfectly within their rights to claim, 'Well, nobody's forcing anything on anyone.'

    What they don't realise is that that is not how cooperation works. And believing you're better or righter than others is an absolutely shit way of improving your own software.

  • by lister king of smeg (2481612) on Wednesday September 03, 2014 @12:52AM (#47814169)

    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.

  • I've used it and could list SystemD's various technical issues, but that isn't and never has been the point.

    The complaints we have about SystemD - and the Poettering cabal in geneal - is not about any technical issues. Bugs can be fixed; bad design, antisocial not-invented-here attitudes, and disregard/blindness to any use case outside their experience are what we have been complaining about. After about 2 years of arguing the topic, we've had to add rudeness, blatant propaganda, and attempts to bully opposing views to the list of complaints.

    Typically, SystemD defenders - such as yourself - spend a lot of time and effort disrupting forums and discussion threads by posting strawmen, non-sequiters, or simply praising SystemD as it applies to very narrow use-cases. Recently, the tactic has bene what you are doing right now: accuse the opposition of being "old" or "luddite" or "hating change". It is quite telling, actually: a big complaint against SystemD's development style (as mentioned in this article if you bothered to RTFA) is that they don't bother to understand how people outside their immediate group actually use their computers, or what their needs are. Comments like this are exactly what we're talking about.

    Nobody has been saying systemd should be banned or that you wanting to use it is bad. Nobody has said OpenRC or sysvinit should be the only option. If some tool solves problems for you or make your life easier - or even if you just like the tool's style/asthetics - then use it. What we're complaining about, more than anything else, is the tight coupling that SystemD has been doing, as it prevents everbody else from having that same freedom of choice.

    Once, a very long time ago (internet years) when an image of a certain borg-ified CEO was common, there was a phrase that was commonly used to describe Microsoft's monopolistic actions against competing technologies: embrace, extend and extinguish [wikipedia.org]. Many discussions on slashdot warned about how Microsoft was trying to "embrace and extend" various standards such as Kerberos [drdobbs.com].

    So instult us if you like - it makes our arguments against SystemD's attitude for us. You can even sit in ignorance, if you desire, while Poettering embraces and extends linux so he can remove all the useful parts form it. The rest of us that have watched this happen before will continue using Free Software that preserves freedoms such as the freedom to choose your init system. We have been marginalized and a social outcast in the past and are used to crap like this. Just remember that it was that same freedom of choice that provided a place for SystemD to be developed in the first place.

  • by julesh (229690) on Wednesday September 03, 2014 @02:14AM (#47814399)

    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.

  • by sjames (1099) on Wednesday September 03, 2014 @03:16AM (#47814567) Homepage

    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.

  • by sjames (1099) on Wednesday September 03, 2014 @03:29AM (#47814607) Homepage

    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.

  • by sjames (1099) on Wednesday September 03, 2014 @04:55AM (#47814901) Homepage

    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

  • by jeremyp (130771) on Wednesday September 03, 2014 @05:58AM (#47815057) Homepage Journal

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

  • by squiggleslash (241428) on Wednesday September 03, 2014 @07:24AM (#47815351) Homepage Journal

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

    by Culture20 (968837) on Wednesday September 03, 2014 @09:11AM (#47815865)

    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?

  • by psmears (629712) on Wednesday September 03, 2014 @10:04AM (#47816219)

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

  • by sjames (1099) on Wednesday September 03, 2014 @10:32AM (#47816425) Homepage

    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.

With all the fancy scientists in the world, why can't they just once build a nuclear balm?

Working...