would be nice to put all the hardware support together.
That would be wonderful. But it does require resources to deal with
incompatibilities as well as different perception of value. My angle
her is that I'm mostly working with obsolete equiopment and I am
extremely reluctant to watch Plan 9
On 8 May 2014 02:38, Kurt H Maier k...@sciops.net wrote:
haha you said exactly the same thing
I confined myself to instructions relating to sources, which isn't mine.
On Thu May 8 01:57:57 EDT 2014, lu...@proxima.alt.za wrote:
would be nice to put all the hardware support together.
That would be wonderful. But it does require resources to deal with
incompatibilities as well as different perception of value. My angle
her is that I'm mostly working with
Now, this is incompatible with the original Soundblaster stuff and no
one seems to care to deal with the incompatibilities.
wrong. it has been dealed with.
--
cinap
Now, this is incompatible with the original Soundblaster stuff and no
one seems to care to deal with the incompatibilities.
wrong. it has been dealed with.
Not in the Bell Labs distribution, it hasn't. At least, not that I noticed.
And that was just a convenient example.
++L
We are losing the 'reference implementation' from which the branches can be
compared.
But is this a necessary consequemce of Bell Labs' distance, or merely
the way the community operates? A reference point need not itself be
in use by all involved, it just needs to move slowly enough for a
On Thu May 8 07:59:12 EDT 2014, lu...@proxima.alt.za wrote:
We are losing the 'reference implementation' from which the branches can be
compared.
But is this a necessary consequemce of Bell Labs' distance, or merely
the way the community operates? A reference point need not itself be
On Thu May 8 07:22:41 EDT 2014, lu...@proxima.alt.za wrote:
Now, this is incompatible with the original Soundblaster stuff and no
one seems to care to deal with the incompatibilities.
wrong. it has been dealed with.
Not in the Bell Labs distribution, it hasn't. At least, not that I
It is this ongoing level of petty pissiness that has led to the fragmentation
of the community.
It's poorly phrased and even offensive, but the answer is not out
there in the public domain. Nor is the list of tasks to be undertaken
in the shape for a GSOC project.
But maybe, just maybe, if
since it's not clear to me from reading this (forgive my reading
comprehension),
i run 9atom on rb, kw, and rpi in addition to amd64. i run the pc and pcpae
kernels when there are changes. i know others also run 9atom on the rb.
sadly i don't have a teg2 or original beagle.
One can
so, someone (cinap) does care about the incompatabilities and has addressed
them.
i think what you're saying is nobody has gotten this in to the distribution.
fair point. why don't you submit a patch?
I ought to, I'm not sure how soon I'll get to it (I'm just a normal
Joe, I also fix
On 8 May 2014 13:46, lu...@proxima.alt.za wrote:
not enough Internet credits to sustain efforts ...
Or a working e-mail supplier (they've blocked Google):
Delivery to the following recipient failed permanently:
lu...@proxima.alt.za
Technical details of permanent failure:
Google tried
But maybe, just maybe, if the community can get its act together to
support a codereview type approach, we can ask Coraid to sponsor the
minimum resources required by it. I don't have a clue to the details,
but I would be thrilled to contribute.
i think you're suggesting using some sort of
Quoting Charles Forsyth charles.fors...@gmail.com:
On 8 May 2014 13:46, lu...@proxima.alt.za wrote:
not enough Internet credits to sustain efforts ...
Or a working e-mail supplier (they've blocked Google):
This is what happens when people vote for Julius Malema.
khm
Quoting erik quanstrom quans...@quanstro.net:
for what it's worth, i review all the changes made to plan 9 and 9front
and apply what makes sense.
Some subset of the 9front people also do this with various publicly-
available resources, like 9changes and 9atom. I'm not sure of the
value of a
Delivery to the following recipient failed permanently:
My fault, my spam rules reject and ban IP addresses if mail is sent to
a non-existent recipient in the proxima.alt.za domain. I have
whitelisted a block of gmail IPs, but that's a moving target.
Should be fixed now.
++L
On Wed May 7 21:40:05 EDT 2014, k...@sciops.net wrote:
Quoting Charles Forsyth charles.fors...@gmail.com:
they weren't shot down, but saying use MY distribution over here,
or use MY distribution over here,
what i said was that both 9front and 9atom have the relevant bits in
an easily
This is what happens when people vote for Julius Malema.
How do you know this?
++L
When Charles brought up that 64bit binaries can be built from Labs
distribution, it would have been so much simple if either 9atom or
9front owners took a quick look at what was there and confirmed what
he meant by binaries.
To a lot of lurkers it's still not clear what the labs amd64 binaries
On 8 May 2014 15:14, balaji balaji.srinivasa+pl...@gmail.com wrote:
To a lot of lurkers it's still not clear what the labs amd64 binaries
are. bootable kernel? commands?
it turned out that it didn't include any of it, except the compilers. i am
attempting to address
this oversight.
On 8 May 2014 15:51, lu...@proxima.alt.za wrote:
That's the result of bad thinking by
the Internet's fathers
you blame the parents?
you blame the parents?
I've been known to. In this case, I do think the stage was set,
rather than grabbed. Of course, opinions are allowed to differ.
++L
On Thu, May 8, 2014 at 7:55 AM, Kurt H Maier k...@sciops.net wrote:
thing, javascript is not a thing that happens on this operating system.
Here is a screenshot of a javascript interpreter running on plan 9.
https://github.com/robertkrimen/otto
Quoting Jeremy Jackins jeremyjack...@gmail.com:
On Thu, May 8, 2014 at 7:55 AM, Kurt H Maier k...@sciops.net wrote:
thing, javascript is not a thing that happens on this operating system.
Here is a screenshot of a javascript interpreter running on plan 9.
https://github.com/robertkrimen/
I'm not trying to weigh in on the discussion. I posted the link in case
someone in the community is interested. This software has only been working
on plan 9 since fairly recently, thanks to a lot of hard work on the Go
port from a few members of this community.
You just have to apply the following patches (from Nix):
Thank you, that worked well (so far, the build is still running),
although I have a spim (0) object type in my mkfile.proto that threw a
(small) spanner in the works.
++L
Out of curiosity is there a reason that the patches for a 64bit install
never ended up in the main plan9 codebase?
On 7 May 2014 06:14, lu...@proxima.alt.za wrote:
The Bell Labs distribution does not seem to have a libc/amd64. It's a
bit of a show stopper. I could also be mistaken and a different amd64
is being looked for.
I did not know that. I've attached a tar file, of what I'm using.
I'll compare
On 7 May 2014 09:38, Riddler riddler...@gmail.com wrote:
Out of curiosity is there a reason that the patches for a 64bit install
never ended up in the main plan9 codebase?
The full story is much more complicated, but briefly, the switch to 64 bits
offered a chance to revisit the kernel
+++ /sys/src/ape/lib/ap/amd64/atom.s
@@ -0,0 +1,75 @@
+TEXT ainc(SB), $0 /* long ainc(long *); */
+ MOVLaddr+0(FP), BX
the comment is wrong. it's int ainc(int*)
further down the definition of casp, cas64 is really wrong.
(it only considers the low 32-bits)
also why have atom.s in
On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote:
the comment is wrong. it's int ainc(int*)
h% grep ainc /sys/include/libc.h
long ainc(long*);
h% grep ainc /n/sources/plan9/sys/include/libc.h
long ainc(long*);
On Wed May 7 04:47:05 EDT 2014, charles.fors...@gmail.com wrote:
On 7 May 2014 06:14, lu...@proxima.alt.za wrote:
The Bell Labs distribution does not seem to have a libc/amd64. It's a
bit of a show stopper. I could also be mistaken and a different amd64
is being looked for.
I did
On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote:
the comment is wrong. it's int ainc(int*)
h% grep ainc /sys/include/libc.h
long ainc(long*);
h% grep ainc /n/sources/plan9/sys/include/libc.h
long ainc(long*);
shouldn't that be aincl? these definitions were added
I see that I had better explain. I am yan cui's mentor for GSoC on a
particular project that is starting with some
code that I wrote, and it will greatly assist me initially if he and I are
using the same basic source code for
the system and the kernel. Sources provides a conservative base for the
On Wed May 7 05:21:03 EDT 2014, charles.fors...@gmail.com wrote:
I see that I had better explain. I am yan cui's mentor for GSoC on a
particular project that is starting with some
code that I wrote, and it will greatly assist me initially if he and I are
using the same basic source code for
also why have atom.s in ape?
This is what was done on 386.
/n/sources/plan9/sys/src/ape/lib/ap/386/atom.s
--
David du Colombier
On Wed May 7 05:24:00 EDT 2014, 0in...@gmail.com wrote:
also why have atom.s in ape?
This is what was done on 386.
/n/sources/plan9/sys/src/ape/lib/ap/386/atom.s
that begs the question. why put the atom functions in ape
for any architecture?
- erik
You just have to apply the following patches (from Nix):
hget http://www.9legacy.org/9legacy/patch/amd64.diff | ape/patch -p0
hget http://www.9legacy.org/9legacy/patch/amd64-fix.diff | ape/patch -p0
I should have commented further. The first patch is a copy from the
original Nix files written
!/bin/upas/marshal -s 'Re: [9fans] [GSOC] plan9 which arch code to use?' -R
/mail/fs/mbox/1815 9fans@9fans.net
On 7 May 2014 10:05, erik quanstrom quans...@quanstro.net wrote:
the comment is wrong. it's int ainc(int*)
h% grep ainc /sys/include/libc.h
long ainc(long*);
h
I should have commented further. The first patch is a copy from the
original Nix files written by jmk. The second is an attempt to synchronize
with the changes made in Plan 9 on September 2013.
Based entirely on these patches, plus a little tweaking because I've
updated APE to be closer to
On 7 May 2014 12:13, lu...@proxima.alt.za wrote:
I haven't yet checked Charles' posting.
that won't have anything to do with wider APE support.
Quoting Charles Forsyth charles.fors...@gmail.com:
I see that I had better explain. I am yan cui's mentor for GSoC on a
particular project that is starting with some
code that I wrote, and it will greatly assist me initially if he and I are
using the same basic source code for
the system and
On 7 May 2014 13:59, Kurt H Maier k...@sciops.net wrote:
Sorry, wasn't aware this is an SP9SSS affair.
nothing secret; just what happened.
On Wed May 7 07:15:46 EDT 2014, lu...@proxima.alt.za wrote:
I should have commented further. The first patch is a copy from the
original Nix files written by jmk. The second is an attempt to synchronize
with the changes made in Plan 9 on September 2013.
Based entirely on these patches,
On Wed May 7 09:37:51 EDT 2014, charles.fors...@gmail.com wrote:
On 7 May 2014 13:59, Kurt H Maier k...@sciops.net wrote:
Sorry, wasn't aware this is an SP9SSS affair.
nothing secret; just what happened.
so, asking myself as well as the list, what steps can we
take to prevent working
could explain why these patches made sense for you rather
than the atom stuff?
Mostly just a mixture of arrogance and ineptitude that says I want to
do this my way?
For real, I can't resist a convergence challenge. The image I had in
my mind was of an amd64 environment within the Bell Labs
Mostly just a mixture of arrogance and ineptitude that says I want to
do this my way?
For real, I can't resist a convergence challenge. The image I had in
my mind was of an amd64 environment within the Bell Labs release
(i386) that would allow me to build either 9atom or 9front releases
if everybody does their own thing, perhaps we spend all our collective
time doing the same thing, and no progress is made?
Most of the duplicated effort never seems to make it out
to the public, so for users, the point is often moot.
The forks of Plan 9 exist mainly because people want to
run
On Wed May 7 14:33:08 EDT 2014, s...@9front.org wrote:
if everybody does their own thing, perhaps we spend all our collective
time doing the same thing, and no progress is made?
Most of the duplicated effort never seems to make it out
to the public, so for users, the point is often moot.
The forks of Plan 9 exist mainly because people want to
run Plan 9 on their computers.
would be nice to put all the hardware support together.
It's all available for anyone to take from the public
repositories. I don't think any of the forks have placed
additional restrictions on what can be
would be nice to put all the hardware support together.
It's all available for anyone to take from the public
repositories. I don't think any of the forks have placed
additional restrictions on what can be done with their
changes.
Enjoy.
you're missing my point. it's not particularly
you're missing my point. it's not particularly useful as a tinker-toy
set. especially when there are 10 wheels and 1 stick.
What I know is that I turn on my Thinkpad x230 and everything
works. After the boot process finishes I just carry on with my
work.
sl
On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote:
you're missing my point. it's not particularly useful as a tinker-toy
set. especially when there are 10 wheels and 1 stick.
What I know is that I turn on my Thinkpad x230 and everything
works. After the boot process finishes I just
Who would you like to volunteer to do all of this work, that's what it
seems like you're trying to do.
On May 7, 2014 4:09 PM, erik quanstrom quans...@quanstro.net wrote:
On Wed May 7 16:00:21 EDT 2014, s...@9front.org wrote:
you're missing my point. it's not particularly useful as a
What I know is that I turn on my Thinkpad x230 and everything
works. After the boot process finishes I just carry on with my
work.
sure that's fine. but if everyone does that, plan 9 will fall into disrepair,
because nobody's willing to do the work.
What are you talking about? If everyone
[Without picking on or singling out anyone ...]
Who would you like to volunteer to do all of this work, that's what it seems
like you're trying to do.
It is this ongoing level of petty pissiness that has led to the fragmentation
of the community.
It's also the reason the folks at the Labs
Why is this controversial?
Because you're missing the point, and arguing against a position nobody holds.
Absolutely nobody here is suggesting that everyone going off and doing their
own thing and keeping the results to themselves is better than everyone going
off and doing their own thing
On May 7, 2014, at 2:17 PM, Anthony Sorace a...@9srv.net wrote:
What some folks are suggesting is that some coordination would yield better
results; that we can do better than the everyone going off and doing their
own thing part of the above scenarios.
I believe Erik's point about
Why is this controversial?
Because you're missing the point, and arguing against a
position nobody holds.
The original post (in its way) was asking for advice about
an amd64 kernel that is not publicly available. Some people
(not knowing the full situation) offered advice about publicly
On 7 May 2014 22:38, s...@9front.org wrote:
. Some people
(not knowing the full situation) offered advice about publicly
available amd64 kernels and were shot down.
they weren't shot down, but saying use MY distribution over here,
or use MY distribution over here, didn't directly help with
Dan Brown
low blow
(come to mention it, i did Dan Brown a favour last year, unwittingly.)
There you go again. More secrets :-)
sl said:
The original post (in its way) was asking for advice about
an amd64 kernel that is not publicly available.
No, it wasn't. There was some confusion over the point that
Plan 9, unlike some other systems, selects the arch based
entirely on the running kernel (no 386 binaries running on
On 7 May 2014 22:38, s...@9front.org wrote:
Maybe the
code is not really secret, but is instead held up somewhere
in the coordination process.
For years, and years, and years at a time.
It's worth remembering that the only reason there was ANY available
code for the amd64, and initial
No, it wasn't. There was some confusion over the point that
Plan 9, unlike some other systems, selects the arch based
entirely on the running kernel (no 386 binaries running on
amd64 machines).
Do you recall the reason this guy is even trying to install
Plan 9?
Kernel hacking.
Once he
It's worth remembering that the only reason there was ANY
available code for the amd64, and initial kernel code to
boot, was because
Thank you Charles, and everyone else involved. Because of your
contributions I'm able to run cinap's pc64 kernel on my x86_64
machines.
I'll say this again just
Why is this stuff always so difficult?
because on the internet nobody does relax.
(1) the amd64 compiler suite, (2) the source for the amd64-specific bits of
the library,
(3) the modifications to make the whole source compile and run in 64 bits
(and not just amd64 but any one), (4) the source for the prototype amd64
kernel,
(5) the source for the several versions of the
Quoting Charles Forsyth charles.fors...@gmail.com:
they weren't shot down, but saying use MY distribution over here,
or use MY distribution over here,
haha you said exactly the same thing
I have every intention of making my efforts available to everyone,
should I have even just a remote chance of success. More importantly,
what I'm trying to do is to reduce differences, rather than increase
them.
Now, I note that by adding the amd64 stuff to an already modified
version of the
Dear all,
I was confused by one experiment which is done today.
My machine is x86_64 and I run Plan9 inside KVM. According to my
understanding, operating system should detect which hardware platform it is
running (x86, sparc, etc) and automatically invoke
corresponding arch-dependent codes.
official plan9 has no amd64 kernel in the distribution.
use 9atom or 9front.
--
cinap
On 6 May 2014 22:00, yan cui ccuiy...@gmail.com wrote:
But, when I echo $cputypes,
it is 386!
where the hardware can do either, the kernel you boot chooses the cputype
to suit itself.
/sys/src/9/pc is only 386 (ie, 32-bit x86). another directory is used for
amd64 (ie, 64-bit x86).
you can use
Got it, Thanks Cinap!
2014-05-06 17:33 GMT-04:00 cinap_len...@felloff.net:
official plan9 has no amd64 kernel in the distribution.
use 9atom or 9front.
--
cinap
--
Think big; Dream impossible; Make it happen.
OK, I will try to do that.
2014-05-06 17:47 GMT-04:00 Charles Forsyth charles.fors...@gmail.com:
On 6 May 2014 22:00, yan cui ccuiy...@gmail.com wrote:
But, when I echo $cputypes,
it is 386!
where the hardware can do either, the kernel you boot chooses the cputype
to suit itself.
On 6 May 2014 22:47, Charles Forsyth charles.fors...@gmail.com wrote:
you can use the 386 kernel to compile and install the /amd64 environment
though,
which you'll need to do before running an amd64 kernel.
more precisely, do
cd /sys/src
objtype=amd64 mk install
On 6 May 2014 22:56, Charles Forsyth charles.fors...@gmail.com wrote:
more precisely, do
cd /sys/src
objtype=amd64 mk install
actually, i use
cd /sys/src; objtype=amd64 mk -k install
so that if something's broken, it will build as much as it can.
nobody expects the spanish inquisition :)
--
cinap
Quoting yan cui ccuiy...@gmail.com:
My machine is x86_64 and I run Plan9 inside KVM.
The architecture of the hypervisor has little bearing on the architecture
of the KVM guest environment. Check your kvm configuration (or the options
passed to the qemu process) to see which cpu has been
On Tue May 6 18:26:58 EDT 2014, ccuiy...@gmail.com wrote:
Dear all,
I was confused by one experiment which is done today.
My machine is x86_64 and I run Plan9 inside KVM. According to my
understanding, operating system should detect which hardware platform it is
running (x86, sparc,
On 7 May 2014 01:40, erik quanstrom quans...@quanstro.net wrote:
your options are 9atom or 9front.
well no, no they aren't.
Quoting Charles Forsyth charles.fors...@gmail.com:
On 7 May 2014 01:40, erik quanstrom quans...@quanstro.net wrote:
your options are 9atom or 9front.
well no, no they aren't.
exactly what value is that comment supposed to add to anyone's day
your options are 9atom or 9front.
well no, no they aren't.
What are the other options?
sl
On 7 May 2014 02:12, Kurt H Maier k...@sciops.net wrote:
well no, no they aren't.
exactly what value is that comment supposed to add to anyone's day
sorry, i meant that isn't the full set of relevant choices.
mkdir -p /amd64/bin/^(ape auth aux bitsy dial disk fossil fs games ip ndb
oventi pub replica upas usb venti aux/jot aux/style ip/httpd) /amd64/lib/ape
The Bell Labs distribution does not seem to have a libc/amd64. It's a
bit of a show stopper. I could also be mistaken and a different amd64
is
The Bell Labs distribution does not seem to have a libc/amd64.
You just have to apply the following patches (from Nix):
hget http://www.9legacy.org/9legacy/patch/amd64.diff | ape/patch -p0
hget http://www.9legacy.org/9legacy/patch/amd64-fix.diff | ape/patch -p0
--
David du Colombier
86 matches
Mail list logo
