[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Getting somewhere
I'm fairly new to this mailing list, so maybe I'm a bit
sidetracked here, but sadly I get the same kind of feeling
here that I have gotten from many other ambitious mailing
lists that have all led to ... nothing.
I don't want to put people down, I think the idea behind
this project is tremendous, and something that could give
really bad nightmares to Bill Gates if it worked out. (It's
not that I want the man to sleep badly, I just meant that this
could become something really competetive and powerful! :-)
In order to succeed it's important that the focus is set on
actually getting results. In order to get results, it's imperative
to avoid doing things that needn't be done. There will be so
much work anyway, just doing the _really_ important things.
I would like to make a few statements:
1. The main strength of the free software concept is that we don't
need to reinvent the wheel over again, but can use the wheels
that are already around, either as they are today, or further
2. One main strength of unix is it's ability to combine different
standard tools to produce results. There is no need to make a
new monolithic application for each kind of task we want to perform.
This is probably the major pedagogical difference between unix and
the MS Windows world, and I think we should nurture this, make this
concept more accessible and make sure it stays that way.
3. SEUL is still a tiny thing. It doesn't have any kind of power to
force changes upon others like MicroSoft or IBM. Inventing new
standards at this point and requiring that application builders
follow them is not really an option.
4. In any project, it's important to achieve results fairly quickly,
or people will get bored and jump to something else.
5. If the aim is to make a unix distribution that is easy for people
to use, it should try to make the environment simple and uniform.
Rather than to introduce a lot of new stuff we should if possible
provide things people recognise (without making it into a stupid
Win95 clone). The unix concept of general tools rather than
monolithic applications can be a real strength here. One standard
editor - regardless of whether you are editing emails or letters
or whatever. If you prefer emacs instead of the simple standard
editor you should be able to use emacs whenever you edit something.
One browser - regardless of whether you are surfing the web or
looking in local help files. (Ok, it might turn into one for X
and one for text mode.)
How does this relate to the SEUL activities today?
Well, to start with nr 4 I think it would be good if a tiny SEUL
distribution could be put together and made available reasonably
soon. Mainly to show us that we can really do this, but also to
form a concrete base for tests and further discussion. The practical
work will also teach us a lot.
Avoid writing software now! Why do you want to write a help file
browser when there are plenty of web browsers available? If we
manage to make all documentation available in HTML and structure
it in a good way, we have achieved much more than through making
the spiffiest new help browser imaginable. With HTML documents
people can access this information over the net, or locally, in
X Windows or from a text terminal. Others refine and develop these
help browsers for us. If PDAs become popular as small linux
terminals in the future they will certainly have web browsers, the
same goes for adaption to other new hardware, solutions for
disabled users etc. If we want to make things as simple as possible
for the user it's rather obvious that we should let him/her use
the same tool for browsing manuals and help texts as he uses for
surfing the web. This is certainly in line with both the concept
of unix and the aims of this project.
Don't try to set new standards. Above all, don't set new standards
where there are already too many 'standards' rather than too few.
Choose the best even if it isn't perfect. So, choose a package
manager, RPM or Debian's and use it as it is for now, and think
about adding features later that could preferably be returned to
RedHat / Debian. Choose an existing tool for administration,
figurine or what ever.
Decide what GUI standard SEUL should use. I see two good candidates.
NeXT/GNU/OpenStep or CDE. Both of these are good. I don't know
enough about them to say which is more easy to integrate with
existing software etc, and for which of these a decent GPLed
environment is closest at hand. I'm certain that it's much better
for us to contribute to GNUStep or KDE etc than to build our own
GUI tools. Even if we have to write things from scratch, stick
to existing standards like the CDE or NeXT concept.
Magnus Lycka, Folktrov. 6C, 907 51 Umea, Sweden
+46(0)90 198 498, email@example.com, www1.tripnet.se/~mly
Simple End User Linux Mailing list
To be removed from this mailing list send a message to firstname.lastname@example.org
with the line
in the body of the letter.