4 ms·
"While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop,
by CrLf 13y ago
"While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device."
Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap.
Lets exclude mobile devices from this picture (because those don't use general purpose Linux distributions and arguably don't use unix at all, but a unix-kernel with specialized - non-unix - userspace) and concentrate on servers and desktops/laptops...
This systemd rage shows exactly why it's 2014 and while Linux is extensively used and trusted on the server side, it continues to limp along on peoples' desktops: it constantly reinvents the wheel (badly) with monolithic pieces of bloatware that are usually throw away tried-and-true solutions for unproven experiments. It throws away the old way of doing one thing and do it well in favor of components that do too much and become so complex that troubleshooting is a nightmare, exactly the kind of complaints we have about non-unix systems...
Need an example? Where are the people that used to criticize the Windows registry now? I just recently almost(1) had to throw away my entire home dir on Ubuntu just to try and reset Kontact, because in this day and age the configuration structure of this stuff is far worse, and it's almost impossible to separate one component's configuration files and folders from everything else. And I'm not even going to start ranting about how in the name of $DEITY a mail/calendar application needs MySQL running in the background and about there is not a single decent mail client for Linux right now. Mail... a decades-old problem!
I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it.
(1) "Almost" because I just learned to live with the occasional crashes and misbehavior caused by some pieces of old configuration still lingering somewhere.
- hactually 13y ago> I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it. I think the Lennart and the Red Hat engineering team have more important things to do than covertly install systemd on your server. Please quit with the hyperbole.
- theBlackDragon 13y agoAnd there you exactly pinpoint the problem. The FLOSS movement used to be about caring about other people and projects. RedHat* and its employees only give a damn about their use-cases and the rest of the "community" can go to hell. Which, of course is a logical stance to take for any corporation, however how easily everyone goes along with it is just appalling. *this, of course, goes for every corporate entity, though some work with the community better than others.
- hactually 13y agoHow have I pinpointed the problem? I'm sorry - are you arguing that the RH guys should be covertly installing systemd in the parent posts servers?
- vidarh 13y agoEveryone "goes along with it" because they've evaluated it and decided it fits their uses cases too. Redhat does not have the power to force anyone to adopt systemd.
- theBlackDragon 13y agoAnd yet they do. They pay enough developers working on enough big projects to have the power to force adoption (not to mention the sponsoring of various other things, like infrastructure). By making it a hard dependency of Gnome for example (which in itself has turned into a 3rd-party developer hostile project, but that is another discussion entirely, but if you care, go read IgnorantGuru's bloggins) So they're using end-user pressure (no systemd = no Gnome) to force adoption.
- Xylakant 13y ago> The FLOSS movement used to be about caring about other people and projects. Was it? I thought the primary driver was "I had a problem, this is the fix for my problem, maybe it helps you. I share this solution, you share yours.". Which basically holds true nowadays: Systemd solves Redhats problems. If it solves enough problems for enough people then it will prevail and other people might enhance it to fix their problems as well if they deem it a viable foundation. If it doesn't, then systemd will remain a niche solution that fixes redhats problems - which would totally be fine with me. Given that we have the discussion on the debian list I'm inclined to believe that at least enough people think systemd is it to give it a push. If you don't like it stick with what you like or roll your own, but don't bitch and moan about redhat building a software that suits their use-case primarily and giving it away for free.
- vidarh 13y agoAs someone responsible for dozens of servers and 100+ vm's: The "tried-and-true" init solution is utter shit. It's duct-tape and band aid. The current init solution does too much. Not in initd, but in the massive mess of scripts piled on top of it to get a working system.
- d0 13y agoYou might want to take a look at FreeBSD's init and process management stuff. It's very clean, tidy, well engineered and doesn't involve sysvinit.
- vidarh 13y agoOr I just use systemd. My interest in getting rid of sysv init is less work, not having to to spend time dealing with an init system not supported by the Linux distro's we depend on. Doesn't matter if FreeBSD's solution is better or cleaner or both, I'm afraid.
- synchronise 13y agoI think he was suggesting you try out FreeBSD, which I also recommend. It's a solid server environment.
- vidarh 13y agoI have, but I have no reasons whatsoever to consider a switch - the potential upside is way too small to be worthwhile.
- synchronise 13y agoWhy?
- vidarh 13y agoBecause the potential upside is tiny. There's nothing in FreeBSD that I can't get in Linux that I have any particular need for. I'm sure there are features that are important and valuable to other people, but that doesn't help me. That leaves near 0 benefit, and some unknown non-zero cost and risk associated with reduced experience with it, potential application incompatibilities and other unknowns, as well as a time cost of re-imaging servers and re-deploying vm's that would put tens of thousands on the cost side. That's not exactly a cost-benefit situation that justifies spending time considering it. If the FreeBSD guys develop something so amazingly much better than Linux that we could save lots of money by switching, that could change. I don't see that as very likely, though. As it is, FreeBSD vs Linux is a bit like Coke vs Pepsi: If you have a preference, and its available, pick it, but it makes very little sense to expend lots of effort to replace one with the other.