Live data from Hacker News

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

news.ycombinator.com

211–220 of 231 posts

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

#211

Earlier quoted context omitted.

> 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.

It depends what you need from it. If you need real-time-like behaviour, it may be a problem. If you need static thread-to-cpu mapping, it may be a problem. Etc.

Know your requirements and then you can decide on the runtime.

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

#212
My advice:

- become good at either C or C++ or both. Lots of fun jobs/projects involve codebases that happen to be written in those languages.

- become fearless and systematic with assembly. You don’t have to be great at it. You just have to have had enough experience looking at it and writing it that you can hack it if you have to.

- learn to read code quickly and accurately. The only way to do that is a lot of practice. It’ll be hard at first but as you practice your reading speed will go up by >10x and eventually it’ll feel like second nature.

- become great at working with large code bases. What makes “systems code” so interesting is really just how big “systems” are. This kinda goes along with the bit about reading code - reading is how you survive in large code.

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

#213
post #143

Earlier quoted context omitted.

> peek(), poke(), memset(), memcpy and similar functions on any memory address that PICO-8 uses Surprised that this hasn't been exploited to build a C compiler targeting the platform. (Unless I needed to Google something other than "pico-8 C compiler"...)

The only thing I can imagine that would be good for is learning how to write a C compiler :)

PICO-8 limits the textual size of your input Lua file, so I'd imagine that it might be possible to squeeze more content into your game with a small interpreter and packed binary format represented as a printable string.

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

#214
post #175

Earlier quoted context omitted.

> Know how your hardware actually works, especially CPU, storage, and network. I learned about MIPS CPUs in college, 20 years ago, with Patterson and Hennessy, and built one from logic gates. It was basically a high-powered 6502 with 30 extra accumulators, but split across the now-classic pipeline stages. I understand that modern CPUs are much different than this. I understand that there are deeper pipelines and bran…

For the average systems programmer, 90% of the really useful CPU information can be found in two places that change infrequently: - Agner Fog's instruction tables for x86[1], which has the latency, pipeline, and ALU concurrency information for a wide range of instructions on various microarchitectures. - Brief microarchitecture overviews (such as this one for Skylake[2]), that have block diagrams of how all the funct…

Do we have similar resources for Discrete GPU's? I checked on wikichip, the GPU information is hard to come by or I am missing some Google fu.

Thanks for sharing the above very useful resources, blocked my Saturday for first scan!

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

#215

Earlier quoted context omitted.

All of that stuff is changing though. I would never ship a product today without remote signed upgrade ability. All devices that plugs into a windows PC can use Windows Update for example to upgrade firmware. Any device that sits at a remote location probably ought to have a GSM modem in (adding only $1 to the cost of the device) for tracking uptime and firmware updates. Any device which offers an API to other device…

Where can I get a GSM modem and support components for $1 in BOM costs, let alone $1 for finished product cost (inc intentional radiator cert and distribution/channel markup)? What about the $1-2/mo network charge? Or battery life considerations? I've got sensors that run for 2-3 years on a CR123a battery. That power profile isn't going to support a GSM connection.

Have a complete kit with free delivery for a dollar:

£0.96 | DIY KIT GSM GPRS M590 gsm module Short Message Service SMS module for project for Arduino remote sensing alarm https://s.click.aliexpress.com/e/b4tPrIy0

Lots of providers are happy to provide worldwide service for free, as long as you pay $10 per gigabyte. I generally budget 1 check-in per day, of about 250 bytes, so a coin cell can easily power it for a few years with a total service cost for 2 years of just a few cents.

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

#216
post #163
post #45

Earlier quoted context omitted.

The german version is called "Kraftfahrtechnisches Taschenbuch" and is ~15EUR cheaper.

But it is in german, and i believe that a native will not fully understand it if he did not work in the field in germany. I'm french and studied in the UK. I'm sometimes lost when my colleague use french technical terms, i have to ask the concept behind it to be able to identify the english term which i learnt during my studies.

From a review on amazon:

> However, as an English speaking engineer, I found many of the discussions rather clumsily written. I'm guessing that it was translated from the German by someone who doesn't thoroughly understand the subject matter.

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

#217

Earlier quoted context omitted.

Huh. I always perceived C to be a subset of C++.

