Wellβ¦ the problem is not immediate, but I think almost certainly long-term. A good analogy may be COBOL. Many critical systems around the world are still based on COBOL, not a βmodern languageβ by most definitions. Of course when the software does its job perfectly, itβs all good and nothing to worry about. But this is rather short-sighted, because the infrastructure around the software will very probably change. This either requires you to jump through hoops to keep interfacing with the βoldβ software, or to actually modify the software itself. Both options are costly. The latter maybe more so, because of an increased risk if your COBOL program is doing some critical process. Nobody wants to touch that for fear of breaking it. Fewer and fewer people understand COBOL too, and those that do can ask a fortune for their services.
Now think of Python 2. Because it is officially deprecated, it will become an βold languageβ, similar to COBOL. Trying to keep interfacing with it is certainly possible, but it will become increasingly harder over time. So I would say yes, when the developers of Python say jump (and they already did in 2008, and again in 2015), you should prepare for the jump and eventually jump. If not, you, and by eventual extension, your users, pay the price of stagnation.
Edit: the open source nature of the project probably makes the analogy less than perfect, but the gist is the same I think.
Yes, itβs not the real solution. But for the moment, itβs still an option to let the software continue to be used.
The risk is, with continual talk of the software being dead, RIP, that wonβt encourage the author to spend any more time on it, (bearing in mind they probably have a lot on their plate at the moment, due to the global pandemic).
simon@anna-ms7c96:~/Downloads$ ./DisplayCAL-0-Build1.7.glibc-x86_64.AppImage
XDG: [Errno 2] No translation file found for domain: xdg-user-dirs
Not starting another instance.
However, I also have the Flatpak installed, maybe thatβs the problem.
Btw, looks like the dev is trying to create the AppImage.
No expert on this, but Appimage does not require any background services to run on. Just change the permission to run it and go. In a way a less complicated but more universal way of distributing software (with all disadvantages in comparison to a managed package as well).
Many pieces of software I use come as AppImage, sometimes even exclusively
For the moment I have found the following workaround on Gentoo:
python 2.7 can still be installed from the repo but not most of the dependencies (notably wxPython), so I created a virtual python environment using virtualenv
installed the following dependencies (pip can install almost everything thatβs listed under dependencies for using the source code on the displaycal homepage but donβt install pychromecast as this pulls in zeroconf and then displaycal stops workingβ¦)
tar xvf /path/to/wxPython-src-3.0.2.0.tar.bz2 && cd wxPython-src-3.0.2.0
./configure --prefix=$PATH_TO_VENV --with-gtk=2 --enable-unicode --with-opengl
make install
cd wxPython
source $PATH_TO_VENV/bin/activate (not sure if even needed)
python setup.py install
and finally added the following line to the $PATH_TO_VENV/bin/activate script
Now I can simply change in the virtual environment with
source $PATH_TO_VENV/bin/activate
and then start Displaycal from its folder (you have to download the source tar-ball and extract it somewhere, the file to execute is called DisplayCAL.pyw) - not a very elegant solution but at least it works and as I donβt need it that often itβs more of a problem to remember the location of the virtual environment and displaycal executableβ¦
Maybe this can be used on other distros as well - at least as long as you can install python 2.7
Hope this proves useful for someone elseβ¦
This thread recently got bumped for other reasons, but I did come across this claim.
That is definitively NOT true. My former employer was forced to keep an ancient machine around running NT4 more than a decade after it was EOL to continue to run an application that wouldnβt run in Win2k or newer. We had to keep a Win2k instance around here for years because Xilinx dropped support for a chip in newer versions of ISE, and their old version of ISE wouldnβt work on recent Windows versions. (Eventually a workaround for the incompatibility was found, but it took a massive amount of effort to do so). One of our vendors just had to completely change file formats because Microsoft EOLed one of their database drivers years ago - the vendor dragged their feet and was forced to move to sqlite on rather short notice because a vulnerability was discovered in the driver. Said vendor now has to pop up a security warning every time the old format is opened.
Perhaps, you might be able to argue, βWindows doesnβt leave working software behind as long as you donβt care about security at allβ, but any company that is trying to comply with ISO 27001 is going to wind up in the position our vendor wound up in.
That is interesting, thanks for sharing. Currently Iβm using the flatpack build of Displaycal, but itβd be good to have a βnativeβ version suitable for distros which no longer provide Python 2!
to get the Python3.8+ version of the DisplayCAL 3.8.9.3+
Iβm working on this project very actively (apart for the last 5-6 days where I have been tackling with Covid-19).
DisplayCAL should be working properly under any recent Linux distro, and there are people using it with MacOS and as far as I know Patrick is done some work to make it work under Windows. But please try it and please report any issues you come across so we can fix it.
This project is not only to make DisplayCAL work with Python 3.x but also modernize and optimize the code and hopefully add more features to it.
I requested to be the next maintainer for DisplayCAL from Florian HΓΆch, but he has yet to answer my request.
I am slightly curious about this item from the roadmap:
Try to move the UI to Qt. This is a big ticket. The motivation behind that is that Iβm much more experienced with Qt. In fact, I have zero experience with wxPython.
It does sound like a large undertaking, to the point that I wonder: would it not take possibly less time to get familiar with wxPython instead?