Slashdot Mirror
UserLinux Proposal (And Analysis) Now Available
Lucky writes "Bruce Peren's idea for UserLinux was much discussed on Slashdot some weeks ago; however, there was no formal proposal. Linuxworld is running an analysis of the proposal and links to the first draft."
I'm not stuck on the UserLinux name, and would listen to alternatives. I proposed gnUserLinux, but RMS didn't like it! He feels that having the GNU up front would signify that it's an FSF official project. UserGNULinux doesn't roll off of the tongue quite as easily.
I'm wondering why these ideas just can't be incorporated by the Debian project itself. They have a desktop subproject, why not just rally around the Debian banner ?
"Based on Debian" is great, but why not convince the project itself that this is the direction to go? Wouldn't this do nothing but improve the distribution? Who would be against that?
* GUI everything: If it's not a system crash, the desktop PC should be able to handle everything in GUI. Perhaps console programs that have a GUI counterpart (you run guiFdisk and you get a pretty "partition magic" type interface, but the real work is done by fdisk). Both parts would probably need to be written together for this to work seemlessly.
* Look to Windows. I hate to use them as a Linux standard, but seriously! If Microsofts 'Distribution' can do it, UserLinux needs to at least take note of it. Where Microsoft is criticized, Linux in general needs to be careful. I'm not just talking about critisism FROM the Linux comunity, but major distributions need to keep tabs on what excites/displeases regular win23 users.
* I don't know enough to comment on how the system should keep tabs on packages, but it would be nice to be able to make sense of dependancies. This isn't a specific recomendation, just a general thought: remember the "device manager" tree in Windows, something like that with at least two tabs. One would have at the top level only packages that have no dependancies. The next level would be packages that directly rely on them, and then the packeges that rely on them, and so on. The other tab would work the opposite direction, starting with a list of all packages and branching into the packages that they rely on. Perhaps the user would even be able to click on a package and get more detail. Something of this nature would allow users to get a sense of 'whos who' among their packages.
* Shoot for the next generation Linux, but do it while aiming at a more distant target. It would be very nice if 20 years from now UserLinux was not a hack upon a hack to keep it up to date (not suggesting that anyone else is).
* Don't lose track of all the user input. This is probably reduntant for me to say, but I'll say it anyway. Michael Collins who rode Apollo 11 wrote in his book "Carrying the Fire" that he kept a notebook and everytime something ocurred to him about the mission he would write it down. If he was in a resturaunt, he would write it down on a napkin, take it home, and copy it into his notebook. He refuse to launch until every concern in his notebook was checked off. Keep track of all good user input in one place.
Finally,
GOOD LUCK!!!
("You're going to need it.")
I think part of the point of UserLinux, and standards in general, is just to tip the scales when less involved developers make choices.
When I'm developing software I frequently come to a decision point where there's multiple protocols, implementations, or standards I can support. I often (usually!) don't care about which one I use, so long as it's not insanely bad. For example, I don't care where my program's files go, so long as I can find them. I don't care what port I use, so long as it doesn't conflict with other programs. I don't care about the file format, but it would be nice if other tools could handle it. And so on.
Standards make it easy to make a decision in these cases. Because lots of decisions are important but not useful. Let a standard committee figure it out for me -- whatever important details there are that I don't understand, they can think about those. And when they are done, they don't have to present a justification of why they are right -- they just have to tell me, the developer, what I'm supposed to do.
Competition can be useful. But only when it's interesting. I know, things that are interesting to one person aren't interesting to another. I don't care about exim vs. postfix vs. qmail, but I'm sure there are people who care very much. I guess part of a standard is a way of making both of those possible -- making it so I don't have to care (because they all talk SMTP) while another person can make decisions that are useful to them. Of course, SMTP is only a start -- I like /etc/aliases too, because it's easy to understand, but it's also limited. A growing standard might extend that -- and well it should, because having a single way to express aliases would be very useful. In this way a standard can grow, and slowly pick off the pieces where useful diversity doesn't exist (only annoying diversity).
I think UserLinux could be successful if it finds low hanging fruit first -- standardizing boring things, where the participants are easy to convince. There might be things that are more useful to standardize (like a GUI toolkit), but down that road leads certain failure.
Don't throw every application into it. As a counter-part to the "gui everything" I think its important that we at some point have a distribution that's is fully and transparently integrated. No more merely cobbling great products together. Success will mean true consistency, maybe then the rest of us will see that its not all that bad.
Quack, quack.
Here's how I understand this project: UserLinux is not meant to build a whole new user-friendly distribution.
The purpose, it seems to me, is to apply the distributed, free development model of Linux to services. To prodive a large community of low-to-zero cost consultants who can answer questions, provide fixes, and write documentation.
The target, I'm assuming, is that grey area between home kernel hackers and enterprise-size corporate entities.
It's for the groups who can neither hack things themselves, nor pay large amounts of money to purchase a contract and site licenses.
An example would be, say, a non-profit organization that would like to use Linux, but does not have any programmers on board, and has a very tight budget. They need support if they're going to use Linux, and this is one way they can get that support on a budget, while still possibly contributing back into the Linux community (either financially or with bug reports, etc).
This is my reading of the paper. I may be wrong, but if I am right in my interpretation, I think that this is a brilliant idea.
Richard Stallman thinks so, which is why he opposes proprietary software. No proprietary software, no problem. This is where Richard and I differ somewhat. I think that proprietary software and Free Software should exist together on a level playing field. And personally I am much more interested in working on Free Software.
The Troll Tech folks chose (with a great deal of prodding) to use a GPL + commercial dual-licensing model. They do this so that they can support their families while making good Free software. This is something that we can respect. They don't have to facilitate proprietary software while making the free stuff. They can choose to make money off of proprietary developers.
The only question in my mind is whether we need to make the same choice. Somehow, GNOME (or should I say GTK) got made without dual-licensing.
You may be trying to say something in favor of BSD-like licensing. In that case, I think you should consider that this argument has two sides, and that it is too often seenn only from the standpoint of the person who recieves free software, rather than the person who creates it.
Bruce
Bruce Perens.
Well, I don't agree with your criticism of Debian.
Therein lies the downfall I think Bruce.
Reading through your white paper, I agreee entirely with your analysis and proposals. We desperately need something like this, but a Debian base and iterative development with that project is not going to fly. I think that you have a tendancy to overlook the shortcomings of Debian and that you don't appreciate that the corporate market has little use for Debian-obsolete and Debian-broken.
Further, to get buy-in from the current Linux install base, you need to be offering a viable alternative to the distributions most are accustomed to. Current Redhat users are ripe for conversion, but not if it means a step backwards to Debian-by-another-name.
It strikes me that one of your unstated objectives is to revitalised Debian. If Debian is suitable for your stated objectives out of the box, why is it that you are proposing a new project, as opposed to working inside the existing Debian framework?
I was the second Debian project leader, and took the project through a very critical time. During that period I was responsible for:
- creating the social contract
- creating the official CD policy
- building Debian from 60 developers to 200
- releasing the first ELF version of Debian - it was previously COFF and LIBC5-based
- transferring all of the base system packages to community rather than centralized development
- founding SPI
- no doubt lots of other stuff that I've forgotten
These are possibly the most fundamental changes that Debian has ever gone through. During or subsequent to that, II don't have to prove myself.
But I agree that now it's time to do the work.
Bruce
Bruce Perens.
No, in windows you ship your program with everything it needs in a whole bunch of .DLLs that will cause havoc if messed with. This is all dumped together in a directory so that you end up with the same dlls all over the place a couple times. Now ask yourself:
- Does that matter to grandma? no.
- Does it fill grandma's hard-drive? no
- Does it work as expected? yes
- Is it easy? yes
It's not perfect but it's better that sudo'ing to install stuff you've hand-compiled....
We need to make it as easy but less evil (no libraries sitting everywhere!)