F20 System Wide Change: No Default Syslog

[Miloslav Trmač]

On Wed, Jul 17, 2013 at 2:20 PM, "Jóhann B. Guðmundsson"
<johannbg at 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.


> We as a community need to be able to set the pace for ourselves and the fact
> is unless you are closed source the best thing you can do as a third party
> is actually participate in the Fedoraproject, packaging you software or
> application stack and ship it within the distribution so that our existing
> processes will catch any fallout which our features or cleanups might bring
> and allow for the community to actually fix it with your or for you.

The "we have source, we can improve the API, update all users and end
up with a cleaner design" argument is very rarely true in practice
outside of fairly tightly coordinating communities (of which the Linux
kernel and its approach to internal interfaces is probably the most
visible example).

In fact, we as a distribution are getting _worse and worse_ in this
regard.  There are, instead, more and more subsystems that ship
parallel-installable versions with no specific plans about ever fixing
"all users" - sometimes apparently just hoping that both the unported
users and older versions of the subsystem will die of neglect at
approximately the same time.

The argument about updating all users is just not true for proprietary
applications, binary-only applications, or cross-platform applications
with a release schedule significantly different from Fedora.  (Some
people think that the Linux ecosystem should be entirely Open Source,
so they don't find this relevant.  I'd rather not extend this huge
thread into a discussion of this particular difference of opinion.)


Finally, as a thought experiment - we have a fairly well developed
concept of automated testing, and we (so far?) have Moore's law making
CPU, storage and the cost of testing exponentially cheaper over time;
it just might be the right thing to do to provide essentially infinite
backward compatibility, in the same way the newest Windows can run
64-bit applications completely natively, 32-bit applications almost
natively, 16-bit applications in a VM or full software emulation, or
even fully emulate old 8-bit systems.

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

[1] One can't promise the backward compatibility 100 years into the
future, though, no more that one can promise that any particular
town/nation/language/building will still exist.
[2] Don't worry, I'm not at all proposing that Fedora should aim for a
backward compatibility 100 years back.  I do want to seriously
undermine the idea that progress requires removing or breaking things,
though.