Over time I evolved to Debian testing for the base system and nix for getting precise versions of tools, which worked fairly well. But, I just converted my last Debian box to nixos

I'm using Debian testing in my daily driving desktop(s) for the last, checks notes, 20 years now?

Servers and headless boxes use stable and all machines are updated regularly. Most importantly, stable to stable (i.e. 12 to 13) upgrades takes around 5 minutes incl. final reboot.

I reinstalled Debian once. I had to migrate my system to 64 bit, and there was no clear way to move from 32 to 64 bit at that time. Well, once in 20 years is not bad, if you ask me.

I've had a couple outages due to major version upgrades: the worst was the major version update that introduced systemd, but I don't think I've ever irreparably lost a box. The main reason I like nixos now is:

1) nix means I have to install a lot fewer packages globally, which prevents accidentally using the wrong version of a package in a project.

2) I like having a version controlled record of what my systems look like (and I actually like the nix language)

I prefer to isolate my development environment already in various ways (virtualenv, containers or VM depending on the project) so I don't need that parts of NixOS. My systems are already run on a well-curated set of software. Two decades allowed me to fine tune that aspect pretty well.

While I understand the gravitas of NixOS, that modus operandi just is not for me. I'm happy and fine with my traditional way.

However, as I said, I understand and respect who use NixOS. I just don't share the same perspective and ideas. Hope it never breaks on you.

I think you could mitigate some of the problems by making the drug company pay for the treatment before approval.

Genius did something like this to prove that Google was stealing lyrics from them: https://www.pcmag.com/news/genius-we-caught-google-red-hande...?

Gemini (3.0 Thinking) solves it too.

I strongly disagree with this: calling your thing that serves webhooks “webhooks” or “webhook-service” sounds nice and neat when you’re looking in a repo list but you immediately impose a tax on everyone in the org: now everyone in a conversation has to distinguish between “webhooks” as the proper name of a particular service and “webhooks” as the name of a particular pattern. Multiply this by all the various components of a modern software ecosystem, and you turn your companies infrastructure into a private language piecemeal and, what’s worse, it’s a private languages outsiders and newcomers think they understand and so they often take much longer to discover what the actual services are.

I wish people would stop promoting the singleton pattern: in almost every case I’ve seen, singletons are unnecessary tech debt and solve a problem that’s better solved with some form of dependency injection (and I don’t mean the XML/YAML monstrosities various frameworks force on you but rather constructor arguments or factory functions)

The site is not "promoting" the singleton pattern. In fact, there is a "Tradeoffs"[1] section that calls it an anti-pattern in JavaScript.

In spite of that, there are plenty of reasonable use cases for singletons in many languages, including JavaScript. For example, ES Modules are effectively singletons. If you import the same module in multiple places, it only gets evaluated once.

Let's not turn the singleton pattern into forbidden knowledge.

[1]: https://www.patterns.dev/vanilla/singleton-pattern/#tradeoff...

Why pose DI as replacing singletons when they're used together all the time? Injecting dependencies to create a singleton repository or service class, which is shared across requests.

Singletons are globals and should be treated the same as every other global (that is, used sparingly and with care).

Worse is that singletons enfurece a single instance which is almost always unnecessary. It’s trivial to only create as many instances as you need.

Off the top of my head, rails (currentattributes), Laravel (facades) especially, and most iOS apps use singletons quite well. It’s all in moderation and depends highly on how it’s used, much like every other design pattern.

I think people just don’t like Singletons because they’ve been especially misused in the past but I guarantee the same argument stands for any other design pattern.

Yes, I have to admit my interest was piqued by the banner, and I then scrolled down, saw the first example was singletons, and closed the tab.

Yeah, the liberating thing for me in CL is that things just don’t break as much as they do in other ecosystems. So, when I get breaking changes I look for an alternative that doesn’t break.

But how the data got sorted is irrelevant to the speed of the algorithm: for example, you could use binary search as part of an algorithm to find the insertion point of a new element in an always sorted data structure, meaning that sorting the data is never necessary.

The overall journey matters. For example, for some flight journeys, the flight-time is only a fraction of the overall time taken by the journey, which could makes it faster if you use road or rail transport. Flight speed doesn't matter.

But that is an unanswerable question which depends on how the data structure is used. The reasonable thing is to calculate the cost for the operations separately and let whoever uses the algorithms figure out what that means for their use case.

The thing that got me was always referring to Scaleway in the third person. e.g. this read like the response I get when I ask AI to review code:

> Scaleway’s solution to that problem was ingenious: embedding a Raspberry Pi module with each Mac mini.

(I realize this may be an artifact of a corporate style guide, but I'd much prefer "Our solution to that problem was embedding . . ." Both because the "was ingenious" doesn't add a ton and reads like puffery and because this is Scaleway's own blog and referring to yourself in the third person is grating.)

To me, it just reads like their marketing person's first language is not English. Which tracks because I believe the whole company is based on France.

Every several years people reinvent serializable continuations

Yupp, making that same point in the post :)

> You could think of [Durable Execution] as a persistent implementation of the memoization pattern, or a persistent form of continuations.

Haha so true. Shame image based programming never really caught on.

Janet lang lets you serialize coroutines which is fun. Make this sort of stuff trivial.

unfortunately they've never really taken off so folks reach for explicit state machines instead. there have been a handful of options on the jvm over the years (e.g. quasar, kilim) but they're all abandoned now, the loom continuation API is internal with no hint of it becoming public, kotlin's aren't serializable and the issue is inactive (https://github.com/Kotlin/kotlinx.coroutines/issues/76), etc.. such a shame