On Sat, Sep 12, 2026 at 1:23 PM C <[email protected]> wrote: > I think, a terminal is just a cpu server you access directly, and its just a > cpu server when you use it remotely.
No, but you're not too far off. Technically, CPU servers and terminals run different kernels, though they are built from the same set of sources, and the differences are very minor; they amount to a difference between how much RAM is reserved for the system versus user processes, how they authenticate at boot, and settings things up so that the system starts /rc/bin/cpurc or /rc/bin/termrc depending on which is which. Generically, CPU servers are configured so that they run network servers that allow multiple authenticated users to log into the machine and make use of its resources; terminals tend not to do that, but rather, run things locally as the host owner (the user who logged in when the system first booted up). Traditionally, CPU servers either provided substantial computation resources and fast network connections (particularly to the file server machine), or were more modest machines that filled specific roles (like running the authentication services), while terminals tended to be smaller and diskless, but have excellent graphics hardware, decent sound, and really nice keyboards and mice: these were the machines users interacted with when they logged into a plan 9 network, that ran their window system, text editors, mail clients, and so on: they're not really meant to be shared in a meaningful way, as that would be mostly uninteresting unless you were sitting right in front of one. > So, including your cpu and terminal nodes, you now basically have two cpu > servers depending on how it's setup. I wouldn't think of a terminal as a "cpu server" per se, but nothing prevents you from running programs that provide services to other users on the network on one, provided you are ok with those things running as your user, etc. > Perhaps I'm incorrect about this abstraction? As above, because the kernels are so similar, it's not too far off. But in the Plan 9 model of the world, the idea is that you construct your environment on your terminal, and you dynamically construct the environment you are using by importing resources that are shared with the network from other machines; thus, the way to think of a CPU server isn't so much that you use one by logging into a remote machine, but rather, you import its resources into your local terminal's environment. Of course under the covers you are actually connecting to a remote machine and running programs on it, but as a conceptual model, this is better than thinking about e.g. using `ssh` to log into a remote Unix machine or something. I wrote about this a bit here: https://pub.gajendra.net/2016/05/plan9part1 (One of these years I'll get around to writing the other parts) - Dan C. > On Fri, Sep 11, 2026, 9:27 PM plat via 9fans <[email protected]> wrote: >> >> a, I want something more like HDMI out, but an HDMI in feature is also >> pretty interesting so thank you for telling me about that. Also, a, could >> you kindly check my personal email to you? >> >> >> Dan, On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote: >> >> and maybe audio? unclear >> >> I knew how to export audio between machines, but had trouble with graphics >> or control and so I requested help, and you did help me, so thank you! >> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote: >> >> or any graphical application, I suppose >> >> yes >> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote: >> >> The idea would be that your slower speed HID devices are being accessed >> remotely via 9P, while the high-bandwidth, fast video signals are using >> their native electrical or optical path via whatever signaling protocol >> (HDMI, DP; whatever the kids are into these days), correct? >> >> exactly >> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote: >> >> you could `cpu` into the server machine, and then `bind /mnt/term/dev/kbdin >> /dev/kbdin; bind /mnt/term/dev/mouse /dev/mouse; bind -b '#i' /dev` >> (possibly others; I may have forgot something) and then invoke `rio`; >> perhaps `aux/vga` as well. >> >> This was literally it. Thank you for the solution! I had no idea it could >> work like that. Now I know >> >> On Friday, September 11, 2026, at 10:25 PM, Dan Cross wrote: >> >> It does beg the question, though: why not also just run a long USB (or >> whatever) cable to the server and use it as a terminal? >> >> I would respond, but I got very confused as to how you would go about >> connecting a second terminal in the same manner to the same server. If you >> could show me an example of connecting a second terminal, I would be very >> grateful. I assume if it is possible, then it is equally possible to do it >> entirely without a terminal too >> >> >> On Saturday, September 12, 2026, at 12:07 AM, C wrote: >> >> A question i have is where is the keyboard and mouse plugged-in that you >> want bound to the namespace that is running your * video cable to display? >> >> C, view my response above. Keyboard and mice are at term, video cable is >> coming out of cpu >> >> >> Thanks everyone, especially Dan Cross! But I am still interested whether >> multiplexing is possible here > > 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T248f62cc83f47b6d-M2cde94c9d34495b655566630 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
