no, they are not. And separate git repositories do not guarantee modularity either (as an example, see the historic problems that have existed with ALSA user space vs kernel code)
There is a mindset required.
1. you have to accept that there will be other users of your interfaces
2. you have to accept that there will be people who don't use your favorite components
3. you have to define your interfaces
4. you have to maintain backwards compatibility for your interfaces (no dropping features just because it's convenient for you and you don't need them any longer)
> Projects don't own turf just because they provide the current implementation. Contributing to existing projects is certainly a good method when possible, but I don't think you'd get very far asking MongoDB developers why they didn't try to get their changes progressively into PostgreSQL or MariaDB.
did they even _try_ to work with existing projects? in the case of journal/syslog we know that they didn't, from the simple fact that a lot of the things that they claimed syslog couldn't do (and therefor justified the journal), were in fact easily done with syslog, and some of the other things were added within days of the journal announcement.
It's not like the journal added capabilities that are so shocking and new that they can't possibly work in standard syslog daemons.
> My same thoughts here. anacron didn't integrate their features into cron...Nor did git seek to build on Subversion....Why does systemd have a unique responsibility to improve other implementations rather than providing capable replacements?
git doesn't force you to not run subversion, being a system tool means that systemd needs to be more accomodating than user tools where multiple ones can be used.
in the case of anacron, you have a single purpose tool that replaced another single purpose tool, and did so in a way that supported existing configs. If systemd was just an init that fully supported everything that was in sysV init (it supports some, but not all, inittab for example) and was presented as "in this version we switch from init to systemd and you don't see any changes if you aren't using new features", and then added new ways of streamlining the things that init has been responsible for, you would not have nearly the pushback that you have now.
> That sounds like a reasonable capability to me, but it doesn't have any bearing on whether systemd should implement other features like a cron equivalent
in the case of CRON, if you were to take away the justification of needing to know about all the processes by having a 'startup' program, what's the justification for replacing a established, well known tool with a new implementation inside systemd?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds