On Fri, 19.07.13 20:12, Miloslav Trmač (mitr@volny.cz) wrote:
On Wed, Jul 17, 2013 at 2:20 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com 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