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."

Comments

Re:UserLinux vs Fedora

[FubarPA]

I think UserLinux has some potential. I'm very interested in seeing where it's going to end up. Using Debian as a base seems pretty good from a package standpoint, but I can see some heated debates revolving around which desktop environment will be deemed "standard". Personally, I use a mixture of both Gnome and KDE apps, but I run Gnome as the DE. I'll be keeping an eye on things, and I think if done right, UserLinux will overtake Fedora in the future.

Re:UserLinux vs Fedora

[Bruce Perens]

No, it's a fair criticism. But since we're basing on Debian, I think you can say that it exists, and for longer than Red Hat has existed.

Bruce

Is this another distribution? What's the point?

[Anonymous Coward]

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.

Re:Is this another distribution? What's the point?

[Anonymous Coward]

Bruce,
I think what you are trying to do is great.
I am new to linux about a year in after a year with M$ products. I started with RedHat 7.3 Bible. I now have RH 9 and Slack 9.1
My way of helping was paying RedHat 60$ a year to be told 6 months later that my money was no good.
I have tried about every distro out there.
Knoppix is great. I installed Debian but got frustrated trying to configure X. I am sure I can do it now but Debian is so out of date and broadband is not available where I live so upgrading to unstable is out of the question.
I payed RedHat even though I didnt use thier servers to keep my system updated instead I used APT. It works much better than up2date does espesially on dailup where you lose that 90% you have dowloaded when the connection dies. With APT it starts back at 90%.
Anyway what I am trying to say is that I hope that my next distro is UserLinux or whatever you all decide on for a name.
Good Luck and keep up the good work.
Ron Watts

NotYourLinux

[Anonymous Coward]

UnitedLinux, UserLinux, Fedora (community) -- add this to the many other linux distros and it becomes a bit more daunting.

I understand the task is to unite all the distros so we can get inter-distro compatibility and all that. There's hope that it works out. Because I'm such a nice guy, I'll offer this:

KDE 3.2, APT as the package manager, Oo.org as the office suite, mplayer, xmms, k3b, mozilla (firebird), evolution, and most importantly, frozen bubble.

So standardize on that! Oh, relax. I could've said Lindows.

Re:UserLinux vs Fedora

[spacecowboy420]

I like both "DE"s, but prefer the applications that kde has, and since functionallity is the ultimate goal, it is what I use. On the other hand Gnome does stuff better than kde i.e. context menus on panels, so I am torn. If the advantages of both were integrated, we would be on our way. Instead we have 2 not quite right options. I really don't believe it would kill the innovation of "DE"s if one was focused on, people will always want a choice. Even windows has litestep etc.

Ideally we use a version of Gnome, with many of the kde apps integrated out of the box without going the way of ximian desktop and hiding the functionallity normally available. Ultimately, the advances made in one enviroment will advance the other as well.

Just my $00.02

Need Meta-Standards

[Anonymous Coward]

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.

Re:How about just "Debian"

[Bruce Perens]

Well, I don't agree with your criticism of Debian.

First, installation is being adressed. The currently-released installer is a rewrite of one I made in 1996 or so. It was great for 1996. I wrote Busybox for that installer, by the way. The new installer being tested for the next release has positive reviews. There is also a port of Red Hat's installer.

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.

Debian has Perl 5.6 in unstable at the moment. I don't know if 5.8 is very different, and what the Perl maintainer has to say about it. Why not ask him?

Unstable gets security updates to the main branch, rather than to security.debian.org . Security.debian.org exists because of the need to bypass the release management for stable to get fixes in immediately.

Regarding the security record of various distributions, I don't think the commercial ones will tell us if they are hit, unless it becomes obvious from outside. Who knows how often they have been compromised? Gentoo just announced a compromise, perhaps based on the same brk() bug.

The really impressive thing about the Debian breach was that it happened at 5 PM, they had detected and confirmed a breach and had the sites shut down by 10 PM, they announced the breach at 10 AM, and they did the forensics and found an unsuspected exploit within about a week. I dare you to show me a commercial Linux distribution that has been that timely.

Bruce

Gnome v. KDE

[Bruce Perens]

One nice thing about GNOME is that a commercial license is not necessary to write and distribute a proprietary GNOME application. That makes the customers life easier.

