Re: LSB Commands and Utilities, Draft proposal
On Mon, 12 Jul 1999, Daniel Bradley wrote:
> Unlike mainstream Unices Linux has the potential to operate in a vast
> number of radically different roles. Hence the LSB needs to be as small
> as possible, to allow maximum flexibility.
That's one of the goals, I beleive.
> For example, Linux as a gamer's platform. Another example is Linux being
> used as the OS for Car MP3 players.
The gamer's platform should depend on LSB so that, for instance, the game
installer can either use a standardized package interface or have access
to a common set of tools that are available (like rm and cp).
The MP3 player platform is considerably different. Chances are that you
won't be installing much software on your MP3 player (or are people doing
word processing in their dashboards now and I missed it?). An MP3 player
is outside of the scope of LSB. The primary goal, as I understand it, is
to provide a baseline of standard tools and libraries that applications
can depend upon the existance of. In the case of an MP3 player, all the
software that is necessary to run it will be installed by the OEM and no
more software (beyond updates) should need to be installed. An application
vendor isn't targeting an MP3 player as a potentail platform. Ditto for a
router. These sort of specialized embedded systems are outside of the
general scope of LSB, and I don't see any reason LSB should make an effort
to include these platforms. They don't benefit from LSB, and LSB doesn't
gain anything from limiting itself to include them.
All this, of course, IMHO.
Jakob 'sparky' Kaivo - firstname.lastname@example.org - http://www.ndn.net/
"As time goes on, my signature gets shorter and shorter..." - me