Discussion:
[9fans] gcc on plan9
(too old to reply)
Corey
2006-06-07 18:02:31 UTC
Permalink
Two questions - quite likely naive, so please be kind!

#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?

#2 - I've been daydreaming about seeing whether I
could get GNUstep ported to plan9, but I'm still curently
way too unfamiliar w/ plan 9 to assess how realistic/possible
that would be - someone else in another thread recently asked:

"If you have gcc on plan 9, will simply compiling the unix code work?"

I'm basically wondering the same thing.


Thanks for the help!
Roman Shaposhnick
2006-06-07 18:25:27 UTC
Permalink
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
The gcc source code is pretty messy. But let me ask you
a different question -- what exactly do you want to
achieve with gcc ?
Post by Corey
"If you have gcc on plan 9, will simply compiling the unix code work?"
It might, but IMHO it'll defeat the purpose.

Thanks,
Roman.
Latchesar Ionkov
2006-06-07 18:36:56 UTC
Permalink
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
It's in my TODO list. It shouldn't be too difficult.

Thanks,
Lucho
Ronald G Minnich
2006-06-07 18:52:48 UTC
Permalink
Post by Roman Shaposhnick
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
The gcc source code is pretty messy. But let me ask you
a different question -- what exactly do you want to
achieve with gcc ?
Let me raise my hand.

I want to run MPQC, which can not ever be compiled with 8c. Or one of
about 1,000 other apps that need gcc. Port one app, solve it once. Port
gcc, solve it 1,000 times.
Post by Roman Shaposhnick
Post by Corey
"If you have gcc on plan 9, will simply compiling the unix code work?"
It might, but IMHO it'll defeat the purpose.
no, I don't completely agree. We need gcc for general use, period.
Unless we like living in a cardboard box in an alley forever.

ron
William Josephson
2006-06-07 18:58:16 UTC
Permalink
Post by Ronald G Minnich
no, I don't completely agree. We need gcc for general use, period.
Unless we like living in a cardboard box in an alley forever.
Are you mostly concerned about support for gcc language extensions
or about support for things like C++?
Roman Shaposhnick
2006-06-07 19:09:34 UTC
Permalink
Post by Ronald G Minnich
Post by Roman Shaposhnick
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
The gcc source code is pretty messy. But let me ask you
a different question -- what exactly do you want to
achieve with gcc ?
Let me raise my hand.
By all means :-)
Post by Ronald G Minnich
I want to run MPQC, which can not ever be compiled with 8c.
So, is it mostly a backend or a frontend problem ?
Post by Ronald G Minnich
Or one of about 1,000 other apps that need gcc.
Could you, please, elaborate on what exactly these apps
need from gcc ?
Post by Ronald G Minnich
Port one app, solve it once. Port gcc, solve it 1,000 times.
I don't really think that with a difference in evironment
between Linux and Plan9 the later holds true.
Post by Ronald G Minnich
Post by Roman Shaposhnick
It might, but IMHO it'll defeat the purpose.
no, I don't completely agree. We need gcc for general use, period.
Sorry, I just fail to see how porting gcc would help. Hence
to make this discussion a bit more concrete could you, please,
be more specific about what exact gcc functionality do you think
would be beneficial to native Plan9 ?

Thanks,
Roman.
Roman Shaposhnick
2006-06-07 19:10:17 UTC
Permalink
Post by Latchesar Ionkov
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
It's in my TODO list. It shouldn't be too difficult.
Does it include things like g++/gfortran/etc. ? What
backends are you interested in supporting ? What linker
do you intend to use ?

Thanks,
Roman.
Latchesar Ionkov
2006-06-07 19:17:44 UTC
Permalink
We need support for C++ and Fortran. It will use GNU binutils.
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes
to the newest versions of the GNU utils.

Thanks,
Lucho
Post by Roman Shaposhnick
Post by Latchesar Ionkov
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
It's in my TODO list. It shouldn't be too difficult.
Does it include things like g++/gfortran/etc. ? What
backends are you interested in supporting ? What linker
do you intend to use ?
Thanks,
Roman.
Christoph Lohmann
2006-06-07 21:23:42 UTC
Permalink
Good evening.

Am Wed, 7 Jun 2006 13:17:25 -0600 schrieb Latchesar Ionkov
Post by Latchesar Ionkov
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes
to the newest versions of the GNU utils.
In the Dissident Plan 9 IRC Kids meeting we decided that SP9SSS sucks
really hard. Does that make you any better?

Sincerely,

Christoph
Roman Shaposhnick
2006-06-07 19:27:10 UTC
Permalink
Post by Latchesar Ionkov
We need support for C++ and Fortran.
Oh my! It'll be a brand new can worms to open :-(
Post by Latchesar Ionkov
It will use GNU binutils.
What about libc ? Surely you can't expect UNIX applications
to be happy without libc or better yet glibc. Do you intend
to port it as well ?
Post by Latchesar Ionkov
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes
to the newest versions of the GNU utils.
That is a doable thing. But I fail to see what it strives to
accomplish on the application level, unless, of course, the other
"secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
etc.) along the way.

Please explain what's your next step, as far as application
migration is concerned ?

Thanks,
Roman.

P.S. Sorry for being harsh, but I've just suffered a long porting
effort of the same thing. And let me tell you -- C++/g++ and glibc
ain't pretty beasts. I dread the day they appear anywhere around
Plan9.
Brantley Coile
2006-06-07 19:37:00 UTC
Permalink
Just make loading gcc and the library and anything else
that from gthe gworld gof gnu optional. So I can rush out
and not load it. Like the way the older gcc is now.
Ronald G Minnich
2006-06-07 20:17:25 UTC
Permalink
Post by Brantley Coile
Just make loading gcc and the library and anything else
that from gthe gworld gof gnu optional. So I can rush out
and not load it. Like the way the older gcc is now.
yep, You don't like it, don't use it. Simple.

But I'm sick of the purity arguments.

ron
Roman Shaposhnick
2006-06-07 20:33:22 UTC
Permalink
Post by Ronald G Minnich
Post by Brantley Coile
Just make loading gcc and the library and anything else
that from gthe gworld gof gnu optional. So I can rush out
and not load it. Like the way the older gcc is now.
yep, You don't like it, don't use it. Simple.
But I'm sick of the purity arguments.
These are not purity arguments. What you're after *can* be
implemented cleanly. There are two things I worry about however:

1. Implementors having enough time to not make shortcuts
which will render system inferior.

2. Knowing when to start bugging users to fix the code
instead of implementing yet another workaround in the system.

Your tone of voice makes me think that you don't have time
for the former and you've exhausted your patience for the
later.

Thanks,
Roman.

P.S. As a compiler engineer working for a commercial compiler
vendor I have to face #2 all the time. And let me tell you
it ain't a simple thing. However, serious developers usually
understand that fixing the code (instead of asking a vendor to
shut the compiler up) is much better long term strategy.
Unfortunately they are usually not the ones to escalate
these sort of "bugs". :-(
Latchesar Ionkov
2006-06-07 19:47:47 UTC
Permalink
Post by Roman Shaposhnick
Post by Latchesar Ionkov
We need support for C++ and Fortran.
Oh my! It'll be a brand new can worms to open :-(
Post by Latchesar Ionkov
It will use GNU binutils.
What about libc ? Surely you can't expect UNIX applications
to be happy without libc or better yet glibc. Do you intend
to port it as well ?
We will try to use APE.
Post by Roman Shaposhnick
Post by Latchesar Ionkov
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes
to the newest versions of the GNU utils.
That is a doable thing. But I fail to see what it strives to
accomplish on the application level, unless, of course, the other
"secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
etc.) along the way.
We would like to convince some people that Plan9 (kernel) is a useful
alternative to Linux without asking them to rewrite all their
applications. Like it or not, most people won't consider spending man-
months in effort just to check if an alternative is better.
Especially if there is not much hype surrounding the alternative :)
Post by Roman Shaposhnick
Please explain what's your next step, as far as application
migration is concerned ?
As Ron mentioned the immediate objectives are running MPQC and some
HPC benchmarks.
Post by Roman Shaposhnick
Thanks,
Roman.
P.S. Sorry for being harsh, but I've just suffered a long porting
effort of the same thing. And let me tell you -- C++/g++ and glibc
ain't pretty beasts. I dread the day they appear anywhere around
Plan9.
The GNU apps won't be part of the standard Plan9 distribution, so you
can continue to ignore them :)

Lucho
Corey
2006-06-07 19:49:15 UTC
Permalink
Post by Roman Shaposhnick
Post by Corey
Two questions - quite likely naive, so please be kind!
#1 - How difficult approximately would it be to port a
more current release of gcc to plan9, say 4.1?
The gcc source code is pretty messy. But let me ask you
a different question -- what exactly do you want to
achieve with gcc ?
Strictly speaking, gcc's just a means to an end ( for a hypothetical
project which is currently no more than an idle pipe-dream... so
take everything I say with a grain of salt or two ): I'm really just
looking for objective-c support on plan 9; doesn't matter to me
via which compiler this was provided, but I figure porting gcc to
plan 9 would be easier than somehow talking someone into
extending 9c with objective-c support.

Why do I want objective-c on plan 9?

I think that plan 9 would make an interesting and appealing base for a
desktop operating system; objective-c and GNUstep is also a very
interesting and appealing development environment - hey, why not
experiment? Combine the two, and it seems (to me) that a very
persuasive, light-weight/fast, general purpose desktop and
development environment/platform could potentially be built.
Post by Roman Shaposhnick
Post by Corey
"If you have gcc on plan 9, will simply compiling the unix code work?"
It might, but IMHO it'll defeat the purpose.
I completely understand, which is why I was hesitent to even open my
mouth on the subject; especially as I'm a mere hobbyist.

I really appreciate plan 9's focus, and agree that it should be maintained.
The whole point of this idea I'm toying with is to ditch the cruft and
luggage of today's linux-based os's.
Corey
2006-06-07 19:58:41 UTC
Permalink
In few words, it
was a warning that: Plan 9 is not UNIX.
Definitely - and this is what makes Plan 9 so appealing.
Plan9 is spartan and lean, and also very effective.
very much like UNIX was.
I like that about plan 9, and I'm very much an advocate of spartan and lean,
as well as focused and well-integrated/holistic.

Objective-C and the base GNUstep library/framework very much themselves
contain those same attributes: light, efficient, lean. Conceptually, I think
obj-c/gnustep running on plan 9 would be pretty enticing.
For example, GNUstep depends not just on the compiler, but also on many
services you find today on Linux and similar UNIXes. Trying to pull that into
Plan 9 would force you to pull many other stuff as well.
Yes, I've considered that - and I agree that it would be difficult and unsavory.

But it would also be temporary, a boot-strap sort of a process. The alien cruft
could be deprecated and replaced over time with natively-built components.

Also, when I talk about considering porting GNUstep, I'm just talking the base/core
framework libraries and whatever could be ported or rewritten easily.
r***@vitanuova.com
2006-06-07 20:49:51 UTC
Permalink
Post by Corey
I like that about plan 9, and I'm very much an advocate of spartan and lean,
as well as focused and well-integrated/holistic.
Objective-C and the base GNUstep library/framework very much themselves
contain those same attributes: light, efficient, lean. Conceptually, I think
obj-c/gnustep running on plan 9 would be pretty enticing.
i used objective C and nextstep, then openstep quite extensively
for some years. i would never have described either the foundation
kit or the app kit (on which, i presume, gnustep is modelled)
as "light", "efficient" or "lean".
plan 9 was a breath of fresh air after that straitjacket.
Corey
2006-06-07 21:08:04 UTC
Permalink
Post by r***@vitanuova.com
i used objective C and nextstep, then openstep quite extensively
for some years. i would never have described either the foundation
kit or the app kit (on which, i presume, gnustep is modelled)
as "light", "efficient" or "lean".
plan 9 was a breath of fresh air after that straitjacket.
Sure, and think of what Obj-C/FoundationKit is like after using GTK
or QT or, gasp, MFC. "breath of fresh air" seems appropriate. Guess
it is, of course, all just a matter of perspective.

