Pretty cheap and pretty slow, relative to other Alphas. The various ATX-sized PC164s motherboards were the ones that should have sealed the deal for Digital, but intel had PPro at about the same time, with similar performance, less cost and probably most importantly ran all the software people already had and vendors didn't have to port to a new arch[1].
What might have been.
[1] Yes, yes...PPro sucks on 16-bit software. My personal experience was that was a red herring by the benchmark-jockies, because it wasn't that much slower, and virtually none of the many, many PPro machines I was responsible for ran DOS/Win3 software.
Some years ago - never mind how long precisely - I also starting writing a Lisp interpreter in Python. I also called it Lispy. This time, the coincidence is less remarkable though, as the word play just sits there, begging to be played.
I remember running CoLinux back in my training days ~2005-2006. It seemed a bit like black magic to me at the time, but it worked quite well for my needs.
But CoLinux - IIRC - required the NT branch of Windows. I can only imagine the level of hackery it takes to make this happen on Windows 9x.
Part of me wants to weep at the sheer perversity, part of me wants to burst into manic laughter. It is indeed a world of endless wonders.
True, however, that has been the case for quite a while. This particular incident doesn't change that, except for the VeraCrypt developer, who is in a crappy situation now (not just regarding VeraCrypt, he mentions he was using the certificate for his main job as well, so this sucks a lot for him).
As much as I like bashing Microsoft, never underestimate people's capacity for incompetence, especially where large organizations are involved. I don't see how they would gain anything from this move.
It doesn’t help that they do that sort of shits AND mandate a microsoft account for logging in to windows. Also how much trust can you have that if you move your business to azure they will not randomly kill it. Incompetence or malice, almost doesn’t matter to the average user.
The outcome is the same, yes. With incompetence, there is at least a glimmer of hope things will get rectified. But you are correct, trust is destroyed this way, and it doesn't look like Microsoft cares much.
STRICT tables are something I appreciate very much, even though I cannot recall running into a problem that would have prevented by its presence in the before-time. But it's good to have all the same.
I don't think I've ever done much with SQLite's JSON functions, but I have on one or two occasions used a constraint to enforce a TEXT column contains valid JSON, which would have been very tedious to do otherwise.
> even though I cannot recall running into a problem that would have prevented by its presence in the before-time
I very, very much did. I was using a Python package that used a lot of NumPy internally, and sometimes its return values would be Python integers, and sometimes they'd be NumPy integers.
The Python integers would get written to SQLite as SQLite integers. The NumPy integers would get written to SQLite as SQLite binary blobs. Preventing you from doing simple things like even comparing for equal values.
Setting to STRICT caused an error whenever my code tried to insert a binary blob into an integer column, so I knew where in the code I needed to explicitly convert the values to Python integers when necessary.
