We all know about Microsoft's latest OS, so I won't rehash. A lot of us intensely dislike it, to put it politely. Those of us who can, use other operating systems. This is Soylent, so let's focus on the one that is the most important to us: Linux.
I have been using Windows as my OS since right after Atari times. A few years ago I bought an ARM (ARMHF/ARMv7) netbook and put Lubuntu on it. I had problems with my first Linux experience, mainly in the area of installing software: missing packages in Synaptic, small dependency hells, installing a package at a time by hand, some broken stuff. I put it down mainly to the architecture I have been using, which can't be supported as well as x86-64.
Now, we all know that no software is perfect, and neither is Linux, even though it is now my main OS. We support it in spirit and financially, but there is always room for improvement.
So, the question is: What are your problems with Linux and how can we fix them? How do we better it? Maybe it's filesystems, maybe it's the famous/infamous systemd. Let's have at it.
(Score: 1) by leftover on Wednesday February 22 2017, @04:16PM
While much is made of the 'choice' offered by the Linux development community, merely shouting "Choices!" repeatedly does not outweigh all other concerns.
My first Linux distro was Slackware '96 and since then, well, more than I can remember offhand: Mandrake, Red Hat (pre-Fedora), Debian, Ubuntu and Kubuntu. After Slack, I forced myself to use a GUI desktop because I was looking for something I could recommend to friends and family as an alternative to Microsoft and Apple. Still looking now and still tempted to abandon GUI desktops because I spend FAR too much time fixing things I really don't want anyway. I use mechanical and electrical CAD and I get neither income nor kicks from fumbling around in admin land. Yikes this stage-setting has gone too long ... This comment is focused on the interface between code libraries and application developers.
My observation is that the Linux development community sorely lacks API configuration management self-discipline. This is the technology dual of the earlier marketing comment (#470108). There is no good reason for every minor version change of a math library to break API compatibility, for example. There is no good reason why each math library needs its own unique API, incompatible with the API's of the seven other libraries available to do the identically same functions. More importantly, the need to modify source to accommodate a library change is an impediment to choice among those libraries.
And why might I want to change math libraries when math doesn't change? Because none of the math libraries are actually completed. All are in some state of development, some making more progress than others. Some going dormant before being completed. Most of the C++ libraries don't work multicore because the Standard Template Library routines are not thread-safe. Analogous situations abound in many other areas: graphics at the OpenGL level, the entire nightmarish sound junkpile, crypto, networking.
Developers, I do 'get it'. The last 10% of a project has all the grunt work and none of the glory. Perhaps we need to change that?
In the meantime, stop dis'ing the APIs!
Bent, folded, spindled, and mutilated.