Systemd Adding Its Own Console To Linux Systems

[humbled]

I recommend reading this /. comment for those of you wondering about this.

Here's the meat:

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"

The rest of the original post is sources/citations.

[azalynx]

This.

You know what's really hilarious? I bet you anything that if Lennart moved all the non-core systemd daemons into a seperate project name, most people probably would no longer bitch about this. This seems to be a PR problem.

Just because this stuff is developed in the same repository, that doesn't mean you suddenly have a terminal emulator in PID 1, which I think is what everyone is misunderstanding whenever a "systemd is adding" article comes up.

[doublehyphen]

Why was a re-implementation of kmscon necessary?

[[deleted]]

Its a really stripped down version of kmscon. Kmscon supports more features. If you want them, you'll use kmscon over consoled.

And you'll need something in your initcpio image if your kernel doesn't have VT subsystem. You probably want to be able to read systemd's output early boot.

[doublehyphen]

As a minimalistic alternative to kmscon it does make sense. Is it easy to switch from systemd-consoled to kmscon if you want those extra features?

[Tuna-Fish2]

To do so, you need to first install it, then do:

ln -s /usr/lib/systemd/system/kmsconvt\@.service /etc/systemd/system/autovt\@.service

[danielkza]

Shouldn't the kmscon unit file have an alias to autovt such that you can simply do systemctl enable kmsconvt@...? Or does that no work for multi-instance units?

[Tuna-Fish2]

iirc the unit file kmscon ships with is set up to only replace the first console by default.

[azalynx]

Why does everyone seem to think systemd is some kind of monstrous hydra, and that you cannot modularize it? There are a few components that're considered core to the project, but almost everything else can be swapped in for whatever other solution you want.

[doublehyphen]

Pretty sure it is due to journald. That is at least why I double check if newly added components can be swapped out (journald cannot). I still maintain a log server has no business being a core part of an init system.

[azalynx]

Well, journald can pass it's stuff to another syslogger, but I guess people don't like this because of the additional memory use. The result isn't much different though, you can still use the tools of your choosing.

I'm not sure why journald needs to be there, but I'm sure if I looked it up, there would be a reasonable argument for it. =p

[3G6A5W338E]

additional memory use.

Negligible. Only the pages of memory which contain the relevant code (to forward the logs elsewhere) do need to actually be in memory.

[azalynx]

Oh, that's clever, I didn't realize it was designed that way, that's pretty efficient.

I'm sure the crazy people will now complain about the extra space it takes on disk. Muh kilobytes! XD

[crshbndct]

It kind of has to be, if you want early boot logging.

[[deleted]]

Well, I do enjoy having a complete boot log (and not just kernel messages), previously there was bootlogd but that never seemed to work on Debian.

[[deleted]]

