@lanodan which undocumented extensions are you talking about? Sure, the Hurd, GNU libc, GCC, etc. all extend classical Unix/C in interesting ways, and the documentation is not always perfect; but that's just from a lack of manpower, not an act of intentionally locking people in. In fact most GNU software is written in a way that *doesn't* require other GNU system components or extensions, making it very portable. This is the opposite of lock-in.

(1/2)

@lanodan he's made it very clear why he opposes clang/LLVM, and it's not on a technical basis:

"The existence of LLVM is a terrible setback for our community precisely because it is not copylefted and can be used as the basis for nonfree compilers -- so that all contribution to LLVM directly helps proprietary software as much as it helps us."

https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

(2/2)

@bugaevc
GNU: Oh no LLVM is not restrictive enough on it's license!
Also, GNU: uses a license so restrictive on GCC it's unusable in a BSD base system.

Also not on a desktop right now so can't give many links but GCC has all theses extensions on C: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C-Extensions.html
And none of the ones I looked into where documented enough to allow a reimplementation in another compiler.

@lanodan clearly, you're in a "permissive is better than copyleft" camp. That's alright, but other people have different opinions on this (namely, on what's better in the long run); that's not the reason to hate GNU or think they're hypocritical.

(1/3)

@lanodan I think copyleft is better, and (most of) my software is under GPL. That doesn't mean I call out everybody who chooses a permissive license for their projects, but I may chose not to use their software if there's a copyleft-licensed alternative that I find better (or not much worse).

(2/3)

@lanodan This quote from Linus Torvalds sums it up:

"Nobody has the right to whine about another persons choice of license. You have a choice: use it or don't. Complaining about the license to the author isn't part of it."

All those GNU C extensions seem pretty well documented to me. Not that I'm developing a C compiler...

(3/3)

@bugaevc Pretty much this. What's more, even if you try to discuss which license is better the results will be different depending on case to case bases.

@bugaevc In my experience, the C language and good documentation is not something that comes well in the same sentence. Probably because I've seen so many scientific articles in the past years that claimed to have finally understood (through very heavy mathematical models) what the C standard meant by a particular word… and then to add that well-known compilers have different interpretations of this 😕 This is not directly related to these extensions, of course, but the C language itself is pretty ill-defined per se, which doesn't help extensions.

@bugaevc @lanodan hi I have developed a C compiler and those GCC extensions are the underspecified bane of my existence

@bugaevc I think that what @lanodan tried to explain is that by the very same argumentation that you exposed at the beginning (software modularity), LLVM should be considered as a good thing: it enables you to plug any software (being proprietary or not) to the software generating the LLVM code. This is good precisely because it doesn't force the user to pick one particular software in the link, and can even choose not to use a free software for a part of the compilation chain. The magic is that this isn't even a matter of licences: a proprietary software can communicate with a free one.

In other words: interoperability is good, because it makes software chains modular.

@MartinShadok can't argue with that; it's awesome that LLVM is this modular!

The problem that Stallman sees here is that it's not only the user who can do this, it's also an upstream proprietary frontend developer, who would then distribute the resulting non-free compiler and thus deprive users of their freedom.

@bugaevc I'm sorry, it's still difficult for me to get this last argument. Sure, anyone using such a non-free compiler won't have much rights on the resulting program, but I don't get why building a non-free compiler removes writes: I would expect that this only happens if such a compiler is somehow enforced. I sure can imagine how such a compiler can be enforced, but I don't see in what aspect LLVM would be involved in this process. 😕

@MartinShadok LLVM is of course what enables the proprietary compiler writer to do this all while keeping it proprietary, this wouldn't happen with GCC or if LLVM was copylefted.

Case in point, the Objective-C frontend to GCC is only free software because Steve Jobs was obliged by GPL to release it as free software; it would've been proprietary otherwise. Then years later, Apple has sponsored LLVM development under a permissive license; guess you can see the logic.

@bugaevc One could still add a GPL endpoint to GCC from any intermediary language (SSA, for instance) and do the same. LLVM is just an intermediary language that a lot of compilers have to agree on anyway. I really wouldn't blame LLVM for enabling people to make software, be it proprietary.

@Wolf480pl I'm a fan of systemd actually :) it is free software and it is quite modular, contrary to some beliefs. Different distros ship with different sets of systemd components. Wouldn't hurt for it to be even more modular, such as supporting elogind (being able to use logins without systemd the PID 1) upstream.

@bugaevc
Last time I checked, systemd had no open standards (maybe except unit file format). libsystemd's API is the only thing you're supposed to depend on, and the communication methods used for socket activation, startup notification, communication between udev and systemd, communication between systemd and logind, etc. are declared as implementation details and subject to change without notice.

Also, things like systemd-networkd, systemd-resolved, systemd-timesyncd, etc. look to me like a blend of EEE and scope creep.

@bugaevc at the end of the day, systemd does pretty bad on the "freedom not to use it" front, IMO.

@Wolf480pl well, hello there from a Linux-based system that doesn't use systemd :)

@Wolf480pl also, hello from a GNU system that doesn't use systemd (or Linux)

@bugaevc
I didn't say it fails completely, but I suspect it places a lot of burden on distro maintainers who want to support non-systemd inits, comparable to that of using non-gnu libc.

@Wolf480pl distro maintainers should just chose which one init system their distro uses and support that. I know Debian and Gentoo want to support all the different configurations, but that's up to them.

(1/)

@Wolf480pl My point here, as far as "freedom not to use" goes, systemd doesn't require individual services to be written in some systemd-specific way (e.g. as dynamically loaded plugins with some entry points, against systemd-specific API/ABI). No, they're just plain Unix executables launched as any other executable. They don't have to care if they're started (and watcher over) by systemd, another init system, from an interactive shell or whatever.

(2/)

@Wolf480pl (That, and systemd also provides sysvinit's config format compatibility.)

This is why you can run pretty much anything that wasn't explicitly written against systemd (and often predates systemd) with systemd. This is why you can pretty much just swap out init systems and have all the services work the same. I imagine the situation on Windows is much different (though I don't know too much about Windows internals).

(3/4)

@Wolf480pl If a service wants to make use of systemd features such as socket activation, than indeed it needs a small systemd-specific codepath that checks if it's even running "on systemd" and does the appropriate setup. But again, this works without systemd (as a no-op) and you don't need this with systemd (but you won't get some niceties).

(4/4)

@bugaevc
> not a dynamically loaded shared library with systemd-specific entrypoint

> not as bad as Windows

Let's not have such low standards. Just because something isn't mind-boggingly horrible, doesn't mean it's good.

>systemd doesn't require individual services to be written in some systemd-specific way

But encourages them to do so.

That, and

>That, and systemd also provides sysvinit's config format compatibility.

is exactly how embrace-extende-extinguish works.

Everything written without systemd in mind will work with systemd.

Anything written with systemd in mind, linking to libsystemd (and, in case of desktop environments, probably also using some systemd's d-bus APIs) will not work without systemd.

@Wolf480pl no. Services aren't written, and aren't encouraged to be written in systemd-specific ways, they're just plain old Unix executables, and any plain old Unix executable can be run as a systemd service.

(1/2)

@Wolf480pl systemd integration (sd_listen_fds and such) should of course be hidden behind an ifdef & a build time option that controls that ifdef and adds or removes libsystemd to the list of dependencies. And again, even if a service is built against libsystemd, it's a no-op at runtime unless systemd (or another service manager using a compatible API) is in use.

(2/2)

@Wolf480pl what? systemd (the PID 1) spawns your process using Unix's standard fork() + exec(), and passes you journal fd as standard IO, and socket fds using the standard Unix fd passing. Most public APIs of systemd components are even exported as clearly documented D-Bus interfaces. Honestly some projects could learn from systemd :)

@Wolf480pl to quote Lennart,

"Let me point out that the interfaces used here are in no way bound directly to systemd. They are generic enough to be implemented in other systems as well. We deliberately designed them as simple and minimal as possible to make it possible for others to adopt similar schemes."

@bugaevc then why do the docs and blog posts tell you to use sd_notify and sd_listen_fds and barely if at all mentions the interface below?

@Wolf480pl they recommend it because these are the convenient wrappers (in case of sd_notify, so that you don't have to mess with sending credentials over a datagram socket yourself). And the docs do a good job of describing the underlying interface, see e.g. http://0pointer.de/public/systemd-man/sd_notify.html#Notes

@bugaevc
>socket fds using the standard Unix fd passing

But you don't know which fds these are, and how many there are, and you're supposed to use sd_listen_fds and SD_LISTEN_FDS_START from libsystemd to find out.

Of course SD_LISTEN_FDS_START is just 3, and sd_listen_fds just reads an environment variable LISTEN_FDS. But IIRC systemd devs consider this an implementation detail and reserve the right to change it any time.

And then, unless your service is of Type=forking (which is "deprecated"), you're supposed to tell systemd when you're done starting up by means of sd_notify.

Which just writes something to a socked specified by NOTIFY_SOCKET env var, but again, that's implementation detail / subject to change.

Last time I checked, all these env vars were not standardized and subject to change. But that was long time ago. Have they since standardized it, and committed to not breaking it? Because that'd be really nice.

@Wolf480pl exactly, it's just 3 and those env variables. I didn't get the impression that these are the internal implementation details / subject to change without notice. That same blog post actually encourages you to reimplement them yourself if you don't want to use sd_* utilities:

(1/2)

@Wolf480pl

"Eventually we plan to turn this into a proper shared library, however using the drop-in files allows you to compile your project in a way that is compatible with socket activation even without any compile time dependencies on systemd. sd-daemon.c is liberally licensed, should compile fine on the most exotic Unixes and the algorithms are trivial enough to be reimplemented with very little code if the license should nonetheless be a problem for your project."

(2/2)

@bugaevc
I've only seen one daemon do that, everyone else just falls for the libsystemd bait.

@bugaevc
>Most public APIs of systemd components are even exported as clearly documented D-Bus interfaces

Ok, could you please point me to something docunenting how udev interacts with systemd? I've always wondered how this works and how hard it'd be to reimplement the whole multiseat thing without systemd.