Re: points on future installation disks development

[Andy Mortimer]

On Jun 9, Sven Rudolph wrote
> 
> My ideas on boot-floppies' future:
> 
> - rewrite dinstall in C - reasons:
>   - runtime improvements
> - don't run fdisk -l that often
>   - todo: make a libsfdisk from sfdisk
> - more complex datastructures (avoid using sed often)
>   - more complex input masks and consistent user interface
> - network configuration: everything in one screen
> - selecting base directory in one screen
> - use :
>   - ncurses and libdialog (from FreeBSD), or
>   - slang (ncurses shouldn't be needed then, slang is said to have
> a curses emulation), or
>   - turbovision (licence OK?), or
>   - something else (suggestions welcome)

Please check out my Giggle library, which can currently be found at
, but will be moving in
just under a fortnight[1].

It is currently under development, but is basically designed as a
flexible interactive information gathering library (as distinct from UI
library, which is much more general). There is currently only one module
for it, which uses S-Lang and gives a `dialog'-like feel to the
interface, except it seems to be (mostly) quite a lot faster; I have also
written a basic dialog command-line clone, which seems to work fairly
well.

Advantages for this application are:
 * Interfaces (IMO :) very easily to C code.
 * Would be able to provide alternative modules for different purposes
   (such as a simpler one for a brail interface?), with no recoding. This
   also makes the provision of an X-based install much more reasonable
   (although IIRC dinstall won't still be running by then?)
 * Designed for reasonably easy i18n (some details still to be worked
   out, and then I planned to ask the Debian teams to look at it).

As well as some things like context-sensitive help which would probably
be quite nice. ;)

Having (finally!) finished my exams, I'm just converting all my source
trees to CVS, and then I shall go back to work on it, and hope to have a
usable set of libraries within the next few weeks; it's certainly OK if
you're relatively clued up ATM, but it's not polished enough to join the
distribution! I'm very keen to add new modules etc, and for other people
to do the same (any X programmers? ;), and a couple of the features which
you've listed below could be done with alternative modules:

> - new features
>   - installation via serial terminal
> - for blind users
I have no idea how brail terminals work, but this should be possible.

> - for automated testing
A `response file' has been planned for a while, which would allow this
sort of thing.

> - use lilo in order to drive the serial line early (or modify syslinux ?)
>   (what about GRUB ?)
>   - an extra command-mode installation ?
>   - installing base via ftp and smbfs (and from tape ?)
>   - mouse support ? (gpm, or derived from gpm)
This should go into the slang method at some point.

Although its normal mode of operation is to dynamically load modules, it
would be fairly painless to make a statically linked version (a metter of
a couple of defines, in fact), which would also remove the need for libdb
etc.

[snip]

> Related topic: I expect to have much less time for Debian for the
> remainder of this year. So I definitely need help here; especially for
> the UI part.

