I’m not insisting anything; stating C is not a memory-safe language isn’t a subjective opinion.

Note I’m not even a Rust fan; I still prefer C because it’s what I know. But the kernel isn’t written by a bunch of Lewis Hamiltons; so many patches are from one-time contributors and the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching. Linux is written by monkeys with a few Hamiltons doing their best to review everything before merging.

Linus has talked about this repeatedly over the past few years at numerous conferences and there’s a reason he’s integrating Rust drivers and subsystems (and not asking them to fork as you are suggesting) to stop the kernel stagnating and to begin to address the issues like one-off patches that aren’t maintained by their original author and to start squashing the volume of memory corruption bugs that are causing 2/3rds of the kernel’s vulnerabilities.

No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.

These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).

The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.

You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).

Rust forces safe® code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.

This slogan was from the 90s (1993/94 maybe?).

deleted by creator

Ship a new app then. Sonos already do this for older products.

Whoever the fuck thought a massive regression for every single customer was the perfect thing to deploy with no option for rollback needs to stop working in software.

You’re right. They’re terms far older than web development. In general the front is the abstraction while the back is the logic/processing. It started as a term for old, large (room-sized) systems where there were front-end machines such as plugboards or terminals, with back-end machines being the CPUs, memory, etc.

Conway’s Law applies in this respect; the mess in governance of Nix has produced a product that reflects that mess. Nix started a beautiful movement but like many first movers, they rarely reap long-term rewards.

He’s been here the whole time!

I don’t know about deduping mid transfer but these two have been helpful over the years:

• dupeguru
• czkawka

Especially since, to calculate current location, it needs an input of initial location (i.e. it needs GPS coordinates to begin with so it can track direction and velocity relative to that initial position). You can’t replace something you depend upon.

We will find out when they push the update.

Only Google’s proprietary extension has encryption. The actual industry standard specification of RCS has no encryption defined at all.

Edit: It turns out Apple have refused to use Google’s proprietary encryption implementation and are instead working with GSMA to update the RCS Universal Profile specification to finally have encryption defined and standardised so that any RCS client can handle encrypted payloads (whereas only Google Messages today can do encrypted RCS and requires other users to be exclusively using Google Messages otherwise messages are sent unencrypted).

Because everyone is too distracted by “Apple bad” to realise how truly awful RCS is.

Bingo. RCS is yet another proprietary protocol, one controlled by Google (GSMA who originally designed it have practically forgotten about it for a decade) and without an open specification. RCS also doesn’t have a standardised approach to encryption as it’s designed for lawful interception.

So unless Apple have licensed Google’s implementation and extended version of RCS, this will be a shitty, insecure way to communicate between the Apple Messages and Google Messages apps and nothing more.

Google did an impressive job applying pressure and suggesting RCS was a perfect solution when in fact it’s just putting more control in Google’s hands. RCS is not an open “industry” standard. You nor I as individuals can implement it without paying license fees to see the specification and fees to have our implementations tested and accredited.

And Google have extended GSMA’s RCS with their own features (such as encryption) which is not part of the official standard and they haven’t made open either.

If Apple had been pressuring Google to implement the iMessage protocol or whatever, we’d have been up in arms (and rightfully so).

But instead of us all collectively hounding Apple and Google to ditch proprietary protocols and move to open ones such as Matrix, Signal, XMPP, etc (ones where we could all implement, use open source software clients, etc) we’ve got this shit:

Proprietary, insecure, non-private communication protocols baked into the heart of hundreds of millions of devices that everyone is now going to use by default instead of switching to something safer, private, public, open, auditable, etc etc.

BleachBit is a great alternative and it’s open sourced under GPLv3.

I’m European

0.63 Empire State Buildings. So yeah, quite a bit.

“Even more reason to switch to Linux!”
Linus Torvalds

Michael Scott

AMD began submitting Zen 5 patches for Linux this time last year and have been steadily submitting in anticipation of Zen 5 / Ryzen 9000.

So technically they’ve already released Linux support.

Edit: Proof from kernel.org showing Zen 5 named specifically.

Edit: I’m a dumbass. Ryzen AI 300 isn’t on Zen 5 but XDNA 2. XDNA support has been open sourced by AMD on GitHub and, according to a developer, they are trying to get it upstream too. The are committing to that repo all the time so I wouldn’t be surprised their XDNA 2 branch is merged in time for release.