C extensions, portability, and alternative compilers • Hacker News Board

Re: C extensions, portability, and alternative compilers

#81

Post by matheusmoreira » Tue, May 26, 2026, 1:27 PM UTC

account42 wrote: post #66

matheusmoreira wrote: post #53

Earlier quoted context omitted.

Nope. Systemd is pretty great. It's pretty well designed, fully featured, very easy to use and quite nice program against. And it's GPL licensed free software. 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…

The definition of a strawman.

Not at all.

The point was that using systemd is somehow "mandated". It's not, people chose systemd because it's actually better and made life easier compared to some POSIX nonsense.

The point was that this non-existent "mandate" caused a "bifurcation" from "standards-based" software to Linux-specific. If anything is being "mandated" here, it's the POSIX compliance. Nobody is obligated to follow this like it's some sort of religion. The standard is garbage and should be forgotten.

The point was that systemd was "the bane" of FLOSS. Systemd is itself FLOSS, it's literally GPL'd. And pretty good FLOSS at that. It's just not "standards compliant" which makes it heretical or something. Total nonsense.

There are no "strawmen" here. Just downvote silently if you disagree and don't want to argue.

Re: C extensions, portability, and alternative compilers

#82

Post by matheusmoreira » Tue, May 26, 2026, 1:34 PM UTC

avadodin wrote: post #62

matheusmoreira wrote: post #53

Earlier quoted context omitted.

Nope. Systemd is pretty great. It's pretty well designed, fully featured, very easy to use and quite nice program against. And it's GPL licensed free software. 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…

Your binary spaghetti monstrosity, our carefully designed literate API. Wait.

Systemd is farther into the "carefully designed" territory than POSIX will ever be. Never forget who gave us signals and locales.

Re: C extensions, portability, and alternative compilers

#83

Post by matheusmoreira » Tue, May 26, 2026, 1:58 PM UTC

whizzter wrote: post #73

matheusmoreira wrote: post #31

Earlier quoted context omitted.

Superiority complex? How many times have we been told that we're entitled freeloaders for expecting Linux compatibility work from others? Insulted by people who use dominant platforms that get all the commercial support while we get literally nothing? Reduced to reverse engineering stuff with no documentation and zero help? Pretty wild to watch this unfold. Now that Linux is finally coming out ahead, as it should , b…

This isn't a new thing, like I mentioned in another comment it goes back to freshmeat.net days ("oh, cool a tool to manipulate fileformat-x", "oh ok too full of gcc-isms, linux-only headers to run on either windows or even bsd"). I worked in gamedev, consoles, etc. Linux support was often discussed but the whole mess of different libraries on various distros vs static library linkage legality, evolving audio api's,et…

> oh ok too full of gcc-isms, linux-only headers to run on either windows or even bsd

You have the source code and it's literally free software. What else do you need?

It's honestly pretty incredible to hear complaints like "it didn't compile on my preferred platform unchanged".

> the whole mess of different libraries on various distros

All the various Berkeley Software Distributions out there don't have different systems and libraries of their own?

This is a user space problem anyway. Linux kernel is actually better here. Linux actually lets you bypass system libraries and talk to the kernel directly. You can write Linux applications in freestanding C and they will work. BSDs will eventually break ABI and your program if you do that.

> static library linkage legality

Nothing illegal about it. Just gotta follow the terms of the GPL. Whether you're willing to do it is a completely separate matter.

> Valve just defaulting on Wine and Win32 binaries for steamdecks could be discussed at length

Don't think there's any discussion to be had here. It's just the pragmatic choice that buys us access to vast amounts of existing software that will never be ported. Linux kernel is even gaining NT functionality now just to support this. Nothing wrong with it.

You can totally get Linux versions of games in the Steam Deck, it's just that they're often second class ports, outdated and generally forgotten by all including the developers. There is no reason whatsoever to sit around waiting for things that will never come.

Re: C extensions, portability, and alternative compilers

#84

Post by cestith » Tue, May 26, 2026, 2:01 PM UTC

einpoklum wrote: post #46

jeltz wrote: post #41

Earlier quoted context omitted.

No, systemd is not the bane of Linux. What existed before it was much worse. Upstart was a totally broken mess and almost all sysv init scripts contained several bugs. I don't like systemd but it is a lesser evil.

systemd is not an init system; it _contains_ an init system. It is a huge swatch of the whole userspace of a Linux system up to shell or GUI sessions - and having an init system was just an excuse; and in fact, the systemd point brought up in the linked article is unrelated to init systems. There are quite a few init systems: The venerable sysvinit, runit, s6, openrc and others. You don't like upstart? Ok, choose ano…

The systemd init system is quite the Trojan horse, though. I prefer it greatly to SystemV init. Most of the rest of systemd varies from unremarkable to problematic in my opinion.

One bright spot is systemd-networkd allows one to change quite a few things about interfaces in the way server automation platforms expect to work without doing a network restart. The workaround otherwise on, say, CentOS was always to write the new config file used by future restarts, also run CLI commands to update things in memory, and be sure to tell the service not to trigger a restart on the config file(s) changing. Otherwise if you’re doing something like streaming UDP video your own automation can become a reliability issue.

Re: C extensions, portability, and alternative compilers

#85

Post by kjs3 » Tue, May 26, 2026, 2:04 PM UTC

pif wrote: post #78

kjs3 wrote: post #51

Earlier quoted context omitted.

