261–270 of 272 posts
Earlier quoted context omitted.
Pay? You mean putting the "you are using X, why not try chrome" adtext everywhere for every search result?
More like having a team of between 1000 and 1500 full time software engineers working on it over a period of more than a decade.
Earlier quoted context omitted.
This is a headline that is very easy to misread and or misunderstand. I don’t find their comment to be that out of place at all.
Root comment is lecturing the ladybird team about not using this suite as a metric, which is totally uncalled for. That’s what I’m trying to convey.
Earlier quoted context omitted.
I do wonder if it's the case of "90% of completeness takes 90% of time; the remaining 10% takes another 90%". Though, I suppose even if true, it would still be a pretty good timeframe.
I'll guess that the remaining 10% will take more than another 90%, and also that it will keep growing as time goes on. Web standards are becoming more complex every day.
It's doable, but not easy especially when the train engine is being stuffed with high-octane fuel by Google's resources.
Earlier quoted context omitted.
The value proposition is not having vendor lockin and having WebKit/Blink be the defacto behaviour. For example the Ladybird team have found and raised spec issues in the different specs. Another example is around ad blockers -- if Blink is the only option, they can make it hard for ad blockers to function whereas having other engines allows different choices to be made.
>The value proposition is not having vendor lockin there by definition is no vendor lock-in by forking an open-source engine. The worst case is the original maintainers going evil tomorrow and you being on your own, which is no worse than starting from scratch, except you saved yourself some ten million odd lines of mindless spec implementation in the case of a browser.
It's like projects trying to keep Firefox XUL alive, or GTK+ 2 or 3.
The project has now moved from just updating the external dependency to working on that and possibly actively fighting against the tide. That is a lot harder and requires more work each time you update the dependency.
So in effect you have vendor lock-in. And if the vendor controls or affects downstream products like plugin developers (targeting manifest V3) or application developers (targeting GTK+ 3 or 4) then its even harder to maintain support for the other functionality.
Earlier quoted context omitted.
Is distribution the only problem? If Mozilla or Google were to make their code freely available on some git forge like GitHub and I cloned the repo and built it myself, would I be able to run it for seven days or something in the US?
nope, one can't get the entitlement -- even just for 7 days dev mode -- just like that.
Earlier quoted context omitted.
Again, just because there's no guarantee of quality doesn't mean there still can't be improvement in quality. Some measures are better than no measures. The world isn't black and white.
Just compare it with Debian repositories. Where's the malware in there?
Earlier quoted context omitted.
I don't remember that; maybe you can look it up? Ladybird is still far from usable or fast enough to even start comparing it to Gecko.
It says here: https://ladybird.org/#sponsors Shopify, CloudFlare, and others.
Earlier quoted context omitted.
The tweet mentions that this is an arbitrary metric thrust upon them by Apple, so I don’t think they would necessarily disagree with you. During the monthly updates they do also show the passing number of tests without including the encoding tests because of how much they skew things.
Ladybird will be faster than anything with an arbitrary metric thrust
The WPT score is a flawed metric (encoding tests are overweighted), but it's one of the few objective yardsticks we have. What matters more is that Ladybird is finding spec ambiguities by implementing from scratch rather than cargo-culting Chrome's behavior. The real test isn't passing 90%—it's whether they can keep pace as the web platform adds new APIs faster than any independent team can implement them. Browser en…
I am not saying they do not have A LOT left to do. But your comment almost makes it sound like they are falling behind and that is most certainly not the case.
The team is quite pragmatic and many perfectly modern websites work already. Again, A LOT to do. But it is looking very doable. They still expect a "usable" release sometime next year.
Earlier quoted context omitted.
LadyBird grew out of the SerenityOS project which was originally written in C++ (they've since moved to Jakt). All software for Serenity had to be written natively for the OS, and C++ was the language originally supported there. Andreas had worked on browsers previously (notable Safari), and was already a seasoned C/C++/ObjC developer. While one can cite many valid reasons for using a C language for a browser (and OS…
The language is actually something that makes me look elsewhere. We already have enough sufficiently vulnerable browsers and other network related software. Choosing C/C++ as language may work to make something that works, and it may be in the realm of experience the people building it have. However, it does not make this browser stand out in terms of security/safety. While they may deliver tremendous work, that work…
They have actively rejected Rust as they see it as unsuitable for a heavily OOP code base. They see OOP as a great fit for implementing the web spec.