I hope that System76 invest into adding accessibility support into Iced, because they are using it to build Cosmic (the official desktop environment for Pop_OS).

They've committed to adding accessibility features. Iirc COSMIC right now has screen reader, magnification, and high contrast/invert colors support.

There is a really long way to go though, and accessibility on mobile comes with its own challenges as well. It will take a long time.

This sounds like a good opportunity for a 3rd party e-ink screen for the framework laptops.

AFAIK if the project has a rust-toolchain.toml[0] file, cargo will download the correct compiler for the project.

[0] https://rust-lang.github.io/rustup/overrides.html#the-toolch...

Well, an underrated aspect of the Rust rewrites, is that it's easy to publish and share official libraries from the projects that the community can use, something that is too hard in C land.

If anything, from a security standpoint, this is one of the bigger issues with a rewrite in Rust. Besides the "MIT EVERYTHING" mindset, Rust people are also similar to JS devs in having projects with huge supply chain attack surfaces, from their eagerness to rely on so many crates.

On the flip side C/C++ devs like to let ancient libs hang around because updating them can be such a pain in the ass.

You can choose to write Rust with fewer external crates or vendor them like you would with c++ that is a dev choice.

Having more choices is better.

I agree this is problematic, sure, and is not unique to Rust or JS. Feel free to propose and work on something better, I'd be your enthusiastic supporter.

It's simply a way to be able to move at a reasonable speed is how I see it.

You are not the target then, but people using Gitlab might find insightful.

Would be cool if companies are forced to open the devices that they aren't supporting anymore.

Is Arch ARM officially supported by the same team? If not, what might be the reason?

x86_64 is the only official Arch Linux. All other ports are unofficial. They are community projects where many of the members are the same as the main Arch Linux.

I think it's basically for the same reason as why they dropped 32-bit x86 support about 8 years ago. Not enough users. (That resulted in the unofficial Arch Linux 32 to maintain support.)

Arch is working to officially support ARM and non x86_64 archs.

https://rfc.archlinux.page/0032-arch-linux-ports/

That RFC says "New ports are added by proposing them in an RFC. At least two package maintainers have to lead a port to ensure it will be developed longer term." but I'm not finding any RFC for ARM support, so can one say work is really officially happening on ARM?

The first step is setting up the project to allow other ports. That it can be done, what it will require, etc.

Once that’s done, then the ports can be submitted.

Look at the maintainers and contributors on the unofficial arm port. Orce this RFC gets accepted, the arm port can propose and figure out how to merge things together.

Yeah, that sounds right to me, and sounds like you're agreeing with me that it isn't yet an official effort, as the RFC hasn't yet been merged, in contrast to what parent claimed.

I think the reason is they don't want to become debian where deciding anything takes foverever. Another architecture is a liability, so it lives in another "project" that official arch is not committed to.

I write this from arch on arm (orange pi) thingy, btw

Ads are annoying, but they are ok, what is not ok is collecting data and then selling it, so they can profile you without your consent across different platforms.

The implementors of the banners did it in the most annoying way, so most users will just accept all instead of rejecting all (because the button to reject all was hidden or not there at all), check steam store for example their banner is non intrusive and you can clearly reject or accept all in one click.

From the video looks like it's already usable, with Lua or some other scripting language it could be a good alternative to vim or helix.