Linux used to be a pretty good UNIX, I'm not sure what it is now. Linux has become Linux, it's own thing that as often as not says "yeah, that old Unix stuff is fine for you boomers and other fossils...we're going to be over here doing our own thing". Which is probably fine, I guess, because all the old Unix versions did the same thing to some extent and the computing world had changed over a dozen times since Unix s…

Also, people confuse "good" with "ought to live forever". It's time to leave BSD and LISP in the history books.

How dare anyone spend time on things you don't approve of. /s

Re: C extensions, portability, and alternative compilers

#86

Post by MereInterest » Tue, May 26, 2026, 2:09 PM UTC

fc417fc802 wrote: post #43

ventana wrote: post #24

Earlier quoted context omitted.

I have no knowledge of this specific "why", but my general experience shows that feature flags, while almost universally better than checks for the specific software version in hope that it has proper support for a feature, appear only as a replacement to platform / software detection, after a few years of struggle. It's probably just natural for software developers (myself included), whenever only FooZoid v5 support…

The ideal isn't feature flags (ie FOO_SUPPORTED) but rather feature tests (ie COMPILES( foo( int ) ) ). Yet another reason why languages with proper metaprogramming capabilities are better.

The problem with feature tests is that you then rely on the test code being correct. A typo in the feature test can erroneously be interpreted as lack of that feature.

One step of the 2024 supply-chain attack on xz utils was to disable a security feature by introducing a feature test with an intentional typo. Even knowing that this commit[0] contains an intentional typo, I had to re-read the diff a few times to actually find it.

[0] https://git.tukaani.org/?p=xz.git;a=commitdiff;h=a100f9111c8...

Re: C extensions, portability, and alternative compilers

#87

Post by pif » Tue, May 26, 2026, 2:09 PM UTC

kjs3 wrote: post #85

pif wrote: post #78

Earlier quoted context omitted.

Also, people confuse "good" with "ought to live forever". It's time to leave BSD and LISP in the history books.

How dare anyone spend time on things you don't approve of. /s

Spending time on your hobby is wondwerful. Expecting the world to consider your hobby important is arrogant.

Re: C extensions, portability, and alternative compilers

#88

Post by cestith » Tue, May 26, 2026, 2:14 PM UTC

eska wrote: post #58

kscarlet wrote: post #48

I think the Common Lisp ecosystem sets a good example of how a dozen of implementations move ahead together. Implementations experiment with extensions, the really useful ones get implemented multiple times, and some portability library emerges as de-facto standard if it's good enough. You can watch the result in https://portability.cl/ , the language is evolving like never before even if the standard committee has d…

Isn’t this only possible in lisp due to the strong foundations of meta programming allowing the implementation of language features as user libraries?

I don’t know that it’s impossible without that. It’s certainly easier with it.

Re: C extensions, portability, and alternative compilers

#89

Post by matheusmoreira » Tue, May 26, 2026, 2:16 PM UTC

whizzter wrote: post #67

matheusmoreira wrote: post #29

Earlier quoted context omitted.

> One of my pet-peeves with C projects is that it's so often more or less "works on my machine" when written by Linux users (as a Windows and FreeBSD user it often hits you on both those platforms). Windows users singling out Linux users for not catering to their platform. How the times change... > you often run into systemd dependencies or other non-posix behaviors Not a problem. POSIX is irrelevant, systemd is grea…

> Windows users singling out Linux users for not catering to their platform. How the times change... 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 ma…

> 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.

Yeah, and then we get "osX-isms" instead. Before node, there was rubygems which contained lots of macOS specific software.

Nothing particularly wrong with that. People should use their preferred platforms to the fullest. Why make it a point to single us out for "linux-isms" though? Makes absolutely no sense. BSD-isms, Win32-isms, macOS-isms are just as abundant.

> 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).

It's definitely welcomed now. There's plenty of legitimate criticism against systemd but lack of standards compliance, incompatibility with other platforms or lack of devotion to some nebulous "unix way" religion aren't among them. The whole point of systemd is to use Linux kernel features like cgroups to the fullest extent, and it does so to great effect.

> Mostly it's the monolithic nature that's makes it a questionable, is it Gnu/Linux these days or Systemd/Linux ?

It's just "Linux".

GNU is not in any way special either. GNU, systemd, they're all just random user space stuff you can put on top of Linux. You can boot Linux directly into your software if you'd like.

It's strictly less monolithic than BSDs which ship a kernel and a whole bunch of system components and user space libraries you can never ever bypass because they explicitly don't guarantee ABI stability like Linux does. To say nothing of macOS which becomes more of a walled garden every day that passes.

Re: C extensions, portability, and alternative compilers

#90

Post by matheusmoreira » Tue, May 26, 2026, 2:47 PM UTC

bigbadfeline wrote: post #42

rwmj wrote: post #22

Earlier quoted context omitted.

MSVC support for C is fairly terrible. For the projects we write that are portable to Windows we insist you use GCC or Clang on Windows. No one has time to deal with the lack of even standard C1x/C2x features (never mind useful extensions like attribute cleanup). Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for…

> Surprised about FreeBSD. My experience is that porting Linux software is usually pretty easy as long as it's not using some Linux-only feature (io_uring for instance). 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…

Linux is just Linux. There is no need for it to be part of some larger category of operating systems.

And BSDs are just as happy to accumulate nifty features like kqueue, unveil and whatever else it is that they have. These features are all just as foreign to Linux as io_uring is to them, and just as non-POSIX compliant.

Yet somehow I just don't see people complaining about them endlessly the way people complain about "linux-isms". When I see such features I am very impressed because I think they're amazing innovations, and my only reaction is to wonder when Linux will gain the same features so it can be just as great as they are.