Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, 22 May 2014 07:36:54 +0200 lu...@proxima.alt.za wrote:
Though the idea of a scmfs (for checkins as well) and using
vac/venti as a backend is starting to appeal to me : )
Let's open the discussion, Plan 9 has some baseline tools other OSes
are still thinking about and will probably implement stupidly. Since
RCS I've been thinking that there has to be a better way and CVS went
a long way to satisfy my personal requirements. Now may well be the
time to look at fresher options.
I am attaching an excerpt from an old email (May 26, 2011)
that I never sent. These ideas are not even half baked. But
may be they will trigger some creative thoughts.
On Thu, 26 May 2011 20:16:11 EDT erik quanstrom quans...@quanstro.net wrote:
file servers are great, but hg concepts aren't really file-system oriented.
it might be nice to be able to
diff -c (default mybranch)^/sys/src/9/pc/mp.c
but hg diff figures out all the alloying stuff, like the top-level of the
repo anyway. also, ideas like push, pull, update, etc., don't map very well.
so a hg file server seems to me a bit like, have hammer, see nail.
I thik the filesystem model is more like an electric motor
that powers all sorts of things given the right attachments!
if i'm missing why this is an interesting idea, i'd love to know what
i don't see.
I partially agree with you; hence the suggestion about editor
integration.
It is just that I have wondering about just how far the FS
model can be pushed or extended seamlessly in various
directions.
In the context of SCMs, we can map a specific file version to
one specific path -- this is what hgfs above does. But what
about push/pull/commit etc.? One idea is to to map them to
operations on magic files.
For example,
- local file copies appear as normal files.
- cat .hg/status == hg status
- cat .hg/commit == hg commit
- cat .hg/log == hg log
- echo -a .hg/revert == hg revert -a
- echo $url .hg/push == hg push $url
- echo $url .hg/pull == hg push -u $url
- ls .hg/help
- cat .hg/help/push
In fact the backend SCM need not be mercurial; it can git,
venti etc. Can we come up with a minimal set of features?
Do we gain anything by mapping $SCM commands to special files?
The same question can be asked about many of existing plan9
filesystems. At least for me visualizing new uses is easier
when more things can be fitted in a simpler model.
Features such as atomic commits, changesets, branches, push,
pull, merge etc. can be useful in multiple contexts so it
would be nice if they can integrated smoothly in an FS.
Example uses:
- A backup is nothing but a previous commit. A nightly
backup cron job to do echo `{date} .commit
- an offsite backup is a `push'.
- Initial system install is like a clone.
- An OS upgrade is like a pull.
- Installing a package is like a pull (or if you built it
locally, a commit)
- Uinstall is reverting the change.
- Each machine's config can be in its own branch.
- You can use clone to create sandboxes.
- A commit makes your private temp view permanent and
potentially visible to others.
- Conversely old commits can be spilled to a backup
media (current SCMs want the entire history online).
- Without needing a permanent connection you can `pull' data.
[never have to do `9fs sources; ls /n/sources/contrib'.]
A better integration can inspire new uses:
- a timemachine like a gui can help quickly scroll through
changes in some file (or even a bird's eye view of changes
in all the files).
- combining versioning + auto push/pull with other filesystems
can open up new uses. You can keep your own daily archive of
http://nyt.com/ or see how a story develops by scrolling through
changes.
Just some things I was mulling about. As you can see there are
lots of open questions half-baked ideas to sort through.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
I am attaching an excerpt from an old email (May 26, 2011) that I never sent. These ideas are not even half baked. But may be they will trigger some creative thoughts. I was hoping for this type of interest, I'm very pleasantly surprised that it now seems to be materialising. I guess I'll need to track this discussion on google groups now, ACME mail is a bit limited in this regard (and probably also needs to be enhanced both for discussions like this one and for code review purposes), L += 1
[9fans] hgfs
i'm playing with hgfs. here are some first observations/thoughts. for a given repository foo, if the repository mounted on /n/hg, had a hierarchy like: /n/hg /ctl /versions /foo it would feel more natural if i could do: % cat /n/hg/versions # list versions ... % echo version rev1 /n/hg/ctl # pull + update -r rev1, etc. % ls /n/hg/foo # list of rev1 files % echo version rev2 /n/hg/ctl % ls /n/hg/foo ... # list of rev2 files, etc % ed /n/hg/foo/main.c 'EOF' $a // a useless comment . w q EOF % cat 'EOF' /n/hg/ctl tag rev1beta1 # tag this version note added a silly comment to main.c and tagged this version as beta1 # commit string? push # push the changes upstream, etc. EOF etc. it would be nice to map as many hg/git operations to file operations as possible. for the rest providing special files (ctl, versions, etc) and directives don't seem out of place.
Re: [9fans] hgfs
it would be nice to map as many hg/git operations to file operations as
possible. for the rest providing special files (ctl, versions, etc) and
directives don't seem out of place.
I've been thinking about combining synthetic file servers with shell
functionality, where Plan 9's rc (but possibly other shells, if
necessary) are initialised with a suite of commands, some of which,
like functions, will come from the namespace, while others will be
provided by a bind over /bin from the appropriate, fabricated
namespace.
I guess, in a way, this an extension of the concept used in busybox.
The idea then would be to start up a shell environment (not unlike
ape/psh) and navigate within it with conventional commands being
mapped to the appropriate procedures automatically.
I know this is a bit obscure, but I think a few examples attached to
something like hgfs (which I have steered clear of because of my
aversion to having Python in Plan 9 - I plead guilty to bigotism)
would explain things somewhat.
The nearest I've come to implementing some of these ideas, is an rc
startup script I wrote to access the OpenLDAP client commands. I use
it infrequently, but it does save me a lot of bother when I do.
The script, attached, is in turn invoked in a smaller, private script
(I call it $home/bin/rc/Ldap):
#!/bin/rc
window rc -m rcldap
L += 1
# rcmain for LDAP shell instance
if(~ $#home 0) home=/
if(~ $#ifs 0) ifs='
'
prompt=('ldap% ' ' ')
echo -n LDAP /dev/label
if(~ $rcname ?.out) prompt=('broken! ' '')
if(flag p) path=/bin
if not{
finit
if(~ $#path 0) path=(. /bin)
}
test -d /n/ldap -a -d /n/ldap/bin || {
ramfs -m /n/ldap
mkdir /n/ldap/bin /n/ldap/tmp
for (x in add search delete modify modrdn compare passwd whoami) {
touch /n/ldap/bin/$x
test -e /$objtype/bin/pub/ldap^$x bind
/$objtype/bin/pub/ldap^$x /n/ldap/bin/$x
}
bind /$objtype/bin/pub/ldapmodify /n/ldap/bin/add
bind -b /n/ldap/bin /bin
}
test -f $home/lib/ldaprc . $home/lib/ldaprc
fn ep {
echo -n $1^' = ' | tr a-z A-Z
test -e '#e/'^$1 cat '#e/'^$1
echo ''
}
fn e {
ep admin
ep attrib
ep base
ep binddn
ep filter
ep host
ep opts
ep scope
}
fn s {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#binddn 0) arg=($arg -D^$binddn)
if(! ~ $#base 0)arg=($arg -b^$base)
if(! ~ $#scope 0) arg=($arg -s^$scope)
if(! ~ $#opts 0)arg=($arg $opts)
if(! ~ $#filter 0) arg=($arg $filter)
if(! ~ $#attrib 0) arg=($arg $attrib)
if(flag x) echo search $arg $*
search $arg $*
}
fn a {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0) arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x) echo add -a $arg
add -a $arg
}
fn m {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0) arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x) echo modify $arg
modify $arg
}
fn d {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(! ~ $#admin 0) arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(flag x) echo delete $arg $*
delete $arg $*
}
fn p {
if(~ $#* 0){
filter='(objectclass=person)'}
if not {
filter='((objectclass=person)(cn='^$*^'))'}
if(~ $#attrib 1){
filter='('^$filter^'('^$attrib(1)^'=*))'
}
s
}
fn enhance {
arg=()
if(! ~ $#host 0)arg=($arg -h^$host)
if(~ $#admin 0){
if(! ~ $#binddn 0) arg=($arg -D^$binddn)
}
if not arg=($arg -D^$admin)
if(! ~ $#opts 0)arg=($arg $opts)
if(! ~ $#* 0){
dn=$1; shift
}
if(! ~ $#* 0){
attrib=$1; shift
}
if(flag x)echo modify $arg
if(! ~ $#dn 0){
if(flag x){
echo dn: $dn
echo changetype: modify
echo add: $attrib
echo $attrib: $*
echo
}
{
echo dn: $dn
echo changetype: modify
echo add: $attrib
echo $attrib: $*
echo
} | modify $arg
}
if not modify $arg
}
if(! ~ $#cflag 0){
if(flag l /bin/test -r $home/lib/profile) . $home/lib/profile
status=''
eval $cflag
}
if not if(flag i){
if(flag l /bin/test -r $home/lib/profile) . $home/lib/profile
status=''
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Hi Shane, I just tried an installation from scratch of 9atom - downloaded the ISO from Quanstro.net, installed on VirtualBox 4.3.12 on Mavericks 10.9.3 accepting the defaults as far as possible. It all installed fine and booted fine. I've not had time to setup networking etc. but it certainly doesn't hang as you describe. I have noticed that the 'default install' doesn't seem to work if installing on a virtual hard disk that already has plan9 on it (in my case installing 9atom over the labs version, it didn't seem to actually do anything and booted back to the labs distro) . Did you start from a fresh HD this time? I can send you my 9atom.vbox (the XML config file) separately if you want. Pete On Thu, May 22, 2014 at 2:17 AM, Shane Morris edgecombe...@gmail.com wrote: Hi 9fans, I am running the latest VirtualBox on the latest Mavericks, and after an install of 9atom, go to run the resulting image, and execution stops at the /bin/rc command, just before entry into Rio. I noticed this same problem on my Macbook Air on 10.8 - I thought I had just botched my previous image, it appears not. All settings should be correct to what the pertinent blogs say the settings should be (ie, IDE hard drive, 1000MT Server network card, etc). Any help, criticism, explanations, etc, are most welcome! Shane.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Wednesday, May 21, 2014, Jeff Sickel j...@corpus-callosum.com wrote: Git is the closest as it’s just C, sort of: it’s a whole lot of code. But why would you want to bring in “178K lines of *.[ch], 20K lines of shell scripts, 100K+ lines of test scripts” and have to lug in the massive payload of Python and Perl just to make it functional? In case anyone is _really determined_ to do this: libgit2 has only 117K lines of code, better than git's 178K. It also has a mere 200 lines of shell, total. It doesn't depend on Python or Perl. It's also supposed to be much more portable than git, though I dunno if that would actually work out for Plan 9. Probably not that much. You could try porting libgit2 and then write some small C wrappers using it.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, May 22, 2014 at 7:36 AM, lu...@proxima.alt.za wrote: (I dislike that Go comes with C compilers and assemblers that seem to be heading off into the hills - our little group of Go porters (please forgive me for presuming) ought to be addressing this issue as well) What issues? What are you talking about? -- Aram Hăvărneanu
Re: [9fans] hgfs
On Thu, May 22, 2014 at 9:36 AM, lu...@proxima.alt.za wrote: ... It would be nice if you didn't hijack other people's threads. -- Aram Hăvărneanu
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
What are you talking about? Merely that it would be nice if 8c on Plan 9 was the same utility, whether Go is installed or isn't. I'm not expecting it to just happen, but I do think it would be better than what we have now. L.
Re: [9fans] hgfs
It would be nice if you didn't hijack other people's threads. Oh, dear, I apologise! L.
Re: [9fans] hgfs
Skip Tavakkolian skip.tavakkol...@gmail.com wrote: % cat /n/hg/versions # list versions ... % echo version rev1 /n/hg/ctl # pull + update -r rev1, etc. % ls /n/hg/foo # list of rev1 files % echo version rev2 /n/hg/ctl % ls /n/hg/foo ... # list of rev2 files, etc What would be the point of this? Once you have a version (revision) you can just bind the subtree where you want it. I don't see the point in having this special switching code inside hgfs. Plan 9 provides the necessary functionality. % ed /n/hg/foo/main.c 'EOF' $a // a useless comment . w q EOF % cat 'EOF' /n/hg/ctl tag rev1beta1 # tag this version note added a silly comment to main.c and tagged this version as beta1 # commit string? Somebody would have to write the code, right now hgfs is read-only. I don't know how hard it would be. Are you offering? -- Aram Hăvărneanu
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Merely that it would be nice if 8c on Plan 9 was the same utility, whether Go is installed or isn't. I'm not expecting it to just happen, but I do think it would be better than what we have now. And what would be the benefit of that? Plan 9's 8c and Go's 8c are different programs. Different calling conventions, different output. Right now Go's 8c uses liblink and generates machine code. .8 files cannot be consumed by Plan 9's 8l. Even before liblink there were serious incompatibilities in the object files. 8c is going away soon anyway, after 8g is rewritten in Go. -- Aram Hăvărneanu
Re: [9fans] syscall 53
I submit not having a proper DVCS is part of the problem for this. The reason github is so successful is because it is so easy to upload code and then to collaborate, get bug fixes etc. While some incomplete code in one's own src tree may not get looked at for a long time and ultimately may never see the light of the day. Github should use the slogan it doesn't /have/ to be ready for the world to see!. You are mistaken, nobody prevents people from putting stuff on sources, and nobody forces people to git push. In every case people have to decide whether to share something or not. -- Aram Hăvărneanu
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Why do people insist on VirtualBox? How many times it has to be said. VirtualBox is utter shite. QEMU and VMware work. QEMU is especially interesting because it can work without a broken kernel driver (although it can use kvm, a good kernel driver on Linux). -- Aram Hăvărneanu
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Aram Hăvărneanu I don’t know who you are but you seem to be in a very bad mood today. From: Aram Hăvărneanu Sent: Thursday, 22 May 2014 11:54 To: Fans of the OS Plan 9 from Bell Labs Why do people insist on VirtualBox? How many times it has to be said. VirtualBox is utter shite. QEMU and VMware work. QEMU is especially interesting because it can work without a broken kernel driver (although it can use kvm, a good kernel driver on Linux). -- Aram Hăvărneanu
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Features such as atomic commits, changesets, branches, push, pull, merge etc. can be useful in multiple contexts so it would be nice if they can integrated smoothly in an FS. - Installing a package is like a pull (or if you built it locally, a commit) - Uinstall is reverting the change. - Each machine's config can be in its own branch. what is the advantage over seperate files? imo, this complicates the issue. - You can use clone to create sandboxes. - A commit makes your private temp view permanent and potentially visible to others. - Conversely old commits can be spilled to a backup media (current SCMs want the entire history online). - Without needing a permanent connection you can `pull' data. [never have to do `9fs sources; ls /n/sources/contrib'.] this is a nice list, but i think a key point is not being teased out. the dump file systems are linear. there is a full order of system archives. in hg, there is a full order of the tip, but not so of branches in general. in git, multiple orders (not sure if they're full or not) can be imposed on a set of hashes. another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. - erik
[9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
I would throw in a vote in favor of a good git client. It's something I use daily and I find it works well with distributed people working on the same project. Which is a situation Linux and plan9 share. Last time I looked at how it was put together the 'core' was actually just a small handful of commands most of which where implementing the content addressed filesystem (that git essentially is). All the other commands just built on top of those basic ones to implement handy features or more user friendly-ness. As suggested above I also think git should fit reasonably well with plan9's filesystem interface. To continue throwing out half-baked ideas. I would envision something like: cp /usr/glenda/myproject /n/git/staging ##Add project files to staging echo Add new feature X /n/git/commit ###Commit staging directory with message cat /n/git/log # view all logs echo 34nb432 /n/git/log ###Tell it you want to read log 34nb... cat /n/git/log ###Reads out log selected with previous command echo my-git-repo.example.com:HEAD /n/git/pull ###Pull changes from online repo Of course, as git just wants another .git directory that could just as easily be echo /n/sources /n/git/pull ###Pull changes to sources If it was decided that someone might like to try to port git I'd imagine you could just port the basic boiler plate commands, and a few higher level ones, ignoring the fancy util commands like bisect that are unlikely to be needed often and tackle those as-needed. But that comment could stand some verification. http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain is an interesting read if anyone is interested.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
More seriously, though, on the issue of revision control on Plan 9 (and code review, that being the really important aspect) I'd like us to keep in mind that being able to interface with existing repositories, difficult as it may be, would be greatly beneficial. To like i said, a hg gateway hosted on google code or whatever is for me welcome, but that's not my top priority. if it is your top priority, then go to it. if you need some system changes, submit patches. if they're invasive, it might be good to discuss the plan first in public. - erik
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On Thu May 22 06:55:44 EDT 2014, ara...@mgk.ro wrote: Why do people insist on VirtualBox? How many times it has to be said. VirtualBox is utter shite. QEMU and VMware work. QEMU is especially interesting because it can work without a broken kernel driver (although it can use kvm, a good kernel driver on Linux). because they're using osx, and don't want to shell out for vmware. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
That said, let me add my encouragement to sample apatch as suggested by Erik, although any valid objections ought to be raised here. One, from me, comes from Erik himself a modified version of Nemo's (a)patch (I don't have the exact quote handy. Nemo, could we please start this exercise with one, and only one version of this? the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. - erik
Re: [9fans] VirtualBox, Mavericks, and Plan 9
because they're using osx, and don't want to shell out for vmware. QEMU works on OS X. -- Aram Hăvărneanu
Re: [9fans] syscall 53
With all respect due to you and Mr Coraid (don't make mne look his Coile. - erik
Re: [9fans] syscall 53
Is this the right place to discuss the actual procedure to include apatch in one's private Bell Labs' distribution? Is it preferable to use apatch within 9atom, or is it reasonably portable to the legacy (I presume that is what David intends with that moniker) distribution? apatch is as specialized as patch in that it creates patches against the current 9atom tree. patch is still there, and i often generate parallel patches for both 9atom and sources. as long as your source hasn't drifted wrt the atom tree, you can send an apatch from a 9atom, hybride or standard tree. Is there a willing participant who is prepared to offer backing storage for the target distribution(s) even when he or she disagrees with the outcome? (And be vociferous both about disagreeing and accepting the outcome?) David, you've been good that way, are there others? I'd like to think that we can leverage Plan 9's distributable properties to have more than one? I'd like to offer this myself, but I live at the bottom of an Internet gravity well, anyone with sufficient patience is welcome to approach me. you are aware that you can mount the 9atom sources directly these days? nflag=-n srv $nflag -q tcp!atom.9atom.org atom /n/atom atom # add to 9fs - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
Go is in a different league: Heretical as it may seem, we can generate Go binaries without compelling all Plan 9 installations to include the Go toolchain, no matter how valuable some of us may perceive it. HG without Python is a dead rat. that's a partially binary distribution. a proper, full, distribution would have the same issue. and go introduces new issues, it's much more in flux than python. the risk is that a go update could then break the system. and only runs on 386. it does not run on plan 9 mips, arm, or amd64. - erik
Re: [9fans] syscall 53
you are aware that you can mount the 9atom sources directly these days? Sure, but then I'd have to commit harakiri as self-immolation is the only avenue left to appease the Internet gods in the tip of Africa :-) Still, I'll keep that in mind for occasional experimentation. More seriously, we do need to start with a benchmark distribution that everybody can buy into. Maybe the right idea is to compute the intersection of common sources for BL, 9atom, 9front, NmX et al. and try to shoehorn more into that framework. Or maybe start with nothing and build from there, one patch at the time? What makes sense here? There has to be some starting point. Maybe the non-existent unreleased source? L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. Out of curiosity, what prompted not using CVS? I can think of a number of reasons, but none that echo with your comments up to now. L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
and go introduces new issues, it's much more in flux than python. the risk is that a go update could then break the system. and only runs on 386. it does not run on plan 9 mips, arm, or amd64. These are very valid reservations, I hadn't thought of them. L.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu May 22 09:45:08 EDT 2014, lu...@proxima.alt.za wrote: the original version is, as far as i know, no longer in use. i only mentioned the lineage to credit nemo with the work. Out of curiosity, what prompted not using CVS? I can think of a number of reasons, but none that echo with your comments up to now. cvs wasn't considered because it's not appropriate. the 9atom model is single committer. very much like linus' model. - erik
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On May 22, 2014, at 8:05 AM, Aram Hăvărneanu ara...@mgk.ro wrote: because they're using osx, and don't want to shell out for vmware. QEMU works on OS X. If by ‘works’ you mean the an ancient version that doesn’t really run well on OS X 10.9.x, then sure. So far, I’ve not gotten a version of qemu to build on OS X that would support Plan 9 or any other OS I’m interesting in testing. -jas
Re: [9fans] VirtualBox, Mavericks, and Plan 9
If by ‘works’ you mean the an ancient version that doesn’t really run well on OS X 10.9.x, then sure. So far, I’ve not gotten a version of qemu to build on OS X that would support Plan 9 or any other OS I’m interesting in testing. I have both 1.6.1 and 2.0 on 10.9 (the latest). 1.6.1 is not ancient and I didn't even need to compile it. Plan 9 runs just fine. 2.0 I compiled because I needed the new arm64 support. It wasn't hard. -- Aram Hăvărneanu
Re: [9fans] VirtualBox, Mavericks, and Plan 9
➜ ~ brew info qemu qemu: stable 2.0.0, HEAD http://www.qemu.org/ /usr/local/Cellar/qemu/1.5.1 (114 files, 90M) Built from source /usr/local/Cellar/qemu/2.0.0_1 (120 files, 98M) * Built from source From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/qemu.rb == Dependencies Build: pkg-config ✔, libtool ✔ Required: jpeg ✔, gnutls ✔, glib ✔, pixman ✔ Optional: vde ✘, sdl ✘ == Options --with-sdl Build with sdl support --with-vde Build with vde support --HEAD install HEAD version On Thu, May 22, 2014 at 4:34 PM, Jeff Sickel j...@corpus-callosum.comwrote: On May 22, 2014, at 9:12 AM, Aram Hăvărneanu ara...@mgk.ro wrote: I have both 1.6.1 and 2.0 on 10.9 (the latest). 1.6.1 is not ancient and I didn't even need to compile it. Plan 9 runs just fine. 2.0 I compiled because I needed the new arm64 support. It wasn't hard. What’s your Mac OS X build environment? Are you using some ports tree to get all the dependencies required by qemu? A stock OS X 10.9.3 with Xcode (with clang et al) won’t build qemu because, well, … it doesn’t build. -jas
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On May 22, 2014, at 9:39 AM, Rubén Berenguel ru...@mostlymaths.net wrote: From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/qemu.rb Ah, ruby, yet another technology I have zero use for on my systems. -jas
Re: [9fans] VirtualBox, Mavericks, and Plan 9
It's homebrew, a package repository for OS X. OS X already comes with a ruby interpreter anyway. And this allows anyone to compile from source qemu 2.0.0 without much fuss. On Thu, May 22, 2014 at 4:44 PM, Jeff Sickel j...@corpus-callosum.comwrote: On May 22, 2014, at 9:39 AM, Rubén Berenguel ru...@mostlymaths.net wrote: From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/qemu.rb Ah, ruby, yet another technology I have zero use for on my systems. -jas
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On May 22, 2014, at 9:44 AM, Jeff Sickel j...@corpus-callosum.com wrote: On May 22, 2014, at 9:39 AM, Rubén Berenguel ru...@mostlymaths.net wrote: From: https://github.com/Homebrew/homebrew/commits/master/Library/Formula/qemu.rb Ah, ruby, yet another technology I have zero use for on my systems. And the link returns: Sorry, this commit history is taking too long to generate. -jas
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Ah, ruby, yet another technology I have zero use for on my systems. That technology is already installed on your system. -- Aram Hăvărneanu
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On May 22, 2014, at 9:49 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Ah, ruby, yet another technology I have zero use for on my systems. That technology is already installed on your system. And not used. Wasted bits on the ssd. http://hadihariri.com/2014/04/21/build-make-no-more/
Re: [9fans] hgfs
On Thu, May 22, 2014 at 3:41 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Skip Tavakkolian skip.tavakkol...@gmail.com wrote: % cat /n/hg/versions # list versions ... % echo version rev1 /n/hg/ctl # pull + update -r rev1, etc. % ls /n/hg/foo # list of rev1 files % echo version rev2 /n/hg/ctl % ls /n/hg/foo ... # list of rev2 files, etc What would be the point of this? Once you have a version (revision) you can just bind the subtree where you want it. I don't see the point in having this special switching code inside hgfs. Plan 9 provides the necessary functionality. true, but now you'd have to have another layer of scripts, etc. why not just make it look the way it should? % ed /n/hg/foo/main.c 'EOF' $a // a useless comment . w q EOF % cat 'EOF' /n/hg/ctl tag rev1beta1 # tag this version note added a silly comment to main.c and tagged this version as beta1 # commit string? Somebody would have to write the code, right now hgfs is read-only. I don't know how hard it would be. Are you offering? i've been thinking about this (as obviously others have been too -- see Bakul's post on another thread), but since i don't have enough rope at the moment to fathom the depths of hg and git, i'm offering it for comment or dare :) -Skip -- Aram Hăvărneanu
Re: [9fans] hgfs
thinking about the idea of a revision control file system brings me back to some work i followed by brian stuart. his θfs has a object store. the object store allows arbitrary metadata and object size. the ℙ snapshot device could be modified to take snapshots based on an arbitrary reference point, rather than the last snapshot. so in theory all the bits are there, they would just need to be put together in a different way. fun little thing to think about. in any event, back to the subject at hand. this in-depth discussion of various revision control systems seems to assume that revision control is the key issue. i have seen plan 9-derived projects fail using codereview and google code because there wasn't a shared goal. so i would identify it as the key issue the goal is strategy, revision control is tactics. instead of a goal or vision, perhaps values are more down to earth. for example, a common value for kernel folks is never break user land. let me propose this draft. 1. keep with the original value system of plan 9: e.g. simple implementation of advanced techniques, self-contained, avoid configuration, use mechanism such as namespaces instead. 2. run on as many systems as practical. do not break compatability without specific articulated reasons. 3. all changes are up for debate, but there is a clear path to decision making. - erik
Re: [9fans] syscall 53
Quoting lu...@proxima.alt.za: Obvious, good grounds for a conspiracy theory. Such code simply does not exist, no matter how much you harp on it. Next thing, you'll insist I need to prove that it does not exist, putting you squarely in the Creationists camp. I don't need anyone to prove anything; I just need them to stop pretending anyone gives a crap about e.g. 9front except 9front users. 9front is not some kind of 'mission'; it's there because it serves our needs well. For the record, hgfs does not depend on python. It's currently read-only but can be extended easily, in C. It works within existing plan 9 paradigms and is one project I'm very excited to watch. git offers nothing hg does not offer. hg is already present and working on my systems. I do not now have, and do not foresee ever having, any desire or need to use git on plan 9. The only real reason people keep braying about it is their habits on other operating systems. (BTW: do not believe everything South African expatriates have to say.) How about I pretend you didn't just call my wife a liar (a priori and for absolutely no reason, to boot), and you stop pretending you have any insight into her motivations and decision-making processes? Thanks in advance. khm
Re: [9fans] hgfs
has anyone looked at camlistore as a starting point? Written in Go, which means it works on Plan 9. ron
Re: [9fans] hgfs
Quoting ron minnich rminn...@gmail.com: has anyone looked at camlistore as a starting point? Written in Go, which means it works on Plan 9. That means it works on *one architecture* of Plan 9. khm
Re: [9fans] hgfs
in any event, back to the subject at hand. this in-depth discussion of various revision control systems seems to assume that revision control is the key issue. Much as I agree with you that clear objectives are essential to any type of success (a tautology if ever there was one - what do you measure success against, if the objectives aren't clear?), it was the code review bit that I perceived as an obstacle. But you're right, and your objectives make a fine starting point. They ought to attract discussion, though, as they seem to me a little too specialised (?). I want a little time to ponder over them, anyway, as it takes me a while to grasp all the ramifications. L.
Re: [9fans] hgfs
On Thu, May 22, 2014 at 6:17 PM, ron minnich rminn...@gmail.com wrote: has anyone looked at camlistore as a starting point? Written in Go, which means it works on Plan 9. No, it doesn't. I uses FUSE for God's sake. Camlistore is also 65kLOC -- Aram Hăvărneanu
Re: [9fans] hgfs
I'm beginning to remember why I redirected this list to /dev/null. I think I'm going to resume. Enjoy your ever-shrinking place in the world, folks; it's clear that you enjoy it. It's also clear that nobody else cares any more. ron
[9fans] θfs vs webfs; θfs vs lookman
i think i've fixed the issues preventing readweb http://www.9atom.org/magic/man2html/4/θfs and lookman θfs from working. it's surprising how many unicode bugs there still are. - erik
Re: [9fans] hgfs
Quoting ron minnich rminn...@gmail.com: I'm beginning to remember why I redirected this list to /dev/null. I think I'm going to resume. thanks for letting us know Enjoy your ever-shrinking place in the world, folks; it's clear that you enjoy it. It's also clear that nobody else cares any more. I'm sorry that popularity is so important to you. I look forward to any future technical contributions you may make regarding plan 9 or software that runs on plan 9. khm
Re: [9fans] hgfs
I'm beginning to remember why I redirected this list to /dev/null. I think I'm going to resume. Good riddance, we don't want your insults here. We don't want your nsec, and we don't want your GPL. Enjoy your ever-shrinking place in the world, folks; it's clear that you enjoy it. It's also clear that nobody else cares any more. Hey, we're not coming to your Googleplex to insult you, but you come here to insult us. We don't serve koolaid here, so go back and drink your koolaid at Google. Thank you for choosing 9fans OSX/Linux. Have a nice day. -- Aram Hăvărneanu
Re: [9fans] hgfs
Who exactly do you think are the we that you are talking about? Lucho On Thu, May 22, 2014 at 12:51 PM, Aram Hăvărneanu ara...@mgk.ro wrote: I'm beginning to remember why I redirected this list to /dev/null. I think I'm going to resume. Good riddance, we don't want your insults here. We don't want your nsec, and we don't want your GPL. Enjoy your ever-shrinking place in the world, folks; it's clear that you enjoy it. It's also clear that nobody else cares any more. Hey, we're not coming to your Googleplex to insult you, but you come here to insult us. We don't serve koolaid here, so go back and drink your koolaid at Google. Thank you for choosing 9fans OSX/Linux. Have a nice day. -- Aram Hăvărneanu
Re: [9fans] hgfs
you're entitled to your opinion, but please don't speak for everyone. On Thu, May 22, 2014 at 11:51 AM, Aram Hăvărneanu ara...@mgk.ro wrote: I'm beginning to remember why I redirected this list to /dev/null. I think I'm going to resume. Good riddance, we don't want your insults here. We don't want your nsec, and we don't want your GPL. Enjoy your ever-shrinking place in the world, folks; it's clear that you enjoy it. It's also clear that nobody else cares any more. Hey, we're not coming to your Googleplex to insult you, but you come here to insult us. We don't serve koolaid here, so go back and drink your koolaid at Google. Thank you for choosing 9fans OSX/Linux. Have a nice day. -- Aram Hăvărneanu
Re: [9fans] hgfs
Quoting Latchesar Ionkov lu...@ionkov.net: Who exactly do you think are the we that you are talking about? All the unpopular, irrelevant people who regularly force poor Ron to loudly, manually pipe this list into /dev/null instead of just unsubscribing. khm
Re: [9fans] hgfs
c'mon. there's no point to namecalling. - erik
Re: [9fans] hgfs
On Thu, 22 May 2014 09:17:18 PDT ron minnich rminn...@gmail.com wrote: has anyone looked at camlistore as a starting point? Written in Go, which means it works on Plan 9. I will take a look at it but Ron, if you are still on this channel, may be you can describe how it will help here? [And, please don't overload /dev/null. Just use a 'killfile']
Re: [9fans] hgfs
So that means you and Aram. It is interesting that unpopular and irrelevant very often comes in combination with loud. Lucho On Thu, May 22, 2014 at 1:13 PM, Kurt H Maier k...@sciops.net wrote: Quoting Latchesar Ionkov lu...@ionkov.net: Who exactly do you think are the we that you are talking about? All the unpopular, irrelevant people who regularly force poor Ron to loudly, manually pipe this list into /dev/null instead of just unsubscribing. khm
Re: [9fans] hgfs
On Thu, 22 May 2014 12:41:05 +0200 =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= ara...@mgk.ro wrote: What would be the point of this? Once you have a version (revision) you can just bind the subtree where you want it. I don't see the point in having this special switching code inside hgfs. Plan 9 provides the necessary functionality. I agree on this specific point. If I am working on branch A and I want to switch to B, git forces me to commit or stash my changes. So even after gadzillion lines of code it still doesn't do the right thing. A tool should not force singlethreading on me. And hg is no better in this regard. This limitation need not exist on plan9.
Re: [9fans] hgfs
camilstore's storage idea is interesting, but i admit i've only played with it and briefly. i think you're referring to the fact it keeps all versions that are put into it and the fact that anything stored can have any metadata (json) associated with it. On Thu, May 22, 2014 at 9:17 AM, ron minnich rminn...@gmail.com wrote: has anyone looked at camlistore as a starting point? Written in Go, which means it works on Plan 9. ron
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Thu, 22 May 2014 08:45:48 EDT erik quanstrom quans...@quanstro.net wrote: Features such as atomic commits, changesets, branches, push, pull, merge etc. can be useful in multiple contexts so it would be nice if they can integrated smoothly in an FS. - Installing a package is like a pull (or if you built it locally, a commit) - Uinstall is reverting the change. - Each machine's config can be in its own branch. what is the advantage over seperate files? imo, this complicates the issue. I don't quite recall what I was thinking 3 years ago in a 30 minute window but I think the idea was that you have a set of configuration files which all need to be consistent and if you wanted to roll back changes, you'd have to undo all those changes. - You can use clone to create sandboxes. - A commit makes your private temp view permanent and potentially visible to others. - Conversely old commits can be spilled to a backup media (current SCMs want the entire history online). - Without needing a permanent connection you can `pull' data. [never have to do `9fs sources; ls /n/sources/contrib'.] this is a nice list, but i think a key point is not being teased out. the dump file systems are linear. there is a full order of system archives. in hg, there is a full order of the tip, but not so of branches in general. in git, multiple orders (not sure if they're full or not) can be imposed on a set of hashes. So if we do SCM right, backups are just a subset, right?! No, don't believe that. No time to explore this right now but I think dumps are at a different (lower) level from SCM data. another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know.
Re: [9fans] θfs vs webfs; θfs vs lookman
cool! what types of metadata are/were stored in a typical case? On Thu, May 22, 2014 at 11:41 AM, erik quanstrom quans...@quanstro.netwrote: i think i've fixed the issues preventing readweb http://www.9atom.org/magic/man2html/4/θfs and lookman θfs from working. it's surprising how many unicode bugs there still are. - erik
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
another key point is that all distributed scms that i've used clone entire systems. but what would be more interesting is to clone, say, /sys/src or some proto-based subset of the system, while using the main file system for everything else. imagine you want to work on the kernel, and imagine that you keep console log files. clearly you want to see both the new log entries, and the modified kernel. Actually with something like venti as the store, `clone' is trivial! Just find the hash for a particular changeset you want to clone and you can build the rest on demand. `rebase' or `pull' will be more painful. venti is going to be a difficult model. the objects in scm are typically arbitrarly sized, and have arbitrary metadata. θfs has this model for its object store. venti does not. i would be concerned that this really challenges the plan 9 model of namespaces. one would have to figure out how to keep oneself out of namespace hell if one were to build this into a file system and use it heavily. Your concern is a bit premature. We are just handwaving right now! I am interested in finding out just how far we can push the plan9 model -- and if the current model doesn't naturally fall out of any extended model, we'd know. i don't know. this concern was addressed in the very first paper, and i have delt with some plan 9-based systems that did this, and didn't get it right. but it can be addressed without much trouble. just have the fs export em all. - erik
Re: [9fans] θfs vs webfs; θfs vs lookman
On Thu May 22 16:10:21 EDT 2014, skip.tavakkol...@gmail.com wrote: what types of metadata are/were stored in a typical case? for the object store, any metadata at all would be acceptable, and i don't think there is a typical case. there is no object store fs interface. for the nfs and 9p server, just the typical metadata were stored. - erik
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Aram, if you have a bunch of settings that work under VMWare Fusion for Plan 9, then I am all ears. I was under the understanding Plan 9 didn't work under VMWare... On 5/23/14, Jeff Sickel j...@corpus-callosum.com wrote: On May 22, 2014, at 9:49 AM, Aram Hăvărneanu ara...@mgk.ro wrote: Ah, ruby, yet another technology I have zero use for on my systems. That technology is already installed on your system. And not used. Wasted bits on the ssd. http://hadihariri.com/2014/04/21/build-make-no-more/
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On Thu May 22 17:25:07 EDT 2014, edgecombe...@gmail.com wrote: Aram, if you have a bunch of settings that work under VMWare Fusion for Plan 9, then I am all ears. I was under the understanding Plan 9 didn't work under VMWare... the second thing the nix terminal ran on was vmware. i just have not it much. - erik
Re: [9fans] VirtualBox, Mavericks, and Plan 9
I was under the understanding Plan 9 didn't work under VMWare... http://plan9.stanleylieber.com/vmware/img/fusion.png sl
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Ok, I stand corrected. On 5/23/14, s...@9front.org s...@9front.org wrote: I was under the understanding Plan 9 didn't work under VMWare... http://plan9.stanleylieber.com/vmware/img/fusion.png sl
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Just booted the VM using WLAN and my phones wireless hotspot, came up almost instantly. Now the real work begins - configuration... On 5/23/14, Shane Morris edgecombe...@gmail.com wrote: Ok, I stand corrected. On 5/23/14, s...@9front.org s...@9front.org wrote: I was under the understanding Plan 9 didn't work under VMWare... http://plan9.stanleylieber.com/vmware/img/fusion.png sl
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Ok, I stand corrected. Off topic, sorry. I saw this phrase some times here. What it does mean? I know it's meaning I think. What I want to know is why they say just 'thanks'. Is this something some culture related? Kenji
Re: [9fans] VirtualBox, Mavericks, and Plan 9
On May 22, 2014 10:18:32 PM EDT, kokam...@hera.eonet.ne.jp wrote: Ok, I stand corrected. Off topic, sorry. I saw this phrase some times here. What it does mean? I know it's meaning I think. What I want to know is why they say just 'thanks'. Is this something some culture related? Kenji It's an old phrase, basically shorthand for I was wrong, you were correct, thanks for the correction.
[9fans] [GSOC] auth server: connection refused
Hi all, I encountered an error when connecting drawterm with cpu/auth server. Basically, I use drawterm -c super -a super -u bootes but it turns out an error, cpu: can't dial: super: Connection refused goodbye on the plan9 cpu/auth server, I type auth/debug, it outputs p9sk1 key: proto=p9sk1 user=bootes dom=cuiy.net !hex? !password? dialing auth server net!super!ticket cannot dial auth server: connection refused csquery authdom=cuiy.net auth=super I also type cpu -h super on the auth/cpu server, the error is the same with drawterm: cpu: can't dail: super: connection refused I set up the auth/cpu server according to plan9 wiki, http://plan9.bell-labs.com/wiki/plan9/configuring_a_standalone_cpu_server/ Followings are my /lib/ndb/local config. Any suggestions or comments are welcome! # # files comprising the database, use as many as you like, see ndb(6) # database= file=/lib/ndb/local file=/lib/ndb/common #file=/lib/ndb/auth auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com ipnet=cuiy ip=192.168.122.0 ipmask=255.255.255.0 auth=super cpu=super fs=super ntp=128.59.22.30 dns=192.168.122.1 ipgw=192.168.122.1 authdom=cuiy.net dnsdom=cuiy.net ip=192.168.122.71 sys=super dom=cuiy.net # # because the public demands the name localsource # ip=127.0.0.1 sys=localhost dom=localhost -- Think big; Dream impossible; Make it happen.
[9fans] [GSOC] auth server: connection refused
Hi all, I encountered an error when connecting drawterm with cpu/auth server. Basically, I use drawterm -c super -a super -u bootes but it turns out an error, cpu: can't dial: super: Connection refused goodbye on the plan9 cpu/auth server, I type auth/debug, it outputs p9sk1 key: proto=p9sk1 user=bootes dom=cuiy.net !hex? !password? dialing auth server net!super!ticket cannot dial auth server: connection refused csquery authdom=cuiy.net auth=super I also type cpu -h super on the auth/cpu server, the error is the same with drawterm: cpu: can't dail: super: connection refused I set up the auth/cpu server according to plan9 wiki, http://plan9.bell-labs.com/wiki/plan9/configuring_a_standalone_cpu_server/ Followings are my /lib/ndb/local config. Any suggestions or comments are welcome! # # files comprising the database, use as many as you like, see ndb(6) # database= file=/lib/ndb/local file=/lib/ndb/common #file=/lib/ndb/auth auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com ipnet=cuiy ip=192.168.122.0 ipmask=255.255.255.0 auth=super cpu=super fs=super ntp=128.59.22.30 dns=192.168.122.1 ipgw=192.168.122.1 authdom=cuiy.net dnsdom=cuiy.net ip=192.168.122.71 sys=super dom=cuiy.net # # because the public demands the name localsource # ip=127.0.0.1 sys=localhost dom=localhost -- Think big; Dream impossible; Make it happen.
Re: [9fans] hgfs
To get ahead in the game of bullying always single one person out, don't try to even do two at the same time or they might team up. It is interesting that unpopular and irrelevant very often comes in combination with loud. No.
Re: [9fans] [GSOC] auth server: connection refused
Finally got the reason, I execute a command exec rio at the end of /cfg/$sysname/cpurc, which turns out the reason of blocking drawterm, although do not know the detailed reason. Sorry for the noise. 2014-05-22 23:24 GMT-04:00 yan cui ccuiy...@gmail.com: Hi all, I encountered an error when connecting drawterm with cpu/auth server. Basically, I use drawterm -c super -a super -u bootes but it turns out an error, cpu: can't dial: super: Connection refused goodbye on the plan9 cpu/auth server, I type auth/debug, it outputs p9sk1 key: proto=p9sk1 user=bootes dom=cuiy.net !hex? !password? dialing auth server net!super!ticket cannot dial auth server: connection refused csquery authdom=cuiy.net auth=super I also type cpu -h super on the auth/cpu server, the error is the same with drawterm: cpu: can't dail: super: connection refused I set up the auth/cpu server according to plan9 wiki, http://plan9.bell-labs.com/wiki/plan9/configuring_a_standalone_cpu_server/ Followings are my /lib/ndb/local config. Any suggestions or comments are welcome! # # files comprising the database, use as many as you like, see ndb(6) # database= file=/lib/ndb/local file=/lib/ndb/common #file=/lib/ndb/auth auth=sources.cs.bell-labs.com authdom=outside.plan9.bell-labs.com ipnet=cuiy ip=192.168.122.0 ipmask=255.255.255.0 auth=super cpu=super fs=super ntp=128.59.22.30 dns=192.168.122.1 ipgw=192.168.122.1 authdom=cuiy.net dnsdom=cuiy.net ip=192.168.122.71 sys=super dom=cuiy.net # # because the public demands the name localsource # ip=127.0.0.1 sys=localhost dom=localhost -- Think big; Dream impossible; Make it happen. -- Think big; Dream impossible; Make it happen.
Re: [9fans] VirtualBox, Mavericks, and Plan 9
Hi Kenji, As Joseph said, shorthand for Thanks for correcting me on that, and giving me the knowledge I needed, or that I asked for... It is probably a Western-ism, a cultural thing of America/ United Kingdom/ Australia, if not others. I've been using it since I could talk, and started asking the big questions as to Why is it so...? Is it like this? No? I stand corrected... Many thanks! On 5/23/14, Joseph Thompson jthompso...@student.gsu.edu wrote: On May 22, 2014 10:18:32 PM EDT, kokam...@hera.eonet.ne.jp wrote: Ok, I stand corrected. Off topic, sorry. I saw this phrase some times here. What it does mean? I know it's meaning I think. What I want to know is why they say just 'thanks'. Is this something some culture related? Kenji It's an old phrase, basically shorthand for I was wrong, you were correct, thanks for the correction.
