Certain cars let you physically disable this. For example, the Tacoma has a "Data Communication Module" (DCM) that performs all of this and has a cell radio to phone home. There's a fuse in the fusebox you can pull to prevent the DCM from getting any power. Only side effect is the in-cabin microphone stops working and you can reconnect the fuse at any time.
It's as if the engineering team didn't want to develop a spying product and made a convenient way to disable it...
I'm guessing it is less about proof of stake and more about the fact that all of crypto is in the gutter and it's not as economical to mine anymore. I would guess that is the big core issue that is enhanced by things like proof of stake. Kind of a perfect storm when paired with inventory issues and crazy inflation. I think that storm is what he is saying they couldn't have predicted.
As someone who worked with seL4, it's because the development experience is literally the worst you can possible have. It's zero fun and anyone who has to deal with it inevitably ends up hating seL4. It exists to brag about verification, developing real applications on it is a fool's errand.
iirc the car does all the driving but you have to have a hand "on the wheel" so they don't technically have to legally classify it as a self driving car or something.
I'm guessing if he is videoing it and hovering over the wheel that much this has happened before and he is nervously expecting it?
iirc it's pretty much completely up to the compositor. The spec is worded to allow "focus" to enter a surface and deliver events to it, but it never specifies under what conditions the compositor should do so.
So the compositor chooses what surface to deliver events to based on its own desires (like letting pointer focus enter background apps) and the users input. I think there is a protocol (used by Xwayland?) to allow a client to get events from any window if the compositor/user allows it
I am biased but FreBSD is very well supported on NVIDIA, so I wouldn't let it hold you back from trying it out. I think you could load NomadBSD on a usb and have NVIDIA drivers set up without any real trouble.
I always understood the argument to be that for rapidly changing projects you might be forced to upstream your GPL code or face an uncomfortably high maintenance burden of constantly rebasing it. Linux almost purposefully does this, it's kind of like a "soft" vendor lock in. Linux kernel interfaces change regularly, and if you don't upstream your code you need to commit time to fixing what breaks. If you upstream, then someone else will handle updating your code for you for free. The more regularly they churn the internal interfaces the more it costs to maintain external patches and the more appealing upstreaming becomes.
The end result is lots of companies jamming their code upstream because it is cheaper (or they are soft-required) to do so, not because it is good for the project. The benefit is you have large corporate contributions, with the possible downside that the companies want to take your software in a different direction than you do (i.e. Microsoft embracing/extending).
The BSD license doesn't try to strongarm people into contributing, and the BSD projects are open to being a base for other projects. This is bad because companies may not contribute back to you. It is good because it means that you don't have 20 companies pressuring you do make decisions. They've gone in their 20 directions and they want you to continue to be a solid base for them to build on.
I think a lot of people (me included) like the feel of this way more. When you read through FreeBSD you don't see the legacy code from a bunch of corporations mixed in, you just see the good stuff. People contribute because they want to even though it's more work, versus reluctantly contributing because it's less work. Not saying permissive licenses are perfect and don't have their own problems, just explaining why they might have different advantages.
One interesting workaround I saw recently was to pass an 802.11ac device to linux running in bhyve. I have yet to try it, but it seems like potentially the best short-term solution if you have a bsd laptop where wifi is the only thing not supported.
If you want something more hands on you can try "FreeBSD Device Drivers: A Guide for the Intrepid" by Joseph Kong. It is much easier to read, and my guess is you ran into it while making those BSD patches.
He also has a short book on building rootkits for BSD, which is a very fun read and demonstrates how things like system calls work.
If you want a guide to reading actual kernel code, here is a great resource explaining where some of the foundational pieces are. With a tool like cscope, reading the FreeBSD kernel is actually pretty easy.
My project was to port DOOM to the seL4 microkernel (on rpi3b+). To continue with that I’ve been porting NetBSD Rump kernel components to seL4 as well.
DOOM itself is a breeze to port. NetBSD can get confusing at times but it’s nice to know there’s always a logical reason behind the design decisions. It rewards you for spending time to understand the code and I like that. Rump kernels are especially cool.
It’s a myth that you can’t get paid to work on BSD ;)
It's as if the engineering team didn't want to develop a spying product and made a convenient way to disable it...