I don't know much about UIs in general, but I'd be more than happy to
help (read `do most of the coding' :) if you ended up using Giggle. I'm
quite happy to help in any case, of course, but I know more about Giggle!

Cheers,

&E

[1] I don't yet know where. :(
-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
I open my eyes, and look at the floor,
And now I don't see you anymore.


pgpXOXhUDeTjo.pgp
Description: PGP signature

Re: points on future installation disks development

[Bdale Garbee]

In article <[EMAIL PROTECTED]> you wrote:

: - new features
:   - installation via serial terminal

An additional reason to do this is that non-PC platforms (Sparc, Alpha, HP
coming eventuall...) often run "headless" with onl a serial console and a
network interface for servers.  Getting it right in general would help with
porting to these other platforms.

Bdale


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Vincent Renardias]

On 9 Jun 1997, Sven Rudolph wrote:

> (Please check whether you answer really belongs to both mailing lists.)
> 
> My ideas on boot-floppies' future:
(plenty of good stuff deleted ;)

I would add an additional idea:

* separate the "install" session from the "configuration" session.
IMHO a system install should be done by asking almost no question (except 
HD partitioning, and install media) in 10 minutes. All the configuration 
questions should IMHO be asked AFTER the installation.

Just think about it: consider Windows95, OS/2, AIX, MacOS, Linux.
Linux is the only one to ask "what's your DNS IP addr?, etc..." in the middle
of the installation.

The changes from the current floppy set would require to remove most 
questions from the install procedure, and after the first reboot say "Do 
you want to customize your system now?" before to start dselect.

The avantage may sound very slight, but after talking with newbie linux 
users who have made a Debian install alone, almost all of them suggested 
this kind of change.

NB: I'm willing to help making those changes if everyone agree.

Cordialement,

--
- ** Linux ** +---+ ** WAW ** -
-  [EMAIL PROTECTED] | RENARDIAS Vincent |  [EMAIL PROTECTED]  -
-  Debian/GNU Linux   +---+  http://www.waw.com/  -
-  http://www.debian.org/   |WAW  (33) 4 91 81 21 45  -
---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Andreas Jellinghaus]

On Jun 9, Sven Rudolph wrote
>   - slang (ncurses shouldn't be needed then, slang is said to have
> a curses emulation), or

slang's curses emulation is not complete, as far as i can say (i tried
to compile some programs with slcurses), and it has no panel/menu/form
emulation (the 3 little libs included in ncurses).

regards, andreas


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble? 
e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Mark Baker]

In article <[EMAIL PROTECTED]>,
Vincent Renardias <[EMAIL PROTECTED]> writes:

> Just think about it: consider Windows95, OS/2, AIX, MacOS, Linux.
> Linux is the only one to ask "what's your DNS IP addr?, etc..." in the middle
> of the installation.

Possibly because linux is the only one that supports install by NFS or ftp?
It's a bit difficult to do that without doing the network configuration
first.

Re: points on future installation disks development

[Sven Rudolph]

Andy Mortimer <[EMAIL PROTECTED]> writes:

> [1  ]
> On Jun 9, Sven Rudolph wrote
> > 
> > My ideas on boot-floppies' future:
> > 
> > - rewrite dinstall in C - reasons:
> >   - runtime improvements
> > - don't run fdisk -l that often
> >   - todo: make a libsfdisk from sfdisk
> > - more complex datastructures (avoid using sed often)
> >   - more complex input masks and consistent user interface
> > - network configuration: everything in one screen
> > - selecting base directory in one screen
> > - use :
> >   - ncurses and libdialog (from FreeBSD), or
> >   - slang (ncurses shouldn't be needed then, slang is said to have
> > a curses emulation), or
> >   - turbovision (licence OK?), or
> >   - something else (suggestions welcome)
> 
> Please check out my Giggle library, which can currently be found at
> , but will be moving in
> just under a fortnight[1].

In general this sounds to be useful.

> It is currently under development, but is basically designed as a
> flexible interactive information gathering library (as distinct from UI
> library, which is much more general). There is currently only one module
> for it, which uses S-Lang and gives a `dialog'-like feel to the
> interface, except it seems to be (mostly) quite a lot faster; I have also
> written a basic dialog command-line clone, which seems to work fairly
> well.
> 
> Advantages for this application are:
>  * Interfaces (IMO :) very easily to C code.
>  * Would be able to provide alternative modules for different purposes
>(such as a simpler one for a brail interface?), with no recoding. This
>also makes the provision of an X-based install much more reasonable
>(although IIRC dinstall won't still be running by then?)

For the boot-floppies purpose we won't need any X interface. The only
needed alternative interfaces is simple command-line (like a terminal
without direct cursor addressing). giggle could try to support this,
e.g. by converting a message box into a text line and "Preass Enter to
continue" or by converting a list box into a list with numbered
entries.

> As well as some things like context-sensitive help which would probably
> be quite nice. ;)

Right; I added this to the list.

> Having (finally!) finished my exams, I'm just converting all my source
> trees to CVS, and then I shall go back to work on it, and hope to have a
> usable set of libraries within the next few weeks; it's certainly OK if
> you're relatively clued up ATM, but it's not polished enough to join the
> distribution! I'm very keen to add new modules etc, and for other people
> to do the same (any X programmers? ;), and a couple of the features which
> you've listed below could be done with alternative modules:
> 
> > - new features
> >   - installation via serial terminal
> > - for blind users
> I have no idea how brail terminals work, but this should be possible.

One person contacted me on this, he simply wanted to control the
Debian installation from his preconfigured (second) PC which can act
as a serial terminal.

So it is sufficient to redirect the console to a serial port.

But as I gathered direct cursor addressing and all the pseudo-graphics
stuff can get confusing for blind people, so an extra command-line
mode without any direct cursor addressing were useful.  (A Braille
display usually shows only one line, so one has to navigate through
all lines in order to find where something changed.)

> Although its normal mode of operation is to dynamically load modules, it
> would be fairly painless to make a statically linked version (a metter of
> a couple of defines, in fact), which would also remove the need for libdb
> etc.

Right. I didn't stress that we have strict disk space
requirements. But replacing ncurses with slang should give us some
room.

> I don't know much about UIs in general, but I'd be more than happy to
> help (read `do most of the coding' :) if you ended up using Giggle. I'm
> quite happy to help in any case, of course, but I know more about Giggle!

This is a good argument for giggle.

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Sven Rudolph]

Vincent Renardias <[EMAIL PROTECTED]> writes:

> * separate the "install" session from the "configuration" session.
> IMHO a system install should be done by asking almost no question (except 
> HD partitioning, and install media) in 10 minutes. All the configuration 
> questions should IMHO be asked AFTER the installation.
> 
> Just think about it: consider Windows95, OS/2, AIX, MacOS, Linux.
> Linux is the only one to ask "what's your DNS IP addr?, etc..." in the middle
> of the installation.

As mentioned before this is necessary when you decide to install base
via NFS. And I plan to extend this to smbfs and ftp, so this might be
used even more often.

> The changes from the current floppy set would require to remove most 
> questions from the install procedure, and after the first reboot say "Do 
> you want to customize your system now?" before to start dselect.

We should provide a program that does all the customizations done by
dinstall later.

> The avantage may sound very slight, but after talking with newbie linux 
> users who have made a Debian install alone, almost all of them suggested 
> this kind of change.

NFS install is more common in professional environments ;-)

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Andy Mortimer]

On Jun 9, Sven Rudolph wrote
> 
> Andy Mortimer <[EMAIL PROTECTED]> writes:
> 
> > On Jun 9, Sven Rudolph wrote
> > > 
> > > My ideas on boot-floppies' future:
> > > 
> > > - rewrite dinstall in C - reasons:
[snip]
> > >   - more complex input masks and consistent user interface
[snip]
> > Please check out my Giggle library, which can currently be found at
> > , but will be moving in
> > just under a fortnight[1].
> 
> In general this sounds to be useful.
> 
> >  * Would be able to provide alternative modules for different purposes
> >(such as a simpler one for a brail interface?), with no recoding. This
> >also makes the provision of an X-based install much more reasonable
> >(although IIRC dinstall won't still be running by then?)
> 
> For the boot-floppies purpose we won't need any X interface.

And there was I thinking X would go on the boot floppies. ;) I'm not sure
that this is such an issue for dinstall, but depending on how it gets
split up, some packages (modconf was the example I had in mind) would
benefit from a `native' X-based display.

> The only needed alternative interfaces is simple command-line (like a
> terminal without direct cursor addressing). giggle could try to support
> this, e.g. by converting a message box into a text line and "Preass
> Enter to continue" or by converting a list box into a list with
> numbered entries.

And in fact it did at one stage -- I wrote it as part of the
testing/debugging -- but it wasn't very pretty at all, because I wanted
to get the S-Lang one working. But yes, this is certainly possible.

> > I have no idea how brail terminals work, but this should be possible.
>
> But as I gathered direct cursor addressing and all the pseudo-graphics
> stuff can get confusing for blind people, so an extra command-line
> mode without any direct cursor addressing were useful.  (A Braille
> display usually shows only one line, so one has to navigate through
> all lines in order to find where something changed.)

Even stronger: a mode which limits itself to as few lines as possible
(for example, menus across the screen rather than down) would be useful
for blind people? Even if we don't use direct cursor addressing, nicer
layout can still be achieved by spacing everything out nicely.

> > Although its normal mode of operation is to dynamically load modules, it
> > would be fairly painless to make a statically linked version (a metter of
> > a couple of defines, in fact), which would also remove the need for libdb
> > etc.
> 
> Right. I didn't stress that we have strict disk space
> requirements. But replacing ncurses with slang should give us some
> room.

Assuming nothing else -- like cfdisk -- uses ncurses, of course ...

> > I don't know much about UIs in general, but I'd be more than happy to
> > help (read `do most of the coding' :) if you ended up using Giggle. I'm
> > quite happy to help in any case, of course, but I know more about Giggle!
> 
> This is a good argument for giggle.

:-)

&E

-- 
Andy Mortimer, [EMAIL PROTECTED]
http://www.poboxes.com/andy.mortimer
PGP public key available on key servers
--
I sing of you in my demented songs.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Sven Rudolph]

Andy Mortimer <[EMAIL PROTECTED]> writes:

> > >  * Would be able to provide alternative modules for different purposes
> > >(such as a simpler one for a brail interface?), with no recoding. This
> > >also makes the provision of an X-based install much more reasonable
> > >(although IIRC dinstall won't still be running by then?)
> > 
> > For the boot-floppies purpose we won't need any X interface.
> 
> And there was I thinking X would go on the boot floppies. ;) I'm not sure
> that this is such an issue for dinstall, but depending on how it gets
> split up, some packages (modconf was the example I had in mind) would
> benefit from a `native' X-based display.

For modconf you are right. modconf needs a rewrite (probably in C)
anyway because it is too slow.

> > > Although its normal mode of operation is to dynamically load modules, it
> > > would be fairly painless to make a statically linked version (a metter of
> > > a couple of defines, in fact), which would also remove the need for libdb
> > > etc.
> > 
> > Right. I didn't stress that we have strict disk space
> > requirements. But replacing ncurses with slang should give us some
> > room.
> 
> Assuming nothing else -- like cfdisk -- uses ncurses, of course ...

Currently we have a lowmem root and a normal root. On the lowmem root
fdisk is used instead of cfdisk. And Andries Brouwer's sfdisk still 
doesn't have a curses-like frontend, so this might make another
project ...

Sven
-- 
Sven Rudolph <[EMAIL PROTECTED]> ; WWW : http://www.sax.de/~sr1/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Bruce Perens]

Andy Mortimer:
> - rewrite dinstall in C:

First of all, I want to thank you for your work on "giggle", and on the
dialog emulation using "giggle". I think this is just the thing we need
for many configuration tasks on Debian.

I was thinking of using S-lang for the installation scripts. For the people
not familiar with S-lang, it's a small interpretive stack-oriented language
that manages to have C-like syntax and has its own cursor-handling library,
and you can easily export C functions to it. Size-reduction is even more
important than speed, and S-lang might let us have both. However, note that
we can currently export any amount of C code to "ash" using "busybox" (in the
boot-floppies package).

>   - todo: make a libsfdisk from sfdisk

There is an fdisk 3 that was designed to be machine-callable.
Its author seems to have let it sit for about a year.

>   - turbovision (licence OK?), or

I think the license is less than acceptable at the moment.

From: Sven Rudolph <[EMAIL PROTECTED]>
> direct cursor addressing and all the pseudo-graphics
> stuff can get confusing for blind people

If you do something for blind people, you can do two levels of support.
Nikhil Nair <[EMAIL PROTECTED]> uses a blind person's screen reader,
which allows him to read and respond to character screens that use cursor
addressing. He has a small Braille "window" that he can roam over the screen.
I think he has highlights and text attributes in a separate "screen" from
text, accessable with an alt-button, but they may well be slower to use.
Then there is speech. It happens that some blind users have less-than-perfect
finger sensitivity and prefer speech. The one I knew was an electronics
enthusiast, and I think his soldering technique might have had something to
do with his impaired finger sensitivity. I have a circa-1986 serial DECTalk
to test speech output on.

Thanks

Bruce
-- 
Bruce Perens K6BP   [EMAIL PROTECTED]   510-215-3502
Finger [EMAIL PROTECTED] for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6  1F 89 6A 76 95 24 87 B3 


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: points on future installation disks development

[Tom Lees]

On 9 Jun 1997, Sven Rudolph wrote:

> My ideas on boot-floppies' future:
> 
> - rewrite dinstall in C - reasons:
>   - runtime improvements
> - don't run fdisk -l that often
>   - todo: make a libsfdisk from sfdisk
> - more complex datastructures (avoid using sed often)
>   - more complex input masks and consistent user interface
> - network configuration: everything in one screen

Can we add at some point a BOOTP/DHCP option to the network configuration,
to do it all automagically? This would be nice.

> - selecting base directory in one screen
> - use :
>   - ncurses and libdialog (from FreeBSD), or

ncurses may have licensing problems.

>   - slang (ncurses shouldn't be needed then, slang is said to have
> a curses emulation), or

Well, SLang does have a distinct set of programming advantages. However,
we'll need a libslang-pic package in this case. Yes, it does have a curses
emulation, but it's much better to use it in native mode.

>   - turbovision (licence OK?), or
>   - something else (suggestions welcome)



>   - easier i18n (see below)
> 
> - new features
>   - installation via serial terminal

Hmmm... nice idea. How about installation over a network, i.e. system
boots up, BOOTPs (or whatever) for IP info, then SysAdmin can telnet in
from a workstation to set it up.

> - for blind users
> - for automated testing

Impressive. Are we going to do this ever?

> - use lilo in order to drive the serial line early (or modify syslinux ?)
>   (what about GRUB ?)

Modifying SysLinux is a nice option. Although I do have TASM, and so can
modify the sources, does anyone know how well NASM (which we have in the
distribution, I notice) can handle these files?

>   - an extra command-mode installation ?

i.e. SysAdmin sticks a special-custom disk into a workstation, and comes
back later, and it is running a fully installed Debian? A lot of people
have expressed interest in this.

>   - installing base via ftp and smbfs (and from tape ?)

SMBFS is just another FS, easy enough to do. Also, we should add in
NCPFS (from NetWare server) there, probably. I had a thought about FTP and
- we could use wget. This would also enable us to use HTTP. The version on
my system is 88K, but I'm sure this can be reduced if we kick out some of 
the functionality (like all the intelligent stuff).

>   - mouse support ? (gpm, or derived from gpm)

Have a look at kmouse if you want an alternative to gpm. So far, this is
looking really good, but it doesn't yet support the variety of mice that
gpm does. I have some patches to make it run on 2.1 kernels, which I will 
be sending to the author pretty soon.

However, gpm is only 33K, plus libgpm at 109K (required for both gpm or
kmouse) would take up around 140K.

> - i18n plan
>   - i18n for C files: use GNUish standard method ? (is this gettext ?)

Yes, this is gettext.

>   - i18n for shell scripts (swapsetup) (is there a good way for doing this) 
> or rewrite them in C

Use the "gettext" command-line utility. Unfortunately, there seems to be
no documentation for it, but it is pretty simple to use. The gettext
command-line utility is, however, 17K, which could make it worth
rewriting nearly everything in C.

>   - i18n for busybox (is it worth the work and disk space ?)

Some of the more major parts of busybox (like ls) may be worth i18n.
However, I wouldn't do all of it.

>   - try to keep i18n and localization separated
> - how many locale data sets will fit on floppy root.bin ?

Autodetection of a CD-ROM can happen very early in the boot process, then
at least we can put all of the locale data sets in, e.g. /l10n on the
CD-ROM.

> - bigger root.bin for loadlin booting

This may be a problem for low-memory systems, though.

> - for floppies: make extra locale file that can be copied to Rescue Disk

Or, seeing as at least one of the floppies is a DOS disk, why not create
"locale data packs". Each one would have the appropriate locale and
translation info for one locale, and this could be copied onto that DOS
disk.

>   - assign versions to original and translated text in order to keep
> them in sync (and automatically find out when they aren't)

GetText can pretty much work this out itself, actually.

> 
> - localization
>   - translate text files

Which text files do we actually have ATM?

>   - translations for the i18n'ed parts

> - minors
>   - better 'make bootable': MBR isn't that self-explaining

I think we ought to also at least have the option of not using MBR. I for
one don't like it, and use LILO instead. Others I know use OS/2 Boot
Manager.

We should also have an option to install all the appropriate LoadLin
stuff into a DOS partition, and set it up properly.

> Related topic: I expect to have much less time for Debian for the
> remainder of this year. So I definitely need help here; especially for
> the UI part.

I will be willing to help.

-- 
Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECT