I wonder if the changes to GDM will mean that other DE's like Cinnamon, MATE, Budgie, Deepen (XFCE?) won't be able to start anymore via GDM?
Introducing stronger dependencies on systemd
161–170 of 179 posts
Re: Introducing stronger dependencies on systemd
#162Earlier quoted context omitted.
> good tooling My completely oblique, binary logs disagree. It won because it solved problems companies with money needed solved. There is no indication that it succeeded on merit.
Ths only issue that non-human readable log storage has caused is the endless nagging on forums. Literally never been an issue besides.
literally has, or there would be no "nagging". I have yet to experience a benefit for those binary logs
Re: Introducing stronger dependencies on systemd
#163Earlier quoted context omitted.
Systemd is crap. Works in the main use case, mess up otherwise. It is the windows kernel of linux distributions. Here for example, suddenly systemd will be mandatory despite systemd not caring for multiple session of a single user. Not only not yet implemented but totally that don't need it personally so no one can want to have it. And so again the capability of our linux based distribution will be restricted for som…
systemd is far from perfect, but it's the best we've got on Linux. Treating systemd like an init system is like treating your car like a Bluetooth speaker: yes, you can connect your phone to the speaker system over bluetooth and yes you can take the speakers with you to most places, but the speakers are only a small part of what you're taking along with you Nobody is forcing systemd down anyone's throats. You can use…
And to add to the fact that it was shoved down our throat, it wasn't even the best system. There was plenty of them that were interested with great features initng, upstart,... But systemd won because they manage to force us to depend on them for main distributions and core components like login. Pushed strong by red hat...
Re: Introducing stronger dependencies on systemd
#164Funny how it doesn't matter anymore. Gnome has been quite good for more than 10 years but nobody really care because the web browser has become the Desktop Environment. I haven't notices any change in the last 10-15 years. and power users will use i3, sway or hyprland anyway. The Gnome people create drama about irrelevant things to get attention like "the danger in theming apps", some minor UI changes or the stronger…
> Gnome has been quite good for more than 10 years
I know there’s no accounting for taste, but GNOME Shell has to be the worst desktop environment I’ve ever used, and man I’ve used a lot of different ones
Re: Introducing stronger dependencies on systemd
#165Earlier quoted context omitted.
> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init sy…
This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service i…
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.
Idiots instead rant about "muh systemd" and use it to attack other maintainers.
Re: Introducing stronger dependencies on systemd
#166What's interesting here isn't a strict dependency on systemd, but dependencies on some APIs it provides. Given the ability and existence of things which implement those APIs outside of systemd, it's worth considering that the APIs themselves should be the focus. Perhaps they should be spun out of systemd itself. It seems sensible to that gnome would want to move to a better API which is almost defacto a standard thes…
The problem is that those APIs are not well documented, so reading the convolute source code may be the only documentation in some cases. Perhaps there is some documentation, but it is well hidden. Just these days, after being hit by the fact that the Xorg server has become dependent on systemd, I have begun to search for what elogind is really doing to simulate the login services of systemd. I have not found any eas…
> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals.
The blog post subject of the thread literally links to the documentation. If you can't even be bothered clicking on the provided links, what are you even doing commenting on such a thread. But by all means, don't let facts get in the way of a good baseless rant.
Re: Introducing stronger dependencies on systemd
#167Earlier quoted context omitted.
All of us paying attention saw how the systemd authors shopped their stuff around issue trackers and mailing lists telling everyone "it's just the way it is now." They absolutely did manufacture the situation. They pushed hard enough doing this that it's resulted in multiple large distros being forked by groups of former maintainers.
Care to share any evidence to back up the tall claim that systemd authors forced their code on anyone?
obligatory: https://news.ycombinator.com/item?id=11797075
Re: Introducing stronger dependencies on systemd
#168I have yet to hear an argument against systemd which isn’t a variation of: - """bloat""" - I dislike Poettering. Remember pulseaudio? - a core user-space layer for modern applications that can’t only rely on the spartan kernel syscall API? Literally 1984. Given that systemd is good enough and is running on 99% of desktops and servers, I always find it hilarious to see how the vocal minority is overrepresented on this…
I believe that the opposite applies. I have yet to hear any argument pro systemd that is valid. As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd. In practice, systemd has been imposed by force. The developers of a few packages, like GNOME, have introduced dependencies upon syste…
> As long as the systemd supporters cannot explain its advantages, there is no reason for anybody else to replace their good systems that work fine without systemd, with systems using systemd.
Assuming you know what systemd as init system able to do, I'm not sure what extra information you need for getting list of advantages.
If you going with examples is better for you, i'll mention couple of mine - note that I likely forget some other good samples as it's so natural so I'm may be not realizing it's systemd's feature, just "how things work"
* hardening - syscall filtering, privilege limiting, read/write path filtering, per-unit tmp files. As nice example, I have great peace of mind when I put php-fpm into network isolated to localhost only for IP level
* resource management and resource information at all - observing resource usage by multiple units when needed with a quick way saves my time, in addition to being able to collect such metrics into monitoring. Setting the lowest IO priority for backup scripts and even MB/sec per block device - godsend. Limits on CPU usage or RAM usage where needed ensures smooth operations of the fleet without nasty surprises
* things like quick overview with systemctl --failed, user-level units instead of flacky @reboot in crontab (yeah, we still remember it from eggdrop/psybnc days)
* clear and uniform way to work with services across the team, no hacky bash scripts with saving PIDs
so on.
Probably you do system administration for your servers in some other way that all that goodies are not noticeable for you and your team.
Re: Introducing stronger dependencies on systemd
#169Earlier quoted context omitted.
There aren't decent Pro systemd arguments other than "the Linux API confused me" and sysv init (which no one argues is good) was bad. Personally the last system I had systemd on corrupted my package database after killing apt that I was running in tmux. "Oh you can fix that with xyz systemd configuration." Here's my response: Kindly shove it up your ass and quit moving things around all the time just because you're b…
Honestly this sounds like an apt problem. A properly robust package management system shouldn't be able to succumb to such a problem. Your abrasiveness is not helping discussion. I'm also not a board.
So your software broke my machine then you tell me it's my problem and wonder why people are angry and frustrated with you?
Do you see why most competent people's reaction is to just use something else? systemd might even be technically superior but the maintainers are such assholes it's not worth it.
Re: Introducing stronger dependencies on systemd
#170Funny how it doesn't matter anymore. Gnome has been quite good for more than 10 years but nobody really care because the web browser has become the Desktop Environment. I haven't notices any change in the last 10-15 years. and power users will use i3, sway or hyprland anyway. The Gnome people create drama about irrelevant things to get attention like "the danger in theming apps", some minor UI changes or the stronger…
> Gnome has been quite good for more than 10 years I know there’s no accounting for taste, but GNOME Shell has to be the worst desktop environment I’ve ever used, and man I’ve used a lot of different ones
Yeah let me put it in context.
I was exited and used Gnome 1.2 back in 2000 (?) It was fun but not serious compared to let's say the MS Windows 2000 desktop.
Progressing in the Gnome 2 serie it became a more serious project and something that could compete with the MS Windows desktop.
Both are full of annoyances...