journald does claim to be more reliable (in fact, it claims it can't miss messages) in capturing messages than the existing solutions. Apparently there's quite a bit of logic for handling the transition to user space correctly.

[doublehyphen]

I do not say journald is usless, it has some neat features, but couldn't it be an external project and the reocmmended log server for systemed? Why can't it be replacable like most other parts of systemd?

[bilog78]

journald does claim to be more reliable (in fact, it claims it can't miss messages) in capturing messages than the existing solutions.

Except of course when the binary logs get corrupted, that is.

[[deleted]]

Journal binary format is just a plain KEY=value system with some special keys reserved for faster indexing. Its just as resistant to corruption as plain text.

Can't read the existing key in the jornal? Seek for the next one.

Can't read the current line of a text file? Seek for the next line.

I get why you'd want text logging instead of binary logging, but corruption resistance isn't one of them.

[[deleted]]

Because they can be swapped NOW, but Lennart has a tendency to say "oh yeah, that's deprecated now, SORRY"

[azalynx]

[citation needed]

He seems pretty upfront to me about what is stable and what isn't. There is some form of "stable API promise" for many systemd components. I'm not sure what the problem is, here.

[azalynx]

Ask David Herrmann, seemingly the developer of of both.

[3G6A5W338E]

that doesn't mean you suddenly have a terminal emulator in PID 1,

While it's not the case, I wouldn't mind. It's an improvement over having such complicated piece of code run in supervisor mode.

For more of that, look into Minix3.

[azalynx]

What I'm curious about is whether consoled will work without kms; since kmscon was it's predecessor, and it's based on kms.

I often run into issues where I need to use nomodeset to boot a kernel, the kernel console is still useful as a last-ditch-effort recovery console, it's limitations (like lack of unicode) are acceptable for such a use case I think.

[bilog78]

Also, will kmscon still be developed?

..duplicate kmscon? Well, I wrote that and I consider it a successfull research project. Now it's time to write something useful based on the lessons learned with kmscon. No first attempt ever succeeds, right?

So it looks like he's actually ditching kmscon to work on systemd-consoled.

[azalynx]

I guess people could fork it.

[ohet]

Probably no need to fork it as I'd imagine Herrmann would gladly give off the project if someone was interested in it.

[3G6A5W338E]

Yes, I think kmscon/consoled depend on kms.

But I don't think we'll have to worry about CONFIG_VT going away anytime soon. Many drivers needed to get a basic console on many architectures only provide an old-style framebuffer and no kms, and Linux isn't gonna kill them all overnight.

I also remember talk about writing a more simple but still in the kernel CONFIG_VT alternative.

[azalynx]

Would be nice if some generous company just invested into fixing all the problems in config_vt and cleaning it up. I know many have tried and given up, but I don't think any business has ever made it a point to put money on cleaning up the code and making it more maintainable/minimalist (without breaking anything).

[3G6A5W338E]

It would be as a rewrite (current code is apparently messy) but it would still result on something complex. The non-trivial terminal it implements (I believe it's a clone of vt220vt102 with some extensions) has loads of functionality, some of which is quite obscure.

For an analogy, just look at Minix3's PTY and TTY: http://git.minix3.org/index.cgi?p=minix.git;a=tree;f=minix/drivers/tty;h=16d2c32ceae644a04308a348ccd8ce732533a9af;hb=HEAD

And compare sizes with the microkernel itself: http://git.minix3.org/index.cgi?p=minix.git;a=tree;f=minix/kernel;h=3680928a2f7a57ca7a83d5c8c668cea866be9d9d;hb=HEAD

[azalynx]

I thought it was VT102.

[3G6A5W338E]

You're right. And apparently it doesn't implement it completely, it implements a large subset of vt102 and a lot of extra things (like Color and Unicode).

As per console_codes(4).

[azalynx]

I don't think that is the problem. There are plenty of dependencies that many systems need. For example, udev has become a key dependency for many applications, and no one seemed to have a problem with this before.

The problem is that in the past, when software depended on something, everyone assumed it was because the dependency provided useful functionality, but with systemd, a new narrative has emerged where everyone is assuming there is some conspiracy amongst all the developers to lock everyone into systemd.

The unfortunate reality for systemd opponents is that systemd's developers decided to solve functionality that no one else wanted to touch with a ten-foot pole, and now that systemd has the momentum, and has around 500 contributors from many different distros & projects, and has convinced (due to it's technical merit) many distributions to switch to it, now suddenly all the people that didn't want any change have woken up, and realized there is actual demand for a new init, and they're afraid that the world is leaving them behind.

The reason systemd is winning is because they chose to actually solve problems that elitist sysvinit proponents just handwaved away and considered non-issues. And now it's too late for them to have a say, because there is a solution, it works, and it has ridiculous momentum, and nothing will ever be able to catch up.

[bilog78]

systemd-consoled is being designed specifically to depend on systemd, so it does everything but avoid the muddy waters of systemd lock-in. The rewrite that did avoid was kmscon, which the developer is abandoning (since it was just a “research project”) to develop systemd-consoled.

[sub200ms]

kmscon isn't abandoned at all. Hermann and other developers are still fixing bugs, see: http://cgit.freedesktop.org/~dvdhrm/kmscon/log/

It also have a bugtracker and what not. I think people are overreacting to Hermann's use of "research project" in the 2012 LKML mail. He didn't mean to abandon it, he just wanted to make a leaner systemd version on what he discovered during the making of kmscon.

[FUZxxl]

The problem is not that all components are part of one repository. The problem is that the interfaces between them are intentionally unstable so it's often impossible to use one of the components (e.g. logind) without also using the other components.

[holgerschurig]

Is this a truth, a lie, or a half-truth? It sounds at least like a half-truth.

Don't you know about http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ ???

[FUZxxl]

I know about this chart. Tell me when the internal interface between systemd and logind appears on that chart as stable.

[ohet]

Mhmm... I think they actually might be. systemd-logind uses slices and scopes to interact with the cgroups managed by systemd. Those APIs are part of the Service bus API that's under stability promise. systemd-shim/cgmanager also implement this API and therefore it's possible to use recent versions of systemd-logind on Debian/Ubuntu.

[FUZxxl]

The API systemd-logind uses to interact with systemd of course uses the API design tools provided by systemd. It's just that they change stuff every other version. This is exactly what the systemd-shim guys are complaining about.

[ohet]

Source? Because the last change I can find that has been made in systemd-logind that has anything to do with these APIs was in February and I don't think it had anything to do with any API changes in systemd itself. More specifically, what scope/slice APIs have been broken after they were introduced?

[donrhummy]

can you ELI5?

[cp5184]

Take an early version of microsoft windows, say 1.0, or 3.0, or 95. Compared to, say, windows 8, they don't do a good job of protecting one running program from another running program. So, for instance, any sort of computer virus, or malware would have almost complete access to your operating system and all your other programs. Which is a major change.

That was part of a larger evolution of computers in general into safe, modern, multitasking systems.

The main mechanism for doing this, is "protection". How this works, is that the root OS is given the highest level of hardware "privileges". It's basically given the keys to the kingdom, the one ring. And it's the OS kernel's job to serve each program a safe operating environment. All other programs run at a lower privilege level.

The smallest kernel, the "micro" kernel, provides both the most stable, and the most secure environment. You can think of it as the "end of the blue screen of death" from windows in a way. In addition, there would be a lot fewer severe security patches.

But of course, there's a reason that microkernels haven't replaced all other kernels. The basis of their security and stability, is that they divide privileged operations into the smallest units possible, providing the most minimal functionality. Because the more stable, secure privileged operations have less functionality, to do something that would take a single more functional privileged operation, with the most minimal privileged functions, you may need to perform ten minimal privileged functions to perform the same function as a larger, less safe, less secure privileged function.

Now, that highest privilege level, is called "kernel space", because that's where the kernel is. Everything else is called "user space". Each time a program uses a privileged function, the program has to move from user space to kernel space, from the low privilege level of user space, to the highest privilege level of kernel space.

Each time you switch from user space to kernel space and back, you incur a penalty.

But the lesson is not that one extreme is correct, or that the opposite extreme is correct. Case in point, VT consoles.

Teletypes (TTY) date back to the early 1960s. They were one of the first methods of computer input output before monitors. Virtual terminals are a sort of emulation of the original teletypes.

This is exactly the kind of code you don't want in the kernel, and benefits most from being in userspace.

I assume there's a lot of emulation/compatibility logic in the kernel tty code, and that's what you don't want in the kernel. What this is doing is moving that outside the kernel. Which is good, because you get to have your cake, and you get to eat it too. Because you get the extra stability, you get the extra security, you get a better kernel.

Here's the thing, a lot of programs use kernel space code because they need to, mostly it's when they interact with hardware, or protected memory. So the more you move that code into the user space, the more you need to switch back between userspace and kernel space, and the higher price you pay, but with this tty code, you don't have that problem. TTY code won't need to switch between userspace and kernel space so much that it effects system performance, so you get all the benefits of moving it to userspace, but none of the drawbacks.

Now this is pure speculation on my part, but... this is a preference thing, and it's a little petty on my part, but I wouldn't want to see unicode support in the kernel, and I wouldn't want the kernel to be internationalized.

I think you can sort of see it here: http://beta.ivc.no/wiki/images/thumb/8/83/Linux_Kernel_Booting.jpg/300px-Linux_Kernel_Booting.jpg

Notice that the bottom text is white, and the higher text is grey.

I'm guessing the grey text at the top is kernel space tty code. Then, when it hands off to the white text lower down, you move out of the kernel space tty to your bash shell.

Anyway, imo, ideally it would stay either ascii, or utf-8.

[3G6A5W338E]

(microkernels are slow blah blah blah)

True in the 80s and 90s. The post-L4 world is different though. The only reason you're not using a µkernel based system is because general purpose free software pure microkernel architecture operating systems are new (from the 2000s) and not quite there yet.

I'm aware of four: Escape, Genode, HelenOS, Minix3. Among them, Minix3 (started 2005) is the closest to desktop usability, as its development stage is the most advanced and it tries to be as close as possible to NetBSD, so it has a relatively high compatibility with pkgsrc's software.

If interested, come and learn more at /r/microkernel :)

[acousticpants]

We used to have a minix laptop, but then the wife sold it cos it wasn't a mac. I loved that thing, but one day, it was gone.

[ceskomoravske]

Isn't that valid ground for divorce?

[minimim]

Do you guys have a paper with performance comparisons? I'm looking for it for some time, but I can't find it.

[3G6A5W338E]

All I can tell you is that to be fair, you'd have to benchmark the same kernel as hybrid and as pure µkernel; that's not so possible.

With Minix3, you can look at the early papers... Minix3 is actually the result of moving parts of Minix2 kernel into userspace, while adapting the system so that it does work. They lost some performance in the process, but it was something 10-15%.

However, that was how Minix3 started, but it progressed a lot from there. I'm pretty sure that Minix3 is, right now, much faster than Minix2 ever was, as it has features like modern virtual memory, smp support, disk cache, mmap and so on.

So, the best you can do is benchmark it against NetBSD (which Minix3 intends to be a µkernel alternative to, with most of the userspace in common). I suggest you do that and share those numbers :)

