But - neither the speed nor constant issues with pip/virtualenvwrappers are really a function of the OS/File System.

A frequent theme in this thread (probably most clearly described in https://news.ycombinator.com/item?id=47444936) is that relying on your Python Environment to manager your Python Environment - always ends up in pain. Poetry had this issue as well.

One of the key architectural decisions of Astral was to write the Python Environment Management tooling in rust - so that it could never footgun itself.

It also benefited from very enlightened engineering decisions described here: https://nesbitt.io/2025/12/26/how-uv-got-so-fast.html

Things got bearable with virtualenv/virtualenv wrappers, but it was never what I would call great. Pip was always painful, and slow. I never looked forward to using them - and every time I worked on a new system - the amount of finaggling I had to do to avoid problems, and the amount of time I spent supporting other people who had problems was significant.

The day I first used uv (about is as memorable to me as the the day I first started using python (roughly 2004) - everything changed.

I've used uv pretty much every single day since then and the joy has never left. Every operation is twitch fast. There has never once been any issues. Combined with direnv - I can create projects/venvs on the fly so quickly I don't even bother using it's various affordances to run projects without a venv.

To put it succinctly - uv gives me two things.

One - zero messing around with virtualenvwrappers and friends. For whatever reason, I've never once run into an error like "virtualenvwrapper.sh: There was a problem running the initialization hooks."

Two - fast. It may be the fastest software I've ever used. Everything is instant - so you never experience any type of cognitive distraction when creating a python project and diving into anything - you think it - and it's done. I genuinely look forward to uv pip install - even when it's not already in cache - the parallel download is epically fast - always a joy.

Looking very forward to more of your insight/comments. Hopefully your NDA has expired on some topic that you can share in detail!

Likewise for 100 years, or 200 years. etc...

ALso - Archival media that needs re-copying every 20-30 years is not Archival media by my defintion

I can't imagine it would ever be worth, under any scenario, trying to write/build/support any $25/seat SaaS software for any company I've worked at in 25+ years.

Another thing to keep in mind - very little of the cost of a SaaS license is the time it takes to build the software. Security, Support, Maintenance, Administration, backups/restores, testing/auditing said backups/restores, etc, etc.. and then x-training new SREs on how to support/manage this software, ...

Even as someone who spend 10+ hours a day churning out endless LLM applications, products, architectures from my myriad of Cursor/Codex/CC interfaces and agents - I'm dubious that LLMs will ever eat into SaaS revenue.

I'm sure (lots of) people will try - and then 1-2 years in someone will look at the pain, and just pull the ripcord.

Reading through the article:

> They were paying $30,000 to a popular tool3

Couple things we needed to understand here:

  - How large is the client company
  - Is that $30,000/month or day or hour....

Any product/service that people care about comes with a pager rotation - which is 6-7 employees making > $200k/year. If you can offload that responsibility to a SaaS for < $1mmm/year - done deal.

I'm wondering what the difference is between this and just tmux basic environment - which already has a lot of pane / window management. What's the key distinction between using tmux and dwm.tmux?

<5 minutes later> - Ah - this is just tmux with some custom config. The window manager is tmux - I would suggest changing the title a bit - maybe something like, "DWM.TMUX - dwm inspired tmux configs. "

Love Floating Panes in Tmux - and best part - all the other plugins - resurrect, continuum, etc..) all support floating panes out of the box.

In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.

The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.

Put another way - to do an apples to apples comparison:

  Hard to attack:   FDC2:1045:3216:0001:0013:50FF:FE12:3456
  Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456

The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.

In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.

I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.