RTFM is an obnoxious retort for people, arguably in community, not to engage with a member of the community. I don’t mind reading the manual, but perhaps you can point me to where in the manual I could get further insight.
Reading a manual is also a skill. Being able to compartmentalize manual info into buckets of “obvious and I don’t need to read on”, “could be helpful”, “interesting, but it gets there I ain’t touching it” takes either training or just getting lucky after a certain number of reps.
Your second point is pretty much the most important skill learned in a humanities PhD, how to make your own learning path and learn what you need to know and what you should avoid.
This is the only comment I’ve seen in here that I’ve seen address this. The whole concept of RTFM is reactionary and ridiculous. That kind of thinking and behavior kept me at arm’s length from the Linux/tech community for many years. Still kinda does.
Fortunately this kind of thinking slowly but surely gets defeated, although we still have to fight for every inch of user-friendliness (and even modern security concepts) against elitists.
Unfortunately right now most documentation is still crap for average users, and people who keep repeating bullshit like “it’s better to provide CLI commands because they’re universal” (actual nonsense people keep saying) don’t make it better. The situation is so phenomenally bad that I’d outright assume Mistral AI with “Reflection” on to be more useful to newcomers when looking for solutions (on case a friendly professional or enthusiast isn’t available), because that thing is less likely to provide an outdated command for the wrong distro than a google search. Which is an absolutely abysmal place to be in for Linux as a whole if we want to keep the rising adoption train going.
RTFM is an obnoxious retort for people, arguably in community, not to engage with a member of the community.
I think there’s a low level of “How do I figure this out?” [generic] in which its good advice to ask “Does it say anything about this in the manual?” before you try and tear into a system as a third party giving advice.
I also think “I read the manual on my refrigerator” is some “I dare you to prove me wrong” horseshit. On the one hand, people don’t do this for a reason. Refrigerators simply aren’t that complicated to use. And the manual is rarely a smooth read, even for professionals. So its good advice, but not practical advice, better than half the time.
Reading a manual is also a skill. Being able to compartmentalize manual info into buckets of “obvious and I don’t need to read on”, “could be helpful”, “interesting, but it gets there I ain’t touching it” takes either training or just getting lucky after a certain number of reps.
Also, just a matter of free time and mental calories to burn. And hey, maybe if you’re a hobbyist who is hip deep in your Linux kernel because you eat this shit up, its the place you should have started. But also, Jesus Christ, maybe I just want a Mint instance to run a Jellyfin server. I’m not trying to get my master’s degree in this shit.
FOSS doesn’t mean “we think people that make software should work for free because we like free shit”. It means:
When you want to modify something someone else made to your benefit you should recognize the work they did for you and pay it back in the form of contributing those changes back to the project. Beyond that, it also benefits you directly because someone else might build on your improvements (well, that, but also its easier to stop your changes from breaking in new versions of the software if other people are aware of them). Like the other commenter said, its communal development, sure lots of people do it at least partly because they want to make the world a better place, but the primary reason it works is because the various parties mutually benefit from mutual cooperation.
The belief that you should have complete control over your own computer, which you can’t do in practice without being able to view the source code of the software you run.
There’s a difference between helping out people who are interested in, and capable of learning, improving, contributing to something…
… and people who just want thing work, and are also almost always unwilling to put literally any thought into this process.
‘User Support’ and ‘Collaborative Development’ are not the same thing.
There’s also ‘the computer guy’ syndrome, where a group of people just expect a seemingly infinite amount of uncomoensated time and mental effort from ‘the computer guy’ to solve all their problems, who then take this for granted, and become hostile and offended when you tell them ‘sorry, don’t have the time’, when ‘the computer guy’ has the audacity to… want to do something else at that moment.
RTFM is an obnoxious retort for people, arguably in community, not to engage with a member of the community. I don’t mind reading the manual, but perhaps you can point me to where in the manual I could get further insight.
Reading a manual is also a skill. Being able to compartmentalize manual info into buckets of “obvious and I don’t need to read on”, “could be helpful”, “interesting, but it gets there I ain’t touching it” takes either training or just getting lucky after a certain number of reps.
Your second point is pretty much the most important skill learned in a humanities PhD, how to make your own learning path and learn what you need to know and what you should avoid.
This is the only comment I’ve seen in here that I’ve seen address this. The whole concept of RTFM is reactionary and ridiculous. That kind of thinking and behavior kept me at arm’s length from the Linux/tech community for many years. Still kinda does.
Fortunately this kind of thinking slowly but surely gets defeated, although we still have to fight for every inch of user-friendliness (and even modern security concepts) against elitists.
Unfortunately right now most documentation is still crap for average users, and people who keep repeating bullshit like “it’s better to provide CLI commands because they’re universal” (actual nonsense people keep saying) don’t make it better. The situation is so phenomenally bad that I’d outright assume Mistral AI with “Reflection” on to be more useful to newcomers when looking for solutions (on case a friendly professional or enthusiast isn’t available), because that thing is less likely to provide an outdated command for the wrong distro than a google search. Which is an absolutely abysmal place to be in for Linux as a whole if we want to keep the rising adoption train going.
Writing a manual is also a skill so starting with good ones help a lot.
I think there’s a low level of “How do I figure this out?” [generic] in which its good advice to ask “Does it say anything about this in the manual?” before you try and tear into a system as a third party giving advice.
I also think “I read the manual on my refrigerator” is some “I dare you to prove me wrong” horseshit. On the one hand, people don’t do this for a reason. Refrigerators simply aren’t that complicated to use. And the manual is rarely a smooth read, even for professionals. So its good advice, but not practical advice, better than half the time.
Also, just a matter of free time and mental calories to burn. And hey, maybe if you’re a hobbyist who is hip deep in your Linux kernel because you eat this shit up, its the place you should have started. But also, Jesus Christ, maybe I just want a Mint instance to run a Jellyfin server. I’m not trying to get my master’s degree in this shit.
It’s so funny to see this on a sub dedicated to FOSS. Trying to imagine how many Pull Requests come with a bill attached.
FOSS doesn’t mean “we think people that make software should work for free because we like free shit”. It means:
When you want to modify something someone else made to your benefit you should recognize the work they did for you and pay it back in the form of contributing those changes back to the project. Beyond that, it also benefits you directly because someone else might build on your improvements (well, that, but also its easier to stop your changes from breaking in new versions of the software if other people are aware of them). Like the other commenter said, its communal development, sure lots of people do it at least partly because they want to make the world a better place, but the primary reason it works is because the various parties mutually benefit from mutual cooperation.
The belief that you should have complete control over your own computer, which you can’t do in practice without being able to view the source code of the software you run.
There’s a difference between helping out people who are interested in, and capable of learning, improving, contributing to something…
… and people who just want thing work, and are also almost always unwilling to put literally any thought into this process.
‘User Support’ and ‘Collaborative Development’ are not the same thing.
There’s also ‘the computer guy’ syndrome, where a group of people just expect a seemingly infinite amount of uncomoensated time and mental effort from ‘the computer guy’ to solve all their problems, who then take this for granted, and become hostile and offended when you tell them ‘sorry, don’t have the time’, when ‘the computer guy’ has the audacity to… want to do something else at that moment.
So much this