Normally I would eye-roll at these kind of self promotions but it looks like you are trying to help with a real pain point of Nix.

I put a good amount of time getting to grips with "raw" nix with the I imagine common yo-yo-ing between "I don't get it" and "oh I see, this is great" but when I realised how the intersection of nixpkgs and package versioning actually worked.. I was done.

For a tool that from the outside seems is so heavily focused on immutability to just continually throw away old versions in nixpkgs head is a head scratcher, and as a monorepo isn't a great fit for utilising different revisions for different packages either.

I can only guess that due to single repo containing every package it wasn't seen as practical to just continually append versions to, but when the diff log is just full of 'delete version X URL and it's hash, add X+1 and new hash' from the outside at least, it felt like a real missed opportunity.

I would suggest one more step of "oh, this is great": I don't think people need to care as much about finding the right version in the repo as they do. (Unless we're talking about something really significant like finding old MySQL 5.6) For smaller apps you can either override or copy the current nix file and update the version and hash - you get the version you want. It will use new version of the dependencies, but normally that's just fine.

I've got 3 packages which are pinned to a specific version that way in home-manager and I'm happy. It's not an approach for the first time user of course.

I thought this too, but we got a lot of requests for better version search + pinning. Adding overrides and looking up the right commit hash is a pretty cumbersome for a first time user.

For new projects though, I agree that using `latest` is generally the way to go.

I believe the Hackage.nix library [1] has a solution to this problem, specifically for Haskell packages.

The `text` package [2] has many major, minor, and fix versions. Many of these versions are still required by projects. However, the current Nix Packages only has one version [3], and maybe a second version under a different name.

Hackage.nix will provide any version of `text` published on Hackage.

One downside is that `text` is not pulled from Nix Packages. The project's specific version of `text` must be cached elsewhere, or built from source. So it is slower.

[1] https://github.com/input-output-hk/hackage.nix [2] https://hackage.haskell.org/package/text [3] https://search.nixos.org/packages?channel=22.11&show=haskell...

> just continually throw away old versions in nixpkgs head

It is simply completely infeasible to store and build every version of every package.

While it is not user friendly to find a package’s version X, it is either just overriding the version field and the hash, or referencing another version of the nixpkgs tree and building the same package from there.

It’s not trivial with other package managers either, and on top you can easily get into inconsistent states with those — nix can handle any version of any software correctly.

I don't think the answer is to have every version at the nixpkg head, for exactly the reasons you mentioned.

But I do think there's a search issue where mapping the version field of a package to the commit hash or nixpkgs version is not trivial or user-friendly, especially for multiple packages.

I do think Flakes help with the "throwing away old versions" issue. They also help with the monorepo issue by encouraging developers publish the Nix derivation in their own repo.

But they currently have a bit of a discoverability issue, and they need adoption by legacy packages to completely fix the problem.

It's not a good reason but I believe this happens because voice command has to go to Google server, Google talk to light vendor API, light vendor communicates with your device, and lights go off only if all of this succeeds.

Meanwhile, button in vendor app will not use internet so lot less can go wrong.

Snaps is just the latest in a long line of failed attempts to differentiate their desktop.

Give it a few years and they will switch to Flatpack.

Re type annotations, is there some non-default setting or plugin I am overlooking?

As a long time pycharm user who recently switched to vscode, I have found pycharm's understanding of type annotations to be borderline broken.

  def foo(value: Optional[str]) -> None:
      print(value.replace("bar", "baz"))

mypy and vscode both point out this will fail when value is None, but my pycharm seems to think this is perfectly fine.

To be honest I don’t use the type annotations given by the IDE that much, and I also only encounter them in my work code base (pymongo), so I can’t comment on that part. I was mainly commenting just on its ability to handle large code bases.

Not aware of a built in way, but if you use bash or similar as your shell you can do an alias like

  git config --global alias.chpull '!f() { git checkout "$1" && git pull; }; f'

Didn't think about alias for this even though I have alias for many other things, that should prevent `direnv` from triggering between checkout and pull. Thanks.

I got into PCs around same time as you, but imho the best overclock came years later: the Intel Celeron 300A would happily run at 450mhz for a whopping 50% increase.

I was right into FPS games at the time, and for a while it seemed every second person was running the overclocked 300A.

FWIW bash supports arrays, and running commands with an array providing the arguments

Like it or not, Docker is the Kleenex of containers.

I don't understand why Computer Programmer (or just Programmer) went out of fashion.

If I ever get to decide on my professional title at a company I'll go with "code monkey". It's as respectful as the profession deserves.

I’d like to call dibs on “digital plumber” for DevOps Engineers

hell also the term Coder, which hilariously gets misinterpreted as Encoder (a copy paste work), which I kind of prefer just to keep it in the low low

Long time OW player here.

Smurfs in overwatch (1) were incredibly obvious because

a) each players 'level' - which correlates directly with hours played - was prominently displayed, so new accounts were immediately identifiable; and

b) as a hero-based shooter, there are various macro strategies and hero-specific techniques that genuinely new players simply can't be aware of

Many smurfs would also have unintended "fancy" battle.net tags - think ツ kinda thing - which were only available by initially purchasing account with region set to an Asian country before then changing it to US.

At it's worst, one would simply look at the player names and levels on the loading screen and know which team was going to win before the match had even started.

Combined with relatively long match times and the inability to forfeit in Overwatch; the end result is many, many hours of dead rubber games over the years.