3 ms·

No, you really can't. Plan 9 wasn't a modification of the Research Unix they used at the Labs, it was a new operating system because Unix couldn't implement the

by 4ad 13y ago

No, you really can't. Plan 9 wasn't a modification of the Research Unix they used at the Labs, it was a new operating system because Unix couldn't implement the required abstractions in an orthogonal way. Plan 9 replaces the abstractions offered by Unix with different new ones; you can't just add new abstractions on top of old ones. It's a completely different world, different process and security models which are incompatible with the old models. Linux wouldn't be Linux anymore. One reason why you would want Linux with Plan 9 semantics instead of Plan 9 is because Linux has a lot of drivers. Unfortunately, the I/O model is a consequence on how Plan 9 does things, and if you want Plan 9 semantics in Linux you'd have to modify all the drivers. Every driver that uses IOCTLs would have to be modified, which is pretty much every one of them. Plus, whatever you did, there's the small matter of Linux people accepting you changes. A Linux fork is useless; if it's not in mainline, it doesn't exist. Historically the Linux folks haven't been very happy with these kind of changes...

coldtea 13y ago
Linux has been implementing Plan 9 features piecemeal for ages. For example: /proc fs, several system calls, utf-8, etc. But I wasn't talking about that stuff specifically (which might or might not be incompatible with core Linux). Parent lamented of Linux generally not trying out new research ideas. Well, why doesn't he have a go at it?
- pjmlp 13y ago
  It is funny how the typical Linux zealots answer is go and implement the stuff one complains about. Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up. And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever. I have been coding before Linus could even think about doing Linux, and have better things to do with my free time.
  - coldtea 13y ago
    >It is funny how the typical Linux zealots answer is go and implement the stuff one complains about. I use OS X. Could not care less about Linux except on a server. Have started with Sun OS and HPUX back in the day. >Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up. Pretty much sums it. >And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever. And why would it be "integrated and accepted" if the people don't like it? Because it's "novel" and "out of the usual"? I'd say, "we actually want it in our kernel" is a far more compelling argument than "It's novel". >I have been coding before Linus could even think about doing Linux, and have better things to do with my free time. So, you "have better things to do with my free time" but the people doing Linux kernel work should implement novel things for your amusement? How exactly do you justify that? (As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that).
    - pjmlp 13y ago
      > So, you "have better things to do with my free time" but the people doing Linux kernel work should implement novel things for your amusement? Why should it be for my amusement?! I was only stating a fact. > (As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that). No, it just means I use GNU/Linux like any other OS and I don't care about OS religious wars.
- 4ad 13y ago
  The Linux procfs is nothing like Plan 9's /proc or Inferno's /prog, in fact it's nothing like any other operating system's procfs. All procfs are different, only the name, and perhaps the mountpoints are similar. I'm not even talking about implementation details, I'm talking about the abstraction itself; what does it do and what it allows you to do. The clone(2) system call is somewhat superficially similar to Plan 9's rfork(2). Linux came to the same conclusion as Plan 9; threads vs. processes is a false dichotomy. The fundamental schedulable kernel entity is a thread and threads may or may not not share resources, like address space. The similarities end quickly, however. Linux clone(2) is crippled by the fact that flags that allow novel abstractions, like universal network transparency, such as the flags that set up per process namespace are restricted to the superuser. This is of course a consequence of the Unix security model and because Linux has suid binaries.

by 4ad 13y ago

coldtea 13y ago

Linux has been implementing Plan 9 features piecemeal for ages. For example: /proc fs, several system calls, utf-8, etc. But I wasn't talking about that stuff specifically (which might or might not be incompatible with core Linux). Parent lamented of Linux generally not trying out new research ideas. Well, why doesn't he have a go at it?

pjmlp 13y ago
It is funny how the typical Linux zealots answer is go and implement the stuff one complains about. Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up. And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever. I have been coding before Linus could even think about doing Linux, and have better things to do with my free time.
- coldtea 13y ago
  >It is funny how the typical Linux zealots answer is go and implement the stuff one complains about. I use OS X. Could not care less about Linux except on a server. Have started with Sun OS and HPUX back in the day. >Everyone needs to be a kernel developer, a XWindows developer, a GNOME developer, a KDE developer, ... or just shut up. Pretty much sums it. >And even when something is done that goes out of the usual copying existing ideas, there is the uphill battle to get it eventually integrated and accepted, if ever. And why would it be "integrated and accepted" if the people don't like it? Because it's "novel" and "out of the usual"? I'd say, "we actually want it in our kernel" is a far more compelling argument than "It's novel". >I have been coding before Linus could even think about doing Linux, and have better things to do with my free time. So, you "have better things to do with my free time" but the people doing Linux kernel work should implement novel things for your amusement? How exactly do you justify that? (As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that).
  - pjmlp 13y ago
    > So, you "have better things to do with my free time" but the people doing Linux kernel work should implement novel things for your amusement? Why should it be for my amusement?! I was only stating a fact. > (As for "coding before Linus could even think about doing Linux", should we be impressed by the timespan alone? Tons of dabblers and mediocrities have also done that). No, it just means I use GNU/Linux like any other OS and I don't care about OS religious wars.
4ad 13y ago
The Linux procfs is nothing like Plan 9's /proc or Inferno's /prog, in fact it's nothing like any other operating system's procfs. All procfs are different, only the name, and perhaps the mountpoints are similar. I'm not even talking about implementation details, I'm talking about the abstraction itself; what does it do and what it allows you to do. The clone(2) system call is somewhat superficially similar to Plan 9's rfork(2). Linux came to the same conclusion as Plan 9; threads vs. processes is a false dichotomy. The fundamental schedulable kernel entity is a thread and threads may or may not not share resources, like address space. The similarities end quickly, however. Linux clone(2) is crippled by the fact that flags that allow novel abstractions, like universal network transparency, such as the flags that set up per process namespace are restricted to the superuser. This is of course a consequence of the Unix security model and because Linux has suid binaries.