Ultimately, the problem is much bigger than /etc/machine-id since there are dozens of hardware IDs on any PC that can be used by malicious telemetry to silently to uniquely identify and track you, and the only solution to this problem currently is to make sure you really trust any software you use.

Systemd, in particular, acts a lot like malware for Linux because if you try to reset your machine-id a long list of stuff that breaks in in it. You could make a cron script to reset /etc/machine-id every day, but machine-id is so deep in the stack that you’d also have to reboot to ensure it’s updated.

  • hirihit640@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    7 hours ago

    Saying Linus uses something is just appeal to authority by the way.

    I was giving Linus as an example of a member of the Linux community, and a particularly prominent one at that. There are many indicators that Fedora is well regarded, and that is just one of them.

    you either adopt them or it becomes increasingly difficult to run software on your distro.

    Arguably, systemd made it easier to run software on Linux. The standardization made it easier for devs to write software that worked across distros. Devs didn’t have to fight fragmentation in the lower levels and could focus on building platforms on top like Flatpak, which in turn led to even more software and apps available on Linux. It’s way easier to find and run software than a few years ago.

    I’m guessing what you were trying to say is that it’s harder to find and run software on Linux that doesn’t use systemd. That’s fair. Just like it’s hard to find apps nowadays that don’t use web technology, and require something like Electron or Firefox to run. But if we think of systemd as a platform (though I think it’s more complicated than that), does it go against the ideals of Linux?

    The fundamental Unix principle is having small programs that do a single thing well and that can be composed together

    First off, I know you didn’t say this but I want to just clarify: software principles are different from community ideals. Software principles are a means to an end. And they are often broken. Modular design is hard to get right. Microservices often end up messier than the monolithic approach. Ultimately it’s a balance. And strategy plays into this too. If monolithic design allows faster iteration, then even if it gets replaced with modular design later, you can use the lessons learned during those iterations to make the modular design.

    It’s possible that someday Redhat tries to weaponize systemd and it ends up holding Linux back until we can replace it. But I doubt it. If you look at the recent backlash that Fedora and Firefox has gotten for AI, you can see that the Linux community is pretty vocal and active about their ideals.

    • ☆ Yσɠƚԋσʂ ☆@lemmy.mlOP
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      7 hours ago

      I’ve already explained repeatedly how systemd goes against core Unix philosophy. Communities can form around all kinds of things, just because a community forms around bad idea that doesn’t mean it should be automatically accepted. Linux did get modular design largely right, that’s the whole problem here. Systemd throws the baby out with the bath water. Monolithic design was basically more convenient for companies trying to monetize the platform.

      Systemd has gotten plenty of backlash as well, I’m certainly not the only person who sees the problems with it. The problem is that it’ll keep getting pushed by commercial interests. And the same thing will happen with AI incidentally.

      • hirihit640@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        1
        ·
        14 minutes ago

        I was agreeing with you. Systemd breaks unix philosophy. You know what else breaks unix philosophy? The Linux kernel. It’s absolutely massive. If you want unix philosophy, switch to a microkernel.

        Also another commenter in this discussion pointed out that flatpak does not actually obfuscate machine-id. You can read the issue tracker here: https://github.com/flatpak/flatpak/issues/4311

        Basically comes down to a design decisions from 15+ years ago, in things that flatpak depends on. This is an open issue to this day. Would it have been better for flatpak to have delayed release until this was solved, possibly remaining unreleased to this day? Meanwhile everybody would have to use regular system packages, which not only have access to machine-id, but also the entire userspace, with zero sandboxing. I doubt that would be better.