Slashdot Mirror

← Back to Stories (view on slashdot.org)

Systemd Adding Its Own Console To Linux Systems

Posted by Soulskill on from the if-you-want-something-done-right dept.

An anonymous reader writes: The next version of systemd is poised to introduce an experimental "systemd-consoled" that serves as a user-space console daemon. The consoled furthers the Linux developers' goal of eventually deprecating the VT subsystem found within the Linux kernel in favor of a user-space driven terminal that supports better localization, increased security, and greater robustness of the kernel's seldom touched and hairy CONFIG_VT'ed code.

107 of 774 comments (clear)

  1. Is this a troll about systemd or is this real news by NotInHere · · Score: 4, Informative

    srsly?

  2. Please stop this madness! by Anonymous Coward · · Score: 4, Interesting

    Few people want systemd at all. Why it is being forced on us?
    Please stop this madness!

    1. Re:Please stop this madness! by Anonymous Coward · · Score: 5, Insightful

      Perhaps it's time for an "Ask Lennart Poettering".

      I still remember spending a summer loving the FreeBSD single do-all config file (it was the 90s) and being annoyed at Linux's confusing mess of an init system. It's not like Linux init is actually good... it's just a thing you know.

    2. Re:Please stop this madness! by Barsteward · · Score: 2

      the majority of desktop users don't care, its only the few vocal few that do for various reasons either because they are Luddites or it'll ruin their working day to learn something new or they have to re-factor their servers for the new ways. i don't care either way as long as my opensuse system keeps working as it has done since the changeover. if i was administrating servers, it may care if i had to throw away a load of scripts i no longer need

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    3. Re:Please stop this madness! by The+Technomancer · · Score: 4, Insightful

      It's less about rewriting scripts (from my understanding, systemd does a bang-up job of supporting init scripts unmodified), and more about the major distributions in use on the server side of the house (RedHat and its derivatives, Debian and its derivates) making it the New Way Forward. It may very well be an improvement over the current init system. For desktops and mobile where boot time matters significantly more than stability, it should be the new way forward.

      But on the server side, nobody gives a crap about boot time. If you're on physical hardware, it should be happening rarely. If you're using a cloud architecture, it should happen all of once per instance. To keep my log management installations working properly, I need to add the extra overhead layer of having systemd's binary logs reprocessed and forwarded to syslog. Not a big deal until you do the math and realize that an extra half percent of overhead is an extra box or instance needed per 200. I also ned to devote sysadmin or devops time to doing some thorough testing for stability.

      This is all a very roundabout way of saying that it's unclear if systemd is an improvement for the server side of things, and that even if it is an improvement, it's not enough of one to be worth all of the resources needed in an enterprise-grade installation to justify switching to it, nor am I comfortable being an early adopter on anything other than my personal lab kit.

      As far as the developer goes? He wrote software. It's not his fault that the project managers of the major distros have decided that shooting for the desktop and mobile is more important than supporting the server side people that have been paying their bills for decades. Be pissed at them for this.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    4. Re:Please stop this madness! by AdamWill · · Score: 3, Informative

      systemd is not about boot time.

    5. Re:Please stop this madness! by The+Technomancer · · Score: 2

      Seems to me that's the largest reason it's being pushed, and then got expanded to be everything from your syslogger to your messaging bus to your replacement for supervisord/xinetd, and so on and so forth. The secondary reason appears to have something to do with GUI application operation, which as an infrastructure engineer, I don't give a crap about. In the short term, it means I'm probably going to work on migrating to Amazon Linux in the short term, since it's the most RHEL-like distro not moving to systemd, while keeping an eye on how systemd fares at the enterprise level. If it becomes the new normal and gets some heavy, real-world testing on it and holds up, I'll switch to it then since it'll end up being the new normal on the enterprise. If it blows up under real-world conditions and threat vectors, it'll be someone else's installation that eats shit, not mine.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

    6. Re:Please stop this madness! by AdamWill · · Score: 3, Informative

      It's been running under 'real-world conditions' for years already - do you think no-one runs real-world systems on Fedora, or that Red Hat doesn't run releases in production internally before they go out, or that RH has no customers who test pre-releases?

      "Seems to me that's the largest reason it's being pushed"

      Nope. I think this impression originally came from Lennart's original post on systemd, years and years ago - http://0pointer.de/blog/projec... - because it starts out talking about boot speed. But even that very first post moves on, in the sections "Keeping Track of Processes" and later, to talk about the really interesting bits of systemd - better service management, and more capable service configuration. As systemd development continued, it's become much more about the latter and much less about boot times - I think that's where Lennart *started* thinking about systemd, but it's really not what systemd is for any more. Red Hat certainly wasn't interested in systemd because it might make servers boot three seconds faster, RH was interested because it can make service management on servers much better.

    7. Re:Please stop this madness! by The+Technomancer · · Score: 2

      It's been running under 'real-world conditions' for years already - do you think no-one runs real-world systems on Fedora, or that Red Hat doesn't run releases in production internally before they go out, or that RH has no customers who test pre-releases?

      There are zero enterprise-level installations of Fedora on the infrastructure side of the house. RedHat's internal servers aren't taking a million or so requests per second, nor does their infrastructure buildout hit the 5 digit+ range of servers and instances. Someone's collection of LAMP stack instances behind an ELB is not representative of what I have to deal with every day.

      As far as the rest of it? Systemd tries to solve problems that don't need to be solved at the enterprise level. If I don't like to use xinetd as a superserver, I can use supervisord. In reality, I'm using neither because I have monit scripts in place to manage server processes I care about.

      I don't manage my system configuration at the system level -- that's what Chef or Puppet or Ansible or Salt does for me. I template it out and let central config management keep the servers in sync. At the scale I work at, the rule "do it once by hand, script it if you have to do it more than once" breaks down, because if I'm doing something once on one server in production, I'm probably wrong.

      This is why in the eyes of infrastructure engineers with an installation large enough to justify the use of config management software, systemd offers nothing except a headache for large, existing installations. Meanwhile, I can very safely state that certain vendors are going to be very, very unhappy when they start losing seven-figure+ contracts over this, or only get them under the requirement that they continue to support and patch the last good non-systemd release.

      Either that, or it'll finally let me convince my boss that it's time to start rolling our own distro and I can use that saved money to hire some engineers to maintain it.

      All your posts are doing is showing that you haven't had to deal with a large-scale installation in your career. That's fine -- there's plenty of rockstar engineers in startups and medium-scale shops. Just don't try to tell me what's good for me when you haven't experienced it for yourself.

      --
      Any sufficiently advanced technology is indistinguishable from magic.

      -- Arthur C. Clarke

  3. it solves some unicode issues by behrooz0az · · Score: 5, Insightful

    Why is everyone so mad about it?
    Is it really just me that has a shitload of problems with the current VT?

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
    1. Re:it solves some unicode issues by Anonymous Coward · · Score: 5, Insightful

      systemd is turning into an operating system, rather than a service.

      When your startup manager becomes more important than the kernel, you might want to rethink your design philosophy.

    2. Re:it solves some unicode issues by sxpert · · Score: 2

      either that, or lennart is using linux as a host os while he's writing his own... it will soon be time to jettison this crap !

    3. Re:it solves some unicode issues by BarbaraHudson · · Score: 3, Interesting

      I've played around with the kernel api for manipulating the virtual terminals. It was nice to be able to select from a 256*256*256 color palette for the 16 colors (same as I did in DOS OMG ages ago when I saw my copy of Alpha4 do it, and figured *I* could do it to).

      Will I miss the VTs? Yes, because none of the software terminals running under X can do this.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    4. Re:it solves some unicode issues by UnknowingFool · · Score: 4, Insightful

      Systemd goes against the KISS principle that Linux and Unix have long followed. However, many would argue that Linux has become too complex for this principle to work when it comes to system management. For user space, it is becoming more of necessity. Those who are using Linux on server side, it seems to solve a problem that doesn't exist.

      --
      Well, there's spam egg sausage and spam, that's not got much spam in it.
    5. Re:it solves some unicode issues by caseih · · Score: 4, Insightful

      Oh really? From the sound of it, VT code in the kernel hasn't been KISS in a long time, certainly not since KML was introduced. Was KML a solution in search of a problem? Hardly. The VT code is full of hacks, bugs, and hard to fix and improve. And we're not just referring to the lack of unicode support, which isn't hugely important. This knee-jerk reaction to systemd is way silly too. One would think Linux users would understand that moving things out of the kernel into userspace is desirable, especially on a server, and especially in an environment where virtualization is the norm. Besides all this,you could just, you know, not run the systemd console daemon. Linux has always supported serial terminals, and will continue to do so. If you're a hardcore server operator (physical or virtual servers) I'm sure you already have this set up.

    6. Re:it solves some unicode issues by smash · · Score: 3, Informative

      Because time and again, Lennart and the systemd team have demonstrated that bug fixes in their software are not a priority, compatibility with applications is not a priority, and by re-writing something that works you inevitably introduce new bugs.

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    7. Re:it solves some unicode issues by rainmaestro · · Score: 2

      People are mad because of who is doing the replacement. Lennart has a consistent track record of releasing code that breaks the world and then blaming the breakage on the users and distros not using his masterpieces correctly. This is someone who publicly advocates breaking POSIX compatibility.

      He's a very talented coder, but shouldn't be allowed anywhere near an OS that needs to remain usable. Unfortunately, his Red Hat ties mean we're stuck cleaning up his messes, and this VT replacement will be yet another mess for the first two years.

    8. Re:it solves some unicode issues by kthreadd · · Score: 4, Insightful

      Systemd is not monolithic. It takes a number of components that used to be developed separately and streamlines them under the same roof, making them work better together. It's is not and there has never been the idea that everything under the sun should go into the same binary.

    9. Re:it solves some unicode issues by BasilBrush · · Score: 3, Insightful

      And we're not just referring to the lack of unicode support, which isn't hugely important.

      ... for the minority of the world who are English language speakers. For most foreign language speakers it is.

    10. Re:it solves some unicode issues by fisted · · Score: 5, Informative

      No, is monolithic Note the part where he repeatedly gibbers about that stuff is impossible to separate.

      --
      CLI paste? paste.pr0.tips!
    11. Re:it solves some unicode issues by rahvin112 · · Score: 3, Interesting

      You know who else advocates breaking POSIX? Linus. Frankly I've never understood why the kernel managed VT anyway. It should be in userspace. Maybe there is an argument it shouldn't be part of SystemD but frankly it's a good thing that this is moving out of the kernel. The kernel shouldn't be managing this stuff anyway.

    12. Re:it solves some unicode issues by poizan42 · · Score: 2, Insightful

      I don't think you know what "monolithic" means. No one said anything about everything being in the same binary. systemd consists of several components that has been designed to only work with each other. There is no modularity in the sense that there is no modules you can replace or decide whether or not to use.

    13. Re:it solves some unicode issues by rainmaestro · · Score: 4, Insightful

      Don't get me wrong, I disagree with a number of decisions Linus has made. But he tends to be more controlled than Lennart in that regard. His approach is to ignore POSIX when it makes sense to do so (eg, when the standard is too vague to be practical). Lennart seems to want to throw the whole standard away straight out.

      I support replacing VT, it is a mess. A mostly working mess, but it could be much better. I just don't trust anything Lennart writes at this point.

    14. Re:it solves some unicode issues by M1FCJ · · Score: 2

      That's a very good response time, 13 months. If it hasn't brought everything down, it's safe to ignore the issue after so much time, right? At least that's how Microsoft operates...

    15. Re:it solves some unicode issues by Barsteward · · Score: 2

      Monolyth - dictionary definition
      noun
      1. an obelisk, column, large statue, etc., formed of a single block of stone.
      2. a single block or piece of stone of considerable size, especially when used in architecture or sculpture.
      3. something having a uniform, massive, redoubtable, or inflexible quality or character.

      Modular - dictionary definition
      noun
      5. something, as a house or piece of furniture, built or organized in self-contained units or sections.
      6. a self-contained unit or item, as of furniture, that can be combined or interchanged with others like it to create different shapes or designs.

      its amazing how people bastardise definitions to suit their arguments.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    16. Re:it solves some unicode issues by kthreadd · · Score: 4, Interesting

      A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.

    17. Re:it solves some unicode issues by nabsltd · · Score: 3, Informative

      its amazing how people bastardise definitions to suit their arguments.

      I fail to see how the GP used the terms in any way other than what you listed for definitions.

      Even though systemd is made up of multiple separate binaries, it is "[has] a uniform, massive, redoubtable, or inflexible quality or character", since you can't replace any one of those binaries with an alternative. Each of the individual binaries cannot "be combined or interchanged with others like it to create different shapes or designs", which means it isn't "modular", but is "monolithic".

      Also, you still missed the most appropriate definition of "modular" for software: "employing or involving a module or modules as the basis of design or construction". Again, although systemd uses separate binaries, there is no way to replace any one of those binaries with an alternative, so the net effect is no different from a single binary that happens to be made up of 69 object files compiled from 69 source files.

    18. Re:it solves some unicode issues by danomac · · Score: 2

      Lennart has a consistent track record of releasing code that breaks the world and then blaming the breakage on the users and distros not using his masterpieces correctly.

      Hmm, was his previous employer Apple by any chance?

    19. Re:it solves some unicode issues by AdamWill · · Score: 2

      Doomed to be buried in /. hysteria, but just for the record: Lennart is not writing this. David Hermann is. systemd is not a one-person project.

    20. Re:it solves some unicode issues by Jesus_666 · · Score: 3, Interesting

      The basic idea (replacing the old VT code with something new and better) seems fine; the only problem is that it's yet another component that will be integrated with systemd. If the old VT code is completely deprecated in favor of systemd-consoled that means that yet another part of the Linux world has dependencies on systemd.

      While that may be fine if you run the kind of system systemd expects, it's problematic if you want to use, say, an embedded system built around uclibc instead of glibc. To my knowledge, systemd still refuses to incorporate libc compatibility patches and thus won't run unless you use their preferred libc flavor. Trying to make your embeddded Linux distro work without systemd will mean that you either have to write and maintain your own console daemon or live without virtual terminals. Or, of course, you can move to glibc and systemd, even if your distro would be better served by lighter alternatives.

      I think that the systemd subprojects would be more popular if they were less dependent on each other... and if the developers had less of a "my way of the highway" attitude.

      --
      USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
    21. Re:it solves some unicode issues by 0123456 · · Score: 4, Informative

      A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.

      It is when they're all tied together so tightly that you're forced to take all or nothing.

      That's the fundamental problem with systemd. This man's last major project was pulseaudio, which most Linux users know only because an entire generation learned that it was the first thing they should uninstall after installing a new Linux release. Years later, it works OK, but only after years of suck beforehand.

      You don't get that 'just unininstall it' option with systemd.

    22. Re:it solves some unicode issues by Rich0 · · Score: 4, Interesting

      A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.

      It is when they're all tied together so tightly that you're forced to take all or nothing.

      Really? I'm certainly not using every systemd binary on every one of my systems, and the others work just fine. Do you have an example of a case where there is unnecessary inter-dependence?

    23. Re:it solves some unicode issues by Rich0 · · Score: 2

      When your startup manager becomes more important than the kernel, you might want to rethink your design philosophy.

      Uh, you do realize that Debian on FreeBSD resembles Debian on Linux a lot more than Debian on Linux resembles Tivo on Linux, right?

      The whole point of the kernel is for it to be in the background. Userspace defines the user experience almost entirely.

    24. Re:it solves some unicode issues by chihowa · · Score: 2

      monolithic: (of an organization or system) large, powerful (sic), and intractably indivisible and uniform.

      Being composed of different absolutely interdependent binaries is functionally indistinguishable from being a single binary composed of absolutely interdependent functions. It's the intractably indivisibility that makes it monolithic. You can't, for example, use this VT replacement without the rest of systemd. Thus, it's monolithic.

      Monolithic (in this case) is the description of an architecture.

      --
      If you want a vision of the future, imagine a youtube comments section scrolling - forever.
    25. Re:it solves some unicode issues by IamTheRealMike · · Score: 4, Interesting

      I haven't used desktop Linux for about a year now, but before that I used it for about a decade and in the early 2000's even did development for it, so I read this post with interest.

      I feel the money quote is this one:

      People on the email thread have claimed we had an agenda. That's actually certainly true, everybody has one. Ours is to create a good, somewhat unified, integrated operating system. And that's pretty much all that is to our agenda. What is not on our agenda though is "destroying UNIX", "land grabbing", or "lock-in". Note that logind, kdbus or the cgroup stuff is new technology, we didn't break anything by simply writing it. Hence we are not regressing, we are just adding new components that we believe are highly interesting to people (and they apparently are, because people are making use of it now). For us having a simple design and a simple code base is a lot more important than trying to accommodate for distros that want to combine everything with everything else. I understand that that is what matters to many Debian people, but it's admittedly not a priority for us.

      For what it's worth, this paragraph makes a ton of sense to me. The biggest problem with Linux, both on the desktop and to a lesser extent on the server, was the fact that you got a basically half-baked set of components that were hardly integrated at all. Basic stuff like being able to set the timezone graphically ended up being distro specific apps / hacks because there was no API to do it, and everything was held together by giant piles of shell scripts and Python which might or might not be something you could actually contribute to or work with, but was certainly never usefully documented.

      Basically, the experience of using or developing on Linux gave you the impression of a man in a slightly dishevelled, ill fitting suit. All the parts of a smart suit were there, but none of them quite fitted or lined up, and there were lots of small tears everywhere. And waaaaaay too many people liked this state of affairs because they had made "I am a UNIX user" a part of their identity and had managed to convince themselves that an OS architecture that dated from the 1970's was actually totally elite, and any attempt to reform it was "ignoring the UNIX philosophy" or some shit like that.

      Result: MacOS X absolutely ate Linux's lunch on the desktop, despite the fact that Linux was free and Macs .... decidedly not free. Heck Linux didn't even make much headway against Windows, even though under Ballmer the Windows team basically sat on their ass for a decade rewriting the start menu.

      From a (now) outsider looking in, this whole systemd fiasco looks a lot like Linux finally being dragged into the 21st century through the sheer willpower of one man, who has an apparently infinite ability to withstand faeces-throwing by the UNIX peanut gallery. Don't like systemd? OK, stick with Debian Stable or FreeBSD and don't get the new features. Stick it to the man and keep your "I Love *Nix" t-shirt on. Me? Between reading about GNOME 3 and systemd I'm starting to wonder if it's time to revisit Linux and give it another shot. If that community can conquer its UNIX fetish and build a modern OS, it has a lot of potential.

    26. Re:it solves some unicode issues by TechyImmigrant · · Score: 2

      Systemd is not monolithic. It takes a number of components that used to be developed separately and streamlines them under the same roof, making them work better together. It's is not and there has never been the idea that everything under the sun should go into the same binary.

      The dependencies make the monolith, not the lack of modules.

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
    27. Re:it solves some unicode issues by segedunum · · Score: 2

      Fucking hell. The whole point of plain text logs, readable by standard tools, is that you can always find out what happened and if you run this on a server it is of vital importance. Anyone with half a brain cell of intelligence knows that giving that up in favour of a binary logging system knows this is a risk, therefore it needs to be investigated and fixed when it occurs. Developers have to be more interested than 'nothing we really need to fix hence'.

      Let me tell you I do not want to have to deal with that shit at some ungodly hour. This is Windows Event Viewer crap.

    28. Re:it solves some unicode issues by segedunum · · Score: 2

      I mean, some of us are legally required to keep logs. Look at that piece of meaningless crap Lennart posts as a final response to this.

      Posted as AC? Check. Comment blames crazy user? Check. Is that you Lennart?

    29. Re:it solves some unicode issues by Rich0 · · Score: 2

      Can you remove logind and journald from systemd?

      About as well as you can remove the preprocessor from gcc. Not every component of systemd is easy to get by without. In the case of journald you can operate it in non-persistent mode, so that it doesn't actually write any logs to disk.

      Some systemd components are more essential than others, which is usually the case with modular software. Kde is modular, but good luck deleting kdelibs.

    30. Re:it solves some unicode issues by Lesrahpem · · Score: 2

      For what it's worth, this paragraph makes a ton of sense to me. The biggest problem with Linux, both on the desktop and to a lesser extent on the server, was the fact that you got a basically half-baked set of components that were hardly integrated at all.

      Lack of integration is what makes these things flexible. As soon as we codify One True Way of integration that flexibility will be gone.

      I'm an insane person though. I use Gentoo and Slackware in production.

    31. Re:it solves some unicode issues by bingoUV · · Score: 2

      About as well as you can remove the preprocessor from gcc

      And with respect to preprocessor , no one calls gcc non-monolithic.

      In the case of journald you can operate it in non-persistent mode, so that it doesn't actually write any logs to disk.

      But not giving direct access to syslog, only forwarding to syslog. So with respect to log system - it is monolithic. Say an operating system where you could have vi (or other editor) but only after emacs forwards editing commands to vi. That operating system would be called monolithic with respect to text editors.

      Kde is modular, but good luck deleting kdelibs.

      KDE is modular in many respects, but not with respect to not needing kdelibs. It is modular in being able to replace window manager, network-manager. At code level it might be modular in replacing some libraries, UI widgets, I am not too sure.

      Systemd is NOT modular where it matters. If journald could be completely replaced with syslogd, without the forwarding business, it could have been called modular with respect to log system. Why should one lose the ability to view non-corrupted text logs from bootloader just to get an init replacement?

      --
      Bingo Dictionary - Pragmatist, n. A myopic idealist.
    32. Re:it solves some unicode issues by Rich0 · · Score: 2

      Systemd is NOT modular where it matters.

      Well, that depends on what matters to you. You can use systemd without many of its components. Just not without those. And I'm not really sure why you care if the log traffic is forwarded vs direct.

      Why should one lose the ability to view non-corrupted [freedesktop.org] text logs from bootloader just to get an init replacement?

      People keep quoting that bug, but it doesn't make it true. In what way does journald corrupt log files any more than any other logger? I think it is just more visible because it can actually detect if a log file wasn't cleanly closed. If you pull the plug on a system running syslog you could end up with truncated log files, but syslog will just happily keep appending to them making the error non-apparent until you try to actually parse the logs programatically.

      Journald still reads whatever it can out of a log file - it just doesn't try to interpret half-records.

  4. Awesome! by Delicious+Pun · · Score: 5, Funny

    All systemd needs now is an integrated web browser and a registry!

    1. Re:Awesome! by Megane · · Score: 2

      let's replace it all with emacs

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    2. Re:Awesome! by godrik · · Score: 3, Insightful

      This should not be tagged funny! This should be tagged depressing.
      What I really don't understand is "why is this part of systemd and not a separate program?" I can only see two answers:

      -Because it has to be tightly integrated with systemd. In this case, I would rather we do not clutter a critical system component with more unnecessary code such as a console implementation.

      -Because it is a tactic to get it deployed as part of the systemd package. In which case, systemd really starts looking like a attempt at conquering the world. I feel like that is exactly what it is here.

  5. So? by PvtVoid · · Score: 2

    As long as I can still run vi in it, I'm good.

    1. Re:So? by TangoMargarine · · Score: 4, Funny

      Joke's on you--next they'll merge vi into systemd.

      OH GOD IT BURNSSSS

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    2. Re:So? by TechyImmigrant · · Score: 2

      Joke's on you--next they'll merge vi into systemd.

      OH GOD IT BURNSSSS

      Too late

      [root@xxxxxxx ~]# ls /usr/lib/systemd/systemd-vid
      /usr/lib/systemd/systemd-vid

      --
      I should use this sig to advertise my book ISBN-13 : 978-1501515132.
  6. Or we learn from others mistakes by Anonymous Coward · · Score: 5, Interesting

    Does anyone really want "better localization" in terminals. My experience as a bilingual user from windows is that the less things are localized the better they work.
    Making commands localized breaks script compatibility. (And that includes any output if that is parsed too.)
    It has gone to the point where I get the English version of Windows rather than one adapted to my native language. The localization of some of the folder names makes things break and the translation of GUI elements obfuscates the function and makes it so that one has to translate everything to English and back to realize what the function is, especially when the original translator used every synonym for "device" he could possibly find.

    Unless they have found a new revolutionary way to localize stuff that haven't been done before. Then it might actually work.

    1. Re:Or we learn from others mistakes by gnasher719 · · Score: 4, Insightful

      I cringe everytime I see "é" "Ã" or "Ã" in folder/file names.

      I cringe every time someone has a problem with accented characters in folder or file names.

      And it doesn't break any programs. Those programs are broken already.

    2. Re:Or we learn from others mistakes by caseih · · Score: 3, Informative

      I can tell you don't use Linux on a regular basis. Don't mistakenly think that Windows' broken localization applies to Linux. The Linux commandline and terminal has been localized for many years with no issues as you report.

      Maybe in Windows things are bad, but in Linux, scripts will work regardless of the localization. The command names don't change, nor do the command-line options. But filenames and data certainly can be in any language. Unlike Windows, system folders do not change names. It's possible that grepping for specific output from programs will fail. But if you're doing that in your script, you can set the LANG variable to whatever language the you need (probably english to be most universal).

      Again, though, this has nothing to do with the idea of putting kernel VT code in userspace. There are valid arguments against this idea, but I've not read of any on slashdot yet. Just knee-jerk teeth knashing, and, sadly, more inappropriate ad hominom attacks.

    3. Re:Or we learn from others mistakes by BasilBrush · · Score: 4, Insightful

      It's 2014. There should be no forgiveness for software that doesn't use Unicode correctly. With the supposed superiority of open source and the ability of any programmer to dive in and fix bugs how is this still a problem for Linux?

    4. Re:Or we learn from others mistakes by Culture20 · · Score: 4, Funny

      You should neko a Japanese file instead.

    5. Re:Or we learn from others mistakes by ciroknight · · Score: 2

      Because when you try to fix it, you get a slashdot article posted with a hundred people saying how "you should go die in a fire."

      --
      "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
    6. Re:Or we learn from others mistakes by shutdown+-p+now · · Score: 2

      You know, some languages don't even use Latin letters in the first place. Are you telling people that they should just all learn and use English?

      Also, non-ASCII characters in filenames have worked for a long time on all mainstream OSes, including Linux. If any piece of software today doesn't handle that's right, it's crap.

  7. ... and the scope creep continues ... by CRC'99 · · Score: 2

    This is what is wrong with SystemD.... Do ONE job, do it well. Not replace the entire ecosystem.....

    --
    Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
    1. Re:... and the scope creep continues ... by phantomfive · · Score: 2

      Wow, your sig is perfect for this topic......someday people will say

      SystemD is like emacs: A nice operating system, if only it had a decent init system.

      --
      "First they came for the slanderers and i said nothing."
  8. Re:Because when something's not broken by Culture20 · · Score: 2

    Thirty seconds every six months on a system where the motherboard BIOS POST, each NIC firmware, the SCSI card firmware, spinning up the drives, and the RAID bios take around two to three minutes to complete. So not really much at all. I propose new features to systemd to parallelize the hardware components to server startups. And a pony. I want a pony.

  9. Re:hum by jedidiah · · Score: 2

    > What is with the SystemD bashing anyway?

    Like someone else already says. It violates the Unix design philosophy. It's a kitchen sink approach that creates unnecessary complexity, unnecessary dependencies, will be harder to work with, and will be more buggy.

    If you want the Windows approach to systems design you can just use that. There's no need to pollute something else.

    --
    A Pirate and a Puritan look the same on a balance sheet.
  10. Re:Just fucking leave it alone! by thieh · · Score: 3, Insightful

    openBSD should be more secure in comparison. Seriously though, the systemd people should look into limiting the interdependencies of their projects. That find of interlocking makes it lacking portability. If they want to replace VT, do that in a way that doesn't make it dependent to everything they have ever made.

  11. Coming soon: systemd appstored by koinu · · Score: 2

    ... because it can never be early enough to buy some apps.

  12. Re:at some point it isnt linux anymore. by Anonymous Coward · · Score: 2, Informative

    Poettering complains about the opensource community but he is one of the most abusive ones out there and his egotistical, almost psychopathic personality doesn't work well in a community.

    Here is a good example, his abuse starts at 12m https://www.youtube.com/watch?v=CmPKDeo9Oow

  13. Future headline... by QuietLagoon · · Score: 2

    The last vestige of Linux has been removed from the GNU/systemd distributions, as systemd continues to move forward.

  14. Re:UseLessD by smash · · Score: 4, Insightful

    Or you could use what we've been using for the past 20-30 years that has been debugged, proven to work and not completely different to the rest of the world.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  15. Re:Just fucking leave it alone! by Anonymous Coward · · Score: 3, Interesting

    Snowden's docs show that the NSA has ways into many operating systems including FreeBSD. OpenBSD has been notably absent from the slides I saw.

  16. Shut up and listen... by joelholdsworth · · Score: 5, Informative

    Before you go round acting like the sky is falling, try educating yourselves about why this is necessary. This is not just a systemd problem, this is a problem for any init system that wants to support multi-seat, and sane switching between VTs:

    Now you may say that OMG systemd is teh evil monolith!!1!!!, but before you do that understand that this has been an important feature that has been needed for a long time in any init system it just happened that SystemD solved it first.

  17. Re:UseLessD by CRCulver · · Score: 3, Informative

    The Debian leadership has already announced that systemd will remain a hard dependency for nearly all graphical applications, and no "systemd-lite" will be offered -- Debian has already deprecated its systemd-shim package that was meant to offer similar functionality to uselessd.

  18. Slashdot Response by inhuman_4 · · Score: 5, Insightful

    Article: Old, crusty, and possibly bug ridden part of the kernel is being moved to userspace. This new work will increase both the security and the stability of Linux systems, while adding the possibility of internationalization support.....

    Slashdot Comments: Finally some one is doing something about CONFIG_VT. People have been bitching about that for years!

    Article: this new feature is part of systemd.

    Slashdot Comments: NOOOO! Why is Lennart taking away my freedoms! I'm switching to BSD.

    It has gotten pretty clear that a lot of the hatred for systemd has nothing to do with the technical merits. This is a fix that has been a long time coming. Yet, almost half the comments are just more systemd hate fest.

    1. Re:Slashdot Response by nabsltd · · Score: 2

      Yup - it's not SystemD's fault for solving this problem first.

      It's systemd's problem for solving it in a non-portable way.

      If I could download a replacement "VTd" package, install it, and get the new features, that'd be great. Unfortunately, I have to replace the Linux kernel (so that the VTs there don't complete with systemd's version) plus replace config files for a bunch of other services that systemd replaces, plus verify that my startup scripts work with systemd, plus.... Get the point?

  19. Re:Why do people care so much? by DeHackEd · · Score: 5, Informative

    [Disclaimer: Yes I hate systemd and I proclaim that loudly. Everything below is my personal experience with systemd and why I hate it.]

    If booting the machine up was all it did, then I probably wouldn't care. Most of my hate (I can't speak for the rest of the internet) comes from the fact that systemd does a lot more. It also tracks user logins using a mechanism (control groups) that isn't available in some container scenarios making systemd unusable in those environments (and by extension any distro mandating systemd). It does its own logging in binary which needs a tool to read the logs and if it gets corrupted then systemd's devs say "just delete the logs". Really?

    But I think the best reason people hate it is because it makes other applications become dependent on it. GNOME is the most well known example but I've also seen that Centos7's Source RPMs have systemd-specific commands (macros?) making it hard to build them on other platforms. rsyslog doesn't listen on /dev/log because systemd is doing something with the socket now. You cannot start services without systemd being the one to do it.

    This is the hate. systemd isn't just an init system, it becomes part of your daily life. I liken it to the MCP (Master Contrl Progam) from the first TRON movie. It's systemd's way or the highway.

  20. Re:at some point it isnt linux anymore. by caseih · · Score: 3, Insightful

    Except that RC init wasn't fine. More than a few times over the years I've had a service that wouldn't start right on a server that actually prevented boot! Whether it was some stuck PID file that wasn't properly erased on boot, or some other race condition (often a network condition, or a chicken/egg problem), it happened enough that I modified inittab on all my servers to throw up a login console near the beginning of boot so I could at least log in to try to fix the problem. Ideally none of this should ever happen, but it did. Bugs are there. Combine that with the fact that init scripts are huge, fragile, hacks, and yes you can say sysv init has serious problems. As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script, and have little to no debugging capabilities, no process supervision, and no easy way to control how many instances of the daemon can run.

    All other major unix server vendors ditched sysv init for the same reasons as I state long ago. To my knowledge, of the major important players, only Linux and BSD still use sysv init. The world has not ended, and the sky has not fallen. Life goes on, and Unix and Linux continue to do well and provide stability and reliability. In fact, all I see here is vitriolic teeth knashing. I've yet to see anyone with a specific argument against systemd. It's really disappointing, actually. I think I read one criticism from a developer of another init system that was actually insightful and valid. Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice. RHEL's mailing list has nary a mention of it. It just works and works well. Uselessd is a validation of the systemd approach. They clearly also believe that init is broken, or they wouldn't be working on the uselessd fork. Will be interesting to see their approach to the VT issue. Competition is good.

  21. finally! by Thud457 · · Score: 2

    year of GNU/Hurd on the desktop!

    --

    the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

  22. Re:Why do people care so much? by Zeromous · · Score: 2

    Well I get shiny RHEL7. I build my systems like RHEL6 (I don't do a lot of custom init stuff).

    RHEL7 fails to boot after a while because of systemd. No one knows why. At first I was told it was hardmounts. Take them out in rescue mode, no booty.

    Systemd by design tries to mount nfs shares, before it even starts up the network, out of the box! Systemd supresses everything unless you tell it to. Why? Because some hotshot idiot thought I was using RHEL to run a desktop? Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION.

    This is the problem with systemd, it is unportable, monolithic and subject to dictatorship. And what does it offer me day to day in a grinding development lab? Nothing. Also yes, Embedded systems. I still support those too.

    --
    ---Up Up Down Down Left Right Left Right B A START
  23. Re:Why do people care so much? by smash · · Score: 3, Informative

    What is starting processes isn't so much the issue. The issue is that systemd is demanding major changes of other software to work with it, and this is then making this software non-portable. e.g., Gnome 3.

    People don't want to run Linux everywhere. Despite what some people think it is not always the best fit. There are other Unix platforms which fit better. Platforms that have had application compatibility with Linux up to this point. systemd has changed this. Changes to Gnome to work with systemd for example have made it non-portable to other platforms.

    This is a problem for anyone who wants to say, develop a cross platform gnome3 application.

    That, and there are the corruptable binary logs, the solution to which in the bug report is to "just delete them" and the bug has been closed as won't fix. Sorry, but if this is the resposne to journal corruption rather than finding out WHY the journals get corrupted and fixing the fuckign problem, then i do not want that in control of my logfiles.

    Also, the massive violation of the KISS principle that has been a core guiding principle of Unix design since the start.

    Systemd is a poor solution to a non-problem. There are plenty of other problems to tackle first, before trashing and re-writing working, well debugged code and breaking cross platform compatibility for no good reason.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  24. Re:at some point it isnt linux anymore. by drinkypoo · · Score: 5, Informative

    Except that RC init wasn't fine. More than a few times over the years I've had a service that wouldn't start right on a server that actually prevented boot! Whether it was some stuck PID file that wasn't properly erased on boot, or some other race condition (often a network condition, or a chicken/egg problem),

    ...it was actually an init script problem, and not a problem with sysvinit at all. Your init script must not assume that /tmp has been cleared before run. When it finds a PID file, it must not blindly trust it. This sort of problem would be readily solved by simply unifying init scripts based on some sort of well-crafted template, but instead we have a daemon to fix the problem.

    Ideally none of this should ever happen, but it did. Bugs are there.

    Explain how systemd prevents bugs.

    Combine that with the fact that init scripts are huge, fragile, hacks

    Let's take a look at your three claims.

    First claim, init scripts are huge. No, most init scripts are quite small. Sometimes they source a library, but there's nothing wrong with that. The replacement (systemd+unit files+required libraries) is still larger than (sysvinit+init scripts+script libraries). So this claim is clearly false.

    Second claim, init scripts are fragile. Init scripts are not fragile. Some people are very lazy scripters. Some init scripts are well-written and they are fault-tolerant. Some init scripts are not well-written, and distribution maintainers should have remodeled them after ones which were. Distributions should have solved this problem by unifying init scripts. I have made the point elsewhere that a simple hashbang and shell script-based processor could permit using unit files as shell scripts, at least for long-running daemons. So this claim is also false.

    Third claim, init scripts are hacks. Shell scripting is a central feature of Unix. Therefore, init scripts are not hacks. This claim is also false.

    Everything you have claimed about init scripts is false.

    As a system administrator I'd far rather mess with a simple ini file to create services than hack a huge bash script,

    As a system administrator I'd far rather mess with a simple script file than have to debug the system that's supposed to interpret the unit files. With a shell script, I can simply run the script with -x and see precisely what is happening, even if all I have is a command line and 80x25. With a daemon interpreting a file, I may be lucky enough to get useful information out of strace, or I may have to load a debugger to actually see why my daemon isn't starting.

    All other major unix server vendors ditched sysv init for the same reasons as I state long ago.

    That's interesting. I looked up AIX, and it looks like they still have init with an inittab. And So does Solaris. From what I can tell, your claim that major Unix vendors have moved on from the traditional init system is also false.

    Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice.

    Either you haven't been following the discussions here on Slashdot on this subject, or you are a liar. There have been numerous examples in these threads by actual systems administrators who have encountered actual problems with systemd. So while your claim might be true, it points only to your ignorance due to inexperience and lack of investigation.

    Uselessd is a validation of the systemd approach. They clearly also believe that init is broken, or they wouldn't be working on the uselessd fork.

    This is also false. They believe that systemd is broken, which is why t

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  25. Re:at some point it isnt linux anymore. by dbIII · · Score: 2

    Yes but systemd doesn't solve any of those problems since it will still be kicking off similar scripts, and not telling you about it when they fail until someone gets their shit together to progress it to the point where you can read the logs when you actually need them. You don't even know stuff is broken until you try to use something and it hasn't started. Updates break anything non-standard such as ZFS. There's long rants here that put things better than I can with my limited exposure on desktop machines - it's not ready for anything with serious consequences of failure yet.

  26. Re:Why do people care so much? by meta-monkey · · Score: 4, Informative

    In addition to the other reasons people have given you (bloated, breaks the unix idea of doing one simple thing well, binary log files, doesn't play nice with others, etc), the reason people are rabidly opposed is because of the way it's being adopted, or should I say, thrust upon us. Poettering and friends are not simply making a piece of software and releasing it and getting people to adopt it because it's good and solves a useful problem. They're playing shady political games to force adoption.

    Ideally, if you think you have this great new replacement for the fundamental piece of userland software in Linux, awesome! Write it, fork a distro and build your distro around systemd. Use it. Find the bugs. Work them out. Do this long before you start suggesting people run it on their servers. If it's actually better, distros will start including it. Instead they've played political games to force it into really popular distros like Debian.

    It's just not ready for prime time. Build it, test it, show us how it's better and we'll be overjoyed to use it. But ram buggy bloated bullshit down our throats for no other reason than your own ego and well, fuck you.

    --
    We don't have a state-run media we have a media-run state.
  27. Re:Why do people care so much? by BasilBrush · · Score: 2

    The only time I see people round here unable to use capital letters to make sentences, they are posting Linux positive stuff.

  28. Re:Seriously considering leaving Linux for good. by BasilBrush · · Score: 2

    I'm done with Linux. Screwing around too much with stuff that doesn't need to be messed with is giving me headaches and sucking up more of my time that I can better spend on other pursuits.

    Welcome to OSX. The OS people go to when they realise constantly fixing and customising computers isn't the point of having them.

  29. Re: UseLessD by Useless · · Score: 3, Funny

    Leave me out of this!

    --
    "Even Prophets don't know everything"
  30. Re:hum by BasilBrush · · Score: 2

    It violates the Unix design philosophy. It's a kitchen sink approach that creates unnecessary complexity, unnecessary dependencies, will be harder to work with, and will be more buggy.

    Sounds like EMACS. Who knew that violated the Unix design philosophy. Has anyone told RMS?

  31. Re: at some point it isnt linux anymore. by Barsteward · · Score: 2

    set up a donations page and just see how many people actually care about systemd

    --
    "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
  32. On the ignorance of this debate by Peter+H.S. · · Score: 5, Informative

    It is pretty sad to see, that after so many comments nobody really has a clue about what the story is about, and what is happening in the Linux kernel.
    The kernel VT system has been considered a monstrosity by kernel developers the last decade and everyone is of the opinion that it should be used to user space.

    The finally a really smart guy actually attacks and solve the problem. His name is David Herrmann, and he has tirelessly worked on this for years. Systemd distros will get the full support of his research, simply because almost all Linux distros are using, or a going to use systemd. But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon"
    https://github.com/dvdhrm/kmsc...

    Here is his fosdem talk:
    https://archive.fosdem.org/201...

    Here is his blog that will tell you more about VT's than you ever knew:
    http://dvdhrm.wordpress.com/

    Here is a wiki link about VT:
    http://en.wikipedia.org/wiki/L...

    Here is an old blog post about the problems with the old kernel VT:
    http://dvdhrm.wordpress.com/20...

    In short, no need for the systemd opponents to get their panties in a bunch; they can either use Hermanns user space tools, or pretend there isn't a problem and use the present kernel system.

    For the rest of us who really likes systemd, this is great news. Thanks to Hermann's work, there will be much better console support for early boot debugging, better security, better keyboard and language handling etc.

    1. Re:On the ignorance of this debate by Peter+H.S. · · Score: 4, Informative

      I guess you don't know much about systemd and kernel VT's. The explanation is quite long and technical, but the bottom line is that systemd provides needed infrastructure to allow eg. user switching in user space for VT's, and nothing else really does, so of course all the advanced features are going to be systemd only; nothing else provides what it does.

      Furthermore, what some distros want is to turn off kernel space VT's completly, so something else in user space need to manage such VT's, whether the init system is SysVinit or systemd. What this is all about, is that systemd is adding support for this so you can use user space consoles in early boot for logging in or having en emergency shell and what not.

      Hermann has made all the necessary tools for the non-systemd distros, so they can enjoy most of the benefits. I have a hard time imagining that ultra-conservative distros like Slackware are going to use it though, so they can just continue to use kernel VT's.

  33. Re:UseLessD by Bigon · · Score: 2

    Who is "Debian leadership"? The DLP? The FTP-masters? the Release team? the individual maintainers? the Pope? You are quoting (or are you Gregory Smith or whatever alias?) https://lkml.org/lkml/2014/10/... which in is complete non-sense. Nobody has decided anything, systemd-shim is still in the archive at this point.

  34. Re:hum by nabsltd · · Score: 2

    systemd is optional, you can remove it and replace it with any init system you like

    Unless you are using a disto like Gentoo, you can't replace systemd because everything useful depends on it either directly or indirectly.

    And now, I expect that you will say "that's not systemd's fault, that's the fault of the distro". Except that without dbus, systemd won't run, and without dbus, you the number of apps that will actually run can be counted on on hand. And, it's that way because the same guy that wrote systemd wrote dbus, and baked in the dependency.

    OTOH, if you have a step-by-step guide on how to replace systemd with any other init system on current releases of CentOS or Fedora, and the upcoming release of Debian, I'm sure there would be many people who would be grateful.

  35. Re:Why do people care so much? by AdamWill · · Score: 2

    "It does its own logging in binary which needs a tool to read the logs and if it gets corrupted then systemd's devs say "just delete the logs". Really?"

    Er...no. They don't say that. journalctl reads as much data as it can from corrupted log files and otherwise routes around them. I don't know of any advice that says to delete them.

    journald is also intentionaly designed to make it simple to store logs in plain text format if desired, using rsyslog or something similar as a journal consumer. you can do this alongside or instead of systemd's native log format.

  36. Re:Why do people care so much? by AdamWill · · Score: 3, Interesting

    "Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION."

    systemd is designed to make it trivially simple to have text logs if you want that. RHEL 7 is configured by default to do permanent logging in plain text format via rsyslog; the native journald logs aren't even permanently stored by default (this is the config that was in Fedora for a while before journald's native format became the default/primary).

    https://access.redhat.com/docu...

    I am starting to suspect you're a troll and haven't actually used RHEL 7 at all.

  37. Re:Seriously considering leaving Linux for good. by AdamWill · · Score: 2

    "The only things I use Linux for anymore is for my personal file server in my basement, and even that is running old Fedora 17."

    so...it's running a rather early version of systemd, and apparently working fine, because you haven't seen a need to upgrade it?

  38. Re:Why do people care so much? by mvdwege · · Score: 2

    On the server side when admining hundreds or thousands of machines, troubleshooting a bloated needlessly complex system wastes precious time.

    Yup. That's why the major distros are all switching away from SysV init to systemd. Because the alternative is to continue with a Rube Goldbergish mess of shell scripts with no proper event-based activation nor decent process monitoring.

    I am most definitely not the only one fed up with chasing Heisenbugs in a maze of twisty little shell scripts, all alike.

    --
    "I know I will be modded down for this": where's the option '-1, Asking for it'?
  39. Re:at some point it isnt linux anymore. by MouseTheLuckyDog · · Score: 2

    He wrote PulseAudio which I had to live with for several years.

  40. Re:at some point it isnt linux anymore. by MouseTheLuckyDog · · Score: 2

    Systemd has been in production a fairly long time now, and I see no issues at all brought up about it in actual practice. RHEL's mailing list has nary a mention of it. It just works and works well.

    Right, because the Kay Sievers wasn't banned from contributing to the kernel because systemD prevented the kernel from loading in debug mode.

  41. Re:Just fucking leave it alone! by IamTheRealMike · · Score: 4

    Yes, you're right! Theo would absolutely approve of stuffing as much random hairy code into kernel space as possible - you aren't gonna find any support for this moving-things-into-userspace nonsense in OpenBSD, that's for sure!

  42. Nobody deserves death threats. by emil · · Score: 5, Insightful

    systemd managed to replace init, inetd, and some of cron in what appears to be a stable environment. This allowed systemd to work in docker and drastically improve Linux virtualization to leapfrog Solaris zones.

    What systemd did not do was provide reasonable documentation. RedHat's v7 inittab has a website for a blog post that sucks. There is no general intro for users attempting to create crontabs executed by systemd, inetd entries for common services, and runlevels that control groups of processes.

    systemd fell down hard on documentation, and the first blush with the unix admin crowd has not been kind.

    These developers delivered working code in a radically new environment, but without documentation the architecture appears to discriminate against people who have been doing things the same way for 30 years. The authors, and their software, appeared cliquish and discriminatory. Had the software and the documentation enabled a gradual migration into a more powerful architecture, things would have been quite different.

    In any case, this is no justification for people to be vile. The old crowd needs help into the new environment. This help needs to happen, and the insults and threats need to stop. Both sides need to work together to get us where we need to be.

    1. Re:Nobody deserves death threats. by HuguesT · · Score: 2

      The only reasonable post in the entire thread. Please mod up.

  43. Re:IN OTHER WORDS? by hairyfeet · · Score: 5, Interesting

    Doesn't have a damned thing to do with Windows or binary files, it has to do with the fact that Debian has been made Red hat's bitch by way of ex RH and Ubuntu employees taking over the board. For those that want to know what systemd is REALLY about its about cloud computing, specifically RH is pushing cloud computing like mad and systemd is gonna end up being a "SVCHost" for Linux dedicated to managing cloud computers.

    This is one time me and the FOSSies are actually on the same page, as just like windows 8 was forced from on high and gave the users a big fat greasy finger so too is systemd being pushed by corporate with exactly zero fucks given about what the end users want. Ironically despite all this "empower the user" talk Linux has always had this is one case where Windows users had more power thanks to the ability to vote with their dollars, thus getting Win 8 shitcanned in favor of a much saner and nicer Win 10. But this does not mean that all hope is lost in Linux land, it just means you are gonna have to organize and SCREAM BLOODY MURDER and refuse to take this bullshit. You especially have to organize all the volunteer coders and get them to walk away, because losing all that free labor and forcing Red Hat and friends to pay for every single dime's worth of work is the ONLY way most of you can hit 'em in the pocketbook. those of you that run non cloud based servers can of course tell them you will no longer use their products but considering how much time and money you have invested in your servers I really don't see that happening.

    Finally you need a rally cry, something simple and catchy and on message to focus the narrative and rally the troops, a "fuck beta" for systemd if you will. And since old Hairy will ALWAYS stand for the users allow me to give you one as a show of solidarity in your plight. Its simple, concise, on message, and sums up in a single simple sentence WTF is wrong with systemd..

    SYSTEMD...Its the Metro of Linux!

    --
    ACs don't waste your time replying, your posts are never seen by me.
  44. Re:Why do people care so much? by inhuman_4 · · Score: 2

    "But I think the best reason people hate it is because it makes other applications become dependent on it."

    No it doesn't. Gnome didn't have to use systemd at all, it was a choice by the Gnome team.

  45. SYSTEMD is a BSOD by Jeremiah+Cornelius · · Score: 4, Funny

    It's not Metro.

    It's SVCHOST.EXE

    But that's a little too arcane, for people who neither debug their own system, or who are not security specialists of one stripe or another.

    How about "systemd is a BSOD" :-)

    https://lh3.googleusercontent.com/-bZId5j2jREQ/U-vlysklvCI/AAAAAAAACrA/B4JggkVJi38/w426-h284/bd0fb252416206158627fb0b1bff9b4779dca13f.gif

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  46. This Is Lennart's Defense? by ewhac · · Score: 4, Insightful
    Every time the systemd thing comes up, I want to hate it, but I don't truly know enough about it to actually hold a defensible opinion.

    One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.

    Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:

    Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

    Well, yeah, corrupt logs would be regarded by many as a major bug...

    ...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

    Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.

    Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

    Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.

    Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

    ....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.

    And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"

    File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.

    ....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr

    --
    Editor, A1-AAA AmeriCaptions
    1. Re:This Is Lennart's Defense? by Rich0 · · Score: 4, Informative

      Just what kind of corruption have you experienced in journald? It appends records sequentially to log files, the same as any text logger. If you kill your syslog abruptly do you complain if the last line of the file is cut off midstream and doesn't contain a newline? If so, do you have utilities to recover the data that wasn't written?

      As far as I can tell journald just appends to its file, and regurgitates the data which is valid on reboot. If the file was truncated, it starts a new file, but doesn't discard any valid data from the old one. That is pretty-much how every database/filesystem/etc works - accept completed writes, roll back incomplete journal entries.

    2. Re:This Is Lennart's Defense? by Eythian · · Score: 3, Informative

      The bug report isn't about how something got corrupted. It was about dealing with something that got corrupted. Tieing off the bad thing and starting a new one, and making tools that are robust enough to see past the corruption is totally reasonable. Stopping the corruption in the first place should be a whole different bug report.

  47. Re:IN OTHER WORDS? by exomondo · · Score: 2

    Seriously what happened here?! Yes those corporations that are in the business of making profit will do what is in their best interests rather than the users. We know that, we've always known that, so what we have always done is to take the systems they provide - that we want/need to use - and work around any issues that we don't like. What they have provided out-of-the-box has never been ideal for everybody so the geek/nerd way of dealing with that (and then helping others deal with that) was to come up with new ways to work while still exploiting these systems.

    With Windows we've had awesome alternative shells like LiteStep, Emerge, bbLean, etc... And when Open Source projects start to be driven in a different direction they are forked (MySQL/MariaDB for example or Open/Libre Office) or you switch to an alternative that does things the way you like (for example Slackware and Gentoo don't depend on systemd). Yet at some point it all devolved to stories about Windows 8 or Gnome3 or Ubuntu or systemd being just hundreds of angry comments from detractors venting rather than genuine solutions - which do indeed exist - to the problem. Nowadays it's mostly just people getting angry and throwing their hands up in the air shouting "it's hopeless". The Amazon/Ubuntu issue was a very simple fix and if you took issue with it such that turning it off wasn't enough then it would be trivial to maintain a fork with that code removed or a patch to remove it but still those who claimed to care about the issue were more interested in posting "fuck you canonical" than fixing the issue.

    It's not all hopeless but it's not all going to be done for you either, getting all angry about it is just detrimental to you. Coming up with a solution to a problem you have is rewarding and sharing that solution should be even more so but the response around here is most often "well I shouldn't have to do anything else, it should work out of the box" well wake the fuck up, corporations don't act in your best interest and never have and never will.

  48. Re:Is this a troll about systemd or is this real n by rd4tech · · Score: 2

    Wake me up in few years. It's still too early to adopt SystemD.

    I mean, the damn stuff looks like it's in alpha, what with lacking basic stuff like it's own filesystems and network drivers.
    When it gets to the point where it can update the CPU's microcode, I may look into it. :) :D

  49. Re:Is this a troll about systemd or is this real n by Anonymous Coward · · Score: 2, Funny

    systemd would make a great OS if it only had a decent init system

  50. Re:UseLessD by benjymouse · · Score: 4, Funny

    Or you could use what we've been using for the past 20-30 years that has been debugged, proven to work and not completely different to the rest of the world.

    Like.... bash?

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  51. Re:hum by nabsltd · · Score: 2

    I'm relying on the very vocal detractors of systemd to be sufficiently competent to install the init system of their choice because they are adopting the position of saying they are smarter and better than the developers of systemd.

    No, we're adopting the position of "if it ain't broke, don't fix it" and "provide your supposedly better solution as an alternative and let it win on its merits".

  52. Re:IN OTHER WORDS? by lsatenstein · · Score: 2

    Doesn't have a damned thing to do with Windows or binary files, it has to do with the fact that Debian has been made Red hat's bitch by way of ex RH and Ubuntu employees taking over the board. For those that want to know what systemd is REALLY about its about cloud computing, specifically RH is pushing cloud computing like mad and systemd is gonna end up being a "SVCHost" for Linux dedicated to managing cloud computers.

    This is one time me and the FOSSies are actually on the same page, as just like windows 8 was forced from on high and gave the users a big fat greasy finger so too is systemd being pushed by corporate with exactly zero fucks given about what the end users want. Ironically despite all this "empower the user" talk Linux has always had this is one case where Windows users had more power thanks to the ability to vote with their dollars, thus getting Win 8 shitcanned in favor of a much saner and nicer Win 10. But this does not mean that all hope is lost in Linux land, it just means you are gonna have to organize and SCREAM BLOODY MURDER and refuse to take this bullshit. You especially have to organize all the volunteer coders and get them to walk away, because losing all that free labor and forcing Red Hat and friends to pay for every single dime's worth of work is the ONLY way most of you can hit 'em in the pocketbook. those of you that run non cloud based servers can of course tell them you will no longer use their products but considering how much time and money you have invested in your servers I really don't see that happening.

    Finally you need a rally cry, something simple and catchy and on message to focus the narrative and rally the troops, a "fuck beta" for systemd if you will. And since old Hairy will ALWAYS stand for the users allow me to give you one as a show of solidarity in your plight. Its simple, concise, on message, and sums up in a single simple sentence WTF is wrong with systemd..

    SYSTEMD...Its the Metro of Linux!

    As I see it for the corporate world, the server in the cloud is the way to go. It is just like outsourcing the data centre to IBM, CGI or other operations organization. It will be cheaper, it will not require a diesel generator and a computer wing, or expensive system admins or rooms of backup tapes and those couriers picking up and returning backups daily.

    The server is going to be an appliance. Only if you work for the cloud company will you retain your career in Linux

    --
    Leslie Satenstein Montreal Quebec Canada