Hacker News Reader

Comment by yzzxy | Hacker News Reader

Enjoying the recent spatter of articles on fuzzing, it's an interesting topic to read about and file for future use.

This page brings me back to a question that I've been having a lot recently: how does one get really good at *nix in this day and age?

It seems like the era of learning on a college mainframe computer is over, and "sysadmining" for hobby and SaaS nowadays projects often totally abstracts the nitty-gritty bits of the OS. Yet these systems still power our computers and servers, and there appears to be a real utility in understanding them well. I run Debian as my daily driver, with a fairly "hardcore" setup without a fancy GUI, but I still feel like I haven't even scratched the surface of my OS. I don't really understand how library linking or process messaging or anything like that works, and I'm not sure how to start learning.

View on HN

Learning C is essentially required to become really good with UNIX. For example, the answer to your library linking question only "correctly" makes sense when you understand C since you need to understand C to really understand how the underlying C code works with all the compilers, linkers, loaders, object files, executable file formats, and such.

The good folks Debian build and maintain a solid linux disto, but you need to realize how a linux distro will only teach you the "linux way" of doing things. There are other ways, and of course, other systems. The various BSD operating systems like OpenBSD, FreeBSD, NetBSD, DragonFlyBSD, ArchBSD, BitRig, and so forth all tend to stick a bit more closely to the classic or historic "UNIX way" of doing things.

If the goal is to learn C so you can learn the underlying system code, my choice would be OpenBSD. It's simple, solid, and secure, but the best reason to pick it would be the quality of the code and documentation. It really helps to have reliable code and docs when you're trying to learn, and like all active projects, they keep trying to improve both.

The only reason why I know about the AFL fuzzer is due to the never ending auditing of OpenBSD since some of the OpenBSD developers, like Damien Miller [1] and Jonathan Gray [2], have recently been using AFL to discover and fix bugs.

[1] https://twitter.com/damienmiller/status/534156368391831552

[2] https://www.marc.info/?l=openbsd-cvs&m=141646270127039&w=2

That is some of the best argument I've heard to go back to OpenBSD.

Thanks for the advice... I will be bookmarking this and I think I'll load up a FreeBSD install on a Raspberry Pi or something[0]. I know C, but I don't know C, and it think learning about compilers and such would be super interesting.

[0] More driver problems are probably good, right? :)

Honestly, I don't think it's been easier in the days of university mainframes. Today, it takes minutes to download, run, and brick new OSes in a VM; you have terabytes of free and easily searchable documentation and code samples at your fingertips; hardware is cheaper than ever; etc. It's pretty great.

My best advice would be, don't overthink it. Take one random thing apart, see how it works, and see if you can break it. Try digging into the inner workings of memory virtualization, or write a "hello world" bootsector in assembly, or figure out how syscalls happen and write your own that does something silly, or design a simple program that injects something into an ELF binary without using any higher-level tools. Or, perhaps, just browse random 2- an 3-section manpages and experiment with what you find.

Couldn't agree more. Take one random thing apart. It won't feel like learning, but that's what it's like. You will not wake one morning and be done, because there's always one more thing to learn.. and that's good!

The best way, for me, was fixing something that didn't work.

The "problem" now is, *nix has gotten pretty good/stable/justworks(tm).

So the other, more time consuming way, is probably contributing to different areas.

That should force you understand all the different systems better.

An OS + Compiler course can go a long way to understanding the grand strokes on those. When it actually starts mattering, it's so dependent on what system you're working with that it's hard to provide an "abstract" understanding that will cover everything.

I, for one, am glad that I don't really _have_ to know all of this. If it does become critical to a component I'm writing, I'm glad to know this stuff, but like a sibling comment said, everything just works. Shoulders of giants and all that, but at the end of the day, what's important is being able to build functional systems, and that's gotten easier.

I would recommend doing Linux From Scratch: http://www.linuxfromscratch.org/

Start with Stephens' books, Unix Network programming, and then move onto The Design of the FreeBSD Operating System (new edition).

I picked up a random piece of hardware I knew probably ran linux under the hood, and found that hacking it really threw me in the deep end. Working with stuff that's not documented, has probably never been tried and looks utterly impossible is a heap of fun and for me at least a good teaching tool. Pick an arbitrary goal and learn how to get there.

There's a lot to be said for reading Kernighan & Pike, to get a feel for the original design of the system.

Reply on news.ycombinator.com