[9fans] hgfs

2014-05-21 Thread Skip Tavakkolian
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 ... %

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> 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

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread Bakul Shah
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 pro

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> i was thinking more in terms of having a git client (fs) on plan9 and using > any number of public git servers. i'm looking at hgfs now; perhaps it > already does all that's needed. A git client would be good. When I attempted to install git on NetBSD I ran into trouble because the packaged ver

Re: [9fans] syscall 53

2014-05-21 Thread Bakul Shah
On Thu, 22 May 2014 03:43:15 - Kurt H Maier wrote: > > But all the DVCS in the world doesn't let us see code that is never uploaded > in the first place. I can't even count the number of programs that are only > even known by oral tradition, mentioned only in passing, then never to be > hear

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> 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

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> And at > least python would be much more useful than gs! I disagree. I try to use Plan 9 to display PDFs as much as it is able to. When it fails, I resort to whatever my recent version of Ubuntu supports. ++L

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> I looked at a few alternative and felt hg is the only workable > alternative that is usable right now. I'm going to stand right with Bakul on this. The actual reasons are not technical, but they are sound. I don't want to install Python on my Plan 9 equipment, but I have HG on Ubuntu and NetBS

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread Skip Tavakkolian
i was thinking more in terms of having a git client (fs) on plan9 and using any number of public git servers. i'm looking at hgfs now; perhaps it already does all that's needed. On Wed, May 21, 2014 at 8:25 PM, Jeff Sickel wrote: > > On May 21, 2014, at 7:13 PM, Bakul Shah wrote: > > > On Wed,

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> But all the DVCS in the world doesn't let us see code that is never uploaded > in the first place. 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 sq

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread Bakul Shah
On Wed, 21 May 2014 22:25:55 CDT Jeff Sickel wrote: > At the base level I find that sources and sourcesdump are much > more accessible than many of the DSCMs (e.g., darcs, git, hg) > out there. Yes it's great to use hg to snapshot state and > allow easy migration across various systems, but it st

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> putting a > dependency on Python would significantly increase the build > time and total lines of code to maintain just to have hg. 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 matte

Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread lucio
> As we’ve managed to migrate towards the topic of version control > systems, I have to add: I don’t like git. Maybe it’s because > I’ve used darcs and hg so much more, or maybe it’s just that I > don’t like the way git is used in many situations. But mostly > I think it’s because I’ve found that

Re: [9fans] syscall 53

2014-05-21 Thread lucio
>> Ergo: Plan 9 does not (yet?) contain sufficient tools to be >> self-sustaining. > > we've managed for years With all respect due to you and Mr Coraid (don't make mne look his name up, he's so conspicuosly absent on this list, even his hallowed name has faded - bless him :-) for all you h

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> i'd encourage you to try participating with apatch, and the mailing > list. > Conceded. I never meant to suggest that one shouldn't, merely that it could be asking for a leap of faith. I have something waiting specifically for this opportunity. So let me ask a few questions. Is this

Re: [9fans] syscall 53

2014-05-21 Thread Kurt H Maier
Quoting Skip Tavakkolian : i like git. as it is a kind of archival file system, one should be able to build a plan9 file system interface for it. This should be possible for any reasonably sane scm; c.f. cinap's hgfs. But all the DVCS in the world doesn't let us see code that is never uploa

[9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]

2014-05-21 Thread Jeff Sickel
On May 21, 2014, at 7:13 PM, Bakul Shah wrote: > On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian > wrote: >> >> i like git. as it is a kind of archival file system, one should be able to >> build a plan9 file system interface for it. > > Have you looked at porting git to plan9? 178K lines

[9fans] VirtualBox, Mavericks, and Plan 9

2014-05-21 Thread Shane Morris
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 pre

Re: [9fans] syscall 53

