Feyd did a pretty good job of outlining the AUR disclaimers in a different comment so I won’t do that here. It’s true that Arch won’t stop you from shooting yourself in the foot, but again it’s nuts to claim that routine compiling is the usual case for all rolling distros and belies your claim that you’re familiar with usual case experience. There’s absolutely no routine experience where you’re regularly compiling.

I’ve used debian and apt-get most of my life, I’ve used arch on a pinetab 2 for about 6 months, regularly playing with pacman and yay and someone who’s never met me is saying I’m a fanboy for being familiar with linux package management. 🤷‍♂️

Gimp is a gigabyte larger as a flatpak

one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to

My understanding is that constantly triggering compiling like that shouldn’t be happening in any typical arch + pacman situation. But it can happen in AUR. If it does, I think it’s a special case where you should be squinting and figuring out what’s going on and stopping the behavior; it’s by no means philosophically endorsed as the usual case scenario for packages on arch.

There’s certainly stuff about Arch that’s Different™ but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.

iit: nerds unable to comprehend that building a piece of software from source in not something every person can do

huh? Using package managers almost never involves compiling. It’s there as a capability, but the point is to distribute pre-compiled packages and skip that step in the vast majority of cases.

Also pretty much everywhere you’re using flatpaks (or snaps or…), you are doing it on top of a Linux system that’s still getting its core system updates via traditional dependency management. And flatpaks, despite trying not to, make assumptions about your kernel, your glibc version, architecture, ability to access parts of your filesystem or your devices, that can break things, and doesn’t bother to track it.

And the closer you get you tracking that stuff (like Snap tries to), you hilariously just get back to where you started, with traditional dependency management that already exists and has existed for decades.

It destroys the beautiful and carefully cultivated ecosystem of distributed packages that has been the bedrock of Linux for decades. They’re bloated, often not quite as sandboxed as claimed, have created packaging chaos, and assume availability of system services that may not be there.

Not even remotely true, this is a myth. Most of what they spend is on development, operations, and legal. They publish their 990 online which gives the breakdown. IIRC the foundation gets like 2%.

Slightly more than 1% of their annual revenue.

Also Ubuntu for me. It had a golden age, I want to say 2006-2015ish.

Love Rhythmbox! I used it way way back when I first installed Ubuntu (back when it was good) and it was part of a special nostalgic feeling of having been ushered into this new linux world, and I think it lets you rate your songs 1-5 stars (if you want) and I had a lot of fun doing that.

You said not a high budget, and yet everyone here is saying Framework even though the they are $900 to $1,000 at the low end. To me that is not budget.

Pine64 is affordable but maybe too slow to be a daily driver, unless you feel confident finding your way through ultralightweight software and the command line and can do most of your problem solving that way.

For other pre-built options, there’s Starlabs and System76 but those are similarly priced to Librem and Framework.

Beyond that I might just research Windows laptops that are agreeable to being formatted.

Apparently it’s feeling the Lemmy hug of death: https://archive.is/Z9Udy

It also took me a second but I got there

Never thought I would see a version of “all lives matter” but applied to web browsers

Daily reminder that Brave uses Chromium, an open source project where all the commits are approved or denied by Google devs.

Idk why but I love this post haha

You can’t for a number of reasons. As other people have said this catastrophically underestimates the complexity of maintaining a code base for a browser.

they’re often 3–5 years behind other browsers in implementing new web standards

I don’t even think that’s remotely true. My understanding is that it’s on the order of a few months to a year, and it relates to things that are negligible to the average end user. They are edge case things like experimental 3d rendering. The most significant one I can think of is Webp, but they resisted adoption for principled reasons relating to Google’s control over that format and aggressive pushing of it, which is a good thing not a bad thing, and an important example of how rushing to adopt new standards it’s not necessarily just a sign of browser health but also an anti-competitive practice intentionally pushed by companies that have money to throw around for that purpose.

They wouldn’t be at the mercy of anything. That’s…how open source works.

That’s how Chromium works.

Anyone can see the source, but it doesn’t mean that anyone’s code makes it into Chromium, because Google picks and chooses. Chromium has a “reviewer pool” of Google developers doing all the picking and choosing. Getting into the reviewer pool takes months to years of building up a contribution history and being vetted by the Google team.

They’re completely at the mercy of how Google integrates things like DRM, or web standards that Google wants to push, like a deeply integrated into the browser and actively maintained with little to no alternative. The engineering overhead of sustaining and increasingly complex fork of Chromium is unsustainable and unless you have the development capability to compete, Google controls the destiny of any chromium browser.

You’re right about the fact that building an engine is hard, but Socraticly speaking, then why are there so many blink-based browsers and so few gecko-based ones? The answer is because blink is easy to embed in a new project and gecko isn’t.

Okay, that’s an interesting point. I mean, there are forks galore of Firefox so I’m not entirely sure I understand. But certainly chromium-based browsers have been getting more traction.

But wasn’t the original point something about how hard it is to make a browser?

And if I have this right you’re suggesting that it would be achievable for Firefox to make an accessible browser tool kit but they’re not due to ulterior motives?

I’m not sure I understand that, either in terms of motive or just impractical terms what it is you think they’re doing to make it hard to develop.

Hold on, why are we talking about this like it’s something that’s not happening? There’s all kinds of forks of Firefox.