Re: sysvinit->systemd transition details
On Sunday, August 24, 2014 9:40:01 AM UTC+2, Joe wrote:
> On Sat, 23 Aug 2014 14:24:59 -0700 (PDT)
>
> Alexandre Ferrieux wrote:
>
> > systemd allows to continue using sysvinit scripts, service per
> > service. It just doesn't preserve the integrity at the system level.
>
> On the whole, it does.
Yes, that's the point. Has backwards compatibility just been dismissed as an old-fashioned concept, or is it just me ?
Imagine: glibc, between x.y.z and x.y.(z+1), deciding to *remove* select() and poll() since there's epoll(). The analogy is deeper than it seems:
- everybody admits that epoll() is superior to select/poll beyond a few tens of monitored fds.
- everybody will happily use epoll() in new programs (except when the extra fd is an issue)
- still, nobody will tolerate that "evolution" as it instantly disables a huge population of existing software.
To pursue the analogy, the "smooth transition" packages I've seen here and there for sysvinit->systemd, e.g. in Debian, look like an LD_PRELOAD hack reinstating select() for those who really want it. The problem is that none of this is done by default, and of course that does not apply everywhere (think of setuid binaries).
Again, I'm not here to blame systemd in itself. Despite being from the "old guard" and well in line with many arguments of the sysvinit defenders, I know that innovation needs some space. I also acknowledge the fact that supporting *two* init systems simultaneously is an hefty burden, so I understand the move that forcibly enables the new system at one point.
What I do regret though, is the apparent lack of care for *perfect* backwards compatibility, in the sense of "existing systems still work after upgrade". There is a *huge* difference between 99% and 100% here.
-Alex
Reply to: