sorry to disagree moddy, but we already document how to use qemu in the 9front fqa. qemu virtualized amd64 is one of the easy ways to boot up a real 9front kernel, so i wouldn't say we don't support this "target".
i'm happy to see other plan9 folks have returned to actually booting real plan9 kernels, even if it's just on a virtualized pc. if this goes on people will realize plan9 is more than just a text editor (acme) or a filesharing network protocol (9p). this is something i didn't know about until now: guestfwd=tcp:10.0.2.1:564-cmd:../sys/src/cmd/unix/u9fs/u9fs -a none -u $USER .. so, thanks. i also see no reason to reject alien scripts (bourne shell) that help create compatibility. there's no real cost. right now we maintain something like this in the fqa, which is bigger overhead (.ms formating is painful) and less directly usable (cannot be directly executed) by the user. the same cannot be said about submodules. there is significant cost for everybody who has to use repos containing submodules. On Mon, Jun 2, 2025 at 11:33 AM Jacob Moody <[email protected]> wrote: > > On 6/2/25 02:04, [email protected] wrote: > > It would be great to have that in the 9front git mirror > > (https://github.com/9front/9front <https://github.com/9front/9front>) > > The 9front git mirror is just that, a mirror of git.9front.org. > I updated stuff to have github actions for syncing largely because > the 9front github org already existed, and github is currently the easiest > way to get free on demand windows and mac hosts to build your stuff. > Since the repos existed I figured they might as well be up to date. > > The important thing to consider here is that the main 9front repo is > what we use for updating the install, our sysupdate script is a small > wrapper around git/pull. I would like to avoid adding extra things in > the repo in order to accommodate things like this, they don't really > have a place in the 9front source tree. > I would encourage someone to do this work for 9front as a separate repo; > git submodules or some scripts or whatever floats your boat for referencing > both repositories. I considered doing this myself for the 9front-in-a-box > repo, but my plate is full for the near future. > > 9front has a strong desire to dog food our own code. I think this is a pretty > important distinction between our project and many other hobbyist operating > systems. > We were lucky to inherit a lot of this from Plan 9, but further improvements > have > been done to continue this desire. We've lost count of the nasty bugs we found > by actually putting the system to use. Many of purposed improvements to the > system > come out of desires that people have when just using the system day-to-day. > There is a certain zen of Plan 9 that you don't fully grasp until you immerse > yourself in the entire picture, editors and window managers included. > > While I understand the desire to make things easier for people to bring their > own set of presumed tools with them to work on 9front, I think there is an > established history of Plan 9 rejecting that. Asking people to take off their > coat and stay a while. > > Just my two cents on the matter, I put in some thought in about this after > Russ > did this work for 9legacy. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b4ec01ec7f57dc8-M6eef868c093815645e40002a Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
