4 ms·

My complaints with unix (as someone running linux on every device, starting to dip my toe into freebsd on a vps); apologies for lack of editing: > everything i

My complaints with unix (as someone running linux on every device, starting to dip my toe into freebsd on a vps); apologies for lack of editing: > everything is text I'd often like to send something structured between processes without needing both sides to have to roll their own de/serialization of the domain types; in practice I end up using sockets + some thrown-together HTTP+JSON or TCP+JSON thing instead of pipes for any data that's not CSV-friendly > everything (ish) is a file > including pipes and fds To my mind, this is much less elegant when most of these things don't support seeking, and fnctls have to exist. It'd be nicer if there were something to declare interfaces like Varlink [0, 1], and a shell that allowed composing pipelines out of them nicely. > every piece of software is accessible as a file, invoked at the command line > ...with local arguments > ...and persistent global in the environment Sure, mostly fine; serialization still a wart for arguments + env vars, but one I run into much less > and common signalling facility As in Unix signals? tbh those seem ugly too; sigwinch, sighup, etc ought to be connected to stdin in some way; it'd be nice if there were a more general way to send arbitrary data to processes as an event > also nice if some files have magic properties like /dev/random or /proc or /dev/null userspace programs can't really extend these though, unless they expose FUSE filesystems, which sounds terrible and nobody does also, this results in things like [2]... > every program starts with 3 streams, stdin/stdout for work and stderr for out of band errors iow, things get trickier once I need more than one input one one output. :) I also prefer something like syslog over stderr, but again this is an argument for more structured things. [0]: https://varlink.org/ https://varlink.org/ [1]: ideally with sum type support though, and maybe full dependent types like https://dhall-lang.org/ https://dhall-lang.org/ [2]: https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-root-directory https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

blibble 6y ago
> iow, things get trickier once I need more than one input one one output. :) you can pass as many FDs to a child as you want, 0/1/2 is just a convention
- remexre 6y ago
  At that point you're writing something for /usr/libexec, not /usr/bin though. (i.e., at that point it becomes sufficiently inconvenient to use from the shell that no user-facing program would do so.)
  - JdeBP 6y ago
    That's pretty much false on every point. * https://unix.stackexchange.com/a/331104/5132 https://unix.stackexchange.com/a/331104/5132
shakna 6y ago
> As in Unix signals? tbh those seem ugly too; sigwinch, sighup, etc ought to be connected to stdin in some way; it'd be nice if there were a more general way to send arbitrary data to processes as an event Well, as the process can arbitrarily change which stdin it is connected to, as stdin is a file, you need some way to still issue directions to that process. However, for the general case, your terminal probably supports sending sigint via ctrl + c, siquit via ctrl + backslash, and the suspend/unsuspend signals via ctrl + z or y. Some terminals may allow you to extend those to the various other signals you'd like to send. (But these signals are being handled by the shell - not by stdin).
- remexre 6y ago
  Sure, I mean more like there'd be some interface ByteStream, and probably another interface TerminalInput extends ByteStream; TerminalInput would then contain the especially terminal-related signals (e.g. sigwinch). If a program doesn't declare that it wants a full TerminalInput for stdin, the sigwinches would be dropped. If it declares it wants one but the environment can't provide one (e.g. stdin is closed, stdin is a file, etc.) it would be an error from execve(). Other signals would be provided by other resources, ofc; e.g. sigint should probably be present in all programs. --- In general, my ideal OS would have look something like [0], but with isolation between the objects (since they're now processes), provisions for state changes (so probably interfaces would look more like session types), and with a type system that supports algebraic data types. [0]: https://www.tedinski.com/2018/02/20/an-oo-language-without-inheritance.html https://www.tedinski.com/2018/02/20/an-oo-language-without-i...
  - Bystroushaak 6y ago
    I have written something on this topic previously: http://blog.rfox.eu/en/Programmers_critique_of_missing_structure_of_operating_systems.html http://blog.rfox.eu/en/Programmers_critique_of_missing_struc...

blibble 6y ago

> iow, things get trickier once I need more than one input one one output. :) you can pass as many FDs to a child as you want, 0/1/2 is just a convention

remexre 6y ago
At that point you're writing something for /usr/libexec, not /usr/bin though. (i.e., at that point it becomes sufficiently inconvenient to use from the shell that no user-facing program would do so.)
- JdeBP 6y ago
  That's pretty much false on every point. * https://unix.stackexchange.com/a/331104/5132 https://unix.stackexchange.com/a/331104/5132

shakna 6y ago

> As in Unix signals? tbh those seem ugly too; sigwinch, sighup, etc ought to be connected to stdin in some way; it'd be nice if there were a more general way to send arbitrary data to processes as an event Well, as the process can arbitrarily change which stdin it is connected to, as stdin is a file, you need some way to still issue directions to that process. However, for the general case, your terminal probably supports sending sigint via ctrl + c, siquit via ctrl + backslash, and the suspend/unsuspend signals via ctrl + z or y. Some terminals may allow you to extend those to the various other signals you'd like to send. (But these signals are being handled by the shell - not by stdin).

remexre 6y ago
Sure, I mean more like there'd be some interface ByteStream, and probably another interface TerminalInput extends ByteStream; TerminalInput would then contain the especially terminal-related signals (e.g. sigwinch). If a program doesn't declare that it wants a full TerminalInput for stdin, the sigwinches would be dropped. If it declares it wants one but the environment can't provide one (e.g. stdin is closed, stdin is a file, etc.) it would be an error from execve(). Other signals would be provided by other resources, ofc; e.g. sigint should probably be present in all programs. --- In general, my ideal OS would have look something like [0], but with isolation between the objects (since they're now processes), provisions for state changes (so probably interfaces would look more like session types), and with a type system that supports algebraic data types. [0]: https://www.tedinski.com/2018/02/20/an-oo-language-without-inheritance.html https://www.tedinski.com/2018/02/20/an-oo-language-without-i...
- Bystroushaak 6y ago
  I have written something on this topic previously: http://blog.rfox.eu/en/Programmers_critique_of_missing_structure_of_operating_systems.html http://blog.rfox.eu/en/Programmers_critique_of_missing_struc...