1. 36
  1.  

  2. 13

    Linus has cared about ABI compatibility long before he was being paid by the Linux Foundation. ABI compatibility in Linux is a technical decision enforced because it’s believed to be both better for users and developers, not because big companies pay Linus’s salary.

    Also, to characterize Apple as not caring about backwards compatibility when they practically invented fat binaries that would work on two separate cpu architectures is … a little rich. Also, they kept the old Carbon APIs around for years so that you could run old versions of Photoshop up until very recently

    1. 9

      Also, to characterize Apple as not caring about backwards compatibility…

      As an outside observer, in this case I would probably distinguish between the Apple as it has been for the last few (5?) years and the Apple that existed when they freshly minted OSX. One makes enormous amounts of money off selling rich people a new iPhone every two years and the other fought for survival to be better than their majority competitor.

      1. 6

        they practically invented fat binaries that would work on two separate cpu architectures is

        System/38 (pdf) (aka AS/400 to IBM i)

        1. 3

          It was NeXT, with NeXTSTEP 3.1, that introduced fat binaries in what later became Apple’s OSX.

        2. 6

          “Years of this approach [non so-called enterprise oriented development] to operating system development which actively deprecates and removes functionalities in favour of new better ones has allowed Apple the ability to make leaps and bounds in both the graphical shell and the underlying kernel while it’s competitors have stayed stuck in the mud.”

          “Leaps and bounds” seems like a bit much.

          I like OSX, but I don’t see how the kernel or the graphical shell are technically superior to competitors (i.e. Windows) in any particular way. “Buggy but doesn’t crash” is hardly a win.

          Apple’s development model puts a lot more responsibility on the developer to keep their app up-to-date with the latest API changes and deprecations. I’ll buy this. However, if this style of OS development is superior, as the author implies, then Apple is probably not a shining example. I use both OSX and Windows daily and have for years. The stability of both systems has been more or less on par for a while, but OSX has taken a serious dip in the past few releases. I suspect this drop in quality is due to Apple moving too quickly - something the author views as a benefit.

          It’s also difficult for me to accept that Apple’s abandonment of “enterprise-oriented development” is somehow superior when I can still run 20+ year old software on Windows while being able to work in native Windows containers and run both powershell and native bash side by side.

          1. 1

            I agree that macOS is both stagnant in some ways and also has added some dubious and unstable (seemingly rushed or poorly thought-out) features in recent years. But the claim here is a little hedged, and harder to evaluate. What “allowed the ability” implies to me is that, having set developer expectations by deprecating legacy APIs (even ABIs) on several occasions, Apple could make more improvements than they’ve chosen to make. Maybe they don’t see the value, or maybe they are reluctant to ‘improve’ their UX in a way that would break users’ entrenched mental models – something not discussed in the article, but I think just as relevant as API compatibility, for user-facing system software. Specific features, mis-features, or lack-of-features all probably have their own stories. It’s hard to generalize.

            As for your other point, I don’t think I get it. If we’re talking about virtualization, I can run Windows, OS/2, Solaris, Classic Mac in 68k or PPC flavors, etc etc in VMs on just about any platform. So what?

          2. 4

            OpenBSD does offer “some” backwards compatibility if you do an upgrade (until there is ABI breakage like the time_t change). You simply just keep around the old binaries and libraries:

            /usr/lib/libc.so.53.0
            /usr/lib/libc.so.56.0
            /usr/lib/libc.so.60.0
            

            Also there was a port/package (devel/jad) that installed a binary for several (3.x-4.x) releases before binary compatibility finally died.

            1. 4

              I agree with this in general, but I disagree with the specifics. There is no real difference between any of the operating systems mentioned except that on some of them applications don’t break with an OS update. More security is great, but it doesn’t really impact end users. Computers suck because they’ve been “televised”. In order to see real improvement, we need a greater focus on computation; that is, automation - the raison d’etre of computers.

              1. 1

                As a person who does not know a lot about the differences between BSD and Linux, this article was very insightful. The article is aggressive against Linux, but that helped highlight the differences for me.

                1. 2

                  I wouldn’t say that it is representative for BSD. Eg. NetBSD has backwards compatibility to very old historic releases.

                  https://2019.eurobsdcon.org/slides/Improving%20modularity%20of%20NetBSDs%20compat%20code%20-%20Paul%20Goyette.pdf

                  1. 1

                    This is all old news for me, and I’m not sure I agree with all the specific claims being made, but it’s nice to see the argument written down. At its root it shouldn’t be all that controversial, really: in general you can’t be substantially better without being at least a little different.