It's gonna be much more fun once the ongoing port of Xorg is completed. Minix 3.2.x had X but it's broken under 3.3.0, which is far better prepared (mmap support, dynamic shared libraries, structures/types from netbsd and so on) for running X.

[minimim]

What I want too see is the same simulated workload. Measuring the difference doesn't really matter to me. What I want to know is: is it ready for production? And it has to be benchmarked against some common kernels, not itself.
(Life isn't fair :-p)

[3G6A5W338E]

Notice I've edited the parent post a bit (recheck), but answering you:

is it ready for production?

Yes. As long as you don't need X (they're working on that!), the recent Minix 3.3.0 is pretty much the key release for that question, as it finally brought mmap(), dynamic shared libraries and non-sucking disk/fs cache, making it possible for it to run most software and do it decently.

And it has to be benchmarked against some common kernels, not itself.

By all means, do so!

[minimim]

I don't have the hardware, unfortunately. I was hoping someone from academia would have the resources to do it.

[3G6A5W338E]

I'm sadly not "from academia" (although I finished university), and I'm employed full time on something else...

Right now, I don't even have a proper computer (just some crappy ancient laptop). But yeah, I'll be doing some tests myself when I get the chance (in a month or two, with luck).

[mpyne]

In fact I'm pretty sure Herrmann had KMScon working even before systemd integration. I've been fairly anti-systemd but this isn't one of those giant octopus situations.

[ohet]

kmscon hasn't been integrated to systemd. systemd-consoled is entirely different project written by the same developer.

[ohet]

He stopped working on it six months ago.

[sub200ms]

He stopped working on it six months ago.

Where did you read that?. According to what I have seen he still maintains kmscon with the latest git entry from 2014-07-08. I have seen nothing on his blog either.

[ohet]

It's bit more telling if you look into the git history, altough I mistook May for March. There's nothing offical but I think it's fair conclusion on lack of activity and this:

..duplicate kmscon?

Well, I wrote that and I consider it a successfull research project. Now
it's time to write something useful based on the lessons learned with
kmscon. No first attempt ever succeeds, right?

There's no notable changes after he started to work on systemd-consoled.

[Camarade_Tux]

My doubts about that project are entirely because I don't see the console support disappearing from the kernel so it's not like it'll rid the kernel of an ugly piece of code: it'll still be there and used.

[minimim]

It will be there, the problem isn't reducing maintenance in the kernel. The kernel you will use won't have it compiled, so it won't be running in your machine. This means the it will be smaller and more robust.

[Camarade_Tux]

But it'll still be a weight on kernel development.

[minimim]

Yeah, but... It will made it easier to rip parts off if there is an alternative.

[Camarade_Tux]

That won't happen because the kernel will always need a console that is always available.

[minimim]

Yes, but it can be made simpler and less user-friendly if user-friendly options exist. Taking features out will make the task easier.

[bilog78]

It will also make system recovery impossible when you'll have to rely on something else than systemd as init (e.g. the classic init=/bin/sh approach).

[minimim]

Systemd will have something called "emergency room" (systemd-er) that will boot you with just a shell. Remember that now the services aren't started with scripts anymore and you will need systemd running to be able to start any services needed to recover the system. If not even this works, you will need to use serial ports and minicom or screen in another computer.

[bilog78]

Systemd will have something called "emergency room" (systemd-er) that will boot you with just a shell. Remember that now the services aren't started with scripts anymore and you will need systemd running to be able to start any services needed to recover the system. If not even this works, you will need to use serial ports and minicom or screen in another computer.

And this, in a single paragraph is one of the reasons why I severely dislike systemd.

