Boot process and user experience was Re: mid-week progress Jan 14th

[David Farning]

On Fri, Jan 15, 2010 at 5:40 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Fri, Jan 15, 2010 at 11:59,  <dfarning at gmail.com> wrote:
>> Having a pretty good week.
>>
>> We now have an ubuntu-sugar-remix package at
>> https://launchpad.net/~dfarning/+archive/ppa/+packages .
>>
>> This is cool for two reasons; 1.  End users can install the
>> ubuntu-sugar-remix package and get the complete ubuntu-sugar-remix
>> experience and 2. Developers build and maintain ubuntu-sugar-remix with the
>> same tools and procedures as other ubuntu products.  No more dirty hacks.
>>
>> Goals by Mondays release.
>> 1. Figure out how set the sugar xsession to open by default;  USR is dual
>> desktop, sugar and gnome, but it would be good to boot to sugar.
>
> Is USR running gdm? What's the intended experience during startup, the
> same as in SoaS?

Hey Tomeu,

It is always good to have upstream stop in and visit.

When taking about the the logon part of the user experience it helps
to have some back-ground on how distributions are built and delivered.
 We are are looking at three basic delivery methods for Ubuntu Sugar
Remix; normal install, live, and live with persistence.  Some very
general definitions:

1. Normal install - this is generally what you get when you install to
your hard drive.
2. Live distribution - this is generally what you get when you you
boot a distro from a CD for testing purposes.
3. Live with persistence - this is the basic concept behind SoaS -
boots from a usb memory device yet has the ability to store data.

==The basics of booting==
When thinking about booting there are four key parts.  Please note,
this is very hand wavey, but it is enough to get someone going:)

1. Kernel - We all know what that is.
2. Filesystem - This is nothing more complicated than the stuff the
sits in your root dir "/".
3. initrd - This is your INITial RamDrive.  It is a very simple
filesystem that the kernel talks to while booting
4. Boot loader - This helps get things going by directing traffic
before the kernel takes over.

Now, we take a look at the differences between a normal install and a
live install.  These differences are; what we know and when we know
it, and the storage medium.

1.  What we know and when we know it.
1a.  Historically, a computer needed to know about the system hardware
prior to boot.  Hot-plugging is blurring this, but for the most part,
we can assume that in a normal install the kernel and initrd know
about the hardware  and have the necessary drivers pre-built.
1b. In a live environment we can make no assumption about what
hardware will be available.  From one boot to another, the stick can
be moved from computer to computer.
2. Medium
2a. A normal install the file system is stored on a large read/write
medium such as a hard drive.
2b. Historically, live distros have been delivered space limited read only cds.
2c. Live - with - persistence is usually made by combining the read
only filesystem that are inclued with cd based live distro with a
second read/write partation.

Distributors use two techniques for dealing with these differences;
the bootloader and how they build the kernel and initrd.
1. Boot loader
1a. Normal installs use 'grub' whiyich is very fast an optimised for
traditional installations.
2b. Live installs tend to use 'casper.'  Casper brings two things,
hooks to handle new and unexpected hardware and the ability to to work
with readonly filesystems.
2. Kernel.
2a. Normal kernels tend to be smaller and optimized for an expected
set of hardware.
2b. Live kernels tend to be big and include a bunch of driver and
modules to handle unexpected hardware situations..

==Current Technology==
When looking at booting solutions it helps to have a picture of past
and current technology.  Grub is simple and well understood.  Casper
is where all of the cool stuff is happening.
1. File systems - By default casper uses a read only squashed file
system.  Casper was designed use on CDs. -- The upstream casper and
debian projects are looking are using alternate file systems for use
with usb memory stick and portable usb hard drives.
2.  Hardware detection.  Casper and related project are making good
progress handling different types of hardware.

==Design Decisions==
The above has lead me to a couple of design designs for Ubuntu Sugar Remix.
1.  Where ever possible reuse existing debian and ubuntu packages and
build processes.
2. Use casper for live and live-with-persistence installs.  My
experience has shown that squashfs is not optimal for usb memory stick
install, but log term we are better sticking with casper and
encouraging people interested in usb file systems to work upstream.

== What this means for USR developers ==
The only difference between a normal install and a live install is:
Normal installs use
   "apt-get install ubuntu-sugar-remix"
while live installs use
  "apt-get install ubuntu-sugar-remix casper"

== What this means for users ==
Live system boots are going to be inherently slower as casper goes
through hardware detection process.  Otherwise, the user experience is
exactly the same regardless of the delivery method.

==User experience==
Finally, we get to user experience.  I think OLPC got a lot right with
the 1.5:)  By default, the first screen an end user see is the 'sugar'
enter name.  A control panel extension lets a user switch from sugar
to gnome and a gnome desktop icon lets a user switch from gnome back
to Sugar.

Normal installs work the way you would expect them to work.  The user
(or more likely the classroom admin) can select if students all use
the same account (via auto login) or use the gnome user login
facilities to select different users.

Live installs bypass the gnome login screen and drop the user straight
to the 'sugar enter name' screen.  Every time they reboot they will
need to re-enter their name.

Live-with-persistence.  I am thinking that using a USB stick
containing Sugar with persistence is 'owned' by and individual thus,
the first time they use a stick, they will be asked for their name.
Future log ins will go directly to that users home view.

==Caveats==
Weekly releases will show the ugly "do you want to use sugar...."
boot screens they are pretty usefull for testing purpose.  Production
releases will skip that screen to avoid confusion and the chance that
a student overwrites their parents hard drive.  Teachers and admins
will still be able to press DEL or F1 to get to the boot screen if
they want to install sugar to their hard drive.


==ToDo==
We need to look at what OLPC is doing to switch back and forth between
Sugar and Gnome.

david

>> 2.  Test and move the packages from my ppa to the sugar team PPA and
>> document how to install from the sugar team pppa.
>> 3.  Create a Sugar-activities package which preseeds a collection of
>> packages from ASLO.  This packages will need to flexible and probably
>> temporary as Jonas figures out a good compromise for packaging activities
>> and their common dependencies upstream.
>> 4. Stub out Sugar-ubuntu-remix-default-configuration as a meta package to
>> set gnome and system defaults the correct way rather than sed and other ugly
>> bash tricks.
>>
>> Apologies for the terrible communications. We have an ubuntu feature freeze
>> deadline coming up in mid-February.  I am in a sprint to get things useful
>> enough that a experienced ubuntu developer will be interested in helping us
>> herd our stuff into universe....
>>
>> Ubuntu Sugarteam
>> On the nerdy side of things, I upgraded my workstation to 8G of memory and a
>> quad core processor.  It has cut the time to build an USR ISO down by an
>> order of magnitude.
>> --
>> Ubuntu-sugarteam mailing list
>> Ubuntu-sugarteam at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-sugarteam
>>
>>
>
>
>
> --
> «Sugar Labs is anyone who participates in improving and using Sugar.
> What Sugar Labs does is determined by the participants.» - David
> Farning
>