Re: branding debian releases

From: Chris Metzler (cmetzler_at_speakeasy.net)
Date: 04/16/04

  • Next message: H. S.: "mzscheme.deb not clean [was: Re: chkrootkit gives this message, should I be worried?]"
    Date: Fri, 16 Apr 2004 11:58:01 -0400
    To: <debian-user@lists.debian.org>
    
    
    

    On Fri, 16 Apr 2004 11:40:19 +0200
    "Simmel" <simmel@anymotion.de> wrote:
    >
    > So why not think about using a strategy that almost every company uses
    > (although Debian isn't one), e.g. Redhat, SuSe, even
    > Microdoft........... For me as a user and systems administrator
    > something like this would be much much better.
    >
    > Why not do it this way?
    >
    > enterprise - this is for servers only - not much GUI/ focused on
    > servers/ networking,routing/ multiple cpus/driver support and so on
    >
    > workstation - this is for home users and workplaces - not much server
    > stuff here/ focused on multimedia/ x-server/ openoffice and so on
    >
    > sandbox - (I like that word, Monique :-) this can stay the same and is
    > meant for people who would like to help the Debian project with further
    > releases, simply a sandbox to play with to find and report bugs.....
    > (maybe there should be two then, something like E-sandbox, for the
    > enterprise stuff, and W-sandbox for the workstation part)

                            [ snip ]

    In making suggestions like this, and like many others in this thread,
    the implicit assumption is that the reason the three distros (stable,
    testing and unstable) exist is so that users have a choice of distros,
    and can then choose the one that suits their needs best. With that
    assumption, it is of course very important that the explanations be as
    clear to users as they possibly can; and it would make sense to even
    consider structuring the contents (and thus titles) of the distros
    differently, so that they'd better achieve that goal of giving users
    choices.

    But this assumption is wrong. The purpose of the existence of testing
    and unstable is *not* to give users choices. It may also be true that
    their existence gives users choices; but that's not what they're
    fundamentally for. The purpose of their existence is to facilitate the
    development process that produces stable releases. Users may decide to
    track unstable or testing (and many of us do); but the existence of
    those distros is to help the developers do what needs to be done to get
    packages into good shape and get releases out. Period. And thus,
    the most important thing is that the descriptions of these distros
    be clear to developers, and that their functions be useful for
    developers. "Re-branding" the distros, and changing their descriptions,
    isn't sensible: testing and unstable don't cleanly fall into categories
    that are sensible for users, and trying to label them that way is (as
    Monique said) trying to assign characteristics that don't exist. But
    that's not a bug; that's a feature. It's intentional. Their purpose
    is to facilitate the job of the developers.

    Looked at this way, the problem with your suggestion above is that
    it doesn't accomplish the goal of facilitating the next release. It
    tears down some of the infrastructure the developers use without
    replacing it with something that helps them do their job as well or
    better.

    "Well, OK," you may be saying, "but what's wrong with giving users
    choices as well? Instead of having unstable, testing, and stable, why
    not have unstable and testing to help developers (and helpful users),
    and also distros like `server' and `workstation' and so on?" But this
    is a false dichotomy: users already have the choices that other
    distributions provide with such focussed releases. Put another way,
    what people are concerned about in this thread is getting more recent
    versions of packages than stable provides; creating "server" and
    "workstation" releases of Debian like other distributions do wouldn't
    solve this. "Server" and "workstation" releases of other Linux
    distributions don't typically differ in the versions of the packages
    they provide. Rather, they differ in *which* packages are provided.
    The "server" release may include apache but not frozen-bubble; while
    the "workstation" release may include frozen-bubble but not apache.
    But they'll both typically have the same version of X (provided the
    server has X at all, of course). So functional releases wouldn't
    obviously address the thing that people have been concerned about
    in this thread -- more current versions of software.

    Furthermore, functional releases would go against Debian's philosophy.
    Perhaps you want a machine with one or the other, or perhaps *both*, or
    perhaps *neither*. Rather than decide for you what you'll need, Debian
    lets you decide. The purpose of tasksel is to make that a little less
    onerous, so that you don't have build your system up entirely from
    scratch; you can select "Web server" or "Java development" and get a
    bunch of packages relevant to whatever you need. But you can install
    whatever you want. Want server packages? Install them. Want
    workstation packages? Install them. It's your machine; do what you
    want with it.

    > P.S.: And while I'm on it, pleeeeez enhance the installation routine,
    > something like a graphical interface. This takes the fear off most
    > users. Take a look at SuSe and Redaht and you'll know what I mean. I
    > know that there are also a lot of small things which aren't good, like
    > the package selection, those are far better in Debian. But the "blue
    > screen" :-P is really annoying and confusing. My first installtion were
    > more like 3 1/2 installations, if you catch my drift.

    Sarge will have a new installer. But that said, most of the developers
    have traditionally found having a GUI installer to be very low priority,
    for the simple reason that with Debian, you should only have to install
    once per machine, ever. The painfulness of the Debian install process
    just isn't something the typical user has to face very often.

    -c

    -- 
    Chris Metzler			cmetzler@speakeasy.snip-me.net
    		(remove "snip-me." to email)
    "As a child I understood how to give; I have forgotten this grace since I
    have become civilized." - Chief Luther Standing Bear
    
    

    -- 
    To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
    


  • Next message: H. S.: "mzscheme.deb not clean [was: Re: chkrootkit gives this message, should I be worried?]"

    Relevant Pages

    • Re: production server
      ... After a 2 hour install process it ... There are offspring sites that are providing packages ... being a server.. ... Then I came full circle back to Fedora, for all its faults it does ...
      (Fedora)
    • Re: [SLE] General comments about 10.1 retail (box)
      ... yast is an invaluable tool for server ... some other problems during installs, I install suse on everything I ... packages then the DVD and old machines only have cd-roms so I was ...
      (SuSE)
    • Re: Server 2003 with Visual Studio.NET
      ... would be required to install Visual Studio .NET on a Server 2003 environment. ... All of the above research was prompted by newly hired .NET developer ... our developers instead of Windows XP Pro. ... A QA test must be an install on a virgin Win ...
      (microsoft.public.windows.server.general)
    • Re: {Disarmed} Re: problems w/ net (http) install
      ... I believe that using NFS, you would want to serve out the ISO and not ... installation and http server base for installation. ... NFS isn't strictly off the table, but the system hosting this install ... Nope the packages aren't big ones, fairly standard, 1MB-ish packages, ...
      (Fedora)
    • [Full-Disclosure] SuSE Security Announcement: samba (SuSE-SA:2003:025)
      ... file server, the widely spread implementation of the SMB protocol. ... Therefore, the update packages ... are being offered to install from the maintenance web. ... standard appendix: authenticity verification, ...
      (Full-Disclosure)

  • Quantcast