Meanwhile libxml2 is still everywhere. Without someone with real backing, a core piece of infrastructure is about to go unmaintained.
Once again, the open-source funding problem is laid bare: the internet runs on the unpaid evenings of a few people until they burn out (add relevant reference from XKCD, obviously).
For instance, consuming XML and creating it are two very different use cases. Zooming into consuming it, perhaps your input data has more guarantees than libxml2 assumes, such as the nonexistence of meta definition tags.
* XSLT is still the only native templating option for HTML pages that runs natively in the browser (but just now you are limited to XSLT v1.0 which as a number of drawbacks and limitations)
* XSLT/XML is still best at text markup. In particular interpolation. There is no simple way to represent marked up text in, say, JSON.
* Content federation (atom, rss) is still very dependent on XML.
Surely somebody somewhere has money to pay for a greybeard to fix XSLT for us? It seems far to fundamental to be left to wither on the vine.
I feel like it adds more weight to my feeling that we should have a software building code. When you have software that's critical infrastructure, with a nutso security policy like "no embargoes / 0day me bruh", we should have some regulations in place to require the software be maintained properly (that is to say, in a sane manner) or you can't use it commercially or for safety-critical things. Which would inevitably force commercial entities to pay for the maintenance so it could be done right.... which they should be doing already, the same way any company that builds safety-critical infrastructure has to pay to do it right.
If we want society to be safe, we have to make a law that enforces it. That's how that shit works.
(as an aside: holy shit, you're a prolific HN submitter, and all from different sources. where do you get it all?)
...you then should stop and re-evaluate your life choices: specifically, choosing this particular piece of software, which is known to have always been insecure, to be a critical part of your infrastructure.
This made my brain go "Oh no, not this again. Open source projects don't owe you..." etc etc.
> or you can't use it commercially or for safety-critical things
Oh. Yeah, okay, absolutely! For safety-critical, I would like to think the responsibility already lies with the integrator/seller, but making it explicitly so can't hurt.
It's not the "safety critical" software that needs this fixed, it's all software in general. There's a million software systems that have important privacy sensitive data or safety relevant processes that fly under the "safety critical" radar.
1. "This XML library is way bigger than what I need, I'll write something more minimal for my use case"
2. write a library for whatever minimal subset you need
3. crash report comes in, realise you missed off some feature x. Add support for some feature x.
4. Bob likes your library. So small, so elegant. He'd love to use it, if only you supported feature y, so you add support for feature y.
...
End result is x+1 big, complex XML libraries.
Obviously Im being a bit obtuse here because you might be able to guarantee some subset of it in whatever your specific circumstances are, but I think it's hard to do over a long period of time. If people think you're speaking XML then at some point they'll say "why don't we use this nice XML feature to add this new functionality".
"You" probably do not.
But different "yous" need different features, and so they get all glommed together into one big thing. So no one needs "all" of lbxml2/XML's features, each individual needs a different subset.
Basically something behaves like your typical JSON parser and serialiser but for XML.
To my knowledge, this is what TinyXML2 does, and I've used TinyXML2 for this before to great effect.
Of course this is an oversimplification, and there will no doubt be some sort of long tail, but it expresses the challenge well. I'd imagine the same is true for many other reasonably complex libraries, frameworks, or applications.
The license for libxml2 (like the license for almost any kind of open source software) already states "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT." I don't see how you can put the responsibility even more on the integrator/seller than that. It literally states the devs don't even guarantee it works correctly.
The former are blazingly fast. In real world they can parse instantly. So alternatives do exist for different use cases.
Expanding that to more fields would be interesting, but difficult and expensive across the board. Particularly any sort of requirements like that generally incur significant regulatory and certification overhead.
However, if it was done similar to PCISS as an industry forum it might work better. Especially if certain fields like anything connecting with the electric grid we're required to use certified software.
Really safety-critical stuff like ASIL-D, ISO26262, IEC61508 (and tons of other magic numbers) isn't something you can buy from microsoft. At best, you can sometimes get a reseller to sign something a little more binding, but with tons of restrictions that basically boil down to "use the microsoft stuff for the readout gauges, but the critical control part goes somewhere else".
"Good news is several Google and Apple engineers have volunteered to help with libxml2 and libxslt security issues, despite your effort to sabotage libxml2 users -- especially web browser users -- by disclosing all vulnerabilities immediately rather than allowing them the industry-standard 90 day disclosure deadline used by all other GNOME projects (#913 (closed)). They've posted a couple patches in the libxslt issue tracker already. I assume you're not satisfied with this, and are now trying to push them away. If that's your goal, you'll no doubt succeed pretty quickly."
RedHat often has a detrimental effect on open source, it is filled with bureaucrats and careerists.
Thanks Nick Wellnhofer for going AGPL. You are setting a great example!
Maybe you don't need libxml2 specifically (good luck finding an alternative to parse XML in C and other such languages though), but "I don't like the complex side of XML so let's pretend it doesn't exist" doesn't solve the problem most people pick libxml2 for. It's the de-facto standard because it supports everything you could possibly need.
Why wouldn't other FOSS projects like Gnome Web for example not use GPLv3 licensed software?
This business model is known as selling exceptions to the GPL.
https://www.gnu.org/philosophy/selling-exceptions.html
Use the most radically copyleft and freedom preserving license you can. If the corporations want your software, you present a business solution: pay for special licensing conditions.
It's even blessed by Stallman. I emailed him to confirm. Unlike permissive licenses, only the original copyright holders get to benefit in this way. Others don't have this relicensing permission. The damage is contained.
I hope it works out for him. Watching beggar barons make billions off of free software that's being maintained for free is really hard to watch.
So when these regulations that OP would start to take hold, would we get companies to sponsor random open source dependencies like libxml2? Or would they gather around some stable proprietary ecosystem like Microsoft's and maybe some big innovative solutions built on top of Microsoft?
I personally like the slow and steady tide of understanding the value of GPL family of licenses.
It's doable, just use the right tools and hacks :)
Processing schema-less or broken schema stuff is always hilarious.
Good times.
> <blink>Expat is UNDERSTAFFED and WITHOUT FUNDING.</blink> > The following topics need additional skilled C developers to progress > in a timely manner or at all (loosely ordered by descending priority):
And no kind of safety-oriented anything will run windows or any microsoft software. There is no windows edition of therac-25. The stuff you see in a hospital is normal workstation PCs for non-safety-relevant data entry and display. As soon as it becomes safety-relevant like controlling your heart-lung-machine, auto-dosing your medications, controlling the x-ray beam, you are far away from anything microsoft.
And actually, OSS is used more often in those safety-relevant settings. Why? Not because the OSS maintainers themselves would themselves provide any support, SLA or warranty. But because the nature of OSS provides third parties the possibility to certify, maintain and guarantee for their special 'safety-relevant-libxml2-fork'. Sometimes this is done by the device vendors themselves, sometimes they buy this from others. But it happens, and it is growing in frequency.
https://www.codethink.co.uk/news/trustable-software.html (Linux) https://access.redhat.com/en/compliance/iso-26262-asil-b (Linux) https://www.lynx.com/case-studies/secure-linux-medical-devic... (Linux) https://developer.arm.com/Tools%20and%20Software/Arm%20Compi... (clang/llvm)
There is tons more. Basically any compiler for safety-relevant embedded stuff is either clang or gcc under the hood. Linux is frequently encountered when the real-time requirements aren't too strict. With Linux also comes the usual Linux ecosystem of OSS libs and services. It won't look like your normal desktop OS, but quite a lot in that area is OSS.
Nothing at all from microsoft (except a useless BS certification "you can use Azure Devops as a code repo to store you ASIL-D code...").
Not sure what React has anything to do with this.
XSLT was pretty much never used as a rendering platform but for XML-data processing.
As JSON became the standard of API communication in early 2000s (less powerful, but also much less verbose and easier to manipulate in JS) XSLT became less relevant.
In any case, I'm not sure I agree with you, while JavaScript and CSS are composable out of the box (you can embed scripts into scripts and stylesheets into stylesheet) HTML really lacks a native composable way to build documents.
It's sad that in order to have some:
<document> <myfragment /> <document>
I either have to rely on JavaScript abominations or I'm stuck with outdated XSLT 1.
XML may not be sexy, but it is extremely powerful and fully declarative.