Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Meta

Suggestion: Basic Linux skills compendium

+5
−0

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?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Related questions (1 comment)

3 answers

+3
−0

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
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

+3
−0

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.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

Linux literacy is the aim of this forum though. Not general computer literacy. OP's targeting newbies... (1 comment)
+2
−0

Neat idea. In favour.

Bottom-up is better

I'd propose bottom-up here, instead of grand idea to strive for.

  1. 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.
  2. Basics means installation and commands. Perhaps a why Linux section.
  3. Commands have aspects. Say, ls. ls shows . and .., why. Do not rely on ls output. Don't parse ls. Understanding ls 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 for exit?" 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 use info 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:

  1. having multiple questions about command aspects (see ls example above)
  2. artificial Q&A, aimed at... yeah, who exactly?
  3. 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.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

1 comment thread

You can actually get a man page for exit(1) (2 comments)

Sign up to answer this question »