Announcement

Collapse
No announcement yet.

Debian 11 Freeze Begins, Debian 12 Might Reduce Focus On i386 Support

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

  • Debian 11 Freeze Begins, Debian 12 Might Reduce Focus On i386 Support

    Phoronix: Debian 11 Freeze Begins, Debian 12 Might Reduce Focus On i386 Support

    The Debian 11 "Bullseye" build-essential freeze is now in effect with the release team no longer entertaining transition requests. Meanwhile, architecture support for Debian 12 is in early stages of discussion with a possible reduction in i386 support for that follow-on release...

    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
    Big jump for plasma from Debian 10 to Debian 11 - thanks to Norbert Preining's work to jumpstart plasma packaging, plasma version will be jumping all the way from 5.14.5 to 5.20.5. Here's what he told us in the MX forum today:
    Bullseye will have:
    - Plasma 5.20.5
    - Apps 20.12.0/1 (with exception of PIM which remains at 20.08)
    - Frameworks 5.77 or 5.78 (experimental has already 5.78, but I am not sure we will push that to unstable/testing)
    https://forum.mxlinux.org/viewtopic....618183#p618183

    Comment


    • #3
      Well, I don't worry about i386 hardware, but I'd prefer i386 (i686 more precisely) multiarch to continue, because many old games are 32-bit and losing ability to play them would be bad.

      Comment


      • #4
        Originally posted by shmerl View Post
        Well, I don't worry about i386 hardware, but I'd prefer i386 (i686 more precisely) multiarch to continue, because many old games are 32-bit and losing ability to play them would be bad.
        We probably will be able to run them via Flatpak (I'm not so sure about video drivers, but anyway, since we are talking about old 32-bit games, I don't think this matters at all)...

        Comment


        • #5
          Can the 5.10 kernel be assumed?

          Comment


          • #6
            Originally posted by wswartzendruber View Post
            Can the 5.10 kernel be assumed?
            Debian testing (bullseye) already has 5.10 kernel rolled out for abt. week or so. 5.10 kernel doesn't play ball with Virtualbox had to roll back to the latest 5.9 kernel.
            Last edited by DRanged; 14 January 2021, 09:11 AM.

            Comment


            • #7
              Originally posted by ivan.cwb View Post
              We probably will be able to run them via Flatpak (I'm not so sure about video drivers, but anyway, since we are talking about old 32-bit games, I don't think this matters at all)...
              Old 32-bit games? You mean, almost every game before about four years ago? I had a nose through here and 64-bit executables for games seemed to really take off around 2017... (not sure how accurate/complete that list is, though...)

              Comment


              • #8
                Originally posted by Paradigm Shifter View Post

                Old 32-bit games? You mean, almost every game before about four years ago? I had a nose through here and 64-bit executables for games seemed to really take off around 2017... (not sure how accurate/complete that list is, though...)
                Windows was a bit later than Linux to the 64-bit game, since upgrading to 64-bit there was more of a "nice to have" thing. Since running 32-bit binaries on 64-bit Linux can be painful, developers were much faster to provide 64-bit binaries.

                Comment


                • #9
                  Originally posted by ivan.cwb View Post
                  We probably will be able to run them via Flatpak (I'm not so sure about video drivers, but anyway, since we are talking about old 32-bit games, I don't think this matters at all)...
                  I play games release more than 30 years ago. And it's really ugly to see that I can play DOS games under Linux but no longer some Linux games (old Loki ports ...).
                  So for gamers this binary compatibility really matters (yes, in an ideal world all game engines would be released under a FOSS license and this problem would no longer exist ... but this is unfprtunately a silly dream right now)!
                  And no, flatpak is no solution but more a plague. It means it has it's own environment - but this is what Steam and others already do (at least quite similarly) - packaging a lot of libraries to be used.
                  In case of incompatibilities between needed libs and system libs it does not help.
                  So yes, the 32 bit gaming is a problem and around 2015 it was still common - and even in 2020 there were a few 32 bit games freshly released.
                  And after mailing several developers it is a problem of proprietary libraries only available in 32 bit ... a problematic own engine while one switched to a complete new one for current games (so problematic to work with this legacy code) - or just small sales which do not justify the work/time/money to be spent on an otherwise great game. So a lot of former premium games may soon be lost.
                  Maybe it would need a virtual 32 bit environment - so layering similar to Wine (just a guess) to solve this.
                  Flatpak is just silly and solves nothing - it's bloat and fits to what special circles want to make. But there is hope that Debian won't walk that way against users ... other distributions may cause more and more troubles with 32 bit games - and already did so.
                  It is silly when seeing that libpng was used by a lot of programs (not only games) and nevertheless libpng12.so.0 (and yes - in 32 bit and 64 bit variants to make it even worse) is no longer provided ... it is a real dance to get it into a current system with broken packages going back and forth - till it magically fits in.
                  What is needed is what Linus Torvalds said long ago - we need the basic library set to no longer break compatibility - they can add - but should not change in such disruptive ways - similar to the kernel not breaking user space.
                  This would be possible - and should get the common rule.
                  But Flatpak is just ridiculous - but may fit for proprietary packaging done since a long time - but not for free SW and does not solve library incompatibilities caused by just the lack of certain basic 32 bit libs ...
                  We will see what happens ... maybe some GNU/Linux distros want to walk the silly way of Apple ... who knows.
                  Last edited by JMB9; 13 January 2021, 10:17 PM.

                  Comment


                  • #10
                    Originally posted by JMB9 View Post
                    I play games release more than 30 years ago. And it's really ugly to see that I can play DOS games under Linux but no longer some Linux games (old Loki ports ...).
                    So for gamers this binary compatibility really matters (yes, in an ideal world all game engines would be released under a FOSS license and this problem would no longer exist ... but this is unfprtunately a silly dream right now)!
                    And no, flatpak is no solution but more a plague. It means it has it's own environment - but this is what Steam and others already do (at least quite similarly) - packaging a lot of libraries to be used.
                    In case of incompatibilities between needed libs and system libs it does not help.
                    So yes, the 32 bit gaming is a problem and around 2015 it was still common - and even in 2020 there were a few 32 bit games freshly released.
                    And after mailing several developers it is a problem of proprietary libraries only available in 32 bit ... a problematic own engine while one switched to a complete new one for current games (so problematic to work with this legacy code) - or just small sales which do not justify the work/time/money to be spent on an otherwise great game. So a lot of former premium games may soon be lost.
                    Maybe it would need a virtual 32 bit environment - so layering similar to Wine (just a guess) to solve this.
                    Flatpak is just silly and solves nothing - it's bloat and fits to what special circles want to make. But there is hope that Debian won't walk that way against users ... other distributions may cause more and more troubles with 32 bit games - and already did so.
                    It is silly when seeing that libpng was used by a lot of programs (not only games) and nevertheless libpng12.so.0 (and yes - in 32 bit and 64 bit variants to make it even worse) is no longer provided ... it is a real dance to get it into a current system with broken packages going back and forth - till it magically fits in.
                    What is needed is what Linus Torvalds said long ago - we need the basic library set to no longer break compatibility - they can add - but should not change in such disruptive ways - similar to the kernel not breaking user space.
                    This would be possible - and should get the common rule.
                    But Flatpak is just ridiculous - but may fit for proprietary packaging done since a long time - but not for free SW and does not solve library incompatibilities caused by just the lack of certain basic 32 bit libs ...
                    We will see what happens ... maybe some GNU/Linux distros want to walk the silly way of Apple ... who knows.
                    how is FlatPak ridiculous ?
                    going by your post count you have no idea what your on about

                    Comment

                    Working...
                    X