4 ms·

> and in many ways are still lightyears beyond what we have now. I think this wildly overstates it. Much of the good innovations have been adopted in Linux. 9p

> and in many ways are still lightyears beyond what we have now. I think this wildly overstates it. Much of the good innovations have been adopted in Linux. 9p exists. /proc was adopted (though that was in UNIX first). One unifying principle of plan9 is that everything is a file. But the (POSIX) file api has a lot of limitations. Fuschia, in contrast had some nice ideas about different types of file (blob/object, log, etc).

ori_b 6y ago
> I think this wildly overstates it. Much of the good innovations have been adopted in Linux. The main innovation can't be done by addition. With plan 9, many special cases are removed. You no longer have to wonder what happens if you try to create a Unix socket on an NFS file system, and then mmap it: There's just 9p. Everywhere. 9p is nice, but it isn't special. Making the whole universe 9p is where the improvement lies.
- cycloptic 6y ago
  >You no longer have to wonder what happens if you try to create a Unix socket on an NFS file system, and then mmap it How does that work? I don't know the details of any implementation, but 9p the protocol appears not to have any concept of mmap: https://9fans.github.io/plan9port/man/man9/intro.html https://9fans.github.io/plan9port/man/man9/intro.html I think I see what you mean about 9p not being that special, it doesn't seem much different than if Windows decided to export every system-level API as a DCOM object, that would also get you the same kind of "the whole universe is networked" kind of deal.
  - ori_b 6y ago
    > if Windows decided to export every system-level API as a DCOM object, that would also get you the same kind of "the whole universe is networked" kind of deal. The difference is that in Plan 9, there is no 'if', and there's no other option for accessing resources. All programs interface with the OS and other programs via 9p, more or less: Notable exceptions are process creation calls like rfork() and exec(). > but 9p the protocol appears not to have any concept of mmap: Correct. Mmap is a kernel feature -- and mmap style stuff is only really done for demand paging of binaries at the moment. You get a cache miss and a page fault? Backfill with a read. Backfilling IO on page fault is really all mmap does, conceptually.
    - cycloptic 6y ago
      >there's no other option for accessing resources That seems like it would create difficulties in porting software there. Please correct me if I'm wrong but the original plan9 appears to also have no support for shared memory or for poll/select. >Backfilling IO on page fault is really all mmap does, conceptually. For read-only resources yes, for handling writes to the mmapped region, that seems quite broken.
      - ori_b 6y ago
        Plan 9 is not a posix system. That means it doesn't have to deal with legacy posix behavior. If you want unix, it's easy to get it. > For read-only resources yes, for handling writes to the mmapped region, that seems quite broken. No more broken than mmap of nfs. Consistency is hard.
        cycloptic 6y ago
        >No more broken than mmap of nfs. Right, I get that's what you meant, it doesn't seem to really change much versus NFS, or DCOM, or whatever. So it's unclear what benefit is being provided by 9p here. Also upon further research I am not sure what you mean by this is the only option, plan9 seems to suggest use of channels for other types of IPC interfaces, which seem to not be the same as 9p and are not necessarily network serializable. (Or are they?)
        ori_b 6y ago
        Channels are not IPC -- they're a libthread API that stays within a shared-memory thread group. There are few magic kernel devices that don't act like 9p, like '#s' which implements fd passing on a single node. And the VGA drivers expose a special memory segment on PCs to enable configuring VGA devices. But the exceptions are very few and far in between, and affect very few programs. > So it's unclear what benefit is being provided by 9p here. A uniform and simple API for interacting with out-of-process resources that can be implemented in a few hundred lines of code.
- mey 6y ago
  9P is how Microsoft is bridging the filesystem between Windows/Linux in WSL2 https://devblogs.microsoft.com/commandline/a-deep-dive-into-how-wsl-allows-windows-to-access-linux-files/ https://devblogs.microsoft.com/commandline/a-deep-dive-into-...
  - anthk 6y ago
    Qemu uses 9p too.
zozbot234 6y ago
Linux is not yet a fully distributed OS, and even the basic foundational work for that featureset is only just being undertaken now (and then mostly as a natural development of cointainerization/namespacing features, which you might or might not see as drawing from Plan9 itself).
stormking 6y ago
These "nice ideas about different types of file" are not new. On the contrary, before Unix, this was common and it was one of the revolutionary approaches of Unix, that files - from an OS perspective - should be streams of bytes and nothing more.
- fnord123 6y ago
  I think before UNIX there weren't nice APIs for different types of file access. It was more like getting a raw block device and being told "fill your boots". stream-of-bytes was the right idea then. It doesn't mean it is still right.
  - stormking 6y ago
    You think wrong, it was exactly the same approach of defining a "nice API" for each type of file. It failed.
  - nix23 6y ago
    Before Multics...not UNIX ;)
