Announcement

Collapse
No announcement yet.

Debian 7.0 "Wheezy" Officially Released

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

  • #11
    If you read about the bugs, some of them are actually symptoms of the same bug while others are going to be marked not release-critical or already have fixes committed. There's nothing in the list that justifies holding up the release.

    I think I will wait a while longer Debian Squeeze is still working fine for me but I am looking forward to upgrading soon!
    I would wait for the first point-release. It usually comes pretty quickly after the release.

    Comment


    • #12
      Guess i'll start thinking about updating my server. Hopefully get around to it before the end of the year ;p

      Comment


      • #13
        Originally posted by DanL View Post
        If you read about the bugs, some of them are actually symptoms of the same bug while others are going to be marked not release-critical or already have fixes committed. There's nothing in the list that justifies holding up the release.


        I would wait for the first point-release. It usually comes pretty quickly after the release.
        Exactly, usually the last few niggling bugs at release time get fixed in the first point release., so these aren't total showstoppers

        Comment


        • #14
          Old software

          It has old software like Linux kernel 3.2 instead of 3.9.
          And GNOME 3.4 not 3.8.

          Comment


          • #15
            Originally posted by uid313 View Post
            It has old software like Linux kernel 3.2 instead of 3.9.
            And GNOME 3.4 not 3.8.
            that's the whole point of it.

            Comment


            • #16
              Meh, looks like they still haven't fixed random lockups on sandy/ivybridge (happens if you are using compositing doesn't matter if its kde or gnome) :/

              Comment


              • #17
                Originally posted by DanL View Post
                I've been contemplating moving from aptosid to siduction, since siduction offered its own xfce 4.10 repo (among other reasons).
                Considering the origins of the name "sid" for Debian, the pun "siduction" seems to have been rather poorly chosen to me. Eww.

                Comment


                • #18
                  Originally posted by Hamish Wilson View Post
                  Considering the origins of the name "sid" for Debian, the pun "siduction" seems to have been rather poorly chosen to me. Eww.
                  I don't give a flying fsck about Toy Story or mascots when I choose an OS, and I never thought about it that way....

                  Comment


                  • #19
                    Wonder if they managed to reach Debian's expected stability despite having such an old and outdated GNOME version.

                    BTW, since they focus so much on the new multiarch support, I wonder how their way is different to the way Fedora handles it?
                    Last edited by Kostas; 05-06-2013, 10:12 PM.

                    Comment


                    • #20
                      Originally posted by Kostas View Post
                      Wonder if they managed to reach Debian's expected stability despite having such an old and outdated GNOME version.

                      BTW, since they focus so much on the new multiarch support, I wonder how their way is different to the way Fedora handles it?
                      It's totally different from RPM-style multilib.

                      Fedora (and virtually all RPM-based distributions that have adopted the /usr merge) split libraries into a /usr/lib and a user/lib64, where /usr/lib stores 32bit libraries and a handful of important 64bit libraries. /usr/lib/64 stores the remaining majority of the 64bit libraries.

                      Before multiarch on Debian was available the Debian way was to have a /lib and /lib32, where /lib stores the 64bit libraries and /lib32 stores the runtime libraries installed by the ia32-libs package (which only contains the most commonly used 32bit runtime libraries, and not the whole set of 32bit libraries).

                      With multiarch Debian now stores libraries in the /usr/lib/<architecture>/ format so you will get something like this in the root directory:

                      /usr/lib/ia32(or was it i586, can't remember)/
                      usr/lib/amd64/
                      usr/lib/arm/
                      usr/lib/arm64/

                      As you can see the very nice thing about Debian's style of multiarch is that there is only one /lib directory at the top level, with all the architectures being separated into their own folder at a lower level. The RPM way of having usr/lib and usr/lib64 was definitely superior to Debian's then non-standard /lib32 and /lib implementation, but the new way Debian handles multiarch in 7.0 is now definitely more elegant than the current /usr/lib and usr/lib64 implementation.

                      The question is whether the RPM-based distributions will adopt the Debian way of multiarch now. I hope they do, but not holding my breath.

                      Comment

                      Working...
                      X