Not entirely true. Several operating systems worked on supporting PAE to address up to 64GB before the shift to 64-bit processors. Intel started using a 36-bit address bus in the Pentium Pro more than a decade ago.
At least some of the lackluster quality there would be from the recompression itself. You would need a fresh compression from a lossless master to make a fair comparison.
Still, I agree that DVD9 is a tight fit, particularly in regard to longer titles or particularly feature-laden releases (though it seems two-disc releases are likely to be used for HD even when unnecessary for reasons of percieved value). Lossless audio has always struck me as more a marketing gimmic than anything else, but the greater range of codecs supported in the new standards do represent a functional improvement.
(I personally think HD30 was plenty and it strikes me as daft that Warner chose the more expensive format while economists were debating whether we were about to go into a recession or had already slipped into one, but that's another debate.:)
So I quote the manufacturer stating explicitely that TDP isn't max power, you reort with "The TDP is max power" and then go on to explain how Intel justifies not using max power for TDP. Fascinating. Might want to bone up on your english some.
No, it's not the absolute maximum. Look at their specs. They all say in the foot notes: " TDP specification should be used to design chipset thermal solution. It is not the maximum theoretical power the chipset can generate."
It's definitely not a straight-across comparison. Intel always includes a footnote stating "TDP specification should be used to design chipset thermal solution. It is not the maximum theoretical power the chipset can generate." while Via reports the maximum theoretical power consumption.
The chipset in the platform integrates both the north and southbridge and consumes a whopping 2.3W.
Not sure what that picture is supposed to be, since you didn't link any context, but it's certainly not of their mobile offering, which comes in at under five watts chipset inclusive.
Intel's own presentations don't have them targeting smartphones until two generations past this one. Both products are targetting "internet devices" and ultramobile PCs.
Trying to compare the two processors with the amount of information available on them right now is pretty silly in general. Clock speed comparisons are even more silly considering the vastly different architectures (single-issue, in-order vs three-issue, out-of-order) and cache sizes (24K L1-I, 32K L1-D, 512K 8-way L2 vs 64k L1-I, 64K L1-D, 1024K 16-way L2).
Power comparisons are a bit premature at this point as well. Noone knows what typical consumption is at this point; just idle and max. A lot depends on how effective the power management is in each processor. Depending on the performance delta between the chips it's also possible that a higher maximum TDP won't always be the disadvantage it seems to be; if the Via chip has higher instruction throughput, it means it can return to idle state that much quicker.
There's also the question of the whole platform, as well. The chipset from Intel manages an impressive TDP (about 2.3W) but is somewhat limited - only 400/533MHz FSB, low max resolution (1366x768 LVDS or 1280x1024 SDVO), one DDR2 400/533Mhz slot, only two 1x PCI-e ports, no SATA and only one PATA channel. So far as I know there are no hard numbers of graphics performance since they're integrating a licensed design (PowerVR SGX535) that has traditionally been used in embedded devices. However their own slideshows comparing the capabilities with their (over four year old!) 915G chipset show about half the memory bandwidth and less than a third the pixel rate. In other words, pretty piss poor. They do, however, include hardware acceleration for most common codecs, which should minimize the impact in their target market.
The new chipset Via is offering - the VX800 - consumes far more power at peak (though as with the processor this may or may not reflect typical depending on how the power management is implemented) but is a bit more featureful - 800MHz bus, up to 1920x1200, two DDR2 667MHz slots, a 4x PCI-e slot in addition to the two 1x slots, two SATA 2.0 ports and video capture support. They also offer a lower power version - the VX800u - which drops the peak TDP to 3.5W but drops the bus to 400MHz and nixes the 4x PCI-e slot and SATA ports.
My take is that the Intel offering is probably better suited to certain embedded applications as well as the MID market. The main market these two will likely compete in is the burgeoning UMPC market. Without real performance and power numbers it's hard to say who has the edge. More likely than not which chip is best will depend entirely on what trade-offs the manufacturer is willing to make.
For every new package i introduced i had conflicts all over and had to resolve them by endless sessions with "--force".
Using --force or --nodeps isn't resolving a problem, it's ignoring and compounding them. I have little modern experience with SuSE but an RPM system using appropriate repositories should never need to be forced, period.
There was no support for ia64 in 2.95 period. Not a matter of a single application not working. Additionally 2.95 suffered from poor standards compliance and an incomplete C++ implementation.
Of course the upstream maintainers aren't going to support a vendor branch. You fork it, you fix it. When you have the resources, sometimes that makes sense.sometimes that makes sense. In this case Red Hat was in a good position to do so since they employed a substantial number of key GCC developers. In fact it was the engineers they inherited from Cygnus who suggested they move to a stabalized version in the first place. The main stink arose mostly from miscommunication and the use of the 2.96 version moniker (later renamed 2.96RH to make it clear that it was a forked release).
And none of that reflects on the quality of the compiler itself. There were a handful of quickly addressed bugs in the early releases, but the majority of the poor reputation really rests on people erroneously blaming the compiler for not accepting sloppy code. I've built literally thousands of packages (remember, it's still the production compiler in RHEL 2.1AS) without running into a single bug attributable to the compiler.
As for whether Red Hat is "all about marketing", you should note that Red Hat continues to support software compiled against that ABI in their current production release. By the time that falls out of maintenance they will have provided FOURTEEN YEARS of support. That, my friend, is giving value to their consumers.
Eh? The move to glibc2 was a painful transition every distribution was making. Red Hat at least did a good job of proving compat libs.
And as maligned as gcc 2.96 was, it was a fairly solid compiler. The vast majority of compile failures were bad code that older versions of GCC allowed.
Unless you're doing load testing (which I can't imagine you'd want to do on old notebooks anyways) then virtual machines work just dandy for cluster testing. My aging Pentium-D desktop with 1GB of memory and a single disk was plenty happy to emulate both a five node cluster as well as an iSCSI SAN. A more modern machine would make an even better test rig. Hell, you can put together an eight core machine with 8GB of memory for about a grand.
Unless you need the horsepower, though, you don't really need dedicated cores for your virtual machines so you can cheap out and either recycle older hardware or spend a few hundred on a single quad-core system instead. Xen and VMware have no problem allocation a percentage of a CPU and a set proportion of memory. Disk could potentially become a bottleneck, though even a single modern 7200rpm drive will certainly outperform even a handful of ultraportables, which are tuned for power rather tha performance. If it really becomes an issue, though, you can pick up 3.5" 80GB SATA drives for under $40 or 2.5" 60GB SATA drives (if you care more about power, noise and density) for under $50. Cheaper to buy dedicated drives than dedicated machines, at least. And performance will still be higher than anything you'll pick up in the old subnote/umpc segment.
In which case people would bitch about how outdated it is. Consumer desktop and enterprise server (or even desktop) needs are highly divergant. Not to mention the value of Fedora as a test bed for cutting edge technology.
Eh? Unless you add optional repositories Fedora has absolutely nothing to do with CentOS. The only packages changed from upstream RHEL are done for copyright reasons (i.e. artwork).
Not sure what problems you have with CentOS in VMware. We have dozens of production instances running just fine.
Cloudmark isn't just a client based solution. They offer a wide variety of server-side (e.g. Exchange and Spam Assassin plugins) as well as full edge solutions.
That said, I've also had pretty good experience with MXLogic. Definitely solid choice for external filtering.
Slashdot Mirror
I have no idea how rails works, but why on earth wouldn't you have back-end modules persist across connections so you can reuse them?
"like Java"? Buh? Why, because they both have objects and can be used to write web applications?
Not entirely true. Several operating systems worked on supporting PAE to address up to 64GB before the shift to 64-bit processors. Intel started using a 36-bit address bus in the Pentium Pro more than a decade ago.
And Oldsmobile didn't get any money when I bought my car. Does that mean it was "just a step up" from theft?
About 42% are H.264, 30% MPEG2, 28% VC-1.
At least some of the lackluster quality there would be from the recompression itself. You would need a fresh compression from a lossless master to make a fair comparison.
:)
Still, I agree that DVD9 is a tight fit, particularly in regard to longer titles or particularly feature-laden releases (though it seems two-disc releases are likely to be used for HD even when unnecessary for reasons of percieved value). Lossless audio has always struck me as more a marketing gimmic than anything else, but the greater range of codecs supported in the new standards do represent a functional improvement.
(I personally think HD30 was plenty and it strikes me as daft that Warner chose the more expensive format while economists were debating whether we were about to go into a recession or had already slipped into one, but that's another debate.
So I quote the manufacturer stating explicitely that TDP isn't max power, you reort with "The TDP is max power" and then go on to explain how Intel justifies not using max power for TDP. Fascinating. Might want to bone up on your english some.
If they follow the pattern they have with board form factors then yes, pico would be next. (Mini-ITX -> Nano-ITX -> Pico-ITX).
No, it's not the absolute maximum. Look at their specs. They all say in the foot notes: " TDP specification should be used to design chipset thermal solution. It is not the maximum theoretical power the chipset can generate."
It's definitely not a straight-across comparison. Intel always includes a footnote stating "TDP specification should be used to design chipset thermal solution. It is not the maximum theoretical power the chipset can generate." while Via reports the maximum theoretical power consumption.
The chipset in the platform integrates both the north and southbridge and consumes a whopping 2.3W.
Not sure what that picture is supposed to be, since you didn't link any context, but it's certainly not of their mobile offering, which comes in at under five watts chipset inclusive.
Intel's own presentations don't have them targeting smartphones until two generations past this one. Both products are targetting "internet devices" and ultramobile PCs.
Trying to compare the two processors with the amount of information available on them right now is pretty silly in general. Clock speed comparisons are even more silly considering the vastly different architectures (single-issue, in-order vs three-issue, out-of-order) and cache sizes (24K L1-I, 32K L1-D, 512K 8-way L2 vs 64k L1-I, 64K L1-D, 1024K 16-way L2).
Power comparisons are a bit premature at this point as well. Noone knows what typical consumption is at this point; just idle and max. A lot depends on how effective the power management is in each processor. Depending on the performance delta between the chips it's also possible that a higher maximum TDP won't always be the disadvantage it seems to be; if the Via chip has higher instruction throughput, it means it can return to idle state that much quicker.
There's also the question of the whole platform, as well. The chipset from Intel manages an impressive TDP (about 2.3W) but is somewhat limited - only 400/533MHz FSB, low max resolution (1366x768 LVDS or 1280x1024 SDVO), one DDR2 400/533Mhz slot, only two 1x PCI-e ports, no SATA and only one PATA channel. So far as I know there are no hard numbers of graphics performance since they're integrating a licensed design (PowerVR SGX535) that has traditionally been used in embedded devices. However their own slideshows comparing the capabilities with their (over four year old!) 915G chipset show about half the memory bandwidth and less than a third the pixel rate. In other words, pretty piss poor. They do, however, include hardware acceleration for most common codecs, which should minimize the impact in their target market.
The new chipset Via is offering - the VX800 - consumes far more power at peak (though as with the processor this may or may not reflect typical depending on how the power management is implemented) but is a bit more featureful - 800MHz bus, up to 1920x1200, two DDR2 667MHz slots, a 4x PCI-e slot in addition to the two 1x slots, two SATA 2.0 ports and video capture support. They also offer a lower power version - the VX800u - which drops the peak TDP to 3.5W but drops the bus to 400MHz and nixes the 4x PCI-e slot and SATA ports.
My take is that the Intel offering is probably better suited to certain embedded applications as well as the MID market. The main market these two will likely compete in is the burgeoning UMPC market. Without real performance and power numbers it's hard to say who has the edge. More likely than not which chip is best will depend entirely on what trade-offs the manufacturer is willing to make.
I'd just Alt+F(x) between my vtty's and do my business.
:)
What, no screen?
The current F5 boxes run Linux. Once upon a time they were BSDI, but that was many many years ago.
For every new package i introduced i had conflicts all over and had to resolve them by endless sessions with "--force".
Using --force or --nodeps isn't resolving a problem, it's ignoring and compounding them. I have little modern experience with SuSE but an RPM system using appropriate repositories should never need to be forced, period.
Unless you learn how to package. :)
There was no support for ia64 in 2.95 period. Not a matter of a single application not working. Additionally 2.95 suffered from poor standards compliance and an incomplete C++ implementation.
Of course the upstream maintainers aren't going to support a vendor branch. You fork it, you fix it. When you have the resources, sometimes that makes sense.sometimes that makes sense. In this case Red Hat was in a good position to do so since they employed a substantial number of key GCC developers. In fact it was the engineers they inherited from Cygnus who suggested they move to a stabalized version in the first place. The main stink arose mostly from miscommunication and the use of the 2.96 version moniker (later renamed 2.96RH to make it clear that it was a forked release).
And none of that reflects on the quality of the compiler itself. There were a handful of quickly addressed bugs in the early releases, but the majority of the poor reputation really rests on people erroneously blaming the compiler for not accepting sloppy code. I've built literally thousands of packages (remember, it's still the production compiler in RHEL 2.1AS) without running into a single bug attributable to the compiler.
As for whether Red Hat is "all about marketing", you should note that Red Hat continues to support software compiled against that ABI in their current production release. By the time that falls out of maintenance they will have provided FOURTEEN YEARS of support. That, my friend, is giving value to their consumers.
RHEL 4.6 came out on 11-16, CentOS 4.6 came out on 12-16.
:)
RHEL 5.4 came out on 11-08, CentOS 5.1 came out on 12-02.
Judging by that, a month sounds likely. Of course I'm sure the answer they would give is "when it's done".
Eh? The move to glibc2 was a painful transition every distribution was making. Red Hat at least did a good job of proving compat libs.
And as maligned as gcc 2.96 was, it was a fairly solid compiler. The vast majority of compile failures were bad code that older versions of GCC allowed.
Unless you're doing load testing (which I can't imagine you'd want to do on old notebooks anyways) then virtual machines work just dandy for cluster testing. My aging Pentium-D desktop with 1GB of memory and a single disk was plenty happy to emulate both a five node cluster as well as an iSCSI SAN. A more modern machine would make an even better test rig. Hell, you can put together an eight core machine with 8GB of memory for about a grand.
Unless you need the horsepower, though, you don't really need dedicated cores for your virtual machines so you can cheap out and either recycle older hardware or spend a few hundred on a single quad-core system instead. Xen and VMware have no problem allocation a percentage of a CPU and a set proportion of memory. Disk could potentially become a bottleneck, though even a single modern 7200rpm drive will certainly outperform even a handful of ultraportables, which are tuned for power rather tha performance. If it really becomes an issue, though, you can pick up 3.5" 80GB SATA drives for under $40 or 2.5" 60GB SATA drives (if you care more about power, noise and density) for under $50. Cheaper to buy dedicated drives than dedicated machines, at least. And performance will still be higher than anything you'll pick up in the old subnote/umpc segment.
Poorly designed sites being the bulk of the internet. :)
In which case people would bitch about how outdated it is. Consumer desktop and enterprise server (or even desktop) needs are highly divergant. Not to mention the value of Fedora as a test bed for cutting edge technology.
Eh? Unless you add optional repositories Fedora has absolutely nothing to do with CentOS. The only packages changed from upstream RHEL are done for copyright reasons (i.e. artwork).
Not sure what problems you have with CentOS in VMware. We have dozens of production instances running just fine.
Cloudmark isn't just a client based solution. They offer a wide variety of server-side (e.g. Exchange and Spam Assassin plugins) as well as full edge solutions.
That said, I've also had pretty good experience with MXLogic. Definitely solid choice for external filtering.