Badabinski

Relevant XKCD.

Open source can be enshittified. FOSS with many contributors should be basically proof against being fucked with.

CAD was a big problem for me as well. I’ve been happy enough with OnShape (coming from Autodesk Inventor), but the extreme SaaS nature of it makes me worry.

I’m not using it because it would be extremely inconvenient for me, but I think that the English language deserves to have the thorn returned to it.

Where would be manually modifying modules.dep and map files on this, I wonder?

Anubis has worked if that’s happening. The point is to make it computationally expensive to access a webpage, because that’s a natural rate limiter. It kinda sounds like it needs to be made more computationally expensive, however.

Do you have any sources for the 10x memory thing? I’ve seen people who have made memory usage claims, but I haven’t seen benchmarks demonstrating this.

EDIT: glibc-based images wouldn’t be using service managers either. PID 1 is your application.

EDIT: In response to this:

There’s a reason a huge portion of docker images are alpine-based.

After months of research, my company pushed thousands and thousands of containers away from alpine for operational and performance reasons. You can get small images using glibc-based distros. Just look at chainguard if you want an example. We saved money (many many dollars a month) and had fewer tickets once we finished banning alpine containers. I haven’t seen a compelling reason to switch back, and I just don’t see much to recommend Alpine outside of embedded systems where disk space is actually a problem. I’m not going to tell you that you’re wrong for using it, but my experience has basically been a series of events telling me to avoid it. Also, I fucking hate the person that decided it wasn’t going to do search domains properly or DNS over TCP.

Debian is superior for server tasks. musl is designed to optimize for smaller binaries on disk. Memory is a secondary goal, and cpu time is a non-goal. musl isn’t meant to be fast, it’s meant to be small and easily embedded. Those are great things if you need to run in a network/disk constrained environment, but for a server? Why waste CPU cycles using a libc that is, by design, less time efficient?

EDIT: I had to fight this fight at my job. We had hundreds of thousands of Alpine containers running, and switching them to glibc-based containers resulted in quantifiable cloud spend savings. I’m not saying musl (or alpine) is bad, just that you have horses for courses.

Is it? I thought the thing that musl optimized for was disk usage, not memory usage or CPU time. It’s been my experience that alpine containers are worse than their glibc counterparts because glibc is damn good. It’s definitely faster in many cases. I think this is fixed now, but I remember when musl made the python interpreter run like 50-100x slower.

EDIT: musl is good at what it tries to be good at. It’s not trying to be the fastest, it’s trying to be small on disk or over the network.

I learned to program by shitting out God awful shell scripts that got gently thrashed by senior devs. The only way I’ve ever learned anything is by having a real-world problem that I can solve. You absolutely do NOT need a CS degree to learn software dev or even some of compsci itself, and I agree that tools like Bolt are going to make shit harder. It’s one thing to copy stack overflow code because you have people arguing about it in the comments. You get to hear the pros and cons and it can eventually make sense. It’s something entirely different when an LLM shits out code that it can’t even accurately describe later.

B-b-but TempleOS isn’t Linux!

There’s also ZZ 👉😎👉 Same caveats apply, smash that fukken esc key (for bonus points rebind caps lock as esc) then ZZ Top your way out of that shit.

This beautiful series of images and the corresponding text from old reddit. Folks, I present kinder surprise sorry. Old reddit was a fun place sometimes.

God, can we not though? Haha funni meme and all, but like, I’m so tired of seeing this shit. It sucks for the women in the community, and honestly it sucks for the men too. It’s just such boomer humor.

Eh, I’m fine with man pages. I looked at tldr before, but I’ve been using the command line for many things almost exclusively for like 10+ years now. I usually just need the reference details.

Manpages are great though? They’re not the best if you need examples, but as a reference for the behavior of flags? I love’em.

I genuinely use vim inside of termux on a daily basis. I dunno if I’m sick in the head or what, but I kinda like vim on my phone.

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.

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.

Yep. Bash was my first programming language so I have absolutely stepped on every single one of those goddamn pedblasters. I love it, but I also hate it, and I am still drawn to using it.