Add a simple "Getting Started" section to the README?

[naikrovek]

(This is less of an issue, and more of a suggestion.)

The examples all involving docker confuse my old, caveman brain. "I'm a simple cave man, your world frightens and confuses me." I have to pull off the Docker stuff in my mind while reading to understand what is really happening, and it is taxing for me.

Imagine that I already have a Linux server and a Linux laptop (or a Linux server and a MacBook running MacOS); without any containers, how can I get this working?

Maybe I'm stupid or something, I honestly don't know, but some simple instructions like "on the remote machine, do this", and "on the local machine, do this" would be welcome. I can then add Docker on top of that or I can add Ansible on top of that, or I can add whatever else I need on top of that.

Probably because I started my career in the 1990s, doing everything manually, I have a very hard time understanding how something works or why it is useful if I can't do get it going manually first. So, can that be done?

I've certainly tried to get this going for myself, but I keep encountering errors, and without a working example, or a nearby Plan 9 expert, I don't know what I'm doing wrong. I have neither of those things.

This is not urgent, it is not important, it is merely a request/suggestion. You don't owe me anything. I am thankful for the project even if the README never changes.

Thank you.

[orangecms]

related: #301 (may already help you)

To run cpud, as your Linux init, add init=/bin/cpud to your cmdline.

For passing arguments, add -- -d etc to the cmdline.

[orangecms]

To spawn as a service, see also:
https://github.com/u-root/cpu/tree/main/sysvinit

[naikrovek]

ok this raises another question I had. Why would I want to run this as the init process and not as a daemon/service?

My use case is that I'm a developer and I want to have my development environment and my debugger and all my tools with me when I cpu into a remote machine. The remote machines will otherwise be normal Linux machines.

[orangecms]

ok this raises another question I had. Why would I want to run this as the init process and not as a daemon/service?

A typical use case is having nothing but the cpu daemon - you bring everything else when cpuing via your namespace. E.g. when targeting a gadget, see my talk referenced at the bottom of the README, "Drivers From Outer Space".

My use case is that I'm a developer and I want to have my development environment and my debugger and all my tools with me when I cpu into a remote machine. The remote machines will otherwise be normal Linux machines.

Exactly that's the idea! When you cpu, through the namespace, you bring from your machine what you need on the target.

The mental model is very much the other way: You import a target and use its resources just as if they were local, e.g. in sysfs or /dev/.

Does that help? :)

Out of curiosity: How did you get to hear about / discover cpu?

[naikrovek]

Does that help? :)

Yeah, a bit. Thank you. I still don't quite understand why you'd run this as the init process but I understand it better than I did earlier.

Out of curiosity: How did you get to hear about / discover cpu?

I recently rediscovered Plan 9 and I'm legitimately angry that this per-process namespace idea didn't catch on in other operating systems. I'm angry because the operating systems available to everyone haven't done much new in 30 years, and 30 years ago that's not the situation I thought we'd be in today.

Where the hell is the innovation in modern operating systems? We're all using this paradigm that was set up in the 1960s and haven't moved past it. It really bothers me that we don't want to move past it as an industry.

So, what's someone to do? They need to do it themselves or discover a tool to make it palatable for the fat lazy masses, get used to it by using it daily, then show others, and that was my intention with cpu. I want to casually cpu into a remote machine and without any further action, have all of my local scripts, compilers, debuggers, everything with me instantly.

I truly miss when I worked in a Solaris shop and every machine I SSH'd (actually telnetted) into would mount my home directory from the NFS file server before it gave me a terminal. It was more clunky, but it did what I needed, and we've somehow lost that portable home directory over time. We've advanced but gone backwards in so many ways. Sick of it.

The entire modern computing landscape is nonsense and I'm angry because of it. I see a tiny ray of bright sunshine in this tool, and I want to use it. But, because I'm apparently quite stupid when the rubber hits the road, I can't get it working, and I'm not sure what I'm doing wrong. Rather than have someone waste their time 1-on-1 with me getting it going, I'd rather see documentation that simplifies what needs to be done for us thick skull neanderthals.

I imagine I'll be joining some Plan 9 group/foundation/fan club soon and finally learning C, or at least polishing up my Go skills enough to be useful writing tools in Plan 9. But for now, I want this tool to work.

I'd be very happy to get this working on a Linux-to-Linux situation, but I'm currently on a Mac, and that's where I ultimately want to use it from, at least at the moment.

[naikrovek]

Also, very strangely, I suspect going Windows-to-Windows with cpu would be quite useful to me, in time. I'll probably have to write that myself, but once I get my head around this tool, I should be able to do that.