Slashdot Mirror
Systemd Adding Its Own Console To Linux Systems
An anonymous reader writes: The next version of systemd is poised to introduce an experimental "systemd-consoled" that serves as a user-space console daemon. The consoled furthers the Linux developers' goal of eventually deprecating the VT subsystem found within the Linux kernel in favor of a user-space driven terminal that supports better localization, increased security, and greater robustness of the kernel's seldom touched and hairy CONFIG_VT'ed code.
Few people want systemd at all. Why it is being forced on us?
Please stop this madness!
Does anyone really want "better localization" in terminals. My experience as a bilingual user from windows is that the less things are localized the better they work.
Making commands localized breaks script compatibility. (And that includes any output if that is parsed too.)
It has gone to the point where I get the English version of Windows rather than one adapted to my native language. The localization of some of the folder names makes things break and the translation of GUI elements obfuscates the function and makes it so that one has to translate everything to English and back to realize what the function is, especially when the original translator used every synonym for "device" he could possibly find.
Unless they have found a new revolutionary way to localize stuff that haven't been done before. Then it might actually work.
I've played around with the kernel api for manipulating the virtual terminals. It was nice to be able to select from a 256*256*256 color palette for the 16 colors (same as I did in DOS OMG ages ago when I saw my copy of Alpha4 do it, and figured *I* could do it to).
Will I miss the VTs? Yes, because none of the software terminals running under X can do this.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Snowden's docs show that the NSA has ways into many operating systems including FreeBSD. OpenBSD has been notably absent from the slides I saw.
You know who else advocates breaking POSIX? Linus. Frankly I've never understood why the kernel managed VT anyway. It should be in userspace. Maybe there is an argument it shouldn't be part of SystemD but frankly it's a good thing that this is moving out of the kernel. The kernel shouldn't be managing this stuff anyway.
A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.
The basic idea (replacing the old VT code with something new and better) seems fine; the only problem is that it's yet another component that will be integrated with systemd. If the old VT code is completely deprecated in favor of systemd-consoled that means that yet another part of the Linux world has dependencies on systemd.
While that may be fine if you run the kind of system systemd expects, it's problematic if you want to use, say, an embedded system built around uclibc instead of glibc. To my knowledge, systemd still refuses to incorporate libc compatibility patches and thus won't run unless you use their preferred libc flavor. Trying to make your embeddded Linux distro work without systemd will mean that you either have to write and maintain your own console daemon or live without virtual terminals. Or, of course, you can move to glibc and systemd, even if your distro would be better served by lighter alternatives.
I think that the systemd subprojects would be more popular if they were less dependent on each other... and if the developers had less of a "my way of the highway" attitude.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
"Oh hey, just what I wanted BINARY LOGS THAT BREAK ALL MY EXISTING AUTOMATION."
systemd is designed to make it trivially simple to have text logs if you want that. RHEL 7 is configured by default to do permanent logging in plain text format via rsyslog; the native journald logs aren't even permanently stored by default (this is the config that was in Fedora for a while before journald's native format became the default/primary).
https://access.redhat.com/docu...
I am starting to suspect you're a troll and haven't actually used RHEL 7 at all.
A fully functional Systemd has about 69 or so binaries. That's hardly monolithic.
It is when they're all tied together so tightly that you're forced to take all or nothing.
Really? I'm certainly not using every systemd binary on every one of my systems, and the others work just fine. Do you have an example of a case where there is unnecessary inter-dependence?
I haven't used desktop Linux for about a year now, but before that I used it for about a decade and in the early 2000's even did development for it, so I read this post with interest.
I feel the money quote is this one:
For what it's worth, this paragraph makes a ton of sense to me. The biggest problem with Linux, both on the desktop and to a lesser extent on the server, was the fact that you got a basically half-baked set of components that were hardly integrated at all. Basic stuff like being able to set the timezone graphically ended up being distro specific apps / hacks because there was no API to do it, and everything was held together by giant piles of shell scripts and Python which might or might not be something you could actually contribute to or work with, but was certainly never usefully documented.
Basically, the experience of using or developing on Linux gave you the impression of a man in a slightly dishevelled, ill fitting suit. All the parts of a smart suit were there, but none of them quite fitted or lined up, and there were lots of small tears everywhere. And waaaaaay too many people liked this state of affairs because they had made "I am a UNIX user" a part of their identity and had managed to convince themselves that an OS architecture that dated from the 1970's was actually totally elite, and any attempt to reform it was "ignoring the UNIX philosophy" or some shit like that.
Result: MacOS X absolutely ate Linux's lunch on the desktop, despite the fact that Linux was free and Macs .... decidedly not free. Heck Linux didn't even make much headway against Windows, even though under Ballmer the Windows team basically sat on their ass for a decade rewriting the start menu.
From a (now) outsider looking in, this whole systemd fiasco looks a lot like Linux finally being dragged into the 21st century through the sheer willpower of one man, who has an apparently infinite ability to withstand faeces-throwing by the UNIX peanut gallery. Don't like systemd? OK, stick with Debian Stable or FreeBSD and don't get the new features. Stick it to the man and keep your "I Love *Nix" t-shirt on. Me? Between reading about GNOME 3 and systemd I'm starting to wonder if it's time to revisit Linux and give it another shot. If that community can conquer its UNIX fetish and build a modern OS, it has a lot of potential.
Doesn't have a damned thing to do with Windows or binary files, it has to do with the fact that Debian has been made Red hat's bitch by way of ex RH and Ubuntu employees taking over the board. For those that want to know what systemd is REALLY about its about cloud computing, specifically RH is pushing cloud computing like mad and systemd is gonna end up being a "SVCHost" for Linux dedicated to managing cloud computers.
This is one time me and the FOSSies are actually on the same page, as just like windows 8 was forced from on high and gave the users a big fat greasy finger so too is systemd being pushed by corporate with exactly zero fucks given about what the end users want. Ironically despite all this "empower the user" talk Linux has always had this is one case where Windows users had more power thanks to the ability to vote with their dollars, thus getting Win 8 shitcanned in favor of a much saner and nicer Win 10. But this does not mean that all hope is lost in Linux land, it just means you are gonna have to organize and SCREAM BLOODY MURDER and refuse to take this bullshit. You especially have to organize all the volunteer coders and get them to walk away, because losing all that free labor and forcing Red Hat and friends to pay for every single dime's worth of work is the ONLY way most of you can hit 'em in the pocketbook. those of you that run non cloud based servers can of course tell them you will no longer use their products but considering how much time and money you have invested in your servers I really don't see that happening.
Finally you need a rally cry, something simple and catchy and on message to focus the narrative and rally the troops, a "fuck beta" for systemd if you will. And since old Hairy will ALWAYS stand for the users allow me to give you one as a show of solidarity in your plight. Its simple, concise, on message, and sums up in a single simple sentence WTF is wrong with systemd..
SYSTEMD...Its the Metro of Linux!
ACs don't waste your time replying, your posts are never seen by me.
Why do you like systemD? What's so great about it?
I could probably write pages on how great systemd is, but the bottom line is, that systemd is "Linux-done-right!" in all aspects it covers:
It is by far the most advanced, feature rich init-system available for Linux (and probably Unix too).
There are several reasons that make systemd a great project;
Its developers (Poettering et al) have really studied all parts extremely well before they started coding, so all the systemd functionality is really well thought out, and implemented in a superb way; everything is an improvement, often by a huge distance. They have dealt with all the hard problems like backwards compatibility, no flag day, service dependencies etc, by solving them in the most correct manner instead of just patching things up, so systemd pc's have a fast boot, not because systemd is optimized for speed, but because by doing system and service initialization in the most predictable and correct way, leads to a boot speedups as a side effect.
Ubuntu's Upstart was an important, well coded, pioneering effort for improving Linux init systems and a serious improvement over SysVinit, but it also demonstrated, that by staying too close to traditional init systems, you didn't get rid of their inherit problems.
Just the logging alone is worth everything; it provides superb and powerful log filter capabilities that enhances the standard Linux text tools like "grep", but since it is structured, indexed and have a programmatic API, it will also mean that GUI developer now can make a functional GUI for viewing logs on Linux. So there is great stuff for the hardcore sysadmin, and the new Linux user at the same time.
systemd makes using advanced kernel feature like cgroup a breeze; no need to read advanced tutorials or cooking up bash scripts, just ad a single keyword like "CPUShares=20%" in the service config file, and systemd will use cgroup to ensure that that process will never get more than 20% CPU time on one CPU. It is so easy, and no coding required.
I could go on, but I recommend that you study systemd yourself:
http://www.freedesktop.org/wik...
Lots of great documentation there, that will make you think; this is great stuff!