You mean late 1990’s? :)

no i mean, back in the 90's cgi perl scripts were the easy it thing for interacting with the big tech wave and now in the mid-2020s llm python agent scripts with tool extensions are the easy it thing for interacting with the big tech wave.

Now we need PHP and Ruby or Rails, somewhere down the line :-))

They’re victims of agenda

Nats is getting there, but not yet.

Redis is still much more powerful: lists, sorted sets and bazillion of other data structures

NATS has a bit more in terms of durability guarantees so I have found that it hits more use cases. I'm trying to strike a bit of a balance between "use the exact right tool for the job, even if that means you have 25 different services" and "just use Postgres". I do think Postgres/Redis/ClickHouse is probably fine as well but durable streaming would be hard to give up.

It’s usually a question of “who are your users?”

As long as you consider developers of derived software to be your users — permissive makes most sense.

But if you consider end-users of software it’s definitely copyleft.

So, the browsers have to provide some means for choosing the desired translation engine (add-on API maybe?) and this is a standard API which all of the providers should implement.

right?

Is it the UI for penthouse lib? Settings look very similar :)

it's based on penthouse, honestly, the most "difficult" part of this was setting up CloudRun with docker to get puppeteer to work and be able to wait whatever amount of time the user needed and netlify functions, I tried using tools like https://criticalcss.com/generate but they just didn't work because of the lack 'waiting' I guess

> Usually new data is generated regularly

This part was not obvious. In a lot of cases geodata is mostly stable and reads/searches dominate over appends. And that’s why we keep this in DB (usually postgis, yes).

So DuckDB is optimised for very different use case and it is not always obvious when it’s mentioned

This is the more trivial use case (static data, heavy reads) and DuckDB is absolutely optimized for this use case.

DuckDB also provides a vectorized, parallelized engine. When I run a query all of my 32 cores light up on htop.

But DuckDB works just as well with static data.

But LLMs are not reliable enough, so you can not actually expect “specificity”

Not perfect now, but adequate in some domains. Will only get better.

> Will only get better.

AI companies are still in their "burning money" phase.

Enshittification is not on the horizon yet, but it's inevitable.

While I have no doubt that individual companies, such as OpenAI for example, will eventually introduce enshittification features, I doubt the industry as a whole can be summarized that easily.

I believe, over all, development will go forward and things will get better. A rising tide lifts all ships, even if some of them decide to be shitty leaking vessels. If nothing else we always have open source software to fall back on when the enshittification of the proprietary models start.

For a practical example: The cars we drive today are a lot better than 100 years ago. A bad future isn't always inevitable.

But are cars we drive today better than they were 10 years ago? 20 years ago? Reliability is now trending down for cars, safety is questionable as deaths and injuries have been steadily increasing for a number of years now. Features are getting converted to subscriptions, and they all constantly send back telemetry.

Good points!

More reliable than 80% of my teachers growing up.

Well, jj is actually very nice in this regard, because:

1. it works on top of git — you keep using all the same infrastructure (GitHub, etc.) 2. in your local repositories you still have access to git-tools, as jj maintains git and its own states in sync.

After all of these months with jj I still find myself using GitUp when I need to review a long chain of commits or do some quick repo-archeology. And, from time to time, I even use Idea's merge tools because their "magic wand" saves a lot of time.

I mentioned this in the first part of series