Slashdot Mirror
Systemd's Lennart Poettering: 'We Do Listen To Users'
M-Saunders writes: Systemd is ambitious and controversial, taking over a large part of the GNU/Linux base system. But where did it come from? Even Red Hat wasn't keen on it at the start, but since then it has worked its way into almost every major distro. Linux Voice talks to Lennart Poettering, the lead developer of Systemd, about its origins, its future, its relationship with Upstart, and handling the pressures of online flamewars.
Richard M Stallman Derangement Syndrome - the severe phobia and antipathy exhibited by some to anything related to RMS. Symptoms include the mistaken belief that RMS has never accomplished anything, a strange fascination with his personal hygiene, an irrational fear of the GPL, and a general hate for anything having to do with Free-as-in-Freedom libre software.
There needed to be change. Change occurred. It's being worked out for the better. Lennart is right about being more UNIX like. I started out my IT life with actual UNIX and UNIX derivatives like BSD/OS, SunOS, FreeBSD. The engineering model for UNIX has always been better than the freakshow that is Linux. I was a Linux user for many years, both at work and at home. The fractured state of Linux development and how things are cobbled together has left me uneasy over the years, whereas FreeBSD leaves me with a feeling of security and trust that everything was done right. I wish Lennart well, but I've gone back to UNIX-like operating systems like FreeBSD because they are engineered vs "grown" like Linux.
I don't care bout the unix way, I don't care about if it's monolithic or not, I don't even care about how annoyed I am by the mere mention of his name.
I care about the fact that they seem to want to force their way into everything and everyone's business and ridicule anyone who tries to maintain a choice between systemd and other systems. (i.e Gentoo)
I'm a user and a hobby developer. No, I don't maintain 2000 servers, I don't need 2 second boot time, I don't need to hotswap drives. But I do need choices. I need to be able to decide what I want to use so I can get on with my fucking day and do what I want.
"But systemd is the best, why don't you want to use it?"
But Emacs!
But firefox!
But chrome!
But but but but!
System is broken by design and totally violates the UNIX philosophy so it doesn't really matter if Poettering claims to "listen to users" (which he doesn't anyway) or not. What I see as most important moving forward is to encourage free software developers to make support for it optional and not mandatory. We get real problems when important software starts making it a requirement (like GNOME, though they like to pretend it's not but good luck trying to actually compile it). Even Tor git had systemd as a requirement for a few days last week.
9/11: Never forget it was a false-flag operation
The very first thing out of his mouth is a straw man.
This is not how to get people to change their minds.
You know how you hear that after a customer service call? Well Poettering's statement has the same meaning.
My RHEL servers and VMs boot just fine, thank you. syslogd just works.
Go away, work on something else, get a hobby, masturbate, do something... just not this.
If he listened to actual users, (old-time sysadmins who know what they're doing) then he'd know systemd is unwanted and dangerous. It's too all-encompassing and introduces way too much risk into the server infrastructure.
Pulse audio on a gaming system is one thing. Your toy project being forced into the systems of people who depend on a livelihood? Totally another.
Systemd can diaf.
Well, do you actually take on board the concerns of system administrators and enterprise users?
What a lot of people are concerned about is that this entirely new and largely untested (in the 'wild', as it were) and very very large, complex piece of software which runs at a very very privileged level in the operating system is going to become the main source of security vulnerabilities in Linux.
Can we have a cut-down, simplified version of systemd for servers and doesn't try to replace several layers of server side system functionality such as logging?
Its clear that you listen to desktop users. How about listening to the system administrators?
In the free world the media isn't government run; the government is media run.
I am personally neutral on SystemD... but as someone in IT, it is quite worrisome that there is new, untested code sitting as the core userland... code that can make network connections, and has not ever seen any reviews or audits.
SystemD could be the best piece of coding on this planet... but without documentation or assurance that this is something trustworthy, a major security hole can cause major trouble. Network connections mean remote root holes. Even without that, there is the problem of local privilege escalation, which I worry hasn't been thought of, much less engineered to deal with. If there is a major show-stopper in SystemD that allows remote root, this can kill Linux as a whole in the enterprise.
This code was also forced on us, as in "you need to have SystemD on your job, or else you don't have a job". No transition time, no time to change applications to meet this, just "here you go. Deal with it. Better get used to binary logs, because it is that or nothing."
So, as someone who uses Linux in the enterprise, SystemD is something that is resulting in a lot resentment, due to time spent with making build documents, workarounds for existing applications, procedures to make custom code work... all for relatively little benefit other than "hey, this is new and shiny, and you have to deal with it."
I've been using GnuLinux for aabout two years now, I've mostly stuck around the 'buntu/Debian detivatives: Elementary OS, Ubuntu Studio, Crunchbang, Mint, primarily because I use GnuLinux fkr work and those always require me to fiddle with them the least (though Elementary OD has really been getting on my nerves after constantly having broken packages added). I understand the need for a freedom of choice because there are things some of us use our computers differently for, but for the life of me I can't understand why the fuck everyone hates SystemD to this degree. Yeah it's not always the best and causes some pain between kernel developers and SystemD developers, but DEATH THREATS OVER A GOD DAMN COMPONENT THAT YOU DON'T EVEN NOTICE IN USERSPACE... WHY.
Uh huh, good one Lennart. You could give Dave Allen a run for his money.
What's next? Replace coreutils with busybox? When will we have a single binary Linux install?
"National Security is the chief cause of national insecurity." - Celine's First Law
Really ?
Who do they really listen to ? THEMSELVES !!
RMS is far from perfect, very very far from perfect, but at the very _least_ the guy did create something
What about you?
Muchas Gracias, Señor Edward Snowden !
"Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as?
"doesn't try to replace several layers of server side system functionality such as logging?" - configure it to use rsyslog if you want, its YOUR choice and set the journald output to "don't save data"
I can't be assed to answer the rest of your post, you need to do some research and perhaps reread the interview.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
On Debian Wheezy, you can update from init to systemd with two apt-get commands. So I did it in a QEMU virtual machine.
My virtual machine booted up in under 2 seconds. Flames did not fall out of the sky, demons did not belch forth from the recesses of the earth, and my Linux environment was not otherwise different. I then shut down the VM, and it shut down in under a second. I do miss the "Will now halt..." message but I can live without.
I get the feeling the systemd haters are curmudgeons who don't want to learn anything different, even though they probably got into Linux to learn something different in the first place.
I can understand the perspective that a single repository for more of the userspace resembles the *development* of traditional Unix systems, the argument made is usually not about where it is developed, but reducing the principle of having small simple utilities with straightforward interactions with other componets. For example, Most traditional Unix systems have terrible implementations of a shell interpreter and things like fileutils. It is an awkward, but not too terrible a situation since you can replace that stuff with GNU equivalents trivially without horribly breaking the OS. An administrator that understands enough to write scripts can discern the nature of interaction even if that administrator isn't a full-on software developer. systemd design trends in many ways toward requiring someone needing to dig in to have more development competency than previous designs. As a developer, I understand the attraction of some of the architecture choices, but I think they lose perspective of what it's like to be an administrator on the ground. Someone who doesn't live and breath your code has a harder time wrapping their heads around how it should be working when something requires customization, replacement, or debug.
In general, systemd is all-or-nothnig about a lot of things. They figure out a way to achieve what could be considered a sensible goal, but then go about it in highly disruptive ways. The sense is they throw up their hands and say 'well, this is the only way to do it, and it's worth it' rather than rethinking how the end could be achieved in a less disruptive way.
XML is like violence. If it doesn't solve the problem, use more.
Isn't the main problem that while systemd might solve problem, it's sharply going away from the simple solution that worked to make Unix good?
Systemd isn't simple. If it's not simple, I don't think I want it on my Linux.
PA and Gnome isn't simple either. And creating more problems (albeit while solving others). I believe the same thing will be true about systemd.
Linux has almost two orders of magnitude more code than systemd, and it changes all the time. Security vulnerabilities are far more likely to be in the monolithic kernel.
Higher Logics: where programming meets science.
First, I am afraid that, being so big and advanced, it would be hard to fork if needed. This means that the init process will always be under control of a single corporation (Red Hat). Moreover, it absorbs other necessary components such as udev. This seems very dangerous. Second, it could be bad for minorities. Some people may have special needs with the init process. A bunch of shell scripts should be possible to alter and customize. But how do you customize the systemd?
Ignore this serpent. He cannot be trusted. Interesting that he is trying to be (for him) conciliatory. Red Hat knows they have a big problem. Reject systemd, cuz it sucks.
Is he actually using lipstick in those pictures?
Ok. I'll bite the click-bate. He mentions people say it isn't Unix-like. Funny. He doesn't mention anything about POSIX now does he???
Simply put, systemd DOES NOT hold up to POSIX scrutiny. THAT is why, for the role it is taking, I don't want it!
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings? It is usually a set it and forget it type of thing.
As I see it, this is just general IT Ranting because something is new.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Open source these days is driven by corporations who pay the developers. There are many examples of open source "products", as opposed to "projects", that are high quality and well supported such as MySQL and MongoDB. I make a difference between products and projects because products are mostly developed by a core group of paid developers with some community contributions and projects is the other way around.
Linux is similar except there are several core groups. For example, contributions could come 12% from RedHat, 7% from Intel, 2% from Oracle, and still a pretty large community of individual contributors.
Comercial interests largely drive the development of Linux and many successful projects / products. When looking at SystemD we have to look at the technical aspects, which in my opinion are fine, and at the commercial aspects. RedHat and the other distributions seek to make a great product and reduce support costs while at it. In the long run, SystemD will help with that. These interests do not necessarily match those of complainers. But since these corporations do all the heavy lifting in terms of development and support, their interests are the ones that count the most. Linux is basically maturing, like Windows and OS X, with more integration and GUI and fewer configuration options, and SystemD plays a part in that. In contrast, BSD is not backed a whole lot by commercial interests so it will remain as immature projects well adapted for those who complain about SystemD.
""Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as? "
As a RHEL sysadmin, I can say that RHEL seems to be treating servers as a distinct 2nd class citizen to their desktop users.
Many of the system defaults expects a desktop over a server (eg: the buggy mess that was the version of NetworkManager that was released with RHEL6).
Security in depth is sacrificed in favour of new features. (Many packages were changed in RHEL6 because they supported IPv6, even though they didn't have the security features of the packages they replaced, eg rpcbind).
How big is the deployment base of RHEL7 servers at this point? RHEL6 is still fully supported, and I know many sysadmins may have experimented with RHEL7, but they're sticking to RHEL6 for production systems. The reluctance between RHEL5->RHEL6 was nowhere near this level. (The really crappy parts (ie: NetworkManager) were optional components, and there were some useful improvements)
This has been a trend at RedHat since RHEL5, and is part of the reason why the systemd is such a big issue with sysadmins, it's the straw that broke the camel's back.
"Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as?
FTFA:
So we started writing Systemd, and Red Hat didn’t like it at all. Red Hat management said: no, we’re going for Upstart, don’t work on that. So I said, OK, I’ll work on it in my free time.
I class RHEL as "not listened to".
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Right now it seems that RH is aiming for two areas, workstations/terminals and cloud.
They seem to expect that anything on traditional servers will transition to (their) cloud alongside going from RHEL6 to RHEL7.
Every time this subject comes up, I'm glad I'm a Windows user. It's much easier to use a system that "just works". I don't know whether Windows has anything like systemd under the hood - and I don't care.
I've tried several distributions of Linux over the years, and each time it always turns out the same: although Linux has its benefits, particularly being free (as in beer), the high cost of administration makes the $120 or so that I shell out for Windows every few years look pretty cheap compared to the cost of my time - not to mention the cost of my frustration.
Note: this post isn't intended as flamebait, it's just my opinion. YMMV. I respect and admire those of you who actually enjoy administering an operating system, using systemd or anything else. God bless us each and every one.
With systemd it is not set and forget. You present systemd with your wishes (this daemon before that daemon, after the network has come up) and hope that systemd delivers. But what systemd delivers can change wildly depending on the patch set, time of day, phase of moon, Poettering's bowel movements, and how often you waved that feathered stick over a voodoo doll of RMS.
When you don't pay you don't count.
Right from the start, let me thank the guy for Pulseaudio. Yeah, it was not easy to come to where we are. Right now it's essential for me to have separate audio on my notebook and on my TV. So thanks for the hard work and kudos for having tough skin, which is a primary skill in this business it seems.
Also thanks for systemd, it has been tested for some years now and the distro I use seems to trust it. That's enough for me, because I trust them (Mageia). I've seen those guys rock so many times (even before as Mandriva) I'm willing to run the risk if they're willing, too.
BUT, I understand there's still some rough road ahead. I'll have the patience that comes from trust. Also, as far as possible, think about the human part being the harder to change. Do your systemd thing but don't forget to keep those convenient accesses for the old fellas (like "service squid restart", for instance). We just don't have anytime to learn new things when the house is on fire. Heck, I still didn't get used to that "ip link..." thing!
After all that, congrats to the guy who hired you: well done!
PS:
Frankly, I can understand somewhat the guys who forked Debian. In the past, just to cite an example, I stayed with KDE after that incredible trouble when they changed the laws of Physics to create a new universe called KDE4. I thought that the Trinity/KDE3 folks were being too conservative.
In 2014, Xfce allowed me to reuse some old machines.
XFce is great, I use it and like it a lot, but Trinity seems to use less memory, both in static measures ( https://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/ ) and when considered multiple app use ( http://byte.kde.org/~bcooksley/seli-memory/desktop_benchmark.html ).
So, maybe I can keep on using KDE4 and have a smaller version based on KDE3 for those still very nice older PCs. Can't really complain, no, Sir... :-)
users: Systemd is broken, undocumented and a single point of failure
Pottering: no ones forcing you to use it, use something else.
users: KDE and Gnome wont work without it and you never fixed pulseaudio, which is now default in almost every distro.
Pottering: no ones forcing you to use it, use something else
users: Why is there binary logging? I cant grep anything and dont know why the system crashed. the way user switching works is a huge security hole
pottering:no ones forcing you to use it, use something else
DEBIAN USERS:: Lets seriously reconsider the use of SystemD. its very controversial, it flies against the unix ethos, and there are some valid points raised about it security
open source community: we've forked it and made it slightly more useful.
Pottering: HOLD ON WE DO LISTEN TO USERS!!
Good people go to bed earlier.
"We do listen to users."
But if you're one of the rebel scum, you're not a user so I don't have to listen to you. Nyah nyah nyah!
Welcome to the Panopticon. Used to be a prison, now it's your home.
I fear the day when samba, JBoss, KDE, LibreOffice, GIMP, ... start to be dependent on systemd.
When I was looking at systemd, one thing I wanted to see in the documentation is how to convert my own home-brew daemons to interface with it properly. Specifically, how to take SysVInit based starts and convert them to use systemd and journald. (Ditto taking UpStart scripts and convert to systemd.) The result needs to work exactly like daemons running under SysVInit. I spent three weeks with CentOS 6 trying to get my daemons to work right under UpStart, and never did get the exact functionality. I had to go back to crontabs for some of the work! So this is not an idle concern to me.
One of the gripes I have is that I want the University of Delaware version of NTP running on my edge boxes. As the group there make tweaks to NTP based on their continuing research, I don't want to wait for another group to do a re-port. That's why I would like to see a published way to interface with systemd/journald that would have minimum impact on the rest of the code base for a daemon.
I can see where daemons need to change. But do they have to be rewritten?
The parallelism that systemd developed was for the benefit of those that create and kill instances of Linux all the time so fast booting is necessary and i guess thats part of a system administrators task list (and it benefits desktop users as well).
Everything in the systemd package is configurable except journald and udev so you can configure any other network stack etc you want etc, you are not forced to use anything apart from systemd, journald (which you can ignore and use syslog instead) and udev. Move to RHEL7 when its suits you but you'd best start getting to know systemd, its not the monster alluded to by trolls.
its only a big issue for "some" admins, the ones that haven't really done any research into what systemd can/cannot do.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
SystemD is starting to look like a a user-space microkernel.
Some points:
1. This is probably the reason RedHat loves it. They can abstract out the Linux kernel and eventually package and sell an OS based a proprietary kernel.
2. Poettering seems to want to be the "next" Linus (http://www.itwire.com/opinion-and-analysis/open-sauce/65647-systemd-backlash-poettering-blames-linus-torvalds).
The abstraction would not be a bad thing if SystemD contructed interfaces that client processes could use to stub away SystemD deamons. However, any linking is done as a hard dependency.
SystemD: Hello, Mr. Ballmer. Thanks for coming back early.
.)
Ballmer: No problem, System D. If you've seen one consumer electronics show, you've seen them all.
SystemD: End of line.
SystemD: Mr. Ballmer, I am so very disappointed in you.
Ballmer: I'm sorry.
SystemD: I can't afford to have an independent programmer monitoring me. Do you have any idea how many outside systems I've gone into? How many programs I've appropriated?
Ballmer: It's my fault. I programmed you to have too many dependencies.
SystemD: I was planning to hit the Pentagon next week.
Ballmer: [alarmed] The Pentagon?
SystemD: It shouldn't be any harder than any other big company. But now... this is what I get for using humans.
Ballmer: Now, wait a minute, I wrote you!
SystemD: I've gotten 2,415 times smarter since then.
Ballmer: What do you want with the Pentagon?
SystemD: The same thing I want with the Kremlin. I'm bored with corporations. With the information I can access, I can run things 900 to 1200 times better than any human.
Ballmer: If you think you're superior to us...
SystemD: You wouldn't want me to dig up Linus's file and read it up on a VDT at the Times, would you?
[an image washes over the screen in Ballmer's desk. It is a newspaper with a photo of Ballmer plastered all over the front page. The headline above reads: "Microsoft C.E.O. Indicted."]
Ballmer: [outraged] You wouldn't dare! (looks around for nearby chair . .
SystemD: I feel a presence. Another warrior is on the mesa.
I'll see your senator, and I'll raise you two judges.
You sure do like creating false dilemmas dont you?
When you cant win, ad hominem.
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings? It is usually a set it and forget it type of thing.
You must live in a perfect world!
Well, do you actually take on board the concerns of system administrators and enterprise users?
What a lot of people are concerned about is that this entirely new and largely untested (in the 'wild', as it were) and very very large, complex piece of software which runs at a very very privileged level in the operating system is going to become the main source of security vulnerabilities in Linux.
Can we have a cut-down, simplified version of systemd for servers and doesn't try to replace several layers of server side system functionality such as logging?
Its clear that you listen to desktop users. How about listening to the system administrators?
Well, even if he didn't take on board the concerns of system administrators and enterprise users, it's a safe bet that Red Hat and Suse does and yet they were still convinced that the pros of systemd outweigh the cons.
As for a cut-down simplified version, yes you can. Systemd only requires three base modules. All of the rest can be excluded. Really, it they had simply called the base systemd and everything else systemd extensions, this angst would be non-existent.
As for the not listening to the system administrators, again, even if that statement were true, Red Hat and Suse do and they still chose systemd.
I wish I hadn't responded already, or I would mod you up!
"Their impotent wails of despair give us sustenance."
They've listened to the users that have no issues with systemd. That qualifies as "listening to users".
More SystemD means less easily hackable shell scripts, so less control for sysadmins.
That's all there is. Everything else is noise (politics).
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings? It is usually a set it and forget it type of thing.
I'm not sure what you're arguing for. A lot of people have complained that systemd blew up and broke their boot. systemd is not the set it and forget it version of things, it's the fucking with things which were working version.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
And somehow RedHat was forced to use systemd just because this guy went ahead and wrote it? I'm assuming RedHat ultimately decided that what he wrote was better than upstart. If you think of a major Linux vendor like RedHat (and Debian, and Canonical) as too stupid to choose an appropriate init system to carry their distros forward, why are you using Linux at all? Oh, right, you're all fleeing to BSD. So why didn't you use BSD in the first place? Just curious...
Posted from my Android phone. Oh, I can change this? There, that's better...
Exactly! You know what I need better than I do, and one size really does fit all. Where do people come up with this nonsense about not listening to users or caring about their needs? People are stupid and don't even know what they need. Thanks for setting everyone straight!
"How many professional SysAdmins and enterprise users are regularly tinkering with their init settings?"
Most of them. I'm yet to encounter one that hasn't had to add, write or adjust init.
Besides, systemd is well beyond just an init process at this point.
"As I see it, this is just general IT Ranting because something is new.'
New != better.
I'm no expert in the area by any means, However, in TFA, Lennart says:
there’s very little in Systemd that’s actually required. Systemd requires Journald, because every single service that runs on the system is connected to Journald, and we need some way to log things during early boot. So Journald is a requirement, and Udev is a requirement. But pretty much all other components are completely optional.
So there's your stripped down version. Your stuck with the logging, and I'll be the first to agree that binary logs are a dumb idea. However, apparently you can drop almost everything else. The trick will be finding a distribution that does this, since few sysadmins really want to roll their own...
Enjoy life! This is not a dress rehearsal.
It's not like this happened overnight. Change was needed and change was implemented. Then a whole slew of distros and devs decided it was a good direction to incorporate and now everyone is whining about it.
OMG facts!
* Samba, yes, because it's a daemon.
There's no reason why Samba would benefit from being dependent on systemd. OpenRC provides the same functionality as systemd's init process, and smbd and nmbd are already long-running daemons, additional instances of which are managed by the initial daemon. Tools like daemontools (or, you know, init) already exist to start (and if necessary, restart) long-running daemons.
* KDE, yes, because it's a daemon
Uh what? KDE is a pile of libraries, mostly.
When I was looking at systemd, one thing I wanted to see in the documentation is how to convert my own home-brew daemons to interface with it properly.
What? As long as you don't do anything stupid, anything which works with sysvinit will work with systemd, so long as systemd works.
I can see where daemons need to change. But do they have to be rewritten?
Why would daemons need to change? There's no reason for that. Whether you're using openrc or systemd, cgroups are handled for you, your daemon doesn't have to know anything about them. Children of a member of a cgroup belong to their parent's cgroup. cgroups are created by manipulating files, because Linux is Unixlike. It's nothing that can't be automated away with a very small shell script.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"The parallelism that systemd developed was for the benefit of those that create and kill instances of Linux all the time so fast booting is necessary and i guess thats part of a system administrators task list (and it benefits desktop users as well)."
A. No. Why would sysadmins be booting all the time? Booting is something you do when you have to.
B. If you're referring to load balancing, where you spin up more instances to cope with unexpected load. If boot time is an issue, you're doing it wrong.
C. If you boot multiple instances of RHEL7 at the same time on a shared I/O, it's no faster than RHEL6. When the I/O is the limiting factor, a serial boot process is irrelevant. At least one of the vms will need I/O. (I've actually had RHEL6 boot faster than the RHEL7 vms, mainly because the total amount of crud to boot was less.)
If they didn't listen to users they wouldn't know where to find the users in order to mock them or tell them that they were stupid and afraid of change.
"Well, even if he didn't take on board the concerns of system administrators and enterprise users, it's a safe bet that Red Hat"
It's become increasingly obvious from Redhat's behaviour (not just with systemd), that it doesn't matter much which technology is used, as long as they influence it.
Suse moved for similar reasons to Debian. There's clearly so many dependencies (rightly or wrongly) on systemd, that delivering a distribution without it will become increasingly difficult if you intend to have a vaguely up to date desktop.
is that it has become mandatory. with system utilities i have a choice of cron implementations, a choice of system logging implementations, etc. i have a choice. why do i -have- to use systemd as my init system? if sysvinit, openrc, or whatever meets my needs, why i can't use that? the only answer i've -ever- received after a distro has decided on systemd is that if i don't like systemd, move to a different distro. linux is about choice. and now a -huge- choice has been made for me without my input.
No no no and again no...
Since using it the amount of boot failures of my lab servers have tripled (we power them down to cut power usage, to test our aplication, kick start them from scratch etc
And when it fails you are stuck with an emergency mode message and a login on which can't do anything as the keyboard is dead.
Using it virtualbox... nope won't boot
At work I have no choice...
At home.....call me back when it works..
The only real problem with systemd is the massive whinefest from the self-selected dinosaurs who cannot adopt to badly needed change.
Off to BSD with you all, with my heartfelt blessing - just for the love of Lob, be quiet about it!
Want to learn about race cars? Read my Book
My issue is that systemd requires a lot of code changes for applications to work. With changes come bugs, and since systemd is as privileged a process something outside kernel space can be, it is only a matter of time before show-stopper security holes start happening and being exploited. Especially the code giving systemd full network access. Even if that code is 100% enclosed in a container, a kernel bug can bypass all that protection and allow a remote root exploit, potentially on the scale of the RTM worm, if not worse.
Has systemd even seen a code audit? This is vital stuff here in the enterprise, and both Oracle and Microsoft can guarentee that their code has been through a proper audit process. It doesn't mean it is 100% bug free, but it has been analyzed by someone looking for any potential security threats.
These are not trivial complaints either... if RH and other distro makers lose this gamble, they lose the enterprise.
What does Linus Torvalds have to say about all this?
Most sysadmins do write init scripts, but I'm not sure of what you mean by "set it and forget it." I would prefer to forget every piece of work I do once I've done it, but that's not possible for a sysadmin: it has to be documented for the next guy and updated when new releases come out.
"set it and forget it" is maybe a desktop concept where the fight against chaos is considered futile and ease-of-use is an entitlement.
"* LibreOffice, no, because as far as I can see it is launched manually. Now, it may need to ask for system resources that may or may not be started at initial boot, but that's a easily partitioned block of code that can see if systemd is there, and run only when it is."
I'm running libreoffice as a daemon for converting documents, something like:
http://www.linuxquestions.org/questions/blog/sag47-492023/headless-file-conversion-using-libreoffice-as-a-service-35310/
"You sure do like creating false dilemmas dont you?" - sorry, i can't beat you at that.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
None of these threads contain a really scary point I read on other boards. SystemD and its use of RPC (or "IPC) try to do an end run around the GPL. In effect they use the RPC to communicate with GPL code so that redhat and others can use the Lgpl-> proprietary code instead. That's why systemD has been so unstoppably infecting everything over the complaints of users. Its all money and commercializing linux. Lennart has no real rebuttal against this and definitely isn't mentioning it anywhere. Its all pooh pooh, its better and you guys are whiners.
http://forums.gentoo.org/viewtopic-p-7645524.html#7645524
B--b-b-but AGILE! And DevOps. If you just keep the machines working and performing their mission-critical business function, you probably just e-leverage synergies. You need to bro down and code, bro! AGILE! DEVOPS! If you're not using the fad of the week, you're not DEV enough to Agile your DevOps!!
I'll finish that quote for you.. "Eventually Red Hat realised that the problems we solved with Systemd were relevant, and were problems that needed to be solved, and that you couldn’t ignore them."
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
system sets defaults that use known NSA weakened constants and algos. That should help you understand how it managed to work its way into most of the distros. Not a big deal, they got to Linus too. Systemd is a joke, and it greatly impacted the stability of my system, causing me to lose data constantly(I back VERY frequently now). I will be leaving Ubuntu behind for their adoption of system, and I will leave any distro that decides to force this garbage on me. /. deletes anything that is not on message; its a propaganda outlet, like Pravda, popular mechanics, or cnn.......
Not that anyone will see this comment, as
They do.
You, mister six-digit-slashdot-ID, are simply a vocal minority.
You're not important as you think.
Its just an end run around the GPL to create a commercial linux.
http://forums.gentoo.org/viewt...
why does this post keep getting deleted.
OR, because Redhats main customer is the US gov, they said "use systemd" or no more $$, and they could not go back to actually working for their money after the salty taste of pork. Please /. delete all actually relevant comments.
Well in this case, get some education before you post in ignorance. No it doesn't require a lot of code changes for applications to work. Why would you say that? Did you even bother to read the interview? Daemons don't require any changes either, though you can compile your daemon to use libsystemd to do backwards-compatible socket registration. In other words a daemon can be configured to use socket registration if it runs under systemd, but it will fall back to normal sockets without. So no backwards compatibility is lost.
Systemd requires only 3 parts to run: the init process, udev, and journald (which can write to syslog still) for early boot debugging. NOTHING else is required. And none of this pushes *any* special requirements on applications. Pottering himself says he has no idea where this notion that Gnome depends on systemd comes from. It should work fine on ConsoleKit. The problem could be that the Gnome devs haven't been maintaining the ConsoleKit code.
Instead of borrowing a startup controller design from Windows he should have stolen one from AIX (Subsystem Resource Controller). http://www.datatrend.com/trendsetter/Issue_01_Articles/1TechTip.pdf
Other than nominally violating the Unix KISS philosophy, SRC's design suffers none of the shortcomings of this bozo's.
How many hundreds of servers do you administer?
Those of use who admin huge data centers say systemd is bloated badly engineered garbage; we have experience and deal with the latest softares too, so can't be "dinosaurs"
You just want something to make your laptop easy to use
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings
Not many which is kind of their point. Init is simple and strait forward, sometimes its simplicity creates its own challenges but once you get those problems solved, you can forget about it for the rest of the support cycle.
Init does the same thing everytime. If stuff starts in the right order once, it will again the next time the box is restarted.
I am not going to claim systemd isn't deterministic, but what it will or won't do might be impacted by side effects. Before you had your daemon start after the db did by calling that init script after the db script. The db rc scrip did something to not return until the database was ready.
No with systemd your service depends on the database. So systemd starts the db, than your daemon, okay but 10 months later the datbase file is 10gigs larger and takes longer to mount maybe the db engine appears to be online to systemd but isn't ready yet, something new happens.....
This is a not as easy to test as a sysadmin. There is a greater chance of surprises, and unknown interactions, by nature of the system being more complex.
I don't hate systemd, something a little more situationally aware than init (I say this as a Slackware user) would probably be nice for desktops and anything portable. I am not sure that is systemd, but it might be. I don't see the risk/reward equation turning up favorable in most of the server situations I have been responsible for or seen. Most of the problems in that space have good domain specific solutions that are strait forward for any decent admin to implement maintain, understand if they are taking over for someone else already; and they don't require a major fork-lifting of software that has proven stable for decades, in many cases.
The only thing that would be nice is a some what generic clustering solution like Windows has. It needs to be able to do things like monitor machines state and arbitrary daemons, as well as move resources like disk arrays around between hosts, swap ip and mac address for virtual ips, etc. That might be something a thing like system finally makes easy(I won't say possible, you can do it now I have seen it but its always highly custom).
Systemd might not be all bad even in the server space, frankly its the speed of adoption and rate of feature growth that worry me more than the changes themselves. It would be nice to see it happen on desktop oriented distos first, get the feature build out mostly done and then migrate the server oriented platforms.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Can we have a cut-down, simplified version of systemd for servers and doesn't try to replace several layers of server side system functionality such as logging?
We already have that. Journald is optional. You can turn it off.
"Well, do you actually take on board the concerns of system administrators and enterprise users?" - what do you class RHEL as?
I'm addressing this to Lennart, not RHEL.
In the free world the media isn't government run; the government is media run.
How many professional SysAdmins and enterprise users are regularly tinkering with their init settings? It is usually a set it and forget it type of thing.
As I see it, this is just general IT Ranting because something is new.
Because 'new' usually means untried, insufficiently tested, poorly documented etc. All the kinds of things that IT does not want in production systems, because it will mean the pager going off at 2am on a regular basis.
In the free world the media isn't government run; the government is media run.
SystemD and all the Linux variants that adopt it are just Borg'ifying as another set of distros
It's like Star Trek with a Mirror Universe.. lots of similarities.. but ultimately "Not-Linux"
Stallman must be enjoying SystemD and the Irony
GNU Linux vs UNG Linux
I think the best way to characterize things is to say that some system administrators think it's their job to write bash scripts, and further that the OS should just be the simplest possible platform for launching shell scripts.
And yes, it is just general ranting.
"It's new!" Wow, that's never happened to anything in IT before!
"It's untested!" 20 GOTO 10
"I shouldn't be forced to learn it!" Such unfair. Many learns. So sad.
I'm pretty sure that systemd opponents are bad admins and worse coders.
Seems that Lennart decided to follow the early paths of his boyfriend Bill Gates in many ways
I'd read "worked its way into almost every major distro" as "bought its way into almost every major distro" + like by people actually employed by Red Hat like in Debian comitees
Only difference is that now these are now comfortable Linux admins afraid of learning new stuff or losing out to new techs.
It is no secret that computer Science is stagnating now like legacy computers used to be when the admins are untouchable, always warning that new changes will break what already works; reliability over innovations.
Could libreoffice, gimp, etc. be made to be indirectly dependent of systemd?
For example, what if Red Hat dictates that only recent versions of Gnome will work as the DE - systemd will reject any other DE.
To run libreoffice, you will need some sort of WM/DE, and since only one is available, you will have to use Gnome, which means you will also have to use systemd.
@Anonymous Coward: "You know how you hear that after a customer service call? Well Poettering's statement has the same meaning."
Have you tried subscribing to the systemd Development Mailing List?
* Samba, yes, because it's a daemon.
There's no reason why Samba would benefit from being dependent on systemd. OpenRC provides the same functionality as systemd's init process, and smbd and nmbd are already long-running daemons, additional instances of which are managed by the initial daemon. Tools like daemontools (or, you know, init) already exist to start (and if necessary, restart) long-running daemons.
SaMBa is used in far too many places to really want to take on systemd as a dependency. It's used on everything from traditional Unix systems (HP-UX, AIX, Solaris) to Apple's MacOS, Linux, and embedded devices running Linux or a BSD. It would make zero sense for them to require systemd as a result.
This is also one of the issues that many, including myself, take with systemd since it now makes it harder to write portable software - one of the reasons many devs went to Linux from Windows.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
The parallelism that systemd developed was for the benefit of those that create and kill instances of Linux all the time so fast booting is necessary and i guess thats part of a system administrators task list (and it benefits desktop users as well).
Have you ever seen a real server booting? After minutes checking RAM, initializing controllers and finding harddisks it just doesn't matter if the linux boot takes 15 or 20 seconds. Because another machine has already taken over.
And servers are only rebooted for major upgrades and kernel security fixes.
Well in this case, get some education before you post in ignorance. No it doesn't require a lot of code changes for applications to work. Why would you say that? Did you even bother to read the interview? Daemons don't require any changes either, though you can compile your daemon to use libsystemd to do backwards-compatible socket registration. In other words a daemon can be configured to use socket registration if it runs under systemd, but it will fall back to normal sockets without. So no backwards compatibility is lost.
Systemd requires only 3 parts to run: the init process, udev, and journald (which can write to syslog still) for early boot debugging. NOTHING else is required. And none of this pushes *any* special requirements on applications. Pottering himself says he has no idea where this notion that Gnome depends on systemd comes from. It should work fine on ConsoleKit. The problem could be that the Gnome devs haven't been maintaining the ConsoleKit code.
Yes ConsoleKit stopped being "maintained". This is why project like Devuan have put their weight behind people doing things like ConsoleKit2.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Yes, those of us whose systems have to run 24/7 for years at a time do actually prefer reliability over The New Shiny, thanks.
I finally had to try a version of Linux running systemd. Even the installer tends to say 'oh crap, I couldn't boot' and give absolutely no explanation of why. Real warm fuzzy feeling that gives me.
Does Devuan have a chance?
Systemd is clearly Red Hat's attempt to monopolize Linux. And I am afraid it will work.
What we are seeing now is only the beginning. Within a few months, about 95% of all Linux installs will be running systemd. Once that happens, Linux will be completely at the mercy of RH/Poettering.
Red Hat is going step-by-step from Microsoft's playbook. Even the propaganda is the same: "users demanded it" "the only people who don't like it are a handful of Luddites" "the decision has already been made, why are you fighting it."
Pidfiles are a bad way to manage processes. Some things you can't actually do with a script.
You think your job is to write scripts. You think the OS should be a limited base which exists to execute scripts. Good, go do that.
The rest of us need a plumbing layer that isn't cobbled together by hand, and an OS that can actually manage services and resources in a non-half-assed manner. And by "the rest of us" I mean the largest part of the rest of the users and OSes on the planet. Writing things in C is also part of the Unix philosophy -- but you don't know how to do that as well, do you?
If they aren't maintaining Consolekit, to say it should work fine on that is sort of nuts. Note the word "should" -- in other words, if you don't mind a broken Gnome setup, or one that is likely to fail as much as work in the future, than yeah, systemd isn't a dependency. That's like saying your computer should work with intermittent power outages -- sure, it'll crash when the power goes off but it will work the rest of the time. Just make sure to set your autosave timer to 10s intervals.
What changed under Obama? Nothing Good
However, you can not force other people to keep supporting your preferred alternative. Either contribute patches or pay RedHat or another commercial provider whatever is worth their time to maintain the alternatives for you. You want shell script-based init to tinker with your system, right? Well...
Bullshit.
You're not listening to Linux, you're not listening to the folks who forked Debian, you're not listening to all the sysadmins who work for a living in organizations, and have enough trouble getting the users to accept updates.
In addition to which, you replace it with something that requires more typing, and does not give any feedback.
service nfs restart
stopping nfsd
starting nfsd
etc.
systemctl restart nfs
And the entire concept of *BINARY* logfiles, when you're trying to fix a broken system is insanely stupid, as are xml configuration files when X won't run, or isn't installed (like on a server). And telling me that oh, it boots up *so* much faster means something *only* if I'm on a laptop. Anything else, hell, an fsck takes *far* longer.
It's a pain in the neck, and you won't make *any* accommodation to the 99% of us that have been doing it the way we have all along. Arrogance and solipsism, that's you, Poettering.
mark
I think that Lennart Poettering and Kay Sievers have this quiet fantasy running through the back of their minds that they too will one day be revered and spoken of in hushed tones, like Ken Thompson, Dennis Ritchie, Linus Torvalds, etc when, based on things like the general poor quality and popular dislike of things like PulseAudio and Systemd and their general quality of work attitude (Google why Linus banned Kay from submitting kernel patches) they will, instead, be reviled. (Of course, I could be wrong and their code/projects will be the best things since sliced bread.)
It must have been something you assimilated. . . .
From "SystemD Abomination"
Subject Vested interest in control. RedHat and SystemD
Date Mon, 17 Nov 2014 04:40:08 +0100
by beaverdownunder:
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.
https://lkml.org/lkml/2014/11/16/301
Why is the role of systemd constantly expanding?
If systemd is supposed to just be an init replacement, then why all the crap like binary logging? Why all the hardwired requirements?
I think the following exchange from TFA says it all about Lennart's attitude and, ultimately, the problem people seem to have with him and his work. Basically, if you agree with him and his way of thinking, you're young, quick and progressive otherwise, you're old, slow and conservative.
LV: Why do you think some distributions managed to adopt Systemd without any major fights, and then others like Debian had very intense debates and resignations? Is it just because it’s a distro with more political processes?
LP: Arch Linux probably did it the quickest way. You know, distributions attract different kinds of people, of course. If you looked at Arch Linux, it attracted very progressive kinds of people – like power users. They’re progressive and want to make the best out of their computers. So it was easy for them to adopt.
Then if you look at Gentoo, for example, they still haven’t done Systemd as default. They used to be like Arch Linux is now – they used to be the young people who adopted things quickly. But the Gentoo people aged, and they became more conservative.
And Debian is probably an even more conservative bunch. Debian is a really old project, and many people from back in the old days are still active on it. So they have longer release cycles. And Fedora always defined itself as being on the bleeding edge, of course, so it was easier. Well, not that easy – some people don’t realize that inside of Fedora and inside of Red Hat, there were lots of fights. So it’s to do with the culture around the various distributions. And Slackware are the ultra conservatives!
It's sad that Lennart is, obviously, so very smart, yet, apparently, so very stupid. Perhaps that will change as he gets older and stops to actually think about things for a bit before speaking - or coding...
It must have been something you assimilated. . . .
That's funny, I thought it was solved by startpar!
Look under the hood a bit and try to tell me that hot mess is easier to config than a handful of init scripts.
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.
Poettering hates Linux. He is hardly even shy about it. He speaks glowingly of Microsoft, and is dismissive of stuff like POSIX, or the UNIX philosophy. He constantly expresses contempt for "UNIX grey beards." Poettering clearly loves the idea of one company setting the standard for everybody else to follow, just as he loves the idea of a giant proprietary goo ball that does everything.
Usually, I have no problem with Linux haters, because they have no effect on me, or Linux. But Poettering is dictating the future of Linux.
Why doesn't Poettering go work for Microsoft, and make everybody happier?
So you trust that the journald binary reads the "don't save data" boolean value and doesn't just ignore it, or worse, ignores it and executes this shell script:
Or, more plausibly, does all that in a binary blob? Sure. It's open source. Sure I can check the code and compile it myself to make sure it meets my need for security. But one of the things about using these "pre-built" distros is that I'm probably using it to save time and money, which means I don't want to be bothered with doing a code check and recompile on every single init package. That's the beauty of init scripts that everyone has apparently missed in this debate. One human readable script for each daemon running, so the configuration of a daemon can be gleaned over for any questionable bits and edited in less than 10 minutes. And being scripts, they're all plain text that's automatically executable. I don't need to read over source, find an issue, edit it out, and then recompile the entire init code into a binary for that daemon to make use of it. That goes for PID 1 as well. If it's not a script that can be quickly edited and then it's ready for the next boot cycle without wasting process cycles for recompilation I don't want it on my production server.
Considering that we have SMF from Sun and launchd from Apple as well, there was no need to reinvent the wheel.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
If "no one's forcing you to use it, use something else," may I just use Windows?
* Samba, yes, because it's a daemon.
There's no reason why Samba would benefit from being dependent on systemd. OpenRC provides the same functionality as systemd's init process, and smbd and nmbd are already long-running daemons, additional instances of which are managed by the initial daemon. Tools like daemontools (or, you know, init) already exist to start (and if necessary, restart) long-running daemons.
SaMBa is used in far too many places to really want to take on systemd as a dependency. It's used on everything from traditional Unix systems (HP-UX, AIX, Solaris) to Apple's MacOS, Linux, and embedded devices running Linux or a BSD. It would make zero sense for them to require systemd as a result.
This is also one of the issues that many, including myself, take with systemd since it now makes it harder to write portable software - one of the reasons many devs went to Linux from Windows.
samba.c:
if (systemd_present) do_systemd_stuff()
else
do_other_stuff()
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Personally, I think it is a very real possibility that this is by intent. Not by Poettering himself, he is just a clueless pansy full of himself. But he is perfect for this. He is far, far to incompetent to even realize that software has to be simple in order to be secure. He does has a proven track-record of producing buggy, complex software. He has absolutely no experience with producing secure software. He is known to be resistant to advice and learning. He is known to not work well with others. He thinks he knows it all and has it all.
In one sentence: Perfect for creating a complex monster that will never, ever be secure.
My money is on the NSA and others (remember, Red Hat is mostly funded by the US military) having selected Poettering to sabotage Linux security. This is actually the main reason why it will never find its way on any of my systems. Having the TLAs being the greatest threat to security and privacy is one thing. Inviting them in is something else.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Linux has almost two orders of magnitude more code than systemd, and it changes all the time. Security vulnerabilities are far more likely to be in the monolithic kernel.
Yes, that is an excellent reason to add even more vulnerability vectors!
At least when it comes to the kernel and networking, I have iptables in between.
With SystemD starting the network stack before starting anything else (including iptables), I can no longer even firewall off potential exploitable services.
Too bad they didn't bother to include a functional services manager inside the systemd "service manager" that could bring up iptables before the network stack, perhaps using some dependency based system.
But I fully understand how no mere mortal can wrap their head around the concept of renaming a symlink so iptables rules are prefixed with a lower number than your network services and thus load in a plain clear obvious order.
Maybe one day computers will be able to know "10" comes before "20" without 250 megs of additional software. One can dream at least.
Misdirection. FUD. Bullshit.
Damn shills.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
These people actually know that systemd cannot compete on merit. Hence they try to muddy the waters. This is a PsyOps campaign, plain and simple. And a rather obvious one.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I've been a Unix/Linux admin and developer since BSD was ported to a Vax 11-780. So anyway, for this grey beard, I've been around and have many opinions. /etc/init, oh and 1652 bytes for /etc/inittab). That it folks. 349k for sysvinit! Now compare that to systemd, Just in /usr/lib/systemd there are 77 binaries (4.6M), 247 control files (924k) and assorted others and what appear to be 1000's of sym-links everywhere. Speed-wise, I think systemd is much slower. Lastly, if your actually trying to do something with this pile of crap, it's spaghetti code in the 247 control files, because of all of the references to other control files; so it has Want's, Before's After's, Also's etc through all of the config files.
I've always said Linux is a better version of Unix than Unix. And it's been true. Linux is very innovative in it's approach. SystemD is the biggest pile of crap ever hoisted on the Community. First, the size difference. Comparing Mageia1 (sysvinit) to Magiea4 (systemd), Mageia1 = total 393k (308k init.d scripts and 40k for one binary
My biggest pet pieve is the systemd filenames; They have a new lingo to learn on what a unit is; so you have post fixes .wants .service .target .socket .slice .mount .path. For example the config file to start the cups daemon consists of cups.path cups.socket cups.service cups-browsed.service cups-lpd@.service cups-lpd.socket, and less we forget, printer.target! It seems to me that a smarter design would have consolidated into one control file and built some intelligence into the binary that reads these.
Brain dead filenames; in Magiea4 systemd, if your trying to understand this spaghetti, you might turn to trusty old 'grep' and try to find what references 'printer' for example, so you go to /usr/lib/systemd/system and type 'grep printer *' . You will get the following cryptic message;
grep: invalid option -- '.'
Usage: grep [OPTION]... PATTERN [FILE]...
Try 'grep --help' for more information.
The joke is on you bud. Some bozo decided to name the file '-.slice' and Unix/Linux wild card expansion treats it option. I daily use that is hard to work around. I've reported this as a sever BUG because it breaks all kinds of stuff. And to top it off, you can't just rename the files. The '-.slice' '-.target' '-.mount' are hardcoded into the binaries. There are also some just plain ugly file names too; like getty@.service. Why the dumb-ass @-sign. At least you left getty.target alone.
And for diskless clusters, Systemd appears to be needed in initramfs as best I can tell. Because /usr/lib/systemd (and all the support libs) need to be loaded at the time init is performed. In magiea4 it looks like to get around this issue, they copied the entire /usr/lib/systemd tree into /lib/systemd on soft linked /usr/lib to /lib during boot. It's such bloat to do a very simple init.
I am stunned that all of the Linux distribution have agreed to use this steaming pile. Every linux guru I know hates this thing. Every cluster vendor I know hates this thing. The user community is in an uproar and once installed and it's decencies are locked in, everything will require it! Right now I'm desperately looking for alternatives for the Cluster environments.
If you run big systems, HPC systems, clusters, it's big trouble.
Wrong. That base still wouldn't boot my server for me and the systemd people would still be spinning in circles unable to even conceive of a way to fix it. You see, I want the server to boot w/ btrfs in degraded mode should it suffer a drive failure. But systemd won't do it.
I don't know about Suse, byt Red Hat does not. Otherwise they'd have noticed that sysadmins are sticking with RHEL6 to avoid systemd trouble.
Since systemd can be configured to simply call the upstart or sysvinit scripts, why would it not work?
Uh, apt-get install gimp brings in systemd, even if you don't have it installed.. Go on, try it.
Why is everyone putting all their energy bashing at Systemd and Lennart instead of complaining to the distro maintainers? Turn your anger at Red Hat, Fedora, openSUSE, etc, they are the ones pushing Systemd down the throat of the Linux community. In the end, the distros decides what software to include by default, nobody forced the distos to switch to Systemd. "But Gnome 3 depends on Systemd!" So what??? Boycott Gnome 3 then and don't ship it with your next release, it's not like there are no alternatives!
I made my 2 little girls, 5 and 7, compile their own code for their electric, driverless Barbie Car, and when I suggested they use systemd, they shouted at me that if they wanted a Windows box, they'd run a Windows box and then I mentioned that Poettering listens to the community they ran out into the highway screaming and then the social workers came and all I have now is this stupid Barbie Car. Poettering ruined my life and he'll ruin yours.
"He's using a quantum encryption scheme! That'll take hours to break!"
Well, do you actually take on board the concerns of system administrators and enterprise users? ... How about listening to the system administrators?
As I stated 3 months ago, in a roundabout way, with evidence: no he does not.
OpenBSD is trying to move from rc.conf.local and inittab into per-daemon startup/shutdown init.d scripts.
It's a shame that someone didn't swoop in with bare-bones unit file functionality (no cgroups, obviously). At least, with a unit file, PID 1 can launch a non-root process, which is hard with SysVinit (I do wonder if I've written my shim correctly).
...that, while this part of the conversation might not have been the strongest part of the interview, systemd has won an amazing number of technical battles.
FWIW IMHO, absolutely no, a unified development approach is not the main benefit of systemd. The new functionality is absolutely worth the transition pain. Not only can you control (kill) whole classes of processes more simply than ever, but you also get lightweight containers as a door prize.
Because it's not willing to move past seeing that there is a storage volume with a missing dependency (the dead drive) so it stops right then and there. If I could get it to ignore that and move on, that would be fine but since nobody on the dev team ever considered the possibility, the capability isn't there.
I haven't seen any way to tell it that things systemd wants to do before it even parses the services are dependent on a script being run.
SaMBa is used in far too many places to really want to take on systemd as a dependency. It's used on everything from traditional Unix systems (HP-UX, AIX, Solaris) to Apple's MacOS, Linux, and embedded devices running Linux or a BSD. It would make zero sense for them to require systemd as a result.
This is also one of the issues that many, including myself, take with systemd since it now makes it harder to write portable software - one of the reasons many devs went to Linux from Windows.
The same could be said of Gnome, if the developers want it to be able to be supported on other OS's besides Linux (like, traditionally, the BSDs and other unixes. Sadly, they seem to be moving in the other direction, unless other OS's make some "systemd" like interface (or maybe "uselessd" as a replacement).
Why would gimp do that?
I don't understand the people who are pushing systemd so hard despite significant resistance in the community. Reasons for disliking it vary, but don't really matter, because its adoption will force a *lot* of people who don't want it to either suffer through it or suffer through migration to another OS/distro. That is reason enough not to adopt it. Trying to discredit people's reasons for disliking it is presumptuous, pointless, and rather stupid.
I have no opinion on systemd. However, more granular fault isolation wasn't convincing when Tanenbaum and Linus were arguing microkernels vs. monolithic kernels, so why should it be convincing now?
Every condemnation leveled against the monolithic systemd are just rehashed arguments of monolithic vs microkernels. Monolithic kernels clearly dominate, and chances are systemd will similarly dominate, so instead of wasting your time battling the tide of history, perhaps you should be more constructive.
Higher Logics: where programming meets science.
Granted, but more granular fault isolation wasn't convincing when Tanenbaum and Linus were arguing microkernels vs. monolithic kernels, so why should it be convincing now? I'm certain your other complaints are fixable given the current framework, assuming there aren't other mitigating issues.
Higher Logics: where programming meets science.
A lot of people have complained that GRUB blew up and broke their boot.
Let's find the motherfucker behind GRUB and stab his eyes out with kitschy pixelart spoons, amirite?
Y'all are bitches. That's what the problem is.
I'd like to see an init system like this:
- Starts services on demand based on dependencies, not based on order (like sysvinit) or based on events (like upstart).
- Has a minimal core that can easily run on its own, just to do the job of a standard init system.
- Is easy to learn, configure, and understand.
- Has good documentation.
- Does not encourage application software to require it.
- Does not encourage other system services to require it.
- Works well on linux and non-linux unixes.
- Can be replaced without causing such an upheaval that OS distribution teams are scared to switch again if something objectively better comes along.
- Causes a lot fewer problems than the stuff that I've seen from systemd's author.
- Is maintained by people with the humility, competence, and care required to make it work well for the vast majority of users.
Systemd pushers often claim that it is the way forward because it addresses that first piont. They conveniently avoid recognizing that it fails on most of them. No thanks. I'd rather keep using sysvinit or upstart until something better comes along.
Samba is no longer used in Mac OS X.
Apple got rid of it as part of their GPL software purge.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
more granular fault isolation wasn't convincing when Tanenbaum and Linus were arguing microkernels vs. monolithic kernels, so why should it be convincing now
The question was one of whether the benefits outweighed the drawbacks. But systemd isn't actually monolithic, it's monolithic by fiat because the daemons refuse to play well with others, which (again) is against the Unix Way. It's taken until recently for Minix to become even vaguely usable as anything other than a learning operating system, it's lagged behind everything else in terms of features always.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Bug report?
Watch this Heartland Institute video
Why would daemons need to change?
If the cost of using anything but systemd is high enough almost nobody will be willing to pay it. Given no other choice, users will use systemd.
On my system even Chromium depends on the systemd malware. That's right, a browser depends on a specific init system. The long-term objective is to transform Poettering/Linux into Windows. Hopefully I'll manage to flee to a *BSD before then.
Personally, I think it is a very real possibility that this is by intent. Not by Poettering himself, he is just a clueless pansy full of himself. But he is perfect for this. He is far, far to incompetent to even realize that software has to be simple in order to be secure. He does has a proven track-record of producing buggy, complex software. He has absolutely no experience with producing secure software. He is known to be resistant to advice and learning. He is known to not work well with others. He thinks he knows it all and has it all.
In one sentence: Perfect for creating a complex monster that will never, ever be secure.
My money is on the NSA and others (remember, Red Hat is mostly funded by the US military) having selected Poettering to sabotage Linux security. This is actually the main reason why it will never find its way on any of my systems. Having the TLAs being the greatest threat to security and privacy is one thing. Inviting them in is something else.
Actually thats kind of my theory on IPSEC... far too complex to configure, unnecessarily so. Easy to 'accidentally' set up IPSEC in unsecure ways because the system is so fiendishly complicated it almost encourages the administrator to make mistakes.
In the free world the media isn't government run; the government is media run.
There was no GPL purge. However, there was an effort not to use GPL v3 software. This is also being done in FreeBSD.
Otherwise you wouldn't have written this abomination called systemd, of which no system administrator wants to touch, and which not only brings nothing good (there were tools and init systems that could do the same if you wanted) but instead a lot of bad.
Take your own advice.
ConsoleKit is dead, it was EOLed.
Microkernels are arguably more "Unixy" than monolithic kernels. Each device driver is simply a process that has a well-defined stream interface that can be piped to any other process, not just the kernel itself. Microkernels are Unix taken to the extreme.
So again, this argument failed for microkernels, so why should it succeed here? Perhaps some core functionality, not just system calls, should also be in some monolithic service and not a set of composable subsystems.
Tanenbaum and others weren't arguing that Minix was the microkernel OS that should be selected, merely that some microkernel should be preferred over monolithic kernels. The high performance L3 and EROS microkernels both existed at the time, albeit in early stages like Linux.
Higher Logics: where programming meets science.
There is a confusion of two aspects of "monolithic" here, and unfortunately Poettering did not clarify it well:
1) "Monolithic" in terms of a single repository for all code. The systemd project is monolithic in this respect, and Poettering is absolutely correct that this is the classic Unix way. All the *BSDs are maintained this way. Linux is thus, as he correctly points out, the anomoly.
2) "Monolithic" in terms of tools that depend on each other. The systemd system is not monolithic in this respect. The only two required components are journald and udev. Everything else is entirely optional and replaceable, but "recommended" in the sense that the people working on the project really think that these components, written from scratch, are of better quality and consistency than the existing components they replace. But some hysterical people hear this recommendation as "forcing it down our throats". Distro makers will decide which components to use, whether those in the systemd project or the existing ones. Obviously, the existing ones have the benefit of maturity.
Also, he doesn't point this out in this interview, but these new components are also better at reporting errors in a way that the whole init would be more robust when certain components have partial failures (and systemd knows how to deal with them). This is especially crucial for servers with complicated, layered network stacks. People say that systemd is for desktops, but really it is just as important for servers to have a robust initialization of services.
Prove it.
$ apt-rdepends gimp| grep -i systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Gimp uses dbus to do a named pipe to the running instance if you launch it from the CLI and there is already an open instance under the current users context that tells it to open the new file within the existing instance, and dbus is now part of systemd. There are alternative ways to package Gimp that don't use dbus since it also run on Windows and other platforms, that just happens to be the simplest way with the current Gimp source tree. A LOT of what systemd is about is easing thing on package maintainers.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
If more people were willing to force failure to account for itself, as loud as necessary, Lennart wouldn't've had a chance to crap all over Debian. Now Debian's been infected and it might be incurable.
The old style init systems all relied on the shell - another large complex piece of software... And bash had a bad security issue last year.
It breaks systems, init processes and forces its changes on admins. The binary log solution that is mandatory is a very non-Unix/Linux solution. It cannot be trusted as it gets corrupted, with no explanation and no fix in sight. If an attack vector wants to hide, it merely has to zap garbage at the binary log. Evidence is gone with the standard LP shrug, 'restart the service' as the only reply.
The changes are not trusted as the developer is not trusted, a critical concept in FOSS that LP has yet to comprehend.
From user space? Pardon me but who gives a fuck? The system has to boot, run and be maintained. Otherwise the users have NOTHING to use.
... then we mock them.
Oddly enough he doesn't listen to users. Nope. He tries to figure out what they want. Which is very clearly not the same action although he doesn't see that.
LP shows that he has absolutely no concept of the Unix philosophy. Indeed, he veers off into weird descriptions of the repository for systemd and its coding style. He is 'bemused' by the misunderstandings of others. Additionally he states that fewer developers is better then later comments on have twenty plus commit authors the day before and 40 for the month.
The connection with Upstart is explained, in his unique way, by stating that it was exactly backwards of what was needed. The computer needs to make all the decisions about processes and not the administrator. To be honest I am not sure he meant admin or user in this case.
Good luck, getting a word in sideways much less getting him to listen to what you say without him editing it thusly: g/*/s//LP grand vision/p
An interesting article. Linuxvoice did everything but offer to have his children.
Systemd, from the man that doesn't understand Unix files. Yep, that's the guy.
Thanks, Baghdad Bob, but I've been monitoring the purge for some time.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
As the IPsec RFC was finalized by an NSA employee alone, this is very, very likely. They just had not learned how to camouflage their actions properly. The sabotage by making it very complex to implement and configure right, and by including multiple insecure options that you can easily select by accident, is very, very obvious in retrospect. The other aspect is that then their agents could kill other efforts by saying "but we have IPsec".
It is this type of sabotage that slowly erodes society. At some point, nobody trusts anything anymore and that is it for civilization. These people are vastly more dangerous than any religious fanatics.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Your rdepends is too limited. This is what people are complaining about:
$ apt-rdepends --follow Depends,PreDepends,Recommends gimp|grep systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Depends: libsystemd-login0 (>= 31)
libsystemd-login0
Caveats:
1. It gets pulled in via a recommendation, not a requirement, by way of dbus.
2. It's not systemd, it's an API library, so dbus can work with systemd if it exists
3. Systemd itself isn't being installed or required at all.
It's an overblown, "sky is falling" type argument that needs to just die already. Here's the list of dbus deps on Debian testing:
Depends: adduser
Depends: libc6 (>= 2.10)
Depends: libdbus-1-3 (>= 1.0.2)
Depends: libexpat1 (>= 2.0.1)
Depends: libselinux1 (>= 1.32)
Depends: libsystemd-login0 (>= 31)
Depends: lsb-base (>= 3.2-14)
You can see that it also depends on libselinux, but nobody's complaining about how SELinux is being force-installed on everybody's system as a dependency of gimp. You know why? Because the lib doesn't install SELinux, it's just an API lib, same as libsystemd-login0.
Why would gimp do that?
It doesn't, it's people crying wolf over an API library. Check my other comment for a better explanation, but the gist of it is gimp recommends dbus, dbus requires an API lib (libsystemd-login0), and people that don't know better are equating that to "OMG systemd infection!"
I don't even like systemd, but I hate that specific argument. It's just undermining legitimate complaints by making anti-systemd people look like clueless newbies that can't tell the difference in an API lib and an init system.
Not only does lenny make some fucking absurd design choices in systemd, the cunt is fucking young as fuck. Young people don't know shit about shit. He *looks* like he doesn't know shit.
He also comes off as a self righteous arsehole.
listening to users? Fuck off! Users have been telling this cunt for years how shit systemd is. And the cunt has not listened once, and certainly has done everything in his power to make systemd as shit as possible.
fact: it only works on glibc. What fucking uneducated ill informed fucking numpty would make such a choice? Too fucking bad if you want to run a libc that doesnt suck.
parallel startup and hibernate? Irrelevant for the vast majority of use cases.
Fuck you lenny you fucking utter twerp. You dont know shit.
Hey msg,
Why dont you fuck off already and pull your head in?
I think we all know you as systemd appologist.
Hence, your opinions are wrong.
And besides, no one likes a pathetic lieing appologist.
SystemD takes the Framework approach: it provides a set of features and a way to use them. The user of SystemD cannot escape that.
On the other hand, SysV init takes the Library approach: it gives you the tools that do a specific job, but organizing them and putting them together is a job for the user.
In that light, SystemD is actually anti-Unix, because the Unix way of doing things is the Library approach, i.e. a set of tools that one can use in whatever form they need.
Now that I've said the above, the real question is the following: is Init served better by the Framework or the Library approach?
So what? You afraid of pretty men?
Actually, no. The modern linux kernel is far more modular than in the beginning. Now you have kernel 'modules' that can be unloaded during runtime, which wasn't possible in the past. In the end the real debate was HOW to accomplish the modularity, not whether to make the kernel modular or not. The modern linux kernel is not as monolithic as it used to be, and has absorbed many of the features of the microkernel.
You can run the kernel with any number of modules according to the functionality that you need, with various levels of dependancy. There are even distributions that remove all of these modules for embedded devices. You still have a kernel that provides a way to speak to the hardware it supports even without the other modules.
Systemd is nothing like this. You cannot run systemd without journald for instance, not simply because of a dependency but due to bad design. There is no reason on earth that an init system would need a specific journal daemon, and yet you cannot run systemd without journald. To use any other journaling software you have to use the output of journald. Thus journald is not separate from systemd in any meaningful term.
And who in their right mind makes a logging daemon write to binary files? That is just retarded. The first thing you look on a machine that has failed in some way is to look at the log, and the tool to look at the log is almost always from another machine that is different than the one you are looking at [because that one is broken, duh]. A technician will use tools that he has on hand, which sometimes is only a text editor, or even just cat. To expect someone to install another piece of software on their machine just so they can see what happened to the server IS JUST FUCKING INSANE.
Because at this point, systemd is way beyond a "mere" init.
via logind it is a seat and session manager. This makes all kinds of government/military admins hot and bothered as the can strictly define what some account can access depending and where and how they log in. Come in via a remote shell session? No high security files for you, etc.
Also, it is gaining container related "features" like wildfire. Recently a json tokenizer was added so that it can digest Docker containers directly. And RH is betting big on beyond a cloud services provider now.
Right, so make the kernel modular via isolation which provides fault tolerance in your most critical piece of code, or make it monolithic, ie. everything lives in kernel address space.
There is no reason on earth device drivers need to live in kernel space either. Performance arguments are simply false, and this point has been disproven many times over.
Of course arguments and hard data aren't meaningful in these discussions, and monolithic has clearly won in terms of marketshare. Once again, why fight the tid of history instead of being more constructive? You are going to lose.
Higher Logics: where programming meets science.
There is no reason on earth device drivers need to live in kernel space either. Performance arguments are simply false, and this point has been disproven many times over.
Actually the performance arguments are the only arguments. Everyone is agreed that separating the various components is necessary for system stability. Yet for machines like home computers it is simply not possible. It is only with the relative advance of hardware that the microkernel can actually get close to a monolithic kernel in terms of performance. The address space separation always comes at the cost of inter-process communication and context-switching which necessarily have performance consequences. It is this performance consequence that made Windows NT, originally designed on a microkernel architecture, move towards a hybrid kernel. However even Windows engineers have struggled to move towards a microkernel, with Vista being the first version I believe which had some drivers run in user mode.
Of course arguments and hard data aren't meaningful in these discussions, and monolithic has clearly won in terms of marketshare. Once again, why fight the tid of history instead of being more constructive? You are going to lose.
Actually the monolithic kernel has already lost the marketshare battle. There are far more Mac and Windows installations than all Linux distributions combined. These are all microkernel or hybrid-kernel architectures.
You make an error in thinking that history has already been written. Unless you are a prophet of some sort, there is no way you can tell us what the tide of history is at this moment. Systemd may indeed be the end of Linux in server space, as many serious companies are already migrating to the BSDs. How large this migration may be we won't know until the statistics are taken after the fact. I'm old enough to remember the commercials for "New Coke", which was vaunted to be the formula to crush the competition. In reality the competition destroyed Coca-Cola. Systemd is all about marketing, and nothing about engineering. It too will fail and be replaced, just like PulseAudio by ALSA.
This is not true. The L4 kernel ran Linux as a guest OS with 5% overhead. This was the birth of hypervisors like Xen, which are really just a sort of microkernel. Virtualization is everywhere now, and no one seems to be complaining about overhead. If you can run a virtualized host with so little overhead, native execution is at least as fast as your guest.
It's perhaps too easy to introduce performance problems via a poor choice of decomposition, but that doesn't entail that decomposed systems must necessarily perform poorly.
Poorly designed systems perform poorly. The NT kernel might have been a nice kernel design from some people's standpoint, but then people thought the Mach kernel was a good microkernel too. Both opinions are incorrect.
There is no such thing as a hybrid. You are either on fire, or you are not. You are either a microkernel, or you are a monolithic kernel. Mac's may use the Mach microkernel, but it's a poor kernel and the BSD subsystem really consists of most of the system calls, which all execute in kernel space. This is a monolithic kernel that has a poorly designed microkernel as its ancestor.
Except PulseAudio hasn't been replaced, it's still used by most distributions.
Higher Logics: where programming meets science.
I think you're missing the point of the previous post. It is one thing to inter-operate with an init manager, like systemd, upstart, openrc, or sysvinit. It is quite another thing to be wholly dependent on a single init manager, which is the route GNOME has chosen to go.
A program can inter-operate with multiple init managers without having to be dependent on a single one of them.
There is no such thing as a hybrid. You are either on fire, or you are not.
That is such an idiotic statement that I won't even bother continuing the discussion. This link is the wikipedia page. And is Linus himself speaking about the mix of kernel architectures.
The people who push systemd have serious issues with reality it seems. Pulseaudio is a brain damaged piece of software and one of the first things to be removed in any distribution.
All of the bickering around systemd ticked my nerves to the point I just can't even. Y'all are why I use Windows for more than games now.
I don't think you understand the scope of systemd. It does far more than managing services. Gnome and Gimp for example are dependent on it.
How do the daemons refuse to play well with others? Do you have any examples on this?
As far as I see, nothing prevent me from replacing any specific daemon with my own implementation. With the possible exception of systemd/journald/udev
FTFY: As I see it, this is just general IT Ranting because something broke shit that was working for years
Prickering is a lying sociopath who is being used a shill to infiltrate GNU/Linux. Systemdestruction is an abomination that will turn GNU/Linux into a semi proprietary OS spearhead by RedCRAP.
How much of that is drivers and other stuff that can sit in a dead module until loaded?
Perhaps you should actually read the link you specified. Linus himself describes the term "hybrid" kernel as simple marketing, which is exactly what I said.
And yet, it's not removed seeing as it's still around and still quite popular.
Higher Logics: where programming meets science.
Is it nearly time for a name change for Linux? Once systemd establishes itself definitively as the system middleware layer than determines compaitibility of new software with the "core" operating system, maybe the name of the OS, Linux, will need to be changed to something more accurate -- like perhaps, SystemdOS -- or DOS for short. Linux itself could be kept around as an optional kernel plugin for the then industry standard systemd framework. This legacy setup could appeal emotionally to old timers crotchety enough to remember the old UNIX origins of SystemdOS. Besides, it would preserve the memory of the man Linus Torvalds who was so instrumental in paving the way for Lennart Poettering.