It is not. Simple. It may be "easy" but easy != simple (simple is hard, I tend to say).

I'm currently involved in a project that was initially layed out as microservices in rust and some go, to slowly replace a monolyth Django monstrosity of 12+ years tech debt.

But the new hires are pushing back and re-introducing python, eith that argument of simplicity. Sure, python is much easier than a rust equivalent. Esp in early phases. But to me, 25+ years developer/engineer, yet new to python, it's unbelievable complex. Yes, uv solves some. As does ty and ruff. But, my goodness, what a mess to set up simple ci pipelines, a local development machine (that doesn't break my OS or other software on that machine). Hell, even the dockerfiles are magnitudes more complex than most others I've encountered.

In my case, I've used a similar strategy of keeping costs under €100/month. (But have sold, or stopped my ventures before hitting such MRRs as OP reports).

I raised some capital to pay my own bills during development. But mostly to hire freelancers to work on parts that I'm bad at, or didn't have time for: advertising, a specific feature, a library, rewrite-in-rust (wink) or deep research into functional improvements.

Sometimes that crashing is what I want: a dedicated server running one (micro)service in a system that'll restart new servers on such crashes (e.g. Kubernetes-alike). I'd rather have it crash immediately rather than chugging along in degraded state.

But on a shared setup like OP shows, or the old LAMP-on-a-vps, i'd prefer the system to start swapping and have a chance to recover. IME it quite often does. Will take a few minutes (of near downtime) but will avoid data corruption or crash-loops much easier.

Basically, letting Linux handle recovery vs letting a monitoring system handle recovery

The problem was, as I mentioned, "he though he was the best developer ever". stubborn as hell. And pushed back against anything he wasn't used to, anything that wasn't his usual "ssh or ftp into prod and change stuff until it works" because he thought this was the only method that worked.

This was my first encounter with a self-proclaimed "10x" developer before that term existed. Someone who - as seen by far off management - seemingly have a high output, but in reality just create a trail of tech-debt and work for the rest of the team.

It shows places that are problematic much better. High churn, low complexity: fine. Its recognized and optimizef that this is worked on a lot (e.g. some mapping file, a dsl, business rules etc). Low churn high complexity: fine too. Its a mess, but no-one has to be there. But both? Thats probably where most bugs originate, where PRs block, where test coverage is poor and where everyone knows time is needed to refactor.

In fact, quite often I found that a teams' call "to rewrite the app from scratch" was really about those few high-churn-high-complexity modules, files or classes.

Complexity is a deep topic, but even simple checks like how nested smt is, or how many statements can do.

So we told him to commit at least once every day, with a relevant commit message, or else fail his internship.

He worked 21 more days. There were 21 commits: "17:00, time to go home".

Seems counterintuitive to me. This would only make gains when they bought the new gold before selling the old, or when there's some arbitrage going on between Gold/USD, Gold/EUR and USD/EUR.

If they first sold the old for USD, then bought the new for USD, with a rising gold price, they'd miss the price-gain during the time between the trades, when they held the USD. It'd be a loss, not a gain.

If there's some arbitrage going on, then I highly doubt that brings $15B gain. The differences would have to be huge.

I think the (author (AI)) writing that article is simply mixing up stuff. I think this gain is not a cause-effect of the conversion, merely the gains from rising gold prices on the gold it holds over that period.

You can find the patch files for your OSs by registering at Oracle with a J3EE8.4-PatchLibID (note, the older J3EE16-PatchLib-ids aren't compatible), attainable from your regional Oracle account-manager.

This is javascript, not Java.

In JavaScript something entirely new would be invented, to solve a problem that has long been solved and is documented in 20+ year old books on common design patterns. So we can all copy-paste `{ or: [{ days: 42, months: 2, hours: "DEFAULT", minutes: "IGNORE", seconds: null, timezone: "defer-by-ip" }, { timestamp: 17749453211*1000, unit: "ms"}]` without any clue as to what we are defining.

In Java, a 6000LoC+ ecosystem of classes, abstractions, dependency-injectables and probably a new DSL would be invented so we can all say "over 4 Malaysian workdays"

https://en.wikipedia.org/wiki/Perverse_incentive?wprov=sfla1

But semantic HTML is exactly that explicit machine-readable entrypoint. I am firmly entrenched in the opinion that HTML, and the DOM is only for machines to read, it just happens to be also somewhat understandable to some humans. Take an average webpage, have a look at all characters(bytes) in there: often two third won't ever be shown to humans.

Point being: we don't need to invent something new. We just need to realize we already have it and use it correctly. Other than this requiring better understanding of web tech, it has no downsides. The low hanging fruit being the frameworks out there that should really do a better job of leveraging semantics in their output.

- All governments under EU (on almost all levels) are "required" to use and/or produce software as Open Source. The source of "that government app" should be available somewhere (though quite likely is not)¹ So go hunt for the source and start there.

- Look at underlying standards. EU regulation, trickling down into local laws and guidelines, rely on Open Standards almost always. That app you use to log into your tax environment quite probably uses (a weird, hard to recognize) variation of OAUTH2 or OpenID connect, SAML or such. The app that shows the time+dates for garbage-collection, quite probably uses a simple ical-feed under the hood. With that knowledge, you may be able to develop/fork/use open source alternatives without too much effort².

- Show (local) representatives the alternatives. Listen to them. Learn from them. Most representatives are suprisingly open to you as expert. But, I cannot stress enough, learn and listen foremost. IT experts and open source community in particular have an (IMHO well deserved) reputation for being arrogant, know-it-all unfriendly and rediculously single-minded. So don't lecture that councillor for using Twitter instead of Mastodon, riduculing them for not using GPG or scoffing at their insistence on using Microsoft Word over Vim with Markdown (My younger self was such an arrogant neckbeard; I am now convinced I have done actual harm to the Open Source community that way). But ask why twitter, have they tried mastodon, or bluesky? Why not? Why did they leave? What features in MSword do they require? Did they know that Jitsi is an option? Maybe you can show how they could use Nextcloud for at least their own files? Sometimes you can answer some of their questions and help them. More often, you learn a few things that you could use to improve sovereign and open source alternatives and align them slightly more with whats needed.

¹ The details, interpretations and implementations are a mess, but the idea is "open source, unless..." for any software that any government buys, rents, builds, etc. In practice almost all projects fall under "unless...". I spoke to a MSFT account-manager for several local govts and he told me they have f*in training material to "help" govt officials write tenders/requirements in such a way that Open Source is practically excluded and Microsoft the only option. I am appalled, but also not that surprised.

² The ical-finding is how I got my local garbage-collection schedule into my calendar app. And when I told this to someone who happened to work at the municipality, they realized that publishing the urls and docs online helped a lot of citizens. Ironically, the push-back, according to this person, was from a civil-servant whose career was influenced on the success (install counts) of the "municipality app" and who was afraid that if people could add the calendar to their outlook/google cal/ical/other-cal, might no longer install the app. Again, I was appalled at such perverse incentives.

The app still has it. It can dump it. It will dump it. Django for example (not a security best practice in itself, btw) will indeed dump ENV vars but will also dump its settings.

The solution to this problem lies not in how you get the secrets into the app, but in prohibiting them getting out of it. E.g. builds removing/stubbing tracing, dumping entirely. Or with proper logging and tracing layers that filter stuff.

There really is no difference, security wise, between logger.debug(system.env) and logger.debug(app.conf)

Currently I'm involved in projects surrounding https://developer.overheid.nl/kennisbank/security/standaarde... . Have a look there. It's not FLOSS in the way that you can just provide PRs of things you'd like different, but FLOSS in the way that you can get in touch and with enough expertise, have people listen to you.

Environment variables are -by far- the securest AND most practical way to provide configuration and secrets to apps.

Any other way is less secure: files on disk, (cli)arguments, a database, etc. Or about as secure but far more complex and convoluted. I've seen enterprise hosting with a (virtual) mount (nfs, etc) that provides config files - read only - tight permissions, served from a secure vault. A lot of indirection for getting secrets into an app that will still just read them plain text. More secure than env vars? how?

Or some encrypted database/vault that the app can read from using - a shared secret provided as env var or on-disk config file.

It is probably unintentional. I work and worked in such projects (in The Netherlands), and the process is -rightfully- chaotic.

Governments typically don't have a central single team that builds all their android apps. They usually write a tender with loads of requirements and app-agencies will then build it. Or freelancers. Or volunteer teams. Or all of that. So there's no central team governed by one minister who can dictate what should happen today. There's hundreds of companies, teams, freelancers, interims, running around trying to make deadlines

Between writing a spec and the delivered app, there's chasms: could be a year between the specs are written and the first app pushed onto a phone. In a (trump)year a lot can change. But also between how specs are requirements or wishes in real life. "No user data may ever reach a google server" (actual specs are far vaguer and broader) may sound good, but will conflict directly with "user must receive push notifications of Foo and Bar". Or "passport NFC data must be attested for login", requiring a non-rooted, android, signed-by-google hardware attestation thingymajick.

So no, this is not malice. Nor incompetence. This is a sad reality, where we've allowed the monopoly to dictate what we, and users, expect, and to have that monopoly be the only option to provide those expectations.

https://github.com/direnv/direnv/wiki/Sops