Re: SEUL: Stopping dreams

[jfm2@club-internet.fr]

> 
> -----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.
> 

In part it was a general remark: an end user does not need a highly
sophisticated editor: the more features it has the heavier it is and
the easiest its very "richness" ends confusing the user.

NEDIT is qualified as a programmer's editor I don't remember if in its
doc or in an article in the LJ.  Of course some programmer's editors
are easier than others.  Another problem with NEDIT is than we would
have to ship a version statically linked against Motif.  That makes a
heavy editor just for composing mail.  (I am composing this with Gnu
Emacs :-).

> - -> 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.
> 

If you want to read the memory range with real addresses between 640K
and 1 Meg it is very easy: use "dd" on /proc/kcore.  The problem is
than you will extract little info from it.

If you want to _execute_ BIOS calls then I told you why it doesn't
work.  The only way is VM86 mode: in this mode the processor will be
acting like if it were in real 16 bits mode (that is how DOSEMU works)
but the program is caged in a 1M "box" like it it were on an ultrafast
8086 and access to the hardware is reported through the Linux kernel
to the process controlling this box.  Like I said the people who know
the more about BIOS and VM86 are the DOSEMU people and better have a
working distribution to get their attention.


> 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?
> 

They use VM86 mode and DOSEMU traps IO and asks the Linux kernel to do
it.  DOSEMU is in fact a BIOS emulator: the program asks DOS, DOS asks
BIOS and the IO is trapped to DOSEMU.

> - -> 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.
> 

The problem is than we are not at the stage were technology allows an
all XDM mode.

Planes ended crossing the Atlantic but in 1912 the sensible thing was
to take a passage on the "Titanic": at least you had 1 chance in three
of surviving.  :-) Planes were barely able to cross the channel between
France and England (first crossing was 1910).

> - -> 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.
>

NVIDIA is one of the hottest and fastest chips at this time.  In fact
AFAIK few PCI cards use it, mostly used in AGP cards.  And it does
_not_ work with the VGA seerver in XFree 3.3.1.
 
> - -> 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.  
> 

The goal of Simple End User Linux can be reached only through X.  If
the user has not a supported card (and I am not referring to VGA mode)
then it is hopeless.  But embarking in an all XDM is something to
forget about until you have a method to give the user a way out and a
method to change the ColourDeptrh on the fly (for the cases where the
user is confronted to a program unhappy with the default colordepth).

About garbled displays, monitors on the verge of frying or loops of
death the sensible thing for the user is to jump on the reset button.
This makes easy to detect than the shutdown was unclean and ask the
user about what he wants (console, safe mode (640x480 with normal
server), ultrasafe (VGA) or normal mode).

That leaves us with the (easy) problem of colr depth.

About VGA mode you told than it could open apetites for Linux better
than console.  I have used VGA mode when I had a Mystique (I knew it
was not supported but the box was cheap enough for me buying another
card, the manufactuer only shipped Mystiques).  VGA mode is horribly
sloooow, fearsomelessly ugly and above all many times you only get
320x200 (even if for some cards you can be lucky and get 800x600
generally by first booting DOS).  With 16 colors you will obviously
not be playing with the GIMP.  Its slowness makes impossible to play
at any "moving" game even xbill or xjewel and aboot xdoom...  And the
last is than X apps are not designed for low res (Win 3 is more frugal
with screen real state).  After a week of using X in VGA mode you will
ask to be sent to Alcatraz instead of continuing to use it).

And I certainly prefer console mode to VGA.

> 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.
> 

The problem is not the number of cards but the number of people using
them: at one time about every clone manufacturer shipped his computers
with Mystiques due to its low cost and good performance.

Same thing could happen with NVIDIAs or the chip most used the day
SEUl is relrased?

> - -> 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.
> 

Go to the news groups and count the messages "Help X doesn't work!".
I do not want console mode, just than for now we can't assume
everything will work first try so we must provide the user with a fall
back solution until X works.

PCs are not Suns.  Sun know what video cards are on the computers it
manufactures so the Sun-made X works first try.  And Sun can make XDM
the default.

> 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.
> 

If you look at previous postings you will see I have ever been
advocating for beauty in Linux as a way for giving a professional
feeling (Xaw3d instead of Xaw, nicer toolkits) and batlling "virile"
hackers than said it was a minor consideration.

The problem is: We must provide a fall-back until X becomes a thing
who will work 100% of the time.  Notice than I suggested one (see
above).  I also consider absurd people who say we should consider
people not wanting X: these are not our public and 4 meg boxes are no
longer in production.

-- 
			Jean Francois Martinez

"For drinking muddy water if that is the water of truth,
            for that the camel is needed"