in my “why are y’all rewriting everything in Rust while critical infrastructure goes unmaintained” era
@aschmitz pretty sure all web browsers depend on either it directly or a fork of it (statically linked, probably, and i’m not sure how exactly the code is joined together)
if not, i’d be interested in finding out whatever they ARE using
@aschmitz and yes i would love for someone to rewrite it as well (and make it support XML1.1, and XSLT/XPATH 2.0, and 3.0…), but nobody IS going to do that, because it’s very hard, and in the meantime libxml2 is what is available on every platform, and it still has bugs i would love to see get solved
@aschmitz (i think actually webkit and chrome depends on libxml2/libxslt and gecko has their own c++ implementation.)
@Lady WebKit uses libxslt, at least it did when I packaged it.
Firefox has its own custom HTML 5 parser, originally developed around 2009 and somewhat based off the HTML 5 standard parsing algorithm and a Java reference implementation, unimaginatively just called "parser". It does vendor a copy of Expat for pure XML.
See also:
https://johnresig.com/blog/html-5-parsing/
https://hacks.mozilla.org/2010/05/firefox-4-the-html5-parser-inline-svg-speed-and-more/
https://hg-edge.mozilla.org/mozilla-central/file/tip/parser
@awilfox @Lady WebKit developer here! Libxml and libxslt are used for... Well, XML and XSLT support (mainly the latter). The main HTML/XHTML parser is custom and heavily tested (and fuzzed) like the rest of WebKit. For those truly concerned about bugs in those libraries, both @WebKitGTK and @WPEWebKit may be built without them but losing a bit of (somewhat niche) functionality.
@awilfox @Lady @WebKitGTK @WPEWebKit the relevant code is in https://github.com/WebKit/WebKit/tree/main/Source/WebCore/html/parser
@lanodan @Lady Kind of, yes. Though systemd and ninja only need it for building, nginx only(?) needs it for libnginx-mod-http-xslt-filter, and php uses it for php-xml. And we're both leaving out things, but I was just sort of surprised by how few things actually seem to have firm dependencies on it. On the other hand, there's enough that if it stopped working with, say, a new glibc/musl version, there would probably be a fix in short order.
@aschmitz a suggestion as someone who has been on both the giving and receiving end of comments like these: please stop making it seem like the only "important" use of Linux is in the server space.
"Some important packages [...] but mostly desktop software" implies that desktop Linux is not important. This is why the Linux desktop sucks so much. Because people don't take it seriously and don't WANT to take it seriously. It does not have to be this way.
@awilfox Sorry, the background on not being as perturbed by those is that desktop software tends to have different attack surface and needs than server software. But you're right of course that they're not unimportant.
(And as someone who has primarily used Linux on the desktop since (eep!) 2004, I do take it seriously, but I don't agree that it sucks.)
@aschmitz mm, so that was more of a security "importance" than anything. Fair.
I've been using desktop Linux since 1999, but I suppose my bar of suckitude (is that still a word?) drops lower ever year. I think all of them are terrible, Windows, Mac, KDE, especially GNOME, LXQt, XFCE, TDE, MATE, Cinnamon, elementary, I could go on… but for vastly different reasons. I primarily daily a mix of Mac and KDE and continue to desperately wish for one of two miracles: that Apple suddenly MIT or GPL's Aqua, or that KDE convinces Qt to stop using FOSS users as guinea pigs and beta testers only.
I am aware neither of these will happen.
@Lady you know why
@Lady It actually has a surprisingly small set of rdepends within Ubuntu. Some important packages, like Postgres, but mostly desktop software besides Postgres, Icecast, and Asterisk, and it's hard to say the latter have all too many users. There's Ruby's Nokogiri, but given the near-weekly security updates to that, I might almost prefer someone Rewrite it in Rust (or literally anything).