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 http://9fans.net/archive/2014/02/1
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 distri
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 (ty
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 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 wrote:
>>>
>>> Yet
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 following
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
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, 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 to be dead on entry t
> 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
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 s
On Sat Jul 19 10:40:49 EDT 2014, ara...@mgk.ro wrote:
> On Sat, Jul 19, 2014 at 2:42 PM, Charles Forsyth
> 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 for extern registe
On Sat, Jul 19, 2014 at 11:31 AM, dante 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, how do you write docume
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
"/n/sources/packages/contrib/rc/bin/c
On Sat, Jul 19, 2014 at 4:55 PM, erik quanstrom 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 register variables, g and
> 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 :
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.
This all changed
> 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
On Jul 19, 2014, at 8:02 , dante 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 distribution model represe
On Jul 19, 2014 1:17 PM, "erik quanstrom" 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
> was never
On Sat, Jul 19, 2014 at 9:20 PM, Christopher Nielsen 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 b
> 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, ra
> - 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
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 by
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 e
> 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 k
36 matches
Mail list logo
