Hacker News Reader

Comment by pedrocr | Hacker News Reader

> Finally, Plan 9 fits well with a networked environment. Since files or directory trees can be imported from other machines, and all resources are files or directory trees, it's easy to share resources. Want to use a different machine's sound card? Import its /dev/audio. Want to debug processes that run on another machine? Import its /proc. Want to use a network interface on another machine? Import its /net. And so on.

Does this kind of abstraction actually work well? Networks are generally quite unreliable so does it really work well to treat everything as files even when the latency can be so different depending on if the resource is local or remote? Do the plan9 APIs make it natural to write code that deals well with random blocking when reading/writing to files?

View on HN

I've not used Plan9; but one ought to consider that any IO may not be successful, and this is regardless of the device.

It may generally be less likely to encounter disk read errors than it is to encounter network timeouts, but both will eventually occur.

The 9P protocol is designed to deal with arbitrary blocking, as synthetic filesystems commonly block reads until some data is present. There are also automatic reconnection proxies (aan), and when a mountpoint is entirely unresponsive (lost connectivity), you can just unmount it. The pending calls will all fail gracefully.

The abstraction works well. The main issue is when you lose access to your root device. Just like if you booted a Linux machine from NFS, the root disk connection must be stable (how do you unmount without being able to read the binary). All other mounts can be arbitrarily flakey.

> how do you unmount without being able to read the binary

We have enough RAM now that there's no reason (even on embedded devices!) to ever unload the initrd/initramfs. An OS should be able to be configured such that you can unmount your rootfs whenever you like, and just automatically be de-pivot-root'ed and end up back in your initramfs, where you can mount the rootfs again.

What's your definition of embedded? It's not embedded if you're running a full blown OS on a regular ARM chip.

Anyway, you could make a ramdisk, put things in it and put it in your path. I doubt that a linux box will survive a dead root without hardcore sysadm skills, but it should work on plan9. Initrd is not meant to stay behind after boot, though.

This abstraction works fantastically well in QnX, a system used in production the world over so I see absolutely no reason why it wouldn't work in plan9.

Reply on news.ycombinator.com