Bruce

Re:Gnome v. KDE

[Anonymous Coward]

If IBM, or someone with deep pockets like them, wants to make a really valuable contribution to open source on the desktop, they should consider buying TrollTech and moving Qt to LPGL or a dual license with LGPL as the option instead of GPL. Then maybe we could put and end to this silly desktop war. Its gonna kill us on the desktop in the long run.

You can grind on the premise that the competition is great but for your core desktop, just like your core kernel its really not.

Application developers who want to write well integrated applications for a Linux desktop shouldn't be subjected to a choice where they have to:

- Pick one and screw the other half of the user community in an already small user base.
- Pick one and have their app look and work piss poorly on the other desktop.
- Write two complete GUI's for their app to keep both halves happy with a huge increase in development, testing and documentation burden.

This is not a handicap Microsoft or Apple suffers (though Apple is close due to their transition from Classic to OSX).

The massive duplicated effort going in to basic desktop technology would be much better spent moving forward applications that users could benefit from.

Lord knows I've written some GTK UI's over the year but its simply not strong enough to be a serious contender against Windows and Mac desktops. Another key indicator is to look at the early strength of Qt on devices. We REALLY want the same desktop standard on the Linux desktop and devices just like Windows and WinCE.

Re:Gnome v. KDE

[abigor]

Marginally so. Even the smallest shops traditionally pay for tools (MSDN subscriptions, emulation software for embedded systems, whatever), not to mention paying for copies of the actual OS they develop for (Windows, proprietary Unix.) Paying for a tookit such as Qt won't burden a shop with more costs than they would normally have.

Re:Gnome v. KDE

[Balinares]

Wicked! I get to catch no other than Bruce Perens himself posting a sizeable but subtle fallacy. I suppose that I get to really feel cool now, in a geeky sort of way. Anyway. Apologies, Bruce, for I strongly doubt you did it on purpose, but here it goes!

> One nice thing about GNOME is that a commercial license is not
> necessary to write and distribute a proprietary GNOME application.

*clears throat*

"One nice thing about paper and pencils is that a pricy PC is not necessary to design and write loads of code."

I mean this seriously, and this says nothing either for or against paper and pencils as opposed to computers.

Only, well, in both cases, the right tool will simply save enough time to make the cost well worth it.

And before some excited kid mods me down for daring to disagree with Bruce, let me tell you that if you've never used paper and pencil to design a piece of code you just thought up where no computer was at hand, you don't deserve your /. geek points.

Different tools work well in different circumstances, that's all. Deal.

And in this specific case, it is not unlikely there's a reason why one of the Linux desktop environments has more proprietary companies developping for it than the others.

Food for thought, I hope.

