Hacker News Reader

Comment by dasb | Hacker News Reader

The difficulty of learning Linux doesn't lie in what flags you should pass to ls, or other GNU core utils idiosyncracies.

The difficulty lies in making sense of the stack of different pieces of software that make up a Linux system, and the terminology we use to communicate about them (e.g. what mounting a filesystem means, which was initially hard for me to understand, coming from Windows).

View on HN

Also: most people think the terminal is something nerds use because they think it look cool. They see that thing and it looks to then like a wall of Katonese text — something they will never understand, partly because they think they can't, partly because they decided not to care.

In teaching the first steps should always be to make clear:

* why is this interesting, why would they care?

* why is this easier than it looks? (Take their fear away to get them started, reintroduce fear later as you see fit)

* show some examples that solve problems they always had, but never could solve any other way

Not all will learn, but even if you just managed to get people to understand why this makes sense and that it is totally possible to things on your own, you succeeded.

The worst teachers in my life where those where I had to learn something incredibly complicated without having a remote clue what it is needed for.

my grossly over-simplified understanding of Linux (for the average end-user) if I had to "teach it" to somebody really quickly

---

processor + RAM in motherboard with hard disk and some kind of integrated graphics solution/external graphic card for video output, plus keyboard + mouse for input (hardware)

hit the power button, motherboard inits procoess and runs BIOS which jumps to hard disk MBR (typically, ignores CD/USB/net boot)

MBR jumps into bootloader on first sector on hard drive (GRUB or syslinux/extlinux) (this is my pre-EFI understanding)

bootloader loads kernel (with optional initrd) from hard disk into memory

kernel performs its own init, mounts root device (hard drive formatted in Linux-friendly file system like ext4 usually), sets up all hardware given bundled drivers/modules, calls /sbin/init or comparable

/sbin/init spawns TTYs, does network configuration, then starts X server + a display manager (typically gdm if i remember correctly for GNOME?)

X has input drivers for keyboard + mouse, output driver to get graphics onto monitor(s) (not sure if Wayland finally killed X yet, gonna guess no)

from there, you can load /usr/local/bin/Chromium while will create a window on DISPLAY=:0 and go on Hacker News (granted you have it installed with all of its wonderful dependencies. probably 300mb+ of executables and resources and dynamic libraries)

the fact that there's 20 different ways to do a lot of the steps I just described is... interesting. the magic (to me at least) happens after /sbin/init. What all gets started? Why? I feel the latest Ubuntu probably spawns... 40-60 processes? systemd and this/that/the other.

I kind of conceptualize Linux as an OS (as compared to say a microprocessor directly executing a single program) like this- in the kernel there is a big infinite loop, just like a videogame loop that "updates" everything. In this loop the OS iterates over a linked list of task structs (AKA processes in userspace) and either gives each process its fair share of CPU time according to some scheduler or skips over it if it is sleeping (which the majority are).

I agree with you but I feel like that isn't specific to Linux as an OS. Windows and Mac both have a kernel responsible for keeping processes ticking in an infinite loop (scheduling executing across threads) as well.

I think the original comment I was responding to was about the complications of Linux. To me... the complications of Linux aren't really in the 20+ years of "tech debt" that is "just make it boot and work for x86_64 like it used to work for i386", but moreso the 20-30 different configuration files and formats that happen after boot.

That's part of it. Now consider the CPU probably has multiple cores, so the "loop" as you have it, isn't a single thread. It's quite fuzzy.

Add in the many tricks CPUs employ, like branch prediction, re-ordering, et al. Things don't happen in sequential order anymore, and multiple chunks of that code are being operated on at the same time.

Even Assembler is pretty much a high level language nowadays, because once its loaded in memory, lots of unseen permutations will happen to it at execution time. It's a language of macros after all.

A question of scope. Do you want people to understand every intricate of the system? Do you want them to grasp the basic concept?

Or do you want people to be able to use it on a day to day basis?

These are very different courses

For my part I just want to answer basic questions that will help me understand the Linux kernel workings. The assembly and hardware details are a different, lower level issue.

CPUs are very constrained on the kinds of reordering they are allowed to visibly exhibit.