_If_ one was interested in experimenting in developing an integrated
graphical desktop environment on plan 9, one would use what - pure C?
With what higher-level libraries would one use? Or would one write it all
from scratch?
Christoph Lohmann
2006-06-07 21:19:38 UTC
Permalink
Good evening.
Post by Corey
_If_ one was interested in experimenting in developing an integrated
graphical desktop environment on plan 9, one would use what - pure C?
With what higher-level libraries would one use? Or would one write it
all from scratch?
There is a "integrated graphical desktop environment" on Plan 9, even if
you do not call it like that.

So if you really have the moral and the power to even write a line of
code for a new "integrated graphical desktop environment" on Plan 9, then
it would be done with underlying file servers, where you write "low level"
libraries, for the graphical applications, that in the end do only a
simple write() on some file - nothing else.

Sincerely,

Christoph
Rodolfo kix
2006-06-07 21:25:45 UTC
Permalink
God save us from QT and GTK ;)
Post by Christoph Lohmann
Good evening.
Post by Corey
_If_ one was interested in experimenting in developing an integrated
graphical desktop environment on plan 9, one would use what - pure C?
With what higher-level libraries would one use? Or would one write it
all from scratch?
There is a "integrated graphical desktop environment" on Plan 9, even if
you do not call it like that.
So if you really have the moral and the power to even write a line of
code for a new "integrated graphical desktop environment" on Plan 9, then
it would be done with underlying file servers, where you write "low level"
libraries, for the graphical applications, that in the end do only a
simple write() on some file - nothing else.
Sincerely,
Christoph
--
Rodolfo García "kix"
Corey
2006-06-07 21:51:34 UTC
Permalink
Post by Rodolfo kix
God save us from QT and GTK ;)
Will god likewise save us from Rio and Acme?

Is there truly no reasonable middle-ground somewhere?

So either Plan 9 stays totally, strictly, pure, and never leaves
the server rooms and some science labs - or it "apes"
gnu/linux, and becomes a total mess?
David Leimbach
2006-06-07 21:56:14 UTC
Permalink
Post by Corey
Post by Rodolfo kix
God save us from QT and GTK ;)
Will god likewise save us from Rio and Acme?
Is there truly no reasonable middle-ground somewhere?
So either Plan 9 stays totally, strictly, pure, and never leaves
the server rooms and some science labs - or it "apes"
gnu/linux, and becomes a total mess?
The only reason it would never leave server rooms and labs is because
no one who would otherwise use it can find an application on Plan 9
they feel like they couldn't live without.

I get by fine day to day without Plan 9 personally. I just use it
because it's interesting.

Dave
g***@collyer.net
2006-06-07 23:05:13 UTC
Permalink
I use f2c when I need to compile Fortran (or, more likely, Ratfor).
Have GNU extended Fortran too? Or do you need to compile programs
that make use of features added to Fortran by later standards (though
I'm not sure that GNU Fortran will help here)?

I guess I don't see what's so offensive about rio and acme. A hazard
is that once one starts adding things to attract novice users (e.g.,
shiney things) or people who are used to some particular (l)unix
configuration (e.g., windows managers, graphical toolkits, the GNU
world), the resulting system will be bigger, slower and clumsier. If
you use gcc routinely, you lose the speed of 8c. As an example of the
cumulative effect of such accretion, a friend reported compiling a Red
Hat kernel from scratch recently and it only took about an hour (vs.
the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
seconds to compile 9pc on oldish PC hardware today).

It may not be feasible, for example due to gcc's asm constructs, but
it would seem more satisfying to write a gcc-to-c preprocessor. Of
course that doesn't help with C++; if only we had a Cfront for current
C++.
Steve Simon
2006-06-07 23:11:28 UTC
Permalink
... if only we had a Cfront for current
C++.
Many people have told me that cfront is just not up to the job,
but can somone take the time to elaborate? What is it about
modern C++ that makes cfront unusable? I can believe it has
been left behind but could it not be given some help to catch up?

I am not trolling, I am a C programmer and not a C++ one so its
not obvious to me.

-Steve
bakul+ (Bakul Shah)
2006-06-08 00:26:12 UTC
Permalink
Post by Steve Simon
... if only we had a Cfront for current
C++.
Many people have told me that cfront is just not up to the job,
but can somone take the time to elaborate? What is it about
modern C++ that makes cfront unusable? I can believe it has
been left behind but could it not be given some help to catch up?
Templates are the biggest change but the C++ standard defines
a much larger language than what cfront implements. Starting
from scratch may be cleaner and faster but who'd do it.
g***@collyer.net
2006-06-08 00:27:42 UTC
Permalink
The last paragraph of the Wikipedia entry for Cfront has a plausible
explanation. In short, exceptions were the straw that broke the
camel's back.
Ronald G Minnich
2006-06-08 03:32:04 UTC
Permalink
Post by Steve Simon
Many people have told me that cfront is just not up to the job,
it was never that satisfying an experience. We were all pretty happy
when the native C++ compilers showed up -- er, well, as happy as you can
be with C++, that is.

ron
David Leimbach
2006-06-08 15:04:59 UTC
Permalink
Post by Ronald G Minnich
Post by Steve Simon
Many people have told me that cfront is just not up to the job,
it was never that satisfying an experience. We were all pretty happy
when the native C++ compilers showed up -- er, well, as happy as you can
be with C++, that is.
ron
it's somewhat funny that now the best C++ compilers in existence are
pretty much CFront-like again then isn't it? :-)

andrey mirtchovski
2006-06-07 23:18:49 UTC
Permalink
Post by g***@collyer.net
it would seem more satisfying to write a gcc-to-c preprocessor.
even that doesn't always help. observe the following result from such
preprocessing (which caused 8c to choke, having set the maximum length
of a line of C code to be no greater than 32K characters):

Loading Image...
g***@collyer.net
2006-06-08 00:18:28 UTC
Permalink
That is grotesque, but I suspect that ken's compilers could be made to
handle arbitrarily-long input lines without too much effort, based on
related work I've done in the past.
David Leimbach
2006-06-08 14:11:40 UTC
Permalink
Post by g***@collyer.net
I use f2c when I need to compile Fortran (or, more likely, Ratfor).
Have GNU extended Fortran too? Or do you need to compile programs
that make use of features added to Fortran by later standards (though
I'm not sure that GNU Fortran will help here)?
GNU Fortran is actually fairly well caught up with F95 at least. I've
seen traffic on the apple scitech list saying that f2c is completely
inadequate for modern fortran codes.
Post by g***@collyer.net
I guess I don't see what's so offensive about rio and acme. A hazard
is that once one starts adding things to attract novice users (e.g.,
shiney things) or people who are used to some particular (l)unix
configuration (e.g., windows managers, graphical toolkits, the GNU
world), the resulting system will be bigger, slower and clumsier. If
you use gcc routinely, you lose the speed of 8c. As an example of the
cumulative effect of such accretion, a friend reported compiling a Red
Hat kernel from scratch recently and it only took about an hour (vs.
the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
seconds to compile 9pc on oldish PC hardware today).
tcc compiles the links web browser is 1/10th the time of gcc. This
isn't terribly surprising. This compiler appears to be x86 only
though, and does it's own assembly and linking too, it can also serve
as a C interpretter.

gcc is not, therefore, always the only choice on linux either.
Post by g***@collyer.net
It may not be feasible, for example due to gcc's asm constructs, but
it would seem more satisfying to write a gcc-to-c preprocessor. Of
course that doesn't help with C++; if only we had a Cfront for current
C++.
Sounds like Comeau C++. A commercial C++ compiler that aims for full
C++ compliance and compiles to other C compiler back ends, gcc is one
of them.

I believe EDG's C++ front end is actually known to be the best C++
front end in the world, and is also a CFront like compiler. EDG's C++
compiler front end is written in C. :-)
Latchesar Ionkov
2006-06-07 23:51:27 UTC
Permalink
I don't understand why is all that fuss about the gcc port. If you don't
like it, don't use it. Few of the current Plan9 users are going to use it.
But if the gcc port brings more developers to Plan9, I don't see how that
can be bad.

Thanks,
Lucho
Post by g***@collyer.net
I use f2c when I need to compile Fortran (or, more likely, Ratfor).
Have GNU extended Fortran too? Or do you need to compile programs
that make use of features added to Fortran by later standards (though
I'm not sure that GNU Fortran will help here)?
I guess I don't see what's so offensive about rio and acme. A hazard
is that once one starts adding things to attract novice users (e.g.,
shiney things) or people who are used to some particular (l)unix
configuration (e.g., windows managers, graphical toolkits, the GNU
world), the resulting system will be bigger, slower and clumsier. If
you use gcc routinely, you lose the speed of 8c. As an example of the
cumulative effect of such accretion, a friend reported compiling a Red
Hat kernel from scratch recently and it only took about an hour (vs.
the 10 minutes it took to compile V6 in 1977 on slow disks, or the 85
seconds to compile 9pc on oldish PC hardware today).
It may not be feasible, for example due to gcc's asm constructs, but
it would seem more satisfying to write a gcc-to-c preprocessor. Of
course that doesn't help with C++; if only we had a Cfront for current
C++.
g***@collyer.net
2006-06-08 00:54:23 UTC
Permalink
The argument `if you don't like it, don't use it', is how PL/I, C++,
gcc and Linux got to be huge. The fallacy in the argument is that
adding complexity and bulk to anything makes it harder to comprehend
and slower to use (not to mention less elegant). Manuals get thicker,
it's harder to find what you want and sometimes you have to learn
about things just to avoid them successfully. There get to be
unintended interactions between the parts. In software, layers (thus
slowness and bulk) tend to accrete. Then there are hacks (e.g.,
shared libraries) to try to ameliorate the bloat.

Is Linux really any better for having Gnome *and* KDE, both layered on
top of X libraries, and a raft of duelling applications written for
each? It reminds me of the Unix Window System Wars of the 1980's,
when people thought (or pretended to) that it *really mattered* if
your windows had drop shadows or 3D effects on the corners.
Latchesar Ionkov
2006-06-08 01:08:44 UTC
Permalink
We have to choose between having clean system that is used by handful
of people, or slightly dirtier one (but still better than Linux for
example) that can attract more users.

I don't think the Plan9 community has the resources (both in numbers
and quality) to continue the development. We need fresh blood.

Thanks,
Lucho
Post by g***@collyer.net
The argument `if you don't like it, don't use it', is how PL/I, C++,
gcc and Linux got to be huge. The fallacy in the argument is that
adding complexity and bulk to anything makes it harder to comprehend
and slower to use (not to mention less elegant). Manuals get thicker,
it's harder to find what you want and sometimes you have to learn
about things just to avoid them successfully. There get to be
unintended interactions between the parts. In software, layers (thus
slowness and bulk) tend to accrete. Then there are hacks (e.g.,
shared libraries) to try to ameliorate the bloat.
Is Linux really any better for having Gnome *and* KDE, both layered on
top of X libraries, and a raft of duelling applications written for
each? It reminds me of the Unix Window System Wars of the 1980's,
when people thought (or pretended to) that it *really mattered* if
your windows had drop shadows or 3D effects on the corners.
g***@collyer.net
2006-06-08 01:23:21 UTC
Permalink
That's the tricky bit: values of `slightly' in `slightly dirtier' vary
widely. My value might be epsilon or zero; others obviously have huge
tolerance for rubbish. I'm not convinced that the system has to be
made dirtier at all to attract users. Perhaps changes are necessary,
but I don't see virtue in dirt.
Post by Latchesar Ionkov
We need fresh blood.
I'm willing to try sacrificing goats but it hasn't work very well in
the past. ☺

I'm not sure what the answer is, but I think it's got more to do with
educating people and getting them to write more-portable code, at
least in the long term. Why are numerical programs dependent on
obscure gcc extensions?
Latchesar Ionkov
2006-06-08 01:26:12 UTC
Permalink
Who is going to make the changes then? Do you think the system is
perfect and there is nothing that can be made better?

Lucho
Post by g***@collyer.net
That's the tricky bit: values of `slightly' in `slightly dirtier' vary
widely. My value might be epsilon or zero; others obviously have huge
tolerance for rubbish. I'm not convinced that the system has to be
made dirtier at all to attract users. Perhaps changes are necessary,
but I don't see virtue in dirt.
Post by Latchesar Ionkov
We need fresh blood.
I'm willing to try sacrificing goats but it hasn't work very well in
the past. ☺
I'm not sure what the answer is, but I think it's got more to do with
educating people and getting them to write more-portable code, at
least in the long term. Why are numerical programs dependent on
obscure gcc extensions?
q***@quanstro.net
2006-06-08 01:28:11 UTC
Permalink
Post by Latchesar Ionkov
We have to choose between having clean system that is used by handful
of people, or slightly dirtier one (but still better than Linux for
example) that can attract more users.
I don't think the Plan9 community has the resources (both in numbers
and quality) to continue the development. We need fresh blood.
thanks for insulting everyone here. i simply don't agree that the quality
of programmers working on plan 9 is lacking. from what i've seen it's top
shelf.

- erik
David Leimbach
2006-06-08 15:03:11 UTC
Permalink
Post by q***@quanstro.net
Post by Latchesar Ionkov
We have to choose between having clean system that is used by handful
of people, or slightly dirtier one (but still better than Linux for
example) that can attract more users.
I don't think the Plan9 community has the resources (both in numbers
and quality) to continue the development. We need fresh blood.
thanks for insulting everyone here. i simply don't agree that the quality
of programmers working on plan 9 is lacking. from what i've seen it's top
shelf.
- erik
I think you may have zoomed in on the wrong interpretation of his
parenthesis. I took it as "there are good programmers in terms of
quality in the plan 9 community, but not enough."

