Ladybird Browser - die Google, die

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
What is the point of Ladybird if we already have shit like Goanna-based browsers that can run perfectly fine with site compatibility (sometimes), have documentation for hardening, have enough extensions, and have been here for years. This only has a support base/blew up in popularity because Redditors/normgroids who either don't know about Goanna or think its outdated and insecure. We already have an alternative and yet they won't use it.
 
What is rust and why is it bad? Can someone explain it in laymen's terms?
What is the point of Ladybird if we already have shit like Goanna-based browsers that can run perfectly fine with site compatibility (sometimes), have documentation for hardening, have enough extensions, and have been here for years. This only has a support base/blew up in popularity because Redditors/normgroids who either don't know about Goanna or think its outdated and insecure. We already have an alternative and yet they won't use it.
I haven't used a goanna based browser in 4 years, but last time I did (K-Meleon & Baskilisk), half of the websites were broken and the iframes (or at least I think that is what they are called) didn't work.
Has anyone tried using a WebKit browser? I haven't done so in a really long time, and I wonder how they compare to everything else.
 
What is rust and why is it bad? Can someone explain it in laymen's terms?

I haven't used a goanna based browser in 4 years, but last time I did (K-Meleon & Baskilisk), half of the websites were broken and the iframes (or at least I think that is what they are called) didn't work.
Has anyone tried using a WebKit browser? I haven't done so in a really long time, and I wonder how they compare to everything else.
from what I know version 30something+ added a lot more compatibility support and besides JS-heavy sites taking a wee bit to load and lagging I see its the best actually in alternative browser engines.
WebKit browser
qutebrowser's webkit right? Excellent browser with very little hardening options but its perfect for what I would need if I didn't care a lot about it. Unlike Pale Moon Cloudflare turnstiles block your ass
What is rust and why is it bad? Can someone explain it in laymen's terms?
trannies
 
Now I am waiting for Nazis to create a LibreBird fork in the clean Aryan C language so we can move on from the dirty Jewish Ladybird project. Oh wait I use GNOME, fuck.
Redots' founder released freebird. Now they have two projects where they'll mooch off the main repo to release "their own" hecking chud project.

What is rust and why is it bad?
The only thing that actually matters for ladybirds case is compile times. Rust is notorious for large compile times, especially for larger project.

Everything else is mostly just muh trannies n shieet.
 
What is rust and why is it bad? Can someone explain it in laymen's terms?
Rust is a programming language that's become popular in the past few years. It's used as alternative to C and C++, with its memory safety features being sold as a way to help prevent memory related bugs and security exploits.

The reasons it's considered 'bad' seem to be mostly about the community and how it's been used. One of the main reasons it's seen as 'bad' here is idealogical with the Rust community apparently infested with troons. There's also a trend of Rust reimplementations of existing C and C++ projects in Rust for questionable reasons.

The technical reasons for it being 'bad' seem to get mentioned far less. I think compile times are slow, but I'm sure there are more.

I haven't used Rust myself, but personally I think generally with software, implementation trumps choice of programming language. Something like web browser engine where performance matters a lot Python wouldn't be appropriate, but arguments over C and C++ vs Rust seem a lot more trivial.
 
Last edited:
Rust is a programming language that's become popular in the past few years. It's used as alternative to C and C++, with its memory safety features being sold as a way to help prevent memory related bugs and security exploits.

The reasons it's considered 'bad' seem to be mostly about the community and how it's been used. One of the main reasons it's seen as 'bad' here is idealogical with the Rust community apparently infested with troons. There's also a trend of Rust reimplementations of existing C and C++ projects in Rust for questionable reasons.

The technical reasons for it being 'bad' seem to get mentioned far less. I think compile times are slow, but I'm sure there are more.

I haven't used Rust myself, but personally I think generally with software, implementation trumps choice of programming language. Something like web browser engine where performance matters a lot Python wouldn't be appropriate, but arguments over C and C++ vs Rust seem a lot more trivial.

