Re: [9fans] syscall 53
On 5/20/14, ron minnich rminn...@gmail.com 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 integrated a modified vc (I use an experimental 64bit MIPS here - provided by the chinese government during my internship) into systemd, which I ported to plan9 kernel space. When I boot the system and a syscall is found missing, the kernel simply recompiles itself (there is some heavy trickery involving clusters of neural networks in a fiber network to make that work) So even though this results from my other project as a byproduct, I'm happy to share it.
Re: [9fans] syscall 53
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 they want to be my sysadm, but it means that i'm no longer an informed consumer. It may not be a coincidence, but I'm going through the same phase. I'm not yet paranoid, but I have been seriously contemplating moving my (other) workstation to NetBSD because I am more comofortable that there are no mysterious daemons lurking in its innards that I ought to know about. Like you, I am perfectly comfortable with my Plan 9 network and continue to wish I did not have to supplement it with any of the paranoia-inducing offering out there. +L 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? My current hate-object is my Galaxy S4.
Re: [9fans] syscall 53
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 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 behaviour; I do wish we could get past that problem, though. ++L
Re: [9fans] syscall 53
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? My current hate-object is my Galaxy S4. purchasing a phone directly from google allows one to cut out the network operator. (to some extent.) in theory the cyanogenmod phone is less tied to google. sadly, it doesn't bluetooth-le, and i need that. all options appear to me to boil down to walled gardens. unless you build it yourself. - erik
Re: [9fans] syscall 53
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 behaviour; I do wish we could get past that problem, though. fwiw... i use a derivative of nemo's patch system. all changes are applied through patches. anyone can comment on a patch, and comments, and patch dispositions are mailed to everyone on the list. the list is open to general discussion. the patch system allows folks to pull (not executables) or apply patches themselves, so in spirit it's closer to git than hg. i'm open to any sort of gateway to hg/codereview/git that folks find useful. i just don't want hg to be a requirement. one of the things i value about plan 9 is the fact that it's a self-contained system. requiring hg and websites runs counter this. i haven't carved out the time to do anything about it, but patches are welcome. 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. off the top of my head, how about having the best plan 9 we can afford, which runs on as much hardware, and as many vms as possible. right out of the box. what do yall think? - erik
Re: [9fans] syscall 53
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 information masters? My current hate-object is my Galaxy S4. 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. khm
Re: [9fans] syscall 53
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 quans...@quanstro.netwrote: 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 behaviour; I do wish we could get past that problem, though. fwiw... i use a derivative of nemo's patch system. all changes are applied through patches. anyone can comment on a patch, and comments, and patch dispositions are mailed to everyone on the list. the list is open to general discussion. the patch system allows folks to pull (not executables) or apply patches themselves, so in spirit it's closer to git than hg. i'm open to any sort of gateway to hg/codereview/git that folks find useful. i just don't want hg to be a requirement. one of the things i value about plan 9 is the fact that it's a self-contained system. requiring hg and websites runs counter this. i haven't carved out the time to do anything about it, but patches are welcome. 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. off the top of my head, how about having the best plan 9 we can afford, which runs on as much hardware, and as many vms as possible. right out of the box. what do yall think? - erik
Re: [9fans] syscall 53
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. I wish we could keep Plan 9 as the sole foundation, but I think that's just not viable, I feel treasonous suggesting otherwise, but I'm merely stating my sentiments, not imposing a rule here. At the same time, the danger that Pyhton-HG-Codeview and web access all somehow become unviable for the Plan 9 community (who knows, there's a lot of ugliness out there and, in my opinion, it is growing), I would like to propose a backup plan to ensure that developments are tracked outside of the HG. I used CVS with some success in the past in parallel with HG while Go for Plan 9 was still in its infancy, but it was a bit of a mission and I could not sustain it when the transition from make to go-tool took place: the changes were coming too thick and fast. Maybe hiro's fibre-optic based neural network will make the next efforts succeed (I restarted the CVS project in an effort to get the ARM developments of Go for Plan 9 in sync, but three months down the line I'm still precisely nowhere with that plan). Something to provide a similar, this time successful, safeguard would be great, some (including me) would no doubt say essential. I'd love to add a new-thought (new-age?) version control system based on venti and proto to Plan 9 and be the envy of the competition, but it would be a big project and more pressing issues in Plan 9 have much higher priority and more likelihood of success, in my opinion. I think we can all benefit from taking this discussion further, if only to explore how others are addressing the shortcomings of Plan 9 development and evolution and possibly discover new ways to deal with our own problems. No need to get political about it, what we need is some facts, some good or bad advice, some humour and, because this is 9fans, after all, some conflict. ++L
Re: [9fans] syscall 53
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
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, but I'm merely stating my sentiments, not imposing a rule here. 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? - erik
Re: [9fans] nokia n900! (was: syscall 53)
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 by the networks and their information masters? My current hate-object is my Galaxy S4. I'm using the n900, it's running maemo (based/compatible on/with Debian armel) which is half no-longuer supported, which means no more updates (or so). I'm happy to use Git, ssh, emacs org-mode and drawterm (without Rio for the moment) on it. It also supports large µSD cards (say 64GB + internal 32GB = really comfortable!). There's also an on-going motherboard drop-in replacement-upgrade project for it: http://neo900.org/ Nicolas (who broke the too-deep thread)
Re: [9fans] syscall 53
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] syscall 53
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 commands are intact. i need them as i try to send as many patches in to sources as possible. 9diff(1) is a nifty little hack. - erik
Re: [9fans] syscall 53
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 codereview (as used in Go, by whatever name), I do not expect less disciplined approaches to be as appealing and successful as codereview, maybe that's just me, but I am speaking for myself and measuring the 9fans community by the same metric. Ergo: Plan 9 does not (yet?) contain sufficient tools to be self-sustaining. We're human and we're subjective individuals. We have a very weak bond holding this community together, consisting, at least in my case, more of what other OSes are missing than of any loyalty to what we have. Whatever we deploy to provide a platform for progress needs to be stronger than the criticism that will be levelled 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 technically superior to codereview, others may well be even more hard-assed than I am, and their skills and contributions are too important to sacrifice. Strong words? Definitely, 9fans has survived past worse and will again, so they need not be taken to heart. But we do risk falling too far behind to ever be of any significance and that would be our loss as well as a loss for the entire IT community. Again, I'm being subjective, by all means keep throwing your stones. A thin skin here is not going to help. ++L
Re: [9fans] syscall 53
Skip Tavakkolian skip.tavakkol...@gmail.com 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 that garbage collection is possible), so that would be some kind of coming home. --steffen
Re: [9fans] syscall 53
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 technically superior to codereview, others may well be even more hard-assed than I am, and their skills and contributions are too important to sacrifice. i'd encourage you to try participating with apatch, and the mailing list. i would find specific issues easier to reason about than technically superior. - erik
Re: [9fans] syscall 53
On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian skip.tavakkol...@gmail.com 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 scripts). Also python and perl scripts. All SCM are in some sense archival systems but the actual storage scheme used is just one tiny part of the system. There are a few more requirements which a simple filesystem model won't satisfy by itself. Consider: This is the most fundamental operation of a SCM is to manage source code updates sanely. Suppose you had to change files f1..fn to implement a feature/bugfix. Now you want to check them in and share these changes with others. But the checkin should succeed *only if* the latest versions of f1..fn in the underlying filesystems are the *same* as the ones you started from. If this is not true, the entire checkin must be aborted. It is upto the developer to merge his changes with the latest versions and try again. [Essentially you are doing a compare-and-swap operation on a set of files] You can single thread this through a human but the problem remains the same and a human (without additional tools) will not be able to check all this reliably. For a collaborative, distributed project where different people may work on different parts, a human in the middle is not a scalable solution. The only reason for a manual SCM is to *slow down* the rate of change. Then there other operations like maintaining separate branches, merging/cherry picking changes from another branch, reverting from local changes, rolling back a bad checkin, pushing changes to a shared repo, pulling from it, access control, etc. etc. You can certainly build something on top of venti to build a nice SCM but that would be a researchy project. Given all this I think hg makes a good compromise if you want to move forward from the status-quo.
[9fans] VirtualBox, Mavericks, and Plan 9
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.
[9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On May 21, 2014, at 7:13 PM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian skip.tavakkol...@gmail.com 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 scripts). Also python and perl scripts. 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 many of the github projects lose sight of what I think is the more important portion of the source history: the history and development process itself. 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 still clutters the model. One of the advantages of having a real archival store, like Venti, is that it changes the conceptual level of how you deal with metadata about a project. When the default is everything is saved and you can manipulate the namespace to represent various portions of the history then you don’t get caught up in all the branching, rebasing, queues, merges, and other general contortions that would make us happy to warp back in time to an early copy of Dr. Dobb’s Journal of Computer Calisthenics Orthodontia when the future looked bright and we really could do anything with 8 bits. Sure working with an automatic snapshot system can be a headache at times, but it’s one of those that easily passes, not like sitting down for a [git] root canal because your tooth has been rotting to the core while you worry about the configuration for the hottest continuous integration system with a butler name that shows we really didn’t learn anything about the 18th or 19th century transitions to the modern age... Back on topic: be careful of the dependencies required to get a system bootstrapped. The FreeBSD community took BIND out of the default system and re-wrote a new basic resolver because the BIND 10+ versions would require packaging Python into the core distribution. There’s no reason for bringing in more than is necessary to build, and putting a dependency on Python would significantly increase the build time and total lines of code to maintain just to have hg. Darcs is in the same boat in that you’d have to keep a version of Haskell in the system. 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? With a payload that large, it would take all the booster rockets [money] on the planet to get it into orbit. And it still might break apart, fall back to Earth, and kill us in the process. At the end of the day, it’s the communication with people that’s the largest benefit. Let’s continue building systems based on the ideas that drew us all to Plan 9 in the first place.
Re: [9fans] syscall 53
Quoting Skip Tavakkolian skip.tavakkol...@gmail.com: 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 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 heard of again. Oh, I'll upload it when it's ready. Years go past: nobody has even defined 'ready.' Nowadays when someone says it's not ready for the world to see I just read I am a liar and I have nothing. Plan 9 is fully self-sufficient; code review tools don't review code. People review code. They just have to see the code first. khm
Re: [9fans] syscall 53
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 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? 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. Is it worth it to get going immediately, or should further discussion take place? Whose opinions ought we to be canvassing, are there parties that ought to be reached outside of 9fans? Any deities we need to burn offerings to? Do we need additional discussion forums (fora, for the pedants) for the more thin-skinned contributors (or for any other need to keep community members from falling out with each other)? Are there any other questions I'm missing from my somewhat limited and remote perspective? i would find specific issues easier to reason about than technically superior. Touché. Although it's kind of obvious I wouldn't be welcome to say subjectively superior instead, right? ++L
Re: [9fans] syscall 53
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 have contributed, Coraid is as exceptional as Cuba (and more successful, to our relief, no doubt). But that was a formidable battle (nay, a full-out war) you waged against all odds and at some stage it must have felt as if the USSR stood a greater chance against Reagan and Thatcher combined. I doff my hat, but I'm not going to start believing in miracles any time soon, much as this is one miracle I would like to see and I think, at minimum, you've overcome the five-year survival barrier. ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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 many of the github projects lose sight of what I think is the more important portion of the source history: the history and development process itself. Thank you for the opened door, Jeff :-) I've been mulling revision control (actually, strictly source control, I have little interest in patching binaries, no matter what old tin can they are fitted with[1]) and one novel idea that keeps nagging me without quite settling in my head is the use of Plan 9's proto to record at least part of the history. Is this entirely original of me? Is it totally insane, or is there perceived merit in what my subconscious keeps shouting at me? ++L [1] See the original cover of Mike Oldfield's Tubular Bells
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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 matter how valuable some of us may perceive it. HG without Python is a dead rat. All for Bind in Go, raise both hands :-) ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
On Wed, 21 May 2014 22:25:55 CDT Jeff Sickel j...@corpus-callosum.com 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 still clutters the model. Wouldn't something like cinap's hgfs give you the same thing? One of the advantages of having a real archival store, like Venti, is that it changes the conceptual level of how you deal with metadata about a project. When the default is everything is saved and you can manipulate the namespace to represent various portions of the history then you don't get caught up in all the branching, rebasing, queues, merges, and other general contortions that would make us happy to warp back in time to an early copy of Dr. Dobb's Journal of Computer Calisthenics Orthodontia when the future looked bright and we really could do anything with 8 bits. Sure working with an automatic snapshot system can be a headache at times, but it's one of those that easily passes, not like sitting down for a [git] root canal because your tooth has been rotting to the core while you worry about the configuration for the hottest continuous integration system with a butler name that shows we really didn't learn anything about the 18th or 19th century transitions to the modern age... Branch/merge features evolved in response to people's needs. Merging is necessary if you (as an organization) have substantial local changes for your product (or internal use) and you also want to use the latest release from your vendor. No amount of namespace manipulation is going to help you. Parallel development is inherently more headachy! Back on topic: be careful of the dependencies required to get a system bootstrapped. The FreeBSD community took BIND out of the default system and re-wrote a new basic resolver because the BIND 10+ versions would require packaging Python into the core distribution. There's no reason for bringing in more than is necessary to build, and putting a dependency on Python would significantly increase the build time and total lines of code to maintain just to have hg. Darcs is in the same boat in that you'd have to keep a version of Haskell in the system. 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? I was certainly not suggesting porting git to plan9! Just pointing out how painful and big the task would be -- I was in fact saying use hg! I looked at a few alternative and felt hg is the only workable alternative that is usable right now. A dependency on python doesn't seem much worse than one on ghostscript. Neither should be built every time you do `mk all' in /sys/src but it should be possible to build them. And at least python would be much more useful than gs! Though the idea of a scmfs (for checkins as well) and using vac/venti as a backend is starting to appeal to me : ) At the end of the day, it's the communication with people that's the largest benefit. Let's continue building systems based on the ideas that drew us all to Plan 9 in the first place. Well, nothing prevents us from continuing to use the existing system.
Re: [9fans] syscall 53
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 squarely in the Creationists camp. (BTW: do not believe everything South African expatriates have to say.) ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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 j...@corpus-callosum.comwrote: On May 21, 2014, at 7:13 PM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 21 May 2014 09:56:26 PDT Skip Tavakkolian skip.tavakkol...@gmail.com 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 scripts). Also python and perl scripts. 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 many of the github projects lose sight of what I think is the more important portion of the source history: the history and development process itself. 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 still clutters the model. One of the advantages of having a real archival store, like Venti, is that it changes the conceptual level of how you deal with metadata about a project. When the default is everything is saved and you can manipulate the namespace to represent various portions of the history then you don’t get caught up in all the branching, rebasing, queues, merges, and other general contortions that would make us happy to warp back in time to an early copy of Dr. Dobb’s Journal of Computer Calisthenics Orthodontia when the future looked bright and we really could do anything with 8 bits. Sure working with an automatic snapshot system can be a headache at times, but it’s one of those that easily passes, not like sitting down for a [git] root canal because your tooth has been rotting to the core while you worry about the configuration for the hottest continuous integration system with a butler name that shows we really didn’t learn anything about the 18th or 19th century transitions to the modern age... Back on topic: be careful of the dependencies required to get a system bootstrapped. The FreeBSD community took BIND out of the default system and re-wrote a new basic resolver because the BIND 10+ versions would require packaging Python into the core distribution. There’s no reason for bringing in more than is necessary to build, and putting a dependency on Python would significantly increase the build time and total lines of code to maintain just to have hg. Darcs is in the same boat in that you’d have to keep a version of Haskell in the system. 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? With a payload that large, it would take all the booster rockets [money] on the planet to get it into orbit. And it still might break apart, fall back to Earth, and kill us in the process. At the end of the day, it’s the communication with people that’s the largest benefit. Let’s continue building systems based on the ideas that drew us all to Plan 9 in the first place.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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 NetBSD to provide the services I need. I also have no idea if this is viable for a mixture of Plan 9 and Windows, exclusively, I avoid Windows and I'm trying to move away from Linux and Android (yes, same thing, indeed). 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? ++L
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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]
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'd like to throw Go into the picture because I have more or less sold my soul to that devil, but I'm willing to continue using C (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) if the community feels strongly about it. L += 1 PS: I've dropped ++ from the list of operators I use in Go. I see no value in this operator that the more explicit form += 1 does not satisfy better. Please do show me how I'm mistaken.
Re: [9fans] syscall 53
On Thu, 22 May 2014 03:43:15 - Kurt H Maier k...@sciops.net 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 heard of again. Oh, I'll upload it when it's ready. Years go past: nobody has even defined 'ready.' Nowadays when someone says it's not ready for the world to see I just read I am a liar and I have nothing. 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!.
Re: [9fans] CMS/MMS (VCS/SCM/DSCM) [was: syscall 53]
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 version (even if compiled from sources) demanded the X development system to be installed (I need to run this by the NetBSD folk, but it hardly matters). I in fact now use Ubuntu to fetch git stuff and the seamlessness of the Go tool goes out the window. The Plan 9 side of this is really for discussion in the Go forum(s), but perhaps others here would care to comment? 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 what degree one bends over backwards to be compatible is a separate discussion, to be had about the merits of each system. But the underlying system must not preclude the option. L += 1