Dave
Lyndon Nerenberg
2006-06-08 01:40:33 UTC
Permalink
Post by Latchesar Ionkov
I don't think the Plan9 community has the resources (both in
numbers and quality) to continue the development. We need fresh blood.
No, we need fresh ideas. An infinite number of monkeys turning Plan
9 into Linux is not progress.

The latest copy of login (the Usenix newsletter) has an editorial
lamenting how UNIX just doesn't fit the current one-user-one-machine
paradigm we see today, and how we need to re-think how things are
done in this regard. Yet Plan 9 has already been doing this for over
a decade.

Plan 9's "future" is in guiding the UNIX community forward, not in
regressing back to what spawned it in the first place. And I
sincerely hope that doesn't happen by having Plan 9 be adopted
wholesale by the masses, for that would (sooner or later) see the end
of research and innovation for the sake of not breaking all the
currently running apps, which is what caused UNIX to start growing
mold. I would much rather see Plan 9 stay small and mostly ignored,
since that's how it will remain agile and pliable. It's the *ideas*
from Plan 9 (e.g. the servers, namespaces) that will help the masses
morph their current environment into something suitable for the 21st
century.

--lyndon
Dan Cross
2006-06-08 03:12:42 UTC
Permalink
Post by Lyndon Nerenberg
Plan 9's "future" is in guiding the UNIX community forward, not in
regressing back to what spawned it in the first place. And I
sincerely hope that doesn't happen by having Plan 9 be adopted
wholesale by the masses, for that would (sooner or later) see the end
of research and innovation for the sake of not breaking all the
currently running apps, which is what caused UNIX to start growing
mold. I would much rather see Plan 9 stay small and mostly ignored,
since that's how it will remain agile and pliable. It's the *ideas*
from Plan 9 (e.g. the servers, namespaces) that will help the masses
morph their current environment into something suitable for the 21st
century.
I concur. One has to ask the question, *why* does one want to attract
new users to Plan 9? It would take many man-centuries of effort to get
an environment as rich (for the end-user) as that provided by the
mainstream Unices right now. And what would be the point? As many
have noted, it would lead to increased complexity, bloat, and decreased
quality on what is otherwise a pretty clean and high quality system.
Plan 9 would, at that point, cease to be Plan 9 and turn into something
else. I don't particularly want that, just as I don't really want to
add a lot of new ``features'' to C: if I want C++, Java, C#, or Ruby, I
know where to get them. Similarly, if I want Unix, I know where to get
it.

Instead, I'd like to go back to basics and use Plan 9 as a clean,
conceptually pure prototype for a new Unix-like system. Let's take the
good ideas from Plan 9, and a current BSD kernel (probably the FreeBSD
one), a current Unix user-land, an axe, and go to town like Charles did
with SunOS 4 back in the day. For that matter, throw in some of the
good ideas from VSTa (now FMI/OS? They seem to be regressing: from
their Wiki's page on `Current Work': ``working on getting switching to
posix style error numbers instead of strings. done'' Great...), EMAS,
TOPS-20, VMS, Multics, QNX, etc. (Yes! VMS had some good ideas! Like
a standardized calling convention that made it possible to call modules
from any number of languages! 20 years ago! Stick THAT in your ELF
and smoke it!) But in general, you know, look back at history and add
in some of those things that were good ideas and got lost in the sands
of time but which will get reinvented two years from now, badly,
because no one thinks to do any research before starting on their work
anymore. At least, not in computer science....

Of course, that will never happen, and Geoff is right: it's mostly an
issue with education and defeating incorrect or outdated perceptions (I
get physically ill when I hear about ``efficiency'' these days. Yeah,
like your GCC extension to pack struct's is *so* much more efficient on
a 3 GHz machine than code to pack it or unpack it from a bytestream.
You spend more time porting it to a new platform than you ever did
writing and debugging once, and running an arbitrary number of times,
the byte packing code). Too bad the example a beginning programmer
sees now is the cess pool of open source cruft instead of well-written
code.


