Re: Whats with this new Debian installer?
On Mon, Aug 09, 2004 at 10:53:27AM +0800, John Summerfield wrote:
> Thomas Adam wrote:
>
> >On Mon, Aug 09, 2004 at 09:46:55AM +0800, John Summerfield wrote:
> >
> >
> >
> >>In the past week I've done two GUI installs. Both were easier than d-i.
> >>
> >>
> >
> >"easier".
> >
> >
> >
>
> Easier translates to easier, quicker. All the same benefits one gets
> from a GUI desktop can be realised in an installer too.
>
>
>
> >>The only thing against GUI installers is the amount of RAM they require.
> >>However, for new machines that's completely unimportant.
> >>
> >>
> >
> >That is not the point. A non-GUI install means that you don't need
> >to ship with X *just* to install the damn distribution. Using X as a
> >means to install only increases the level of complexity and this
> >likelyhood of something going wrong.
> >
> >
>
You can also always use DirectFB for the installer which is much lighter
then shipping the whole of X, both on memory and disk space. Take a look
at qingy, a gui replacement for getty. IIRC it uses almost the same
amount of memory as getty (<RANT>if it would only log in for me when
started from init and not only the command line, that would be
nice</RANT>)
> With Anaconda, use of the GUI is optional. I'm sure it is with SuSE too,
> but it came sans documentation.
>
> Besides, Debian ships with X anyway,
>
Yes, but you need it installed on the installation file system to use
it, not only packaged, not to mansion some minimal auto-detection of
video/keyboard/mouse (not optimal settings, but working ones at least).
>
> People often assert that increasing complexity increases the probability
> of errors and unreliability, but in fact this is not always the case. I
> used to be a systems programmer for MVS systems, back when IBM's finest
> ran to 16 Mbytes of RAM. A good deal of the complexity of MVS back then
> went into prevention of problems such as one job monopolising the CPU
> (or other resources) and generally making sure everyone got a fair go,
> and from code to recover from errors when they did occur.
>
> There were very few hardware or user errors that could actually take the
> system down.
>
> For example, if there was a read error on a tape, it
> a) Notices
> b) Retried some number of times by backspacing and retrying.
> c) Rewinding, spacing back to the same position and retrying some number
> of times.
>
> In contrast, a Wang 720C (I think that was the model number) whci was
> about equivalent to a peecee in that time ignored read errors on its
> tapes. Whoops.
>
>
> >With a curses or similar installer, Ok, you don't have clickie
> >things but big deal. Who cares? They're usable, intuitive and don't
> >require lots of RAM to install. It just means that you have to use
> >the keyboard more often.
> >
> >
>
> I had "clickie things" in DOS. I used to use Turbo Pascal and the mouse
> worked very wll then. Didn't need much RAM either, _my_ peecee was
> enormous two megabytes of RAM. Can you beleive it!!
>
> Of course, DOS only used 640K.
>
Actually playing with the mouse interrupts to get a mouse support was
kind of fun and writing directly to the video memory of the cga and ega
for graphics also (although the highmem issues were a bit of a pain).
Only pressing the turbo button in the middle of a game of digger would
throw things really of pace ;-)
>
> --
>
> Cheers
> John
>
> -- spambait
> 1aaaaaaa@computerdatasafe.com.au Z1aaaaaaa@computerdatasafe.com.au
> Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
Reply to: