I think the experience of the gpt4/gemini2/claude2-3 era of models was widely variable depending on the use case and how much reference material there was on the internet. I'm told it was very good at producing react code for example, but my experience was it often failed to handle Rust or Kotlin type checking and failed pretty often (in less immediately detectable ways) on PHP. So looking at the trajectory from the initial copilot (could auto compete fast inverse square root and method level problems that you could also just google), to GPT4 (which from my experience, still couldn't code) and hearing that the training data by that point was "most of the internet" it wasn't that clear to me that it would reach the point it has today.

Obviously the models themselves have trended bigger since which has helped and also just the tooling and harnesses around it and the models being trained for that use case has achieved a lot since that q4 2025 window which is about the first time it became functional for me.

The training data back then was sooooo bad. You'd open something at random in Common Crawl and it was truly unbelievable that models (like llama) were able to output coherent stuff. The architecture was truly miraculous if it could train well with terabytes of garbage.

There was so much low hanging fruit back then in terms of training.

Can you point out an example where someone made that mistake?

Today? The target market wouldn't want to deal with the stock and pricing caused by RAM demand.

N100 mini PCs are easy to come by on sites like Newegg. Cringley was laser cutting cases. Then, you have open source software like Comitup that would make it easy to auto setup WiFi and tailscale for bypassing home NATs. You can script a lot of that stuff

Maybe we should revive the project in memory of Bob? /s

I was there in the early 2010s and we did have older versions of AIM, netscape in an archive CVS (svn was the day to day system when I started). But then we moved to git and only stuff that had a designated owner got moved from cvs/svn to git so there was another round of losing old source code. And another in the migration to yahoo systems post merger.

> It looks like that phrase was removed from the article, but that is standard for C-level jobs.

Isn't the standard they get a made up advisor role for some months? Though usually that involves the ex-C-level to understand the implicit expectation of not starting immediately at the next place.

It only works backwards (though you can probably get away with it if your future dates are not too far forward). There are ~10 tzdb updates a year due to rule changes and if you bake a date on the other side of one to UTC too early then your app is going to have incorrect datetimes

My experience is (despite the Postgres developer's advice to use it), timestamptz is largely a useless data type since it is just a wrapper around conversion to UTC.

- Are you storing past events? Just store them as UTC. Maybe you use timestamptz to do it for you, but it's actually a more obtuse interface for that than timestamp

- Are you storing future UTC times? Great, just use UTC, see above

- Are you storing future human times? Then timestamptz is actively harmful because it eagerly converts to UTC so even if you get an updated tzdb in time for when the event comes due, you don't know what happened at write time so now your datetime is ambiguous. It's less broken to use a plain timestamp + string timezone column (if you need to sort by it, maybe a denormalized _utc column too, with the understanding that you'll need to regenerate it or accept slight off-by-one errors when you update the tzdb, but at least you can do this when you know what the input value was, unlike with timestamptz)

SQL Server has `datetimeoffset` which stores the UTC offset (and so roundtrips it), which is definitely an improvement. (You still may need/want a string timezone column even with UTC offsets, but you don't need a denormalized _utc column because datetimeoffset math just works as if the times were all UTC.) It seems like something that Postgres could use. Especially because the overhead for storing UTC offsets isn't that much. (10 bytes versus 8.)

BSD was under a cloud of a lawsuit at the early stages of corporate adoption of open source operating systems and by the time that was resolved network effects had given Linux too much of a lead.

Obviously it's hard to predict the opinions of the dead, and I think a lot of the disagreement here comes from whether they view his ideas as being motivated by anti-copyright as a standalone idea or part of a larger pro-little-guy stance. I think depending on which you think it was, you can come to a different idea of what his view would be on open models. But surely both views would lead to an anti-closed models stance? Would a hypothetical generation later Aaron want to publish the weights for Claude rather than academic publisher articles?

I am not talking about open models. I am talking about proprietary models being trained on public information. A lot of people want to posture about what an ideological person might think, and some of it seems conveniently positioned to use a past figure that can't speak for themselves.

I think copyright has real intrinsic value in our society, but having been subjected to threatening legal letters for legit fair use situations in my youth, as a result I don't think the legal structure behind it is sane. I always respect copyright when I can, but it's gotten to a point where fair use is not equally considered.

And yet I expect the QOL for the median French person to be higher than the median Mississipian.