- Dan C.
Joel Salomon
2006-06-08 03:46:06 UTC
Permalink
if I want C++, Java, C#, or Ruby, I know where to get them.
You know where to find a standards-compliant C++ compiler?
Roman Shaposhnik
2006-06-08 07:06:29 UTC
Permalink
if I want C++, Java, C#, or Ruby, I know where to get them.
You know where to find a standards-compliant C++ compiler? ☺
Which standard ? After all, 2008(9) one is downright scary :-(

Thanks,
Roman.
Ignacio Torres Masdeu
2006-06-08 01:51:21 UTC
Permalink
Post by Latchesar Ionkov
I don't understand why is all that fuss about the gcc port. If you don't
like it, don't use it. Few of the current Plan9 users are going to use it.
But if the gcc port brings more developers to Plan9, I don't see how that
can be bad.
I am not a developer and I cannot compare gcc with 8c, but from
seeing Plan9's architecture and comparing it with other OSs I would
trust the people that said that gcc makes you a lazy developer.

And about bringing new developers, let me make a parable here:
If I move to another country with a different language and customs, I
will learn their language and their tradition. Adopting GCC to
attract open source developers is like making french an official
language in Spain to attract french women. I rejoice on the idea but
don't think it would work.

Or maybe a better example: it would be like allowing driving on the
left lane in USA to attract UK visitors. Not using the left lane
wouldn't be an option, for there would be lots of british using MY
lane to overtake. And dislexic drivers getting their licenses now for
they couldn't before.

Best regards,
Ignacio
Ronald G Minnich
2006-06-07 21:57:33 UTC
Permalink
Post by Corey
So either Plan 9 stays totally, strictly, pure, and never leaves
the server rooms and some science labs - or it "apes"
gnu/linux, and becomes a total mess?
"welcome to hell, kid" -- Wally

ron
Ronald G Minnich
2006-06-07 22:34:29 UTC
Permalink
Post by Francisco J Ballesteros
Venti. I just sold Plan 9 services to our local set of linux users. Our
dept. server (a linux box) crashed. I know, they know, but there were
no complete backup for the system. It´s just so simple to manage
distributed
resources with Plan 9, that this is just the type of thing to sell.
yeah, fossil/venti does get people excited.
Post by Francisco J Ballesteros
But anyway, going back to this thread of gcc/etc.etc. Isn´t p9p what
you are seeking for?
no, I want plan 9, not linux tarted up to look like Plan 9. Although p9p
is sure good stuff.

ron
Corey
2006-06-07 22:40:32 UTC
Permalink
Post by Christoph Lohmann
Good evening.
Hey!
Post by Christoph Lohmann
Post by Corey
_If_ one was interested in experimenting in developing an integrated
graphical desktop environment on plan 9, one would use what - pure C?
With what higher-level libraries would one use? Or would one write it
all from scratch?
There is a "integrated graphical desktop environment" on Plan 9, even if
you do not call it like that.
Do you use Plan 9 for your general-purpose, everyday, recreational computing
environment?
Post by Christoph Lohmann
So if you really have the moral and the power to even write a line of
code for a new "integrated graphical desktop environment" on Plan 9
Well, that's sort of what I've been trying to say, (c8=

I have neither the morale nor the power to write even a single line of code
for this new "integrated graphical desktop environment" on Plan 9 -- I
merely intend to assemble the work that others are doing; I'm like a child
clumsily playing with lego bricks. The best that I can do is help write
the gluework to get it working together nicely.

As I just now read in a different post:

On Wednesday 07 June 2006 15:33, Ronald G Minnich wrote:
"I want plan 9, not linux tarted up to look like Plan 9."

It's like this:

_Were_ there a choice between running a general-purpose/consumer-oriented
Plan 9 "distribution" of sorts, and running yet another linux distro - I would opt
for the Plan 9 "distro" ( or whatever it would be called ); this hypothetical
operating system would of course only be interesting so long as it were
designed complementary to the very cool underlying Plan 9 concepts.

But there currently is no such incarnation/form of Plan 9, and so I sometimes
find myself idly speculating on what sort of task it would be to create one, and
what this conceptual operating system might look like were it embarked upon.
Post by Christoph Lohmann
then it would be done with underlying file servers, where you write "low level"
libraries, for the graphical applications, that in the end do only a
simple write() on some file - nothing else.
You give the impression that the only way of writing 9p fileservers and
consumer-oriented applications on Plan 9 is with pure C, and that this will
always be the only way, and that it should always be the only way.

You also make it sound as though higher-level libraries and/or object-oriented
programming on Plan 9 are a complete waste in all circumstances.

I honestly don't understand, but I'm also very ignorant - which is why I was
hoping for friendly explanations on how and why my assumptions don't meet
the reality. I think the primary rift is that the idea of a general-purpose,
user-grade version of Plan 9 is distastefull and/or useless.

Anyhow, I'm probably just becoming line-noise at this point. (c8=


Cheers!

Corey
Paul Lalonde
2006-06-07 22:50:01 UTC
Permalink
Post by Corey
You also make it sound as though higher-level libraries and/or object-oriented
programming on Plan 9 are a complete waste in all circumstances.
Plan 9 is object-oriented. The objects have a file-like abstraction
and interactions with the objects are mediated by a network protocol
that abstracts all the network messiness away.

C++ on Plan 9 is a whole other issue. It's bad enough that it has
invaded my work life, having it invade my hobby computing environment
would just make me sad. And most C++ is at best what I'd call
naively object oriented. C-with-classes is a better name, and,
frankly, more palatable than what's it has grown into.

I can easily imagine a nice smalltalk implementation for Plan 9 that
plays well with the 9P servers. That would be sexy. But C-double-
cross is not compatible with Plan 9's "do it cleanly" aesthetic.

Paul
Christoph Lohmann
2006-06-07 23:00:43 UTC
Permalink
Good evening.
Post by Corey
Do you use Plan 9 for your general-purpose, everyday, recreational
computing environment?
Yes.
Post by Corey
I have neither the morale nor the power to write even a single line of
code for this new "integrated graphical desktop environment" on Plan 9
-- I merely intend to assemble the work that others are doing; I'm like
a child clumsily playing with lego bricks. The best that I can do is
help write the gluework to get it working together nicely.
So why are you discussing this, when you are not going to write any source
code?
Post by Corey
_Were_ there a choice between running a
general-purpose/consumer-oriented Plan 9 "distribution" of sorts, and
running yet another linux distro - I would opt for the Plan 9
"distro" ( or whatever it would be called ); this hypothetical
operating system would of course only be interesting so long as it were
designed complementary to the very cool underlying Plan 9 concepts.
That is only a propaganda position and not a technical one. Propaganda is
boring.
Post by Corey
You give the impression that the only way of writing 9p fileservers and
consumer-oriented applications on Plan 9 is with pure C, and that this
will always be the only way, and that it should always be the only
way.
No, I said, that we use file servers in Plan 9, that speak 9P or the
appropriate syscalls. C is just good taste, but you can still do the
same in whatever language you like.
Post by Corey
You also make it sound as though higher-level libraries and/or
object-oriented programming on Plan 9 are a complete waste in all
circumstances.
Yes they are, but that is only a question of taste.
Post by Corey
I honestly don't understand, but I'm also very ignorant - which is why
I was hoping for friendly explanations on how and why my assumptions
don't meet the reality. I think the primary rift is that the idea of a
general-purpose, user-grade version of Plan 9 is distastefull and/or
useless.
First define "general-purpose", "user-grade", "distastefull" and
"useless".
Post by Corey
Anyhow, I'm probably just becoming line-noise at this point. (c8=
Yes.

Sincerely,

Christoph
Lluís Batlle
2006-06-08 09:41:13 UTC
Permalink
Post by Corey
I have neither the morale nor the power to write even a single line of code
for this new "integrated graphical desktop environment" on Plan 9 -- I
merely intend to assemble the work that others are doing; I'm like a child
clumsily playing with lego bricks. The best that I can do is help write
the gluework to get it working together nicely.
What do you mean by "others are doing"? I don't know about the GNUStep
general development, but a bit about Windowmaker's - there isn't more
than a message a month in their mailing lists, and I think they aren't
many people. A recent post in their lists claimed "We used to have
time when we was at university...", explaining how difficult is for
the Windowmaker's developers keep on programming.

Maybe I'm wrong? I don't know about the out-of-the-mailing-lists work.
Dan Cross
2006-06-07 23:13:22 UTC
Permalink
Post by Christoph Lohmann
Good evening.
Why do you always put the appropriate greeting of the day in your emails?
Post by Christoph Lohmann
Post by Corey
I have neither the morale nor the power to write even a single line of
code for this new "integrated graphical desktop environment" on Plan 9
-- I merely intend to assemble the work that others are doing; I'm like
a child clumsily playing with lego bricks. The best that I can do is
help write the gluework to get it working together nicely.
So why are you discussing this, when you are not going to write any source
code?
Because he doesn't want to invent a new window system and programming
abstractions for it, but he's interesting in using one if it already exists?
Why shouldn't he discuss it?

What a stupid, arrogantly elitist attitude.
Post by Christoph Lohmann
That is only a propaganda position and not a technical one. Propaganda is
boring.
More wisdom from the IRC crowd. What, collectively, have you people ever
done? We're still waiting for Uriel's 9load replacement, if I recall
correctly.

- Dan C.
Federico G. Benavento
2006-06-07 23:36:09 UTC
Permalink
Post by Dan Cross
Post by Christoph Lohmann
Good evening.
Why do you always put the appropriate greeting of the day in your emails?
Post by Christoph Lohmann
Post by Corey
I have neither the morale nor the power to write even a single line of
code for this new "integrated graphical desktop environment" on Plan 9
-- I merely intend to assemble the work that others are doing; I'm like
a child clumsily playing with lego bricks. The best that I can do is
help write the gluework to get it working together nicely.
So why are you discussing this, when you are not going to write any source
code?
Because he doesn't want to invent a new window system and programming
abstractions for it, but he's interesting in using one if it already exists?
Why shouldn't he discuss it?
What a stupid, arrogantly elitist attitude.
Post by Christoph Lohmann
That is only a propaganda position and not a technical one. Propaganda is
boring.
More wisdom from the IRC crowd. What, collectively, have you people ever
done? We're still waiting for Uriel's 9load replacement, if I recall
correctly.
you can run "9fs sources; cd /n/sources/contrib/zwansch; ls", can you?

judging all "the IRC crowd" by what uriel said is the same as judging all 9fans by what you say.

Federico G. Benavento
Dan Cross
2006-06-07 23:53:36 UTC
Permalink
Post by Federico G. Benavento
you can run "9fs sources; cd /n/sources/contrib/zwansch; ls", can you?
At the moment, no, I can't.
Post by Federico G. Benavento
judging all "the IRC crowd" by what uriel said is the same as judging all
9fans by what you say.
It's not just that, but the snarky attitudes and IRC logs, and the attitudes
that, ``we use Plan 9, so we're better than everyone else.'' I'm sorry, I'm
not convinced.

- Dan C.
Corey
2006-06-07 23:20:17 UTC
Permalink
Post by Paul Lalonde
Post by Corey
You also make it sound as though higher-level libraries and/or
object-oriented
programming on Plan 9 are a complete waste in all circumstances.
Plan 9 is object-oriented. The objects have a file-like abstraction
and interactions with the objects are mediated by a network protocol
that abstracts all the network messiness away.
I've more or less dimly grokked the not-immediately-obvious-but-very-elegant
Plan9-as-object-oriented-via-9p concept; but Plan 9 is not a programming
language.

To which I'll probably get the response from someone: "OOP is pointless -
you can do every thing OOP can do, using 9p and modular programming in
C."

Which is certainly a valid point, unless for whatever reasons, you are unable
to write a whole framework or whatever from scratch, and would thus selfishly
prefer to use an existing one.
Post by Paul Lalonde
C++ on Plan 9 is a whole other issue. It's bad enough that it has
invaded my work life, having it invade my hobby computing environment
would just make me sad.
I don't like C++ either; I'm merely asking about Objective-C, which I find
enjoyable and mostly sound.
Post by Paul Lalonde
I can easily imagine a nice smalltalk implementation for Plan 9 that
plays well with the 9P servers.
Yes, that would be cool.

But when I mention: "I can easily imagine a nice <insert programming language>
implementation for Plan 9 that plays well with the 9P servers", I somehow quickly
make an annoyance of myself. <grin> It's weird.


Cheers,

Corey
Paul Lalonde
2006-06-07 23:37:58 UTC
Permalink
Post by Corey
I've more or less dimly grokked the not-immediately-obvious-but-
very-elegant
Plan9-as-object-oriented-via-9p concept; but Plan 9 is not a
programming
language.
Agreed - It's more like the CORBA part rather than the language part,
although much nicer/more uniform.
That said, language bindings to services should be simple to write,
not the hideous mess we see in the CORBA and COM world. Sadly, C++
makes for a hideous mess of these models.
File abstractions wind up being pretty easy and relatively clean.
Post by Corey
To which I'll probably get the response from someone: "OOP is
pointless -
you can do every thing OOP can do, using 9p and modular programming in
C."
OOP isn't pointless - but most supposed OOP code is just a poor
excuse not to understand your flow control. My annoyance is that the
cult of re-use that is associated with most OOP proselytization makes
the code bloat hugely - I'm as guilty of that as the next guy.
Compare the STL hash implementation with the the elf hash table
implementation - the latter works in 20 lines of code, the former
requires 769 lines of near-opaque code. Sure, it extends to any
object you have, but the development cost was huge. It's good to
have it, but then people mimic that style with substantially less re-
usable constructs that aren't nearly as functionally stable as
hash_map and hash_set.
Post by Corey
Which is certainly a valid point, unless for whatever reasons, you are unable
to write a whole framework or whatever from scratch, and would thus selfishly
prefer to use an existing one.
Now that's a separate issue, although still touching on re-use. For
that one I question the viability of *any* open source "desktop"
environment and most closed ones too. The cruftiness that is so-
called required to satisfy naive users is dead in the way of
usability for advanced users. It's sad we've all decided that
computers have to be easy-to-use, by which is usually meant "require
little or no training". Sadly, a little training can go a long way
to make usability happen for expert users, which is a level most
users wind up a in a few years: for evidence, see how many windows
users are willing to muck deep in their menus to change interface
options. Perhaps not for their early exposure, but soon enough after
everyone seems to. Yuck.
Post by Corey
I don't like C++ either; I'm merely asking about Objective-C,
which I find
enjoyable and mostly sound.
I like it much better than C++, that's for sure. I'm still not so
sure about bastard hybrids though :-)
Post by Corey
Post by Paul Lalonde
I can easily imagine a nice smalltalk implementation for Plan 9 that
plays well with the 9P servers.
Yes, that would be cool.
But when I mention: "I can easily imagine a nice <insert
programming language>
implementation for Plan 9 that plays well with the 9P servers", I somehow quickly
make an annoyance of myself. <grin> It's weird.
:-) I think the key part is that people don't want to see the layers
and layers of cruft that seem to be involved in any port from the
linux (GCC) world these days. Even python is so corrupted by that
environment I want to scream (I had to port it to PS3 recently, and
at least the dev kit uses GCC, but even then the platform
dependencies are hellish to work with).

But mostly I've been finding that rc + awk + sed does most of my 9p
coding, with surprisingly good results.

Paul
q***@quanstro.net
2006-06-08 01:02:44 UTC
Permalink
Post by Paul Lalonde
Post by Corey
To which I'll probably get the response from someone: "OOP is
pointless -
you can do every thing OOP can do, using 9p and modular programming in
C."
OOP isn't pointless - but most supposed OOP code is just a poor
excuse not to understand your flow control. My annoyance is that the
cult of re-use that is associated with most OOP proselytization makes
the code bloat hugely - I'm as guilty of that as the next guy.
Compare the STL hash implementation with the the elf hash table
implementation - the latter works in 20 lines of code, the former
requires 769 lines of near-opaque code. Sure, it extends to any
object you have, but the development cost was huge. It's good to
have it, but then people mimic that style with substantially less re-
usable constructs that aren't nearly as functionally stable as
hash_map and hash_set.
you're really on to something here.

768/20 ~= 40. that may be a good proof that hash tables can't be abstracted from
the stuff hashed.

i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.

interfaces like those provided by plan 9 fileservers are much more compelling.
/dev/draw seems to me much more object-oriented than anything i've seen in
c++ or java. it's ironic that the oop crowd seems to be the biggest poo-pooers
of plan 9.

- erik
John Barham
2006-06-08 01:17:32 UTC
Permalink
Post by q***@quanstro.net
i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.
Neither was Stepanov, the creator of the STL:

"STL is not object oriented. I think that object orientedness is
almost as much of a hoax as Artificial Intelligence. I have yet to see
an interesting piece of code that comes from these OO people."

See http://www.stlport.org/resources/StepanovUSA.html.
David Leimbach
2006-06-08 14:52:54 UTC
Permalink
Post by q***@quanstro.net
Post by Paul Lalonde
OOP isn't pointless - but most supposed OOP code is just a poor
excuse not to understand your flow control. My annoyance is that the
cult of re-use that is associated with most OOP proselytization makes
the code bloat hugely - I'm as guilty of that as the next guy.
Compare the STL hash implementation with the the elf hash table
implementation - the latter works in 20 lines of code, the former
requires 769 lines of near-opaque code. Sure, it extends to any
object you have, but the development cost was huge. It's good to
have it, but then people mimic that style with substantially less re-
usable constructs that aren't nearly as functionally stable as
hash_map and hash_set.
you're really on to something here.
768/20 ~= 40. that may be a good proof that hash tables can't be abstracted from
the stuff hashed.
i'm not convinced by OOP -- at least in the sense that leads to STL hash tables.
I don't understand why people say OOP and STL in the same sentence.
Just because code is encapsulated and isolated to a class, does not
make that code OO.

