Yeah this is the very first time I am hearing that templates are "extremely cheap". Template instantiation is pretty much where my project spends all of its compilation time.
A younger person who only knows the comparative merits of Windows, macOS, and Linux in this decade probably cannot imagine the relief felt by people when they were finally able to move their technical applications off unix boxes onto Windows NT workstations. The situation was so bad, the computers cost so much and worked so poorly, a Dell with a Pentium Pro was like a miracle, at the time.
I don't have any nostalgia for old machines, I understand the 5- or 6-figure price tags were ridiculous, but I'm curious - in what way did Unix machines back then work poorly?
That means nothing when everything it's either RHEL bound, Ubuntu LTS or docker containers among standalone services written in Go which are everywhere.
Serious GUI software will be written in QT5/6 where the jump wasn't as bad as qt4->5. Portability matters and now even more. Software will run in any OS and several times faster than Electron.
Yeah it was a real piece of junk, but I guess there's no accounting for nostalgia. People also like to restore the SGI Indy, easily the worst machine that SGI ever shipped.
At one point decades ago there were a lot of these IPXs and their SCSI accessories on eBay and they were a decent source of project boxes because you could use the power supply and stick your project where the hard drive was supposed to be, with the wires coming out the SCSI port. It looks like the model 411 is still $30 or so on eBay but there are few.
The Indy was awesome. One client had 400 of them, as long as you didn’t take the lowest RAM entry level model they were excellent. Hardware was reliable, graphical desktop better than MacOS today, and very low support burden.
So true. Keep in mind, OP said it was the worst machine SGI shipped, not the worst machine Sun shipped. SGI's worst machine could be fixed by adding some RAM. Sun's worst machines were completely unsalvageable.
Because the Indy (and O2) are actually attainable. Indigo2, Octane2, Tezro cost 2-3x minimum. Sometimes a Personal IRIS comes up for relatively cheap though.
Hey, don't trash talk Indy like that. It has.. well, it is Web! and has VRML.. and it's your only option for N64 devkit. So, there's that. Overall you're right though. Entry level machine. I have one in working order, rarely has use next to Indigo2 MAX impact. I do have one Sparc, haven't been booted in ages. I have to check whether it's IPX or Classic. I'm even afraid to boot it up.
Regarding your conclusion, I always figured that the reason WAITPKG seems kinda lame is the only reason they ported it to Core architectures was to make the heterogenous CPUs possible. It works better on Atom. On Core it does almost nothing, as you note. AMD's ISA extension was written from the ground up for their high performance server core, which might explain why it's actually useful.
I was psyched about UMWAIT and TPAUSE when Alder Lake arrived but unfortunately Intel has never shipped a model where these features actually work right. There have been errata all over the topic of the monitors failing to fire. TPAUSE also unfortunately useless since you have to read TSC, it just takes too long.
Obligatory dense field numbers seems like a massive downside, the problems of which would become evident after a busy repo has been open for a few days.
It's not obligatory.
Basically Protobuf gives you a choice between (1) binary format, (2) readable JSON.
Skir gives you a choice between (1) binary format, (2) readable JSON, (3) dense JSON. It recommends dense JSON as the "default choice", but it does not force it. The reason why it's recommended as the default choice is because it offers a good tradeoff between efficiency (only a bit less compact than binary), backward compatibility (you can rename fields safely unlike readable JSON) and debuggability (although it's definiely not as good as readable JSON, because you lose the field numbers, it's decent and much better than binary format)
Right, this is a car-priced CPU and the only rational reason to have one is that you can exploit it for profit. One pretty great reason would be giving it to your expensive software developers so they don't sit there waiting on compilers.
A person who only has real industry experience can very easily have never needed git at all. I know this shocks people who only have hobby or startup experience but git works very poorly at large scale and there are many big organizations who don't use it either because their solutions predate git, or they are newer companies that simply have good taste.
I’ve been in dev since CVS was a thing and did migrations across all of them really, svn, mg and finally git. I’ve worked in a broad swathe of industries and never once over 25 years have I ever seen an org not using source code management.
reply