3 ms·

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of

by samus 3y ago

This means layering additional protocols on top of the file APIs. Of course you can do that, but eventually there will be a similar explosion such as on top of `ioctl`, and it's doubtful whether the resulting interfaces will be any easier to use than the existing ones.

c00lio 3y ago
On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)
- civilitty 3y ago
  I can’t wait till we’re configuring our OS using CSS-in-JS and booting using webpack. npm install -g styled-linux
  - c00lio 3y ago
    As always, Fabrice Bellard is ahead of his time: https://bellard.org/jslinux/ https://bellard.org/jslinux/ :)
ori_b 3y ago
Plan 9 does this. The resulting interfaces are indeed easier to use, forward over the network, and redirect or emulate for testing.
butterisgood 3y ago
Exactly? The alternative is ioctl whereas Plan 9 does everything over serialized streams to files. The serialized streams make it easier to think of these ioctl-alikes as something you can easily access over a network (9p). And that’s how resource sharing is done in plan 9.
TheRealPomax 3y ago
Let me introduce you to the Linux Audio Stack. Laying protocols on top of each other, when everything is just files, is no different from layering protocols on top of each other when some things are files and some thing aren't. The question isn't "will it be just as bad" but "would some things become easier, and if so, how many things would become easier?". Because if the latter, then it's a worthwhile topic to think about even if we never use it in any commercial sense of of the word.
- samus 3y ago
  The main problem with Linux audio is the bloom of APIs that appeared over the years. While a file-based interface would be cool, it would be just yet another API that competes with all the others for its place in the ecosystem. Fortunately, ALSA and PulseAudio seem to dominate right now.

by samus 3y ago

c00lio 3y ago

On the other hand, layering tons of stuff on unsuitable interfaces has been all the rage in the last 25 years. Just think of everything-over-http, stuff-it-in-xml/json, program-it-in-yaml and similar industry trends. ;)

civilitty 3y ago
I can’t wait till we’re configuring our OS using CSS-in-JS and booting using webpack. npm install -g styled-linux
- c00lio 3y ago
  As always, Fabrice Bellard is ahead of his time: https://bellard.org/jslinux/ https://bellard.org/jslinux/ :)

ori_b 3y ago

Plan 9 does this. The resulting interfaces are indeed easier to use, forward over the network, and redirect or emulate for testing.

butterisgood 3y ago

Exactly? The alternative is ioctl whereas Plan 9 does everything over serialized streams to files. The serialized streams make it easier to think of these ioctl-alikes as something you can easily access over a network (9p). And that’s how resource sharing is done in plan 9.

TheRealPomax 3y ago

Let me introduce you to the Linux Audio Stack. Laying protocols on top of each other, when everything is just files, is no different from layering protocols on top of each other when some things are files and some thing aren't. The question isn't "will it be just as bad" but "would some things become easier, and if so, how many things would become easier?". Because if the latter, then it's a worthwhile topic to think about even if we never use it in any commercial sense of of the word.

samus 3y ago
The main problem with Linux audio is the bloom of APIs that appeared over the years. While a file-based interface would be cool, it would be just yet another API that competes with all the others for its place in the ecosystem. Fortunately, ALSA and PulseAudio seem to dominate right now.