Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Debian Linux Business Operating Systems Software

UserLinux Proposal (And Analysis) Now Available 367

Posted by timothy from the good-work-in-progress dept.
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."
This discussion has been archived. No new comments can be posted.

UserLinux Proposal (And Analysis) Now Available More

UserLinux Proposal (And Analysis) Now Available

Comments Filter:

  • UserLinux vs Fedora (Score:4, Informative)

    by Steve 'Rim' Jobs ( 728708 ) on Wednesday December 03, 2003 @05:37PM (#7622856) Journal
    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.

    • Re:UserLinux vs Fedora (Score:2, Interesting)

      by FubarPA ( 670436 )
      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.
      • 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 Gnom

        • Gnome v. KDE (Score:5, Interesting)

          by Bruce Perens ( 3872 ) * <bruce@perens.com> on Wednesday December 03, 2003 @06:29PM (#7623340) Homepage Journal
          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 (Score:3, Interesting)

            by abigor ( 540274 )
            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 (Score:3, Interesting)

            by Balinares ( 316703 )
            Wicked! I get to catch no other than Bruce Perens himself posting a sizeable but subtle fallacy [m-w.com]. 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

            • Re:Gnome v. KDE (Score:4, Interesting)

              by Bruce Perens ( 3872 ) * <bruce@perens.com> on Wednesday December 03, 2003 @11:01PM (#7625263) Homepage Journal
              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:Gnome v. KDE (Score:3, Insightful)

                by Balinares ( 316703 )
                > 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.

                Maybe it -seemed-, yep. Unfortunately, it -is- not, as clearly expressed in another of the articles I presented, that from a Rosegarden developper, written after he switched to Qt/KDE from GTK/GNOME-with-C++. Interestingly, you'll note that the GTKmm maintainers didn't understand
        • I've always thought that the solution would be to write library that used gtk as its core and have a qt api. That way you could compile kde apps against this qt-gtk library and it would be integrated with gnome instead of kde.

          I'm not sure how much work it would be (I assume a lot), but I think it will eventually be done.

  • UserLinux is bound to do better (Score:5, Funny)

    by Rosco P. Coltrane ( 209368 ) on Wednesday December 03, 2003 @05:40PM (#7622885)
    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 ...

  • Distributions too conservative (Score:3, Insightful)

    by Anonymous Coward on Wednesday December 03, 2003 @05:45PM (#7622932)
    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!

    • Re:Distributions too conservative (Score:5, Informative)

      by Rosco P. Coltrane ( 209368 ) on Wednesday December 03, 2003 @06:00PM (#7623078)
      There are tons of games on freshmeat.

      only 75% of which are free (as in speech), and 95% of those 75% being crap. Which leaves you only with a handful of really promising open-source games, and 2 or 3 really good original ones (that excludes Doom, Heretic, Duke3D, Quake and other previously-commercial-but-look-how-nice-we-are-we- released -the-source-code-to-you-guys kind of games).

      Not much to make CDs out of really.

      • Re:Distributions too conservative (Score:2, Funny)

        by Anonymous Coward
        Minesweeper runs exceptionally well under wine, could that be be included?
      • 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

  • How about just "Debian" (Score:5, Insightful)

    by reaper20 ( 23396 ) on Wednesday December 03, 2003 @05:45PM (#7622935) Homepage
    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?

    • Re:How about just "Debian" (Score:5, Informative)

      by Bruce Perens ( 3872 ) * <bruce@perens.com> on Wednesday December 03, 2003 @05:48PM (#7622973) Homepage Journal
      Our goal is to get everything we do into Debian. Sometimes, Debian might not want it, or the package maintainer may be slow to accept it. So, I think we will end up having our own repository for fixes. But if we are unable to get Debian to take stuff, it is more expensive for us to maintain - we have incentive to work with Debian.

      Thanks

      Bruce

      • It seems to me that an obvious example of this would be your idea of having more automated configuration. You suggested having a sort of configuration metapackage that had the primary package as a dependency and then did the work of configuring the primary package after it was installed. Debian might or might not want such a thing as part of their system, so it might be necessary to maintain it separately from the main Debian tree.

        I'd assume that some of the ease of installation could be handled by a si

  • My own humble suggestions: (Score:5, Insightful)

    by Steve 'Rim' Jobs ( 728708 ) on Wednesday December 03, 2003 @05:46PM (#7622946) Journal
    * 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'd like to add.. (Score:5, Insightful)

      by msimm ( 580077 ) on Wednesday December 03, 2003 @05:59PM (#7623076) Homepage
      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.
    • GUI everything: If it's not a system crash, the desktop PC should be able to handle everything in GUI.

      Gosh, no. Not even Mac OS X does that. All you need to take care of in a GUI are the tasks that normal users are expected to do. Advanced users, developers, and administrators can cope with more complex interfaces. I think the more important task is to make it a good GUI, which is very hard. Imagine a UI that can allow a novice to configure a firewall or mail server correctly.

      I don't know enough to comm

    • * 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.

      Mandrake already does this ....

      Just yesterday I setup my friend's scanner, TV card, and got his networked windows printer working in linux via *purely GUI

    • What about Mac BSD? (Score:2, Insightful)

      by Anonymous Coward
      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.
    • 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 sho

  • Is this another distribution? What's the point? (Score:3, Interesting)

    by Anonymous Coward on Wednesday December 03, 2003 @05:49PM (#7622980)
    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? (Score:5, Informative)

      by Bruce Perens ( 3872 ) * <bruce@perens.com> on Wednesday December 03, 2003 @06:03PM (#7623105) Homepage Journal
      Please read the paper [userlinux.com]. That will explain something of what I am trying to do. The main thrust is not a radical improvement in user-friendliness. The "User" in the name is due to the user-supported nature of the economic paradigm I am proposing.

      Bruce

      • Re:Is this another distribution? What's the point? (Score:5, Insightful)

        by dominion ( 3153 ) on Wednesday December 03, 2003 @06:47PM (#7623521) Homepage
        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.

  • Give me a standard, any standard... (Score:5, Insightful)

    by Ian Bicking ( 980 ) <ianb@@@colorstudy...com> on Wednesday December 03, 2003 @05:51PM (#7623003) Homepage

    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.

    • Need Meta-Standards (Score:2, Interesting)

      by 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'.

  • My suggestions. (Score:4, Insightful)

    by Anonymous Coward on Wednesday December 03, 2003 @06:20PM (#7623268)
    For UserLinux to succeed, it must.
    • 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
    • The command line must be disabled by default, and the only way to get it is to install an unspported rpm, with a huge disclaimer in bold red text saying explicitly that they can destroy their system, and the user must sign a disclaimer and have to enter in a 50 character activation code to confirm that they want to use such dangerous software.
    • Up to date software in the STABLE distribution, with contiuous upgrades for FREE. Release a core distribution every year, with service packs throughout the year. For example UserLinux 2004, UserLinux 2005 SP3.
    • One of each app, no more. One text editor, mp3 player, video player, image viewer, office suite, email client, image minupulation program.
    • Must come with comprehensive documentation, with interface reviews, proofreading and all. With the option to have PRINTED manuals, access to a moderated user forum (read: RTFM response not allowed)
    • Must come with support to migrate from leagcy Windows Apps, with wine, and a guide to equivlents for various applications from windows. EG Konqueror instead of IE, Evoloution instead of Outlook, OpenOffice instead of Microsoft Office
    • Most importantly, ALL options MUST be configurable from the gui. If just one thing, no matter how advanced, or geeky, has to be done from the command line or a text file, THEN YOU HAVE FAILED.
    • Occam's Razor. Kiss (keep it simple stupid)

      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 /..... and makes it simple to use. However it is intellegent, setting up the right parameters correctly, and CONSISTANTLY.

      In the words of my dad, "Pick a lane and go!"

      * KDE or Gnome Pic
    • The command line must be disabled by default, and the only way to get it is to install an unspported rpm, with a huge disclaimer in bold red text saying explicitly that they can destroy their system, and the user must sign a disclaimer and have to enter in a 50 character activation code to confirm that they want to use such dangerous software.

      Don't like the command line, huh?

      There's nothing wrong with the command line. If the user is not logged in as root, the most they can do is fuck up their own home
    • ...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 sa

    • Re:My suggestions. (Score:3, Insightful)

      by vsprintf ( 579676 )

      One of each app, no more. One text editor, mp3 player, video player, image viewer, office suite, email client, image minupulation program.

      Stick with Windows if you want lack of choice. That is not the GNU/Linux approach, nor should it be. That kind of thought got us to the malware playground we now have to deal with.

  • ...I am currently in negotiation with an industry group that proposes to fund between $1Million or more annually to pay for the engineering of a fully supported and certified GNU/Linux system, without a per-seat fee, that meets the specific needs of their industry. That group represents approximately 50,000 desktop or server units - do the math and you'll see that they would save tremendously over Enterprise Linux.

    This is enough for me.

  • Enterpise Debian (Score:4, Insightful)

    by Usquebaugh ( 230216 ) on Wednesday December 03, 2003 @06:29PM (#7623349)
    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.

  • Bruce on Thelinuxshow.com (Score:4, Informative)

    by bstadil ( 7110 ) on Wednesday December 03, 2003 @06:49PM (#7623549) Homepage
    Bruce Perens was guest at TheLinuxshow [thelinuxshow.com]last night and what he wants to do was discussed in some deatal at the second half of the show.

    Click Here [thelinuxshow.com] if you want to hear it.

  • The Name UserLinux (Score:5, Interesting)

    by sethadam1 ( 530629 ) * <ascheinberg@nosPam.gmail.com> on Wednesday December 03, 2003 @06:55PM (#7623603) Homepage
    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?
    • We could switch everything to GNU.. UserGNU, or SuSE GNU, or Debian GNU/GNU.

      If people don't mod this post DOWN, I will be dissapointed.
    • 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
  • Bruce Perens , of Perens LLC wrote: (from "UserLinux: Repairing the Economic Paradigm of Enterprise Linux")

    Play Favorites

    I think it makes sense for an enterprise project to make choices among the two complete GUIs available on Debian, the dozen web servers, and so on. Having a bounded set of packages to collectively support and improve is important, especially at the beginning. Additions to that list can be driven by what customers are willing to pay for. Expect the initial choosing to be painful. Of c

  • RPM vs. apt - DUH! (Score:3, Interesting)

    by ajboyle ( 547708 ) on Wednesday December 03, 2003 @07:34PM (#7623946)
    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

    :-)

Slashdot Top Deals

Promising costs nothing, it's the delivering that kills you.

Close