Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The secret of *nix that people don't like accepting is the file approach is often the right approach.

Consider lowly embedded linux. You COULD dig down deep into the documentation of which register, which interrupt, which special memory address needs to be written to interact with the right ports on a embedded linux board. All while adding a bunch of safeguards and checks to make sure "Only you are doing this".

Or, as if often the case, you can simply find the right /dev/xxxx device and read from it or write to it.

9 times out of 10, you'd not suffer any negative consequences from using the /dev/xxx system as intended and you get the bonus ability of being able to interact with the outside world using programming languages other than C.



The file approach ignores anything that exists (at least in part) in the time domain.

Audio files are (for me) the canonical example. A text file has no inherent bit-rate. An audio file being handled without knowledge of (even just) its sample rate has its semantics distorted or destroyed.

There's an awful lot of things you can do with the file approach, and I love it. Cross into the time domain and try to retain the same approach, and I say you're making a serious mistake.

What's worse is when the actual programming APIs (as opposed to just redirecting stdout to /dev/dsp) also fail to model the time aspect, and encourage programmers to think that you can just shovel data at a device without any consequences for your software's properties (like latency).


Many character devices do in fact have a bitrate.


It's mostly syntactic though, not semantic.


I don't think this has anything to do with the file approach per se, just with using an interface at a higher abstraction level.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: