[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Indy updated
>
> I have taken our guidelines web page and crystalized all its thoughts and
> notions into standard English. Here is the new code in HTML which we should
> now adopt for the guidelines page :
>
> Linux will remain a niche operating system until the majority of operating
> system end users learn to utilize its many advantages. To date, near
Here it should read "the majority of end users"
> universal use of Linux hinges on the future availability of less expensive
> hardware support and software packages for multilingual documented programs
> for the occasional end user.
>
> Manufacturers' incentive to contribute to the critical mass chain reaction
> snow ball effect of compatibility will nudge our deficiencies into a self
> resolving stage of development as the industry rushes to maintain sales by
> updating to the fast growing Linux trend.
>
I think the preceding paragraph is a bit contorted,
> A well executed Indy distribution of Linux can hasten such an accelerating
> exponential growth of the proverbial snow ball which should provide drivers,
> translation of documentation, and applications eventually.
> <BR>
Ditto
> <H3>
> I) Forget about Unix tradition: Linux is NOT Unix.</H3>
>
> <H4>
> a) Two different ways of life: Unix and Linux.</H4>
> Unix was used in universities and medium-to-large sized companies which were
> big
> enough to buy the expensive Unix computers. Unix was seldom used as a cost
> effective solution for simple tasks that were easily accomplished using Macs
> or Wintel machines. The tasks reserved for Unix required a highly trained
> and educated network of system administrators and their professors. Unix
> users could afford a non-intuitive obscure interface between its expensive
> hardware and its 'elite' operatives who were trained within a highly
> structured highly maintained academic milieu. Although Linux now follows in
> the narrow path of Unix footsteps, it has the suddenly apparent tendency to
> break out of the narrow Unix path and into enough directions for the
> majority of computer end users. It will no longer beat funeral marches to
> the Unix grave but will repopulate the growing empty space of world wide
> computer storage devices and random access memory.
>
> Whereas expensive Unix is collapsing into a neutron star Linux as the new
> red giant is expanding into our laptops and desktops at home and within
> small companies.
>
> The needs, constraints, and training of Unix and Linux are
> vastly different.
> <BR>
> <H4>
> b) Linux at home</H4>
> The home computer system administrator is the end user of the box from
> installation day to the day of obsolescence. We will configure our box
Should read "he would have to configure his box at a time when he
doesn't know even the most trivial commands. Of course he should have
a book"
> first, then learn how to copy a file single handed. Problem solving will be
> a Neil Armstrong adventure in isolated space. Of course, we should have a
> book, which will fall short of hands-on experience. Previous such books
> have assumed Linus to be just another Unix, but have failed to address the
> home-user's problems or adequately address software for dial-up IP and
> access to the net. A mac user cannot be expected to rise to the occasion as
Here you will have to express the following idea: "Unix assumes the
system administrator is an experienced user, that the Unix user is
working for his boss and that he is using the box in a relativeley
large organization (Unix was unaffordable by private users).
This is wrong in Linux: there are private users and have to take
charge of systaem admainistration for minute one, they could be using
at home so several assumptions like permanent access to the net don't
hold and they would be using Linux for their own need and pleasure.
(My personal example is an RDBMS with every security feature known in
world for mision critical apps if you target personal users versus the
non relatiuonal rolodex like data base good for managing a wine cellar
but with an attractive UI when you tarhet indidual users and of course
games)." End of the idea I want to express.
> a de novo power use hacker. Most of Mac users want to be productive from
> day one and never accumulate weeks of training. Obviously the Unix shell is
> not a tool to attract mac people to Linux. We must provide an alternative
> intuitive shell containing help files.
Expressed differently a Mac user wants to do real work ASAP. It is
important we get "normal" people wanting to use Linux not because they
want to become power users but for real work or (or games).
> <BR>
> <P><B>c) Linux in small companies</B>
> <P>Although Linux could rapidly assume the server role for small companies
> where the computer operator has direct contact with the cost conscious
> proprietor, here are 3 potentially overriding factors :
> <UL>
> <LI>
> A small company might use fewer or perhaps only one server computer, and
> only one license. Economy of scale might be achieved more easily with NT.
About economy with NT I would want something like 'in case Linux is
significantly harder to use'
> An employee RTFMing costs $200.00 a day.</LI>
>
> <LI>
> Small companies which cannot afford a full time guru can either externalize
> their system administration or retain a part time employee using a simple
> system.</LI>
> <LI>
> Classic Unix servers
> like Sendmail and INN are overkill for such a small business. Unix was
> designed with the
> needs of big organizations built in. </LI>
> <BR> </UL>
> <H4>
> d) Linux in the desktop: </H4>
> Just because Unix never made significant inroads into the desk-ware lap-ware
> market does not mean that Linux needs to be restricted to the server,
> programmer's work station role. A secretary could just as easily write memos
> on a cheap Wintel machine as on an expensive Unix work station so she was
> handed a Wintel. Such an argument against Unix does not hold water as an
> argument against Linux which is cheaper than Windows and can be administered
> from a distance, is not subject to virus attacks, and doesn't crash five
> times a day. The choice is clear. But we have to include a good GUI and get
> rid of the "real men use TeX" mind set. TeX is great in the hands
> of certain people and for certain documents. Here what is needed is X-based
> Wysiwyg word processors, spreadsheets and presentation software. When we
The end of paragraph of unfortunate (it was mine). It should tell
about provifing an adequate environment and tools for non technical
users.
> cannot find a good, free tool, we should ensure that the user knows about
> commercial ones.
> <H4>
> e) Separating Linux from Unix: </H4>
> Linux can go where no Unix has gone before, but not simply by blindly
> following Unix tradition. Unix has not been designed for the mass market.
> Before someone burns me for heresy, let's keep in mind that this, in fact,
> is the real Unix spirit. Ken Thompson never said that Unix had to be user
> hostile. In fact he separated the shell from the kernel in order to allow
> different users to get different user interfaces. Linux must keep the
> classic Unix interface for power users, but there is no reason other people
> cannot get a different one. <BR> <H3> II) Design
> guidelines.</H3> <H4>
> a) Mind set.</H4>
> If a feature is useful for 10% of cases but makes no difference for the
> remainder, then add it. If a feature helps 90% of users and annoys the
> remaining 10%, then add it (providing the benefits outweigh the losses). If
> a feature would annoys a hacker but helps a beginner then add it. A newbie
> end user cannot add a feature but a hacker can easily remove anything he
> likes. You have to forget about yourself and your tastes: you must be able
> to think like someone who knows nothing, is not a hacker and is learning
> Linux without assistance.
> <BR>
> <H4>
> b) A superb installation is... relatively unimportant.</H4>
> The best installation would simply be to get PC manufacturers to do their
> jobs. They will do it-- if Linux market share reaches critical mass. But if
> the user only gets unfriendly programs, software which was not designed for
> the job, or cryptic docs, then even that ideal installation will have
> achieved nothing. The RedHat's 5.2 that we use as base has an install which
> is not so bad: it detects hardware, can handle partitioning without user
> intervention,
> and package selection is reasonably terse. Its two main drawbacks are
> scarcity of on-line help and the fact that it acts as if PPP didn't exist;
> the latter meaning that after install the PPP user has to configure his
> networking without the same kind of hand holding the LAN user gets during
> install. But to a home user, no PPP means no access to help. Another point
> of improvement
> would be to boot directly into XDM if X is configured (we can allow
> ourselves to do this now that LILO tells the user how to re boot no X in
> case of
> problems).
The XDM part is obsolete: every major distribution is doing it now.
> <H4>
> c) Docs: the "Now what?" syndrome</H4>
> After install, many users find themselves completely lost. Read the news
> groups and you will see postings like "I typed X and only got a grey
> screen". In addition, there is a risk that many of the nice programs we
> include end up never being used because of advice in books or new groups
> like "Use VI, elm, tin". To avoid our efforts being wasted, it is important
> to have a small guide pointing the user to the correct tools and detailing
> how to get out of some common pitfalls. Of primary importance is making the
> .doc attractive, readable and easy to navigate for the appropriate
> information. If we look at a How-To collection, we will find most to be
> reference rather than pedagogical works; in addition there is no hierarchy:
> important .docs and obscure ones, .docs for advanced users and for beginners
> are all at the same level and it is difficult to find what you are looking
> for. I have seen people using Windows or NT because they didn't know about a
> Linux program: we will have to ship one of the databases of Linux software
> like the LSM. Woven Goods could be a good choice: it includes all the LDP
> documents, an LSM, plenty of info about Linux software, all in very nice
> HTML. Caldera used to include it but doesn't anymore. I don't know why;
> perhaps because of its size and the fact it has not been translated AFAIK.
> Speaking of translations, Linux could afford to have docs available only in
> English as long as its users were 'computer nerds', but 'normal people' are
> not good at foreign languages. Man pages and most How-Tos have been
> translated, but only a few programs have been internationalized. This also
> goes for special manuals like the GIMP manual or doc in info format.
> <H4>
> d) Learning from Microsoft.</H4>
> <I>"Learn from your enemy and you will ever be victorious"<BR> -Sun Tzu
> <BR><BR>
> "Microsoft makes crappy operating systems but they make good user
> interfaces"<BR>
> -Linus.</I><BR><BR>
Here I needed to use Linus as a shield in order to avoid being lynched
for prasing Microsoft. :-))) But the quote is authentic.
> Look at the last versions of DOS before Windows 95. They made a file manager
> (DosShell) to be the default, and forced experienced users to edit the
> AUTOEXEC.BAT. In Linux we make the power-user get his favorite interface out
> of the box and the defenseless new user is supposed to discover about "mc"
> and then the way to make it his default shell. This illustrates what is
> wrong in Linux designer's thinking: design for Linux the same way as for
> University
> Unix. It would be a good idea to provide an option at user creation: <BR>
> "advanced user" or "beginner" with the latter being dropped into 'mc'
> instead of the shell. Of course in most cases this would be a moot point
> because we hope to make XDM the default root level, but it is still
> worthwhile to implement. In Microsoft products like Windows 95 and MS Word,
> the user gets a tip each time he starts it. This ensures the user learns the
> main tricks and ways to get out of problems. In fact, Microsoft software's
> frequent crashes are not due to bugs. This is a feature to ensure that the
> user will read many messages and learn fast. :-) This a trick (also used in
> GIMP) we should
> take advantage of: display a tip each time the user logs in.
> <BR>
> <H4>
> e) What is wrong with RTFM</H4>
> There was a time the Matrox Mystique was the most popular card.
> Unfortunately it wasn't supported by Xfree, and for months after it was
> supported there were people with old versions asking why it didn't work. Of
> course they were
> mercilessly flamed. Nobody pointed out that the X configurator could have
> said flatly: "This card is unsupported". Nobody pointed out that the X
> configurator could have said: "This version is 11 months old, you should
> look
> for an upgrade". "RTFM in case of problem" is the answer you give a user who
> knows how to get
> to the doc, how to look through it, and has only one problem to solve (like
> when trying to add a service to a working box For the user who Instead has
> half a dozen problems (like right after finishing installation) it helps if
> he isn't forced to look at the book to know how to display a file. If the
Should tell about Linux users with half a dozen problems and not
enough skill to be able to display a file without looking at the book.
> user doesn't meet these requisites then the program should point at what is
> wrong. It is astonishing how often the simple principle of "Put the
> information under the user's nose" is forgotten in Linux world. The
> existence of an FAQ in news groups that doesn't mean that users are lazy; it
> just means we did something wrong. <BR><BR><BR><B>
> f) Networking: the road to help<BR><BR></B>Commercial Unix users have hot
> lines. University users can go to friends or teachers but Linux needs to
> spread at home, and the Net is very often the only way to get help for a
> home user. This means that we should introduce PPP configuration in
> installation. We also need a good curses-based PPP configurator in case the
> user does not configure at install time. KDE has a very good configurator
> but we can't rely on it: What happens if the user needs help about X? In
> many countries phone time is billed at extortionist
> rates; therefore, we should optimize to make the connection be as short as
> possible. Mail and news clients should allow off line reading. Some small
> organizations could have net access through PPP, but for them small mail and
> news servers would be better than off line readers. That means we have to
> design a mechanism ensuring that traffic is routed when the PPP link is up,
This is done (for mail) in 0.2
> and that mechanism should not require the user to hack files. With small
> mail and news servers there is the problem that they don't have Linuxconf
> modules like send mail. For mail IBM's "postfix" could be a good compromise
> because it is able to use either sendmail configuration files or a native
> (and simpler) mode, but we have to carefully check its copyright A proxy
Postfix copyright has been fixed
> server can allow substantially faster (and thus cheaper) web surfing;
> however, the batch retrieving allowed by wwwoffle is more important for
> small organizations and home users than the proxy interconnection allowed by
> Squid (the proxy shipped by RedHat). Again the problem is that wwwoffle has
> no Linuxconf module while squid has one. Another interesting proxy is
> "junkbuster" which removes the ads from web pages. If we ship two proxies we
> have to design a clean and transparent mechanism for chaining them. Finally,
> UUCP is sorely neglected in Linux distributions. It is dead in America but
> its speed and low requirements makes it still useful in Europe,
> ex-communist,and Third World countries.
> <H4><BR>
> g) Replace cron</H4>
> We can no longer live with the absurd paradigm that the user will keep his
> box turned on for 24 hours a day. The replacement for cron should accept
> regular crontabs for compatibility, be self-tuning (use cron mechanisms if
> the machine
> is turned on when the task is programmed and alternative mechanisms if a
> task was not run at the programmed time) and unobtrusive (try to run tasks
> when load is low). AFAIK "anacron" falls short on the unobtrusive part.
> <BR>
> <H4>
> h) Get a better booter than LILO</H4>
> LILO is a hacker's booter. You have to perform a special operation when
> installing a new kernel, don't get menus at boot time, support for national
> keyboards is tricky, and you can do nothing until you reboot. Other booters
> should be investigated. The one I like most is the booter which used to come
> with the now defunct Linux Universe. You got menus, could add a kernel at
> boot time, explore the file system in case you didn't remember where it was,
> change booter parms at boot time and could change the keyboard on the fly.
> It seems there will not be copyright problems but there are parts which need
> a Microsoft or Borland assembler unless someone translates them into gas
> syntax.
> <H4><BR>
> i) Pushing aside the "mother of all Unix haters".</H4>
> Every time I find a Unix hater I ask him why. So far no one has told me
> about the shell or the cryptic commands as the main reason. <B>ALL
> </B>of
> them pointed to VI as the culprit. (Emacs does not seem to cause this kind
> of allergic
> :-). "VI is the editor you will find in all Unixes". Well, in most jobs you
> could down load another editor even if you are using another Unix; and in
> addition, we hope Linux will crush other Unixes, so to hell with their
> editor.
> VI has made Unix lose many users; don't let the same happen to Linux. We
> don't plan to remove VI, but:<UL><LI> Never force it on an unwilling user.
> The Editor environment variable must be set so that programs needing an
> editor don't call VI. It is simple to set it differently according to
> whether or not we are using X. Never place the user in a situation where VI
> is the only editor: ensure that there is another editor in /bin with all
> needed shared
> libs in /lib so the user can resort to it in case he cannot mount /usr. In
> the same way, place an alternative in rescue disks. Unfortunately we cannot
> remove sentences like "edit this file with VI" from standard docs but we
> should never use mention VI in docs written for this project. We don't want
> to frighten new users. Don't ask yourself if VI is good for you, ask
> yourself if VI is good for Linux.
> <H4><BR></UL></LI>
Here I owe an apology to VI lovers of this list. VIM is far better
than traditional VI due to the fact it has online help and tells you
how to get it. I still think VI was a PR disaster for Unix (ever
thought it was written by a Microsoft spy :-), just kidding) and that
he will be disliked by most people but VIM is an acceptable editor for
a person who have to fix problems five minutes after sseing a Unix box
for the first time.
> j) The user should not have to recompile the kernel.</H4>
> It is our duty to ship kernels complete and good enough so the user will
> never need to recompile them except for sport and <B>very</B> experimental
> features. In 2.0 the performance increase you get by recompiling the kernel
> (if the distribution editor did a half decent work) is nearly nil, despite
> what vulgata could say. See my analysis in the Independence-features RPM.
> About the only case in which it's necessary is if you are using a multi
> processor box. This could change in 2.2, especially when using better
> compilers than gcc 2.7 so perhaps we will be forced to ship several kernels
> and have the
> installation choose one according to processor type and chip set.
> <H4><BR>
This is obsolete. Kernel 2.2 has several portions of code who really
benefit of processor optimization but Redaht (and Indy) ship several
kernels tuned for 386s, pentiums and 686s and the install chooses the
right one.
> k) X should be the default mode.</H4>
> Nowadays the memory and CPU frugality of curses-based applications is not
> important. People accustomed to windows will dislike this
> kind of apps and in addition they will find themselves clueless in front of
> the command line. We should make XDM the default boot mode (with LILO
> telling how to boot non X).
Again this is obsolete
> <P><B>l) Consistent GUIs</B><BR>
> Traditional X has had nearly every application having its own look and feel.
> This is disconcerting to the user. Fortunately Linux now has complete GUIs
> where every application shares the same look and feel and in addition have
> richer intercommunication protocols than when using different tool kits. We
> should keep neutrality in KDE-Gnome rivalry, ie ship both.
Both are in 0.2
> <P><B>m) Selecting application program</B>s
> <P>Programs must be user-friendly (of course) and good looking (to an
> inexperienced user, ugly programs cause an instinctive interpretation of
> being buggy and of poor quality). ). If they need to have resources set to
> make them attractive then it is up to us-- not to the user, to do the job.
> Having easy programs is not enough; they need to cover a need for the user,
> so shipping only hackers software will attract only hackers. This is not
> what we want. For that reason we should look for programs which are fun,
> allow artistic expression (I would like to ship a GIMP with every plug in
> available)
Perghaps next we will ship GIMP 1.1
> and are useful for real life. We don't want the user needing to boot DOS
> just to manage his check book. Agreed, some of the free programs we can
> include are not as attractive as their Windows commercial counterparts, but
> by providing Linux alternatives there is a chance the user will be annoyed
> at having to boot DOS and be still more reluctant to buy them. Many editors
> don't port to Linux, many hardware manufacturers don't provide drivers
> because they expect the Linux user will accept to reboot Windows. Providing
> software for everyday life will make Linux users more likely to refuse
> playing this game.
> <H4>
> n) Games</H4>SVGAlib games must run setuid root so everyone is a security
> risk. In addition a number of cards are not supported in SVGAlib. We should
> avoid them. We can make exceptions in rare occasions because, unfortunately,
> X is
> not adequate for action games (not without GLX who is not supported in
> XFree). Net worked games can be played in America and in Universities but
> in Europe the telephone is too expensive and this restricts their use to
> people having
> several computers in the same home. <BR>
> <H4>
> o) Delivering ready to use applications</H4>We must try to get installations
> requiring as little user intervention as possible. X apps must get their way
> into menus, resource files provide good looks out of the box, parms who can
> be deduced automatically must find their
> way in config files (think in a networking client who needs the machine host
> name) and so on. Whenever possible we should avoid automatic edition because
> it is relatively dangerous, especially in case the user has manually
> edited the file. Instead, we should use file inclusion or directory scanning
> (look at /etc/profile.d for examples) if at all possible.
> <BR>
> <H4>
> p) Plug and play cards</H4>
> Using the isapnp tools is very difficult, and this makes using most sound
> cards a daunting ordeal. The Turbo Linux distribution has a GPLed tool whose
> main drawback is being curses based. There is also a Gnome front end to
> isapnp but, for one part it is unfinished work, and in addition this lets
> KDE or classic X ers out.
> <H4>
> q ) Samba</H4>
> Having Linux sharing disk space with Windows boxes is not uncommon, whether
> in
> the server or client role. Linuxconf allows to configure Samba, so unless
> there is a significantly easier configurator, I think we could leave the
> things the way they are. What wbut last time I checked it had a very
> primitive setup. Of course we could modify it.
Here we should update this. Problem is the fact the classic distribs
are designed by people who never worked in a Windows-centric company.
The tool for cąonfiguring SMB printing is unadequate, they don't
integrate LinPopUp with Samba, don't provide a decent tool for
exploring the network and mounting share (Mandrake will include Gnomba
but if you test it you will notice the Mandrake people never tried it).
Please don't quote me in the preceeding paragraph, I just expreseed ideas.
> <H4>
> r) Printing</H4>
> We ship ghostscript 5.10 and we should introduce in the printer
> configuration database the additional printers respective to the ghostscript
> 4 shipped in plain RedHat.
> <H4>
Preceeding is obsolete. I wanted to add aditional printers support
and improving SMB printing and config but I finally decided to let it
out of Antaeus, we will see in next release.
> s) Linuxconf</H4>
> Having a central program like Linuxconf for configuring everything is a
> great plus, but the drawback is that it tends to freeze situations. The most
> popular or traditional programs have Linuxconf modules and that makes it
> more
> difficult for newer and easier programs to gain the upper hand. Sendmail,
> for instance, is difficult to configure even with Linuxconf but the user
> would tend to try his luck with Sendmail even when not requiring as powerful
> MTA. Therefore it would be great if we were able to provide Linuxconf
> modules when
> shipping alternatives to classic servers.
> <BR>
> </BODY>
> </HTML>
>
>
>
>
--
Jean Francois Martinez
Project Independence: Linux for the Masses
http://www.independence.seul.org