C extensions, portability, and alternative compilers

Then there's portability between compilers, which, as the article notes, glibc is also completely hostile to (except for anointed compilers) for no good reason whatsoever.

2: You could easily compile Samba yourself for FreeBSD in the past, last time I tried a new version it broke in what I remember being due to linux-isms (yes there is ports, but being reliant on older versions if ports maintainers can't keep up isn't a good thing).

3: The only "fairly basic" stuff that's hugely different is mostly the absence/reliance on shell-scripts (when building), but that has little to do with the actual code function (Personally I often used Node scripts in those scenarios, Python scripts would probably be an improvement since there's no reason it couldn't be everywhere).

I used to use Tremor to decode Ogg audio (no UI needs, just binary data in, arrays of primitive values in audio buffers out), early versions were easy to compile under Windows but building later versions were buried in shell scripts generating headers,etc for no real good reason (maybe to help port when working on a Linux workstation to other embedded devices but made the code less easily compilable by default), the core functionality only really needed a C compiler as early versions showed.

I can agree that something with advanced UI's like Blender (that relies on GL/3d rendering for UI) might not be easily portable, but when algortihm libraries often requires heavy reworking it's not a good thing (Here I think Github has helped since people has had an easier time to contribute, it's a sad thing that people are moving away due to the AI-crap).

In the end, it's not about _actual_ differences but more of a superiority complex of Linux users that is the main roadblock.

I don't expect anyone writing GUI tools or more high-perf servers to spend their time porting to other platforms (trying to compile GTK on Windows wasn't for the faint of heart).

Which is at least better than with MSVC, where they did everything differently, and only half of it.

I'm not sure why you're surprised, the parent of you comment clearly stated

"on FreeBSD you often run into systemd dependencies or other non-posix behaviors"

which means, software written for Linux often uses "Linux-only features" such as systemd and other non-posix dependencies that are foreign to the BSDs and traditional UNIX. Thus, it shouldn't be surprising that Linux software is hard to port to the BSDs.

Linux used to be a pretty good UNIX, I'm not sure what it is now.

I don't like systemd but it is a lesser evil.

Systemd bothers people because it's not "the Unix way". In other words, it's not some painful lowest common denominator POSIX nonsense. That's a feature, not a bug. POSIX is garbage and restricting oneself to it is pure masochism.

Every unixlike deviates from POSIX and for good reason. That includes the BSDs, but somehow I don't see people complaining endlessly about all the nifty exclusive features they keep accumulating for themselves. Why is it that only Linux gets singled out?

In my experience this was a problem over 25 years ago when I developed for Solaris and other non-Linux operating systems.

This goes back to the days I was browsing freshmeat and saw some interesting command line tool or otherwise non-UI tool from some hopeful developer for something useful. Node had significant traction but didn't really blow up until it became really cross-platform.

And perhaps is less of an issue these days since so many people use Mac's as their primary, so less Linux-isms survive once in context with osX.

> Not a problem. POSIX is irrelevant, systemd is great and we should all be using Linux to its fullest extent. Linux has great features and there is absolutely no reason not to use them all. Nobody complains about the fact BSDs have cool things like kqueue and unveil.

From following it over the year it was not entirely welcomed even in the linux community (and some of the security issues made one shudder). Mostly it's the monolithic nature that's makes it a questionable, is it Gnu/Linux these days or Systemd/Linux ?

kqueue is just an api, just like epoll, io_uring or even iocp on windows. And yes, it's a special case for high-perf servers where posix becomes less relevant (and while I can appreciate some lower-perf fallback to be able to develop/port to another platform like a console I do see that some programs are inherently platform bound).

I think one thing lost in my original comment was that I was often encountering things like this with "simple" CLI tools or lower level format libraries, and honestly projects like that also had a tendency to break over time without updates as they often relied on specific versions of libraries the maintainers had installed via Linux package managers, in the same fashion as npm has caused churn in the JS community. (npm at least has version pinning so old cli tools can often be run as long as node hasn't deprecated api's).

But I think the power dynamics is crucial. In the Lisp ecosystem the users have great power, (and there are dozens of implementations,) so it's not like one or two implementation decides what everyone is gonna use and everyone just lives with it.

What I want to explore is cheap and fast optimizations, without SSA and data flow tracking. I have huge sources files compiled to 25MB .o files, which should need to be compiled in less than 5m. So far only tcc can do that. But I have now consteval and deadcode elimination for free. Which tcc cannot do.