1. 12
  1.  

  2. 14

    My general stance is:

    • Just because they build doesn’t mean they actually work. Has anyone actually verified that they function? It would be a maintenance burden otherwise. (Drivers can be tricky to do CI for.)

    • (edit: point I forgot) I don’t think anyone is running relatively bleeding-edge for anything mission-critical on these systems. I also doubt anyone also has to use these as their only system, because not only do Pis exist, you can get very very cheap off-lease systems from say, your local university with Core 2 Duos.

    • (edit: point I forgot) The graphics stack is in flux. Eventually, X.org drivers might be phased out in favour of pure DRM or even Wayland. Has someone put the effort in there?

    • As someone who actually does love “retro” systems, I personally don’t see much merit in actually running a modern OS on one (You know, the era where Moore’s law still meant something.). At some point, the software is too much for it, let alone actually doing something with it. That’s why I run old systems on old hardware. (Of course, systems age differently nowadays. But a 10-year 486 was a lot less usable in 2000 than a 10-year old Core i5 is in 2020.)

    I generally don’t care for handwringing over something people will say they care about, but don’t actually do, let alone put the work into.

    1. 11

      One person who used to be a NetBSD developer says that’s how the situation with “of course it runs NetBSD” really is: many allegedly supported platforms haven’t been actually tested in years because no one has access to that hardware anymore.

      I wouldn’t want to see Debian turn into something like that, so I welcome their decision.

      1. 4

        That, and your toaster comes with Linux already…

        1. 2

          I’d hope my toaster runs something more high-assurance like seL4.

          I’d rather not have to deal with burnt bread because Linux crashed or got hacked.

        2. 2

          I do confirm Amiga works, works well, and has more users than just myself.

          1. 1

            That is scare-mongering pushed by individuals with an agenda. It would be nice not to trash talk people doing work to maintain support for a platform without even verifying any of those claims yourself.

            1. 4

              I’m not trash talking people doing work to support hardware platforms. Neither did that guy. He was talking specifically about code for a bunch of obscure machines that no one actively maintainer or even had a realistic chance to test in a long time.

              If there’s such code in a system, I do believe it should be removed.

              1. 1

                Yes you are. You’re spreading outdated misinformation to trash-talk an OS. I’m pretty pissed that I keep hearing endless non-specific complaints about how everything is broken when I’ve personally spent countless of hours of my own free time to fix some of those issues prior to their complaints. People bitch without even checking if their issue was already fixed!

                1. 2

                  Where am I saying “a platform NetBSD should support is broken”? I’m not.

                  1. 4

                    Ok, to prevent any further misunderstanding, that guy’s claim literally:

                    There exists support code for a number of hardware platforms that none of the developers or community members are known to use, and no one knows if that code works because a machine to test it on is very hard to find. Despite that, it’s not removed from the codebase.

                    1. 1

                      Can your acquaintance provide an example of such a platform?

                      One that is considered Tier 1 or Tier 2, that is.

                      To my knowledge, the only platform that could meet that description is the sole Tier 3 entry.

          2. 2

            Just because they build doesn’t mean they actually work. Has anyone actually verified that they function?

            A lot of these aren’t drivers for obscure hardware. AMD discontinued Geode about one year ago – there’s plenty of Geode hardware still being sold. r128 and savage are definitely vintage material, but they still work. (Case in point, there’s someone in the thread offering to maintain the r128 package – turns out there are plenty of people who will say they care about something and will put the work into it :-) )

            I’m not sure what to think of this. On the one hand, yes, these drivers don’t see any new development – on the other hand, it’s not like S3 is gonna be launching the next generation of the Savage series next year, and driver support will be flaky. As for not providing any value to the distribution, I bet there are packages under gnustep (which I absolutely love!) or science that have even fewer users than xserver-xorg-video-r128 or xserver-xorg-video-savage, and haven’t seen updates in longer than either.

            If you read through the thread, someone actually mentions that R128 did see some recent(-ish?) commits, and then you see this:

            No, the hw is just 20+ years old and while there have been some janitorial work upstream a few years ago, it’s not like the driver has gained any new functionality.

            Which is definitely true, but then neither has the hardware…

            That being said, I don’t think this is really that big a deal. Between Debian and the Xorg upstream, there aren’t too many releases for these things, and packaging them is reasonably straightforward. deb-multimedia is/used to be a thing, so can deb-vintage :-).

            Or who knows, maybe it’s time to think of an additional section besides main, contrib and non-free – say, firedumpster – for packages that still build, but testing is difficult enough that it makes no sense for any bug in there to ever become blocking. 25 years ago, in the early days of Debian, that made no sense – 20 year-old hardware meant PDP-11, on which Debian never ran. 20 year-old hardware today means Thinkpad T20. That’s what’s hooked into a bunch of inverters at my university, after the 486s they had back in my day finally died. It makes no sense to run anything more recent than Debian Potato on them, sure, but try telling that to the IT auditing team when they can’t cross “runs supported OS version” off their list.

            1. 2

              Just because they build doesn’t mean they actually work. Has anyone actually verified that they function? It would be a maintenance burden otherwise. (Drivers can be tricky to do CI for.)

              Debian maintainers are volunteers. Volunteers exist that maintain these packages. These packages still build. Verify every package still works is done by the maintainers and users. There’s a bug tracker that’s used to report when something breaks. Let’s not assume that just because I don’t use a driver, it is automatically broken.

              (edit: point I forgot) I don’t think anyone is running relatively bleeding-edge for anything mission-critical on these systems. I also doubt anyone also has to use these as their only system, because not only do Pis exist, you can get very very cheap off-lease systems from say, your local university with Core 2 Duos.

              I don’t get what your point is, to be honest. Debian isn’t a mission-critical specialized distribution.

              (edit: point I forgot) The graphics stack is in flux. Eventually, X.org drivers might be phased out in favour of pure DRM or even Wayland. Has someone put the effort in there?

              The keyword from your text is “might”. Hypotheticals like this certainly aren’t a justification to drop a driver that works, is maintained and has users.

              As someone who actually does love “retro” systems, I personally don’t see much merit in actually running a modern OS on one

              As someone who also does, I certainly do see the merit and I do run modern systems. There’s more than one way to appreciate old hardware.

            2. 12

              Meh, it’s not like they’re removing the drivers from the Linux kernel. Just because Debian ships with a wide array of hardware support in its vanilla kernel doesn’t mean that the maintainers are obligated to support everything. If you’re running obscure hardware, there’s nothing stopping you from building a custom kernel, or just building a dkms package and putting it in a repo somewhere. Heck, to this day, nvidia drivers are built through dkms, and half the world runs nvidia hardware.

              1. 6

                This. I’d rather Debian spent more time keeping a smaller list of better maintained, more up to date packages than support hardware that is decades old. If you want, you can still run an old version of Debian or compile your own modules and put them in an alternate repository. People are so ungrateful towards OSS maintainers sometimes.

                1. 2

                  I’d rather

                  Debian is mostly run by volunteers. The package maintainers of these drivers are volunteers too.

                  The person who removed the packages isn’t the maintainer of the packages.

                  The criteria was “this hardware is too old”. It was not “these packages are abandoned” or “these packages are broken”.

                  Plenty of maintainers put effort, now and over the course of Debian’s history, to keep old hardware and software working.

                  This is now thrown out of the window by somebody who personally doesn’t hold the same values.

                  1. 5

                    The person who removed the packages isn’t the maintainer of the packages.

                    I just read the bug itself and the reporter was doing so on behalf of the X Strike Force, which is the team that maintain(ed) those packages. So I think you’re mistaken.

                    1. 1

                      Clearly the person who ‘doesn’t hold the same values’ has a higher decision power than the volunteers providing updates to these packages. Debian’s Constitution has a clear structure, and arguably the people who chose to deprecate these packages are charge of shaping the direction the distro should follow.

                      I understand the annoyance of being excluded from a distro, but we have to ask an honest question: what possible benefit would Debian get out of including every single piece of software someone proposes? It’s not like people using these obscure pieces of hardware are in need of the latest kernel (and if they were, they could compile it themselves) or a huge unattended market.

                      1. 1

                        what possible benefit would Debian get

                        As I understand it, Debian isn’t in for the profit.

                        As for the community, they use or contribute to Debian for a variety of reasons. For some of them, it is the hardware support; Debian supports a lot of architectures. For some others, it is the large package library.

                        Dropping support for old hardware might actually turn away a lot of people. Or not.

                        In any event, I don’t believe the nonsense that packages that still build, are still maintained upstream and still have users are, somehow, a maintenance burden. So yes, I am disappointed in Debian.

                  2. 2

                    the maintainers are obligated to support everything.

                    They aren’t. But this isn’t what happened here. What happened is that somebody removed a bunch of packages that aren’t broken, without a care in the world that these packages might actually have users.

                    Heck, to this day, nvidia drivers are built through dkms, and half the world runs nvidia hardware.

                    Distributions do build nouveau, the open driver. They don’t build nvidia’s proprietary driver, the same way they don’t build other proprietary drivers.

                  3. 4

                    They’ve been dropped in the development distribution (“unstable”) but they remain in the stable release, which is the only officially supported release anyway. they’ve been dropped by the current maintainers who are volunteers and can’t be forced to do work that they don’t want to do. Other volunteers are free to pick up maintaining these packages. Anyone using them, even people using the unstable distribution, will not have the packages suddenly uninstalled from their computers. So this seems like a storm in a teacup.

                    Looking at the driver list I thought “oh I have an aiptek tablet” but it turns out I gave it away years ago. Otherwise I’d pick up maintaining that one myself.

                    Edit: one of the other issues raised in the Phoronix article is the r128 driver and its importance for old Apple hardware. However, old apple hardware (powerpc) was dropped as an official release architecture in 2017. And reading the thread on the Debian powerpc mailing list, the driver doesn’t actually work without some out-of-tree patches (which were not in the Debian package) anyway.

                    Ultimately I have a lot of sympathy for people maintaining vintage machines, amongst other things I am a founder and volunteer of a Historic Computing Committee, but sadly the volunteer people-power required to keep these things in the distribution is just not there.

                    1. 4

                      Seems like the right way to do it. This looks like perfect thing for derivative distro. Also a good way to test if long tail packages without a package maintainer can go away.

                      1. 1

                        long tail packages without a package maintainer

                        Maintainers are optional. Plenty of packages lack a maintainer. This is absolutely alright as long as when it breaks somebody steps in to fix them. If nobody does, then the packages can be indeed removed.

                        Please do not remove that which isn’t broken.

                        1. 2

                          Hmm, that’s true. If there’s no maintenance burden, why bother removing them? Okay, I sympathize.

                          1. 3

                            There is a maintenance burden. Every package in the archive, whether or not there’s an active maintainer or not, adds to a burden felt by all maintainers, and ultimately, users. They inflate the package DB metadata, which makes everyones package updates take longer, they get tangled up in transitions (e.g. libc6 updates, or Debian-specific changes like packaging updates to match newer policy versions), and by existing in the archive they both imply a level of support to users that isn’t there, and hurt the reputation of Debian as a reliable distribution.

                            1. 1

                              By your logic, Debian should stop packaging so much software and just shrink.

                      2. 3

                        I’m a packrat and I might have a VESA Local Bus card with one of those chipsets around in a box. I may very well also have an AMD k6 kicking around somewhere. What I don’t have is a motherboard that accepts either of those. And what I surely don’t have is time and energy to invest in mucking with x86 kit that’s old enough that its kids could buy beer. It’s reasonable for volunteers to stop maintaining builds for old hardware and let people who care about it build the kernel them themselves.

                        1. 0

                          It’s reasonable for volunteers to stop maintaining

                          Nobody “stopped maintaining” anything. Somebody simply decided to remove these, without asking anyone.

                          VLB

                          Some of these chipsets exist in PCI and AGP cards.

                          I have used mach64 pci and mach32 (onboard in a server) recently, although not on Debian.

                          1. 1

                            | Some of these chipsets exist in PCI and AGP cards.

                            To be a little snarky, I fail to see the problem with a distro dropping support for old kit in future releases. I’m grateful for the distros and all the effort I already get.

                            If one wants to use, for the case of AGP, a card that hasn’t been made in a decade, they build the support themselves. No one is saying one can’t use the hardware, just that the existing volunteer maintainers aren’t going to. I’ve run plenty of old or embedded systems with chipsets from vendors that no longer exist as a hobby and had to build kernels, kernel modules, or drivers on another contemporary system to get it running. That’s the way it is. If it were for work I’d pay someone if I didn’t/couldn’t do it and I certainly wouldn’t be upset because someone, somewhere won’t do it for free.

                            1. 1

                              Except the packages still build, and would still be rebuilt automatically when appropriate.

                              There’s absolutely no reason to remove them, other than someone arbitrarily decided they aren’t important, in full disrespect of their users and the efforts put by everybody who’s kept these packages building and working up until now.

                        2. 3

                          The article doesn’t explain why Debian and Fedora in 2013 dropped support for this hardware.
                          These drivers use the obsolete User Mode Setting that require the X11 server to run as root.
                          Kernel Mode Setting, the current driver model, doesn’t have this requirement.
                          It makes a lot of sense to drop unmaintained drivers with security weaknesses.

                          1. 1

                            unmaintained drivers

                            They are still maintained upstream, and the Debian packages still build.

                            obsolete user mode setting

                            KMS is Linux-specific, and it does indeed not support all hardware UMS does.

                            security weaknesses

                            Can you point to anything specific? I recall mach64 upstream disabling some features years ago to take care of a security weakness. Of course, it only affected those actually using the driver.

                            1. 2

                              KMS is Linux-specific

                              All four BSDs have been using a port of KMS for the last $many years.

                              it does indeed not support all hardware UMS does

                              Yeah, it does not support retro hardware, while UMS does not support pretty much anything released in the last 10 years.

                              1. 0

                                All four BSDs have been using a port of KMS for the last $many years.

                                What about Debian/Hurd?

                                1. 2

                                  Both users of Hurd are probably upset too. /s

                                  1. 0

                                    Debian/Hurd is a thing.

                          2. 3

                            Personally, I cannot comprehend why Debian would do anything like this.

                            For decades, the maintainers have put effort into keeping it all working, so that Debian continues to work well on old devices for long as it’s feasible.

                            And now, somebody removes these packages, which do still build, are still maintained upstream, and are still in use. Unilaterally. And with no discussion or warning whatsoever, as I understand it. Because they don’t personally see the value of these.

                            What a disrespect for the Debian community, its users, the developers who maintain or have maintained these packages.

                            Reading stories like this makes me wonder if I should have just stayed in bed for the day.

                            1. 3

                              Talk is cheap. Show me that the code works.