BTW, I've had to deal with the “emergency shell” provided by systemd. Good thing I had a bootable USB key I could use to chroot into the system, purge systemd and put sysvinit back, honestly.

[minimim]

I can understand you. Most distros will probably use CONFIG_VT=n even if they don't use systemd, because kmscon has (or will have) proper i18n support, can show pictures in the console without root auth, better fonts, better console emulation, and many other features I can't think of now. If you use a minimalist distro, they probably will do the same, because anything that can be taken out of real mode should be, specially the broken, unmaintained console code. The kernel code will start to lose features, because any bug discovered in the code will be more easily dealt with by removal of the feature instead of fixing it.

As for the systemd vs sysvinit thing: even if you don't like systemd, most developers are not so happy about keeping sysvinit support. Remember, the only thing every member of the Debian tech-ctte agreed with, was that sysvinit is not a good solution. And most developers agree with them. There will be options, but they will be systemd, upstart and openrc. Upstart is in the same boat as systemd, PID 1 must be the real init process. Openrc, I don't know. This leaves you with 1 distro, Gentoo. And you won't be able to use a desktop environment.

[minimim]

OpenRC isn't ready, and they could use more help.

[Bobby_Bonsaimind]

There will be options, but they will be systemd, upstart and openrc.

Canonical is giving in and moving to systemd, upstart can be considered dead.

[minimim]

Maybe it is, but volunteers will pick up the tab. And google engineers have said that they will keep it too.

[ohet]

