On software side, building an OS (distribution) from scratch provides a step above bare metal programming[0].
Provides familiarity with different types of things a kernel does via programs/scripts that make use of kernel.
Actually writing binary code for kernel bit can be done under qem[1][2]. aka don't need to buy actual hardware, can use 'software probes' to view what's going on, etc.
Don't have to worry about 'crashing'/trashing box running on (just crash the qem software & loosing just what was done in qem session, if didn't save as 'export/save to external location outside of qem session')
"Reading OpenBSD source code daily (blog.tintagel.pl)" from [hn: 3] automated way to review code.
It sounds like you're doing the normal sort of things that systems people do to get started. The fact that you have lots of ideas to jump off of is very good. In general just follow all of your ideas down as far as you can to the base systems. Write the TCP implementation for your HTTP server and run it over the internet for example. You've only gone too far when you start worrying about noise and debugging looks like randomly grounding metal things.
IMHO there is neither baseline nor “enough” when it comes to learning any programming language for any reasonably complex domain.
As you already know, C/C++ helps with low level software layers that interface with or manage hardware resources. In my experience, Go and Rust are also pretty much used as systems programming languages. For example, I use Go and EBPF to instrument systems calls on Linux kernel.
For me, most of my learning came from solving problems and building for specific use-cases. I think getting into builder mode and creating some cool will definitely accelerate your learning.
Sounds like you’re doing some interesting stuff and have a good, varied skill base to build on.
My advice would be to jump in and start working on kernel level stuff, or writing your own - IMO there’s no finer way to really “get” the low level concepts and the understanding you’ll build will really help with any other system-level stuff you do.
Not to plug, but if you were interested in getting involved in an existing project, my own toy kernel project[0] is at a point where there’s still lots of fun stuff left to do (both design- and implementation-wise) but a lot of the basic “project plumbing” and one-time machine setup stuff that people often get stuck on is already done, and I’d be glad to have the opportunity to share knowledge.
On software side, building an OS (distribution) from scratch provides a step above bare metal programming[0].
Provides familiarity with different types of things a kernel does via programs/scripts that make use of kernel.
Actually writing binary code for kernel bit can be done under qem[1][2]. aka don't need to buy actual hardware, can use 'software probes' to view what's going on, etc. Don't have to worry about 'crashing'/trashing box running on (just crash the qem software & loosing just what was done in qem session, if didn't save as 'export/save to external location outside of qem session')
"Reading OpenBSD source code daily (blog.tintagel.pl)" from [hn: 3] automated way to review code.
-----
[0] : https://www.linuxfromscratch.org/
[1] : qem for kernel developers - https://www.youtube.com/watch?v=LyWlpuntdU4
[2] : https://www.collabora.com/news-and-blog/blog/2017/01/16/sett...
[hn:3] : https://news.ycombinator.com/item?id=14521386
It sounds like you're doing the normal sort of things that systems people do to get started. The fact that you have lots of ideas to jump off of is very good. In general just follow all of your ideas down as far as you can to the base systems. Write the TCP implementation for your HTTP server and run it over the internet for example. You've only gone too far when you start worrying about noise and debugging looks like randomly grounding metal things.
IMHO there is neither baseline nor “enough” when it comes to learning any programming language for any reasonably complex domain.
As you already know, C/C++ helps with low level software layers that interface with or manage hardware resources. In my experience, Go and Rust are also pretty much used as systems programming languages. For example, I use Go and EBPF to instrument systems calls on Linux kernel.
For me, most of my learning came from solving problems and building for specific use-cases. I think getting into builder mode and creating some cool will definitely accelerate your learning.
Sounds like you’re doing some interesting stuff and have a good, varied skill base to build on.
My advice would be to jump in and start working on kernel level stuff, or writing your own - IMO there’s no finer way to really “get” the low level concepts and the understanding you’ll build will really help with any other system-level stuff you do.
Not to plug, but if you were interested in getting involved in an existing project, my own toy kernel project[0] is at a point where there’s still lots of fun stuff left to do (both design- and implementation-wise) but a lot of the basic “project plumbing” and one-time machine setup stuff that people often get stuck on is already done, and I’d be glad to have the opportunity to share knowledge.
[0] : https://github.com/roscopeco/anos
Oxide and Friends has an episode on the topic [1], I found interesting.
[1] : https://oxide-and-friends.transistor.fm/episodes/paths-into-...