LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - General (https://www.linuxquestions.org/questions/linux-general-1/)
-   -   Are you for or against systemd? (https://www.linuxquestions.org/questions/linux-general-1/are-you-for-or-against-systemd-4175603950/)

ondoho 05-07-2017 12:06 PM

!!!, you should really invest a minimum of time into formating your posts, i almost missed this:
Quote:

Originally Posted by !!! (Post 5704359)
I want systemd to replace my bootloader, kernel, and PackageManager in My SunOS SMF

that could be one answer to a question i posed earlier in this thread.

and this:
Quote:

systemd on wristwatch FUD!
is a pretty funny remark.
Subtitle:
"Lennart Poettering would love it!"

Xeratul 05-11-2017 02:00 PM

Further reading for a great time and fun:
http://suckless.org/sucks/systemd

ondoho 05-11-2017 02:17 PM

https://encrypted-tbn0.gstatic.com/i...d7Q0-6ZTYTJWuA
edit:
i should reintroduce full quoting.
the previous post was MUCH longer, with loads of unsubstantiated and even plain false statements, hence my reaction, trying to calm myself with a nice green colour and thoughts of the queen of england.

jamison20000e 05-11-2017 06:09 PM

How bout nothing ever braking‽ https://www.linuxquestions.org/quest...ml#post5708564 :eek:

the dsc 07-09-2017 12:57 PM

Sorry if that's too old a thread to "bump".

I'm just an average ex-windowser for 10 years or so, and I don't know the nitty-gritty things os software design, development and sysadministration, but the notion of "do one thing and do it well" has a tremendous intuitive appeal.

I can't believe that a "pro" on systemd at slant.co is "do one thing and do it well." Does "everything" counts as "one thing"? And "well..." counts as "well"?


So I was wondering if is anyone (like FOSS councils and the like) considering to slice the systemd code into "minimal" subcomponents, as a way to perhaps address the criticism that it's too gargantuan and doing too many things, becoming a huge, unavoidable dependence for some other software.

Instead of having all these things in a single binary, it could be systemd-core, systemd-cron, systemd-whatever and so on. Would something like that help making systemd more easily optional, giving more freedom and room for other init systems to evolve in parallel (kind of akin to different desktop environments), as well as improving systemd itself?

Does not doing that presents any advantage other than the glory of conquering the init monopoly in linux?

Is the systemd development a "member" of some sort of "FOSS council"/whatever that commits to adhere to some democratic decisions? If such thing exists, rather than being just, "hey, this is what we think it would be better for everyone, but no one need to commit to anything". But, either way, perhaps systemd may be involved in some of those non-binding councils, which could eventualy come to the conclusion that splitting the software would be better. Then they'd be kind of jerks if they'd just ignore it.

jamison20000e 07-09-2017 02:27 PM

The opinion\philosophy
Quote:

do one thing and do it well
is no longer relevant in today's computing unless you're setting up something small* or old* in which case still use FOSS... :eek:

...can walking be one thing done well, won't you hit a wall or be by a car if not also looking‽

jamison20000e 07-09-2017 02:31 PM

Linux runs the whole OS and often with blobs too... grumble, grumble and keep that GUI off my lawn!

the dsc 07-09-2017 08:49 PM

Quote:

Originally Posted by jamison20000e (Post 5732878)
The opinion\philosophyis no longer relevant in today's computing unless you're setting up something small* or old* in which case still use FOSS... :eek:

...can walking be one thing done well, won't you hit a wall or be by a car if not also looking‽

I believe the disagreement of people more engaged in defending this would be on the lines that "doing one thing well" doesn't mean we're speaking of the entire system focused on that single-task while it's running.

Hence, you can be running "walk" and "look" at the same time, which in turn may communicate with "walk" and call any other task as needed. And each task can be more or less highly specialized, which may allow its code to be clearer and more easily debugged, or replaced. It also allows users or sysadmins to play with "walkthisway" instead, while keeping the same "look" application at the same time. Or vice-versa. There's no need for a "do-absolutely-everything" singular program.

Likewise, there's no need for systemd to eventually merge with xorg/wayland and provide a graphic environment, or to replace grub, in the other end (not that they're actually planning it). They still can do it, but it could be through a separate "sd-xorg", or "sd-grub", each focused in doing "one thing".



I'm not sure that even really applies that much to the systemd debate that much, that's not something I really have any knowledge about. I just feel kind of lost with it. My PC was simply not shutting down for a while, unless I used the sysreq "trick" or the even more brutish "poweroff -f". I just had no clue where to look, and google wasn't helping. Whereas with sysv, at least, there's this feeling I could "hack" into the shutdown script and adapt it to whatever mess I may have done somewheere else, making it work. Fortunately that wasn't even needed, as switching back to sysv just fixed it out of the box.

jamison20000e 07-09-2017 10:17 PM

Quote:

Originally Posted by the dsc (Post 5732964)
... "do-absolutely-everything" singular program....

Again, like Linux, that has developers first and foremost; thankfully. The average person has two parents even tho needs a village.edu

For me is opinions\philosophy versus (on my Stretch\Sid side lightning-fast, stable(—tho "not supposed to be"(;))?):eek:) reality‽

