This part is true though:
Let’s face it, the Linux user base is still mostly geeks, most of whom are happy to understand at least a little how the command line works. Most Mac and windows users are not that. This is a major limiting factor on the popularity of Linux. Does anyone have right to complain? Not really, as the software is provided freely, and what you get for free is quite amazing. But at the end of the day, every OS has its own limitations, and you pick your poison.
True, but that list will be fairly long, and since I have had some bigger upsets on my machine which meant that I could not run updates for a few months this year, it was probably buried in a list of several thousand updates. And in the interest of eventually using the computer for its intended purpose rather than just solving issues with the software meant to drive it, I eventually stopped paying close attention to each of those items. My therapist says that’s progress*.
I’m growing increasingly critical of the tendency to allow things to fail by default and then blame users for not paying enough attention or knowing enough about how everything works. Whether its laws which screw you over, or big companies’ T&C or EULAs, or your typical OSS forum person pronouncing that nobody deserves to use software X if they can’t write a bash script to circumnavigate its flaws. My favourite example is the Discworld Assassins’ Guild whose code of honour states that “customers” must be given a fair chance to escape assassination. Of course, if you don’t check your toothbrush for poisoned needles every night, you have lost your will to live.
Of course, in the case of free, gratis OSS, users have no legal or even moral right to demand anything from the devleopers, merely point out things they observe and hope for the best, or get active. I understand that devs may have other stuff on their plates, some of which might (gasp!) not even be related to the software. They have lives, and those need attention, too. So my request is simply:
I’m also not insisting that @fhoech spend time introducing me to the code, as I also acknowledge that I have no idea how big the task is before seeing it, and he cannot know how well I’d be able to cope with it – so this is not a trivial problem. Maybe there’re other people better suited to the task, maybe there are specific issues with some of those individuals, maybe he hates the thought of someone messing with certain parts of his code. I’ve maintained a reasonably large and complicated piece of Python for the last few years, and some of the contributions from colleagues took me more time to integrate than it would have taken me to write them myself. I know all of those things. I just don’t think that “tough luck, it’s everyone for themselves” is a good response. We should at least try to solve it quickly, and in time before it breaks for even more users.
(*) that’s only partly sarcastic
All discworld references get a like 
It’s not about rights and demands. It’s about hope, expectation and disappointment. If you tell your friends you’ll invite them to the pub for a beer and then you show up and only buy one for yourself, they have no legal recourse. They cannot force you or somehow compel you to buy them beer – but it’s not a nice thing to do anyway. They might not show up next time you invite them, they might not invite you the next time, and they will probably update their opinion about you and communicate that to others.
Now, of course, the comparison is flawed because there’s no promise that DisplayCalGUI will never break, but most people will take its continued availability as a sign that someone behind it cares about making it available. Especially on Linux, running any other means of display calibration is difficult. And after a few years, they will start trusting that this will keep working.
If it breaks, many will not know to look here for reasons. They’ll just conclude that OSS is a bit buggy at times, and stuff on Linux just requires a lot more attention by users (because others on Windows and MacOS don’t have that issue). If it stays broken for a longer time, it’s reasonable to conclude that they can’t trust the software at all and that maybe they’d be better off with commercial calibration software, or at least ditching Linux.
And again, it’s not @fhoech’s obligation (legal or otherwise) to prevent that scenario. If the developer can’t fix an issue, that’s annoying but sometimes unavoidable.
But if technically-able and time-rich users deny the obstacle created for other users not so fortunate, that’s very bad form.
You can write all the long, snarky analogies you’d like, but that doesn’t change the fact that you’re responsible for your own system and for choosing a paltform that can run the software you need.
Which adults do you that are “time rich?”
I don’t think spending thousands of hours on something then giving it away for free can ever be considered bad form.
Not everyone using Linux actually uses or knows the command line.
Nor should they have to.
This is anecdotal, but: I personally know of several people who do use Linux but don’t know how to use a command-line shell — even a little bit. They care about things like having older computers remain viable, avoiding malware, and trying to have some digital privacy.
This is part of Software Freedom too, it’s not just having code you can look at, the flexibility to modify software (if you know how), or the pursuit of nerdiness. 
Linux is not alone in having software break due to updates.
Look at the Mac, which people point to for “stability”:
There are a ton of apps that no longer run on the M1 ARM chip (despite Apple’s efforts to make most x86 software still run). Many devs are working hard to port their stuff over and/or fix bugs. However, not even Adobe will have an official port of Photoshop or other parts of their creative suite until 2021.
And even upgrading to Catalina breaks a bunch of stuff on x86-based Macs. Just last night, I had someone in my Twitter timeline complaining about how all their games broke due to the update (with screenshots).
And every time Apple has switched architectures (processor families or even jumping from 32-bit to 64-bit, things have broken.
And Apple has deprecated pretty big things like OpenGL. (People are working on doing ports of OpenGL and Vulkan to Apple’s Metal.)
Additionally, new Macs don’t support third party OSes. This means no dual-booting with Linux and/or Windows. Meanwhile, Windows doesn’t even run in a VM on a Mac (aside from some community efforts to get the ARM version of Windows running in a VM).
Closer to the topic:
Back when I was stuck with a Mac just for photography (before I switched 100% back to Linux, thanks to this forum and the software featured on it), I had to buy new color calibrators from time to time due to their software getting deprecated. One was only supported by PPC. The next had software that was 32-bit only (and Apple switched to 64-bit apps only). Then one had some odd bug where everything was orange (not originally, but some update broke it and then they stopped putting out updates… and didn’t have old versions anymore). The last one I bought still worked before I switched to Linux for photography also (with darktable) a few years ago.
All of these calibrators work well with DisplayCal (with varying speeds of calibration). I tried, out of curiosity, as I saw they were supported.
I had been using GNOME’s own color calibrator before, but with varying success (depending on which colorimeter I grabbed from my drawers of stuff). DisplayCal gives better results overall, especially with some of the older colorimeters. I’m sad I could only start to use it for a little bit before it became not available due to Python 2.7.
Anyway, there are a bunch of bad “hot takes” in this thread. Let’s please refocus back to display calibration and solutions instead.
“argue all you like but if you have no software you can’t do anything, so you’ll just have to suck it and do everything yourself. Why did you even use OSS in the first place, idiot?”
Correct! If the software is broken, then I cannot use it and have no legal recourse. I can neither command Florian’s time (and I am not criticizing him for that!), not can I force you to behave in friendly and responsible ways. I can only notice and point out that you aren’t.
I used to be. Part of not being time rich anymore is learning to stop tweaking everything and reading all the fora about each piece of software I’m using. It’s hard. And as soon as I do, something breaks. So unless I stumble across the correct forum post, I won’t know why or how to deal with it. So what’s the lesson? Avoid open software?
That’s not what I said. I called your statements here bad form. One of the very good things about OSS is people helping others out, by making free software available, or by supporting their projects, investigating bugs, etc … so then arguing that helping out the people who are affected by a particular issue was somehow not needed (just punishment for ignorance?), and leave them to it is … like, why are you even on this forum, if you think that helping others out is stupid?
Like, if the Linux Kernel introduced some insane problem that made it essentially useless for your purposes, and Linux Torvalds refused to deal with it, would you just be like “no problem, I’ll just write my own”?
You’re just refusing to acknowledge or sympathize with the difficulties experienced by people other than yourself. You’re essentially saying “I can work around it, therefore everyone else should be expected to do the same”. Which in turn is the same as saying that OSS software should be treated as unreliable by everyone, and should not be used by people on tight schedules. And the vibe I’m getting from you is that that was somehow a good thing.
I love software which allows me to see behind the facade, to learn about how it works, use it in different ways and to change it if needed. I hate software which (deliberately) makes the knowledge, ability and time(!) to do those things a requirement to using it at all. And again, that’s not trying to make DsplayCal or Florian look bad, it’s a response to your argument in favour of leaving DisplayCalGUI in its current state, where an increasing number of Linux Distros won’t be able to include it.
Tested on openSUSE Tumbleweed, works! Thanks a million!
@fhoech, would it be acceptable to make the PyInstaller-generated package available in some place where users affected by the issue can find it more easily than here, and maybe put a pointer to it up in one or two strategic places (release notes, issue #17813)?
As the pop-up at start-up announces, this is of course not the latest version (3.1 vs. 3.8.x), and I find the UI has some hitches, but it works, thus makes it much easier to “hold my breath” for some time.
After rereading some of this discussion …
1: I can kind of see how many comments are easily put in the “entitled user” basket, at least if you’re a stressed-out developer. I hope I kept my tone on the good side of that but in case you think I did not, I apologize. I can’t really tell anyone what to do, and I should not try to.
2: At the same time, I am trying to contribute to the discussion. From my own view it seems clear that there are quite a few users for whom DisplayCal has stopped working, who don’t know why or what to do about it, and no obvious way to get that information. I think it is fair not to make things harder for them than they need to be.
3: if there’s no way to switch to Python 3 in the near term, it seems that making a PyInstaller version available would be a quick relief. Either the one from @agriggio or another one based on the current DisplayCal version, depending on how tricky and time-consuming, it is to compile.
4: Gosh, why is communication so hard? Someone should write a program to solve that…
I think we do need to remember that developers of free software, may have other things on their mind, during a global pandemic…
I think all your posts, which I mostly understand, come back to this root problem. Python v2 to v3 happened without a legacy mode, it broke compatibility. I think we all know why this sometimes must happen, but ofcourse everyone would be happier without it happening.
It’s rather unfortunate in the FOSS world where manpower cannot be easily relocated to tackle such things. I think Aurelien tried this in his own way with this thread. Thanks @agriggio for stepping in!
Blaming the user would be the more upsetting part here.
But, I also reluctantly understand the gist of it. If you know what a calibration is, which colorspace you target, what dE is, what profiling means and how it’s different from calibration…you already know a lot about very technical things. Hacking some cli commands should not stop you. It’s just very very inconvenient (as it comes on top of the time spent on the calibration/profiling itself).
Guys, I feel we have a strong tendency of being too political, too religious or even docmatic (maybe I am struggling finding the right word in a foreign language).
The only question remains:
(Me I cannot code, but I can volunteer for testing. Until then I use this, which is even harder than displayCAL’s CLI )
For what it’s worth, it’s possible to even use a GitHub repo with an SVN client: https://docs.github.com/en/free-pro-team@latest/github/importing-your-projects-to-github/support-for-subversion-clients… so it wouldn’t even require switching to git, if that’s considered a blocker.
People can use git and/or svn with GitHub repos. Their choice.
Also: I checked to see if GitLab supports this. It doesn’t (at least according to a 6-month-old comment).
2020 has been a struggle for everyone. Overall: Tensions are high, patience is low, and things are tough. We should all remember this, especially as plain text, like in this forum, can easily be misconstrued.
I hope (and think) we’re all friends here, with a common goal: using (and in some cases, aslo developing) some amount of FOSS (Free / Open Source Software) for photography… whether that’s a complete FOSS stack or even just one tool.
Much thanks to all the devs who make this possible and 
to all.
(Hopefully the Python 2 → 3 thing can be solved with DisplayCAL in some friendly way.)
Heck I won’t be reading through all this, just addressing a few points:
No, it would not stop me if I it came down to it. But it would cost me an afternoon to work out how DisplayCal’s interface even works and what goes where, assuming the documentation is decent.
However: openSUSE Tumbleweed has removed DisplayCal entirely, not just the GUI, and the only package I could find on OBS threw an error when trying to install it. So in my individual case, I can’t even work around the problem by moving to the commandline. Fortunately, I saw the package posted above by agriggio, and that is what saved me.
However however: This is not about just me. There are a lot more people using Linux who are less informed than me. I already have the huge advantage of having found this thread. The ones who have not are out of luck because they don’t even know what to do. And I think it would be elitist to shrug and say that’s their problem, because if I did, then I’d have to be okay with someone else doing the same to me in other areas where I’m less equipped to fix stuff myself. Even if it only ever happened in areas where I’m perfectly capable of circumventing a problem: A world in which I have to fix all the stuff myself is a world in which I get nothing done, ever.
So my argument is not about what developers should do, it’s about people claiming that if they themselves can work around an issue, then if it is an issue for anyone else, that’s those people’s fault. If such an attitude came to prevail in the free software community, that would mean that any free software would be useful only to nerds, and none of those nerds could use more pieces of software than they can keep on top of simultaneously.
Note that this is completely separate from Florian’s statement that he does not have time to deal with the Python migration right now. “Sorry, I can’t help you right now” is a valid response to somebody who could use help, but “Tough luck, you’re not qualified to use this software anymore” is not.
I’d just suggest to also consider making PyInstaller-generated versions available that can run from userspace, like @agriggio posted above. At least I prefer that to Flatpak, because Flatpak has always been pretty unwieldy to use and has caused issues of its own on my system. I suspect that unless it’s already set up on their machines in a good way, most non-technical users will find it easier to download and unpack an archive than to get flatpacks to work.
Although I’d be rather curious, I start to understand why you would not want to feed more “internal” details into a public discussion about your project… Hope that your current work goes smoothly and turns out to be worth it.
Flatpak is installed and works by default on most Linux distributions these days.
And adding Flathub, if it’s not already there by default (as it is on at least EndlessOS, ElementaryOS, Pop_OS!, PureOS, Zorin, Linux Mint, and ClearLinux), is usually a matter of just by clicking “Install” on Flathub. The browser downloads the file, passes it to the software installer app (GNOME Software, KDE Discover, etc.), and it gets registered — automatically.
For the ones above that have flatpak installed and Flathub already registered, they can also just search in their software app installer and click install (without ever visiting Flathub.org). That’s it; just about as simple as it gets.
There are additional instructions @ Flatpakâthe future of application distribution (linked from every app on Flathub) too, such as those for Ubuntu (where it’s a few more steps to set up, as Canonical is different from everyone else and defaults to Snap instead): Flatpakâthe future of application distribution
An app in flatpak form is easier to install and integrates better into a system than a PyInstaller. A flatpak doesn’t even need a command line to install (although you could install it that way, if you wish).
However, it probably wouldn’t hurt to have a flatpak and a PyInstaller version. Both methods would be better than what we have now, with most distros having already dropped Python 2.7 completely.
Meanwhile, I tweeted out a request for help with packaging. People are looking into it already: https://twitter.com/garrett/status/1339948532036493313
Yup, 100% with you on that.
Totally.
My impression is, that this is already the case. I know zero artists who run Linux and the Photographers I know only on their backup fileserver, if at all. And the reason is exactly the amount of time you have to spend on finding out how certain things work on Linux IF they work (hello wayland-colormanagment discussion).
To some extend, of course it is. And are you happy with this state of affairs? My impression is that those who will happily blame users for difficulties they encounter are, more or less covertly, happy to have an ecosystem for themselves. It gets them bragging rights, they can feel superior for using the OS for the smartest people, and by keeping newbs out, they can keep it that way, and still claim underdog status! win-win-win!
There’s probably also some amount of “I didn’t have it easy, so neither should anyone else” – another one of those really stupid sentiments.
I for one am not happy with this state of affairs, because it punishes not just non-technical users, but also me, who’s been at it for about 20 years now. Sure, I can deal with issues. But that becomes an enormous time sink, and if my OS prevents me from using time efficiently, then all the nice efficient tools I have set up here are for naught. So, should I just give in and allow Microsoft to surveill me? Are efficient working free software mutually exclusive? And should they be? I think nobody who thinks that free (libre) software has value can believe that its use should stay limited to those whose technical knowledge qualifies them for it. And I certainly don’t think that suitability to non-expert users is a technical obstacle for free software.
In fact, this seems to me the biggest factor holding Linux back.
And just to reiterate (because for some reason people just love to read things that way): That does not compel/force/whatever anyone to do anything. I’m not trying to enforce my will here or make demands. I’m trying to make a case that people losing access to a piece of software is also a bad thing if those people haven’t used bash before, and declaring them irrelevant is only reinforcing an existing problem. Therefore, I would like people to stop dismissing non-expert users, and take them into account when deciding on their own priorities.