Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Early stages of Google Docs support in the Ladybird browser

twitter.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Early stages of Google Docs support in the Ladybird browser

#81

Post by sedan_baklazhan »

lslgienxials wrote: post #14
nonethewiser wrote: post #6

Clearly I have no idea what Ladybird browser is. Why should I be impressed? I would expect every browser to be capable of this. EDIT: Lots of great answers. Thanks everyone. Glad this inspired such lively discussion.

Nobody is trying to impress you. There have been no new browser engines for years, with the idea that its impossible to develop one anymore being a meme people would espouse regularly. This is impressive as a group of random interested people have made significant progress to making a functional web browser off the back of passion, not billions of dollars. Andreas has be an incredible force for showing what bringing…

I wonder how much of mainstream browser code consists of layers of legacy over legacy over legacy which complicates it much more than needed.

Re: Early stages of Google Docs support in the Ladybird browser

#82

Post by Y_Y »

djbusby wrote: post #47
Y_Y wrote: post #28

Earlier quoted context omitted.

Of course WebKit and Blink (Chromium) are both just shitty descendants of the beautiful (and foss) KHTML from Conqueror.

*Konqueror https://apps.kde.org/en-gb/konqueror/

Thanks. You can blame autocorrect for that one. No doubt more of Google's anticompetitive behaviour using Android keyboards to surpress rival browsers.

Re: Early stages of Google Docs support in the Ladybird browser

#83

Post by maybevain »

nonethewiser wrote: post #52
lslgienxials wrote: post #36

Earlier quoted context omitted.

Ah, I'm sorry I misread the tone. I'm quite a big fan of the project and didn't reply in the most sane way possible. Sorry about that :)

No worries, I can see how it sounded. The project sounds pretty cool. I really dig the 90's UI of SerenityOS. Do you think the OS can be more than a novelty? I read that it doesn't support 3rd party software. Maybe I don't fully understand what that means, but wouldn't it mean anything that doesn't ship with the OS likely wont work? That I couldn't make my own package that could be installed via the package manager?…

Not sure what your source for ”doesn’t support 3rd party software” is, so it’s unclear what that actually means, but there are numerous examples on Andreas’ YouTube channel about porting software to Serenity, e.g. Diablo [1].

Maybe the text you read refers to the OS itself and all first party software being written without external dependencies?

[1] https://m.youtube.com/watch?v=ZOzZ8R4gphE

Re: Early stages of Google Docs support in the Ladybird browser

#84

Post by marginalia_nu »

rvz wrote: post #73
marginalia_nu wrote: post #68

Earlier quoted context omitted.

> Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors. Is it though?

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities. If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

I think you should take it easy with the rust kool-aid. Not that black and white in reality.

Re: Early stages of Google Docs support in the Ladybird browser

#85

Post by rvz »

marginalia_nu wrote: post #84
rvz wrote: post #73

Earlier quoted context omitted.

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities. If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

I think you should take it easy with the rust kool-aid. Not that black and white in reality.

And in reality, it is really going great for C++ based browsers and their engines like Chromium, and WebKit with all their static analyzers, address sanitizers, valgrind, etc have got their memory corruption CVE woes sorted /s

As Ladybird gets more complex, it will most certainly have memory corruption vulnerabilities, just like the other browsers and it will turn out to be no different.

Re: Early stages of Google Docs support in the Ladybird browser

#86

Post by marginalia_nu »

rvz wrote: post #85
marginalia_nu wrote: post #84

Earlier quoted context omitted.

I think you should take it easy with the rust kool-aid. Not that black and white in reality.

And in reality, it is really going great for C++ based browsers and their engines like Chromium, and WebKit with all their static analyzers, address sanitizers, valgrind, etc have got their memory corruption CVE woes sorted /s As Ladybird gets more complex, it will most certainly have memory corruption vulnerabilities, just like the other browsers and it will turn out to be no different.

You're really just dogmatic making assertions. I don't really see much backing these assertions up. Making them more firmly isn't making your case more convincing.

--

Let me make a silly argument. Let's say you write a program in rust, a sort of elaborate turing tape that interprets C++ code and evaluates it as a C++ program according to all standards and rules. To the end user it is indistinguishable from a C++ interpreter, but between the C++ code and the system is a layer of rust.

According to standard rustacean dogma, this program will simultaneously be guaranteed to be memory safe because it is rust, and inevitably have memory corruption bugs because it is C++. This is surely a contradiction. It cannot both be incorrect and correct at the same time.

Re: Early stages of Google Docs support in the Ladybird browser

#87

Post by willeum »

marginalia_nu wrote: post #86
rvz wrote: post #85

Earlier quoted context omitted.

And in reality, it is really going great for C++ based browsers and their engines like Chromium, and WebKit with all their static analyzers, address sanitizers, valgrind, etc have got their memory corruption CVE woes sorted /s As Ladybird gets more complex, it will most certainly have memory corruption vulnerabilities, just like the other browsers and it will turn out to be no different.

You're really just dogmatic making assertions. I don't really see much backing these assertions up. Making them more firmly isn't making your case more convincing. -- Let me make a silly argument. Let's say you write a program in rust, a sort of elaborate turing tape that interprets C++ code and evaluates it as a C++ program according to all standards and rules. To the end user it is indistinguishable from a C++ inte…

I'm not agreeing with rvz, but I don't think even extremely pro-Rust devs would agree with what you just claimed

Re: Early stages of Google Docs support in the Ladybird browser

#88

Post by UltraViolence »

rvz wrote: post #73
marginalia_nu wrote: post #68

Earlier quoted context omitted.

> Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors. Is it though?

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities. If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

No it isn't. I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII.

Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.

Re: Early stages of Google Docs support in the Ladybird browser

#89

Post by rvz »

UltraViolence wrote: post #88
rvz wrote: post #73

Earlier quoted context omitted.

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities. If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

No it isn't. I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII. Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.

> No it isn't.

It is.

> I'm studied the Firefox code and there are lots of raw pointers being used everywhere, instead of them using RAII.

Firefox is still in C++ and is still subject to memory corruption vulnerabilities, proving my point again.

> Anyway, wxWidgets is an example of a C++ framework which is almost flawless and comparable in complexity to Gecko.

"almost flawless" is still in the category of 'possible'. Memory corruption is not possible in Rust by default.

Surely you understand what 'inevitable' means before giving me an example of a project that has at least one memory corruption vulnerability out of the thousands of other projects that are also in C++, especially browser-based software?

Post reply on HN