Lots of small files isn't bad on its own. In fact, it's downright common. Ext4's design does consider this case and makes these operations efficient.
The problem with small files is data consistency. If the application requires a file hierarchy and associated buffers to be on disk before continuing, then a call to fsync() is required (even on ext3). Implicitly syncing on every small file will kill performance, so don't do that.
Ext3 doesn't write out immediately either. If the system crashes within the commit interval, you'll lose whatever data was written during that interval. That's only 5 seconds of data if you're lucky, much more data if you're unlucky. Ext4 simply made that commit interval and backend behavior different than what applications were expecting.
All modern fs drivers, including ext3 and NTFS, do not write immediately to disk. If they did then system performance would really slow down to almost unbearable speeds (only about 100 syncs/sec on standard consumer magnetic drives). And sometimes the sync call will not occur since some hardware fakes syncs (RAID controllers often do this).
POSIX doesn't define flushing behavior when writing and closing files. If your applications needs data to be in NV memory, use fsync. If it doesn't care, good. If it does care and it doesn't sync, it's a bad application and is flawed, plain and simple.
I understand what Jeff's saying, and he's claiming that it's apples to apples. It's not, even in the slightest.
Besides, executables and packages are two different concepts. It's fine to compare against executables if you want, it's just far harder to keep track off. FYI, there are over 2400 executables in that same CentOS 4 system described in my parent post, and that doesn't include script or bins in some places (/etc/rc.d for example). Toss in over 900 shared objects if you want to track DLLs too. Might as well track every file, since there are vulnerabilities exposed by poor configuration, bad resources, etc. In that case we're looking at over 173,000 files, and that's just/usr.
Point being, common Linux distributions are huge. Even a minimal install will dwarf a full Windows install by a significant margin.
Q: Linux distros contain many more optional applications than Windows - that is Apples
and Oranges - how can any comparison be valid?
Actually, Windows Vista and Windows XP have different components too. Windows Vista
Ultimate includes Media Center for example, which was not in Windows XP Professional. From a
user perspective, I think it is Apples and Apples. Whichever OS is chosen, I believe most people
will install the default set of components and use that. If vulnerabilities are in those components,
they will be exposed and need to take mitigating action.
I did, however, try to even the playing field as much as possible by excluding optional Linux-distro
components and excluding even some default components for which there is no obvious
counterpart. In contrast, on the Windows analysis, I included any component that shipped with
the product. I think the comparison is valid and useful.
From my basic CentOS 4 system:
$ rpm -q -a | wc -l
1104
Even on a (stupid) vulnerability count, even with a reduced package setup, the number of packages on a RHEL/CentOS system dwarfs the number of programs that come with Windows. You can't even compare against Jeff's Windows numbers because he looks into how critical each vulnerability is on Windows (good) but not on any Linux setup (bad). If the real concern is user exposure, then vulnerabilities in all packages makes sense, but only if you count vulnerabilities in common Windows packages to, like Acrobat Reader, Photoshop, Office, and even games like WoW.
My biggest beef is that Jeff fails to include his compiled vulnerability database. Even though he writes on his methodology and sources, there is no way to easily verify his claims. This is the 21st century and there's something called the Internet. There's no excuse to not provide the raw data, and I certainly don't have enough interest to make guesses and recreate the data for such a flawed analysis anyway.
Next time at least provide a list of analyzed RPMs and DEBs!
FastTCP isn't really a full TCP replacement but rather a congestion control algorithm. There are many competitors to FastTCP, including BIC/CUBIC (common Linux default), High-Speed TCP, H-TCP, Hybla, and many others. Microsoft calls their version Compound TCP (available in Vista).
If you use Linux, have (CU)BIC loaded, correctly setup your NIC, and tune your TCP settings (rx/tx mem, queuelen, and such) then there is be no way for FastSoft to claim a 15-20x speedup improvement. I've done full 10 gigabit transmissions with a 150ms RTT using that kind of setup. FastSoft's device doesn't even support 10 gigabit, and their 1 gigabit device still isn't released.
This article is nothing other than a Slashadvertisment.
There has been no modesetting branch of the Intel driver for some time now. Oh, and it is merged into XOrg. Get up to date with XOrg server 7.3, xf86-video-intel-2.0.0, and Mesa 6.5.3 and try again.
Run the numbers again. First, it's kilometers, not miles (1km ~=.62 miles). Second, heat engines, like your gas car, are far and away from efficient. We're talking on the order of 30% if you're lucky. Third, pressures of 200 bar isn't as high as modern tanks can go. Modern mass-produced tanks can easily reach, and break in a safe way when damaged, 700 bar. Finally there's the whole weight deal. I'm willing to bet that these cars are much lighter than your typical gas-fed car.
300 kilometers might be pushing it (not that I'm an expert here), but it's not implausible considering other efforts claiming similar ranges: http://news.bbc.co.uk/2/hi/europe/2281011.stm
My family owns a vacation cabin in the mountains and this is what we do:
- Dual heating systems. One gas heater keeps the house warm enough (55F) and electric room heaters are set below that. We've had yet the chance to see both fail.
- The water is shut off. If a pipe breaks then at least it doesn't flood.
- To avoid water breaks, cover all outside faucets. We use something similar to this: http://www.improvementscatalog.com/HanoverAssets/I mprovements/large_images/264284zz.jpg
- Some lights are put on timers for protection against burglary (the house looks occupied). You should also ask your neighbors to call if you they see suspicious activity.
Don't forget that when you come back to turn on the water and flush out both the hot and cold water from the system. You don't want to be heating up or drinking water that's been sitting around in water heater or pipes.
If you're really worried about the place, get a security camera. I've used Axis network cameras ( http://www.axis.com/products/video/camera/ ) and they are good cameras.
To quote the article: "Our test computers weren't fully fledged high-end gaming machines, but we don't have two identical high-end rigs, but we made do."
So what IGN is saying is that the Killer NIC performs better on a machine that is not the same as the control machine. IGN's results are entirely invalid. Heck, the little data that is presented isn't correctly formed.
There are hardware encryption accelerators that are being common. For instance, newish VIA's C3 processors have hardware RNGs, MAC, and AES engines that speed up the hard work in encryption.
Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.
Like another poster said,/dev/random is probably your problem. Over here we're running Linux with a Myricom 10G card on a PCIe bus. 9.9Gb/sec is easy enough to do so long as you have the right equipment and enough processing power (you'll see about 30,000 interrupts/sec).
Am I reading it correctly that CNet doesn't understand the difference between launching an executeable stored on an external media device, and somehow running it "on" the media device? Am I the only one who thinks Mr. Usher could have been clearer, but intentionally wasn't? Or that both are playing it as "plug an ipod in, instantly hack a machine", like in the movies where magical devices "hack" systems?
I wouldn't bet on that. Hardware really can magically and (near) instantly hack a host: Don't trust your hardware
I can't believe the parent got modded up. This kind of thing has been done before (RTFA. Yeah yeah, I know. I must be new here...). It's called TOE (TCP Offload Engine) and many networking companies have done TOE. However, most cards are expensive and don't have much support across platforms.
What's new here is that Intel wants to put this in their chipsets everywhere and not just in $700+ NICs. Already this has been happening with checksum offloading, TCP fragmentation, smart interrupts, and so on in most GigE chips.
So yes, people have done this before and have been since at least 2000.
As far a DRM is concerned, look at the NIC market and look at the TCP/IP spec. TCP/IP? Standard and anything non-standard won't work with stuff that's out there. Wierd NICs? I've been getting Linux source-code drivers for even the cheapest of cheap NICs for years now. There's too much competition to sneak in something restrictive.
Totally agreed. President Bush should be protecting us from evil terrorists from the middle east and possibly North Korea. For shame that he is off campaigning in the latest swing state.
Heck no! Every canidate has a right to campain for their office of choice. Kerry would have better chances of getting his legistlation through if he is president, and the same goes with Bush.
Read this, it might help you understand the concept: http://en.wikipedia.org/wiki/Opportunity_cost
"DHCP Client, automatic. Unnecessary on most home machines. Should be disabled by default."
Now, I'm no fan of Microsoft (Windows free for over 5 years now), but this is insane. Evey home user I have ever helped needs a DHCP client so that their computer can get an IP off the university LAN or off their brand-spankin'-new broadband router. To disable the DHCP client means to turn off the interweb for the majority of users. Greene went a little over the top it seems.
That's true, but by closing the Windows source Peter is closing off GPL code written by others. While selling GPL software is fine, selling GPL software without the code at a resonable cost is not allowed.
It's a GPL project with contributers and Peter assumed that since the contributers never stated licensing terms that he could close up the Windows client. That and the fact that only the *nix source would be downloadable.
Bytes 0x10 through 0x23 in the tgz are the signature. They are unique in every download and are probably recorded by transgaming to know who downloaded what archive. Also, all hopes of using md5 or any other form of checksumming to verify valid files are out the window.
So there you have it. Gentoo is forced to download from Transgaming's website and they keep changing signatures. Unless you are installed a warezed copy of it, MD5 checksums arn't going to be of much use.
While it is true that the FPU of the C3 still isn't up to speed with other processors, the C3 1Ghz can definatly play 720x540 MPEG4 back at full speed. I do it all the time with a CVS copy of MPlayer (DirectFB driver) on Slackware Linux. I can even play 720x460 WMV9 (windows binary DLL) with 80% cpu utilization. For comparison, libavcodec decodes 640x480 MPEG4 with only 32% CPU utilization, with 14% going to dealing with the framebuffer (not decoding, just frame copying or vsyncing).
Slashdot Mirror
Extrapolating? Sounds like a job for Randall Munroe! http://xkcd.com/605/
Lots of small files isn't bad on its own. In fact, it's downright common. Ext4's design does consider this case and makes these operations efficient.
The problem with small files is data consistency. If the application requires a file hierarchy and associated buffers to be on disk before continuing, then a call to fsync() is required (even on ext3). Implicitly syncing on every small file will kill performance, so don't do that.
Ext3 doesn't write out immediately either. If the system crashes within the commit interval, you'll lose whatever data was written during that interval. That's only 5 seconds of data if you're lucky, much more data if you're unlucky. Ext4 simply made that commit interval and backend behavior different than what applications were expecting.
All modern fs drivers, including ext3 and NTFS, do not write immediately to disk. If they did then system performance would really slow down to almost unbearable speeds (only about 100 syncs/sec on standard consumer magnetic drives). And sometimes the sync call will not occur since some hardware fakes syncs (RAID controllers often do this).
POSIX doesn't define flushing behavior when writing and closing files. If your applications needs data to be in NV memory, use fsync. If it doesn't care, good. If it does care and it doesn't sync, it's a bad application and is flawed, plain and simple.
> Intel can do it. ATI has promised to do it and now so does VIA. Why is NVidia different?
ATI hasn't just promised, they did:
http://ati.amd.com/developer/open_gpu_documentation.html
http://www.phoronix.com/scan.php?page=article&item=842&num=1
I understand what Jeff's saying, and he's claiming that it's apples to apples. It's not, even in the slightest.
/usr.
Besides, executables and packages are two different concepts. It's fine to compare against executables if you want, it's just far harder to keep track off. FYI, there are over 2400 executables in that same CentOS 4 system described in my parent post, and that doesn't include script or bins in some places (/etc/rc.d for example). Toss in over 900 shared objects if you want to track DLLs too. Might as well track every file, since there are vulnerabilities exposed by poor configuration, bad resources, etc. In that case we're looking at over 173,000 files, and that's just
Point being, common Linux distributions are huge. Even a minimal install will dwarf a full Windows install by a significant margin.
From Jeff Jones' report:
Q: Linux distros contain many more optional applications than Windows - that is Apples and Oranges - how can any comparison be valid?
Actually, Windows Vista and Windows XP have different components too. Windows Vista Ultimate includes Media Center for example, which was not in Windows XP Professional. From a user perspective, I think it is Apples and Apples. Whichever OS is chosen, I believe most people will install the default set of components and use that. If vulnerabilities are in those components, they will be exposed and need to take mitigating action.
I did, however, try to even the playing field as much as possible by excluding optional Linux-distro components and excluding even some default components for which there is no obvious counterpart. In contrast, on the Windows analysis, I included any component that shipped with the product. I think the comparison is valid and useful.
From my basic CentOS 4 system:
$ rpm -q -a | wc -l
1104
Even on a (stupid) vulnerability count, even with a reduced package setup, the number of packages on a RHEL/CentOS system dwarfs the number of programs that come with Windows. You can't even compare against Jeff's Windows numbers because he looks into how critical each vulnerability is on Windows (good) but not on any Linux setup (bad). If the real concern is user exposure, then vulnerabilities in all packages makes sense, but only if you count vulnerabilities in common Windows packages to, like Acrobat Reader, Photoshop, Office, and even games like WoW.
My biggest beef is that Jeff fails to include his compiled vulnerability database. Even though he writes on his methodology and sources, there is no way to easily verify his claims. This is the 21st century and there's something called the Internet. There's no excuse to not provide the raw data, and I certainly don't have enough interest to make guesses and recreate the data for such a flawed analysis anyway.
Next time at least provide a list of analyzed RPMs and DEBs!
FastTCP isn't really a full TCP replacement but rather a congestion control algorithm. There are many competitors to FastTCP, including BIC/CUBIC (common Linux default), High-Speed TCP, H-TCP, Hybla, and many others. Microsoft calls their version Compound TCP (available in Vista).
If you use Linux, have (CU)BIC loaded, correctly setup your NIC, and tune your TCP settings (rx/tx mem, queuelen, and such) then there is be no way for FastSoft to claim a 15-20x speedup improvement. I've done full 10 gigabit transmissions with a 150ms RTT using that kind of setup. FastSoft's device doesn't even support 10 gigabit, and their 1 gigabit device still isn't released.
This article is nothing other than a Slashadvertisment.
There has been no modesetting branch of the Intel driver for some time now. Oh, and it is merged into XOrg. Get up to date with XOrg server 7.3, xf86-video-intel-2.0.0, and Mesa 6.5.3 and try again.
Run the numbers again. First, it's kilometers, not miles (1km ~= .62 miles). Second, heat engines, like your gas car, are far and away from efficient. We're talking on the order of 30% if you're lucky. Third, pressures of 200 bar isn't as high as modern tanks can go. Modern mass-produced tanks can easily reach, and break in a safe way when damaged, 700 bar. Finally there's the whole weight deal. I'm willing to bet that these cars are much lighter than your typical gas-fed car.
300 kilometers might be pushing it (not that I'm an expert here), but it's not implausible considering other efforts claiming similar ranges: http://news.bbc.co.uk/2/hi/europe/2281011.stm
My family owns a vacation cabin in the mountains and this is what we do:
I mprovements/large_images/264284zz.jpg
- Dual heating systems. One gas heater keeps the house warm enough (55F) and electric room heaters are set below that. We've had yet the chance to see both fail.
- The water is shut off. If a pipe breaks then at least it doesn't flood.
- To avoid water breaks, cover all outside faucets. We use something similar to this: http://www.improvementscatalog.com/HanoverAssets/
- Some lights are put on timers for protection against burglary (the house looks occupied). You should also ask your neighbors to call if you they see suspicious activity.
Don't forget that when you come back to turn on the water and flush out both the hot and cold water from the system. You don't want to be heating up or drinking water that's been sitting around in water heater or pipes.
If you're really worried about the place, get a security camera. I've used Axis network cameras ( http://www.axis.com/products/video/camera/ ) and they are good cameras.
To quote the article: "Our test computers weren't fully fledged high-end gaming machines, but we don't have two identical high-end rigs, but we made do."
So what IGN is saying is that the Killer NIC performs better on a machine that is not the same as the control machine. IGN's results are entirely invalid. Heck, the little data that is presented isn't correctly formed.
There are hardware encryption accelerators that are being common. For instance, newish VIA's C3 processors have hardware RNGs, MAC, and AES engines that speed up the hard work in encryption.
Furthermore, THG's article claims to have tested large file sizes but their graphs dont show it. In order for a filesystem to be correctly benchmarked, the test file size must be at least twice the size of RAM. If it isn't then the test is only testing RAM speed, algorithm speed, and Linux's page cache system. According to THG, LUKS can sustain > 100MB/sec on a 20GB laptop drive from 2002. Hmmm, I think not.
Like another poster said, /dev/random is probably your problem. Over here we're running Linux with a Myricom 10G card on a PCIe bus. 9.9Gb/sec is easy enough to do so long as you have the right equipment and enough processing power (you'll see about 30,000 interrupts/sec).
Am I reading it correctly that CNet doesn't understand the difference between launching an executeable stored on an external media device, and somehow running it "on" the media device? Am I the only one who thinks Mr. Usher could have been clearer, but intentionally wasn't? Or that both are playing it as "plug an ipod in, instantly hack a machine", like in the movies where magical devices "hack" systems?
I wouldn't bet on that. Hardware really can magically and (near) instantly hack a host: Don't trust your hardware
If everyone got their minds out of the gutter and started choosing decent key numbers I'm sure DES wouldn't be broken so quickly. ;-)
I can't believe the parent got modded up. This kind of thing has been done before (RTFA. Yeah yeah, I know. I must be new here...). It's called TOE (TCP Offload Engine) and many networking companies have done TOE. However, most cards are expensive and don't have much support across platforms.
What's new here is that Intel wants to put this in their chipsets everywhere and not just in $700+ NICs. Already this has been happening with checksum offloading, TCP fragmentation, smart interrupts, and so on in most GigE chips.
So yes, people have done this before and have been since at least 2000.
As far a DRM is concerned, look at the NIC market and look at the TCP/IP spec. TCP/IP? Standard and anything non-standard won't work with stuff that's out there. Wierd NICs? I've been getting Linux source-code drivers for even the cheapest of cheap NICs for years now. There's too much competition to sneak in something restrictive.
Totally agreed. President Bush should be protecting us from evil terrorists from the middle east and possibly North Korea. For shame that he is off campaigning in the latest swing state.
Heck no! Every canidate has a right to campain for their office of choice. Kerry would have better chances of getting his legistlation through if he is president, and the same goes with Bush.
Read this, it might help you understand the concept: http://en.wikipedia.org/wiki/Opportunity_cost
Really?
"DHCP Client, automatic. Unnecessary on most home machines. Should be disabled by default."
Now, I'm no fan of Microsoft (Windows free for over 5 years now), but this is insane. Evey home user I have ever helped needs a DHCP client so that their computer can get an IP off the university LAN or off their brand-spankin'-new broadband router. To disable the DHCP client means to turn off the interweb for the majority of users. Greene went a little over the top it seems.
That's true, but by closing the Windows source Peter is closing off GPL code written by others. While selling GPL software is fine, selling GPL software without the code at a resonable cost is not allowed.
One small detail: Gettext is not LGPL. It's GPL.
It's a GPL project with contributers and Peter assumed that since the contributers never stated licensing terms that he could close up the Windows client. That and the fact that only the *nix source would be downloadable.
From the article:
Bytes 0x10 through 0x23 in the tgz are the signature. They are unique in every download and are probably recorded by transgaming to know who downloaded what archive. Also, all hopes of using md5 or any other form of checksumming to verify valid files are out the window.
So there you have it. Gentoo is forced to download from Transgaming's website and they keep changing signatures. Unless you are installed a warezed copy of it, MD5 checksums arn't going to be of much use.
... I tend to find them:
1 7236&tid=103&tid=117&tid=185&tid=9 8
http://it.slashdot.org/article.pl?sid=04/08/13/13
Must be the season for dups.
While it is true that the FPU of the C3 still isn't up to speed with other processors, the C3 1Ghz can definatly play 720x540 MPEG4 back at full speed. I do it all the time with a CVS copy of MPlayer (DirectFB driver) on Slackware Linux. I can even play 720x460 WMV9 (windows binary DLL) with 80% cpu utilization. For comparison, libavcodec decodes 640x480 MPEG4 with only 32% CPU utilization, with 14% going to dealing with the framebuffer (not decoding, just frame copying or vsyncing).