Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Operating Systems Software Linux

Systemd Adding Its Own Console To Linux Systems 774

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.
This discussion has been archived. No new comments can be posted.

Systemd Adding Its Own Console To Linux Systems

Comments Filter:
  • by NotInHere ( 3654617 ) on Wednesday October 08, 2014 @09:23AM (#48091321)

    srsly?

    • by rd4tech ( 711615 ) *

      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

  • by Anonymous Coward on Wednesday October 08, 2014 @09:23AM (#48091335)

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

    • Few people want systemd at all. Why it is being forced on us?

      If you don't want to use all of Lennart Poettering's code, you can choose to use less [darknedgy.net].

    • by Anonymous Coward on Wednesday October 08, 2014 @09:49AM (#48091687)

      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.

    • 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
      • by The Technomancer ( 3649405 ) on Wednesday October 08, 2014 @12:11PM (#48093699) Homepage
        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.
        • by AdamWill ( 604569 ) on Wednesday October 08, 2014 @12:26PM (#48093919) Homepage

          systemd is not about boot time.

  • by Behrooz Amoozad ( 2831361 ) on Wednesday October 08, 2014 @09:27AM (#48091389)
    Why is everyone so mad about it?
    Is it really just me that has a shitload of problems with the current VT?
    • by Anonymous Coward on Wednesday October 08, 2014 @09:46AM (#48091633)

      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.

      • by sxpert ( 139117 )

        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 !

      • by Rich0 ( 548339 )

        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.

    • by BarbaraHudson ( 3785311 ) <barbara.jane.hud ... minus physicist> on Wednesday October 08, 2014 @09:49AM (#48091695) Journal

      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.

    • by UnknowingFool ( 672806 ) on Wednesday October 08, 2014 @09:51AM (#48091717)
      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.
      • by caseih ( 160668 ) on Wednesday October 08, 2014 @10:00AM (#48091877)

        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.

        • Re: (Score:3, Insightful)

          by BasilBrush ( 643681 )

          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.

      • year of GNU/Hurd on the desktop!
    • by smash ( 1351 ) on Wednesday October 08, 2014 @10:11AM (#48092027) Homepage Journal
      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.
    • 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 anothe

      • by rahvin112 ( 446269 ) on Wednesday October 08, 2014 @11:00AM (#48092721)

        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.

        • by rainmaestro ( 996549 ) on Wednesday October 08, 2014 @11:30AM (#48093133)

          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.

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

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

    • by Jesus_666 ( 702802 ) on Wednesday October 08, 2014 @12:33PM (#48094043)
      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.
  • Awesome! (Score:5, Funny)

    by Delicious Pun ( 3864033 ) on Wednesday October 08, 2014 @09:29AM (#48091427)
    All systemd needs now is an integrated web browser and a registry!
    • by Noryungi ( 70322 )

      It will be there soon. I estimate it at around end of Q1 2015. Just wait.

    • Re:Awesome! (Score:4, Insightful)

      by godrik ( 1287354 ) on Wednesday October 08, 2014 @12:20PM (#48093837)

      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.

  • by PvtVoid ( 1252388 ) on Wednesday October 08, 2014 @09:31AM (#48091447)
    As long as I can still run vi in it, I'm good.
  • I'm just here for the entertainment. Now where are those villagers with pitchforks?
  • by Anonymous Coward on Wednesday October 08, 2014 @09:33AM (#48091473)

    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.

    • by caseih ( 160668 ) on Wednesday October 08, 2014 @10:10AM (#48091989)

      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.

  • by CRC'99 ( 96526 ) on Wednesday October 08, 2014 @09:35AM (#48091505) Homepage

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

    • 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.
  • Will this console run any worthwhile games? (Other than NetHack, that is.)
  • by QuietLagoon ( 813062 ) on Wednesday October 08, 2014 @10:09AM (#48091975)
    The last vestige of Linux has been removed from the GNU/systemd distributions, as systemd continues to move forward.
  • by joelholdsworth ( 1095165 ) on Wednesday October 08, 2014 @10:18AM (#48092115)

    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.

  • Slashdot Response (Score:5, Insightful)

    by inhuman_4 ( 1294516 ) on Wednesday October 08, 2014 @10:24AM (#48092231)
    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.
  • by Peter H.S. ( 38077 ) on Wednesday October 08, 2014 @11:58AM (#48093497) Homepage

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

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

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

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

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

    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.

  • by ewhac ( 5844 ) on Wednesday October 08, 2014 @04:51PM (#48097261) Homepage Journal
    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 [darknedgy.net] 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 [freedesktop.org] 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

    • by Rich0 ( 548339 ) on Wednesday October 08, 2014 @06:55PM (#48098219) Homepage

      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.

    • by Eythian ( 552130 ) <robin.kallisti@net@nz> on Thursday October 09, 2014 @12:33AM (#48100199) Homepage

      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.

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Working...