On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote: > On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote:
[about the Linux kernel developers] >> They do, however, maintain their external interfaces - rigidly so, >> sometimes to what others might call the point of insanity. An >> intentionally user-visible API from the Linux kernel will >> essentially never change, and if an exception to that is ever made, >> it will be announced *years* in advance. That is one reason why >> they try to be *VERY* careful to get the user-facing interface >> "right", at least on some basic level, before ever pulling it into >> a released kernel. >> >> The kernel interfaces which kernel modules need to use are >> kernel-internal interfaces. >> >> The systemd interfaces described on the page you link to appear to >> be systemd-external interfaces. > > I know the difference, and I know this is just some tradeoff, there > is advantages and disadvantages on doing that, and if I was cynical, > I would postulate that companies like redhat do push for that model > of internal/external interfaces in the kernel, because this give a > reason to take entreprise distributions. ( ie, SLES, RHEL do have a > stable promise API for each release like Windows do, because > customers do pay also for that ) > > My point is not that kernel or systemd devs are right or wrong. But > the point is that people who complain that systemd do not have a > internal interface yet forget that kernel do not have one since the > start and will not have in a near future. Er... were people complaining that systemd does not have a stable internal interface? I thought (given the context of that linked-to page) that the complaint was that systemd does not have a stable *external* interface. With possible room for dispute about what constitutes an "interface", what qualifies as "stable", and maybe even what counts as "internal" vs. "external"... but I didn't see anything that I recognized as being a complaint about systemd's internal interfaces. No one is even trying to implement something outside of the systemd project that talks to systemd's internal interfaces directly, AFAIK - unless systemd-shim does, but I didn't think systemd-shim talked to systemd itself at all, just to other tools provided by the systemd project. And if the interfaces which those tools use to talk to systemd-the-init-system are considered "internal" interfaces, which is a position for which an argument could be made, then that would simply bring up the argument that since those are separate tools the interfaces between them should be considered external to each tool. Whether or not that's a reasonable argument, and the extent to which it might be possible to treat those interfaces that way, could be a discussion worth having - but having it would require *getting* to that point first. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
