| |||||||||||||
you do NOT need to write all your programs together to make them work together.you do NOT need to write all your programs together to make them work together.Posted Jan 28, 2013 22:14 UTC (Mon) by dlang (✭ supporter ✭, #313)In reply to: you do NOT need to write all your programs together to make them work together. by raven667 Parent article: Poettering: The Biggest Myths
> I'm not sure what more could possibly be done.
don't merge udev, go ahead and enhance udev to provide whatever service you are wanting to use, but keep udev a separate project so that people who don't want systemd continue to be first-class users
don't reinvent syslog, if there is something that you need, contact the syslog maintainers and ask for the feature if you want it. Or if they don't have time to implement the feature, write it and contribute it (all of the syslog daemons accept outside contributions, and rsyslog, the default is very accepting, and supports sponsoring new features if you can't just convince them it's a good idea)
etc
for the most part it's not that systemd needed to do more, it's that they should have done less, writing utilities and working with existing tools rather than reinventing them or re-implementing part of the existing functionality inside systemd.
The latest thing with CRON is another example, the argument seems to be that they need to take over cron because it's another way to start a process, and they need to know about all process starts to 'manage' them.
How about instead defining a 'startup' program that starts jobs in their own cgroup, notifying interested programs through some mechanism (init being one of them, but probably not the only one) and then get CRON modified to use this program to fire off the apps.
This program could then be used by other things, desktop environments could use it to start apps, user scripts could use it to launch apps. Things besides init could watch for processes to start (such as high availability and other monitoring software)
This would be "the unix way", a tool that does one thing "launch an app with appropriate isolation and notification) that could be re-used by many other people
(Log in to post comments)
you do NOT need to write all your programs together to make them work together. Posted Jan 28, 2013 22:39 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
> don't merge udev, go ahead and enhance udev to provide whatever service you are wanting to use, but keep udev a separate project so that people who don't want systemd continue to be first-class users
It's sort of touched on in myth #10. Separate git repositories is not the only path to modularity.
> don't reinvent syslog, if there is something that you need, contact the syslog maintainers and ask for the feature if you want it. Or if they don't have time to implement the feature, write it and contribute it (all of the syslog daemons accept outside contributions, and rsyslog, the default is very accepting, and supports sponsoring new features if you can't just convince them it's a good idea)
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.
> The latest thing with CRON is another example, the argument seems to be that they need to take over cron because it's another way to start a process, and they need to know about all process starts to 'manage' them.
My same thoughts here. anacron didn't integrate their features into cron. Nor did chrony seek to slowly improve ntpd. Nor did git seek to build on Subversion. (And there are many more examples.) Why does systemd have a unique responsibility to improve other implementations rather than providing capable replacements?
> How about instead defining a 'startup' program that starts jobs in their own cgroup, notifying interested programs through some mechanism (init being one of them, but probably not the only one) and then get CRON modified to use this program to fire off the apps.
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 and the journal.
you do NOT need to write all your programs together to make them work together. Posted Jan 28, 2013 23:17 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Separate git repositories is not the only path to modularity.
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?
you do NOT need to write all your programs together to make them work together. Posted Jan 28, 2013 23:51 UTC (Mon) by davidstrauss (subscriber, #85867) [Link]
> 1. you have to accept that there will be other users of your interfaces
Multiple external projects use the systemd interfaces. We've built a lot of them here at Pantheon. Some, like the Python journal API, have been moved to the systemd core repository. Some interfaces, like the PHP, Lua, and node.js interfaces, remain external.
Projects like the journal gateway are *entirely* APIs for external use and were built to improve inter-tool operation.
> 2. you have to accept that there will be people who don't use your favorite components
In the case of cron, there's no conflict at all. Keep running cron if you want to. It might eventually not be installed by default, but I'm sure it will be packaged and maintained for the next decade or so.
In the case of the journal, messages collected by systemd do have to travel through it but can be forwarded to syslog. syslog can also forward to the journal. The journal, by default, runs as an in-memory-only pass-through for messages to syslog.
In the case of init itself, you obviously can't have two co-existing as PID 1 on the same system, but systemd support init scripts, LSB headers, and the standard, traditional tools for managing services.
> 3. you have to define your interfaces
They're either plain text with key/value pairs (the journal interface), documented CLI tools, or metadata-defined D-Bus serializations.
> 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)
You can generally mix and match new and old API invocations without much trouble. For example, journalctl runs fine with newer and older journald implementations. The CLI tools have been consistent enough that we haven't had to alter Chef's systemd service support since it was implemented over a year ago. I'm not familiar enough with the D-Bus interfaces to comment on those.
> 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.
First, you need to cite the things that were supposedly claimed impossible with syslog but were actually easy, including where systemd maintainers made the claim.
Second, a project doing something within days of a fork is not evidence they were receptive to the change before. The Linux kernel stonewalled Android-style sleep-as-default (I forget the exact name) until Android forked the kernel and demonstrated a successful architecture for it. It took more than a few days, but it's still clear that competitive pressure is quite different from lobbying a project.
> It's not like the journal added capabilities that are so shocking and new that they can't possibly work in standard syslog daemons.
Maybe, but nothing comparable (even in terms of major changes unrelated to the journal's goals) has happened with syslog daemons in the last decade of running Unix logging. Until the journal, I still couldn't log a PHP backtrace in any way that kept the lines all together.
> 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.
systemd timer units don't force you to not run cron. Stop spreading obvious FUD.
> "in this version we switch from init to systemd and you don't see any changes if you aren't using new features"
That was basically the case for Fedora aside from dropping rc.d symlinks. The journal only came later, and it runs as a completely separate daemon and CLI toolset.
> what's the justification for replacing a established, well known tool with a new implementation inside systemd?
Consistent configuration of executable units (whether it's a service or a periodic job) and consistent administrative tools for logging and monitoring success/failure. It's unclear to me why anyone would want to configure things the old cron way once they're accustomed to writing systemd units.
you do NOT need to write all your programs together to make them work together. Posted Jan 29, 2013 2:54 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
> 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)
Well, systemd does that[1].
[1]http://www.freedesktop.org/wiki/Software/systemd/Interfac...
you do NOT need to write all your programs together to make them work together. Posted Jan 28, 2013 23:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
> How about instead defining a 'startup' program that starts jobs in their own cgroup, notifying interested programs through some mechanism (init being one of them, but probably not the only one) and then get CRON modified to use this program to fire off the apps.
Internally "cron" subsystem is implemented by a separate utility. It just uses the common systemd infrastructure and can be easily developed separately.
It's certainly possible to hook up systemd to launch services using DBUS interface. And you can then use it with any kind of triggers - I've actually used good old cron to start systemd tasks for a while.
you do NOT need to write all your programs together to make them work together. Posted Jan 28, 2013 23:22 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> don't merge udev, go ahead and enhance udev to provide whatever service you are wanting to use, but keep udev a separate project so that people who don't want systemd continue to be first-class users
I'm not sure that this has anything to do with what we were discussion about systemd compatibility with existing management methods but I should point out that in this case udev is still very much supported as a stand-alone component although it is fair to mention that because it shares build scripts with the rest of systemd so there there are additional build time dependancies that aren't explicitly needed by udev alone. This is of interest to developers and Gentoo users but is of no practical effect to anyone else.
> don't reinvent syslog, if there is something that you need, contact the syslog maintainers and ask for the feature if you want it.
http://blog.gerhards.net/2011/11/journald-and-rsyslog.html
Some thoughts on the Journal by the main rsyslogd maintainer. What might be interesting is if a tool like rsyslog would talk the Journal protocol natively, possibly replacing the systemd included implementation for large environments. In the blog post there are several examples given as to why building a new component might be a better approach, because of the things that you can't change for compatibility reasons, even if you improve them in rsyslog.
|
|||||||||||||