You are not logged in.
Well, the usual GNU license says: No Guarantee of merchantability. No surprises here.
Offline
Python is under the Python Software Foundation License
I don't disagree w/ Trilby's general point, but unless we know the specific issue, this is abit academic.
EDrawSoft could rely on stuff that's been deprecated a decade ago or run into a genuine bug in the last release or this could be a config change in a pacakge.
Online
I'm not sure why the GNU license was mentioned, as no software subject to this concern could be licensed under the GPL (the GNU license). As much as I dislike strong copyleft in general, it is the one category of license that makes it impossible to ever be stuck with an ABI-incompatible binary.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
As noted, downgrading a single package (or subset of packages) via the archive is unsupported and likely to result in problems. However, downgrading the entire system to a specific archive date - or more practically just picking a date to point the repo Servers to in order to hold packages as that date - is safe and practical (within reason and under certain circumstances).
This, in fact, would be the sane way of achieving what you seem to be calling "LTS" packages. However, LTS is not old packages but it is older versions of software in new packages with relevant security patches.
Debian stable doesn't get fewer updates than their edge / testing / whatever. In fact, in many cases, stable or LTS distros will get more updates. They just will not get many updates to new (major) versions of software: instead fixes are back-ported to the older version.
Systematically using old packages without back-ported security patches is not called "LTS", it's called "stupid".
(As for "good" use of flatpak: Ceterum censeo Flatpak esse delendam)
Another aside: WTF is up with the title of this thread? I have used almost exclusively arch linux on desktops / laptops for well over a decade. Have I note been in the "real world" that whole time?
I like your reply because it is very constructive and you are suggesting a way of what is feasible.
As for the "real world", I would like you to add what computing application that have you been successfully achieving instead leave a point of the generality of what the term means. So you can say: For this application and line Arch has been successful for me and that is a use case for the broad term "real world" that applies to the discussion. This idea is a reference of the general viability and usage of the Arch distro. Which will be true for specific cases.
Let's take Valve for example with the Steam Deck. They have picked Arch as a base and I can imagine they did it because they can have a better kernel overall because "If it is latest version then it should be for the better" but it reality this is not the case for the "real world" which in the spirit of clarifying my meaning let's sat "Arch Linux applicability to use cases". I also game on Linux and I prefer it over Windows because I can run Steam as a Flatpak. And what is the most important thing in the context of a Kernel regarding rendering a video game? Well, I think it is frames per second, right? Well it so happens that I get 10 fps less after the kernel 5.15 with my RX 590. How to investigate such a complex computing case and find if a patch for my particular CPU has created some bottleneck? or the game updated something and has a new feature that is more GPU intensive? Or is it the AMDGPU driver that has introduced a bug that hinders 3D processing? In the meantime, if you want your 10 fps back you are stuck with the previous version, right? Or work with a kernel developer that wants to find the issue causing the loss of 10 fps.
In the practice more and more functionality is not always better for the applicability for every use case because guess what, more functionality doesn't always come at less computing processing cost. Until a better algorithm which takes time to develop and figure out comes around you will not have your 10 fps back. So, the whole "applicability of software for a use case" for gaming does not depend on the latest version of a Kernel. That is why the term refers to "Real" and "World" because the World is the culture and we have a culture that has a market that in turn makes possible the manufacturing of commercial hardware that you can use for a purpose. But if Real World is an issue we could say something different, I think changing the topic title to "Applicability of Arch Linux to use cases and how to address software changes and updates" and also poll for success stories on use cases so that way the post is more talkative and inclusive to whatever users are doing.
Offline
I've been using arch linux exclusively for well over a decade (15+ years I think) for a wide range of "use cases" including software development, bioinformatics ("big data", machine learning), website w/ database with tens of thousands of users, personal business website, media-center machines, designing / creating marketing print marketing material, etc. The only notable "use-case" that I probably can't represent well is "gaming". I play a few games occasionally, but not in the way that word seems to be used these days. But there are plenty of other archers who certainly do.
I just reject your apparent assumption that arch may be good for some niche use but not for "real world" use as every single real world use is well represented by some arch users. The *only* use case that I'd say arch is not just as well suited to as any other distro or OS is on systems that cannot / will-not be updated for many months at a time (though there are archers who use it successfully in these contexts too ... but some extra care is needed).
Note don't mistake me for some fanboy type: I'm not arguing (at present) that arch is better than other distros / OS for any of these use cases - but it's certainly just as good. There are no use cases for which arch wouldn't be suitable. There is no "real world" use that is out of scope for arch as it is a fully functional general purpose OS.
So if someone faces hurdles with any "real world" use, it's not likely that arch is not suited for that use, but much more likely that said user has run into a problem that could be solved. Certainly arch is not suited for some use cases "out of the box" ... but that's not surprising as it's not really suited for *any* use case "out of the box" not even web browsing or document editing. If you want to browse the web on arch, you need to select, install, and perhaps configure a web browser (and unless you selected elinks / w3m or similar, a gui as well). If you want to edit documents you need to select, install, and configure a word processor or text editor. And if someone is just coming from systems where these are all pre-installed, this could seem daunting: but this doesn't mean that arch linux isn't suitable for web browsing or document editing. Just the same, every other use case would require some software selection, installation, and configuration.
Last edited by Trilby (2024-01-04 15:19:33)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I've been using arch linux exclusively for well over a decade (15+ years I think) for a wide range of "use cases" including software development, bioinformatics ("big data", machine learning), website w/ database with tens of thousands of users, personal business website, media-center machines, designing / creating marketing print marketing material, etc. The only notable "use-case" that I probably can't represent well is "gaming". I play a few games occasionally, but not in the way that word seems to be used these days. But there are plenty of other archers who certainly do.
I just reject your apparent assumption that arch may be good for some niche use but not for "real world" use as every single real world use is well represented by some arch users. The *only* use case that I'd say arch is not just as well suited to as any other distro or OS is on systems that cannot / will-not be updated for many months at a time (though there are archers who use it successfully in these contexts too ... but some extra care is needed).
Note don't mistake me for some fanboy type: I'm not arguing (at present) that arch is better than other distros / OS for any of these use cases - but it's certainly just as good. There are no use cases for which arch wouldn't be suitable. There is no "real world" use that is out of scope for arch as it is a fully functional general purpose OS.
So if someone faces hurdles with any "real world" use, it's not likely that arch is not suited for that use, but much more likely that said user has run into a problem that could be solved. Certainly arch is not suited for some use cases "out of the box" ... but that's not surprising as it's not really suited for *any* use case "out of the box" not even web browsing or document editing. If you want to browse the web on arch, you need to select, install, and perhaps configure a web browser (and unless you selected elinks / w3m or similar, a gui as well). If you want to edit documents you need to select, install, and configure a word processor or text editor. And if someone is just coming from systems where these are all pre-installed, this could seem daunting: but this doesn't mean that arch linux isn't suitable for web browsing or document editing. Just the same, every other use case would require some software selection, installation, and configuration.
"I just reject your apparent assumption that Arch may be good for some niche use but not for "real world" No I don't think Arch is a niche, quite the opposite, Arch has more to offer in my experience than regular distros. I will define better my concern and think about it. Just a lil anecdote, In 2008 I was delving into photography and was using Linux exclusively. So, I used Gimp. To my surprise, it didn't have 16-bit support which was added by the time I was out of photography. And, I realized that development is a decade slow on Linux to market standards. Of course for regular RAW reveal we had Darktable but if you needed to edit the photo you were doomed to 8-bit RGB. My guess is that even today you need your own printer to print in 16 bits, at least in my country because most if not all places where you can print industrial use 8-bit RGB.
I will clarify that much time has gone and these ideas and discourse were just what I had in mind back there. I will revisit the idea again. Yes, Linux has many real-world applications, Arch is not niche, you just need to apply yourself to install it and setup and I think if you are serious about using a computer for work you are bound to get your hands dirty. I was thinking about the non-developer/programmer use cases, but anyway, you need to know your system if you are using a computer for work IMHO. Offloading all that work to the OS developer is a bad idea because one doesn't fit all in reality. I will make a list of careers that use computing, check applications for it that are cross-platform, and see how the landscape is now. What I mean also, is that maybe, the Linux world could start charging for their binaries but it will depend on developers already having enough in other ways which is optimal of course. I am open-minded on keeping things the way they are, just wanted a constructive convo on the monetization of free software.
Offline