Quote:
Quote:
https://www.linuxquestions.org/quest...ml#post5771074 https://www.linuxquestions.org/quest...ml#post5772948 The last post (last paragraph) also contains my view on systemd integration, consider it also as an answer to your last question. I'm not against having it provided by Slackware, much like as an alternative, but I doubt it'll be possible without messing up the whole distribution. If they just designed it as an overlay like webmin (not using it either), it would have been fine, hence, this is one of the design issues I mentioned. Speaking of flexibility, if systemd will become a de facto standard (again, I doubt it will) and I'll need to conform to its operation mode and syntax, my concern is that I'll loose details (or granularity) over the administrative tasks I like to perform. I'm pretty sure I'll develop a series of small scripts to hack & tune it, and I'll be back to where I started - bash init scripts, well with some unnecessary overhead. Speaking of design flaws, I gathered a few that I remember reading about and considered "scary" enough to get concerned: - overall, IMHO one of the truly big design flaws is the complexity, size (pushing all the crap into the init), interconnections & dependencies. I don't see a sysadmin (myself included) lecturing the systemd sources to gain more knowledge and troubleshoot issues. Instead, he/she will be dependent on the Poettering & co. Not the case with a "clear text" scripted init system. - to the complexity I can add the constant "invention" of features some Biggus Dickus came up with or was told to implement (more likely) and the precarious (bad code & design) way these are implemented, many times needing several patches. - security - adding everything into the init process increases its attack surface/vulnerability - an unnecessary PITA changing the boot order. I remember the parallel execution was the only feature I considered novel/useful, not anymore, just an useless over-complication for gaining a few seconds (minutes?) in boot time. https://serverfault.com/questions/48...and-boot-order - binary logs and the "rationale", right... very rational rationale https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3 -"simplifying" the network setup, guessing interface names https://www.freedesktop.org/wiki/Sof...nterfaceNames/ https://access.redhat.com/solutions/2592561 - hard coding nameservers? really? https://github.com/systemd/systemd/issues/494 - etc - just use google for some more interesting design (& features) examples I do question Monsieur Poettering & team both intelligence & wisdom, based on the outcome of their work, which I consider, apart from what they were instructed to do, driven more by typical "youth exuberance" (and other affections like boredom) ending up in a "premature ejaculation" and not in a serious product. Sorry, not impressed and doubtful that things will improve given the "kind and fruitful" interaction these folks have with the Linux community. __ I guess I spent enough on this subject (again) - @enorbert - please do ask the mods to lock your thread ;) |
Quote:
|
Isn't part of the problem that there are two Linux communities, not one? On the one hand, most servers run Linux. The whole Internet runs on Linux. And then you have the desktop Linux community, which is itself split into hacker types and people like me who just want an easy-to-understand OS which is secure against malware.
These communities have totally different priorities and Red Hat is oriented towards the server market. Most server admins prefer systemd and not just systemd either. The new nomenclature for network interfaces is also aimed at the server market where machines often have several different network cards, which need reliably constant names. And I suspect the replacement of simple partition device names by UUIDs is also server oriented. For desktop users all this is a pain in the a***. We didn't ask for any of it but we are given it anyway. Desktop users value the modularity of Linux because it gives us the freedom to mix and match software. We don't like the tight integration that comes with systemd. I'm currently wrestling with BLFS-9.0 (sysV version) and finding it quite dispiriting. I can't quickly put up a functional but minimalist system as I could with earlier versions because of all the new dependencies that have been introduced. They are necessary, apparently, to allow higher level software to run without systemd. This is definitely the last LFS that I do and I don't even know if I shall finish it. It just isn't fun any more. I'm beginning to wonder if the best answer is some kind of "conscious uncoupling" of the two communities. |
I think most of the opinions on this thread can be summed up in a systemd that is:
a blob of unnecessary software that creates too many dependencies and breaks the system and principles of the GNU/Linux community implemented by the thoughtless and inconsiderate and greedy corporate lackeys and their uncaring newbie and lazy followers who allows it. |
Quote:
|
Quote:
|
Quote:
|
The off-topic and back-and-forth personal attacks will not be tolerated moving forward. Challenge others' points of view and opinions, but do so respectfully and thoughtfully... without insult and personal attack. Differing opinions is one of the things that make this site great. LQ is a great place for public discourse, and something we encourage, but the recent escalating trend of that discourse not being possible is both disconcerting and disappointing. If you're like to continue participating here, I encourage you keep this post in mind. If there are any questions, please feel free to contact me.
--jeremy |
Quote:
Just look at all the effort to use dash as a default shell in debian and ubuntu. Yet it was much easier since dash is (as bash) a POSIX/bourne shell... So yes, when (most of) the world settled on the bourne shell, it would have been increasingly difficult and costly for a distro maintainer to keep csh as the default shell. I used this analogy just to highlight why I am worried. When the rest of the world switches away from a piece you rely on, you are condemned either to adapt, or to a looong uphill battle. This is what devuan is facing. I don't know how they are doing. I don't know how motivated their (unpaid) contributors will be, five years down the road. |
AntiX has the same problem. They use a special repository with nonsystemd versions of programs like cups, which takes precedence over the Debian repos. But I've seen this cause horrendous problems when, for any reason, the nonsystemd repo isn't accessible. Then the Debian versions are referenced and they want to install systemd and get rid of eudev (which means also getting rid of a lot of software including the X desktop). A naive user who answers "yes" to this can get into a lot of trouble. I've seen it happen.
|
why has this thread not died yet. Slackware is more than likely not going to switch to systemd, so get over it and let this thread die, if you want a systemd distro then switch distros, there are plenty of zombie distros that have sold their soul for systemd
|
Quote:
|
Quote:
I'm actually using both, whichever is more appropiate to the problem I'm writing a script for. For instance, my "backup" script uses tcsh, but to restore something FROM such a backup bash is used (as it's using "$@", which is a bash'ism). And I think there are still quite some people using ksh, which is NOT a Bourne-shell replacement (although bash did borrow some enhancements from it). |
Quote:
Regarding ksh, I thought that it was compatible with the Bourne shell (ie. for example an ash script would run ok in ksh - the opposite is obviously not true). Maybe I am wrong here. When I said "(most of) the world settled on the bourne shell" I admit that I was a bit "Linux-centric" :-) Sorry for that. |
Quote:
Then, there is the sustained potential of this thread, as previously highlighted by Lysander666, to attract trolls and spark flame wars. It's not about free speech, which I obviously support, but about useless speech, because nothing changed with systemd ever since it was launched. Same design, well, maybe the code is a little bit more mature (patched & overpatched). I remember someone mentioned the Dlackware project some time ago, forgot about it and found it again now: https://github.com/Dlackware/dlackware https://github.com/Dlackware/systemd https://github.com/Dlackware/pam It's there, the effort has been made, there are two maintainers that could provide valuable feedback and the project can be both an alternative and a source of inspiration. |
All times are GMT -5. The time now is 10:42 AM. |