I take my shitposts very seriously.

  • 14 Posts
  • 1.46K Comments
Joined 3 years ago
cake
Cake day: June 24th, 2023

help-circle


  • Off the top of my head, in no particular order:

    • Systemd and its components are responsible for too many essential system functions. Init, services, mounts, timers, logging, network config, hostname, DNS resolution, locale, devices, home directories, boot, NTP sync, and I’m sure there are others, can be handled by systemd or one of its components.
    • Systemd violates the UNIX philosophy of “do one thing and do it well”. Systemd is a complex solution to a complex problem: this thread has several comments by a former Arch Linux maintainer that explains why they’ve switched to systemd, and why the earlier method of using single initscripts was unsustainable.
    • It is owned and maintained by Red Hat, known for its many controversies.
    • Some people just don’t like modern things and think that the Linux ecosystem peaked in the 1980s.

    Most (though not all) of the popular complaints are completely unreasonable. Those people usually see themselves as moral and righteous and expect the world at large to follow their personal creed. I especially consider the UNIX philosophy to be outdated, and strict adherence to it to be an obstacle for modern apps and systems.

    I have some issues with systemd, and I don’t like that one for-profit company has such a massive influence over the entire Linux ecosystem, but I have to acknowledge that it works, it works well enough to counter my personal issues, and that the people whose opinion matters the most (specifically Debian and Arch maintainers) chose it for a good reason.







  • rtxn@lemmy.worldMtolinuxmemes@lemmy.worldaccurate
    link
    fedilink
    arrow-up
    15
    ·
    edit-2
    4 days ago

    Because someone in the 1970s-80s (who is smarter than we are) decided that single-user mode files should be located in the root and multi-user files should be located in /usr. Somebody else (who is also smarter than we are) decided that it was a stupid ass solution because most of those files are identical and it’s easier to just symlink them to the multi-user directories (because nobody runs single-user systems anymore) than making sure that every search path contains the correct versions of the files, while also preserving backwards compatibility with systems that expect to run in single-user mode. Some distros, like Debian, also have separate executables for unprivileged sessions (/bin and /usr/bin) and privileged sessions (i.e. root, /sbin and /usr/sbin). Other distros, like Arch, symlink all of those directories to /usr/bin to preserve compatibility with programs that refer to executables using full paths.

    But for most of us young whippersnappers, the most important reason is that it’s always been done like this, and changing it now would make a lot of developers and admins very unhappy, and lots of software very broken.

    The only thing better than perfect is standardized.








  • The problem is that syncing between devices is not implemented in KeePass itself but through an external tool (Nextcloud, Syncthing, or whatever else). The sync client will only see the ciphertext and won’t be able to tell which records have been changed, only that two different binary files have a common ancestor and are in conflict.

    The most obvious solution is to lock and close the database when it’s not in use (which is a good practice from a security perspective too), and to sync immediately when it is changed.