Slashdot Mirror


Debian Woody Nearing Release

willybur submits word of this Debian Planet story on the upcoming release of its next stable version. The article says: "According to Anthony Towns (our beloved Release Manager), woody is nearing release. All but three RC base bugs are fixed now, and the bugsquashing party is working through the RC bugs in standard. It's not all good news though. The bad news is that this means we're probably releasing soon, and that of the hundreds of less important packages with RC bugs (eg, bugzilla, craft, crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively, kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly ripped out of testing ... Check the stuff that's important to you and get it fixed before it's too late." Says willybur: "See the announcement on debian-devel-announce."

293 comments

  1. Nice by malachai · · Score: 0

    Ive been waiting for this, hopefully going to convert when i can get some Woody :D

  2. Better Late by Aknaton · · Score: 2, Insightful

    Of all the Linux distributions out there, I think that I like Debian the best. I also really like the fact that they are more concerned with quality then being there with the newest toys on the block.

    1. Re:Better Late by bad-badtz-maru · · Score: 2


      If the inclusion of archaic, bug-ridden software is your idea of "quality", then I concur. Postgresql 6.5 is definitely a quality-laden release, the later versions just implement useless features such as "stability".

      maru

    2. Re:Better Late by Anonymous Coward · · Score: 0

      Yea, so what do you use?

    3. Re:Better Late by Anonymous Coward · · Score: 0

      Yeah, byteboyz only two years late WTF which is like 18 months preggers w-h-o c-a-r-e-s

    4. Re:Better Late by 1%warren · · Score: 1

      I prefer Slackware. It has quality, stability, and the newest toys on the block.

      --

      Full plate and packing steel! -Minsc
    5. Re:Better Late by Anonymous Coward · · Score: 0

      how the fuck is this insightful?!?!?

  3. A port of linux! by Anonymous Coward · · Score: 0, Funny

    Think linux is just for gay geeks? Then check this out

  4. About time too by ideut · · Score: 1

    I'm hoping they're serious about changing to a much shorter development cycle. 2.2 was out of date enough when I installed it over a year ago.

    --

    --

    1. Re:About time too by Anonymous Coward · · Score: 0

      I ran early 2.4 kernels- you didn't miss anything, let me tell you. Nothing good that is.

    2. Re:About time too by ideut · · Score: 1
      I ran early 2.4 kernels- you didn't miss anything, let me tell you. Nothing good that is.

      No, I meant Debian 2.2

      --

      --

    3. Re:About time too by Anonymous Coward · · Score: 0
      Didn't miss anything?

      A shitload of new drivers, a snappy new VM, tuned scheduler... what more do you want?

    4. Re:About time too by Shiny+Metal+S. · · Score: 4, Interesting
      I'm hoping they're serious about changing to a much shorter development cycle. 2.2 was out of date enough when I installed it over a year ago.

      You should've installed Woody then. Most of the time you have three versions to choose from: stable, testing/frozen and unstable. When you need a system which will not ever crash after years of heavy load, use stable. If you want more decent software, use testing. If you want the newest versions of software from yesterday, use unstable. It's Good Thing because you have a choice, so don't complain that you're not forced to use the latest untested software, it's up to you. And remember that unstable Debian is usually more stable than any other distro.

      --

      ~shiny
      WILL HACK FOR $$$

    5. Re:About time too by ideut · · Score: 1
      You should've installed Woody then.

      No what I actually did was install Red Hat. That's something I thought I'd never do, but I don't regret it. When debian adopts a sensible release cycle I will come back to it.

      --

      --

    6. Re:About time too by Anonymous Coward · · Score: 1, Interesting

      hehe, yeah Debian sucks ass when it comes to releases. Take a look at OpenBSD for a nice stable release cycle (of course they have a much, much smaller distro). I would be happy to see Debian shrink its size and just release a "core" system. All the other 1000's of packages can be on their own.

      I am a Debian user, and have been for many years. apt is _the_ best for getting and installing binary packages. It handles dependencies _so_ much better than RPM. Debian tends to try and be more "correct" than RH (ie. more stable). The BSD's are better though, but Free/OpenBSD are seriously lacking in software/driver support.

      I have used Red Hat... I also laugh every time I hear some RH user complaining about this or that not working. RH likes to make "special" changes to certain software, and breaks things in the process... Red Hat, lol, right.

    7. Re:About time too by Anonymous Coward · · Score: 1, Funny

      You should've installed Woody then.

      I install Woody regularly, UP YOUR ASS!

    8. Re:About time too by Shiny+Metal+S. · · Score: 2
      You should've installed Woody then.
      I install Woody regularly, UP YOUR ASS!
      I have to say, that it's quite funny. :) I'd mod it up if I could, I'm serious.
      --

      ~shiny
      WILL HACK FOR $$$

    9. Re:About time too by Shiny+Metal+S. · · Score: 5, Interesting
      You should've installed Woody then.
      No what I actually did was install Red Hat. That's something I thought I'd never do, but I don't regret it. When debian adopts a sensible release cycle I will come back to it.
      If you just don't like Debian and prefer Red Hat, then good for you, but don't spread misinformation. What I'm trying to say here, is that there is not one Debian. There's:
      • Debian stable version (today it's Potato),
      • Debian testing version (Woody) and
      • Debian unstable version (Sid).
      Have you read The Myth of Open Source Security Revisited ?
      "Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record."
      That means that you won't see the latest untested toys in Debian stable, like you won't see them in OpenBSD. There is no point in arguing that Debian stable doesn't have the newest software, because if you want to run the newest (which also means untested) software, that means you don't want Debian stable. You should use one of the other available versions, unstable or testing. I usually find the testing version the best for my own use, but I still use stable Potato on few mission critical machines, which have never disappointed me so far.
      --

      ~shiny
      WILL HACK FOR $$$

    10. Re:About time too by ideut · · Score: 1
      Listen sweetheart, bang on all you want about the other branches. There's not one debian, but there *is* one stable Debian. The fact is Debian 2.2 was released in August 2000. For the last year and a half there have only been security updates. Debian 3.0 is still not released. A year and a half later. That is too long. I think they can do better.

      Oh, and comparing Debian security to OpenBSD's in such a fatuous manner is really daft. There is no project within Debian to audit their code. Debian has comparable security problems to any other linux distribution.

      --

      --

    11. Re:About time too by Anonymous Coward · · Score: 0

      First thing that made me laugh here for a while. Too bad I can't relate this joke to any normal people.

    12. Re:About time too by CentrX · · Score: 1

      Regardless of whether there is a centralized auditing project within Debian, the fact remains that even with almost 4000 packages in the main distribution and six supported architectures, Debian 2.2 only had more security holes than AIX and OpenBSD, and fewer holes FreeBSD, HP-UX, Mandrake, Red Hat, and Solaris, according to that article.

      --

      "The price of freedom is eternal vigilance." - Thomas Jefferson
    13. Re:About time too by Florian+Weimer · · Score: 2
      Have you read The Myth of Open Source Security Revisited [slashdot.org] ?
      "Both the Debian and OpenBSD projects exhibit many of the aforementioned characteristics which help explain why they are the Open Source UNIX operating systems with the best security record."

      Unfortunately, the data for Debian which leads to this conclusion is completely wrong. Important security holes were simply ignored when the statistics was prepared (for example, the OpenSSH remote root hole is missing).

    14. Re:About time too by mbanck · · Score: 1
      Then please note that woody is not secure at all. While security fixed for potato are prepared by the Debian Security Team and fixes for unstable are done by their maintainers, these fixes always need some time to propagate to woody. If RC bugs or conflicts are found, it might take a long time before a security fix enters woody.

      Michael

    15. Re:About time too by ideut · · Score: 1

      Oh dear you seem to have your facts in a terrible muddle. Goodness knows where you are getting this bogus information from, but I think you should consider something of more fundamental importance: Debian is not Free Software. Ever since they announced their intention to go completely closed source, developers have been flocking away in droves. Alas, it is now time to start building a new community-developed distribution that is truly open and not dominated by vested commercial interests.

      --

      --

    16. Re:About time too by Daniel · · Score: 2

      Debian is not Free Software. Ever since they announced their intention to go completely closed source, developers have been flocking away in droves.

      Wow, April Fool's Day came early this year :)

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    17. Re:About time too by Cro+Magnon · · Score: 1

      Unfortunately, all 3 Debian branches have problems. One branch smells of stale potatoes and doesn't even include KDE, one branch takes 2 weeks to get security updates, and the last branch has the latest/greatest, but if you apt-get at the wrong time, you can royally break your system.

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
  5. Fighting the /. effect. Do not mod up. by miracle69 · · Score: 0, Informative

    [2002-02-16] Release Status Update

    To: debian-devel-announce@lists.debian.org
    Subject: [2002-02-16] Release Status Update
    From: Anthony Towns
    Date: Sat, 16 Feb 2002 12:23:18 +1000
    Mail-copies-to: nobody
    Mail-followup-to: debian-devel-announce@lists.debian.org
    Organisation: Lacking
    User-agent: Mutt/1.3.27i

    Hi guys,

    The good news, and the bad news.

    The good news is that base is back in good shape. glibc, base-passwd and
    rsync have all had their RC bugs fixed which is very pleasing. There are
    still bugs in some important packages, including apache, bind, binutils,
    bison, emacs, iproute, kdebase-libs, menu, php3, sudo, tetex, and vim,
    but most of these seem fairly controllable.

    The bad news is that this means we're probably releasing soon, and that of
    the hundreds of less important packages with RC bugs (eg, bugzilla, craft,
    crossfire-{client,server}, epic4, fvwm95, gmc, gnome-admin, intuitively,
    kdepim, moon-lander, tkdesk, wine, and xosview) will be getting randomly
    ripped out of testing (in the case where bugs apply to the version in
    testing, anyway). What this means, is that if packages you're interested
    in have accumulated RC bugs (ie serious, grave or critical) you've almost
    run out of time to get them fixed if you want them released.

    Other news:

    * new incoming's being tested on pandora now (if you're
    interested, see /org/non-us.debian.org/queue) and seems to
    be working out okay, so the whole crypto-in-main transition
    looks like being on track for the first time in history.

    * new boot-floppies (3.0.19) are available for all architectures
    but alpha, mipsel [0] and sparc. Please test these (and build
    them if you're on one of the architectures that hasn't already
    done so) since there'll probably only be one more b-f's release
    before 3.0r0.

    * over the next few days, we're going to start doing install and
    upgrade testing somewhat seriously (with the aim of doing it
    well for the entirety of the next release). If you haven't
    already tried and upgrade from potato, or a fresh install,
    try one now so that you don't get embarassed by newbies and
    users pointing out obvious bugs that a Visual Basic programmer
    would've been ashamed of....

    There's a BugSquash party now on in #debian-bugs on irc.openprojects.net,
    so wander on over there to help rescue packages that're worth keeping
    in woody.

    It's also okay to help fix non-release-critical bugs too.

    Cheers,
    aj

    [0] mipsel b-f's are built, but are waiting on someone with a DecStation
    5000/120, /125, /133 or /240 to test them to make sure they're not
    completely broken. See debian-mips@lists.debian.org.

    --
    Anthony Towns
    We came. We Saw. We Conferenced. http://linux.conf.au/

    ``Debian: giving you the power to shoot yourself in each
    toe individually.'' -- with kudos to Greg Lehey

    --
    Linux - Because Mommy taught me to Share.
  6. Kernel version? by frozenwoody · · Score: 2, Funny

    All I can say is this: I *seriously* hope we're using at least the 2.0 kernel.

    1. Re:Kernel version? by Shiny+Metal+S. · · Score: 2
      All I can say is this: I *seriously* hope we're using at least the 2.0 kernel.

      2.2.20 AFAIK. It's a rock solid kernel.

      --

      ~shiny
      WILL HACK FOR $$$

    2. Re:Kernel version? by Anonymous Coward · · Score: 0

      2.2.20 AFAIK. It's a rock solid kernel.

      Yeah, MSDOS 3.2 is rock solid too.

    3. Re:Kernel version? by Anonymous Coward · · Score: 0, Insightful

      All I can say is this: I'm deeply disappointed they aren't using a 2.4 kernel. I'm a debian potato devotee. Going to woody, and staying with the 2.2 kernel is a letdown.

    4. Re:Kernel version? by Anonymous Coward · · Score: 1, Informative

      > All I can say is this: I'm deeply disappointed they aren't using a 2.4 kernel. I'm a debian potato devotee. Going to woody, and staying with the 2.2 kernel is a letdown.

      Until just recently, if Debian wanted Woody to be their new stable release, a 2.2 kernel was the best they could do - the 2.4 series just wasn't ready, what with all the VM rework.

      Now, though, they could go with 2.4.16 or .17, those are the beginnings of the *real* stable 2.4 series.

    5. Re:Kernel version? by Shiny+Metal+S. · · Score: 2
      All I can say is this: I'm deeply disappointed they aren't using a 2.4 kernel. I'm a debian potato devotee. Going to woody, and staying with the 2.2 kernel is a letdown.

      So why won't you use Sid with 2.4.17 then?

      --

      ~shiny
      WILL HACK FOR $$$

    6. Re:Kernel version? by Shiny+Metal+S. · · Score: 3, Informative
      2.2.20 AFAIK. It's a rock solid kernel.

      Sorry, you can use 2.2.20 or 2.4.13 2.4.14, 2.4.16 and 2.4.17.
      See the list of base packages.
      (and always you can build your own kernel of course)

      --

      ~shiny
      WILL HACK FOR $$$

    7. Re:Kernel version? by Shiny+Metal+S. · · Score: 4, Insightful

      That's insightful and informative indeed, but wrong. Why won't you just check it? You can use "2.4.16 or .17", they're in binary base packages and have been for some time now.

      --

      ~shiny
      WILL HACK FOR $$$

    8. Re:Kernel version? by Anonymous Coward · · Score: 1, Insightful

      The whole issue is that woody defaults to 2.2.x. You could probably use a 2.5.x kernel as well. The whole point is that in about two years or whenever woody's successor is announced, people will still be installing woody distros with 2.2 kernels.

      Woody is going to be obsolete the day it is released. The day after people will already be pointing endusers to testing because it's a public secret that stable really stands for seriously out of date.

    9. Re:Kernel version? by slainfu · · Score: 0

      Can't see it being much of a problem if you're using apt.

      --

      slainfu
      "I can't be a terrorist if you're sucking my bum."
    10. Re:Kernel version? by sydb · · Score: 2

      People, get a grip. with make-kpkg you can build your own debs of whatever kernel you like. I'm running woody with 2.4.18-pre7, and some patches. Why do people get hung up on the default kernel?

      Even without make-kpkg there is usually a choice of kernel.

      --
      Yours Sincerely, Michael.
    11. Re:Kernel version? by sydb · · Score: 1, Redundant

      Woody is going to be obsolete the day it is released.

      Everything is obsolete the day it is released. You were obsolete the day you were born.

      --
      Yours Sincerely, Michael.
    12. Re:Kernel version? by Shiny+Metal+S. · · Score: 2
      The whole issue is that woody defaults to 2.2.x. You could probably use a 2.5.x kernel as well. The whole point is that in about two years or whenever woody's successor is announced, people will still be installing woody distros with 2.2 kernels.
      No. You can always use whatever you want, you can build your own kernels, from many different trees etc., but the point is that 2.4.x kernels have been already available as binary packages in base section of Woody for quite some time now.
      Woody is going to be obsolete the day it is released. The day after people will already be pointing endusers to testing because it's a public secret that stable really stands for seriously out of date.
      This one sydb has already commented well. :)
      --

      ~shiny
      WILL HACK FOR $$$

    13. Re:Kernel version? by Anonymous Coward · · Score: 0

      Sorry, I was talking about the default kernel install, which will be (so far as I know) 2.2.something. Parent post wanted the default to be a 2.4 kernel, and I was commenting on why that wouldn't happen.

      Yep, 2.4 has always been available to Woody users as a user-installed extra, but not as the distro default. My bad in not clarifying that.

    14. Re:Kernel version? by Anonymous Coward · · Score: 0

      Too bad many motherboards today can't boot a 2.2 kernel due to a lot of stuff that was never back-ported. A good portion of my hardware isn't supported in 2.2. Your "apt-get" is a nice answer to any problem, but it's going to do me shit for good if I can't get the thing installed. I think I'll stick with a distro that's a little more up-to-date.

    15. Re:Kernel version? by CentrX · · Score: 1

      No, actually DOS has always sucked.

      --

      "The price of freedom is eternal vigilance." - Thomas Jefferson
    16. Re:Kernel version? by CentrX · · Score: 1

      You can use the boot disks with kernel 2.4 on them, that support ext3 and udma100.

      --

      "The price of freedom is eternal vigilance." - Thomas Jefferson
    17. Re:Kernel version? by linzeal · · Score: 1

      I'm sorry but who here believes that there are that many non-technical users that need 2.4 functionality or do not know a technical friend?

    18. Re:Kernel version? by Anonymous Coward · · Score: 0

      Yes, I can believe there's millions of non- and semi-techincal users that need good USB support, VIA mobo support and so on.

      Can I believe anyone but the most diehard Linux nerd would be running Debian, no matter the kernel? No.

    19. Re:Kernel version? by linzeal · · Score: 1

      Exactly this is not an issue for debian. Redhat mandrake and such yes but debian users are a hearty and resourceful bunch that will not be scared off by such things as even OMG building your own kernel for unsupported crap.

    20. Re:Kernel version? by Logi · · Score: 1
      So why won't you use Sid with 2.4.17 then?

      Or in fact woody with 2.4.17. I installed this yesterday and it worked nicely except that there aren't alsa modules for 2.4.17 in woody yet, so I downgraded to 2.4.16 which has those.

      Also, my "must never go down" systems are running potato with a 2.4.x series kernel. This required a couple of packages from woody, but nothing horrendous.

      --
      Logi - I can do anything, but not everything.
    21. Re:Kernel version? by datalife · · Score: 1

      There are OFFICIAL Boot-Floppies with 2.4.17 in the bootdisks directory of woody/testing. Look for a bf2.4 directory.
      So You can choose between ext2,ext3 and reiserfs at boottime!

      Andy

      --
      There are only 10 types of people in the world: Those who understand binary and those who don't.
    22. Re:Kernel version? by PhracturedBlue · · Score: 1

      I'm very sad that you can't use a 2.4 kernel to do the install. Yes I'm aware that you can install it as a package, but without it being the boot kernel for the install disk, you can't format your root partition (or any others) as reiserfs easily.
      You need to reboot to do that, and by then you at least have /etc,/var,/lib, and /bin installed, and you had to do it all from 2.2.20.

      Yes I know there are ways around it (I went through this exact thing last year), but it isn't convenient to do.

      I had heard rumors that there were going to be multiple kernels on the boot disc, but haven't seen anyhing else about it. If they did this, it solves my only gripe, and I'd love to see the link.

    23. Re:Kernel version? by borud · · Score: 1

      the default kernel is there to reliably bootstrap the system. it doesn't really matter if it's 2.2 or 2.4 -- it's going to be replaced anyway. at least when the installer has a clue. whatever works on the greatest number of systems for the duration of the install.

    24. Re:Kernel version? by Daniel · · Score: 2

      See the Woody 2.4 boot floppies.

      There was previously a reiserfs flavor based on the 2.2 kernel, but it doesn't seem to be availble any more.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    25. Re:Kernel version? by sjames · · Score: 2

      it's a public secret that stable really stands for seriously out of date.

      Actually stable stands for you won't spend hours cursing over your malfunctioning server because the package you installed had serious bugs in it.

      If you really want something from testing or unstable, just download the source deb, and re-build it for stable.

  7. Why is it... by Nameles · · Score: 1, Funny

    ...that every time I download and burn a Linux distro, the next version appears within 8 hours - 3 days?

    1. Re:Why is it... by Shiny+Metal+S. · · Score: 2
      ..that every time I download and burn a Linux distro, the next version appears within 8 hours - 3 days?

      use apt-get...

      --

      ~shiny
      WILL HACK FOR $$$

    2. Re:Why is it... by Anonymous Coward · · Score: 1, Funny

      Simple: it's to keep the CD-R makers in business.

      -MBCook

    3. Re:Why is it... by OsCarJ · · Score: 1

      I hear ya. I just burned ISO's for 2.2r5, fired up Mozilla when it was done and the first thing I see is this.

      Never tried Debian before but I've heard good things about it. I think tomorrow will be "play with new distro" Day.

    4. Re:Why is it... by GigsVT · · Score: 3, Insightful

      Why is it that every time there is a release announcement, this same lame joke gets modded up?

      Blah...

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    5. Re:Why is it... by Nameles · · Score: 1

      At least I didn't say "I'm on Linux 8.2" or something. I've never actually seen my comment, but I know it could be expected.

    6. Re:Why is it... by GigsVT · · Score: 2

      Oh, it wasn't you personally, it's more just the repetitiveness of it all. :)

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    7. Re:Why is it... by macshit · · Score: 1

      Why is it that every time there is a release announcement, this same lame joke gets modded up?

      Well, it may not be a good joke, but it is a standard one. And, as you can read elsewhere in the comments for this story, standards are good!

      --
      We live, as we dream -- alone....
    8. Re:Why is it... by ndogg · · Score: 1

      Don't you mean 8 to 3 years? Oh, oh, you mean other distros.

      Sorry for the misunderstanding, mea culpa.

      --
      // file: mice.h
      #include "frickin_lasers.h"
  8. Re:Fighting the /. effect. Do not mod up. by Anonymous Coward · · Score: 1, Funny

    Debian has PHP3? Welcome to the 90's, Debian!

  9. Wow good to see the light at the end of the tunnel by Anonymous Coward · · Score: 0, Informative

    That's pretty good progress, considering that, not even a month ago, developers were quitting Debian in disgust because it appeared Woody might never get released.

  10. woody release by nealrs · · Score: 0

    ya i think ill be released my on woody when this one comes out!-n-rs-

  11. big news by seanw · · Score: 1, Funny


    Debian is being released soon!

    in other news, hell has recently frozen over.

    1. Re:big news by Anonymous Coward · · Score: 0

      no, actually some howling stray mutt shat in the roadway ...

  12. beat to the mark (again) by global_diffusion · · Score: 0, Redundant

    I was going to make a joke about how my woody was read for release right now, but it looks like 10^4 people already did that.

    I must say, I've been waiting for this for a long, long time. Imagine running Mozilla 1.0 on Debian 3.0. Ah well, gotta save some things for future generations, right?

    (I'm joking of course. These are both fantastic projects. I'm especially psyched to get my hands on Woody as soon as I get my new hard drive...)

  13. porn-get by global_diffusion · · Score: 1

    ... has got to be the best idea in the last five years.

  14. List of all the Release Critical bugs by arnoroefs2000 · · Score: 5, Informative
    1. Re:List of all the Release Critical bugs by Anonymous Coward · · Score: 0
      What's a "critical bug" to a woody?

      The clap?

    2. Re:List of all the Release Critical bugs by reynaert · · Score: 2

      Note that this weekend the Debian developers are holding a bug squashing party on #debian-bugs on OpenProjects. Expect the number to be a bit lower tomorrow :)

    3. Re:List of all the Release Critical bugs by shallot · · Score: 3, Informative
      An up to date list of the release critical bugs, the one from which that report you linked to is generated, is available at
      http://bugs.debian.org/release-critical/
    4. Re:List of all the Release Critical bugs by Performer+Guy · · Score: 2

      Two xscreensaver critical bugs, xgammon critical bug, all three about marking files as conffiles. They have a strange definition of a critical bug.

    5. Re:List of all the Release Critical bugs by shallot · · Score: 1
      When packages install files as "conffiles" they tell the package management system they are special, configuration files. This enables the user to edit the files in question without worrying his changes will be clobbered with the next package upgrade.

      Arguably those few hundred unmarked conffiles that have recently been filed as bugs are hardly noticeable, users surely would have complained had the packages overwritten their configuration settings. However, that's still no guarantee there aren't actually users that are getting hurt with these bugs.

      Note also the bugs were filed with the "serious" severity, not "critical". These words have different meanings, see this page for an explanation.

  15. In other news... by MBCook · · Score: 1, Offtopic

    Duke Nukem Forever has gone gold, hell froze over, and I got a date ;) Seriously though, good from them. It will be nice to have magazines that compare linux distros compare woody vs. redhat, not potatoe (which is woefully old) to redhat.

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
    1. Re:In other news... by Anonymous Coward · · Score: 0

      How about Team Fortress II? That one will show up reaaaaal soon. Hell I have switched jobs twice since they started talking about that one

  16. foo by Anthony+Boyd · · Score: 3, Informative
    Expected major upgrades, by the time woody releases, include GLibC 2.2, GCC 3.0, XFree86 4.1 and Perl 5.6. Linux kernel 2.4 is judged not to be mature enough to be a default for most architectures at this time, but you can install a 2.4 kernel from Debian after completing your installation. It's also likely that the debconf package will be used in nearly all the packages which need to prompt in the maintainer scripts.

    I think Debian needs a 2.4 kernel as the default if Debian is going to shake its image as hopelessly outdated. For instance, even now you can apt-get up-to-date packages, but most people don't go beyond the defaults. As for me, I go beyond a little: I like to get security patches. Love those. But I'm wary of upgrading other things -- I've tried a KDE 2.1 to 2.2 upgrade that really made my system screwy, and a SuSE 2.4.10 kernel upgrade to 2.4.14 that lost my ext3 functionality. Of course I fixed these things, but I'm wary now. It took time, which is valuable to me. Even with Debian, you can apt-get yourself into trouble. So as someone on the sidelines (well, maybe more than that, I've done a lot of Debian installs), I would encourage the Debian folks to either reconsider the default install, or actively plan for a 3.1 (or even 3.0.1) release that will happen soon after 3.0.

    1. Re:foo by Anthony+Boyd · · Score: 1, Offtopic

      Good God. Look at my subject. What a horrible, horrible subject I used. I apologize -- I put "foo" in as a placeholder subject so I could do a preview, and then forgot to change it. I in no way meant it to be "oh foo on Debian" in the grinchy sense. Damn. That probably just painted my entire comment in a light that I did not intend.

      I guess I don't need enemies. I have myself.

    2. Re:foo by Daniel · · Score: 3, Informative

      For instance, even now you can apt-get up-to-date packages

      That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.

      The 2.4 kernels will be *in woody*, distributed on woody CDs, and available in the same way as the rest of the woody software. They just weren't planned to be the default kernel, although I've also heard rumors that some install disks are being built around 2.4.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    3. Re:foo by Anonymous Coward · · Score: 0

      > I think Debian needs a 2.4 kernel as the default if Debian is going to shake its image as hopelessly outdated.

      Debian has a stronger rep for stable "stable" releases than it does outdated. 2.4 wasn't ready to be the default kernel for a Stable release until maybe a month ago when 2.4.16 came out.

      Now that there really *is* a stable 2.4 series being maintained it's a new ballgame, but up 'til recently the only sensible default kernel was 2.2.x.

    4. Re:foo by Dwonis · · Score: 2
      That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.

      That's nearly a non-issue, now that you can pick and choose which packages to install from which distros, by editing /etc/apt/preferences.

      man 5 apt_preferences

    5. Re:foo by Daniel · · Score: 2

      Ehh. stable/unstable mixes are not supported or encouraged, at least not by me :) If you're adventurous, sure, do it and file bugs against packages whose dependencies are wrong.

      But most people should stick with stable. If stable is too out-of-date, the proper solution is to release more often.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    6. Re:foo by borud · · Score: 1
      most people don't go beyond the defaults


      then why do they complain? if they cared they'd install a newer kernel. I think it is just too daft to nix a very good OS distribution just because there are clueless people in the world.


      why can't they run Windows instead?

    7. Re:foo by borud · · Score: 1
      That's talking about an entirely different thing: to install up-to-date packages, you have to put unstable (or testing) in sources.list, and deal with the issues that arise from that.



      just out of curiosity: what issues? I've been running woody for a few months now and I've had very few "issues" at all. in fact, I've had an order of a magnitude fewer issues with woody than I've had with ANY RedHat dot-release.


      this makes me curious: what are you (or I) doing differently?

    8. Re:foo by Daniel · · Score: 2

      I was referring primarily to the problems of running a stable/unstable/testing mix, which may work, but is not tested at all.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    9. Re:foo by Cro+Magnon · · Score: 1

      Potato was badly outdated from day 1. One gripe is that it doesn't have KDE, which BTW is far more stable than the ancient version of Gnome in Potato. I agree that Debian should release more often, but they apparently never will. I don't think many Debian developers even use Potato, so they're not really using what the average user does.

      --
      Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
  17. fallback to unstable hack by pmineiro · · Score: 1

    if you have a recent version of apt, and you put the following lines into /etc/apt/prefences it will get unstable packages when there is no testing version.
    --- begin cut here ---
    Package: *
    Pin: release a=unstable
    Pin-Priority: 50
    --- end cut here ---

    enjoy,

    -- p

  18. Re:fallback to unstable hack (typo correction) by pmineiro · · Score: 2, Informative

    damn, i posted this before but i misspelled preferences, so to be clear:
    if you have a recent version of apt, and you put the following lines into /etc/apt/preferences it will get unstable packages when there is no testing version.
    --- begin cut here ---
    Package: *
    Pin: release a=unstable
    Pin-Priority: 50
    --- end cut here ---

    enjoy,

    -- p

  19. So does alien work reliably yet? by Nailer · · Score: 3, Interesting

    From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

    The distributions which put initscripts in nonstandard places have had to change, those install packages into /opt have had to change, and if they haven't, they've been looked upon negatively (and rightly so) for their lack of standards support. So how well does alien work, and would you use it to install some, or even most software on your system? A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer that's tired of maintaining different sets of packages for Red hat, Suse, Debian, Mandrake, Connectiva, and every other distro out there. Theoretically, the KDE people (for example) should only have to release one set of packages per OS. Doing otherwise wastes a great amoutn of time that could be used elsewhere.

    And yeah, I'm a Red Hat user who has posted a non 100% supportive comment about Debian in a Debian release news item. /me waits for the inevitable negative moderations from people who disagree with what I'm saying but can't voice their own opinions and repond maturely.

    1. Re:So does alien work reliably yet? by Jay+Carlson · · Score: 4, Interesting
      Note that the LSB specifies the version of the RPM file format in the book Maximum RPM. That's version 3. Let me repeat that; the LSB standard RPM package format is version 3. So now that RH is shipping v4 RPMs, a lot of other people are too, and those packages are simply not compliant with the LSB.

      More broadly, the LSB did not intend to give RedHat the power to define standard Linux. You shouldn't let RedHat define the standard either.

    2. Re:So does alien work reliably yet? by mbanck · · Score: 1
      So how well does alien work, and would you use it to install some, or even most software on your system?

      Most of the important Open Source Software is already in Debian. If you miss anything, file a RFP(Request for Packaging) bug against wnpp.

      The big commercial Packages _are_ mostly self-contained AFAICT. I don't use alien that often, but you manage to install stuff properly most of the time I guess.

      Theoretically, the KDE people (for example) should only have to release one set of packages per OS

      I could argue that different Linux Distributions are different OSes, but the real point here is: It's the work of the Distribution to package stuff, not upstream's! If official KDE RPM packages don't work on SuSE, tough luck, I guess they have enough resources to tune and build them theirselves.

      Michael

    3. Re:So does alien work reliably yet? by sydb · · Score: 2

      I've never had any problems using alien to install rpms in over 3 years of using Debian.

      I've not installed too many rpms though....

      --
      Yours Sincerely, Michael.
    4. Re:So does alien work reliably yet? by Garen · · Score: 1

      Theoretically, the KDE people (for example) should only have to release one set of packages per OS. Doing otherwise wastes a great amoutn of time that could be used elsewhere.

      I see your point, but FYI KDE doesn't release distribution-specific packages. They release source only -- it's the distros themselves that are providing specific packages.

    5. Re:So does alien work reliably yet? by jbailey999 · · Score: 1

      IIRC, /opt is in the latest LSB. I frequently wish Debian would use it.

      ``opt'' is nice, because instead of having all that cruft in /usr/bin (Like windows tends to insist you do with DLLs!), you can actually install packages in /opt/PACKAGE/ and symlink them in. This lets you see what package all of that stuff belongs to from ls, without having to run various tools (different per distro!) to find out.

    6. Re:So does alien work reliably yet? by jbailey999 · · Score: 1

      Do what most people do, and don't care about the packaging. In the packages that I maintain, I provide source code. The various packagers can sort out what they need to as they see fit.

    7. Re:So does alien work reliably yet? by Nailer · · Score: 2

      My point is that repackaging something in a nonstandard format is a massive amount of unnecessary effort. Debian won't always include that latest apps (neither can any distro), and that people should be able to create Linux packages the same way they create Solaris or OpenBSD packages. To think that different Linux distros are different OS saddens me, as it means there's a massive fragmentation that's occured on the platform ala Unix and the individual Linux OS's will never have the same impact on competitive platforms as a single Linux OS would.

      Re: my KDE example. If KDE produced a single set of packages against the LSB, and they didn't work on SuSE, then SuSE should fix whatever bug stops these packages from working - because very soon, people will take the attitude that if it isn't LSB, then it isn't Linux.

    8. Re:So does alien work reliably yet? by Nailer · · Score: 2

      /opt has been in the LSB for a while. However,
      it's reserved for local system administrator use, distributions can't use the directory unless they ask the local sysadmin if its okay to overwrite files that exist there. In other words,

      Unix sorts file by type (lib, bin, doc, etc) and always has / will. I can see the advantages of sorting by program, but you don't want to break the exising system like /opt does (so some files are placed primarily by file type, others by app). The only real solution is a filesystem with multipel views (think BIND 9s split level DNS). QNXs package filesystem is similar to this.

    9. Re:So does alien work reliably yet? by Nailer · · Score: 2

      Or use source packages - you get the standardized install, uninstall, querying, dependency checking, and verifying of packages, but people can rebuild and add compiler flags if they see fit. If you've amrked your package as relocatable then you can also allow users to install it wherever they please.

    10. Re:So does alien work reliably yet? by Dwonis · · Score: 2
      The only real solution is a filesystem with multipel views

      Why are symlink forests not a solution?

    11. Re:So does alien work reliably yet? by dvdeug · · Score: 2

      Theoretically, the KDE people (for example) should only have to release one set of packages per OS.

      They can't. The LSB doesn't standardize C++, since the libraries change too much.

      In any case, there's no reason for any Debian user to be using KDE that isn't from Debian and isn't from source. Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.

      Doing otherwise wastes a great amoutn of time that could be used elsewhere.

      Getting a large piece of software like KDE working right on your distribution can take quite a bit of work. So? If someone from Debian feels like putting that work into getting to work right with
      Debian, what buisness of it is yours? Taking that away would take away the point of a distribution.

      If you want to write an LSB program, then the LSB is there for you, and Debian will support that. If not, then the source and volunteers from the distributions will be there for you.

      A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer

      That's what "configure; make; make install" is for.

      You can't tell everyone to use the same language so we don't need to translate; don't tell everyone to use the same distribution so people don't have to worry about the differences.

    12. Re:So does alien work reliably yet? by Glytch · · Score: 2

      Most of the important Open Source Software is already in Debian. If you miss anything, file a RFP(Request for Packaging) bug against wnpp.

      And if one doesn't feel like waiting for that beaurocracy to get it's act together, one could just compile the program themself. Just a thought.

    13. Re:So does alien work reliably yet? by dvdeug · · Score: 2

      To think that different Linux distros are different OS saddens me

      Why? In some ways, Linux has the best of all possible worlds. It doesn't have the monoculture of Windows or MacOS, where new ideas and new ways never get tested and if you don't like it, there's nothing similar that might fix your bug - if you want to move, you change everything. It beats the proprietary Unixes, in that they all work together in new features and bug fixes, and almost never will a program work on one Linux but not another. With Linux, you have actual choices, without losing everything you liked about the operating system.

    14. Re:So does alien work reliably yet? by Panoramix · · Score: 1
      My point is that repackaging something in a nonstandard format is a massive amount of unnecessary effort. Debian won't always include that latest apps (neither can any distro), and that people should be able to create Linux packages the same way they create Solaris or OpenBSD packages. To think that different Linux distros are different OS saddens me, as it means there's a massive fragmentation that's occured on the platform ala Unix and the individual Linux OS's will never have the same impact on competitive platforms as a single Linux OS would.

      The thing is, I believe, that if the package format were the only difference, the RPM-or-DEB issue would be moot. The reason why Debian use its own packaging scheme, and IMHO what makes it far superior than RedHat and others when it comes to install or upgrade things, is the Debian Policy.

      When some maintainer makes a DEB, it does it according to policy. And this doesn't mean only where things get installed, it means lots of depends/conflict/suggests information, checking that the package is able to upgrade from very old versions, that if it provides an alternative for other package already installed it doesn't clobber it, that the new app gets managed by the Debian menu system... lots of nice things. And it works: dselect upgrade and install works fine, with almost no user intervention, 99% of the time, even on weird potato/woody hybrid systems such as my laptop.

      I think that converting and installing DEBs in RPM-based systems should be quite easy. The opposite, however, would most likely be very hard without screwing policy, because most RPMs out there are a far cry from compliance. I've never used alien, and probably won't anytime soon. I think it would be a very bad thing for the integrity of the system as whole.

    15. Re:So does alien work reliably yet? by Nailer · · Score: 2

      The thing is, I believe, that if the package format were the only difference, the RPM-or-DEB issue would be moot. The reason why Debian use its own packaging scheme, and IMHO what makes it far superior than RedHat and others when it comes to install or upgrade things, is the Debian Policy.

      Indeed, the Debian policy is similar - is there any reason that it wouldn't be largely portable to RPM? Conectiva (which uses standard packages) already uses Debian policy as a basis for its own packaging guidelines.

    16. Re:So does alien work reliably yet? by Nailer · · Score: 2

      Hopefully, perhaps inevitably, C++ libraries will be included as part of the LSB.

      Debian does great work to make sure that everything supports the Debian menu system, for example, and any problems with the software can go through one main bug tracking system.

      Either of these are still entirely possible while using standard packages. One can track . Almost every other Linux distribution has its own version of the menu system, typically /etc/applnk directory.

      Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.

      This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.

      If you want to write an LSB program, then the LSB is there for you, and Debian will support that.

      Not unless I make alien work as a package manager rather than an extractor of archives.

      >> A standardized packaging system is useful for more than just closed source apps - its useful for every open source app maintainer

      That's what "configure; make; make install" is for.

      How? How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory? It won't.

      You can't tell everyone to use the same language so we don't need to translate

      Nobody is forcing people to do anything. Linux distro's, if they want to label themselves LSB, should do their best to support the LSB. The current abilities of alien seem to be highly lacking in this regard. If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.

    17. Re:So does alien work reliably yet? by mbanck · · Score: 1
      Policy has nothing to do with RPM/DEB. Is has everything to do with the *effort* maintainers put in creating and managing packages. I've come accross several upstream programs where upstream already included a debian/ directory to build DEBs. Sometimes their good, sometimes their bad, but they almost always need some sort of tweaking.

      If KDE released some LSB-compliant packages, Debian would still repackage them to comply with Debian policy. I don't get your problem with this. Having only one repository for _all_ distributions would be rather difficult WRT bug fixing and releasing, no? So I guess every distribution will continue to provide its set of packages and I don't know why you think its bad for Debian to provide their packages in .deb format. Please note that Debian and therefore DEB is older than Redhat or SuSE, AFAIK.

      Michael

    18. Re:So does alien work reliably yet? by dvdeug · · Score: 2

      If Debian don't want stable and reliable way of installing LSB packages, they should stop hoping inanely that the packaging system decision will be reversed and simply say they have no interest in the LSB, as Slackware does.

      Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.

      An LSB package must have one, and only one, dependency - lsb. There's no possibility of a large independent set of LSB packages.

      How will that solve the LDP from having to write twelve million different guides to ppp because some distro decided to use a nonstandard initscript dir, packaging system, or documentation directory?

      Does every guide really have to tell you how to install a package? Even if you do standardize on all that, what's to prevent a distro from coming up with a better name for it or a completely different implementation? (Documentation directory is more of a strawman - it's dictated by FHS, which is followed by almost everyone.)

      Getting a large piece of software like KDE working right on your distribution can take quite a bit of work.

      This is precisely the problem the LSB was created to solve. Linux apps should be Linux apps.

      So you're going to magically wave your hands and get everything working right? We must never change libpng (since doing so cause rampant incompatibilities in KDE pacakges, that would require a full recompile of everything.) We must never change compilers (again, massive incompatibilies.) We must never add i18n to the package format, for that must forever be pure rpm 3.0. We must never change libc's, even if something vastly superior to glibc comes up.

      We aren't interested in something that would prevent us from improving Debian. Yes, we are different from RedHat. We try to make the incompatibilities where we do something better, but life is as it is. Infinite Diversity in Infinite Combinations. It's a strength of Linux.

    19. Re:So does alien work reliably yet? by lordsutch · · Score: 2

      From discussion with Debain users (and time spent administering Debian boxed at my workplace) Debian's rpm support doesn't work that well for anything apart from large self-contained statically compiled packages. The problem being that the Linux Standards Base will probably be considered the definition of what a Linux distro is in a couple of years (and is starting to be used as a yardstick these days). Yes Debian ostensibly supports the LSB via alien, but how well?

      That's a very good question (and one nobody bothered to answer in the ensuing discussion). At present, it probably doesn't support it at all, excluding the rudimentary support for LSB packages joeyh added to alien 8.00. I can't locate any intent to package statement for lsb or lsb-rpm (the former being the LSB's core dependency, the latter being the RPM specified by LSB). The only packaged LSB component is lsb_release.

      I'd have to do a bit more digging to figure out if anyone is actually working on this stuff.

      --
      My Blog. Sela Ward can sell me long distanc
    20. Re:So does alien work reliably yet? by Nailer · · Score: 2

      I don't know why you think its bad for Debian to provide their packages in .deb format.

      Because Debian doesn't allow one to install a standard package and have that package work with ither software. This means a whole bunch if unecessary effort. As I've said earlier, and you've said yourself, policy has nothing to do with rpm or deb. Policy would be applicable to a LSB based Debian as well. In fact, this policy should be moved into the LSB - that's the best place for it. If one distro isn't allowing a et of packages to be installed because it causes some kind of problem, it sounds like all distros could benefit from that information. This should be obvious.

      Please note that Debian and therefore DEB is older than Redhat or SuSE, AFAIK.

      AFAIK that's not correct, RPM is the older system, but I can't find a URL. Not that age has anything to do with this.

    21. Re:So does alien work reliably yet? by Nailer · · Score: 2

      Please don't confuse what you want the LSB to be with what the LSB is. Debian is a full member of the LSB, the packaging decision was made with Debian's approval, and it has always been understood that Alien is an acceptable solution.

      I see this as a conflict within the LSB. Obviously a system which turns packagines into dumb archives is not a packaging system. Even if you said alien supports RPM installs, (I think the `P' and `M' is prettty debatable) it certainly doesn't do them well. Every Debian user I know of including myself wouldn't install a large volume of packages in standard format on a Debian box.

      This is a bug withihn the LSB generated to satisfy Debian users. A rather unfortuinate compromise that will olikely bite either the LSB or Debian at some point in the future.

      You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should. Next question.

      Yeah, I like /usr/share/doc too. Its nice that everyone's actually uses the directory, rather than installing them into /var/cache/docs and saying they `support' /usr/share/doc is that's what you want to use.

      Your argument regarding changing is completely illogical. What is preventing you from changing? Just change within the standard. Policy is portable, APT already exists on RPM and I'm sure suggested/recommended dependencies woildn't be hard to implement. For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option, but by default, it should support LSB standards in their entirety and reliably.

    22. Re:So does alien work reliably yet? by dvdeug · · Score: 2

      I see this as a conflict within the LSB

      And I see this as them specifing what they want, not what you want. LSB packages don't have dependecies, beyond lsb, since dependencies aren't portable among RPM systems. It isn't for people installing a large volume of packages - it's so you can install one or two packages like oracle or Civ:CTP.

      You're wondering if a guide to using software shoudl include instructions about installing that software: yes it should.

      Should it include instructions on how to use your keyboard to type in the installation? Unless installing that software is tricky, then don't bother. If you need to know that to install ppp, you say apt-get install ppp, then you should reading the Debian instructions first. If you need to point out that it isn't named ppp on all system, well, removing deb's won't solve that problem.

      What is preventing you from changing?

      Do you have any idea how much work it would be to take 6000 packages, and repackage them in RPM format? Do you have any idea how much work it would be to support mixed deb and rpm installs? (We still haven't switched completely to /usr/share/doc - there's still a simlink from /usr/doc to /usr/share/doc for each directory in /usr/share/doc, because of a need for backward compatibility.)

      And for all that, compatibility still won't appear. A KDE RPM compiled against libpng3 will still have various problems when run with a libqt RPM linked against libpng2. An RPM that depends on XFree86 will still not work on a Debian system that has xserver-common installed. An RPM that depends on libstdc++2.9 won't make that library suddenly appear on a Debian system - it needs to be recompiled.

      For servers and wrokstations, Linux should be Linux. If you want to make it something else, you have the option,

      Fine. We're exercising that option. You're welcome to go to the trademark holder, and whine about how we diluting the trademark, but until then we're have as much right to call it Linux as anyone else.

      it should support LSB standards in their entirety and reliably

      That doesn't include RPM dependencies, because the LSB doesn't include dependencies. In fact, the LSB was carefully designed so that Debian can support it in its entirety and reliably without moving to RPMs.

      The LSB was never designed to be what you want it to be. If you want a straitjacket standard, you're welcome to try and get one started; good luck getting everyone to use it.

    23. Re:So does alien work reliably yet? by Anonymous Coward · · Score: 0

      > Because Debian doesn't allow one to install a standard package and have that package work with ither software.

      There's no such thing as 'standard package' - every distribution has so far added their own tweaks, and more importantly, done everything to make sure they have a consistent set of packages in their distribution (everything built against compatible library versions, everything integrating with whatever menu or config front end system they use, for starters).

      If you think the LSB is enough to guarantee that packages from any upstream (X, KDE, Gnome) will _seamlessly_ integrate with every single compliant distribution your're sorely mistaken. It only sets a minimum standard (lowest common denominator regarding package format, which Debian choses to implement via alien, FHS and perhaps minimum requirements for basic library versions). Anything beyond that would require close coordination between all distributions, to an extent that I'd question if those were independent distributions after all.

      Frankly, I rather prefer it the way it is. Being Debian developer my stance is biased on the package format count but even without that, I'm still biased against mutual assimilation of all existing Linux distributions :-)

      Michael

  20. About Time by Tremul · · Score: 1

    I've recently become a debian user from slackware. Apt-get is by far the best tool I've ever used however I was shocked when I installed debian standard and checked the versions of some of the tools. SSH was at version 1.2.3!!! which was insane. Testing wasn't a whole lot better. However I am quite satisfied with unstable currently. Although it breaks from time to time on my laptop.

    --

    "Can't sleep. Clowns will eat me"
    1. Re:About Time by reynaert · · Score: 3, Informative

      Just to be clear, OpenSSH 3.0.2 is included in Woody (and has been for some time).

    2. Re:About Time by CentrX · · Score: 1

      Actually, testing is a whole lot better, and you don't get the breakages you do in unstable. So what is SSH is version 1.2.3, what's so insane about that? Aside from not supporting protocol 2, there's nothing wrong with SSH 1.2.3, or do you just have some perverted need for ever higher version numbers?

      --

      "The price of freedom is eternal vigilance." - Thomas Jefferson
    3. Re:About Time by Ziviyr · · Score: 1

      One could get the idea that certain important bugs still exist because of its low revision.

      --

      Someone set us up the bomb, so shine we are!
    4. Re:About Time by joib · · Score: 1

      Protocol 2 is a rather major improvement, imho. Better security, and sftp is very convenient. And well, testing currently has 3.0.2p1 so I'm happy :)

  21. Speed of releases by XBL · · Score: 1, Troll

    This is a valid question: Why does it take so long for new Debian releases to come out? Even OpenBSD seems to have more releases with security audits, new features, etc.

    What makes it even worse is the fact that by the time releases come out, many of the software packages are out of date. Sure, they are almost guaranteed to work, but is it really that big of an issue? I have no problems with rolling my own if a package does not work.

    Another thing I do not like about Debian is the installer. Dammit, if the packages are so good, then it should be even easier to create a good installer without many bugs, etc. For Linux itself, there are other installers that can take care of a lot of those development issues.

    To personify Debian, I would describe the person as autistic with a generally obsessive mind on minute details, and slow learning capabilities.

    1. Re:Speed of releases by ideut · · Score: 1
      The new Debian release manager wants to make the releases more frequent but I really can't see this happening.
      For the next cycle (assuming this freeze actually turns out to be relatively short and controlled), I think it would be interesting to see if we can do the same thing again, with a short (2 or 3 month) development cycle, for a 5 to 7 month release cycle.

      Read the whole mail at the list archives

      It looks like the first part of his plan failed dismally. He sent that mail 7 months ago, and part of it says

      My overriding goal for this release was to manage to get a short, controllable freeze; one that we can get over and done with in a few months, rather than letting it drag on for seven months with no end in sight

      It would be nice to use Debian again but to be frank why bother when there are such more responsive and up to date distributions?

      --

      --

    2. Re:Speed of releases by Jagasian · · Score: 2

      So wait, you claim that you have no problem rolling your own packages, but you do have a problem installing Debian? Do you happen to be an Enron CEO?

    3. Re:Speed of releases by sydb · · Score: 2

      Yeah, I think Linus said this about 2.4.

      --
      Yours Sincerely, Michael.
    4. Re:Speed of releases by jbailey999 · · Score: 1

      My experience has been that while Debian stable tends to be quite out of date, the responsiveness can't be faulted! What problems have you had?

    5. Re:Speed of releases by ideut · · Score: 1

      Sorry, I don't mean responsiveness of the developers to bug reports. I mean the responsiveness of the whole system to advances in software technology.

      --

      --

    6. Re:Speed of releases by Anonymous Coward · · Score: 0
      Able to != easiness

      Just because it can be done doesn't mean it's not a pain in the ass. I CAN build every package on my machine from source... it doesn't mean I want to... just like I CAN install Debian but it doesn't mean the current shitty installer isn't a pain in the ass

  22. random removal? by oyenstikker · · Score: 1

    hundreds of. . .packages. . .will be getting randomly ripped out of testing. . .

    What does this mean to me, as a woody user? Will lots of packages be ignored by apt after i dist-upgrade following the switch?

    --
    The masses are the crack whores of religion.
    1. Re:random removal? by mbanck · · Score: 1
      In theory, RC bugs don't even appear in testing, they get sifted out by the time the package sits in unstable. If RC bugs are found against packages in testing, this could mean that this package will be dropped. Be sure that all favourite packages will be in woody. Every maintainer should look after his own RC bugs anyway. If one of the packages you use has RC bugs, you could still try to solve them yourself and send a patch to the BTS. Somebody might pick it up and do a NMU if the maintainer is not responsive.

      Michael

    2. Re:random removal? by oyenstikker · · Score: 1

      What does it mean if the package is dropped? If the package gets added at a later date, will it be upgraded with a dist-upgrade?

      --
      The masses are the crack whores of religion.
    3. Re:random removal? by Anonymous Coward · · Score: 0

      > What does it mean if the package is dropped? If the package gets added at a later date, will it be upgraded with a dist-upgrade?

      I'd doubt it. dist-upgrade only installs new packages that are a dependency on another package's upgrade; it doesn't fetch new stuff that has no relationship to something already installed on a system.

      If a package is dropped and you have an earlier version installed, then yes you should be able to upgrade it if/when it gets added in later. But a fresh Woody install wouldn't be able to do this since there wasn't any initial version to begin with.

    4. Re:random removal? by Daniel · · Score: 2

      Yes, sort of.

      If you have a package installed which is removed from testing, it will still be installed on your personal machine. ajt won't come to your house and wipe it from your disk :)

      But you won't get upgrades from apt (unless you have it set to download from unstable or the new testing) until or unless the package is placed back into the archive.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    5. Re:random removal? by Anonymous Coward · · Score: 0
      unless you have it set to download from unstable or the new testing

      This doesn't make any sense. I have apt set to download from "testing". If a release candidate is made, packages should not be removed from this distribution. They should be removed from a release candidate distribution. Testing should always be testing.

    6. Re:random removal? by Daniel · · Score: 2

      Testing is the release candidate; that is its purpose. (AIUI, anyway)

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    7. Re:random removal? by Dwonis · · Score: 2
      You don't understand how dist-upgrade works. It's just like upgrade, but more zealous in dependency-handling (it will uninstall packages to satisfy dependencies). It does not do the equivalent of a "clean install" of a new distribution.

      Whether or not this is a bug or a feature, I won't say.

  23. Obligatory Sex Joke... by Anonymous Coward · · Score: 1, Funny

    Now that "Woody" is the base for my Debian installation, I can start working on my new, security focused distro "Stiffy," followed up by next Uber-Gaming project, "Hard On."

    Makes me wonder were Potato fits into it all....

    1. Re:Obligatory Sex Joke... by Anonymous Coward · · Score: 0

      Unlike you two, who are the REAL DEALS!

    2. Re:Obligatory Sex Joke... by jo42 · · Score: 1
      >Makes me wonder were Potato fits into it all...

      Up Woody's wazo.

  24. Forgive me... by Issue9mm · · Score: 2

    but I am compelled to share with everyone how I misread the caption...

    All but three RC base bugs are belong to us.

    :(

    -9mm-

  25. About damned time... by Anonymous Coward · · Score: 0

    How long as woody been in development? How old is the last 'official' release? Jeez.... I switched to running slackware because it had more up to date software... IMHO that is

  26. Debian woody nearing release by Anonymous Coward · · Score: 0

    Am I the only one that finds that subject hilarious? :)

  27. Do the packages being yanked out matter? by Snowfox · · Score: 3, Interesting
    I'm curious as to how much it matters if most of these packages are yanked out of stable.

    Sure, most people using Debian as a server are running the stable release, but I was under the impression that almost all desktop users were tracking unstable for want of the hundreds of packages missing in the age-old 2.2 release.

    Having all these things fixed for Woody release would be nice, but I'm guessing there's almost nobody out there who'd be affected by these vanishing.

    How many of you Debian folk are using stable for something other than a server?

    1. Re:Do the packages being yanked out matter? by Anonymous Coward · · Score: 0

      My guess is that the woody has beeen yanked allready.

    2. Re:Do the packages being yanked out matter? by gmhowell · · Score: 1, Redundant
      My guess is that the woody has beeen yanked allready.


      I yank woody almost every day. I bet most /. reader's are in the same boat.

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    3. Re:Do the packages being yanked out matter? by F.O.Dobbs · · Score: 1

      I use Potato at work because I can't afford to have my workstation down, and that's something that I've had on my Woody machines a few times for various broken packages that sneak in. When I get to work, I don't wonder if my machine is going to work when I turn it on (unlike some of the w2k people here). It always works, and that's why I stick with stable.

      F.O. Dobbs

    4. Re:Do the packages being yanked out matter? by benmhall · · Score: 2

      Actually, Potato with Ximian Gnome makes for a pretty decent desktop experience. It's what I run on my age-old laptop. (Well, I use the packages from Gnome, I run XFCE, as Gnome, even without running a file manager, seems quite a bit heavier.) It works great, and I see absolutely no reason to upgrade.

      Plus, building packages as you need them for Potato isn't so bad. You can easily find XFree86 4.03 debs for Potato, along with 2.4 kernels. KDE's stuck at 2.1.2, but that's not so old. What more do you really need?

  28. support for kernel 2.4 in the installation system by shallot · · Score: 1

    Actually, that piece of woody web page is somewhat stale -- I've recently heard that boot-floppies 3.0.19 include a version which installs kernel 2.4. I'll go update the web page.

  29. First Glance by Zog · · Score: 1

    Well, you know how sometimes you look at a story title and only see part of it at first?

    'Woody Nearing Release.'

  30. Re:Fighting the /. effect. Do not mod up. by sydb · · Score: 2

    Debian has php4 too. Really, people think Debian is out of date, it's not. It's just stable and DFSG free. (except for php4 - see the Zend engine...).

    --
    Yours Sincerely, Michael.
  31. SOmebody has to ask by Anonymous Coward · · Score: 0

    How long does it stay up?

  32. What? No whining bitches? by Talez · · Score: 0, Troll

    And I was so looking forward to laughing at the "Why the hell was this posted? I dont want to know about stuff that will be released soon, I want to know when the stuff is released! Why the hell is this news for nerds? Why dont we just post when redhat makes another beta? Or when Linus builds another pre version of a kernel! Yeah that'd make a really interesting news site! Screw you slashdot!" posts...

  33. Oh come on now.. by Anonymous Coward · · Score: 0

    "Debian Woody Nearing Release"

    *quick!* somebody get a paper towel!

  34. Debian Woody by Anonymous Coward · · Score: 0

    I am going to run my Linus beowufl cluster using these softwares! And I will play my favorite Linus game DOOM on it.

    PS did you miss me? I know you missed me.

  35. /etc/apt/source.list anyone? by Anonymous Coward · · Score: 2, Informative

    Im surprised by the amount of "slashdotters" who, while bagging Debian for being out-of-date, are painfully unaware of the fact that Debian is actually 3 different distributions, i.e. Stable/Potato, Testing/Woody and Unstable/Sid. You can have the latest and greatest software with Debian, all it takes is a simple find and replace on /etc/apt/sources.list to change the branch apt-get gets it's package list from.

  36. Re:Kernel version by __past__ · · Score: 2
    make-kpkg is definetly one of the best things about Debian. It's at least as nice as apt. It almost solves all problems with the stupid development cycle of the Linux kernel.

    Serious, however, Debian is the best Linux distro I ever used. Some of its approaches are questionable - like "alternatives" - but its as close to a well-designed system as one can get with an eclectic system like GNU/Linux.

    The major griefs are - obviously, others already pointes that out - the bogus release cycle nearly forcing you to run unstable, and the package management system, which rocks, but only as long as you are just installing pre-made binaries. I never tried to create a RPM, but making a .deb from some arbitrary code you downloaded is definetly way to much work (compare it to creating a BSD port, where the hardest thing is to determine the best download URL for the source tgz). While Debians package collection is of course impressive, once you install something not included, you most likely will not care about your packaging system, which is always a bad thing.

  37. Re:Fighting the /. effect. Do not mod up. by cymen · · Score: 2

    I thought that having a release with six kajillion packages "doesn't slow down the release." Yeah, right. I wish I could get out a gattling gun and mow down all the extra cruft that goes in each Debian release. Split the base system from the extra crap. Get Debian complete base install down to a couple hundred mb and make what is on that cd the base system. Screw the other crap.

    Oh well. Won't happen. We must use something version .007 for three years while waiting for the next release. Sure we can patch something .007 forever but NO we CAN'T UPGRADE IT! Yeah, OK. So you would rather use something version .007 patch level 2342304234 then upgrade to something version .now and give feedback to the developers of something? Navel gazing in extreeeeeme!

    This is stupid.

  38. Tee hee hee... he said "potatoe" by WD · · Score: 1

    Must be a graduate of the Dan Quayle school of spelling.

  39. Re:Wow good to see the light at the end of the tun by Anonymous Coward · · Score: 0

    I don't think one developer quitting merits the plural here. You make it sound like many instead of just one.

  40. OMG by Anonymous Coward · · Score: 0

    "Debian Woody Nearing Release"

    "from the long-time-comin' dept."

    is any more proof needed that Slashdot is a site for gay homosexuals?

    1. Re:OMG by Anonymous Coward · · Score: 1, Insightful
      is any more proof needed that Slashdot is a site for gay homosexuals?

      As opposed to the other kind?

    2. Re:OMG by Anonymous Coward · · Score: 0

      The sad ones

  41. Re:Tee hee hee... he said "potatoe" by Anonymous Coward · · Score: 0

    Must be a graduate of the Dan Quayle school of spelling.

    ...and I suppose you are from the Tom Daschle school of Assholes.

  42. There are no `version 4' RPMs by Nailer · · Score: 2

    RPM 3.05 will happily install any RPM in existence.

    Red Hat didn't join the LSB for a couple of years precisely to avoid these inevitable (and completely unjustified [well you didn't provide any supporting arguments]) accusations. They lost out on few things too - eg, initscript directories (and thank god, rc.d/init.d sucks). Everyone has (and has already often made) concessions towards the LSB, Red Hat, Debian, SuSE or otherwise.

    1. Re:There are no `version 4' RPMs by Jay+Carlson · · Score: 3, Insightful
      I don't care what a particular implementation of RPM will install. The implementation is not standardized. I care about the format. Let me demonstrate to you that v4 RPMs exist:

      nop@family-values:/tmp$ wget ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i3 86/RedHat/RPMS/ash-0.3.7-2.i386.rpm

      [...]

      nop@family-values:/tmp$ od -t x1 ash-0.3.7-2.i386.rpm | head -1
      0000000 ed ab ee db 04 00 00 00 00 01 61 73 68 2d 30 2e

      You will note the "04 00" after the magic number. Is this accusation still unjustified?

      The place I first saw these in the wild was source RPMs. In several cases, I've gotten SRPMs that I could not extract due to version mismatches. (Extraction of SRPMs is not a LSB issue, however.)

      I'm not complaining that Red Hat was not a good player in the LSB standardization process; I've no reason to think otherwise. I'm complaining about the attitude that "interoperability with Red Hat" is an important goal for Debian or other distros. It's more important to interop via standards, not testing against a perceived market leader.

    2. Re:There are no `version 4' RPMs by Nailer · · Score: 2

      I see your point, and agree with it. But lack of RPM 3 packages in Red Hat doesn't excuse the same error in Debian. I don't think `interoperability with Red Hat' is a goal, and if anyone does, they are wrong. If the LSB went with debs, initscripts in /sbin/init.d and all software in /opt, that's what I'd want out of Red Hat, Debian, and everyone else. But they didn't - they spent a great deal of time deciding on these issues, inclduing a standard package format and people should move towards that packaging system (if you want suggested / recommended dependencies, then add it to rpm).

  43. Re:fallback to unstable hack (typo correction) by xercist · · Score: 1

    I use sid, and want to switch to sarge as soon as it's filled with sid's packages. I also want to continue updating from sid before the release. Got a script for that one?

    --

    --
    grep "xercist" /dev/random ...you'll find me in there someday
  44. Re:Fighting the /. effect. Do not mod up. by Daniel · · Score: 3, Funny

    Thanks for your insightful [0] comments on our release process. Could you give me a URL for the webpage of your Linux distribution? Given your cutting insight into the issues of building one, I assume you have one with some useful features we could learn from. I also presume it's quite stable, secure, and up-to-date, and already runs on a half dozen hardware architectures and at least two kernels.

    Thanks,
    Daniel

    [0] or is that inciteful?

    --
    Hurry up and jump on the individualist bandwagon!
  45. Re:Fighting the /. effect. Do not mod up. by dark_panda · · Score: 2

    Actually, the Zend engine is now covered under a BSD-like license, just like PHP4, and should be acceptable according to the Debian guidelines. Both PHP and the Zend engine contain the original BSD advertising clause, which some people don't like, but other than that, they're both fine. See http://www.zend.com/license/2_00.txt for details.

    J

  46. Debian and Standards by castlan · · Score: 5, Interesting

    It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.

    The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."

    The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.

    The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.

    More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the /opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.

    Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.

    Theoretically, software developers should only have to release their files as .TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.

    As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:

    apt-cache search pppoe

    If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:

    apt-get install pppoe

    and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

    I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

    -castlan

    1. Re:Debian and Standards by joey · · Score: 3

      > AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

      I hate to burst your bubble, but the FHS has nothing to do with package formats at all.

      joey@silk:/usr/doc/debian-policy/fhs>zgrep -i rpm fhs.txt.gz
      zsh: exit 1 zgrep -i rpm fhs.txt.gz

      As for how well alien works, what can I say, it works for me.

      --
      see shy jo
    2. Re:Debian and Standards by Nailer · · Score: 2

      It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable.
      Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information.


      Of course they provide control information - if they didn't, they wouldn't be management systems would they? If alien still removes this information it does not do a good job of installing packages. Rather it turns those packages into dumb archives.

      Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts)

      Initscripts live in /etc/init.d. Other locations are not correct. Red Hat, SuSEm and other people who once put initscripts in other (now incorrect) locations are moving towards this.

      AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB.

      It seems you're in error. RPM 3 format packages are specified in the Linux standards base.

      DJB has a number of valid criticisms [cr.yp.to] (of the FHS) that are as of yet not addressed by the LSB, or more accurately, the FHS.

      Good or bad, its a standard. You'll get more pain from not sticking to a standard and fragmenting Linux than you will from adopting a standard even if you don't like every part of it. Some of DJBs recommendations (eg, a registered namespace for apps) coudl easily be included in the LSB, just as suiggested / recommended dependcies could be added to RPM if so desired (says someone who happily maintains a 3GB APT repository filled wit h RPM packages for the Red Hat machines at his workplace).

      in fact the Debian Project has made FHS support a specific requirement [debian.org] in their official policy manual.

      Excellent. But they really should do the same with the LSB.

      The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant.

      True, another poster made this point earlier and I agree: all Linux distribtions should completely support RPM 3.05 packages.

      Offical standard RPMs are handled by Debian via Alien flawlessly

      No they are not, if they remove control information as you have earlier stated. Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

      Debian's pretty good with FHS support, so is RH: RH has likewise moved all /usr/doc files into /usr/share/doc, and haven't used /opt in years. Suse moved their initscripts from /sbin/init.d to the proper location, but still /opt kde. I'm glad that these efforts are being made, however greater effort on fundamental issues like the packaging system needs to be performed to stop Linux fragmenting.

      Theoretically, software developers should only have to release their files as .TGZ archives

      If they added standardized installs, uninstalls, information about the relationships between packages, querying / verifying machinisms, etc, this would be possible. Unfortunately they don't and it isn't: hence the need for packaging.

      As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen.

      I am well aware of the FHS and APT. I am well aware alien doesn't handle RPM packages beyong turning them into dumb archives. I just wanted to se if there is any attempt under way to fix this.

      I'm also especially aware of how APT works: I run an APT repository for the Red Hat systems at work and my own machcine, with around 3000 packages.

      Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

      There are no `APT' packages - you means debs. APT run on top of the packaging system. Yes, recommended / suggested dependencies are very useful, and its good that .deb provides this. So is transaction handling for the rpm database - its good that rpm provides this. They each have their advanatges. I'd like to see the good features of deb added into RPM, and the LSB updated to this new version.

      I am heartened to see that you haven't been down modded, I I hope that my post has been informative.

      Thankyou.

      Mike

      -castlan

    3. Re:Debian and Standards by dvdeug · · Score: 2

      Without this data there is no `management' and it seems alien can hardly be trusted to install a large amount of interdependent software.

      Why would you want to do that? There's no large interdependent amount of non-free software for Linux. If you're using Debian, use Debian packages - they work better on Debian, since they are built for and tested with Debian. I would be surprised to find a large amount of interdependent Free software that Debian doesn't include at least of most of.

      Does the RPM world agree on dependencies? It didn't last time I heard, but I don't pay attention to stuff like that. The X maintainer completely rearranges the X packages frequently, as do the Gnome and KDE developers, and fairly often some developer will change the packages on his or her package and everyone depending on that package will have to jump to correct their package's dependencies. My assumption would be that Red Hat and everyone else do this too, whenever they find it beneficial, making it a pita to keep track of dependencies cross- and even intra-distribution.

    4. Re:Debian and Standards by castlan · · Score: 1

      Hey, It was off the top of my head and I was mistaken. I'm surprised that it took the Alien maintainer to notice my bubble, and frankly a little pleased too. It is heartening to see that a prolific Debian developer like yourself is still responsive in public forums. Congratulations on helping Debian remain my preferred distro.

      -castlan

      p.s.
      Have you considered adding functionality to Alien to support Open Packages? It looks like it hasn't make much progress recently, but I am still optimistic regarding its future. Some names I recognize from Progeny also seem to be significantly involved, and it seems like a worthy project. What do you think of its viability considering the FHS?

    5. Re:Debian and Standards by shadoi · · Score: 1

      I believe he was confusing (unintentionally) the FHS with the LSB. The LSB does deal with the package standard, the FHS does not.

      FHS = Filesystem Hierarchy Standard

      It seems quite plain to me what that means...

      shadoi

      --
      -- "Chaos often breeds life, when order breeds habit." -Henry B. Adams
    6. Re:Debian and Standards by castlan · · Score: 1
      It seems that I mistook your quantity of cluefulness.

      While well thought out standards are a good thing, some standards are meant to be broken. Seeing as how the LSB came after the fact, nonconformity could hardly be considered an act of fragmenting Linux. That is not to say that standards are not a worthy goal. The issue here is that Debian is sticking to a standard that was well defined before the LSB was concieved, before the FHS was called the FHS. This publicly available standard predates the concept of Open Source. The Debian Policy Manual is what makes Debian a paragon of Free Software, of open practices, and a positive institution in general.

      It seems the the LSB is less of a standard to aspire to, then a LCD (lowest Common Denominator). While interoperability with the LSB as stated is an important goal, that does not mean that extra functionality, non-standard enhancements, or even differing but equivalent mechanisms should be wholly disposed of. That would just prevent evolution, and advancing the state of the art.

      You say that Debian should cast off Dpkg in favor of using RPMs internally. Does that mean that Red Hat should condemn and avoid all post 3.05 RPMS? While Red Hat uses a package format with the same name as the LSB packages format, they are distinct packages. There is nothing wrong with Red Hat improving their RPM package, which is distinct with LSB RPMs. As long as an avenue of interoperability with LSBs is maintained, then they are compliant. Likewise with Debian. You said that Debian should quit dpkgs and work to improve RPMs. That would be of absolutely no benefit, because even if RPMs grew to be feature compatible with currrent dpkgs, those RPMs wouldn't be LSB RPMs.

      Perhaps Debian dpkgs contain control information above and beyond that specified by the LSB. Are you suggesting that Debian cut off its left hand to be more conformant? As long as Debian can use alien to produce LSB RPMs (that would be missing the enhanced control info) then there is no reason to use RPMs internally. And just because alien can process LSB RPMs into less capable dpkgs doesn't mean that those RPMs should be preferred over less restrictive dpkgs.

      Hopefully you can see that debian using dpkgs are a good thing, and have no downside as long as there is still an avenue for LSB RPM interoperability. But since the LSB mandates RPM, the Debian Policy Manual cannot incorporate the LSB wholesale.

      Just a few more minor points.

      I still stand by my statement that raw .TGZ archives should be sufficient for software developers release. As maintainer of your Red Hat APT repository, do you really trust each developer to know the complete workings of your specific supported system? You would have to at the very least proofread and tweak the control information yourself if your goal is to maintain a useful repository for stable systems. To make my point even more extreme, packages are a convienence of efficiency, but not a strict need. If all "packaged" archives were statically compiled, then you would have a relatively heavy but interdependancy resilient collection.

      Also, at no point did I say "APT packages". As I stated a few paragraphs ago, dpkgs currently are more expressive than LSB RPMS, so they would be preferred. I said
      • Even if you had the [LSB] compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.

      In other words, the 3.05 RPM of Red Penguin's PPPoE is less valueable to a Debian system then a current DPKG version. This RP-PPPoE is readily available in the standard Debian repostory, so rather than installing an unverified or out of date version via dpkg -i, it would be best to use the standard .dpkg version via the standard APT repository. I can imagine that you are sensitive to this issue, being the maintainer of an APT/RPM repository, but I in no way stated that RPMS are APT proof.

      In contrast, it seems that RPMs are more "network aware" than DPKGs. One cannot simply #dpkg -i http://127.0.0.1/distro/rp-pppoe.dpkg as you can with RPMs. DPKGs are an implementation of the worse-is-better philosophy, completely depending on an external transport mechanism like APT, so that each can focus on their specialized strengths more efficiently, with less complexity. I guess that RPMs are trying to be all-in-one integrated solutions. the existense on your repository seems to rather clearly express how good RPMs handle that. I must admit, I was not aware that APT/RPMs were common just yet. I just knew that some Brazillian Distro (connectiva?) had developed them, and they had seemed to fall behind in APT development. What shortcomings do you see in uRPMi that APT/RPM handles better?

      Have you checked the alien maintainers web site? He has a fairly thourough comparison of DPKG, RPM and TGZ(with slackware control info). Going solely by the list of features, it seems that perhaps it would be less work to add Red Hat RPM's good features into DPKG. Though I still wouldn't want the LSB updated to this new DPKG+RPM format. The value of RPM 3.05 is that it is unambiguous, being fully defined and specified in Maximum RPM, and so there should be no reason why any arbitrary OS couldn't maintain interoperability with it.

      Down With RED HAT, DEBIAN FOREVER!!!!

      j/k,
      -castlan
  47. Re:Fighting the /. effect. Do not mod up. by cymen · · Score: 1

    Thanks but no thanks. But I'm getting close. I simply wonder why you would want 6 kazillion packages in the distrib when it could simply be the base system.

    You can continue to come back to my stupid posts with "show me your dick" or whatever but the fact remains that people are leaving debian, debian is lagging behind, the release process is very slow, etc.

    Just because I don't work on another distrib doesn't mean my dick is too small to comment on the problems.

    Some things are pretty obvious. If you would rather see the dick than the light just look in your pants.

  48. update (Re:Fighting the /. effect. Do not mod up.) by cymen · · Score: 3, Interesting

    Ok, ok, ok... I admit in a fit of boredom a bit of trolling was hard to pass up. But in all honesty the central issues I was trolling about are real issues and are causing problems. Of course it is better to be part of the solution instead of part of the problem but sometimes discussion of issues is enlightening. Debian people most likely do not want to discuss people leaving their project, the problems with their project, the release schedule ("it'll be released when it's done"), etc.

    Obviously Debian is a not a commercial product but if people who did this out of the good of their heart get so sick of the slow release schedule that they are leaving it seems obvious that there are a number of problems. Of course you can say "slashdot troll" and so can I but all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.

    Those things are pretty obvious from the outside. I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.

    The funny part of this whole thread is that I'm replying on a machine running unstable. But the fact is I don't think I'd use Debian on a server. As a sysadmin the core release makes sense but the fact that other non-essential packages like Apache are never upgraded in a release does not. I'd rather run the mainstream release of a package with perhaps only a few modifications for install location than the Debianized patched to hell version.

    So I currently run FreeBSD and RedHat (sigh) on my servers. I'd love to run Debian but it simply doesn't make any sense.

    Ok, now you can reply with six million reasons why I'm wrong, how this university runs Debian stable on 3,000 boxes, yadda yadda.

  49. Re:Hand off North Korea by Anonymous Coward · · Score: 0
    Ciao now, I'm, I'm now an online now I can all inbound financial won the long island allow the details on the any amount of Loma

    This post courtesy of Microsoft's Beachwood in mission. Er, Microsoft Speech Recognition.

  50. Re:Tee hee hee... he said "potatoe" by Anonymous Coward · · Score: 0

    Geez, you dittoheads are so fucking prickly it's pathetic. Go have a drink and pick up a few DUI's like our draft-dodging armchair warrior VP, maybe that will help you relax.

  51. Re:APBP by Anonymous Coward · · Score: 0
    I was thinking about purchasing power boat I wasn't present ways performance and features. I was playing with a woman CompUSA innovator was very impressed with his performance in the sizes monitor.

    this post brought to you by Microsoft speech recognition

  52. Re:Fighting the /. effect. Do not mod up. by Daniel · · Score: 3, Informative

    I simply wonder why you would want 6 kazillion packages in the distrib when it could simply be the base system.

    Why not? Having precompiled packages that integrate with the system is a very valuable thing to me and many other developers and users.

    As for "just the base system"...the primary reason the freeze was held up was because of bugs in the base system, many of them bugs from the upstream source relating to failures on obscure hardware or when using charsets other than the default one.
    The primary reason the freeze is now progressing again is because the base system is down to under five "makes the package unsuitable for release" bugs.

    Packages not in base or standard will simply be dumped if they aren't ready in time (about two weeks from now), as you'd know if you had read the article.

    the fact remains that people are leaving debian, debian is lagging behind, the release process is very slow, etc.

    The fact remains that a handful of maintainers have left in the last year due to burnout, the number of Debian maintainers is increasing overall, woody is a very impressive distribution, and it is (at long last) moving towards release.

    The fact remains that if you only read /. headlines, you will have only a narrow and sensationalized view of matters.

    The fact remains that sometimes experience matters, and uninformed opinions are uninformed. "I don't know a thing about aeronautics, engineering, or fluid dynamics, but I've flown on lots of planes, and I have this great idea about how you can make your 747s go faster.."

    Everyone has seen the accusation that "all those crufty packages" are holding up the release, it's been discussed dozens of times on the mailing lists, and not one person has yet produced a specific and concrete example of a way in which so-called "package bloat" is holding up the release. Hand-waving arguments, personal attacks, and oblique references to Fred Brooks are easier, I guess. *shrug*

    Daniel

    --
    Hurry up and jump on the individualist bandwagon!
  53. Re:Kernel version by doob · · Score: 1

    ...the package management system, which rocks, but only as long as you are just installing pre-made binaries. I never tried to create a RPM, but making a .deb from some arbitrary code you downloaded is definetly way to much work...

    You should investigate checkinstall. It makes making a .deb (or a .rpm or .tgz (for slackware) for that matter) as easy as a single command. Sure it doesn't take any dependencies into account, but you can't have everything :)

    --
    In the spoon, there is no Soviet Russia!
  54. Welcome to Debian! by Lord+Vipor+Scorpion · · Score: 1

    You might want to try netselect to find the nearest package mirror. The man page for apt-get goes over all the features. I find the much-touted 'apt-get update' -> 'apt-get dist-upgrade' to be overkill. For one thing, some packages haven't been put together or mirrored everywhere yet. The ease of apt-get can be deceiving, too. The Mozilla maintainer (Takuo Kitame) split out some of the extra goodies (ie. DOMInspector, JavaScript debugger, etc.) into separate packages, which took me a few days to figure out. Vaya con Dios!

  55. Red Hat to Debian by reaper20 · · Score: 2

    My conversion has been detailed here.

    I'm not going to get into the Debian/Red Hat argument here. To me, they're both fine distributions that deserve the attention that they're due. I don't understand the "stability" issue that some Debian fanatics get into. Red Hat has been stable as a rock for me. The thing that makes Debian rule is how easy it is to maintain and keep up to date.

    If you're a Red Hat/Mandrake user and has been looking to convert, this might be useful. FWIW, Debian is a mighty fine distro, give it a try, though you have been warned, it can be addictive. :)

  56. I installed using 2.4 kernel yesterday by bug1 · · Score: 1

    I did a netwrok install, i only needed to make a boot and root disk, _everything_ else (even base and kernel modules) i downloaded via the net.
    I was pretty lucky as my net driver (rtl8139) was built into the kernel, a lot of people would need the driver disks.

    I had no problems at all during hte install, there are still outstanding issues being worked on though.

    images from your
    /debian/dists/testing/main/disks-i386/3.0.19-200 2- 02-07/images-1.44/bf2.4/

    1. Re:I installed using 2.4 kernel yesterday by TaxSlave · · Score: 1

      Huh. I installed the 2.4.latest kernel two days ago. I was feeling kinda smug, having just installed an old Wyse 60 terminal, and decided it was time for a kernel upgrade.

      Now, when I see "Starting Kernel" I see a stopping system. When I use Lilo to boot the old kernel, I have a choice between dropping to a useless shell or continuing until the kernel panic.

      I had to spend yesterday using Windows. Tomorrow, I have to learn something new, 'cause I broke debian again. :)

    2. Re:I installed using 2.4 kernel yesterday by bug1 · · Score: 1

      Well, i meant that i boot floppies i installed from utilised the 2.4 kernel rather 2.2.

      With your problem, when you installed the new kernel it would have mentioned some things you have to do or it wont boot.

      Make your bootloader use
      initrd /boot/initrd.img-2.4.17-k7

      add 'do_initrd = Yes' to /etc/kernel-img.conf

  57. Question about Stability by tacocat · · Score: 1

    I think it's a great idea that Debian has developed wherein they are able to slide distributions through different levels of stability: Stable, Testing, Unstable. This is really something that is ahead of every other Linux distro out there

    One of the biggest claimed advantages that Linux has over so many other Operating Systems is that the stability is so much greater. It is for this reason that I have switched to Linux myself. But in reading the posts here, it seems that more people are concerned with the newest fad feature over stability when they speak of a computer to use on a regular basis with little acknowledgement for the need of a stable system

    At least Debian gives you the option to push yourself into the newer products that are available. The only thing that is asked in return is that you provide bugreport feedback

    I believe that the other Linux distros, and indeed other OSes, could gain a lot from the Debian model of software development in that they provide different tiers of advanced products wich you can select based on your desire to "fiddle" with the installation.

    I do however have some issue with the bloat that Debian has been gaining in the last 18 months that I have been using it. There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function. Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs. Last I checked, emacs was still a CLI compatable editing tool. This has really messed with my remote machine administration. And before you tell me to use vi, remember, it's my choice so zark off.

    I think that Debian has some really great ideas in it, but I am also wary that there are some bad practices that are encroaching onto the overall distribution as evidenced by the two examples I have cited above.

    1. Re:Question about Stability by Dwonis · · Score: 2
      I do however have some issue with the bloat that Debian has been gaining in the last 18 months that I have been using it. There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function. Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs. Last I checked, emacs was still a CLI compatable editing tool. This has really messed with my remote machine administration. And before you tell me to use vi, remember, it's my choice so zark off.

      Have you filed bug reports? Dependencies are handled automatically by the build scripts, so it's possible the maintainers haven't noticed those errors.

    2. Re:Question about Stability by Daniel · · Score: 2

      I think it's a great idea that Debian has developed wherein they are able to slide distributions through different levels of stability: Stable, Testing, Unstable. This is really something that is ahead of every other Linux distro out there

      To be fair, there's little new in the idea, although I'd like to think that our implementation is somewhat more advanced :)

      But in reading the posts here, it seems that more people are concerned with the newest fad feature over stability

      Because of some unusual situations within the Linux software world, potato's age is more critical than it might otherwise be. Many very useful software packages have been created or have come to maturity in the last year and a half. For instance, the web browser I'm typing this into (galeon) did not exist when potato was released...at least, not in any usable form.

      There are interdependencies that are being forced into the installation that are getting very expensive to manage. Examples are: Apache now requires mysql-client to be installed. But it is only used if you are interested in using mysql for authentication. That's a rather heavy handed requirement for a rather specialized function.

      I suspect that people who want to use mysql for authentication might differ with you on that :)
      In any event, this dependency seems to have been removed in unstable.

      Similarly, I was very happy with emacs until they make a package requirement for XFree86 in order to install emacs.

      Ok, you win. You've completely stumped me here. I cannot find an emacs package that depends on an X server. Could you post the control information for that package here so I can put together a bug report?

      Oh, in case this is it, depending on xlibs isn't a bug -- the X support in emacs is very useful, and it can't be enabled without this. Having xlibs installed will do nothing to you if you don't install the rest of X.

      Now some random general comments:

      Things that one person considers bloat are usually a feature request from another person.

      Some maintainers compile their package dozens of times, once for each useful combination of compilation options...this lets you be selective about what options you have installed, but tends to (IMO) bloat the archive and package list, and make things confusing for the user. Striking a balance is very difficult, and the only certain thing is that some people will be upset no matter what we do :)

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    3. Re:Question about Stability by tacocat · · Score: 1

      I have a PC that has no xserver-common or anything else related to it. It is intended to be my firewall. I have included three excerpts from the

      It is the reference to xfree86-common that is the problem

      pretorian:/home/tallison# apt-get -d install emacs
      Reading Package Lists... Done
      Building Dependency Tree... Done
      Package emacs has no available version, but exists in the database.
      This typically means that the package was mentioned in a dependency and
      never uploaded, has been obsoleted or is not available with the contents
      of sources.list
      However the following packages replace it:
      emacs19
      E: Package emacs has no installation candidate
      --------------------
      pretorian:/home/tallison# apt-get -d install emacs21
      Reading Package Lists... Done
      Building Dependency Tree... Done
      The following extra packages will be installed:
      libjpeg62 libtiff3g xaw3dg xfree86-common xlibs
      The following NEW packages will be installed:
      emacs21 libjpeg62 libtiff3g xaw3dg xfree86-common xlibs
      0 packages upgraded, 6 newly installed, 0 to remove and 0 not upgraded.
      Need to get 14.9MB of archives. After unpacking 48.2MB will be used.
      Do you want to continue? [Y/n]
      ---------------
      pretorian:/home/tallison# apt-get -d install emacs19
      Reading Package Lists... Done
      Building Dependency Tree... Done
      The following extra packages will be installed:
      libxaw6 xfree86-common xlib6g xlibs
      The following NEW packages will be installed:
      emacs19 libxaw6 xfree86-common xlib6g xlibs
      0 packages upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
      Need to get 7750kB of archives. After unpacking 22.6MB will be used.
      Do you want to continue? [Y/n]

    4. Re:Question about Stability by tacocat · · Score: 1

      I have tried to, but the debian bugreport application has some issues with a non-local smtp server.

    5. Re:Question about Stability by Daniel · · Score: 2

      It is the reference to xfree86-common that is the problem

      As I explained in private mail before I checked here, xfree86-common is just a bunch of documentation and skeleton files to support X clients and servers. It doesn't install any programs or configuration, and it doesn't start an X server.

      It is being pulled in because xlibs now depends on it, not because of emacs; it is far less bloated than emacs itself; and the X maintainer has a history of making good decisions about his packages, so I presume he did this for a sound reason unless I hear otherwise.

      Daniel

      --
      Hurry up and jump on the individualist bandwagon!
    6. Re:Question about Stability by Dwonis · · Score: 2

      Heh. Save your bug reports to a file and email them to me. I'll be happy to file the reports on your behalf.

  58. Re:update (Re:Fighting the /. effect. Do not mod u by Panoramix · · Score: 1
    The funny part of this whole thread is that I'm replying on a machine running unstable. But the fact is I don't think I'd use Debian on a server. As a sysadmin the core release makes sense but the fact that other non-essential packages like Apache are never upgraded in a release does not. I'd rather run the mainstream release of a package with perhaps only a few modifications for install location than the Debianized patched to hell version.

    Well I don't know... what exactly is that you need from the mainstream package that is missing in the one in potato? I mean, you could build a potato package from the woody sources (apt-get source apache, with woody as deb-src in sources.list), but... why?

    So I currently run FreeBSD and RedHat (sigh) on my servers. I'd love to run Debian but it simply doesn't make any sense.

    Funny. The only Linux I allow in my servers is Debian stable.

  59. Re:Fighting the /. effect. Do not mod up. by cymen · · Score: 2

    The fact remains that if you only read /. headlines, you will have only a narrow and sensationalized view of matters.

    So you're saying that the Debian doesn't have a slow release problem? That is only a /. sensationalized view of Debian? I think not.

    The fact remains that sometimes experience matters, and uninformed opinions are uninformed. "I don't know a thing about aeronautics, engineering, or fluid dynamics, but I've flown on lots of planes, and I have this great idea about how you can make your 747s go faster.."

    Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything... It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.

    Everyone has seen the accusation that "all those crufty packages" are holding up the release, it's been discussed dozens of times on the mailing lists, and not one person has yet produced a specific and concrete example of a way in which so-called "package bloat" is holding up the release. Hand-waving arguments, personal attacks, and oblique references to Fred Brooks are easier, I guess. *shrug*

    Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.

    Anyway, I'm done... I don't think that my critizing is going to help anything. Helping would be much more beneficial. It's just that reality is so frustrating sometimes :).

  60. Re:update (Re:Fighting the /. effect. Do not mod u by cymen · · Score: 2

    Well I don't know... what exactly is that you need from the mainstream package that is missing in the one in potato? I mean, you could build a potato package from the woody sources (apt-get source apache, with woody as deb-src in sources.list), but... why?

    Because as a sysadmin running mainstream packages is more beneficial to prepackaged things. The combination of Apache+PHP+PostgreSQL/MySQL is far better managed outside of the Debian process. If you can live with PHP 4.0.1 for a couple years than go for it.

    The easy solution there is to simply build my own .debs and that is what I'll probably do in the future when I have more time to read the packages guide.

    Funny. The only Linux I allow in my servers is Debian stable.

    RedHat wasn't and isn't my choice.

  61. Re:update (Re:Fighting the /. effect. Do not mod u by Daniel · · Score: 4, Interesting

    Debian people most likely do not want to discuss people leaving their project

    You keep bringing this up. Only a few people (less than ten, probably less than five; I don't have an exact count and not all the announcements were public) have left in the last year, and most of those were burn-outs who have continued their involvement with Debian as users. (that is to say, they are still active on the mailing lists and submit bugs/patches; they just don't take on the commitment of maintaining packages, etc) Only one person cited the release schedule as a reason for leaving. That's hardly droves.

    Do you really expect 6000 people to be continually happy with everything about the project? I hope you don't think we're the Borg :)

    I also never said I think the release process was perfect; I merely disagreed with what you claimed were the flaws in it.

    all criticism of Debian is pretty much ignored. The Debian project is a very insular project that isn't very open to criticism or change.

    It's quite hard to take it seriously when most of the criticism is making the same few claims without providing a shred of hard evidence, and when most of the changes suggested are the same one we've heard before.

    If people are terse in replying, it's because these specific issues have been discussed for years in gigantic threads already, and the list traffic is high enough that no-one wants to waste more bandwidth on it. The consensus each time has been that the number of packages is a red herring, and we need to look elsewhere for the problems.

    Ben Collins recently observed that the "Debian is dying, it has too much bloat" thread has been around, in various forms, since he became involved with the project, and I can say pretty much the same thing. Some people even suggested, only somewhat facetiously, that it's been around ever since Ian realized he couldn't maintain the entire distribution himself :)

    I don't know what people think of these issues on the inside and frankly I don't really care. All I care about is progress.

    How admirably utilitarian of you. It also absolves you from making any constructive suggestions that people will listen to..

    Oh, and if you want my personal opinion: there have been a lot of technical measures taken to streamline Debian releases in the past year or two. Many people have suggested that woody's long cycle implies that these measures are failures. I personally suspect, although I'm not yet sure I believe, that these measures are responsible for the fact that woody is being *released at all*.

    Compared to what I remember from previous releases, the number of coordination problems we've had with coordination and dependency issues does not seem *to me* to have increased proportionally to the package count; in fact, I think it may actually have gone down. (this is all a very fuzzy estimate, and should not be taken particularly seriously)

    Automatic dependency checks to ensure an internally consistent "testing" distribution, BTS enhancements for all manner of things, automatic lists of base system bugs, continual improvements in the package maintainence tools (debhelper, debconf, lintian, etc)...all of these have addressed particular problems in the distribution. I think that claiming that they didn't work simply because they didn't solve every single problem at once is failing to see the forest for the trees.

    And finally, since I said I don't think your explanation is correct, here are some specific things I have seen that probably held things up, based on my personal experience within the Debian Project:
    * Effort was diverted from boot-floppies to debian-installer; then, when it appeared that debian-installer wouldn't be releasable in time for woody, it was put on hold and the installation team scrambled to get boot-floppies to work again (since it had since been broken by changes to the base system) We lost at least several months here.

    A major problem here (and the reason we want to get rid of boot-floppies) is that the boot-floppies code is fragile and tends to break whenever it is so much as sneezed upon. It's been a culprit in past delays as well.

    debian-installer will be used for woody+1, and to hear joeyh talk about it, it's the coolest thing since debhelper :) In any event, it's a huge technical improvement.

    * Many new architectures were added, some at the "last minute". This resulted in many more "interesting" ways that packages can fail to build, especially since the build tools often behave subtly differently on different archs. In some cases, we actually have to use completely separate branches of code! (gcc 2.95, 2.96, and 3.0 are all required for at least one arch, for instance, so all code must compile with all three of them)

    (I should add that Debian has probably made a tremendous contribution to the portability of free software in general, simply by building every single program in the archive, no matter how exalted or humble, for architectures the author often never heard of, and submitting patches for the failures)

    At the same time, some core packages always seemed to be broken on some obscure arch, generally due to the immaturity of that port of the program. Today g++ wouldn't compile hppa code; tomorrow libc didn't build from source on s390. And the kinds of platform bugs that crop up in these packages tend to be hairy and hard to solve.

    * Many maintainers became too busy to maintain their packages (perfectly ok) but left themselves as the official maintainer in the package system (not ok!) This meant that many packages became buggy and went unattended to for far too long before anyone noticed. In fact, this is still a problem, although measures (technical and social) have been and are still being put in place to combat it.

    This is the one place where size hurts: with so many maintainers, so-called "MIA"-ness seems to be somewhat inevitable. The main fix here appears to be breaking down the semi-feudal "one maintainer, one package" paradigm that has become ingrained in the distribution.

    I think that sums up the major things I have seen slowing the project down, and they're based on hard (or at least firmly mushy :) ). The number of packages has little to do with it, as far as I can see.

    And of course, remember: these are only my personal opinions. I may be wrong, and other maintainers probably disagree violently with me.

    Daniel

    --
    Hurry up and jump on the individualist bandwagon!
  62. Re:update (Re:Fighting the /. effect. Do not mod u by Daniel · · Score: 2

    A few corrections..

    6000 people

    That should of course be ~1000 at last count.
    I was somehow thinking people=packages or something. :)

    Also, I realized it looks like I'm contradicting myself a bit: first "size doesn't matter" and then "technical measures to deal with issues are helping us release.."
    Basically, I think that archive size has not been much of a problem precisely because people have been addressing some specific technical problems. Even if they weren't meaning to work on that :) -- the improvements in our infrastructure have enabled us to greatly expand the archive with relatively little trouble.

    Daniel

    --
    Hurry up and jump on the individualist bandwagon!
  63. Re:update (Re:Fighting the /. effect. Do not mod u by Panoramix · · Score: 1
    Because as a sysadmin running mainstream packages is more beneficial to prepackaged things. The combination of Apache+PHP+PostgreSQL/MySQL is far better managed outside of the Debian process. If you can live with PHP 4.0.1 for a couple years than go for it.

    I see your point. And yes, I've been able to live with PHP 4.0 for a couple of years, indeed (4.0.3, actually). PostgreSQL and MySQL from potato, too --never had a problem.

    Sure, sometimes I need a newer version of some package (say, openldap). For those I usually pull the woody source package and build potato binaries. Check this article, it explains the basics on doing this trick.

    The easy solution there is to simply build my own .debs and that is what I'll probably do in the future when I have more time to read the packages guide.

    Man, trust me, is far easier to use the woody source packages. Building debs is not trivial.

  64. Re:Fighting the /. effect. Do not mod up. by Anonymous Coward · · Score: 0

    Debian has become a dinosaur that will just die out one day.

    It is a system that wants to be everything for everybody by including thousands of packages.
    Have you looked at the package list recently ? Main is friggin 1700k (compressed) !
    Hundreds of developers who want to push their little pet package into the distribution, and no true leadership or vision behind the whole thing.

    I will not be surprised when mirror admins start dropping it because of its huge size, and then the convenient apt-get (which meanwhile has been cloned for other dist-s) will be useless.

    I used to be a die-hard Debian fan from the 1.3 era, but I cannot recommend it to anyone anymore, and I use it mainly because I just know it too well.
    Commercial and other free distributions are taking what's best in debian technology, and are offering leaner and more modern stable releases.

  65. Re:Wow good to see the light at the end of the tun by Dwonis · · Score: 2

    FUD!! Only one developer quit.

  66. It releases when it is ready. by castlan · · Score: 1

    The last time I did a comparison, OpenBSD and Debian were neck and neck, though I theorized that it looked like Debian would fall behind by the Next release of OpenBSD. OpenBSD releases every 6 months, December and June, disregarding subjective milestones. That is, 3.0 just meant that it was the release after 2.9. Regardless, I was wrong, Debian has kept up, even if the releases aren't as consistently timed. OpenBSD released 3.0 on December 1, 2001, OpenBSD 2.9 released June 1, 2001, and so on. Debian released 2.2r5 on January 10, 2002. 2.2r4, was released on November 5, 2001. 2.2r3, was released on April 17, 2001. 2.2r2, was released on December 3, 2000. To me, they both seem to maintain about 2 releases per year.

    Of course, Debian is very conservative, issuing only bug fixes and security patches, and strictly limiting new development for each new major relaseWoody. OpenBSD releases are also stable compared to Debian, but the development isn't segregated from the bug-fixes via Feature-freezes with Major/Minor releases as in Debian. Off the top of my head, OpenBSD had some significant changes, including XFree86 4.1 and PF replacing IPF.

    You say that by the time releases come out, software packages are out of date. I have to challenge that - cutting edge packages are by definition not stable, and a package being "out of date" doesn't mean that it is obsolete just because a newer version exists. Bugfixes are not a valid excuse to upgrade to the latest version of a software release, as you may add just as many bugs as you fix. The Right Way is to backport fixes, which Debian does on a regular basis. Additional features are only significant if you find them useful, they don't make your current version any less useful. If you find that you need features added in a newer version, then it is trivial to apt-get update leetproggie.
    If you think that rolling your own version of a package is preferable to a guaranteed working version, that means that you shouldn't be using a distribution: you should be grabbing your own .TGZs and building your own cutting edge system.

    As it was already established that you shouldn't be relying on a stable distro but rolling your own system, you shouldn't need to rely on an installer. Just extract your Linux filesytem from a tarball and be done with it. You can roll your own options, so why do you need an installer to walk you through it? If you are as leet as you imply, the Debian installer is ideal... it allows you to use the shell to complete as many steps as you wish, and will take over from where you left it when you start to trip over your own feet. What is so awful about the Debian installer? It isn't a WIMP GUI? What are some of these "many bugs, etc."?

    If you really need a WIMP (Windowing Interface, Mouse Pointer) then you should look into Progeny Debian, which made a good installer (read: point and click) which leverages the packages. The same GUI installer is reused for later reconfiguration of the system as well. Unfortunately, Progeny no longer sells their GUI improved version of Debian (Newton release, a meld of Potato and Woody) but you can can still find an ISO if you would like to try it. If you become comfortable with the Debian CLI subsystem, you can always point /etc/apt/sources.list towards the Debian archive to upgrade to Woody.

    As for your personification, you should at least qualify Debian as having High Functioning Autism, or perhaps Asperger's Syndrome. But the prognosis is very good, as Debian has an excellent support community. And that obsessive mind works quite well with clearly defined rules, which makes the Debian Policy Manual quite a boon with the thoroughly defined package dependancies superior to competing operating systems.

  67. Up to date distributions by castlan · · Score: 1

    When you say up to date, do you mean the distribution installed on your system, or the CDROM/ISO? Rather than reinstalling each new version with a CD, it is much simpler and to seamlessly upgrade your system with one command, and you don't need to wait 6 months for a new release to do it. You can do upgrade daily if you wish. It seems a little silly to wait for CDs to be pressed and distributed, or even to download entire 650 Megabyte ISOs when you can download only the individul files that changed, saving time and bandwidth.

    You can think what you want, but it might make sense to consider that the "testing" distribution style is still pretty new, this upcoming release will be the first to utilize it. After that, I really do except that feature realeases will occur more frequently. Of course, that will have little effect on current Debian users with net connections, who always had the option of tracking more current releases if stability wasn't their top priority.

    -castlan

  68. Debian isn't out-of-date by Dwonis · · Score: 3, Insightful
    Debian is the Linux distribution with the shortest release cycle in the world: it is released daily. After a few years, some people take a collection of packages that are known to be very solid, hack together an installation system for them, cut a CD, and call it "Debian stable".

    Anyone who says Debian is out of date is just wrong.

  69. Re:Fighting the /. effect. Do not mod up. by Daniel · · Score: 2

    So you're saying that the Debian doesn't have a slow release problem? That is only a /. sensationalized view of Debian? I think not.

    I quote you:

    the fact remains that people are leaving debian, debian is lagging behind

    "people are leaving debian" is sensationalized. See my other post.

    And honestly, the "lagging behind" bit is overdramatized in my opinion. 6-month cycles for major new releases are not a necessity, folks.

    I was referring more to the "Debian is Dying" overtones, a meme that some people seem to have picked up lately. I don't know where they got it from. Maybe they like the alliteration.
    (although I'm not sure /. really has been that complicit in this)

    Maybe that is because people are getting so frustrated at a lack of progress in the change that they'll suggest anything

    Fine, but it doesn't mean that these repetitive "suggestions" do anything more than clog up the communication channels every time they have to be discarded. (about every three months on average)

    It's easy to shoot people down but I don't really see you coming back with any response besides "this isn't an issue and you aren't fit to question/make suggestions" and ignoring things that are an issue.

    Likewise, it's easy to make broad claims about what things are serious "issues" without backing them up. When someone does indeed do this, and comes up with the same "new" idea as many other people who are unfamiliar with the situation, I tend to dismiss the comment as coming from a person who doesn't have enough information or experience to assess the situation accurately.

    Maybe part of that is because these people are partly right. FreeBSD has a nice steady release process and the ports system works well. Obviously Debian isn't FreeBSD but it doesn't hurt to look at other ways of doing things.

    Another explanation is that "for every complex problem, there is a solution which is simple, obvious, straightforward, and wrong"...

    Actually, it's you should mention that, because someone started a thread about that just the other day on debian-devel. It's still going; I'm browsing the most recent few messages in another window. Many people in the thread agree that some changes are a good idea, based on the experience of this cycle; however, we can't change the entire process this close to a release.

    Personally, I think the closest thing to the "split it up" approach is that we could put out several quick releases on a frozen core -- but changing the core will be a pain anyway, we can't get around that. It's the nature of the core.

    And I'm not really convinced this is as simple as it seems. In this area, the devil is generally in the details. Two years ago, we thought "testing" was going to issue in a golden age of quick releases. It really has been a tremendous help (IMO), but it hasn't lived up to some of the overly high expectations that some people had of it.

    Daniel

    --
    Hurry up and jump on the individualist bandwagon!
  70. Re:Fighting the /. effect. Do not mod up. by cymen · · Score: 2

    You make some interesting points and I definately agree that the "Debian is dying" crap is just that - crap. I hadn't realized that such discussions come up so regularly on debian-devel. I'll have to start reading some of the mailing lists. The least that can be said is that the next couple of years will continue to be interesting.

    I think for me the best thing to do would be to learn the packaging process and do my own packages for things I can't live without. That would be far more beneficial to myself than whining about crap on /. :).

  71. Wow by Moosechees · · Score: 1

    I'm surprised there haven't been more trolls about the word choice of the title...

  72. Re:update (Re:Fighting the /. effect. Do not mod u by cymen · · Score: 2

    You've made some interesting points. I'm going to drop anything inflamatory just to drop it and get on with things. No flame intended... I do care what people think on the inside and after some thought I'd have to take back the "insular" comment as it is obvious a lot of work goes on via mailing lists.

    Many maintainers became too busy to maintain their packages (perfectly ok) but left themselves as the official maintainer in the package system (not ok!) This meant that many packages became buggy and went unattended to for far too long before anyone noticed. In fact, this is still a problem, although measures (technical and social) have been and are still being put in place to combat it..

    I think what led to that insular comment was the general feeling of having the "one maintainer, one package" thing and the problems that result. It sounds like that is being fixed and seeing people say "fix it or I'm going to fix it myself" in terms of abandoned packages is very refreshing...

    Oh, and if you want my personal opinion: there have been a lot of technical measures taken to streamline Debian releases in the past year or two. Many people have suggested that woody's long cycle implies that these measures are failures. I personally suspect, although I'm not yet sure I believe, that these measures are responsible for the fact that woody is being *released at all*.

    Well as I said in my other post it will be interesting watching the next couple years. Change takes time...

    You point out a lot of holes in some arguements that come up fairly regularly here and (it sounds like from your posts) on the debian mailing lists. Definately gives me something to think about. Thanks for posting for what that's worth...

  73. Re:update (Re:Fighting the /. effect. Do not mod u by cymen · · Score: 2

    Man, trust me, is far easier to use the woody source packages. Building debs is not trivial.

    I trust you but I'll have to look at it myself. At least I can read over the package sources for earlier versions. For some things we can't live with an older version of PHP/Apache/DB. Hard choices...

    Sure, sometimes I need a newer version of some package (say, openldap). For those I usually pull the woody source package and build potato binaries. Check this article [debianplanet.org], it explains the basics on doing this trick.

    Now that does sound sweet. Thanks for pointing it out.

  74. WTF??!! by Anonymous Coward · · Score: 0

    Why was this modded down? The moderators are smoking CRACK.

  75. Re:Hand off North Korea by Anonymous Coward · · Score: 0

    W is starting WWIII. He is going to start burning blacks- canada will take the role of poland.

  76. seriously.... by dogas · · Score: 1

    why is there so much debate/commentary about binary distros nowadays? I've been using sorcery for 3 weeks, and I've never been more satisfied. I'm willing to wait an hour for a piece of software to be optimized for *my* particular hardware configuration, rather than waiting 20 minutes for downloading a pre-compiled binary. cast apt-get, anyone?

    --
    'When the going gets weird, the weird turn pro.' -HST
    1. Re:seriously.... by danrees · · Score: 1

      Well, considering most optimisation takes place in the kernel, it seems like a waste of time for me.

      How is compiling GNOME from source going to make it efficient? ;)

  77. You suck at trolling, asswipe by Anonymous Coward · · Score: 0

    You are really giving trolls a bad name. You should try for something a little more than the automatic -1.

  78. Debian Woody nearing release? by Anonymous Coward · · Score: 0

    I'm going out for my third date with my new girlfriend tomorrow night, so my woody is also nearing release.

  79. WOODY NEARS RELEASE by Anonymous Coward · · Score: 0

    Into Taco's mouth!

  80. Re:Imagine, by Anonymous Coward · · Score: 0

    You don't need debian for that, just visit the slashdot editors at night.

  81. ahhh by Rogain · · Score: 1

    I never release my woody, I keep a tight grasp on it at all times.

    --
    The current Slashdot moderation system is made by gay communists!
  82. debian has problems by Anonymous Coward · · Score: 0

    I use debian myself, but I find it extremely irritating in some respects. I do find that the most critical applications work fine. However, some of the maintainers are total retards. Like for instance, whoever is doing the windowmaker package has to be shot There are a countless number of bugs, and the maintainer hasn't done anything about them, like WPrefs is totally broken. However, it works perfectly fine when compiled straight from the regular source (same version). Another example, Fluxbox: you would expect to find a sample menu file included with the package, but NO! The maintainer thought it would be cool to just leave out the menu, and there is absolutely nothing except a menu with xterm, restart, quit. I search around, dpkg -L fluxbox, and there appears to be no sample menu included. Great work maintainer. I'm not using the stupid Debian menu system, because it is crap, and I want my own menus. Ah well...there goes another thing to hand compile myself. People always complain about Debian's installer, and I must say, I agree with them. People tell me, why is debian's installer so bitchy or difficult? Well, when I'm told to use tasksel in #debian, I tell them it's broken in woody/sid, in other words, it's useless, and they say nothing back to me. Then we have aptitude, dselect, deity, gnome-apt, etc, etc. dselect is extremely fucking annoying, it does totally random things sometimes, like install packages that are completed unrelated. Whatever happened to console-apt? _WHY_ do they think they should replace a good working utility with something else? That I don't understand. _WHY_ is it that a debian release only occurs every 20 million years? I would like to have a system that is functional, and not expect breakage all the time. _WHY_ is galeon not in testing? _WHY_ is there no XFree86 4.2.0 in woody/sid? It goes on and on. You always have troubles with Debian, and you only get excuses from people. "OH, well... the maintainer seems to have let a few bugs creep in to the package, and so uh......it won't make into testing until the maintainer gets a fucking brain, and fixes the package". Even when you get sid packages, it's never guaranteed to work in woody. Congrats to the idiot who recently released another broken mozilla in sid. Personally, I like Debian policy about some things, but I would like a functional system, and see more releases and a new fucking installer. Don't start giving me this bull shit about it being free software and I shouldn't be pissing my pants over it, other distributions do it well, Debian should do it too.

  83. Re:support for kernel 2.4 in the installation syst by danrees · · Score: 1

    Installing kernel 2.2 as the default isn't a big issue. People didn't complain when Slackware 8 was released running 2.2. You still had the choice to use 2.4 if you wanted to.

  84. Re:Fighting the /. effect. Do not mod up. by Anonymous Coward · · Score: 0

    Leaving the fact that your post adds up to nothing but trashtalk, I can give you some of the vision that you so severely lack. Think of debian as a mother distro. The vision is simple. Get as much into it, make it as stable as possible, and supply tools to maintain the mess. What else could a distro be about? Firing rockets? Waging wars? Get real! If you think that it is missing something, start your own "pet project"! What is the problem!

  85. Later by castlan · · Score: 1

    Postgresql 7.1 is available, and will ship with Woody. 6.3.2 is also available for backwards compatibility.

    Any other shortcomings to point out?

    -castlan

    1. Re:Later by bad-badtz-maru · · Score: 1


      No other shortcomings. Any time a Debian zealot makes reference to the ancient versions of the software packaged as "stable" there is always some comment about "no need for the latest toys". This really turns a blind eye to the fact that software such as postgresql, sendmail, and even perl have had ten trillion bugs fixed since the releases that come with Debian stable. Debian addresses security issues in a reasonably timely fashion (although red hat typically does have them beat now). I would like to see them realize that new versions of software can represent a significant amount of bugs fixed and that it is not necessarily a good thing to just continuously backport security fixes to ages-old versions of these programs.

      To point out the good, a base debian installation makes an excellent foundation on which to tarball everything. I have done this to scores of machines (I have four to do this to next week) and it works reasonably well.

      maru

  86. Debian Security by castlan · · Score: 1

    Did you even bother to click on the link so kindly provided in the previous post? It looks like you barely comprehended what Shiny said at all. Debian Stable is comparable to that of OpenBSD releases. You state that comparing the two is daft, after complaining about "a year and a half" of security updates. Or you could realise that perhaps the code has been audited for a year and a half.

    The OpenBSD security audit, and all security audits, need to be performed on a stable code base. If you use new and untested code, then all of that auditing had been defeated. The OpenBSD audit only takes place on the "core" of OpenBSD, which means that you open yourself to insecurity if you activate the "ports" and other software which isn't considered part of OpenBSD proper - hence the claim of no remote explaits in the "Default install".

    As for Debian, the security does not restrict itself to any "core" of packages - all included Free Software is valid, and their exploits "count". In spite of this, Shiny's link would have told you that in 2001, Debian GNU/Linux only had 1 remote exploit compared to OpenBSD's 7 remote exploits. So if you are planning on running Ports not included in OpenBSD core, Debian Stable arguably has better resistance to "remote holes".

    This year and a half of debian auditing is evidently effective, contrary to your statement that "Debian has comparable security problems to any other" Linux distro. The same Security Focus report for 2001 claims that Debian Gnu/Linux had 14 total vulnerabilities, compared to Mandrakes 29 and Redhat's 40. "Sweetheart", you should realise that Debian Unstable is only "unstable" compared to Debian Stable. In Practice, I find that Debian Unstable is comparable to a Redhat x.0 release, Testing is comparable to most Redhat .x releases later than 0 (e.g. 7.3) and Debian Stable is comparable to an OpenBSD Release.

    -castlan

    1. Re:Debian Security by ideut · · Score: 1

      Unfortunately I can't continue this conversation right now. But I will just say: next time you write an improvised diatribe from a position of total ignorance, you will not be let off the hook so lightly.

      --

      --

    2. Re:Debian Security by Shanep · · Score: 2

      You say "Debian is not Free Software" and then call this guy ignorant?

      You sir, are a class AA fuckwit.

      I find Testing, to be the most stable Linux distro I have ever used, besides Stable.

      At best, I guess I could give you the benefit of the doubt and assume you to just be a troll. PS, this is a compliment.

      --
      War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
  87. Re:Hand off North Korea by Anonymous Coward · · Score: 0

    Yeah, and I guess Bill Clinton fills the role of Neville Chamberlain.

  88. Re:Hot for David by Anonymous Coward · · Score: 0

    Is wanting to bang the crap out of Gillian Anderson a bad thing?

    I have a conspiracy theory in my pants as we speak! Who wants in on it? ;-)

  89. I've noticed something curious ;-) by Anonymous Coward · · Score: 0

    Rock-hard stability up till just prior to any new release of Woody, where a unstable process overflows and I dump core. What could be causing this? ;-)

    Wait...I think I have discovered the source

    http://attrition.org/gallery/computing/tn/linuxc hi q.jpg.html

  90. Mod the parent UP by castlan · · Score: 1

    this post shouldn't be +5 insightful. It should be a link off of the debian Homepage.

    Maybe not, but it should at least be under the About link, or in an advocacy page. The salient point is that Debian, as an open organization, is fundamentally differnet than currency modulated corporations that release Linux. If somebody decides to spend 8 hours a day, 2 days a week working on FreeCiv for Debian, there is no resulting negative impact to the core packages such as Apt. A bug in Apt-get is orthoganal to work done on "extra" by hobbyists who don't take resources away from core maintainers.

    As stated, bugs in the base system held up release. Bugs in 6 kazillion non-core packages are irrelevant to release.

    -castlan

  91. New versions by castlan · · Score: 1

    There is a subtle difference you might not realise. For Debian, the "later toys" are all that are added in newer releases. If you consider that bugs fixed in newer releases can be outweighed by bugs added with newer features, then you might see that there is a better way to fix bugs. When bugs in package foo3.2, the answer isn't to upgrade to foo3.3 - debian backports the fixes, resulting in foo3.2-x, where x is incremented for each new bugfixing release.

    The upshot is that you cant compare a package's bugs by looking at the Debian version - that is what the changelog is for. The Debian version only indicates additional new features. If the package foo3.3 adds a new feature (toy) that you actually need, then foo3.2-x won't be sufficient. Debian doesn't just backport security fixes, bug fixes are backported too - but usually the emphasis is just on "important" major bugs, which includes security fixes.

    To reciprocate, Red Hat has made significant improvements to their security with their new empasis on servers over desktops. In my experience, I still find that Red Hat is not yet comparable to Debian Stable for server security. Perhaps if the trend of profitability and server emphasis continues, then the advantages of commercial support will prevail and Red Hat will prove superior WRT security.

    -castlan

    1. Re:New versions by bad-badtz-maru · · Score: 1


      That's the problem, Debian doesn't backport the bugfixes as I think you are suggesting. They backport security fixes.

      I concur on the redhat issue. They are addressing security issues faster but the base installation is still not as secure as Debian.

      maru

    2. Re:New versions by castlan · · Score: 1

      Perhaps you are correct. In this case, "Debian" is not so much an entity, as an umbrella for the maintainers who volunteer their time. If this is a problem, then the answer is to report the bug, so that the maintainer is aware of it. If the maintainer is unresponsive after a reasonable amount of time, then one can always package the newer version which fixes the bug, as per the directions in the Debian developers section. This fixes your immediate problem. To help the Debian comunity, raise the issue via the appropriate Debian mailing list, and volunteer your updated dpkg as a candidtate for a Non-Maintainer Upload (NMU).

      I still feel that for packages I am aware of, bugfixes are considered important, and are usually timely, if not subject to "fix in 24 hrs or your money back!" If you disagree, there are always options. If you need such guarantees, you can always pay for Debian support. One such company is Progeny Linux who used to distribute a very useable GNOME centric distribution called Progeny Debian. I believe they still maintain it somewhat, though it never made it past the "Newton" release, and they recommend that users upgrade to the current "Woody" release of debian 3.0. *sigh*

  92. Informative? Its wrong! by Nailer · · Score: 2

    This is informative? Its demonstrably incorrect for one thing, about both the FHS and how packages are handled by Alien. Problem: the people who read (and moderate) Debian stories are the ones interested in Debian to the point of excluding anything that seems counter to the direction of their distribution.

    Oh well, I guess I was never going to get much of a chance.

  93. Whoa there! by castlan · · Score: 1

    I don't believe my post was flawless in any sense! Does that mean that it didn't have iny information worth reading? I am very dissapointed by your reaction here, especially the victim mentality. How did you not get a chance? Despite your fears to the contrary, you were not modded down. There was no summary judgement or execution by the Slashdot wing of the "Debian Community" You were hardly excluded, and just about every post with positive moderation was very fair and even, not rallying against any people expressing "counter-Debian" sentiments.

    I really wish that I didn't see this post. Perhaps a negative moderation wouldn't have been uncalled for in this case, if it obscured this post. I suppose that is because I find /. karma probably isn't as valuable as respect. :(

    -castlan

  94. Offtopic, Personal post - IHBT by castlan · · Score: 1

    But so what, it's not like I have a life at this very moment. So I've waited a business week, can you continue this conversation yet?

    Any _real_ troll worth his salt would not surrender so easily. Any respectable conversant would realize when they were mistaken, and submit with honor. Only sneaky vermin such as yourself would scuttle off and pretend it was an act of generosity. That is not to say that you wouldn't be doing us all a favor by just going away, unfortunately, your kind tends to reinfest after the lights go out again.

    So, step into the light. Are you a man, or are you a mouse? (Because you definitely aren't a troll. The billy goat would have easily kicked your ass.)