The difference is how you interact with the browser engine. Blink is very easy to embed into a new browser project. I’ve seen it done - if you’re familiar with the tools, you can build a whole new browser built around the Blink engine in a few hours. You can write pretty much whatever you want around it and it doesn’t really change how you interact with the engine, which also makes updates very simple to do.

With Firefox, it’s practically impossible to build a new browser around Gecko. The “forks” that you see are mostly just reskins that change a few settings here and there. They still follow upstream Firefox very closely and cannot diverge too much from it because it would be a huge maintenance burden.

Pale Moon and Waterfox are closer to forks of Firefox than Librewolf for example, but they’ve had to maintain the engine themselves and keep up with standards and from what I’ve read, they’re struggling pretty hard to do so. Not a problem that Blink-based browsers have to deal with because it’s pretty easy and straightforward to update and embed the engine without having to rewrite your whole browser.

Unfortunately, since Google controls the engine, this means that they can control the extensions that are allowed to plug into it. If you don’t have the hooks to properly support an extension (ie. ublock), then you can’t really implement it… unless you want to take on the burden of maintaining that forked engine again.

That said, Webkit is still open source and developed actively (to the best of my knowledge - I could be completely wrong here). Why don’t forks build around Webkit instead of Blink? Not really sure to be honest.

I chuckled a bit while reading this, because what you wrote is exactly where Blink came from. It was a fork of webkit, which in turn was derived from KHTML. Then again, the fact KHTML was discontinued does support your point to an extent too, I guess.

But the point is, Chrome is doing exactly this - providing the engine free as in beer and letting people embed it however they like. And yet, what you’re predicting, ie. not using the original but just using forks instead, doesn’t seem to be happening with Chrome - they still enjoy a massive fraction of the market share. There’s no reason to believe that this couldn’t happen at Mozilla as well. People usually want the original product, and it’s only a small fraction of people that are really interested in using the derivatives.

Ironically, the anti monopoly lawsuit against Google will end this.

People are quick to assume this, and there’s a very good chance that they’re right, but I don’t think we should take it as a given. It’s always possible that there could be some sort of court decision that allows Google to keep funding Mozilla after the “breakup” is complete.

In any case, we don’t yet know what the outcome of the antitrust case will be, so I think it might be best to avoid making statements of certainty like this until we see how things really shake out.

We should definitely take the possibility of this happening very seriously though.

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.

If Mozilla really wants to take back the web (and I honestly don’t think they actually do), then what they should really be doing is making gecko as easy to embed in a new browser as blink is. They don’t do this, and I suspect that they have ulterior motives for doing so, but if they did, I think we would be much closer to breaking chrome’s grasp on the web.

Because let’s face it: Mozilla makes a pretty damn good browser engine. But they don’t really make a compelling browser based off it. Ever noticed how Mozilla has been declining ever since they deprecated XPCOM extensions? It’s because when they provided XPCOM, it enabled users to actually build cool and interesting new features. And now that they’ve taken it away, all innovation in browser development has stagnated (save for the madlads making Vivaldi).

They need to empower others to build the browser that they can’t. That’s what would really resurrect the glory days of Firefox in my opinion.

This has always been the whole point behind the Trojan Horse that is systemd. Now that Poettering/Red Hat control the entire userspace across virtually all distros, he/they can use it as a vehicle to force all of them to adopt whatever bullshit he thinks of next.

This is what the Linux ecosystem gave away when they tossed their simple init system to adopt the admittedly convenient solution that is systemd. But in reality, the best solution was always to drop init, and instead replace it with an alternative that was still simple to replace if the need should arise. But now that everyone is stuck on systemd, they’re all at the mercy of Poettering’s Next Stupid Idea.

Convenience comes at a price. systemd is the Google Chrome of Linux userspace. Get out while you can.

Not just the hardware. I far prefer icons from that time as well. I hate the modern trend of flat icons with no details. They look like someone mashed them out after 5 minutes in Krita and then drugged their management into believing that it was a recreation of the Mona Lisa.

Search engines are websites that people used to go to in order to get helpful information. These days, they just spam out a bunch of SEO garbage, AI-generated bullshit, and ads.

Google, probably

Yes, a lot of developers have done this. Many examples have been posted on this thread (OsmAnd, Conversations, Davx5) - Mindustry is another example. free on f-droid (and Google store too I think), but $10 on Steam.

Not necessarily! I always run ln -s '/usr/bin/$EDITOR' $(which $EDITOR) after a fresh install, so I have a valid executable on the path called $EDITOR.

Of course, then I have to make sure to add export EDITOR=\$EDITOR to my .bashrc. (Obviously.)

It was always obvious to me that as long as I was using closed source software that any day could come when the vendor would screw me over. In fact, it could have been running it with bundles and bundles of spyware already and I had no way of knowing it. So I pledged to start using open source software only, to make sure that wouldn’t happen. First, I migrated all my desktop applications to open source alternatives. Then I finally made the switch.

I don’t have any suggestions, but this is incredibly impressive. I haven’t heard of jmp.chat before, but it sounds like you can create multiple identities using different phone numbers - is that correct?

If so, that sounds amazing. I really hate how the modern world is trying to force people into a singular identity online, and the way that they’re using phone numbers to do it. This sounds like it could be a pretty decent method to avoid that.

+1, I would recommend neovim with lazyvim. The documentation is excellent, and it’s very easy to set up.

https://www.lazyvim.org/installation

What exactly is it that people obsess over? The desktop environment and terminal customisation? Setting up NetworkManager with nmcli? Using Vim to edit a .conf file?

Welcome to the crowd! Eventually, you realize that an operating system is just an operating system: something you use to get work done, and the less you notice it, the better it’s doing its job. The pride of setting it all up mostly ends very shortly after you’re done. At that point, you realize that pretty much all distros are the same, give or take.

That said, there are always moments that make you realize that your OS is amazing. When you’re faced with a new and difficult task that you don’t know how to achieve, then you look at your distro’s documentation and solve it in a few elegant steps. And I’m not an Arch user, but that’s when the Arch wiki will really be your friend, as well as all the other resources that Arch has for its users. I can’t think of examples of these kinds of moments because they’re so rare, but those are the moments that feel great and really make you appreciate your OS.

One for every current ~0.5% market share!

I’m not sure what you mean when suggesting Linux is a singular implementation around which features are exclusively designed. There’s all kinds of software that runs on all kinds of different OSes. Userspace applications, for example, can take advantage of POSIX compatibility to ensure that they run on all platforms (Linux, BSDs, even Windows).

Does systemd have any similar sort of compatibility guarantee? Can I run systemd-whateverd on BSD? Can I run systemd itself on BSD? I’m pretty sure most other init systems support at least one other OS if not more. Would the maintainers even support merging patches that do this? What about musl?

I am also a Void user, but will agree that the installation process can be very difficult, especially if you want to set up encryption in ways the standard installer does not support. You have to install it into a chroot (which I believe is how Debian was installed 20+ years ago).

That said, it is a great learning process and really helps you appreciate how awesome xbps is as a package manager!

I believe you’re thinking of Gentoo. But it seems that you can get precompiled kernels in Gentoo these days.

+1. systemd is something the Linux ecosystem really needs, but its execution is abysmal. We should be designing around standards so the best product can win. We should not be designing around singular implementations that could make it easy for Red Hat to execute a EEE strategy to consolidate Linux on the workstation.

I can’t wait till a crowdstrike-like flaw is exposed in systemd so we can all see how terrible^W wonderful monocultures can be.

The full write-up can be found here and should be fairly readable for users of this forum.

Some quotes that I thought were interesting:

With a heap corruption as a primitive, two FILE structures malloc()ated in the heap, and 21 fixed bits in the glibc’s addresses, we believe that this signal handler race condition is exploitable on amd64 (probably not in ~6-8 hours, but hopefully in less than a week). Only time will tell.

So 64-bit systems seem to be a bit more resistant to this it seems? But I can’t be completely sure given how much I’ve read about this yet.

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd’s privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

It seems that non glibc-based systems also could be vulnerable, but they have not yet tried to demonstrate it yet (or have tried and not been successful).

And OpenBSD wins again it seems.

I just use the lazy plugin manager (not to be confused with lazyvim) to set up a few plugins for my environment. I followed this guide and just chose only the plugins and configuration that I like. I’ve used vim for over 15 years now but have only used plugins for the past 2-ish years, so I don’t like it when distributions mess up existing keybindings and other default behaviors. Lazy makes it very easy to set up your own environment and I was able to learn how to do it in a relatively short time with some guides and tutorials.

It’s not for the faint of heart, but for me, I think the personal customizability is worth it, as well as not having plugins installed that I don’t want/need. A lot of the time, they’re more modern, but they would also require unlearning my existing habits and learning new ones, which I would rather not do, so I prefer doing it this way.

But I will say that it can be helpful to look at existing distributions to see how they implemented configurations when I run into trouble with my own configurations. Sometimes I’ll steal their keybindings and maybe adjust them to my own preferences. It’s also a great way to explore new functionality and configuration options as well.