Exploring Linux command-line space time
fabiensanglard.net
Exploring Linux command-line space time
1–10 of 39 posts
Re: Exploring Linux command-line space time
#2The GitHub repo link is broken
Re: Exploring Linux command-line space time
#3Would be curious to see how a "Hello World!" in Zig compares.
Re: Exploring Linux command-line space time
#4The GitHub repo link is broken
Re: Exploring Linux command-line space time
#5This is excellent across a few key dimensions.
- Clear and concise code.
- Clear communication: writing, technical explanations, and conveyance of thought process.
- Thorough and systematic.
Major kudos to the author. It was a fantastic refresher on the mechanics of fork() for me!
This kind of article is the reason I troll HN so much. Occasionally gems pop up.
Re: Exploring Linux command-line space time
#6this is a small personal nit complaint, but increasingly I see "Linux command-line" used to refer to things which have nothing to do with command-lines per se, which to me suggests some cli-fu with p|pes || other tricky \\&\\&& if-fi $(things).
Perhaps we need some better vocabulary to separate these ideas, but the world of unix includes "shell" ideas, and their interplay with cli, there's ascii text ttys, there's ansi tty control and TUIs, and what this article is about, traditional unix userspace process-space, system calls, C-libs, compilers vs interpreters got skipped, but C-vs-Rust, just all without the overhead of GUI frameworks which brings a bit more clarity to timings but they don't absolutely, to do timings could be better to write a program to launch all these things and make sure that program is "sticky" in unix space-time.
This is a good article, but because I like to search for things again later, just as a headline I wouldn't really call this exploring Linux command-line space or time
Re: Exploring Linux command-line space time
#7> Following process/thread creation is done via netlink(7).
shouldn't ptrace with PTRACE_O_TRACEFORK (etc.) be enough (and much easier)?
the high overhead of strace the author notes is due to it doing PTRACE_SYSCALL, which is not needed here.
Re: Exploring Linux command-line space time
#8This is excellent across a few key dimensions. - Clear and concise code. - Clear communication: writing, technical explanations, and conveyance of thought process. - Thorough and systematic. Major kudos to the author. It was a fantastic refresher on the mechanics of fork() for me! This kind of article is the reason I troll HN so much. Occasionally gems pop up.
Fabian is a treasure. He also made the Game Engine Black Books covering Wolfenstein 3D and Doom.
Re: Exploring Linux command-line space time
#9This is excellent across a few key dimensions. - Clear and concise code. - Clear communication: writing, technical explanations, and conveyance of thought process. - Thorough and systematic. Major kudos to the author. It was a fantastic refresher on the mechanics of fork() for me! This kind of article is the reason I troll HN so much. Occasionally gems pop up.
Fabian is a treasure. He also made the Game Engine Black Books covering Wolfenstein 3D and Doom. https://fabiensanglard.net/gebbdoom/
And his book on the Capcom system is interesting for me even though I’ve never played one.
Re: Exploring Linux command-line space time
#10Would be curious to see how a "Hello World!" in Zig compares.
Why not run `st` on it and post the result here?