OpenBSD admin and ports maintainer

  • 1 Post
  • 43 Comments
Joined 1 month ago
cake
Cake day: May 29th, 2024

help-circle
    1. Agreed, and in addition, I hate the web interface dependency for github and gitlab, and how many system resources they use (can’t even load gitlab on my pinephone without it crashing due to running out of memory!). At least gitlab can hypothetically have a minimal open source client. I’d much rather just communicate with developers through mailing lists. If hosting is hard, there are providers for lists.

    2. I think there’s nuance to this. Of course there are asshats like MongoDB that pull the rug and enshittify; but on the other hand licenses are a tool, not an ideology. If fucking over corporations involve a more restrictive non-commercial license that isn’t open source, that’s a good thing in my eyes. It depends on the software being written and how it’s being used.

    3. Fuck Discord, all my homies hate Discord; use IRC/XMPP/SMTP/Matrix instead.

    4. I’m not gatekeeping anything, I only care if your patches for my ports are good.

    5. FSF feels like a cult, they care more about the purity of foss than its practical effects on the world; and their specific implementation of foss (copyleft). This goes back to licensing and how there’s more nuance in licensing than if it’s open source or not.



  • And neither Arch, nor Ubuntu, nor Debian, nor OpenSUSE, nor any other distro using systemd belongs to IBM.

    Where did I say they belong to IBM?

    Sure, the centralization is pretty damn bad. But for example replacing sudo is needed.

    We already have doas, which is such a simple codebase I’d have a hard time imagining it contains a bug that leads to setuid being a problem. run0’s codebase size on the other hand…









  • It’s as easy as following any set of instructions. Whether or not you actually understand what the instructions are doing is an entirely different story. If you actually want to learn how to operate a posix system, doing a bunch of command line installs of Linux isn’t going to help you with that. What will help is living in something with excellent documentation like OpenBSD, with minimal reliance on external tooling. Once you have the skills, they’ll transfer anywhere.







  • Just make the file root owned and readable by no one. An unreadable file can’t be copied. You can use chattr to add some flags like immutability if you desire (shouldn’t really need to). Use a command like find /some/path -type f -exec chattr whatever {} \; if you need to do this recursively. Root account should need a password, and should (hopefully) not be accessable with an unprivileged user’s password through sudo/doas, but on its own account with it’s own password using su or login.

    Note that without encrypting the file, this does not protect you from someone just grabbing your storage device and mounting it with root permissions and then they can do whatever they want with your data. It also doesn’t protect you if someone gets root access to your device through other remote means. If you want to encrypt the file, use something like openssl some-cipher -k 'your password' -in file -out file.cipher_ext. If you want to encrypt multiple files, put them in a tarball and encrypt the tarball. You can again also use find with openssl to encrypt/decrypt recursively if you don’t want to use a tarball, which may be better with ciphers like blowfish that aren’t secure at large file sizes; but if you do that, you expose your encrypted file system structure to attackers.

    I am not a fan of full disk encryption, because it usually means leaving all your data decrypted during runtime with how most people use it. If you only decrypt a block device when you need to, there’s nothing wrong with that, and can work as an alternative to encrypting a tarball.