I’ve seen some optometry equipment running RHEL

About a year ago I moved to Hyprland & Wayfire for my NVIDIA & Intel boxes. Moved NVIDIA to Radeon a few months back and had mixed results.

Recently tried Plasma 6 for experimental HDR and am impressed.

deleted by creator

No, I’m saying that when people run into strange bugs, sometimes they put together an issue (like the person behind cve-rs), and sometimes they quietly work around it because they’re busy.

Seeing as I don’t often trawl through issues on the language git, neither really involve notifying me specifically.

My lack of an anecdote does not equate to anecdotal evidence of no issue, just that I haven’t met every rust developer.

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.

If someone did, why would I hear of it?

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 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.

deleted by creator

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?

This and crucially he is beyond the age at which he can have his understanding of (and fear of) death moulded (brainwashed) to the weird Jedi dogma.

You can make people do some really fucked up shit if you can disassociate their emotions from the deaths of those around them.

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.

The difficulty is that a VPN isn’t just a product like ProtonVPN, it’s a huge family of software and protocols.

You can block vpn.protonvpn.com, but since most operating systems come with VPN functionality out of the box, you’d have to start listening to all traffic (not just DNS lookups) and blocking ALL packets that might be VPN traffic without causing regular disruption to non-vpn traffic.

TL;DR: it’s easy to prevent unmotivated users from downloading a VPN app. It’s practically impossible to block a motivated user from using a VPN, and they’re the users you particularly care about.

What kind of idiot workplace would allow that? Perhaps if you don’t assume the people you talk to are literally brain-dead, you might understand what they’re saying.

hat’s a bad faith interpretation of “the people control the means of production”.

I want you to consider the difference between the work needed to complete a task, and the work needed to manage a workplace: for one of those tasks, only the experts in that task can meaningfully contribute to the outcome, whereas for the other, everybody who is part of the workplace has meaningful input.

I don’t know about your experience, but everywhere I’ve worked there have been people “on the ground” who get to see the inefficiencies in the logistics of their day to day jobs; in a good job a manager will listen and implement changes, but why should the workers be beholden to this middleman who doesn’t know how the job works?

I’ve also had plenty of roles where management have been “telling me where to cut”.

Sure, but that’s not necessarily a bad thing; if the Linux version is missing useful output that would be bad, but if the DX to Vulkan translation ironed out a performance regression, or the scheduler works better in this scenario, or filesystem access had issues with NTFS it could also cause performance differences in Linux favour.

It opens the door to more manufacturers since there is no ISA licence fees. While the AMD/Intel duopoly is being fairly competitive at the moment, it really doesn’t have to be. Only think back to how bad it was late 2000s to 2015.

I imagine a plethora of core designers, soc vendors and platform creators filling their own niches; lowest cost, lowest power, HW accelerators, highest core count etc.

I don’t see the raw performance of AMD/Intel being surpassed soon, just because of the sheer total R&D years each has, but that doesn’t mean there aren’t other areas better suited to a different architectural approach.