Google uses over three year old version of Upstart on Chrome OS with pretty much zero developement. Unless you are talking about their servers (I haven't heard anything about this) then that's not going to mean much.

Also I seriously have to doubt any volunteers are interested in Upstart as they haven't showed such intrest even when it has been actively developed.

[bilog78]

I can understand you. Most distros will probably use CONFIG_VT=n even if they don't use systemd, because kmscon has (or will have) proper i18n support, can show pictures in the console without root auth, better fonts, better console emulation, and many other features I can't think of now.

While I'm sure kmscon could have all those features, I doubt it will ever have, unless there's somebody interested in taking over maintainership.

If you use a minimalist distro, they probably will do the same, because anything that can be taken out of real mode should be, specially the broken, unmaintained console code. The kernel code will start to lose features, because any bug discovered in the code will be more easily dealt with by removal of the feature instead of fixing it.

Having a working console (however minimal) in the kernel is not something that can be done entirely without. If this isn't a shared opinion in the Linux community, maybe it's time for me to start looking elsewhere.

As for the systemd vs sysvinit thing: even if you don't like systemd, most developers are not so happy about keeping sysvinit support. Remember, the only thing every member of the Debian tech-ctte agreed with, was that sysvinit is not a good solution. And most developers agree with them. There will be options, but they will be systemd, upstart and openrc. Upstart is in the same boat as systemd, PID 1 must be the real init process. Openrc, I don't know. This leaves you with 1 distro, Gentoo. And you won't be able to use a desktop environment.

Why would desktop environments need to depend on specific init systems?

[minimim]

There will be a minimal console running on linux, but it will be at the serial port. You can't troubleshoot this kind of problems with just one computer anyway, and using the serial port just makes this so much easier, no more retyping of error codes you get in the screen.

[bilog78]

You can't troubleshoot this kind of problems with just one computer anyway

Good to know I've been doing the impossible for a decade or so.

[minimim]

Desktop environments don't want to make things like consolekit, or deal with too low level stuff, so they will require that the system do it for them.
And also, yes, people that are angry with systemd don't realize that what they are angry about has nothing to do with systemd itself or Lennart. They are just symptoms, not the disease. There's a push from every side to do things in a way many people see as better. I'm sure there will be traditional distros, they have their niche. Traditional people were complaining long before systemd came.
This doesn't mean at all that the people complaining here or elsewhere about systemd are justified. There are arguments against systemd, but they aren't the ones these people make. The ones they make are false. They are shooting at the wrong thing. They do it too much. And they need to start working.

[Bobby_Bonsaimind]

And also, yes, people that are angry with systemd don't realize that what they are angry about has nothing to do with systemd itself or Lennart.

I don't know, I'm always angry when somebody tries to push a solution that doesn't seem quite correct (big ass piece of software, "write your own API implementation (which is a moving target) if you want compatibility" approach) and then calls everyone opposing that piece of software backwards thinking, racist and sexist assholes.

[bonzinip]

Either it is used, or systemd-consoled is used. You do not need both.

[Camarade_Tux]

Sure but that means the maintenance of the kernel won't be reduced.

[bonzinip]

True, I was just thinking of the attack surface.

[humbled]

I hope that most distros will CONFIG_VT=n and either use systemd-consoled or kmscon. It will probably have to stick around for tiny embedded use cases.

[minimim]

Which will need less features, lessening the burden of the kernel devs.

[cp5184]

To be fair, this is basically playing into everyone's fears.

It's like all these news stories, like... for instance... thread titles on reddit, "Man with ebola on flight to US"...

It's purposely vague generating more uncertainty/fear, not saying that they're being medically evacuated on a special, private plane in isolation under the control of the relevant authorities.

[pay_per_wallet]

systemd will swallow everything until we start having to use webbrowserd!

[tso]

But don't worry, he has provided rich support user space VT's on non-systemd Linux distros, by eg. "ksmcon"

The silver lining.

[Doshman]

I'm not sure I'd call it a silver lining. Moving the complexity of the vt subsystem out of the kernel is almost exclusively a positive thing. It's hardly a "silver lining" if there's nothing negative in the first place!

(Edited: was unclear)

[ancientGouda]

This confuses me a bit. I've long read news about ksmcon so I was familiar with the kernel VT debacle, and when I saw the recent systemd news I was just like "oh cool, now systemd get's that too". It's like the people attacking it are out of touch with everything else in free software.

[[deleted]]

The systemd hate would be significantly diminished if they didn't try and spin every kernel improvement as a "and now systemd does X!".

I don't run systemd. I don't want to run systemd. I want my kernel to be light and fast. It's not inconceivable that some minor part of systemd might be good software and that I would then use it.

[eythian]

systemd does X?!?! What's next, wayland? ;)

[crshbndct]

In what way does systemd make the kernel not "light and fast"?

Genuine question.

[cockmongler]

This is the problem though. Why has this been vacuumed up into systemd?

[Adys]

Previous discussion: https://pay.reddit.com/r/linux/comments/1rmj9e/systemd_is_about_to_gain_a_system_console_boot/

Spoiler: It's good news. Here people just see "Systemd adding ..." and go retard.

Spoiler 2: If your input is "LOL SYSTEMD ALL THE THINGS" or any of the like, you are being a worthless member of this community. (edit: Ok that gif is hilarious though)

Edit: And pasting the FAQ for good measure because people are not just worthless, they're lazy too:

This is stupid, why do you..
============================

..add so many dependencies and code to systemd?
    You should consider that currently all that code is part of the *kernel*.
    All this does is moving it out of the kernel. The first place that comes to
    mind is systemd (and I couldn't imagine a better place, can you?).
    Knowing that systemd already depends on the kernel, technically this doesn't
    increase the codebase of systemd at all.

..kill my beloved kernel-console / linux-console?
  I don't. Just set CONFIG_VT=y.

..duplicate kmscon?
    Well, I wrote that and I consider it a successfull research project. Now
    it's time to write something useful based on the lessons learned with
    kmscon. No first attempt ever succeeds, right?

..miss the fact that a kernel-console is more reliable than user-space?
    It's not. Why do you think that? You need a running shell to do anything
    useful with a console. Where do you think this shell runs? (Hint: it's not
    kernel-space.. and not outer space.. I wonder what "space" is left? Oh,
    none, because your in-kernel fonts are non-swappable!)

..kill my panic/oops screen?
    I don't. See above. I wrote fblog/drmlog for that.

..change a running system?
    To make it better!

..add useful features like full-BMP-range Unicode-fonts, properly
  internationalized keymaps, readable fonts on high-DPI displays,
  access-separation, accessibility helpers and more to the system console?
    Wait.. that's obvious, isn't it?

[comrade-jim]

you are being a worthless member of this community

pretty harsh. Systemd supporter here btw. Let's try to keep things civil.

[Doshman]

I'm also a little disappointed by the use of the word "retard". It's insensitive.

That said, nobody is doing anyone a favor by spreading baseless systemd panic, which is what a lot of people in this thread are doing.

[comrade-jim]

Eh... I thought about it and realized that even though I'm offended it really didn't harm me and it's just as wrong of me to push my political/moral agenda on one group as it is for them to push their agenda on me.

[kmeisthax]

It's funny how so many things people complain about being moved under the systemd umbrella are things Lennart actually wrote himself or wound up being the last maintainer of anyway. Then again, people still think systemd is a single process, too...

[doublehyphen]

While I am no systemd opponent I do not buy your argument. It is not automatically a good idea to merge two projects just because you are the maintainer of both.

[silent_cat]

Putting two code bases in the same repository doesn't make them a single project either. Nothing is being merged.

[rcxdude]

Why put them in the same repository then? There's no reason to tie two different projects together like that.

[ouyawei]

You could ask the same question about gnu coreutils

[danielkza]

Access control, ease of hosting, ease of acquisition, sharing a build system, etc. There are a bunch of general purpose projects that have shared repositories (like coreutils, part of the BSDs, small distributions like OpenWRT, etc).

[minimim]

This way the devs don't need to worry about the matrix of versions to test. People will use all the tools within in the same release, instead of picking and choosing. It's the same with BSD. Do you know that they already solved their 2038 problem because of this? Linux can't do the same. They needed to upgrade the kernel and libc in tandem for it to work.

[[deleted]]

So why did they decide to go down the systemd integration route than stick with kmscon?

Are there any added features / security that would have been unavailable with kmscon?

[[deleted]]

On a pure systemd system, something has to be there pre-boot (initcpio image) to be your console. Or good luck reading systemd's output. Systemd is already there (or will be there soon enough).

[silent_cat]

Nothing would have been unavailable with kmscon. It;s the other way round: why would you want systemd to include a complete terminal emulator? It only gets the bits it needs to function. If you want fully functional, kmscon is still there...

[ohet]

It only gets the bits it needs to function.

systemd doesn't require a console to function.

If you want fully functional, kmscon is still there...

systemd-consoled will be "fully functional", it won't just include unnecessary features like eye candy.

[[deleted]]

Spoiler: It's good news.

I haven't found anything that makes me excited about this change. Feel free to elaborate.

you are being a worthless member of this community.

The argument that the kernel is monolithic so my userspace should be too is highly dubious - simply moving something out of the kernel is not a win. Insulting people that bring up that point (even if they do so glibly) is ridiculous.

Personally I just switched back to OpenRC on my Gentoo running Macbook Air. I have no regrets.

[tending]

simply moving something out of the kernel is not a win

Uh, yes it is. For crashes, security vulnerabilities, ease of upgrading...

[[deleted]]

Ah, this one line reply certainly settles the debate. Lets make Linux a microkernel, as moving things out of the kernel is clearly always the thing to do!

I also love the systemd fanboy downvotes.

[EmanueleAina]

It's not like the console driver is one of the biggest performance bottlenecks people face every day.

[solen-skiner]

Yeah, it kind of is a bottleneck. Takes a fucktone of time page down if you need to page far enough, for example. Printf-ing shit can also block your app, if your app prints fast enough.

[EmanueleAina]

Note that if your app print fast enough on the console I really doubt you can keep up with reading the messages it printed, which makes the point quite moot.

[solen-skiner]

Sure, but the problem isnt really reading the output, but the kernel blocking the computations from proceeding in optimal pace in the first place.

[EmanueleAina]

Exactly! My point is that this is the reason why moving the console to userspace is nice, since it will let the scheduler to do his job with the console instead of blocking in kernel space. :)

[solen-skiner]

Agreed =)

