Curl on 100 Operating Systems
daniel.haxx.se
daniel.haxx.se
It's interesting to me that he highlights 32 bit time_t as one important point of compatibility. Makes perfect sense if your goal is to keep your program working on many operating systems. OTOH 2038 is only 14 years away now, or well closer to today than when curl was launched. I wonder when no one will think working with 32 bit times is worth the trouble? My guess is about 3 months after the Y2K38 date, maybe even longer.
Like, if you have your service with a backend and a frontend and want to toss your API between those out and deal with it, who cares? Do it.
If you want to throw out some weird edge case in a base template because "It's ugly", you need to look at 20 legacy services, and 20 somewhat modernized services people don't want to touch, and some 50 more services if they use that. That's the work necessary to understand how much work that change would mean. At that point, we're not talking about executing the change, or reverse engineering arcane mysteries.
I'm not going to say it's glorious work, but it makes a roadie or an admin proud if you can keep the "wonderful star" afloat and change everything below it without anyone noticing.
I've run these, I know some curl exists on them, but in my experience that curl is always like at least 15 years old.
If you say you don't want to break some support matrix and the last build on a bunch of that matrix was well over a decade ago, how do you know it's not broken?
I don’t think you can build for Xenix, the most modern GCC that can target it is 2.7 and that’s already ancient, not to mention the network code. It’s probably “at some point it was running on those systems”.
It's a pretty cool machine but I assure you it's extremely useless these days.
The TIFF format it uses, for instance, no longer supported by imagemagick. It doesn't support modern DNS resolution and if you want NFS you'll need a legacy v3 server.
The Ethernet is a blistering 10baseT and the SCSI drive doesn't crack 300MB.
The ssh server exists but modern clients no longer support it's archaic protocol.
You've got perl and zsh, that's nice. There's also some antique Apache for it so you can use WebDAV and you can get it to play mp3s in real time if they're mono channel and under 32khz (yes, that's what I meant)
That doesn’t mean you cannot waste some time having fun with it: I’ve ported some software to Xenix (including Doom, sort-of-working: https://github.com/gattilorenz/Xenix-doom), and while completely useless it’s intellectually stimulating.
But geez, 25$… that’s a nice thrift find!
They're not waiting on their, say, Blackberry 10 build to pass the test suite before tagging a release.
Most people, even proprietary closed source developers, write software where one of the first sentences in its license is something like "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
That is inexpensive.
Some people, myself included, develop software where the fitness for purpose is guaranteed and warranties are explicit and absolute.
That is very expensive. And slow.
It makes sense to stick with ancient and niche platforms that have been pored over for 30-40 years by very slow and deliberate developers when someone may die, the environment may be ruined, or millions of dollars in damage may occur if something breaks.
At least that's what I tell myself when staring at Ada on INTEGRITY on PowerPC.
Contradicted yourself in one sentence!
If a single person dying is going to cost million dollars of damage, it makes sense to not use software or platforms where the developer pool is a about as big as the number of french Jugglers with Wilsons Disease
"Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder."
[1] https://www.gnu.org/licenses/license-list.html#X11License
There are many MIT-derrived licenses, some of which have identifiers prefixed with MIT- and others like X11 and curl have independent identifiers: https://spdx.org/licenses/
That’s not to say they necessarily aren’t; I’d be interested to see if any rationale behind that choice has been published anywhere. But if the choice was made more or less arbitrarily, or based on what seemed more popular to the authors, I’d be inclined not to treat SPDX as an authority on the matter.
See WWDC 2018 session,
"Introducing Network.framework, A modern alternative to sockets"
But you have to draw the line somewhere and the way curl didn't isn't unreasonable IMO.
What is or isn't a separate "operating system" is always a bit fuzzy and depends on which layer you're looking at. Android is "just Linux" on some levels, but also clearly isn't on others. But also: Debian really is quite different from, say, Chimera Linux, or Alpine. But it's also very similar.
It also lists illumos and OmniOS for example, and it could be argued that it's really just one system. Same with Linux and ucLinux, and probably a few others.
* adhering closely to well-regarded coding practices regarding naming, typing, modularity etc.
* being more standards-compliant (except in clearly-identified locations)
* having more robust abstractions
* exhibiting less bugs (in particularly on modern platforms)
* having a more robust build system
* being automatically compatible with future platforms, or at the very least exceedingly easy to make compatible
which is a good thing.
(But this may not be true if you cater to just a few legacy systems, because then you might make do with a bit of idiosyncratic combination of fudges and hacks.)
That would be like saying NextSTEP and OS X were the same as well.
In the spirit of discussion, this article (2021) makes the argument that it would correct existing bugs in curl:
> There are 95 bugs [in curl]. By my count Rust would have prevented 53 of these [in 2021].
https://blog.timhutt.co.uk/curl-vulnerabilities-rust/
The curl author (Stenberg) has said:
> I don't believe in rewrites, no matter which language. I believe in replacing code and fixing components gradually over time. That could mean that we have a curl written mostly in rust in 10 years. Or in 20 years. Or not.
(1) https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...
The curl tool comes installed in addition to the dreaded curl alias that plagues Powershell users since it is an alias that runs the invoke-webrequest command and therefore isn't acting much like curl at all.
A work-around is to invoke curl as "curl.exe" to prevent powershell from treating it as an alias
That said, as far as I'm aware Java is the only one that brags about how many devices it's on.
What was funny is that the go binary was written as a better replacement for a Python tool (fortunately, most deployments were on civilian OSes.)
I assume it's no longer real GPL Linux after all the lawsuits, right? ...right?
metalink crypto z pthread c nghttp2 idn2 ssh psl ssl gssapi_krb5 ldap_r-2 lber-2 expat dl unistring rt krb5 k5crypto com_err krb5support resolv sasl2 keyutils selinux pcre
so,
* Cryptography
* Threading
* Compression
* Network security
* Regular expressions
* Various network protocol
many of these are OS-specific and none of these is provided by the compiler.
They did it when all the world was an i386 (a take on the "all the world's a VAX), and now they're treating even 32 bit x86 the way they used to treat all non-x86. It's not a good look.
Given that, I wouldn't count ChromeOS as Linux, because if we do, by that logic, we'd have to count Windows as Linux due to WSL.
But you can ( with some effort ) make it run in ChromeOS.
I often compile things inside Alpine containers statically and run them on my local machine, and plenty of times I've downloaded deb packages, extracted them on a raspberry pi running Alpine and it's ran fine (assuming glibc compatibility is set up.
"Different enough", I guess is the mark.
E.g. "Ubuntu is a reskin of Debian with spyware"
Linux in that list is flavour, but that is also the same with BSD. BSD is the flavour and Free, Net, Open all come from BSD 4.3. And if we really want to push it, it also includes MacOS 10.
I was also surprised to see Sailfish OS, Meego and Maemo listed separate from Linux, but my guess would be that the list comes from the build system of curl. Everything that is its own build target is listed there.
If you so desired, you can enable Linux support, which will run a Linux container just like WSL on Windows, for the Crostini environment.
If that counts, Windows, IBM mainframe/micros, and Unisys mainframe/micros are also Linux.