In fact, currently, none of the STL classes are even safe to derive
new classes from, based on the fact that none of them have virtual
destructors.

I'd call STL containers and algorithms an attempt at parametric
polymorphism which has been handled better in almost any Functional
Programming language I've ever seen than in C++.
Post by q***@quanstro.net
interfaces like those provided by plan 9 fileservers are much more compelling.
/dev/draw seems to me much more object-oriented than anything i've seen in
c++ or java. it's ironic that the oop crowd seems to be the biggest poo-pooers
of plan 9.
I know people who think files should be for files, and that's it.
That abstracting the filesystem to mean anything else is almost as bad
as overloading operators in C++.

I can kind of understand the complaint.

in C++ for example you've got things like

C = A + B;

If A and B are objects of classes, this could mean a lot of different
things as you must define operator + for that class. A and B don't
even have to be of the same classes, and the same goes for C. Without
knowing about the data types, it's not really possible to know all the
possible side effects, exceptions, allocations (needless copies that
might be immediately thrown out and how different compilers might
interpret those) etc for a single expression. In fact there are a lot
of different function calls and code paths that could imply.

The same might be said (though I think with less confusion) when someone says:

echo eject > /dev/<blah>

could be confusing because the file interface and syntax by which we
operate on it is also overloaded.

Now think about Mac OS X again. Sure it's unix underneath, but does
grandma even know or care about that? Probably not. One of my best
friends is a graphic artist who uses it every day. He asked me about
Terminal.app one day (which would get him a shell and expose him to a
whole other world of functionality). I told him to ignore it, that
for him, it'd be opening up the wrong can of worms.

For some, ignorance really is bliss. And never needing to touch the
shell and still be productive is actually a dream come true.

Dave
Post by q***@quanstro.net
- erik
Corey
2006-06-08 00:33:29 UTC
Permalink
Post by Christoph Lohmann
Post by Corey
Do you use Plan 9 for your general-purpose, everyday, recreational
computing environment?
Yes.
That's definitely remarkable, and respect-worthy.

Not necessarily because you use Plan 9, but because of all the things you
obviously _don't_ use while using Plan 9 - such as graphical/current web-browsing
apps, various media apps, pim apps, vector graphics editing apps, spreadsheet
and publishing apps, pdf, relational database management systems, etc. etc.
Post by Christoph Lohmann
Post by Corey
I have neither the morale nor the power to write even a single line of
code for this new "integrated graphical desktop environment" on Plan 9
-- I merely intend to assemble the work that others are doing; I'm like
a child clumsily playing with lego bricks. The best that I can do is
help write the gluework to get it working together nicely.
So why are you discussing this, when you are not going to write any source
code?
Because I firmly believe that writing source code is for suckers!

Wait, no - because I am not Super-Programmer. And also because, one of the
primary benefits of open-source software and code-reuse in general is... well,
so. that. people. may. reuse. code.
Post by Christoph Lohmann
Post by Corey
You give the impression that the only way of writing 9p fileservers and
consumer-oriented applications on Plan 9 is with pure C, and that this
will always be the only way, and that it should always be the only
way.
No, I said, that we use file servers in Plan 9, that speak 9P or the
appropriate syscalls.
Appologies for misinterpreting your words.

I had got the impression that you were rejecting the notion that using an
object-oriented language with some higher-level libraries is a potentially
more suitable basis as the foundation for a more fully-realized integrated
user environment on Plan 9 than is pure-C.
Post by Christoph Lohmann
C is just good taste, but you can still do the same in whatever language you
like.
That seems reasonable.

Which low-level languages besides C are currently available on Plan 9?

For instance, I was merely asking about objective-c; which is not an option at
this time, nor will it perhaps ever be an option if current gcc and it's ugly friends
are not ported. Alas, the world may never see my all-new, totally awesome os.

So here's the rub - whatever existing language and/or environment besides
C or perhaps Limbo one would like to use under Plan 9, requires either a port,
or a complete rewrite. But there appears to be some negative-feedback on
porting the gnu-land toolchain, and complete rewrites require unrealistic
amounts of time and effort and man hours to implement


Cheers,

Corey
g***@collyer.net
2006-06-08 01:06:47 UTC
Permalink
all the things you obviously _don't_ use while using Plan 9 - such as
graphical/current web-browsing apps, various media apps, pim apps,
vector graphics editing apps, spreadsheet and publishing apps, pdf,
relational database management systems, etc. etc.
I use Safari via VNC from Plan 9 for web browsing (we do after all
have networks nowadays, so we don't have to run everything in one
machine). page(1) reads PDF.

The rest of the above list seem to me to be mostly bling, symptoms or
check-list items. In a pinch, my Mac Mini makes a fine multimedia
processor. I have no interest in most of the other items
(spreadsheets!?), and actively dislike others (RDBMs). Somehow the
lack of these things hasn't been a problem.
q***@quanstro.net
2006-06-08 01:34:23 UTC
Permalink
i have found relational databases pretty useful for certian problems --
like tracking ever-changing customer and billing information.

/interfacing/ to relational databases is downright obnoxious.
but that's an implementation issue.
Post by g***@collyer.net
(spreadsheets!?), and actively dislike others (RDBMs). Somehow the
lack of these things hasn't been a problem.
Victor Nazarov
2006-06-08 10:10:41 UTC
Permalink
Post by g***@collyer.net
all the things you obviously _don't_ use while using Plan 9 - such as
graphical/current web-browsing apps, various media apps, pim apps,
vector graphics editing apps, spreadsheet and publishing apps, pdf,
relational database management systems, etc. etc.
I use Safari via VNC from Plan 9 for web browsing (we do after all
have networks nowadays, so we don't have to run everything in one
machine). page(1) reads PDF.
The rest of the above list seem to me to be mostly bling, symptoms or
check-list items. In a pinch, my Mac Mini makes a fine multimedia
processor. I have no interest in most of the other items
(spreadsheets!?), and actively dislike others (RDBMs). Somehow the
lack of these things hasn't been a problem.
I actively dislike Web tecnologies (w3c as a whole). But why RDBMs?
Actually I dislike them too, but there seems to be no real alternatives.
And, hmm, I like spreadsheets :)
--
Victor
j***@plan9.bell-labs.com
2006-06-08 01:25:25 UTC
Permalink
When I got home this evening after a very frustrating
couple of days (weeks, really) and found my mailbox slashdotted
with this, it took physical restraint to prevent me from
replying.
Post by Corey
...
Wait, no - because I am not Super-Programmer. And also because, one of the
primary benefits of open-source software and code-reuse in general is... well,
so. that. people. may. reuse. code.
...
You missed the 'bad' before 'code'.

People are lazy and stupid (me included) and will always look for
the easy way out. Open Source (as it is generally understood) has
merely lowered the standard for entry.

Lucho's work to upgrade David Hogan's GCC port is being done for a
very particular purpose, it's part of a Department of Energy research
project looking at operating system requirements for the next
generation of peta-scale supercomputers and it's necessary to run
some of the accepted supercomputer applications on Plan 9 for comparison.
The resulting GCC will be, as now, walled off in its own ghetto and
not play any part in the day to day life or death struggles of Plan 9.
If it proves to be too difficult to get the targeted applications to
run this way, we'll look for another solution.
Ronald G Minnich
2006-06-08 03:36:32 UTC
Permalink
Post by j***@plan9.bell-labs.com
If it proves to be too difficult to get the targeted applications to
run this way, we'll look for another solution.
exact-a-mundo. Whatever that word means.

We've already looked at a few things here that we have not discussed,
including source-to-source transformation using the U. Oregon PDT. It's
just a messy problem. We have yet to find a really satisfying solution.
I can't say I like the gcc path, but we've tried a fair number of ideas
and we keep getting back to that one.

ron
Ronald G Minnich
2006-06-08 03:52:29 UTC
Permalink
so, end of this thread, we hope.

GARSH, Mickey, I had no idea this would happen. You make one simple
comment, and ... ah well.

anyways, a few thoughts on another tangent.

linux nowadays is all about building a windows desktop. BORING. Or a Mac
OSX ripoff desktop. BORING. And just look at all that great vista stuff.
oh boy, I can slant my windows or something. Who the F*** cares?

What if you had a window manager that could be recursive? that would set
it up so you can name windows by a path name? that would let you treat
the recursive desktops -- to any level -- as just another window? that
would trivially allow you to connect mouse clicks in a window to control
actions for one or more other windows (i.e. you could logically group
windows and then control all of them via mouse clicks)? That would maybe
let you easily connect output from a process in one window to another?
that would let you build little widgets that could easily control other
windows? That would let you display all window state in another window?
That would let you set, say, all windows with a browser with the label
abaco-### (### a number), with a simple text command; and let you find
all windows with the label abaco.* with, in the limit, a grep? That
would make it easy to group all windows with the label 'abaco.*' so that
you could say 'hide all abaco' with a simple script?

Wouldn't that be neat? I mean, that's a real bitch in X, right?

Except ... you already have it.

ron
Roman Shaposhnik
2006-06-08 04:08:01 UTC
Permalink
Post by Ronald G Minnich
so, end of this thread, we hope.
Well, I've writing a reply to your earlier email in a separate window,
but except that
one (and one question which I'm saving for the end of this email) I
think we've had enough.

The discussion helped me understand where you guys are coming from and
why gcc is
just a means to an end for you. One question that I still have, though,
is what
makes you think that once you're done with porting gcc (big task) and
porting HPC apps to
gcc/Plan9 (even bigger one!) they will *execute* faster than they do on
Linux ? Or is the
ease of building clusters (along the lines of what you've presented at
SuperComputing in
Seattle) alone worth the trouble. Please help me understand (and feel
free to change the
subject ;-)).
Post by Ronald G Minnich
linux nowadays is all about building a windows desktop. BORING. Or a
Mac OSX ripoff desktop. BORING. And just look at all that great vista
stuff. oh boy, I can slant my windows or something. Who the F*** cares?
Unwashed masses, perhaps ? ;-)
Post by Ronald G Minnich
What if you had a window manager that could be recursive? that would
set it up so you can name windows by a path name? that would let you
treat the recursive desktops -- to any level -- as just another
window? that would trivially allow you to connect mouse clicks in a
window to control actions for one or more other windows (i.e. you
could logically group windows and then control all of them via mouse
clicks)? That would maybe let you easily connect output from a process
in one window to another? that would let you build little widgets
that could easily control other windows? That would let you display
all window state in another window? That would let you set, say, all
windows with a browser with the label abaco-### (### a number), with a
simple text command; and let you find all windows with the label
abaco.* with, in the limit, a grep? That would make it easy to group
all windows with the label 'abaco.*' so that you could say 'hide all
abaco' with a simple script?
Wouldn't that be neat? I mean, that's a real bitch in X, right?
Except ... you already have it.
You're absolutely onto something here, Ron! In fact, if everything
goes right, I really want to explore
a possibility of building a clean desktop (don't laugh yet!) on top of
Plan9. I really think that what Nemo
has been doing with building UIs is quite convincing and has lots of
potential. But I have to start at
even lower level, making "/dev/draw" do all the basic things I care
about in a desktop.

Will see where it goes, but one thing for sure -- I'll be asking lots of
questions in this forum ;-)

Thanks,
Roman.
Paul Lalonde
2006-06-08 04:12:14 UTC
Permalink
Post by Ronald G Minnich
What if you had a window manager that could be recursive? that
would set it up so you can name windows by a path name? that would
let you treat the recursive desktops -- to any level -- as just
another window? that would trivially allow you to connect mouse
clicks in a window to control actions for one or more other windows
(i.e. you could logically group windows and then control all of
them via mouse clicks)? That would maybe let you easily connect
output from a process in one window to another? that would let you
build little widgets that could easily control other windows? That
would let you display all window state in another window? That
would let you set, say, all windows with a browser with the label
abaco-### (### a number), with a simple text command; and let you
find all windows with the label abaco.* with, in the limit, a grep?
That would make it easy to group all windows with the label
'abaco.*' so that you could say 'hide all abaco' with a simple script?
Wouldn't that be neat? I mean, that's a real bitch in X, right?
Except ... you already have it.
And this is what makes me such a fan of the Plan 9 model.

