<rant frustration="50%" whine="33%" emotion="100%">
If I can put my 5 pence worth in...
When cars were first invented, the controls were all over the place and they were guaranteed to break down at some point. Thought wasn't put into the car's end-of-life and there were no established expectations or conventions to build upon to create an intuitive drivable vehicle which can be utilised by taking a general 'how to drive' course. Eventually, the concept of a 'car' became clear, conventions were established and it's users grew in confidence when utilising it. Now, no matter which car you drive, you take the same test as everybody else. This has a side-effect of making roads safer.
Now, I started off on home computers, where you turned the thing on and coded or loaded a game/program and off you went. The user manual included ALL the commands, in alphabetical order with examples, for any built-in version of BASIC you may have. This meant that the initial knowledge was relatively high as there were materials available which told you EVERYTHING you needed to know to write code with them. You could always improve upon that official knowledge further down the line.
Now, as complicated and involved as modern operating systems are, the skillset of condensing and streamlining an concept to make it easily graspable and usable by the masses seems to have gone by the wayside, especially on the niche OS that is Linux and it's various, separate, communities, each with their own take on 'how' a person should learn and how a computer should function - Maybe even forcing their own way of thinking on to others in the process. As much as Microsoft had 'their way' it was after in-depth consultation with their product testers first. They actively accepted feedback. We (Linux) could improve on this by putting it on the desktop, especially in the Live editions for user feedback.
IMHO, to improve Linux beyond what is currently attempted, it needs to stop being a myriad of small projects by disparate groups of self-entitled individuals. I mean, when one dev group says another isn't following standards and doesn't support it, the user is stuck in the middle of this pathetic argument over principles, as opposed to getting together with the other group and working on the solution TOGETHER. So many devs think they are doing it the 'right' way, even when it doesn't actually work in the end and the end user is left wondering 'Why can't I just access my files??!?!' I know, I've been there.
We live in a world where literally ANYONE and his dog (drag and drop coding?!!??) can invent 'new' technology or write ground-breaking 'apps', where every self-interested group is narrowly working away on their own individual half of the 'channel tunnel' whilst everyone else wonders why the ends seldom meet in the middle. We are in a time where keyboards, an established technology with known mechanisms, long expected and seen to simply 'work', now require in-depth knowledge of the Linux Kernel drivers to diagnose and report faults on.
My own pet peeve is the way in which knowledge is spread. Community forums. Nothing wrong with the people themselves - there are wonderful people in the Linux communities - but rather it seems to be upshot that a group of people all guessing, sharing opinion and working things out together brings - Mistakes, confusion and a lack of direction. As honest as the forum creator's intentions are, not everyone works well with guesses. Not everyone wants to spend days fixing an issue.
I, myself, have received advice from one community member only to be derided by another for accepting it, as it was incorrect. Altogether, it all seems a tad pathetic to me. Why can't the developers be held responsible for generating documentation... Why has it become the norm to throw software out into the world without accompanying documentation and knowledge. It is as if the developers cannot imagine a person not knowing what they know about their code. Very selfish in a way, IMHO and quite counter-constructive.
I honestly don't think forums can compete with a well organised, concise technical reference - The very same Issue I am having with the 'groundbreaking' FreeSWITCH. What use is code without documentation?
I have left various Linux several times over things like not being able to update my system for fear of it being unusable and unfixable, especially after spending such a long time tweaking all those wonderful options, installing and configuring packages and getting things to work just how I like them. I, like many other people, don't want to spend time fixing that which, ostensibly, should just work by now. I have spent enough time trawling through forums for a fix to a bug which apparently only I have ever experienced, with no luck in fixing it and the report of the fault not being accepted as being 'done correctly'.
When all you want is 'the answer', you get 'a response'.
Linux always seems to be unfinished. It is a fluid, ever-changing, unstable situation to be in. For some it's just not worth the risk to data or the time and effort to overcome things which simply don't happen in Windows or Mac OS.
I sometimes think that all the best Linux developers are working on separate projects, following separate standards on different distros and that if they were to put their heads together on a definitive Linux distro which can lend itself to being customised and changed within established bounds. Until the Linux 'minefield' of distros settles down, no one Linux distribution will ever cover all the bases that Windows does. Not mentioning the vanity distros.
And lastly, to every Linux dev who reads this and I am sure it will not apply to every one... Test. Test, test, test, test, test & test. And, when you think it's perfect, keep going until it breaks. Be brutally honest with your code. TRY to break it - it will eventually. Give it to someone else to test who doesn't have emotions invested in it, just don't go by the book when testing code, don't have a formula because that becomes a testing weakness. It just seems like some code has been rushed untested and undocumented and ultimately forgotten about. I learned early on to comment the ever living hell out of your code before you write an executable statement. IMHO, 'well written' code should be 60% descriptive/logical comments and 40% statements.
I used to make fun of Windows, I used to get so pissed off at the problems I had, but they were nothing compared to the issued I (still) have with Linux distros. I just don't think Linux is finished and am thinking it probably never will be. Some people seem to be constantly stuck in 'develop' mode and never make it to 'finish'.
Given the choice between an OS with 1000000 options which can break itself and an OS with 1000 which won't, I now know which one I should go for. ~8 years ago, I may have said the opposite, but that was before I used Linux for work - I used Windows 7 lol
And another thing, IMHO, bug-reporting sites shouldn't be socially-driven, but rather focussed on getting all the required info from the user and structuring it for diagnoses and trouble-shooting purposes. I think if we had a desktop application which doesn't require the user creating another account to use, it would help gather software versions, machine info, diagnostic details, etc.
New users also experience a vast array of inconsistencies, ranging from inconsistent language/vocabulary use (between and even within a single distro community) right up to the total culture change of seeking help - There's very rarely a single, authoritative source of accurate information for many software titles on Linux.
I think these are all symptoms of the relatively casual way Linux is developed. Maybe this substitution of knowledge/documentation for presumption and guesswork has caused more issues than people want to admit. idk
(Why are my tildes, ~, being converted into hyphens?)
Quote: "Look, a vast majority of people need access to highly specialized hardware and software in order to do their jobs outside of science, technology, engineering, and mathematics"
I would say that a vast majority of people only need a web browser and productivity suite to do their jobs and argue that a minority of jobs require specialists hardware/software and they would be within the scientific realms of computer usage. Maybe our views of IT are skewed, but I worked in education and tech support and every last person was using Windows and Office with an inkjet printer. Maybe you have seen more specialist environments/deployments than I.
I would say that a vast majority of work on a PC is completely mundane and the same across the board with pools of specialists carrying out engineering, mathematics or scientific works on specialist hardware/software.
"1. If it ain't broke, then don't fix it." - Nobody likes changing things if they see no reason to do so. That's just reality, especially when there is a lack of knowledge about what is changing and why;
"2. Patience is a virtue" - It is. However, waiting for months to remedy an ongoing issue is unrealistic and you shouldn't expect anyone to stop their lives whilst you 'try out' guesses with them, IMHO. Documentation, documentation, documentation. It cannot be stated enough.
"3. Practicing delayed gratification is a learned skill set" - Maybe, however there has to be a reasonable end-point. See #2.
"4. People are highly resistant to major changes in their lifestyles that cost them more time, money, and effort especially sweat" - Same as #1.
"5. Instant gratification and disposable commodities rule the roost" - Instant gratification is what happens when things work first time, every time, without issue and I see nothing wrong with expecting things to work outright, without issue. However, people generally are admitting that it is harder and harder to provide this experience with modern technology without controlling every aspect of the software and hardware, not something you can do when your OS has 4473 different authors to 590 different modules all trying to somehow work together well enough to not cause an issue. The situation is simply not conducive to the required level of interoperability without each of the 4473 devs to talk and work together.