undefined | Better HN

0 pointsremexre5y ago0 comments

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/

[1]: ideally with sum type support though, and maybe full dependent types like https://dhall-lang.org/

[2]: https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

0 comments

shakna5y 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).

remexreOP5y 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-i...

Bystroushaak5y ago

I have written something on this topic previously: http://blog.rfox.eu/en/Programmers_critique_of_missing_struc...

blibble5y 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

remexreOP5y 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.)

JdeBP5y ago

That's pretty much false on every point.

* https://unix.stackexchange.com/a/331104/5132

j / k navigate · click thread line to collapse

0 pointsremexre5y ago0 comments

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

> 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

> 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/

[1]: ideally with sum type support though, and maybe full dependent types like https://dhall-lang.org/

[2]: https://www.phoronix.com/scan.php?page=news_item&px=UEFI-rm-...

0 comments

shakna5y ago

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.

remexreOP5y ago

Other signals would be provided by other resources, ofc; e.g. sigint should probably be present in all programs.

---

[0]: https://www.tedinski.com/2018/02/20/an-oo-language-without-i...

Bystroushaak5y ago

I have written something on this topic previously: http://blog.rfox.eu/en/Programmers_critique_of_missing_struc...

blibble5y 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

remexreOP5y 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.)

JdeBP5y ago

That's pretty much false on every point.

* https://unix.stackexchange.com/a/331104/5132

j / k navigate · click thread line to collapse