What Might UserLinux Look Like? 528
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."
UserUtopia? (Score:5, Insightful)
Re:UserUtopia? (Score:2)
The details of the config files do not matter. Most users don't need to touch the config files directly. Let the users get to everything they need to change through the desktop, e.g. the "Start here" icon on Red Hat or Gnome systems or the equivalent if KDE is the choice. In any case, there isn't "continued divergence"; the LSB and freedesktop.org are helping to pull things together.
UserLinux is Debian-based, so apt is underneath. But that doesn't mean that anyone has to type apt-get on the command li
Desktop intergration... (Score:2)
What I'd like to see would be a site dedicated to collecting feedback on what Linux users (old and new alike) would like to see created or improved. We really are full of comments, but its a little disappointing that as a user group (slashdot-computer nuts) we have no useful outlets. Its pretty funny really considering in a lot of ways we probably represent a larg
Re:Desktop intergration... (Score:5, Interesting)
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).
Better standards and documentation (Score:5, Insightful)
Something else that'd increase desktop Linux: accurate, up to date documentation. Man pages are hopelessly out of date (read man resolv.conf and find out that most machines should be running local copues of Bind, or the various setting up a SLIP PPP connector on kernel 2.0 docs on TLDP).
Re:Better standards and documentation (Score:3, Interesting)
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.
Re:Better standards and documentation (Score:3, Insightful)
Is it? By whose standards? The Debian project insist that all commands must include man pages. The LSB has, AFAIK, nothing to say on the matter,
Oh yeah, and the info page for resolv.conf is wrong too.
What are you thinking on specifically, in terms of `fixing things which aren't broken' ?
Re:Better standards and documentation (Score:5, Insightful)
Good troll. Now, about the only person who seems to think man is deprecated is RMS and his cohorts, and as you say, they seem to prefer their own obtuse documentation system info.
While info might sound like a good idea for some developers too lazy to write man-pages, or a real manual in a readable format, it's completely ridiculous for the rest of us.
First, GNU documentation guidelines state that an info manual should be both a tutorial and a reference, which flies in the face of any advice you could get from both people experienced in reading or writing manuals. While man-pages are at least good for getting a complete reference of something, info-pages are almost always completely confused about their purpose, being as comprehensive as the average man-page, but much more wordy, making neither a good introduction nor a good reference.
Second, there is the file info.dir, which must either be manually updated, or gradually fall into a long unorganized mess of links pointing everywhere, but without any comprehensible organization.
Third, there really aren't that many programs having an info-file. While you can expect almost everything to have a man-page (and possibly point you at the info-manual), the other direction is not as common. A good documentation solution should probably have some way of accessing info-files, because of their historical significance, but it should not be based upon it, as it is quite despickable. The same can of course be said of man, but man never tried to be everything you need.
Last, the GNU info program has a loathsome user interface, with keybindings as intuitive as those found in dselect. The emacs version is slightly better, but requires you to run emacs. But apart from the other problems with info, this is actually fixable.
In conclusion; there are serious problems with GNU info. It is certainly not better than man, in any way. Man makes it easy to incorporate it as part of a better help-system. Info makes it hard, and instead tries to be everything for everyone, but fails completely at the task. A good documentation system should cater for the user, info seems to only care about the person writing info manuals.
Re:Better standards and documentation (Score:3, Insightful)
Try doing that when your Xserver is fried and you need to check the syntax for the commands to get it back up and running. Or for that matter try that when the only access you have to the box is via the textmode only terminal server plugged into the seriel port; and just for fun you're dialed in over a 33kbps, at 2am Sunday local time, the box you're connected to is on a different continent (it's 5am Sunday there
Comment removed (Score:5, Interesting)
Re:UserUtopia? (Score:3, Informative)
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 mach
Re:UserUtopia? (Score:3, Interesting)
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
It's not RPM, it's the packagers (Score:3, Insightful)
Repeat after me - It's not RPM's fault, it is the fault of the packagers!
The problem with ANY packaging system that allows for dependancies is the JACKASS PACKAGE CREATOR who defines his dependancies as
libfoo.1.2.3.so.pl1.thursday.3oclock.mine.mine
as opposed to
libfoo.1.so
Debian fix this by being very controlled in what they let in - overly anal-retentiv
Re:UserUtopia? (Score:4, Insightful)
I must disagree with: "When someone downloads a package for "Linux" it should work on any Linux distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board. this.
"Linux" is an OS-kernel, and it should set no policy. When someone downloads a package for windows CE, they don't expect it to work on windows XP. And there are plenty of server applications that refuse to work on XP or 2K professional even without any technical reasons.
Similarly, when someone downloads a debian package, they shouldn't expect it to work on mandrake or suse. And when somebody downloads a package for a linux distribution for the ARM, they shouldn't expect it to work on one for the Itanium. And you shouldn't expect ximian rpm's to work on the fullpliant linux distribution either.
Your expectations are unrealistic. What is good for one linux distribution is not necessarily good for another. You could just as well complain that "When someone downloads a package for "Unix" it should work on any Unix distro out there, similar to the way which "Windows" software works (excluding win9x/NT incompatibilities) across the board.".
If you want the ease of windows, you have to make some choices. This includes choosing between rpm, dpkg, or something else, KDE, gnome, a mix, or something else. Supported packages, etc. Debian (and many other distributions) is a nice example of this.
But even debian gives you too many choices. I can expect most debian packages to work out of the box after installing it with apt-get, but not every combination that the package system allows would make sense for the end user.
So, we limit it further, and call it UserLinux, or something like that, which is a subset of debian. But you can't call it "Linux", because that is something else.
No, it isn't. You don't need to understand much more to be able to write "apt-get install openoffice", than you need to get down to your favourite software store, get Microsoft Office, insert the CD's and click next, next, next, and finish. I would actually go so far, as to say that debian is simpler for the end-user in this arena.
Now, I wouldn't recommend linux to non-technical users either (unless I or someone knowledgeable sysadmined the box), but having to use the command-line for access to apt-get is not the reason. They can learn that pretty fast. There are other more complicated issues that hurt the user-experience a lot more.
Solution for configuration babel (Score:4, Interesting)
Bruce
Re:Solution for configuration babel (Score:4, Interesting)
Bruce
Re:UserUtopia? (Score:2)
Wow, I would really have to respectfully disagree there. The desktop is the primary problem, IMHO. I have used linux for years on servers, but still use it sparingly for desktops. Part of the problem *is* the decentralized way Linux is developed, in one respect: No one agrees how much configurability is too much or not enough. Ironically, its also its greatest strength.
The current Linux desktop does NOT pass the G
Re:UserUtopia? (Score:3, Funny)
My grandmother is 70 and isn't able to use windows. So, uh what's this granny test supposed to tell you?
Re:UserUtopia? (Score:3, Funny)
Re:UserUtopia? (Score:3, Insightful)
At a guess these are actual us
YALD (Score:3, Interesting)
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 ?]
Re:YALD (Score:3, Interesting)
Bruce
I guess I'm not the target. (Score:2)
This is, of course, the reason why none of these "perfect desktop" distributions will take off. I consider myself a pretty typical home Linux user, and I have completely different needs than addressed
Re:I guess I'm not the target. (Score:2)
It's weird, isn't it? Distros like Debian and Gentoo are known as "hard", but only because of the installation. Using portage or apt is exactly the kind of simplicity "average" users are looking for. In my case, if I want to install or update an application, it's just a matt
Re:I guess I'm not the target. (Score:2, Insightful)
If you're posting to Slashdot, you're not the typical home user they're targetting.
Re:I guess I'm not the target. (Score:2)
> components of this ideal distribution might work
> in some instances -- for instance, in order to
> have uniformity through an entire organization --
> but I can't see it working out for home users.
Actually, I think having a single app to do one thing would be a very big plus for home users. The first time I installed Mandrake on my mum's PC, she looked through the menus and found 8 Web browsers, 6 email clients, 5 word processors,
Article Text (Score:2, Informative)
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
A good thing (Score:5, Insightful)
The UserLinux initiative is an excellent chance for us to penetrate into the mainstream desktop market and start making software houses recognize and implement for linux - because their target audience can finally use the system.
The list posted in the article looks to be a rather [complete] connonical set of programs. --- This has been just a few, incomplete, thoughts ---
Re:A good thing (Score:2)
The UserLinux initiative is an excellent way of adding yet another linux distribution on top of the 3 or 4 major ones that already exist and the 150+ that nobody cares about, confusing newcomers (users and industry alike) and diluting the cohesion of the Linux "standard" (as if th
Re:A good thing (Score:2)
Re:A good thing (Score:2)
Re:A good thing (Score:2)
Bruce Perens would have had been much more inspired by proposing to work on alternative GUI packages to replace X and/or Gnome/kde/afterstep/whatever
So... adding Yet Another Distro is bad and confusing, but Yet Another GUI would be a good thing?
But what will it do that we don't already have? (Score:3, Insightful)
What will UserLinux do that we don't already have (yes, that's question, not a statement)? We already have a Free Software, user focused Linux distribution that ships with all the user apps mentioned in the article. Its called Fedora and is based on one of the most popular distro around (according to Netcraft and IDC). What will UserLinux do that Fedora doesn't?
Browser Plugins (Score:4, Insightful)
hmmm (Score:5, Insightful)
Linux could do with a few less 37337 coders and a few more artists and graphic designers, people who have an understanding of what colors work together, and most importantly what proportions are pleasing to the eye. The thing I like least about linux is how so many little aesthetic things are off. Dialog box fonts are a little too big for the dialog box, the borders between windows are too narrow, nothing matches like it should.
Re:hmmm (Score:3, Insightful)
That being said, there should be a difference between making it pleasant and making it Microsoft. There's a saying I once heard, "Do not seek to follow i
Consistency and control (Score:5, Insightful)
What's really needed IMO is consistency. Dialog boxes, for example should have the same style across applications &c. - and that doesn't just mean the font size, or even the font; it means having a similar layout (where appropriate), with buttons in a similar order, the same default focus, similar keyboard controls, similar positioning. And the same principle applies right across the GUI, from having the menus arranged in a similar fashion with common menu options in similar places, to similar behaviour of toolbars and palettes, and so on and so on.
The trouble with this is control. This sort of consistency would mean developers willingly going with someone else's design principles and UI guidelines, and too many developers seem too keen on doing their own thing to let this happen, whether from a desire to make their app stand out, thinking (rightly or wrongly) that the usual principles don't apply to their app, incompetence, or just sheer stubbornness.
Not everyone has graphical skills or UI design skills, so IMO we need a way of working where developers who want to can do so without needing those sorts of skills, but without inflicting that lack on their users. I think this is one of the fundamental problems that the free software community needs to address. GUI toolkits are a step in this direction, but clearly don't go far enough.
Maybe we should consider some fundamental reorganisation. With everything split by application, each has its own way of doing things; what if there was some other way of doing things? What if application developers yielded ultimate control of their GUI to a separate project of some kind? I've no idea how this might be done technically, and even less idea how developers could be brought on board, but IMO it's the only way to achieve the sort of consistency, predictability, and least astonishment that more centrally-controlled systems have.
Re:Consistency and control (Score:5, Interesting)
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.
Re: Consistency and control (Score:3, Interesting)
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
Hehe, amusing (Score:5, Informative)
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:hmmm (Score:5, Funny)
Queer eye for the GUI?
Hmm.... (Score:5, Funny)
Well, if the link's any indication, UserLink will look very rectangular. And white. Did I mention white?
And who's Bruce Peren? Nice to see a new name bursting onto the Linux scene!
Re:Hmm.... (Score:2)
He used to reply to stories and comments quite often on here.
Masses Vs. Community (Score:5, Insightful)
More often than not what the (geek) community considers the most important might not be in tandem with what the masses think. So for linux to be a viable desktop for the masses, we need a little mind storming. Going with the obvious of aping MS Windows definitely should be resisted, but fresh thoughts with the masses in consideration would certainly help make postive moves.
Nice. (Score:3, Funny)
This was the part that jumped out: (Score:2, Insightful)
Re:This was the part that jumped out: (Score:2, Insightful)
That's an extremely difficult project for a volunteer group to do, especially in the US -- you need people with a reasonably good grasp of tax accounting for federal taxes and 50 different state tax laws (well, not 50, however many it is. Plus they all change every single year, and the software needs to be ready on schedule every year.
It's not something volunteers can do well, es
Re:This was the part that jumped out: (Score:3, Insightful)
Bruce
Re:This was the part that jumped out: (Score:2)
GNUCash's back-end is configurable. By default, it stores to its own XML file format, but it can also be set up to talk to an SQL database. I believe this configuration needs to be done at compile time; it's not a simple setup option.
Schwab
Where to begin... (Score:5, Insightful)
Ease of use means making the computer work the way PEOPLE think, not forcing people to work the way COMPUTERS think.
Linux geeks and other developers, who have been conditioned to think like the computer because of the work they do, have the mistaken notion that advanced computer user means a user who has learned to force the natural human way of doing things into the artificial machine way a computer does things.
Any interface that doesn't force this paradigm is "dumbed down."
The truth is, the Linux geek has simply been conditioned to do things the difficult way, not the natural way. Designing the interface to do things the natural way is not dumbing it down, it's making the Linux Geek's paradigm obsolete. Of course, the Linux Geek doesn't like this, so in a fit of human ego, he looks his nose down on anything that points out the stupidity of his position (working the way the computer demands; being the tool of the computer), and calls it "dumbing down."
Natural interface (Score:2)
ANYthing that stands between a user and the power of the computer is a "dumbing down." That is what most geeks refer to when talking about the MS-Windows interface.
Until computers are able to interact with humans using a human interface (speech, AI to grok information, and user agents to make intelligent responses
Re:Where to begin... (Score:4, Interesting)
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...
don't begin (Score:2)
Re:Where to begin... (Score:4, Interesting)
About the Finder... [arstechnica.com]
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.
The Biggest Problem is Printing!!!! (Score:5, Insightful)
I have been slowly switching one of my clients over to Linux desktops, but the printing situation made the move stall. I settled for XP with Open Office, Firebird and Thunderbird as the base.
Though to give yuou an idea of the level of user I am dealing with they all still think they are using new versions of IE, Outlook and Office (they all swore they would only use MS products). The management approved of the alternatives, the users are none the wiser at this point.
When is printing going to be unified?
Re:The Biggest Problem is Printing!!!! (Score:2)
Bruce
It will look almost exactly like. . . (Score:2, Insightful)
Is there some controversy over this or something? It's pretty straightforward to set up a "grandma box" these days.
KFG
ease of use (Score:2, Insightful)
Re:ease of use (Score:4, Insightful)
Is that a secure box? Nope. But quite a lot of peopole are running their PC configured just like that.
Can the same be said for a Linux installation?
It must have a GUI option for just about everything. "Do you want A or B? Click here."
It must have standard install locations for programs. No "3 files for this must go in your
Linux can be easy to use, once it is set up, and if you never change/install anything.
Plug & pray mostly works on Windows. Plug the printer/camera/joystick in, and it's recognised and set up. Rarely do you have to put the accompanying CD in.
A successful neophyte GUI leads the user to the answer, instead of making him look for it.
Now...the question is, does Linux need a 'neophyte GUI'?
How to solve the installation problem (Score:5, Insightful)
Answer: no installation problem because the user doesn't have to install it! Almost no one installs XP themselves.
Get a hardware partner. Sell boxes that have components selected that work optimally with Linux, pre-install and pre-configure the software, and make the desktop so beautiful (by appropriate choice of themes) that people who see the machine in stores have to have one.
I think this needs to be pointed out (Score:2)
Re:I think this needs to be pointed out (Score:2)
Bruce
Re:I think this needs to be pointed out (Score:2)
Bruce
But first! (Score:2)
Re:But first! (Score:2)
Bruce
Ones (Score:2)
Linux Users (Score:5, Funny)
Some suggestions I guess... (Score:2)
an easy, working version of wine.
More free games like kq.
A media player that can play everything (xine and mplayer both?).
Where was Bruce? Oh where was Bruce? (Score:4, Insightful)
Where was Bruce? Oh where was Bruce?
If he so cared about so much about Debian not having desktop marketshare, why didn't he use his position as Debian project leader to speak out against the elitist, anti-end user attitudes that have come to define Debian as a community and a distribution?
Where was Bruce? Oh where was Bruce?
Re:Where was Bruce? Oh where was Bruce? (Score:4, Informative)
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
Modularity, "Eye-Candy", And Other Unix Geek Myths (Score:3, Insightful)
My point in general is that given Debian's history of avoiding a graphical installer and given your substantial role in Debian history as it's leader, I very much question your opinion of linux being "ready for the desktop", as I question why you should be put in any kind of leadership role of a process that targets non-technical users.
As for the points in general about linux an
Re:Modularity, "Eye-Candy", And Other Unix Geek My (Score:3, Insightful)
And before I accept your point about the GUI not working as an add-on, I'd like to hear what systems you like.
One could also make the moral argument that developers who have contempt for newbies have entirely no right to the desktop. You could ev
Re:Modularity, "Eye-Candy", And Other Unix Geek My (Score:3)
UI folks shouldn't have to become programmers to get UI problems solved. I would much rather continue my HCI education and put all my energy in studying newer and better ways for people to get their work done with computers than learn a bunch of crud about AutoConf and Makefiles. There are people far more experienced than me who have decades of experience at making computers less confusing for
Re:Modularity, "Eye-Candy", And Other Unix Geek My (Score:3, Insightful)
Re:Modularity, "Eye-Candy", And Other Unix Geek My (Score:3, Insightful)
HCI people
Don't see why not.
wait a minute...I'm seeing a vision....Jakob Nielsen and Linus's desktop linux show
Excellent idea. Jakob's contributions are as important as Linus'.
If you keep 'screaming at programmers' I guarantee you'll continue to be ignored.
We'd get ignored no matter how we put it. Your point is?
The perfect position (Score:3, Insightful)
I think the free OS industry is in a perfect position to create a user interface that is no bound by having to look like anything.
Windows has to keep the same basic look from year to year, or they have a lot of confused users.
Apple is bound by the same strings. although the jump from classic to OSX was a big one, much of the same logic applied to the GUI.
*NIX GUIs are not bound by the same things. There is no "standard interface" other than a terminal.
Why hasn't someone invented a GUI yet that is designed by people with some ergonomic sence?
Optimally the GUI would be very configurable, as well as being appealing to the eyes, and efficient in every sence of the word.
Re:The perfect position (Score:3, Insightful)
Because the people who have the ergonomic sense are not generally people who know how to code, and the people who know how to code in no way want to listen to the people who have ergonomic sense. Ergonomists are derided, coders are lauded. Such is the way of Free Software.
Robust package management (Score:5, Insightful)
The problem came when I tried to go back, and use apt again. The entire apt system maintained its own list of installed packages with no awareness of what was actually on the system, so as soon as it fell out of sink, the entire apt manageer collapsed. My experience on Redhat and Mandrake were similar.
It doesn't have to be like this! It is possible to find out what's on a system. Does a package require python>=2.1? Parse python -V and get an answer you can trust. Do you need a library, get its version with /etc/ld.so.conf` /lib /usr/lib;do ls $i/ libraryName .so*;done 2>/dev/null | grep -v @ | sed 's/.*\.so\.//g' | sed 's/\*//g'
for i in `cat
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.
Is anybody working on this? Is anybody interested in working on this?
Re:Robust package management (Score:3, Informative)
Right. In fact an easier way to look for a library is to scan the linker cache. Look, I'll show you:
In fact, the code we use in autopackage is a little more involved:
Just use Suse (Score:3, Insightful)
Give it a shot. I had Fedora after Redhat 9.0 and have used everything from Yggdrasil, Suse, Mandrake, Redhat 4.3 through 9.0, Gentoo and others. Nothing compares. I've even used Debian and well, for a workstation, laptop and useability factor (especially on the wife) Suse takes the cake.
Thats my 2 cents
an idea... (Score:2)
*ducks*
To Bruce, wherever you might be? (Score:4, Insightful)
I think the instincts that have driven you to create a new distribution are very much correct. But let me reiterate a few things that I as a user think are important:
A community distribution that serves as an active and clear implementation of an evolving LSB that both software and hardware manufacturers can focus on.
A community distribution that honors the lofty goals that those working on Linux set out to accomplish. This means no-pear seat licensing, in fact, no onerous licensing terms of any sort. Red Hat or SUSE are to expensive for the developing world and even for small non-profits in the US, simply because they added cost of their yearly support agreements is beyond what they can pay. For the record, I am currently using Mandrake as I can freely redistribute it and the keep their security updates on a distributed network of FTP servers, the way that Linux was traditionally distributed. In summary, it is paramount to have a distribution that commits to keeping security updates for at least three years.
Bruce, don't start anew. Linux is all about standing on the shoulders of giants. So if you can adapt Anaconda or Mandrake's installer to your distribution, all the better. These are good and tested tools. The same goes for configuration tools. Borrow as much as you can. Ark Linux also looks very promising and very integrated.
Software installation is not difficult if you have the correct repositories. Preconfigure this for the user and provide a tutorial that shows them how to add new software. Adjust expectations by telling him that all software will be now available just a click away. URPMI and apt-get are great tools. Make them look pretty a la Lindows and the problem is solved.
The desktop is far more complex than it is made out to be. It's not just about email, office software and mp3 playing. It's about accounting and instant-messaging and multimedia. Let's popularize the ogg format a hell of a lot more. Let's include in the distribution's web site a list of radio sites that broadcast in ogg ( i have such a list). Let's work on getting Realplay to really open up its format as they said they would do with their Helix player. All of these things need to happen.
Finally, I think your distribution should link a lot more closely with Linux true power base: the LUGs. Work with them, talk to them, make it easy for them to promote it. Make it easy for them to be involved. A Pan-lug UserLinux forum would be a great thing. I am looking forward to the day when we can differentiate at a higher level of system design. Distribution differences, particularly on the desktop, are getting old. If you are a successful, you may lead other distributions to join forces with you. At least, I would that the smaller ones, ArkLinux, VectorLinux, Yoper and even Mandrake would.
Suerte.
Formal proposal coming up (Score:3, Informative)
I'll be off Slashdot for a few hours now, time to give Stanley [perens.com] his bath and put him to bed.
Bruce
All that, AND a bag of chips...! (Score:3, Interesting)
One of the major complaints I hear is about differing interpretations of the file system hierarchy [pathname.com]. 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' [w3.org] W3C
Bazaar for the developers, Cathedral for the users (Score:3, Insightful)
As a user, once you pick up your distro from one of the stalls of the vibrant and diverse 'bazaar', that stall now becomes your 'cathedral'. You like that shiny new app in that stall over there? Better head to your cathedral to check whether your high priests have compiled a version for you. Is that an available upgrade that you see two stalls over? Better pray that your one true distro has decided to upgrade as well. Did your high priests just take off their ceremonial red hats, don their fedoras and close your cathedral down? Too bad you'll have to find another cathedral to pray at. Sure you can try to learn the incantations and join the priesthood, or even build your own cathedral, but not everyone has the strength of will to take a vow of poverty and give up sex
Ok, ok, so I went a little overboard with the metaphor, but you get the idea. I don't know what the solution is, but I do know that users, like developers, prefer the freedom of the bazaar. It seems to me users won't get this freedom unless developers are willing to give up some of theirs.
Oh dear (Score:3, Insightful)
Oh dear, please tell me Bruce didn't just spout that old chestnut of "if something isn't there in open source, you can go code it".
I'm a mediocre C programmer and there are plenty of people who aren't programmers - the fact that I (let alone them) can just dip in and start programming some wizzy new bit of functionality is absurd.
In reality it takes 3 months of 9-5 work to become fully up to speed with the way something works, it's nuiaces, issues, problems, general fudges and other "gotchas". You can't just sit down, fire up VIM and hack yourself up a new feature.
The truth of the matter is that if he want someone to add something he either
- Makes a lot of noise in the right places and hopes someone decides to implement it
- Pays someone to implement it
and even with point 1, if the programmer doesn't ask you for feedback, the chances of you getting exactly what you what is slim.Re:could it be? (Score:3, Interesting)
Re:could it be? (Score:5, Interesting)
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
Re:could it be? (Score:3, Insightful)
Nearly all for-profit software projects have a small set of key customers. These customers dicate the vast majority of the product's content because the developers must please them to continue eating. If a feature Joe Public wants isn't on the same list these key customers come up with, Joe may not get his feature at all. Not b
Re:Best answer... (Score:2, Insightful)
But that's just my personal opinion.
Re:Best answer... (Score:3, Interesting)
Re:Best answer... (Score:5, Insightful)
The command line works more like a humans way of thinking than a GUI, for example:
$ mkdir my_files
which is pretty sensible, aside from the contraction of the words "make directory". A user wants something done, they TELL the computer what to do. IMHO this is more intuitive than, say,
right click on an unoccupied are of screen,
select create new folder,
enter name for new folder,
refresh screen to see new folder.
bah, I'm probably wrong.
Re:Best answer... (Score:2)
It Should NOT Look Like Windows... (Score:3, Insightful)
Making distributions that look and feel like Windows not only shows a lack or originality but only stands to confuse and frustrate "new" windows users in the end when something does not execute as they would expect them too only because they were lead to believe that thier experience would be "like windows"
I recently posted a rant about this on my personal website here:
http://www.phatvibez.net/commentary.php?ID=notWin d ows [phatvibez.net]
X needs fixing, or users need help? (Score:2, Insightful)
If substantial numbers of people don't understand X, doesn't that indicate the need to make X more user-friendly?
It shouldn't matter if those nine out of ten are plain vanilla non-technical people, either -- if we want to get X more used, it's got to be easy for anyone to use.
-kgj
Do you need to understand MFC or Quartz? (Score:3, Insightful)
I'm sure 9/10 Mac users don't understand Quartz, and I certainly don't understand X or the equivalently low-level bits of the Windows GUI (I said MFC in the subject line, but as
Good points (Score:3, Insightful)
Good points. Thanks for the clarification.
As for why my post got modded Insightful -- when it really isn't, in retrospect -- I can only blame the moderators.
-kgj
Re:I'd love to see this become reality (Score:3, Insightful)
Linux has a developer culture with a rich tradition and history of devaluing the user experience, demonizing the end user, glorifying that which is esoteric and confusing, and is more at home with a text-based UI. This is why after 10 years today's linux deskto
Re:Back to bare-bones? (Score:5, Insightful)
everyone I know that has been toying with the idea of switching to linux has wanted at least one of these things before switching:
1) Macromedia creation tools - maybe wine can do the trick, but not likely.
2) DirectX/game support - not going to happen until the userbase is there, and even then, it's iffy - when was the last time you saw a good game for PC? not terribly frequent, are they? nearly everyone's developing for Xbox now.
3) adobe products - some work, but just barely, though wine. not an option. gimp is not an option, because it doesn't compare. neither are all the other tools - they've got nowhere near the feature list (which is invalueable in something like premiere or ps).
4) easy to configure, and then to change their configuration, from the desktop, using gui tools - people don't really care what's underneath. they want to be able to add, remove, etc. their printers and everything else. sure, there's largely hardware support available - but it's difficult for the users t oset up due to lack of cohesive gui tools.
I hate to say it, but I'd blame X for these shortcomings, largely. Sure, it does what it does well, some might say. But it is bloated, buggy, leaky, and inadequately designed for the task at hand. It's trying to do the wrong thing.
If we had a pluggable gui TK framework with a single programming interface, instead of the individualistic layering we have now, then there'd only need to be one network configuraiton tool, one printer tool, one hardware setup tool. there could even be multiple instances of each functional tool set, all approaching it in the same fashion, but: all these tools could then use the same TK, depending on the desktop used, so that there's not a) extra memory overhead, b) extra dependency requirements, and c) an ugly, incongruous desktop. Additionally, TKs wouldn't have to duplicate silly things, like AA fonts, OGL support, and the like.
Likewise, dialog boxes (save document, etc.) should also be pluggable, so that anyone using any application can use the file navigation method that they want (or that the distribution packager decides). This way someone using GIMP would get the same
I'd say that doing this does indeed need an X rewrite, because the above illustrated design is not possible with the current TK-on-X arrangement. the current situation on the desktop is chaos, at least compared to the majority of other major functionality. With X, everything runs on top of X. With apache, the kernel, emacs, and various other mature projects, things are modular. You don't write a userland hardware driver. You don't use CGI to process PHP. It's modular.
People say "but linux is about choice", and i'd agree. However, X currently doesn't provide any choice: if the average user wants to use a graphical interface, it's a fairly safe bet that they'll be using X. In that case, they're stuck with everything: not GTK or QT, but both; that is, if they want any semblance of a desktop that's comparable to windows.
The perspective that most linux users seem to take is one of the old school unix user, even though most of them are not. "X works fine, that's what X is supposed to do". I'd agree, if the competition was Windows 3.1 w/ modern hardware support with OGL and other 'modern' features - because that's what it amounts to, in my mind. I'm not saying, "the GUI should be integral to the OS", but that the GUI is indeed integral to the desktop, and cohesion is necessary in that regard.
Apple recently realized that their OS and GUI infrastructure from the last millenium was inadequate for the future, integrating OGL into the core of the GUI, vector graphics for everything, and the like. MS has apparently realized this as well about their own products, what with Longhorn looming on the horizion, and is transitioning everything to
That's an impostor (Score:3, Informative)
The real Bruce Perens [slashdot.org] has a UID of 3872. Everyone else is an impostor.