For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | more fabrice_d's commentsregister

Most of Firefox user base has always been on Windows, not Linux. What OS do you think the "techies" that promoted Firefox to replace IE in the first place were running?


Sure maybe 20 years ago. But back then Linux's userbase was also on Windows, because desktop Linux hadn't really become usable yet. I think nowadays Firefox's marketshare is a lot higher on e.g. Ubuntu (where it's the default) than it is on Windows (where Edge is the default).


According to Mozilla's own data at https://data.firefox.com/dashboard/hardware Windows (7, 10 & 11) make up 84% of their user base.


That's not the claim being made and you know it


Only thing that wasn't usable on Linux 20 years ago was games.


No, the phone variant of HarmonyOS runs on top of a Linux kernel.


I believe thats being phased out slowly to be native app only with their multidevice HarmonyOSNext (mobile/pc). Once the major apps move over , last bits of linux will be excised.


Nope, the new version removed it.

https://en.wikipedia.org/wiki/HarmonyOS_NEXT


Indeed, I did not see that!


It is absolutely Google's security issue if they use an open source project with that license:

https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/COPYING....

and then expect volunteers to provide them fixes.


Google never asked a volunteer for a fix.

This is part of Google’s standard disclosure policy: it gets disclosed within 90 days starting from confirmation+contact.

If ffmpeg didn’t want to fix it, they could’ve just let the CVE get opened.


It's not just Google who could be affected by this.

> and then expect volunteers to provide them fixes.

Expect volunteers to provide everyone using the software with fixes.


For a bug in the LucasArts Smush codec? Why didn't you verify it was an mp4/h264 first?


Mp4 is an envelope codec, so it could be both an mp4 and an obscure codec


Related: https://github.com/servo/servo/issues/21817

You should likely join https://servo.zulipchat.com and ask questions to know where to start.


On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages). On the web it's currently impossible to bootstrap the integrity verification with just SRI.

This proposal aims at providing the same guarantees for web apps, without resorting to signed packages on the web (ie. not the same mechanism that FirefoxOS or ChromeOS apps used). It's competing with the IWA proposal from Google, which is a good thing.


> On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages)

Not quite. It is possible for an account to be taken over or bought and a new update deployed. It is also possible for the server the app gets its data from to be taken over just like in your example and serve you fake data to make you regurgitate whatever data the malicious actor wants


The wpt score is not that well balanced. Look at https://staging.wpt.fyi/results/?product=servo&product=ladyb... : out of about 2 million tests, more than half are for the "encoding" category. Good encoding support is needed for sure, but likely not at that level of prevalence.


It seems my communication did not adequately convey the fact that I have no problem with the Ladybird team doing this. It makes perfect sense and is the right thing to do.

However, a jump like that means precisely and exactly what I said it means; very suddenly, that metric became much more important to the team. It is written straight into the graph.

A large number of encoding-related tests that were probably relatively easy to fix in bulk is certainly a plausible explanation.

A lot of people are imputing to me assumptions that they are bringing to my post, such as assuming that such improvements must be fake or bad or somehow otherwise cheating. Nope. Moreover, if you are thinking that, don't take it up with me, go take it up with the graph directly. It's not my graph. I'm just amused at the spectacular demonstration of Goodhart's Law.

Are the commentators who think I'm being critical of the Ladybird project going to defend their implicit proposition that the browser got twice as good in whatever period that graph is in, a week or a month or whatever? Of course that's not the case.


> However, a jump like that means precisely and exactly what I said it means; very suddenly, that metric became much more important to the team. It is written straight into the graph.

Not really, though. The latest jump was from implementing some CSS Typed OM features, which has been in-progress work for a while now. The 6k increase in the test score was a bit of a happy surprise. It's also not that much of a jump when you zoom out and see it's "just" a continuation of a steady increase in score over a long period.


fwiw, I'm not imputing you any assumptions. I'm just pointing out that using wpt score as a criteria is not necessarily a good proxy for browser readiness. So I'm not sure why Apple uses that, other than... there's no other objective measure? Of course it's fair game for browser engines to improve their score!


Dude at this point just raise your knickers up and criticize the thing. You’ve got the most valuable observation about this topic on your side. The graph is jarring and for someone only recently made familiar with Goodhart’s Law this is a great example of it in practice. You must be further well-informed enough to defend any issues you actually have with the project outright instead of this small war of attrition playing out waaay down here.

Too much useful insight is withheld or misappropriated these days.


It looks like Amazon has people looking at Servo integration in GTK: https://blogs.gnome.org/nacho/2025/10/01/servo-gtk/


This is what https://c2pa.org/ is for. I think some camera vendors already have support.


It's a Rust based OS, so I expect people to try a Servo port instead!


The "almost" is very load bearing there... It's not remotely competitive with blink/webkit/gecko yet, be it for features support or performance.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search:

HN For You