3 ms·
> No one, in the Unix world, ever complained about the Unix's missed promise about file abstraction. I was complaining about the missed promise of file abstrac
by einpoklum 4y ago
> No one, in the Unix world, ever complained about the Unix's missed promise about file abstraction.
I was complaining about the missed promise of file abstractions since the first time I was exposed to their potential: "Oh, that's great - but then, why isn't XYZ accessible as a file? And why can't we have the kernel offload interpretation of path suffixes to userspace code? And why isn't `/proc` richer? And why do I need to mess around with BSD sockets if we can just go through files? etc. etc."
Now, sure, I'm just a nobody (and was a complete nobody 25 years ago when I noticed this) - but the author's claim is just false.
- drdaeman 4y agoSo did I. Just the last week I needed a replacement for a container init that watches the process outputs and kills the process on timeout. Surprising, but I haven't found anything readily available, so I had to hack my own tiny program. I haven't done much system programming any recently so my knowledge was kinda rusty. I knew the basics of what I should do - I had to wait on the child PID, watch out for the signals (because I'm running an init process, can't keep those zombies around), and work with the piped stdout/stderr fds. Sounds trivial, except that it's three completely independent APIs and those aren't files so select(1) is not my friend here. So I learned about signalfd and then learned how it's broken. Almost thought I have to run some threads but then I've learned about pselect(1) which seem to do the job. Either way, "gosh, I'd wish I'd have Plan 9 instead of all this mess" was one of my thoughts that day.