Here's a short video from Chris Wanstrath announcing our non-profit yesterday, and kicking things off with a $1M donation: https://www.youtube.com/watch?v=k9edTqPMX_k
Happy to answer questions :)
Of course, it has a long way to go before it is going to be a good daily driver, but I truly believe this is the beginning of something great. I've been consistently surprised by what works, and the rate of improvement is staggering at times.
My question: Has anyone given any thoughts regarding the stance to take with DRM features, e.g. Widevine/Encrypted Media Extensions? It seems like since our previous stewards of the open web didn't care enough, now making a browser with substantial marketshare without this may be hard. Seems like a hard problem, I really do wonder where Ladybird will stand if it continues on its current lightning fast trajectory.
I don't think it should have to be in the browser. I would like the option to watch the content. I know the while process of DRM is stupid and will be side stepped somewhere.
But with the updates, it wild to see progress moving steady but impressively. And the last year - wow! With all the donations, there is now a path towards a real viable alternative rather than something that looses interest as contributors lives get in the way.
I love that you are no over promising and have provided a reasonable time line, it is the kind of restraint that typically gets things done rather than promising the world up front. I love it and look forward to where this goes from here and it could end up in some very odd places.
If in 2001 you where to say that KHTML would be the core base of the majority of web browsers in 15 years, you would have been a great joke. And look at what happened. The big thing is to keep a Richard Stallman like resolve to do what is right for the people, even if it means a little less personal success.
Be well.
First, thanks for this project and making your self accessible!
Will "plug-in" or "add-on" support be a first-party concept in Ladybird?
I ask that because in years past a few other browsers (Konqueror, Falkon, Dillo, etc) made it pretty far but lacking add-ons, useful capability such as 'NoScript' or 'uBlock' or even a tab manager made them non-starters.
Plus there are plugins for dillo... https://dillo-browser.github.io/#plugins
That said, Ladybird is obviously far from becoming the daily driver for the average webizen. What do you think is going to be the first milestone where Ladybird is going to be able to be a real alternative (even if limited to certain use cases) and in what timeframe do you think this can be accomplished?
Also, do you already have any plans or ideas for how to improve the web browsing experience beyond what existing browsers provide or is your focus entirely on the engine catching up for now?
At the moment, we are focusing primarily on our own use cases as developers, since those are the easiest to test and qualify. So websites like GitHub, web specifications, MDN, etc. are likely going to be very high fidelity before other parts of the web catch up ;)
> Also, do you already have any plans or ideas for how to improve the web browsing experience beyond what existing browsers provide or is your focus entirely on the engine catching up for now?
We are definitely focused on the engine catching up right now. There is an incredible amount of work to do, and we're doing the best we can :)
Well the impossibility isn't so much in making a browser but making a browser that manages to get a chunk of web audience.
That means presence on mobile, feature and performance parity with Chrome, surprasing Chrome on some level (e.g. Safari having better vendor lock-in).
According to Hacker News readers, the ladybird shouldn't be able to compete in the browser space. It's too difficult, the spec is too large, its competitors have large pockets. The ladybird tries anyway, because ladybirds don't care about what HN readers think.
Inspired by https://www.goodreads.com/quotes/823379-according-to-all-kno...
Also, any thoughts on having official communication channels on some open, freedom-respecting platforms, rather than Discord only?
And we're perfectly happy using proprietary services like GitHub and Discord as long as they make our work easier and more enjoyable. We recently evaluated a number of alternatives, and found that they all introduced more friction than we were comfortable with.
Although the task of building a browser is itself challenging, we're a pragmatic project :)
Github I can understand to some extent, it's a convenient temporary staying place until they can afford, community-wise, to move to something truly open, but Discord? In this day and age?
So he knows that corporations can take open source browsers and make it proprietary.
This immediately comes to mind as akin to the Signal vis-a-vis WhatsApp etc. Here there is an obvious reason to use Signal and a well-understood proposition. What might it be for Ladybird? And how will you differentiate?
That said, I do think we'll find ways to differentiate given our uncommon situation with no ties to the advertising industry. This gives us the ability to experiment with privacy measures more aggressive than others may be comfortable with for fear of losing funding, for example.
Servo wants to build an embeddable engine for controlled sets of HTML/CSS/JS content, with a focus on modularity and parallelism.
Ladybird wants to build a usable browser for the open web, warts and all, with a focus on compatibility and correctness.
I'm a big fan of Servo and I hope they become a huge success! Competition and new ideas in browser engines will benefit all of us! :)
Indeed, I doubt very much that Ladybird will get there.
What languages have prototypes and where can I learn more?
1. Legacy hardware support. Is it a goal for Ladybird to build for 32-bit and big-endian CPUs out of the repository?
2. Electron. Do you have any plans to work on an Electron alternative based on Ladybird further down the line? No free Electron alternative other than Sciter seems to use the same browser engine on all platforms. There may be value in one that implements the latest web standards.
2. No concrete plans, but it's not outside the realm of possibilities.
Thanks again for your hard work!
This is definitely more than a hobby at this point. I already manage 3 employees, with 3 more joining in the next month!
Here’s hoping one day I can move to LadyBird and leave the others behind.
Bravo again.
Not trying to pry into your personal lives, just wondering because there's a lot of meaningful information behind the answers to those questions.
Given the limitations of our funding model, we won't be building a huge team, but rather a small team that allows us to maintain a runway of at least 1.5 years. :)
Edit: In Blink, the layer/compositing system extends to SVG elements inside SVG tags, as well, and in WebKit, it doesn’t yet, but there is an active years-long effort going back to 2019 that will eventually land: https://youtu.be/WxqJFxiprrU?si=dhQIgW1V4yS_Ca4s Compositing and using the GPU seems like a complex but important part of rendering in a browser, and a case where it could be good to implement the kind of system that other browsers have arrived at after years of iteration, when it comes time to do so.
Will the JS engine still be LibJS?
AFAIK there's some support for it already, but it has to be enabled explicitly with --enable-gpu-painting. I can confirm that with that switch Ladybird can do 3D CSS transforms (which don't work without it).
The JavaScript engine is our own LibJS, currently sitting at 94.3% pass rate on https://test262.fyi/ (although the number might be a little outdated, it's supposed to be higher! Need to investigate this..)
https://mozilla.github.io/standards-positions/
It seems to me that a large volume of code in Blink deals with obscure features with relatively niche use cases (such as WebRTC, WebUSB,WebGL, WebAudio and so on and so forth), which would mean a large amount of programmer effort for very little user-facing gain.
Additionally, in these areas, web standards tend to say 'whatever Chrome does', with FF often lifting large parts of Chrome code to support these features. Even if the above wasn't true, in practicality it is, since all clients are tested against Chrome, you'd need to follow all its quirks to have your browser be compatible.
Are you planning to do a clean room implementation of these features as well?
I also have a personalized build step on our pre-production web app that launches the site in Ladybird for my host. It’s been awesome to see the browser lock in functionality along with our own progress.
Does Ladybird still follow that ideal?
Going forward, we want to support the open web as it exists, so you can actually use Ladybird to interact with all your websites. We may not agree that every web platform API is awesome and perfect, but we will honor the open standards to the best of our ability.
But please do consider putting up some screenshots of the browser - including how it renders the popular sites.
Over time, I expect them to diverge enough that this becomes impractical, as Ladybird now allows 3rd party code while SerenityOS does not. It’s up to the SerenityOS community how to handle this.
We benefit greatly from this of course, and we will do what we can to contribute when we’re mature enough!
That said, there will always be websites relying on bugs, and for that we will need a way to selectively emulate alternate behaviors in some cases. We are looking at a few different solutions for this but it’s not a huge priority right now as there are far lower hanging fruit in front of us.
Can't wait for the day I can drop Firefox and use Ladybird full time.
(or will you just use Chrome as a reference spec and implement anything it implements?)
Q2: what is your “guiding principle/mission”? Is it to be the fastest browser? The most privacy centric browser? The only 100% standards compliant browser? etc…
—-
Super excited for you. Wishing you the best in this and hope you change the world for the better.
Will you use Vulkan when it comes to gpu accel or OpenGL?
Will you make better adblocking capabilities by embedding faster checks and rule engines/lookups in c++ than what we have now?
How much can people who do not contribute code affect development? In terms of requests suggestions? E.g. if I would suggest to skip OpenGL and use Vulkan (so basically defining a limit on how old should the hw be), would this be even considered?
This could be key differentiator over other browsers.
Personally, I much prefer developing for the web than native so if there were APIs exclusive to Ladybird it might create a nice virtuous cycle of developers targeting Ladybird to do new things and users using Ladybird to try those new experiences.
There's probably a huge influx of people trying to get involved now, which probably really complicates and muddies the waters right now as well.
Either way, congrats!
The best for a beginner is usually to start with some simple page you made yourself, since you know how it’s supposed to work, and can debug more easily.
And come join us on Discord, there are new people getting into the codebase all the time :)
Best of luck!
By building a new engine, we can increase ecosystem diversity and put all these open standards to the test. We regularly find, report, and sometimes even fix bugs in the various web standards - stuff we find just by being the first to try and implement everything from scratch in a long time!
We also believe it’s good for the world to have more engines that aren’t directly or indirectly funded primarily by the advertising industry.
Here's a tweet with a couple of diagrams that illustrate how much control Google has over all browsers (including Firefox and Safari): https://x.com/awesomekling/status/1793937129250214344
Once we get the desktop version into decent shape, we will direct more attention to mobile platforms. At the moment there's just too much important low-hanging fruit that's easier to develop (and debug!) on desktop :)
* We're already making a top 5% income for our area and have more than enough for our needs and even an early retirement.
* We get non-monetary benefits from our job like WFH and/or flexible scheduling.
* We're working on projects that excite us and make us happy to go to work and that matters more than total comp.
Money aside, I'd rather see Ladybird hire 6 developers who are seriously passionate and live all across the world than see them hire 6 Bay Area developers who think they're better because they ask for more comp. That the passionate and global developers are cheaper is just a nice bonus.
>Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.
>However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.
https://assets.mozilla.net/annualreport/2022/mozilla-fdn-202...
I want ladybird to succeed and show the world how ridiculous the Mozilla situation has been.
I quickly put together a "cleaner" design for anyone interested, which also uses the original (and objectively better) logo:
2. gives black text white background
3. now its "clean(er)"
4. "also your old logo is objectively better"
This isn't design work.
[1] https://web.archive.org/web/20240208004519im_/https://ladybi...
P.S. Check out my UI/UX portfolio at https://hipfolio.co
https://hicks.design/journal/firefox-logo?trk=feed-detail_co...
This of course comes at the cost of not being able to support non-free parts of the web standard such as DRM.
Then write one.
Perhaps BSD in its anarchic freedom is compelling to the kinds of people who decide to do something crazy like building a brand new browser engine from scratch, and GPLv3 with its detailed rules and regulations is compelling to people who like to talk about how they wish the world had more software licensed under GPLv3.
Open source isn’t handed down from God, it starts with one person deciding to type mkdir.
So poetic! I love that sentence!
Sorry this is not the GPLv3 everywhere world you are dreaming of, and I'm glad it works this way.
Like others said, if you want to have a GPLv3 licensed browser (that will probably be as unusable as GIMP), write one yourself.
That would be a benefit, not a cost.
LGPLv3 would solve that, wouldn't it?
I must admit I'm not crazy about the logo though. It's fine at the top of a page, but I cant see it as my browser icon on my desktop, and it's much less appealing and identifiable than the old Ladybird.
I am happy to see the project thrive.
Developers can simply look at the Github readme and get their near plain text overview there.
We're all nitpicking no matter what our thoughts are on the design. I have my own thoughts on the design, but I'm more excited about the product than to put any more care in what the website looks like. It's easy enough to ignore and doesn't have an effect on the product.
It is a nitpick, and the website works just fine for conveying what Ladybird is & what the project will be doing: The elevator pitch given was straightforward & at the top of the main page.
That might play if this was another Chromium fork, instead of something built from scratch.
I hope that as Ladybird grows you'll keep privacy, security, and customization in mind because our options in that space are very limited.
A reminder that years ago they were paid by an advertising firm to secretly install a plugin for a TV show. When someone raised a bugzilla bug about it, the project manager for the plugin (who herself had come to Mozilla after a career in online advertising tech...) marked it employee-only. Another employee reversed that, and then someone at the highest levels of Mozilla leadership changed it to a level that made it unviewable even by employees.
Pocket? That shit requires manually editing a bunch of config strings to disable. We were never asked "would you like to enable Pocket?" because they knew 99% of their audience would click "no." There still isn't a checkbox to disable it.
This whole "privacy is our priority" thing has been a farce and always will be.
But hey, they won't enable WebSerial because ZOMG DANGEROUS USERS CAN'T BE TRUSTED PRIVACY CHAOS DANGER DANGER MUST PROTECT THEM!
...meanwhile in Chromium browsers, WebSerial has been supported for years, it asks the user to give permission per-site just like cameras and microphones. The world has not caught fire, nobody's pacemaker has killed them, etc.
It would be a statement of hope that we are not condemned to Google’s corporate strategy and the absolute rot the Mozilla foundation has become.
I know pretty much everything is not in their favor but I truly believe it’s still possible for a couple of guys with their head between their shoulders to actually “change the World”. I need to sleep at night after all.
I loved opera to death in the early 2000s. I was young and broke and didn't want to pay for it, but even though there were cracked versions around I dealt with the officially free, ad-sponsored version (Google ads, ironically) because I wanted to support it.
Now I've donated to Firefox in the past, but they've disappointed again and again with questionable business decisions. Still, I'm exclusively using Firefox than anything Chromium-based out of principle and I think I will switch to ladybird as soon as feasible. I have no problem paying for a browser that's truly independent.
Welcome to Ladybird - https://news.ycombinator.com/item?id=40845951 - July 2024 (94 comments)
The Ladybird Browser Initiative - https://news.ycombinator.com/item?id=40845954 - July 2024 (13 comments)
Ladybird browser update (June 2024) [video] - https://news.ycombinator.com/item?id=40838973 - June 2024 (1 comment)
Ladybird browser spreads its wings - https://news.ycombinator.com/item?id=40746804 - June 2024 (304 comments)
Ladybird browser update (March 2024) [video] - https://news.ycombinator.com/item?id=39889576 - April 2024 (2 comments)
Understanding Complexity Like an Engineer – The Case of the Ladybird Browser - https://news.ycombinator.com/item?id=39342887 - Feb 2024 (55 comments)
The Ladybird browser project - https://news.ycombinator.com/item?id=39271449 - Feb 2024 (284 comments)
Ladybird browser update (July 2023) [video] - https://news.ycombinator.com/item?id=36939402 - July 2023 (1 comment)
Chat with Andreas Kling about Ladybird and developing a browser engine - https://news.ycombinator.com/item?id=36620450 - July 2023 (65 comments)
Shopify Sponsored Ladybird Browser - https://news.ycombinator.com/item?id=36502583 - June 2023 (1 comment)
I have received a $100k sponsorship for Ladybird browser - https://news.ycombinator.com/item?id=36377805 - June 2023 (166 comments)
Early stages of Google Docs support in the Ladybird browser - https://news.ycombinator.com/item?id=33511831 - Nov 2022 (84 comments)
Github.com on Ladybird, new browser with JavaScript/CSS/SVG engines from scratch - https://news.ycombinator.com/item?id=33273785 - Oct 2022 (1 comment)
Ladybird: A new cross-platform browser project - https://news.ycombinator.com/item?id=32809126 - Sept 2022 (473 comments)
Ladybird: A truly new Web Browser comes to Linux - https://news.ycombinator.com/item?id=32014061 - July 2022 (8 comments)
Ladybird Web Browser - https://news.ycombinator.com/item?id=31987506 - July 2022 (2 comments)
Ladybird Web Browser – SerenityOS LibWeb Engine on Linux - https://news.ycombinator.com/item?id=31976579 - July 2022 (2 comments)
Meanwhile Mozilla spends a massive chunk of money on the organization and the philanthropy and the blog posts, and the activism, and the salaries of people who have little resemblance to engineers.
We are definitely a stripped down operation, and we will spend as much of our funding as possible on engineer salaries for the foreseeable future.
This also makes me a bit of a tab hoarder, though.
I'd say "I'll be keeping an eye on this," but I'm sure there'll be plenty of posts about Ladybird before the alpha even drops, haha.
Tree-style tabs could be a core feature. Maybe this is something you can contribute to the project?
I can't wait to see the absolute mountain of perfect pull requests all these people bring to the project!
Seriously though, congratulations Andreas and please keep the faith. We might not be the loudest voices, but almost all of us are cheering for you.
Sounds good, but how would you make sure the sponsors won’t influence you in the future once it’s popular enough? After all, they are still corporations and are after profits, as opposed to crowdfunding.
Is this going to work with screen readers, magnification, speech recognition etc? I guess a more abstract version of that question is: Does Ladybird intend to offer some kind of feature parity with existing solutions where integration with OS-specific accessibility architectures (UIA, AT-SPI2, etc.) are concerned? If not, it's a non-starter for quite a few people, and I'd rather know so I know to even keep up with this project or add it to the "user first but oh not actually all users first" pile :)
"User first" definitely doesn't mean targeting all 8 billions people on the planet.
Also, its* not it's
This is not even in the list of my concerns. I just don't like to see efforts of hundreds if not thousands of volunteers are rolled into a closed source application and distributed for the profit of a couple of people who pat themselves on the back because they got their next car/house/whatever for free.
This is why I prefer GPL over BSD/MIT.
If one values the web being somewhat open/less monopolistic, an open source web browser would be more appealing.
I have faith in the Ladybird browser project to avoid such a situation though.
1) Ladybird matures with a community around it.
2) A company actually cares enough to fork it.
3) Said fork becomes the dominant version.
4) Company closes down fork.
I did these assumptions because I saw potential in the project and witnessed the cycle enough times to worry about its future.
On the other hand, it's a food for thought. Just to play with and explore the possibilities.
And I don't see any problem with forking. Tons of browser bugs were found, reported and fixed exactly because companies forked them. And remember that Blink is forked from Webkit.
Ladybird might be added to this list. It's not impossible. It'll be a winding and hard road to go, but it is not a path with no end.
You don't need to fork a codebase to fix its bugs. It's GitHub's workflow (fork -> PR -> merge). What I meant, as noted in this thread, is a hard and closed fork propelled with money and corporate greed, which eclipses the open and primary version and drown it in the process.
EEE'ing it, basically. This is why I prefer GPL (preferably V3+). If you want to improve it, it's open. If you want to monetize and EEE it, then nah. It's not allowed.
I work at Brave, VP of IT. I worked at Mozilla for 5 years. So have some experience with browsers.
I see our insanely high infrastructure bill each month, most of the cost comes down to CDN/distribution of updates, block lists, safe browsing etc. But we also have a bunch of other costs for staff to maintain said infrastructure and security.
If you get to scale, what is the plan here? Because $1M won't get you a very long runway and the moment browsers stop doing what they should be doing well, they die. Wishing you the best of luck.
Even LGPLv3+ would be a good choice here.
> At the moment, many core library support components are inherited from SerenityOS:
LibWeb: Web rendering engine LibJS: JavaScript engine LibWasm: WebAssembly implementation LibCrypto/LibTLS: Cryptography primitives and Transport Layer Security LibHTTP: HTTP/1.1 client LibGfx: 2D Graphics Library, Image Decoding and Rendering LibArchive: Archive file format support LibUnicode: Unicode and locale support LibAudio, LibMedia: Audio and video playback LibCore: Event loop, OS abstraction layer LibIPC: Inter-process communication
> Because of Brazilian government demands to remove creators from our platform, Locals is currently unavailable in Brazil
> We are challenging these government demands and hope to restore access soon
Does anyone have access to it?
Also, I am very curious why is someone like Shopify sponsoring this.
This way the user can feel more secure about the extension not doing things it didn’t advertise.
In those cases I would say that’s genuinely better for the user. Wouldn’t you?
Not all extensions are AdBlock Plus which (as an exception) have very specific needs not covered by manifest V3.
It’s not all black and white. Google is not all in the wrong here, even though their motivation is obvious.
Another answer: concentration of power and market share stifles innovation. Look at what happened to Internet Explorer when Microsoft was the only game in town.
Less specific, but I think just as reasonable, is looking at the philosophical alignment and financial incentives of the organization behind the browser.
Google's interests are often in direct misalignment to my own, and by virtue of that, I would strongly prefer them to not have such a position of power over the market.
I think for a lot of us on the older end, we lived through the era of Microsoft Internet Explorer dominating the web and that experience informs our thinking. As long as there was competition between MSIE and Netscape, with each one trying to outdo the other, both browsers kept getting better and the web kept becoming a more and more capable platform. But quite soon after Netscape crumbled and stopped being a serious competitor, MSIE stagnated: development didn't just slow but halted for half a decade. The web stagnated, too, and Microsoft's dominance meant that a lot of what did get built was locked in to their platform. (Partly things like CSS quirks and nonstandard rendering behaviors, and just plain neglect of new possibilities in HTML, JS, and CSS. But more than that: how many companies built ActiveX controls in that era, which mostly required Windows to function? The entire internet infrastructure of South Korea got locked in to ActiveX by law from about 1999 to 2020.) So imagining an era of Chrome monoculture brings back some pretty negative memories.
I don't expect that Google would make the exact same mistakes that Microsoft made. But it would be awfully hard for them not to shape browser design around their own corporate interests if there were no competition driving innovation and no disincentive to shaping the entire future of the web platform in Google-friendly ways. I know that's not "things that have actually happened", but the whole point is that things change once an effective monopoly is achieved.
- Chrome began to "log in" users into the browser by default, if they so much as logged in to Gmail or Youtube, or anything that uses Gmail ID oAuth. That means that all the searches and web visits made on the browser are explicitly tied to your Gmail ID.
The less obvious question, and Im genuinely curious, is why do you need to rewrite the engines when there are at least 2 good compliant open source ones? The only way an engine rewrite is worthwhile is if yours is significantly leaner or faster, both seem very unlikely. An seemingly-impossible milestone of hitting party isnt that interesting, is it?
I can imagine how hard it is to develop a browser. However, I can't imagine how much the landscape will change in the next 2 years... LLM, privacy, etc.
How come a european project becomes an american foundation?
There's only one way we can make sure we can get really independent browsers:
SIMPLIFY THE WEB
- Limit the platform to absolute minimum - give way to render things, fetch stuff from the network, etc.
- Get rid of CSS - leave just some basic rendering primitives, so libraries can be created to paint on the canvas. We don't need 78 new animation primitives. We'll build them ourselves if we have a sensible canvas and execution platform.
- Move JS out of the browser to a WebAssembly compiler and make browsers run only WebAssembly
- Or keep JS in the browser but don't add any new features, features should be in libraries outside of the browser. Language should be as simple as possible.
- Get rid of all semantic html junk. We only need some basic blocks to move things around.
This way we can have simple browsers and move all complexity to client libraries, which you can pick and replace when needed. Just keep things as simple as possible and let people build on that.
(updated whitespace)
However, I should also think that documents should not need to execute JS or WebAssembly code; although there are uses for such things, it should perhaps be separately.
Also, some of the semantic HTML commands can be helpful, such as <ARTICLE>, <TIME>, etc. (However, the user agent should decide how to display them, according to the options selected by the user; this should not be decided by the author of the document.)
A completely new protocol and file format (or more than one) is another way. A few people have tried some things relating to this, including myself. One thing I had done is that, documents cannot contain scripts to be executed nor can they link to scripts to be executed as a part of the document; executable code can only be linked to from the conversion file (which does other things too, and is not only for executing programs; e.g. to specify how to transform a URL to download a file in a different format), and the user must explicitly tell it to execute; furthermore, it uses uxn and not JavaScript nor WebAssembly (since uxn is much simpler to implement); and, if the conversion file is implemented at all (for simplicity, it is not required), it is mandatory that the end user must be allowed to override it and specify their own conversion file instead (therefore, the end user decides what the client software does). Furthermore, I had also decided to use binary formats, to make them less complicated to parse special cases (to avoid needing so many escaping and stuff like that, which is necessary with HTML). And then, TLS is allowed but is optional; it does not have mandatory TLS (although it is recommended that servers and clients will accept both TLS and non-TLS connections; but a client or server that does not support TLS will still work even if the other does support TLS, if both TLS and non-TLS are implemented). There are many other things can be done too, to make improvement.
It wasn’t that long ago you needed QuickTime and RealPlayer for videos. Then Flash, Director, Silverlight, and Java for multimedia.
You can build something good enough for vast majority of websites and people.
Announcement post: https://ladybird.org/announcement.html
Probably merge these discussions: https://news.ycombinator.com/item?id=40845951
In terms of SWE, it doesn't get harder than an OS in my book (and not even from scratch). So them coming from success in that space is more than enough to convince me they can deliver a world-class browser core engine.
Or what Firefox is doing wrong.
Or what sets this apart from existing browsers, besides the funding model.
As a end user, what should I be excited about?
As a developer, what should I be excited about?
> Ladybird is in a pre-alpha state, and only suitable for use by developers
Generic “he” is correct 20th century English. Singular “they” is correct 21st century English. Some people use “she”. I thought the current zeitgeist was to not judge people based on which pronouns they use :)
To prevent this, remove `anon` from the `wheel` group and he will no longer be able to run `/bin/su`.
To prevent this, remove `anon` from the `wheel` group and they will no longer be able to run `/bin/su`.
“awesomekling commented on May 2, 2021 This project is not an appropriate arena to advertise your personal politics”
Ironically for a story about a webbrowser, the screen is showing 404 comments as I type this. :-)
Announcement post: https://ladybird.org/announcement.html
More discussion: https://news.ycombinator.com/item?id=40845951
What an intriguing name for a web browser.
And what if you succeed? Best of luck on this bold endeavor, and try not to break our hearts.
Mmmmmmh, I don't think this is a good goal. I would expect quicker iterations even with the web browser complexities.
It would give hope we're not doomed to Google’s corporate strategy of cannibalization.
If you disagree, roll up your sleeves and show us how you can make it better. Otherwise, STFU.
get something working
make it correct
make it fast
Having a vanilla green field working web browser could enable experimentation. Prototying a novel more useful hybrid history & bookmarks feature set, for instance, is a giant pain thru the current plugin extensions. Like sucking apples thru a soda straw. As you said about lower level APIs, it's easier to "go straight to the metal".
It's the best (perhaps only) "small project to stratosphere" 101-recipe I've found. [Note that for browsers, even 1% of market share is stratosphere-level.]
Historical music/media apps were a great example before browsers (Winamp, Foobar2K, XBMC…). Tiny teams + key community contributions made for amazingly complete and rich software fit for all use-cases, beating any commercial alternative by far.
(The fact is that to this day, these 2000-2010 solutions gave you far more user-power & customization, not to mention discoverability and meta-knowledge, than current Netflix or Spotify UIs.)
A project like Ladybird should take that general road, IM(very but educated)HO. That's how they can eventually catch up to big names feature-wise.
- This post
- Yesterday: https://news.ycombinator.com/item?id=40845951
- 2 weeks ago: https://news.ycombinator.com/item?id=40746804
- 4 weeks ago: https://news.ycombinator.com/item?id=40560768
Anyway, I don't mind that much. I hope they succeed.
2. Would it have the features of the Line Mode Browser?
> preparing to become the only major web browser which does not treat the user like the product being sold.
...is either ignorant or a deliberate slam on Mozilla. Whatever else you might say about Firefox, it has never tried to "sell" me to anyone. The fact of the matter is that Mozilla has done the impossible for decades and gets no end of grief for it.
(I expect we'll get a zillion complaints about search engine placement & Pocket recommendations because that always happens on this site)
Clearly, they are referring to paid search engine placement. But that doesn't just apply to Mozilla, it also applies to Apple/Safari.
And given that both Mozilla and Apple are being payed by Google somewhat proportionally to how many users they have, clearly users are indeed being treated like a product being sold.
The risk of exploits is too high
Random exploits on the Internet are still a higher risk for me.
WebGL, WebGL2, WebGPU, WebNN, WebXR, WebAudio, WebRTC, WebAssembly? Etc....?
Each of those seem like a multi-year project for a team on their own if you're not going to take code from any other browser
legacyPackages.x86_64-linux.ladybird (0-unstable-2024-06-04)
nix run nixpkgs#ladybird
...
502144.831 Ladybird(1297933): WebContent process crashed!
502144.831 Ladybird(1297933): WebContent has crashed 5 times in quick succession! Not restarting...
...
I'll check back every few months and see how it's going!
I wish distros would not package pre-alpha software, since the only thing it accomplishes is giving people a bad first impression of something that isn't ready :(
If you want to mess with Ladybird, build it from the source at https://github.com/LadybirdBrowser/ladybird :)
Clearly, some upstreams do not appreciate that NixOS provides non-standard or sometimes-unfinished versions of their software, but it's either that or the software is essentially unusable and uncompilable on NixOS.
I do wonder if there is a potential for productive compromise, though. Maybe it would be desirable to have a QMessageBox warning to the user at startup that the distribution is unsupported and bugs should not be reported upstream. I think that the folks maintaining the Ladybird derivation would be happy to take feedback into account.
If that doesn't work, please open an issue in the nixpkgs bug tracker.
So, some people feel that it'd be better to have a viable browser that isn't dependent upon Google.
Sorry sometimes I get a bit existential.
good luck
- Quark is written in Coq and is formally verified. What can be learned from the design of Quark and other larger formally-verified apps.
From "Why Don't People Use Formal Methods?" (2019) https://news.ycombinator.com/item?id=18965964 :
> - "Quark : A Web Browser with a Formally Verified Kernel" (2012) (Coq, Haskell) http://goto.ucsd.edu/quark/
From https://news.ycombinator.com/item?id=37451147 :
> - "How to Discover and Prevent Linux Kernel Zero-day Exploit using Formal Verification" (2021) [w/ Coq] http://digamma.ai/blog/discover-prevent-linux-kernel-zero-da... https://news.ycombinator.com/item?id=31617335
- Rootless containers require /etc/subuids to remap uids. Browsers could run subprocesses like rootless containers in addition to namespaces and application-level sandboxing.
- Chrome and Firefox use the same pwn2own'd sandbox.
- Container-selinux and rootless containers and browser tab processes
- "Memory Sealing "Mseal" System Call Merged for Linux 6.10" (2024) https://news.ycombinator.com/item?id=40474551
- Endokernel process isolation: From "The Docker+WASM Technical Preview" https://news.ycombinator.com/item?id=33324934
- QubesOS isolates processes with VMs.
- Gvisor and Kata containers further isolate container processes
- W3C Web Worker API and W3C Service Worker API and process isolation, and resource utilization
- From "WebGPU is now available on Android" https://news.ycombinator.com/item?id=39046787 :
>> What are some ideas for UI Visual Affordances to solve for bad UX due to slow browser tabs and extensions?
>> - [ ] UBY: Browsers: Strobe the tab or extension button when it's beyond (configurable) resource usage thresholds
>> - [ ] UBY: Browsers: Vary the {color, size, fill} of the tabs according to their relative resource utilization
>> - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU
- What can be learned from few methods and patterns from rust rewrites, again of larger applications
"MotorOS: a Rust-first operating system for x64 VMs" https://news.ycombinator.com/item?id=38907876 :
> "Maestro: A Linux-compatible kernel in Rust" (2023) https://news.ycombinator.com/item?id=38852360#38857185 ; redox-os, cosmic-de , Motūrus OS; MotorOS
From "Industry forms consortium to drive adoption of Rust in safety-critical systems" (2024) https://news.ycombinator.com/item?id=34743393 :
> - "The Rust Implementation of GNU Coreutils Is Becoming Remarkably Robust" https://news.ycombinator.com/item?id=34743393
> [Rust Secure Coding Guidelines, awesome-safety-critical,]
I mean it both in a sarcastic way and not.
Such soulless corpo design is not befitting of a project this nice.
People talk about 'polish' in design as a signifier of quality but my mind always goes to conching, the process by which cacao nibs are ground down over days to produce silky chocolate. You need to conch the nibs to grind them past the point that the chocolate has a gritty texture in order to get the nice smooth chocolate we all love, but what the process also does is grind down the sharper notes of the flavour. The further you go the more the deeper and richer notes are lost. So too a design language and brand can be conched to smooth it out for broader consumption, but you can go too far and lose the flavour.
> This page is not fancy because we are focusing on building the browser. :^)
I approve this message
But I see now that they actually updated the site.
Why not fork Firefox or Chromium?
Can you point to an example where Mozilla's funding model led it to make a bad decision?
Also twenty hours ago: https://news.ycombinator.com/item?id=40845951
One day ago: https://news.ycombinator.com/item?id=40838973
Along with 60 other threads you can see by clicking the link I posted.
Oh the homepage was discussed yesterday? Let's add /index.html and resubmit it!
Is avoiding those sorts of things not supposed to be reason enough for them?
Also the page does a good job of specifically mentioning Google and making general statements about what any source of funding can impact. If Google wanted to give an unrestricted donation it's not clear from this page they would decline it.