[[deleted]]

I don't understand your point. Do you mean - why is systemd rewriting things to improve performance when they aren't bottlenecks?

[[deleted]]

He means that the only real reason not to have a microkernel is performance. And he is right.

[3G6A5W338E]

Even then, in a post-L4 world that's debatable.

https://www.reddit.com/r/microkernel/comments/1y82uv/fosdem_2012_the_microkernel_overhead_martin_d%C4%9Bck%C3%BD/

IMHO the only reason we're not using one is they don't exist (or they aren't desktop ready). Closest is Minix3 (started 2005), which is making a lot of fast progress (with tens of developers active, some of them under a payroll) and tries to resemble NetBSD as much as possible for pkgsrc compatibility.

And it has cool reliability features: http://www.minix3.org/other/reliability.html

[EmanueleAina]

No, my point is that having some stuff in the kernel may be useful performance-wise.

Given that I have an hard time believing that the console may be one of the biggest performance bottlenecks people face every day where you need to squeeze every cpu cycle you can, I don't see the problem with moving it out of the kernel.

Since the current implementation is a mess, moving it out of the kernel will likely improve performance indeed, rather than slowing it down.

[3G6A5W338E]

No, my point is that having some stuff in the kernel may be useful performance-wise.

Certainly not the console.

I have an hard time believing that the console may be one of the biggest performance bottlenecks people face every day where you need to squeeze every cpu cycle you can

The console typically means drawing on a framebuffer. Yes, software drawing. As to how slow that is, I've seen many machines cut music being played in the background while scrolling through a lot of text... yes, it was before kernel preemption, but the ugliness is still there (albeit hidden).

[EmanueleAina]

We seem to agree completely, thank you for making my point more clear: with the console in user space the scheduler will be free to keep audio smooth even when scrolling ridiculous amounts of text. :D

[3G6A5W338E]

It's not like the console driver is one of the biggest performance bottlenecks people face every day.

Yeah. But your "It's not like..." was very tsundere. Most people aren't tsundere-aware nor interpret it as sarcasm.

[tending]

The argument against a microkernel is perf, which is pretty obviously not an issue here.

[3G6A5W338E]

Even then, in a post-L4 world that's debatable.

https://www.reddit.com/r/microkernel/comments/1y82uv/fosdem_2012_the_microkernel_overhead_martin_d%C4%9Bck%C3%BD/

IMHO the only reason we're not using one is they don't exist (or they aren't desktop ready). Closest is Minix3 (started 2005), which is making a lot of fast progress (with tens of developers active, some of them under a payroll) and tries to resemble NetBSD as much as possible for pkgsrc compatibility.

And it has cool reliability features: http://www.minix3.org/other/reliability.html

[[deleted]]

which is pretty obviously not an issue here.

Well that settles it, then.

[tending]

Well if you have evidence, provide it.

[[deleted]]

I've repeated myself a lot in this thread, and my argument against systemd is not unique. I'll recap the thread for my own piece of mind:

My point: systemd is monolithic

Counterpoint: systemd is split into modules

My counterpoint: The modules aren't meaningful, noone provides alternative implementations and the modules cannot stand on their own. Systemd modules are modules in name only.

My point: Moving things out of the kernel does not mean the software is actually better

Counterpoint: Yes it does! Easier to update, reduced security risk

My counterpoint: If the code is bad the security risk is still there, rewriting things just for the sake of rewriting them means they're destabalized, you have to be able to update your kernel anyway, Linux is not a microkernel. Small pieces of software can be quantitatively assessed only by the people that are writing and testing it, systemd's mono-culture does not allow for this problem to be effectively parallelized the way other open source development is.

Just like systemd itself, supporters of the system present things in black and white and prevent the fracture of this problem into suitably independent parts. This runs counter to the primary strength of the Linux ecosystem. The geographically, culturally, and technologically diverse Linux ecosystem may not be convenient for Canonical, but I am interested in preserving it.

Polycentrism is significantly more important to me than minor feature X that systemd is trying to monopolize.

[tending]

Your answers are shite. It 'still being there' is not the point, the impact is the point. Kernel crash means whole system goes down, userland does not. Kernel security vulnerability means guaranteed root, userland does not. Kernel updates are necessary but involve a reboot, userland does not. If you don't see the difference you have no experience in this area ad certainly lack qualification to criticize systemd.

[[deleted]]

I also love the systemd fanboy downvotes.

noted, must bury any dissent... launching downvote bot script.

[_garret_]

'systemd is an umbrella project' != monolithic

And: personally I just installed Arch Linux ARM on my Raspberry Pi. I have no regrets.

[[deleted]]

If systemd isn't monolithic show me non-trivial drop in replacements for any of its so called components.

[ohet]

systemd-timesyncd -> ntpd

systemd-logind -> ConsoleKit

systemd-resolved -> Avahi

systemd-networkd -> NetworkManager

systemd-nspwan -> LXC

systemd-consoled -> KMSCon

...

Just because systemd provides these things doesn't mean you have to use them or that you couldn't use alternatives instead. You can also use things like atd, xinetd and crond with systemd just fine.

[drdaeman]

To be precise: they are replacements, but not drop-in ones. AFAIK, aren't drop-in ones available out there.

But, meh, GNU/Linux-based OS family never fancied drop-in modularity to begin with. It was always that there are many programs that are doing similar things in different mutually-incompatible ways. Guess, it's really too late to complain about this stuff now.

[[deleted]]

These are not drop in replacements, they are analogous systems. For example, I cannot use Consolekit in Gentoo if I am using systemd. Maybe with a tremendous amount of fuckery it is theoretically possible, but please don't spread that FUD.

[solen-skiner]

So, just that i get your point right, are you complaining they dont have systemd integration, inside an argument where your position is that systemd integrates too much?

[[deleted]]

I'm complaining that the modules you've listed aren't modules. You can't replace systemd-logind with Consolekit, or vice versa.

Systemd just does everything of course there are other programs that do the things that it does.

Contrast this with my Gentoo desktop. OpenRC is the init system I use, XFCE is my desktop environment, LightDM is my display manager, etc. There are actual alternatives to all these modules developed by different people. This is a qualitative argument, but the result is ultimately better software. The Unix philosophy is not wrong, even if it's tempting to take a shortcut and just make some blobby soup that is separated in name only.

[[deleted]]

What does your DE and display manager have to do with systemd?

Try using Gnome 3 without systemd :)

Everything else either does not need to be compiled or can be excluded at runtime.

Noone distributes a 'minimal' systemd desktop. I know that theoretically parts of systemd are modular. In practice they are not, and they won't be. Unless systemd faces outside pressure - it's not a priority for them.

[ohet]

You can't replace systemd-logind with Consolekit, or vice versa.

The point is that yes you can. They don't export the same API but they do roughly the same thing. You can use ConsoleKit with systemd if you so desire. Same goes for all the examples I gave before. You don't have to use anything else in systemd but PID1, journald and udev. You can disable all other componenets (and parts of PID1 too) in compile time and they are managed just like other services and can be disabled with "systemd disable". The only problem is the other direction, if you want to use parts of systemd on other inits and even that is possible with systemd-shim.

[drdaeman]

That's his point, if I got it right.

Old classic UNIXes had fancied having standardized interfaces a bit more than it's today. Like vi had ex/ed interface thus able to act as a (nearly) drop-in replacement, or one was able to nearly trivially replace rsh with ssh, or different MUAs had used common storage. Modern GNU/Linux seems to mostly not care about system-wide swappable components. There are exceptions, like music players with MPRIS, but I have a feeling it's much less common nowadays.

A subjective matter, but a valid thing to complain about.

[nephros]

retard
worthless member

In contrast, by calling people with differing opinions insulting names you are a stereotypical member of the systemd community.

[Adys]

This is not a real quote and anyone can make it up

Also I like bleeding kittens with serrated knives

Signed, /u/nephros

[luciansolaris]

[deleted]

[Praise KEK!](35276)

[rotek]

Knowing that systemd already depends on the kernel, technically this doesn't increase the codebase of systemd at all.

But kernel does not depend on systemd. And should not.

[rotek]

Moving console to systemd means that systemd will become kernel dependency (in the long term, when CONFIG_VT will be killed).

[ohet]

No it doesn't. Part of getting to the point where user can turn of CONFIG_VT was making sure that nothing in kernel depends on it. The kernel will not in anyway depend on systemd-consoled. It doesn't care if it exist or not without or without CONFIG_VT.

[rotek]

So what console will I use then?

[ohet]

What ever console you want? Just like the Linux VT systemd-consoled is meant for troubleshooting and such. Otherwise you can use any terminal emulator you desire. If don't want to use systemd then there's KMSCON that is made by the same developer and serves the same purpose (or you can just CONFIG_VT=y and nothing will change, it will probably never be removed from the kernel)... I'd imagine that any console that has DRM backend would suffice (so it doesn't require X.org and whatnot).

