91–100 of 193 posts
Earlier quoted context omitted.
Didn't upstart and launchd cover this before systemd?
I don't know launchd, but upstart was a piece of crap that didn't even implement it's own documented functionality.
Earlier quoted context omitted.
It's baffling to see people insist that that's the UNIX philosophy when the UNIX philosophy has always been about monolithic kernels over microkernels, so "do one thing" is out the window, and about worse-is-better over do-the-right-thing ( https://www.dreamsongs.com/RiseOfWorseIsBetter.html ), so "do it well" is out the window. And the userspace tools don't follow this either. Quoting http://prog21.dadgum.com/139.ht…
The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosophy. Crashing an init process is a very bad thing, is it not? Wouldn't less surface area be a better approach?
Earlier quoted context omitted.
> I'm curious what functionality other OSes had that Linux did not before systemd came along. Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess. The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion time…
You refuse to look, and thus have clarity. Dude that is not a good argument. What is not uniform about the previous service handling implementation in debian?
What? Should I have to know everything about systemd to comment on one specific part of it? I don't know about alternative init systems either, all I wrote is that for service management: systemd >> SysV.
> What is not uniform about the previous service handling implementation in debian?
I can't tell you since I don't use Debian. I can tell you that in Ubuntu there are lots of inconsistencies. Like different service scripts respond differently to the help command.
Even the "status" commands output varies between scripts.
This means there is no way to introspect a service to know if it supports things like the "restart" command or if "stop" and then "start" should be used instead. This also means that making a robust GUI tool for handling services becomes hard/impossible.
Earlier quoted context omitted.
I basically agree with everything you're saying, I just think if the people who think systemd is misguided spend their time writing blog posts about it, nothing will change and the people actually writing the code will have the final say, right or wrong.
The thing is though - their code is already written. Systemd is entirely unnecessary for 99% of people, probably everything except some of it's LXC features has clear and popular alternatives. LXC is the only thing making me eye systemd with interest, but I'll come back to it in a few years once all the weird stuff is worked out.
All production ready Linux distros (RedHat (and by extension CentOS), SuSE and Debian) are all running systemd and as a systems administrator for a large company I _must_ adopt it, I don't have a choice.
It seems like it is quite fashionable to hate on systemd, and it seems like systemd is kindof a piece of crap - in some ways. However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. This is open source, if you don't like systemd, if you think it's crap, if you think there are obviously better ways to do it, well, what are you waiting for then? Syst…
I think Systemd is winning because it works (in the overwhelming majority of cases), and no one cares about init systems except the vocal minority.
Earlier quoted context omitted.
> However, linux is missing basic functionality other os's offer Could you please elaborate on what some of those are? > systemd is showing up and trying to fill in those blanks I haven't really kept on top of all systemd releases, but all I can see is them replacing things that already exist, just doing them in a different way. I agree the init system replacement was necessary, but I'm struggling to understand why a…
I basically agree with everything you're saying, I just think if the people who think systemd is misguided spend their time writing blog posts about it, nothing will change and the people actually writing the code will have the final say, right or wrong.
Earlier quoted context omitted.
With PulseAudio, I have 1 singular feature that makes most people wow: When I plug in any new audio device, whatever I'm playing/recording automatically sinks to the most recent device. Seamlessly. So if I'm on mail.google.com and a GVoice call comes in, I can take the call, and during the call, plug in my USB headset. It just works. Mac can't do that. Windows can't do that. Linux/PulseAudio can. And that kicks ass.
Mac absolutely can do that, I'm not sure why you think it can't, perhaps it couldn't in the past. I do it almost daily when I come home and plug in my Bose Companion 5 into my Macbook (USB Speakers)
It could also have been a borked install as well. But I'm sitting in front of a Win10 install on a Surface 4 Pro, and it can't auto-sink audio.
Earlier quoted context omitted.
There are exactly two compelling (for me) arguments against systemd, and one that seems to result from it's current focus: * Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.) * Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it. * Servers - systemd seems to be focused on a desktop lifec…
Yes, these are also reasons I dislike systemd. Also, one of the original selling points of systemd was "It will reduce boot times significantly!" ... And then it ends up that systemd is actually slower to boot than any of the other ones out there.
But honestly, even an extra 30s booting a server is nothing, I don't give a shit about boot times on my servers.. I care about what order my services are started in- my servers should be 100% reproducable otherwise you could have bugs that never get found except in 1% of cases.
And since it's turtles all the way down 1% of one system can be a lot of problems in a 2,000,000 server architecture.
So "Fast boot" in the way systemd achieves it is not beneficial for me.
Earlier quoted context omitted.
I strongly disagree. I didn't need anyone to "show up" to replace my init system in production across several thousand servers, and the way systemd "won" that battle wrt Debian was, to be polite, controversial, political and extremely divisive. They sure as heck didn't win because "they showed up and no one else did". They showed up and RedHat's money showed up with them. I hold no animus towards the systemd project'…
> I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state. I am, in a way, reminded reminded of PulseAudio. I kept PA of my desktop and laptop for years, having heard about PA being a complex nightmare to configure and make work that caused audio to break. Eventually, there was an application I needed to use that…
systemd wasn't reliable or fit for purpose for servers when it got shoehorned in to everything.
When it comes to production servers you need stable and reliable. Not new and shiny. You're ideally rarely having anything happen on the server other than "run this software"