HN Books @HNBooksMonth

For what it's worth I had asked someone the very same question when I started my career.

From the horses mouth take a look at ext4 on ubuntu https://help.ubuntu.com/community/LinuxFilesystemsExplained

Then a 10,000 mile view, I'd take a look at UNIX and Linux https://www.amazon.com/UNIX-Linux-System-Administration-Hand...

There are more books I could list and papers on FileSystems. I will leave you with three particular books that have guided my career

If you want to look solely at Ubuntu. The Ubuntu Server book https://www.amazon.com/Official-Ubuntu-Server-Book-3rd/dp/01...

Unix Made Easy - https://www.amazon.com/UNIX-Made-Easy-John-Muster/dp/0072193...

Hope this helps

Might as well add a link to a book I learned about on HN but never seem to run across since, UNIX and Linux System Administration Handbook, 4th Edition: http://www.amazon.com/Linux-System-Administration-Handbook-E...

I'm willing to bet there isn't but a handful of people in this community that "knows everything on that list", remembering everything on that list is... well, unneeded?

9/10 times when I'm using a command that isn't part of my "daily list" I'll need to consult man pages and/or Google.

I've used xargs hundreds of times, but depending on when I used it last, I can never remember if I need -0 or not, and is it $1 or {} or wait, no no, I'm using awk, so it's $1, and I need to changes something... is it needle, haystack, replacement or... hell, I'm not even sure if it's substr or just sub... errrr.

Not to mention some of these are distro specific, in some you use service name start, in others it's /etc/init.d/service start. Some it's adduser, others it's useradd, etc. It's relative to the distro a lot of the times... are the files in /usr/opt/ or /opt/... or maybe they're in /usr/local/opt/... Also they list stuff like locate, but not updatedb. Not a single mention of dd or shred or /etc/resolv.conf or netcat (I fucking love netcat!) or unzip (far more likely to need to unzip an archive than add a user in your day to day life).

We're not command libraries, we're duct tape mechanics.

http://xkcd.com/1168/

edit: if you're interested in learning more... I honestly can't recommend this book enough.

http://www.amazon.com/Linux-System-Administration-Handbook-E...

⬐ colechristensen

I don't consider myself in any elite minority for it, but I feel I have strong familiarity with everything on that list. While maybe a bit of curating might be necessary, _every_ developer whose code comes anywhere near a Unix descendant should be just as familiar to be considered anything above 'junior'. Most teenagers are perfectly capable of this understanding.

I find my job wearing a DevOps hat to be very often much more difficult than it ought to be because so many programmers clearly don't understand the OS layer they're running on (both when supporting internal developers at various places which I've called $work, and using OSS and commercial software in that role)

There's no shame in running `man xargs` to get the syntax just right (we're not dictionaries) but general knowledge of what those tools are and how to use them are _essential_ to being a good developer... this is an essence too often neglected by universities and professionals.

⬐ jimmaswell

>There's no shame in running `man xargs` to get the syntax just right (we're not dictionaries) but general knowledge of what those tools are and how to use them are _essential_ to being a good developer... this is an essence too often neglected by universities and professionals.

I don't really think so. You can get by fine developing a lot of things without knowing linux tools. They are helpful, though. What if you're working on Windows like a ton of devs do?

⬐ colechristensen

It's always good to have a diverse set of skills, but I meant (and said somewhere) the things I said for those whose code ever runs on nix. I also don't just mean a mastery of the commandline tools but also how various pieces of a nix system run (most recently my irritation has come from bad logging) and general Unix philosophy.

⬐ chadillac

I agree completely. My point was when I looked at the list the first thing that jumped out at me was dig... yeah, I know what dig is, what it's used for, but I just hadn't seen it in a while... that's how often I actually have to use it. There isn't a reason for me to really keep it in my mental dictionary of known commands because of it's overall utility to me. Likewise commiting logrotate flags to memory, pretty much useless, how often do you honestly have to run that by hand or use it in a day in day out situation. If you answer "often" to that, then we'll need to get you up to speed on more core components like crons and shell scripts.

That was my point.

⬐ oftenwrong

tar -xzf bombdefuser.tar.gz

If you find yourself using xargs frequently, you should check out GNU Parallel https://www.gnu.org/software/parallel/

⬐ xixixao

So is it maybe that Python is a language with much smaller surface area and (most likely) much more consistent design, so we simply don't need a cheat sheet like this? By rough estimate, my Mac came with over 1000 commands - no structure, namespacing.

