Ariadne Conill, an Alpine Linux developer, writes about libc differences, service managers, portability, and open source maintenance.
HN links it for technical posts on musl, Alpine, and portability; one commenter says she treats musl and Alpine as right and others as wrong.
I am using that expression to separate them from the broader Open Source movement. I do think there is a major difference between general open-source and GNU/FSF "free as in freedom" ideology.
I see the broader open source movement as "hey I made this thing to get stuff done, oh btw it's open source under a permissive license so feel free to take it/improve it".
GNU/FSF is more like "here's a list of reasons why the way you do your computing is wrong, the right way is to go back to the dark ages of computing, oh and we have some half-baked software to help with that - and don't you dare use that other open-source thing over there, it's not free enough".
> Name some examples
The hundreds of different Linux distributions, none of which can match the stability, consistency and user-experience of proprietary OSes even from a decade ago? Imagine the collective effort that has been wasted reinventing the wheel and bikeshedding.
The PinePhone, which despite there being a permissively-licensed, battle-tested mobile userspace (Android), would rather try to adapt a desktop-focused userspace to it (and the effort is obviously spread across multiple distros, because why wouldn't it?), and as a result you have a device for sale today that's less usable than a PocketPC from 2003.
The whole "Respects Your Freedom" list from the FSF (https://ryf.fsf.org/index.php/), which looks like a low-budget computer parts catalog from a decade ago, or their absurd position against CPU microcode…
> “Nginx is an incredible software and platform, but I was wondering if it wouldn't be time to just bite the bullet and create a more modern solution based on Rust.”
I actually don't understand why I am seeing arguments like this all the time. Rewrite takes time and effort. It may be OK for new projects. But for a mature project that has a quarter million lines of code and load-tested for cross-platform compatibility and security, it is way more than "just biting the bullet". (Not to mention that memory safety in Rust is ... still improvable. [1])
Rust is not a panacea. [2] When a corporate tries to seize control of a open source project, some one (or some entity?) has to do something, and rewriting in Rust by no means reclaims the freedom and openness of the project.
[1] https://news.ycombinator.com/item?id=39440808
[2] https://ariadne.space/2023/12/07/most-breaches-actually-begin-in-corp/
The author thinks that musl, Alpine, and Linux are right and everything else is wrong.
* https://ariadne.space/2022/03/27/the-tragedy-of-gethostbyname/ - musl's DNS resolver doesn't support TCP lookups, but it's your fault for expecting the standard DNS lookup functions to work. You should change your program to use a third-party library for DNS lookups. This post is a couple years old; musl now supports TCP lookups.
* https://ariadne.space/2021/06/25/understanding-thread-stack-sizes-and-how-alpine-is-different/ - Alpine has a stack size that's substantially smaller (128k) than other widely used OSes (512k+). Your program may work everywhere else, but you're wrong to assume a reasonable stack size. Here's how to jump through a hoop and make it work on Alpine.
> The initial/main thread stack size is dynamic
That seems doubtful, AFAIK all OS have a static allocation for the main thread, just one that is commonly (though not necessarily) much larger than what they give off-threads, as https://ariadne.space/2021/06/25/understanding-thread-stack-sizes-and-how-alpine-is-different/ quotes Windows gives 1MB to all threads, while macOS or OpenBSD 4.6+ give 8MB to the main thread and 512k to off-threads.
The former would not merit consideration if it was automatically increased.
> it grows until it runs into another allocation
Which it won't because vmem.
> and these days there are guard pages and such
That just makes the access segfault if the stack allocation is not large enough to straight jump over the guard page.
Cat is an interesting example because it's not as trivial as it seems, especially when it comes to performance and resilience:
https://endler.dev/2018/fastcat/
https://ariadne.space/2022/07/17/how-efficient-can-cat1-be/
I think this is one of these "not built here" discussions. It's very easy to underestimate the number of edge-cases to support especially in the case of network transfer. You start implementing your own, then you've got to handle non standard certificates, 300 redirects, temporary failures, backoff strategies, optimizing chunk size, handling proxy calls, etc. Using a standard library makes sense.
I think you mean glibc 2.34: https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
You opt-in by building with -D_TIME_BITS=64: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fTIME_005fBITS
An approach not without its problems: https://ariadne.space/2021/12/29/glibc-is-still-not-y2038-compliant-by-default/ - but then again software that relies on time_t being 32 bits has been broken on 64-bit architectures for a very long time already, surely?
I suppose I could have written that "GNU/Linux values ABI stability" in my comment, instead of plain "Linux"... ;)