Live data from Hacker News

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

news.ycombinator.com

121–130 of 231 posts

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

#121
The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well.

For me, low-level is assembly, not C.

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

#122
post #121

The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well. For me, low-level is assembly, not C.

Does anyone beside compiler writer write in assembly? For what systems? Why wouldn't they use a compiled language?

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

#124
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 into basic electronics.

5. Learn what user-space vs kernel-space is.

6. Learn what device trees are, and how to prevent kernel from taking over a peripheral.

7. Based on above information, write a user-space driver for a simple peripheral (e.g. GPIO or UART) in C (don't try to learn assembly, yet). You will not be able to use the peripheral interrupts in user-space.

8. Learn how to verify hardware functionality, and see your driver in action. (Warning: high dopamine levels are reported at this point).

9. Repeat steps 7 and 8 for all peripherals, and see how far you can go.

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

#125

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Are you sure about your epoll statement concerning complexity? 1 thread per client connection that blocks is as simple as it gets to reason about in my experience, and if you don't care about the stack space the thread occupies (mostly virtual anyways) your contemporary Linux kernel handles lots of threads very well.

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

#126
post #121

The word "system" is used a lot to describe many different collections. For example, the molecules that act on glucose to create ATP is considered a "system," as in something like an RF chip that has Tx/Rx on the same piece of silica. Can someone help provide a definition for what a system means in the Hacker News context? What is "low-level" as well. For me, low-level is assembly, not C.

Does anyone beside compiler writer write in assembly? For what systems? Why wouldn't they use a compiled language?

There are post-mortem crashes where the only thing I can look at in the disassembly. It's not if they write in it, but if they know how to read it. It's more useful, particularly in some cyber security subsets.

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

#127

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…

Oddly there is a Raspberry Pi 3 sitting on my desk today. I find myself a little reluctant to setup the BTD loop for it (BTD = build test debug), because at the end of the day I'm going to have a (physically small) linux box. Which is fine because I plan on installing a network proxy on it that only needs wifi. But how is the Pi a gateway to embedded programming? It has pinouts you can attach an oscilloscope to?

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

#129
post #56

From the top of my head, these are some areas I often would like other system programmers to know better: - Understanding how to write purely event-based programs using e.g. epoll since that will avoid lots of complexity and potential problems compared to throwing threads at everything. - Floating point representation and gotchas ("What Every Computer Scientist Should Know About Floating-Point"). - Unit-testing as pa…

Maybe it is just me, but I've seen this issue multiple times where a programmer used a regular expression thinking they were clever, only to have it backfire later when there was some corner case not covered by their regex (which likely would have obviously been caught if they had just taken the time to write out each case as an if statement). You're usually just gaining complexity in exchange for fewer lines of code…

A good in-between option is a parser generator like Ragel ,http://www.colm.net/open-source/ragel/

This takes in the definition of a regular language as a set of regular expressions, and generates C code for finite state machine to parse the language. You can visualise the state machine in Graphviz to manually verify all paths, making it much easier to spot hidden corner cases, while being a lot quicker to code than a big pile of if statements.

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

#130

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…

Oddly there is a Raspberry Pi 3 sitting on my desk today. I find myself a little reluctant to setup the BTD loop for it (BTD = build test debug), because at the end of the day I'm going to have a (physically small) linux box. Which is fine because I plan on installing a network proxy on it that only needs wifi. But how is the Pi a gateway to embedded programming? It has pinouts you can attach an oscilloscope to?

Yes, it has a GPIO header that has pins that mux to a limited number of periphals. You can attach an oscilloscope to any GPIO.
Post reply on HN