(Having karma to spare is a nifty thing, you get to speak plainly and maybe get people to think. That's way cool.)

Bali out.

Re:Gnome v. KDE

[Bruce Perens]

I can't change the fact that you need a computer until I can replicate matter the way I can software. When I can, I will make Open Source designs for material objects. Meanwhile, see the folks at OpenCores.org and the CNC machining crowd.

I can change the fact that you are required to pay money to distribute a proprietary application. And I have to weigh the advantages and disadvantages. One of the articles you presented was an exposition of the difference between writing for GTK in C and Python and Qt in C++. It seemed a little apples-and-oranges, since nice C++ interfaces are available for GNOME.

If you want to talk about the proprietary companies on GUIs, you might consider that HP and Sun do that on GNOME. Even on their Unix platforms.

One of the things I'd like to go for is the principle of least surprise. Having a set of development libraries that are all cleared for producing and distributing proprietary applications would be least surprising.

Bruce

Re:How about just "Debian"

[Bruce Perens]

Well, the fact that I am ex Debian Project Leader, a member of the SPI board (Debian's corporation) and Debian's representative to some standards groups means that the bridge already exists, doesn't it? My task is to extend that bridge to the business people who participate in this.

Bruce

Re:UserLinux vs Fedora

[omega9]

• My father is an axe murderer. As his son, I am based on my father. I would like the chance to be my own person, and don't enjoy meeting people who hold me in a certain light because of my fathers image.
  
• I base all my financial decisions on what I believe Warren Buffet would do. Since my decisions are based on his, I should expect to soon gain millions of dollars.
  

You cannot hype UserLinux simply because it's based on Debian. While there's weight in where you came from, you have no choice but to prove yourself. We've all had plenty of time to become familiar with Debian. We've all had plenty of time to become familiar with the horde of other distributions based on Debian. We know what's been done and what's possible.

You could have made mention that you believe you have strong potential because you're based off a distribution with a longstanding reputation. But in two sentences it appears you've demonstrated that your zealotry for Debain can outweigh your vision for what could be best for the community.

Debian exists. UserLinux does not. At this moment anything and everything related to Debian has nothing to do with UserLinux until you stop writing theory and start producing product.

The Name UserLinux

[sethadam1]

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?

Re:The Name UserLinux

[jumpfroggy]

While neat, this idea seems counter productive. The point is to create a *brand* around a product, so that enterprise users can trust in both. If we didn't need a brand (ie. a name they trust), everyone would simply choose the best product and go. Which they're not doing yet.

Linux is something even businesses know now. If you remove that from the name, you've just eliminated an asset. It's like the choice of debian. It's not just the technology, but also the fact that debian has a great reputation (I've never used it, and I already feel like a fan simply from what I've heard... someday I'll try it if I ever throw out Slackware). So while putting "Linux" in the name may be cliche nowadays, it also makes too much sense to change simply for personal taste.

While it would be really fun to give it a neat name (Like nemo, or Oliver, or Crush the OS), this product is being made to fulfill the needs of the enterprise. So throw linux in the title and give it a nice professional logo. And make it work.

... That having been said, who's for naming it Nemo? Anyone?

Toy Story names

[Bruce Perens]

A note about the Toy Story names used for Debian versions. They are working titles within Debian, rather than the names of real products. The released products have version numbers rather than names of Toy Story characters.

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

Re:How about just "Debian"

[rifter]

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 think what you are going for is that using the system is more important than installing the system. But honestly, OS installers are very important, especially when evaluating for the home user. Most home users have never installed an OS, they got one with their computer. Besides, ease of use with Linux is usually less a function of the distribution itself and more a function of the environment (eg GNOME, KDE, etc.) which are essentially the same for all distros.

Package management is a problem which, IMHO, still needs solving. There are several package management schemes but only debian and the source based distros appear to have mostly killed the dependency monster (it still rears its ugly head in various ways). Both are fairly simple to use, but still not ready for Grandma.

I think that a user linux system should strive to be easier to use and administer than the current crop of commercial operating systems. I think that installation of the system itself and the software are going to be lynchpins in this process. Most users spend more time doing these things than performing any other administration task. Existing technologies will probably provide a good framework for this, but the key to usability is interface interface interface. I think all OSs have a long way to go in this area, quite frankly, not just Linux.

RPM vs. apt - DUH!

[ajboyle]

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.

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 .deb package, and they really are functionally equivalent.

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

:-)

Re:Distributions too conservative

[aardvarkjoe]

only 75% of which are free (as in speech), and 95% of those 75% being crap.

There was a time when the "1000 Game" shareware cds did well enough. There are plenty of open source games that are better than those games. Finding enough interesting and fun games to fill a CD would be easy enough.

It would be rather nice to have them collected on CD, along with all the libraries that they require. It's fun to browse happypenguin occasionally and try out a few new games, but far too often I take a look at the installation notes, realize that I would need to download and install ten different libraries to play the game, and promptly delete it. If somebody was to do that legwork for me, they would have a product worth marketing.

Re:How about just "Debian"

[rgmoore]

What we need is a better package management system that even grandma could use. Is UserLinux going to try and solve that problem or just slap a frontend on apt and call it good to go?

What's wrong with apt or portage (or yum for that matter) other than their UI? They do an excellent job of the essential function of a package-management system, which is resolving dependencies and installing or uninstalling the packages that need to be added or removed. The biggest issues for a good UI would be presenting a reasonable list of possible packages to be installed (which actually is a biggie) and configuring the packages when you're done installing them (which is also a biggie). (I actually think that portage will always have problems with the "Grandma test" because of compile times, but I'll set that aside for the time being.)

As a practical matter, I think that the issue of presenting a list of packages (at least in "Grandma mode") is solvable by using a coarse granularity of packages. If the options are "Basic Desktop", "Business Programs", "Software Development", "Mail Server", etc. rather than individual programs then it should be possible to list them all in a reasonably sized UI. Configuration is harder, but Bruce has already mentioned that it's likely to be one of the big thrusts of the development process. A combination of sane defaults (so that most users don't have to change anything) and maybe auto-running the appropriate GUI based configuration utility on installation might help to solve this kind of problem.

Your legacy is my preferred desktop

[Cid Highwind]

...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")

Re:Need more specific complaint

[femto]

APT/APT-GET

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).

Re: Package Dependency Managing

[BlackGriffen]

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

Re:Debian is a show stopper.

[Bruce Perens]

Well, if you are just going to say people don't want "debian-obsolete, debian-broken, and debian-by-another-name" without any supporting reasons, we're not really having an argument, it's just abuse. Try to put a logical argument together.

Why not do everything inside of Debian? Because Debian is a non-profit, and needs the synergistic relationship with for-profit engineering and service providers to achieve the goals I am proposing.

Thus, I had to design a structure with Debian at the core, but which is a superset of Debian.

Were I starting with a for-profit, I'd have had to design an independent non-profit at the middle and a number of competing for-profits. Fedora fails the independence test, if you were wondering.

And before you accuse me of wanting to revitalize Debian, you should attempt to make a case that it has lost vitality.

Bruce

UnitedLinux???

[deKernel]

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.)

Something else?

[khasim]

Various circumstances:

#1. User wants to install app that is in .deb format.

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 .rpm or some other PACKAGE format.

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.

Rule of design

[Anonymous Coward]

The best rule of design that I know of is the following.

1) Create 10 potential users of your application
2) Give them each a name, an age, some ability, etc.
3) Role play some design decisions with all of them
e.g. Bob the geek likes ultra control over everyhing and really likes this part of that app
Lisa the art major prefers to be directed, i.e. less options, more depth
4) for each design situation you need, rate the happiness of the users
5) find the target user, the target user is a user where when he is very happy about a design choice, all the others are at least ok with it (nobody hates it). Let's call her Julie.
6) Design everything for that user from now on. Don't worry about anyone else.

If you can find a target user then it turns out that you do please everyone, i.e. you don't have anybody which hates a decision. They might feel it's not the best but they are at least ok with it and can recognize that it makes others reall happy about it. It sounds like the holy grail, yet it happens often in practice: the carry-on was built and designed for pilots and no one else, yet everyone likes them.

Bruce, find that target user. When you do, you can beat any and every commercial distro.

Re:Need more specific complaint

[Mawbid]

One thing I don't get is why apt doesn't allow something like:
apt-get install --file ./somepackage.deb

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?

Re:Debian is a show stopper.

[oob]

Why not do everything inside of Debian? Because Debian is a non-profit, and needs the synergistic relationship with for-profit engineering and service providers to achieve the goals I am proposing.

Ah, I think that this is the crux of the matter. You are not proposing a free distribution suitable for the enterprise that happens to be based on Debian. Rather, you are interested in creating a veneer of corporate respectablity for Debian; an arduous task, given the culture of Debian and it's shortcomings (which you of all people don't need itemised.)

Here's the thing; I really need a User Linux option, so do other people. You have identified this need. My proselytizing in corporate environments currently has to be Suse or Redhat for the server and the desktop for the obvious reason- Oracle (and like companies') certification causes these two distributions to be the only option in the data centre, with the trickle-down effect that it makes sense for me to push out the end user versions of these products to developer workstations. That they are easy distributions to install and maintain and contain recent software is a bonus that means the transition for users unfamiliar with the platform is smoother - the value of which should not be under-estimated.

Oh for an alternative! Unfortunately the equation you offer is chosing the lesser of two evils; RHE/Fedora | Suse E/Suse or UserLinux/Debian. I think that Debian is the major distribution least suitable for the corporate environment, and I don't see that changing in a hurry. For the forseeable future the decision is no contest; people like me simply do not have the time to mess around with Debian because we happen to share an ideological affinity with it when our employers demand best-of-breed.

Though I hope you prove me wrong.

Way to go Bruce

[a.ameri]

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.