Then folks should not complain about Google taking over the Web, when being part of the problem.
We managed to write cross platform games and applications across 8 and 16 bit home computers, but apparently that is too complicated to architect for Chrome as App adopters.
If it is to be Web stack, maybe learn how to support various browsers, instead of shipping one with the application.
I'm explaining how we got here, not justifying it.
> We managed to write cross platform games and applications across 8 and 16 bit home computers, but apparently that is too complicated to architect for Chrome as App adopters.
I'm not sure what you mean. For past 40 years making app run on Windows, Linux, Mac, and now iOS and Android has been a pain unless you wrote a webapp. Or shipped it in a container (Electron).
> If it is to be Web stack, maybe learn how to support various browsers, instead of shipping one with the application.
The issue as developer I experienced is justifying thi effort to management/money-holders.
- I spent last day optimizing our CSS for Firefox.
+ How many of our customers use Firefox?
- 1%
+ I'm going to file that as unpaid leave.
I just don't see a way around the monoculture in web browsers. Web developers don't bother testing it (works on my chromium), management doesn't want to bother with it (what is firefax?), and users just want website to work (how come Firex doesn't work as good as Chromum? Also why do I have 300 toolbars).
People always say that, but I don't see why would I want that. I like the idea of a browser engine in Rust, but I actually hope it might theoretically replace Chrome in 10 years, because it's better. Browser Engine is not an opinionated thing, or shouldn't be, anyway, why would I want any "alternatives" for that? I would rather have 1 engine and several good browsers, which are ultimately opinionated. Meanwhile, we do have more than 1 solid engine, and, uh, let;s say 0.8 good browsers.
Management of browser engines are absolutely opinionated. It's chock full of opinions. Decisions to not deprecate, decisions on which features to add, decisions on which features to refuse to add, all align around the incentives of the people who control the browser engine. For the last fifteen+ years the internet has primarily been driven forward by the needs of Apple and Google. There's no reason we have to continue like this, though.
Third party cookies are a great example of how chrome is actively hamstringing the entire internet with its dominance and control by a for-profit multinational.
> Browser Engine is not an opinionated thing, or shouldn't be, anyway, why would I want any "alternatives" for that? I would rather have 1 engine and several good browsers, which are ultimately opinionated.
Maybe you don’t see the irony in your comment, but that is exactly how you get opinionated engine. If there is only one party that controls the only engine, that is the definiton of ”opinionated”.
The invention of JavaScript, the rise and fall of ActiveX, and the death blow to Flash have all been opinions held by browser engine makers with dominant market positions. Even just Mozilla's pre-Chrome opinion of "our JavaScript engine is fast enough"
Google is no less opinionated with Chrome than Netscape, Microsoft and Apple have been. Google's opinions for the most parts align with our own, but that doesn't make it any less opinionated. And a Servo-monopoly would be better but still not great. Firefox started to stagnate after it took over from IE and vastly improved once Chrome appeared. Competition keeps things healthy
In my opinion, web browsers have become too popular and widespread. They're an important application on nearly every phone, laptop and desktop computer sold. The pressure to implement pervasive tracking is immense. I don't see a future where companies like Google, Microsoft and Apple all decide to drop this level of tracking and switch to an open-source product.
If another browser engine is good enough they might _fork_ it in order to add these kind of predatory features. Kind of like they already did with WebKit, now that I think about it. :-P
Before browsers was Windows. Microsoft had dominance, and they lost it.
I think browser based Apps took over in business because (1) Windows had shit security and shit App deployment, (2) Microsoft somehow forgot about developers developers developers.
It's also worth remembering that developing cross-platform between windows and literally anything else (excepting maybe the xbox? never owned one) is a nightmare. At best managed code will handle some of it, but Windows has many primitives that operate fundamentally differently than other desktop platforms. That alone will ensure I'll never touch that market except potentially as a secondary effort if a product takes off. (I also haven't had to use windows for anything since like 2009, which helps.)
My favorite example of this is to look at all the hoops Wine has to jump through to get decent performance for locks. Apparently many developers writing for Windows default to using a locking primitive that can wait for a list of locks (specified by handles), and those locks can be shared between processes. That primitive frequently gets used even for waiting on a single lock confined within a single process, but Wine usually still has to go through the incredibly expensive emulation to handle the general case.
> and those locks can be shared between processes. That primitive frequently gets used even for waiting on a single lock confined within a single process
And why not use a cheap primitive and if a lock is detected to be shared between multiple processes then upgrade it to the "expensive emulation"?
The NTSYNC driver lands this month with Linux 6.14. I've been following the Wine MR the last few weeks eagerly waiting for it. Especially for Nvidia users this should help close some of the performance gap between Windows/Linux while the GPU drivers catch up.
Microsoft never forgot about locking developers in. As someone with trying to fulfill an organizational imperative to deliver cross-platform compatibility, they made my life as miserable as they possibly could.
> [Microsoft] made my life as miserable as they possibly could.
Exactly what I was saying. They had the goodwill of developers and then they burned it. Any developer through the 00's got burned multiple times - like the terrible Kiddie Server 2008. They are still burning us with Telemetry and unprofessional choices like advertising within the OS.
Before that they delivered mediocre but functional software. It worked. Now it doesn't work so well and is a masterclass in ugly graphic design and usability flaws.
Bookmarks and tabs are something that dedicated group can do in one week. Even I managed to do that decade ago.
The difficult part (rendering, its correctness and performance, protocol support and security) matters more. After that, maybe someone will build UI on top of that.
Thanks. How much of the remaining missing support is necessary for pragmatic daily-driver use by computer nerds?
For what I have in mind, initially, a non-requirement is perfectly mimicking whatever someone managed to jam into a standard, unless it's really necessary to use "necessary" sites.
(Anyone who does a lot of blocking of ads/trackers will already be familiar with sites not being pixel-perfect.)
I'm thinking that bending over to mimick someone's big-moat browser behavior standards in every detail can be a secondary priority, for later, after nerds are already using it successfully as a daily driver.
Nothing says nerds can't keep a Chromium installed as an emergency backup, for trying that one demo that uses the latest thing Google-Microsoft is going to railroad into the standard, or for watching Netflix while traveling. (And for Web development testing, of course.) But otherwise, we should be dogfooding, like we had to do with Linux.
Seems like most nerds that are looking for an alternative browser engine are instead moving towards Ladybird.
Last year they passed Servo in WPT and recently passed Servo in stars.
As of January, Ladybird has been able to successfully render Gmail[0], so I imagine this year it will be able to solve most users daily-driver requirements.
Interesting. Has Ladybird solved memory bugs somehow, or is the situation going to be the usual constant security vulnerabilities and frequent security updates?
I have mixed feelings about Rust, but it's one way to improve the current culture of tolerating numerous memory defects in C and C++ desktop application programs and userland libraries. So that would be a point in Servo's favor, unless they've Rusted themselves into a borrowing/lifetimes/async development complexity corner that makes moving forward too slow.
I haven't seen anything on memory vulnerability issues. The project originated within a larger project to implement an operating system from scratch - including all dependencies (e.g. font parsing/shaping, image parsing, libc, you name it). That means that the project itself, and every single one of its dependencies, need to go through that whole cycle.
> I haven't seen anything on memory vulnerability issues.
The issue is that barely nobody uses the Ladybird yet, so there are zero interests for anyone serious party to test that security. So nothing gets published about the issues. I don't even know if Ladybird runs in Google's Clusterfuzz.
Memory safety is their long term plan (according to them), and they are going to use Swift for that. Let's see what happens.
Has/will Swift be sufficiently disentangled from Apple influence?
And is this redirecting open source in an essentially proprietary direction (which has happened many times), on the key piece of software that is the Web browser?
Why I'm asking: For a startup, I've used Swift (and SwiftUI, various Apple APIs, "entitlements", developer-hostile App Store experience, often nonexistent documentation). The core language is OK overall (not great). But most of the rest of the developer experience was awful, due to Apple. And you need a lot of pieces beyond the core language.
Ultimately, the people who fund/do the work get to decide how they do it.
I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
> I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
> Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!
> First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.
> Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
IME, Google Meet isn't the worst videoconf (that might be Microsoft Teams). Each one has problems.
But what's even worse than when company/boss mandates a bad or so-so videoconf product, is when you're doing partner/customer calls, and for whatever reason, you wind up using their preferred service. So you have to keep a few/several different ones working on your devices, poorly configured, and have many first time joining difficulties at the start of possibly important meetings.
Another time you need several videoconf is when job-hunting, and so many companies want you to use something different. And it's often shitty. And the first impressions can be high-stakes, while you're trying to get their shitty proprietary thing to work, even with Chrome or as an app you put on your sacrificial videoconf device.
This is a little tricky to solve entirely with open standards, but there's a reason we started doing open standards.
Is anyone building a simple web browser UI (also known as "chrome") that implements WebView API? It would be great to have UI with all the core necessities, like navigation buttons, address bar, bookmarks, download management and few simple settings. User must be able to choose their preferred browser engine and switch it at will, even run one tab using webkit, another with servo. This way browser engine developers can concentrate on building the engine, and UI developers could easily experiment with various layouts and new features in forked projects.
The collectives' operational costs come out of the fee, GitHub is big enough to zero-rate their cut. But I'd kinda rather also support OpenCollective use over a tech monopoly.
No. OpenCollective collectives effectively replace having to operate your own nonprofit organization. So it includes all of the legal, administrative, and accounting costs of operating a nonprofit on behalf of the participating collectives.
I operate a collective which effectively operates as a 501c6 but I file no paperwork, OSC does for us.
> OpenCollective collectives effectively replace having to operate your own nonprofit organization.
> I operate a collective which effectively operates as a 501c6 but I file no paperwork, OSC does for us.
I think you might have meant Open Collective fiscal hosts replace having to operate a nonprofit organisation? Unless I'm parsing your statements wrong.
Yeah, I try not to get too in the weeds on terms when describing OpenCollective to people unaware. (Also the company, nonprofit, and biggest fiscal hosts have historically largely been run by the same folks.)
The core point is just that OpenCollective is not just a payment processor.
I think it could garner more support with a license that would guaranteed that it stays free instead of the MPL.
With such a liberal license what would stop Google or Microsoft to build their own proprietary browser on to of Servo? At this point releasing software under liberal licenses instead of (A)GPL is basically providing free labor for the tech monopolists.
I felt like this link is missing some important context.
History: Initially started by Mozilla in 2012. They laid off the team off in 2020 and transferred the project to the Linux Foundation. Source: https://en.wikipedia.org/wiki/Servo_(software)
If my memory serves me right, Rust was initially created FOR Servo. Rust came into existence because Mozilla wanted a memory safe browser engine and couldn’t achieve that with existing languages without garbage collection.
Without GC came later, Rust was originally designed with GC as well.
Basically how languages like Swift, D, Chapel, OCaml, Haskell are now approaching it, using the type system in addition to automatic memory management mechanisms, not just one way.
Rust pre-1.0 was full of sigils, Perl style, on what kind of memory a type related to to.
We'll need Servo to counterbalance Chrome's dominance. I'll chip in $5.
It starts by not pushing Chrome all over the place, including Electron, that is how we got here.
Well it's more of there is one cross platform GUI, plenty developers know it, and it isn't hobbled by performance issues or hard to develop for.
Then folks should not complain about Google taking over the Web, when being part of the problem.
We managed to write cross platform games and applications across 8 and 16 bit home computers, but apparently that is too complicated to architect for Chrome as App adopters.
If it is to be Web stack, maybe learn how to support various browsers, instead of shipping one with the application.
I'm explaining how we got here, not justifying it.
> We managed to write cross platform games and applications across 8 and 16 bit home computers, but apparently that is too complicated to architect for Chrome as App adopters.
I'm not sure what you mean. For past 40 years making app run on Windows, Linux, Mac, and now iOS and Android has been a pain unless you wrote a webapp. Or shipped it in a container (Electron).
> If it is to be Web stack, maybe learn how to support various browsers, instead of shipping one with the application.
The issue as developer I experienced is justifying thi effort to management/money-holders.
- I spent last day optimizing our CSS for Firefox.
+ How many of our customers use Firefox?
- 1%
+ I'm going to file that as unpaid leave.
I just don't see a way around the monoculture in web browsers. Web developers don't bother testing it (works on my chromium), management doesn't want to bother with it (what is firefax?), and users just want website to work (how come Firex doesn't work as good as Chromum? Also why do I have 300 toolbars).
People always say that, but I don't see why would I want that. I like the idea of a browser engine in Rust, but I actually hope it might theoretically replace Chrome in 10 years, because it's better. Browser Engine is not an opinionated thing, or shouldn't be, anyway, why would I want any "alternatives" for that? I would rather have 1 engine and several good browsers, which are ultimately opinionated. Meanwhile, we do have more than 1 solid engine, and, uh, let;s say 0.8 good browsers.
> Browser Engine is not an opinionated thing
Management of browser engines are absolutely opinionated. It's chock full of opinions. Decisions to not deprecate, decisions on which features to add, decisions on which features to refuse to add, all align around the incentives of the people who control the browser engine. For the last fifteen+ years the internet has primarily been driven forward by the needs of Apple and Google. There's no reason we have to continue like this, though.
Third party cookies are a great example of how chrome is actively hamstringing the entire internet with its dominance and control by a for-profit multinational.
> Browser Engine is not an opinionated thing, or shouldn't be, anyway, why would I want any "alternatives" for that? I would rather have 1 engine and several good browsers, which are ultimately opinionated.
Maybe you don’t see the irony in your comment, but that is exactly how you get opinionated engine. If there is only one party that controls the only engine, that is the definiton of ”opinionated”.
The invention of JavaScript, the rise and fall of ActiveX, and the death blow to Flash have all been opinions held by browser engine makers with dominant market positions. Even just Mozilla's pre-Chrome opinion of "our JavaScript engine is fast enough"
Google is no less opinionated with Chrome than Netscape, Microsoft and Apple have been. Google's opinions for the most parts align with our own, but that doesn't make it any less opinionated. And a Servo-monopoly would be better but still not great. Firefox started to stagnate after it took over from IE and vastly improved once Chrome appeared. Competition keeps things healthy
It's not really competition when your paid by the other party.
> Browser Engine is not an opinionated thing
Here are some “opinions”
“The engine shouldn’t allow the user to block select parts of the content”
“Telemetry should always be on”
“The engine should restrict access to a list of websites and domains provided by the government”
“All encryption should have a backdoor”
[flagged]
[flagged]
You don't need alternatives or competition, you just need improvements. But competition spurs improvements and alternatives spur competition.
In my opinion, web browsers have become too popular and widespread. They're an important application on nearly every phone, laptop and desktop computer sold. The pressure to implement pervasive tracking is immense. I don't see a future where companies like Google, Microsoft and Apple all decide to drop this level of tracking and switch to an open-source product.
If another browser engine is good enough they might _fork_ it in order to add these kind of predatory features. Kind of like they already did with WebKit, now that I think about it. :-P
Before browsers was Windows. Microsoft had dominance, and they lost it.
I think browser based Apps took over in business because (1) Windows had shit security and shit App deployment, (2) Microsoft somehow forgot about developers developers developers.
It's also worth remembering that developing cross-platform between windows and literally anything else (excepting maybe the xbox? never owned one) is a nightmare. At best managed code will handle some of it, but Windows has many primitives that operate fundamentally differently than other desktop platforms. That alone will ensure I'll never touch that market except potentially as a secondary effort if a product takes off. (I also haven't had to use windows for anything since like 2009, which helps.)
My favorite example of this is to look at all the hoops Wine has to jump through to get decent performance for locks. Apparently many developers writing for Windows default to using a locking primitive that can wait for a list of locks (specified by handles), and those locks can be shared between processes. That primitive frequently gets used even for waiting on a single lock confined within a single process, but Wine usually still has to go through the incredibly expensive emulation to handle the general case.
> and those locks can be shared between processes. That primitive frequently gets used even for waiting on a single lock confined within a single process
And why not use a cheap primitive and if a lock is detected to be shared between multiple processes then upgrade it to the "expensive emulation"?
The NTSYNC driver lands this month with Linux 6.14. I've been following the Wine MR the last few weeks eagerly waiting for it. Especially for Nvidia users this should help close some of the performance gap between Windows/Linux while the GPU drivers catch up.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7226
Microsoft never forgot about locking developers in. As someone with trying to fulfill an organizational imperative to deliver cross-platform compatibility, they made my life as miserable as they possibly could.
> [Microsoft] made my life as miserable as they possibly could.
Exactly what I was saying. They had the goodwill of developers and then they burned it. Any developer through the 00's got burned multiple times - like the terrible Kiddie Server 2008. They are still burning us with Telemetry and unprofessional choices like advertising within the OS.
Before that they delivered mediocre but functional software. It worked. Now it doesn't work so well and is a masterclass in ugly graphic design and usability flaws.
Most obviously because that one engine is guided by Google's goals, so ex. it has deliberately-inferior support for adblocking.
We changed the URL from https://opencollective.com/servo to the Github Sponsors page - see https://news.ycombinator.com/item?id=43221739 for why.
What's a sober assessment of the state of a full Web browser using Servo, and scale of effort to get there?
It needs features like bookmarks and basic tabs, and support for uBlock Origin rulesets (either as an extension or built-in).
It doesn't need features like DRM, tethering to mothership services, telemetry, and paid-placement portal screens.
Bookmarks and tabs are something that dedicated group can do in one week. Even I managed to do that decade ago.
The difficult part (rendering, its correctness and performance, protocol support and security) matters more. After that, maybe someone will build UI on top of that.
They still have 62% pass rate in WPT so my guess is that there's still a lot to do to make it usable as a browser.
Thanks. How much of the remaining missing support is necessary for pragmatic daily-driver use by computer nerds?
For what I have in mind, initially, a non-requirement is perfectly mimicking whatever someone managed to jam into a standard, unless it's really necessary to use "necessary" sites.
(Anyone who does a lot of blocking of ads/trackers will already be familiar with sites not being pixel-perfect.)
I'm thinking that bending over to mimick someone's big-moat browser behavior standards in every detail can be a secondary priority, for later, after nerds are already using it successfully as a daily driver.
Nothing says nerds can't keep a Chromium installed as an emergency backup, for trying that one demo that uses the latest thing Google-Microsoft is going to railroad into the standard, or for watching Netflix while traveling. (And for Web development testing, of course.) But otherwise, we should be dogfooding, like we had to do with Linux.
Seems like most nerds that are looking for an alternative browser engine are instead moving towards Ladybird.
Last year they passed Servo in WPT and recently passed Servo in stars.
As of January, Ladybird has been able to successfully render Gmail[0], so I imagine this year it will be able to solve most users daily-driver requirements.
[0] https://www.youtube.com/watch?v=-l8epGysffQ
Interesting. Has Ladybird solved memory bugs somehow, or is the situation going to be the usual constant security vulnerabilities and frequent security updates?
I have mixed feelings about Rust, but it's one way to improve the current culture of tolerating numerous memory defects in C and C++ desktop application programs and userland libraries. So that would be a point in Servo's favor, unless they've Rusted themselves into a borrowing/lifetimes/async development complexity corner that makes moving forward too slow.
I haven't seen anything on memory vulnerability issues. The project originated within a larger project to implement an operating system from scratch - including all dependencies (e.g. font parsing/shaping, image parsing, libc, you name it). That means that the project itself, and every single one of its dependencies, need to go through that whole cycle.
> I haven't seen anything on memory vulnerability issues.
The issue is that barely nobody uses the Ladybird yet, so there are zero interests for anyone serious party to test that security. So nothing gets published about the issues. I don't even know if Ladybird runs in Google's Clusterfuzz.
Memory safety is their long term plan (according to them), and they are going to use Swift for that. Let's see what happens.
Has/will Swift be sufficiently disentangled from Apple influence?
And is this redirecting open source in an essentially proprietary direction (which has happened many times), on the key piece of software that is the Web browser?
Why I'm asking: For a startup, I've used Swift (and SwiftUI, various Apple APIs, "entitlements", developer-hostile App Store experience, often nonexistent documentation). The core language is OK overall (not great). But most of the rest of the developer experience was awful, due to Apple. And you need a lot of pieces beyond the core language.
Ultimately, the people who fund/do the work get to decide how they do it.
I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
> I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.
See here for his reasoning for picking Swift: https://x.com/awesomekling/status/1822236888188498031
> Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!
> First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.
> Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.
> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.
Here is a lot of discussion about the same concerns: https://news.ycombinator.com/item?id=41208836
> Nothing says nerds can't keep a Chromium installed as an emergency backup,
I do, now
My boss insists on Google Meet, and it will not access audio on Firefox
Every single other website does not have this problem, dark patterns indeed
I use Meet from Firefox desktop with audio. Are you on mobile?
Dell laptop running Debian-12
Signal Desktop seems to be the best conference app these days. Give a tip.
Most people have to use what their company says to use.
Condolences.
IME, Google Meet isn't the worst videoconf (that might be Microsoft Teams). Each one has problems.
But what's even worse than when company/boss mandates a bad or so-so videoconf product, is when you're doing partner/customer calls, and for whatever reason, you wind up using their preferred service. So you have to keep a few/several different ones working on your devices, poorly configured, and have many first time joining difficulties at the start of possibly important meetings.
Another time you need several videoconf is when job-hunting, and so many companies want you to use something different. And it's often shitty. And the first impressions can be high-stakes, while you're trying to get their shitty proprietary thing to work, even with Chrome or as an app you put on your sacrificial videoconf device.
This is a little tricky to solve entirely with open standards, but there's a reason we started doing open standards.
How is Ladybird so much further ahead when servo had years of commercial funding? Just different priorities?
Is anyone building a simple web browser UI (also known as "chrome") that implements WebView API? It would be great to have UI with all the core necessities, like navigation buttons, address bar, bookmarks, download management and few simple settings. User must be able to choose their preferred browser engine and switch it at will, even run one tab using webkit, another with servo. This way browser engine developers can concentrate on building the engine, and UI developers could easily experiment with various layouts and new features in forked projects.
> Donating via GitHub Sponsors is better for Servo than donating via Open Collective
https://servo.org/sponsorship/#donation-fees
(Someone asked us to change the top link but I'm not sure we should do that without permission from lostmsu.
What I did do is detach this subthread from https://news.ycombinator.com/item?id=43221548, so it's now the top comment.)
Edit: permission received. Link changed now (https://news.ycombinator.com/item?id=43222904).
Hmm. GitHub being big enough gives some leverage for payment method fees? Seems a bit absurd that PayPal can take more than 10%.
The collectives' operational costs come out of the fee, GitHub is big enough to zero-rate their cut. But I'd kinda rather also support OpenCollective use over a tech monopoly.
Aren't those operational costs in this case those payment processor fees? Because otherwise there should not be much difference.
No. OpenCollective collectives effectively replace having to operate your own nonprofit organization. So it includes all of the legal, administrative, and accounting costs of operating a nonprofit on behalf of the participating collectives.
I operate a collective which effectively operates as a 501c6 but I file no paperwork, OSC does for us.
> OpenCollective collectives effectively replace having to operate your own nonprofit organization.
> I operate a collective which effectively operates as a 501c6 but I file no paperwork, OSC does for us.
I think you might have meant Open Collective fiscal hosts replace having to operate a nonprofit organisation? Unless I'm parsing your statements wrong.
Yeah, I try not to get too in the weeds on terms when describing OpenCollective to people unaware. (Also the company, nonprofit, and biggest fiscal hosts have historically largely been run by the same folks.)
The core point is just that OpenCollective is not just a payment processor.
I think you missed my point. Or are you saying that if I pay with PayPal instead of Stripe, OpenCollective gets themselves more money?
Man PayPal skimming 20% is insane. Do they get away with it just because of name recognition?
I think it could garner more support with a license that would guaranteed that it stays free instead of the MPL.
With such a liberal license what would stop Google or Microsoft to build their own proprietary browser on to of Servo? At this point releasing software under liberal licenses instead of (A)GPL is basically providing free labor for the tech monopolists.
Supposedly, Apple now allows third party web engines on iOS. Is there a Servo iOS roadmap?
> Apple now allows third party web engines on iOS
Really?
I want to know more about that
Silly me: Should have checked for myself...
https://www.theverge.com/2024/1/25/24050478/apple-ios-17-4-b...
Haven't they always done that?
No, Mozilla developed a full Firefox for iOS in ~2010, and Apple flatly refused to put it on the AppStore.
This was not a full Firefox, just a basic demo browser to showcase the port that TedM did. It was not even submitted to the app store.
Ah, that's how I recall Vivien telling me the story, but that was a long time ago, I may be misremembering.
Even now it's only allowed in the EU, and only subject to a restrictive set of rules.
No. 3rd party browsers were allowed but they had to use WkWebView as engine.
I felt like this link is missing some important context.
History: Initially started by Mozilla in 2012. They laid off the team off in 2020 and transferred the project to the Linux Foundation. Source: https://en.wikipedia.org/wiki/Servo_(software)
2025 Roadmap: https://github.com/servo/servo/wiki/Roadmap
50k commits 22k closed PRs. Rust language has 280k commits and 80k PRs respectively. Not a small project by any means.
If my memory serves me right, Rust was initially created FOR Servo. Rust came into existence because Mozilla wanted a memory safe browser engine and couldn’t achieve that with existing languages without garbage collection.
Without GC came later, Rust was originally designed with GC as well.
Basically how languages like Swift, D, Chapel, OCaml, Haskell are now approaching it, using the type system in addition to automatic memory management mechanisms, not just one way.
Rust pre-1.0 was full of sigils, Perl style, on what kind of memory a type related to to.
I was wondering why are random donation page was on the front page.