mattpallissard

I agree most of it doesn't, especially if it's about current events or captures the feeling of the era.

My Cousin Vinnie is an example that holds up still. No current events, no racist jokes, just typical social interactions that are still relevant.

> It’s like a world inside one’s head with a text-based interface.

I had a co-worker describe it as a giant Linux playground.

Another as ETL nirvana.

Every job on an HPC cluster should have a memory and CPU limit. Nearly every job should have a time limit as well. I/O throttling is a much trickier problem.

I wound up having a script for users on a jump host that would submit an sbatch job that ran sshd as the user on a random high level port and stored the port in the output. The output was available over NFS so the script parsed the port number and displayed the connection info to the user.

The user could then run a vscode server over ssh within the bounds of CPU/memory/time limits.

The functional code isn't reassigning the same variable. The and/or have something that looks like an implicit return.

I have 5 and can say that this is the way.

> many of us kind of hate it and only stay because of the money, and would work anywhere else if the other jobs paid well enough.

I think you just described most people who aren't SE's. The only difference is that they can't land better paying jobs.

Arch user here. These things work much nicer than any of the previous alternatives. Sure, kernel signing is a bit of a mess, but that's more of a product of how key-signing at a low-level works than anything. Cryptsetup, cryptenroll, unified kernel images, and systemd-boot worked for me out of box.

> Frontend is a mess because all you people are a mess.

As a backend guy who considers himself extremely fortunate that nearly all of his users/customers are technical, this got an audible chuckle out of me.

> There is no "syntax", it's all just key=value pairs,

This, with the sections, is INI. Duplicate keys included. Loosely defined spec, but INI none the less

> I don't know why you'd be parsing unit files or serializing something else to unit files. Just drop them into place

It's common to store information in a DB, or some other format that is easy to merge/override programmatically. Even configuration management tools like puppet, salt, ansible do this with JSON/YAML

> If systemd is the reason, there are several good distros without systemd

I totally get avoiding systemd, I don't myself, but I get it. The author on the other hand talks about the problems doing this in a professional setting. This I do not get. As far as management of large fleets of servers goes, systemd is quite nice. Yeah, it's odd for some things but as far as automation is concerned it's the way to go.

With systemd the same file syntax and management works for services, timers, mount points, networking, name resolution, lightweight containers, virtual machines. You literally have to write one parser and serialize to ini. Then you get distribution generic management. Upgrades? No problem? Moving to CentOS to Debian? Ubuntu? arch? Whatever? No problem. It. Just. Works.

Yeah, if you're in the know you can do better for specific circumstances, but in this day and age OS's are throw away and automation you don't have to refactor is paramount. For professional work, this flame war is over.

> Other potential tells include long pauses and inconsistencies on candidates’ resumes, such as claimed expertise in technologies before they were developed and widely available.

Funny, I've seen a fair number of job postings that require this exact thing

Same boat as the author here, except I switched from physics to software after year three.

I had never heard of them until I was _years_ into software engineering. I think this is more common than you may think. I had never dealt with linear algebra in a formal setting, despite leveraging a lot of the concepts, until then.

I think this is the case. Most of my family and friends use and like the various AI features that are popping up but aren't interested thinking about how to coax what they want out of ChatGPT or Claude.

When it's integrated into a product people are more likely to use it. Lowering the barrier to entry so to speak.

That's not the same type of bot net. Fail 2 ban simply is not going to work when you have a popular unauthenticated endpoint. You have hundreds of thousands of rps spread across thousands of legitimate networks that. The requests are always modified to look legitimate in a never ending game of whack-a-mole.

You wind up having to use things like tls fingerprinting with other heuristics to identify what to traffic to reject. These all take engineering hours and require infrastructure. It is SO MUCH SIMPLER to require auth and reject everything else outright.

I know that the BigCo's want to track us and you originally mentioned tracking not auth. But my point is yeah, they have malicious reasons for locking things down, but there are legitimate reasons too.