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 anyth
Some thoughts from a new guy.
I would suggest the best way might be to take the 'main' labs sources
distribution and build one patch at a time.
Should in theory leave behind it a nice linear list of patches from a
common base and might get some patches ready to go into sources (if
accepted) for fe
> 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 d
> 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 mo
> With all respect due to you and Mr Coraid (don't make mne look his
Coile.
- erik
> 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
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
> 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
>> 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
> 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
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
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
> 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
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
> 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
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
> 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
> 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
> 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,
> 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
> 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 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
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 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
> 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
> 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
> 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
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
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
req
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
On May 20, 2014, at 11:41 AM, ron minnich 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 does
a very good
Quoting ron minnich :
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 operating system
ba
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 po
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
Quoting ron minnich :
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 the
firmware
to th
> 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 distributi
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 techno
On Mon, 19 May 2014 17:34:24 EDT Anthony Sorace 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 whoev
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 the
> > 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
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
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
On May 19, 2014, at 6:17 PM, andrey mirtchovski 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 time to cut over to
I suggest personal notes, flowers, and some hard liquor.
On Mon, May 19, 2014 at 5:12 PM, Kurt H Maier wrote:
> Quoting andrey mirtchovski :
>
>> 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 sys
Quoting andrey mirtchovski :
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'm not complaining;
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 wrote:
> Quoting ron minnich :
>
>> 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
Quoting ron minnich :
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 request to reex
On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
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 scheduling. When there
>
On 19 May 2014 21:54, ron minnich 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 scheduling. When there
is
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 w
> 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 (al
> 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 s
On Mon, 19 May 2014 13:25:42 EDT erik quanstrom 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 time and accuracy
On 19 May 2014 20:15, Aram Hăvărneanu 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 troublesome in
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 an
> On 19 May 2014 18:13, 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 to ca
> > 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
>
On 19 May 2014 18:13, 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 to cache the time
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 i
> 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 ch
> 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 mat
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 imp
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
> 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 t
> 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
> 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
On May 18, 2014, at 8:54 PM, erik quanstrom 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
>> environment (pc, bcm,
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
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 bina
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 wrote:
>
> > * pull only /sys/src/9
>
> * pull -s sys/src/libc
>
> > * build the kernels you need and inst
> * 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.
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
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 wo
note to self: add /dev/sdE?/9fat to vac
streamline getting 9LOAD in place w/o corruption
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 pull
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 w
> 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 th
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.
On Sat, May 17, 2014 at 2:17 PM, Jeff Sickel wrote:
> 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
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 wrote:
> A lot more than Caps lock is not working….
> This has been some of the wor
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 my
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.
Already copied kernels to 9fat, all is working fine, seems plan9 got a bit
faster generaly.
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 int
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.
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.
http://9legacy.org/download/kernel.t
> it requires 3 syscalls and not two, and takes about 2x as long. it's still
good grief. s/two/one/.
- erik
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: suic
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:1
90 matches
Mail list logo
