1. 7
  1.  

  2. 6

    The idea that a stable API surface area for kernel modules is “nonsense” is definitely one reason I’m keen to avoid seriously working on or even with Linux for the rest of my career. The article itself doesn’t appear to have actually used the word “nonsense”, but it definitely offers some false dichotomies; e.g., the idea that innovation and improvement can’t be had if you also want to provide stability, or that API/ABI stability is somehow a burden for those closed source operating systems to bear.

    In illumos, we have inherited a rich, stable interface for various kinds of kernel modules from our Solaris heritage. Though Solaris was closed source, illumos is not, and yet we continue to support the same kind of stability. We remove ancient things from time to time, but if you’re working on a device driver for a PCI network card or certain other classes of kernel module, and you stick to the stable interfaces, you should be well-served. Most recently we extended our USB framework to support XHCI controllers and USB 3.0, without needing to ditch support for existing USB device drivers.

    API/ABI stability is a critical variety of engineering empathy for the people who build software on top of the platform you provide.

    1. 2

      The article itself doesn’t appear to have actually used the word “nonsense”

      The HTML file itself is named stable-api-nonsense.html.

        1. 1

          Ah, so it is!

          Also, I had somehow missed this gem from the executive summary:

          You think you want a stable kernel interface, but you really do not, and you don’t even know it.

          The author must be great fun at parties.

      1. 4

        Fuck with the internal API all you want, but the public API better be stable. If you scroll up a little, you’ll find this:

        Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces.

        The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is very stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. That interface is the one that users and application programmers can count on being stable.

        Now compare this with something like Django that breaks the public API with every minor version change.

        1. 3

          That’s an unreasonable potshot at Django (especially considering that Rails exists)

          They explicitly deprecate things at least one minor release before removing interfaces, often providing mixins to help with the transition. Considering the minor release schedule is pretty long, this gives you a good amount of time to update things.

          Most breakage is pretty straightforward to resolve (exceptions being things like South or the recent form rendering changes).

          You have LTS releases! so you can stick to a release for a very long time if you don’t want to go up.

          There also are rarely any API changes for what ends up being the day-to-day work in the view layer.

          1. 2

            That’s an unreasonable potshot at Django (especially considering that Rails exists)

            I work with Django, not with RoR.

            this gives you a good amount of time to update things

            Not an amount of time my clients are willing to pay for, and I’m not working for free on commercial projects.

            1. 1

              I believe that’s why we have the LTS releases, so you can stick on one branch for a long time. Imperfect solution, for sure. But Django is my day-to-day, and I still feel like it’s too early to treat Django as “feature-complete”. There are a lot of warts that I’d like to have fixed (and security fixes that require backwards-incompatible changes!)

              It’s a bit unfortunate that Django has so many users but ultimately is being supported by a couple people’s free time + Tim Graham handling reviews, releases. the Django Software Foundation doesn’t have the money to hire more people to have a more comprehensive support strategy.

              I don’t want to presume too much on how your work is laid out, but I thought that generally you’re supposed to charge clients for maintenance on the principle of “don’t do work for free”? So either you have previously agreed to do maintenance by charging them when it’s required, or you didn’t and offer no maintenance until they agree to pay you for it.

              Or are you more saying that clients aren’t willing to pay for the amount of time it would take to work?

              1. 1

                I believe that’s why we have the LTS releases, so you can stick on one branch for a long time.

                Not long enough.The sites I work on live longer than 2 years.

                It’s a bit unfortunate that Django has so many users but ultimately is being supported by a couple people’s free time + Tim Graham handling reviews, releases. the Django Software Foundation doesn’t have the money to hire more people to have a more comprehensive support strategy.

                Fuck those people, their free time and their lack of money. They break the backwards compatibility on purpose, they generate huge amounts of unnecessary work all over the world, just to slightly increase the demand for their consulting services. Fuck everything about their business model.

                I thought that generally you’re supposed to charge clients for maintenance on the principle of “don’t do work for free”?

                The clients are not willing to pay for work they don’t need and I’m not willing to lie to them and disguise it as maintenance.

                The clients only care about features, optimisations and bug fixes. Hours of invisible work every month just to upgrade some piece of software is a hard sell.

                1. 1

                  It is maintenance though right? Making sure you will continue to get security fixes.

                  The alternative is backporting security fixes yourself. But if you consider security fixes to be maintenance you have to get the code in there somehow right?

                  Also I’m like 99% sure the DSF isn’t a “consulting-first” thing but a purely volunteer-based organization that is trying to make a web framework people want to use. Most of the developers just want a thing that works well (hence things like ORM improvements that don’t break everything).

                  Would you be interested in helping to fund backported security fixes?

                  1. 1

                    It is maintenance though right? Making sure you will continue to get security fixes.

                    Good luck convincing people that you need thousands of dollars each year for this never ending “maintenance” and with the only visible outcome being the occasional breakage.

                    Also I’m like 99% sure the DSF isn’t a “consulting-first” thing but a purely volunteer-based organization

                    Jacob Kaplan-Moss co-owns this Django support shop: http://www.revsys.com/

                    Andrew Godwin, the fucker who decided that the best way to integrate South into Django is to have everybody delete their existing migrations, works for Eventbrite. From one of their job postings: “Eventbrite’s primary tech stack is Python, Django, and MySQL, all running on AWS”

                    So this is the perverse incentive at work here: Django needs to be so fucked up that you either need to hire a core developer, or pay for the services of a core developer’s consulting firm. Now you know why things constantly break. It’s good for business.

                    Would you be interested in helping to fund backported security fixes?

                    At this point, I would be interested in seeing it crash and burn.

              2. 1

                The Django maintainers are working for free on your commercial projects, and all it’s getting them is users like you who whinge on message boards.

                I’d love to be given free shit that was perfect, but since it’s not happening I’m pretty happy to get free shit that isn’t - and apparently so are you, since you’re choosing it as your tech stack.

                1. 2

                  The Django maintainers are working for free on your commercial projects, and all it’s getting them is users like you who whinge on message boards.

                  Free software lives and dies on its users. A project like Django, that disrespects its entire user base for some quick buck on consulting services, deserves to be treated like a bloody scam.

                  free shit

                  No, the fact that it’s free does not justify the fact that it’s shit.

                  I’ll keep on talking about this shit-show of a project in the hope that newcomers will not be trapped by it like I am. Backwards compatibility is the most important thing you should look for in a long term project. The sooner you learn this, the less time you’ll be wasting in the future.

                  1. 2

                    Backwards compatibility is the most important thing you should look for in a long term project

                    I’m with you 100% there - I’d argue it’s the key factor behind the wild success of php, windows and java.

                    To date I’ve usually chosen less stable tech than that because I dislike the cruft that accrues when you’re stable, but I keep getting less sure that the up-front savings are large enough to offset the ongoing maintenance costs.

            2. 1

              In defense of Django, there is no set of standards across different frameworks describing even roughly what happens after an HTTP request comes in.

              One could argue that it would be nice if Flask and Django and all yould provide the same interfaces, even that RESTful microservice interfaces would be nice.

              There are downsides to that too, especially not having decades of pedigree that Unix has.

              The breaking changes are usually quite easy to refactor, but of course this is a pragmatic argument and as such may be considered worthless in a discussion about ideals.

              1. 1

                In defense of Django, there is no set of standards across different frameworks

                That’s not the point. I don’t need cross-framework compatibility. I need compatibility between Django 1.x.y and 1.(x+1).z, just like I get with the Linux kernel.

                I have dozens of Django “apps” and the intentional monthly backwards compatibility breakage makes it impossible for me to justify the upgrade costs for commercial projects, so I have to run old and possibly vulnerable versions. Django turned into a liability and a security nightmare.

                There is no upside to this and no room for “you get what you paid for” silliness. Django is how you do not run a free software project and an adjacent service business. Django is how you make enemies out of your users.

            3. 2

              This might be a reasonable position if the kernel maintainers always accepted new drivers submitted to the tree. But they don’t (see e.g. reiserfsv4).

              Back when I ran linux I had no less than three pieces of hardware that were supported in one version of Linux stop working in future versions (Logitech QuickCam USB, Hauppauge TV tuner of some variety, ASUS A730W PDA), because the drivers were out-of-tree and the kernel became incompatible with them.