SirNuke

Mostly just as a wrapper for Docker. The main issue I've run into is Docker's union file system functionality doesn't work when backed by ZFS, so disk usage can balloon out of control. I wouldn't use this in production but don't tell me how to live my life mom.

Beyond various Docker stacks I also have a Certbot container that uses Snap (sigh), and Hashicorp Vault container which runs as a vanilla SystemD service. I run Wireguard as part of my OPNSense VM. That's something I would run in a VM since it's exposed to the internet. I have an older MinIO and Concourse CI Docker Compose config that I'd love to run in LXC but I suspect that isn't realistic.

Note on Vault, I haven't been able to get mlock to work (used to prevent sensitive memory from being swapped). By all accounts it should just work in LXC, but since it isn't and there's no swap on the host I just turned it off. I may migrate Vault to a VM at some point.

I'm personally just interested in lightweight environments with good enough isolation and don't break all the time over nothing. Docker mostly accomplishes that for me. LXC + Docker also mostly accomplishes that.

(My heart yearns for FreeBSD Jails but with decent tooling)

I originally excited by Podman, but ultimately migrated away from it. Friendship ended with Ubuntu and Docker -> CentOS and Podman -> Proxmox + Debian LXC (which has its own irritations but anyway). Off the top of my head:

• Can't attach a containers to multiple networks. Most of my Docker Compose stacks have an Nginx reverse proxy and a network for each service.
• But you can use pods. However since they share the same network interface if you have multiple legacy services that both insist on, say, port 80 they can't be in the same pod. They also don't isolate services, nor can you assert a specific pod is the one listening on a forwarded port.
• Pods also have DNS issues with Nginx. It kept crashing since it couldn't resolve the hostnames of the other containers in the pod, even if they were already running. If you launch a shell inside an Nginx container the other container hostnames resolve fine. I suspect the problem is the container is launched before its behind-the-scenes DNS infrastructure is ready.
• Podman lets you use secrets on normal containers (yay) but if the secret changes you have to recreate the container. Amazing synergy with rotating TLS certificates.
• Endless issues with SELinux and bind mounts. My Nginx container kept crashing because SELinux didn't like the TLS certificate bind mount. This is where I reflected on the endless parade of random issues that I had no interest in solving and finally threw in the towel.

I brought all this up in another community and was told the problem was [paraphrased] "people keep trying to use Podman like they use Docker" - whatever that means. I do like a number of design choices in it, like including the command used to create containers in the metadata, and how it's easy to integrate into SystemD for things like scheduled updates.

Cockpit is pretty slick though, need to install it on my bare metal Debian host.

Honestly, I'd be more curious what topics where the media does nail the nuances of. Are there any at all?

Could be. Anonymize your resume and post it on programming.dev's cscareerquestions or something if you want someone to review it. Assuming you are US based, the market is still cool so you might have to keep treading water or find something that just keeps the lights on for now.

However, I would never assume things make any sense on the hiring side. There's a lot of bad recruiters but there are even more bad hiring managers. Years ago as I sat on the other side of the table for the first time for a presentation and Q&A for intern candidates. When I followed up asking if any had been any offers, I was told none of them performed well enough but it was okay because turns out there wasn't room in the budget for an intern anyway. What a colossal waste of everyone's time.

I'm a similar boat. Diagnosed with ADHD recently but later in life, and it's likely why I never settled into a single domain. I consider myself a strong software engineer but tend to fall apart in interviews, particularly with unstructured things like being asked to "tell me about yourself." I am also planning a shift into a management role.

My main regret in life is spending a lot of time trying to apply advice that seemed reasonable and how Other People did things. Only adopt things that work for you.

• I highly recommend at least trying stimulants. I inadvertently self medicated with caffeine for years, which might work in a pinch. My secret sauce is frankly 90% Concerta and 10% behavior modification things like carrying a notebook around.

• I would not mention that you have ADHD to interviewers since you can't count on anyone to properly understand it. Showing weakness is just blood in the water. Hopefully this won't be an issue for future generations. Yes, I am extremely bitter about this.

• Approach this as doing whatever you have to do to get yourself over the finish line, and know that trying harder at a failed strategy never works. Don't limit yourself to how things are supposed to be done.

