I feel this is a bit of a moot point from the White House. Memory-safe languages have been around for decades. I feel like the amount of C/C++ out there isn’t so much that people think having dangerous stuff around is good, but more that nobody really wants to pay to change it.

Link to the YAML spec, for the (very) brave: https://yaml.org/spec/1.2.2/

Growth might be impossible, but a steady and “boring” amount of profit should still be possible selling plain-ole-dishwashers. Yet … for some reason, we don’t see that.

God yes this bothers and fascinates me.

Instead companies throw everything into growth and we get the retarded bluetooth enabled dishwasher problem everywhere, and I’d like toknow more about why.

I think it’s alluded to in the article:

They found a way to make consumers spend more money on dishwashing. The line goes up, for one more year. But it’s not enough. It has to go up every year.

Digging deeper: why must the line go up? Pesonally I see it as a deeply emotional, human thing.

When you read those annual financial reports from big companies, they will do anything to make sure things look rosy. Bullshit terms like “negative growth” are used because “loss” or “shrink” sound bad. So what if it sounds bad?

Confidence. Trust. It’s emotional. These are deep in our psyche. It’s how governments get elected, contracts are won, and investments are made. It’s what makes us human. If that line goes down… will it go back up? What’s going to happen? Alarm bells! Uncertaintly. Anxiety. People abandon you. Money, power, influence fades. You could find yourself replaced by the up-and-coming who “show promise”.

Our social emotional species has hundreds of thousands of years (millions?) of years of this stuff hardwired into us. Trust let us cooperate beyond our own individual or family interests. Would we be human otherwise? (I found the article Behavioural Modernity interesting).

Even with (more) UX engineers, it was incredibly difficult to get any development done. When I was in this space, management and contractors were incredibly entrenched playing political games to grow teams even bigger to get more funding. There was nobody with any authority using the thing end-to-end saying “this sucks”.

I worked for a German car company for a little bit, in a team responsible for a similar system: https://www.srcbeat.com/2023/08/sbt/

Unfortunately for those who have those values, not all paid positions involve acting on those values.

Random brain dump incoming…

Most businesses pay money to solve problems so they can make more money. You can solve their problems - but not in the way that you may be thinking.

This is a generalisation that is not strictly true, but I say it to illustrate a different way of thinking: Businesses do not undertake penetration testing because they want more secure software. They do pentesting so they can stay in business in the face of compliance and bad actors.

To find a job, you want to start learning what people pay for. People pay contractors to come in and fix things, then leave again (politically easier, sometimes cheaper). People pay sotfware developers to develop features (to sell more stuff).

Start looking up job titles and see which ones interest you (DevOps, frontend dev, backend dev, embedded…). Don’t get too stuck on the titles themselves. It’s just to narrow down what kinds of business problems you find interesting.

Other random questions:

• What specific projects are you interested in?
• What types of problems do you like solving?
• Do you like digging in and finding those tricky bugs that have been bothering people for years?
• Do you like trying out new frameworks which let you think about the system differently?
• Would you rather implement a database or GUI toolbox?

Once you’re deep in the belly of the beast, you’ll find ways to exercise those values. It’s hard to know in advance what this will look like.

Ah yes! That is a great trick that kept me going doing software dev professionally.

Instead of trying to get the system I was working with to interact correctly with some shit enterprise system, I would find common protocols (or related protocols) and implement that well. Then I would discover more specifically where the shit enterprise system was behaving badly, and point to something politically neutral (like an IETF RFC) to help get us out of a rut.

It made debugging so much easier. Those specifications and open-source implementations have had much more engineering talent put in them than what I was usually dealing with.

Definitely depends, yeah. bash is a huge piece of software that - for me - feels a bit out of place in other systems closer to original unix. Interesting ones are rc and even plain old /bin/sh provided by something like busybox.

We can’t go back to the old way of doing things but we can’t keep maintaining these fundamentally flawed systems either.

That’s a great way of putting it, thanks. I’m actually only 30 years old (lol). Sometimes I feel there’s so few people who’ve ever used or written software at this level in the part of the industry I find myself in. It seems more common to throw money at Amazon, Microsoft, and more staff.

