nickwitha_k (he/him)

  • 2 Posts
  • 40 Comments
Joined 2 years ago
cake
Cake day: July 16th, 2023

help-circle









  • In a world not dominated by unfettered capitalism, sure. That’s not the one that we live in however and this tool has both been built on stolen and unlicensed intellectual property as well as being used explicitly to harm people’s livelihoods while replacing their work with objectively inferior plagiaristic amalgams.

    AI companies also refuse to obey the rules of the Internet and continually DDOS sites that request crawlers and scrapers not do so, necessitating creation of whole new types of software to defend against their malicious behavior.

    And on top of all that, they have substantially increased greenhouse gas emissions and are actively consuming potable water in a manner that makes Nestlé execs hard. Putting the planet’s biosphere at greater risk and unnecessarily increasing water scarcity.

    Nah. Simping for AI companies is the irrational take. The value that they provide to humanity is, outside of some niche use cases, marginal at best and will likely never come close to making up for the harms that they are causing to humanity for a quick buck and to increase worker oppression.





  • Why don’t distros support listing packages and system settings in text file(s)?

    Short answer: Because it would be bad software design.

    More detailed answer: I can definitely understand the feeling but a large part of it is that text files are not databases. Trying to use them for that purpose leads to quickly running into a brick wall of scalability problems. Seriously, that wall is hit faster than one might expect.

    Why use a db in the first place? Well, when a package manager installs a package, it does a lot more than install files in their specified paths and store the name. Every package also has a ton of metadata. This includes everything from the software version number and versions that it obsoletes to repo that the package is from to signatures to verify package authenticity and checksums to verify file integrity.

    Storing all of this info is the sort of thing that databases excell at and text flatfiles are terrible at. The db also includes integrity checks for itself. Since the data is already stored in a db, also storing even a subset in a flatfile would be poor software design as it is unnecessarily wasting storage space in a manner that would perform significantly worse and is much more prone to data integrity failures.

    So, how do you work around that for backup? Just script a dump of the installed packages from the package manager. It’s trivial with apt and dnf/yum. Then, store it with dot files in your backups.

    To restore, I’d recommend Ansible because it works nicely with lists of packages and has minimal dependencies.

    If you don’t want to interact with the package manager and like domain specific languages (or don’t dislike the syntax), just use Nix and be done with it. Noone whose opinion matters is going to bully you for the choice. If, like me, you strongly dislike DSLs and the Nix syntax, the choices are pretty much Fedora Atomic, GUIX, and/or Ansible.






  • I’ve done a lot of SysAdmin and DCOps stuff in the past so, thought I’d give you some plausible suggestions (haven’t dug deep into Lemmy DB stuff and DNS/Federation of the stack, so not sure all is practical).

    Scenario 1 - Preserve and merge when access is restored

    Setup

    • Spin up two VMs/VPS (or one that has enough grunt for two Lemmy servers). Call them robak.slrpnk.net and slrpnk.net and point DNS appropriately.
    • Pull federated content from other instances and place it on robak, set as read-only.
    • Sync important comms to (new) slrpnk.net without content.
    • Allow users to sign up, vetting as possible (all mods). Keep a list of those that are vetted (call it vetted.list). Inform all users that any non-vetted users will have their content dropped when access is restored.

    Merge!

    • Once access is restored, ensure that (old) slrpnk.net is set to read-only.
    • Schedule a maintenance window (announce more time than you are likely to need).
    • During the maintenance window, put (new) slrpnk.net into R/O, or just block external access.
    • Query the db on (old) slrpnk.net for all users.
    • Subtract the vetted users from vetted.list from the list.
    • Drop all records from the resulting list of non-vetted users from (new) slrpnk.net.
    • Insert the records from vetted and new users (those without conflicts) into the DB on (old) slrpnk.net.
    • Validate that everything is working
    • Cut over DNS and spin down the new VMs/VPS.

    Scenario 2 - Server is in DC or Admin able to facilitate access

    • Get a db dump/backup.
    • Spin up temporary slrpnk.net on a VM/VPS.
    • Use backup of temporary server to restore data to original, when possible.