[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Restart after long silence
> email@example.com a écrit :
> > All going well tomorrow we will have something like a 0.0.0 Indy in
> > the ftp site. I have hacked the RedHat 7.0 beta installer to work
> > with Indy but it still displays RedHat logos and texts. This will
> > have to be fixed. The _only_ benefits for now are support of multiCD
> > installations, a compiling environment with gcc 2.95 granting a 30%
> > speed bonus at floating point and the use of RPM 4.
> > After that we will have the question of how to make evolve the
> > software base, we can be coventional and just add tools or radical and
> > do things like replacing sendmail by postfix, drop TWM and (don't shoot)
> > make the user explicitly install VI ie VI would not instlled by default.
> I think that the radical way is the good way. There are a lot of tools
> that are not suited to end-users.
> > Why to make such crazy things? Because it really marks the fact Unix
> > and Linux are different worlds so we should not accept to use/include
> > a tool just because it is the standard in Unix. The user who is used
> > to Unix and/or expects to get a Unix job can use it but we should not
> > accept it as our standard if it is not in Linux users best interest.
> > Of course this was just to test reactions, you can disagree with the
> > radical path.
> No, if as I understand the unix tools will still be present so that
> advanced users are not lost...
> > What is wrong with Unix? It is based on three hypothesis. First
> > hypothesis: The user is in a soft learning environment.
> > Unexperienced users have a teacher, can call as syadmin to solve
> > probelms and/or can ask senior colleagues. That means cryptic
> > utilities are not a problem. If you are a private user (non existent
> > in proprietary Unix due to price) but a strong opportunity for Linux
> > then you have to solve your problmes yourself from your first day so
> > cryptic utilities _are_ a problem.
> True. And a lot of linux advanced users assume that everybody can learn
> linux, and that the good way is to try, make errors and read docs... But a
> lot of people haven't time for that, nor want, nor have computerized
> cultural background.
> > Second hypothesis: The system administrator has no other tasks to do.
> > That means he has the leisure to read FAQs, HOWTOs and books for weeks
> > if needed. This is only possible if organization is big enough to
> > have a non directly productive employee. It does not work on say a
> > threee person medical cabinet. These did not exist on Unix because
> > such organizations had enough with cheaper systyems but again Linux
> > could go there but not with sendmail as the default (often unique)
> > mail server.
> I don't totally agree with you. I think there is a difference between linux
> used at home and linux used in a professional environment. In the second
> case you can have a technical support provided by a specialized society
> that does linux support (it exists some, I guess ?...). For things becoming
> complicated like a network, I think it becomes needed to have more
> knowledge of the system than an end-user (or to purchase support).
I don't say we can solve all the problems with tools and ad-hoc
software but if we keep standard tools as the only choice then we keep
out of Linux all those people who are not in the situation the tool
was designed for. As an example of what can be done yesterday there
was an announce about BSMTP: a mail server who needs only three
parms for working. It can only send messages (you fetch them with
mail reader from your ISP) but it can be very useful for people who
have more than one computer at home and/or for the medical cabinet I
The point is we cannot just keep traditional tools and tell the user
to go to a company for support because the user can lack the money or
his job can require intervntions at 3am or user can live at
> > Third hypyhesis: Unix assumes it will be used for relatively important
> > and/or mission critical tasks like web serving not for having fun,
> > Wysywyg word processing and so on. But few organuizations would have
> > allowed use of a Wysywyg word processor on Unix when it could be used
> > on the far cheaper Wintels and Macs. On Linux this is not a nonsense
> > but we need to conisder that handling fonts, printer configuration,
> > shipping of the right software for desktop and homen are not
> > unimportant problems.. I stiil have to see a distribution who does
> > not end the installtion with the user having a functional web server
> > even in betas but I have seen many who either don't configure printers
> > and/or have buggy printing subsytem and/or provide such crappy fonts
> > that use of StarOffice is a real ordeal. This low priority for the
> > desktop should no exist in Indy.
> It isn't so right in some distros where there is a desktop priority. But as
Yes there are distros like Mandrake and Suse where printing is
configured at install time. They are making steps in the right
> you noted elsewhere they are commercial with all the bad things going with.
> I think that the end-user should never have to use an xterm.
> In addition to giving priority to WYSIWYG and graphical tools, for me there
> is other important things, that are
> 1) there should be assumed that the default user's want is not to do any
> choice. For example there should be only one news reader installed (in
Sometimes it is not clear what is the best tool but I certainly want
to keep only the best.
> addition to the UNIX one). The huge problem here is the choice between kde
> and gnome, and between apps from these environments that does similar
In fact I think we can stil ship both provided there is a no-brainer
installation where we choose his environment. Perhaps later he will
decide to switch but by then he will able to make his own decisons.
> 2) there should be no bug at all in the softwares included in Indy (well by
> default, then, the user does what he wants...). For example, I think that
> abiword, although needed because it can read word docs shouldn't be used,
> as it is a pre-release, and there are some bugs that are not tolerable.
> 3) the hardwre should be better handled, especially the exotic harware,
> such as parallel port devices like zips, cd burners.... There is a lot of
> progress regarding that subject in some commercial distros, but a lot of
> things are missing.
Here I do with the resources I have.
> Also, I would like to know the hardware platform you target, because it
> changes a lot of things. What should be the minimal requirements for an
> Indy box ?
KDE 1.0 required a Pentium 75 as the real minimum. On a 486/66 it
sucked big time. Present versions of KDE and Gnome are probably
slower. So my guess is the minimal machine would be a Pentium
120. Another question is the hardware we assume since this influences
how you compile stuff. I think plain Pentium is dead so we should
assume the most frequent box is a PII or Celeron.