You might want to harden that those outbound firewall rules as another step. Did the Umami container need the ability to initiate connections? If not, that would eliminate the ability to do the outbound scans.

Also could prevent something to exfiltrate sensitive data.

Probably, because researchers/vendors/maintainers aren't going to catch everything, but you have less exposure too.

Perhaps they don't have the funds to implement that feature.

Yes, that's likely much cheaper than loading up an aircraft carrier with a bunch of Mustangs and Silverados. They're still likely bound to some sort of lowest bidder for contracts. It's also likely to be more economical than having the person find their own transport and reimbursing them.

There are some pictures of aircraft carriers loaded with civilian crew cars, but that's when the carriers home port changes, so it does the trip anyways.

It's a pretty robust logistics system. The tour lengths are 2-3 years. If your job demanded that you relocate to another continent for 3 years I think we'd all expect some relocation assistance.

True but providing a local vehicle pool might be a lot more sensible. That way vehicles are more innocuous and also meet the local requirements better. Think of the UK for example where they drive on the left. I've driven my Dutch car there and while it was possible with some stickers on the headlamps, it was a real PITA when trying to enter a parking garage because the ticket machine is on the other side.

I was so happy to read that part of the statement. A refreshing bit of common sense.

That's the reader's fault then. I see the blog post as the counter to the insane resume-building over-engineered architecture you see at a lot of non-tech companies. Oh, you need a cache for our 25-user internal web application? Let's put an front a redis cluster with elastisearch using an LLM to publish cache invalidation with Kafka.

There's also a sort of anti-everything attitude that gets boring and lazy. Redis is about the simplest thing possible to deploy. This wasn't about "a redis cluster with elastisearch using an LLM" it was just Redis.

I sometimes read this stuff like people explaining how they replaced their spoon and fork with a spork and measured only a 50% decrease in food eating performance. And have you heard of the people with a $20,000 Parisian cutlery set to eat McDonalds? I just can't understand insane fork enjoyers with their over-engineered their dining experience.

Software development has such a pro-complexity culture that, I think, we need more anti-stuff or pushback.

There is this cv-driven-development when you have to use Redis, Kafka, Mongo, Rabbit, Docker, AWS, job schelduers, Microservices, and so on.

The less dependencies my project has the better. If it is not needed why use it?

After quite a few years of being an employee (and the whole CV driven crap), I’m now in entrepreneur mode, stealth for now (that’s relatively easy, because I’m bootstrapping and funding this with my own money, no investors), and I made an executive decision to (forcibly) think many times, before adopting any “cloudy” thing.

Hardware…is cheap, and bare metal performance outweighs anything cloudy by multiples of magnitudes. If I have to invest money into something, I’d rather invest that in bare metal tooling, than paying for a managed service, that’s just a wrapper around tooling. E.g RDS, EC2, Fargate… or their equivalents across other CSPs.

I can run a Postgres cluster on bare metal, that will obliterate anything cloudy, and cost less than a 3rd if not less. Is it easy? No. But that’s where the investment comes in. A few good Infra resources can do magic, and yes, I hope to be large enough that these labor costs will be way less than a cloud bill.

The author does acknowledge that in the "How it Should Be" section.

It took me a while to realize that there is no getting ahead. Something else is always waiting, so better for my health to prioritize and make those whose job it is to prioritize actually make the hard decisions they're paid to make.

There is always more to do, sure. But I’ve found there is value to being ahead of expectations.

In my experience, no one is willing to make decisions on what is actually a priority.

To channel Peter from Office Space, my only real motivation is to not be hassled.

I think that your motivation is going to burn you out.

In order not to burn out one has to start prioritizing other things higher than work, like your health or your hobbies. That means thinking: "someone wants this done and will hassle me for it, but I'm letting it go now."

Edit/addition: there will always be more things to be hassled about.

That's what I've always seen done with git or Perforce. The initial set of all likely IDE-related files is known (just talk to the people you work with...), so you just add all of them to the ignore list (of whatever kind) and off you go. Then over time, additional entries might get added, as new platforms become supported and/or new team members join who use other IDEs. And the easiest thing is to add them to the list, because if one person is using this or that tool then there's a fair chance that somebody else will be using it in future too.

One way of thinking about this is to note that there are an awful lot of these tools, and so each person should look after their own shit rather than fucking it up for everybody else. Another is to note that the number of these tools is finite, and team members won't be using all of them, and so over time the centralized ignore file will tend towards a useful degree of completeness.