• 0 Posts
  • 28 Comments
Joined 1 year ago
Cake day: May 31st, 2023
  • 7heo@lemmy.mltoLinux@lemmy.ml•What distro should I use on my potato?
    84·
    3 months ago

    Note: this comment is long, because it is important and the idea that “systemd is always better, no matter the situation” is absolutely dangerous for the entire FOSS ecosystem: both diversity and rationality are essential.

    Systemd can get more efficient than running hundreds of poorly integrated scripts

    In theory yes. In practice, systemd is a huge monolithic single-point-of-failure system, with several bottlenecks and reinventing-the-wheel galore. And openrc is a far cry from “hundreds of poorly integrated scripts”.

    I think it is crucial we stop having dogmatic “arguments” with argumentum ad populum or arguments of authority, or we will end up recreating a Microsoft-like environment in free software.

    Let’s stop trying to shoehorn popular solutions into ill suited use cases, just because they are used elsewhere with different limitations.

    Systemd might make sense for most people on desktop targets (CPUs with several cores, and several GB of RAM), because convenience and comfort (which systemd excels at, let’s be honest) but as we approach “embedded” targets, simpler and smaller is always better.

    And no matter how much optimisation you cram into the bigger software, it will just not perform like the simpler software, especially with limited resources.

    Now, I take OpenRC as an example here, because it is AFAIR the default in devuan, but it also supports runit, sinit, s6 and shepherd.

    And using s6, you just can’t say “systemd is flat out better in all cases”, that would be simply stupid.

  • 7heo@lemmy.mltoAnnouncements@lemmy.ml•Lemmy.ml `v0.19` upgrade issues and downtime.English
    54·
    7 months ago

    Yep, I’ve been enraged by this decision from day one. This is depressingly amateur. Let people join, let other developers make very cool apps, and then introduce a deeply breaking change in a minor version, and deploy it on the most active instance, with mere days of warning. Or “How to destroy all the progress made by Lemmy, in one small change”.

    I get it if the devs and admins of Lemmy.ml are paying too much out of their own pocket, and if they want users to literally go away, to mitigate that cost.

    But doing it in such an in such an insidious, demoralizing way, as opposed to being transparent with the costs and announcing (drastic) measures to mitigate that cost, is literally destroying most of the progress made so far, and driving most users back to reddit.

    As of today, the list of most active servers of the fediverse has only one Lemmy server (Lemmy.world), in ninth position, and that is the only Lemmy server in that list, over four pages… The Lemmy instances used to be in the middle of the first first 10 instances, with Lemmy.ml leading the way.

    Now, I guess the devs didn’t want to take those drastic measures, and tell people to they would be closing down their accounts, ordered by creation date, until the costs become bearable again. Because that would mean “admitting the Lemmy.ml experiment to show the world that people are, when given the opportunity, rising to the challenge, and putting in the effort, in true communist fashion, is actually a failure”. People aren’t ready for communism. Communism requires education, intelligence, and empathy/compassion. Our western societies are fostering the opposite traits. When we become educated, intelligent, and empathic or compassionate, it is in spite of our societies, not thanks to them.

    Now, a few people opened instances, but it wasn’t enough, and fast enough, when the “reddit migration” happened, to absorb the insane influx of users to Lemmy.ml.

    So I guess it is what it is, but it’s still sad and depressing…

  • 7heo@lemmy.mltoLinux@lemmy.ml•SystemD
    7·
    10 months ago

    None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there.

    I’m assuming you meant to say that “none of these are sacrificing portability for features”? If so, absolutely, and that’s very much a feature, not a bug. Portability matters.

    So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features.

    If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.

    Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.

    That’s a bit disingenuous. SysV Init has long term glaring, unrelated issues. It is really showing its age.

    Systemd moved the goal posts for what a Linux init system needs to do.

    On that, I very much agree. Moving the goal posts doesn’t mean “doing the right thing”, however, and this fact is a big part of the reason some people complain about it.

    I doubt any generic Unix init system can compete.

    With the feature set? Absolutely not, you are correct. But the same way, systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.

    So in the end, it is down to your personal preferences.

    Which is theoretically all fine; but practically, it stops being “all fine”, for some people, when you consider systemd’s aggressive disregard to being compatible with literally anything else.
    The systemd project is the software embodiment of the “this works and it works well, so why would you ever need anything else?!” mentality.
    People take issue with the facts that “aggressive disregard to being compatible with literally anything else” reasonably translates to “having absolutely zero room for mistakes” (which, to be clear, systemd failed to honor multiple times: it isn’t perfect, which would be fine, in a vacuum, but not with this mentality) and that “works well” varies drastically from case to case, and from expectation to expectation (in short, it does not, always, “work well” for everyone and/or in every use case).

    TL;DR: systemd existing is totally fine, systemd being used by the majority is totally fine. systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay; and systemd de-facto making itself irreplaceable on the grounds that “it’s fine, don’t worry about it”, is not okay.