Studio 8502 :verified: (@mos_8502@oldbytes.space)
oldbytes.space
Given that the Suckless guys are a pack of fascists, would it be immoral to fork the `st` terminal emulato to adapt to a new GNUStep terminal using XEmbed to make it into a controllable TerminalView class?

kinda glad I bounced off of the suckless ecosystem when I realized how much their config mechanism (C header files and a recompile cycle) fucking sucked

  • argv_minus_one@beehaw.orgEnglish
    0·
    1 year ago

    it has to be said that a lot of systemd’s features are broken if you’re operating a system without a dbus-enabled desktop manager

    Huh? Most of systemd’s features, including all in the above list, work even if you have no GUI installed at all.

    I do wish there were a good alternative that did not (via network effects) give firm control over a big portion of the Linux userland to a big corporation like IBM and its associated development practices

    I’m not seeing it. This isn’t Chromium, where it takes an army of world-class developers just to keep it up-to-date enough to be fit for its purpose. If systemd were hard-forked right now, and the new maintainer did little more than the occasional bug fix, systemd would still be useful for the foreseeable future.

    • self@awful.systemsOPEnglish
      3·
      1 year ago

      Huh? Most of systemd’s features, including all in the above list, work even if you have no GUI installed at all.

      user session features don’t work properly unless your DE sends session start/end information to systemd (and when I found this out, only gnome, kde, and enlightenment did). this breaks various systemd features in surprising ways; I found out about this when my user services wouldn’t work, but I stopped keeping track of what was broken when I realized it was all WONTFIX anyway

      If systemd were hard-forked right now, and the new maintainer did little more than the occasional bug fix, systemd would still be useful for the foreseeable future.

      historically, hard forking systemd has gone about as well as hard forking bitcoin, for very similar reasons. technologically, systemd forks tend to accumulate compatibility issues with the rest of userland very quickly due to breaking API and functionality changes in the interdependent systemd process ecosystem (and these breakages can very quickly propagate to downstream programs — a breakage in logind can be expected to be catastrophic for auth in general, for example). note too that breaking changes in the systemd API are rarely signposted in advance, which makes the job of a systemd fork and its dependent distros even harder. practically speaking, this means that a systemd fork must either excise the service ecosystem entirely (and would probably be better off just being a completely different init system at that point) or must have the wealth and support of a very large corporation behind it. this is similar to the technological means by which cryptocurrency projects maintain control: in a fork, the chain with more wealth behind it quickly becomes the longer one, and the shorter chain is extremely vulnerable to various attacks.

      socially, both cryptocurrency projects and systemd possess notably toxic communities which severely punish forks and dissent, which is also used as a mechanism by which control over the project is maintained. the upshot to this is an additional high cost to the morale and community resources of a fork, which particularly harshly punishes forks run by individuals and small teams.