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

  • 𝘋𝘪𝘳𝘬
    link
    fedilink
    English
    11
    edit-2
    10 months ago

    Nazi nonsense aside,

    when I realized how much their config mechanism (C header files and a recompile cycle) fucking sucked

    That’s the thing here: It REALLY sucks. Which sucks for a project that calls itself “suckless”.

    • @sarchar@programming.dev
      link
      fedilink
      English
      310 months ago

      I dunno. I’ll be the odd one out and say that I fuckin love it. I’m a systems programmer though, so maybe that skews my opinion.

      I use dwm and st regularly but with this new news, I’m disappointed.

  • @bitofhope@awful.systems
    cake
    link
    fedilink
    English
    610 months ago

    Gave up on st in favour of alacritty after realizing I deserve nice things like clickable links and scrolling without maintaining a dependency hell of patches.

    I think they toned down the nazi shit around the time when my tolerance for that brand of edginess began to dip towards the crust punk bartender’s level, so I’ve given them a huge benefit of doubt.

    I somehow didn’t remember them doing a mock Charlottesville, though. I’m disappointed but at this point not too surprised.

    Thankfully my desire for a community of software minimalist C curmudgeons and Unix nerds is adequately fulfilled by friends IRL whom I know for sure not to be fascist assholes.

  • raktheundead
    link
    fedilink
    310 months ago

    Just as an aside, I know it’s probably meant to be pronounced “suck-LESS”, but I think it’s funnier to pronounce it “SUCK-less”.

  • @Evinceo@awful.systems
    link
    fedilink
    English
    310 months ago

    There was some remarkably juicy drama i saw on suckless personal pages (mostly manifestos) once but hell if I can find it now.

  • @naevaTheRat@lemmy.dbzer0.com
    link
    fedilink
    English
    010 months ago

    :( sadness. I’m pathologically opposed to software complexity (I mean pathologically, it hurts me) and have a really nice rice set up with dwm.

    GNOME’s new mosaic layout project which is a few years down the pipeline looks like it might solve the problem of tiling vs teenager’s desk windows management so maybe I should switch.

    I actually do like the patching thing, prefer it to xmonad which needs recompiling every day that ends in Y or i3 which is about as fun to configure as fellating one of those tubular cheese graters.

    Taking suggestions on fast minimalist launchers and windows managers tiling ideally (and terminals with Unicode support rxvt suuuuuuuuuuucks) if anyone has them.

    • @naevaTheRat@lemmy.dbzer0.com
      link
      fedilink
      English
      010 months ago

      Or I would accept trying something a bit chubby if people have reasons to recommend it. Like sure it slows down the hellbox but it detects when your concentration is flagging and makes you a coffee type shit. Just no transparency effects, Jesus fuck I hate transparency effects. It’s like “hey want to spend more power rendering something that’s harder to parse visually?” umm no? who wants that? why would you want that?

      • @argv_minus_one@beehaw.org
        link
        fedilink
        English
        -110 months ago

        Because it looks cool. That’s seriously the only reason.

        And it does look cool, although yeah, it is also harder to parse visually, which I suppose is why CSS has a media query specifically for asking whether the user wants reduced transparency.

        As for suckless, the biggest target of their hate seems to be systemd, and there are quite a lot of reasons to recommend it. A few off the top of my head (all but one of which I have used at one point or another):

        • Faster startup/shutdown
        • More reliable shutdown (it hangs less often than the old shell-script-based shutdown procedure)
        • Being able to see at a glance which services failed to start (systemctl --failed)
        • Being able to see at a glance a service’s status including its last few log entries (systemctl status)
        • Keeping track of (systemd-cgls) and optionally cleaning up (KillUserProcesses in logind.conf) user sessions
        • User services started on boot (requires loginctl enable-linger)
        • Easy sandboxing/deprivileging of services (ProtectHome, InaccessiblePaths, SystemCallFilter, CapabilityBoundingSet, etc)
        • Service→device dependencies (Requisite=sys-subsystem-net-devices-wlan.device + WantedBy=sys-subsystem-net-devices-wlan.device = “don’t start hostapd unless the Wi-Fi dongle is plugged in, and stop it if the dongle is unplugged”)
        • Querying the logs like a database (journalctl -p warning -b -u smbd = “give me all log entries made by smbd, of warning level or higher, since the last reboot”)
        • @self@awful.systemsOP
          link
          fedilink
          English
          010 months 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 or are running in an embedded environment. that describes all my systems except my Steam Deck, where I’m thankful for the parts of its game console-like features that systemd enables, though 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

          with all that said, suckless init ain’t it. it’s an extremely simple init that reminds me of the deterministic init systems you’d usually see in something like an android phone — ideal if you need to work around broken hardware with a strict boot order, but awful for almost everything else. there are much better options for an alternative init out there, and I’d prefer to use any of them

          • @argv_minus_one@beehaw.org
            link
            fedilink
            English
            010 months 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.systemsOP
              link
              fedilink
              English
              010 months 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.

              • @argv_minus_one@beehaw.org
                link
                fedilink
                English
                -110 months ago

                user session features don’t work properly unless your DE sends session start/end information to systemd

                Which features, exactly? I just tried IceWM, which has no systemd-related dependencies and vastly predates systemd, and the session appears correctly on loginctl and disappears from there a few seconds after logging out, same as logging in and out of Plasma. Seems like it works fine.

                I did notice that loginctl lock-session doesn’t work with IceWM, and presumably neither does anything else that involves sending D-Bus messages to the process controlling the session, but that’s not the end of the world.

                this breaks various systemd features in surprising ways; I found out about this when my user services wouldn’t work

                I definitely have not observed this issue. I have loginctl enable-lingered myself, so my user services start during boot, before any desktop environment is loaded. I haven’t tested whether user services work in IceWM without that, but as far as I know, user service managers are started and stopped by logind in response to session start/stop, and logind gets notified of session start by the PAM module pam_systemd, not by the desktop environment.

                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).

                Breaking changes affecting programs outside of the systemd suite? Can you give me some concrete examples of such breaking changes and the problems they caused? I wasn’t aware there were any. I would have expected to see some serious fireworks if such a thing ever happened.

                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.

                We’re discussing a community hard fork that leaves IBM behind, like what happened with XFree86. What IBM says or does after that is irrelevant, I would think.

    • @self@awful.systemsOP
      link
      fedilink
      English
      1810 months ago

      here, I can give you some extra time to dig into the linked thread! does forever work for you?