Re: [9fans] mounting fossil
I have an IDE HD with fossil (no venti) partition on it. It contains some data precious to me. I would like to mount it on a native Plan9; yes, I've RTFM, but it seems to me too brief for me to avoid (fatal) mistakes. Thus, could some nice person lead me step - by - step? Let's say your disk is named sdE1 and have a Plan 9 partition named fossil. % fossil/fossil -m 20 -f /dev/sdE1/fossil -c 'srv -AWPV fossil.other' -c 'srv -p fscons.other' Then, you can mount it: % mount /srv/fossil.other /n/fossil And to halt it: % echo fsys all sync /srv/fscons.other % echo fsys all halt /srv/fscons.other -- David du Colombier
Re: [9fans] 9atom vs 9front
On Tuesday, March 12, 2013 4:53:04 PM UTC-4, a...@9srv.net wrote: // It would be tres cool if this information was getting // mirrored in the Wiki. I've been copying over some of the more concise and complete reports, but yes: people with working setups should add their experiences there. For those who have not used the wiki, editing existing pages is pretty easy. In Acme acme on Plan 9¹, run Local 9fs wiki which will connect to the wiki and mount it at /mnt/wiki within a running acme. Next, run Wiki to launch the client, which will read the files in there and give you a much nicer interface. On the main page there, you can right-click on [Wiki index] to get a list of all the pages on the wiki. Type in your changes and execute Put in the tag when done. For details, see the pages Acme wiki instructions and Wiki syntax². Note in particular that the syntax is like a *very* minimalistic version of the sort of markdown used on many other wikis. Anthony ¹ I'm told this is doable somehow on p9p, but I don't how and can't confirm that. ² It'd be neat if someone would work out how to get the plumber to handle /mnt/wiki paths (or some conventional mapping thereof) so we could pass them around as pseudo-hotlinks. I would love to help, as I have a good install, but I have no networking.
Re: [9fans] 9atom vs 9front
On Monday, March 11, 2013 4:47:45 PM UTC-4, Matthew Veety wrote: On Mar 11, 2013, at 16:36, Bakul Shah wrote: Note: if your host uses wifi but no ethernet, bridged adapter won't work. That's card dependent. It needs to support promisc mode AFAIK. Not all cards support it. I think if I remember correctly I have gotten Linux to work under VirtualBox, without promiscuous mode -- I don't think that the network card in Mac's is capable of promiscuous mode.
Re: [9fans] 9atom vs 9front
On Monday, March 11, 2013 12:36:25 PM UTC-4, erik quanstrom wrote: Neither have a very extensive description on their homepages. hmm. what kind of description are you expecting? - erik Sorry. I guess 9atom does explain that it adds specific hardware functionality and software, but 9front on the other hand just explains that it is a fork of Plan9. Any other differences?
Re: [9fans] 9atom vs 9front
On Monday, March 11, 2013 4:56:16 PM UTC-4, Bakul Shah wrote:
On Mon, 11 Mar 2013 16:47:45 EDT Matthew Veety mve...@gmail.com wrote:
On Mar 11, 2013, at 16:36, Bakul Shah ba...@bitblocks.com wrote:
Note: if your host uses wifi but no ethernet, bridged
adapter won't work.
That's card dependent. It needs to support promisc mode AFAIK. Not all cards
support it.
Just discovered that at least on the MBP you can get bridged
mode to work by using en1: Wi-Fi (AirPort).
Really? I have the same setup as you mentioned, with Bridged Adapter, en1: Wifi
(AirPort), and Promiscuous Mode set to {Deny, Allow VMs, Allow All}, but for
each of those three options for Promsicuous mode, ip/ipconfig still times out
with ipconfig: no success with dhcp.
Re: [9fans] 9atom vs 9front
On Monday, March 11, 2013 4:36:38 PM UTC-4, Bakul Shah wrote: On Mon, 11 Mar 2013 20:50:07 BST David du Colombier wrote: I've been trying for about two days to get the stock Plan9 from Bell Labs to install with Networking under Virtual Box Bell Labs Plan 9 and networking works well in virtualbox 3.1.8 using Am79C973 virtual ethernet adapter in bridged mode, chipset PIIX3 selected and Enable IO APIC turned off. (Maybe not the only usable settings but these work for me.) Some newer versions of virtualbox have been reported as problematic. You can search for virtualbox old builds on the web. I agree with Richard and I can confirm Plan 9 works fine in VirtualBox 4.1.24 (2012-12-19). It can be downloaded here: http://download.virtualbox.org/virtualbox/4.1.24/ I too am using Bell Labs Plan9 but on 4.1.22. Settings that work for me: system: chipset PIIX3, enable IO APIC, enable PAE/NX, Enable VT-x/AMD-V, enable nested paging Storage: IDE controller, PIIX4, use host io-cache, cd-rom secondary master Network: bridged adapter, Intel Pro/1000 MT Server Ports: Enable USB controller, Enable USB2.0 controller IIRC you need to install matching virtual box extension pack for USB to work. Note: if your host uses wifi but no ethernet, bridged adapter won't work. Oh so if my laptop (host) uses Wifi for internet, then I cannot get networking to work in Plan9 under VirtualBox? I have gotten it installed, and snoopy shows packets arriving (many arps), but ip/ipconfig timeouts with ipconfig: no success with dhcp. Is there any way to use wifi or no?
Re: [9fans] Solicited VirtualBox submission (negative)
On Wednesday, March 13, 2013 11:04:03 AM UTC-4, Steffen Daode Nurpmeso wrote: Hello, VirtualBox 4.2.6 on Mac OS X does *not* work with plan9.iso: ISO 9660 CD-ROM filesystem data \ 'PLAN 9 - DEC 8 2012 04:00 ' Memory ranges: 128 - 1024 MB. Chipset: PII3X with/out I/O APIC; ICH9. With/out PAE/NX. With/out hw-virt-acceleration. Video memory: 8 - 128 MB with/out 3D acceleration. Storage controller: PIIX[34], ICH6; with/out host cache. It always enters an endless loop after the 'Plan 9' message appears. --steffen I can confirm. On 4.2.8, it hangs after the 'Plan 9' message.
Re: [9fans] Solicited VirtualBox submission (negative)
Aram Hăvărneanu ara...@mgk.ro wrote: | Does QEMU run on Mac OS X at all? | |Sure. I never got it compiled; i tried again and failed even after light configure hacking. But really, i'm happy with VirtualBox and even got Plan9 installed in the meanwhile; first made the big too disk (DOS partition that is), the second try failed to install -- at 75% i switched off and went online on the host, when i switched back i got an endless I/O errors read failed loop still at 75%, but when i reinstalled on top of that failed one turned out to be an installation-continuation instead (only hitted RETURN and yet installed data was recognized), and this time it finished just fine! |Aram Hăvărneanu --steffen
[9fans] ANTS: an attempt to bring ideas inspired by Nemo to standard Plan 9
Hi 9fans, Since I have now released what I am calling Advanced Namespace Tools, I want to offer proper credit and citation for the primary design idea in ANTS. Let me clarify that Nemo and lsub did not directly advise or contribute, but the Plan B and Octopus papers provided foundational ideas and insights which I tried to build on in ANTS. The ANTS paper does not (yet) have proper citations, and because the debt to Nemo's work is so large I want to make sure to offer proper credit to his ideas and design work. Two specific things should be cited - the first is the general principle of adapting Plan 9 design to a more dynamic and changing environment, where services may come and go without notice. Nemo has written on this topic very clearly, and in my paper written about ANTS, there are several short sections which paraphrase his ideas as I understand them. The final ANTS paper will have appropriate citations; since this theme of adapting to changes in the environment is written about in many of Nemo's papers, I'm not sure which one would be considered definitive. On the design level, the central change in ANTS - booting and not attaching to any root file descriptor - was directly inspired by section 2.2 of the Give me back my personal mainframe paper (http://lsub.org/ls/export/mainframe.pdf) about the transition from Plan B to Octopus. In this section, Nemo writes about recovering from file server crashes and switching the root file system as aspects of Plan B which he said did not work well for them, despite the attempts of the Bns program to support these things. It was when reading this section of the paper that a fairly famous sentence from original Plan 9 paper jumped into my mind: it is fair to say that the Plan 9 kernel is primarily a 9P multiplexer. it struck me that the core function of the Plan 9 kernel - multiplex 9P - did not imply that any given 9P stream had to be made more important than any other, from the kernel's point of view. The user needs a root file system to build a userspace on; once the kernel is booted, the job of the kernel is to multiplex 9P to clients, and it makes the system more reliable if the kernel itself is NOT dependent on any of the 9P streams it is multiplexing in order to continue performing that function. Because Plan 9 already was built around per process namespaces, the system already has the built in capability to host processes with any number of different roots simultaneously - couldn't this principle be used to solve the same problem that Bns was trying to solve, but in a different way? Rather than trying to do extra work to protect a particular file descriptor because the whole system depended on it, why not remove the single point of failure (one primary root fs) and instead have multiple independent roots. If one of them breaks, just switch to another one! The kernel doesn't care, it just sits back happily multiplexing 9P to clients. If one fd happens to go dead, it doesn't hurt the ability of the kernel to serve all the other 9P connections that are still alive. One of the best ways to understand ANTS is as another approach to the same issues that Nemo says Plan B did not handle successfully - problems with the root filesystem. The ANTS approach is to say if we can't protect the root filesystem, let's have multiple roots so if one breaks we have another. This means that the the ability of the kernel to do its job of multiplexing 9P to clients - and the function of the grid as a whole - is much less dependent on any external conditions. Another way to express this idea is decoupling. The Plan 9 design of per process namespace and kernel-as-9p-muxer allows us to easily decouple the construction of the user's namespace from the ability of the kernel to control the system and provide namespace to the user on demand. To put it in imperative form: The ability of the kernel to provide an environment to the users should not depend on the userspace file descriptors. The ANTS 9pcram kernel implements this design principle by creating the service namespace with no non-kernel dependencies. Understanding this is a way to summarize the big picture on ANTS: ANTS is an attempt to bring my understanding of Nemo's designs into standard Plan 9. It take a different approach than the Octopus to dealing with the issues which Nemo described in Plan B. Also, I would like to say that Nemo and the lsub are much more skilled programmers and their projects are much more sophisticated and technically challenging than what I implemented for ANTS. ANTS tries to bring a simple subset of the lsub concepts to the main Plan 9 from Bell Labs distribution, to help make standard grids more reliable and easier to administer. Because my debt to Nemo's ideas for what I was trying to do with ANTS is so large, I wanted to offer this statement of credit and great thanks for his extensive work on Plan 9, and I hope the Giant ANTS are a welcome addition to the growing
Re: [9fans] 9atom vs 9front
On Thu Mar 14 09:06:51 EDT 2013, 23h...@gmail.com wrote: the difference about 9front is that it also works on real hardware, so you don't need to mess with these VMs. i think you misspelled similarity. i'm sure you can point to some instances of hardware not working in plan 9 and working in 9front. that's fine. but if i understand correctly, 9front has taken the decision to not send in patches. that's totally fine in my book. but it seems a little less than helpful to not send patches and then criticize. - erik
[9fans] Acme hack
I like my +Errors window clean once in a while. Attached patch provides
Edit ,d
by default in +Errors window tagline.
--
dexen deVries
[[[↓][→]]]
From b4edef7c40de4c4a8678622e11eee8bd9aef8523 Mon Sep 17 00:00:00 2001
From: dexen deVries dexen.devr...@gmail.com
Date: Thu, 14 Mar 2013 14:41:22 +0100
Subject: [PATCH] acme: provide Edit ,d in +Error windows
---
src/cmd/acme/wind.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/cmd/acme/wind.c b/src/cmd/acme/wind.c
index d2bec16..5e952ed 100644
--- a/src/cmd/acme/wind.c
+++ b/src/cmd/acme/wind.c
@@ -451,6 +451,7 @@ winsettag1(Window *w)
static Rune Lget[] = { ' ', 'G', 'e', 't', 0 };
static Rune Lput[] = { ' ', 'P', 'u', 't', 0 };
static Rune Llook[] = { ' ', 'L', 'o', 'o', 'k', ' ', 0 };
+ static Rune Leditcomad[] = { ' ', 'E', 'd', 'i', 't', ' ', ',', 'd', 0 };
static Rune Lpipe[] = { ' ', '|', 0 };
/* there are races that get us here with stuff in the tag cache, so we take extra care to sync it */
@@ -509,6 +510,10 @@ winsettag1(Window *w)
runemove(new+i, Llook, 6);
i += 6;
}
+ else if (!w-filemenu){
+runemove(new+i, Leditcomad, 8);
+i += 8;
+ }
else{
static Rune foo[] = { ' ', 0 };
runemove(new+i, foo, 1);
--
1.8.1.4
Re: [9fans] 9atom vs 9front
On Thu, Mar 14, 2013 at 09:38:26AM -0400, erik quanstrom wrote: On Thu Mar 14 09:06:51 EDT 2013, 23h...@gmail.com wrote: the difference about 9front is that it also works on real hardware, so you don't need to mess with these VMs. i think you misspelled similarity. i'm sure you can point to some instances of hardware not working in plan 9 and working in 9front. that's fine. but if i understand correctly, 9front has taken the decision to not send in patches. that's totally fine in my book. but it seems a little less than helpful to not send patches and then criticize. - erik All of 9front is public in the hg repository. Not sure what the value is in sending in patches of stuff we wrote because we wanted it, and not necessarily to solve some larger problem. If anyone wants the code, he can just take it. I don't think hiro was criticizing 9front as much as the fact that 9fans seems to discuss p9p and vbox on osx more than any other software. khm
Re: [9fans] mounting fossil
// I have an IDE HD with fossil (no venti) partition on it. // It contains some data precious to me. David's already provided good instructions on dealing with your immediate problem, but allow me to take a step back: Don't do that! Fossil, without venti, is not the stablest thing around. I would very strongly recommend against putting precious data on it. I've had it go wonky personally, and there've been plenty of similar reports here. In my experience, it's particularly vulnerable to unclean shutdown, but I've seen more difficult-to-explain issues, too. With venti, it's great: the snapshotting capabilties are very nice, venti's very solid, and if your fossil does get out of whack, it's trivial to re-initialize it from a known-good state from venti. Anthony
Re: [9fans] Acme hack
On 14 March 2013 14:44, dexen deVries dexen.devr...@gmail.com wrote: I like my +Errors window clean once in a while. Attached patch provides Edit ,d by default in +Errors window tagline. Not that I have any problem with this but, isn't it easier to just Del the window so that a new one is created when you need it? -- - yiyus || JGL .
Re: [9fans] Acme hack
On Thursday 14 of March 2013 15:38:08 yy wrote:
Not that I have any problem with this but, isn't it easier to just Del the
window so that a new one is created when you need it?
you are right. i use Edit ,d to preserve general window layout.
i'm not happy with Acme's placement of +Errors window in my default workflow.
in two columns, i keep one directory (project root) window, one +Errors window
beneath it (syntax errors, upload progress †, scratchpad) and some 1...6
source code file windows spread 'round.
btw., the patch may not apply cleanly since my p9p fork has `Look' disabled
via if(0) {...}
--
dexen deVries
[[[↓][→]]]
† i'm a LAMP webdeveloper by day.
Re: [9fans] mounting fossil
Thanks for warning! However, I reorganize my data very often, moving between dirs, renaming, reorganising tree structure... How will Venti cope with this? Fopr now, I plan to put the data onto an ext2 partition for now, until I feel the dir tree is well-designed. I just want to mount the fossil partition and copy the data out of there. Thanks, best, ++pac On Thu, Mar 14, 2013 at 3:23 PM, a...@9srv.net wrote: // I have an IDE HD with fossil (no venti) partition on it. // It contains some data precious to me. David's already provided good instructions on dealing with your immediate problem, but allow me to take a step back: Don't do that! Fossil, without venti, is not the stablest thing around. I would very strongly recommend against putting precious data on it. I've had it go wonky personally, and there've been plenty of similar reports here. In my experience, it's particularly vulnerable to unclean shutdown, but I've seen more difficult-to-explain issues, too. With venti, it's great: the snapshotting capabilties are very nice, venti's very solid, and if your fossil does get out of whack, it's trivial to re-initialize it from a known-good state from venti. Anthony
Re: [9fans] mounting fossil
I reorganize my data very often, moving between dirs, renaming, reorganising tree structure... How will Venti cope with this? Well. Venti does block-level deduplication. If you have 100 MB of data in dir A and move it to dir B, you're not going to duplicate that storage (you'll get new blocks for the directory, of course, but that's both minimal and unavoidable). Anthony
Re: [9fans] 9atom vs 9front
On Mar 14, 2013, at 11:43, Kyle Laracey kalara...@gmail.com wrote:
On Monday, March 11, 2013 4:56:16 PM UTC-4, Bakul Shah wrote:
On Mon, 11 Mar 2013 16:47:45 EDT Matthew Veety mve...@gmail.com wrote:
On Mar 11, 2013, at 16:36, Bakul Shah ba...@bitblocks.com wrote:
Note: if your host uses wifi but no ethernet, bridged
adapter won't work.
That's card dependent. It needs to support promisc mode AFAIK. Not all cards
support it.
Just discovered that at least on the MBP you can get bridged
mode to work by using en1: Wi-Fi (AirPort).
Really? I have the same setup as you mentioned, with Bridged Adapter, en1:
Wifi (AirPort), and Promiscuous Mode set to {Deny, Allow VMs, Allow All}, but
for each of those three options for Promsicuous mode, ip/ipconfig still times
out with ipconfig: no success with dhcp.
So the card itself needs to support it. The little promisc thing in vbox
doesn't really do shit if your card doesn't support it.
Also try setting the ip and other net info manually.
[9fans] 9front Acme unresponsive to key presses
Kurt H Maier kh...@intma.in wrote: |I don't think hiro was criticizing 9front as much as the fact that 9fans |seems to discuss p9p and vbox on osx more than any other software. I also installed 9front in the meanwhile (python, pfff), and learned that the (broken) hostname setup can be skipped during installation, and how easy it is to set the german keyboard layout! That is really great (and it would be so easy to adjust it as necessary!) design! Acme in 9front doesn't respond to keypresses and starts hanging around; i'd have a (rather useless though) 13997 bytes screenshot of what happens on the controlling tty during this, in case noone else has seen this and the behaviour is of interest -- it's just that you place the cursor, hold down a key, and nothing visual happens, but at times something comes back and then it seems as if something has been queued somewhere, but not necessarily the key that has been pressed (in fact the screenshot shows bad character in filename, which *definitely* not happened). But maybe it's VM related anyway, which might be true since i had to turn to VESA which is not needed for Plan9 from Bell Lapps, which also doesn't show the mentioned behaviour. |khm --steffen
Re: [9fans] 9atom vs 9front
On Mar 14, 2013, at 6:05 AM, hiro 23h...@gmail.com wrote: the difference about 9front is that it also works on real hardware, so you don't need to mess with these VMs. A VM is far more convenient and portable for me.
Re: [9fans] 9atom vs 9front
On Mar 14, 2013, at 4:43 AM, Kyle Laracey wrote:
On Monday, March 11, 2013 4:56:16 PM UTC-4, Bakul Shah wrote:
Just discovered that at least on the MBP you can get bridged
mode to work by using en1: Wi-Fi (AirPort).
Really? I have the same setup as you mentioned, with Bridged Adapter, en1:
Wifi (AirPort), and Promiscuous Mode set to {Deny, Allow VMs, Allow All}, but
for each of those three options for Promsicuous mode, ip/ipconfig still times
out with ipconfig: no success with dhcp.
This works for me on the last 2011 model (the one before the
Retina display MBPs) and it works on a 6 year old MBP. Your
problem may be card dependent as Matthew says or it may be
some config issue. Try debugging with tcpdump on the host. See
if DHCP provides a working IP address for other VMs (Linux for
instance) on the same laptop when connected via en1. See if
manually setting the IP address allows you use the net.
