What Might UserLinux Look Like?

Lucky writes "This story at Linuxworld talks about some of the potential features of UserLinux, as well as Bruce Peren's proposed community desktop project and its potential features. There's some exclusive commentary by Perens there, too."

Comments

Article Text

[Anonymous Coward]

* LINUXWORLD EXCLUSIVE * What Would UserLinux Look Like?

Bruce Perens tells LinuxWorld's desktop editor what he has in mind with UserLinux
November 17, 2003

Summary
Mark R. Hinkle, LinuxWorld's Desktop Technologies Editor, muses on what his his ideal incarnation of a Linux desktop would be. Bruce Perens, whose idea it was, chips in with detailed comments.

By Mark R. Hinkle Bruce Perens
Page 1 of 1

Last Monday at the Desktop Linux Consortium Conference at Boston University's Tyngsboro, Massachusetts Campus there was a lot of talk about a "UserLinux" distribution. The topic was sparked by remarks by Bruce Perens who voiced a need for a distribution that was designed to meet community needs for a desktop operating system based on the Linux community favorite Debian distribution.

I contacted Bruce who has been kind enough to interject some comments to my own text. They are marked [thus].

The thought of UserLinux sparked my thinking. The thing I like about Linux is that it's infinitely customizable to meet the needs of almost any situation. However, for it to be a viable desktop for the masses there seems to me that there has to be some common features that a large number of Linux desktop users would appreciate. I thought about this quite a bit and started my list of what it would take for Linux to be my "ideal" environment rather than my preferred environment. I'd be interested to see what the community considers the most important features.

