Suggestion: Basic Linux skills compendium
We are all Linux users and enthusiasts on this site, as well as caring about FOSS. Although technically this is a site for technical Q&A, I think some level of Linux activism is possibly beneficial, in the sense of helping newbies "get into Linux". It should not be our job to convince people to use Linux, but maybe it can be our job to help total newbies (who are already convinced) to get started?
The majority of computer users have baby duck syndrome for the major commercial OSes (Windows, Mac OS, Chrome OS). This is exacerbated because Linux does not have the marketing force to educate new users, and commercial vendors follow abusive strategies of removing the user's control of their own computer and obfuscating the operation of the OS. As a result, when people hear about Linux and even after they accept it as a superior alternative, it is very hard to get started because so much of it feels like an alien environment.
I propose we explicitly define a category of "basic Linux survival skills" like using the shell, working with files, basic scripting, man files, obvious resources for getting help (besides this site, so for example Arch wiki), troubleshooting strategies (such as dealing with FOSS bug trackers, collecting appropriate logs, etc). Newbies should not have to glean such information in between the lines of other posts, it should be directly spelled out.
This can be in the form of a "newbie question" tag (probably a better name can be found), or perhaps a "fundamentals" section of the site where more experienced users can write primers. Crucially, newbies struggle not just with basic tasks, but understanding the correct way to even phrase the question, so it makes sense to ask the correct way for them. We don't need to spoonfeed everything to them, just enough basic skills that they can actually use a Linux computer for basic tasks, and thereafter we would expect people to compose their own questions like "regular" users would.
I think this is a good way to cut down on basic question, improve the health of the Linux/FOSS ecosystem and improving the activity of the site (I would expect basic Linux questions are a popular search query). It's easy to do, since most people here probably know most Linux basics and can easily research the ones they don't.
What is the community's opinion on this?
3 answers
My thoughts on the matter are clear from the question, but I'll add some example topics that could be covered by this "basics compendium":
- A "curriculum" of sorts that lists all the basic topics in a logical order for people who want to try learning all or most of them
- Explanation of what a shell is, brief summary of confusing historical artifacts:
- Why we "emulate" "terminals"
- Why normal keys don't work in the shell
- Explanation of basic Unix philosophy, and how to use pipes to combine programs simple programs into complex pipelines
- Significance of using CLI vs. TUI vs. GUI
- Basic file operations like
ls
,cp
,mv
,rm
,find
,touch
,mkdir
,rmdir
- Using
man
to figure out how to use a CLI program - How to find programs that do a task
- Partitioning
- General aspects of OS installation (ie. stuff that is commonly assumed knowledge in install guides)
- How to choose a distribution and how live CDs are useful
- Managing configurations with a dotfile repository
- Significance of text vs. non-text file formats
- Basic version control with git
- How to get sound to work
- How to get graphics to work
- Why some hardware doesn't work on Linux (specifically the FOSS vs. proprietary drivers context on this) and how to deal with it
- How to install programs and the purpose of a package manager
- What "compiling from source" is and why it matters
0 comment threads
I've been persistently advocating for an analogous effort in the Software community, and generally think that any Codidact community could likely benefit from doing something similar. As a practical matter, everything that can meaningfully be "mastered" has far more beginner practitioners than experts and masters. I saw your self-answered Q&A on find
, which I understand is intended as an example (since you linked it here), and it looks like a great start.
I have one main caveat to offer here, specific to the idea of doing this here: it's important to distinguish between general computer literacy and Linux-specific literacy. Many useful skills are applicable to other operating systems, and can be even more fundamental than what you describe. In particular, before teaching the most common shell commands, the student needs to be familiar with the concept of a command line (many people coming from Windows or Mac will never have had to use one, even though the option has been there the whole time) and a current working directory. (GUI filesystem windows will teach the concept of a path; but most people will naturally associate each path with the window that has it in the title bar, and will associate that window in turn with "the operating system". They won't necessarily have a separate concept of a file-explorer process, and certainly won't mentally associate CWDs with processes).
Because of that, an effort like this would IMO greatly benefit from coordination with the Power Users community. Content here should focus on the issues, and aspects of issues, that are Linux specific (so for example, the idea of treating "text files" separately from "binary files" is platform-agnostic, but a Linux-specific treatment might cover shebang lines, along with having a stub to explain how Linux treats newlines in text files and how that differs from Windows). Unfortunately, I don't really know how best to accomplish that kind of inter-community coordination on Codidact.
Re your proposed list of topics, I would also hold off on Git stuff; that's rarely if ever relevant to non-programmers, and it's not really necessary to learn programming to "take back control" of the computer (just like how learning to drive using manual transmission, without cruise control, parking assistance features etc. doesn't require becoming a mechanic). By my understanding, the basic use of Git should be perfectly on topic for the Software community already.
1 comment thread
Neat idea. In favour.
Bottom-up is better
I'd propose bottom-up here, instead of grand idea to strive for.
- I'd cut the list of topics down to real basics. I agree with @KarlKnechtel on Git. I'd skip compilation from source until much later (not basic). Etc.
- Basics means installation and commands. Perhaps a why Linux section.
- Commands have aspects. Say,
ls
.ls
shows.
and..
, why. Do not rely onls
output. Don't parsels
. Understandingls
styling and changing it (why some files are green, why some files have * next to them...). Not sure new users, indexing and SEO would like to see all that in one question. Consider https://linux.codidact.com/posts/290222 and see that other natural questions could be "What is whatis and how it differs from apropos?" or "Why can't I get a man page forexit
?" or "Is there a tool that gives me just man examples or do I need a shell script for that" or even something like "does anyone useinfo
anymore and what is it for?".
Q&A format
This forum uses only Q&A format. So, all points from the Linux Basics Curriculum (work term) need to have it. This means IMO:
- having multiple questions about command aspects (see
ls
example above) - artificial Q&A, aimed at... yeah, who exactly?
- getting new users to ask their questions and answering them - naturally, organically (I'm deliberately NOT raising the "how to be higher in search terms than other sites).
I take it you mean 2. I'm leaning towards 1 for to me brevity of the answer is key. Just meat. Which also would mean examples.
1 comment thread