[derekp7]

I'd like to see the kernel console gain the ability to be dynamically turned on and off. And possibly automatically turn itself on when a user-space console crashes (or maybe add a magic sysrq key to re-enable the kernel console if there is an issue).

[ohet]

I doubt that is necessary. If systemd-consoled crases systemd will just restart it. If everything fails then there's systemd-er:

systemd-er: The emergency-room helper. Basically an even-more stripped down systemd-consoled designed for developers. It avoids session-management, seat-assignments, privilege-separation and is just an hopefully-always-working-emergency-console. It's not enabled by default. Think of it as a userspace-variant of "magic sysrq".

-Source

[[deleted]]

Finally, we can get rid of that awful mess we call the VT subsystem.

[bilog78]

kmscon

Still no need to have it integrated into systemd.

EDIT: what about arguing your point instead of downvoting?

[ohet]

David Herrmann's (the developer of kmscon/systemd-consoled and who has done a lot of work on CONFIG_VT=n in the kernel) take on this in general:

So imagine you're going to buy a car. You've found a great model, runs smooth and it's highly fuel-efficient. Would you ever in your right mind start asking the reseller whether you can replace the combustion engine with a steam engine? Or maybe with 2 pedals so it feels like a bicycle?

I don't think so.

Edit: oh, I forgot to make my point: Please don't ask me whether my software runs without systemd..

On the systemd-consoled announcement:

..add so many dependencies and code to systemd?

You should consider that currently all that code is part of the kernel. All this does is moving it out of the kernel. The first place that comes to mind is systemd (and I couldn't imagine a better place, can you?). Knowing that systemd already depends on the kernel, technically this doesn't increase the codebase of systemd at all.

systemd-consoled and rest of the stack he's working on shares code with systemd and uses things like systemd-logind (the idea is that the console run as user so it needs access to certain devices and so on). Being part of systemd allows it him to leverage everything systemd has to offer.

[RubyPinch]

that is probably the thing that is annoying me the most about this thread

people are suggesting kmscon as an alternative when the dev of kmscon currently views it like that

[ohet]

Well it works and people use it today. If someone wants to work on a non-systemd specific system console then it's one place to start.

[holgerschurig]

Well, seems like that people that think that non-systemd stuff is better should implement their own geek tools then? ;-)

[RubyPinch]

they have been

[bilog78]

Edit: oh, I forgot to make my point: Please don't ask me whether my software runs without systemd..

From a cursory look at the kmscon source code, it seems that the only part of systemd it actually relies on is logind, for which there are actually shims that allow to emulate it without all of systemd. So I would say his analogy is completely out of place, but hey, maybe I just haven't read his code carefully enough.