Now if people wanted to do something "end-user-ish" perhaps they
could produce those little handy tools, and hook them up to some
simple window decorations (but that still somehow work the natural
way they do now - perhaps a "decorated" mirror file server).

But the effort is doomed to failure - end-user-pleasers want more eye
candy than can be coordinated without a good professional designer
riding whip on the project.

I'm a big fan of the extreme wire-it-together we get from unixish
tools + plan 9 file servers, but it's an environment for experts, not
end-users.

Paul
ems
2006-06-08 05:26:44 UTC
Permalink
Post by Ronald G Minnich
What if you had a window manager that could be recursive? that would set
it up so you can name windows by a path name? that would let you treat
the recursive desktops -- to any level -- as just another window? that
would trivially allow you to connect mouse clicks in a window to control
actions for one or more other windows (i.e. you could logically group
windows and then control all of them via mouse clicks)? That would maybe
let you easily connect output from a process in one window to another?
that would let you build little widgets that could easily control other
windows? That would let you display all window state in another window?
That would let you set, say, all windows with a browser with the label
abaco-### (### a number), with a simple text command; and let you find
all windows with the label abaco.* with, in the limit, a grep? That
would make it easy to group all windows with the label 'abaco.*' so that
you could say 'hide all abaco' with a simple script?
________________________
| It looks like you're |
| playing with rio. |
| |
| Would you like help? |
| |
| * Get help with |
| hiding windows |
| |
| * Just hide the |
| windows without |
| help |
| _ |
||_| Don't show me |
| this tip again |
|______ ______________|
\ |
\|
Glenda

Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)
Simon Williams
2006-06-08 05:43:57 UTC
Permalink
Dont knock the paper clip - just the implementation
The people who designed it ( at Microsoft Research ) are seriously excellent
Bayesan statisticians who names i have forgotten ( apologies ). The problem
for the marketroids was that it didnt appear often enough for them to sell
it as a feature so they took all the careful tuned parameters and wound them
up to 11 creating the monster we have today.
Simon
Post by ems
Post by Ronald G Minnich
What if you had a window manager that could be recursive? that would set
it up so you can name windows by a path name? that would let you treat
the recursive desktops -- to any level -- as just another window? that
would trivially allow you to connect mouse clicks in a window to control
actions for one or more other windows (i.e. you could logically group
windows and then control all of them via mouse clicks)? That would maybe
let you easily connect output from a process in one window to another?
that would let you build little widgets that could easily control other
windows? That would let you display all window state in another window?
That would let you set, say, all windows with a browser with the label
abaco-### (### a number), with a simple text command; and let you find
all windows with the label abaco.* with, in the limit, a grep? That
would make it easy to group all windows with the label 'abaco.*' so that
you could say 'hide all abaco' with a simple script?
________________________
| It looks like you're |
| playing with rio. |
| |
| Would you like help? |
| |
| * Get help with |
| hiding windows |
| |
| * Just hide the |
| windows without |
| help |
| _ |
||_| Don't show me |
| this tip again |
|______ ______________|
\ |
\|
Glenda
Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)
Bruce Ellis
2006-06-08 06:09:59 UTC
Permalink
Dont knock the paper clip - excellent way to get stuck media
out of a Mac.

If you want gcc then port it ... it won't change my world. Run
whatever you like. Have fun, dhog didn't.

brucee
Post by Simon Williams
Dont knock the paper clip - just the implementation
The people who designed it ( at Microsoft Research ) are seriously excellent
Bayesan statisticians who names i have forgotten ( apologies ). The problem
for the marketroids was that it didnt appear often enough for them to sell
it as a feature so they took all the careful tuned parameters and wound them
up to 11 creating the monster we have today.
Simon
Post by ems
Post by Ronald G Minnich
What if you had a window manager that could be recursive? that would set
it up so you can name windows by a path name? that would let you treat
the recursive desktops -- to any level -- as just another window? that
would trivially allow you to connect mouse clicks in a window to control
actions for one or more other windows (i.e. you could logically group
windows and then control all of them via mouse clicks)? That would maybe
let you easily connect output from a process in one window to another?
that would let you build little widgets that could easily control other
windows? That would let you display all window state in another window?
That would let you set, say, all windows with a browser with the label
abaco-### (### a number), with a simple text command; and let you find
all windows with the label abaco.* with, in the limit, a grep? That
would make it easy to group all windows with the label 'abaco.*' so that
you could say 'hide all abaco' with a simple script?
________________________
| It looks like you're |
| playing with rio. |
| |
| Would you like help? |
| |
| * Get help with |
| hiding windows |
| |
| * Just hide the |
| windows without |
| help |
| _ |
||_| Don't show me |
| this tip again |
|______ ______________|
\ |
\|
Glenda
Sorry, I couldn't help myself. (BTW, is there ACSII Glenda anywhere?)
Ronald G Minnich
2006-06-08 05:20:21 UTC
Permalink
Post by Roman Shaposhnik
One question that I still have, though,
is what
makes you think that once you're done with porting gcc (big task) and
porting HPC apps to
gcc/Plan9 (even bigger one!) they will *execute* faster than they do on
Linux ?
Excellent question.

It's all about parallel performance; making sure your 1000 nodes run
1000 times as fast as 1 node, or, if they don't, that it's Somebody
Else's Problem. The reason that the OS can impact parallel performance
boils down to the kinds of tasks that go on in OSes that can be run at
awkward times,and in turn interfere with parallel applications, and
result in degraded performance. (for another approach, see Cray's
synchronised scheduler work; make all nodes schedule the app at the same
time).

Imagine you have one of these lovely apps, on a 1000-node cluster with a
5-microsecond latency network. Let us further imagine (this stuff
exists; see Quadrics) that you can do a broadcast/global sum op in 5
microseconds. After 1 millisecond, they all need to talk to each other,
and can not proceed until they're all agreed on (say) the value of a
computed number -- e.g. some sort of global sum of a variable held by
each of 1000 procs. The generic term for this type of thing is 'global
reduction' -- you reduce a vector to a scalar of some sort.

The math is pretty easy to do, but it boils down to this: OS activities
can interfere with, say, just one task, and kill the parallel
performance of the app, making your 1000-node app run like a 750 node
app -- or worse.

Pretend you're delayed one microsecond; do the math; it's depressing.
One millisecond compute interval is a really extreme case, chosen for
ease of illustration, but ...

In the clustering world, what a lot of people do is run real heavy nodes
in clusters -- they have stuff like cron running, if you can believe it!
They pretty much do a full desktop install, then turn off a few daemons,
and away they go. Some really famous companies actually run clusters
this way -- you'd be surprised at who. So do some famous gov't labs.

If they're lucky, interference never hits them. If they're not, they get
less-than-ideal app performance. Then, they draw a conjecture from the
OS interference that comes with such bad configuration: you can't run a
cluster node with anything but a custom OS which has no clock
interrupts, and, for that matter, no ability to run more than one
process at a time. See the computational node kernel on the BG/L for one
example, or the catamount kernel on Red Storm. Those kernels are really
constrained; just running one proc at a time is only part of the story.

Here at LANL, we run pretty light cluster nodes.

Here is a cluster node running xcpu (under busybox, as you can see):
1 ? S 0:00 /bin/ash /linuxrc
2 ? S 0:00 [migration/0]
3 ? SN 0:00 [ksoftirqd/0]
4 ? S 0:00 [watchdog/0]
5 ? S 0:00 [migration/1]
6 ? SN 0:00 [ksoftirqd/1]
7 ? S 0:00 [watchdog/1]
8 ? S 0:00 [migration/2]
9 ? SN 0:00 [ksoftirqd/2]
10 ? S 0:00 [watchdog/2]
11 ? S 0:00 [migration/3]
12 ? SN 0:00 [ksoftirqd/3]
13 ? S 0:00 [watchdog/3]
14 ? S< 0:00 [events/0]
15 ? S< 0:00 [events/1]
16 ? S< 0:00 [events/2]
17 ? S< 0:00 [events/3]
18 ? S< 0:00 [khelper]
19 ? S< 0:00 [kthread]
26 ? S< 0:00 [kblockd/0]
27 ? S< 0:00 [kblockd/1]
28 ? S< 0:00 [kblockd/2]
29 ? S< 0:00 [kblockd/3]
105 ? S 0:00 [pdflush]
106 ? S 0:00 [pdflush]
107 ? S 0:00 [kswapd1]
109 ? S< 0:00 [aio/0]
108 ? S 0:00 [kswapd0]
110 ? S< 0:00 [aio/1]
111 ? S< 0:00 [aio/2]
112 ? S< 0:00 [aio/3]
697 ? S< 0:00 [kseriod]
855 ? S 0:00 xsrv -D 0 tcp!*!20001
857 ? S 0:00 9pserve -u tcp!*!20001
864 ? S 0:00 u9fs -a none -u root -m 65560 -p 564
865 ? S 0:00 /bin/ash

see how little we have running? Oh, but wait, what's all that stuff in
[]? It's the stuff we can't turn off. Note there is per-cpu stuff, and
other junk. Note that this node has been up for five hours, and this
stuff is pretty quiet(0 run time); our nodes are the quietest (in the OS
interference sense) Linux nodes I have yet seen. But, that said, all
this can hit you.

And, in Linux, there's a lot of stuff people are finding you can't turn
off. Lots of timers down there, lots of magic that goes on, and you just
can't turn it off, or adjust it, try as you might.

Plan 9, our conjecture goes, is a small, tight, kernel, with lots of
stuff moved to user mode (file systems); and, we believe that the Plan 9
architecture is a good match to future HPC (High Performance Computing)
systems, as typified by Red Storm and BG/L: small, fixed-configuration
nodes with memory, network, CPU, and nothing else. The ability to not
even have a file system on the node is a big plus. The ability to
transparently have the file system remote/local puts the application
into the driver's seat as to how the node is configured, and what
tradeoffs are made; the system as a whole is incredibly flexible.

Our measurements, so far, do show that Plan 9 is "quieter" than Linux. A
full Plan 9 desktop has less OS noise than a Linux box at the login
prompt. This matters.

But it only matters if people can run their apps. Hence our concern
about getting gcc-based cra-- er, applications code, running.

I'm not really trying to make Plan 9 look like Linux. I just want to run
MPQC for a friend of mine :-)

thanks

