Re: [GSoC 2011]: Sysinst alternative interface

[Marc Balmer <mbalmer%NetBSD.org@localhost>]

Alexander,

> I have found the GSoC idea to rework the sysinst for a better user
> interaction very interesting and would like to discuss the possibilities
> of working on it. I have previously sent a mail to tech-install but for
> some reason it didn't reach the list and. Martin Husemann was the only
> one who contacted me because I CC'd him, we briefly discussed the idea,
> but didn't come to a conclusion and he did not reply to my further
messages.

let me elaborate why I don't like your proposal as is and why I think it
goes into the wrong direction right now.  Usability does not come from
the user interface only.  Especially in the case of a system installer,
a tool to accomplish a non-trivial task, much experiences of the OS
developers has to be put somehow into code.  Ease of use e.g. means to
provide sane defaults for disk partitioning and such.

If you want to add a graphical user interface using X11 to sysinst, you
are opening a can of worms, and I go as far as to say you will fail with
this project.  Just think of all the platforms you would have to support
to make this work.  The world is not i386 only! Plus it makes no sense
and adds no real value.  Think of embedded devices where you install
NetBSD over the serial port.  Would X help here?  Then you are making
things unnecessare complicated by providing two installers, one text
based, one graphical.  Who is going to maintain that?

sysinst as is allows for very quick installation and initial
configuration.  The downsides are the more or less static menu system
and rather unflexible flow of execution.

Rather than a graphical user interface, I would like to see in sysinst:

- A small core in C, driven by Lua, thus making sysinst extensible and
adaptable using Lua.
- The ability to install and configure software from pkgsrc
- More flexible i18n (e.g. using Lua)
- The ability to move backwards in the install process
- Unattended installs

Part of these changes (Lua, pkgsrc) we have already done at micro
systems and we plan to eventually committ these changes to NetBSD-current.

> What is the goal of the project?
> The goal is to refactor the current NetBSD installer to provide an
> X-based user interface and possibly separate installer frontend and
> backend. A bit of googling shows that effors to factor out the common
> code into a separate library was taken during previous years, namely,
> install-tool for GSoC 2008, so one step would probably be identifying
> the results achieved by previous projects. The alternative approach
> might be adding some kind of callbacks so that X installer wraps
> text-based one but it may not allow to do the fancy stuff X installers
> usually do, like turning to the previous page.
> 
> What will be the deliverables of the project?
> I expect to provide the NetBSD project with the following output:
> 1. A set of patches for the sysinst
> 2. Document the process of refactoring and write man for the new installer
> 3. New X-based and text-based installer frontends to work with the
> modified installer code
> 
> Timeline and milestones.
> 1. Community bonding period
> -> Studying current sysinst and menuc code
> -> Research ways to separate installer logic from the user interface
> -> Discussing the implementation ideas with mentor(s)
> 2. May 24 - June 23 - working on coding the installer part of the project
> -> Factoring out common code into the library
> -> Fixing text installer frontend to work with the library
> -> Writing X installer frontend

This is, imo, not doable in one month of time only.

> 3. June 25 - July 10 - preparing for mid-term evaluation
> -> Receiving review from mentor(s)
> -> Testing the code and binaries, wikifying the information on the
> project so that other members of the community can join in and test
> -> Bug/Design fixing
> 4. July 11 - August 6 - further development and integration
> -> Add/Modify installer behaviour based on the feedback I receive after
> testing
> -> Build installation CD for i386 to serve as an example of using new
> installer

A proof of concept should at least cover all tier-1 ports.

