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.

As someone who primarily uses Unix-like systems and develops cross platform software, having windows as a weird outlier is probably best for the long term. Windows is weird and dumb but it forces us to consider platform differences more explicitly. In the future if a new operating system becomes popular, all the checks that were implemented for windows will make it a bit easier to port to newer systems.

That’s true for all commercial development. No company wants to invest more than they have to. Upstreaming does save time in the long run, but not in the short term.

I don’t think this is as much of a problem, proprietary hardware is a thing on x86 too. The two big problems are a lack of boot standardization, and vendors not upstreaming their device drivers. A lack of standardization means it is difficult or impossible to use a single image to boot across different devices, and the lack of upstream drivers means even if you solved the boot process, you won’t be able to interface with peripherals without using a very custom kernel.

It’s work, I don’t get much of a choice here. I do get paid for the hassle though.

Debian or Ubuntu are usually the best choice if you depend on glibc. Alpine is definitely more compact but musl isn’t always an option.

I do this stuff for work, unfortunately I don’t have the flexibility to choose here.

Sorry I was way off in my assumption that the venv package is a few hundreds kilobytes. apt is reporting 6144 bytes. 6 kilobytes. Installing python on the base bookworm image is 38.3MB. If you’re already installing python, it’s a rounding error. Also they have a separate python3-minimal package (which saves a laughable 200kb), why are they de-featuring the regular python version when they also have a separate minimal version? It makes zero sense. The python3 package should contain the entire python standard library. If it were supposed to be an addon, it wouldn’t be part of the standard library.

This is the kind of crap that makes me glad flatpak and such exist. I don’t want a maintainer making arbitrary decisions like this, it adds unpredictability and platform inconsistency.

A similar issue I face is that on Debian the python stdlib well… isn’t all standard. In particular they split off the venv package, and it’s an extra step that adds unnecessary complication. No other Linux distros or other OS do this, it’s so frustrating. I guess someone is super happy they saved a few hundreds kilobytes of disk space though.