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

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?

As a person who has been managing Linux servers for about a decade now, trust me that a few hours or days of learning docker now will save you weeks if not months in the future. Docker makes managing servers and dealing with updates trivial and predictable. Setting everything up in docker compose makes it easy to recover if something fails, it’s it’s self documenting because you can quickly see exactly how your applications are configured and running.

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.

Exactly. Adding a third should be much simpler than a second.

As a fellow risc-v supporter, I think the rise of arm is going to help risc-v software support and eventually adoption. They’re not compatible, but right now developers everywhere are working to ensure their applications are portable and not tied to x86. I imagine too that when it comes to emulation, emulating arm is going to be a lot easier than x86, possibly even statically recompilable.

I’m both surprised and not surprised that ever since the M1, Intel seems to just be doing nothing in the consumer space. Certainly losing their contract with Apple was a blow to their sales, and with AMD doing pretty well these days, ARM slowly taking over the server space where backwards compatibility isn’t as significant, and now Qualcomm coming to eat the windows market, Intel just seems like a dying beast. Unless they do something magical, who will want an Intel processor in 5 years?

All else being equal, a complex decoding pipeline does reduce the efficiency of a processor. It’s likely not the most important aspect, but eventually there will be a point where it does become an issue once larger efficiency problems are addressed.

We stuck to x86 forever because backwards compatibility and because nobody had anything better. Now manufacturers do have something better, and it’s fast enough that emulation is good enough for backwards compatibility.