Thanks a lot, it works!
Kind Regards,
Dante
On 18.07.2014 16:59, Richard Miller wrote:
Would a replica/pull -v /dist/replica/network result in the same
system as the last 9pi kit
(http://plan9.bell-labs.com/sources/contrib/miller/9pi.img.gz)?
Almost. See
I would like first to thank everyone for the kind replies!
Each was useful in it's own way.
On 18.07.2014 16:36, erik quanstrom wrote:
Yet: is there a source control system behind it?
Would it be possible to check out directly from there?
there is nothing most folks would recognize as a
You are not the first one to bring this up. There is a chain titled
CMS/MMS (VCS/SCM/DSCM) [was syscall 53] that discusses it. I'd suggest
giving it a skim if you can find it in the archives.
That said, in my opinion:
1. The history is confined to Plan9.
It is hard to do small fixes
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote:
I would like first to thank everyone for the kind replies!
Each was useful in it's own way.
On 18.07.2014 16:36, erik quanstrom
Hi,
On 19.07.2014 13:20, Riddler wrote:
3. Contrib packages are tied to people; there is no common
repository.
This leads to the situation where you can't update a package
of a long gone user.
Please tell me how many Mercurial packages you can find in
Contrib!
I don't see how a
On 19.07.2014 13:49, pmarin wrote:
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
And this might lead to the problems pointed in my previous mails.
Or not, I might be wrong.
Kind Regards,
Dante
This was an unfair statement from you, pmarin.
You make me answer twice.
I did not imply anywhere that I proposed the bazaar model (whatever
that is, no one wants the Linux .
Scalability is also possible in projects maintained by a central
authority.
My whole argument goes about the
On Sat, Jul 19, 2014 at 01:49:10PM +0200, pmarin wrote:
Plan9 in general doesn't follow the Bazaar model ( the current usual
way of doing things ).
The Bazaar model is the one for not doing or undoing.
Small is beautiful. The attraction for Plan9 is its consistency and size.
As far as I'm
Please, be so kind and stop this Bazaar thread.
The proposal was to use some maybe more scalable tools while
maintaining the current responsibilities.
This could allow for more contributions to be done with the same burden
for the maintainers.
An example for what it's worth could be OpenBSD.
I don't have any opinion on whether R14 and R15 should be saved, but
the justification posted in the top post seems weak.
The stack is already per-process data. One can use _tos for per-proc
data, just like privalloc(2) does.
--
Aram Hăvărneanu
On 19 July 2014 02:57, cinap_len...@felloff.net wrote:
would it make sense to save and restore the two registers
on syscall entry/exit, so userspace programs could make use
of them for per process data?
Good question. None of the others need to be saved and restored because
they are defined
You, 9front developpers, created kbdfs, and
lost kbdputc() in port/devcdons.c. Most of
pc/kbd.c stuffs are driven out to user space, kbdfs.
In lab's or 9atom's distribution, I can have
/rc/bin/Kanji, like:
#!/bin/rc
pipefile -r ktrans /dev/cons
rio -i
On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
_tos only works when every process has
at least one stack always at the same fixed virtual address.
Isn't this always true?
--
Aram Hăvărneanu
1. The history is confined to Plan9.
It is hard to do small fixes (typos, documentation) from another
system.
that's true. but it's easy to get a plan 9 system, or drawterm into one.
in my experience, plan 9 is a system one spends siginficant time in.
i would not want to change the
On Sat Jul 19 10:40:49 EDT 2014, ara...@mgk.ro wrote:
On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
charles.fors...@gmail.com wrote:
_tos only works when every process has
at least one stack always at the same fixed virtual address.
Isn't this always true?
does anyone have a use case
On Sat, Jul 19, 2014 at 11:31 AM, dante subscripti...@posteo.eu wrote:
It is hard to do small fixes (typos, documentation) from another system.
One could argue this is a feature. Everything has to be tested.
I've seen way too many botched patches that purportedly only fixed
documentation. Also,
Hi Eric,
Thanks for your answers! They are really a good start for me with
Plan9.
So, you and the others convinced me that a source management system for
the main system is not really necessary.
What's left from my initial questions is if it won't be a bad idea to
have an integrated contrib
Are you intentionally trying to make plan bureaucratic?
Hello everyone.
I'm turning my NetBSD gateway in a venti server with plan9port. Reading
the list I have saw a lot of considerations about the configuration.
I'll appreciate any information (links to docs?) about setting venti.
The man pages and /sys/doc/venti/ are too much technical for me now!.
Usable, not bureaucratic.
And you don't need to invest work.
Just use it if you like it.
Take a look at how it works now. Is this OK with you?
1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
Why do I need to know about fgb, why not
On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom quans...@quanstro.net wrote:
does anyone have a use case for extern register in user space?
Well Go uses it, but the meaning is different than in the Plan 9
kernel; they reused it for a different storage class.
In Go, there were two external
1. Gather the good packages from the user's directories and other
sources on the net into a central system, like the core Plan9.
There is some work implied to check licenses and get permissions.
Try 9front :)
yes
On 19.07.2014 19:31, hiro wrote:
1. Gather the good packages from the user's directories and other
sources on the net into a central system, like the core Plan9.
There is some work implied to check licenses and get
permissions.
Try 9front :)
Quoting dante subscripti...@posteo.eu:
Usable, not bureaucratic.
Lots of people already use plan 9, therefore it is already
useable.
And you don't need to invest work.
This seems like a load of garbage, since you're already demanding
that other people do work to support your preferences.
1. /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
Why do I need to know about fgb, why not
/n/sources/packages/contrib/rc/bin/contrib/install contrib ?
2. bichued/hg -- 1.0.2
jas/hg-src
mjl/hgfs
stallion/mercurial -- 2.2.3
Which one now?
this is
On Jul 19, 2014, at 8:02 , dante subscripti...@posteo.eu wrote:
My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in the current model.
Okay, it *may* not. But we have no evidence of that. There's no indication that
the current
On Jul 19, 2014 1:17 PM, erik quanstrom quans...@quanstro.net wrote:
[snip]
- having an SSH2 server (there is one in 9atom, but I didn't see
it in the stock Plan9). Are you sure it doesn't have the Heartbleed?
i'm sure it doesn't have heartbleed. code for that sort of renegotiation
On Sat, Jul 19, 2014 at 9:20 PM, Christopher Nielsen cniel...@pobox.com wrote:
Not to mention heartbleed has nothing to do with ssh... It was an
implementation bug in openssl only; it wasn't even a protocol bug.
Yes, OpenSSH doesn't even use OpenSSL.
--
Aram Hăvărneanu
On 19.07.2014 20:17, erik quanstrom wrote:
3. What about
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/ ?
What about the broken links there?
Can we still save that software?
Archive.org?
you may edit the wiki yourself to correct these issues.
The Wiki seems to
The Wiki seems to be frozen (i.e., not editable anymore):
- no Edit button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
- no permissions for /mnt/wiki/software_for_plan9/current (wiki.wiki
444)
edit from plan 9.
- erik
you may edit the wiki yourself to correct these issues.
The Wiki seems to be frozen (i.e., not editable anymore):
- no Edit button on
http://www.plan9.bell-labs.com/wiki/plan9/software_for_Plan_9/
It was changed some time back to allow edits only using
the acme wiki interface, rather
- having an SSH2 server (there is one in 9atom, but I didn't
see it in the stock Plan9).
Geoff included the same ssh implementation as 9atom
has in /sys/src/cmd/ssh2 but with some code clean-up.
So the server code is there. I've been meaning to go
back an reconcile the two different
My whole argument goes about the following hypotheses:
1. increasing the amount of contributions may not scale in
the current model.
2. submitting trivial contributions is not trivial for the contributor.
Both of these points seem to come from a mental model
that just doesn't apply to Plan 9.
ok, i preserve user R14 and R15 now. also removed the saving and restoring
of DS/ES/FS/GS segment registers... they have no effect in long mode and
there are no 32 bit tasks.
someone write a proof of concept program that communicates with another
process by morsing data on the segment registers
Hello,
How should I properly update to the latest kernel on a new install of Plan 9
from Bell Labs?
I downloaded Plan9, ran the pull script, and then tried to compile and
install a new kernel by running mk install in /sys/src/9/pc
Compilation seemed to go fine, but then I got an syscall 53
I downloaded Plan9, ran the pull script, and then tried to compile and
install a new kernel by running mk install in /sys/src/9/pc
Compilation seemed to go fine, but then I got an syscall 53 error (the error
seems to come from ar, see below).
you need to reboot using one of the kernels
36 matches
Mail list logo
