RE: SEUL: Stopping dreams

[Cyberdyn <cyberdyn@seul.org>]

-----BEGIN PGP SIGNED MESSAGE-----


On 16-Feb-98 jfm2@club-internet.fr wrote:
- -> 
- -> I have seen some propositions who seem to be going too far or be
- -> irrealistic.
- -> 
- -> 1) Editors: The goal is to provide the user an editor for common tasks
- -> like sending mail and news or fiwing some problems in config files.
- -> These tasks don't require a powerful editor.  They don't need much
- -> more than an editor being capable of search and replace.  Criteria are
- -> online help and intuitiveness.  In addition it would be nice if it had
- -> an X and a console mode.

I can certainly agree with this.

- -> Editors like NEDIT are _not_ what we are looking for.  NEDIT is a
- -> programmer's editor with many features who won't be used by an end
- -> user but whose sheer existence will confuse our users.  In addition
- -> NEDIT works only under X: ie cannot be used in emergencies.

I don't see this.  Nedit was originally a notepad copy.  Sure it has some added
finctionality now.  It's more like wordpad that can recognise c and header file
format.  I doubt a programmer would use it over say emacs or some other more
intensive programming editor.  I think it's programming functionality are to do
simple edits of c, header, and makefiles, not to create programs.

Nedit is a good simple program for doing simple editing.  I use it all the
time.  The problem with it is that it is linked to motif.  This makes it
non-free and non-base for SEUL.

- -> 2) Using BIOS under Linux: BIOS works in 16 bit real mode and LInux in
- -> 32 bit protected mode.  The x86 CPUs use the same op codes in 16 bit
- -> mode and in 32 bits mode but in one case it uses 16 bit addresses and
- -> in the other 32 bits.  That means than the same binary seuqnce will
- -> not produce the same results in 16 and in 32 bits mode.  About
- -> protected against real mode in real mode the base address is the
- -> contents of sement register multiplied by 16, in protected mode the
- -> segment register contains an index to one of of the segement
- -> descriptor tables.  Again the same binary sequnce will not give the
- -> same results if invoked in real or protected mode so the BIOS designed
- -> to be invoked in real mode will not work in the protected mode of
- -> Linux.

Maybe my concept of this has been wrong all these years.  I am not talking
about invoking any BIOS.  I'm talking about reading a memory location.  Wether
it be 16 or 32 bit addressing the BIOS copies it's self to a specific area in
memory.  You just dump that location to file or stdout and the manufacturer and
model etc., normally, are right there in plain text.  I did it all the time in
MSD.  It was no different than reading a binary file in MC.  Had nothing to do
with invoking the BIOS with some command.

Now I have never done anything like that in Linux.  It just seems to me that if
you *can't* access the memory location of a piece of hardware in Linux then you
just can't use that hardware in Linux.  Knowing that is not the case I have to
assume that you can access the memory locations of the hardware.  This means
that we can read the manufacturer and model for hardware from memory.  If you
are simply saying there is no software available, be it a program or driver, to
do this then it's a matter of creating it.  I'm sure it wouldn't be a very
large program.  The task is simply to take an adress as an argument and read
that address without modifying it.

- -> If it can be done from Linux it must be in VM86 mode (that is how
- -> DOSEMU work).  The DOSEMU people have experience with it but if you
- -> want to influence them so thay write a detection program the best is
- -> having something to show, for now we only have vaporware.  In addition
- -> there is no magic in the BIOS: the driver probes the address used by
- -> the peripheral is supposed to manage.  The driver came with the
- -> equipment so the DOS user can assume than if he has a Millenium,
- -> Matrox shipped the right driver and a Mystique driver.

You will have to explain to me how they can do it in Linux but it's not
possible.  dosemu and freedos simply run under Linux and emulate DOS.  Why
would the restrictions you are talking about not in force in that situation?

- -> 3) About an all XDM Linux: This would be nice however don't forget to
- -> look if that is possible in 1998.  I don't doubt there were people
- -> dreaming about croosing the Atlantic by plane in 1912 but that
- -> exceeded the capabilities of 1912's planes.

An opinion like this will make this wait until sometime after 2000.  Until the
write brothers flew for the first time people said they were crazy.  Insisted
that flight was impossible.  Sounds familiar.

- -> For now: XDM does not detect loops of death (easy to fix), but worse X
- -> does not detect if the monitor is displaying garbage or even if it is
- -> frying.  X does not support detection and automatic configuring of
- -> Plug and Play Monitors.  XDM does not allow changing color depths
- -> (some clients don't work in cerain colour depths).  In addition we are
- -> not even sure the card is supported in better than VGA mode nad even
- -> this is not sure (NVIDIA based cards don't work with the VGA 16
- -> server).

Might I draw your attention to the fact that Windows doesn't detect garbage
displays either unless it is plug-n-play.  NVIDIA cards must not be VESA
standard.  Sounds like they're about 8 - 10 years old.  New users tend to have
new equipment.

- -> So for now it is not possible to drop the user into X without having
- -> given him the opportunity to verify it works.  In additikon X and XDM
- -> don't support concepts like if immediately killed than next time start
- -> in failsafe mode.  The best we can do is: in case of unclean shutdown
- -> (like when the user hits reset due to garbled display) ask about
- -> restarting in conservative mode (640x480 low refresh rate) assuming
- -> PCI scanning reports than it is a supported card and than the server
- -> is present.

The right aproach isn't to not do it because something might go wrong.  The
right aproach is to do it because things go right the majority of the time.  We
just need to leave an out in case something does go wrong.  

You are talking about a verification proceedure that will be the same from the
console as it will be from the GUI.  I'm sure we can count on one hand the
situations in which the VGA driver won't work with specific hardware.  We put
questions about that in the installation process and thats that.

- -> I feel than it is still too soon to make XDM the default mode out of
- -> the box.  The more we can do with available software is insure the
- -> user knows how to start X manually and when convinced than it works
- -> provide him with a push-button tool for making XDM mode the default or
- -> reverting to console mode as default.

I'll tell you right now.  If we take this aproach we will loose at least half
of the users we are trying to get.  You don't seem to understand that these
people don't want to screw with their computer, they want to use it.  We are
going to loose quite a few people just because of the install process length
and complexity let alone make them play around at the console for a while
before they can use the system.

If you take a brand new Continental, grind all the paint off of it, primer it,
and offer it to somebody they'll cringe but hop in and take off because that's
all you're offering them.  Do the same thing but offer them an identicle car
with a shiney new paint job right beside the primered car and which do you
think they'll take?  Tell them the shiney one only gets half the gas mileage as
the primered one and they'll still take the shiney one.

Now look at it as SEUL being the primered car and Winblows 95 being the shiney
car that gets half the mileage.

We need to do the touch-up work to make them choose us instead of Winblows.  It
isn't a difficult task either.

- ---
E-Mail: Cyberdyn@seul.org       Date: 16-Feb-98        Time: 22:26:53
Conscious is when you are aware of something and conscience is when you
wish you weren't.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: noconv

iQCVAwUBNOkDh0rwMsuKKoVhAQElEAQAoPHtGy6gFhTaXPeco/ET0399b5W6IOry
Hi15CAx/pypUq4p/nZLTV48rTnsHqBfBpfd60ni/6nZg8ZvX8Tg8dPhFef35n6gm
1AsKL8vLb7zW/UCRHBsIjdKTJo0HOjALMEbxEg1kTZAan4qsx4r3kBTviSgLnvRP
8YyI5zoC2KU=
=+kv5
-----END PGP SIGNATURE-----