To add a little bit: the reason for that (or at least one of them) is strict aliasing rules:
If the compiler had to assume that a write to an int* might change the value of a double&, that’ll cause it to avoid some optimization and maybe even perform expensive reads.
This is the reason that you are not allowed to alias a variable with another type (can be disabled using -fno-strict-aliasing) [1].
However, one of exceptions is char and std::byte. The compiler is not allowed to assume that a write to char& won’t affect the value of a double& for example [2].
No idea why the downvotes, these are valid points. I still don’t fully agree with it:
1. There are alternatives to nvidia: these 3 companies are probably developing their own alternative to NVIDIA, at some point they will switch to their solution or to competitors (for example: google used TPUs to train Gemini 3 [1], with no nvidia GPUs, despite being a pretty large Nvidia customer).
2. The market seems to be consolidating: for example Apple has decided to use Google Gemini for their new Siri [2]. I’m not an export (or future teller), but I think it increases the chance that other companies might follow and get off the AI race.
3. I am sure that OpenAI and related companies would want to sustain these kind of orders, but I am not sure it is possible without more and more funding, and I don’t know if even Sam himself know to estimate how many GPUs they will be able to buy from Nvidia in 2026.
According to nvidia’s 2025 annual report [1], 34% of their sales for 2025 comes from just 3 customers.
Additionally, they mentioned that customers can cancel purchases with little to no penalty and notice [2].
This is not unique for hardware companies, but to think that all it takes is just one company to get their sales down by 12% (14b$).
To cut to the point, my guess is that nvidia is not sustainable, and at some point one or more of these big customers won’t be able to keep up with the big orders, which will cause them to miss their earnings and then it will burst. But maybe i’m wrong here.
[2] same, page 116:
> Because most of our sales are made on a purchase order basis, our customers can generally cancel, change, or delay product purchase commitments with little notice to us and without penalty.
Edit:
Kinkora implies that it has something to do with kinks, at least that was my first impression.
My guess is that it means something in another language, but maybe this is not a good first association that you would want for a AI image generation product that can be used in a professional setting.
I think that reading all of the information from the SSD should “recharge” it in most cases. The SSD controller should detect any bit flips and be able to correct them.
However, this is implementation detail in the SSD FW. For Linux UBI devices, this will suffice.
It will trigger reads in random areas in flash, and try ti correct any errors found.
Without it, the same issue as in the original article will happen (even if the device is powered on): areas in the NAND were not read for long time will have more and more errors, causing them to be non recoverable.
Hopefully it will make Qualcomm behave more like Arduino and not the opposite.
Qualcomm is one of the worse companies I have had the pleasure to work with.
Their support model is hellish and they provide very little information and documentation, so usually you’ll end up doing a lot of guessing and reverse engineering. They will tell you to sign a contract with one of their “design partners”, but even they can’t get answers for basic questions.
Seriously, if they want more small cap companies working with them they have to treat them better, I worked with them as a small company and as a larger company and in both cases their support was basically non existent even if we were buying chips from them for more than 10m$ a year.
Tie that chip to a beamformer (silicon labs have a few) and you have a phased array radar, which is a radar that does not move at all (pretty cool in my opinion)
Also, 15usd is not cheap for this kind of chip. You can buy a full wifi 7 rf/modem or a 4 core arm64 soc with this kind of money.
I think that while data is a major point here, in my opinion, these are the reasons apps are preferred by developers:
1. Persistence: while websites are very easy to close, deleting an app is much more difficult and usually requires pressing on some “red buttons” and scary dialogs. It also makes sure the user now has a button for your app on their Home Screen which makes it a lot more accessible.
2. Notifications: while they exist for websites too, they are much less popular and turned off by default. Notifications are maybe the best way to get the user to use your app.
And while I hate the dark patterns some companies use (Meta, AliExpress, etc), I do understand why installing the app worth so much to them.
The article is a bit strange. While GPS can be used to receive accurate timing (phase correction once per second), for gps less navigation, even a picosecond accurate atomic clock wont really give any additional benefit compared to a wirst watch.
Using an accurate clock, you might be able to detect spoofing (by detecting small “jumps in time”).
However, the same should be possible even with a non accurate clock (a few ppms) by detecting conflicts between the different satellites timings (since the “fake” transmitter is on earth, it will never be able to accurately simulate the real satellites’ airtime delays from space to your specific reception location).
On the other hand, if you pair a very accurate clock with a very accurate gyroscope, you might be able to replace gps altogether (https://en.m.wikipedia.org/wiki/Inertial_navigation_system) But from my knowledge, these kind of gyros are not really available for sale (but this is already outside of my knowledge, so maybe something changed).
Maybe i am missing something but while it is interesting, I dont think it has any real security impact.
Since the threat model is that the attacker and the victim are connected to the same router via the same wifi network, not isolated from each other, in a case where you are using wifi in psk for example, the attacker can already sniff everything from other clients.
Therefore, you can spoof packets by just responding to them directly. It is a lot simpler and takes a lot less time (since you just need to respond faster than the server with the right seq and port numbers).
Once you are in the same network you can do even crazier stuff like arp spoofing and then let the victim think that you are the router and convince it to send all of its packets to you (https://en.m.wikipedia.org/wiki/ARP_spoofing)
Edit: on a second thought, maybe in a use case where the victim and the attacker are in different wifi networks (or just configured to be isolated ), the attacker should be able to perform a denial of service for a specific ip:port by sending RST and then ACK with every possible source port.
In my experience in two HW companies that developed their own ASICs (one as a startup and one as a publicity traded company), we never developed any chip fully by ourself. In all of the cases there was another large company who helped to make the project work so we will actually end up with wafers.
If you are not at the scale of NVIDIA/intel and release a new silicon every other month, it is not worth it to recruit so many people for a relatively short period. However, I am not fully sure how involved they were in the pre-silicon verification process, but at least in some cases they were very involved in the development.
Not sure i am following, what problem your product is trying to solve? helping to write tests/run the tests/just organizing tests as a part of the CI pipeline? How is it different than just running tests? (Or is it the platform to run tests on?)
If you are trying to do CI for silicon, then what is your target market? From my experience, companies that design their own silicon are usually big enough to have their own custom pipeline for testing and verification and it would be quite difficult to convince them to switch. Smaller companies get help from larger companies in development and verification.
Do you have any tooling that won’t require the developer to write tests? (E.g. something that will ‘work’ with no effort from the developer’s POV - kind of sonarqube for vhdl/verilog)
In any case, good luck. Glad to see some HW-related startups.
From my experience, the biggest footgun with shared_ptr and multi threading is actually destruction.
It is very hard to understand which thread will call the destructor (which is by definition a non-thread-safe operation), and whether a lambda is currently holding a reference to the object, or its members. Different runs result different threads calling the destructor, which is very painful to predict and debug.
I think that rust suffers from the same issue, but maybe it is less relevant as it is a lot harder to cause thread safety issues there.
As for the second, There is no shell=True for me in the demo but it is present in the code you sent. So maybe it is just a bug in the presentation somewhere.
This is the reason that you are not allowed to alias a variable with another type (can be disabled using -fno-strict-aliasing) [1].
However, one of exceptions is char and std::byte. The compiler is not allowed to assume that a write to char& won’t affect the value of a double& for example [2].
[1]: https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...
[2]: https://en.cppreference.com/w/cpp/language/reinterpret_cast....