- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
systemd 225 Adds 'su' Replacement, Saving of Private-Zone DHCP Options
systemd 225 is a small release that adds a replacement for the 'su' command in the form of a 'shell' verb for the machinectl command ('machinectl shell'), which has been engineered to open a fresh shell session on the target system as a new systemd unit. |
|
|
Comments (42)
22 earlier comments in the full thread.
Err when torvalds posted a rant on G+ about networkmanager requiring root password to change the wlan, people jumped to change that behavior virtually instantly...
750 wrote:Err when torvalds posted a rant on G+ about networkmanager requiring root password to change the wlan, people jumped to change that behavior virtually instantly...
If I remember correctly, this was specific to openSUSE, and maybe Ubuntu. It was the "Make available to other users" check box not being checked by default, which isn't the normal behavior.
Changing anything related to time still requires a password...
Likewise with adding a printer, still behind a password.
There is still a lot of "gothic" black in the GNOME theme.
You still can't change font sizes without GNOME Tweak Tool.
And those are just the recent things I've heard him complain about...
... more then 2 years ago.
I just stumbled across this, today...
(the internet has some funny detours, sometimes)
-
Busybox removes systemd support
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da97...
(the internet has some funny detours, sometimes)
-
Busybox removes systemd support
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da97...
The commit comment is priceless:
Quoting:remove systemd support
systemd people are not willing to play nice with the rest of the world. Therefore there is no reason for the rest of the world to cooperate with them.
Bravo!
If only more upstream developers would likewise stand up against these systemd clowns...
If only more upstream developers would likewise stand up against these systemd clowns...
The only one who can stop Poettering is his employer, REDHAT.
Nobody would be using Poettering 'creations' if REDHAT wasn't pushing systemd.
Systemd is a REDHAT project, not a personal project of Poettering, they just like to hide behind Poettering so it doesn't seem so obvious that REDHAT is pushing systemd to gain full control over the whole Linux ecosystem.
Systemd is REDHAT's trojan horse to shape and control the whole Linux ecosystem according to their own ideas.
GNU/Linux is turning into REDHAT/Linux.
Nobody would be using Poettering 'creations' if REDHAT wasn't pushing systemd.
Systemd is a REDHAT project, not a personal project of Poettering, they just like to hide behind Poettering so it doesn't seem so obvious that REDHAT is pushing systemd to gain full control over the whole Linux ecosystem.
Systemd is REDHAT's trojan horse to shape and control the whole Linux ecosystem according to their own ideas.
GNU/Linux is turning into REDHAT/Linux.
For a while now I've been seriously thinking that it might be time to create a non-business focused fork of the Linux ecosystem, aimed at hobbyists and home users. But not being a software person, that's way beyond anything I could manage. And it would almost certainly never be a money making proposition, so it would have to be a labor of love. Maybe Devuan will allow that to become possible. We'll see.
Red Hat could be looking to exert more influence in the Linux sphere. However, if they really are doing that, I think they've forgotten with whom they're dealing here. If the systemd issues ever get to the point where Red Hat can somehow leverage them to get other distributions, companies, or people to do something they don't want to do, then systemd can be dropped or forked faster than they might think. It's called Free Software for a reason.
CFWhitman wrote:If the systemd issues ever get to the point where Red Hat can somehow leverage them to get other distributions, companies, or people to do something they don't want to do...This scenario has already happened many times. The systemd folks have been getting developers to unnecessarily designate systemd as an external dependency. Many distros have caved since this practice started.
Here's Poettering pushing for Gnome's external dependency on systemd back in May of 2011.
Hopefully, more developers will renounce systemd before things get critical.
I think you're missing the degree of what I'm talking about. I'm well aware of distributions like Debian and Ubuntu changing or planning a change to systemd. However, right now it's just, 'Things are easier if we use systemd as the init.' It's not, 'We have no choice but to use systemd.' Also, there are distributions like Gentoo that have no plans to leave their default init behind to switch entirely to systemd.
If it were to ever get to the point where Red Hat basically tried to force these distributions to do things the systemd way against their will, they'd revolt. Busybox is one small and important project that's already gotten fed up with systemd. If they push it too far, other projects will follow.
My point is, for Free Software, there is no point of no return where you just have to accept someone else's terms, because the leverage just doesn't exist. If they wanted to, Debian could turn around and reject systemd before the next major release and go to something else altogether. It doesn't matter how deeply involved in systemd various projects get, there is always a way out. If you don't believe me, ask the folks at Xfree86.
If it were to ever get to the point where Red Hat basically tried to force these distributions to do things the systemd way against their will, they'd revolt. Busybox is one small and important project that's already gotten fed up with systemd. If they push it too far, other projects will follow.
My point is, for Free Software, there is no point of no return where you just have to accept someone else's terms, because the leverage just doesn't exist. If they wanted to, Debian could turn around and reject systemd before the next major release and go to something else altogether. It doesn't matter how deeply involved in systemd various projects get, there is always a way out. If you don't believe me, ask the folks at Xfree86.
@CFWhitman: theoretically you are right, distros can reject systemd and choose something else.
But in practice the cost in terms of man hours and know-how required to disentangle the fast growing systemd dependencies is already becoming so high that no smaller distro can afford to not use systemd and continue using SysV init or upstart.
The only distro that had enough man power to do that long term was Debian, but they caved in, so there is no hope left for others.
You need to consider that while there are countless Linux distros, most are either based on Debian or on Fedora. They do not have the manpower to create a distro from zero that's why they have to follow either Debian or Fedora.
Only Slackware and Gentoo are not directly dependent on the work of Debian and Fedora and therefore might still be able to avoid systemd for a while but even for them the cost is rising due to more and more applications becoming dependent on systemd.
But in practice the cost in terms of man hours and know-how required to disentangle the fast growing systemd dependencies is already becoming so high that no smaller distro can afford to not use systemd and continue using SysV init or upstart.
The only distro that had enough man power to do that long term was Debian, but they caved in, so there is no hope left for others.
You need to consider that while there are countless Linux distros, most are either based on Debian or on Fedora. They do not have the manpower to create a distro from zero that's why they have to follow either Debian or Fedora.
Only Slackware and Gentoo are not directly dependent on the work of Debian and Fedora and therefore might still be able to avoid systemd for a while but even for them the cost is rising due to more and more applications becoming dependent on systemd.
If it's not a legit tactic for Microsoft, perhaps it's a dubious practice for Red Hat, as well?
Just to throw some numbers in here.
Red Hat: US$ 1.534 billion in revenue for 2014.
Canonical: US$65.7 million for 2013 (latest wikipedia had)
Also, for the latest (4.3) kernel Red Hat was the biggest contributor besides Intel.
RH is massive in the Linux ecosystem, and so what they back is very likely to become the de-facto standard.
Red Hat: US$ 1.534 billion in revenue for 2014.
Canonical: US$65.7 million for 2013 (latest wikipedia had)
Also, for the latest (4.3) kernel Red Hat was the biggest contributor besides Intel.
RH is massive in the Linux ecosystem, and so what they back is very likely to become the de-facto standard.
> Only Slackware and Gentoo are not directly dependent on the work of Debian and Fedora and therefore might still be able to avoid systemd for a while but even for them the cost is rising due to more and more applications becoming dependent on systemd.
Yes. I'm hoping Slackware can hold out or Devuan will be successful, but we'll have to see what happens. Systemd is simply too Windows-like for my tastes.
Yes. I'm hoping Slackware can hold out or Devuan will be successful, but we'll have to see what happens. Systemd is simply too Windows-like for my tastes.
Again, the comments about Red Hat already having imposed their will on other distributions here are only talking about creating a system that a lot of people end up using because it was made the most convenient. There is a big gulf between doing that and trying to leverage it to force distributions to do what you want. As much as some people may feel that Red Hat forced Debian, Ubuntu, Arch, etc. to use systemd, they didn't really. Those projects decided to use it because they came to the conclusion that it was the better course to take.
As soon as Red Hat does something onerous with systemd that they are strongly against, it will be dropped if necessary. You only have so much leeway in the Free Software world. Imagine how quickly systemd would be dropped if they introduced a license clause that was unacceptable. I don't care how big Red Hat is, an unacceptable license clause would get systemd dropped or forked fast enough to make your head spin (I don't think Red Hat is stupid enough for that yet).
The thing that is really bad about systemd is that it makes it much more difficult to have alternative standards. That is, not that it would be so difficult for most distributions to drop systemd, but that it is much more difficult for there to be some distributions that use it and some that don't. Up till now, whatever init system you liked was easy enough to switch to from the most common, SysV init. Many have existed over the years, and distributions have used what they wanted. Systemd's dependency arrangement makes it so it's much more trouble to deviate from what is becoming the most popular init system. This is very similar to X-Window, where almost no distributions used anything but Xfree86. However, that still didn't stop Xfree86 from being dropped as soon as they did something that many distributions had an issue with.
In reality, Xfree86 had a much stronger position than systemd can ever have, since Xfree86 was used on other Unix and Unix-like operating systems while systemd cannot be, and yet they were replaced very quickly when they made the wrong move.
My guess is that eventually, systemd will either get its act together (Poettering's exit would likely be necessary), be replaced by a fork (this may be the most likely), or simply be replaced by one of the alternatives. This is not to say that they haven't or won't cause plenty of trouble in the meantime. However, I don't think systemd will give Red Hat significantly more control over the whole of Linux than they already have.
There is some chance that the outcome will be that eventually there is a more general split of Linux into systemd and non-systemd based operating systems, which is probably the worst case scenario.
It's also quite possible that the actions of Busybox are early indications of a general revolt which would culminate in one of the outcomes I already mentioned.
As soon as Red Hat does something onerous with systemd that they are strongly against, it will be dropped if necessary. You only have so much leeway in the Free Software world. Imagine how quickly systemd would be dropped if they introduced a license clause that was unacceptable. I don't care how big Red Hat is, an unacceptable license clause would get systemd dropped or forked fast enough to make your head spin (I don't think Red Hat is stupid enough for that yet).
The thing that is really bad about systemd is that it makes it much more difficult to have alternative standards. That is, not that it would be so difficult for most distributions to drop systemd, but that it is much more difficult for there to be some distributions that use it and some that don't. Up till now, whatever init system you liked was easy enough to switch to from the most common, SysV init. Many have existed over the years, and distributions have used what they wanted. Systemd's dependency arrangement makes it so it's much more trouble to deviate from what is becoming the most popular init system. This is very similar to X-Window, where almost no distributions used anything but Xfree86. However, that still didn't stop Xfree86 from being dropped as soon as they did something that many distributions had an issue with.
In reality, Xfree86 had a much stronger position than systemd can ever have, since Xfree86 was used on other Unix and Unix-like operating systems while systemd cannot be, and yet they were replaced very quickly when they made the wrong move.
My guess is that eventually, systemd will either get its act together (Poettering's exit would likely be necessary), be replaced by a fork (this may be the most likely), or simply be replaced by one of the alternatives. This is not to say that they haven't or won't cause plenty of trouble in the meantime. However, I don't think systemd will give Red Hat significantly more control over the whole of Linux than they already have.
There is some chance that the outcome will be that eventually there is a more general split of Linux into systemd and non-systemd based operating systems, which is probably the worst case scenario.
It's also quite possible that the actions of Busybox are early indications of a general revolt which would culminate in one of the outcomes I already mentioned.
+100
That is sensible & the voice of reason.
Open source corporation or not, Red Hat is doing what corporations will always try to do. Control
As long as SystemD is covered by a GPL, there shouldn't be a major concern. The minute it doesn't, it should be, and will be forked.
Linus would be concerned only when SystemD developers start dictating how things should be done in the Linux kernel.
All good things will end when something better comes along.
That is sensible & the voice of reason.
Open source corporation or not, Red Hat is doing what corporations will always try to do. Control
As long as SystemD is covered by a GPL, there shouldn't be a major concern. The minute it doesn't, it should be, and will be forked.
Linus would be concerned only when SystemD developers start dictating how things should be done in the Linux kernel.
All good things will end when something better comes along.
> There is some chance that the outcome will be that eventually there is a more general split of Linux into systemd and non-systemd based operating systems, which is probably the worst case scenario.
I'm not certain that would be the worst case scenario. The forced marriage of home/hobbyist and enterprise users in Linux is not necessarily a good thing. Distributions aimed at the home/hobbyist market that strip out enterprise oriented features such as systemd might be better.
I'm not certain that would be the worst case scenario. The forced marriage of home/hobbyist and enterprise users in Linux is not necessarily a good thing. Distributions aimed at the home/hobbyist market that strip out enterprise oriented features such as systemd might be better.
CFWhitman wrote:It's also quite possible also that the actions of Busybox are early indications of a general revolt which would culminate in one of the outcomes I already mentioned.It could go the other way, perhaps. I'm not up to play on how initrd works with distributions using systemd but it might lead to Busybox being replaced for that purpose.
In my experience systemd has proven itself for resource management on headless and larger 'embedded' setups. Busybox could potentially be forked or surpassed in favour of systemd.
Busybox's choice is irrelevant in this discussion as they are not a full fat general purpose distro but rather a tiny minimalistic distro with a very narrow focus, so for them doing without systemd is far easier than for a normal distro.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
I actually think it's quite evident that Torvalds hardly has any influence outside of the kernel, simply because whenever he says anything negative about any component of userland software, no one listens to him.
It's why despite Torvalds encouraging people to first "[print] out a copy of the GNU Coding Standards, and NOT read it. Burn them" as a "great symbolic gesture" before reading the Linux Kernel Coding Style, the GNU Coding Standards are still used (possibly even primarily for software in C).
It's also why despite his numerous complaints about GNOME 3 (the top bar is black? OMG!), they never fixed anything he had a problem with.
I can understand this viewpoint if you aren't using SystemD.
However, if you are using SystemD, even if you don't want to, you should have a problem with this. Even if the new "su" replacement is something we aren't forced to use, or worse yet, people simply never use it and continue to prefer "su", that still means more code was added for something that wasn't necessary for SystemD to include. Meaning SystemD gets bigger, more bloaty, and possibly slower.
All because Poettering didn't think the 30+ year tried-and-true "su" was good enough, and didn't even think to make "su" do what he needs (perceives to need) before duplicating the functionality in SystemD.
As you say, options for distributions that don't use SystemD are becoming severely limited. That's why those concerned should be the ones either telling Poettering to stop it, or going to the developers of these projects and asking or helping them to fix the issues to prevent SystemD from absorbing them.
I just want to point out, Linus has nothing to do with it. That's why he isn't interested and doesn't understand the hate SystemD gets.