• Security requires a flexible mindset and attracts square pegs. Data centers are where all the real weirdos hang out so devops might be worth considering. I'm confident most scientists I've worked with have ADHD, and prototype R&D work is definitely more ADHD friendly.

• Insist on knowing the structure and expectations of each round of an interview. I pitch this as "I need to know how I'm being evaluated so I can properly prepare and demonstrate my abilities."

• I'll be honest: the interview process is mostly nonsense and should be treated as such. Anything that puts a thumb on the scale in your favor is fair game, short of unethical behavior like lying. Telling people what they want to hear is a great way to counter dumb questions.

• I've built up an Obsidian 'database' of bullets to help during interviews, including a prepared statement of why I have it and need to have it available.

  • "Tell me about yourself", "what type of role are you looking for", "why do you want to shift into management" open ended questions. The key thing is respond in a coherent, organized way without showing any negativity or weakness. Yes this is ridiculous, but it's how it is.

    • Turn your generalist background into the strength it is. I use: software engineering is a problem solving role, everything else is a means to that end. Solving problems is what I do; I've done so in a wide range of fields and domains and always drive them to completion. What I'm looking for is a great team to join, which is independent of industry or tech stack.

  • "Tell me about a time" behavior questions. I like the STAR format. I do well on these but need an outline to work with. Make sure it's polished into a coherent narrative. Put an emphasis on what you did, but also how you enabled your team. Numerical data points are great if you have them

    • If the company posts their values or principles then that's likely want they want to see out of these. Match your scenarios to the values beforehand. The idea is previous behaviors indicate future ones.

  • System design questions. I have my own checklist of questions I go through since I don't like the popular format. I expect this is where you shine, maybe just need a bit of scaffolding to help organize your thoughts.

  • Leetcode programming tests. Like it or not, it's part of the game.

• If you are serious about going into management, you'll need a prepared philosophy of how you see the role and will approach it.

  • This is also a great question to ask hiring managers. The best indicator of what the job will actually be like and you can't wiggle out without raising red flags.
  • The two books I like are The Manager's Path by Camille Fournier and the classic First, Break All the Rules by the Gallop folks. Again, not all advice is good so only take away what you think will work for you. Worth reading if only to understand what you should expect out of a manager.
  • Do not make the mistake of feeling like you need to go into a people management position. Shifting into project management is perfectly fine. Topping out at a senior or staff software engineer role is also perfectly fine. Frankly, topping out at a mid level engineer is fine, just watch out for ageism.

• I also have check lists for all sorts of random things. Even dumb things like how to respond to a question I didn't prepare for: repeat the question, write it down, jot down what I think they want to hear, write down points, and give them an order.

I disagree with that as a rule of thumb. I'll take writing 1000 lines of code from scratch every time over deciphering 1000 lines of bad code.

However, I do you think are right if limited to the ~100ish lines that fit into an hour sized block of interview time. I suspect the other half of the answer is (good) job postings have largely gotten away from hard language requirements. It's perfectly reasonable to hire someone that will need to familiarize themselves with Go or Python or Typescript or whatever. It's not fair to expect someone to analyze code in a language they haven't used on the spot.

I see them as a flawed indicator of the ceiling of someone's theoretical computer science abilities. Having worked with some brilliant people that career shifted via bootcamps, I will contend there's value in having that foundation. I also prefer Leetcode problems over having to memorize search algorithms. But yeah, it's not very reflective of day to day tasks even in R&D heavy projects. The most algorithm heavy thing I've ever done was implement Ramer–Douglas–Peucker to convert points from mouse polling into a simplified line.

