It doesn't matter what Intel chooses to call it (they have changed their mind 3 times: IA-32e, EM64T, Intel64).
The fact is, Intel cloned the AMD64 architecture.
AMD wrote the architecture specs
and they gave it the name AMD64.
When you install NetBSD or OpenBSD on a 64-bit Intel processor, you install NetBSD/amd64 or OpenBSD/amd64, these
guys adopted the proper architecture name.
Other vendors use other names, Microsoft and Sun use x64, some use x86-64.
Should you use these names ? No. Just stick to the official arch name, AMD64.
When AMD cloned the IA32 (aka i386) architecture, AMD processors were (properly) recognized
as being IA32 or i386 processors, so let's do the same for this generation of processors
and use the proper name: AMD64.
There are 2 ways to get a 32-bit Java plugin running under a Linux/AMD64 environment (BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned):
Use the Blackdown Java plugin, they provide a 64-bit version (it works ok, but I have come across at least 1 applet able to crash it).
Use nspluginwrapper that allows you to load 32-bit plugins in 64-bit browsers.
Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.
Transport:
JACK audio connection kit: supported by almost all linux audio software.
I have recently spent a lot of time researching network-transparent audio transport applications so that I can, for example, walk around my apartment with a wireless Linux laptop while it is outputting sound to big speakers in the room (over wifi to a Linux media server connected to an audio receiver).
I have come across JACK and a dozens other apps, but it seems that PulseAudio is by far the most advanced and the cleanest implementation out there. It is multi-platform, it comes with dozens of plugins (alsa, oss, esound, etc) for max compatibility with existings apps, it is a clean architecture, etc. I haven't taken the time to test it yet, but it seems very promising. Has anyone here had previous experience with PulseAudio ?
For 3-layer HD-DVDs, Toshiba decided to use 17 GB layers instead of 15 for the sole purpose of obtaining the upper hand in capacity over the competing 50 GB Blu-ray discs. I agree that this is a bit laughable:)
In a
recent Slashdot article about an effort to write an open source
driver for Nvidia cards, people such as mgemmons were asking
"What is wrong with the proprietary driver?"
Well, what a perfect example you have there: Nvidia is actively trying
to hide serious bugs/limitations present in their drivers ! WTF !
This sort of vendor behavior is precisely one of the reasons
why some of us would like open source drivers.
This is likely to boost QEMU's popularity, the virtualizer accelerated by KVM.
An interesting coïncidence is that I released the very first version of
Qemudo on Jan 4th while being
totally unaware of the existence of KVM. Then three days later the KVM project
released their first version too, and I read about it on this
kerneltrap article.
I am thrilled at the idea of using KVM + QEMU + Qemudo together.
To put it simply, and to quote my README, Qemudo is "a Web interface to QEMU
offering a way for users to access and control multiple virtual machines
running on one or more remote physical machines." Qemudo makes use of two
important features in QEMU: native support of VNC, and copy-on-write disk images
for instantaneous VM creation. If you are interested go check out the website
(and download the tarball which contains more detailled doc).
</shameless-plug>
For short distances, feet is extremely useful. Most things that you eyeball are between 0 and 10 feet, which gives you 11 values without resulting to a decimal, which confuses people.
Dude, your Imperial system goes to 11 ! Our decimal system only goes up to 10:(
It is possible to use ftp.exe in such a way. I work in the ITsec field and have used this exploitation technique in the past (step 1: create foo.txt containing ftp commands to download malicious.exe, step 2: run ftp.exe @foo.txt, step 3: run malicious.exe).
I really have a hard time understanding your mindset. You refuse to believe in the seriousness of the vuln even when people give you an attack vector example. Please, why ?
Dear son, I told you a hundred times, but you never seem to remember. - Gb means Gigabit - GB means Gigabytes This Xbox model would come with a 120 GB disk, not 120 Gb.
I don't want to be "about to buy" something before I know definitively that it will work for my application. If Googling can help with that, what are the search terms please?
Let me give you a concrete example. 8 months ago I did my research, settled on the Atheros chipset, decided to buy an SMC card because newegg had plenty of them, in particular their PCI model SMCWPCI-G. At this point I was about to buy it, so I googled for '''SMCWPCI-G linux problems''', '''SMCWPCI-G linux "not detected"''', '''SMCWPCI-G linux "does not work"''' (in other words, the kind of research you would do IF the card wouldn't work for you). And it quickly became clear to me that no major problems were reported with it, so I bought it.
I don't know why people don't do such simple searches before buying, it is so effective to stay away from potentially problematic devices...
But you can use this list of Atheros-based adapters. I used it 8 months ago to buy an SMCWPCI-G card for about $20, and I ended up with a perfectly working card under Linux.
Buy one of every device in the store, and hope to find one that has your chipset? We actually did this once. Found one that was Prysm2. Bought the rest. Some turned out to be Broadcom.
Yes, unfortunately sometimes vendors silently change the chipset used in a particular model. But honestly I think that googling for 10 min before buying is all you need to confirm that you won't run into this pb for the model you are about to buy.
"Usually" == "Never" in this case.
No, this is not true. Look, 6 months ago I was looking for a well-supported PCI wifi adapter. So I basically followed the exact steps I described in my GP post, and I decided to buy one using the Atheros chipset. It turns out that the driver developers (madwifi project) have a very complete list of adapters using this chipset, and therefore fully-supported under Linux. The list literally references 100-200 adapters, 50% of them are probably not sold anymore, but the other 50% are currently sold on the market.
Say I want an 802.11g PCI card that works with Ubuntu 6.06 on an ASUS motherboard.
Just buy an Atheros one. It will work with any modern Linux distro. The exact distro or motherboard you use doesn't matter. Most distros have packaged the Atheros kernel modules. And as I understand it Atheros use a unified architecture, so the latest driver will always support all Atheros chipsets.
Trying to get an exhaustive list of all WLAN adapters supported under Linux is the wrong way to approach the pb because there are literally hundreds of them on the market. However they are all based on only a dozen or so of common WLAN chipsets: Zydas ZD12xx, Atheros, Intel PRO/Wireless 2xxx, etc. It's easier to assemble a list of supported chipsets rather than a list of supported adapters.
Firstly, you can have a look at the drivers/net/wireless directory of the kernel source code. From there look at the Kconfig file (compilation options) where every WLAN chipset natively supported by the kernel is succinctly described, and pointers to additional details about the drivers are often provided: READMEs, URLs...
Secondly, some WLAN chipsets are not natively supported by the kernel, but instead by third party drivers from independent open-source projects (most of them will be integrated into the kernel in the near future). So check out this webpage for example (the interesting section is "The devices, the drivers - 802.11+, 802.11a, 802.11g"), it has been written by Jean Tourrilhes who got involved as a developer with early work on the Wireless framework in Linux. He wrote this page specifically to gather info about all the existing WLAN drivers in a central place. It contains info about third party drivers as well as drivers natively supported by the kernel. The page is slightly outdated though, so check out this wikipedia article about open source wireless drivers for a complement.
Thirdly, other WLAN chipsets are supported by proprietary drivers only, I recommend you stay away from them.
At this point, personally, I like to take decisions about hardware purchases "from the bottom up". In other words, I decide which one of the WLAN chipsets I would like my adapter to be based on (since it determines the major features of the device), and then I search for adapters using it. Usually the website of the driver maintainer, or the mailing list of the driver project, or the driver documentation are good places to look for list of adapters based on particular chipsets.
People who argue that piping a single file via cat is the best method are wrong. The following method has all of the advantages you cite, but is also shorter to type, uses less system resources (no cat process, no pipe(2) object), and doesn't require you to "rething the input method" in case you want to change the grep command:
$ <file.txt grep foobar
Few people know that input-redirection can be established before the command name:)
However, regarding 10G ethernet adapters, does anyone know when vendors will start making use of PCIe x8 or x16 for them ? In all those Internet2 benchmarks papers, everybody complains about PCI-X beeing too slow, but PCIe x8 or x16 would be perfect for 10G.
The odds also depend on time.
Because as with every vulnerability, it only get worse over time: more bad guys become aware of how to exploit it, methods of exploitation become more reliable, etc.
You may not realize it, but as of today, virtually all new applications being developed re-use existing working software systems. For example, when you develop a new web application, the components that you re-use are: the OS, HTTP server, database server, scripting language (PHP...), etc. Of course nobody is re-developing everything from scratch. Very often only the higher level software layer (ie. your application) is developed partially or mostly from scratch, but everything else (ie. the internal or lower level components) are re-used from existing projects.
The Internet is all about sharing information.
Yet, they chose to make it difficult for people to share and access it.
Gosh, I hate this nytimes.com login form.
Here is a direct link to
the article (no login required).
So the quote that was usually translated in French to "C'est un petit pas pour l'Homme, mais un bond de géant pour l'humanité" now becomes "C'est un petit pas pour un homme, mais un bond de géant pour l'humanité."
It turns out that Firefox leads the pack with 47 vulnerabilities,
compared to 38 for Internet Explorer.
Totally. Pointless. Comparison.
First, as the Slashdot posting correctly points out, the window
of vulnerability is much larger with IE. Microsoft is known for
taking months to fix some vulns, and is taking longer and longer over the years.
Second, what about the importance of these vulns ? Was
it 47 minor DoS for Firefox and 38 critical arbitrary code execution
vulns for IE ?
Third, what about the methodology used to gather the vuln
counts ? The report always says "Source: Symantec Corporation", with
no more information.
Did they count Firefox security related bugs or security advisories ?
Did they count 1 Microsoft patch fixing N vulns as 1 or N vulns
(too many studies make this mistake) ?
Fourth, what about silently fixed vulns in IE ?
Microsoft is known for
secretly fixing vulns that are discovered internally,
and of course they never talk about them in public.
Symantec certainly did not count these.
There are just too many reasons making virtually all studies comparing
the number of security patches between 2 products useless. This
one is no exception.
Slashdot Mirror
It doesn't matter what Intel chooses to call it (they have changed their mind 3 times: IA-32e, EM64T, Intel64). The fact is, Intel cloned the AMD64 architecture. AMD wrote the architecture specs and they gave it the name AMD64. When you install NetBSD or OpenBSD on a 64-bit Intel processor, you install NetBSD/amd64 or OpenBSD/amd64, these guys adopted the proper architecture name.
Other vendors use other names, Microsoft and Sun use x64, some use x86-64. Should you use these names ? No. Just stick to the official arch name, AMD64. When AMD cloned the IA32 (aka i386) architecture, AMD processors were (properly) recognized as being IA32 or i386 processors, so let's do the same for this generation of processors and use the proper name: AMD64.
There are 2 ways to get a 32-bit Java plugin running under a Linux/AMD64 environment (BTW, AMD64 is the official arch name implemented by AMD and Intel, x86-64 has been officially abandonned):
Of course, since Sun has open sourced Java, a 64-bit Java plugin is likely to appear soon.
I have recently spent a lot of time researching network-transparent audio transport applications so that I can, for example, walk around my apartment with a wireless Linux laptop while it is outputting sound to big speakers in the room (over wifi to a Linux media server connected to an audio receiver).
I have come across JACK and a dozens other apps, but it seems that PulseAudio is by far the most advanced and the cleanest implementation out there. It is multi-platform, it comes with dozens of plugins (alsa, oss, esound, etc) for max compatibility with existings apps, it is a clean architecture, etc. I haven't taken the time to test it yet, but it seems very promising. Has anyone here had previous experience with PulseAudio ?
1 layer = 15 GB
:)
2 layers = 30 GB = 2 x 15 GB/layer
3 layers = 51 GB = 3 x 17 GB/layer
For 3-layer HD-DVDs, Toshiba decided to use 17 GB layers instead of 15 for the sole purpose of obtaining the upper hand in capacity over the competing 50 GB Blu-ray discs. I agree that this is a bit laughable
In a recent Slashdot article about an effort to write an open source driver for Nvidia cards, people such as mgemmons were asking "What is wrong with the proprietary driver?" Well, what a perfect example you have there: Nvidia is actively trying to hide serious bugs/limitations present in their drivers ! WTF ! This sort of vendor behavior is precisely one of the reasons why some of us would like open source drivers.
This is likely to boost QEMU's popularity, the virtualizer accelerated by KVM. An interesting coïncidence is that I released the very first version of Qemudo on Jan 4th while being totally unaware of the existence of KVM. Then three days later the KVM project released their first version too, and I read about it on this kerneltrap article.
I am thrilled at the idea of using KVM + QEMU + Qemudo together. To put it simply, and to quote my README, Qemudo is "a Web interface to QEMU offering a way for users to access and control multiple virtual machines running on one or more remote physical machines." Qemudo makes use of two important features in QEMU: native support of VNC, and copy-on-write disk images for instantaneous VM creation. If you are interested go check out the website (and download the tarball which contains more detailled doc). </shameless-plug>
No way. Real ducks would have built better software.
Dude, your Imperial system goes to 11 ! Our decimal system only goes up to 10 :(
I really have a hard time understanding your mindset. You refuse to believe in the seriousness of the vuln even when people give you an attack vector example. Please, why ?
Let me give you a concrete example. 8 months ago I did my research, settled on the Atheros chipset, decided to buy an SMC card because newegg had plenty of them, in particular their PCI model SMCWPCI-G. At this point I was about to buy it, so I googled for '''SMCWPCI-G linux problems''', '''SMCWPCI-G linux "not detected"''', '''SMCWPCI-G linux "does not work"''' (in other words, the kind of research you would do IF the card wouldn't work for you). And it quickly became clear to me that no major problems were reported with it, so I bought it. I don't know why people don't do such simple searches before buying, it is so effective to stay away from potentially problematic devices...
But you can use this list of Atheros-based adapters. I used it 8 months ago to buy an SMCWPCI-G card for about $20, and I ended up with a perfectly working card under Linux.
Yes, unfortunately sometimes vendors silently change the chipset used in a particular model. But honestly I think that googling for 10 min before buying is all you need to confirm that you won't run into this pb for the model you are about to buy.
No, this is not true. Look, 6 months ago I was looking for a well-supported PCI wifi adapter. So I basically followed the exact steps I described in my GP post, and I decided to buy one using the Atheros chipset. It turns out that the driver developers (madwifi project) have a very complete list of adapters using this chipset, and therefore fully-supported under Linux. The list literally references 100-200 adapters, 50% of them are probably not sold anymore, but the other 50% are currently sold on the market.
Just buy an Atheros one. It will work with any modern Linux distro. The exact distro or motherboard you use doesn't matter. Most distros have packaged the Atheros kernel modules. And as I understand it Atheros use a unified architecture, so the latest driver will always support all Atheros chipsets.
Trying to get an exhaustive list of all WLAN adapters supported under Linux is the wrong way to approach the pb because there are literally hundreds of them on the market. However they are all based on only a dozen or so of common WLAN chipsets: Zydas ZD12xx, Atheros, Intel PRO/Wireless 2xxx, etc. It's easier to assemble a list of supported chipsets rather than a list of supported adapters.
Firstly, you can have a look at the drivers/net/wireless directory of the kernel source code. From there look at the Kconfig file (compilation options) where every WLAN chipset natively supported by the kernel is succinctly described, and pointers to additional details about the drivers are often provided: READMEs, URLs...
Secondly, some WLAN chipsets are not natively supported by the kernel, but instead by third party drivers from independent open-source projects (most of them will be integrated into the kernel in the near future). So check out this webpage for example (the interesting section is "The devices, the drivers - 802.11+, 802.11a, 802.11g"), it has been written by Jean Tourrilhes who got involved as a developer with early work on the Wireless framework in Linux. He wrote this page specifically to gather info about all the existing WLAN drivers in a central place. It contains info about third party drivers as well as drivers natively supported by the kernel. The page is slightly outdated though, so check out this wikipedia article about open source wireless drivers for a complement.
Thirdly, other WLAN chipsets are supported by proprietary drivers only, I recommend you stay away from them.
At this point, personally, I like to take decisions about hardware purchases "from the bottom up". In other words, I decide which one of the WLAN chipsets I would like my adapter to be based on (since it determines the major features of the device), and then I search for adapters using it. Usually the website of the driver maintainer, or the mailing list of the driver project, or the driver documentation are good places to look for list of adapters based on particular chipsets.
People who argue that piping a single file via cat is the best method are wrong. The following method has all of the advantages you cite, but is also shorter to type, uses less system resources (no cat process, no pipe(2) object), and doesn't require you to "rething the input method" in case you want to change the grep command:
:)
$ <file.txt grep foobar
Few people know that input-redirection can be established before the command name
Wow, thanks for the info. I had never read about the release of this 10G PCIe NIC !
You are right. Here are some numbers for the curious, nothing comes close to 100 Gbit/s:
PCIe x16 (2.5 Gbit/s per lane, 8B/10B encoding): 32.0 Gbit/s bidirectional (64.0 Gbit/s of aggregated bandwidth)
PCIe x8 (2.5 Gbit/s per lane, 8B/10B encoding): 16.0 Gbit/s bidirectional (32.0 Gbit/s of aggregated bandwidth)
PCIe x4 (2.5 Gbit/s per lane, 8B/10B encoding): 8.0 Gbit/s bidirectional (16.0 Gbit/s of aggregated bandwidth)
PCIe x1 (2.5 Gbit/s per lane, 8B/10B encoding): 2.0 Gbit/s bidirectional (4.0 Gbit/s of aggregated bandwidth)
PCI-X 2.0, 533 MHz, 64-bit: 34.13 Gbit/s
PCI-X 2.0, 266 MHz, 64-bit: 17.07 Gbit/s
PCI-X, 133 MHz, 64-bit: 8.53 Gbit/s
PCI, 66 MHz, 64-bit: 4.27 Gbit/s
PCI, 66 MHz, 32-bit: 2.13 Gbit/s
PCI, 33 MHz, 32-bit: 1.06 Gbit/s
However, regarding 10G ethernet adapters, does anyone know when vendors will start making use of PCIe x8 or x16 for them ? In all those Internet2 benchmarks papers, everybody complains about PCI-X beeing too slow, but PCIe x8 or x16 would be perfect for 10G.
The odds also depend on time. Because as with every vulnerability, it only get worse over time: more bad guys become aware of how to exploit it, methods of exploitation become more reliable, etc.
You may not realize it, but as of today, virtually all new applications being developed re-use existing working software systems. For example, when you develop a new web application, the components that you re-use are: the OS, HTTP server, database server, scripting language (PHP...), etc. Of course nobody is re-developing everything from scratch. Very often only the higher level software layer (ie. your application) is developed partially or mostly from scratch, but everything else (ie. the internal or lower level components) are re-used from existing projects.
The Internet is all about sharing information. Yet, they chose to make it difficult for people to share and access it. Gosh, I hate this nytimes.com login form. Here is a direct link to the article (no login required).
Slashdot needs a mod option: +1, Whatever.
So the quote that was usually translated in French to "C'est un petit pas pour l'Homme, mais un bond de géant pour l'humanité" now becomes "C'est un petit pas pour un homme, mais un bond de géant pour l'humanité."
This is obviously a bug in the Matrix.
(Here what I was about to post, but you pretty much summed up my viewpoint. Before all, here is a direct link to this Symantec Internet Security Threat Report -- Volume X: September 2006 that is talked about.)
Totally. Pointless. Comparison.
First, as the Slashdot posting correctly points out, the window of vulnerability is much larger with IE. Microsoft is known for taking months to fix some vulns, and is taking longer and longer over the years.
Second, what about the importance of these vulns ? Was it 47 minor DoS for Firefox and 38 critical arbitrary code execution vulns for IE ?
Third, what about the methodology used to gather the vuln counts ? The report always says "Source: Symantec Corporation", with no more information. Did they count Firefox security related bugs or security advisories ? Did they count 1 Microsoft patch fixing N vulns as 1 or N vulns (too many studies make this mistake) ?
Fourth, what about silently fixed vulns in IE ? Microsoft is known for secretly fixing vulns that are discovered internally, and of course they never talk about them in public. Symantec certainly did not count these.
There are just too many reasons making virtually all studies comparing the number of security patches between 2 products useless. This one is no exception.