On Tue, 2009-06-23 at 00:49 +0200, Lennart Poettering wrote: > On Tue, 23.06.09 00:36, Fons Adriaensen ([email protected]) 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 communities. 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 -- Bob Ham <[email protected]> for (;;) { ++pancakes; }
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
