8 ms·

This is something I like about Plan 9 (and I like basically everything about Plan 9). The entire OS's source code (the kernel, userspace, everything) is availab

This is something I like about Plan 9 (and I like basically everything about Plan 9). The entire OS's source code (the kernel, userspace, everything) is available at /usr/src and can be compiled and installed with these commands: cd / . /sys/lib/rootstub cd /sys/src mk install It takes about 5 minutes. Want to cross-compile for another architecture? cd / . /sys/lib/rootstub cd /sys/src objtype=arm64 mk install If you haven't tried Plan 9, you really ought to spend your next spare weekend messing around with 9front. http://9front.org/ http://9front.org/ No other technology you could spend your weekend with will have a larger impact on your way of thinking about computers than Plan 9 might.

qqii 7y ago
Unfortunately I think plan9 only remains this way by keeping the people who use it small, being elitist and somewhat unwelcoming[0]. That's not to say I wouldn't also recommend spending a weekend messing around. I was recently having a conversation about the unix philosophy on reddit[1]. As nix and software built for nix became more and more mainstream it becomes harder and harder to keep with the unix philosophy and the philosophy of this post. [0]: http://fqa.9front.org/ http://fqa.9front.org/ [1]: https://youtu.be/XvDZLjaCJuw https://youtu.be/XvDZLjaCJuw
- ddevault 7y ago
  The reading material is "unwelcoming" to discourage coming into it with any preconceptions. If you go into it trying to make it do $x, you'll have a bad time and send lots of annoying emails to the maintainers. If you come into it wanting to learn about it and derive an $x from your experience, you'll have a better time.
  - saagarjha 7y ago
    To be fair, a cat flipping me off and telling me to “go away” in the FAQ may lead to misunderstandings.
PaulDavisThe1st 7y ago
Plan 9 is lucky - by design it is self-contained and has no dependencies. One of the hardest parts about building many complex open source projects (particularly on Windows and macOS) is getting their dependency stacks in order.
- ddevault 7y ago
  All projects would be well served by carefully keeping their dependency graph small and conservative.
  - PaulDavisThe1st 7y ago
    So you think that rather than see that list grow, they should all reimplement their own (drawing examples from my own project): * font rendering * audio file I/O * resampling * websocket support * OSC support * i18n * XML parsing * .... ? In our case, 89 libraries. 2GB of compiled libraries. Surely you can't be serious. Unless you just don't believe in "big, complex software" ?
    - ddevault 7y ago
      89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make. In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
      - akkartik 7y ago
        As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.

qqii 7y ago

Unfortunately I think plan9 only remains this way by keeping the people who use it small, being elitist and somewhat unwelcoming[0]. That's not to say I wouldn't also recommend spending a weekend messing around. I was recently having a conversation about the unix philosophy on reddit[1]. As nix and software built for nix became more and more mainstream it becomes harder and harder to keep with the unix philosophy and the philosophy of this post. [0]: http://fqa.9front.org/ http://fqa.9front.org/ [1]: https://youtu.be/XvDZLjaCJuw https://youtu.be/XvDZLjaCJuw

ddevault 7y ago
The reading material is "unwelcoming" to discourage coming into it with any preconceptions. If you go into it trying to make it do $x, you'll have a bad time and send lots of annoying emails to the maintainers. If you come into it wanting to learn about it and derive an $x from your experience, you'll have a better time.
- saagarjha 7y ago
  To be fair, a cat flipping me off and telling me to “go away” in the FAQ may lead to misunderstandings.

PaulDavisThe1st 7y ago

Plan 9 is lucky - by design it is self-contained and has no dependencies. One of the hardest parts about building many complex open source projects (particularly on Windows and macOS) is getting their dependency stacks in order.

ddevault 7y ago
All projects would be well served by carefully keeping their dependency graph small and conservative.
- PaulDavisThe1st 7y ago
  So you think that rather than see that list grow, they should all reimplement their own (drawing examples from my own project): * font rendering * audio file I/O * resampling * websocket support * OSC support * i18n * XML parsing * .... ? In our case, 89 libraries. 2GB of compiled libraries. Surely you can't be serious. Unless you just don't believe in "big, complex software" ?
  - ddevault 7y ago
    89 libraries is a lot. Even the most complex project I work on has just 20. The list you gave seems somewhat reasonable, but I'm willing to bet that the long tail of stuff you didn't mention includes a lot of more trivial dependencies. I don't know your project, but I imagine that you ought to redefine your scope to avoid introducing a need on complex dependencies. Simpler software is more robust, more maintainable, and often gets the job done better - but it's more difficult to make. In any case, I'm mainly criticisng the typical JavaScript, Ruby, etc project, with their giant pile of node_modules or whatever the case may be. It can easily get out of hand with other projects, too, especially in languages which encourage over-engineering and over-abstracting like Rust or C++ (let me guess: yours is the latter?).
    - akkartik 7y ago
      As a trivial example, I spent a couple of hours last night pruning stuff I didn't need from one of my text editor plugins (https://github.com/mhinz/vim-signify https://github.com/mhinz/vim-signify). I was able to take it down from 1400 lines to sub-300 lines. And in the process it became a lot clearer precisely what the algorithmic core of the library was. A valuable learning experience. vim-signify was 800 lines large back in 2014 when I first started using it. How much of the stuff added since mattered to me? Almost nothing. These are the costs we all take on -- death by a thousand cuts -- when we blindly import dependencies.