I think people should keep this in mind. Especially when it is a project that makes all the open source trannies seethe by simply existing like this one does (because at some point he told the trannies no, that's all it took).

 
Rust is a programming language that's become popular in the past few years. It's used as alternative to C and C++, with its memory safety features being sold as a way to help prevent memory related bugs and security exploits.

The reasons it's considered 'bad' seem to be mostly about the community and how it's been used. One of the main reasons it's seen as 'bad' here is idealogical with the Rust community apparently infested with troons. There's also a trend of Rust reimplementations of existing C and C++ projects in Rust for questionable reasons.

The technical reasons for it being 'bad' seem to get mentioned far less. I think compile times are slow, but I'm sure there are more.

I haven't used Rust myself, but personally I think generally with software, implementation trumps choice of programming language. Something like web browser engine where performance matters a lot Python wouldn't be appropriate, but arguments over C and C++ vs Rust seem a lot more trivial.
Good post.

It's the ideological aspects that most concern me at the moment. To fill out one of your comments about "questionable reasons", there is an ongoing effort to rewrite the GNU Utils in Rust. These aren't part of the Linux kernel but they're about as close to integral as you can get for userland code. When you use the cp (copy) command in Bash or `stat` a file, you're using GNU Utils. There's no technical reason to rewrite them in Rust. They're simple, performant and very mature. The only real performance bottlenecks are external to the process - file system operations for example. Nothing that a Rust rewrite will affect. Nor is there any realistic security reason for it. They're probably about the last programs on Earth you're likely to find an in-the-wild memory leak in.

No, the reason they're being re-written is both because it lets them be re-done under a non-GPL licence and because it excises older grognard people with expertise in favour of younger members of the cult. Linus has put Rust support in the kernel now. Five years from now, a fundamental part of the Linux OS may be non-GPL as standard and with a new crew of Rust trannies having Repo control over it.

As an aside, their version of the GNU Utils is one big blob.

I'm less well qualified to talk about the technical side because whilst I used to work with C/C++ professionally, it's been a long time since I've actively worked on that. However, I feel the "memory safe" is relied upon too much. You can still write memory unsafe code in Rust and people do. You just have to effectively tell the compiler that it isn't safe and then carry on. And people do that in production code. The Cloudflare fuck-up last year was due to this. It does give them the PR response of "but someone deliberately didn't use Rust's features" to any criticism. Which is fine until you ask why someone deliberately didn't use that feature and the answer is: "because it gets in the way of doing what I need."

The thing with memory safety and C++ is that it gets better and better every year. It's not the 90's anymore. People use standard libraries that are very mature for most things. Tooling and testing have gotten better and better to catch things like this. And I would have thought, though I've been out of the business for a while, that modern AI tools are excellent for catching memory problems in code.

Rust has other problems. The very long compile time has been mentioned, but they don't care because they don't really want you compiling everything. They want to send out binaries and to that point, you can't bootstrap Rust from nothing when compiling. You have to use their binary compiler. If you want to compile the compiler yourself, you used to have use their binary compiler to do it. This opens the door to a class of exploits in which a powerful actor (think State actor) could introduce backdoors into even Open Source code that you compile yourself. There has been at least one real world case of this technique in the wild.

Someone with better knowledge of Rust (I have only skimmed language summaries) and more recent knowledge of C++ can answer in more detail. But we also have a thread on it.

But what I will say is that I'm not convinced you can have Rust without the cult politics that come with it.
 
It's the ideological aspects that most concern me at the moment. To fill out one of your comments about "questionable reasons", there is an ongoing effort to rewrite the GNU Utils in Rust. These aren't part of the Linux kernel but they're about as close to integral as you can get for userland code. When you use the cp (copy) command in Bash or `stat` a file, you're using GNU Utils. There's no technical reason to rewrite them in Rust. They're simple, performant and very mature. The only real performance bottlenecks are external to the process - file system operations for example. Nothing that a Rust rewrite will affect. Nor is there any realistic security reason for it. They're probably about the last programs on Earth you're likely to find an in-the-wild memory leak in.
Absolutely aware of the Rust rewrite of GNU Coreutils and that's what I was alluding with 'questionable reasons' - I just was trying to be fairly neutral with question to put it into laymens terms about Rust. But I have to say Canonical replacing the GNU Coreutils is completely and utterily retarded. As you said they're a mature part of the operating system - why the hell are they being so cavelier about ripping out and replacing it?
 
But what I will say is that I'm not convinced you can have Rust without the cult politics that come with it.
It's possible, but you have to gatekeep like a motherfucker. Easy for Null, in his doghouse castle on a mountain of cheese, because cultists don't want to associate with him. Harder for a project like ladybird, but not impossible.

why the hell are they being so cavelier about ripping out and replacing it?
The most likely reason is they want to close up as much of the distro as possible to make a fully commercial version. Can't do that if your userspace is GPL. Systemd is LGPL (something I only realised now), so it can be safely included in a hypothetical closed-source distro without forcing open any closed components they might add to it.
 
Last edited:
The technical reasons for it being 'bad' seem to get mentioned far less. I think compile times are slow, but I'm sure there are more.
The technical reasons are twofold:
1. Rust’s memory model is still capable of producing memory leaks, despite its “safety” guarantees. Not too long ago, there was a controversy with the COSMIC desktop environment for Linux in which it had huge memory leaks despite being entirely programmed in Rust. This resulted in the hue and cry of a million trannies arguing that Rust doesn’t actually guarantee no memory leaks, but guarantees protection from other kinds of memory errors. This is true, but because its memory management system is intended to be almost entirely implicit, it can be difficult to catch memory leaks and to fix them appropriately.
2. Rust is not a fully standardized language. With C, for example, we’re coming up on 40 years of C standards along with an immense amount of effort from the standards committees to ensure that even very significant additions to the language don’t break backwards compatibility. Rust changes things every release and will break compatibility with previous releases on occasion. This means any project in Rust is going to require an additional bit of effort to make sure its kept up to date with the most recent version of rustc. Even with newer languages, Go put a lot of effort into standardizing the language for the 1.0 release and uses a comprehensive versioning system for its build system to ensure that modules are built with the correct version of the language, even while breakages between versions are rare.

Rust is OK apart from these issues, but especially for large projects these issues can become very significant bug bears.
I'm less well qualified to talk about the technical side because whilst I used to work with C/C++ professionally, it's been a long time since I've actively worked on that. However, I feel the "memory safe" is relied upon too much. You can still write memory unsafe code in Rust and people do. You just have to effectively tell the compiler that it isn't safe and then carry on. And people do that in production code. The Cloudflare fuck-up last year was due to this. It does give them the PR response of "but someone deliberately didn't use Rust's features" to any criticism. Which is fine until you ask why someone deliberately didn't use that feature and the answer is: "because it gets in the way of doing what I need."
The Cloudflare breakage was due to an uncaught exception in code that was not marked unsafe.
 
Last edited:
If there was a Linux version of The Onion, "Ladybird adopts Rust, with help from AI" would be a convincing parody headline.
 
2. Rust is not a fully standardized language. With C, for example, we’re coming up on 40 years of C standards along with an immense amount of effort from the standards committees to ensure that even very significant additions to the language don’t break backwards compatibility. Rust changes things every release and will break compatibility with previous releases on occasion. This means any project in Rust is going to require an additional bit of effort to make sure its kept up to date with the most recent version of rustc. Even with newer languages, Go put a lot of effort into standardizing the language for the 1.0 release and uses a comprehensive versioning system for its build system to ensure that modules are built with the correct version of the language, even while breakages between versions are rare.
Rust claims here they have backwards compatibility with their editions: https://doc.rust-lang.org/edition-guide/editions/
 
Yes, link works for me. I specifically linked to the 'What are Editions?' section. See text below.
In May 2015, the release of Rust 1.0 established "stability without stagnation" as a core Rust axiom. Since then, Rust has committed to a pivotal rule: once a feature is released through stable, contributors will continue to support that feature for all future releases.

However, there are times when it's useful to make backwards-incompatible changes to the language. A common example is the introduction of a new keyword. For instance, early versions of Rust didn't feature the async and await keywords.

If Rust had suddenly introduced these new keywords, some code would have broken: let async = 1; would no longer work.

Rust uses editions to solve this problem. When there are backwards-incompatible changes, they are pushed into the next edition. Since editions are opt-in, existing crates won't use the changes unless they explicitly migrate into the new edition. For example, the latest version of Rust doesn't treat async as a keyword unless edition 2018 or later is chosen.

Each crate chooses its edition within its Cargo.toml file. When creating a new crate with Cargo, it will automatically select the newest stable edition.
 
Back
Top Bottom