ron
Federico G. Benavento
2006-06-08 06:08:41 UTC
Permalink
Post by Ronald G Minnich
I'm not really trying to make Plan 9 look like Linux. I just want to run
MPQC for a friend of mine :-)
gcc/g++/whatever crap is needed, if you are a human being you need apps
I don't like gcc either, but having to write every app by hand it's not an option.
Victor Nazarov
2006-06-08 09:39:59 UTC
Permalink
Post by Ronald G Minnich
Post by Francisco J Ballesteros
Venti. I just sold Plan 9 services to our local set of linux users. Our
dept. server (a linux box) crashed. I know, they know, but there were
no complete backup for the system. It´s just so simple to manage
distributed
resources with Plan 9, that this is just the type of thing to sell.
yeah, fossil/venti does get people excited.
Post by Francisco J Ballesteros
But anyway, going back to this thread of gcc/etc.etc. Isn´t p9p what
you are seeking for?
no, I want plan 9, not linux tarted up to look like Plan 9. Although
p9p is sure good stuff.
ron
What about incorporating Plan9 kernel into Linux kernel? ;) Some steps
have been already done, I think.
--
Victor
Corey
2006-06-07 20:01:18 UTC
Permalink
Post by Latchesar Ionkov
Post by Roman Shaposhnick
That is a doable thing. But I fail to see what it strives to
accomplish on the application level, unless, of course, the other
"secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
etc.) along the way.
We would like to convince some people that Plan9 (kernel) is a useful
alternative to Linux without asking them to rewrite all their
applications.
I'm thinking in a very similar way as what Latchesar is expressing.
Roman Shaposhnick
2006-06-07 20:16:37 UTC
Permalink
Post by Latchesar Ionkov
Post by Roman Shaposhnick
Post by Latchesar Ionkov
It will use GNU binutils.
What about libc ? Surely you can't expect UNIX applications
to be happy without libc or better yet glibc. Do you intend
to port it as well ?
We will try to use APE.
That could be interesting.
Post by Latchesar Ionkov
Post by Roman Shaposhnick
That is a doable thing. But I fail to see what it strives to
accomplish on the application level, unless, of course, the other
"secret pact" was to bring all the GNU cruft (like glibc, libstdc++,
etc.) along the way.
We would like to convince some people that Plan9 (kernel) is a useful
alternative to Linux without asking them to rewrite all their
applications. Like it or not, most people won't consider spending man-
months in effort just to check if an alternative is better.
Especially if there is not much hype surrounding the alternative :)
True. However, even in Linux circles the idea that "GNU is not Unix,
but sure seems like a lot of cruft" is now getting some recognition.
Personally, I would very much welcome (to the point of participating
myself) any effort which aims at writing a clean C99 environment
(including compiler, libc, etc.) one can use without losing sanity.

On the application front I would expect it to be a drop-in replacement
for a glibc/gcc (may be with a couple of fixes here and there).

Is it similar to what you have in mind ?
Post by Latchesar Ionkov
Post by Roman Shaposhnick
Please explain what's your next step, as far as application
migration is concerned ?
As Ron mentioned the immediate objectives are running MPQC and some
HPC benchmarks.
What benchmarks are these ? Since I'm in HPC business myself (or at
least I work for a team, that works for a company which tries to be
in HPC business) I'm very curious to know what your expectations
are w.r.t migrating from UNIX kernel to Plan9.

Thanks,
Roman.
Ronald G Minnich
2006-06-07 20:15:53 UTC
Permalink
Post by William Josephson
Post by Ronald G Minnich
no, I don't completely agree. We need gcc for general use, period.
Unless we like living in a cardboard box in an alley forever.
Are you mostly concerned about support for gcc language extensions
or about support for things like C++?
I hate to say it, but in the scientific computing world, you either do
gcc compatibility, 100%, or you run gcc, or you don't get used. That's
it. Many companies we deal with had to do extensive work to their
compilers to get apps to run, i.e. they had to make them gcc-compatible.
It's sad, I don't like it, but that's the way it is.

I'm really tired of telling people how nice plan 9 is, then having them
ask me how to compile xyz, and having to tell them they have to do a
port. That's pretty much where their interest ends.

But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the
out-of-kernel picture is not great, since we lack gcc or gcc-compatible
compilers.


ron
Ronald G Minnich
2006-06-07 20:17:05 UTC
Permalink
Post by Roman Shaposhnick
So, is it mostly a backend or a frontend problem ?
all of the above. Just get MPQC (google it) and then try to build it.
Post by Roman Shaposhnick
Could you, please, elaborate on what exactly these apps
need from gcc ?
no. There's too long a list for email.
Post by Roman Shaposhnick
I don't really think that with a difference in evironment
between Linux and Plan9 the later holds true.
have you looked at the apps?
Post by Roman Shaposhnick
Sorry, I just fail to see how porting gcc would help. Hence
to make this discussion a bit more concrete could you, please,
be more specific about what exact gcc functionality do you think
would be beneficial to native Plan9 ?
gcc compatibility.

ron
Ronald G Minnich
2006-06-07 20:17:55 UTC
Permalink
Post by Corey
I really appreciate plan 9's focus, and agree that it should be maintained.
The whole point of this idea I'm toying with is to ditch the cruft and
luggage of today's linux-based os's.
Me, I want more Plan 9 users. It's a great kernel, but it's going to
continue to fall behind if we don't get more people on it.

ron
Roman Shaposhnick
2006-06-07 20:21:07 UTC
Permalink
Post by Ronald G Minnich
Post by William Josephson
Post by Ronald G Minnich
no, I don't completely agree. We need gcc for general use, period.
Unless we like living in a cardboard box in an alley forever.
Are you mostly concerned about support for gcc language extensions
or about support for things like C++?
I hate to say it, but in the scientific computing world, you either do
gcc compatibility, 100%, or you run gcc, or you don't get used. That's
it. Many companies we deal with had to do extensive work to their
compilers to get apps to run, i.e. they had to make them gcc-compatible.
It's sad, I don't like it, but that's the way it is.
I truly share your sentiment because that's exactly what I hear from
my customers as well. Now, what's interesting is -- are you talking about
Fortran scientific apps or something else ? Because if fortran is anywhere
to be found than surely these guys must use something else rather than
gcc at least occasionally. After all, up until 2004 fortran support in
gcc used to be a total joke.
Post by Ronald G Minnich
I'm really tired of telling people how nice plan 9 is, then having them
ask me how to compile xyz, and having to tell them they have to do a
port. That's pretty much where their interest ends.
Could you give examples of such apps, or are they internal ?
Post by Ronald G Minnich
But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the
out-of-kernel picture is not great, since we lack gcc or gcc-compatible
compilers.
I'm curious. Tell me more. See my earlier question to Latchesar.

Thanks,
Roman.
Roman Shaposhnick
2006-06-07 20:27:23 UTC
Permalink
Post by Ronald G Minnich
Post by Corey
I really appreciate plan 9's focus, and agree that it should be maintained.
The whole point of this idea I'm toying with is to ditch the cruft and
luggage of today's linux-based os's.
Me, I want more Plan 9 users. It's a great kernel, but it's going to
continue to fall behind if we don't get more people on it.
Once again: I hope I was able to make my point clear that I'm not
against the idea in general, but rather I'm very cautios about
the way it can go.

That said, however, I feel pretty strong about one thing -- if by
"getting more people on it" we are going to end up with a Linux-looking
GNU-based beast that takes a mental asylum patient to support and maintain
then I urge you to reconsider. If they want Linux they know where to
find it.

Thanks,
Roman.

P.S. Unfortunately, that's exactly what is going on with Linux desktop
these days. People are hungry for Windows/MacOS but without a license fee.
That in turn twists core UNIX technology so much that you can't recognize
it anymore. Which is a shame... :-(
Ronald G Minnich
2006-06-07 20:41:39 UTC
Permalink
Post by Roman Shaposhnick
On the application front I would expect it to be a drop-in replacement
for a glibc/gcc (may be with a couple of fixes here and there).
good idea, but ... how do we avoid making another APE?

ron
Roman Shaposhnik
2006-06-08 06:50:09 UTC
Permalink
Post by Ronald G Minnich
Post by Roman Shaposhnick
On the application front I would expect it to be a drop-in replacement
for a glibc/gcc (may be with a couple of fixes here and there).
good idea, but ... how do we avoid making another APE?
APE has a slightly different purpose.
What I'm after is a C99 complete environment,
not a POSIX-complete one.

Thanks,
Roman.
Ronald G Minnich
2006-06-07 20:43:37 UTC
Permalink
Post by Roman Shaposhnick
I truly share your sentiment because that's exactly what I hear from
my customers as well. Now, what's interesting is -- are you talking about
Fortran scientific apps or something else ? Because if fortran is anywhere
to be found than surely these guys must use something else rather than
gcc at least occasionally. After all, up until 2004 fortran support in
gcc used to be a total joke.
It's just that I can't think of a single scientific app that runs on
Plan 9. Oh, maybe that one Andrey ported. But stuff like nwchem, mpqc,
NAS PB, the HPCS benchmarks, ... it's a long list.
Post by Roman Shaposhnick
Could you give examples of such apps, or are they internal ?\
some internal. Actually, just go find about any C++ app, or get the R
framework, and see all the stuff it does ... eek.

ron
Ronald G Minnich
2006-06-07 20:44:19 UTC
Permalink
Post by Roman Shaposhnick
That said, however, I feel pretty strong about one thing -- if by
"getting more people on it" we are going to end up with a Linux-looking
GNU-based beast that takes a mental asylum patient to support and maintain
then I urge you to reconsider. If they want Linux they know where to
find it.
point taken.

It's a tough thing to do. And, I agree, Linux seems to all about
emulating windows nowadays. Gross.

ron
William Josephson
2006-06-07 20:49:18 UTC
Permalink
Post by Ronald G Minnich
But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the
out-of-kernel picture is not great, since we lack gcc or gcc-compatible
compilers.
The gcc C extensions are much more tractable than C++,
hence the question.
Roman Shaposhnick
2006-06-07 20:50:33 UTC
Permalink
Post by Ronald G Minnich
Post by Roman Shaposhnick
So, is it mostly a backend or a frontend problem ?
all of the above. Just get MPQC (google it) and then try to build it.
I'm doing it right now. It looks like a C++ application which means
that your task of porting it to plan9 will be even more difficult
than I previously though. It also looks like the sort of C++ they
use is not strictly speaking ISO STD complaint. But I need more
time to dig into this.
Post by Ronald G Minnich
Post by Roman Shaposhnick
Could you, please, elaborate on what exactly these apps
need from gcc ?
no. There's too long a list for email.
But do you have this list ?
Post by Ronald G Minnich
Post by Roman Shaposhnick
I don't really think that with a difference in evironment
between Linux and Plan9 the later holds true.
have you looked at the apps?
If by the apps you mean MPQC -- I'm looking at it right now.
If by the apps you mean other OpenSource apps, there's a list
of about 500+ of them I'm looking at on a weekly basis. Most
of them have a pretty long list of non-trivial dependencies
on Linux environment.
Post by Ronald G Minnich
Post by Roman Shaposhnick
Sorry, I just fail to see how porting gcc would help. Hence
to make this discussion a bit more concrete could you, please,
be more specific about what exact gcc functionality do you think
would be beneficial to native Plan9 ?
gcc compatibility.
Well, all I can say is -- its a pity that even more resources will
be spent on proliferating gcc's bad influence on application developers.

I understand that most likely you're doing it as part of your job which
means that you don't really have a choice.

Thanks,
Roman.

P.S. Is it that even HPC community is so commercialized and time-to-market
oriented these days that there's no light at the end of the tunnel ? Looks
like as far as Plan9 community is concerned, the only place where the
decisions are not dictated by the mighty VOC is Nemo's research lab.
Europe vs. USA kinda thing... I don't know...
Ronald G Minnich
2006-06-07 21:01:03 UTC
Permalink
Post by William Josephson
Post by Ronald G Minnich
But, in many ways, plan 9 is an ideal kernel for HPC. It's just that the
out-of-kernel picture is not great, since we lack gcc or gcc-compatible
compilers.
The gcc C extensions are much more tractable than C++,
hence the question.
good point.

There is some requirement for C++, I have to go back and figure out all
the places. People use G++ or python or even perl ...

ron
Ronald G Minnich
2006-06-07 21:06:00 UTC
Permalink
Post by Roman Shaposhnick
If by the apps you mean MPQC -- I'm looking at it right now.
If by the apps you mean other OpenSource apps, there's a list
of about 500+ of them I'm looking at on a weekly basis. Most
of them have a pretty long list of non-trivial dependencies
on Linux environment.
IMHO, you know more than I do at this point!

So, what's our problem :-) Is all hope lost?

Is this mess fixable? If so, how?
Post by Roman Shaposhnick
Well, all I can say is -- its a pity that even more resources will
be spent on proliferating gcc's bad influence on application developers.
The world sucks. I could not agree more. Propagating all this gnu stuff
is depressing, makes me wish I did something else for a living
sometimes. I sort of watch with amazement as people work on the segment
layout of their ELF files, and discuss what to inline. arg!

thanks, I think you've educated me (I'm dead serious).

