Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isn't clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.
The code used in cve-rs is not that complicated, and it's not out of the realm of possibility that somebody would use lifetimes like this if they had just enough knowledge to be dangerous.
I'm as much a rust evangelist as the next guy, but part of having excellent guard rails is loudly pointing out subtle breakages that can cause hard to diagnose issues.
I recently bought a 7800 XT for the same reason, NVIDIA drivers giving me trouble in games and generally making it harder to maintain my system. Unfortunately I ran headfirst into the 6.6 reset bug that made general usage an absolute nightmare.
Open source drivers are still miles ahead of NVIDIA's binary blob if only because I could shift to 6.7 when it released to fix it, but I guess GPU drivers are always going to be GPU drivers.
But it's not a binary "we're fucked" or "we're fine", it's an ever worsening gradient of terrible conditions. Even within that, how many people get the brunt of it depends on the extent of the damage.
I am curious about why performance cores would go with a no-smt implementation; the die area improvements are obvious, but how are they going to spend that die area improvement to make up the performance gap?
AVX only really affects a small subset of applications, so I can't see that going too far.
A better branch predictor could be a boon, but given how good they are already I'm not sure how they could make up the 50% multi threaded loss.
Perhaps just cramming more physical cores together and a better cache sharing mechanism?
The link you posted has nothing to do with this SoC?
You're not going to get 2.5G over wireguard on the 3588, but you are definitely going to get over 1G.
Wireguard scales well with cores, but due to the way big.LITTLE is implemented on the 3588, it could lose performance if it tries to split the workload between core complexes.
I'm sure the developers are competent, but the reason I care about the design decisions is the same reason the electric brakes on cars don't interface with its infotainment system; the interface inherently creates opportunities for out of spec behaviour and even if the introduced risk is tiny, the consequence is so bad that it's worth avoiding.
If you have to have an airbag be controlled by software (ideally the mechanism is physical, like a pull tab), it should be an isolated real time device with monitoring your accelerometer and triggering the airbag be it's only jobs. If it's also waiting to hear back from another device about whether your subscription ran out before it starts checking, the risk of failure also has to consider that triggering device.
It can be done perfectly, but it's software so of course it has bugs.
That information changes none of my issues; if you don't see the plethora of potential implementation bugs involved, either you don't code professionally or you shouldn't be.
Yes, but also from an implementation perspective: if I'm making code that might kill somebody if it fails, I want it to be as deterministic and simple as possible. Under no circumstances do I want it:
checking an external authentication service.
connected to the internet in any way.
have multiple services which interact over an API. Hell, even FFIs would be in the "only if I have to" bucket.
America isn't even the most democratic country in the Americas, but that's clearly not the point they're making.
If the title was "...end of world democracy" you'd have a point but given how much fascistic rhetoric and policy has increased around the world since trunpism it's fair to say many countries are following the US lead here.
Relationships only really feel like jobs in this way when you feel your effort is not being reciprocated. Doing emotional labour for your partner is not exhausting if you feel like you are equally pulling each other up.
I feel like the branches we're making and rebasing must just be less complicated than other companies, because I've never found the rebase process scary?
Rebase, find the conflicts, sort them out, add the files, continue. It helps if you do so on a regular basis while working on the branch. It's a bit involved sure, but scary?
Typically no, the top two PCIE x16 slots are normally directly to the CPU, though when both are plugged in they will drop down to both being x8 connectivity.
Any PCIE x4 or X1 are off the chipset, as well as some IO, and any third or fourth x16 slots.
So yes, motherboards typically do implement more IO connectivity than can be used simultaneously, though they will try to avoid disabling USB ports or dropping their speed since regular customers will not understand why.
Most firewalls are at their safest when you first get them i.e by default they block everything coming in. As you start doing port forwarding and the like you start making the network selectively less secure; that's when you have to pay attention.
I had an EdgeRouter X for years before I started my job. They are solid devices, and I'd definitely put them above most consumer routers.
Because they only charge for the hardware, they will eventually run into the same disincentive to provide consistent timely updates. If you do buy an Ubiquiti or similar enthusiast brand, do still keep an eye out for the CVEs that don't get patched.
I build Linux routers for my day job. Some advice:
your firewall should be an appliance first and foremost; you apply appropriate settings and then other than periodic updates, you should leave it TF alone. If your firewall is on a machine that you regularly modify, you will one day change your firewall settings unknowingly. Put all your other devices behind said firewall appliance. A physical device is best, since correctly forwarding everything to your firewall comes under the "will one day unknowingly modify" category.
use open source firewall & routing software such as OpenWRT and PFSense. Any commercial router that keeps up to date and patches security vulnerabilities, you cannot afford.
Yes, the problems rust is solving are already solved under different constraints. This is not a spicy take.
The world isn't clamoring to turn a go app into rust specifically for the memory safety they both enjoy.
Systems applications are still almost exclusively written in C & C++, and they absolutely do run into memory bugs. All the time. I work with C almost exclusively for my day job (with shell and rust interspersed), and while tried and tested C programs have far fewer memory bugs than when they were first made, that means the bugs you do find are by their nature more painful to diagnose. Eliminating a whole class of problems in-language is absolutely worth the hype.