Alt account of @Badabinski

Just a sweaty nerd interested in software, home automation, emotional issues, and polite discourse about all of the above.

  • 0 Posts
  • 80 Comments
Joined 8 months ago
cake
Cake day: June 9th, 2024

help-circle

  • I’ve been very pleased with my factory-seconds Framework 13 (11th gen i7, 64 gigs of RAM and 2TB storage acquired through other channels). Linux support has been basically perfect for me, although there were some kinks earlier on. The Framework 16 might work for you if you need something with a discrete GPU.

    If you want something more mainstream, ThinkPads are often great for running Linux. Not every model is perfect, so I’d recommend doing some research there. The Arch Linux wiki often has laptop specific web pages that show how well supported the laptop is. For example, here’s the page for the Framework 13.




  • I spend all day at work exploring the inside of the k8s sausage factory so I’m inured to the horrors and can fix basically anything that breaks. The way k8s handles ingress and service discovery makes it absolutely worth it to me. The fact that I can create an HTTPProxy and have external-dns automagically expose it via DNS is really nice. I never have to worry about port conflicts, and I can upgrade my shit whenever with no (or minimal) downtime, which is nice for smart home stuff. Most of what I run tends to be singleton statefulsets or single-leader deployments managed with leases, and I only do horizontal for minimal HA, not at all for perf. If something gives me more trouble running in HA than it does in singleton mode then it’s being run as a singleton.

    k8s is a complex system with priorities that diverge from what is ideal for usage at home, but it can be really nice. There are certain things that just get their own VM (Home Assistant is a big one) because they don’t containerize/k8serize well though.



  • Yeah, if strong emotions were such a liability then we probably wouldn’t have them anymore. Emotions aren’t vestigial or useless or contrary to rational discourse, they’re an integral part of what it means to be sentient and sapient, and they can be incredibly useful when doing things that are decidedly “rational.” I can tell that some code I wrote is shit because it “feels wrong” a hell of a lot faster than I can by logically reasoning it out.

    I’m hoping that quote is simply lacking context. The alternative is that the people behind the quote are just fucking insufferable.



  • I know someone with an issue kinda like this. Some childhood trauma and neglect lead to her forming limerant relationships and made it difficult for her to be platonically friendly with men that she viewed as eligible. Her fix was doing evidence-based therapies like EMDR and healing her fear of being alone/unsupported/unloved. It took her a while, but she’s much better at having platonic friendships with men now.




  • The license of a GPLv3 project can change moving forward provided all copyright holders agree to the change. The license cannot be changed for code that was already released. If the Paisa devs could get every contributor on-board, then it’s fine. Alternatively, if they forced contributors to sign a CLA (Contributor License Agreement) which signs over the copyright to Paisa (most CLAs include copyright transfer), then that’s basically free rein to rug pull shit whenever they feel like it.

    Fuck CLAs by the way. Try to avoid contributing to projects on your free time that force you to sign one. If you’re contributing on behalf of a company, it’s likely that your legal team will take umbrage at you signing a CLA, but it’s not like you’ll own the copyright to your work anyways, so it’s less of an issue there.

    Support projects that have you sign a DCO (Developer Certificate of Origin). The DCO protects the company or individual running the project without forcing developers to give up their rights.




  • Oof, I didn’t know that about firejail. I’d heard of it, but I’d never used it. Like, c’mon folks! If you need privilege escalation, either require launching as root (if appropriate), or delegate the responsibility to a small, well-audited tool designed explicitly for the purpose and spawn a new privileged pid. Don’t use SUID. You will fuck it up. If you reach the point where setuid is your only option, then you’ve hopefully learned enough to rearchitect to not need it, or to give up, or use it if you’re, say, someone who maintains a libc or something.

    EDIT: this is overly dramatic, but also it’s not. I personally feel like using SUID is kinda like rolling your own crypto in terms of required competence.


  • This is why I made the reference to Go. I honestly hate Go, I think exceptions are great and very ergonomic and I wish that language had not become so popular. However, a whole shitload of people apparently disagree, hence the popularity of Go and the acceptance of its (imo) terrible error handling. If developers don’t have a problem with it in Go, I don’t see why they’d have a problem with it in Bash. The error handling is identical to what I posted and the syntax is shockingly similar. You must unpack the return of a func in Go if you’re going to assign, but you’re totally free to just assign an err to _ in Go and be on your way, just like you can ignore errors in Bash. The objectively correct way to write Go is to handle every err that gets returned to you, either by doing something, or passing it up the stack (and possibly wrapping it). It’s a bunch of bubbling up. My scripts end up being that way too. It’s messy, but I’ve found it to be an incredibly reliable strategy. Plus, it’s really easy for me to grep for a log message and get the exact line where I encountered an issue.

    This is all just my opinion. I think this is one of those things where the best option is to just agree to disagree. I will admit that it irritates me to see blanket statements saying “your script is bad if you don’t set -euo pipefail”, but I’d be totally fine if more people made a measured recommendation like you did. I likely will never use set -e, but if it gets the bills paid for people then that’s fine. I just think people need to be warned of the footguns.

    EDIT: my autocorrect really wanted to fuck up this comment for some reason. Apologies if I have a dumb number of typos.





  • I personally don’t believe there’s a case for it in the scripts I write, but I’ve spent years building the || die habit to the point where I don’t even think about it as I’m writing. I’ll probably edit my post to be a little less absolute, now that I’m awake and have some caffeine in me.

    One other benefit I forgot to mention to explicit error handling is that you get to actually log a useful error message. Being able to rg 'failed to scrozzle foo.* because service y was not available' and immediately find the exact line in the script that failed is so nice. It’s not quite a stack trace with line numbers, but it’s much nicer than what you have with bash by default or with set -e.