I’ve replaced big Java systems with small Go programs and rescued stalled projects trying to adopt Kubernetes. My fave was a failed attempt to adopt k8s for fault tolerance when all that was going on was an inability to code around TCP resets (concurrent programming helped here). That team wasn’t “unskilled”; they were just normal people being crushed by complexity. I could help because they just weren’t familiar with the kind of problem solving I was, nor what tooling is available without installing extra stuff and dependencies.

Thanks for your understanding :)

You just said that this software was much more complex than Unix tools

Probably need to keep in mind incidental versus essential complexity here.

So with all those configuration options, why is the standalone binary expected to have defaults that may sound same on one system but insane in a different one?

Because this is how much of what we use already is implemented. Significant effort goes in to portability, interoperability and balancing compromises. When I’m doing software development e.g. writing HTTP APIs (of which I apparently know nothing about ;) ) - I feel like I’ve got a responsibility to carefully balance what I expose as some user-configurable thing versus something managed internally by the application. Sometimes, thankfully, the application doesn’t even have to think about it al all - like what TCP flags to set when I dial some service.

You bring up containers which is a great example of some cool features provided by the Linux kernel to solve interesting problems. If you’re interested, have a look at FreeBSD’s Jails, Plan 9 and LXC. Compare the interface to all these systems, both at the library level and userspace, and compare the applications developed using those systems. How easy is it to get going? How much do I need to keep in my head when using these features? Docker, Kubernetes, and the rest all have made different tradeoffs and compromises.

Another one I think about is SQLite. Some seriously clever smarts. Huge numbers of people don’t know anything about for-loops, C, or B-Trees but can read & write SQL. That’s technology at its best.

Consider how difficult it could be to, say, start a car in all the different operating conditions it is expected to be used in. But we never think about it.

We as tech people pride ourselves on familiarity with esoteric detail, but it doesn’t need to be like this. Nor does memorising it all have anything to do with “skill”.

What I’m struggling with are thoughts of significant vested commercial interest in exposing this kind of detail, fuelling multi-billion dollar service industries. Feelings of being an outsider despite understanding how it all fits together.

It is a pluggable service that connects to one or more TSDBs, performs periodic queries, and notifies another service when certain thresholds are exceeded.

Have you ever written this kind of software before?

It sounds like you are comfortable with the status quo of this part of the software industry, and I’m truly jealous! If you’ve got any tips on dealing with this kind of stuff you can find my email at https://www.olowe.co/about.html Thanks :)

This is more along the lines I was thinking.

I think the parent comment went ad hominem rather than trying to understand some of the difficulties I brought up. I’m not sure whether engaging with them would be productive.

I’m now 30 years old and I wonder what I’ll feel like after another 30 years :(

You’ve done a great job of showing what it feels like when I see Rust sometimes. There’s something about the way that it “builds up” on the page over time… I’ve never written any Rust - I’ll get to it one day! - but I found this article interesting look at how and why design decisions effect the final syntax: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

Maybe a silly question: how did you find it on GitHub? Did the project appear as some kind of “recommended” thing?

I wonder whether that many people actually do this. From my quick look, I saw jobs flooded with offers for well below the minimum wage of my country (Australia).

Keen to hear anyone’s experience!

Changing that much was probably a bad thing,

I’m a generalist and this gets me too.

For many jobs the ones doing the hiring are thinking of their domain, so more experience in the domain means a better worker. But a software developer who has developed CRUD apps 50 times on-budget and on-time over 20 years is almost certainly going to be a fantastic candidate alongside the dev who specialised in the health insurance (or whatever) domain for the entirety of their 5-year career.

Now I’m aiming for more software-focused companies and consultancies since I think I’m more likely to meet people who appreciate that broader experience.

Fair enough. Hopefully you can keep using those scripts even if nobody else uses them.

Yes I’ve personally argued against automation, too. Particularly when something is clearer to just be written down in a checklist-like format, to be followed by someone with domain expertise.

Thanks for sharing. I did a bit of work for a NOC and know exactly what you mean about letting real work slip through your hands. I wasn’t directly responsible for managing the alarms, but it felt strange to be writing software streamlining the workflow. All the time I spent I felt like I could have just helped the technicians actually solving problems they faced in their day to day - to stop the alarms going off in the first place!

Ah come on, what’s a little spaghetti code between friends ;)