User: Password:
|
|
Subscribe / Log in / New account

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 23:17 UTC (Mon) by dlang (subscriber, #313)
In reply to: you do NOT need to write all your programs together to make them work together. by davidstrauss
Parent article: Poettering: The Biggest Myths

> 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?


(Log in to post comments)

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...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds