Just some Internet guy

He/him/them 🏳️‍🌈

  • 0 Posts
  • 156 Comments
Joined 1 year ago
cake
Cake day: June 25th, 2023

help-circle

  • What distro I’m using isn’t that helpful of a question because it’s largely a matter of taste and technical needs. I use Arch in large part because I do some rather exotic things that would be harder to set up on most mainstream distros whereas Arch just gives me a completely blank slate to work with and configure my system the exact way I want it to work. My desktop also has some server duties, it runs VMs, it has multiple GPUs and also drives my TV room independently of my main workstation area.

    I usually recommend whichever distro gets you the closest to having everything the way you like out of the box as a starting point just because it’s less frustrating when most things works out of the box. The Arch experience is nothing works out of the box because it doesn’t even come with a box. Arch isn’t necessarily a bad choice even for beginners, but the learning curve is much steeper as a result and some people do like to just learn everything whereas some others prefer to start with the shallow part of the pool rather than diving it headfirst. It’s not like you have to commit to any distribution forever, you can start with something simple to use, learn your way around Linux and then you can upgrade to another distribution as your needs and wants evolves.








  • I think it can also get weird when you call other makefiles, like if you go make -j64 at the top level and that thing goes on to call make on subprojects, that can be a looooot of threads of that -j gets passed down. So even on that 64 core machine, now you have possibly 4096 jobs going, and it surfaces bugs that might not have been a problem when we had 2-4 cores (oh no, make is running 16 jobs at once, the horror).


  • I have none of that on my phone, just plain old keyboard.

    But the reason it’s everywhere is it’s the new hot thing and every company in the world feels like they have to get on board now or they’ll be potentially left behind, can’t let anyone have a headstart. It’s incredibly dumb and shortsighted but since actually innovating in features is hard and AI is cheap to implement, that’s what every company goes for.





  • If you want FRP, why not just install FRP? It even has a LuCI app to control it from what it looks like.

    OpenWRT page showing the availability of FRP as an app

    NGINX is also available at a mere 1kb in size for the slim version, full version also available as well as HAproxy. Those will have you more than covered, and support SSL.

    Looks like there’s also acme.sh support, with a matching LuCI app that can handle your SSL certificate situation as well.


  • The concern for the specific disk technology is usually around the use case. For example, surveillance drives you expect to be able to continuously write to 24/7 but not at crazy high speeds, maybe you can expect slow seek times or whatever. Gaming drives I would assume are disposable and just good value for storage size as you can just redownload your steam games. A NAS drive will be a little bit more expensive because it’s assumed to be for backups and data storage.

    That said in all cases if you use them with proper redundancy like RAIDZ or RAID1 (bleh) it’s kind of whatever, you just replace them as they die. They’ll all do the same, just not with quite the same performance profile.

    Things you can check are seek times / latency, throughput both on sequential and random access, and estimated lifespan.

    I keep hearing good things about decomissioned HGST enterprise drives on eBay, they’re really cheap.



  • It could be a disk slowly failing but not throwing errors yet. Some drives really do their best to hide that they’re failing. So even a passing SMART test I would take with some salt.

    I would start by making sure you have good recent backups ASAP.

    You can test the drive performance by shutting down all VMs and using tools like fio to do some disk benchmarking. It could be a VM causing it. If it’s an HDD in particular, the random reads and writes from VMs can really cause seek latency to shoot way up. Could be as simple as a service logging some warnings due to junk incoming traffic, or an update that added some more info logs, etc.


  • There’s always the command escape hatch. Ultimately the roles you’ll use will probably do the same. Even a plugin would do the same, all the ZFS tooling eventually shells to the zfs/zpool, probably same with btrfs. Those are just very complex filesystems, it would be unreliable to reimplement them in Python.

    We use tools to solve problems, not make it harder for no reason. That’s why command/shell actions exist: sometimes it’s just better to go that way.

    You can always make your own plugin for it, but you’re still just writing extra code to eventually still shell out into the commands and parse their output.



  • Very minimal. Mostly just run updates every now and then and fix what breaks which is relatively rare. The Docker stacks in particular are quite painless.

    Couple websites, Lemmy, Matrix, a whole email stack, DNS, IRC bouncer, NextCloud, WireGuard, Jitsi, a Minecraft server and I believe that’s about it?

    I’m a DevOps engineer at work, managing 2k+ VMs that I can more than keep up with. I’d say it varies more with experience and how it’s set up than how much you manage. When you use Ansible and Terraform and Kubernetes, the count of servers and services isn’t really important. One, five, ten, a thousand servers, it matters very little since you just run Ansible on them and 5 minutes later it’s all up and running. I don’t use that for my own servers out of laziness but still, I set most of that stuff 10 years ago and it’s still happily humming along just fine.