![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
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.
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.
I think it is this way because Apple thought it would be misleading if the option was “deny tracking”, because there isn’t a specific technical mechanism to ensure that. It’s unfortunate but I’d rather it was honest than lied.
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.
Most people shouldn’t self host. It’s a hobby for people who want to do it, and there are benefits, but spending 3 hours on a weekend fixing stuff is not how most people wish to spend their time. Furthermore, it’s not a good use of most people’s time. We split labor up into specialties, forcing people to do work outside their specialty causes pointless inefficiency. I agree with what other commenters have said in that a better approach would be to have more small businesses hosting federated together, and anyone not inclined to self host should just purchase service through one of those many small providers instead.
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.
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.