On Fri, 19.07.13 20:12, Miloslav Trmač (mitr@xxxxxxxx) wrote: > On Wed, Jul 17, 2013 at 2:20 PM, "Jóhann B. Guðmundsson" > <johannbg@xxxxxxxxx> wrote: > > On 07/17/2013 12:05 PM, Richard W.M. Jones wrote: > >> > >> On Wed, Jul 17, 2013 at 09:21:39AM +0000, "Jóhann B. Guðmundsson" wrote: > >>> > >>> On 07/17/2013 12:58 AM, Ding Yi Chen wrote: > >>>> > >>>> You still have not addressed the third party programs and scripts > >>>> that monitor /var/log/messages > >>> > >>> We honestly cant keep progress and cleanup in the distribution back > >>> out of fear of breaking some third party programs. > >> > >> Irrespective of whether journald is good or bad, this is a dumb > >> argument. > > > > Dumb I see so you have established a time frame for us how long we should > > hold back progress in the project and or you have devised an implementation > > plan on features and cleanups with a rate that a third party can keep up > > with in the distribution, maybe even chosen which third parties we wait for > > and which we dont? > > Progress does not that frequently depend on removing older > functionality. Specifically in this case, removing rsyslog does not > make journal in any way better. It certainly makes *Fedora* better though, by making the core less redundant and decreasing its footprint. > The same thinking applies to individual sets of APIs and other > interfaces: write the new implementation, write a compatibility layer > for old users that replaces the old implementation, write a test suite > of the compatibility layer (... or just use the test suite of the > implementation thing that you should have already), keep the > compatibility layer shipped and running and forget about the > transition. Writing a compatibility layer is roughly the same kind of > work as porting applications, so with any interface that has at least > a handful of users a single compatibility layer should in fact be less > work. With this approach, it's not at all obvious that one shouldn't > aim for a backward compatibility 100 years back[1][2]. > Mirek Note that the journal provides this compatbility layer to a fairly comprehensive degree. We speak the syslog protocol natively so that log clients don't have to be updated. We provide a pretty much perfect identical output to /var/log/messages as default from journalctl. We make it easy to to get the exact files /var/log/messages by forwarding everything to syslog instantly if it is running. However, we also go one step further: eventually we remove the old implementation from the default installation. That's a very gentle push only, because the old stuff is trivially easy to get back, simply by installing rsyslog again. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel