116
submitted 1 year ago* (last edited 1 year ago) by clif@lemmy.world to c/linux@lemmy.ml

Hello fellow Linux Lemmings!

I've been tasked with putting together a 20 hour class for "Introduction to Linux" and I'd like to solicit your opinions for topics that should be covered.

The class is targeted for at least minimally technical people - maybe developers, or future developers, but regardless of background they've never seen or worked with Linux before.

I plan to do a VERY short overview of installing Linux (to a VM - so they have a "real" environment to learn with) and the GUI but the primary focus will be CLI. Imagine tools and tasks you come across while working on a "real" server (or VM).

A high level overview of the topics I currently have allocated is :

  • Super brief history of Linux
  • Benefits and use cases of Linux
  • General overview of the file system and the purposes of the pre-defined directories (/dev, /proc, /etc, /home, /bin, etc)
  • "Everything is a file"
  • File extensions don't matter (windows users : )
  • Note on responsibility - you can delete "in use" files. It will do exactly what you tell it with sometimes minimal guardrails.
  • Everything from here down is CLI only!
  • What is a terminal/CLI and how do we use it?
  • How do we navigate the file system using the CLI
  • How to list, create, copy, move, delete, and read files/directories
  • EDIT: Basic file editing with nano
  • How to search for files (find... maybe locate)
  • Archives and compression (tar, gzip, bzip2)
  • Overview of permissions (read/write/execute, owner, group, chmod, chown)
  • Brief overview of different shells (bash, zsh, etc)
  • How to get help on the CLI (man, info, --help)
  • Tab completion, history
  • Shortcuts / control codes (ctrl+c, ctrl+d, ctrl+a, ctrl+e, and coverage of ctrl+z later)
  • grep
  • Checking processes (top, ps, kill)
  • Signals (sigterm, sigkill, etc - related to kill above)
  • Backgrounding and multitasking (ctrl+z, fg, bg, jobs, nohup, &)
  • Linking (ln)
  • STDIN, STDERR, STDOUT and redirection
  • Redirection (>, >>, <)
  • Command pipes ( | )
  • How to access a remote machine via SSH with UN/PW
  • How to access a remote machine via SSH with key auth (think cloud VMs like EC2)
  • Administrative commands and tasks (su, sudo, how it works, when to use it)
  • Add users and groups
  • How to change your passwd (maybe how to change your default shell too)
  • Restart, shutdown, halt
  • How to install/remove software (package managers, packages, pre-compiled binaries, maybe compilation with make if time allows)
  • Configuring your profile for customizing your environment
  • ENV variables and aliases
  • Network information (ifconfig) and tools (curl, wget, netcat, etc)

Everything from here down is "extra" if time allows (AKA - ensuring I don't run out of material :)

  • Encryption (gpg - symmetric and asymmetric)
  • Backups (rsync, maybe dd)
  • screen/tmux
  • How to setup key based logins/auth
  • EDIT: More advanced CLI text editing with vim
  • sysreq commands
  • srm/shred
  • Shell scripting basics
  • init vs systemd, how to start/stop/status services.
  • Maybe how to create a simple service
  • Run levels
  • sed, awk basics
  • File system types, file system checking, formatting... I hesitate to get into partitioning but it's always an option if I need it.
  • Alternatives to well known win/mac utilities and how to find them. EG: GIMP to replace Photoshop.

What do you think?

Did I miss anything that you deem super important?

Anything that I should definitely keep in the "only if I run out of material" category?

O, and if you have any good ideas for practical exercises I'd love to hear those too. I want to keep them <15min but things like "create a new directory, cd into it, touch a file, list the contents of / and write the output into the file you just created" are perfect.

Thanks!

all 50 comments
sorted by: hot top controversial new old
[-] Lantern@lemmy.world 15 points 1 year ago

You should probably explain what a distribution, a DE, a WM, and a DM are. I feel like this is something that Windows users lack in particular, as they have little control over these features.

[-] MrCamel999@programming.dev 14 points 1 year ago

This looks like an amazing class! I would absolutely take it, it looks awesome to me.

[-] clif@lemmy.world 3 points 1 year ago
[-] eeleech@lemm.ee 13 points 1 year ago

I would consider that ifconfig is deprecated on many distros and would therefore teach about iproute2 (mostly the ip and ss commands) instead. Additionally I would consider editing files essential, even if it is with nano.

Maybe mention more modern and simpler help tools like tldr, as they could be even more useful to beginners.

To introduce the shell and utilities, I would try to find a somewhat realistic use case that combines multiple aspects, like analyzing some files or spellchecking instead of simply mentioning every feature one by one.

[-] clif@lemmy.world 6 points 1 year ago

Now I'm learning something. I've defaulted to using ifconfig for so many years I didn't even realize that ip and ss were around. I'll look into them, thanks for the pointers.

And yeah, good idea on file editing. Maybe I should move nano up to the essential category for basic editing and keep vim in the "extras" since it takes a little more training to use effectively, while providing a lot more functionality if you know how to take advantage of it : D

[-] eeleech@lemm.ee 7 points 1 year ago

Keeping the details about vim in the extras is what I would do as well, but I would definitely tell the students that vim and vi exist, because they are the only editors available on many systems.

[-] wviana@lemmy.eco.br 11 points 1 year ago

It's missing GNU 🐂 project and free 🕊️ software.

[-] possiblylinux127@lemmy.zip 3 points 1 year ago

Beat to to it

[-] mvirts@lemmy.world 10 points 1 year ago

For the love of God make them all practice using tab completion in shells, and show them nice shells that do completion for command options. I spend a significant amount of time dictating commands that could be completed by the shell 😅

[-] russjr08@outpost.zeuslink.net 6 points 1 year ago

Also, some of the other bash/readline niceties - like Ctrl+r for reverse-search, or Ctrl+x Ctrl+e to open the currently typed in command in $EDITOR (saving will execute the command). Good for when you have one of those really long commands and you have to do some more extensive editing.

[-] selokichtli@lemmy.ml 10 points 1 year ago* (last edited 1 year ago)

It's too much for 20 hours, if it's introductory. Also, wouldn't you want to teach them how to actually install Linux?

[-] ExLisper@linux.community 8 points 1 year ago

I would do it completely differently. Do some intro about history and philosophy. Next:

  • everything is a file -explain and actually show /proc & /dev with some fun examples (/Dev/urandom /proc/cpuinfo and so on). Not necessarily CLI
  • explain the idea behind Unix way of having lots of small tools. Show examples of grep, cat, ps, head, tail...
  • explain piping and streams, show ps | grep and so on
  • combine it all and show some fun examples (a one liner to change display setup or something
  • explain processes, input output streams, pid, kill
  • combine and show how do a one liner to find and kill a process

I like to courses to have natural flow where you keep adding stuff and build more and more complex things. A lot of small tidbits are hard to follow.

[-] jagungal@sh.itjust.works 4 points 1 year ago

I like this idea, but I think you should work a bit of history/philosophy into each lesson by explaining why things work the way they do. The students are unlikely to engage with a history of a system they've never used before, so starting with that will lose their attention before you've even gotten it. Giving them a bit at a time means that they will slowly build a mental model of how *nix works and is built.

[-] atlasraven31@lemm.ee 8 points 1 year ago* (last edited 1 year ago)

With files, include user and group permissions (read, write, execute).

You could talk briefly about the FOSS philosophy.

[-] clif@lemmy.world 6 points 1 year ago* (last edited 1 year ago)

Ah, great point on FOSS. I know I have it in my original notes somewhere but I need to be sure it makes it into my outline.

I added chmod and chown into the permissions bullet.

[-] atlasraven31@lemm.ee 1 points 1 year ago* (last edited 1 year ago)

Everything else is great. It looks very comprehensive.

[-] HerbalGamer@lemm.ee 7 points 1 year ago

Maybe the linuxupskillchallenge is a good inspiration?

[-] snowraven@sh.itjust.works 6 points 1 year ago

I think you've got it all covered. But for my 2 cents: maybe resources to keep them engaged after these classes, a beginner's book like "the command line by william schotts" might be an Excellent resource to recommend.

Throwing in a word for foss as someone else is also a nice idea. It would be even better if you could relate it your own life. For example - I use tons of custom scripts for purposes like creating automated git backups and syncing my gdrive using rclone. If you could show your students a glimpse of what you as a enthusiast could accomplish(and what they might customise someday too) it can leave a very lasting positive impression and desire to learn more in their minds.

[-] clif@lemmy.world 2 points 1 year ago* (last edited 1 year ago)

Excellent suggestions.

I've got one example for the shell scripting section - a script I wrote decades ago called serial_killer.sh that's used to terminate "bad" processes that spin up tens to hundreds of copies of themselves. You do something like serial_killer.sh my-bad-program and it will use a few CLI commands to find the PIDs for all processes named "my-bad-program", ask you to input the signal (sigterm/sigkill) to use, ask you for confirmation that you want to send that signal to the list of processes (listing all of them with program name, owner, PID, PPID, etc), then kill all of them in one go if you confirm.

That was a hacky fix to a bad approach/configuration, but it was a fun script : )

[-] Cornelius@lemmy.ml 6 points 1 year ago* (last edited 1 year ago)

I would consider teaching them about a CLI shell, like Fish or ZSH (through oh my zsh), whilst they're not usually going to have the luxury of a nice shell on a remote server but they will if they're on a desktop. A good shell makes the CLI soooooo much easier, and faster, to use. Work smarter not harder, install a shell other than bash.

I would also HIGHLY consider teaching them about desktop app software development on Linux, there's a surprising number of developers who don't know about the different ways you can distribute software on Linux:

  • Native system packages
  • Snap packages
  • Flatpaks

Teaching them about this is definitely a must imho, there are so many OSS projects out there that insist on distributing their software via native system packages (without supporting most distros). They're also likely to run into it even if they're just in IT, the server market uses Snaps quite a bit.

[-] secret301@sh.itjust.works 2 points 1 year ago

I've been using bash forever maybe I should try zsh

[-] Cornelius@lemmy.ml 2 points 1 year ago

I highly recommend it, I've been using OMZ for almost a year now, it's super nice and I have no performance issues.

[-] theshatterstone54@feddit.uk 1 points 1 year ago

A few things you need to know:

  1. In my experience, my super-customised Zsh is a bit slower

  2. It is far more customisable

  3. When loading plugins, do NOT use oh-my-zsh or other plugin managers. In most cases, the plugins are just zsh files, so just source the files directly into your .zshrc to have better performance. For me, zsh with oh my zsh is unbearably slow. Without it, zsh is so much faster.

  4. Add a zsh history file to save your history. This is especially useful if you want to use something like autosuggestions and autocompletion.

  5. Check out my zsh config at https://gitlab.com/theshatterstone/dotfiles for examples of how to do 3 and 4. If you need any help, let me know.

[-] Cornelius@lemmy.ml 1 points 1 year ago

When loading plugins, do NOT use oh-my-zsh or other plugin managers. In most cases, the plugins are just zsh files, so just source the files directly into your .zshrc to have better performance. For me, zsh with oh my zsh is unbearably slow. Without it, zsh is so much faster.

Maybe you used a much older version of oh my ZSH, but at least the latest versions of OMZ I use have no issues with performance at all. It's a possibility that some of the plugins you're using just don't play nice through OMZ in terms of performance. I know there's been many updates to OMZ as of recent years that have massively improved performance.

For context the slowest device I use is a laptop (granted with a 5800U), on battery it'll struggle to load pages quickly, but such is the way of a laptop if you want reasonable battery life. Doesn't help that the web is a mess though :/

[-] kylian0087@lemmy.world 5 points 1 year ago

For package management i would also give a brief explenation about repositorys.

[-] eruchitanda@lemmy.world 4 points 1 year ago

I'm not sure it's the 'right' topic to learn, but I'd want to learn about some of the terms. At least why there are so much 'Linuxes', and what is a distro. It doesn't have to be a full day, but some background is important, IMO.

[-] clif@lemmy.world 1 points 1 year ago

Great point. I think I have a "flavors" note in my margins somewhere but I'll ensure it makes it into the introduction.

[-] possiblylinux127@lemmy.zip 4 points 1 year ago

You should explain free software and copyleft

I would also consider having some sort of final project. It can be anything from a game server to a desktop widget

[-] tla@sopuli.xyz 4 points 1 year ago

+1 for the FOSS philosophy and why that's important when it comes to privacy (ie closed source crypto implementation back doors etc) + full system control, lack of spyware etc. KVM for the VM demo - keep it Linux, right? Introduce the concept of how almost everything in Linux is a file and can be read from / written to. This is important when understanding pipes. Show pipelines - logical && ie cat x | grep y | grep z. Logical || ie grep -E 'x|y|z' Useful commands like top and ps. Explain selinux and why it's a good idea.

[-] NegativeLookBehind@kbin.social 4 points 1 year ago

Keyboard shortcuts, for example, CTRL a to move to the beginning of the line, or CTRL e to move to the end. These are extremely important for moving around quickly and getting things done faster, and knowing just a few basic ones make huge improvements to productivity.

https://ss64.com/bash/syntax-keyboard.html

[-] slampisko@czech-lemmy.eu 1 points 1 year ago

I was gonna suggest Ctrl+r as the most important bash shortcut, and also Alt+b/Alt+f and Ctrl+w.

Also, I would teach them the basics of viewing text files in less, with a seamless transition into editing in vim.

[-] qjkxbmwvz@lemmy.sdf.org 4 points 1 year ago* (last edited 1 year ago)

Looks awesome! I'd put a big emphasis on piping/IO redirection (maybe move it further up the curriculum?). I find this video, when Kernighan explains some basics, just amazing: https://youtu.be/tc4ROCJYbm0?si=3l48F_Ci9FYDkNEi

I'd also maybe move shell script basics up a bit


like the really basic stuff. I think it really hammers home the point that the command line and a script are doing the same thing


telling the computer what to do!

[-] PipedLinkBot@feddit.rocks 1 points 1 year ago

Here is an alternative Piped link(s): https://piped.video/tc4ROCJYbm0?si=3l48F_Ci9FYDkNEi

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source, check me out at GitHub.

[-] mub@lemmy.ml 3 points 1 year ago

Yey! I know all of these.

[-] Gebruikersnaam@lemmy.ml 3 points 1 year ago* (last edited 1 year ago)

Depending on your audience (don't overestimate your audience!) you might also want to have a look at the material from The Carpentries. The participatory live coding style works really nicely in workshops for minimally technical beginners. Also don't make the assignments too hard, or give multiple difficulty levels.

[-] finickydesert@lemmy.ml 3 points 1 year ago

Why not align the course with a LPI cert?

[-] timkenhan@sopuli.xyz 3 points 1 year ago

I happened to have put together a class curriculum for something quite similar when I was doing volunteering work at FreeGeek. This was a few years ago, but it should still be good.

https://gitlab.com/Free_Geek_PDX/command-line-guidance

[-] ChunkMcHorkle@lemmy.world 3 points 1 year ago

How to access a system overview (installed hardware, memory, drivers, etc.) It doesn't have to be super detailed or interactive; I'm thinking of the System Information report available on Macs.

[-] Swiggles@lemmy.blahaj.zone 3 points 1 year ago

I would put shell scripting basics higher up on the list as part of the introduction to cli, because that's one of the major benefits over using a gui.

Otherwise it looks really good, maybe sprinkle some vi(m) in there, because it is the defacto default editor outside of Ubuntu and few others.

Also maybe focus more on iptools2 over the legacy commands like ifconfig, netstat etc as they are not available everywhere anymore (use ip or ss instead). It is still very useful to know both though.

Finally you should pay close attention to anti patterns like "sudo su", "ps aux | grep ...", "cat ... | grep ..." etc and make sure to teach proper usage of the tools. I have seen it way too often done wrong in beginner guides.

[-] valentino@lemmy.ml 2 points 1 year ago

Lmao in university we had a Linux Kernel/OS - system calls class (4 months). You want to cover all of that in just 20hrs?

[-] floppingfish@kbin.social 2 points 1 year ago

Before you talk CLI, I'd talk about; customizing the machine, connecting to networks, installing programs, backing up and other regular tasks.

[-] MNByChoice@midwest.social 1 points 1 year ago

Looks great. Suggestions, but I only slimmed your list and did not internalize.

  • I installed a thing. How do I run it? (And other fun topics.)
  • How do I find a program that does X? (Grepping man pages or a internet search engine.)
  • fifty ways to do a thing. (To emphasize how everyone does things differently. Most are fine, some are wrong, a few are horrifying.)
[-] MajorHavoc@lemmy.world 1 points 1 year ago
[-] immibis@social.immibis.com 1 points 1 year ago

@clif @linux I think your plan is way too technical if your goal is to teach non-technical people to use Linux. For grandma it's pretty much the same as Windows - click on "Internet" to open the googles. What is your target audience and what are they trying to get from the course?

[-] danielfgom@lemmy.world 1 points 1 year ago

Always start with GNU Project, Freedom in computing and Richard Stallman.

The Freedom of the User in Linux is absolutely number 1 in Abu discussion of Linux. This is the core and essence of Linux. Nothing is more important.

Then explain who Linus is and what the kernel is any why it's known as GNU/Linux.

Most people never consider or are aware of the concept of user freedom so learning this is paramount.

The rest of the course looks ok, but seems like a lot of terminal stuff. If your audience are IT Pros that's ok but if ordinary users, is way too much.

[-] secret301@sh.itjust.works 1 points 1 year ago

Can I take it?

[-] gronjo45@lemm.ee 1 points 1 year ago

Personally, I'd enjoy if the class had an aside about how the display graphics are used to render graphics in something like Groff vs. a desktop environment like GNOME or KDE.

Also, emphasize that your students could choose vim/neovim or emacs to edit text rather than nano.

this post was submitted on 01 Sep 2023
116 points (98.3% liked)

Linux

48317 readers
685 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS