Lots of cluster customers buy preconfigured clusters from someone like MicroWay. Even if an organization has the skills internally to build it, their personnel might be busy running the existing systems and networks rather than building new capacity. There certainly are places where the staff builds the cluster on site, but it's not everywhere that a cluster could be useful.
Sine Nomine isn't a terrible consulting company, either.
I worked for a company that used their services to help us design and implement a fairly major project. They had one guy come to us onsite and another guy help him out with the planning. Their solution wasn't the flashiest. It wasn't the newest tech. It probably wasn't the absolute fastest, and certainly wasn't the most vertically scalable. It scaled really well horizontally, though, and was really reliable.
Despite a higher hourly rate and higher travel expenses than some, their quote was on the low side over all. They knew enough to get the job done in a reasonable manner in a short period of time.
Based on my past experience with them, I'd probably trust them for support on any fork they released. It's always nice when the code goes back to the core project and others are willing to support it, too. Sine Nomine is probably a good choice if you can afford them, though, since they did the work on the port.
It doesn't matter what source you use. Both major-party candidates are the type of people who want votes from the half-brained TV watchers. The candidates would rather be elected and reelected by those people than to see the state of discourse improved. So long as that's the case, the candidates are part of the problem.
Just because something hasn't happened yet doesn't mean it can't be made to work. In the 50's and 60's there were lots of crazy ideas like flying cars and protecting yourself from a nuclear weapon by hiding under your desk.
No kind of science gets done without the funds to do research and experimentation. Just because something's not immediately feasible doesn't mean it can't be investigated for application a decade or two in the future.
If you want something that's going to replace petroleum tomorrow, then I suggest you get used to walking quite a bit. If you want something that might replace it in thirty years, then why tie the hands of people trying to make that happen?
So let's just forget about the future and keep burning petrol. The future will never come.
In case you didn't read the HTE links there, most of them believe they can make it work with less exotic tech than hot fusion. Hot fusion would pretty much guarantee it would work, but is probably not necessary.
Again, the total input is less than the total output, so there's no claim of violating the 2nd law which you keep saying I'm proposing. If hydrogen is the fuel of choice, then producing it will cost some energy. If batteries or ultracapacitors work better sooner, then there'll be no reason for hydrogen auto fuel.
Yay, we finally got to the personal attack and the accusation of a drug-induced altered mental state!
Now, if you've never read anything about tokamak reactors or the NIF (or other intertial confinement research), I suggest you do so.
Severaldifferent researchprojects are working toward using HTE of water or HTE of water + CO2 (to produce methane gas), so it's not exactly pixie dust.
Any form of invisible link, invisible button, link or button in an iframe, getURL() call in Flash, or JavaScript handler for any normally non-clickable item that makes you go somewhere, yeah.
This could be useful for flooded areas, too. Along the Mississippi, Ohio, Illinois, and Missouri rivers, high flooding often means the rivers cover the water treatment and maybe the sewage treatment plants. So some cities go days or weeks without clean tap water during floods like 1993, 1997, and 2008. A few of these things per neighborhood would be a good emergency management step.
You assume I'm talking about an existing rod fission reactor. I am talking about high-temperature fusion reactors. Take a look at the Sun. High temperatures are guaranteed from high-temperature hydrogen fusion. Hence the name.
The heating of some water to steam, even 850 degree steam, wouldn't impact the heat of a 10**9 kelvins very damn much. Getting the water close enough to take advantage of the heat might be an issue. There are significant barriers to the high-temperature fusion plants themselves, too, but there is progress in that area.
Batteries might be a better carrier someday than hydrogen or hydrocarbons. Lithium-ion is probably not the technology to do that. Zinc-silver might be if ZPower actually solved the dendrite issue with them. Ultracapacitors would be nice, too.
Coal, oil, and natural gas are inherently lossy, too, or did you think we're currently producing new dinosaurs and forests and fossilizing them faster than they're being used?
Using anything as an "energy carrier" doesn't mean you're violating the second law of thermodynamics. As far as anyone knows, there's no way at all to ever do so. The whole idea of an energy carrier, even one like gasoline or diesel, is that it produces more energy on site than it takes to deliver it. It does not produce more energy at its final destination than what it took to produce in the first place.
I said "closer to the green", and I was assuming they hit the nitrous a bit too early as most of those ricer hooligans do. Most of their clutches are sloppy anyway from all the wheel spinning, as if it's impressive to spin wheels three revolutions from a dead stop on damp pavement. Suspension and tires are for old farts, after all.
Of course, if the new hot drag strips are 100 meters rather than a quarter mile, then all bets are off. BTW, whatever happened to the one-mile drag?
Oh, and you kids get your leafblowers -- I mean "cars" off my lawn!;-)
Well, if speed is that much of a factor then you want your memory fabbed at a smaller node anyway, right?
The RAS recharge and data cell recharge in modern RAM is handled by the memory module anyway. The CPU just tells the module when to do it. So the module should be able to separate that from the read/write voltage on the data and address lines if it's dealing with two very different voltage ranges. The right solution, though, is to put the RAM through a die shrink.
The higher voltage is used almost entirely to shorten the RAS recharge time, IIRC. The data line voltage usually shouldn't need to be the same as the refresh voltage. If your memory really requires 2 volts these days to send data to and from the processor, then you need a process shrink.
Memory can only be read or written at the proper edges of the clock frequency, so allow a write then refresh before the next possible read. The higher refresh voltage takes care of refreshing quickly and accounts for the voltage leak. The lower data line voltage to the processor means no damage.
This all depends on something other than the on-CPU memory controller providing the higher voltage for the refresh rewrite only, under the control of the memory controller.
In a CAS-before-RAS memory implementation, the memory controller sends CAS then RAS and the memory module refreshes itself. There's no reason the actual refresh voltage would need to flow through the memory controller. If there's no separation of the RAS recharge voltage from the external data lines, then that's a limitation of the module design. The modules would, again, be in need of a process shrink so they don't need so much voltage or a design change so that the higher voltage for internal module requirements don't flow out to other components.
The main power issue with RAM is the refresh pulse being high enough voltage so that it happens so frequently with enough reliability. There's not much reason with the nature of DRAM that the read and write voltages need to be as high as the refresh voltage.
You could accomplish this, if the memory can be read and written with a lower voltage than the refresh pulse, by putting resistors inline on the bus.
Why in the world would electrolyzing part of the steam remove the capability of the plant's main purpose of generating electricity? High-temperature electrolysis is a byproduct, not a primary goal for those types of plants that could produce hydrogen that way.
Unix and Windows are different mindsets as much as different technologies. Perl fits the Unix mindset very well. That said, although I am both a Perl programmer and a Unix user, I'd rather have Perl on my Windows machine than mess with VB, ASP, or C#.
I do, in fact, have Perl on Windows. I have ActiveState's packages for Perl 5.8 and 5.10, Strawberry Perl for 5.8 and 5.10, and Cygwin with its perl 5.8 as well.
PowerShell is a nice system, and I'm starting to learn it because it's really powerful on a Windows system. However, why should I write something in PowerShell and Perl when I can write it once and run it on Windows, Linux, BSD, and OS X?
If I was writing Windows-specific code that would never be ported, PowerShell is probably the way to go for quick-and-dirty code. C# would be the way to get Windows-specific code that kinda sorta works on Linux with Mono for more serious projects. However, writing to Perl (or Python or a few other languages) means I can take the code with me from one platform to another with minimal hassle.
Experienced programmers who write for maintainability write maintainable code. Experienced programmers who write whatever the hell they want or whatever clever bullshit comes to mind have the wrong kind of experience.
Look up "Moose". It's a module for objects in Perl 5 that pretty closely match the default implementation of objects in Perl 6.
Larry has promised that Perl 6 will still have most of the flexibility of Perl 5, but the design is going to include good defaults throughout the language rather than forcing you to always roll your own.
If you have a real hard-on for OOP, then you will probably love Perl 6 some day when it's out. Even the parser is just polymorphic methods, and therefore you can extend it and override parts of it at will. There's even enough thought behind the mutability and overriding of the parser that there are no reserved words and no numeric precedence levels. If you want a certain level of precedence, you say which operator you want the same precedence as, or that you want higher or lower precedence than operator X. You can whole new precedence level in between multiplication and addition, if you really need it, and all in one statement.
Well, Microsoft has been one of the big fund sources for ActiveState's ActivePerl package.
One thing you must realize about Perl before you go and stick it on the CLR is that Perl is severely dynamic at several levels. The CLR is a stack-based virtual machine for languages that are slightly dynamic. It really isn't a very good fit. Perl 5's parsing rules also happen to be very complex.
That's why Parrot was invented -- it's a register machine VM with automatic spilling and designed from the ground up to work well with highly dynamic languages. It's also designed to allow multiple languages to be compiled down to byte code for it. The main language in question is Perl 6. Perl 5, Ruby, Python, and PHP interpreters are also being written for it among others.
There have been many minor to major improvements in Perl 5 since 8 years ago. Among them are a mostly iterative regular expression engine, better threading, a native case statement (called given) and a new popular object system (as a module) that most people who try it like more than the original stock Perl 5 objects. Most of the serious heavy lifting in Perl implementation is being done on Perl 6, though. Rakudo (the implementation of Perl 6 on Parrot) is progressing and Parrot itself is stable enough that people are starting to write directly to it for production use.
If the people who develop perl think that Perl needs a different kind of VM to run its best and they've spent eight years on the language and VM, then why disregard all that now that completion of that work is within sight? Why shoehorn Perl 5 into an environment where it won't fit when there are viable systems for running it and it's about to be largely superseded?
Perl hasn't gone anywhere. It's just that newer shops tend to start with the buzzword languages of the time. In the 1980's there were thousands of Lisp shops developing software. Now many of them are gone, but plenty of people still use Lisp even for new projects.
In the 1990's there were lots of start-ups using Perl, and now many of them are gone. There are still plenty of people using Perl, even for new projects.
In ten years, there will probably be a new king of the hill, like Erlang some kind of implicitly concurrent extension to Ruby. Yet Python will not magically die out over night any more than Perl or Lisp.
The places most qualified to answer specific questions are probably comp.lang.perl.moderated (or maybe comp.lang.perl.misc) and Perlmonks. I don't know too much first-hand about PerlGuru, but they do have a section specific to Win32 programming with Perl and I've heard some good things.
Slashdot Mirror
Lots of cluster customers buy preconfigured clusters from someone like MicroWay. Even if an organization has the skills internally to build it, their personnel might be busy running the existing systems and networks rather than building new capacity. There certainly are places where the staff builds the cluster on site, but it's not everywhere that a cluster could be useful.
Yeah, lots of systems support 64 Gb of RAM per system. You can get PC motherboards that do that for under $100 on Newegg. I'm betting they mean GB.
Or a regular computer and two motor scooters.
Where the hell did you find a Pentium 33Mhz?
Sine Nomine isn't a terrible consulting company, either.
I worked for a company that used their services to help us design and implement a fairly major project. They had one guy come to us onsite and another guy help him out with the planning. Their solution wasn't the flashiest. It wasn't the newest tech. It probably wasn't the absolute fastest, and certainly wasn't the most vertically scalable. It scaled really well horizontally, though, and was really reliable.
Despite a higher hourly rate and higher travel expenses than some, their quote was on the low side over all. They knew enough to get the job done in a reasonable manner in a short period of time.
Based on my past experience with them, I'd probably trust them for support on any fork they released. It's always nice when the code goes back to the core project and others are willing to support it, too. Sine Nomine is probably a good choice if you can afford them, though, since they did the work on the port.
It doesn't matter what source you use. Both major-party candidates are the type of people who want votes from the half-brained TV watchers. The candidates would rather be elected and reelected by those people than to see the state of discourse improved. So long as that's the case, the candidates are part of the problem.
Just because something hasn't happened yet doesn't mean it can't be made to work. In the 50's and 60's there were lots of crazy ideas like flying cars and protecting yourself from a nuclear weapon by hiding under your desk.
No kind of science gets done without the funds to do research and experimentation. Just because something's not immediately feasible doesn't mean it can't be investigated for application a decade or two in the future.
If you want something that's going to replace petroleum tomorrow, then I suggest you get used to walking quite a bit. If you want something that might replace it in thirty years, then why tie the hands of people trying to make that happen?
Who the hell uses 5.25" hard drives these days? If you use a Quantum Bigfoot, you deserve every kind of data loss and corruption you get.
So let's just forget about the future and keep burning petrol. The future will never come.
In case you didn't read the HTE links there, most of them believe they can make it work with less exotic tech than hot fusion. Hot fusion would pretty much guarantee it would work, but is probably not necessary.
Again, the total input is less than the total output, so there's no claim of violating the 2nd law which you keep saying I'm proposing. If hydrogen is the fuel of choice, then producing it will cost some energy. If batteries or ultracapacitors work better sooner, then there'll be no reason for hydrogen auto fuel.
Yay, we finally got to the personal attack and the accusation of a drug-induced altered mental state!
Now, if you've never read anything about tokamak reactors or the NIF (or other intertial confinement research), I suggest you do so.
Several different research projects are working toward using HTE of water or HTE of water + CO2 (to produce methane gas), so it's not exactly pixie dust.
Any form of invisible link, invisible button, link or button in an iframe, getURL() call in Flash, or JavaScript handler for any normally non-clickable item that makes you go somewhere, yeah.
This could be useful for flooded areas, too. Along the Mississippi, Ohio, Illinois, and Missouri rivers, high flooding often means the rivers cover the water treatment and maybe the sewage treatment plants. So some cities go days or weeks without clean tap water during floods like 1993, 1997, and 2008. A few of these things per neighborhood would be a good emergency management step.
You assume I'm talking about an existing rod fission reactor. I am talking about high-temperature fusion reactors. Take a look at the Sun. High temperatures are guaranteed from high-temperature hydrogen fusion. Hence the name.
The heating of some water to steam, even 850 degree steam, wouldn't impact the heat of a 10**9 kelvins very damn much. Getting the water close enough to take advantage of the heat might be an issue. There are significant barriers to the high-temperature fusion plants themselves, too, but there is progress in that area.
Batteries might be a better carrier someday than hydrogen or hydrocarbons. Lithium-ion is probably not the technology to do that. Zinc-silver might be if ZPower actually solved the dendrite issue with them. Ultracapacitors would be nice, too.
Coal, oil, and natural gas are inherently lossy, too, or did you think we're currently producing new dinosaurs and forests and fossilizing them faster than they're being used?
Using anything as an "energy carrier" doesn't mean you're violating the second law of thermodynamics. As far as anyone knows, there's no way at all to ever do so. The whole idea of an energy carrier, even one like gasoline or diesel, is that it produces more energy on site than it takes to deliver it. It does not produce more energy at its final destination than what it took to produce in the first place.
I said "closer to the green", and I was assuming they hit the nitrous a bit too early as most of those ricer hooligans do. Most of their clutches are sloppy anyway from all the wheel spinning, as if it's impressive to spin wheels three revolutions from a dead stop on damp pavement. Suspension and tires are for old farts, after all.
Of course, if the new hot drag strips are 100 meters rather than a quarter mile, then all bets are off. BTW, whatever happened to the one-mile drag?
Oh, and you kids get your leafblowers -- I mean "cars" off my lawn! ;-)
Well, if speed is that much of a factor then you want your memory fabbed at a smaller node anyway, right?
The RAS recharge and data cell recharge in modern RAM is handled by the memory module anyway. The CPU just tells the module when to do it. So the module should be able to separate that from the read/write voltage on the data and address lines if it's dealing with two very different voltage ranges. The right solution, though, is to put the RAM through a die shrink.
What about inline solid resistors?
The higher voltage is used almost entirely to shorten the RAS recharge time, IIRC. The data line voltage usually shouldn't need to be the same as the refresh voltage. If your memory really requires 2 volts these days to send data to and from the processor, then you need a process shrink.
Memory can only be read or written at the proper edges of the clock frequency, so allow a write then refresh before the next possible read. The higher refresh voltage takes care of refreshing quickly and accounts for the voltage leak. The lower data line voltage to the processor means no damage.
This all depends on something other than the on-CPU memory controller providing the higher voltage for the refresh rewrite only, under the control of the memory controller.
In a CAS-before-RAS memory implementation, the memory controller sends CAS then RAS and the memory module refreshes itself. There's no reason the actual refresh voltage would need to flow through the memory controller. If there's no separation of the RAS recharge voltage from the external data lines, then that's a limitation of the module design. The modules would, again, be in need of a process shrink so they don't need so much voltage or a design change so that the higher voltage for internal module requirements don't flow out to other components.
The main power issue with RAM is the refresh pulse being high enough voltage so that it happens so frequently with enough reliability. There's not much reason with the nature of DRAM that the read and write voltages need to be as high as the refresh voltage.
You could accomplish this, if the memory can be read and written with a lower voltage than the refresh pulse, by putting resistors inline on the bus.
Why in the world would electrolyzing part of the steam remove the capability of the plant's main purpose of generating electricity? High-temperature electrolysis is a byproduct, not a primary goal for those types of plants that could produce hydrogen that way.
Unix and Windows are different mindsets as much as different technologies. Perl fits the Unix mindset very well. That said, although I am both a Perl programmer and a Unix user, I'd rather have Perl on my Windows machine than mess with VB, ASP, or C#.
I do, in fact, have Perl on Windows. I have ActiveState's packages for Perl 5.8 and 5.10, Strawberry Perl for 5.8 and 5.10, and Cygwin with its perl 5.8 as well.
PowerShell is a nice system, and I'm starting to learn it because it's really powerful on a Windows system. However, why should I write something in PowerShell and Perl when I can write it once and run it on Windows, Linux, BSD, and OS X?
If I was writing Windows-specific code that would never be ported, PowerShell is probably the way to go for quick-and-dirty code. C# would be the way to get Windows-specific code that kinda sorta works on Linux with Mono for more serious projects. However, writing to Perl (or Python or a few other languages) means I can take the code with me from one platform to another with minimal hassle.
Experienced programmers who write for maintainability write maintainable code. Experienced programmers who write whatever the hell they want or whatever clever bullshit comes to mind have the wrong kind of experience.
Look up "Moose". It's a module for objects in Perl 5 that pretty closely match the default implementation of objects in Perl 6.
Larry has promised that Perl 6 will still have most of the flexibility of Perl 5, but the design is going to include good defaults throughout the language rather than forcing you to always roll your own.
If you have a real hard-on for OOP, then you will probably love Perl 6 some day when it's out. Even the parser is just polymorphic methods, and therefore you can extend it and override parts of it at will. There's even enough thought behind the mutability and overriding of the parser that there are no reserved words and no numeric precedence levels. If you want a certain level of precedence, you say which operator you want the same precedence as, or that you want higher or lower precedence than operator X. You can whole new precedence level in between multiplication and addition, if you really need it, and all in one statement.
Well, Microsoft has been one of the big fund sources for ActiveState's ActivePerl package.
One thing you must realize about Perl before you go and stick it on the CLR is that Perl is severely dynamic at several levels. The CLR is a stack-based virtual machine for languages that are slightly dynamic. It really isn't a very good fit. Perl 5's parsing rules also happen to be very complex.
That's why Parrot was invented -- it's a register machine VM with automatic spilling and designed from the ground up to work well with highly dynamic languages. It's also designed to allow multiple languages to be compiled down to byte code for it. The main language in question is Perl 6. Perl 5, Ruby, Python, and PHP interpreters are also being written for it among others.
There have been many minor to major improvements in Perl 5 since 8 years ago. Among them are a mostly iterative regular expression engine, better threading, a native case statement (called given) and a new popular object system (as a module) that most people who try it like more than the original stock Perl 5 objects. Most of the serious heavy lifting in Perl implementation is being done on Perl 6, though. Rakudo (the implementation of Perl 6 on Parrot) is progressing and Parrot itself is stable enough that people are starting to write directly to it for production use.
If the people who develop perl think that Perl needs a different kind of VM to run its best and they've spent eight years on the language and VM, then why disregard all that now that completion of that work is within sight? Why shoehorn Perl 5 into an environment where it won't fit when there are viable systems for running it and it's about to be largely superseded?
Perl hasn't gone anywhere. It's just that newer shops tend to start with the buzzword languages of the time. In the 1980's there were thousands of Lisp shops developing software. Now many of them are gone, but plenty of people still use Lisp even for new projects.
In the 1990's there were lots of start-ups using Perl, and now many of them are gone. There are still plenty of people using Perl, even for new projects.
In ten years, there will probably be a new king of the hill, like Erlang some kind of implicitly concurrent extension to Ruby. Yet Python will not magically die out over night any more than Perl or Lisp.
Suits who pick the technology are usually wrong, and seldom obeyed.
Strawberry Perl and ActivePerl are both pretty nice packages. Many Win32 modules like Win32::OLE, Win32::API, and more in the Win32 and Win32API namespaces are perfectly usable.
The places most qualified to answer specific questions are probably comp.lang.perl.moderated (or maybe comp.lang.perl.misc) and Perlmonks. I don't know too much first-hand about PerlGuru, but they do have a section specific to Win32 programming with Perl and I've heard some good things.
...but in the great tradition of Emacs, it can do both, and browse the web, too.