Oh well. I'm in that 1%, so it's useful to me. Dell alone is selling some 4000 240xFPW monitors a week, that alone comes pretty close to 1% of the total PCs sold. That doesn't include the 30" that dell and apple sell, nor any other 1920x1200 resolution monitors from other manufacturers.
But ok, let's just assume it's 1% of the market. I don't know of any major company that wouldn't be willing to dedicate a couple programmers (if that) for a few weeks to possibly increase their sales by 1% (probably MUCH more with the PR of being known as the fastest/best).
It has had a limited version of window scaling for a long time. It wasn't until version 2.6.17 that they actually started to implement a more robust solution, which caused the above problems as posted on KernelTrap. The problem is in the way they "cap" the window scaling in prior versions. I believe even in 2.6.18 and beyond, the window scaling option is still capped, but now it's capped at 6. Of course this all stems from the fact that the TCP stack limits the amount of memory it'll allocate to a maximum of 1/128th of the available memory. For a 512MB system, that means 4MB maximum will be allocated (which is the default maximum), and since the window scale must be no more than 1/2 of the receive buffers, 2MB is the maximum window size (2^6*(64k-1)), which corresponds to a window scale of 6.
Ok, just to be fair. You can also download the latest linux betas, go through the TCP network stack, change the source to remove the memory limitation checks or modify the formulas, recompile your kernel (and hope nothing else breaks), and you'll have the same effect as windows by default. Then after that, you can make a few changes to a configuration file (Pretty much the same numbers you need for the windows registry), and you're good to go.
Linux doesn't yet support some of the more advanced features of TCP/IP. At that rate, I'm guessing that you are having a problem with the ACK window being too small (Forcing the sender to stop sending). The original 64k ack window is woefully small over either high latency links, or over high bandwidth links (Your situation being the later). I think they are working on adding it to the 2.6.17 or 2.6.18 linux kernel, but it's still very buggy. You may need a TOE capable card that can also do the ack window scaling options of TCP. No sure if the one you mentioned does or not.
I had a perfectly working HTPC. Hauppage TV Tuner, and Beyond TV worked great. Then my cable company (BASTARDS!) decided to move my most watched tv channel (Sci-Fi) from analog to digital-only. Yeah, there were ways around it, like getting a cable box, and feeding the signal to the line in of the hauppage, running infrared cable channel changers (Which always seem to be unreliable), etc. Add to that the hauppage tuner is SD only, and I've gotten spoiled by HD content when possible it was evident that an upgrade was necessary.
But the available options sucked. There are no HD TV tuners that can take a feed from my cable provider. There are some workarounds, but they all blow. Grabbing feeds from my cablebox via firewire was promising until again, my cable provider started to broadcast a good number of my favorate shows with the CP-flag bit set. Then I get nothing over firewire. Ugh. Which meant that ok, for some shows I can still use the hauppage for getting analog cable signals. For digital channels, I have to grab it via firewire from the cable box. Unless of course, the content is CP-flag bit set, then I need to grab it via the analog outputs from the cablebox.
I finally gave up, and got the PVR from comcast. True, it *BLOWS* in comparision. Has 1/10th the storage my HTPC did, and my HTPC converted the MPEG-2 streams to MPEG-4 (DivX or WMV actually), losing almost no quality for a fraction of the space. It was easier to skip around in the show (And marked commercials). The EPG was infinately better. I could stream it to my other computer in the house. Before all this happened I was close to getting a solution to stream it to my Big Screen TV via the X-Box as well. That way my wife can watch her futurama on her computer, I can watch Sci-Fi on mine, and my son can watch Blues Clues (Or I could rip *my* DVD's and let him watch them while keeping the DVD's safe from... Peanut Butter, Frisbee Testing, etc that they seem to go through with my son in the house).
It isn't that we can't technically do it. I blame the cable companies for dragging their feet with cable card implementations as the reason my HTPC went the way of the dinosaur.
As for convergance failing, I blame:
Big Screens with high resolutions (1080p+) costing too much. You can't effectively use a TV for a monitor until it has decent resolution, interleaving doesn't count, and 780p has as much resolution as the monitor I threw away 12+ years ago. But for me, convergance is still present. I don't watch the Big Screen TV EVER. I run my PVR directly to my 24" Dell Widescreen LCD, and watch TV on it. If I knew it'd work as well as it does, I would have opted for the 30". But that was beyond my pain threshold to see if I'd like it enough as both my TV and monitor at the time. But I'll definately get something similiar or bigger if available next purchase (Or as soon as I can figure out a way to put my current monitor to some other use).
Yes, you can. Just look for an iSCSI PCIe card. It's basically an ethernet card that looks like a standard ethernet card and disk controller (Most are SCSI controllers, although there is no reason they couldn't make it look like an ATA controller, but you'd lose a lot of features).
PeterK is an idiot. He can't even summarize key points well. Here's the relevant quote from the article:
I believe '2' is a good number. '4' will be an interesting number for the high-end. Will we see eight cores in the client in the next two years? If someone chooses to do that, engineering-wise that is possible. But I doubt this is something the market needs.
Ok, now that's probably accurate. Will we ever need 8 cores? Sure. In the next two years? Probably not, and definately not mainstream.
If I had points, I'd mod your post up. Very informative.
In addition, I can't more agree with what you've said. Unlike most posters, it appears you've actually done some research before you speak.
It was probably the bad memory that caused the WGA to fail. Large memory increase/decrease (Like losing 1GB of RAM), is one of the triggers to check if reactivation is required.
My bad, I meant MySQL 3.x not PHP 3.x. A lot of web hosting providers STILL haven't moved to MySQL 4.x yet.
A large number of hosting providers also don't give you access to PEAR either. If you want it, you have to go and get it yourself. As for C and C++ supporting parameterized queries, that's a different argument. Neither of those are really a web framework, and neither of those include database support at all in the core. However, on the windows platform, ODBC is the standard and most accessable way of accessing databases from those languages, and as such is what is most commonly used, and most likely the way a beginner would use. In addition, many (All 2 of the ones I've worked on) projects out there don't use PEAR, and they have their own database abstraction layer, which is something the other frameworks don't need. Most of the big frameworks have a default database implementation that abstracts atleast some of the differences between different database backends, or atleast implement APIs that are similiar (although maybe different classes) for different backends, which PHP doesn't.
The most common scenario for PHP with a database is accessing MySQL 3.x, and on a shared hosting provider. And in that scenario, PHP does not allow parameterized queries. Yes, you can use someone's database abstraction layer to emulate that functionality for you, but then again the same thing could be said about ANY language. It's a workaround to add a feature that other web frameworks don't suffer from.
ASP.NET supports parameterized queries to SQL Server, which is it's most common database backend (It also supports it for MySQL including 3.x versions, Oracle, and any ADO/ODBC database).
I do believe java has support natively as well.
To be quite honest, I would love to see the baseline PEAR packages moved over to the PHP core. But even that won't solve the problem today in trying to help beginners not make insecure web applications. And you can still circumvent the parameterized query API calls by doing string concatenation for your queries, but that's a different subject.
Why can't you write your own device drivers anymore? Nothing stopping you. You can't rebuild your linux kernel without turning on the PC, so? I see tons of benchmarks being published everyday. Granted, there are a few licenses that don't allow this, mostly beta products, and only then because they probably are representative of the final product. I can't take a legally purchased linux binary and run it on windows. When hard drives are like $40 for a 200GB drive, cry me a river that windows takes up 1.5GB of disk space. I can't get have my money back that I spent on paying for an internet connection I needed to download linux either. I can't have days added back to my life span for having to waste my time fixing linux bugs or trying to find drivers for hardware that just gets recognized by windows.
Not like this has anything at all to do with the article.
While I agree PEAR is a good way to prevent such attacks, your statement "PHP supports parameterized SQL just as well as any other language I've worked with" is a bit misleading. PEAR is not part of PHP, it's a class library that runs on top of the PHP framework. As such, the mysql interface class (The one that supports PHP 3.x), does NOT have parameterized queries at all.
That is not FUD, it's the truth, and yes, there are workarounds, and fixes, but that's still a big hole unless you use the magic_quotes_runtime, which causes it's own issues.
I couldn't figure out how a 5.7% growth is a "decline" until my wife walked in and told me how much money she saved me at the store because she bought all this stuff 50% off that we didn't need.
I'll conceed that there are benefits to Hypertransport over Intel's FSB technology. Even Intel itself is planning on implementing some of the same types of technology down the road (Although the current plan is to not use HT).
However, the FSB/non-integrated memory controller does afford Intel the flexability to quickly change whole processor families to being able to support different memory technologies (RAMBUS/SDR/DDR/DDR2/?). They only change the northbridge, and the whole processor line is good to go. Looking back, it may have been a good thing (or bad) considering they were using Rambus and needed to quickly switch to DDR/DDR2.
In large servers however, you won't find the issues that you mentioned. Each processor can/will have it's own memory bus. It's only at the low end servers that you see memory busses being shared, and even then only on cheap server board implementations. Cheap dual-processor servers is probably the largest market sharewise in the server space, so being able to build cheap dual (and quad) processor machines is a fairly big deal, and something AMD currently has an advantage in. Step up to 8x, 16x, and 32x processor machines however (where prices generally tend to skyrocket), and you'll see Intel Servers with memory busses for each processor, multiple northbridges (or what would be similiar to a northbridge). Because of this, at the high end, AMD's performance advantage because of hypertransport is negligable (again).
I'm not arguing that Intel's method is better, because it really isn't. But it's not as bad as many seem to think when they don't look beyond the entry level server area. Intel never said (I don't believe they did) that integrated memory controllers were a bad idea, nor would better interconnect be beneficial. They said that it wasn't yet time, and they prioritized other things higher. So far, I'd have to agree with that. I haven't seen any overwhelming reason to have had an integrated memory controller or hypertransport in the past few years. The time may very well be approaching when we do need it, but we didn't need it when AMD delivered it. So long as Intel does deliver it before I need it, I'm good with that.
Yeah, I averaged 109mi/hr from Chicago to San Diego. Probably would have averaged more, but I had a discussion with a Texas Ranger for about 20 minutes.
NUMA isn't a hypertransport technology. There are many Intel multi-processor machines that have NUMA and multiple banks of memory. Even the old Data General P2 server we had used NUMA.
It's hard drive speed in that scenario. Double click your icon, and watch your CPU usage. It doesn't hit the CPU that hard at all. Your hard disk light is probably on non-stop. Try opening firefox. Wait until it completely loads. Close firefox. Now open firefox again. Now it should have loaded almost instantly (If you have enough RAM). Once the data is in windows disk cache, most applications load instantly (There are exceptions, like games that pre-render some graphics, or uncompress textures and load them into the video card, etc).
Uh, yeah. Tell that to the 32 processor machine sitting next to me that it needs to run linux. It seems to be running windows just fine;-)
Windows was running on 32-way servers before linux was even a thought.
That's not really how "optimized" code for multiprocessing works. A lot of today's processes do most of their processing in one thread. Once programmers get in the habit of breaking up the computational portion of their code into multiple pieces, it's easy. You don't have to "optimize" for a dual core, or quad code. You break your processing up into many pieces/threads and then it will use that many (or less) cores. For todays applications, you can use a thread pool. You basically then tell the processor I want thread to do a, and a thread to do b, another to do c, etc. The machine then spins up (normally) 2 or more threads per core. As each processes completes on a thread, it then pulls the next process in the thread pool and executes it. If you can break your processing up into many small pieces (Anything more than 8 will do, but it's not that difficult to break most complex processing to a hundred or more "tasks"). The thread pool (or OS if you just want to run a hundred threads) will then execute them as efficiently as possible.
Those of us who have been writing server software have had a lot of experience in this, and a lot of the projects that I have written scale very well from a single core processor all the way to a 64 core machine (That's the biggest machine I've tested with, I see no reason why it wouldn't scale on bigger machines).
I can think of one excellent application right now. Fresh meat. No longer do they have to process the meat in some plant then ship it off. Now they ship the frozen pig/chicken/fish right to the grocery store.
Actually, NTFS streams were pretty well discussed when they came out back in 1994. They have been there since Windows NT 3.1. They are similiar to the old macintosh's data and resource forks, and I believe Microsoft implemented it so that they could support Macintosh files when acting as a file server (or perhaps they were considering building a Macintosh compatability box on top of the NT kernel).
I was actually suprised that Microsoft didn't take advantage of streams more often than they do. It would be a nice place to have put file meta-data (Like MP3 tags, creator, summary, etc), or image thumbnails (instead of thumbs.db). They probably wanted to support FAT32, and Windows 9x which is why they didn't.
It's hardly a backdoor, it was a pretty big deal and a feature Microsoft made a pretty big deal of when it arrived. NTFS also supports another hardly used feature known as sparse files where you can allocate space within a file that doesn't actually take any disk space. Useful for some record/database applications. It also supports junction points as well, allowing you to map a drive into a folder (Similiar to linux's symbolic links).
Not to get off topic, but there are many reason why NSF and ANSI 837 can support multiple ID's, like:
A) Coordination of Benefits. Depending on who you are sending the claim to, if the insured has multiple insurance plans, one insurance companies pay out may differ depending on what the other insurance payouts are. In some cases a primary insurance plan may need to forward the claim to a secondary or tertiary insurance company that uses a different ID.
B) Better insured matching. If you supply an insured's medicare id, employee id, social security number (Not supposed to do that, but it's rampant), EIN, etc. Then if you can't find the patient/insured via one ID, then you may be able to find them via the other IDs. This helps to reduce the claim processing time, as the claim doesn't need to be rejected.
C) Claim clearinghouses. In cases where you are submitting a claim to multiple insurance companies (Primary, secondary, tertiary, etc), the insured/patient information can be contained in a single instance, and the insurance companies to receive the claim can reference the single instance with multiple ID's. Each insurance company can then pull whichever ID they use internally to identify the insured/patient.
Perhaps you just like saying things without really understanding what it is you said, but...
Windows has a kernel, and IE, GUI, command shell, filesystem browser, etc aren't part of it. Infact the Win32 API isn't even part of it. If you weren't aware, the windows kernel even has 2 other subsystems shipped for it (Posix, OS/2 1.1). Feel free to google to learn more.
Slashdot Mirror
It has small red lines in float 0, and red boxes in height 3. All others pass.
Oh well. I'm in that 1%, so it's useful to me. Dell alone is selling some 4000 240xFPW monitors a week, that alone comes pretty close to 1% of the total PCs sold. That doesn't include the 30" that dell and apple sell, nor any other 1920x1200 resolution monitors from other manufacturers.
But ok, let's just assume it's 1% of the market. I don't know of any major company that wouldn't be willing to dedicate a couple programmers (if that) for a few weeks to possibly increase their sales by 1% (probably MUCH more with the PR of being known as the fastest/best).
It has had a limited version of window scaling for a long time. It wasn't until version 2.6.17 that they actually started to implement a more robust solution, which caused the above problems as posted on KernelTrap. The problem is in the way they "cap" the window scaling in prior versions. I believe even in 2.6.18 and beyond, the window scaling option is still capped, but now it's capped at 6. Of course this all stems from the fact that the TCP stack limits the amount of memory it'll allocate to a maximum of 1/128th of the available memory. For a 512MB system, that means 4MB maximum will be allocated (which is the default maximum), and since the window scale must be no more than 1/2 of the receive buffers, 2MB is the maximum window size (2^6*(64k-1)), which corresponds to a window scale of 6.
Ok, just to be fair. You can also download the latest linux betas, go through the TCP network stack, change the source to remove the memory limitation checks or modify the formulas, recompile your kernel (and hope nothing else breaks), and you'll have the same effect as windows by default. Then after that, you can make a few changes to a configuration file (Pretty much the same numbers you need for the windows registry), and you're good to go.
Use windows and enable the advanced TCP options.
Linux doesn't yet support some of the more advanced features of TCP/IP. At that rate, I'm guessing that you are having a problem with the ACK window being too small (Forcing the sender to stop sending). The original 64k ack window is woefully small over either high latency links, or over high bandwidth links (Your situation being the later). I think they are working on adding it to the 2.6.17 or 2.6.18 linux kernel, but it's still very buggy. You may need a TOE capable card that can also do the ack window scaling options of TCP. No sure if the one you mentioned does or not.
google "ACK window scaling" for more information.
I had a perfectly working HTPC. Hauppage TV Tuner, and Beyond TV worked great. Then my cable company (BASTARDS!) decided to move my most watched tv channel (Sci-Fi) from analog to digital-only. Yeah, there were ways around it, like getting a cable box, and feeding the signal to the line in of the hauppage, running infrared cable channel changers (Which always seem to be unreliable), etc. Add to that the hauppage tuner is SD only, and I've gotten spoiled by HD content when possible it was evident that an upgrade was necessary. But the available options sucked. There are no HD TV tuners that can take a feed from my cable provider. There are some workarounds, but they all blow. Grabbing feeds from my cablebox via firewire was promising until again, my cable provider started to broadcast a good number of my favorate shows with the CP-flag bit set. Then I get nothing over firewire. Ugh. Which meant that ok, for some shows I can still use the hauppage for getting analog cable signals. For digital channels, I have to grab it via firewire from the cable box. Unless of course, the content is CP-flag bit set, then I need to grab it via the analog outputs from the cablebox. I finally gave up, and got the PVR from comcast. True, it *BLOWS* in comparision. Has 1/10th the storage my HTPC did, and my HTPC converted the MPEG-2 streams to MPEG-4 (DivX or WMV actually), losing almost no quality for a fraction of the space. It was easier to skip around in the show (And marked commercials). The EPG was infinately better. I could stream it to my other computer in the house. Before all this happened I was close to getting a solution to stream it to my Big Screen TV via the X-Box as well. That way my wife can watch her futurama on her computer, I can watch Sci-Fi on mine, and my son can watch Blues Clues (Or I could rip *my* DVD's and let him watch them while keeping the DVD's safe from... Peanut Butter, Frisbee Testing, etc that they seem to go through with my son in the house). It isn't that we can't technically do it. I blame the cable companies for dragging their feet with cable card implementations as the reason my HTPC went the way of the dinosaur. As for convergance failing, I blame: Big Screens with high resolutions (1080p+) costing too much. You can't effectively use a TV for a monitor until it has decent resolution, interleaving doesn't count, and 780p has as much resolution as the monitor I threw away 12+ years ago. But for me, convergance is still present. I don't watch the Big Screen TV EVER. I run my PVR directly to my 24" Dell Widescreen LCD, and watch TV on it. If I knew it'd work as well as it does, I would have opted for the 30". But that was beyond my pain threshold to see if I'd like it enough as both my TV and monitor at the time. But I'll definately get something similiar or bigger if available next purchase (Or as soon as I can figure out a way to put my current monitor to some other use).
Yes, you can. Just look for an iSCSI PCIe card. It's basically an ethernet card that looks like a standard ethernet card and disk controller (Most are SCSI controllers, although there is no reason they couldn't make it look like an ATA controller, but you'd lose a lot of features).
Ok, now that's probably accurate. Will we ever need 8 cores? Sure. In the next two years? Probably not, and definately not mainstream.
No, more people should take responsibility for their own actions.
Stop trying to pass the buck onto someone else.
If I had points, I'd mod your post up. Very informative. In addition, I can't more agree with what you've said. Unlike most posters, it appears you've actually done some research before you speak.
It was probably the bad memory that caused the WGA to fail. Large memory increase/decrease (Like losing 1GB of RAM), is one of the triggers to check if reactivation is required.
My bad, I meant MySQL 3.x not PHP 3.x. A lot of web hosting providers STILL haven't moved to MySQL 4.x yet.
A large number of hosting providers also don't give you access to PEAR either. If you want it, you have to go and get it yourself. As for C and C++ supporting parameterized queries, that's a different argument. Neither of those are really a web framework, and neither of those include database support at all in the core. However, on the windows platform, ODBC is the standard and most accessable way of accessing databases from those languages, and as such is what is most commonly used, and most likely the way a beginner would use. In addition, many (All 2 of the ones I've worked on) projects out there don't use PEAR, and they have their own database abstraction layer, which is something the other frameworks don't need. Most of the big frameworks have a default database implementation that abstracts atleast some of the differences between different database backends, or atleast implement APIs that are similiar (although maybe different classes) for different backends, which PHP doesn't.
The most common scenario for PHP with a database is accessing MySQL 3.x, and on a shared hosting provider. And in that scenario, PHP does not allow parameterized queries. Yes, you can use someone's database abstraction layer to emulate that functionality for you, but then again the same thing could be said about ANY language. It's a workaround to add a feature that other web frameworks don't suffer from.
ASP.NET supports parameterized queries to SQL Server, which is it's most common database backend (It also supports it for MySQL including 3.x versions, Oracle, and any ADO/ODBC database).
I do believe java has support natively as well.
To be quite honest, I would love to see the baseline PEAR packages moved over to the PHP core. But even that won't solve the problem today in trying to help beginners not make insecure web applications. And you can still circumvent the parameterized query API calls by doing string concatenation for your queries, but that's a different subject.
Why can't you write your own device drivers anymore? Nothing stopping you.
You can't rebuild your linux kernel without turning on the PC, so?
I see tons of benchmarks being published everyday. Granted, there are a few licenses that don't allow this, mostly beta products, and only then because they probably are representative of the final product.
I can't take a legally purchased linux binary and run it on windows.
When hard drives are like $40 for a 200GB drive, cry me a river that windows takes up 1.5GB of disk space.
I can't get have my money back that I spent on paying for an internet connection I needed to download linux either.
I can't have days added back to my life span for having to waste my time fixing linux bugs or trying to find drivers for hardware that just gets recognized by windows.
Not like this has anything at all to do with the article.
While I agree PEAR is a good way to prevent such attacks, your statement "PHP supports parameterized SQL just as well as any other language I've worked with" is a bit misleading. PEAR is not part of PHP, it's a class library that runs on top of the PHP framework. As such, the mysql interface class (The one that supports PHP 3.x), does NOT have parameterized queries at all.
That is not FUD, it's the truth, and yes, there are workarounds, and fixes, but that's still a big hole unless you use the magic_quotes_runtime, which causes it's own issues.
I couldn't figure out how a 5.7% growth is a "decline" until my wife walked in and told me how much money she saved me at the store because she bought all this stuff 50% off that we didn't need.
I'll conceed that there are benefits to Hypertransport over Intel's FSB technology. Even Intel itself is planning on implementing some of the same types of technology down the road (Although the current plan is to not use HT).
However, the FSB/non-integrated memory controller does afford Intel the flexability to quickly change whole processor families to being able to support different memory technologies (RAMBUS/SDR/DDR/DDR2/?). They only change the northbridge, and the whole processor line is good to go. Looking back, it may have been a good thing (or bad) considering they were using Rambus and needed to quickly switch to DDR/DDR2.
In large servers however, you won't find the issues that you mentioned. Each processor can/will have it's own memory bus. It's only at the low end servers that you see memory busses being shared, and even then only on cheap server board implementations. Cheap dual-processor servers is probably the largest market sharewise in the server space, so being able to build cheap dual (and quad) processor machines is a fairly big deal, and something AMD currently has an advantage in. Step up to 8x, 16x, and 32x processor machines however (where prices generally tend to skyrocket), and you'll see Intel Servers with memory busses for each processor, multiple northbridges (or what would be similiar to a northbridge). Because of this, at the high end, AMD's performance advantage because of hypertransport is negligable (again).
I'm not arguing that Intel's method is better, because it really isn't. But it's not as bad as many seem to think when they don't look beyond the entry level server area. Intel never said (I don't believe they did) that integrated memory controllers were a bad idea, nor would better interconnect be beneficial. They said that it wasn't yet time, and they prioritized other things higher. So far, I'd have to agree with that. I haven't seen any overwhelming reason to have had an integrated memory controller or hypertransport in the past few years. The time may very well be approaching when we do need it, but we didn't need it when AMD delivered it. So long as Intel does deliver it before I need it, I'm good with that.
Yeah, I averaged 109mi/hr from Chicago to San Diego. Probably would have averaged more, but I had a discussion with a Texas Ranger for about 20 minutes.
NUMA isn't a hypertransport technology. There are many Intel multi-processor machines that have NUMA and multiple banks of memory. Even the old Data General P2 server we had used NUMA.
It's hard drive speed in that scenario. Double click your icon, and watch your CPU usage. It doesn't hit the CPU that hard at all. Your hard disk light is probably on non-stop. Try opening firefox. Wait until it completely loads. Close firefox. Now open firefox again. Now it should have loaded almost instantly (If you have enough RAM). Once the data is in windows disk cache, most applications load instantly (There are exceptions, like games that pre-render some graphics, or uncompress textures and load them into the video card, etc).
Uh, yeah. Tell that to the 32 processor machine sitting next to me that it needs to run linux. It seems to be running windows just fine ;-)
Windows was running on 32-way servers before linux was even a thought.
That's not really how "optimized" code for multiprocessing works. A lot of today's processes do most of their processing in one thread. Once programmers get in the habit of breaking up the computational portion of their code into multiple pieces, it's easy. You don't have to "optimize" for a dual core, or quad code. You break your processing up into many pieces/threads and then it will use that many (or less) cores. For todays applications, you can use a thread pool. You basically then tell the processor I want thread to do a, and a thread to do b, another to do c, etc. The machine then spins up (normally) 2 or more threads per core. As each processes completes on a thread, it then pulls the next process in the thread pool and executes it. If you can break your processing up into many small pieces (Anything more than 8 will do, but it's not that difficult to break most complex processing to a hundred or more "tasks"). The thread pool (or OS if you just want to run a hundred threads) will then execute them as efficiently as possible.
Those of us who have been writing server software have had a lot of experience in this, and a lot of the projects that I have written scale very well from a single core processor all the way to a 64 core machine (That's the biggest machine I've tested with, I see no reason why it wouldn't scale on bigger machines).
I can think of one excellent application right now. Fresh meat. No longer do they have to process the meat in some plant then ship it off. Now they ship the frozen pig/chicken/fish right to the grocery store.
Actually, NTFS streams were pretty well discussed when they came out back in 1994. They have been there since Windows NT 3.1. They are similiar to the old macintosh's data and resource forks, and I believe Microsoft implemented it so that they could support Macintosh files when acting as a file server (or perhaps they were considering building a Macintosh compatability box on top of the NT kernel).
I was actually suprised that Microsoft didn't take advantage of streams more often than they do. It would be a nice place to have put file meta-data (Like MP3 tags, creator, summary, etc), or image thumbnails (instead of thumbs.db). They probably wanted to support FAT32, and Windows 9x which is why they didn't.
It's hardly a backdoor, it was a pretty big deal and a feature Microsoft made a pretty big deal of when it arrived. NTFS also supports another hardly used feature known as sparse files where you can allocate space within a file that doesn't actually take any disk space. Useful for some record/database applications. It also supports junction points as well, allowing you to map a drive into a folder (Similiar to linux's symbolic links).
Not to get off topic, but there are many reason why NSF and ANSI 837 can support multiple ID's, like: A) Coordination of Benefits. Depending on who you are sending the claim to, if the insured has multiple insurance plans, one insurance companies pay out may differ depending on what the other insurance payouts are. In some cases a primary insurance plan may need to forward the claim to a secondary or tertiary insurance company that uses a different ID. B) Better insured matching. If you supply an insured's medicare id, employee id, social security number (Not supposed to do that, but it's rampant), EIN, etc. Then if you can't find the patient/insured via one ID, then you may be able to find them via the other IDs. This helps to reduce the claim processing time, as the claim doesn't need to be rejected. C) Claim clearinghouses. In cases where you are submitting a claim to multiple insurance companies (Primary, secondary, tertiary, etc), the insured/patient information can be contained in a single instance, and the insurance companies to receive the claim can reference the single instance with multiple ID's. Each insurance company can then pull whichever ID they use internally to identify the insured/patient.
Easily, if you want to. I went from Downtown Chicago to San Diego (2400 miles) in 22 hours.
Perhaps you just like saying things without really understanding what it is you said, but...
Windows has a kernel, and IE, GUI, command shell, filesystem browser, etc aren't part of it. Infact the Win32 API isn't even part of it. If you weren't aware, the windows kernel even has 2 other subsystems shipped for it (Posix, OS/2 1.1). Feel free to google to learn more.