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...
lol - if they were only that altruistic. Toyota doesn't make the tech, they buy modules from suppliers and integrate the tech. Better hope someone doesn't come out with a fancy super module that has everything integrated because there will be no disabling it as soon as that happens :/
Don't forget Toyota was the manufacturer that was going to charge a monthly subscription just for the key fob (!) to work until they got a massive backlash over it. A freaking key fob that doesn't use cellular or the cloud at all - it's 100% local between the fob and the car. And don't think for one minute that they won't try to sneak it back in.
> Better hope someone doesn't come out with a fancy super module that has everything integrated because there will be no disabling it as soon as that happens
I was just thinking about how to find and disable all the microphones in a car and realized that, with software, any speaker can be used as a microphone, so the logical conclusion is that you'd have to disable all the speakers as well.
> Better hope someone doesn't come out with a fancy super module that has everything integrated because there will be no disabling it as soon as that happens :/
FWIW, getting to that fuse is a massive, massive pain in the ass on some of their newer cars like the 2023 corolla. It's basically not possible. The alternative requires taking off the dash and manually pulling out some wires.
In the process you may lose some functionality like some speakers, the radio, wireless android auto, microphone, etc.
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.
That's interesting, do you think the poor DX is due to not enough effort being made to make it more useful for outside devs, or because making it possible to do verification makes other things ugly and inconvenient?
I was considering seL4 for a hobby project (having worked with L4Ka:Pistachio a long time ago), but didn't dig deep enough to spot these problems.
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?
Tesla has caused a lot of confusion by calling this system "full self driving", but in reality, this system is an SAE level 2 driver assistance system where the human is required to be in charge of driving at all times.
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
That's how it is. It's up to compositor to decide what events to send to what clients. Usually this means compositor only forwards input events to the focused surface.
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.
But imagine if Linux used the BSD license and FreeBSD used the GPL license. Absent any other philosophical changes to how each project was managed, I don't think the incentives to upstream projects would be any different. Sony would dump a bunch of code on their website somewhere (which would be excellent, because others could study and use it as desired), and little else would change.
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.
Do you mean it's miserable to develop the seL4 microkernel or do you mean it's miserable to develop applications on top of seL4? If the latter, is it any different from any other microkernel?
It's as if the engineering team didn't want to develop a spying product and made a convenient way to disable it...