Hi, nice write-up, I can second every thought and feel the same.
However, I think it's worth looking at the beginner's journey - and I think there are many. I'll share my own, maybe that helps you understand a bit more about certain issues I (and probably others) had. For the background, I probably was the last generation to learn basic programming in a blue editor. That was on DOS, when windows 2000 was already out and windows XP was around the corner. I was very lucky to learn all that and at some point I learned about Linux (thanks, Dad). Starting with some suse Linux, I learned a lot about different linuxes, posix, Unix and so on. I also touched different OSes a bit (MacOS, Haiku, Menuet/Kolibri), but only as a visitor. During my Linux journey, I encountered Luke smith. That was before he moved into the forest and made more Linux content than anything else. Thanks to him, I started to use suckless software and learned about Plan 9. My first year of plan 9 was me using Linux and reading plan 9 papers (including fqa), as well as playing around with inferno. I liked the idea of inferno, but I didn't really understand what inferno was for, and I wasn't deep enough to really use it. At some point (after around a year) I started to use plan 9 (9legacy, later 9front) in a qemu. That is, I installed it and played around from time to time. I wasn't really able to do anything useful with it. People might remember me from my time on gridchat, back on mycroftiv's grid, and thanks to all the community there, I was able to learn more about using the system. At some point, I got a thinkpad T61, which I installed 9front on, and basically I started daily driving it. It was the only system I used personally, my professional job enforced windows. That was when I started writing software and really using the system. I tried to explore every corner of the system, and I believe I have quite a solid understanding of it now. Eventually, I got a VPS to run my website on. It now also runs mail and a few other services. I installed 9front on everything I had and that was capable of running it. I started working on the ninephone project, as well as a few other bigger projects, like gpufs, and many smaller projects (most of them you can find on shithub/sourcehut). What I think of my journey: It took a long time. It took 1 year until I started to use the system, and another year to fully understand it. It's almost impossible to apply any knowledge from the original papers without touching the system (kudos to Daniel CyReVolt) and asking the community (thanks everyone). The most practical piece of written guides is the fqa, as well as one or the other blog post. Even the man pages sometimes only show how a tool works, and not what you can do with it and what it's used for. Plan 9 being a bit unixy, it relies on chaining tools together, and how many things just fit together, and to what degree! In interaction with other people, I think namespaces are hard to grasp, but they're one of the easiest things if explained correctly. Other components like factotum, devdraw, /srv, /net are way more complicated to explain without showing. The fqa tried its best to show plan 9 from a more practical (and historical) side, the papers highlight the technical, theoretical side. The man pages show the details of the implementation of the individual components. I think those cover many aspects individually, but a guided tour is somewhat missing. A tour that uses all these aspects to guide a user into the system. A inst/start for learning. A guide that doesn't focus on one aspect, but shows enough of each aspect so that a user can understand what they are doing and are empowered to apply what they're learning. That's what my plan was with the "serious guide to plan 9": starting with the basic principles like resource abstraction as filesystems and logging into a system, to how the individual components play together to form a powerful unit for what the user wants to do. I'd like to see it covering every relevant piece of the system, and going deeper into the inner working chapter by chapter. After the first parts for the user, there would be additional parts for the developers, which shows programming on programs and later the kernel. The goal should be, not documenting things there are, but showing everything that's needed to start doing whatever. For example, I wouldn't want to show every single tool in /bin, but I would want to show that tools are in /bin, how they end up being in /bin using namespaces, how to find more info about them using the man pages. I believe that this is also part of the goal of the fqa, and in some chapters it does it very well. In others it's more focused on getting the system running (installation), which is important, but it doesn't really help a user to learn the system. I know there's also nemo's paper, which I didn't really read yet. At first glance it feels like it's very technical and it also focuses on the technical side of resource abstraction, but I might be wrong. I believe a guided tour/learning guide should also be written with a mindset of teaching, not so much with the thought of explaining and documenting. I think this is a lot more work than just writing up how things work, and it probably also involves user tests, as well as making good images (screenshots and graphics). I don't want to make this mail any longer, and it's long enough already. Thank you for coming to my ted talk. sirjofri ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T767651d6223b6d46-M0f2083fe396cea2fc039458b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