> -> Clean up makefiles, write manual pages
> -> Prepare patches for the software modified
> 5. August 7 - August 15 - preparing for the final evaluation
> -> Receiving review from mentor(s)
> -> Testing among the volunteers from the community
> -> Fixing newly discovered bugs and other issues
> 6. August 22, August 30 - submit information and code to Google as
> specified by the GSoC timeline
> 
> Here are some notes on the implementation
> 1. Separate the existing installer logic from representation
> -> Move installer code to a separate library
> -> Define the interface between the installer and user interface. For
> example, structures for passing ui <-> logic callbacks and events and
> dynamically choose one of them (this can be done via probing available
> representations via dlopen or defined at compile time)
> I do not like the proposed idea of using #ifdefs. Mainly, because
> supporting it will duplicate code and make building the installer more
> complex.
> 2. Implement installer frontends
> -> X based installer. using XCB or lightweight toolkit like fltk to make
> it consume little space on the installer cd and run with low memory
> footprint to be used on legacy and embedded systems.
> -> Reimplementing current text-only interface in case the decision to
> split backend and frontend is made.
> 3. Make UX nicer. As we're building the X-based UI, we can add wizards
> to difficult operations like partitioning and warnings to hint users of
> potentially difficult actions. This will allow the new users to adapt
> quickly. Also it could be worth adding the ability to select package
> groups for common tasks as done in Fedora Core installer or at least as
> in Debian, to allow to quickly configure the installation for a NAMP
> server or a laptop installation.  
> 
> I think that the project will be beneficial to the community because it
> will allow to bootstrap different kinds of systems faster which is
> important for a cross-plaform project like NetBSD.

How will that be faster than a text based install?
> 
> Now a few words about me. I'm currently a student of Software
> Engineering department at the russian National Research University -
> Higher School of Economics. I'm in my second year now. I enjoy learning
> new stuff about open source projects because I like to get to know how
> things work and I like hacking on *NIX stuff, especially, Linux kernel,
> and graphics (qt/gtk, opengl). I also enjoy learning different
> programming languages because they help you understand how other people
> express their ideas and what they have in mind when writing code.
> 
> Now that i'm planning to work on this project, I should tell you some
> details about my schedule. As stated in my timeline, i'll begin working
> on may the 24th, not the 23rd when the program officially starts. That's
> because I will be working on my coursework project at the university
> during spring an will be presenting it at the university on the 23rd.
> Also please note that I may have to miss 3-4 days at the end of June,
> because I will be having exams on that date, and a week in August
> because I may be going on a vacation, but if that happens, I will warn
> my mentor(s) at least two weeks in advance.
> 
> Some of the recent projects I have been working on are connected with
> reverse-engineering embedded devices and I'm currently involved in the
> XDANDROID project (http://xdandroid.com/). My personal contributions
> include reverse-engineering several drivers (led/pwm, usb phy power
> control, camera sensor), porting code to the new codebase (from kernel
> 2.6.27 to 2.6.35) and porting the open-source bootloader LK to allow
> booting off internal memory
> (http://htc-linux.org/wiki/index.php?title=LK_Bootloader). I was
> previously involved in upgrading the linux project for FSC Loox 720 PDA.
> My personal project was porting Linux to Asus P525 PDA (status page is
> http://www.kaa.org.ua/asus-p525/hardware-asus-p525.html). So, you can
> see that I mostly work with low level stuff and have some experience at
> bootstrapping system, but I also like to explore anything new... except
> web programming...
> 
> As for my experience with NetBSD, it is not very long. I have been using
> it on my secondary PC for about a year. Unfortunately I have not been
> into any kind of development here, but I am willing to get involved.
> When setting up my box, I have compiled most of the software from
> sources. I have also used the Gentoo distribution before and have
> recompiled the kernel in FreeBSD, if this is relevant at all. I have not
> yet created any package for pkgsrc, but I have built a debian package
> together with my friend Oleg Kravchenko for his printer driver, which is
> available at his site - http://www.kaa.org.ua/ubuntu/).
> 
> As for my experience with X, I can tell that I have only played around
> with raw X widgets, but I have experience with Qt4 and GTK (also
> GTKSharp, used it for my coursework project last year) and have
> programmed UI in Microsoft WinAPI, so I understand how event processing
> and ui building works and think that adapting to XCB/XLib won't take
> much time.
> 
> Sorry for such a long and late letter, but I am willing to hear your
> response.

I think the main problem with your project idea is focus:  It is much to
wide.  sysinst should be evolved in small steps, not by putting a
gigantic user interface overhead on top of it.  E.g. a narrower focus
could be:

GSoC 2011:  Lua-fy sysinst to drive the sysinst logic from a scrip langauge

GSoC 2012: Make sysinst package aware

GSoC 2013: Provide a GUI using Lua?

My 2 cents,
Marc