'm not talking about the piddling little difference between a Marslike atmosphere and an Earthlike atmosphere, I'm talking about the difference between a gas giant atmosphere and a rock planet atmosphere. The point was that a Mercury-distance planet might be a rock planet like Mars is.
*Sigh*. For the nth time - this is because of fractioning of the protoplanetary disk *BEFORE* planets formed!
Just what are you basing that specific distance on? You just pulled it out of your hat, didn't you?
This is the distance at which the relative gravitational influences of the star and the jupiter-sized planet would be comparable to the relative gravitational influences of Jupiter and Sol. Not difficult to estimate.
There's still the little problem of a gas giant in the inner solar system pulling any smaller planets out of their orbits. If you recall, that's the real reason I said there won't be a rocky planet in a stable orbit.
At asteroid-belt distance hardly counts as "in the inner solar system". All that this gas giant does is make the band in which stable orbits can occur a little narrower. Inner planets can most certainly still exist stably.
While I didn't mention it, obviously a weaker star can still blow out the gasses from closer-in planets (a Mercury-distance planet there might get the treatment Mars did here).
Mars is bereft of atmosphere because it its escape velocity is low enough that the atmosphere can boil off - solar influence has nothing to do with it.
The only planet that has had substantial solar influence on its atmosphere is Mercury, because it's *extremely* close to the sun. Even that effect has nothing to do with the sun "blowing away" the atmosphere - on the contrary, it _heats_ the atmosphere so that individual molecules can more readily reach the planet's escape velocity.
With a Jupiter-mass planet at the distance of the asteroid belt, you'd have stable planetary orbits from Earth-distance on in. The star is cooler, so atmospheres will be cooler, and more easily retained unless you're *really* close to the star.
I'm afraid that your arguments about atmospheres being "blown away" just don't make any sense. See above.
We've got rock planets here in the inner solar-system because our manly yellow star blew off most of the atmosphere of the nearest planets.
Actually, according to the literature I went through when writing a project on star systems in high school, the gasses are blown out of the inner solar system _before_ planets start to form.
Blowing the atmosphere off of an already-formed planet won't happen under anything short of very extreme circumstances. Jupiter could be sitting in Venus's orbit and still remain intact. In the primordial disk, however, there's nothing to hold gases in one place, so they can be moved easily.
So, I think that there is a very good chance of finding rocky planets around Epsilon Eridani.
Generally planets are so much smaller than the star they orbit that any affect they have on the stars brightness is very minimal, if any...
What's actually being detected isn't a brightness change - it's a doppler shift in the star's emission lines as it moves towards and away from us due to the influence of the orbiting planet.
You have the right reason for nondetection; it's just a different parameter being measured:).
Does anyone know if this DOS support extends to the int 10 mechanisms for setting up graphics? It would be interesting to be able to easily run my collection DOS games and demos under this.
Well, I don't think it is possible now. But, what if your compiler had enough smarts to divide register level tasks umongst different processors [...]
At _compile_ time, it's possible, though not always practical or beneficial, as I'd already stated.
You were talking about doing it at _run_ time on binaries that weren't designed for multithreading/multiprocessing.
There is a big difference between these cases.
It's not impossible, but it's *very* difficult, and of questionable use in almost all cases (overhead for threading is high, for multiprocessing is higher, and for running on processors separated by substantial latency is prohibitive).
As another poster pointed out, some compilers already do this at build-time, but that's about it. If you want your application to be easily parallelized, then write it to be multithreaded to begin with.
The best you can hope for is that some day compilers will be really smart and parallelize things for you, but even then the effect would be very limited, I'd think.
You can do this fairly easily for certain types of loop. It would be a straightforward extension of loop unrolling. Now, I don't think anyone's been insane enough to _do_ this to date, as the thread creation overhead would eat the speed gain for anything except a very long-running loop.
Something like TransMeta's code morphing that profiles on the fly could in principle figure out where it's sensible to do this, but speed gains would be questionable except in very special cases.
I think it would be even cooler to have something that, given enough bandwidth, would transparently divide up processor time for a single thread/task.
How exactly do you propose that the operating system do this?
Unless the programmer or compiler parallelizes the code, you're out of luck for running it on more than one processor at a time. What is the OS supposed to do? Recompile it on the fly, adding all of the MT-safing, rebuild it, and hope that it's faster?
Unless an application is designed from the start to be parallel, it can't be run as a parallel program.
Having a distributed OS would take a great load off of distributed application developers. Currently, a distributed application has to be able to handle all the tasks that a normal operating system currently does. Not having a distributed operating system for distributed apps is like not having an OS for normal client apps.
Seti@Home has to be able to route all its necessary functions and information around its network. Why is that necessary? A distributed operating system should be able to handle the tasks of distribution for the applications. It's almost as if every distributed app developer has to re-invent the wheel every time he/she wants to create such an app.
You are already running a distributed application whenever you run a threaded application on a SMP box. Writing applications for a distributed operating system is no easier and no harder than this.
You _will_ have some programming overhead no matter what - by nature, a distributed application needs to have multiple pieces running concurrently, and so has to manage synchronization and communication between these parts.
The good news is that everyone already understands multiple processes and threads, so we already have a well-established programming model for it.
Now, in the real world, client/server computing will always tend to have an advantage for wide deployment, as you can run those on heterogenous platforms (a la SETI-at-home). For small deployment... you're looking at either a high-processor-count SMP machine or a cluster, depending on the degree of coupling, and those are already well-understood.
So, I'm a bit puzzled as to what you think needs to be developed. It looks like we have distributed computing already.
It wasn't until someone actually wrote some code that the Great Beast was forced to roll-over and grumble. Corporate entities do not respond to warnings. Corporate entities only respond to crisis. There is no crisis until someone codes the bitch.
A very amusing example of this is buried amidst the Jargon File pages:
No, the clock speed of a chip is a quantative measure. A synchronous chip runs at its quoted speed (unless you overclock it:-)
"Clock speed" means different things on different architectures, as there are *different ways* of clocking a chip.
You can have a single square-wave clock (single-phase). This is a bugger to design logic for, because eliminating race conditions is difficult, but allows you to push your circuits a little harder because you don't have to worry about keeping non-overlapping multi-phase clocks non-overlapping.
You can have two non-overlapping square-wave clocks with a duty cycle lower than 50% each (two-phase clocking). This makes functional units *much* easier to design, but you have to add enough padding between pulses on alternate clocks that clock skew won't cause them to overlap anywhere.
You can have four non-overlapping square-wave clocks with a duty cycle lower than 25% each (four-phase clocking). This is very hairy to design logic for, but if you can pull it off, the resulting logic is a bit more forgiving on timing constraints and can be clocked a bit faster than might otherwise be possible.
Now, this is relevant because the shortest possible pulse _length_ under any clocking scheme is roughly constant, but the number of pulses per full clock cycle is the number of phases. If I can make clock pulses 0.5 nanoseconds long, a single-phase clocked system would be running at 1 GHz, while a two-phase clocking system would be running at 500 MHz, and a four-phase clocking system would be running at 250 MHz - while doing the same amount of work.
So, comparing the clock speeds on two architectures that use different clocking methods islike comparing apples and oranges. It just doesn't work. Compare performance instead.
I wonder how the mac keeps it going? Anyone out there a Mac developer? Is it just an easy port?
I've done minor development under MacOS, Windows, and Linux.
In my experience, the MacOS development environment is just cleaner. APIs "feel" neater, simpler, and more cleanly packaged, and the developer help pages on Apple's site are extremely useful.
Under Windows, the API has a fair bit of bloat and isn't as neat, and digging through the help files is annoying as all heck, because they aren't sanely organized and often skimp on important details.
Under Linux, I'll spend a few days of research to write a few hours' worth of code. There isn't any unified API - there are several competing APIs for window managers, and a patchwork of micro-APIs for other aspects of the system. It's great fun to dig into, but it's not a cakewalk.
Either way they need to get those processors running faster.
My understanding was that the apparent gap in clock speeds was due to Apple using a different clocking scheme than Intel.
Benchmarks would provide a more reliable comparison of performance between the platforms. Unfortunately, Apple hasn't submitted SPECmarks in quite a while.
Now that MacOS X is out, it should be straightforward for a third party to compile the SPECmarks with a compiler optimized for the platform (gcc is almost certainly sub-optimal due to lack of specs).
This would not happen if playing these games honestly was as fun as it is supposed to be.
Not true.
All it takes is one person who considers it more fun to harrass their fellow players than to play the game.
These people will always exist, no matter how good the game is. Look at the slashdot trolls for an example.
Any system that has to deal with a vast number of people will have to protect itself against the small but occasionally very capable minority who will actively try to ruin it for everyone else. This applies to games, public forums, network administration, and many other aspects of life.
So the rest of the industry is playing "catchup" to SGI ?! I don't really think there's a huge market for large-scale multiprocessor machines when equivalents can be built up easily from cheap hardware and fast network infrastructure.
Actually, they can't be.
This is not a cluster - it's a multiprocessing supercomputer designed as a single unit. The internal busses have far, far greater bandwidth than even the expensive networks in a high-end cluster.
It does have competition - the Sun Starfire. But that's about it.
Clusters are definitely useful, and give you by far the best bang-for-the-buck on problems with relatively light communications load, but problems with a heavy communications load are best run on machines with high communications bandwidth, like this one.
If you outlaw something, you don't affect criminals who already have shown that laws won't influence their behavior, but you do have a strong influence on law-abiding citizens
This argument crops up whenever the topic of gun control is raised, and it's valid - in the short term.
Guns don't last forever, especially when they're in the hands of criminals and likely to be lost on a botched crime or during a gang war or when evidence must be dumped.
If the general public doesn't have access to guns, the replacement stream for these missing weapons slows to a trickle, for a _long-term_ benefit.
For an example of what the steady-state situation looks like after gun control, take a look at any country that's already _had_ gun control for a few decades.
Would I fear getting mugged walking through a city park in the dead of night here in Toronto, Canada? Sure.
Would I fear being shot? Nope.
Could one criminal get one gun up here if they really, really wanted to? Probably.
Could a hundred criminals get themselves an arsenal for a gang war? Maybe if they spent enough time at it, but it would be a hell of a lot more work than it would be down in the US.
In conclusion, I feel that the long-term benefits of gun control outweigh the short-term problems.
Will perl 5 source be 100% ok with perl6 or will i have to rewrite code?
The impression I get from the article is "mostly compatible":
So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.
You'll probably be ok, but no promises, assuming they don't change their minds during the next year or so (remember, they're just _entering_ the planning stage now).
Honest question: For what niches is this technology useful?
I can maybe see controlling a speaker-phone or a TV with this, but button-based interfaces are pretty efficient for this as it is. I can maybe see using this for quick shortcuts on a computer, but again, current interfaces are pretty efficient.
For massive data entry or for extended interactive editing, this probably isn't practical (try giving a multi-hour lecture - not too comfortable, is it?).
So, I'm wondering where a verbal interface _is_ practical.
Simply monitoring a T1 with a packetsniffer doing decent filtering can easily trash a fast 30GB HDD.
A T1 is 1.5 megabits/sec. To fill up 30 gigabytes recording _all_ data sent across the T1 (no filtering) would take about 44 hours. If a cracker leaves a sniffer unattended for that long, I have little sympathy for them.
Overflowing a user account I can believe, but I would be amazed if drive overflow was a significant problem for the vast majority of packet-sniffing crackers. Heck, cut out HTTP and take only the first few packets of an FTP or POP session's data and you've reduced your data load by a factor of 100 or more, while keeping the information you're interested in (passwords).
In summary, I don't think that drive space is a problem for a half-way competent sniffer.
Tom's Hardware did a moderately detailed benchmark of SDRAM vs. RDRAM a while back.
Which is better? It depends on both the montherboard configuration and on what you're doing.
Intel's high-end RDRAM motherboard beat the hell out of SDRAM systems. It had two interleaved RIMM slots, doubling effective bandwidth.
Intel's more recent SDRAM offerings have generally been pretty bad. Via chipsets put out a good effort, but were still beaten out by the high-end RDRAM systems and the BX board.
The best SDRAM offering was a 440 BX board overclocked to 133 FSB. Tom swears it's stable. YMMV.
As far as load is concerned, RDRAM is optimized for throughput, SDRAM is optimized for latency. Something that hits many cache rows in more or less random order taking only a little data from each will work well with SDRAM. Something that processes large amounts of data in more or less linear order will work well with RDRAM. It depends on what you're doing.
My personal opinion? RDRAM is a bad implementation of a good idea. In five years we might see something better. For now, by DDR SDRAM. YMMV.
Eh? What is the practical use of this? I'm not disagreeing with the concept, which obviously works, but surely this is just another one of NASA's research projects that never go anywhere. They've got ion drives now, so why are they bothering with this?
They are trying this because a) sailcraft in principle can have a greater delta-v potental than just about any other thrust mechanism, including ion drives, and because b) once the technology matures, sailcraft will be dirt cheap.
Point a) holds because of the limited power generation capability of any probe. A sail has a *huge* collection area and directly converts any incoming beamed power to thrust. While thrust per unit power is low, your sail is big enough to handle a lot of light, and your ground-based laser won't run out of fuel. Leave it on for a few months, and your sail-and-probe-package ship will be moving faster than any probe based on chemical or photovoltaic power, and will be far lighter than any fusion-powered craft (which can't even be built yet).
Hold the laser on for a few years instead of a few months, and you can bring the probe up to sufficient speed to reach another star in our lifetimes. The only thing that can possibly match that is a Bussard ramjet, which is even harder to build than an ordinary fusion ship (we'll manage it eventually, but why not start sending probes now?).
Point b) holds because the sail is very light and is made of a common substance (carbon fiber). It's expensive to manufacture now, but this will improve as engineering techniques get better.
As this is the most promising current technology for interstellar probes, I would most certainly argue that it's worth spending money on.
I'm guessing that to launch a craft of any reasonale size you would probably need a huge solar sail. Now i've got no evidence whatsoever to back this up but personally i'd imagine huge football pitch sized things.
Actually, most proposals I've heard were for sails many square kilometres (or more) in area.
Thrust from a reflective sail should be on the order of 1 newton per 1.5e8 watts for a perfectly reflective (1 newton per 3.0e8 watts for a perfectly absorbing sail or for a perfect photon drive).
At earth's distance from the sun, the sun provides about 1.0e3 watts per square metre (_roughly_; I don't have the exact value).
This means that to accelerate a 100kg mini-probe at 1 cm/sec/sec (suitable for in-system movement, not launch), using the sun's light, you'd need a circular sail about half a kilometre in diameter.
For heavier probes or probes that still need to accelerate when farther from the sun (interstellar probes) or for probes that need to accelerate more quickly or for probes with sails that are partly transparent, you'll need a bigger sail.
With all the crap floating about in space surely the chance that these would rupture is unacceptably high, given the ery thing material they are made from.
The best way to design these sails is to give them a film-on-mesh structure so that they'll still hold together with holes in them. Matter in interplanetary space is very sparse; they'd last a while. The main junk hazard would be in low Earth orbit, which isn't where your craft would be deployed.
On an inter_stellar_ trip, OTOH, your sail would probably degrade, but an interplanetary trip could probably be managed.
I'd understood that a more practical way of getting helium 3 for the fusion reactor was to put a "lithium blanket" on the reactor's inner surface. Neutrons emitted from the fusion reactons breed He3 (among other things) from the blanket.
(p+d -> 3He + gamma): aw bugger, the energy runs away as light. (p+t -> 4He + gamma) bugger again.
A couple of points here - First of all, if the many metres of shielding around your reactor absorb a substantial fraction of these gamma rays (and they'd better for the sake of the technicians), you can just run a heat engine off of it the way you do with a fission reactor.
Secondly, even if gamma rays aren't reclaimed and a lot of your energy escapes, this still looks a lot more mass-efficient than chemical energy sources - and we have a near-limitless supply of hydrogen and deuterium.
(d+d -> 3He+n or p+t) nice idea, but notice that neutron... (d+t -> 4He + n) this is an easy to produce reaction, but notice the neutron again. (t+t -> 4He +n+n) argh, two neutrons now.
And the problem with this is?
This would make fusion reactors as impractical as energy sources as fission reactors are now - which is to say, perfectly usable if you put in the required safety effort. And again, with a fuel supply that will last forever.
In principle, you could also run forever (or at least thousands of years) with breeder fission reactors taking in thorium and with reprocessing of spent fuel rods, but even "dirty" fusion is far preferable from a waste standpoint (only low-level waste produced, and no need to chemically reprocess it).
Still don't want a "dirty" fusion reactor on earth? Put it in high orbit (above geosynch). The fuel doesn't weight much, so refueling isn't much of a problem, and tidal drag will actually move it _farther_ away from earth as time passes. But I digress.
In summary, while fusion is unlikely to be a perfect energy souce, it is still quite usable IMO.
Slashdot Mirror
'm not talking about the piddling little difference between a Marslike atmosphere and an Earthlike atmosphere, I'm talking about the difference between a gas giant atmosphere and a rock planet atmosphere. The point was that a Mercury-distance planet might be a rock planet like Mars is.
*Sigh*. For the nth time - this is because of fractioning of the protoplanetary disk *BEFORE* planets formed!
Just what are you basing that specific distance on? You just pulled it out of your hat, didn't you?
This is the distance at which the relative gravitational influences of the star and the jupiter-sized planet would be comparable to the relative gravitational influences of Jupiter and Sol. Not difficult to estimate.
There's still the little problem of a gas giant in the inner solar system pulling any smaller planets out of their orbits. If you recall, that's the real reason I said there won't be a rocky planet in a stable orbit.
At asteroid-belt distance hardly counts as "in the inner solar system". All that this gas giant does is make the band in which stable orbits can occur a little narrower. Inner planets can most certainly still exist stably.
While I didn't mention it, obviously a weaker star can still blow out the gasses from closer-in planets (a Mercury-distance planet there might get the treatment Mars did here).
Mars is bereft of atmosphere because it its escape velocity is low enough that the atmosphere can boil off - solar influence has nothing to do with it.
The only planet that has had substantial solar influence on its atmosphere is Mercury, because it's *extremely* close to the sun. Even that effect has nothing to do with the sun "blowing away" the atmosphere - on the contrary, it _heats_ the atmosphere so that individual molecules can more readily reach the planet's escape velocity.
With a Jupiter-mass planet at the distance of the asteroid belt, you'd have stable planetary orbits from Earth-distance on in. The star is cooler, so atmospheres will be cooler, and more easily retained unless you're *really* close to the star.
I'm afraid that your arguments about atmospheres being "blown away" just don't make any sense. See above.
We've got rock planets here in the inner solar-system because our manly yellow star blew off most of the atmosphere of the nearest planets.
Actually, according to the literature I went through when writing a project on star systems in high school, the gasses are blown out of the inner solar system _before_ planets start to form.
Blowing the atmosphere off of an already-formed planet won't happen under anything short of very extreme circumstances. Jupiter could be sitting in Venus's orbit and still remain intact. In the primordial disk, however, there's nothing to hold gases in one place, so they can be moved easily.
So, I think that there is a very good chance of finding rocky planets around Epsilon Eridani.
Generally planets are so much smaller than the star they orbit that any affect they have on the stars brightness is very minimal, if any...
:).
What's actually being detected isn't a brightness change - it's a doppler shift in the star's emission lines as it moves towards and away from us due to the influence of the orbiting planet.
You have the right reason for nondetection; it's just a different parameter being measured
Does anyone know if this DOS support extends to the int 10 mechanisms for setting up graphics? It would be interesting to be able to easily run my collection DOS games and demos under this.
Well, I don't think it is possible now. But, what if your compiler had enough smarts to divide register level tasks umongst different processors [...]
At _compile_ time, it's possible, though not always practical or beneficial, as I'd already stated.
You were talking about doing it at _run_ time on binaries that weren't designed for multithreading/multiprocessing.
There is a big difference between these cases.
It's not impossible, but it's *very* difficult, and of questionable use in almost all cases (overhead for threading is high, for multiprocessing is higher, and for running on processors separated by substantial latency is prohibitive).
As another poster pointed out, some compilers already do this at build-time, but that's about it. If you want your application to be easily parallelized, then write it to be multithreaded to begin with.
The best you can hope for is that some day compilers will be really smart and parallelize things for you, but even then the effect would be very limited, I'd think.
You can do this fairly easily for certain types of loop. It would be a straightforward extension of loop unrolling. Now, I don't think anyone's been insane enough to _do_ this to date, as the thread creation overhead would eat the speed gain for anything except a very long-running loop.
Something like TransMeta's code morphing that profiles on the fly could in principle figure out where it's sensible to do this, but speed gains would be questionable except in very special cases.
I think it would be even cooler to have something that, given enough bandwidth, would transparently divide up processor time for a single thread/task.
How exactly do you propose that the operating system do this?
Unless the programmer or compiler parallelizes the code, you're out of luck for running it on more than one processor at a time. What is the OS supposed to do? Recompile it on the fly, adding all of the MT-safing, rebuild it, and hope that it's faster?
Unless an application is designed from the start to be parallel, it can't be run as a parallel program.
Having a distributed OS would take a great load off of distributed application developers. Currently, a distributed application has to be able to handle all the tasks that a normal operating system currently does. Not having a distributed operating system for distributed apps is like not having an OS for normal client apps.
Seti@Home has to be able to route all its necessary functions and information around its network. Why is that necessary? A distributed operating system should be able to handle the tasks of distribution for the applications. It's almost as if every distributed app developer has to re-invent the wheel every time he/she wants to create such an app.
You are already running a distributed application whenever you run a threaded application on a SMP box. Writing applications for a distributed operating system is no easier and no harder than this.
You _will_ have some programming overhead no matter what - by nature, a distributed application needs to have multiple pieces running concurrently, and so has to manage synchronization and communication between these parts.
The good news is that everyone already understands multiple processes and threads, so we already have a well-established programming model for it.
Now, in the real world, client/server computing will always tend to have an advantage for wide deployment, as you can run those on heterogenous platforms (a la SETI-at-home). For small deployment... you're looking at either a high-processor-count SMP machine or a cluster, depending on the degree of coupling, and those are already well-understood.
So, I'm a bit puzzled as to what you think needs to be developed. It looks like we have distributed computing already.
It wasn't until someone actually wrote some code that the Great Beast was forced to roll-over and grumble. Corporate entities do not respond to warnings. Corporate entities only respond to crisis. There is no crisis until someone codes the bitch.
g -of-Hack.html
A very amusing example of this is buried amidst the Jargon File pages:
http://www.tuxedo.org/~esr/jargon/html/The-Meanin
Regrettably, "killall" would probably stop this hack in its tracks now, but it's still very amusing reading.
No, the clock speed of a chip is a quantative measure. A synchronous chip runs at its quoted speed (unless you overclock it :-)
"Clock speed" means different things on different architectures, as there are *different ways* of clocking a chip.
You can have a single square-wave clock (single-phase). This is a bugger to design logic for, because eliminating race conditions is difficult, but allows you to push your circuits a little harder because you don't have to worry about keeping non-overlapping multi-phase clocks non-overlapping.
You can have two non-overlapping square-wave clocks with a duty cycle lower than 50% each (two-phase clocking). This makes functional units *much* easier to design, but you have to add enough padding between pulses on alternate clocks that clock skew won't cause them to overlap anywhere.
You can have four non-overlapping square-wave clocks with a duty cycle lower than 25% each (four-phase clocking). This is very hairy to design logic for, but if you can pull it off, the resulting logic is a bit more forgiving on timing constraints and can be clocked a bit faster than might otherwise be possible.
Now, this is relevant because the shortest possible pulse _length_ under any clocking scheme is roughly constant, but the number of pulses per full clock cycle is the number of phases. If I can make clock pulses 0.5 nanoseconds long, a single-phase clocked system would be running at 1 GHz, while a two-phase clocking system would be running at 500 MHz, and a four-phase clocking system would be running at 250 MHz - while doing the same amount of work.
So, comparing the clock speeds on two architectures that use different clocking methods islike comparing apples and oranges. It just doesn't work. Compare performance instead.
I wonder how the mac keeps it going? Anyone out there a Mac developer? Is it just an easy port?
I've done minor development under MacOS, Windows, and Linux.
In my experience, the MacOS development environment is just cleaner. APIs "feel" neater, simpler, and more cleanly packaged, and the developer help pages on Apple's site are extremely useful.
Under Windows, the API has a fair bit of bloat and isn't as neat, and digging through the help files is annoying as all heck, because they aren't sanely organized and often skimp on important details.
Under Linux, I'll spend a few days of research to write a few hours' worth of code. There isn't any unified API - there are several competing APIs for window managers, and a patchwork of micro-APIs for other aspects of the system. It's great fun to dig into, but it's not a cakewalk.
Just my personal experiences and opinions.
Either way they need to get those processors running faster.
My understanding was that the apparent gap in clock speeds was due to Apple using a different clocking scheme than Intel.
Benchmarks would provide a more reliable comparison of performance between the platforms. Unfortunately, Apple hasn't submitted SPECmarks in quite a while.
Now that MacOS X is out, it should be straightforward for a third party to compile the SPECmarks with a compiler optimized for the platform (gcc is almost certainly sub-optimal due to lack of specs).
This would not happen if playing these games honestly was as fun as it is supposed to be.
Not true.
All it takes is one person who considers it more fun to harrass their fellow players than to play the game.
These people will always exist, no matter how good the game is. Look at the slashdot trolls for an example.
Any system that has to deal with a vast number of people will have to protect itself against the small but occasionally very capable minority who will actively try to ruin it for everyone else. This applies to games, public forums, network administration, and many other aspects of life.
So the rest of the industry is playing "catchup" to SGI ?! I don't really think there's a huge market for large-scale multiprocessor machines when equivalents can be built up easily from cheap hardware and fast network infrastructure.
Actually, they can't be.
This is not a cluster - it's a multiprocessing supercomputer designed as a single unit. The internal busses have far, far greater bandwidth than even the expensive networks in a high-end cluster.
It does have competition - the Sun Starfire. But that's about it.
Clusters are definitely useful, and give you by far the best bang-for-the-buck on problems with relatively light communications load, but problems with a heavy communications load are best run on machines with high communications bandwidth, like this one.
If you outlaw something, you don't affect criminals who already have shown that laws won't influence their behavior, but you do have a strong influence on law-abiding citizens
This argument crops up whenever the topic of gun control is raised, and it's valid - in the short term.
Guns don't last forever, especially when they're in the hands of criminals and likely to be lost on a botched crime or during a gang war or when evidence must be dumped.
If the general public doesn't have access to guns, the replacement stream for these missing weapons slows to a trickle, for a _long-term_ benefit.
For an example of what the steady-state situation looks like after gun control, take a look at any country that's already _had_ gun control for a few decades.
Would I fear getting mugged walking through a city park in the dead of night here in Toronto, Canada? Sure.
Would I fear being shot? Nope.
Could one criminal get one gun up here if they really, really wanted to? Probably.
Could a hundred criminals get themselves an arsenal for a gang war? Maybe if they spent enough time at it, but it would be a hell of a lot more work than it would be down in the US.
In conclusion, I feel that the long-term benefits of gun control outweigh the short-term problems.
Will perl 5 source be 100% ok with perl6 or will i have to rewrite code?
The impression I get from the article is "mostly compatible":
So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.
You'll probably be ok, but no promises, assuming they don't change their minds during the next year or so (remember, they're just _entering_ the planning stage now).
A few additional titles that are quite fun:
Humour:
Irresponsible Captain Tyler
The City Hunter series
Dragon Half
More serious:
The "Patlabor" series
Honest question: For what niches is this technology useful?
I can maybe see controlling a speaker-phone or a TV with this, but button-based interfaces are pretty efficient for this as it is. I can maybe see using this for quick shortcuts on a computer, but again, current interfaces are pretty efficient.
For massive data entry or for extended interactive editing, this probably isn't practical (try giving a multi-hour lecture - not too comfortable, is it?).
So, I'm wondering where a verbal interface _is_ practical.
Simply monitoring a T1 with a packetsniffer doing decent filtering can easily trash a fast 30GB HDD.
A T1 is 1.5 megabits/sec. To fill up 30 gigabytes recording _all_ data sent across the T1 (no filtering) would take about 44 hours. If a cracker leaves a sniffer unattended for that long, I have little sympathy for them.
Overflowing a user account I can believe, but I would be amazed if drive overflow was a significant problem for the vast majority of packet-sniffing crackers. Heck, cut out HTTP and take only the first few packets of an FTP or POP session's data and you've reduced your data load by a factor of 100 or more, while keeping the information you're interested in (passwords).
In summary, I don't think that drive space is a problem for a half-way competent sniffer.
Tom's Hardware did a moderately detailed benchmark of SDRAM vs. RDRAM a while back.
Which is better? It depends on both the montherboard configuration and on what you're doing.
Intel's high-end RDRAM motherboard beat the hell out of SDRAM systems. It had two interleaved RIMM slots, doubling effective bandwidth.
Intel's more recent SDRAM offerings have generally been pretty bad. Via chipsets put out a good effort, but were still beaten out by the high-end RDRAM systems and the BX board.
The best SDRAM offering was a 440 BX board overclocked to 133 FSB. Tom swears it's stable. YMMV.
As far as load is concerned, RDRAM is optimized for throughput, SDRAM is optimized for latency. Something that hits many cache rows in more or less random order taking only a little data from each will work well with SDRAM. Something that processes large amounts of data in more or less linear order will work well with RDRAM. It depends on what you're doing.
My personal opinion? RDRAM is a bad implementation of a good idea. In five years we might see something better. For now, by DDR SDRAM. YMMV.
Eh? What is the practical use of this? I'm not disagreeing with the concept, which obviously works, but surely this is just another one of NASA's research projects that never go anywhere. They've got ion drives now, so why are they bothering with this?
They are trying this because a) sailcraft in principle can have a greater delta-v potental than just about any other thrust mechanism, including ion drives, and because b) once the technology matures, sailcraft will be dirt cheap.
Point a) holds because of the limited power generation capability of any probe. A sail has a *huge* collection area and directly converts any incoming beamed power to thrust. While thrust per unit power is low, your sail is big enough to handle a lot of light, and your ground-based laser won't run out of fuel. Leave it on for a few months, and your sail-and-probe-package ship will be moving faster than any probe based on chemical or photovoltaic power, and will be far lighter than any fusion-powered craft (which can't even be built yet).
Hold the laser on for a few years instead of a few months, and you can bring the probe up to sufficient speed to reach another star in our lifetimes. The only thing that can possibly match that is a Bussard ramjet, which is even harder to build than an ordinary fusion ship (we'll manage it eventually, but why not start sending probes now?).
Point b) holds because the sail is very light and is made of a common substance (carbon fiber). It's expensive to manufacture now, but this will improve as engineering techniques get better.
As this is the most promising current technology for interstellar probes, I would most certainly argue that it's worth spending money on.
I'm guessing that to launch a craft of any reasonale size you would probably need a huge solar sail. Now i've got no evidence whatsoever to back this up but personally i'd imagine huge football pitch sized things.
Actually, most proposals I've heard were for sails many square kilometres (or more) in area.
Thrust from a reflective sail should be on the order of 1 newton per 1.5e8 watts for a perfectly reflective (1 newton per 3.0e8 watts for a perfectly absorbing sail or for a perfect photon drive).
At earth's distance from the sun, the sun provides about 1.0e3 watts per square metre (_roughly_; I don't have the exact value).
This means that to accelerate a 100kg mini-probe at 1 cm/sec/sec (suitable for in-system movement, not launch), using the sun's light, you'd need a circular sail about half a kilometre in diameter.
For heavier probes or probes that still need to accelerate when farther from the sun (interstellar probes) or for probes that need to accelerate more quickly or for probes with sails that are partly transparent, you'll need a bigger sail.
With all the crap floating about in space surely the chance that these would rupture is unacceptably high, given the ery thing material they are made from.
The best way to design these sails is to give them a film-on-mesh structure so that they'll still hold together with holes in them. Matter in interplanetary space is very sparse; they'd last a while. The main junk hazard would be in low Earth orbit, which isn't where your craft would be deployed.
On an inter_stellar_ trip, OTOH, your sail would probably degrade, but an interplanetary trip could probably be managed.
I'd understood that a more practical way of getting helium 3 for the fusion reactor was to put a "lithium blanket" on the reactor's inner surface. Neutrons emitted from the fusion reactons breed He3 (among other things) from the blanket.
(p+d -> 3He + gamma): aw bugger, the energy runs away as light. (p+t -> 4He + gamma) bugger again.
A couple of points here - First of all, if the many metres of shielding around your reactor absorb a substantial fraction of these gamma rays (and they'd better for the sake of the technicians), you can just run a heat engine off of it the way you do with a fission reactor.
Secondly, even if gamma rays aren't reclaimed and a lot of your energy escapes, this still looks a lot more mass-efficient than chemical energy sources - and we have a near-limitless supply of hydrogen and deuterium.
(d+d -> 3He+n or p+t) nice idea, but notice that neutron... (d+t -> 4He + n) this is an easy to produce reaction, but notice the neutron again. (t+t -> 4He +n+n) argh, two neutrons now.
And the problem with this is?
This would make fusion reactors as impractical as energy sources as fission reactors are now - which is to say, perfectly usable if you put in the required safety effort. And again, with a fuel supply that will last forever.
In principle, you could also run forever (or at least thousands of years) with breeder fission reactors taking in thorium and with reprocessing of spent fuel rods, but even "dirty" fusion is far preferable from a waste standpoint (only low-level waste produced, and no need to chemically reprocess it).
Still don't want a "dirty" fusion reactor on earth? Put it in high orbit (above geosynch). The fuel doesn't weight much, so refueling isn't much of a problem, and tidal drag will actually move it _farther_ away from earth as time passes. But I digress.
In summary, while fusion is unlikely to be a perfect energy souce, it is still quite usable IMO.