On Tue, 2007-07-31 at 10:32 +0100, Paul Nasrat wrote: > On Tue, 2007-07-31 at 09:51 +0100, Richard Hughes wrote: > > (from my blog, apologies to anyone that's read this once already) > > Have you read - http://klik.atekon.de/presentation/klik.html it's > focussed on the users care about applications and highlights some of the > issues with existing pkg/distro universe setup. Thanks for that, I'll review in detail in a few minutes. > > Before ideal system requirements we should talk about use cases and > > system interactions. > > OK who do we care about - your subject implies all package management, > you don't really cover large systems deployment, your examples are > direct user not centrally administered based. Well, they are the way I've seen Linux being used 1st hand. We need some other use cases for the corporate desktop, and I'm open for adding more :-) > > I think this is where update systems have gone > > wrong in the past, closely integrating with the existing package > > system > > rather than studying the complete ideal user interactions. > > So who are your users based on your cases I'm guessing: > > Suzanne - non administrator casual user > Simon - a more advanced user sharing a machine with Suzanne > Toby - a single user/admin > However this is really not distinct and clear - please expand. Sure, will do. > > Boot Time Security Update > > > > Toby logs into his desktop. A notification area icon with a critical > > icon appears in the top right and a libnotify popup tells him there are > > 3 three critical security updates. The libnotify popup has three > > buttons: > > • Update now in the background > > • Always do updates automatically > > • Ignore for now > > Toby clicks the first button and the update completes in the background. > > When completed, after a few minutes, another libnotify popup appears > > telling Toby that the update was completed and after a few seconds the > > status icon disappears. > > This seems a reasonable one not sure if it's boot time or "scheduled > check". > > Update automatically - you need to be able to not do this if you're > using GPRS or some low bandwidth connectivity on the road. Maybe we need > a traveller case. Sure, this is why I didn't just suggest automatically installing no matter what. You don't want to do a kernel update over a 1$/Mb GPRS link. > The search requires much better metadata than we probably have in > description/summary right now. Can we use mime/file(1) info to help the > search. Yes, we'll have to look at other information sources. > How do we define trust, how do users add trusted sources - or can only > administrators do that. I'm open for ideas. > > Installing new features > > > > Suzanne switches back to her session and wants to add some clipart to > > the word file she has just opened. She clicks "Insert" and then > > "Clipart" and then a windows pops up telling her that clipart is not > > installed. She clicks "Install" and a progress bar appears and moves > > across as the clipart is downloaded and then installs. When finished, > > the dialog disappears and she chooses a picture of a cat. > > Trying out a new version in parallel: I'm not sure that's a good idea. As soon as you start talking about per-user or per-group installs then things get very complicated indeed. Richard. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
