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 > [EMAIL PROTECTED] [EMAIL PROTECTED] > Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