While it's a difficulty in understanding a Linux system as a whole, it means you can understand pieces without understanding the entire system. One of the major difficulties I've had learning about Windows systems is that it's one coherent system (as least compared to Linux), so it's hard to understand a component without also having to understand how it integrates with the entire system.

Just like the BSDs, mac, Android, ChromeOS,... there is a certain beauty that even if the whole design is a bit Frankenstein like, at least it was kind of thought out together.

> e.g. what mounting a filesystem means

Funny. I've been using Linux for 10 (?) years and I still don't know what mounting means. I just know it's something that needs to happen in order for me to access the contents of a disk. I don't really care about it either, I only care about accessing the data. Why isn't it automatic anyway? Windows does it automatically whenever possible, why can't Linux?

> Windows does it automatically whenever possible, why can't Linux?

Linux can do that as well, every desktop environment worth their salt does it by default.

To expand on this a bit, desktop versions of Linux will happily mount filesystems when they're attached. Server versions tend not to because with a server you likely have a specific use case for the device you just attached, maybe you want to use it for database storage, or extra swap space, or any number of other things. There's no intelligent way to divine that just from the fact a new drive was plugged in, so it doesn't.

Thats a part of it.

There is also no one canonical linux stack. Different distros do things differently (sometimes drastically so).

E.g. systemctl flags and argument ordering differs from sysv style /etc/init.d/foo commands (as just one example)

So to learn “GNU/Linux” really you need to learn several distributions and piece together the common components and why different approaches are better suited to different environments.

> There is also no one canonical linux stack. Different distros do things differently (sometimes drastically so).

Does this fragmentation help or hurt the ecosystem over the long-term? I personally think it's the #1 reason Linux never stole any sizable market share from Mac OS X/Windows. Hardware support just isn't there. Polish just isn't there. Instead I can name multiple init systems, multiple shells, multiple package managers all fighting for space in our "brains" to be remembered and used. :P

Most hardware systems are binary drivers that manufacturers don't want to open up in the first place. Think nvidia/broadcom

Yeah but put yourself into the shows of a hardware manufacturer: if you'd build a Linux driver, which version do you build against? There is no reference implementation that you might use as a "if it works here it should run on every Linux there is".

If we really want good hardware support on Linux we have to at least some reference that manufacturers can use to verify it works

I'm confused. Drivers are kernel level right? All the distros use the same underlying kernel code (plus patches and binary blobs). But basically if a driver works for RHEL it will work for Ubuntu. Even better once the driver is mainlined in the kernel it will be supported going forward.

The problem for hardware manufacturers is that they think their drivers are valuable trade secrets and don't want to mainline them into the kernel...

The problem isn't distros, but different kernel versions. Linux has no stable driver ABI by design, so unless you open source all your code and get it in the mainline, you have to rewrite it for potentially every single kernel release.

Again, this is by design to try and force manufactures to open their driver code. To me, that seems like a lost cause now thanks to the proliferation of binary blobs required for hardware anyway.

Source for it being by design?

https://github.com/torvalds/linux/blob/master/Documentation/...

> So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? [...] Simple, get your kernel driver into the main kernel tree (remember we are talking about drivers released under a GPL-compatible license here, if your code doesn't fall under this category, good luck, you are on your own here, you leech).

In order for a driver to be in-tree, it has to be open.

Incidentally, this document is full of the kinds of arrogant and user-hostile arguments that the Linux community is known for, for example: "You think you want a stable kernel interface, but you really do not, and you don't even know it."

That's not how is works. Linux devs will write high quality drivers for free for any hardware that provides a spec.

The bad manufacturers like Nvidia and Broadcom intentionally block Linux compatibility for drivers they don't write themselves.

> I personally think it's the #1 reason Linux never stole any sizable market share from Mac OS X/Windows.

I assume you speak about desktop. MacOS never had any huge market share in this space. Its iPhone (and its predecessor, iPod) which allowed Apple to become as big as they currently are.

> Does this fragmentation help or hurt the ecosystem over the long-term?

Over the long-term it allows for abstraction layers, such as Ansible or Nix, to become status quo.

Reply on news.ycombinator.com