Myk267 07-10-2017 12:20 PM

Quote:

Originally Posted by the dsc (Post 5732844)
Sorry if that's too old a thread to "bump".

I'm just an average ex-windowser for 10 years or so, and I don't know the nitty-gritty things os software design, development and sysadministration, but the notion of "do one thing and do it well" has a tremendous intuitive appeal.

I can't believe that a "pro" on systemd at slant.co is "do one thing and do it well." Does "everything" counts as "one thing"? And "well..." counts as "well"?


So I was wondering if is anyone (like FOSS councils and the like) considering to slice the systemd code into "minimal" subcomponents, as a way to perhaps address the criticism that it's too gargantuan and doing too many things, becoming a huge, unavoidable dependence for some other software.

Instead of having all these things in a single binary, it could be systemd-core, systemd-cron, systemd-whatever and so on. Would something like that help making systemd more easily optional, giving more freedom and room for other init systems to evolve in parallel (kind of akin to different desktop environments), as well as improving systemd itself?

Does not doing that presents any advantage other than the glory of conquering the init monopoly in linux?

Is the systemd development a "member" of some sort of "FOSS council"/whatever that commits to adhere to some democratic decisions? If such thing exists, rather than being just, "hey, this is what we think it would be better for everyone, but no one need to commit to anything". But, either way, perhaps systemd may be involved in some of those non-binding councils, which could eventualy come to the conclusion that splitting the software would be better. Then they'd be kind of jerks if they'd just ignore it.

It's important that not everything in the systemd changelog, or those on that suckless page, are included in the singular `systemd` binary. There's a number of modules that live under the 'systemd' name which get built as separate binaries. Here's some from my system:
Code:

$ ls /lib/systemd/
                          systemd-import                systemd-rfkill
                          systemd-importd              systemd-shutdown
                          systemd-initctl              systemd-sleep
                          systemd-journald              systemd-socket-proxyd
                          systemd-localed              systemd-sysctl
systemd                  systemd-logind                systemd-sysv-install
systemd-ac-power          systemd-machined              systemd-timedated
systemd-backlight        systemd-modules-load          systemd-timesyncd
systemd-binfmt            systemd-networkd              systemd-udevd
systemd-cgroups-agent    systemd-networkd-wait-online  systemd-update-utmp
systemd-cryptsetup        systemd-pull                  systemd-user-sessions
systemd-export            systemd-quotacheck           
systemd-fsck              systemd-random-seed         
systemd-fsckd            systemd-remount-fs           
systemd-hibernate-resume  systemd-reply-password       
systemd-hostnamed        systemd-resolved

I edited out the extra directories and other files living in there.

You seem to want software designed by a committee*? I'm not really convinced there's any one good methodology to producing an optimal outcome in software. They probably all have trade-offs.

Though, in a way, there kind of is a committee: the rest of the software in the world. For a while now, some systemd people want daemons like tmux to add systemd-specific code so that they don't get killed when a user logs out**. Unix has had a way of doing this for a really long time, so the tmux and other developers are totally in the right to push back against this, keep filing bugs, and/or turn that stuff off at the distro level by either config options or patches.

*What a ridiculous word. Look at all those extra, bureaucratic letters. :p
** https://github.com/tmux/tmux/issues/428

Quote:

I'm not sure that even really applies that much to the systemd debate that much, that's not something I really have any knowledge about. I just feel kind of lost with it. My PC was simply not shutting down for a while, unless I used the sysreq "trick" or the even more brutish "poweroff -f". I just had no clue where to look, and google wasn't helping. Whereas with sysv, at least, there's this feeling I could "hack" into the shutdown script and adapt it to whatever mess I may have done somewheere else, making it work. Fortunately that wasn't even needed, as switching back to sysv just fixed it out of the box.
I definitely empathize with your point. I appreciate some aspects of systemd but, other times I feel like "I'm not just a node in a server farm -- this is my Personal Computer." I still have hope that, one day, a daemontools-alike or maybe something radically different will swoop in and save the day.

the dsc 07-10-2017 03:24 PM

Quote:

Originally Posted by Myk267 (Post 5733250)
You seem to want software designed by a committee*? I'm not really convinced there's any one good methodology to producing an optimal outcome in software. They probably all have trade-offs.

Not really "by committee", I guess. I just know that there are things like the "freedesktop.org" standards, so perhaps something similar to that for the "under the roof" side could have lead or eventually lead the development of systemd and alternatives without such a dramatic schism. Somewhat like Gnome and KDE, neither have become yet de facto "linux dependencies", and even though there are mutual haters in each side, I guess the large majority of users is't that much of a hater of the other DE or software, even though they may frown upon the fact that sometimes there are too many dependencies if you want to use just one thing or another. There are also heated debates in the DE+distro wars anyway, but I guess that perhaps they agree in some sort of principles that allow for a comparatively easier coexistence, rather than a state of a looming monopoly.



Quote:

I definitely empathize with your point. I appreciate some aspects of systemd but, other times I feel like "I'm not just a node in a server farm -- this is my Personal Computer." I still have hope that, one day, a daemontools-alike or maybe something radically different will swoop in and save the day.
In a way don't "really" have anything against systemd in a "technical" point of view myself; I just sort of overheard those, they seem to make sense; coincidentally, I've had more init-related bugs in the brief existence of systemd than during all those years before. At the same time it's not self-evident to me that it's compensated by dramatic improvements elsewhere; when it works, it's just like it always have been before, not a "next generation" experience. So I assume that if these criticisms were being taken more seriously, possibly there would have been less bugs. But if there weren't bugs somehow, being just a desktop user, I wouldn't even mind if somehow they blended init with grub and with the kernel itself, or any other philosophical atrocity.

At the same time I of course empathize with the concern of those to whom those things could also mean practical troubles. And with those who actually are closer to the actual improvements side of things, apparently developers like systemd's APIs better than whatever they had before.

In brief, I was wondering if it there couldn't be a "middle ground", or "the best of both worlds", or "most of the goods of both worlds", possibly a less buggy middle ground.

jamison20000e 07-10-2017 03:38 PM

https://www.linuxquestions.org/quest...ml#post5708518

NewbProgrammer 07-10-2017 10:56 PM

I'm *absolutely* fine with using systemd, I just don't like it.

elcore 07-11-2017 12:30 AM

I think fragmentation will persist, no matter what the "major distributions" demand.
Furthermore, a good architect can easily make every part of the building accessible, it's just that some architects act like wardens and build cell blocks where houses used to be.
A secure binary registry to replace the evil plain text, if you will. To protect you from freedom, or something.
Just hang this pretty poster over these steel bars and it's just like before, they said. It's not that I hate systemd, I'm just disgusted by it.

jamison20000e 07-11-2017 02:52 AM

Bitching about the software and not the hardware is stupid! http://www.techrepublic.com/blog/lin...-linux-kernel/


All times are GMT -5. The time now is 10:17 AM.