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
With all respect due to you and Mr Coraid (don't make mne look his
Coile.
- erik
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)
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
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
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.
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
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
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
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
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
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
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
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
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 use a derivative of nemo's patch system.
Where is this in the 9atom tree? Did you replace the old
patch(1) entirely?
sl
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
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
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
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
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
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
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
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
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
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
Ron wrote:
That said, the problems were due (IMHO) to a limitation in the
update mechanism, not to the inclusion of a new system call.
This is true depending on how you define update mechanism.
A simple note from whoever made the decision to push the
change out to the effect of hey, we're
That said, the problems were due (IMHO) to a limitation in the
update mechanism, not to the inclusion of a new system call.
This is true depending on how you define update mechanism.
A simple note from whoever made the decision to push the
change out to the effect of hey, we're going to
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
If you are telling me that the upgrade technology of Plan 9 can not
handle an automatic upgrade, fine; we have
On Mon, 19 May 2014 17:34:24 EDT Anthony Sorace a...@9srv.net wrote:
Ron wrote:
That said, the problems were due (IMHO) to a limitation in the
update mechanism, not to the inclusion of a new system call.
This is true depending on how you define update mechanism.
A simple note from
On Tue May 20 12:42:35 EDT 2014, rminn...@gmail.com wrote:
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
If you are telling me that the upgrade technology
I never understood why binaries are pulled. Even on a lowly
RPi it takes 4 minutes to build everything (half if you cut
out gs). And the 386 binaries are useless on non-386
platforms!
Why not just separate binary and source distributions? Then
include a file in the source distribution to
Quoting ron minnich rminn...@gmail.com:
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
Millions of carefully-crafted machines updating all the time, from
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
On Tue May 20 15:50:56 EDT 2014, 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.
nobody said that. there's a difference between noting a strawman
argument, and
Quoting ron minnich rminn...@gmail.com:
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
Deliberate misdirection then; got it.
I'm sorry you're sad, but comparing plan freaking 9 to an
On May 20, 2014, at 11:41 AM, ron minnich rminn...@gmail.com wrote:
This is not a human communication problem. It's a technology problem,
trivially solved for many years now by many systems.
This event was a communication problem.
The technology, replica, works as advertised. In general it
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
yes, it was a lack of *any* notice; i occasionally check /n/sources/patch
for incoming patches and i don't believe the NSEC patch went through that
channel. in the past, changes that had a system-wide or kernel effect were
announce, and instructions for upgrading were given. certainly, it's not
Which raises another question: are 9atom and 9front in synch with the
BL distribution (itself in question) regarding syscall 53?
9atom is not. i didn't know that it was added, nor do i
know why nsec was added as a syscall.
i indirectly heard go needs it, but that is not really a reason
i can
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important alert, quite indirectly: when using
high resolution timers, the issue of opening a device, reading it and
converting the input value to a
On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote:
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important alert, quite indirectly: when using
high resolution timers, the issue
On Mon May 19 12:26:00 EDT 2014, quans...@quanstro.net wrote:
On Mon May 19 10:04:28 EDT 2014, lu...@proxima.alt.za wrote:
i indirectly heard go needs it, but that is not really a reason
i can understand technically. why must it be a system call?
Actually, Go raised an important
i took a quick look at the runtime·nanotime, and it looks like it's being
used for gettimeofday, which shouldn't be super performance sensitive.
I'm on thin ice here, but I seem to remember that the crucial issue
was the resolution (nanosecond) and the expectation that Plan 9 would
have to
also, one cannot get close to 1ns precision with a system call. a system call
takes a bare minimum of 400-500ns on 386/amd64.
Sure, but accessing /dev/time is, if I guess right, orders of
magnitude slower, specially if you have to open the device first.
As far as I know, that was the only
On Mon May 19 13:17:59 EDT 2014, lu...@proxima.alt.za wrote:
also, one cannot get close to 1ns precision with a system call. a system
call
takes a bare minimum of 400-500ns on 386/amd64.
Sure, but accessing /dev/time is, if I guess right, orders of
magnitude slower, specially if you
On 19 May 2014 18:13, lu...@proxima.alt.za wrote:
Curiously, I'm pretty certain that it was the issue of an fd that
remained open (something to do with caching the /dev/time fd, if I
remember right) that caused some tests to fall apart, probably because
a test for leaking fds actually needed
On 19 May 2014 18:13, lu...@proxima.alt.za wrote:
Curiously, I'm pretty certain that it was the issue of an fd that
remained open (something to do with caching the /dev/time fd, if I
remember right) that caused some tests to fall apart, probably because
a test for leaking fds actually
There are two separate issues here. First, there's the issue of
whether 9front and 9atom should incorporate the change.
For purely egoistic reasons, I'd like that, regardless of the
technical merits of the change. I regulary test labs software on
9front. It would be a pity if I couldn't do that
On 19 May 2014 20:15, Aram Hăvărneanu ara...@mgk.ro wrote:
Some people claimed
that using it leaked file descriptors in multithreaded programs. I
don't understand why this problem can't be solved by opening it
close-on-exec.
The optimisation was a static int file descriptor.
That was
On Mon, 19 May 2014 13:25:42 EDT erik quanstrom quans...@quanstro.net wrote:
i would be very surprised if there were any gain in accuracy. the
accuracy is going to be dominated by the most inaccurate term, and
that's likely going to be timesync, and on the order of milliseconds.
Speaking of
I am adding some logic to synchronize with the PPS signal from
the GPS device that I hooked up to a RaspberryPi. With this
change the TOD clock should be accurate to within 10 to 20 µs.
So I for one welcome the new syscall! [Though its introduction
could've been better managed]
even a
There was another complaint about /dev/bintime. Some people claimed
that using it leaked file descriptors in multithreaded programs. I
don't understand why this problem can't be solved by opening it
close-on-exec. In fact, this problem doesn't exist in the port of
Go to Plan 9 anymore
I've been watching the discussion but was hesitant to jump in. But
somebody asked me to say a thing or two.
We put the nsec() system call into NxM because, any way you cut it, it
provides better accuracy than the open/read/close path, particularly
when there's lots of stuff running, and the apps
On 19 May 2014 21:54, ron minnich rminn...@gmail.com wrote:
jitter-free time
Jitter says something about (in)consistency of time periods or intervals.
It will be a function of scheduling decisions, not the overhead of a single
call.
In Nix, on an AP core, sure, because there isn't any
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
Jitter says something about (in)consistency of time periods or intervals. It
will be a function of scheduling decisions, not the overhead of a single
call.
In Nix, on an AP core, sure, because there isn't any
Quoting ron minnich rminn...@gmail.com:
And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which boiled down to:
if you can do it with a single system call, you should with a
response of we put in a patch, was not accepted yet.. I just renewed
the
golang-dev has more clout than 9fans nowadays, at least as it pertains to plan9.
On Mon, May 19, 2014 at 5:02 PM, Kurt H Maier k...@sciops.net wrote:
Quoting ron minnich rminn...@gmail.com:
And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which
Quoting andrey mirtchovski mirtchov...@gmail.com:
golang-dev has more clout than 9fans nowadays, at least as it
pertains to plan9.
That's why I'm asking. We now have three go-related new syscalls, while
lots of actual hardware support gets flushed down the toilet for
unspecified reasons.
I suggest personal notes, flowers, and some hard liquor.
On Mon, May 19, 2014 at 5:12 PM, Kurt H Maier k...@sciops.net wrote:
Quoting andrey mirtchovski mirtchov...@gmail.com:
golang-dev has more clout than 9fans nowadays, at least as it pertains to
plan9.
That's why I'm asking. We now
On May 19, 2014, at 6:17 PM, andrey mirtchovski mirtchov...@gmail.com wrote:
I suggest personal notes, flowers, and some hard liquor.
/me could use all three after a weekend of sysadmin frustration.
All hope is not lost… this exercise, by not being able to use
my usual cpu servers, gave me
added the syscall for binary compatibility with sources to 9front kernel.
nsec() remains a library function that reads /dev/bintime. removed the
filedescriptor caching from nsec() like in the 9atom version.
--
cianp
I will use pull -n from now on. But it will still not help if one needs to
recompile kernel with new syscalls or similar. Erics procedure helps to recover
to old state, but i never tried it, it may be that some commands needed new
syscall too, i tried to copy to 9fat with same error, maybe it
The safe way to upgrade your file server is simply to update the kernel
binaries (for example, with the ones I'm providing) on your 9fat and reboot.
Then, you can pull the updated program binaries from /n/sources.
There is no need to wait, because you have to be running the new kernel
before
note to self: add /dev/sdE?/9fat to vac
streamline getting 9LOAD in place w/o corruption
i got the impression that sources were in some inconsistent state.
if the only change is the new system call, isn't it sufficient to:
* pull only /sys/src/9
* build the kernels you need and install on boot medium
* reboot
* pull again and rebuild all the binaries
since existing binaries would
0intro's last paragraph says the same thing.
On Sun, May 18, 2014 at 8:32 AM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
i got the impression that sources were in some inconsistent state.
if the only change is the new system call, isn't it sufficient to:
* pull only /sys/src/9
*
* pull only /sys/src/9
* pull -s sys/src/libc
* build the kernels you need and install on boot medium
* reboot
I recovered by using 9fs snap so I could get an earlier state
of /386. 9fs dump triggered the syscall error.
rebuilding/installing the binaries from local sources takes very little
time and guarantees that pull will not overwrite them (unless forced).
On Sun, May 18, 2014 at 8:38 AM, Jeff Sickel j...@corpus-callosum.comwrote:
* pull only /sys/src/9
* pull -s sys/src/libc
* build the kernels
fyi, pulling/merging (e.g. adding IL back), building the kernels, booting
and building the binaries works as expected for all cpu types in my
environment (pc, bcm, rb and kw).
On Sun, May 18, 2014 at 9:03 AM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
rebuilding/installing the
On Sun May 18 18:56:49 EDT 2014, skip.tavakkol...@gmail.com wrote:
fyi, pulling/merging (e.g. adding IL back), building the kernels, booting
and building the binaries works as expected for all cpu types in my
environment (pc, bcm, rb and kw).
i'd put a vote into restoring il to the standard
On May 18, 2014, at 8:54 PM, erik quanstrom quans...@quanstro.net wrote:
On Sun May 18 18:56:49 EDT 2014, skip.tavakkol...@gmail.com wrote:
fyi, pulling/merging (e.g. adding IL back), building the kernels, booting
and building the binaries works as expected for all cpu types in my
i'd put a vote into restoring il to the standard kernels. there's no
downside.
My vote, too.
++L
Great
machine, on 9atom.
Which raises another question: are 9atom and 9front in synch with the
BL distribution (itself in question) regarding syscall 53?
++L
Hello, help please, after recent (15 May) pull:
mntgen 31: bad sys call number 53 pc 813f
ipconfig, keyfs, webfs webcookies, faces = the same.
ls -l for example shows
ls 222: bad sys call number 53 pc bb8f
ls 222: suicide: sys: bad sys call pc=0xbb8f
acid leads to /sys/src/libc/386/main9.s:16
On Sat May 17 06:28:02 EDT 2014, puta2001-...@yahoo.com wrote:
Hello, help please, after recent (15 May) pull:
mntgen 31: bad sys call number 53 pc 813f
ipconfig, keyfs, webfs webcookies, faces = the same.
ls -l for example shows
ls 222: bad sys call number 53 pc bb8f
ls 222: suicide:
it requires 3 syscalls and not two, and takes about 2x as long. it's still
good grief. s/two/one/.
- erik
Since the kernels on /n/sources haven't been recompiled yet,
I've uploaded an archive with the 9pcf and 9pccpuf kernel
binaries.
In case you pulled the updated binaries and aren't able
to use you system anymore, you can just replace the 9fat
kernels with them.
Thanks, tried to compile kernel with no luck cause of the same syscall 53. Was
postponing some kind of dump file system until it finally got me :) webfs needs
53, so no internet. Will load some linux and copy kernels into 9fat. thanks.
On Sat May 17 09:55:16 EDT 2014, puta2001-...@yahoo.com wrote:
Thanks, tried to compile kernel with no luck cause of the same syscall 53.
Was postponing some kind of dump file system until it finally got me :) webfs
needs 53, so no internet. Will load some linux and copy kernels into
Already copied kernels to 9fat, all is working fine, seems plan9 got a bit
faster generaly.
p.s. Caps lock is not working. Also copying in 9fat directory shifts file time
current time+3 hours, even +6 hours if renaming (mv). My timezone is +3 GMT.
Its native plan9 on ibm t42.
A lot more than Caps lock is not working….
This has been some of the worst 36+ hours I’ve had w/ Plan 9,
and no end in site to get everything running again.
I sure hope the NSEC change is worth it in the long run.
I did want to write some Go code yesterday, but this rebuild
has eaten up most of
s/site/sight/
Might not be so bad… one day, but it does mean that handling the
stand-alone file server needs to have a few more controls in
place to prevent a pull.
-jas
On May 17, 2014, at 4:17 PM, Jeff Sickel j...@corpus-callosum.com wrote:
A lot more than Caps lock is not working….
This
thanks for the heads-up. i'll wait pulling from sources for now.
On Sat, May 17, 2014 at 2:17 PM, Jeff Sickel j...@corpus-callosum.comwrote:
A lot more than Caps lock is not working….
This has been some of the worst 36+ hours I’ve had w/ Plan 9,
and no end in site to get everything running
On Sat May 17 15:16:03 EDT 2014, puta2001-...@yahoo.com wrote:
p.s. Caps lock is not working. Also copying in 9fat directory shifts
file time current time+3 hours, even +6 hours if renaming (mv). My
timezone is +3 GMT. Its native plan9 on ibm t42.
the standard plan 9 key map maps caps
thanks for the heads-up. i'll wait pulling from sources for now.
I guess we need one of two alternatives at this point: either somebody
documents how to recover from a pull by first reconstructing (or
binding from the dump) the critical commands or we are given some
indication by Bell Labs so
87 matches
Mail list logo
