> It's wild to me that 10gbit isn't the norm by now
I honestly just don't need it. Part of that is my ISP options top out around 1200Mbps, certainly. But I also just don't need that kind of speed inside my home. Streaming video needs at most 20Mbps or so, and I don't do much in the way of large file transfers. And when I do large file transfers, it's usually from or to the internet, and my home network is not the bottleneck there.
Why would you be sharing that? There's no reason why the navigation system needs to constantly tell a remote system where you are. Navigation systems don't even need an Internet connection for basic routing.
Navigation through gps means you're connected to a satelite at all times. has nothing to do with an internet connection. You're directly connected to the U.S. government (Space Force)
A GPS receiver is passive, it doesn't send any signal to the satellites. The satellite broadcast their position and what time it is from their point of view, and the receiver computes its position from that.
Also, there are now several countries that sent positioning constellations (obviously to not have to rely on the US for positioning), and most receivers support several: GPS (US), Galileo (Europe), Glonass (Russia), Beidu (China).
It reveals where you are to the cell towers, but not to the car company. My phone already reveals where I am based on its cellular connectivity, so I'm not too worried about that.
I'm pretty sure they have a legal obligation in most jurisdictions not to sell 0days for profit.
And they absolutely have a moral obligation to do things in a way to minimize damage and impact to other people's systems. (I'm not saying "responsible disclosure" is the correct way to do that, but hoarding vulnerabilities and exploits and selling them to the highest bidder certainly isn't.)
It is categorically false that there's a legal obligation not to sell vulnerabilities. There's an obligation not to knowingly sell them directly to ongoing criminal enterprises. That's it. Plenty of people make fuckloads of money selling vulnerabilities for exploitation rather than repair.
(The buyers are the NSA, the IDF, Cellebrite, NSO and its successor corporation and that kind of thing. Depends on what you are offering)
You'll learn who the buyers are if you routinely have the really good stuff to sell! If you are offering iOS zero click on a semi-regular basis, the buyer is going to want to try to deal with you directly and preferably offer you a more regular form of employment, if you are interested. Some national governments may offer certain benefits to you, depending on your situation.
All depends on what you have to offer. If you were able to offer this https://arstechnica.com/security/2025/09/microsofts-entra-id... or something of that magnitude, a lot of problems in your life would just go away. The buyers would all be Five Eyes and the intelligence gain of having that kind of access even briefly is priceless.
In a more Western-centric context, imagine if you had a flaw like that, same 'no logs are generated' and 'every single customer account is accessible' but the impacted vendor was Alibaba Cloud. The researcher would get to name their price. That's the real world, that's the world we share. We shouldn't be blind to that.
That's not how this worked. Cloudflare was not involved at all. Spanish ISPs were ordered by Spanish courts to block their customers from accessing specific IP addresses.
The libsanitizer library is imported from the LLVM sources into the GCC source tree. There are probably more examples of code sharing. Both projects are quite large.
Unless they have patents on their fan impleller geomeries, the IP they're referring to is likely just trade secrets. Trade secrets do have legal protections in the US, but those protections are mainly about disclosing or stealing those secrets, not about physically inspecting something and deriving the trade secret that way.
Not sure about the tech aspect of 3D scanning or if that would be accurate enough; I don't have any experience there to draw on.
> every single meeting room and common area in this building is designed around the consumption of alcohol--the long bar downstairs, the meeting room modeled after an airport lounge, the meeting room modeled after a smoking club, the meeting room / roof deck...
To be fair, this could describe a lot of successful tech companies back in 2014.
> I wondered back then, is this the end of the company? [...] Perhaps so, but perhaps not
As much as that stuff was often pretty toxic and super not inclusive, I think Microsoft is nearly 100% to blame here for Github's decline.
And even though all the drinking was really not great, in some ways I do miss those days. They were fun. Then again, I'm in my mid-40s now and can't drink and party like that anymore. Today, even a single night out with 3-4 drinks (plus twice as much water) over the span of 6 hours or so makes me a useless lump of garbage for half of the next day.
This made me think of Github's charity dodgeball tournament. The last one was in 2016. For an entry fee that went to a donation to charity, your company could field a dodgeball team. It was super fun, and we (at Twilio) attended for several years.
While I'm not going to say they stopped because of Microsoft (they didn't get acquired until 2018, though I would expect that talks were probably underway by sometime in 2017), the loss of something like this does feel emblematic of how tech culture got significantly less fun toward the end of the 2010s, and the pandemic just killed the rest of it for me.
(Of course, "fun" is in the eye of the beholder. It's possible that my tastes just changed as I got older.)
I think it's more accurate to say that Wine contains some components that are emulators, not that it is an emulator. Sure, it has to emulate the x86 MMU's segmentation behavior, because Linux doesn't set it up the same way. It has to emulate x86 interrupt & CPU exception delivery, because Windows delivers those to applications in a different way than Linux does. For some very old programs, it has to emulate I/O ports and some device behavior. I think GDI and DirectDraw require emulation of a framebuffer and palette hardware.
But the vast majority of Wine's code is not emulation; most of it is a clean-room reimplementation of the win32 APIs, a PE/COFF loader, Windows registry, etc. All of those parts are implementations of API contracts and binary format parsers, not emulation, in the same way that GNUstep is a reimplementation of NeXTSTEP/Cocoa, and not an emulator. (The main difference being that Wine can run Windows executables unmodified, whereas GNUstep expects you to recompile/relink from source. That is a sizeable difference, but not an emulator-sized difference.)
And yes, the computer science definition of "emulator" doesn't specify hardware: it's simply a system that reproduces the externally observable behavior of another system. But if we follow that definition too closely, then things that are clearly not emulators become emulators. Like musl and glibc are emulators of the C standard library (or of each other?), Android is an emulator of the Java virtual machine, and Mesa's software renderer is an emulator of OpenGL or a GPU (that latter bit is tempting, but it really isn't a GPU emulator). At this level, "emulator" just means "abstraction layer", which makes it pretty useless as a term if we take it that far.
So I think "WINE Is Not an Emulator" is true. It contains some bits that are absolutely emulators, but it is not, in its entirety, an emulator, and emulating isn't the function of the bulk of its code.
(I'm not trying to be pedantic here; this was actually a fun thought exercise about emulation in general and Wine in particular.)
I honestly just don't need it. Part of that is my ISP options top out around 1200Mbps, certainly. But I also just don't need that kind of speed inside my home. Streaming video needs at most 20Mbps or so, and I don't do much in the way of large file transfers. And when I do large file transfers, it's usually from or to the internet, and my home network is not the bottleneck there.
reply