Edubuntu: some observations.......contd

[Matt Zimmerman]

On Fri, Jan 13, 2006 at 04:08:39PM +1100, Dan McGarry wrote:
> Matt Zimmerman wrote:
> >You explicitly told aptitude to upgrade your system, and you felt that it
> >was a bug that it tried to carry out your command?
> 
> Not exactly. I popped the Breezy CD into the drive, and it offered to 
> automatically upgrade me. It never asked whether I wanted to download 
> files from a remote location, and

The old CD-based automatic upgrade feature was immature and was disabled in
hoary-updates and breezy.  In Dapper, a new system for upgrading to a new
Ubuntu release is being developed, and when it is ready, we can consider
implementing CD-based upgrades using that instead.

> there was no way (via the GUI) that I 
> could find to perform the automatic upgrade without aptitude grabbing 
> the security updates from the remote site.

You can deselect those repositories in Synaptic.

> This is especially true when the fix is as simple as using a dialog that 
> asks 'would you like to download the latest security updates now?' to 
> set a flag. As far as I can tell, it's purely a UI design issue in which 
> assumptions are made that are only true in developed countries.

It isn't a UI issue; the traditional upgrade system doesn't really know the
difference.  It upgrades you to the latest packages available, and in your
case, the network repositories were available to it, even though you didn't
want it to use them.

> - When users log in, a dialog often appears and tells them, "There are 
> new updates available. Would you like to download them now?" This dialog 
> appears even if the user does not have admin rights, and clicking yes 
> causes confusion.

A bug which has been fixed in Dapper.  It's possible that it could be
backported to Breezy, though this wouldn't help you since you don't download
the updates.

> - The low-contrast frame-buffered start-up screen is very difficult to 
> see under natural lighting conditions, especially on older CRTs. It took 
> me a day to realise that the [ok] signal actually did exist. It wasn't 
> until the NTP time-sync failed that I saw the red [failed] sign and 
> realised that the text was still there.

The text is mostly technical gibberish anyway; we've considered disabling it
entirely.  I don't think this significantly affects the user experience, and
it's very straightforward to disable (remove 'splash' from the kernel
command line) if you don't like it.

> - This is a more generic issue, but: It appears that the init console 
> messages are switched from console 1 to console 7 very early in the init 
> process. This means that, once gdm starts, one can no longer switch to 
> console 1 to view the remaining status messages. This is especially 
> relevant when X hangs, which often happens with the dodgy[*], 
> second-hand equipment we use here.

They're on vt 8.

> - Keyboard support seems to have changed, causing errors when certain 
> keystroke combinations are passed. On one test machine, the CTL-ALT-Fn 
> combination does not work, making it difficult to switch to console 
> mode. On another machine, SHIFT-PGUP does not work on the console nor in 
> gnome-xterm. I havent had chance yet to diagnose this, so I can't even 
> speculate on the cause. It's quite possibly an upstream bug.

There are some known bugs in the X keyboard subsystem which were fixed with
post-release updates.  I recommend rolling out all of the updates in
breezy-updates to your Breezy systems.

> In all of these cases, though, I see a common tendency, which is to make 
> things easier and more attractive. It's a truly commendable goal, but I 
> worry that it's coming at the expense of those working on the trailing 
> edge, with cheap, underpowered equipment and limited resources.

This conclusion doesn't follow from your observation; the problems that
you've described are mostly (known and fixed) bugs, not attempts at
usability improvements (they would be poor examples indeed!).

-- 
 - mdz