I like to think what is JSON to Javascript is C to C++ (not capability wise). JSON and Javascript are completely, entirely different things even though JSON is technically a subset of Javascript (every valid JSON sentence is a valid Javascript sentence). C and C++ are extremely different languages -- mostly due to cultural reasons -- even though every valid C program is a valid C++ program (not strictly true, C and C…

Can I be pedantic? If I'm wrong someone will correct me and I'll learn something.

Json is not exactly a subset because it supports representation of numbers of any precision. JavaScript will convert to an IEEE 754. But it's up to a json deserializer to decide how many decimals to use. I think.

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

#218

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)

The running conspiracy theory is that they want to sell you support via application engineers.

Could be a case of unfit business model leading to wrong incentives.

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

#219
"Systems Programming" at the minimum, requires knowledge of Language internals, Runtimes, Compiler Toolchains, OS internals, Drivers, Computer Architecture/Organization, CPU/Multiprocessors and Networking. There are other domains like Security, Parallel/Distributed Processing etc which are cross-functional or orthogonal to the above and can be focused on as needed.

But be warned, earning potential-wise you may lose out(unless you get lucky) to the latest whiz-bang Web/Mobile technology/framework brouhaha. That is the nature of the market. However i consider that the satisfaction of learning and "knowing" how things work, more than makes up for the small loss in earning potential. This technology is also more fundamental and stable and thus will not go away anytime soon.

I have found the following papers/books (somewhat different from the most commonly cited) useful in my study;

Languages: Fluency in C is a must. It is THE "portable assembly" language and is available on everything from 8-bit MCUs to multicore servers. You can also link C modules to everything under the sun thus allowing you to extend almost any other language. C++ is also needed; but judicious usage as a "better C" rather than heavy-duty OOP/Generic/Template-mataprogramming madness.

- Computer Systems: A Programmer's Perspective 3rd ed. based on x86-64. You might also want to get the 1st ed. which is based on 32-bit x86. These books cover the HW/SW interface and thus includes almost all the topics under "Systems Programming".

- The C Companion by Allen Holub.

- Inside the C++ object model by Stan Lippman.

Tools/Toolchain: Knowledge of the GCC toolchain is a must.

- The Definitive guide to GCC by Hagen

- ELF: A Programmer's perspective; paper by H.J.Liu

- C++ Under the hood; MSDN article by Jan Gray

- The Practice of Programming by Kernighan and Pike.

OS/Kernel/Drivers:

- UNIX Systems for Modern Architectures: Symmetric Multiprocessing and Caching for Kernel Programmers by Curt Schimmel.

- Linux Kernel Development 3rd ed. by Robert Love.

- Essential Linux Device Drivers by Venkateswaran.

- Embedded Linux Primer 2nd ed. by Hallinan

- The Unix Programming Environment by Kernighan and Pike

- Advanced Unix Programming 2nd ed. by Rochkind

Computer Architecture/Organization

- Modern Processor Design: Fundamentals of Superscalear Processors by Shen and Lipasti

- Computer System Design: System-on-Chip by Flynn and Luk

Parallel/Distributed processing:

- Foundations of Multithreaded, Parallel, and Distributed Programming by Andrews

- The Art of Multiprocessor Programming by Herlihy and Shavit.

Bare-metal Embedded: Where the "rubber meets the road"

- Embedded Systems Architecture: Explore architectural concepts, pragmatic design patterns, and best practices to produce robust systems by Lacamera

- Patterns for Time-Triggered Embedded Systems by Pont.

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

#220
post #189
post #62

Earlier quoted context omitted.

What if -and I'm sorry to hijack- by low-level OP means a position as a C/C++ developer (asking for ~a friend~ me)? I've always been insanely attracted to the C variants and messed around with them to minor extents, but what might someone _need_ to know to be competitive if they're trying to make a move to that area of SE?

For C: Pointers, stacks (one in ever 23.7 bugs is a stack smashing bug), bit bashing and endianness, types and coercion at the byte level (see also: pointers, bit bashing), C strings, the stupid rules about when a variable's value is actually written to memory that need to die in a fire, memory allocation/clearing/copying/ownership/freeing, ALWAYS CHECK RETURN CODES, what the heck an lvalue is. This book is fun: http…

Thanks! I just started reading that last night. Pretty good so far.
Post reply on HN