I love that xkcd. I really hope someone will take up the task of replacing the UI of *nix with something better. For me, it's like Windows 8: it was a nice idea to combine touch and traditional user interface - it just turns out to be inferior to either being done well. Writing shell scripts is just, let's face it, horrible, and the command line interface far from ideal. It works, it has for decades. But it's not like there has been a lot of competition to compare with.

Sibling is complaining about academia and universities - but again, apart from sys admins, who don't teach, none of the academics know this stuff. Learning and teaching Python (Java) is in some respect easier but more importantly interesting - it just doesn't make sense to learn all these commands without actually needing them (whoever comes up with an exercise to use them all together gets a medal).

⬐ ecma

I'd disagree with the assertion in your first paragraph. The Unix CLI toolset has evolved in a very similar way to any other software ecosystem. To compare with Python, the GNU coreutils/binutils and friends could be thought of as analagous to the Python core with other toolsets fulfilling a role similar to packages from PyPI. The standards and interface issues for both ecosystems are similar but luckily Python has more leeway to alter compatibility (ref changes in 3k).

There are all sorts of issues with altering the nix toolset, and we mustn't forget the importance of POSIX for compatibility. We can't simply decide to 'replace the UI of *nix' without fundamentally changing how the nix ecosystem and community operate (and I wouldn't want to). OS development is not agile and rarely compat breaking, and for good reason.

I also read the sibling as promoting a fundamental understanding of the underlying platform being developed on, not so much pushing teaching of just CLI usage. Knowing how, e.g., the filesystem works and the caveats involved is something that can lead to much better software design decisions. And knowing how to chain a cheap sed instead of just throwing Python and the re module at a glob.glob listing can be just as useful.

⬐ chadillac

I agree with your sentiment but if you find the CLI to be a lack luster interface the only thing I can think is that you've not spent enough time using it correctly. I was a Windows guy, then an OS X guy, then a Linux guy. I found that I preferred CLI more than GUI's so I moved to Linux full time when I started getting frustrated with GUI tools and Darwin ports and the like.

Now days it annoys me if a library doesn't have a CLI. Even on my personal machines I run the least amount of GUI possible for resource and usability purposes. I don't want a new GUI or a better CLI (zsh, csh, bash, ksh, etc. do just fine). I just want tools that utilize it properly to support it's most powerful functionality (pipes, output redirect, proper exit codes, etc.)

A lack of familiarity with it is no institutes fault, it's a personal fault, if you find your self looking at a CLI interface, and then resorting to searching Google for a GUI wrapper for that interface, the ignorance isn't due to a failure of the CLI, it's a failure of the user being intimidated or ignorant.

Also I have no issues writing shell scripts, I use them all the time to save me tons of work. If you're a programmer then you really get to know your system and you really get to customize it to your liking.

An example would be switching to i3 from Gnome/KDE. I was a long time KDE/Gnome/XFCE user and my laptops track pad settings would never stick after a reboot when I used the GUI tools for disabling the touchpad tap to click or just disabling it in general (thinkpad nipples ftw). After moving to i3 and really getting more access to the core of the system I ended writing a couple little shell scripts for enabling disabling my touchpad for when I need/want it. What used to be a 5 step operation (open gui > click tab > uncheck box > click save) has now become (super+space, type disa[tab](autocomplete disable.touchpad), enter). I have a second script to enable it again, the contents of which are small.

#!/bin/bash

exec synclient TouchpadOff=1

⬐ zodiac

I agree that CLIs are ofter better than GUIs, but I think the point was that the Linux CLI tools could have been designed better. For example, personally I don't like how gzip/gunzip comes in a pair, but there's no "untar" command, instead you must pass the -x argument to tar.

Wow, this is a great approach you've chosen, and it will teach you a ton. If you want to start learning more about how your machine is configured, the Nemeth book is very good:

http://www.amazon.com/Linux-System-Administration-Handbook-E...

I've only read the 3rd edition, but it looks like this newer edition also includes Linux.

Well damn.

Though, it did feel inevitable after so long without news.

If you're not sure who she is, take a moment to read up [0][1].

0: http://en.wikipedia.org/wiki/Evi_Nemeth

1: http://www.amazon.com/dp/0131480057

Get some books on Unix admin. Nemeth et al's "Unix System Administration Handbook", and its Linux version are usually a good start. The most recent edition is coming out in 17 days: http://amzn.com/0131480057

You will also need a bunch of O'Reilly books.