|
|
|
|
|
|
by matheusmoreira
27 days ago
|
|
|
> 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 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. |
|
|
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).