2014-05-21 Thread Bakul Shah
On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian wrote: > > i like git. as it is a kind of archival file system, one should be able to > build a plan9 file system interface for it. Have you looked at porting git to plan9? 178K lines of *.[ch]. 20K lines of shell scripts (+ 100K+ lines of test

Re: [9fans] syscall 53

2014-05-21 Thread erik quanstrom
> Ergo: Plan 9 does not (yet?) contain sufficient tools to be > self-sustaining. we've managed for years > at it; it needs firm buy-in by the community. I, for one, would need > some hard sell to consider patch and its offspring as sufficient and > much more to convince me that it would be

Re: [9fans] syscall 53

2014-05-21 Thread Steffen Nurpmeso
Skip Tavakkolian wrote: |i like git. as it is a kind of archival file system, one should be able to |build a plan9 file system interface for it. Funky idea. After reading through some Plan9 papers i had the impression that the backing store of git(1) was designed with Venti in mind (except tha

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> can you explain why is this not viable? what essential bits would be > missing if hg/git/whatever is not tightly integrated into the process? Maybe I didn't explain well: self-contained Plan 9 does not provide code review tools. Whereas I can follow (I have learnt to) the conventions of codere

Re: [9fans] syscall 53

2014-05-21 Thread erik quanstrom
On Wed May 21 14:28:51 EDT 2014, s...@9front.org wrote: > > i use a derivative of nemo's patch system. > > Where is this in the 9atom tree? Did you replace the old > patch(1) entirely? good question. the commands are all apatch/create, apatch/note, etc. patch(1) is not replaced, and the patch co

Re: [9fans] syscall 53

2014-05-21 Thread sl
> i use a derivative of nemo's patch system. Where is this in the 9atom tree? Did you replace the old patch(1) entirely? sl

Re: [9fans] nokia n900! (was: syscall 53)

2014-05-21 Thread Nicolas Bercher
On 21/05/2014 17:36, lu...@proxima.alt.za wrote: > PS: I have resurrected an old Nokia (5110, but I'm not sure) phone, > but it's been borrowed and I have my doubts that I will be seeing it > again any time soon. Maybe this forum can help me decide what GSM > equipment is safe from interference b

Re: [9fans] syscall 53

2014-05-21 Thread hiro
> I recommend the nokia 6700 classic, as it's one of the best s40 phones > that still supports real gps (including offline maps and routing). The > only caveat to s40 is the nokia xpress browser, which does pre-rendering > on nokia (now microsoft) servers, even for https traffic. I don't like s40

Re: [9fans] syscall 53

2014-05-21 Thread erik quanstrom
> To keep the ball rolling, let me suggest that we drop the requirement > that Plan 9 be self-contained as a measure to make some progress with > existing expertise. I wish we could keep Plan 9 as the sole > foundation, but I think that's just not viable, I feel treasonous > suggesting otherwise,

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> all options appear to me to boil down to walled gardens. > unless you build it yourself. I do wish the news was better, but at least I don't have to feel alone. Thanks, Erik. ++L

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> i think a key bit to collaboration is going to be setting some ground rules. > and the most important one imho is having a clear goal. To keep the ball rolling, let me suggest that we drop the requirement that Plan 9 be self-contained as a measure to make some progress with existing expertise.

Re: [9fans] syscall 53

2014-05-21 Thread Skip Tavakkolian
i like git. as it is a kind of archival file system, one should be able to build a plan9 file system interface for it. On Wed, May 21, 2014 at 9:25 AM, erik quanstrom wrote: > > I think such a beast would provide the foundations for a serious > > effort to bring the distributions back together

Re: [9fans] syscall 53

2014-05-21 Thread Kurt H Maier
Quoting lu...@proxima.alt.za: PS: I have resurrected an old Nokia (5110, but I'm not sure) phone, but it's been borrowed and I have my doubts that I will be seeing it again any time soon. Maybe this forum can help me decide what GSM equipment is safe from interference by the networks and their

Re: [9fans] syscall 53

2014-05-21 Thread erik quanstrom
> I think such a beast would provide the foundations for a serious > effort to bring the distributions back together. I know many resist > such efforts because of Python (a pet hate of mine, even though I > don't know it from Adam), HG and codereview and I resist accusing them > of reactionary beh

Re: [9fans] syscall 53

2014-05-21 Thread erik quanstrom
> PS: I have resurrected an old Nokia (5110, but I'm not sure) phone, > but it's been borrowed and I have my doubts that I will be seeing it > again any time soon. Maybe this forum can help me decide what GSM > equipment is safe from interference by the networks and their > information masters? M

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> but with codereview extensions now available, it might make sense to > create/switch to a repository hosted on an hg site so that all the change > requests, discussions and reviews are available to everyone I think such a beast would provide the foundations for a serious effort to bring the dist

Re: [9fans] syscall 53

2014-05-21 Thread lucio
> my Plan 9 environment is the only one that i feel i know and have control > over; i don't feel the same about my (Canonical's) ubuntu desktop, my > (Google's) chromebook, my (Apple's) macbook, my (T-Mobile/Google's) android > phone, etc, etc, precisely because of auto-update. i appreciate that t

Re: [9fans] syscall 53

2014-05-21 Thread hiro
On 5/20/14, ron minnich wrote: > Ah well, back to 'm' for this thread, and I now accept that this > community is unwilling to solve this simple problem, as so many others > have. Bummer. > > ron > > This is wrong. I've already solved the problem in my local tree by accident. Basically I've inte