rewriting your stuff is an eye opener though -- it mostly involves removing code that shouldn't be there in the first place but was forced upon you by unix' legacy crap.
how about we go back to basics and read the proper books on computer science? no need for your shmancy-fancy-'voice debugged'-automagically-'quality assured' offerings, thanks.
i'll stick with The Practice of Programming. at the very least i trust the people who wrote it to have a better judgement.
Google knows that 80% of mail messages are text, and we all know that text is highly compressible. That said, they probably only have around 2-300MB of storage allocated for each 1GB account (obviously this will fluctuate up to 1GB depending on the user's mail content). My take on this, is that they have a huge series of RAID arrays at their server farm. Every time an email comes in, it is compressed and stored in that users account on the RAID.
I've seen "non-embarrassingly parralel" tasks and, believe me, compiling a kernel isn't one. Proof: distcc for Plan 9 is implemented in 10 lines of shell code.
BTW, I wasn't suggesting Ken's C compilers for Linux, not at all -- Linux can have gcc (and distcc for that matter), for they deserve each other:)
Don't get caught offguard by the snide remarks. If you think P9 is elitist then you're quite right -- the compilers were designed and written by Ken Thompson, the gui and editors by Rob Pike, the networking code by Dave Presotto, the group manager was Dennis Ritchie. With such a team you're guaranteed to end up with a well thought-out system, compared to which such puny hacks as distcc seem a waste of time and lack of vision.
Sure, nobody's using it. Everyone tries to emulate it, though. Unsuccessfuly.
nothing but gcc can compile the linux kernel anyway:)
sure you can get sub-minute compile times with 1024 machines at your disposal -- it's an embarrasingly parralel problem. you can even get less than 10-second compile with a 32way pSeries p690. at what cost, though?
I compile my programs once, then use them for MONTHS on end.
And then they spend most of their time waiting for IO.
Only in HPC do you ever look for ultra-optimized code and even then you end up running your code twice (or more) to verify your answer.
Most machines (including yours) are running at load levels way below 1 (unless they aren't dedicating wasted cycles to SETI or somesuch, which itself confirms they have cycles to waste).
Plan 9's compilers may produce 20% slower code, but when a (true) developer sees 10 times decrease in compile time they immediately realize the benefit. Just ask DeRaadt or Viro whether they would prefer a kernel compile in 8, 80 or 800 seconds (and guess which one they get with Plan 9's C compilers).
more bragging, now with history and remote filesystems (pity it only goes back to 2002 online, on BL's internal servers you could possibly trace it back to when the 386 port was done, sometime before OpenBSD even existed):
plan9% history/n/sources/plan9/386/9pccpu Jun 18 22:15:51 MDT 2004/n/sources/plan9/386/9pccpu 1466062 [jmk] Jun 18 22:15:51 MDT 2004/n/sourcesdump/2004/0628/plan9/386/9pccpu 1466062 [jmk] May 26 08:58:13 MDT 2004/n/sourcesdump/2004/0618/plan9/386/9pccpu 1464801 [jmk] Feb 17 13:23:06 MST 2004/n/sourcesdump/2004/0526/plan9/386/9pccpu 1485859 [presotto] Nov 9 06:50:22 MST 2003/n/sourcesdump/2004/0217/plan9/386/9pccpu 1471511 [rsc] Sep 26 11:47:07 MDT 2003/n/sourcesdump/2003/1109/plan9/386/9pccpu 1490617 [rsc] Jun 23 04:33:55 MDT 2003/n/sourcesdump/2003/0926/plan9/386/9pccpu 1474348 [rsc] May 17 13:49:27 MDT 2003/n/sourcesdump/2003/0623/plan9/386/9pccpu 1463526 [rsc] Mar 28 15:08:57 MST 2003/n/sourcesdump/2003/0517/plan9/386/9pccpu 1463207 [rsc] Feb 20 14:30:56 MST 2003/n/sourcesdump/2003/0328/plan9/386/9pccpu 1455559 [rsc] Feb 17 20:15:06 MST 2003/n/sourcesdump/2003/0220/plan9/386/9pccpu 1455620 [rsc] Dec 15 19:39:00 MST 2002/n/sourcesdump/2003/0217/plan9/386/9pccpu 1448231 [rsc] Dec 13 00:32:50 MST 2002/n/sourcesdump/2002/1215/plan9/386/9pccpu 1429714 [rsc] Sep 22 22:23:01 MDT 2002/n/sourcesdump/2002/1212/plan9/386/9pccpu 1376389 [rsc] plan9%
"I write for living" is different from "I'm a good writer". As someone skilled in the writing profession you should be able to attest to that by simply reading most of the articles linked to from slashdot -- the quality of the writing there is abhorable (take the recent 'Graphics Algorithms' article for example).
For every Joseph Heller (ok, Bradbury) there are countless unnamed authors that were only as good as to write the innumerable soft-cover space operas.
In technical writing (papers) the barrier to entry is even lower. Especially today, when the research writing tradition in Computer Science (notice the emphasis) has been lost in the flood of papers satisfying the hunger for articles for the ever sprawling cancer of conferences in the past 5-10 years. I have seen reviewers who would gladly reject 'GOTO Considered Harmful' on the basis that there isn't enough performance measurement in the paper.
Anyway, I hope you take pride in your profession -- writing good documentation is just as hard as writing good code.
you have 'multiple' machines, LANL has thousands. you try netbooting a 1024-node cluster and tell me how your nfs and tftp servers fare...
or try doing that in an embedded part of an airplane which needs to guarantee that in the event of an error it will come back to initial 'safe' state in a certain amount of ( 1) seconds (well, sometimes it just keeps rebooting in the 'safe' state but that happens even without linuxbios to help it).
remember, linuxbios solves much more, and general, problems than having a few machines with pxe on them and an NFS server do.
oh, and linuxbios is 4 years old. back then not many motherboards came with pxe.
blah, thanx to my communist bloc education i only knew the US has been to the moon once. i was in for a surprise when i opened a non-government-sanctioned encyclopaedia for the first time...
to each their own...
ps: "lemme tell you the chernobil story -- i heard about it from western european newscasts." communist propaganda only talked about an "insignificant" accident for the first week.
the 500mhz box has no moving parts whatsoever -- it boots from flash and connects to a network attached file server, a part of a cluster of Plan 9 nodes on our university network...
Fanless cases running VIA EPIA chipsets and cpus have been available for some time and are quite useful, especially when running operating systems that allow one to stick a huge monitor in front of them, a keyboard, a 3-button mouse and connect to the massively parralel machines in the quite noisy, but lovely air conditioned, server room.
I can't run Quake on one of these, but then again it's research we're talking about -- if I wanted games I'd buy a PS2.
The only fan I have is, funnily enough, on my video card.
Rural Canada (that covers about 7349832% of the country and 1% of the population) sattelite internet is quite common. Works by you pissing off a phone line for 64kbits upstream and downloading with about 50 to a 100kbytes. No limits on how much you can download.
The latency is a minimum of 500ms, that's the least amount of time you get for the reply to come through the sattelite.
Mind you, having a second phone line installed for your DSL costs $2000CAD here, more up north, so you choose the lesser evil.
No, thanks. I'll stick with Frederik Brooks' "Plan to throw one away, you will anyway".
50 years of wisdom are not to be discarded lightly.
But, then again, perhaps because people have forgotten this rule we've been stuck with the same OS design for the past 30 years -- people keep adding to it without really understanding the problem. On the other hand the new developments are shunned and soon forgotten.
Go ahead, reuse the same code over and over again until it becomes a bloated behemoth which nobody understands, contrary to what are probably the three best rules of software development -- Simplicity, Clarity, Generality.
They should teach kids at school that as soon as they have understood the problem they should rewrite their code to reflect the fact.
Slashdot Mirror
antarctica is a continent covered by ice, 3km of it in some places. not really 'underwater'. same for greenland -- the second biggest ice sheet.
Also, if you will, a link for (instructions) porting to Plan 9.
if you don't want to rewrite your code use this:
APE - The ANSI/POSIX environment...
rewriting your stuff is an eye opener though -- it mostly involves removing code that shouldn't be there in the first place but was forced upon you by unix' legacy crap.
you take the cake... no, really!
"any plans for a distributed Plan 9?"... you rock!
not the first time that's done :)
what could be done with a few leftover laptops: LANL and Plan 9.
what could be done with a few leftover read-projection screens and a nice opengl MPI library rendering on all them simultaneously: the GUT...
how about we go back to basics and read the proper books on computer science? no need for your shmancy-fancy-'voice debugged'-automagically-'quality assured' offerings, thanks.
i'll stick with The Practice of Programming. at the very least i trust the people who wrote it to have a better judgement.
we all want to know how google does it, don't we?
here's what he thinks:
Google knows that 80% of mail messages are text, and we all know that text is highly compressible. That said, they probably only have around 2-300MB of storage allocated for each 1GB account (obviously this will fluctuate up to 1GB depending on the user's mail content). My take on this, is that they have a huge series of RAID arrays at their server farm. Every time an email comes in, it is compressed and stored in that users account on the RAID.
this should be closer to the truth: Venti: a new approach to archival storage
I've seen "non-embarrassingly parralel" tasks and, believe me, compiling a kernel isn't one. Proof: distcc for Plan 9 is implemented in 10 lines of shell code.
:)
BTW, I wasn't suggesting Ken's C compilers for Linux, not at all -- Linux can have gcc (and distcc for that matter), for they deserve each other
Don't get caught offguard by the snide remarks. If you think P9 is elitist then you're quite right -- the compilers were designed and written by Ken Thompson, the gui and editors by Rob Pike, the networking code by Dave Presotto, the group manager was Dennis Ritchie. With such a team you're guaranteed to end up with a well thought-out system, compared to which such puny hacks as distcc seem a waste of time and lack of vision.
Sure, nobody's using it. Everyone tries to emulate it, though. Unsuccessfuly.
nothing but gcc can compile the linux kernel anyway :)
sure you can get sub-minute compile times with 1024 machines at your disposal -- it's an embarrasingly parralel problem. you can even get less than 10-second compile with a 32way pSeries p690. at what cost, though?
I compile my programs once, then use them for MONTHS on end.
And then they spend most of their time waiting for IO.
Only in HPC do you ever look for ultra-optimized code and even then you end up running your code twice (or more) to verify your answer.
Most machines (including yours) are running at load levels way below 1 (unless they aren't dedicating wasted cycles to SETI or somesuch, which itself confirms they have cycles to waste).
Plan 9's compilers may produce 20% slower code, but when a (true) developer sees 10 times decrease in compile time they immediately realize the benefit. Just ask DeRaadt or Viro whether they would prefer a kernel compile in 8, 80 or 800 seconds (and guess which one they get with Plan 9's C compilers).
andrey
s/BL/Lucent/g
if it was up to BL Plan 9 would have been released under a BSD license long ago.
"I write for living" is different from "I'm a good writer". As someone skilled in the writing profession you should be able to attest to that by simply reading most of the articles linked to from slashdot -- the quality of the writing there is abhorable (take the recent 'Graphics Algorithms' article for example).
For every Joseph Heller (ok, Bradbury) there are countless unnamed authors that were only as good as to write the innumerable soft-cover space operas.
In technical writing (papers) the barrier to entry is even lower. Especially today, when the research writing tradition in Computer Science (notice the emphasis) has been lost in the flood of papers satisfying the hunger for articles for the ever sprawling cancer of conferences in the past 5-10 years. I have seen reviewers who would gladly reject 'GOTO Considered Harmful' on the basis that there isn't enough performance measurement in the paper.
Anyway, I hope you take pride in your profession -- writing good documentation is just as hard as writing good code.
simple: those who like Plan 9 like it a lot.
go through my comment history -- it's all there.
you have 'multiple' machines, LANL has thousands. you try netbooting a 1024-node cluster and tell me how your nfs and tftp servers fare...
or try doing that in an embedded part of an airplane which needs to guarantee that in the event of an error it will come back to initial 'safe' state in a certain amount of ( 1) seconds (well, sometimes it just keeps rebooting in the 'safe' state but that happens even without linuxbios to help it).
remember, linuxbios solves much more, and general, problems than having a few machines with pxe on them and an NFS server do.
oh, and linuxbios is 4 years old. back then not many motherboards came with pxe.
plan9% find / -type f -perm -001
find: '/bin/find' file does not exist
plan9%
One word: Amdahl.
just now El Reg published some of the angry letters in defence of .GNU:
.GNU, just presenting a counterpoint.
http://theregister.co.uk/content/35/35557.html
not that i'm trying to defend
blah, thanx to my communist bloc education i only knew the US has been to the moon once. i was in for a surprise when i opened a non-government-sanctioned encyclopaedia for the first time...
to each their own...
ps: "lemme tell you the chernobil story -- i heard about it from western european newscasts." communist propaganda only talked about an "insignificant" accident for the first week.
they tried. it's itanium... ... itanic in some circles.
HAND
the 500mhz box has no moving parts whatsoever -- it boots from flash and connects to a network attached file server, a part of a cluster of Plan 9 nodes on our university network...
See parts of a similar cluster, again with no moving parts.
tomshardware ran benchmarks on the VIA EDEN cpu's up to a gigahertz, the quake 3 performance was miserable.
sorry, no link...
Fanless cases running VIA EPIA chipsets and cpus have been available for some time and are quite useful, especially when running operating systems that allow one to stick a huge monitor in front of them, a keyboard, a 3-button mouse and connect to the massively parralel machines in the quite noisy, but lovely air conditioned, server room.
I can't run Quake on one of these, but then again it's research we're talking about -- if I wanted games I'd buy a PS2.
The only fan I have is, funnily enough, on my video card.
Rural Canada (that covers about 7349832% of the country and 1% of the population) sattelite internet is quite common. Works by you pissing off a phone line for 64kbits upstream and downloading with about 50 to a 100kbytes. No limits on how much you can download.
The latency is a minimum of 500ms, that's the least amount of time you get for the reply to come through the sattelite.
Mind you, having a second phone line installed for your DSL costs $2000CAD here, more up north, so you choose the lesser evil.
No, thanks. I'll stick with Frederik Brooks' "Plan to throw one away, you will anyway".
50 years of wisdom are not to be discarded lightly.
But, then again, perhaps because people have forgotten this rule we've been stuck with the same OS design for the past 30 years -- people keep adding to it without really understanding the problem. On the other hand the new developments are shunned and soon forgotten.
System software research is irrelevant.
Go ahead, reuse the same code over and over again until it becomes a bloated behemoth which nobody understands, contrary to what are probably the three best rules of software development -- Simplicity, Clarity, Generality.
They should teach kids at school that as soon as they have understood the problem they should rewrite their code to reflect the fact.