I've encountered my first issue.
I was updating my Arch test system, and it failed with an error that one of my installed packages was incompatible with the new packages.
The offending package was electron25.
You will note electron is not in my list of applications. It isn't an application I use, specifically. Rather it is a framework for developing applications which will run on multiple operating systems. I was fortunate enough to have been vaguely aware that Obsidian (which is one of my applications) is built on electron. A web search might give you that answer (it did me, but search isn't entirely trustworthy nowadays - dark forest and all...).
I did do some searching in Arch for an answer. I found a few similar issues, but not the same, and no applicable solutions.
Since this is a test system, I decided to try uninstalling electron. I would then run the updates, and then see if I could figure out how to get electron back on.
The uninstall and update went smoothly, no issues. Then for giggles, I decided to try launching Obsidian. It worked.
Puzzling.
I used a command to query my system for electron and discovered that, unbeknownst to me, there was a new version of electron which was installed.
My initial thought was why didn't the older version of electron uninstall when the newer version was installed. Of course the answer is, there are some frameworks which you can have multiple versions installed, to satisfy compatibility issues with different applications. You see this same behavior on windows, with .Net, and a variety of Visual C++ libraries (And I have had to deal with issues on the Microsoft side, though usually not with typical consumer applications).
This did give me pause to consider my decision to go with Arch, One of my criteria is that I don't want to have to spend time fiddling with the guts of the Operating system. I expect it to largely "Just work".
Interestingly, as I was pondering going back to Debian, there was news of excitement there, involving KeepassXC - one of the applications I depend on.
One of the quirks of the Linux ecosystem is, you don't typically get your applications directly from the original developers.
You can get the source code. And then build it yourself. But that can be a major headache. You have to work out what dependencies are required, tweak compiler options and settings, then compile the source code into the application. It can be a time-consuming and fiddly process.
And then you have to watch for new releases of the source code and repeat the process to keep your applications up-to-date. Not a user-friendly process.
Fortunately, most Linux distributions have a package management system. This system works similar to an app store. You select the application you want to install, and the package management system handles deploying the the program and any dependencies for you. It typically has a mechanism to check for an apply updates as well.
But where does this compiled program for your distribution come from? And how does it know about the dependencies?
Somebody else does all of that for you. These individuals, called package maintainers do the heavy lifting, so you don't have to.
There are a few catches.
1. They are usually volunteers, which means your important package may not be their number one priority.
2. They make decisions about how the application gets packaged, which you may not agree with. And you might not get much of a say in the matter.
That is essentially what happened to KeepassXC for Debian. The person maintaining the package for Debian decided several features were a security issue, and arbitrarily removed them. The ramification was many people suddenly lost access to features they relied on after updating to the latest version.
Now, this wasn't really as dreadful as the news articles made it out to be. The maintainer released a separate version under the name "KeePassXC-full" with all the features available. So, all you really had to do was select a different package and all is well.
But it does point out one challenge when working with Linux.
You are often entirely dependent on individuals, over whom you hold zero influence. What if they decide to configure the program in a way that doesn't meet your needs? What if they do't feel like building necessary documentation, leaving you to "figure it out"? What if they decide to slip malware in? (yes, the benefit of open source is anyone can look at the code, and report if this happens, but can you really be certain that capable people are looking at the code for the programs you use?). What they have a falling out with the developers of the program, or the Linux Distribution you use, and decide to abandon it?
The reality is many of those same issues exist in the Windows/Apple worlds as well. Companies abandon applications, or make poor financial decisions, or poor technical decisions, which can impact your experience as a user. That is in fact one of the primary reasons I started this endeavor - Microsoft was caught reading customers' email - not just reading, but also breaking into password protected zip files, ostensibly "for your safety". Apple of course claims they "would never". But then, they just implemented a backdoor into their iPhone OS giving them the ability to do so. If they "would never", why then did they do that?
And that is, I suppose the bright side of the Linux "mess".
Yes, you have to deal with this mass of independent, often arrogant, free thinkers, often driven by their own whims, which leads to a cacophonous array of distributions, disjointed systems, inconvenience and general chaos.
But, that inconvenience and chaos can disrupt conspiracies of wealth and power, and it does produce some brilliant innovations as well.
Not the ideal, perhaps, but, until we humans can ascend to our better natures, it is better than the alternative.
No comments:
Post a Comment