Slashdot Mirror
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."
Linux is an OS that was and will always be for a few academites plus thousands of system administrators. The path from OS to regular users is long and hard. Just look at OS/X...and notice, people were *paid* to do all that work.
Yet Another Linux Distro ... But I suppose more choice is good.
...
My list has two overwhelming requirements for the Linux desktop. First it has to be easy to use. It should pass the "Grandma test"
Choose the the grandma well, or fit her Sonotone with a hidden HF receiver so you can discreetly tell her what to do.
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.
Oh okay, I didn't realize it was a YALD that was also doomed to fail even before seeing the light of day. Nevermind
[Moderators: this is not a flamebait. Think about it, how many such schemes have ever worked ?]
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
black screen. white flashing cursor. 80 columns, 24 rows. Fixed width font.
That man tried to kill mah Daddy
Since we are the ones programming them, doesn't that mean that they've been conditioned to think the way that we do? After all, they're running our logic. Kind of like a small section of our minds...
Stop the Slashdot effect! Don't read the articles!
I think everyone agrees that rpms suck. Most of the good code comes in source tarballs - configurable for any *nix... but this is where the user experience falls apart. What person is going to want to dig out the command line to compile source code, and will he or she know about all the ocnfigure options... and then, will there be dependency issues (or should the source contain the dependencies too?). Then there are the legal issues of bundling dependancies... and then there will be future commercial Linux apps which won't want to include source code.
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.
PLEASE! Will someone serious about standardizing Linux installs do something about this... or desktop Linux will never take off.
READY.
PRINT ""+-0
Bruce
Bruce Perens.
I had this same argument with Steve Jobs in 1999. Today we have more people on the Linux desktop than on OS/X, and Steve stood in front of a slide saying "Open Source, We Love It!" at MacWorld.
Bruce
Bruce Perens.
There is a great article at Ars Technica by John Syracusa on this subject of the paradigm that the computer interface is based on, specifically spacial interfaces versus hierarchical interfaces:
About the Finder...
As a Linux user (and user of OS X at work) I have, like most of us here, am very comfortable with flying around in and out of the hierarchical nature of the file-systems on our computers. When giving my mother tech support over the phone, she is continually amazed that I can just list to her (while driving down the road) the series of directories that she had to go through to find her necessary document. A little after this, I read the above mentioned article which gets into why the finder in Apple's OSes =9 were so "user friendly" and got some new insight.
Like many of us, when using OS 8-9, I was always annoyed with how the icons would never line up and you very soon built up this annoyingly HUGE mess of windows whenever searching very deep for something. What I missed about this system in my attempts to over-ride it, are Syracusa's main points: - There is ALWAYS a one to one correspondence between folders and windows. I.e., you can't have the same folder open in two windows. - The contents of a folder ALWAYS look EXACTLY how you last left them, even if that causes some weird overlap or scrolling nastiness.
The result of the absolute consistency of the above two things is that when you interface with the computer, you can build a visual sequence of landmarks to your data. Something akin to driving your route to work. You may not know the names of all of the streets (directories), but still find your way because you can recognize the arrangement of streets, like taking the third one after the blue house. Syracusa gives the example of light-switches. After a couple of days in a house, you don't need to hunt for them because our minds have developed over millions of years to recognize these sorts of visual information so that we can find things in the world around us.
Contrast this with your the file browser in OS X, Konqueror, Windows, etc. When you open up a given directory you really have no idea what the contents will look like. This depends on the view options you chose in the parent directory as well as auto sorting and all of these such things. Because of this lack of visual consistency, you are forced to remember the file names of every parent of the file that you are looking for. While I do well with this and am perfectly comfortable keeping the whole darned thing in my head and navigating from the cli, MOST people aren't. This is one of those things that should be heavily researched (anyone doing a psychology PhD and need a thesis topic?) in order to move not just Linux, but computing in general forward.
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers
Man is out of date for a reason - it's deprecated and hasn't been used for ages. Try info instead, that's where you'll find up to date documentation for most things.
There are more problems with the LSB as well. It definately has a tendency to 'fix things that aren't broken,' and to introduce unecessary complexity. As much as I like the idea behind standards, I don't have much faith in LSB to write them correctly, and as long as that is the case it's better to just ignore them.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
To really get it to take off we need the equivalent of _Certified for Windoze_ program. Ideally the certification would become a must have tick for corporate purchasing staff and non-compliance would result in adverse reviews in the computer sections of mainstream media.
I envisage something like the 5 star ratings for energy efficiency - all 5 stars if everything in the system supports open source with published interfaces, less a star for each undocumented feature (or half a starif they partiallyof support it or you need a closed source driver).
To get the Open Source Tick would require at least 4 stars.
The key here is that they are attempting to put something together that our naive end users will be able to dig and thus buy - pushing the precentage of desktops more on an even keel with you know who. This can't be bad for the Linux world domination conspiracy -er- Linux users... :)
:)
One of the major complaints I hear is about differing interpretations of the file system hierarchy. While I think standardization is good, I also believe developers should have a certain amount of flexibility - which the standard allows. The key here, I think, is for the distributions to honor the locations that the developers established for their files - so compatability crosses all boundaries and documentation can be maintained by the developer on the particulars of his application - instead of the distributor. In cases where the application creates problems due to inappropriate placement - the issue needs to be raised to the developer to correct his implementation; distributors would have the option not to include the application/system if it was too disruptive - but that is all (more than this and the distributor can cause more problems than he intends to fix). Developers need to understand the standard; distribution creators need to cede the responsibility for application locations to the developers - with the right to veto bad locations from entering their distro until corrections are made by the developer. This way, no matter which distribution you are using, foo.ini is located in the same place every time.
Related to this, and probably more frustrating for end users, is when application developers make assumptions about libraries and other applications that exist on the system during the build. For hard core *nix system administrators this is no big issue - something they have been dealing with for years; however, for a general purpose workstation this has to be idiot proof. Coupled with standard locations includes being able to check those locations for particular files, and if not found, have the confidence to load them for the user, rather than simply complaining and dropping back to the command line. Again, the onus is on the developer to include all parts necessary to work with his tool (perhaps even going so far as loading a different library in an alternate location [sub directory in standardized path location] - then changing an environmental variable used exclusively by the application to locate it without disturbing an existing library or any applications that depend upon it - lets definitely do it smarter than Microsoft DLL hell)
These two items coupled together would make installation and maintenance across all distributions easy - and dependent on the documentation and careful work of the developer community - instead of left at the whim of the distribution agents - who are not on the same sheet of music. If developer X creates app Y and puts it in location Z - then Z should be where everyone finds Y when they look on their system.
Finally, I think easy to use tools for administering very clearly standardized core items (the rc.d run level scripts, crontab management, X configurations etc...) should leverage existing text based configuration files. Lets not get into the trap of reimplementing the Microsoft registry - as a single point of failure. Up to this point these types of tools have been adhoc; someone needs to take the ball and run with it to create something that is clearly superior and usable for all distributions that intend to target the niave user (hmmm - sounds like a good open source project to me - maybe a python Tk gui with a builtin command language parser for power users...
These are the core items I think are critical to a successful linux desktop to compete with Microsoft's dynasty.
One additional frill I would suggest:
Implementation of a better 'Annotea' W3C
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
You can't accomodate them all with a single UI.
What is really needed is a virtual layer between the (G)UI and app that would allow GUI "themes", similar to the way that KDE and GNOME have themes for their WMs.
For example, say that I am using a program that displays various objects that can be moved, copied, etc.
Rather than receiving events like <KEY C with CTRL modifier> or <MB1 with mouse coord> , the program would receive events like <COPY> or <MOVE with delta/coord>
Then, the GUI theme that I was using would determine what keys/mouse movements generate what events.
Some programs already allow users to customize keyboard shortcuts and menus.
This would be like that, except that, instead of customizing per-application, it would customize across all applications.
The problem is determining the domain of events that the virtual layer would support.
Operations like copy, paste, and move are easy (and have already been done for things like text boxes); file open/save operations are semi-standard in that many apps use <CTRL+O> and <CTRL+S> (but not necessarily customizable, and certainly not globally); other, less common operations (e.g., drawing a line from point A to point B, adding to or subtracting from the current selection, etc.) could be handled using some sort of modular system (ala XML XPointers, etc).
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Mod this guy up.
The only way the Linux desktop is going to become consistent, and not only from a GUI perspective but from a config file and usability, and application integration (i.e. clipboard) perspective, is for EVERY application that is available for UserLinux to filter through a single point of contact.
This group would then standardise (with regards to the GUI, config files etc) EVERY application that is submitted.
I dont see any other bullet proof solution. It would be a ton of work (and really shitty work at that) but it *would* work.
It's basically what distros are doing already with their different package management implementations, but taken to the next level; i.e. instead of making sure the package compiles/binary is not left with missling libs, you make sure of not only that but also the applications all have the same file dialog, windowing toolkit etc.
Invoicing, Time Tracking, Reporting
A user oriented distribution of linux would need some basic re-thinking of existing linux distributions.
Kernel configuration/rebuilds should tie into the boot loader so that a kernel/system failure would allow for a boot into a known good configuration, one specified at initial ship date. You should always be able to boot into a reliable kernel for your hardware, even if very little is installed in it.
The user should never have to see a boot loader config. Upgrades to kernels should include a boot-loader update and install.
Initial system installs should be graphical, should run out of the box on 99.9% of all current hardware, and should allow for a "one click" install. This would mean a very simple, basic install with minimal fluff. The install time messages should be clear, communicate essential information, and allow going back to correct mistakes.
After-install modules should allow the user to update configurations. Example - I don't know the IP information right now, so skip that at install and run a wizard later, after I've spoken to my admin.
Installed packages, like StarOffice, should come completely integrated into the OS. Not only should they be completely installed, but they should have all the default configuration already done. The user should be able to launch from the desktop just by opening the app, and not configuration is needed. Add-on packages or plugins should already be installed for the most common needs. Examples are browser plugins, pdf readers, etc.
Windows emulation should be installed and integrated by default. The user should NOT have to know anything about installing an emulator or configuring it.
Printing, lots of printer drivers, most common configurations should all be installed and driven by a point/click wizard. Same for instant messaging.
The system should ship with an installed wizard for AOL, Earthlink, etc. that requires almost no user interaction to get running.
Automatic updates should exist, and should be pushed to the user system if the user chooses to subscribe.
It's not enough to be windows compatible or similar to windows. We need to be better than windows, easier to use, easier to configure, more productive. Until linux offers users substantive reasons to change, they won't. Free is not enough of a reason, or they'd be here by now. Free and easy is closer to a reason. Free, easy and better is a big enough reason.
It's certainly what other systems tend to do - I'm thinking particularly of Mac OS X here, but other less-known systems work well in a similar fashion. However, I don't see that as a viable solution for the open source world; as I said, there's just too much incentive for developers to keep control, to do their own thing.
But there needs to be some central point of contact. I was wondering if that point could be part of the system, rather than a group of people. I don't know exactly what form it might take, but consider this: suppose instead of using a GUI toolkit directly, an application used some sort of meta-toolkit. Instead of saying "I want a window here with this widget here and that widget there, and these menu items with these shortcuts...", it might say "This is what I'm called, I manipulate these data structures, these are my preference settings, this is how I quit...". Then the meta-toolkit would decide exactly how to present that to the user. The developer wouldn't have to worry about the UI decisions, and every app would have a consistent look and feel automatically.
Now, this is only a very rough idea; as above, it would be far too restrictive and simplistic, and most apps wouldn't fit into such a specific model. But my intuition tells me that the future must lie with something like that; software has got far too complex for app developers to have to make the sort of low-level UI decisions they do. I'm convinced that this area of research could be defining the way we write applications in years to come.
Ceterum censeo subscriptionem esse delendam.
I agree that that one of the biggest problems with a "Desktop" Linux is software installation (the other being look-and-feel consistency). I see that most people mention apt-get or similar solutions to software install and dependency problems; however, not everyone is permamnently online, with most people still using dialup at home.
One solution, as I see it, would be for applications to be self contained. They can use the libraries available in the system, if they need extra, they can install them in their own folders. I think that's how OSX does it.
This, however, will require a major shift in the development model for Linux.
This is not going to be easy unless there is standardation on a single distribution - how likely is that?
I have only been using Linux exclusivly for about a year. I guess I would say that I am typical for the granny test. Well almost typical, I am only 23 and not female, but other than that, I am a typical home computer user. I use office suites, email programs, browse the internet, watch movies, burn cd's, and keep my finances in order on my pc.
/mnt/cdrom where RH uses something different. Well it did when I last used it, its been about 8 months. I would also like to see a universal package installer. I like the idea of .deb's because they handle pretty much everything. KRPM also looks to make sure dependancies are filled. It would be nice to have a program handle both package formats.
My first complaint is there is a lack of documents that are easily used by the home user. Man is ok, but I haven't really found a good gui for searching for help by topic. That would have been nice. I usually have to search the net to find out what program I have to use to do a certain thing. It would be nice to search for 3d animation, and if a program was installed, have a link pop up to the help file from that program. If more are installed...have multiple links. I guess that comes from using MS for a long time.
Dependancies are a killer. SuSE (its what I use) seems to handle this pretty well. I have yet to install anything over the net. I dont have much need to, I have everything I need. I have noticed that they file systems are big time different. I have used RH , and SuSE. The mount points are different for my removable media. Since I am not a programmer, I can only assume that there is some variable that I can use in a script to detect the usual mount point for say... my cdrom. That isn't much of a deal to me, I can get around well enough to figure the stuff out. But to a new user....I bet it could get confusing, especially if they switch from one distro to another. Suse uses
Hardware support is a major issue. I guess we can only blame the vendors for not releasing the proper information to develop those.
The config system for the different WM's and Desktops are completely different. I personally like that, but it would drive my old man nuts. Many of the windows home users that I deal with are used to learning the exact steps to do something, not the concept of how to do it. IE. "to open my add printers dialog, I go to START -> Settings -> Printers -> enter. If it wasn't there...I wouldn't know to look in the control panel." The different distro and WM's place things in different locations and have the config UI's in different places. Most MS users dont even know that you can use the command prompt. Before you flame me, I said users, not admins.
I think a database of available packages for download by distrobution would also be nice. Add a gui for apt, or apt getrpm (is that correct?) with a menu option to add, modify, or remove a source from the list and it would help. Make that same list available to your package manager so it can dl any dependancies that your system doesn't have when it checks and it makes life all happy and stuff.
Some of the stuff I have mentioned is probably being looked at or being solved by the LSB.
Ohhh...one more thing...
It would be nice to have a find button on "add attachments" for the email programs. I dont know how many times I have had to instruct people on how to find the file before they attach it. It would also lower the need for knowing the file system layout of your system. I think it would also solve some of the confusion for the "where is my c:\ prompt" people that are still trying to learn linux. It really isn't that hard to figure out, but if you want someone to migrate from something they are already familiar with...you have to make it really easy for them.
Stop signs are only Suggestions