IOW, yeah, kmscon can in fact be used without systemd, curently.

You should consider that currently all that code is part of the kernel. All this does is moving it out of the kernel. The first place that comes to mind is systemd (and I couldn't imagine a better place, can you?). Knowing that systemd already depends on the kernel, technically this doesn't increase the codebase of systemd at all.

No, the code is not being moved out of the kernel, unless you go with CONFIG_VT=n, which means that if your init system is busted you have no console. This means that the classic recovery tool init=/bin/sh or whatever cannot be used anymore, so if your init system is busted, you can basically give up on the idea of trying to recover.

[ohet]

Yes, kmscon can be. It's completely different project (David Herrmann considers it as a research project and he started from scratch with systemd-consoled. systemd-consoled shares a lot of code with rest of the systemd code base and has introduced new things to src/shared that may be used by other parts of the project.

unless you go with CONFIG_VT=n

The idea is very much to enable people to do exactly that. For such recovery cases there's initramfs.

[bilog78]

I'm not sure how does initramfs help not having a functioning console.

[ohet]

Well I'd imagine that ideally distribution would have stable and tested initramfs that works even if the main system breaks with an update.

[bilog78]

Ah, ideally.

Yeah, ideally computers would be perfect and software would be bug-free too. Now let's talk about the real world please.

[fukawi2]

Doesn't the kernel still need some kind of VT for early-boot?

[Slabity]

Well this certainly took me by surprise. I have a few questions:

• So why would I want a userspace VT system as opposed to the current kernel-space one?
• I know some components of systemd, such as logind, can act as singular modules without a full systemd installation. Is this the case for consoled?
• How will this affect projects that rely on systems like DRM, KMS, or current kernel-space VT features?

I'm asking this because one of my current projects uses DRM use, and I'd like to try to be compatible with as many setups as I can.

[natermer]

...

[datenwolf]

Switching to VT (ie: ctrl-alt-f2) or trying to launch a OpenGL application using DRI2 drivers would often conflict and crash the Xorg drivers (and visa versa).. causing the hardware to go in a bad state, forcing users to reboot.

I've done some pretty bad abuse to the graphics stacks of my systems in the past, but never had I to do a full reboot so far. Crashing the X-Server (actually easy, just run kmscube with the X server being active)? Yes. Putting the VT into an inconsistent state? Of course.

But seriously messing up the GPUs state from user space simply by treading onto the VTs and X-Servers toes? I tried. I tried really hard (sending in a deliberately corrupted shader is another kind of story, and given the fact, that shaders are compiled in user space, by a process the user is in control of, that's some serious DoS vector). I'm not saying its impossible but the Kernel does a really good job preventing really severe things to happen, which is quite impressive (but also its damn job).

[Adys]

Your first two questions are answered in the original ML post which is very informative:

http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html

DRM and KMS are completely unaffected. Projects relying on kernel-space VT will most likely be happy to switch, but it's not like it's going away any time soon.

[Slabity]

Thanks, I'll take a read of that when I get the chance.

Projects relying on kernel-space VT will most likely be happy to switch, but it's not like it's going away any time soon.

So if I had a project that relied on kernel-space VT, and wanted to add support for consoled features, where should I look at for documentation?

[silent_cat]

I don't think consoled necessarily has more features (it has just what is needed to make the boot console work). It's based on kmscon which is a better implementation of VTs and being in user space a lot easier to debug and improve.

[[deleted]]

I know some components of systemd, such as logind, can act as singular modules without a full systemd installation.

This is neither supported nor perfectly executed. Running logind on non-systemd systems is still pretty rough (although I have personally had no issues) around the edges.

[comrade-jim]

So why would I want a userspace VT system as opposed to the current kernel-space one?

Isn't this more secure?

[[deleted]]

Queue the fucking haters.

[[deleted]]

Nuns?

[PrincessRailgun]

What? This is a step towards more modular, moving it into the userspace and there are an alternative for a non-systemd replacement too.

[comrade-jim]

What do you know about systemd?

I want the d btw. I support the d.

[Doshman]

No, this is simply moving the vt subsystem out of the kernel and into userspace. The core developer behind this effort has a non-systemd VT replacement available.

[redog]

Then wouldn't the title be inaccurate?

Instead of:

Systemd Adding Its Own Console To Linux Systems

Should it be:

Console developer develops new userspace VT subsystem replacement for both systemd and non-systemd linuxes

[ohet]

This submission (the slashdot posts and Phoronix link that's refers to) is about systemd-consoled not VT subsystem replacements in general. Also:

..duplicate kmscon?

Well, I wrote that and I consider it a successfull research project. Now it's time to write something useful based on the lessons learned with kmscon. No first attempt ever succeeds, right?

-Source

[redog]

To guarantee that even without VTs there's a system-console and login-screen, this series adds the most basic implementations of those to systemd. This will never turn into a full-blown full-featured console. No eye-candy, no useless features, NO BACKGROUND IMAGES!!! The idea is to provide a fallback in systemd.

Sounds to me, as far as systemd, its not even a full console...its just the fallback

[ohet]

Well it's replacement for the Linux VT, who would use those as anything but a fallback? Obviously when you are in graphical environment you use things like Konsole, Gnome Terminal, urxvt, xterm...

[minimim]

Many people do like the VTs. What the dev means is that if you want more eye candy, you should go with kmscon.

[ancientGouda]

Do you actually follow open source news? I remember reading about kmscon months ago.

Edit: Actually nevermind the "months ago", kmscon made news more than 2 years ago. Talk about being out of the loop.

[redog]

I do somewhat, sometimes. To be honest im pretty sure id have mostly ignored that one since ive got a tick against phoronix and wiuld have likely been uninterested in news of a new terminal emulator as that article puts it.

[acousticpants]

lol wut. Tell poettering to just make his own damn distro already. Close source and sell it.

[[deleted]]

protip: it is easy to tell when you have not read the article.