Live data from Hacker News

Ask HN: What should a systems/low-level software engineer know?

news.ycombinator.com

191–200 of 231 posts

Re: Ask HN: What should a systems/low-level software engineer know?

#191
post #176
post #77

Earlier quoted context omitted.

http://hentenaar.com/dont-learn-c-the-wrong-way

Nah, that author wrote: >before you rewrite your C book, perhaps you should take the time to actually dig into it and learn C first (inside and out.) which is uninformed, as Zed wrote Mongrel and Mongrel2 in C. Saying he doesn't know C is ludicrous. He might have a different approach to C, but then argue this view instead of claiming your way is the only way. The author of that blog post is saying the book is bad bec…

K&R is a remarkably good and concise introduction to C.

I think that C is actually good, and that C++ is a Scooby-Doo sandwich of fail. But this is an opinion concerning a particular domain (low-level programming) that doesn't carry over to anywhere else.

Re: Ask HN: What should a systems/low-level software engineer know?

#192
Since your goal is to have a career switch I would recommend you the following approach:

- Essential books and papers are good as a reference to learn and improve but focus first on hands-on stuff.

- Get involved in an open source project that fits the 'system level' category, learn how it works and try to contribute to it (again, put your hands-on)

- Start with development in C language, a good tool to build would be a TCP client and server (kind of 'echo' program). The goal of this will be to learn: how to compile a C program, basics of memory management (malloc, free, realloc), networking (create a socket, bind, listen, connect), transfer data (write, read) and so on.

- If possible, learn using a native Linux environment.

All of the suggestions above will pay off if you are persistent and keep trying learning by building; of course, getting involved in an open source project is a must if you want to have a successful career.

Re: Ask HN: What should a systems/low-level software engineer know?

#193
Hi. Linux system / embedded developer here.

There are many different types of jobs. I will assume you mean low level development on an otherwise normal operating system like Linux.

I would start by learning how Linux userspace is constructed. Dig up old Linux From Scratch docs, build your minimal system, experiment with it. Try to understand how different stuff is put together. How elf/static/dynamic libraries works, etc. Look at your running processes (there shouldn't be many if you do LFS) and try to explain everything you see (what this process does, how it does its job, etc.)

Learn how kernel communicates with userspace. What are devices? What are syscalls? What syscalls are available? How filesystems work? How devices work? Etc.

Learn what is the job of Linux kernel. How memory management works, what is virtual memory, what is the difference when programming in user/kernel space.

The best way to learn system programming is definitely not getting up to your ears in a single open source project. You need variety of knowledge because you want to understand in breadth how the system works. Once you get a job or you figure out something interests you more there will be good time to specialize (say you want to specialize in security or containerization etc.)

Re: Ask HN: What should a systems/low-level software engineer know?

#194

Earlier quoted context omitted.

Does knowledge of the STM32 family apply to other ARM chips?

I would say absolutely yes. I started with the STM32 parts and have then used ARM Cortex devices from TI, Freescale, and Atmel. They all have different peripherals and of course different peripheral libraries from the vendor but overall they are conceptually similar. It can certainly be a pain in the neck to switch a project from one device to another (lots of gotchas with pin layout, peripheral minutiae etc etc) but…

Spent a lot of time with the Kinetis DMA. Luckily I had nothing to compare it with. Learned later it was not as other DMA:s.

Re: Ask HN: What should a systems/low-level software engineer know?

#195

If your are looking towards embedded: * put a cap between power and ground * get some nice ESD-birkenstocks * don't listen to anybody telling you how it's done The start of the art is BS and we need a revolution. There will be so many people who tell you that you can only do it in C and if you don't, you can't be taken seriously. The result is that everybody is keeping to C and nobody invests time in bringing new ide…

regarding crappy SDK's from vendors - it is indeed strange they do not put more effort in this. I mean software is a huge cost in embedded as with other fields. My only theory is that it is usually the hardware team that decide what chip to use!? Would be interesting to know if respective tools for CAD/EE/hardware design is any better? (Hard to compare though)

Re: Ask HN: What should a systems/low-level software engineer know?

#196

A systems programmer will specialize in subdomains much like any other programmer, but there are some characteristic skills and knowledge that are common across most of them. Systems programmer coding style is driven by robustness, correctness, and performance to a much greater degree than higher up the stack. Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. - Know ho…

> Most systems programming jobs these days is C/C++ on Linux and will be for the foreseeable future. I don't disagree, but at least anecdotally a lot of the shops I've been involved with/worked with are really excited about Rust and Go. A previous employer that used C++ exclusively has even shipped a few Golang based tools, and is planning to introduce it into the main product soon. No new projects are being started…

Golang is garbage collected. I thought due to this, system programmers don't like it.

Re: Ask HN: What should a systems/low-level software engineer know?

#197

I'm an embedded software engineer. Here's my $0.02 on how to get started: 1. Get a platform you can tinker around with, and recover quickly in case of disaster. Raspberry pi is a good example. 2. Learn how to find and read detailed register-level manuals of the underlying chip you're working on. 3. Learn what a programmer's memory-model is. 4. Learn what peripherals are, and what they do. You may have to dig a bit in…

This is an odd ordering, mostly because of things like devicetree's are pretty arm/linux centric. In which case if your doing arm/linux just find a module you can unload or fail to build into your kernel. Real embedded programming is more like grab a cortex-m0, avr, etc and start bit banging.

OTOH, there is a danger that I've seen frequently that embedded systems guys don't seem to be able to make the conceptual leap to fully paged, SMP programming. Having sort of come up this way myself (via mircocomputers without MMUs and just a single processor) it doesn't make any sense to me, but it seems common.

People who have been exposed to a more common multi-threaded and virtualized environment seem to be able to pick up those pieces easier.

Re: Ask HN: What should a systems/low-level software engineer know?

#199
post #161

Earlier quoted context omitted.

Does knowledge of the STM32 family apply to other ARM chips?

Yes and no. General ARM programming--yes. Specific peripherals--no. General peripheral knowledge--yes. An ARM is an ARM withing certain limits so your knowledge transfers. Sadly, every chip has a different way of programming the periperhals. However , every chip has roughly the same core peripherals (I2C, SPI, UART, etc.), and those electrical specifications and how you use them for protocols doesn't change.

  General peripheral knowledge--yes.
Maybe, programming a modern DMA based device running in a full blown OS with userspace, kernel space, an IO MMU, giving you bus IOVA addressing through a VM, with multiple command buffers, SRIOV, etc, while not wildly different isn't the same as doing IO read/writes into a fixed MMIO mapped device region. Doing some basic SPI programming is a start, but one has to understand there are a lot more layers that get added as the systems grows from a AVR level device to a modern server.

Re: Ask HN: What should a systems/low-level software engineer know?

#200
Topics to study should include: Unix IPC, signals and syscalls, filesystem and kernel implementation details, and network/socket programming.

Being able to read and write C programs goes a really long way.

Beej's guides are a good resource. I learned a lot from them.

Guide to network programming: https://beej.us/guide/bgnet/html/multi/index.html

Guide to Unix IPC: https://beej.us/guide/bgipc/

The Unix Programming Environment (Kernighan & Pike) is also very good.

http://files.catwell.info/misc/mirror/the-unix-programming-e...

A good exercise would be to write a simple IRC-like chat server and client in C.

Post reply on HN