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."
Which one is more likely to grow the most mindshare in the future? I'd be interested to hear some opinions.
Personally I think UserLinux or something like it will prevail in the end. Red Hat exercizes too much control over Fedora IMHO.
UnitedLinux to date seems to have had very little impact on the Linux user community - due to SCO's participation and the lack of unilateral support by Linux distribution vendors, most notably Red Hat.
...
Yes, having SCO and RedHat as organizations supporting your Linux project is a bit of a handicap
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Why not a linux-games CD, for example?
There are tons of games on freshmeat.
Generally linux distributions are too scared and following the SYS-V standards: init scripts, a compiler, a shell, GNU shell utils and that's it. No innovation man!
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.")
There's already tons of distributions that are focused on end users -- It's really unclear what the point of another one is. It seems like this is just an attempt to make Debian more popular by packaging it better, but it's not clear why a that can't be done by the existing Debian project.
Also, the idea that YA distro could become some sort of "standard" reminds one of SCO's "UnitedLinux" plan.
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.
I'd prefer a formal analysis of a normal proposal rather than a normal analysis of a formal proposal.
I'd rather have
a bottle in front of me
than a frontal lobotomy.
-kgj
-kgj
I am also more than a little dubious about the announced Sun-China deal and how it will really play out.
Bruce
Bruce Perens.
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.
What is missing is metastandards. Sure we have TCPIP, SMTP, FTP, HTTP ..... etc, but we are missing higher level standards that surround such activities as:
Installation, compilation, platform and hardware identification, common GUI methods to build unified desktops.
Of course I accept we already have RPMs and 'standards' in install scripts but this is not enough.
We need to establish (several) standard models
which everyone agrees is the template for a higher level organism like a 'home PC' or 'office PC'.
These 'meta-standards' should be the next place to concentrate efforts in the OSS community.
I hate to take a good discussion off course. But with all due respect, sir, you're stealing all our karma!
Windows is not what I would consider an ideal end-user experience. Why not look at the 20 years of history of the Macintosh desktop computer, as well as the more recent experience and "lessons learned" with MacOSX. Apple may have created the most beautiful and well-behaved *nix GUI of them all (not like there isn't room for improvement there, either).
Just a thought.
Bruce
Bruce Perens.
I am all for an Enterprise Debian, I think most companies would also prefer a professinal open solution to RedHat/Novell/Sun. Most developers would.
This project will obviously address the needs of it's sponsors, reading the paper it sounds like this is a for a desktop replacement for Windows, why not be more specific about your sponsors needs. As for KDE/GNOME didn't FreeDesktop address this? What is the future plans for your sponsors? How often do they wish to patch, how often do they wish to upgrade etc etc. More info.
What happens when other orgs want their version of Debian Enterprise, say an LTSP version or a MOSIX cluster? Do we have multiple Enterprise Debians?
I think you will need to be far more strict than you imagine to cut down the packages used. I'm sorta thinking a new release of debian that things from Debian-Stable get promoted from. Or indeed a subset of debian-Stable.
Why not build a testing framework as your version of Linux? Take Debian-Stable, reduce the package count to a minimum. Write the AUTOMATED test. Then anybody can write software for your system. The validation is that after they've installed their software your test framework still executes correctly. Test early, test often.
Cerifitcation will have to happen on many levels. Hardware players IBM,Sun etc need to certify your code. Infrastructure software needs to certify your code. Apps software needs to certify your code. Developer/Admin/User certification will need to be available.
Make no mistake $1m a year is not a lot of change and this is a _HUGE_ undertaking.
Click Here if you want to hear it.
Help fight continental drift.
Although we're all getting comfortable with it, I'd like to see the name UserLinux go bye-bye. In fact, "Linux" is getting to be scary word to a lot of execs, especially as Red Hat and Sun announce their pricing, which is getting up there.
I like names like MorphOS, which are much more friendly. Frankly, I'd love to see a catchy name withOUT the word Linux in the title and have th tagline be "Built On Linux" or "Based on Linux."
Does anyone else agree with that?
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?
Occam's Razor. Kiss (keep it simple stupid)
/..... and makes it simple to use. However it is intellegent, setting up the right parameters correctly, and CONSISTANTLY.
Simple is better than complex. The parent post makes this point about 5 different ways, but not quite getting to the point.
Simplify Everything. Don't make it DUMB, just simple. I will give an example of simple not dumb.
DHCP. It takes a complicated job, IP / DNS / WINS / Gateway
In the words of my dad, "Pick a lane and go!"
* KDE or Gnome Pick one
* commandlines are for geeks, not users
* Consistant AND Easy Versioning
* Pick the best in class client/app
* User Manuals in the style of "Dummies series"
* Want to do THIS, use THAT app.
* commandlines are for geeks, not users.
If LuserLinux is going to be sucessful, the GEEKS and Zealots have got to get out of the way. So what if RMS wants to call everything GNU/linux. Users don't care about such stuff. So what if Perens wants to compile his own kernel. Users don't care. The point is, USERS don't WANT to care about such things. And it doesn't matter to them what RMS, BP or whoever thinks. (and don't get me started on Emacs vs Vim, neither one are usable by users).
Users want easy to use, unbreakable, solid applications that get stuff done. Use simple defaults; default the best options MOST people need, and then hide them.
Put stuff in the background that the average user doesn't need or want to see. Translate things from GEEKSPEAK to Natural Language. "Automate tasks" instead of "Cron Job".
Providing something simple to use, yet powerful takes intellegence. Simple doesn't mean Dumbing down.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
"Hey Grandma! There's a new program I think you might enjoy called 'Foobar'. Type 'sudo apt-get install foobar', enter your password at the prompt, and tell me how you like the new program!"
"Gee Sonny.. that was swell. And I didn't even have to reboot! Here's a nice apple pie for you to take home to your mother..."
I have something in common with Stephen Hawking...
Toy Story character names are trademarked by Pixar and Disney. Disney is especially known for its legal department. We can't really make commercial use of those trademarks.
Bruce
Bruce Perens.
Click-and-install is certainly possible with Apt. If you are connected to the package repository, you should get all of the software you need to resolve any dependency with "apt update; apt-get install package-name". There have been click-and-install implenentations using this. Providing a meaningful package catalog might be more of a problem.
Bruce
Bruce Perens.
But the most important thing about installers is that they are run once. People base entire distribution reviews on the installer, which is just stupid.
I used to agree with the above statement until I had to help many newbies "Try Out" linux. Most of them had tried to install on their own, but ran into trouble. Once I got it installed, most were impressed. But some were just entirely turned off from the first impression the installer left them with.
Granted, this was a year and more ago, most distros have improved their installers dramatically; however, I would not include debian in that list.
My $0.02It would help if you could tell me specificaly what you think is wrong with the apt + front-end combination as far as user friendliness is concerned. Try answering these: 1. What don't you like about all existing front-ends. This is not to say that any of them would work for grandma, but it helps to understand why. 2. Why do you feel that the front-end + back-end arrangement is fundamentaly flawed?
Personally, I think that at minimum we need to get to a state where, like most commercial desktop OSs, you download a file which appears as an icon and double-click that to install it on your computer.
I also think it would be better if we did not have to go that far to install software. Perhaps when we reach the point where through a web interface on a site a user could signal his/her intent to use a piece of software (perhaps by clicking a link) and that software would then be downloaded, installed, and launched. It should also be easy to go back to an older version or get rid of the software cleanly.
From LinuxWorld: This is an interesting proposal because Debian has as good a technology as anyone (arguably better by many).... The difficulty of installation of applications across distributions due to conflicts and lack of supporting libraries could be solved by Debian's apt tools, which are quite superior for the installation and resolution of dependencies in comparison to rpm.
.deb package, and they really are functionally equivalent.
:-)
Can we stop being so ignorant about RPM, please!!! RPM is a packaging standard, not a delivery/dependency resolving mechanism. Please don't tell me that RPM is worse than apt-get, because you're comparing a package to a delivery mechanism. RPM is the equivalent of a
If you want to compare delivery and dependency resolution mechanisms, try comparing Mandrake's urpmi or RedHat's up2date to apt. And urpmi is arguably better than apt:
$ urpmi evolution
takes less characters to type than:
$ apt-get evolution
...and vice versa
"Have only ONE GUI. No KDE vs Gnome, just standardize on one, but keep compatibllity libraries for leagacy gtk apps until they are replaced by modern QT apps"
I really wish someone could mod the KDE control center down to "-1, troll" for using that terminology. This pointless sniping makes both desktops look bad. It's just as valid to claim that QT libraries are for keeping compatibility with legacy GPL-violating apps, while GTK2 is the free toolkit to code future apps with. (I'm not saying that QT is still a GPL violator, just that calling GTK2 "legacy" is inaccurate in the same way as calling QT "un-free")
0 1 - just my two bits
A good example would not use SourceForge, which is a giant and overwhelming repository. But I understand that your example would work with your personal web site as well.
There are really only two choices when resolving dependencies. Either package all dependencies along with the desired software, a la Windows and (I'm told) Mac, or have some sort of repository of the current package pool, whether it's a DVD or an FTP site, from which you can pull required software to resolve a dependency.
I don't really like the all-in-one-file method, becuase it makes it nearly impossible for library makers to fix their libraries. Unless, of course, the one-big-files are all coming from one central place that does active release management on them, replacing packages whenever libraries change, in which case you are back to one big repository. It also makes it more difficult for shared libraries to help you conserve memory if there are lots of different point releases of the library being used by different applications, rather than one periodicaly-updated copy of the library.
Monolithic repositories can't contain all useful software, but it is easy with apt to load from multiple repositories, where one may be specific to an application and the other is the main repository and resolves all of the dependencies of that application.
I think this is one of the things we got right with apt.
Thanks
Bruce
Bruce Perens.
IMHO, apt and apt-get are a very good solution for a command line interface. Generally speaking, apt-get just works (once the man page has been read). Sometimes strange things happen, but I've always put this down to my running unstable and there being a temporary dependency problem. Problems have always gone away when I have done an 'apt-get update' a few days later.
FRONT ENDS
I find the user interface of gnome-apt not to be intuitive and it has a different 'feel' to all other gnome programs. I find the 'seach' feature difficult to use. I liked it better when the search options were in a menu. Even then it wasn't great.
I admit I haven't really tried other front ends. Can you recommend some good ones? Perhaps selecting an apt front end could be the subject of a FAQ or HOWTO? Most 'newbies' will have to chose an apt front end early on in the piece. This is a difficult thing to do and it would be a real shame if the wrong choice was made, putting the user off Debian. Related, one of the most difficult tasks in Debian tends to be selecting a good package for a task, from the many candidates available.
Suggestion 1: Perhaps include 'subcategories' in the dpkg database? (eg admin>apt-frontends) Perhaps use 'virtual folders' in case a program covers multiple categories?
Suggestion 2: Better searching facilities for choosing packages
Suggestion 3: In general (I don't know how), come up with a way to make it easier for a user to make informed choices between packages. (Perhaps a natural language interface that suggests a package for a given task?)
APT-SRC
On an unrelated note. Do you know the status of apt-src? Does it work? Is it under active development? I'm to the stage where I would like to start tinkering with the source code of Debian, with a view to eventually becoming a maintainer. It would be really neat if I could say to apt-src: "Please upload source for all packages which I have installed, unpack it and set things up so that when I issue a 'make' instruction my entire system will be recompiled from these sources, and have exactly the same functionality as it does now"
OTHER THOUGHTS
Also, running unstable, I'm finding that my system is 'bloating'. If a dependency A->B gets changed to A->C, package C gets installed but package B doesn't get deleted. Eventualy I end up with dozens of unused pakages on my system and no easy way to find which are redundant.
Suggestion 1: Make the front end give a tree view of all installed packages, arranged according to dependencies. The user can then remove any package trees which do not correspond to desired applications.
Suggestion 2: have a second installed state, 'installed-due-to-dependancy'. When an upgrade is done, any such package will be deleted/purged unless it has to be there to satisfy a dependancy. By default packages are installed as 'installed-due-to-dependancy', unless explicitly mentioned in the command line of an 'apt-get install ...' statement. An 'apt-get remove' on a 'user installed' package, which is still required for dependency reasons, would change the package status to 'installed-due-to-dependancy'.
I apologise that these thoughts are so disorganised, but I put them down in the hope that they may be useful. Quite possibly much of what I have said is already in place and I just don't know about it (which in itself can be a difficulty with Debian).
Package management should be based centered around two things:
1 - Making it easy for the user to identify what he wants
2 - Doing whatever is necessary to make the user's desire a reality.
A good package management system needs to keep these two ideas at their very core.
Having said that, here are my proposed guidelines for satisfying those criteria:
1 - The list of things the user selected to install should be the only thing the user has to see. Thus, install by choice and install to satisfy dependency should be kept distinct (hereafter, chosen packages versus dependency packages).
2 - Any package that isn't installed by choice should be removed the moment all choice packages that depend on it are removed (reduces disk clutter)
3 - Conflicts among dependancy packages that are only needed at build time are not conflicts, just remove the package that's in the way and get the new one. A real conflict only occurs if it effects the user's chosen packages as installed in some way. This will require the package manager to be careful about build/install order, though.
4 - Don't force the user to choose between "sticking with the distro" and installing things for him/herself. "./configure; make; install" should be replaced with some kind of script that defines the package's dependencies and conflicts, and suggests a way to satisfy them before an attempt to compile is made. The suggested way(s) to satisfy can be any of the following three: 1, the name of a package that the package manager can get from the main distro; 2, a link to download the file necessary (download, decompression, and installation should be handled automatically); 3, as a last resort, instructions on where the user should go to get the dependancy, and where they should put the file once they download it (to maintain the distinction between chosen and dependent packages, the installer should say something like, "Please go to web page X, download Y, place the file in directory Z, and then press enter to continue."). Then the package list for the computer should include a manually installed section.
5 - Given the new freedom of number 4, conflicts will occur. To guard against the most flagrant ones (overwriting files needed by other files at install time), the file system will need to support metadata that describes what package a file is associated with.
6 - The user should, by default, be blissfully oblivious of what is going on in the background. No asking if a dependancy should be satisfied, only notification of conflicts. Said conflict notification should also be at the level of "_____ chosen package conflicts with new chosen package ______, what do you want to do? Install ______ and remove ______, or keep _______ and abandon installation of ______?" Then, hidden away in preferences (possibly as deep as being hidden by an advanced mode preference) should be the ability to turn on examination of the package tree, force full disclosure of what dependent packages need to be installed, etc.
At least, that's how I think a package manager should behave.
BlackGriffen
Thanks
Bruce
Bruce Perens.
Here.
I hear you can get a native, Trolltech-provided Qt 3.2 Windows free edition on the CD-ROM that comes with the upcoming re-edition of the Qt book, too, if you can't want for the above project to reach completion.
Otherwise, a decent alternative is wxWindows (not as clean and elegant as Qt, and thus requires a bit more code for a given task, but still very decent, don't worry).
Thank you.
-- B.
This sig does in fact not have the property it claims not to have.
Personally, I think that at minimum we need to get to a state where, like most commercial desktop OSs, you download a file which appears as an icon and double-click that to install it on your computer.
Just because Windows forces you to go and download a file and then run that file for every piece of software that you want to install doesn't mean that all operating systems should do the same. Different from Windows does not mean more difficult. In this case, it actually means easier:
Whenever I want to install software, or update my system, I just click the pretty icon on my desktop that's labeled 'Synaptic'. Then, after supplying the root password, I can install any software that is available in the Debian repository. No need to go download a special installer for every program that I want to install. It really is that easy.
For example, in order to update all of my currently installed software to the latest versions, it takes exactly 5 mouse clicks (two to launch Synaptic) and a password. Try that with Windows - and no, 'Windows Update' doesn't count because all that does is update Windows files - not your office suite, database server, integrated development environment, etc.
Or, what if I read about some snazzy new tool on slashdot and I just have to have it on my Debian system? Well, chances are, there's a package in the Debian repository. Fire up Synaptic, use the search, select the package, click the install button, maybe pick a few more things and do likewise, and then finally click the big friendly 'Execute' button. In most cases, that's all there is to do. Some packages require minor configuration which means there may be a question or two to answer, but that's it. Done.
Now, what about the Windows way? Well, first, I'd have to go buy, or download an installer and run it. Then, I'd probably have to decide where to install the software. If my system didn't meet minimum requirements, I might even need to go buy or download additional software to install first. Sure, there would probably be a soothing installer to watch, a progress meter or two, maybe some fancy pictures, etc. Finally, assuming everything goes well, I will more than likely have a shortcut on the desktop and a new group in my Start menu (score one for MS here). Great, all done.
But, here are the things that nobody ever thinks about:
So, in essence what you end up doing is maintaining your very own package repository just so you can be sure that you'll be able to reinstall the software should the need arise. That sounds easy, doesn't it? Hell no! But wait, Debian is happy to do that for me - and you too!
I also think it would be better if we did not have to go that far to install software. Perhaps when we reach the point where through a web interface on a site a user could signal his/her intent to use a piece of software (perhaps by clicking a link) and that software would then be downloaded, installed, and launched. It should also be easy to go back to an older version or get rid of the software cleanly.
See above. We're already there, except no need to use a web interface, the GTK+ interface is just fine. Going back to an older version? Sure. Uninstall cleanly? Do you want to keep the configuration, or nuke that too? It's your choice, but both are already possible and only a few clicks away.
The moral to this little story is: Just because you know how to do something one way does not mean that way is the easiest or best way.
When people ask me if Linux is harder to use than Windows, I usually ask them this question: Is French harder to speak than English? Obvi
After spending way to much time reading through all of the posts, I guess I want to throw in my comments and get beat-up like the fool I am!!
First, I do disagree with Bruces' comment about the installer being only run once. I might be reading to much into the comment, but the installer is one of the most important pieces of software you ship. First impressions are very important, and if the user cannot get Linux onto the computer then the game is lost. Plain and simple. You can try to argue, but if the user can't boot into Linux then what is the use.
(Remember, that most users are not all that bright!!! Just ask any tech support person.)
Second, why not use UnitedLinux as a base? Yes, it might cost some money initially but look at the rewards. Now you would most likely have a desktop that matches the servers in the important areas (compiler version, kernel version, WM versions etc). I think what UnitedLinux (minus Caldera/SCO) aims for is exactly what the desktop needs.
Third, RPM vs apt-deb argument. Dammit, it is too late for me to try to argue for/against each. Sorry. Need sleep.
(P.S. If anybody wants to contine offline, feel free to email me.)
Various circumstances:
.deb format.
.rpm or some other PACKAGE format.
#1. User wants to install app that is in
Debian already solves this fairly well.
This also works really nice for upgrading and un-installing.
#2. User wants to install app that is in
Alien does an okay job. But it would be nice to have some improvements.
Again, upgrading and un-installing are handled.
#3. User wants to install app from tarball WITHOUT changing any of the tarball defaults.
Instead of using make and configure, why not have another app that calls them BUT monitors and RECORDS what was installed and where it was installed?
This will allow the app to be UN-installed, cleanly. But upgrading it will be a hassle.
#4. User wants to install from a tarball AND wants to change some of the defaults.
This looks like the hardest situation to handle. I don't know if there is a way to make this a "one-click" install.
But then, anyone wanting to do this is probably advanced enough to be able to handle it on their own.
Remember, a package management system should be able to INSTALL a package, UPGRADE a package, VERIFY and FIX a package, and UN-INSTALL a package.
Debian does VERY WELL with package management, but that is mostly because of the community that the maintainers belong to.
When you get away from that community (installing from source), you lose those benefits.
I think there are too many variables to be able to handle every case of installation from source code correctly (install, upgrade, verify, fix and un-install while allowing for a custom installation).
Instead, can we provide for the other cases and just issue a warning/notice that, since the installation was not done via a packaged app, the system cannot upgrade or verify/fix the app but can only install and remove it?
I think that will still give you an advantage over most Windows desktops.
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!)
apt-get install --file
Sometimes you want to install a .deb that doesn't exist in any repository, but depends on packages in Debian. apt-get won't help you, so you use dpkg --install. But dpkg doesn't satisfy dependencies so you have to do it yourself.
It seems to me that apt-get is missing a simple and useful feature. Am I missing something?
Fuck the system? Nah, you might catch something.
You know, this stuff comes up on Slashdot every so often -- someone notices that Linux is difficult for Grandma to use and suggests that we do something about it. There are lots of people who would love to see Linux take down Microsoft on the Desktop.
When talking about how this should be done, invariably a bunch of people start talking about GNOME and KDE and about making everything a GUI and making it work more like Windows, because that's what users are migrating from. And lots of folks start critisizing what we have currently, saying things like "we must get rid of the command line" and "geeks and zealots must step aside".
To produce a Grandma-oriented desktop, they may be right. But here's one big problem with what they say, and as I see it, it's insurmountable.
Linux is written by geeks and zealots. And the tools (GNU or otherwise) that come with it are too.
I am a geek, and a zealot, and I develop free software. I'm just one example. Most of us are. We are technically minded, and critical of windows. We like the command line, we like text files, and we like to argue about emacs and vi. This isn't just a steryotype -- it's the truth.
Mind you, I'm not talking about Linux users now -- I'm talking about developers. There are an increasing number of not-very-technical users out there who see the benefits of Linux and want to share it with their even less technical friends. And they see our UNIX/command-line/text files/geek/zealot philosophy as a barrier.
They are probably right.
The problem is, that 90% of these people do not write software. As ESR said, every good work of software starts by scratching a developer's personal itch. Not by scratching a user's personal itch, but a developer's. The problem is that users (who, on Linux at least, are increasingly normal folks) and developers (still primarily geeks/zealots) do not see eye to eye on any of this.
I'm sorry, but frankly speaking, the interesting problem to me is not a consistant UI written for grandma to use, but a UI that does what I want. I might put together a GTK front-end and even follow the GNOME usability guidelines or the like, just because I like having a sense that I'm doing something "the right way", but that's the extent of it. If someone wants user-friendliness badly enough, they can send me a patch, and I'll include it -- that's ok.
But I don't have a lot of time to begin with, and there's no way I'm going to spend it doing stuff that I don't care much about. I'm happy with linux the way it is now. You don't agree, and that's fine, but the problem is that you are asking me (a developer) to write you the stuff you want.
Hat's off to the GNOME and KDE developers for caring about this stuff; I salute them. But there aren't enough people who really, really, passionately care about UI programming in the Linux world. It's that simple.
The closed-source model (like Microsoft or Apple's) works well in this regard because the zealots they hire are getting paid to write code they probably don't care much about, under the direction of PHBs who are basically normal folks with normal concerns.
But until the 100,000 Slashdot-reading linux users stop making wishlist requests and begin coding themselves, they probably won't see their personal itch scratched.
This is the open source framework, friends. Either code, or live with things the way they are.
I don't know if bruce is still reading this story or not, but here is my comment on his initiative after reading his draft. First of all, we all agree for the need for a UserLinux. SuSE/Novell and RedHat as you mention are now lock-in situations. I also think that most of the community agrees on basing the whole thing on Debian. It is a true and tested ditribution, that works. Criticism to Debian ofcourse is valid, woody installer isn't great, and debian stable is out of date. But that doesn't mean that UserLinux should also face these disadvantages. I personlay like Anaconda very much, I think it's the best installer for any OS now a days. I don't know of your relationf with Ian, but I encourage you to work with progeny and their port of Anaconda on Debian. While I have also tested the debian-installer for sarge (beta 1) my vote still goes with Anaconda. Anaconda can be UserLinux's installer, and put an end to the installer issue for good. As for being out of date, well UserLinux can address this, like Libranet has addressed it, by upgrading some packages to their testing/unstable version. But this process should be done carefuly, so that the distro still works with Debian apt's repositories. I find the argument of 'Why don't do all these inside the Debian project" a valid argument. But your answer for a need for the Debian to work with for-profit organizations also seems valid. The whole thing sounds good to me. UserLinux can be an umbrella project for Debian/SPI, in which debian produces the core system, and UserLinux builds on top of it. Slecting from competeing packages can be a painful task, but you have to face it. Bruce, tell me if you have ties with Progeny, and if they are interested in working with you/User Linux. I personlay don't like the name UserLinux, I propose Debian Enterprise GNU/Linux (if Debian can accept it) or GoLinux (if the name can be cleared). Also, you seem to think $1M is a lot of money. Well, it is, but not for the task that you are going to face. The FLOSS community needs people like you Bruce. I am proud of you, and proud of the work you have done. Good Luck with UserLinux, hope it becomes another success.
--