> The way to manufacture more efficient compute now is do things like put DRAM closer to the chip and even closer integration between CPU and GPU. The fact that Apple can co-design their silicon such that the CPU and GPU can pull from the same pooled RAM is a major advantage over competitors.
> When you have CPU, GPU, and even DRAM sitting on the same "die
Apple has been really successful convincing people they've done something special here. Given how many people are so horribly misinformed about this I'd go so far as to call it false advertising.
No, the DRAM is not on the same die. It's on package. They're literally standard SK Hynix memory chips.
Yes technically there's a latency advantage, but comparing M1 to DDR5 desktop chips Apple actually has worse overall memory latency.
Every integrated graphics chip from Intel and AMD has had unified memory for the last 10+ years.
Compute itself is also not what makes the Apple chips get long battery life. Looking at tests under full load the M1 is significantly worse than the latest Intel or AMD, yet it still gets better battery life under normal usage. The efficiency does not come from compute but from a whole host of idle consumption optimisations Apple brought over from their phone chips.
Indeed, on an HP Elitebook with a Ryzen 8840U I get about 20 hours of battery life on CachyOS (but downclocking a bit, with TLP) and the speed tests claim this is like a M2-3. For like $500 (before RAM went up...)
If the returned value is still valid despite an error, then the function would return (u32, Option<Error>), perfectly valid rust. If the value is meaningless in case of an error then using it is incorrect code; you wouldn't want to do that in either language and rust makes that assumption explicit with unwrap. If you want a default value in case of error just use unwrap_or_default.
Significantly less so than before, but it's unfortunately still the case. It's also just now getting features that people have been asking for for over a decade, and of course due to the nature of Wayland the implementations of these features are sporadic and inconsistent.
I think the main difference is that there aren't really any deal-breaker kind of bugs any more, and as far as features there are none missing that users care about compared to X11. It's mostly just annoying bugs and the usual "third party" (including KDE) apps looking off in GNOME because the devs can't reach an agreement on some things, users be dammed.
That reminds me of Microsoft's Active Desktop in Windows 98, when the desktop had widgets that were web pages and would show webpage-related errors when something went wrong. We've really gone full circle over the last three decades.
It's not really using it for much text, though. It's mostly buttons and controls, which GDI, QuickDraw, and Motif did much better back then and newer toolkits like GTK, Tk, wxWidgets, DWM, Cocoa, etc are great at today.
All these games already have an authoritative server. These cheaters aren't breaking the rules of the game by being invincible, super speedy, etc. they're aim-botting and wall hacking. Those cheats can't be prevented with authoritative networking.
I dont know what kind of authoritative server Apex Legend uses that let the infamous "Tufi" hacker do what he did for so long. IMO it should be trivial to ban someone hitting more than 80% of their shots as headshots,, dual weilding weapons that were never supposed to be dual-weilded. Charge rifle beam permanently shooting and swapping armors from miles away
There's a big difference between authoritative networking with some security holes and non-authoritative networking. Note also that hitting 100% headshots is entirely within the rules of the game; it has nothing to do with the networking implementation.
Sometimes user can partially see them, game client would need that position. Then user can make a mod that flashes silhouette that just appeared behind a wall for a moment.
you run into some really difficult to solve issues when it comes to the gameplay loop, the graphics engine, and network latency trying to solve that unless you are playing some sort of turn based game where all data can be resolved before the next action
And yet there's plenty of competitive multiplayer shooters that work fine on Linux. Rivals, The Finals, deadlock, CS2, Overwatch, Hunt Showdown, etc.
EA did a big announcement about switching to kernel level Anti-Cheat for Battlefield 6 to combat cheating, yet there's still plenty of cheaters around. It's looking more and more like an excuse in order to give the appearance of combating cheating.
> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog.
> During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases.
Some corrections:
Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break backwards compatibility.
Python saw 5 major releases, each breaking backwards compatibility. Counting all releases they had 132.
Node has an LTS every year. There were 6 LTS versions in the last 6 years. Those releases also included major breaking changes.
Go had no new major version, like rust it's only made minor changes.
So going by the author's own evaluation, rust and go are considerably better for project decay.
> For example, I just looked at the dependencies of a small project I'm working on, and we have 5+ (!) different crypto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto
ring is explicitly an experiment, not suitable for use. My guess is the author looked at their Cargo.lock to determine what duplicated dependencies they have.
For the uninitiated, rust libraries can have optional dependencies that only get included under certain conditions. A common pattern is for a library to support multiple underlying implementations, such as different crypto libraries. For instance rustls has both ring and aws-lc-rs as optional dependencies, meaning that both get included in the Cargo.lock file when resolving dependencies. That doesn't mean that both are actually being used.
Yeah on top of that I've seen virtually no evidence that Rust projects really decay. I bet you can compile some really old Rust projects with the latest Rust with no problems.
In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is:
1. Go. Very reliable.
2. Rust. Also very reliable.
3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently.
4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently).
Yeah, it's pretty weird that they're hating on the six week release cadence because...they think the changelogs are too long? Just don't read them then!
The rustcrypto crates seem a lot better maintained and will probably supplant ring in future. Ring maintenance seems hostile to use outside of expected use cases.
My Kyocera will work in orbit and withstand intense radiation. In fact, this very moment my new Duraforce Pro 3 is having fun in a launch-testing thermal/vac chamber.
Kyocera's 'flagship' is high-reliability phones in absolute garbage environments.
Samsung's 'flagship' overheats and earns them class-action lawsuits.
Motorola's 'flagship' is a hinged throwback to the 90s.
Apple's 'flagship' is an overpriced piece of vendor lock-in.
Meanwhile my phone takes serious abuse and laughs at it. I've dropped it and watched it go more than 700 feet down the side of a mountain (Chambless Skarn) and BARELY chip the screen protector. Waterproofing still intact. Case barely scratched.
What you consider a flagship phone is a brittle piece of junk in my hands.
That's not a radiation hardened chip, it's regular off-the-shelf consumer electronics. The "solar radiation" test they advertise is part of MIL-STD-810H. It tests whether the electronics survive regular sunlight on earth. The only ionizing radiation this phone is rated for is UV light.
At least if it had registered memory there might be an argument that it has some radiation resistance, but no it's plain old LPDDR4x.
Ulefone Armor 29 Ultra has the same MIL-STD-810H conformance with "radiation hardening", 16GB of RAM and a flagship Dimensity 9300+. Just not a removable battery.
Funny because the Qualcomm sm7450-ab snapdragon 7 gen-1 page lists itself as only supporting LPDDR5.
>also do you mean perhaps Strontium-90?
Nope. Strontium-60. 25 year half life compared to Sr-90's ~29. It's what we like to use in real space-environment testing on the ground. Nasty stuff.
>source?
You can actually probe your hardware and see what sort of ECC is enabled on a Droid phone. In this case, in-line ECC, so that means some of the RAM is actually sacrificed for error correction instead of having a dedicated extra chip (256 bit, 240 of that is data 16 bit is error correction.) What's awesome about that is that enabling ECC is simply a bit flip in firmware and you don't need the extra RAM modules installed - the installed memory can already do it. You don't need the extra hardware.
> Nope. Strontium-60. 25 year half life compared to Sr-90's ~29. It's what we like to use in real space-environment testing on the ground. Nasty stuff.
> If people wanted removable batteries in their phones, they would buy them a lot. They don't.
This argument gets thrown about every time companies make anti-consumer changes, and it completely ignores the information asymmetry and other dynamics at play. When I go to the store to buy a new phone, where does it list on the box how repairable the device is? Where does it show how expensive the repair will be? If I'm locked in the apple ecosystem, where do I buy an iPhone with a replaceable battery?
Your assumption that the market is driven by informed consumer choices presupposes that every buyer is an expert.
I don't have the evidence to say either way, but I do know that at least my city has a lot of cellphone repair businesses, including mall kiosks. Presumably they have enough clientele to keep them going which suggests a lot of people are repairing their phones.
> When you have CPU, GPU, and even DRAM sitting on the same "die
Apple has been really successful convincing people they've done something special here. Given how many people are so horribly misinformed about this I'd go so far as to call it false advertising.
No, the DRAM is not on the same die. It's on package. They're literally standard SK Hynix memory chips.
Yes technically there's a latency advantage, but comparing M1 to DDR5 desktop chips Apple actually has worse overall memory latency.
Every integrated graphics chip from Intel and AMD has had unified memory for the last 10+ years.
Compute itself is also not what makes the Apple chips get long battery life. Looking at tests under full load the M1 is significantly worse than the latest Intel or AMD, yet it still gets better battery life under normal usage. The efficiency does not come from compute but from a whole host of idle consumption optimisations Apple brought over from their phone chips.
reply