[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

Bob Ham rah at bash.sh
Tue Jun 23 10:59:19 UTC 2009

On Tue, 2009-06-23 at 00:49 +0200, Lennart Poettering wrote:
> On Tue, 23.06.09 00:36, Fons Adriaensen (fons at kokkinizita.net) wrote:

> > Since you claim that all the *Kit stuff is optional,
> (as a side note, I didn't claim that)
> > and you will still allow us to run our systems as we
> > see fit, and since you wear a Red Hat, please tell
> > me how to remove 
> Just downgrade to FC5 or so.

This response shows a real problem.  The fact that you cannot disable
these kinds of services without forking shows there's a design problem.
The fact that these badly-designed services have become so widespread
shows a deeper problem. 

Recently, money seems to have become quite influential in the free
software community, typified by Red Hat and its efforts to drive free
software development in a direction that suits enterprise customers.
The quoted response shows an unwillingness for these parties to
*cooperate* with communities and instead I see a desire to *dictate* to

Yes, I can fork Fedora and create a new distribution but that takes a
great deal of time and effort.  If Red Hat were interested in
cooperating instead of dictating, that effort would not be needed; Red
Hat would take on the responsibility of ensuring that their systems are
flexible enough not to need a fork.  Practically, that means designing
software systems in such a way as they can be easily disabled.

Being fuelled by money, this new influence in free software is
susceptible to the control of any parties willing to spend enough.  That
opens the possibility of a fifth column within the free software
community.  I've previously argued that in future, it may be necessary
to protect the interests of free software by forking away from this
influence if it starts behaving as a fifth column.

The above response shows that this influence is already having a
detrimental affect on the quality of free software.  I wonder if it
won't be necessary to fork away from this influence, purely because of
the sub-standard nature of the solutions it produces.

RealtimeKit demonstrates this sub-standard nature in that it's a
workaround.  It provides an API to be used if a system call fails.  This
is not a problem in itself but there seems to be no desire to spend the
time and effort needed to deal with the issue of why the system call is
failing.  Instead, there seems to be only a narrow-minded drive to
produce the next-best *Kit, which will provide an all-new service to
enable our enterprise customers!

It's great that all these new Kits are putting free software in the
hands of average users.  What isn't great is that they seem to be
hastily developed and without concern for the wider free software
community.  There will be consequences of this lack of concern.


Bob Ham <rah at bash.sh>

for (;;) { ++pancakes; }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090623/bd0e447c/attachment.pgp>

More information about the Linux-audio-dev mailing list