Announcement

Collapse
No announcement yet.

Debian Wheezy Now Has Less Than 100 Critical Bugs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Debian Wheezy Now Has Less Than 100 Critical Bugs

    Phoronix: Debian Wheezy Now Has Less Than 100 Critical Bugs

    Debian 7.0 "Wheezy" is now under 100 release-critical bugs. The release of Debian Wheezy is now not too far out...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I always found the Debian way to handle releases quite bizarre, and this time around it's no exception. Debian still tries to be "theoretically bug-free". This unnecessarily delays releases, sometimes for many months, without improving the overall product quality. Meanwhile, bugs are fixed upstream, but new versions are not incorporated. Instead, Debian tries to be more clever than the developers of a particular software, and picks various fixes, or includes custom modifications. Essentially, this often creates Debian-specific forks of many software packages.

    The OpenSSL debacle is a good example of why this is a bad idea.
    Last edited by brent; 21 March 2013, 08:55 PM.

    Comment


    • #3
      Stability.

      Bug fixing doesn't stop at the program. It also has to inter-opt with other programs and not cause further bugs. With this delay, it does improve the overall product quality.

      Comment


      • #4
        The installer is a big blocker too. In the past, from what I understand, the installer was more of a blocker than the bug count. Reading the mailing lists shows that Debian's Release Team considers the installer close to finished and don't expect it to be a blocker this go-round, though.

        So, no, it's not like a release of 40,000 packages is being held up by bugs in 96 of them. For now. We'll see what happens when the installer is declared release-ready. Then things will get interesting.

        Comment


        • #5
          Originally posted by brent View Post
          I always found the Debian way to handle releases quite bizarre, and this time around it's no exception. Debian still tries to be "theoretically bug-free".
          Debian is never bug free and never tries to be bug free... What's really bizarre is distros that ship software that crashes during normal usage by an end-user . That's what Debian is trying to avoid doing with their releases, and in addition to that they have a bunch of release goals for packaging and improving all the software in the distro. Not to mention, that Debian packages, by **FAR** more software than any other distro with a lot of devs stretching their time out to cover dozens or even hundreds of packages.


          Originally posted by brent View Post
          This unnecessarily delays releases, sometimes for many months, without improving the overall product quality.
          How does freezing the archive so that no new bugs can be introduced and making patches that fix application crashes not improve overall product quality? You need to explain your point because you haven't.


          Originally posted by brent View Post
          Meanwhile, bugs are fixed upstream, but new versions are not incorporated.
          The bug fixes are incorporated during the freeze if they're important bug fixes.

          Originally posted by brent View Post
          Instead, Debian tries to be more clever than the developers of a particular software, and picks various fixes, or includes custom modifications. Essentially, this often creates Debian-specific forks of many software packages.
          It's not a fork if the patches are accepted and used upstream.. So you're wrong.

          Originally posted by brent View Post
          The OpenSSL debacle is a good example of why this is a bad idea.
          Sooo... 99.999% of security exploits are caused by upstream and the 00.001% of the time that the distro packager makes a mistake, partially because a dev from upstream said "if it helps with debugging, I’m in favor..." You think that's enough of you to make an example out of? Fantastic.
          Last edited by Sidicas; 21 March 2013, 09:58 PM.

          Comment


          • #6
            Also wish to add: Debian has a lot of packages. It's a complicated distro to begin with, and the huge number of packages only makes it even more complicated. It's a lot easier for a minimalistic distro with only 15,000 packages (Arch Linux) to keep up-to-date with the latest upstream versions than it is for a maximalistic distro with over 40,000 packages to do the same. Debian has to try to be more clever than upstream, simply because there's more variables to the equation. Debian has shit to worry about that upstream does not.

            As for, "Why go the maximalist route?" Well, that's a question of preference. Some people prefer to set it up just the way they like it, and some people prefer to have someone else set it up for them. Debian is for the later.

            Comment


            • #7
              Originally posted by Serge View Post
              As for, "Why go the maximalist route?" Well, that's a question of preference. Some people prefer to set it up just the way they like it, and some people prefer to have someone else set it up for them. Debian is for the later.
              IMO, I agree with the maximalist route because if end-users can't find the software they need in your distro's repos, they're going to be inconvenienced... They're going to go google it and of course the high paid websites end up on top (ex: The vlc malware website that bought it's way to a higher search ranking than the official videolan.org website and installed malware on countless PCs before it was shut down).

              Just wait until those malware websites repackage open source software along with malware and start shipping .tar.gz files .. It's going to be more fun than a barrel of monkeys.
              Last edited by Sidicas; 22 March 2013, 12:48 AM.

              Comment


              • #8
                /usr/ merge?

                No /usr/ merge?

                Boring that new fresh Wheezy will use old GNOME 3.4, KDE 4.8, and Xfce 4.8.

                Comment


                • #9
                  On the one hand, I'd like to have more recent software in Debian, too. Yet, on the other hand I wonder why this really matters. What real advantage does e.g. GNOME 3.6 have over GNOME 3.4? Maybe they use the old GNOME. Yet, when testing it, I was quite surprised as they pre installed different extensions which made GNOME more pleasant, e.g. the alternate button layout for log-off etc. And GNOME 3.4 seemed more stable than e.g. my GNOME 3.6 on Gentoo. The later tended to hang sometimes, so I had to kill gnome-shell in order to continue working. No such problem on wheezy. So even they use an elder GNOME version, the desktop seems more polished. And if you really want a more recent version of a package, there are always the backports.

                  Comment


                  • #10
                    Originally posted by oleid View Post
                    On the one hand, I'd like to have more recent software in Debian, too. Yet, on the other hand I wonder why this really matters. What real advantage does e.g. GNOME 3.6 have over GNOME 3.4? Maybe they use the old GNOME. Yet, when testing it, I was quite surprised as they pre installed different extensions which made GNOME more pleasant, e.g. the alternate button layout for log-off etc. And GNOME 3.4 seemed more stable than e.g. my GNOME 3.6 on Gentoo. The later tended to hang sometimes, so I had to kill gnome-shell in order to continue working. No such problem on wheezy. So even they use an elder GNOME version, the desktop seems more polished. And if you really want a more recent version of a package, there are always the backports.
                    For certain packages it does matter.

                    Debian's testing, unstable and experimental repositories only carry Mesa 8 while virtually all other distributions are already on Mesa 9, and Mesa 9 is not even available in their backports. And that is just 1 example.

                    Those who prefer to compile their own software for the heck of it aren't going to be very pleased to work with older devel libraries and stuff. I remember that one time I could not even compile aMSN because Debian's copy were tcl and tk were too old to compile the latest aMSN sources.

                    Comment

                    Working...
                    X