- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Is systemd as bad as boycott systemd is trying to make it?
|
|
|
Comments (45)
25 earlier comments in the full thread.
devnet wrote:So you have something other than x86,x86_64 or ARM eh?Have used: PowerPC
Probably will use at some point: MIPS
Always a possibility: Power, Itanium, who knows what else?
Regardless of what I may use in the future, one of the strengths of Linux has always been its ability to go right on to any new architecture that becomes available. I'd hate to see that change because some Red Hat developer decided that portability wasn't important, and, 'Who cares about anything that's not mainstream?' The 'Who cares about anything that's not mainstream?' attitude is rather ironic for a Linux developer, considering the origins of the kernel/operating system.
Quoting:Architecture aside...attitude of developers isn't something I base my choices on. I don't go out and look at a program that I install on my desktop and say "hrm...what is the attitude of the developers who made this program?". Honestly, I don't care and don't have time to care.Well, it's certainly affected me many times in the past (like many others I have used Microsoft software). However, the dismissive nature of your comment readily illustrates the dismissive attitude of the developers.
the portability problem of systemd is not about architectures. systemd will run on any architecture that linux runs on. the problem is rather that systemd is not portable to other kernels like *bsd, because it depends on linux specific kernel-apis.
this is for example a problem for debian which also supports the freebsd kernel. and because of this debian will have to support sysvinit for the forseeable future.
greetings, eMBee.
this is for example a problem for debian which also supports the freebsd kernel. and because of this debian will have to support sysvinit for the forseeable future.
greetings, eMBee.
Everyone here needs to go and read about what systemd actually does, what it does for small distro developers such as myself, and mythbust a few things because it is obvious that you think you know and you don't just by the comments here.
What I mean is...you're moaning about architectures that won't adopt systemd anyway because they're primarily for embedded distributions. You're ignoring any production gains, performance gains, etc. and just saying "oh, it removed the choice from me" when it CLEARLY doesn't...because it will support all of your init scripts should you choose to use them. You also state that users are abondoning it by the truckload when I know of 4 major distributions that have switched or are switching INCLUDING debian.
I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
What I mean is...you're moaning about architectures that won't adopt systemd anyway because they're primarily for embedded distributions. You're ignoring any production gains, performance gains, etc. and just saying "oh, it removed the choice from me" when it CLEARLY doesn't...because it will support all of your init scripts should you choose to use them. You also state that users are abondoning it by the truckload when I know of 4 major distributions that have switched or are switching INCLUDING debian.
I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
> You're ignoring any production gains, performance gains, etc....
No, I'm not. I'm saying they're not worth the cost to me.
> ... because it will support all of your init scripts should you choose to use them.
And, again, if I'm going to keep my current init scripts, why exactly am I running systemd?
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
Strange, my system primary system still doesn't use pulse audio. My laptop does. I haven't noticed any significant difference in audio quality between them.
No, I'm not. I'm saying they're not worth the cost to me.
> ... because it will support all of your init scripts should you choose to use them.
And, again, if I'm going to keep my current init scripts, why exactly am I running systemd?
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
Strange, my system primary system still doesn't use pulse audio. My laptop does. I haven't noticed any significant difference in audio quality between them.
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
This is totally inaccurate. Only last month I run into a computer with pulseaudio running as a pure white noise generator. I've replaced it with ALSA and it worked fine. If you do a search on the web you'll find plenty of people complaining about pulseaudio problems. These problems are casually dismissed by the developer, unless you have a RedHat support contract. This is why quite a number of distros are quietly dropping pulseaudio - Lubuntu for example.
Systemd is a new technology brought to you by the same people who built pulseaudio. At some point it will start getting dropped by some of the distros that implemented it. My plan is to wait 2 or 3 more years until RedHat customers report all the problems. We'll see how it goes.
This is totally inaccurate. Only last month I run into a computer with pulseaudio running as a pure white noise generator. I've replaced it with ALSA and it worked fine. If you do a search on the web you'll find plenty of people complaining about pulseaudio problems. These problems are casually dismissed by the developer, unless you have a RedHat support contract. This is why quite a number of distros are quietly dropping pulseaudio - Lubuntu for example.
Systemd is a new technology brought to you by the same people who built pulseaudio. At some point it will start getting dropped by some of the distros that implemented it. My plan is to wait 2 or 3 more years until RedHat customers report all the problems. We'll see how it goes.
Some people just can't handle change and refuse to adapt to it. If history taught us something it is the fact that Change is inevitable. we complain, yell and scream all we want, but for some reason or another, for good or for worse, change is going to happen and people eventually will learn to live with it.
Today's FOSS is no longer what RMS wanted it to be and it might not be what Torvald wanted it in the future. Many FOSS developers are moving on and new ones are coming in. Nothing is going to stay the same.
Today's FOSS is no longer what RMS wanted it to be and it might not be what Torvald wanted it in the future. Many FOSS developers are moving on and new ones are coming in. Nothing is going to stay the same.
> I remember when people were all up in arms about pulseaudio as well....now people look back on it like it was a pure genius move. I think people will do the same with systemd.
PulseAudio has made my USB headset useless. It is no longer recognized when it's plugged in, so I have no way of using any telephony applications on my system.
Please don't tell me how "happy" I should be about Pulse Audio, when stuff is broken that had been working for a DECADE prior to it.
PulseAudio has made my USB headset useless. It is no longer recognized when it's plugged in, so I have no way of using any telephony applications on my system.
Please don't tell me how "happy" I should be about Pulse Audio, when stuff is broken that had been working for a DECADE prior to it.
> Some people just can't handle change and refuse to adapt to it.
Yeah, that's obviously why I had so much trouble switching from Windows to Linux on my home machine back in the 90's: I just can't handle change and refuse to adapt.
Yeah, that's obviously why I had so much trouble switching from Windows to Linux on my home machine back in the 90's: I just can't handle change and refuse to adapt.
@Fettoosh
That's what I like about systemd proponents: they always come up with so many meaningful arguments like "you can't handle change" and "getting s**t" done. It so much enriches the whole discussion. Furthermore, simply ignoring idiotic slogans like "it's a bad architecture", "too many dependencies", "what does it solve" and "why are there so many CVE's and other bugs that are just closed - because it is not a problem" exactly the way you should handle these fossils. It really enhances the trust in the development team and the final product.
I'm sorry Fettoosh - what was my first objection again? Perhaps you'd care to re-read my post...
R.E. Pulse Audio, I run Alsa on my home desktop computer. I never could get Pulse to work and I finally surrendered. Unquestionably, Pulse is intended to solve many problems in Alsa, and it probably does that for many people, but it doesn't work at all for me.
R.E. Pulse Audio, I run Alsa on my home desktop computer. I never could get Pulse to work and I finally surrendered. Unquestionably, Pulse is intended to solve many problems in Alsa, and it probably does that for many people, but it doesn't work at all for me.
Quoting:Pulse is intended to solve many problems in Alsa, and it probably does that for many people, but it doesn't work at all for me.
emphasis is mine
that is the problem that some have, they don't see the good that change brings to many others. I can understand that, but we should look at the over benefits and not only the problems it brings to specific individuals. If systemd is being adopted by major distributions and eventually by their branches & re-spins, there must be beneficial things in it that either not being recognized or being ignored. And if systemd doesn't bring the benefits or fails at accomplishing its objectives, software evolution will take care of replacing it.
> ...they don't see the good that change brings to many others...
If my standard in OS'es were "good ... to ... others" or "overall benefits", I'd be using Windows.
If my standard in OS'es were "good ... to ... others" or "overall benefits", I'd be using Windows.
You know, some might have gotten the impression that I am absolutely against systemd. This is not the case. The jury is still out for me. As long as portability to different architectures is feasible (and it really seems like it ought to be, at least once the growing pains are over) I might find that its advantages outweigh its disadvantages.
However, though it may be fine, even good, for systemd to take advantage of Linux specific features as an init system, the bigger it gets, and the more beyond init it goes, the more concerned I become about portability of all its different parts to other Unix and Unix-like operating systems. The more other software that becomes dependent on it, the more portability becomes a concern.
If the developers of systemd and other projects that deal with systemd can find a way to make sure that as few pieces of software are dependent on the whole system as possible (or practical), then that software can be more widely used among all Unix like systems.
I just want the strength of Linux and Unix in general, interchangeable pieces, to continue to be respected. I would also like to see a less dismissive attitude by the developers. At least the "Myths" page tries more to address concerns rather than just dismissing them.
It's funny, but I actually think PulseAudio may have more problems than systemd in some ways. However, I can always rip out PulseAudio and replace it with Jack (or something else) when I need something different than it provides. My major concern is that this remains true with systemd as well.
I don't think the sky is falling. The reason I don't think that is because I think that if an impasse would be reached, we'd just see an alternate init, either new or existing, start to be implemented more widely. I'd rather it didn't reach an impasse, though. I'd rather not see any more of things like a certain desktop can't be run on a certain system because it doesn't have systemd. That seems too far for dependencies on an init system to reach. There are enough concerns of that sort about Wayland, which is more directly connected to the user interface, and thus can't help but have a more direct effect on the user.
Read the whole commentHowever, though it may be fine, even good, for systemd to take advantage of Linux specific features as an init system, the bigger it gets, and the more beyond init it goes, the more concerned I become about portability of all its different parts to other Unix and Unix-like operating systems. The more other software that becomes dependent on it, the more portability becomes a concern.
If the developers of systemd and other projects that deal with systemd can find a way to make sure that as few pieces of software are dependent on the whole system as possible (or practical), then that software can be more widely used among all Unix like systems.
I just want the strength of Linux and Unix in general, interchangeable pieces, to continue to be respected. I would also like to see a less dismissive attitude by the developers. At least the "Myths" page tries more to address concerns rather than just dismissing them.
It's funny, but I actually think PulseAudio may have more problems than systemd in some ways. However, I can always rip out PulseAudio and replace it with Jack (or something else) when I need something different than it provides. My major concern is that this remains true with systemd as well.
I don't think the sky is falling. The reason I don't think that is because I think that if an impasse would be reached, we'd just see an alternate init, either new or existing, start to be implemented more widely. I'd rather it didn't reach an impasse, though. I'd rather not see any more of things like a certain desktop can't be run on a certain system because it doesn't have systemd. That seems too far for dependencies on an init system to reach. There are enough concerns of that sort about Wayland, which is more directly connected to the user interface, and thus can't help but have a more direct effect on the user.
You are generalizing way too much beyond the scope of this subject.
@devnet, systemd has by now gone far beyond init.
Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal.
Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal.
Quoting:Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal.
Which leads back to the title of this thread and notbob's original point - not to mention one of the points I made - simply, just give a choice. And no "you can disable much of SystemD, but you are stuck with it like it or lump it" is not a choice. And that's precisely where we are heading considering that user space programs are starting to depend on SystemD.
Quoting:@devnet, systemd has by now gone far beyond init.
Here is the thing tho. With any other init alternative, the things running on top don't care what init is being used (sysv, openrc, upstart, a long shell script running things in sequence, etc etc etc). But with Systemd it suddenly becomes A Very Big Deal.
Aye, there's the rub...
It's apparently become such a chore to avoid using systemd, that many distros have switched, not because they prefer it (indeed, sometimes to the contrary) but simply because the extra effort that avoiding it entails is becoming/has become rather onerous, so that the devs can't afford to leave it aside.
There is a GSoC project to port systemd to OpenBSD, even though systemd devs have no intention to support it.
Just sayin'.
Just sayin'.
it's not a port of systemd but a reimplementation of the APIs.
skip the discussion that links to the code repository, there is nothing useful in there except for the last few comments, for example http://www.phoronix.com/forums/showthread.php?105988-OpenBSD... which points to ubuntus systemd-shim: http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-...
another interesting comment below shows partial success in porting the bsd rewrites back to linux.
that whole post at http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-... is actually quite interesting. although the author is a bit dismissive about the systemd-shim effort, he does point out a lot of what's wrong with the discussion around systemd.
greetings, eMBee.
skip the discussion that links to the code repository, there is nothing useful in there except for the last few comments, for example http://www.phoronix.com/forums/showthread.php?105988-OpenBSD... which points to ubuntus systemd-shim: http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-...
another interesting comment below shows partial success in porting the bsd rewrites back to linux.
that whole post at http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-... is actually quite interesting. although the author is a bit dismissive about the systemd-shim effort, he does point out a lot of what's wrong with the discussion around systemd.
greetings, eMBee.
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 think you missed the point. The changes didn't make things more productive. They just broke things, and users needed to develop work-arounds to fix them. As for easing the pressure on individual distributions, it certainly does ease the pressure when a significant percentage of your users abandons you for the competition. That's another thing that happened ...