Pre-AI-boom, Intel was a failing chipmaker. The situation was bad in all respects. Processor design fell behind AMD. Fabs fell behind TSMC/Samsung/etc. Culture was broken. Massive braindrain.
Stock was down three-fold between its peak around 2019 and its bottom in 2024/2025. Indeed, it was down three-fold in 2024/2025 from its 2000 dot-com peak.
Basically, imploding company, on its way for collapse.
With AI boom, there was more demand for ICs than production capacity. It almost didn't matter how bad your chips were -- someone would buy them, and at a healthy markup. This placed Intel in a very strong position to recover.
That recovered some value -- going above their previous high, but much less than 25 years of S&P500 growth. However, it's worth remembering the peak of $120 was less than double it's dot-com peak 25 years prior.
If AI boom doesn't materialize, Intel may, again, be on a path to death.
If it does materialize, but like the dot-com boom with a few winners and many losers, Intel will likely be one of the losers.
Ergo, falling value.
NVidia, in contrast, looks a lot more like the Amazon of the dot-com bust.
> Nvidia is essentially scheduled to collapse with the rise of 1-bit NNs
This assumes the shape of demand for computational intelligence which we don't know the answer to. Maybe 1-bit NNs do everything we want to do with LLMs. Maybe it means we span tens of thousands of them to do sundry tasks every day.
I think part of the problem is we don't talk about these issues openly. I see a lot of posts like (from this thread):
"I followed a line of research that a senior (MacArthur Fellowship-winning) colleague had pioneered... After three years and a few negative results, I came to suspect that several high-profile publications were p-hacked and likely false positives... A very senior scientist later confirmed my suspicions about their disregard for professional ethics."
These issues should be discussed openly. This also means that the consequences should be appropriate. In many domains -- anything dealing with sex / gender in almost any culture is a good example to look at -- the consequences are draconian, be that stoning or cancel culture or ... which prevents open conversations.
No, I can't provide a cite. Insider information. But whistleblowers have been threatened with being "Shwartzed" since (e.g. have frivolous criminal charges filed, to make their lives hell). In every case I've seen, whistleblowers signed an NDA, a non-disparage, and backed down.
That's why I don't trust a !@#$% thing from MIT anymore. Lies and fraud get covered up. Once that starts happening, you can't trust anything.
These things don't lead to anything other than a rich guy getting his name on a building, and more corruption in academia. By far the best thing which could happen to MIT would be for 95% of the endowment to go up in a poof of smoke, bringing it back to nineties levels. That's the end of the period when the Institute did high-integrity research.
No, today institutions like Georgia Tech -- which has an endowment of just about the same as MIT in the nineties adjusted for inflation -- seem to function just about the same way as MIT did back then.
I want to get back to the era before people went to MIT as a center of wealth, power, and prestige, and would lie and cheat to get tenured positions there, to where it was a place where nerds went to nerd together.
And to a place where every !@#$% done didn't lead to a self-hyping press release, but where statements were precise, measured, calibrated, and most importantly, scientifically-accurate.
Anywhere the nerds or artists go, if they are good, eventually becomes overrun with such types. Just look at the state of Silicon Valley and y combinator, and gentrification in general…
Curiosity: Some facial biometrics are explicitly designed to they can't change over time, barring an accident or similar. They look at features of facial geometry such as eye versus nose positioning and similar kinds of things set by bone structure.
They're surprisingly hard to intentionally defeat. Growing a beard, putting on weight, etc. won't do it.
I looked into this some time ago, when I didn't want to be tracked. It turned out to be annoyingly hard. And e.g. "wear a hat and mask" makes you rather conspicuous.
The increasingly universal cameras are rather effective at knowing what you're doing at all times.
Having worked in / adjacent several such industries, a lot of the question depends on scale.
A trillion-dollar business can easily trade dollars for the privacy. A business with $1M to spend won't even get a phone call with OpenAI or Anthropic, who were the only* previous players in town for doing this.
Worst-case example: Bootstrapped startup working in military.
It's also the case that an open model enables many more intermediate-cost solutions. E.g. providers certified for specific applications, on-prem rentals, etc.
* Omitting Azure, which gives some privacy for some $$$ on their models, but not at the level of high-security.
> Worst-case example: Bootstrapped startup working in military.
That's the easiest case.
AWS Bedrock models running in AWS Secret Cloud for Industry. (I really have no affiliation with them, I'm just like... this is a completely solved problem, why do people think this is hard and requires on-prem hardware?)
I'm with GP that these are tinfoil hat concerns, when there are solutions to all of these, unless you're perhaps in some country with very specific needs beyond things like European sovereignty or US military secrets (like a non-US defense concern).
You seem to be categorizing everything that considers their data being in the possession of the US an unacceptable risk to be tinfoil hat, which is kind of an insult to a large portion of the world. If you haven't been paying attention to the news in the last 48 months, the political reality has shifted considerably.
Note that the other commenter never said US-based military oriented startup. You just assumed, then jumped to "heck yeah let's use Amazon Secret Cloud for Industry"
Not everyone has or wants an office in Crystal City.
> Omitting Azure, which gives some privacy for some $$$ on their models, but not at the level of high-security.
If I were ranking third parties on their ability to safely handle my data without compromising it, I would rank Anthropic pretty low for things like Fable (where they more or less promise that they will misuse my data), but I want Azure pretty low in the sense that I fully expect them to be compromised.
I would tend to trust Amazon to avoid being compromised.
At least for regulated applications I worked on, no one cared.
The provider needs to comply with specific rules, have specific certifications, and sign specific agreements. You check the boxes, and you're good to go.
Microsoft does that better than anyone. OpenAI and Anthropic don't do that at all. Google does that rarely and poorly. AWS is not bad, but not as good as Microsoft.
Azure was always my go-to for regulated applications in the cloud. Some do require e.g. on-prem or even air gap, where even Azure is out.
> Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in one subsystem only crashes that subsystem instead of crashing everything; if windows were a microkernel system then the crowdstrike bug would have just stopped some IT security staff from getting telemetry instead of being front page news. If linux were a microkernel system then the linux kernel team wouldn't be responsible for merging every driver for every hardware device, and wouldn't be responsible for vetting code that they would have to become experts on the inner workings of every chip supported by the linux kernel to properly vet.
Is false. In particular:
- A kernel-level exploit can almost always be escalated. If I control your filesystem, you're SOL
- A kernel-level crash in any subsystem brings down the whole system. If your file system crashes, or your GPU is in an unstable state, there is no coming back
- Modularity is a question of clear boundaries. Whether those are static linking, dynamic linking, or XML-RPC doesn't change the level of modularity.
And so on.
Basically, none of the upsides have panned out. On the other hand, code complexity explodes. Microservices need to know who to call how. The whole "a crash in one subsystem only crashes that subsystem instead of crashing everything" means every subsystem needs defensive code for things going wrong elsewhere. KLOCs go up, bugs/KLOC stay constant, and things get less stable.
Plus, it's hard to reason about systemically, and without excellent telemetry, neigh-impossible to debug.
What commercial microkernel systems are you referencing that suffer from trivial LPEs? Or whole system DoS from unprivileged code execution? To the extent that you argue your alleged failure modes are fundamental.
> none of the upsides have panned out
Again, what history? What proof? What evidence?
One of the stated upsides relative to monolithic kernels is superior reliability. There are numerous microkernels reliable enough for usage in critical flight systems. None of the standard commercial monolithic kernels are even in the vicinity of that.
Another of the stated upsides is superior security. There are multiple microkernels secure enough to be platforms for systems that need to be secure against state actors. None of the standard commercial monolithic kernels are even in the vicinity of that.
History has proven the opposite of your claims. The concrete evidence is the opposite of your vague unsupported assertions.
To get to microkernels, we're reaching for QNX and Minix.
Monolithic kernels won *hard* with good reason.
> critical flight systems
Hard RTOS is a whole different domain of engineering. You're very confused if you think the same principles apply to something which makes sense in a mainstream OS.
You did not claim that microkernels were less commercially successful.
You claimed that microkernels suffer from the same security problems that plague commercial monolithic kernels such as Linux, Windows, macOS, iOS, Android, etc.
You claimed without evidence, and I quote, “none of the upsides have panned out”.
In contrast, microkernels have completely dominated the field, displacing prior monolithic kernel solutions, in domains where reliability and security are not the lowest priority. All you have really supported is that the broader commercial IT landscape continues to prefer easily hacked systems as long as they can save a buck.
You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security." And you were somehow confused that security mattered for systems with no network connection.
FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority. Most of that is Linux, BSD, and friends.
> You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security."
That sentence is grammatical nonsense. Try again to articulate your point so it is coherent.
Furthermore, you have still failed to present any historical examples for literally any of your bullet points or articulate any of the claimed upsides you purport have failed to pan out. In contrast, I have pointed out two frequently claimed upsides, reliability and security, that have demonstrably succeeded to such a degree that prevailing monolithic systems were largely replaced with microkernel systems in domains where reliability and security are highly valued such as aerospace and defense. To the extent that monolithic systems are still used, they were either the legacy option that has not been replaced or chosen where cost reduction is the highest priority, not security and reliability.
> FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority.
Frankly, I find it baffling that you think that nuclear weapon systems, military jet fighters (which are network connected by the way), and commercial jetliners (also network connected) have lower reliability and security requirements than commercial networking equipment. And this is ignoring the fact that commercial networking equipment is some of the worst with respect to reliability and security. Cisco, one of the largest vendors in the space, routinely has trivial remote authentication bypasses allowing complete takeover. Here is one from last month: https://app.opencve.io/cve/CVE-2026-20181. One from earlier this year: https://app.opencve.io/cve/CVE-2026-20079. Or this one: https://app.opencve.io/cve/CVE-2026-20127. How about this one: https://app.opencve.io/cve/CVE-2026-20182.
Commercial networking equipment security is a joke. Find me literally any technical person who would claim that Cisco can defend against state actors. I will wait.
I can’t say I know much about kernels, but what you say rings true. It’s not unlike the micro service vs monolith argument. It depends on the use cases, but in a system where the micro services depend on each other, all you have is a distributed monolith. All the complexity and overhead, and none of the benefits. Keep dependencies close.
Device drivers as separate processes might not improve much the resistance against intentional exploits, but they would certainly greatly improve the resistance against bugs.
There are parts that are so simple that it can be practically guaranteed that they are bug free, e.g. the keyboard driver. Also the microkernel itself can be practically bug-free.
A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer.
On Linux I have seen cases when the GPU crashed, but switching to a virtual console and back avoided the reboot, by reinitializing the GPU, but I have also seen crashes when not even the keyboard worked, which should never happen, so a reboot was the only solution.
With device drivers in separate processes, bugs in one should not corrupt the memory of others, so restarting a device driver should be enough, instead of rebooting the computer.
> Microservices need to know who to call how
Here there is no difference between a monolithic kernel and a microkernel. With a monolithic kernel, the applications need to know which syscalls to use.
Libraries like libc or liburing can be implemented either by using syscalls to a monolithic kernel or messages to the processes that own peripheral devices, without any change in the API used by application programs. Obtaining memory pages shared with device driver processes can be done by creating file mappings for some pseudo-files with standard names, which has no essential difference from doing I/O by opening device nodes from the /dev pseudo-filesystem in UNIX-like OSes.
Any complex program must be designed from the beginning to be easy to test and debug. If the device drivers are distinct processes, there is no reason to be more difficult to debug them. On the contrary, because the interactions between them are more limited than when they live in a common address space, they should be easier to debug.
A micro-kernel with the associated device driver processes would contain more or less the same code that is now included in the Linux kernel or in any other monolithic kernel but it would be separated in multiple parts with clear boundaries and interfaces between them.
This can only make much easier the reasoning about how the entire system works. The downside is that the interfaces must be well defined. The history of Linux shows a huge number of badly defined interfaces, which later had to be changed. Even in the syscalls, which are supposed to be stable, there are many syscalls already at their fourth or fifth variant, with the previous variants still kept around despite being obsolete, for backwards compatibility with legacy programs.
Nevertheless, defining good interfaces is not that difficult, especially today when there is much less pressure to save every bit in a parameter list (even when taking into account the current memory prices). Most Linux interfaces that had to be replaced were replaced for not having features that were obvious as necessary since the beginning, e.g. for not having a parameter with option-encoding flags or for using some data types that were too small.
Funnily enough, "GPU" (video driver) on Linux used to be microkernel-like: the Xorg would run in userspace and talk to device directly. It was exactly as you described - if Xorg crashed, you could use keyboard shortcut to reinitialize it.
And the major motivators for KMS/DRM, which moved a lot of that functionality into kernel, was performance and stability.
> A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer.
Yes, it should be. I can name zero times in the past half-decade that it's been possible to soft-reset the hardware in my GPU.
The "reset the GPU switch" is the power switch on my computer.
That's true of most hardware. If my ethernet, wifi, or whatever else enter an unstable state, on paper, the monolithic kernel can do the same thing as the microkernel: unload the module, then reload the module. In practice, I've virtually never seen a driver able to pick up a piece of hardware in an unstable state and be able to "reset" it.
> With device drivers in separate processes, bugs in one should not corrupt the memory of others, so restarting a device driver should be enough, instead of rebooting the computer.
Device drivers can corrupt other devices easily enough. The hardware itself would need to be built for isolation.
> Any complex program must be designed from the beginning to be easy to test and debug. If the device drivers are distinct processes, there is no reason to be more difficult to debug them. On the contrary, because the interactions between them are more limited than when they live in a common address space, they should be easier to debug.
That's exactly the myth.
In practice, a complex data flow for a heisenbug might start at the network layer, go through the disk, and land on the GPU. Tracing that on a microkernel requires instrumentation which, while possible in theory, I've never seen in practice.
I'd love to see a hardware stack where everything is ECC, devices are isolated, etc. but for now, on a typical computer, plugging in a bad USB device can brick the whole system (regardless of the software on it). The assumption is that devices on your PCIe bus can be trusted.
> This can only make much easier the reasoning about how the entire system works.
You make very strong statements, without support.
There's a reason Linux runs on every Android phone, almost every router, and increasingly, devices like home microwaves.
Stock was down three-fold between its peak around 2019 and its bottom in 2024/2025. Indeed, it was down three-fold in 2024/2025 from its 2000 dot-com peak.
Basically, imploding company, on its way for collapse.
With AI boom, there was more demand for ICs than production capacity. It almost didn't matter how bad your chips were -- someone would buy them, and at a healthy markup. This placed Intel in a very strong position to recover.
That recovered some value -- going above their previous high, but much less than 25 years of S&P500 growth. However, it's worth remembering the peak of $120 was less than double it's dot-com peak 25 years prior.
If AI boom doesn't materialize, Intel may, again, be on a path to death.
If it does materialize, but like the dot-com boom with a few winners and many losers, Intel will likely be one of the losers.
Ergo, falling value.
NVidia, in contrast, looks a lot more like the Amazon of the dot-com bust.
reply