ron
Roman Shaposhnik
2006-06-08 06:43:26 UTC
Permalink
Post by Ronald G Minnich
IMHO, you know more than I do at this point!
Relatively speaking ;-) I once tried to do the same thing I do with
these 500+ apps with everything that's
available through the Gentoo portage system. To say that I was surprised
would be a gross
understatement. :-(
Post by Ronald G Minnich
So, what's our problem :-) Is all hope lost?
Is this mess fixable? If so, how?
Now that I understand your goal (which is to provide a way for running a
preselected
set of HPC apps on a Plan9 system) and I can stop confusing it with
inventing a magic
G-wand I'd say that your biggest challenge will be to carefully
retarget the apps in
question from (L)POSIX/C++ environment. I don't believe its a lost
cause, but it all
depends on how messy the apss will turn out to be.

I don't know much about the apps, but here's a list of issues I
personally confronted
while porting Sun Studio C/C++ compiler from Solaris to Linux:

It doesn't matter whether its C, C++ or Fortran -- nowadays its all
about autotools/libtool
recognizing your system, and let me tell you these guys are *wild*. Case
in point: when we
first ported our seed C compiler autoconf was convinced that it was a
PGI compiler running
on an Open?BSD system -- go figure. Once you get past configuring the
apps, every C/C++
compiler gets confronted with two essential interfaces: glibc and
linker/ELF. For a C compiler
dependency on ELF is less of an issues, but for a C++ one its a pretty
big deal. In fact
we had seriously considered porting Solaris ld to Linux just so that we
don't have to depend
on GNU ld messing up object files (we ended up fixing GNU ld, but its a
different story).
Next comes the glibc, which in turn, depends on Linux kernel headers and
wants to get into
compiler business all the time by providing "kosher" crt*.o and
demanding a certain way
of tickling its internals for things like IEEE floating point support to
work properly.

The biggest problem with all of this is that the way C99 (and portions
of the C++) standard
are structured makes it impossible to have a properly functioning
application unless
you have glibc support in certain areas. One of the reasons GCC can't
claim
C99 compliance is because glibc sucks (you can find more on that right here:
http://gcc.gnu.org/gcc-4.1/c99status.html).

Now, you say that you're going to use APE and there I have serious
doubts that things
like FP exception handling and C99 complex will work for you. These two
proved
to be quite essential for the set of HPC apps I have internally from
*our* customers.

Now, suppose that you've overcome all of that. What's next ? C++ of course!

C++ with things like templates instantiations in ELF COMDAT sections and
exception
handling support places lots of additional requirements on how flexible
linker should
be in handling ELF files. Speaking of which -- do you intend to port ELF
to Plan9 as well ?

Once you get past codegeneration the glibc will rear its ugly head once
again. This time
around it'll be about supporting C++ header files which are just there
to wrap around
standard C headers in the latest and greatest std:: namespace. Of
course, I'm talking
about things like <cstring> and <cstdlib>. There again you will start
battling how
gcc configures itself on different systems and how it all can be hooked
up to APE.

Oh, and there's also a question of what to do about MT apps. I'd be very
curious to
know how would you go about solving it on Plan9 as far as PTHREADS are
concerned.
Or may be your apps don't use any (which I find hard to believe for an
HPC market).

That's about it when it comes to the biggies. The sort of things I
distinctly remember
suffering through on a personal level.

On the application level you still have to tame dependencies on things
which go beyond
the scope of C99 or ISO C++ standards, but that's a story for another day.
Post by Ronald G Minnich
Post by Roman Shaposhnick
Well, all I can say is -- its a pity that even more resources will
be spent on proliferating gcc's bad influence on application developers.
The world sucks. I could not agree more. Propagating all this gnu
stuff is depressing, makes me wish I did something else for a living
sometimes. I sort of watch with amazement as people work on the
segment layout of their ELF files, and discuss what to inline. arg!
thanks, I think you've educated me (I'm dead serious).
Well, I'm glad my emails weren't in vain. I'm very curious to see
how far you can go with the approach
you've chosen, and I'd be glad to share more of the porting experience.
Feel free to drop me emails
on this subject. I've been there and there's a chance I might be able to
help you guys.

Thanks,
Roman.
Iruatã Souza muzgo
2006-06-08 07:00:57 UTC
Permalink
(...). Speaking of which -- do you intend to port ELF
to Plan9 as well ?
Static ELF is already ported by Russ.
Dynamic is coming soon.

Iruatã Souza (muzgo)
Ronald G Minnich
2006-06-07 21:50:50 UTC
Permalink
Post by Christoph Lohmann
Good evening.
Am Wed, 7 Jun 2006 13:17:25 -0600 schrieb Latchesar Ionkov
Post by Latchesar Ionkov
What I am planning to do (and that's what we agreed on the Secret
Plan 9 Secret Society Society meeting :) is just migrate dhogs changes
to the newest versions of the GNU utils.
In the Dissident Plan 9 IRC Kids meeting we decided that SP9SSS sucks
really hard. Does that make you any better?
of course it sucks. All secret societies do. But we have such fine
fashion style!

ron
David Leimbach
2006-06-07 22:16:48 UTC
Permalink
Post by Corey
Post by Rodolfo kix
God save us from QT and GTK ;)
Will god likewise save us from Rio and Acme?
In fact I use rio in Linux at my job. And by now I don't use Acme
because I have to deal with veryawfulcode (lots of very bad indentations
fruit of many tab/spaces/tab/spaces at code changes, functions more than
1500 lines long, an unworkable hierarchy of header files...). I agree
that acme is really pleasant for well-written code. As an example, I
like surfing plan9's with it. Also my code looks better if it's written
with acme, but this part is too subjective. :)
Let's wonder why there is plan9port but there is no gcc in plan9.
I think a part of the problem is the momentum that linux got, and
people have been fighting with the pains of migrating from windows
(those that try to use linux as a desktop OS). Many people got
frustrated with Linux and went to Mac OS X.

I don't see Plan 9 as a desktop OS for sure, but thanks to
virtualization technology (which certainly isn't new), I can run Plan
9 on my desktop in it's own VM and use the bits of Plan 9 that I want
or feel that I need. P9P also helps here.

I'm not sure if we've got any killer apps to bring people to Plan 9 though.

Mac OS X has the "Ooooh Shiny" effect on people.
Linux had uhm... Apache I guess that helped it get off the ground as a
viable alternative to expensive servers.

So the question is really, what does plan 9 do better that people
actually care about?

I usually don't have a good answer for this question. I'm not sure
saying "support gcc and all our problems are solved" is a good
approach though.

There's gotta be something we can do the Plan 9 way to WOW people
enough to give it a first or even second look.

As for me... I like operating systems, sometimes I wonder why, but I do.
Francisco J Ballesteros
2006-06-07 22:32:10 UTC
Permalink
Post by David Leimbach
So the question is really, what does plan 9 do better that people
actually care about?
I know! I know! :-)

Venti. I just sold Plan 9 services to our local set of linux users. Our
dept. server (a linux box) crashed. I know, they know, but there were
no complete backup for the system. It´s just so simple to manage distributed
resources with Plan 9, that this is just the type of thing to sell.

But anyway, going back to this thread of gcc/etc.etc.
Dan Cross
2006-06-07 22:55:47 UTC
Permalink
Post by Ronald G Minnich
of course it sucks. All secret societies do. But we have such fine
fashion style!
Fashion and style sense are not the same thing.

- Dan C.
q***@quanstro.net
2006-06-08 01:39:48 UTC
Permalink
On Wed Jun 7 17:07:21 CDT 2006, ***@gmail.com wrote:

acme and previously sam has done me well with all manner of badly formatted
and ill-concieved c, c++, perl, pre-f77 fortran, etc.

perhaps i don't get it, but there's nothing i've seen in other editors that helped
with bad code. bad code is just as bad in colour -- and harder on the eyes.
Post by Corey
Will god likewise save us from Rio and Acme?
In fact I use rio in Linux at my job. And by now I don't use Acme
because I have to deal with veryawfulcode (lots of very bad indentations
fruit of many tab/spaces/tab/spaces at code changes, functions more than
1500 lines long, an unworkable hierarchy of header files...). I agree
that acme is really pleasant for well-written code. As an example, I
like surfing plan9's with it. Also my code looks better if it's written
with acme, but this part is too subjective. :)
c***@gli.cas.cz
2006-06-08 07:09:32 UTC
Permalink
IMHO, I don't see any advantage in having gnustep/openstep/nextstep
stuff (except, maybe, displayPS/PDF), on Plan9.
And yes, I am a former nextstep user, believe me or not...
For example, GNUstep depends not just on the compiler, but also on many
services you find today on Linux and
similar UNIXes. Trying to pull that into Plan 9 would force you to pull
many other stuff as well.

++ pac
-------------------------------------------------
PDF is to PS as lung cancer is to lung......
-------------------------------------------------
q***@quanstro.net
2006-06-08 09:30:02 UTC
Permalink
as noted before, page already handles ps/pdf.

- erik
Post by c***@gli.cas.cz
IMHO, I don't see any advantage in having gnustep/openstep/nextstep
stuff (except, maybe, displayPS/PDF), on Plan9.
And yes, I am a former nextstep user, believe me or not...
r***@vitanuova.com
2006-06-08 12:00:11 UTC
Permalink
Post by q***@quanstro.net
as noted before, page already handles ps/pdf.
this is true. however i wouldn't mind seeing some way
of doing nice looking drawing under plan 9 (not that i'm implying that
display pdf is suitably lightweight!). the draw ops implemented
by /dev/draw are not really good for anything except crude looking
diagrams - jaggies galore, and not enough positioning accuracy.
by way of illustration, observe how the implementation of line()
needs to use sub-pixel accuracy in order to get reasonable looking arrows.

i reckon you could strip out ellipse, line and polygon from devdraw
and almost nothing would notice. but replacing them is quite a bit of work...
c***@gli.cas.cz
2006-06-08 07:25:01 UTC
Permalink
Post by Federico G. Benavento
Post by Ronald G Minnich
I'm not really trying to make Plan 9 look like Linux. I just want to
run
MPQC for a friend of mine :-)
gcc/g++/whatever crap is needed, if you are a human being you need apps
I don't like gcc either, but having to write every app by hand it's not
an option.

But it's the WAY. I started with APE ports, now I'm trying to go native.
As a non-+programmer (biologist, mainly), my learning curve is too steep
compared to human life's length, I agree.
But:
Once you have gcc, would anyone other bother to rewrite your ported
program natively??

Thanks, regards, ++pac.
_________________________________________________________

C++ is to c as lung cancer is to lung ...
_________________________________________________________
c***@gli.cas.cz
2006-06-08 07:31:01 UTC
Permalink
Post by Lyndon Nerenberg
No, we need fresh ideas. An infinite number of monkeys turning Plan
9 into Linux is not progress.
I agree 100%. Although I would LOVE to have some loonix prgs w/o
rebooting to L. Or c++, java, perl, etc...
Attract more people to the clean design (and they will, hopefully,
rewrite everything that is(isn't;-) worth it...
IMHO.

++pac.
Lluís Batlle
2006-06-08 09:35:56 UTC
Permalink
Maybe something capable of running an isolated linux box in plan9's
environment would do the trick, as some people do right now in Linux
in order to run plan9. Let's say... a 'xen-like-thing' running on
plan9, for running other kernels over the same hardware.

Of course, I don't plan coding that.
Post by c***@gli.cas.cz
Post by Lyndon Nerenberg
No, we need fresh ideas. An infinite number of monkeys turning Plan
9 into Linux is not progress.
I agree 100%. Although I would LOVE to have some loonix prgs w/o
rebooting to L. Or c++, java, perl, etc...
Attract more people to the clean design (and they will, hopefully,
rewrite everything that is(isn't;-) worth it...
IMHO.
++pac.
Continue reading on narkive:
Loading...