Sure, I have crappy mobile reception a lot of times on my travels, so I'll be the first when finally Starship can launch satellites with antennas big enough so that my mobile phone can directly be used for internet access.
I hope not. Musk can directly go to hell with his shit.
Nonetheless, the 10 Billion and 60 Billion deal with Cursor is weird as hell. I can only imagine that he wants to throw as much money at all of his shit before the IPO.
Sure, then good like paying twice as much for the next Opus / Codex models.
Margins are going up for the 2 frontier model providers like crazy, and I don't expect it to go down more, I think we have seen the cheapest token prices already.
Mistral is just not as good, saying this as a European, sadly. I support them and would like to see them get better in their models, for chat especially as that is what I use. Dont use any CC, APIs etc.
I avoid using and buying Chinese things due to the country. That is my view. They will turn on us too.
Microkernels have lost the open kernel wars because of their speed problems, but this is a great example of a driver that should have been running in userspace a long time ago, just like how Windows has been moving in that direction.
I guess things are going into that direction naturally, but not officially. eBPF is helping with getting deep kernel aspects into userspace. And there's some ressurgence of out-of-tree graphics drivers, specially for gaming.
I believe userspace drivers are much more powerful and easy to build than 10 years ago, but it is not from a requirement from the kernel.
Who knows, maybe we will get a smaller (instead of bigger) kernel in 10-20 years
Luckily I'm not a kernel maintainer, but it seems like they don't have 10-20 years to make hard practical decisions. It's easy to get rid of old unmaintained drivers, but they have to solidify interfaces much more as it is getting exponentially easier to find and use bugs or any unspecified part of the kernel for attacking it.
There was a very interesting point when people who were creating Rust interfaces were asking hard questions about ownerships and lifetimes in driver interfaces from the C linux maintainers and they didn't really care to answer (just wanted to wish Rust away).
Now with AI these questions are getting practical. Fortunately big companies have big stake in keeping linux secure, so I'm not worried about it being addressed at least.
> this is a great example of a driver that should have been running in userspace a long time ago, just like how Windows has been moving in that direction.
Hasn't windows (nt lineage) moved solidly in the opposite direction? Used to be you could reload/restart the video card ("GPU") driver if the driver crashed?
No it's the opposite. WDDM and DirectX are constantly being updated and have been improving crash recovery of the GPU, updating its driver, power management, abstracting features like video encoding and storage DMA, among many things. In Linux it is taking ages, the first proposal for DRM to support 2010 era WDDM features was in 2021 and it still does not exist. Graphics is one of the few places some of Microsoft still innovates. Although not in the sense of having great code, they just put in the work to coordinate these changes from the handful of vendors. If only someone hosted more steak dinners for Linux.
I think this conflates two different eras/layers. NT 4 famously moved the window manager/GDI/graphics subsystem into kernel mode, so that’s probably the “opposite direction” history. But modern GPU-driver recovery is WDDM/TDR, and it very much still exists: WDDM splits the display driver into user-mode and kernel-mode components, and TDR resets/recovers a hung GPU/driver instead of requiring a reboot.
I also update NVIDIA drivers regularly on Windows 11 without rebooting, though that’s install-time driver reload rather than exactly the same thing as TDR.
And I don't recall any practical way to recover from a crashed NT 3.x GUI subsystem.
It would presumably still function as a server, and be gracefully shut down remotely, but in the absence of anything like Remote Desktop or EMS[1], you'd be hard pressed to get much local troubleshooting done without rebooting the system anyway.
Also, as an NT user since 3.1, and a daily user of 3.5 and 3.51, I don't recall the GUI ever actually hanging or crashing (other than as a side effect of a bugcheck, which, by definition, is a crash triggered by code running in kernel mode).
That's one of the main reasons I was an early and enthusiastic NT user: while I can't say its performance was any better than "good enough", and then only on hardware that was at least comfortably above average in terms of CPU speed and RAM capacity, it was remarkably stable compared to every other PC OS I had used at the time.
Which, to be fair, would have been limited to MS-DOS, 16-bit Windows 2.x and 3.x, and OS/2 2.0 at the time, though it remained true throughout the lifespan of Windows 9x and OS/2 (at least through 3.0, the last version I used), and neither FreeBSD nor Linux were as reliable once you added at least a basic X11 environment to reach rough feature parity (and while X11 did allow recovery after crashing, insofar as it can be restarted without rebooting the system, it still took all your GUI applications and xterm windows down with it when it crashed).
You can't do it with zero kernel code for ISA devices, but if there was a pci busmouse, uio + uio_pci_generic would work for reading the mouse, and you'd use uinput to send the events to the input stack. If you're willing to make a little uio stub driver for the interrupt, you can do it for ISA. UIO is from 2006 or something.
tldr; it's there but nobody is interested in reinventing ancient pre-PCI drivers, so there's no generic ISA plumbing.
There's already KernelBench which tests CUDA kernel optimizations.
On the other hand all companies know that optimizing their own infrastructure / models is the critical path for ,,winning'' against the competition, so you can bet they are serious about it.
reply