On Sun, Feb 14, 2021 at 09:51:40PM +0100, Louigi Verona wrote: > That proprietary software becomes obsolete. I have to say that I find > this argument to be unconvincing. I'm sorry you find it unconvincing. I may have been unfortunate, but it is my repeated experience. > First of all, I honestly question the frequency with which people need > to access their old projects. [..] How often does one need opening old > project files? Is this even a serious use case? For me, this use case arises several times per year, on average. It has meant keeping an unwelcome number of old PCs/HDDs/dongles/etc. It has also meant sometimes having to abandon new upgrades (and therefore having to take systems offline in order to minimise security risks from known-vulnerable unpatched versions). > Second, this "enforced obsolescence" is pretty rare, in my experience. Again, it sounds like you have been fortunate. Apparently, I was not. But I have felt much more fortunate since I discovered free (libre) software, at least outside of audio, because I have experienced far less enforced obsolescence. > I guess it also depends on the developer's business model, but most > proprietary software I own just doesn't have this problem. Lucky you! > At the same time, Ubuntu distros definitely force you out. This > "moving on" mentality is more a feature of organized development, not > just proprietary. Nobody wants to maintain some old version. In fact, > it simply becomes physically impossible. I am still on Ubuntu 14.04 on > my old laptop. Most software I try to install won't work because of > dependency hell. There are no updates anymore. By your logic, I now > have to say that FLOSS forces me to upgrade and that this is "enforced > obsolescence". Not comparable. For instance: - If you want to maintain 14.04 on one machine and 20.10 on another, you don't need a separate license for each. - If you want to clone your 14.04 install, and to upgrade or otherwise use the clone, that's fine too. You don't need to phone Canonical and justify it to them (as people used to have to do with Microsoft), or deal with other DRM hassles that are designed to keep you on a linear upgrade path. - If you want to recompile your FOSS audio tools for a different version of the same OS (or even a different OS, or a different architecture), you stand a chance of being able to. With proprietary tools, you're limited to the platforms for which binaries are available, or to tenuous workarounds like Wine that can introduce problems of their own into the mix. (I'm not knocking Wine. It's impressive and I'm glad it exists. But I'd prefer not to have to use it, if possible.) - I have never had a Free Software product update require me to insert a copy-protection dongle that prevented me from running more than one instance of that product on that PC, or that restricted me to running only the *latest* version for which I had paid. - Etc. > Technology moves on quickly. *You want it to move on.* Maybe, but not everyone wants to deal with bleeding edge breakage or frequent upgrade headaches. That's why stable distributions (Debian; Ubuntu LTS; etc.) exist. The best of these allow users to selectively stay close to the bleeding edge where desired (via backports, or compiling locally, or whatever) while retaining stability everywhere else in the system. With proprietary software from Steinberg, Cakewalk, Native Instruments, Microsoft, and even Apple, I have never encountered such a great dynamic range of stability alongside flexibility as I have experienced from Free Software. > Which leads me to the point that actually proprietary software can be > pretty good at backwards compatibility. While I'm not aware of things > on the Mac, Windows is known to be generally backwards compatible to > an amazing degree. They have several teams making sure that this is > the case. I paid full retail price for Vista, and spent years dealing with compatibility issues, terrible performance, and even totoally broken basic functionality such as: https://answers.microsoft.com/en-us/windows/forum/all/vista-search-is-not-working-cannot-find-partial/334ec4ec-7bba-44e0-92ec-e3a2685e6df6 (Also other nonsense such as Microsoft installing unwanted Firefox extensions that could not be removed without editing the Windows Registry: https://bugzilla.mozilla.org/show_bug.cgi?id=476661 .) Even on Windows 10, Microsoft does things like unpredictably restore tunables to default values during minor upgrades, so that the user either has to just live with crappy system settings or keep a long list of settings to check for changes every few weeks. (I don't have Windows 10, but I have encountered this issue myself while troubleshooting other people's PCs; and have encountered reports of it in support forums.) No respectable GNU/Linux or BSD distros treat users so badly. Even if they did, good workarounds or community-generated fixes would likely become swiftly available. As for Apple, I was unlucky enough to be using Macs when Rosetta (on which several pieces of software functionality in my workflow turned out to depend) was retired. Also unfortunately for me, rather than port those pieces of software to x86, some software houses involved did things like release updates that dropped that functionality. If I was lucky, this was announced, so that I could choose to not upgrade. In a couple of cases, IIRC the functionality was dropped quietly, so that I only discovered it had been dropped *after* I had already upgraded. This was not a happy time. > At the same time, smaller companies are at the mercy of platforms. If > Windows or Mac (or Linux) changes in a dramatic way, what am I to do? > If I am a plugin, I have no choice, but to break compatibility. Again, > this doesn't happen often. And I guess my only choice is - do I force > people to pay for it again or not? And there is no general right > answer to that. As the Rosetta termination demonstrated, a third option is to just retire that plugin, meaning that old mixes now won't work on the new platform. I.e. even if the user was willing (as I used to be) to buy an upgrade in order to retain compatibility, that might not be available. This has happened to me multiple times. By contrast, if the plugin is libre, then as I pointed out earlier in this email, it might be possible for the user (or the distro) to recompile it for the new platform. So, while a happy outcome is not guaranteed, its likelihood is at least greater in the libre world. > And backwards compatibility might not be true for FLOSS at all. I > mean, if I want to install a very old version of some program, I might > need to install a whole operating system, to take care of the > dependencies, and there is absolutely no guarantee it will even run on > a modern laptop. There's a reasonable chance it will run in a VM, for which there are many good libre options now: QEMU/KVM, Xen, VirtualBox, etc. It might even run under a container system like Docker. And you won't have any "phone home" or dongle-based license-reactivation hassles. > I think there is a difference between "but in theory this could be > done" and "it is actually being done". A lot of FLOSS advantages are > very theoretical, while in practice a lot of those things are not > happening, for various complicated reasons. And a lot of proprietary > vices are also theoretical and in practice are not happening, for > various complicated reasons. Maybe, but in practice I have repeatedly been bitten by proprietary vices (in audio work and beyond), and pampered by libre virtues. I'm not exaggerating when I say that due to my experiences, if it weren't for Free Software I'd be avoiding computers as much as possible, at this point. I can't express enough how grateful I am to Free Software developers, and how regretful I am not to have understood the differences sooner. > FLOSS is inevitable I don't think you can make that statement with certainty. (I'm a trained historian of science and technology.) Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx https://lists.linuxaudio.org/listinfo/linux-audio-user