(There's clearly a "it's what everyone else is doing" aspect to Leetcode, on top of being very practical to run, hence I why don't see them going anywhere. They're also as objective as anything in an interview will ever be, so as I always say: it can be so much worse.)

I intend to make the hacker "dive into an icky codebase armed with a stack trace and fix a bug" aspect of software development a part of my interview process; plus lean more heavily on system design questions which is where non-entry level engineers really ought to shine. The parts that worry me are the ability to create new tests as they inevitably leak, plus whether I can truly objectively evaluate someone's performance.

I'm curious what you include and how well it works.

Yeah, they kinda suck and they are brutal to go into cold. Having to grind a bunch of leetcode problems is a burden, particularly if you currently have a job and god forbid a family.

I would still take them over the puzzle questions that used to be popular, or the personality test nonsense that dominates most fields. At least Leetcode problems are reasonably reflective of programming skill. I'll also take them over vague open ended questions - ain't nothing more fun than trying to ramble my way into whatever answer the interviewer is secretly looking for.

Personally, when the day comes when I'm In Charge, I plan on experimenting with more day to day type evaluations. I think there's potential for things like performing a mock code review or having someone plan out a sprint based on a very detailed design document. "Here's an icky piece of code, tell me what it does and what you would do to improve it" seems to have fallen out of style, though it's not clear to me why.

That said, like it or not it's how the game is played and not changing anytime soon. Get on the Grind75 train, or don't and keep failing tech screens.

If he's someone that's normally good at being funny - that is good at finding humorous observations and wording things that get people to laugh - then I'd say he's messing with you.

I would mess with him right back by acting like I'm very seriously trying to understanding the joke and ask increasingly dumb questions until he realizes that yes, I knew exactly what he was doing. Or a knowing smirk if that's too much.

(Yes this comment is very revealing about my childhood)

This might not be what your friend is going for, but I smirked slightly and this is how I interpret it:

I particularly like jokes that take something absurd and launder it through the structure of things that do make sense. Everything in your friend's joke is factually true. It's structured as a logically consistent argument.

And yet it is completely nonsensical. No one has ever thought that windows make something move. It invoked a slightly confused response in me, which is why I found it funny.

It's not a great joke, but I might tell it to feel out someone's sense of humor plus whether they pick up on that I'm doing so. I think the analogy to Windows makes it a weaker joke, but I would give that as an explanation just to mess with someone a little.

I'm going to assert a few things up front:

• A company that is struggling to keep its head above water should not be paying 2.5 billion to shareholders. The mechanism - dividends or buybacks - is not the problem.
• There's a hidden assumption in your first statement. Just because dividends have always existed does not mean they necessary or optimal. I actually don't have an answer to that, only that it is an assumption worth challenging.
• I'm typing this on an M2 Macbook Air. It is an incredible technical achievement, and creating it provides real tangible value to society in its own small way that wouldn't have existed without Apple. Apple is not struggling.
• However, Apple has 164,000 Apple Store employees. Apple Stores are part of Apple's successful business strategy, and the retail employees are by extension part of Apple's success. How many of them are paid enough to make their jobs a career? That 14 billion comes out to ~$85k per Apple Store employee.
• 401(k)s are a terrible way to do retirement, and I say this as someone who has a shot at retiring. Crumbs being chucked at me doesn't change my stance. The stories of people who ran out from nursing home stints or medical bills or whatever are just starting to trickle out.

Since you are reading a lot into my comment I'm going to read a lot into yours. Why are things different now? The rules of the (United States) game changed, and checks against this behavior have been nullified. Value creation is a means to an end: acquire as much power as possible, and flex that to siphon value off for your shareholders.

That's what Unity is doing. They are flexing their power to extract value from its customers. If you use Unity, what are you going to do? Unreal is a different beast with a different target audience. Godot is untested, and I don't blame anyone that hesitates hitching themselves to a noncommercial open source project. Porting a game to a different engine may not even be realistic anyway.

So everyone will stomp their feet and complain and mostly keep on using Unity. Some day they'll push too hard and that'll be the end of them, but what do the shareholders care? They got paid. Onto the next one.

The 11 million is irritating given how it's more than most will make in a lifetime being paid to someone who is incompetent. The 2.5 billion is why Unity is forced to resort to destructive behaviors to stay afloat. The incentives for companies to act this, and lack of checks against it, are why the economy is broken.

From a quick search, John Riccitiello received about 11 million in total compensation in 2022. In comparison:

During the fourth quarter of 2022, we bought 42.7 million shares back at an average price of $35.10 per share. With this buyback, we returned $1.5 billion to shareholders as part of our $2.5 billion share buyback program.

We need to call buybacks what they are: a method of siphoning value from where it was created and is useful and into the hands of the already wealthy.