zymhan 6y ago
By 9p you mean 9pfs? if so, it "exists" for Linux, but that's about all.
- calvinmorrison 6y ago
  One can natively mount 9fs on linux and there's also diod which exports 9fs. Works well for my setup of local file share to both plan9 machines and my linux boxes. I use diod because my storage system is running a chunky zfs with lots of storage I wanted to share
MisterTea 6y ago
> I think this wildly understates it. Much of the good innovations have been poorly hammered into Linux. FTFY. > 9p exists. A hacked up version called 9p200.u and later on, 9p2000.l which comes laden with posix and unix baggage and of course linux baggage in the lase of .l. This is to handle things like symlinks and special device file hacks inherited from Unix. > /proc was adopted (though that was in UNIX first). Linux proc is a mess. Plan 9 proc is just that, the interface to running processes. There's no stupid stuff like /proc/cpuinfo. wtf is that doing in there? http://man.postnix.pw/plan_9/3/proc http://man.postnix.pw/plan_9/3/proc > One unifying principle of plan9 is that everything is a file. But the (POSIX) file api has a lot of limitations. Plan 9 is not posix. > Fuschia, in contrast had some nice ideas about different types of file (blob/object, log, etc). A file is an array of bytes. Why complicate that simple approach?
- lucideer 6y ago
  > Linux proc is a mess. Plan 9 proc is just that, the interface to running processes. There's no stupid stuff like /proc/cpuinfo. wtf is that doing in there? http://man.postnix.pw/plan_9/3/proc http://man.postnix.pw/plan_9/3/proc Do you think Plan 9 /proc would have remained as "clean" over time if it were as popular as Linux? One thing that seems to be something of an axiom is that popular interfaces become messy over time. The location of /proc/cpuinfo seems to be an individual act of vandalism rather than being due to fundamental differences in underlying philosophy/approach.
  - MisterTea 6y ago
    > Do you think Plan 9 /proc would have remained as "clean" over time if it were as popular as Linux? If people are allowed to submit "functionality" patches ad-hoc with little to no scrutiny or thought, then yes, any project will become a mess. The general approach taken by plan 9 maintainers is to question functionality/feature patches and ask "Who does this benefit?" If the answer is only the submitter or rare edge cases then the patch is rejected. If the patch benefits a large audience, then it is accepted. But to be fair, Linux is hammered on by large corps who's only goal is to make money by vomiting webshit from Linux servers. They don't care about simplicity, technical details, correctness, or anything like that, so long as it increases their bottom line. From my point of view the Linux I came to love is long dead.

ori_b 6y ago

> I think this wildly overstates it. Much of the good innovations have been adopted in Linux. The main innovation can't be done by addition. With plan 9, many special cases are removed. You no longer have to wonder what happens if you try to create a Unix socket on an NFS file system, and then mmap it: There's just 9p. Everywhere. 9p is nice, but it isn't special. Making the whole universe 9p is where the improvement lies.

cycloptic 6y ago
>You no longer have to wonder what happens if you try to create a Unix socket on an NFS file system, and then mmap it How does that work? I don't know the details of any implementation, but 9p the protocol appears not to have any concept of mmap: https://9fans.github.io/plan9port/man/man9/intro.html https://9fans.github.io/plan9port/man/man9/intro.html I think I see what you mean about 9p not being that special, it doesn't seem much different than if Windows decided to export every system-level API as a DCOM object, that would also get you the same kind of "the whole universe is networked" kind of deal.
- ori_b 6y ago
  > if Windows decided to export every system-level API as a DCOM object, that would also get you the same kind of "the whole universe is networked" kind of deal. The difference is that in Plan 9, there is no 'if', and there's no other option for accessing resources. All programs interface with the OS and other programs via 9p, more or less: Notable exceptions are process creation calls like rfork() and exec(). > but 9p the protocol appears not to have any concept of mmap: Correct. Mmap is a kernel feature -- and mmap style stuff is only really done for demand paging of binaries at the moment. You get a cache miss and a page fault? Backfill with a read. Backfilling IO on page fault is really all mmap does, conceptually.
  - cycloptic 6y ago
    >there's no other option for accessing resources That seems like it would create difficulties in porting software there. Please correct me if I'm wrong but the original plan9 appears to also have no support for shared memory or for poll/select. >Backfilling IO on page fault is really all mmap does, conceptually. For read-only resources yes, for handling writes to the mmapped region, that seems quite broken.
    - ori_b 6y ago
      Plan 9 is not a posix system. That means it doesn't have to deal with legacy posix behavior. If you want unix, it's easy to get it. > For read-only resources yes, for handling writes to the mmapped region, that seems quite broken. No more broken than mmap of nfs. Consistency is hard.
      - cycloptic 6y ago
        >No more broken than mmap of nfs. Right, I get that's what you meant, it doesn't seem to really change much versus NFS, or DCOM, or whatever. So it's unclear what benefit is being provided by 9p here. Also upon further research I am not sure what you mean by this is the only option, plan9 seems to suggest use of channels for other types of IPC interfaces, which seem to not be the same as 9p and are not necessarily network serializable. (Or are they?)
        ori_b 6y ago
        Channels are not IPC -- they're a libthread API that stays within a shared-memory thread group. There are few magic kernel devices that don't act like 9p, like '#s' which implements fd passing on a single node. And the VGA drivers expose a special memory segment on PCs to enable configuring VGA devices. But the exceptions are very few and far in between, and affect very few programs. > So it's unclear what benefit is being provided by 9p here. A uniform and simple API for interacting with out-of-process resources that can be implemented in a few hundred lines of code.