[Bruce Perens writes: I should point out that UserLinux also has a server mission. Our first customer group has both server and desktop needs. But the server is a solved problem, at least mostly, so we know a lot of work needs to go into the desktop.

Also, the most important thing about UserLinux is that it is an attempt to change the economic paradigm of the Linux distribution. We feel that creating a Linux distribution doesn't work as a profit-center, and that it is better viewed as a cost-sharing exercise. So, the customers involved in UserLinux will be paying for the engineering of creating a Free Software system, rather than for boxes, "seats", or user licenses. The system will be certified to various standards and vendor requirements with their funding, and the result will be given away. The customers get all of the copies they need with no incremental cost per seat added. They will have to pay for service.]

My list has two overwhelming requirements for the Linux desktop. First it has to be easy to use. It should pass the "Grandma test" which is when placed in front of the average grandma she would find it intuitive and easy to use. Second it should include a set of tools that allow the user to accomplish their most important tasks. I generated my list of tools and what I feel are my most important for my needs. I would encourage you the prospective users of such a system to add your feedback.

Productivity Tools

Browser I think Mozilla is a great option for browsers. I like the tab-based browsing and pop up blocker. If not Mozilla than maybe some of the projects spawned from Mozilla aimed at speedier performance without the frills like Firebird.

[Bruce Perens writes: I'd like to hear if Konqueror has something to offer that is not matched by these choices.]

Office Suite I use Open Office and Star Office and I think they are good. For some of my more ambitious projects I do use Microsoft Word but I find myself using Microsoft less. I particularly like the ability to export files to PDF format preserving the look and feel of my files across platforms. If these suites could handle better more complex formatting I think they would easily displace their competitors that costs many hundreds of dollars.

[Bruce Perens writes: I like OpenOffice and hope that I can facilitate the creation of a broader development community outside of Sun.]

E-mail/PIM Outlook made the integrated PIM and email client the vogue in business. I like the idea but I think that Mic

Re:Where was Bruce? Oh where was Bruce?

[Bruce Perens]

It's really not necessary to be so dramatic.

I wrote a character-mode installer that fit on one floppy, and was the best installer in 1996! It's not 1996 any longer. I think character mode would still be OK if it were easy, and that's where the new Debian installer is heading. It partitions your disk if you want it to, and so on. But it is built so that it can get a GUI front-end too. I think the developers are going for functionality before eye-candy.

I don't like developers who bear contempt for newbies. But the place to handle them is somewhere other than where the developers are attempting to do their work. This is why you need a layer over Debian.

Bruce

Re:UserUtopia?

[.Bruce Perens]

Agreed, and you make some good points. However, don't discount the power of financed research. Microsoft poured tons of money into usability studies of their Aqua interface, and we can benefit from their efforts. Obviously I'm not saying I want to copy it, but there are elements of usability that not only have the data to support it, but a proven track record as well.

POSIX ain't it. The factor of the "Apple matrix" that we were taught with OSX can readily be applied here. Merely linking, say, and icon to a representative unit (of the underlying operating system) to the point where the icon becomes the object itself is inherently bad. The user is too far removed from what he is actually doing.

I appreciate your input.

Re:UserUtopia?

[CustomDesigned]

In an ideal world, packaged installs will be a compressed single file, containing all source code, configurable on any *nix like normal source code EXCEPT that now there's a graphical interface so that setting compile options, creating desktop shortcuts, and "Make clean, make install, make uninstall" now all work under X with a point-and-click.

You just described Source RPMS.

And while I can appreciate the desire to compile everything from source, it doesn't cut it when you are managing 40 production machines, most of which have no compiler installed (for security reasons and lack of need). Instead, I compile the Source RPMS on my devel machine, and push the binary RPMS to the 40 installations. I still get to use optimizations like compiling for i686 since all installed machines have Celeron or better.

I like the way RPM tracks installed files and keeps a database of MD5s to detect changes.

Formal proposal coming up

[Bruce Perens]

I expect to have the formal proposal for Userlinux done on Thursday. Sorry it's taken so long, I've been busy with closing out work for some current consulting customers.

I'll be off Slashdot for a few hours now, time to give Stanley his bath and put him to bed.

Bruce

Re:Robust package management

[Kakemann]

1. CheckInstall will generate DPKG files (among many package formats) for anything you build from source. Makes it easy to uninstall the files.

2. What APT repository were you using? Did you search for the package at apt-get.org to see if there were any third party repository? You know that you can have several repositories in your sources.list file, right?

How should a package manager handle the user overwriting files left and right with different versions? The policy is that you put YOUR stuff in /usr/local and leave the rest alone. If you don't want to do that, creating your own Debian packages _really_ isn't that hard.

RPM can be done right---Mandrakes urpmi

[waferhead]

I have had less issues with Mandrake than debian (unstable, using the default installer, Knoppix ;-) but very few in either case.

Redhat I gave up on, I did use Redhat 5.0>7.2, and tried 9.0/9.1/Fedora--- Mandrakes implementation stomps on Redhats. Repeatedly.

I have good wishes for Fedora now that apt is supported... But Core 1 blew for me.

The joy of typing urpmi somelibraryimlookingfor.so and having it pull the package(s) is extreme...
(building something not in contrib for example, from a tarball)

(As to the "default installer" bit, if more people use Knoppix to install Debian than Debians installer, that actually makes knx-hdinstall the defacto default installer I guess)

Hehe, amusing

[2nd Post!]

I understand most (95%+) don't have constant contact with Mac OS X, much less play with the developer tools...

But what you just described is how Mac OS X's Interface Builder works! The widgets, guidelines, interface paradigms, and look and feel are encouraged and enforced by the UI; the menubar, window layout, widget placement, texturing, widget types, etc,

It's not perfect; developers can still intentionally (or unintentionally) violate the HIGuidelines, but it's a lot harder than any other IDE I've ever seen.

Re:Robust package management

[IamTheRealMike]

There's nothing about your system that can't be tracked down by a little intelligent scriptwork. If package managers worked like that, then you'd be able to ignore them on occasion or even break small pieces and the rest wouldn't come tumbling down.

Right. In fact an easier way to look for a library is to scan the linker cache. Look, I'll show you:

/sbin/ldconfig -p | grep libfoo .

In fact, the code we use in autopackage is a little more involved:

/sbin/ldconfig -p | grep "${lib}\(\.[[:digit:]\.]*\)\?$" | awk 'BEGIN {FS=" => "} { print $2 }' | (while read; do test -f "$REPLY" && echo "$REPLY"; done)

This works because (unfortunately) if a library is not in the linker cache, it won't be usable by the system anyway so nothing is lost by not checking the filing system directly in this case. For python we do exactly what you suggest

Is anybody working on this? Is anybody interested in working on this?

In short, yes. You aren't the first one to think of this. In fact the approach goes back to the days of autoconf, but as far as I know my project is the first attempt to apply this to binary packages on Linux. See autopackage.org for details. It's essentially a lot of infrastructure and support code for packages, combined with a library of tests for common packages. Eventually we hope the library developers will maintain the "skeleton files" themselves.

That's an impostor

[Compact Dick]

Note the dot before the username? You bit :-)

The real Bruce Perens has a UID of 3872. Everyone else is an impostor.