Re: Desktop normalization
On Tue, 24 Nov 1998, Davide Bolcioni wrote:
> Marcin Krol wrote:
> > On Tue, 24 Nov 1998, Greg S. Hayes wrote:
> > > Desktops are a value added product
> > Not at all. It's not seventies anymore. Now desktop (widely understood) is
> > de facto part of OS.
> > Marcin Krol
> In my opinion, one of the major points of the Unix approach is precisely
> that the whole GUI is an *optional* component (just like other major
> components, by the way).
Definitely, modularity per se is wonderful thing.
>I can do without or pick the one I like best
> and have the right to expect everything else to (sort of) adapt
> accordingly (well, this last point is not here yet).
In hardware world your approach has worked very well - do you know *any*
other architecture than PC that is a. fully modular b. you can buy modules
from various vendors? a. allows you to customize your machine up to your
wishes (that's what I love PC for), b. allows competition and excellent
price/performance ratio (that's the second reason to love PC). Other than
that PC is clumsy machine (that's why I don't like it).
However, in software world modularity approach seems to actually
worsen price/performance. It simply is too complicated and requires
having too much knowledge (from POV of casual user) before achieving
satisfactory state. Something needs to be done about it, or else
Linux will get opinion of system that geeks promote so they
have guaranteed employment forever - I have met such opinions
> I have often tried to articulate the feeling of the difference between
> Windows and Unix, and here follows the reasoning of a convert to the
> latter: with Unix, the user (even more so the root user) is in control.
It's not really unix vs win, it modularity vs one model. The only
> Applications are expected to adapt, not the other way around.
Yes, they are expected. Problem is, they don't adapt - user
has to do it. In order to do so, user has to acquire large quantities
of intrinsic and otherwise useless knowledge. It's not
impossible - it's uneconomic. IMHO, the whole point of standards
is to make things economic. If you need customization only, you
do not need standard, just DIY everywhere.
> sense, it would be best if applications could adapt without the user (or
> a configuration program) configuring each of them when a change is made:
> it is up to each application to look around when launched, and adapt on
> the fly (the user might want different instances of the same application
> with different behavior, after all: environment variables affecting
> behavior maybe are a kind of attempt at this).
It looks great. The only problem is cost.
> Of course, applications need an API that either abstracts the services
> they can rely on or lets them "look around" and find out what's
> available. I understand that LSB is definitely concerned with the
> former, and I would like to hear comments about the latter.
Yes, it is the problem of extent of LSB. What I read in Mission Statement:
The goal of the Linux Standard Base (LSB) is to develop
and promote a set of standards that will increase
compatibility among Linux distributions and enable
software applications to run on any compliant Linux
system. In addition, the LSB will help coordinate efforts to
recruit software vendors to port and write products for
Take following restrictions:
- desktop machine
- work with use of GUI
- user with average skills
1. "Compatibility between distributions" and "ability to run
on any Linux compliant system".
LSB has to describe desktop *behaviour* in some way for the sake of
compatibility between distributions tailored for desktop machines.
Otherwise you get anarchy on the level of UI, and that is what new users
The moment OS reaches desktop machine there is no way to avoid definition
of default UI behaviour. Now the challenge is how to do it without
sacrificing customizability and alienating current user base.
2. Porting/writing for Linux.
Put yourself in shoes of software vendor that wants to port
popular application that uses GUI to Linux.
If you don't have the way to make it easily (and cheaply) integrate into
all possible GUI styles (fvm95 windows-like start menu, KDE way, etc.),
then this vendor has instantly limited out-of-box usability of
application. Theoretically this vendor can write installation scripts for
all possible wms, but vendor does not want to do it (besides it has little
practical chance to work 100% correctly), so he says "screw it, let end
user integrate it". Which end user hates to do, because time spent on
configuring machine is from user's POV wasted.
InstallShield is what largely solves this problem in win95 env. This is
more attractive both to vendor and end user. Since LSB is about
interoperability rather than providing the only way to do it, it would be
best if LSB defined some way of "transmitting" this data easily.
I know that at first time it may look as being outside of scope of LSB,
but it does look important to be there in LSB. This is about philosophy
of LSB - to which parts of system it pertains.
Call for participation:
"This standard base will be distributed as a reference
platform from which Linux distributions may be derived and which
application producers may use for testing [...]"
How do you want GUI-using application producer to integrate his app into
Linux system without some universal means to do it? I know that "Linux
systems with GUI" is only a subset of "Linux systems" set, but
nevertheless it is subset of major size and importance.
"...but it will _never_ be targeted to be an end-user solution in itself,
as that is the role of the Linux distributions that incorporate the
Such standard would not be meant for end user - it would be meant
for developer. Or else we will have word processor xyzzy for RedHat,
for Slackware, for Debian, for....
Now the question is how to do it with kind of "minimum" specification.
The last thing Linux needs is additional complexity.
Hiroshima 45 Tschernobyl 86 Windows 95