In article ,
Federico G. Benavento wrote:
>isn't this redundant with cpp(1)'s __FUNCTION__?
>
>if __FUNCTION__ isn't standard, then we should change
>it to __func__ in cpp and that's it
I'm not sure what cpp's __FUNCTION__ is, but be careful, as it's
easy to loose some semantics in subtle ways a
* Gary V. Vaughan wrote:
> I have never used sysroot in all that time,
Maybe that's the problem. ;-p
I'm using sysroot all the time, since I don't want to tweak
every single package so that the right pathes are found, at
build- as well as runtime.
W/ sysroot you build and install everything
my bad, I thought cpp(1) implemented __FUNCTION__...
On Thu, Nov 18, 2010 at 11:06 PM, Joel C. Salomon
wrote:
> On 11/18/2010 05:50 PM, Federico G. Benavento wrote:
>> On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon
>> wrote:
>>> Why is __func__ listed as “unwanted”? I’ve found it useful for
On 11/18/2010 05:50 PM, Federico G. Benavento wrote:
> On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon
> wrote:
>> Why is __func__ listed as “unwanted”? I’ve found it useful for some
>> logging functions.
>>
> isn't this redundant with cpp(1)'s __FUNCTION__?
>
> if __FUNCTION__ isn't standard,
isn't this redundant with cpp(1)'s __FUNCTION__?
if __FUNCTION__ isn't standard, then we should change
it to __func__ in cpp and that's it
On Thu, Nov 18, 2010 at 2:30 AM, Joel C. Salomon wrote:
> On 11/14/2010 04:44 PM, Charles Forsyth wrote:
>> the list of unimplemented items in /sys/src/cmd/c
> Why is __func__ listed as “unwanted”? I’ve found it useful for some
> logging functions.
i think the correct interpretation of unwanted in this
context is either don't want or don't want to implement.
one former member of the don't-want list was varadic macros,
which are now supported by both
On 11/14/2010 04:44 PM, Charles Forsyth wrote:
> the list of unimplemented items in /sys/src/cmd/cc/c99* is:
> i can think of something else that's not been noticed, but what other things
> have you found?
Why is __func__ listed as “unwanted”? I’ve found it useful for some
logging functions.
-
On Wed, Nov 17, 2010 at 09:38:46AM +0200, Pavel Zholkover wrote:
> I did a Go runtime port for x86, it is in already in the main hg repository.
> Right now it is cross-compile from Linux for example (GOOS=plan9 8l -s
> when linking. notice the -s, it is required).
>
I have Plan 9 versions of the t
Hi,
I did a Go runtime port for x86, it is in already in the main hg repository.
Right now it is cross-compile from Linux for example (GOOS=plan9 8l -s
when linking. notice the -s, it is required).
There were a few changes made to the upstream so the following patch
is needed until the fix is comm
On Mon, Nov 15, 2010 at 19:32, wrote:
>> I always had the impression that the object formats
>> used by the various ?l are more for kernels and the
>> various formats expected by loaders than for userland
>> apps. For userland, I would think the intent is for
>> there to be a single consistent o
> if you just want go on plan 9, i think object formats
> are a non-sequitor.
>
But that's not it, really, I want both Go and the ELF capabilities :-)
> calling out the guys who wrote plan 9 for not supporting
> object formats that plan 9 never used, seems a bit rude
> to me.
I am willing to apo
> Of course, the ideal situation would be for Go and p9p to converge and
> the whole lot to be back ported to Plan 9.
if you just want go on plan 9, i think object formats
are a non-sequitor.
calling out the guys who wrote plan 9 for not supporting
object formats that plan 9 never used, seems a b
> I always had the impression that the object formats
> used by the various ?l are more for kernels and the
> various formats expected by loaders than for userland
> apps. For userland, I would think the intent is for
> there to be a single consistent object format (at least
> for a given architec
My personal disappointment with autoconf, is that there was no simple
file which the package author writes (or even autgenerates)
describing what features their package depends on.
There is a file, but its anything but simple and as it (ab)uses m4
and shell script macros that it "knows" exist. It
> Even then, many vendor compilers and linkers have many
> non-conformances, and outright bugs. Take a look at the
> number of workarounds that make their way into gnulib to
> cover breakage in the POSIX APIs alone.
>
> You can either try to remember what all of those are, or
> use something like
> to a single underlying (OS) platform, but failed (in a
> suprisingly ugly
> way) to cater for different target object formats, even
> though there were
> efforts to do so. In my opinion - and this is all I
> hold against Plan
> 9 - by shoehorning various target object formats in the
> linker/loa
Dan makes a good point and I agree entirely with his sentiments. But I do
have a qualm: the Plan 9 designers managed to simplify cross-compilation
to a single underlying (OS) platform, but failed (in a suprisingly ugly
way) to cater for different target object formats, even though there were
effor
> *much* rather wait 90 seconds for each build that try to maintain a giant
> tabulation with thousands of entries, which go out of date every time a new
> patch or revision of libc or the compiler or the os or the linker comes along.
there seems to be an affliction in the unix world, that started
On 15 Nov 2010, at 08:02, Enrico Weigelt wrote:
> * Gary V. Vaughan wrote:
>> People like to beat on GNU Libtool, and in some cases that criticism is
>> not undeserved... but in my experience, many critics of the tool come
>> from a perspective of building on a single architecture.
>
> Actually
On Sun, Nov 14, 2010 at 11:29 PM, Gary V. Vaughan wrote:
> You can either try to remember what all of those are, or use something
> like autoconf to probe for known bugs, and gnulib to plug them, or
> you can link against a shim library like GNU libposix which will
> do all of that automatically w
On 15.11.2010 05:29, Gary V. Vaughan wrote:
> On 14 Nov 2010, at 17:50, Carl-Daniel Hailfinger wrote:
>
>> On 14.11.2010 10:10, tlaro...@polynum.com wrote:
>>
>>> Furthermore, the auto* and libtool were typically made
>>> for trying to do something "working" to some extend with a chaotic
>>
On 14 Nov 2010, at 17:50, Carl-Daniel Hailfinger wrote:
> On 14.11.2010 10:10, tlaro...@polynum.com wrote:
>> Furthermore, the auto* and libtool were typically made
>> for trying to do something "working" to some extend with a chaotic
>> source. They typically manage to compile "things" written by
* Gary V. Vaughan wrote:
> People like to beat on GNU Libtool, and in some cases that criticism is
> not undeserved... but in my experience, many critics of the tool come
> from a perspective of building on a single architecture.
Actually, I'm building for lots of different archs almost all the
> > unfortunately, the last i checked, gnu grep mallocs
> > for each byte of input when using a utf-8 locale.
>
> that bug was fixed in gnu grep years ago,
> probably before you found and reported it.
> unfortunately, linux distributions were for
> many years not updating their copies of
> gnu gre
Compound literal support is unimplemented for arrays. Also, most c99
headers are missing, even the simple ones like stdint.h. It seems most of
the work to fix that would be teaching OSTRUCT to work with arrays in
com.c
*dives back into schoolwork*
On Sun, 14 Nov 2010 21:44:07 +, Charles Forsy
>I have successfully avoided using autoconf and similar stuff in my
>projects by adhering to strict C99, but in an ironic twist of fate, Plan
>9 will be the OS that forces me to use something like autoconf due to
>the limited C99 support.
the list of unimplemented items in /sys/src/cmd/cc/c99* is:
> unfortunately, the last i checked, gnu grep mallocs
> for each byte of input when using a utf-8 locale.
that bug was fixed in gnu grep years ago,
probably before you found and reported it.
unfortunately, linux distributions were for
many years not updating their copies of
gnu grep to the latest
On Sun, Nov 14, 2010 at 7:56 AM, Jacob Todd wrote:
> The full standard c library isn't included in a statically linked
> executable. Only what's needed is, at least on plan 9, i have no idea what
> gcc does.
To emphasize this comment: Plan 9 has always done the equivalent of
what gcc recently got
The full standard c library isn't included in a statically linked
executable. Only what's needed is, at least on plan 9, i have no idea what
gcc does.
On Nov 14, 2010 3:14 AM, "Gary V. Vaughan" wrote:
> Hi Erik et. al,
>
> Thanks for the feedback, all.
>
> On 14 Nov 2010, at 13:24, erik quanstrom
> GNU awk is a nice piece of software. The core of
> GNU grep is very well written even if the surrounding
> utility has been embellished a bit too much. Groff is
when mike wrote it, gnu grep was the best thing one
could get if one wasn't at the labs. since brucee started
this, i was in the roo
On Sun, Nov 14, 2010 at 11:50:53AM +0100, Carl-Daniel Hailfinger wrote:
> On 14.11.2010 10:10, tlaro...@polynum.com wrote:
> > Furthermore, the auto* and libtool were typically made
> > for trying to do something "working" to some extend with a chaotic
> > source. They typically manage to compile "
On 14.11.2010 10:10, tlaro...@polynum.com wrote:
> Furthermore, the auto* and libtool were typically made
> for trying to do something "working" to some extend with a chaotic
> source. They typically manage to compile "things" written by
> programmers who have been encouraged to look at the finger
Hello Gary,
On Sun, Nov 14, 2010 at 04:32:34PM +0700, Gary V. Vaughan wrote:
> [...]
>
> Does your build system work correctly with shared libraries in Mingw,
> cygwin, AIX, HP-UX (to name just a few of the more awkward under-
> featured shared library implementations I care about) under various
On 14 Nov 2010, at 16:10, tlaro...@polynum.com wrote:
> Hello,
Hi Thierry,
> On Sun, Nov 14, 2010 at 09:17:46AM +0700, Gary V. Vaughan wrote:
>> [[resent from my subscribed email address after the mailing list rejected
>> the original]]
>>
>> [...]
>> AFAICT, without rewriting the entire GNU b
Hello,
On Sun, Nov 14, 2010 at 09:17:46AM +0700, Gary V. Vaughan wrote:
> [[resent from my subscribed email address after the mailing list rejected the
> original]]
>
> [...]
> AFAICT, without rewriting the entire GNU build system from the ground
> up (and there is far too much momentum behind
Hi Erik et. al,
Thanks for the feedback, all.
On 14 Nov 2010, at 13:24, erik quanstrom wrote:
>> You may well be right that there's too much momentum behind
>> autoconf/automake to change GNU. But that doesn't mean it's the right
>> thing to do, or something sensible people ought to choose to
>>
On Nov 14, 2010, at 1:26, Russ Cox wrote:
[a bunch of very reasonable stuff]
I clearly didn't write that well because Russ just disagreed with me by saying
exactly what I was trying to say: the approaches ask and answer different
questions. My main interest was to point out that the mail Gary
> You may well be right that there's too much momentum behind
> autoconf/automake to change GNU. But that doesn't mean it's the right
> thing to do, or something sensible people ought to choose to
> participate in.
to be a bit more blunt, the argument that the tyrrany of the
auto* is unstoppable
> When I write C code which I intend to be portable, I write against p9p, ...
I don't think this is fair to Gary's well-reasoned mail.
He explicitly said libtool was solving the problem of
providing a single consistent command line tool that
handled the job of building a *shared library* on a
vari
On Nov 13, 2010, at 21:17, Gary V. Vaughan wrote:
> People like to beat on GNU Libtool, and in some cases that criticism is
> not undeserved... but in my experience, many critics of the tool come
> from a perspective of building on a single architecture. If you have
> never tried to build and lin
[[resent from my subscribed email address after the mailing list rejected the
original]]
Hi Enrico,
On 14 Nov 2010, at 02:24, Enrico Weigelt wrote:
> * ron minnich wrote:
>
>> If you're the kind of guy who can't resist changing things that don't
>> need changing, then you won't get it; perhaps
* ron minnich wrote:
> If you're the kind of guy who can't resist changing things that don't
> need changing, then you won't get it; perhaps you'd be better off
> working on libtool. But Plan 9 is far from dead.
Nobody with at least half-sane mind voluntarily works on or even
with libtool ... it
* Charles Forsyth wrote:
> ``My last company switched to nmake, and they're OUT OF BUISINESS :-) :-)
> :-)''
> [fortune]
When it comes to builder systems, I'm still thinking of an more
declarative approach: describing the software's structure by
certain object types and their relations (eg. we
brucee has a t-shirt press.
fun - $5 - 5 minutes (mate's rates). cinap has a reversed glenda shirt
to remind him the cars are on the left of the road. he should be
surfing with tiger - waves were a bit scarey for the boy today.
brucee
"GCC makes me wanna smoke crack"
On Tue, Nov 9, 2010 at 2:18
``My last company switched to nmake, and they're OUT OF BUISINESS
:-) :-) :-)''
That line is tee-shirt worthy.
There are places you can get custom t-shirts made for a reasonable fee,
so you should be able to have one made ;-)
On Nov 8, 2010, at 4:33 PM, Charles Forsyth wrote:
> ``My last company switched to nmake, and they're OUT OF BUISINESS :-) :-)
> :-)''
That line is tee-shirt worthy.
a more than fair justification.
brucee
On Tue, Nov 9, 2010 at 9:22 AM, Charles Forsyth wrote:
>> but it seemed better just to port mk itself.
>
> the intention was to support building both inside and outside the Inferno
> environment,
> and neither sh nor mash were going to be as easy to reprod
>the intention was to support building both inside and outside the Inferno
>environment,
oh. and just like Plan 9 mkfile's and for the same reason, Inferno's mkfiles
were
essentially concise lists of the names of inputs and the names of outputs, with
few instructions,
which suited my little bra
> but it seemed better just to port mk itself.
the intention was to support building both inside and outside the Inferno
environment,
and neither sh nor mash were going to be as easy to reproduce
outside Inferno as simply making mk work (more or less) inside Inferno.
that action alone wasn't inte
that doesn't describe mash at all. my talk at IWP9 hinted on the functionality.
the first advice i was given when i started on inferno was not to port
everything in sight - think forward. fixing the awkward and backward
syntax and semantics of rc+mk, and the replication, was the
intention..
bruce
On 5 November 2010 19:06, erik quanstrom wrote:
>> > ('&', '&&', '||', if, '|', 'and '`{}') with something general
>> > enough to replace mk, you'd be on to something.
>>
>> i did a mash-inspired version of mk as an inferno shell module once.
>> it required no new syntax (although it could be conf
On Saturday 06 of November 2010 03:20:55 Bruce Ellis wrote:
> i can answer that one easily. that's why it's called mash rather than
> "random marketting name". the intention was to replace plan9 rc with a
> shell that was maintainable and had loadable modules. i wrote it in
> limbo to show it works
i can answer that one easily. that's why it's called mash rather than
"random marketting name". the intention was to replace plan9 rc with a
shell that was maintainable and had loadable modules. i wrote it in
limbo to show it works, damned well. the first requirement was a make
loadable. it's not b
> A honest question: what is the rationale for merging functionality of make and
> shell into one?
at the time, people were pushing more and more scripting or programming language
functionality into accretions of the original make, and someone observed that
it might be better
instead to put a sma
On Fri, Nov 5, 2010 at 12:07 PM, dexen deVries wrote:
> On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote:
>> Quite right:
>> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
>>
>> Although, no doubt brucee has a new, improved version not fit for mere
>> mort
> > ('&', '&&', '||', if, '|', 'and '`{}') with something general
> > enough to replace mk, you'd be on to something.
>
> i did a mash-inspired version of mk as an inferno shell module once.
> it required no new syntax (although it could be confused by
> files named ":"...)
what you did was very
On Thu, 04 Nov 2010 22:20:04 - Charles Forsyth
wrote:
> >But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfil
> e and acid)
> >at least as long as all that Java in the ant distribution (213151 lines)?
> >That's a lot of catching up to do.
> >The market has clearly spo
On 5 November 2010 18:14, erik quanstrom wrote:
>> > -- and then traversing it in a sensible order. How's that for daily use
>> > shell?
>> >
>> >
>> Why is a shell that can generate acyclic digraphs of dependencies bad?
>> Someone clearly found a use for it at some point or it wouldn't have been
> > -- and then traversing it in a sensible order. How's that for daily use
> > shell?
> >
> >
> Why is a shell that can generate acyclic digraphs of dependencies bad?
> Someone clearly found a use for it at some point or it wouldn't have been
> done.
it is silly bloat if it's not an essential pa
On Friday 05 of November 2010 18:39:14 andrey mirtchovski wrote:
> > To me, make is a tool for generating an acyclic, directed graph of
> > dependencies between build steps from some explicit and some wildcard
> > rules -- and then traversing it in a sensible order. How's that for
> > daily use sh
On Fri, Nov 5, 2010 at 10:32 AM, dexen deVries wrote:
> On Friday 05 of November 2010 18:18:44 Nick LaForge wrote:
> > > A honest question: what is the rationale for merging functionality of
> > > make and shell into one?
> >
> > Use your imagination
>
> Tried, failed.
> To me, make is a tool
> To me, make is a tool for generating an acyclic, directed graph of
> dependencies between build steps from some explicit and some wildcard rules
> -- and then traversing it in a sensible order. How's that for daily use shell?
your focus is too narrowed on building. a sequence of commands piping
On Friday 05 of November 2010 18:18:44 Nick LaForge wrote:
> > A honest question: what is the rationale for merging functionality of
> > make and shell into one?
>
> Use your imagination
Tried, failed.
To me, make is a tool for generating an acyclic, directed graph of
dependencies between b
> A honest question: what is the rationale for merging functionality of make and
> shell into one?
Use your imagination
Nick
On Friday 05 of November 2010 14:31:01 Eric Van Hensbergen wrote:
> Quite right:
> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
>
> Although, no doubt brucee has a new, improved version not fit for mere
> mortals to gaze upon.
A honest question: what is the rationale
> http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
that one is indeed fairly old, much as we received it, except for
changes to fit any changes in the environment, but
http://www.vitanuova.com/inferno/man/1/mash.html
and
http://www.vitanuova.com/inferno/man/1/mash-m
Quite right:
http://code.google.com/p/inferno-os/source/browse/#hg/appl/cmd/mash
Although, no doubt brucee has a new, improved version not fit for mere
mortals to gaze upon.
-eric
On Fri, Nov 5, 2010 at 2:55 AM, Bruce Ellis wrote:
> no. it was the last thing i wrote for the bidness u
no. it was the last thing i wrote for the bidness unit.
brucee
On Fri, Nov 5, 2010 at 6:11 PM, Lucio De Re wrote:
> On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote:
>>
>> mash has a make builtin. very brief, as all the shell type stuff in mk
>> goes away..
>>
> I seem to remember tha
On Fri, Nov 05, 2010 at 02:50:22PM +1100, Bruce Ellis wrote:
>
> mash has a make builtin. very brief, as all the shell type stuff in mk
> goes away..
>
I seem to remember that the mash source was lost?
++L
mash has a make builtin. very brief, as all the shell type stuff in mk
goes away..
brucee
On Fri, Nov 5, 2010 at 12:41 PM, Venkatesh Srinivas wrote:
>> one interesting thing about that example is that if it were done again
>> for the Plan 9 environment, mk might well be even smaller, since
>> so
>
> one interesting thing about that example is that if it were done again
> for the Plan 9 environment, mk might well be even smaller, since
> some of the existing functionality isn't really used,
> or might be achieved by simpler mechanisms, or with functionality
> added instead by further compos
>But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfile
>and acid)
>at least as long as all that Java in the ant distribution (213151 lines)?
>That's a lot of catching up to do.
>The market has clearly spoken, and it appears that more lines dominates the
>soup.
one interes
On Thu, Nov 4, 2010 at 9:00 AM, erik quanstrom wrote:
> > On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov >wrote:
> >
> > > I'm looking at
> > >
> > > http://plan9.bell-labs.com/sources/plan9/sys/src/
> > >
> > > and I noticed that most of the distribution hasn't been updated in
> > > years.
> > >
On Thu, Nov 4, 2010 at 6:19 PM, andrey mirtchovski wrote:
> > Some people prefer privacy, others are just assholes who want to pick
> fights
> > because they are bored.
> >
> > Asking a perfectly valid question is not trolling, unlike your reply that
> > adds nothing to the subject at hand.
>
> so
> Some people prefer privacy, others are just assholes who want to pick fights
> because they are bored.
>
> Asking a perfectly valid question is not trolling, unlike your reply that
> adds nothing to the subject at hand.
so, no bait and switch then? was your question answered satisfactorily?
On Nov 4, 2010, at 11:39 AM, ron minnich wrote:
> If you're the kind of person who understands that we don't need to
> change 'cat' any further, then you understand the work that is going
> on.
But why isn't the source for mk (3929 lines w/ headers, okay 4661 with mkfile
and acid) at least as l
On Thu, Nov 4, 2010 at 1:48 PM, Venkatesh Srinivas wrote:
> In the ~8 years since the 4th edition release, there has been pretty
> continuous work on Plan 9, both at Bell Labs and in the 9fans community;
> nightly an ISO is constructed and uploaded. Changes have been incremental --
> a tool appea
On Thu, Nov 4, 2010 at 5:00 PM, erik quanstrom wrote:
> > On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov >wrote:
> >
> > > I'm looking at
> > >
> > > http://plan9.bell-labs.com/sources/plan9/sys/src/
> > >
> > > and I noticed that most of the distribution hasn't been updated in
> > > years.
> > >
Request to add "If you're the kind of person who understands that we
don't need to change 'cat' any further, then you understand the work
that is going on." to fortune.
Ron++
D
On Thu, Nov 4, 2010 at 10:39 AM, ron minnich wrote:
> ignoring the troll, but for the rest of you here: plan 9 is *ver
On Thu, Nov 4, 2010 at 11:01 AM, John Floren wrote:
>
> Watch Ron's repository, which Venkatesh posted earlier.
> http://bitbucket.org/rminnich/sysfromiso
On Thu, Nov 4, 2010 at 11:39 AM, ron minnich wrote:
>
> sysfromiso makes that clear. It's a great way to watch the
> improvements going in. H
ignoring the troll, but for the rest of you here: plan 9 is *very* active.
If you're the kind of person who understands that we don't need to
change 'cat' any further, then you understand the work that is going
on.
If you're the kind of guy who can't resist changing things that don't
need changin
On Thu, Nov 4, 2010 at 10:39 AM, David Leimbach wrote:
>
> There's a plan9changes google group I believe that will let you see the
> commits that have been going in.
http://groups.google.com/group/plan9changes/topics
doesn't show any updates since July, 2008.
Is there another way to track updat
On Thu, Nov 4, 2010 at 11:55 AM, Stanley Lieber
wrote:
> On Thu, Nov 4, 2010 at 10:39 AM, David Leimbach wrote:
>>
>> There's a plan9changes google group I believe that will let you see the
>> commits that have been going in.
>
> http://groups.google.com/group/plan9changes/topics
>
> doesn't show
> On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov wrote:
>
> > I'm looking at
> >
> > http://plan9.bell-labs.com/sources/plan9/sys/src/
> >
> > and I noticed that most of the distribution hasn't been updated in
> > years.
> > Is the development of plan 9 abandoned?
> >
> >
> There's a plan9changes g
On Thu, Nov 4, 2010 at 2:36 AM, Admiral Fukov wrote:
> I'm looking at
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/
>
> and I noticed that most of the distribution hasn't been updated in
> years.
> Is the development of plan 9 abandoned?
>
>
There's a plan9changes google group I believe th
In the ~8 years since the 4th edition release, there has been pretty
continuous work on Plan 9, both at Bell Labs and in the 9fans community;
nightly an ISO is constructed and uploaded. Changes have been incremental --
a tool appears, bugs are fixed, etc..
http://acm.jhu.edu/git/plan9 has a git tr
On Thu, Nov 04, 2010 at 09:36:11AM +, Admiral Fukov wrote:
> I'm looking at
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/
>
> and I noticed that most of the distribution hasn't been updated in
> years.
> Is the development of plan 9 abandoned?
Please note the timestamps in listings
Unlike many open source systems, plan 9 is stable. Very reliable. It doesn't
get changed just for fun.
iPhone email
On Nov 4, 2010, at 5:43 AM, "Admiral Fukov" wrote:
> I'm looking at
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/
>
> and I noticed that most of the distribution hasn
> and I noticed that most of the distribution hasn't been updated in
> years.
> Is the development of plan 9 abandoned?
No it is not, a lot, depends on which file(s) you are looking at.
There has been much work recently on the ARM port (guru plug and beagleboard)
Other changes happen as required (
On Thu, Nov 04, 2010 at 09:36:11AM +, Admiral Fukov wrote:
> I'm looking at
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/
>
> and I noticed that most of the distribution hasn't been updated in
> years.
> Is the development of plan 9 abandoned?
Why fix what's perfect? ;-)
++L
I'm looking at
http://plan9.bell-labs.com/sources/plan9/sys/src/
and I noticed that most of the distribution hasn't been updated in
years.
Is the development of plan 9 abandoned?
91 matches
Mail list logo
