What an achievement! Curl is a blessing.<p>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.
This is something a bunch of devs growing closer to us ops-guys have learned as well: Dependants are drag. Infrastructure and central systems stop being agile and nimble if enough stuff depends on it. Trivial changes become really hard.<p>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.<p>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.<p>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.
There's a bunch of things on there that haven't had a release in over 25 years. Are they still doing current builds on SCO, Xenix, OS/2 and NextStep?<p>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.<p>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?
> Countless users and companies insist on sticking to ancient, niche or legacy platforms and there is nothing we can do about that.<p>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."<p>That is inexpensive.<p>Some people, myself included, develop software where the fitness for purpose is guaranteed and warranties are explicit and absolute.<p>That is very expensive. And slow.<p>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.<p>At least that's what I tell myself when staring at Ada on INTEGRITY on PowerPC.
One of the reasons for this popularity is the permissive license. I would guess that the license is MIT, but seems to be a bit different [1]. Does anybody know (in simple words) what are the main differences with MIT? The copyright webpage does not elaborate.<p>[1] <a href="https://curl.se/docs/copyright.html" rel="nofollow noreferrer">https://curl.se/docs/copyright.html</a>
In my personal experience, when you write code which caters to many legacy systems, your code will likely end up...<p>* adhering closely to well-regarded coding practices regarding naming, typing, modularity etc.<p>* being more standards-compliant (except in clearly-identified locations)<p>* having more robust abstractions<p>* exhibiting less bugs (in particularly on modern platforms)<p>* having a more robust build system<p>* being automatically compatible with future platforms, or at the very least exceedingly easy to make compatible<p>which is a good thing.<p>(But this may not be true if you cater to just a <i>few</i> legacy systems, because then you might make do with a bit of idiosyncratic combination of fudges and hacks.)
Strange that they list FreeDOS, DR-DOS and MS-DOS as separate OSes even though they are very similar. They are effectively ABI-compatible, unlike the different Unix flavors.
Related reading: On how curl was born and its history (1)<p>(1) <a href="https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-curl/" rel="nofollow noreferrer">https://daniel.haxx.se/blog/2023/03/20/twenty-five-years-of-...</a>
101 to be exact. I run it on ENIAC but due to program size it takes me about 11 years to re-enter the machine code every time Daniel does an update. I’m currently on version 1.01 hoping to get to 1.01A around 2042.
The PR mentioned: <a href="https://github.com/curl/curl/pull/11610">https://github.com/curl/curl/pull/11610</a>
It's an excellent response to the rather dismissive attitude that a subset of developers have about legacy anything. Too many times they don't care about portability and/or correctness, and are happy to dismiss whatever they don't use as irrelevant.<p>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.