Makes sense, there are a lot of reasons why having some "big iron" might have been practical in that era. x86 was not a full contender for many workloads until amd64, and a lot of the shared-nothing software approaches were not really there until later.
If you have enough to worry about someone beating out of you, maybe putting some into professional multiparty custodial systems and/or one or more cold wallets with trustees is a good idea. This idea scales fine with geopolitical risk.
Your "hot wallet" should be like cash, no more than you are prepared to lose/surrender at once.
None of these things are mutually exclusive. Holding a large pile of any one country's fiat is probably the dumbest move. Ownership of physical assets that generate revenue is the smartest.
And to add: Your "hot wallet" being bank issued credit cards for everyday purchases or emergencies that you are prepared to lose/surrender the moment someone tells you to hand over your wallet.
Later log into the accounts, flip the toggle to stolen/lost and mark unauthorized purchases if there are any. Then sleep peacefully knowing new credit cards are in the mail and you are only out the cost of the physical wallet holding the cards that were stolen.
Most people of any significant wealth would have made the delegation long ago to private client banking where a team of people overlook all aspects of the accounts. So yes, you are a fool not to if you have the level of wealth proportional to having it beaten out of you in your geopolitical region.
A custodial service is a bank that operates on a different network and is not FDIC insured (which only covers $250k). It could be insured privately. The interest on an FDIC deposit account is well below true inflation of fiat currencies.
This is weird because the microprocessor industry owes a lot of early success to automotive companies. Motorola 6800, Intel 8061 (https://www.intel.com/content/www/us/en/history/virtual-vaul...) etc. Quoting wikipedia: "the name "Motorola" by linking "motor" (from motor car) with "ola" (from Victrola), which was also a popular ending for many companies at the time, e.g. Moviola, Crayola"
TI has some powerful automotive SoCs like the AM69A/TDA4AH (https://www.ti.com/ds_dgm/images/fbd_sprsp79b.svg) that target the industry.. 8 Cortex-A72s, a full GPU, multiple Cortex R5Fs that can lockstep, and a bunch of powerful C7000 DSPs. The SDK is probably not awesome as embedded BSPs tend to be but the SoC should be workable. That should be plenty of compute.
Marc Laidlaw had a number of novels published before and after going to work for Valve and doing the Half Life thing.
"The Third Force" novel and the associated game "Gadget" are probably not well known - but if you liked Myst you might like them. It's a bit more of a visual story than a puzzle game - a bizarre psychological/psychedelic story with stunning for the time graphics (1993 or 1997 depending on the version).
A lot of work has gone into FreeBSD's aio(4) so it will be interesting to see how that works, because it doesn't have the drawbacks of Linux/glibc aio.
BTW I have patches for PostgreSQL AIO on FreeBSD, which I will propose for v19. It works pretty well! I was trying to keep out of Andres's way for the core architectural stuff and basic features ie didn't want to overload the pipes with confusing new topics for v18 :-)
Linux aio (the POSIX one, not the broader concept that now includes io_uring) has been fundamentally bad. Part of it is some of the implementation is delegated to user space in glibc as worker threads. https://lwn.net/Articles/671649/ surveys the issues. I have not done a deep dive into this topic in a long time but as far as I know the situation never greatly improved. io_uring does not suffer from the problems, although it is a new and non-standard API with associated pros and cons.
Thomas Munro has gone into some of the benefits and also gaps of FreeBSD's aio(4) vs io_uring here https://wiki.postgresql.org/wiki/FreeBSD/AIO. Notably, because the implementation is in kernel and has received continuous improvement it is gradually removing downsides and there are several users that need it to work well. This document undersells the problems of ZFS though: the ARC is a necromanced buffer cache which Sun ironically worked very hard to remove (http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf) and nobody has fixed this in 20 years. But for UFS or raw block devs or vendor file systems that doesn't matter.
FreeBSD being a complete "src" tree yields some advantages. In concrete, there are some in tree consumers like ctld (a CAM/iSCSI server) that have been used as vehicles to provide end to end implementation of things like NIC offload of complex protocols that play well with backend block devices such that you can make an offloaded data path that is pumped via asynchronous completion events on both sides (network and block). A related whitepaper https://www.chelsio.com/wp-content/uploads/resources/T6-100G... but this concept can be extended to iSCSI, NVMeOF etc. It seems NVMeOF work sponsored by Chelsio is yielding a lot of the finishing touches https://papers.freebsd.org/2023/eurobsdcon/baldwin-implement.... I believe my colleagues are also improving aio to further optimize the Netflix case of KTLS NIC with data on disk but I am not the right person to extrapolate on that.
A lot of the fun parts of the computing industry have, predictably, been hollowed out by the rent seeking model of cloud and *aaS. There is some grace as it's easier than ever to build some scalable web business.. but the most fun of my career was rabbit holing on computers for the sake of computers.. working on operating systems and device drivers and network stacks. And it did and still does matter to a lot of bottom lines, but corporates have a hard time connecting the dots or doing something other than what the flock is doing.
It's a little awkward because the AI datacenter boon is a little bit of a revival for physical and systems work but it is limited to that and I am skeptical of the longevity.
Those days of having fun working on network stacks, operating systems, setting up FOSS development labs and being a good steward of things.. harder and harder to do and even harder to get started.
It's probably a simple economics thing. You can hire out a contract PCB design for a reasonable cost and the long poll is getting back physical prototypes. Contrast to HDLs displacing schematic based designs for ASICs and programmable logic, where simulation allows for rapid development.
I'd say it's significantly different because you can get a physical PCB prototype in days for a few dollars while an ASIC prototype takes months and millions.
I'm not sure if you missed the point. HDL design work is done by simulation for countless iterations before ever making it to a physical prototype. ASIC prototypes come very late in the cycle and are usually a low digit number of revs. So the point is simulation carries you through most of the design feedback cycle, and a significant economic and technical effort went into industry automatic place and route, DRC/LVS, etc. I am also ignoring the human heavy side of layout especially around analog and RF which is more like PCB design still.
A PCB can be reworked by hand on site. And those revs can be incorporated cheaply as you say. So the need to do all this programmatically is lowered below the economic threshold to make it all plausible in most cases. This presupposes that modern PCB tooling is itself semi-automated and includes simulation capabilities, but an expert operator is doing a lot of the decision making.
It seems like the parent was trying to paint a situation of you being a bottleneck to success. It seems a bit Schrödinger's BFDL though.. is Linus a bottleneck to the most used server operating system? Did Guido hold back Python? The existence of the GDC and LDC compilers torpedoes toolchain concerns.. I'd be more worried about Java or Golang suffering from some eventual corporate buffoonery.
To the parent's point of startups, betting the farm on something like a particular language out of some sense of superiority might mean you are not focusing on the right problems. But if the founders happen to know a less widely used tool it doesn't seem inappropriate either. The type of employee that can drive a startup or a big tech project forward is not going to be thwarted by a language, and they might find something new to learn fun.
There are a lot of other things that follow this pattern. 10-30 year predictions are a way to sound confident about something that probably has very low confidence. Not a lot of people will care let alone remember to come back and check.
On the other hand there is a clear mandate for people introducing some different way of doing something to overstate the progress and potentially importance. It creates FOMO so it is simply good marketing which interests potential customers, fans, employees, investors, pundits, and even critics (which is more buzz). And growth companies are immense debt vehicles so creating a sense of FOMO for an increasing pyramid of investors is also valuable for each successive earlier layer. Wish in one hand..
