Not necessarily. If you trust the code running on your device then there is no backdoor they could install on a server that would break e2ee. They would have to backdoor the client where the keys are.

If it’s anything like ChromeOS, it’ll be a VM where you can do whatever you want, within that VM.

Your default types for that are i32 or u32. It’s the exact same number of characters yet encodes more precise information.

I’m aware of packing, but for my specific niche the main bottleneck is CPU, and it’s important to minimize the amount of memory usage to improve data locality, increasing cache hit rates, ultimately increasing cpu throughout. Any gains we would make by packing such small values would likely be eliminated by the cost of unpacking them, unless it’s a flags-like value where we are primarily comparing individual bits.

I’ll be honest if that’s your complaint, I have a hard time believing you would find the equivalent C or C++ code to be better.

Cargo being an all-in-one tool is actually one of my favorite things about the rust ecosystem. It’s many things, and it does it all seamlessly.

Regarding comparing to C or C++, how can you argue either is designed better? C, while standing the test of time, predates so many modern programming concepts or standards and writing C code is extremely error prone. C++ improves on many of C’s shortfalls, but it wasn’t designed. It’s the result of different things being loosely bolted on to C over the course of 30 years. And it’s still error prone, for example while there are smart pointers and other types that can make writing memory safe code possible, they’re not default and they aren’t always fully supported in the standard library, let alone anything else.

I do systems programming work, sometimes with constrained memory scenarios. We always want to use the smallest types we can for any task, and unless negative numbers are a necessary, always prefer unsigned. That means a lot of u8 and u16 unless we know a value is likely to need more bits to be represented. Probably doesn’t matter as much in we programming but that’s not Rust’s niche (or well not its original niche).

It does define minimum sizes for different types. An int for example is at least two bytes, whatever size those might be!

In the branding, but the name of the installed applications in the UI do not contain “gnome”.

Is gnome that bad? They seem to have been moving away from weird names for many years now.

continuously fighting against awful software

Arguably this is why some people don’t bother with a VM and use the web apps instead.

VSCode’s vim plugin is pretty great for full-color graphical terminal users

The part you’re missing is that while C++ does have newer safer ways of doing memory management, all the old ways are still present, in wide use, and are easier. Basically, C++ makes it easy to do the wrong thing and hard to do the right thing, and most codebases are built around the wrong things. It’s often easier to just rewrite it in rust than it is to refactor an existing code base, so if you’re going to expend that effort why not do it in a language that has stronger safety guarantees, a better dependency and build management system, and a growing community?

I guess I don’t see the point of removing pocket from the build since it can be disabled in a standard Firefox build with a single about:config option. That’s what I do.

Heretical, you will burn in hell

True Temple OS has no networking

Tor browser is something else, I don’t group it in with stuff like Librewolf.

For librewolf, I just took a look to try and figure out what binary blobs are being talked about. This is the repository I was looking at, I think its the right place: https://codeberg.org/librewolf/source/src/branch/main. There isn’t much documentation on the patches besides the file names for the most part, but do you have any idea which of these relates to binary blobs? Or is it in the settings file? Really nothing I see here convinces me that this project is worth anybody’s time over regular firefox, it just changes some defaults, disables pocket (they patch it out, but there’s already a setting), and changes the branding. I don’t disagree with most of their changes, I just don’t see the point of maintaining and marketing an entire derivative browser for what could just be a settings hardening guide on a wiki somewhere.

I do genuinely believe that these Firefox forks are mostly pointless rebrands of Firefox to satisfy a small crowd of people who are fine with Firefox but don’t want Firefox or Mozilla branding. Other than branding, they tweak the default config, pre-install ublock origin, and that’s about it. I guess this one exposes some already existing about:config flags in the settings UI. The best part is they are managed by small teams that run a few versions behind Firefox persistently, leaving 0-days unpatched and thus their users vulnerable. Their small userbase also opens their users up to tracking that wouldn’t be possible with larger browsers.

Instruction decoding takes space and power. If there are fewer, smaller transistors dedicated to the task it will take less space and power.

Well, not exactly. You have to remove instructions at some point. That’s what Intel’s x86-S is supposed to be. You lose some backwards compatibility but they’re chosen to have the least impact on most users.

I also haven’t wanted an Intel processor in a while . They used to be best in class for laptops prior to the M1, but they’re basically last now behind Apple, AMD, Qualcomm. They might win in a few specific benchmarks that matter very little to people, and are still the default option in most gaming laptops. For desktop use the Ryzen family is much more compelling. For servers they still seem to have an advantage but it’s also an industry which requires longer term contracts that Intel has the infrastructure for more so than it’s competitors, but ARM is also gaining ground there with exceptional performance per watt.