51–60 of 126 posts
Earlier quoted context omitted.
> Given things like this: "The default configuration is defined during compilation [so a configuration file is only needed when it is necessary to deviate from those defaults....]" I don't get it. What's so bad about that?
It means that a configuration file on two similar machines could have radically different behaviors.
Before systemd, a difficult bug was a difficult bug. With systemd, a difficult bug leads to an attack on systemd itself, and questioning whether it should even exist. I like systemd, it's a pity some vocal people aren't enthusiastic about it. Just like politics and the news, when you read of something being attacked, I think "who is saying this, doing they have an underlying bias against this thing they are attacking…
With systemd, any really tricky low-level bug is systemd's fault, because systemd tries to do everything, in the most "advanced" way. And due gnome3 dependencies it's been adopted by all major distros. Before systemd, a difficult bug was not always the fault of one newfangled opinionated and unavoidable package. I read the first blog post about systemd when it was written, and thought it was really interesting. Then…
That's not correct. It has been adopted by all major distros due to ease of use and maintaibility of unit files. That is very clear from nearly all mailing list discussions.
Also, people can and do use gnome3 without systemd. (https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd).
Earlier quoted context omitted.
Everything that would have been "a weird problem with Foo Daemon's init script" we now call "a weird problem with systemd". So you think that systemd-timesyncd's service file shouldn't choose the uid at service-start time. That's not really the issue though. The issue is that for service isolation reasons (related to choosing the uid at service-start time), the service file wants to run systemd-timesyncd in a private…
If SELinux doesn't cut it and you actually need to jail a badly-behaved service, "set up a jail in this specific way and exec this process in it" should be a tool to be invoked by an init script or a unit file or whatever. unshare(1) looks like it's halfway there.
As I understand the bug, the problem is in systemd's version of the `mount --make-rslave /` step, which (for a reason unknown to me) tries to stat (as root) the mountpoint first, and if the mountpoint is on a remote FS that might fail, and systemd isn't correctly handling that.
TL;DR: systemd has bugs. Mountain out of a mole hill. Lack of debuggability? It's not like this is some threaded golang program you'll lose your mind attempting to make sense of in strace. systemd is a single-threaded C program, if you consider this as not debuggable it's your failing not systemd's. There are valid complaints to be made about systemd, but from what I've seen the crux of the problem is generally the h…
I have no idea if it has changed, as I gave up trying to get things fixed.
The one issue I still have with systemd is the way it handles the kernel's command line.
I work with Chromebooks a lot, using software that isn't ChromeOS. The cool thing is that they can use FIT images so you can load multile kernels and device tree bindings into one image. So I can use the same sdcard on the Acer tegra Chromebook, Samsung's Chromebook, as well as the ASUS Flip Chromebook. However, to boot from sdcard you have to enable developer mode. When you enable developer mode, it adds a flag to the kernel command line "debug" - systemd sees that and thinks you want systemd in debug mode (wat?) Unfortunately there is no way to override this. I've tried passing the log level as info, which sort of works, until journalctl starts, and IT parses the debug flag in the command line and ignores the flag that sets the log level to info.
No amount of explaining this helped and I (and many others who have had various issues) gave up on trying to help make systemd better.
The only workaround to this is to stop using 1 sdcard amongst all of my Chromebooks and use individual sdcards per machine that uses a u-boot built for each Chromebook that does not pass the debug flag.
I like systemd and many of it's features are helpful, but when you run into issues, it's almost always an uphill battle to fix them, even when you provide a patch.
Earlier quoted context omitted.
It's disappointing to see the top comment here condoning ad hominem attacks. But if you do believe that the identity of a speaker is more important than the arguments they make, note that the author of this blog post has a history of praising systemd (e.g. https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight ) There is no anti-systemd bias motivating this post.
>>condoning ad hominem attacks I'm not condoning ad-hominem attacks. In fact I am pointing out that often it is systemd itself that it the victim of ad-hominem attacks, which is to say that often people attack systemd, not its behaviors.
It's understandable that people don't like critique, especially delivered harshly as it so often is on The internet. But that only applies to those who worked on systemd. What I don't understand is why it seems to have fanboys.
systemd's job is to start daemons. It can be reasonable to decide dynamically when to start them based on which others are healthy (maybe you care more about speed than determinism on a laptop). But there's no reason to choose a uid and mkdir dynamically. You want these errors at install time, not at the box's next (probably unattended) restart.
Obviously there's so much inertia in the existing system that it could realistically never happen at this point, but one can dream, right?
[0] Kind of like e.g. /etc/services but with UUIDs.
Earlier quoted context omitted.
The company I work for runs Gentoo at a global scale...
Then you either make significantly more money than we do or are able to allocate resources to that project as it is key to your business strategy. The main focus of my company is to make Video games. Not maintain operating system distributions. That’s why we pay redhat so much.
One thing I like about Gentoo that no other mainstream distro has is something like this https://packages.gentoo.org/packages/net-proxy/haproxy.
That page says that you can install any version of haproxy that suits you. You don't have to upgrade/downgrade the OS just because you need an older or newer piece of software.
But, as always, no distro is perfect. Gentoo has its issues too.
Earlier quoted context omitted.
>>condoning ad hominem attacks I'm not condoning ad-hominem attacks. In fact I am pointing out that often it is systemd itself that it the victim of ad-hominem attacks, which is to say that often people attack systemd, not its behaviors.
Systemd is not a hominem - it's a piece of software. It doesn't have feelings. It's understandable that people don't like critique, especially delivered harshly as it so often is on The internet. But that only applies to those who worked on systemd. What I don't understand is why it seems to have fanboys.