mey 6y ago
9P is how Microsoft is bridging the filesystem between Windows/Linux in WSL2 https://devblogs.microsoft.com/commandline/a-deep-dive-into-how-wsl-allows-windows-to-access-linux-files/ https://devblogs.microsoft.com/commandline/a-deep-dive-into-...
- anthk 6y ago
  Qemu uses 9p too.

zozbot234 6y ago

Linux is not yet a fully distributed OS, and even the basic foundational work for that featureset is only just being undertaken now (and then mostly as a natural development of cointainerization/namespacing features, which you might or might not see as drawing from Plan9 itself).

stormking 6y ago

These "nice ideas about different types of file" are not new. On the contrary, before Unix, this was common and it was one of the revolutionary approaches of Unix, that files - from an OS perspective - should be streams of bytes and nothing more.

fnord123 6y ago
I think before UNIX there weren't nice APIs for different types of file access. It was more like getting a raw block device and being told "fill your boots". stream-of-bytes was the right idea then. It doesn't mean it is still right.
- stormking 6y ago
  You think wrong, it was exactly the same approach of defining a "nice API" for each type of file. It failed.
- nix23 6y ago
  Before Multics...not UNIX ;)

zymhan 6y ago

By 9p you mean 9pfs? if so, it "exists" for Linux, but that's about all.

calvinmorrison 6y ago
One can natively mount 9fs on linux and there's also diod which exports 9fs. Works well for my setup of local file share to both plan9 machines and my linux boxes. I use diod because my storage system is running a chunky zfs with lots of storage I wanted to share

MisterTea 6y ago

> I think this wildly understates it. Much of the good innovations have been poorly hammered into Linux. FTFY. > 9p exists. A hacked up version called 9p200.u and later on, 9p2000.l which comes laden with posix and unix baggage and of course linux baggage in the lase of .l. This is to handle things like symlinks and special device file hacks inherited from Unix. > /proc was adopted (though that was in UNIX first). Linux proc is a mess. Plan 9 proc is just that, the interface to running processes. There's no stupid stuff like /proc/cpuinfo. wtf is that doing in there? http://man.postnix.pw/plan_9/3/proc http://man.postnix.pw/plan_9/3/proc > One unifying principle of plan9 is that everything is a file. But the (POSIX) file api has a lot of limitations. Plan 9 is not posix. > Fuschia, in contrast had some nice ideas about different types of file (blob/object, log, etc). A file is an array of bytes. Why complicate that simple approach?

lucideer 6y ago
> Linux proc is a mess. Plan 9 proc is just that, the interface to running processes. There's no stupid stuff like /proc/cpuinfo. wtf is that doing in there? http://man.postnix.pw/plan_9/3/proc http://man.postnix.pw/plan_9/3/proc Do you think Plan 9 /proc would have remained as "clean" over time if it were as popular as Linux? One thing that seems to be something of an axiom is that popular interfaces become messy over time. The location of /proc/cpuinfo seems to be an individual act of vandalism rather than being due to fundamental differences in underlying philosophy/approach.
- MisterTea 6y ago
  > Do you think Plan 9 /proc would have remained as "clean" over time if it were as popular as Linux? If people are allowed to submit "functionality" patches ad-hoc with little to no scrutiny or thought, then yes, any project will become a mess. The general approach taken by plan 9 maintainers is to question functionality/feature patches and ask "Who does this benefit?" If the answer is only the submitter or rare edge cases then the patch is rejected. If the patch benefits a large audience, then it is accepted. But to be fair, Linux is hammered on by large corps who's only goal is to make money by vomiting webshit from Linux servers. They don't care about simplicity, technical details, correctness, or anything like that, so long as it increases their bottom line. From my point of view the Linux I came to love is long dead.