That's what Poettering has been doing his whole life, getting into good open source projects, squatting and then shitting all over them. The infection, stink and filth then linger for decades. He's a cancer on open source.
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
Yeah, that's true. He sees features people want, and he builds them. For example, Debian distro builders were frustrated writing init scripts, so Poettering made something that filled the need of those distro builders [slashdot.org]. That's why it got adopted, because it contained features they wanted.
Do we have any *good* systemd alternative projects--that attempt to fix these problem features but do so with *good* unix-way architecture?
Good question. To reiterate the problem, it's that init scripts are a pain to write, and the systemd unit files makes it easy.
Of course, there are plenty of systems that are happy to not use systemd. The core of the question then is, why do systems like OpenBSD, FreeBSD, and Slackware not have any problems with init scripts? Their systems work well, AFAIK. When I get time, I'd like to do a comparative analysis of these different systems, to figure out why Debian had so much trouble with init, but the oth
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Because Poettering doesn't understand "modular", I don't get just the good stuff - it's all or nothing. And because systemd isn't even modular as an overgrown bloated monstrosity, the only way to avoid it is to either run old distros or some other
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Yeah, that's basically the problem. Systemd is really three different things:
1) init system
2) cgroups manager (cgroups architecture is still crap, btw)
3) session manager
It probably does more stuff, but it's hard to keep track of it all
[...] the only way to avoid it [systemd] is to either run old distros or
some other OS entirely.
A third option is to use a newer distro that does not use systemd. I
run a Gentoo system that does not use systemd. You can also get
up-to-date Debian based distros such as antiX Linux [distrowatch.com] which don't use systemd. I imagine
these are not the only options.
A third option is to use a newer distro that does not use systemd. I run a Gentoo system that does not use systemd. You can also get up-to-date Debian based distros such as [ Debian ] which don't [ have to ] use systemd.
I still don't know what Devuan and friends are supposed to be for.
As an aside launchd is open source. The FreeBSD people were able easily to move it over.
Now onto your question:
OpenBSD, FreeBSD, and Slackware not have any problems with init scripts?
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them. They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them.
That's an interesting thought.......have you ever supported Oracle Financials or similar? Do you have experiences you can share?
They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
Not sure about this one......I worked with Linux-HA before systemd, and I of all the problems, I don't recall init scripts being one of them.
.I worked with Linux-HA before systemd, and I of all the problems, I don't recall init scripts being one of them.
The problem isn't init scripts it is what to do with chains of dependencies on high availability. If you worked in Linux-HA think about the application specific restart code that each application had to do and how fragile it all was.
That's an interesting thought.......have you ever supported Oracle Financials or similar? Do you have experiences you can share?
The problem isn't init scripts it is what to do with chains of dependencies on high availability. If you worked in Linux-HA think about the application specific restart code that each application had to do and how fragile it all was.
Yes, we were constantly thinking of restarting things, but systemd wouldn't help with the majority of that. The applications themselves need to be written with restart in mind, and that's where the difficulty really comes in. (actually we spent most of our time trying to create a novel system for nodes to discover each other, but that isn't related)
They all want an much richer environment of management tools. In real life I've never met anyone who thinks systemd is too thick, they all argue it is too thin.
It sounds like they are looking at things from a feature perspective, not an architecture perspective. Those are cool features, but architecturally, continuous t
There are a number of articles I read on this that I don't feel like ducking right now, but basically there were many attempts and none of them gained the traction needed. The big thing that needed fixing was full process control. You can do that without all the other crap that comes with systemd. Maybe a combined init+inetd...okay I can get that. Maybe auto-launching apps with sockets...but no wait...dbus already does that. Oh lets just integrate everything with dbus.... You know...up until this point, th
is harder to parse then this (correct because you also managed to mispell the command invocation): systemctl stop servicename
The problem with people who hate systemd is that all of them only manage to come up with, at best, utterly petty complaints like this and "binary logs" (guess my syslog-ng configuration doesn't exist).
The people who like systemd tend to like the features.......the people who dislike it, the architecture
phantomfire;
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
If I had to place a bet on the fate of architectural perfection vs. responsiveness to users, I'd have to go with the users.
The problem of course is that he doesn't understand the Unix way [catb.org], especially when it comes to good interfaces between code [slashdot.org] (IMNSHO).
I have no doubt he understands it. I understand the Nazis too, I understand the motivation of terrorists. That doesn't mean I need to approve of either of them.
I'll be modded into oblivion for this but I think while the Unix way got it where it was today, it is the Unix way that is preventing it from going further. The entire world seems to be shifting gears right now. It used to be that we were searching for ways to maximise how useful computers could be, how customisable, how we could string together and
The Unix way is more than "stringing together commands." It's a way to build good systems. If you don't have good interfaces, your system will be bad.
And systemd is not simple at all.
The Unix way is more than "stringing together commands." It's a way to build good systems.
And yet some of the most successful systems are not built that way. Considering it the only way is absurd. It's a way that suits one particular line of thinking. Incidental it's also a way that is fundamentally incompatible with the notion that computers should magically work in any scenario without complicated user intervention.
Systemd is a shitload simpler than the kernel itself, and providing it's interfaces are well documented (debatable at this point) there's no reason it can't be the foundation of a "
And yet some of the most successful systems are not built that way.
Built what way? I think you misunderstood what I said, so I'll say it again more clearly:
The Unix way is a way to build good systems. You can skip "stringing together commands" and still follow the Unix way.
And yet some of the most successful systems are not built that way.
Built what way? I think you misunderstood what I said, so I'll say it again more clearly: The Unix way is a way to build good systems. You can skip "stringing together commands" and still follow the Unix way.
I wasn't talking about stringing together commands. I was referring to the all encompassing "Unix Way"
Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing? Why restrict software to input and output inefficient plain text strings? Why start new when something can be expanded on the old?
These are philosophies not followed by Windows, OSX, iOS, Android, or
Your post makes me think you still don't understand the Unix Way. If you're not going to investigate, at least look through the list of rules here [catb.org], and that will give you something of an idea.
Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing?
These are philosophies not followed by Windows, OSX, iOS, Android, or even some great Unix protocols such as Xwindows. Yet the above are all examples of good systems.
it is the Unix way that is preventing it from going further
So you are saying any violation of the Unix philosophy will make it "go further"? Probably not, but if yes, I give up on you.
If no, are you saying linux kernel, or other "good" non-systemd things never violate the unix philosophy? If so, you are wrong. ZFS, and Btrfs violate the Unix philosophy quite spectacularly by merging filesystem, LVM, checksum etc. into one monolithic piece. Linus himself was against this initially (especially in the context of encryption), but he has come to terms with reality. Look
Upstart: couldn't keep up. Systemd came out of solutions to some of the problems with upstrart. There was no good reason in theory upstart couldn't have won, it just didn't.
Launchd is tied to BSD initialization. But... there was an attempt to port its features over to Linux. That was called systemd.
What you might really like is OpenRC which is a "better init for Linux" and doesn't aim to be more than just init version 2. But it is mostly defunct now.
"The problem of course is that he doesn't understand the Unix way [catb.org]," i don't get this complaint at all especially when there ares such things as the Linux Kernel are not complained about in the same way. Virtually every troll is really a personal attack on LP using the vehicles of PA or Systemd. I have yet to see anyone in these forums dissecting the code of these projects. All trolls posts on this particular subject are based on the assumption "su" has been deprecated so it just shows you how l
BSD is looking better all the time (Score:0)
LOL still fighting to his day with Pulse Audio on XFCE on Fedora 22.
Jeez has it come down to me having to write a functional volume/mixer applet for myself?
Re: (Score:2, Insightful)
That's what Poettering has been doing his whole life, getting into good open source projects, squatting and then shitting all over them. The infection, stink and filth then linger for decades. He's a cancer on open source.
Re: (Score:-1)
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
That he uses giant bloated abstraction layers to do it, is a bit questionable of course. :)
Linux already runs slower than Windows because of this overengineered junkpile.
Re:BSD is looking better all the time (Score:5, Insightful)
That's a bit rude... I think Poettering's main motivation has been to simply modernize Linux.
Yeah, that's true. He sees features people want, and he builds them. For example, Debian distro builders were frustrated writing init scripts, so Poettering made something that filled the need of those distro builders [slashdot.org]. That's why it got adopted, because it contained features they wanted.
The problem of course is that he doesn't understand the Unix way [catb.org], especially when it comes to good interfaces between code [slashdot.org] (IMNSHO).
The people who like systemd tend to like the features.......the people who dislike it, the architecture.
Re: (Score:1)
Do we have any *good* systemd alternative projects--that attempt to fix these problem features but do so with *good* unix-way architecture?
Re: (Score:2)
Do we have any *good* systemd alternative projects--that attempt to fix these problem features but do so with *good* unix-way architecture?
Good question. To reiterate the problem, it's that init scripts are a pain to write, and the systemd unit files makes it easy.
Of course, there are plenty of systems that are happy to not use systemd. The core of the question then is, why do systems like OpenBSD, FreeBSD, and Slackware not have any problems with init scripts? Their systems work well, AFAIK. When I get time, I'd like to do a comparative analysis of these different systems, to figure out why Debian had so much trouble with init, but the oth
Re: (Score:2)
Wouldn't it be easier to develop a new "init language" which translates to the current init scripts?
I'm not sure what that means. Systemd can run the old init scripts, but also gives the option of writing new unit files.
Re: (Score:3)
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Because Poettering doesn't understand "modular", I don't get just the good stuff - it's all or nothing. And because systemd isn't even modular as an overgrown bloated monstrosity, the only way to avoid it is to either run old distros or some other
Re:BSD is looking better all the time (Score:4, Insightful)
I had trouble with init scripts. The systemd init subsystem was a better approach. The problem was, systemd also brought in a lot of stuff that wasn't directly part of the init subsystem that I didn't want, don't want, and don't see any probability of ever wanting.
Yeah, that's basically the problem. Systemd is really three different things:
1) init system
2) cgroups manager (cgroups architecture is still crap, btw)
3) session manager
It probably does more stuff, but it's hard to keep track of it all
Re: (Score:2)
4) log mutilator
5) dbus abuser - so I'm told. Fortunately, I haven't had need to get involved at that level. Yet.
It probably does more stuff, but it's hard to keep track of it all
Re: (Score:2)
5) dbus abuser - so I'm told.
I don't know what you mean by 'abuser,' but they're trying to get dbus integrated into the kernel.
antiX Linux is a systemd-free Debian derivative (Score:2)
[...] the only way to avoid it [systemd] is to either run old distros or some other OS entirely.
A third option is to use a newer distro that does not use systemd. I run a Gentoo system that does not use systemd. You can also get up-to-date Debian based distros such as antiX Linux [distrowatch.com] which don't use systemd. I imagine these are not the only options.
Re: (Score:1)
A third option is to use a newer distro that does not use systemd. I run a Gentoo system that does not use systemd. You can also get up-to-date Debian based distros such as [ Debian ] which don't [ have to ] use systemd.
I still don't know what Devuan and friends are supposed to be for.
Re: (Score:2)
As an aside launchd is open source. The FreeBSD people were able easily to move it over.
Now onto your question:
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them. They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
Re: (Score:2)
Those 3 don't support complex tiers of applications that need to work together. They aren't aiming to have say something like Oracle Financials running on them.
That's an interesting thought.......have you ever supported Oracle Financials or similar? Do you have experiences you can share?
They aren't used in large configurations involving hundreds (or many thousands or more) CPUs.
Not sure about this one......I worked with Linux-HA before systemd, and I of all the problems, I don't recall init scripts being one of them.
Re: (Score:2)
The problem isn't init scripts it is what to do with chains of dependencies on high availability. If you worked in Linux-HA think about the application specific restart code that each application had to do and how fragile it all was.
I help people migrate to cloud.
Re: (Score:2)
The problem isn't init scripts it is what to do with chains of dependencies on high availability. If you worked in Linux-HA think about the application specific restart code that each application had to do and how fragile it all was.
Yes, we were constantly thinking of restarting things, but systemd wouldn't help with the majority of that. The applications themselves need to be written with restart in mind, and that's where the difficulty really comes in. (actually we spent most of our time trying to create a novel system for nodes to discover each other, but that isn't related)
They all want an much richer environment of management tools. In real life I've never met anyone who thinks systemd is too thick, they all argue it is too thin.
It sounds like they are looking at things from a feature perspective, not an architecture perspective. Those are cool features, but architecturally, continuous t
Re: (Score:2)
There are a number of articles I read on this that I don't feel like ducking right now, but basically there were many attempts and none of them gained the traction needed. The big thing that needed fixing was full process control. You can do that without all the other crap that comes with systemd. Maybe a combined init+inetd...okay I can get that. Maybe auto-launching apps with sockets...but no wait...dbus already does that. Oh lets just integrate everything with dbus. ... You know...up until this point, th
Re: (Score:2)
Seriously?
You're saying this: /etc/init.d/servicename stop
is harder to parse then this (correct because you also managed to mispell the command invocation):
systemctl stop servicename
The problem with people who hate systemd is that all of them only manage to come up with, at best, utterly petty complaints like this and "binary logs" (guess my syslog-ng configuration doesn't exist).
Re: (Score:1)
Not to mention that
is horrible but
is horrible and doesn't work (gets the environment wrong).
Re:BSD is looking better all the time (Score:5, Informative)
OpenRC++
openrc init scripts are fairly straight forward.
Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.
Re: (Score:2)
OpenRC++
openrc init scripts are fairly straight forward.
Coupled with gentoo's baselayout, and the config file layout is fairly normalized also.
Yep a system brought to you by the people who brought you:
#464385 +(4150)- [X] /dev/hda && mkfs.xfs /dev/hda1 && mount /dev/hda1 /mnt/gentoo/ && chroot /mnt/gentoo/ && env-update && . /etc/profile && emerge sync && cd /usr/portage && scripts/bootsrap.sh && emerge system && emerge vim && vi /etc/fstab && emerge gentoo-dev-sources && cd /usr/src/linux && make menuconfig && make install modules_install && emerge gnome mozilla-firefox openoffice && emerge grub && cp /boot/grub/grub.conf.sample /boot/grub/grub.conf && vi /boot/grub/grub.conf && grub && init 6
[@insomnia] it only takes three commands to install Gentoo
[@insomnia] cfdisk
[@insomnia] that's the first one
Re: (Score:2)
The people who like systemd tend to like the features.......the people who dislike it, the architecture
phantomfire;
6) The user asked for a feature request to be added to machinectl, that would retain that environment variable
7) Lennart said, "sure, no problem." (Which shows why systemd is gaining usage, when people want a feature, he adds it)
If I had to place a bet on the fate of architectural perfection vs. responsiveness to users, I'd have to go with the users.
Re: (Score:2)
The only question is, with a lousy architecture, will they continue to be able to deliver?
Re: (Score:2)
The problem of course is that he doesn't understand the Unix way [catb.org], especially when it comes to good interfaces between code [slashdot.org] (IMNSHO).
I have no doubt he understands it. I understand the Nazis too, I understand the motivation of terrorists. That doesn't mean I need to approve of either of them.
I'll be modded into oblivion for this but I think while the Unix way got it where it was today, it is the Unix way that is preventing it from going further. The entire world seems to be shifting gears right now. It used to be that we were searching for ways to maximise how useful computers could be, how customisable, how we could string together and
Re: (Score:2)
And systemd is not simple at all.
Re: (Score:3)
Yes and init scripts are just a bastion of race-free stateful design, and service monitoring. Except not at all those things.
Re: (Score:2)
The Unix way is more than "stringing together commands." It's a way to build good systems.
And yet some of the most successful systems are not built that way. Considering it the only way is absurd. It's a way that suits one particular line of thinking. Incidental it's also a way that is fundamentally incompatible with the notion that computers should magically work in any scenario without complicated user intervention.
Systemd is a shitload simpler than the kernel itself, and providing it's interfaces are well documented (debatable at this point) there's no reason it can't be the foundation of a "
Re: (Score:2)
And yet some of the most successful systems are not built that way.
Built what way? I think you misunderstood what I said, so I'll say it again more clearly:
The Unix way is a way to build good systems. You can skip "stringing together commands" and still follow the Unix way.
Re: (Score:2)
And yet some of the most successful systems are not built that way.
Built what way? I think you misunderstood what I said, so I'll say it again more clearly:
The Unix way is a way to build good systems. You can skip "stringing together commands" and still follow the Unix way.
I wasn't talking about stringing together commands. I was referring to the all encompassing "Unix Way"
Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing? Why restrict software to input and output inefficient plain text strings? Why start new when something can be expanded on the old?
These are philosophies not followed by Windows, OSX, iOS, Android, or
Re: (Score:2)
Heck some of the most successful elements of Unix don't follow the "Unix Way" such as "do one thing and do it well". I couldn't disagree with this more. Why should a program restrict itself to doing one thing?
Yeah.....you definitely don't understand the Unix Way. That concern is addressed here [catb.org]. Read it.
These are philosophies not followed by Windows, OSX, iOS, Android, or even some great Unix protocols such as Xwindows. Yet the above are all examples of good systems.
Uh.....are you measuring 'good' by popularity?
Re: (Score:2)
it is the Unix way that is preventing it from going further
So you are saying any violation of the Unix philosophy will make it "go further"? Probably not, but if yes, I give up on you.
If no, are you saying linux kernel, or other "good" non-systemd things never violate the unix philosophy? If so, you are wrong. ZFS, and Btrfs violate the Unix philosophy quite spectacularly by merging filesystem, LVM, checksum etc. into one monolithic piece. Linus himself was against this initially (especially in the context of encryption), but he has come to terms with reality. Look
Re: (Score:2)
But why SystemD and not something like Upstart or Launchd?
Re: (Score:2)
Re: (Score:2)
Upstart: couldn't keep up. Systemd came out of solutions to some of the problems with upstrart. There was no good reason in theory upstart couldn't have won, it just didn't.
Launchd is tied to BSD initialization. But... there was an attempt to port its features over to Linux. That was called systemd.
What you might really like is OpenRC which is a "better init for Linux" and doesn't aim to be more than just init version 2. But it is mostly defunct now.
Re: (Score:2)
All trolls posts on this particular subject are based on the assumption "su" has been deprecated so it just shows you how l
Re: (Score:2)
I have yet to see anyone in these forums dissecting the code of these projects.
I'm working on it.