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.
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.
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 !!
"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)
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?
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.
I farted once on the set of the Blue Lagoon.
""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.
Because when you rip-out the entire init system, your ONLY concern is bootup and shutdown speed, isn't it?
Silly boy.
And, your experience is not necessarily generalised. Many people who do the above on working systems have ended up with non-working systems. And those who customise their machines rather than use only stock installs are also likely to fall afoul of other problems, aren't they? And, just because it boots faster, does not mean it boots reliably does it (many have reported that boots become faster but sometimes unpredictable - or even unbootable - because of various timing / dependency issues)? And even if the software is wonderful and does all the above, it doesn't mean that it's actually better for even a minority of users.
You've considered only the desktop aspect, in a perfect virtual machine, from a clean distro (by the sounds of it), in one instance.
Something tells me, replacing the entire Linux init-system globally might just possibly generate more problems than your contrived example. No?
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.
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?
He doesn't seem to know the difference between hearing and listening.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
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: 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.
Yes. it's nice to use a system that "just works". It's too bad that Windows isn't that. It may be fine for ultra-light use but if you push it a little around the edges it starts to fall apart.
These alternate init daemons have that same problem.
Their level of complexity and their assumptions make it far too easy to render your system unbootable. They create something that's no longer transparent or maintainable.
A Pirate and a Puritan look the same on a balance sheet.
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."
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...
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.'"
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.
First, Systemd is neither unwanted nor dangerous, until and unless you can give me a specific example.
Second, Any new technology does not belong on high reliability servers until they have been thoroughly vetted. No one is putting Systemd into stable releases yet, its still going through the vetting phase.
Third, are you running Upstart? That was a new technology once. It also had to be vetted, but You would be laughed out if you referred to Upstart as unwanted and dangerous. All told, Systemd can claim a great number of actual performance and ease of use improvements over most init systems including Upstart and sysvinit.
Fourth, Neither pottering nor anyone else has the kind of clout it would take to force these distributions to do anything (Possibly excepting Linus). The dastardly way Pottering got all of these distros to switch to Systemd was to present it on its merits! (I can see why that kind of foul play would be wholly unacceptable to you.)
At the end of the day, The anti-Systemd crowd fails to offer any concrete examples, and relies on rhetoric, which is why they are failing to stop the spread of Systemd. Systemd is winning, and quickly, because it is a technically superior solution to a problem that every operating system has to solve. The wonder isnt that Systemd is being adopted so quickly, the wonders are that it took this long for a good solution to appear and that so many people who are otherwise qualified administrators would choose to oppose it. I guess it just goes to show how many people in IT really can't hack it.
I wish I had a good sig, but all the good ones are copyrighted
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.
When you are administering machines you need to be able to have control over said machines.
When you cant win, ad hominem.
I created Bitcoin
"Leave the logging and console and other stuff alone." - other daemons do that work, not systemd e.g. journald, consoled.
Why can't scripts be launched parallelly? - why don't write some using Bash and see how it works.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
"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)
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)
This whole systemd thing is largely irrelevant to desktop users anyway. It's system administrators (read: people who use the console all day to do Advanced Stuff) who have a bone to pick. There's nothing wrong with being glad you are a Windows user, but it probably has nothing to do with Systemd. These news stories don't affect Joe Ubuntu much, just as news stories about HyperV nested virtualization don't affect grandma and her email even though she's on Windows.
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.
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.
He could have created The Washington Monument, that does NOT change the fact that the whacko thought it was perfectly acceptable to sit down ON STAGE no less and ATE TOE CHEESE in front of God and everybody!
Ya know just because somebody was ONCE an insightful person does not mean that they will always be insightful, hell or even sane for that matter. Here we have a person that shows he has no concept of correct public behavior, openly brags about being a homeless squatter, and his views are often frankly self contradictory and don't follow logic (see his "what is a circuit" for some truly amazing logic hoop jumping) and the man doesn't even have the grace or good sense not to piss on his own license by having a childish tantrum and naming a clause after a company he believed didn't uphold "the spirit" of the GPL instead of simply admitting he made errors when coming up with GPL V2. Any way you slice it the man is the best poster child MSFT and Apple ever had, he looks, dresses, and behaves like its 1979 and computers are just toys for homebrew clubs and academia.
As for TFA? Sadly Pottering is another one that MSFT and Apple really should send a fruit basket to, because its him and the devs of his ilk that keep Linux in the backroom instead of the showroom and the reason why is simple...they will NEVER EVER let Linux become fucking stable! I swear these devs and their "itch scratching" are from bizarro world, they are like "Oh noes, things am stable and most stuff am working! This is no good, users am happy and can update without breakage! Quick lets change enough internals that many devices am broken and stability worse than Win2K, that will make users miserable!".
I mean for fucks sake you had MSFT being run by STEVE "Buzzword McBingo" BALMER and you STILL can't gain share, ever wonder why? Well you had the DE devs help out MSFT by taking a steaming dump on the UI with the barely alpha quality KDE 4 release, The Gnome 3 mess, or yeah and Linus made sure to fiddle with the kernel just enough to cause serious driver issues, not to mention the Mickey Mouse Pulse audio which to this very day is usually the most crash prone part of any Linux build. Then you had the whole "What is gonna replace the shitty X Server" mess, Mozilla having to disable hardware acceleration in Linux (which frankly is still piss poor and a decade behind Windows), not to mention here it is 2015 and Linux STILL doesn't have a simple GUI for rolling back drivers or the system if an update takes a steamer on the system (something Windows has had for a decade and a half) and the driver situation is still such a mess hardware OEMs can't just put a penguin on the box and a Linux driver on a CD because hey, what works now may not work 6 months from now!
Sadly at the end of the day Linux is never gonna get any better, its just gonna get different. This is why Linux is getting its ass handed to it by "other" because at the end of the day the devs would rather crank out a new version with new bugs and new problems than fix what they have. Cranking out new software is a hell of a lot more enjoyable than bug fixing, regression testing, writing docs, hell this is the real reason why Linus won't allow Linux to have a stable driver ABI, something every. other. OS. has. because it might mean he couldn't just tweak and twiddle with the kernel like its still 1993 and Linux was only a hobbyist project!
Its a damned shame that FOSS advocates won't hold Linux to the same standards they hold MSFT and Apple, if they flat up refused to take the Mickey Mouse alpha quality shit you could probably whip Linux into an OS that would make Windows 10 look like Windows 3 and OSX look like System 7, all the parts are there, if the devs would actually work to make things better instead of crapping out new versions every other year.
ACs don't waste your time replying, your posts are never seen by me.
First, Systemd is neither unwanted nor dangerous, until and unless you can give me a specific example.
This thread is full of evidence of both. Don't be deliberately disingenuous, nobody likes a liar.
No one is putting Systemd into stable releases yet, its still going through the vetting phase.
Yes, that's why we are arguing against it now, to try to prevent it from becoming a part of "stable" releases. Because it isn't.
Third, are you running Upstart? That was a new technology once. It also had to be vetted, but You would be laughed out if you referred to Upstart as unwanted and dangerous
Not at all. Many felt that way about it, too. But the impact was not as widespread, so neither was the interest.
The dastardly way Pottering got all of these distros to switch to Systemd was to present it on its merits!
False. Systemd was used for some downstream projects (like GNOME) because at the time, the existing interfaces for doing certain things were in flux. Now they aren't, and the systemd dependency is coming out of GNOME.
Systemd is winning, and quickly, because
...embrace and extend. HTH, HAND.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Why can't scripts be launched parallelly? - why don't write some using Bash and see how it works.
It's really not hard to handle waiting on a dependency in shell scripting. In the case of init scripts, the obvious thing to do is to sleep loop until initscript status returns true, for a maximum number of cycles or period of time, where initscript is a dependency of your init script. This does require that your init scripts exit with proper status, but that does not seem like an arduous requirement. If you can't manage to reliably determine if a daemon is running in a shell script, then something is wrong either with the daemon or with your shell scripting abilities, or both. Give your init script another case or two, let it exec itself while it loops until deps are launched, then fork to launch in the background if that's called for in its /etc/default file.
If you want to simplify the init scripts, then just use systemd's unit files with a hashbang at the top, the processor is another script which uses the unit file to set variables and then does the normal things init scripts do based on those. Where systemd is playing the role of inetd, the processor script instead ensures that a proper line is created in the inetd.conf, or a proper file in inetd.conf.d.
Why haven't I done this yet, if it's so easy? 1, other hobbies at present. 2, who gives a shit? parallel boot knocks off a few seconds at best. The only part of the boot that needs parallelism is volume mounting. If I don't need a volume before I boot, then I would prefer that any checks on that volume proceed while I boot, in the background. Parallelism in starting daemons improves boot speed over preload (or just having an SSD) by a few seconds at best, and I could not give two shits about those seconds. If I'm starting a lightweight container, I don't want the overhead of something so complex as a full boatload of init scripts anyway. I'd rather have a totally BSD-style boot with just init to handle gettys and anything else I desperately need to boot, and everything else launched by a script. That script can launch scripts, so I can get as flexible as I like. I personally never had a problem with in-kernel udev, nor with the classic daemon, and I suspect mdev will do me just fine as well. The only thing I want that systemd has is early boot logging, but a) I want it to be ASCII and b) I don't want to have to replace my init daemon, and I shouldn't have to.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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)
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."
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
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
Let's be honest: Linus is known to have something of an ego.
My guess is: Linus is not speaking up because Linus does not the world to know how powerless he has become.
Red Hat is the 800 pound gorilla.
As for TFA? Sadly Pottering is another one that MSFT and Apple really should send a fruit basket to, because its him and the devs of his ilk that keep Linux in the backroom instead of the showroom and the reason why is simple...they will NEVER EVER let Linux become fucking stable! I swear these devs and their "itch scratching" are from bizarro world, they are like "Oh noes, things am stable and most stuff am working! This is no good, users am happy and can update without breakage! Quick lets change enough internals that many devices am broken and stability worse than Win2K, that will make users miserable!".
I mean for fucks sake you had MSFT being run by STEVE "Buzzword McBingo" BALMER and you STILL can't gain share, ever wonder why? Well you had the DE devs help out MSFT by taking a steaming dump on the UI with the barely alpha quality KDE 4 release, The Gnome 3 mess, or yeah and Linus made sure to fiddle with the kernel just enough to cause serious driver issues, not to mention the Mickey Mouse Pulse audio which to this very day is usually the most crash prone part of any Linux build. Then you had the whole "What is gonna replace the shitty X Server" mess, Mozilla having to disable hardware acceleration in Linux (which frankly is still piss poor and a decade behind Windows), not to mention here it is 2015 and Linux STILL doesn't have a simple GUI for rolling back drivers or the system if an update takes a steamer on the system (something Windows has had for a decade and a half) and the driver situation is still such a mess hardware OEMs can't just put a penguin on the box and a Linux driver on a CD because hey, what works now may not work 6 months from now!
Sadly at the end of the day Linux is never gonna get any better, its just gonna get different. This is why Linux is getting its ass handed to it by "other" because at the end of the day the devs would rather crank out a new version with new bugs and new problems than fix what they have. Cranking out new software is a hell of a lot more enjoyable than bug fixing, regression testing, writing docs, hell this is the real reason why Linus won't allow Linux to have a stable driver ABI, something every. other. OS. has. because it might mean he couldn't just tweak and twiddle with the kernel like its still 1993 and Linux was only a hobbyist project!
I think you have it backwards.
The stability you're arguing for is a feature for servers, an area where Linux traditionally does well.
To get the penetration into userland you want you need the new features, you need attempts to support buggy new hardware that was written to work under Windows and has weird behaviour in other places.
As for the topic at hand Systemd helps fix the problems you're talking about. Part of the bugginess is from different systems interacting and the amount of complexity those devs have to deal with. Systemd takes a chunk of that complexity away from those systems and moves it down one level. Even if the critics are right and this is a disaster for servers it should still improve stability in userland.
I stole this Sig
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. . . .
You think your job is to write scripts.
False. I think that my job encompasses being able to do that, and sometimes that's the best way to do my job. But in most cases, the user will simply install a package. You do know how this deduplication of effort thing works, right? In software? You can make unlimited copies? HTH.
The rest of us need a plumbing layer that isn't cobbled together by hand
What appendage would you prefer I type with?
Writing things in C is also part of the Unix philosophy -- but you don't know how to do that as well, do you?
Not well, which in turn is why I'm not expecting anyone to adopt an init system that I wrote in C.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
What does Linus Torvalds have to say about all this?
Linus Q&A at Debconf 2014
https://www.youtube.com/watch?...
starts at 18:43
"I think systemd does a lot of things right."
"Systemd gives a lot of features you couldn't get any other way. The boot-up speeds are real. And it's not saying you couldn't get the same things with non-systemd. But systemd stepped up and did it."
"I think the fight is mostly over."
"The lack of portability is sad. The thing I that I absolutely hate is that the bug reports have been basically ignored in some cases."
"I realize people expected me to hate systemd. I don't hate it, really. I think it is somewhat interesting and it has quirks, but what does not?"
Typical symptom of megalomania. Which he clearly suffers from. Well, the good thing about all this is that this has woken up a lot of people to the fact that free software needs to be defended against people that try a land-grab (and systemd is nothing else) and that constant vigilance is required.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Stop lying your ass off. There are a _lot_ of people that do not want it and have stated so. Your dishonesty is repulsive and disgusting.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
* 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.
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!
Thanks and fuck you too.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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!"
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.
Simply put, systemd DOES NOT hold up to POSIX scrutiny.
POSIX hasn't bothered to scrutinize it, as stuff such as the init system are outside the scope of POSIX. (SUSv3-compliant systems include a system using launchd, a system using SMS, and some systems that, as far as I know, still use System V-style traditional inits.)
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.
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.
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
You have plainly been around a while. Even longer than I in fact, at least on Slashdot.
I am slightly disconcerted with the unseemly personal attacks on the developer of a controversial new system component. I am slightly more concerned with the aggressive tone adopted by those who believe this component a step forward. The rather distasteful suggestion that those that hold a different opinion are simply disposable is not very attractive especially since many who are not convinced by systemd have many, many years of watching unix and unix like systems break.
I am on the fence personally, willing to be convinced but bear in mind I have many, many years of having my arse saved by following the trail the very transparent init gives us. I have many many years of experience of pain when required to follow less transparent approaches such as SMF.
Perhaps you have a convincing argument for me.
Regards
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.
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.
This thread is full of evidence of both. Don't be deliberately disingenuous, nobody likes a liar.
This thread is full of the following:
Systemd is bad because it is monolithic. (Systemd may be monolithic, or it might not, but that is completely irrelevant to its usefullness or fitness for use)
Systemd is bad because it replaces X (While Systemd does offer replacements for many other components, the alternatives can continue to be used as before)
Systemd is bad because it might break something (These comments piss me off because no one can give me *any* examples of anything that Systemd breaks, just a bunch of what ifs, and maybes )
In the end, I see a bunch of BS FUD, and nothing of substance from the anti-Systemd crowd. At the end of the day, I can easily see how init was broken, and pottering stepped up and made a solution. The rest of the people who are whining need to either a:) provide a solution of their own, b:) point to an alternate that works or c:) STFU. end of story. Nothing pisse me off more than people who are getting something for *FREE* and are whining that they are not getting what they want. That is the definition of balls my friend.
I wish I had a good sig, but all the good ones are copyrighted
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.
I don't think your comment is flamebait regardless of whatever groupthink the mods are engaged in today. Stallman may be worthy of respect but IMHO he is not a desirable poster-child for F(L)OSS for many of the reasons you outline; that should be obvious to most of us. However - and more germane to the discussion - I think your comments regarding Linux's lack of progress on the Desktop are insightful although it's a little uncomfortable to have it boiled down so succinctly. I guess I must be in some mild form of denial about the software and my passion for seeing its usage spread.
I love Linux and use it everywhere, everywhere. Everywhere except the desktop, that is. Whilst I'm very out of date and I'm quite sure that things have since improved, I've been thoroughly turned off by Linux employed in anything other than a server or infrastructure role.
I've tried to love Linux on the desktop over many years and so far the love has been unrequited. I've been through the usual suspects (Debian, Redhat, Ubuntu, CentOS and a couple of other distros from yesteryear) but have never managed to build a desktop environment that didn't piss me off or get in the way of doing useful work. Even with a nice OSS suite of Gimp, TB/FF, LibreOffice, etc., I experienced continual distractions from niggly little problems and found my general level of frustration to be higher than with Windows. Audio glitched out frequently. Updates broke stuff. Icons would disappear. Newly-installed software would commonly fail to create icons or shortcuts. Browser plugins would shit themselves regularly. There were of course days when everything was plain sailing but even then it felt a little precarious. I did spend a bit of money ensuring I had all my hardware right and in all honesty this did help, but not enough to change the feeling of general instability and the sensation of things being rough-around-the-edges. I'm no shrinking violet when it comes to the command line but even then I've had plenty of time sapped playing whack-a-mole with trivial annoyances.
Windows comes complete with its own Halls of Suck to traverse but MS have at least sorted out most of the stuff that really gets in the user's way. I honestly tried to move to Linux because I wanted to practice the FLOSS philosophy I preached, but Windows, to my chagrin, always re-emerged as the right tool for the job in my case. It should be mentioned for full disclosure that I managed to avoid Vista altogether, which goes a long way to explaining why my Windows experience has been reasonably good.
Maybe Linux is simply not suited to the mass-appeal desktop GUI market? I'd say with the phenomenal success of Android on various devices in production today, such a concession may not be such a hard one to make. It's no loss for FLOSS if there never is a Year of the Linux Desktop when we're squarely in an age of Linux on the Handheld.
..Mullah or Pope, Preacher or Poet, who was it wrote: "Give any one species too much rope and they'll fuck it up"?
... then we mock them.
Systemd is bad because it is monolithic. (Systemd may be monolithic, or it might not, but that is completely irrelevant to its usefullness or fitness for use)
No, no it isn't. The elements of the Unix philosophy are not there just because someone thought they sounded cool. They're there because they're good ideas. We don't like to just throw away the good ideas our favorite OS is based on.
Systemd is bad because it replaces X (While Systemd does offer replacements for many other components, the alternatives can continue to be used as before)
Sometimes they can, sometimes they can't, this has been addressed elsewhere in the thread so you should not be bringing it up here. That is just lazy of you.
Systemd is bad because it might break something (These comments piss me off because no one can give me *any* examples of anything that Systemd breaks, just a bunch of what ifs, and maybes )
There are several examples in this thread, and there have been several examples in prior threads, and there are several examples in various blog entries which you could find with google if you knew how to internet, bro.
In the end, I see a bunch of BS FUD, and nothing of substance from the anti-Systemd crowd.
Reading comprehension must not be your strong suit. It requires that you be willing to see information which contradicts your views.
Now, you might well want to turn that argument around on us, but the truth is that Unix got where it is by following these ideals. These ideals appeal to greybeards because they can see specifically where they saved them a whole lot of trouble.
Nothing pisse me off more than people who are getting something for *FREE* and are whining that they are not getting what they want. That is the definition of balls my friend.
No, balls is taking away someone's lunch and replacing it with a shit sandwich, then insisting that they should be grateful and furthermore, that they should love the taste and that it's the way of the future. But what it isn't is a good idea. At least, it's not a good idea to eat the sandwich.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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 I suspected grep printer -- * does work and I'm sure you know it. I'm not excusing the choice of names but that's a bit of a failure of Unix itself.
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.
Actually only getting labeled flamebait is an improvement, I turned down a chance recently to write a "devil's advocate" style column for a Linux magazine because I got tired of death threats and cyberstalking, so a little name calling? Not that big a deal.
What pisses me off is they act like I have some sort of axe to grind when the reality is the opposite...I WANT Linux to work on the desktop, I WANT to be able to hand my customers a shiny new desktop with a brand new Linux distro and be confident that it'll run with security updates for the life of the system...but I can't. Do you have ANY idea how many perfectly good systems I dumped because the cost of Windows would be more than the unit was worth? You name the distro I tried it, and it never failed, they ALWAYS shit all over themselves. I even spent a not inconsiderable amount of time coming up with "The Hairyfeet Challenge" so that there would be an easily reproducible way to show even the most zealot FOSS advocate the areas that were horribly broken.
At the end of the day Linux works great on the server and the reason why is simple, you strip out the most broken parts (like sound and wireless) and its administered by someone with a degree and/or years of diagnostic troubleshooting experience. And the reason it works on Android is simple, Google took control away from the "itch scratchers" and put in place actual standards. The sad part is there is no reason why Linux couldn't be a world class desktop PC OS, couldn't be loaded onto HTPCs and laptops in every B&M on the planet but sadly as long as the so called "advocates" take alpha quality code and attack those that point out the issues? Its just never gonna get any better, it'll start to get stable and then get knocked back down.
Meanwhile guys like me will have to junk perfectly working PCs that have years of life left because the cost of Windows is more than the PC is worth and that is just a damned shame.
ACs don't waste your time replying, your posts are never seen by me.
I think one of the biggest missed opportunities for Linux was not coming up with a suitable replacement for XP.
Those on XP (and still on XP) just want (and had) something that 'worked'. A suitable Linux distro, that 'looked' and 'felt' like XP, and was as stable as XP (SP3), but could run the latest 'application' software like XP (browser, email client, office package) could've gained traction. Something rock-solid, stable and safe. Unfortunately not to be.
(And I don't know why you were labelled 'flamebait' either.)
You never know what is enough unless you know what is more than enough. - Blake
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?
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.
Sometimes they can, sometimes they can't, this has been addressed elsewhere in the thread so you should not be bringing it up here.
I have read (and posted) this thread extensively, and There are no truthful examples of a portion of Systemd that cant be replaced except udev which has to be an integral part of the init system.
There are several examples in this thread, and there have been several examples in prior threads, and there are several examples in various blog entries which you could find with google if you knew how to internet, bro.
Every time I ask for examples, I get a response just like yours: "Look around, examples are everywhere!". They are not. Even in this thread, there are no examples whatsoever. The closest I have seen to examples are either lies, or half truths, like the statement I found indicating that Systemd replaces ntpd (it does not, but it does offer an alternative to ntpd, which is not required). I have only been able to conclude that people are opposed to Systemd for personal reasons which I can only guess at the reasons for. Those reasons seem to have no technical foundation, but mostly appear to stem from a long working understanding of xyz init system, and a healthy fear of the new and unknown.
My personal suspicion is that there are a lot of Sysadmins out there who have been working with sysvinit like systems for a very long time, and are comfortable with the various scripting languages involved, but with Systemd being written in C, it scares them to think they would have to understand C in order to debug their boot-up problems in the future. I can fully understand this particular bit of paranoia, but it is simply paranoia, nothing else.
No, balls is taking away someone's lunch and replacing it with a shit sandwich,
TANSTAAFL. Linux doesn't belong to you. You haven't paid for it, you didn't build it, so don't whine when it isn't what you want. Furthermore, no one is taking anything away from you. You are still free to continue using whatever distro you use today. It is yours as long as you like, but no one owes you free updates, in fact no one owes you a damn thing, so get over your self righteousness, because you haven't the right.
I wish I had a good sig, but all the good ones are copyrighted
I have read (and posted) this thread extensively, and There are no truthful examples of a portion of Systemd that cant be replaced except udev
..and dbus, and you have to have journald running whether you're using it or not. HTH, disingenuous douche.
Every time I ask for examples, I get a response just like yours: "Look around, examples are everywhere!".
That's because they are, and you are being a disingenuous douchebag.
My personal suspicion is that there are a lot of Sysadmins out there who have been working with sysvinit like systems for a very long time, and are comfortable with the various scripting languages involved, but with Systemd being written in C, it scares them to think they would have to understand C in order to debug their boot-up problems in the future. I can fully understand this particular bit of paranoia, but it is simply paranoia, nothing else.
Again, there are examples in this very thread (and in prior threads here) which show people coming to precisely this pass. So you're a disingenuous douchebag.
Linux doesn't belong to you. You haven't paid for it, you didn't build it, so don't whine when it isn't what you want.
In fact, I did help build it, in many ways. So you're being a disingenuous douchebag.
Fuck off, you disingenuous douchebag.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Its great you can do that, not everyone can code that well but i'd bet they'd have better success at configuring systemd to do that.
"a) I want it to be ASCII "
"b) I don't want to have to replace my init daemon, and I shouldn't have to."
They are both your choices. if your preferred distro uses systemd then you have vote with your feet and move to another distro. The distro have every right in the world to put out the system the way it sees fit and if you don't agree with it then you have to move or suck it up - thats life.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
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.
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.
Vista was practically a free gift to Linux, MSFT put out OSes that were truly dispised and what did the developers do? A perfect example of why Linux never goes anywhere, they said "Well things are pretty stable and solid, let's rip out the audio subsystem for a broken mess and replace the DEs with alpha quality code that will make Linux as buggy as Windows 98!"...facepalm.
Lets be honest here...the FOSS advocates claimed Elop was a "plant" well what is THEIR excuse? If you managed to get a plant at every major distro there is NOTHING they could have done to sabotage Linux any better than the actual developers did! Every single time MSFT puts out a major bomb like Vista or Windows 8? Some genius decides THAT is the perfect time to make a major dump on some vital system!
You should try the "Hairyfeet Challenge" sometime, as it perfectly illustrates why Linux is BROKEN, because it only asks that the distro perform half, just half, of a Windows lifecycle, can any distro do it? Nope in fact the only time I had a FOSS advocate claim they had "passed" the challenge they 1.- Had to use SciLinux, a distro designed for research labs and thus broke the very. first. condition of the challenge and then if that wasn't sad enough? When asked about the other conditions of the challenge he admitted that 2.- Sound didn't work, another fail, and 3.-His wireless not only took major CLI to get working but couldn't get WPA or even WEP to work!
That is why I'm really not surprised about the mods and insults, because even when faced with something as basic as "Get your OS to update without breaking itself" is shown to not be possible, do they say "Wow, that is just terrible! We should demand better, why Windows has been able to update itself without crapping on its own drivers since Win2K!" they instead call me every filthy name in the book, send me death threats, and having one FOSSie follow me for 6 months just so he could post at every site I use "die you fat fucker die". Seriously look at the challenge yourself, should we consider an OS to be suitable for purpose if it can't even pass such a simple test?
Take ANY mainstream consumer oriented (not LTS, because even Ubuntu advises against mainstream users using LTS) from FIVE years ago, this simulates a 5 year typical lifecycle. This BTW is less than HALF a windows support cycle, so I'm cutting linux a break. Lets say you use Ubuntu, that would be Ubuntu 9.10 and can be downloaded from their archive. Install it on ANY PC, desktop or laptop (NOT VM as that isn't real hardware and comes with special drivers) that has a wireless card. Wireless is required because more and more mainstream users are ditching wires and nobody wants a laptop that doesn't have wireless, do they?
During this phase you are the system builder so CLI (which is usually required because Linux driver support is poor) IS ALLOWED. Once its installed you are no longer the system builder but THE USER, so like a windows user you are ONLY allowed to use the GUI. You then get to "enjoy the freedom" of using nothing but the GUI (because if you can't even update the thing without CLI you're no match for windows are you) of updating to current...with ubuntu that is SEVEN RELEASES, just FYI. You will film this and post it to youtube, you only have to upload the final install process of each release and a pic of the device manager showing working hardware complete with wireless showing WPA V2 connection, but the complete video should be hosted on dropbox to prove you aren't faking it.
I've tried every major Linux distro, PCLOS, Ubuntu, even Fedora because one fanboy swore that Fedora could pass, yet here it is, 8 years since I first issued the challenge and not. a. single. distro. has had a 100% pass. Not one. And that is just sad.
ACs don't waste your time replying, your posts are never seen by me.
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
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.