Equipment that can do better in hw is extremely expensive, and out of reach of much of the market.
It's kind of the other way around than expected. Small ISP's have no problems, a full-table-capable Juniper J-series is quite cheap and a Mikrotik RB1000 is $695. A full table in a software router just isn't a problem anymore.
Once you need a lot of packet forwarding capacity you'll need hardware forwarding, and then you can hit problems. It isn't THAT hard (or costly) to double the CAM table size though, as long as you don't do it faster than Moore's law. Routing table growth is almost linear, and the last doubling in size has taken 4 or 5 years.
The growth of the IPv6 table is more uncertain, of course. Right now it's extremely small.
It's fairly difficult to bungle traditional CPU-heavy loads. The kernel just needs to get out of the way and let userspace do whatever it wants to do. Try the same tests on Mac OS X and Windows (assuming they compile), and you'll see just about the same performance.
It doesn't take a long time just for the sake of taking a long time, it takes a long time to make sure everything is correct as it should be.
No, it takes a long time because BIOS programmers are the worst programmers in existence. For most of the boot sequence the machine just sits around doing nothing. Coreboot has shown how quickly it CAN be done.
Passing a message in a lockless ring buffer costs about as much as a function call
Only in the dreams of computer scientists. In reality, cache invalidates aren't free. Building an OS which is heavily dependent on inter-CPU communication through shared memory sounds rather short-sighted.
You are talking about worst case latency. Linux's best case latency (for e.g. system calls, context switches, reacting to interrupts) is somewhere between really good and fantastic, and so is the average case latency. The worst case latency is where QNX would likely win, and that's what matters for realtime.
Probably nothing nice about microkernels. Context switching is traditionally slow, so running everything in different contexts costs quite a bit of performance. Even if share all memory mappings between all "kernel-like" contexts so you avoid a traditional context switch, you're still stuck with a few extra non-predicted jumps, and at that point you have lost most of the benefit of microkernels.
I don't see customers ship back the SmartArray controllers.
There's no need to ship them back, especially the low end versions. The high end ones can't handle non-RAID-formatted disks, which is a bit of a pain, but they perform ok as long as you avoid using real RAID (anything that requires calculating parity.) So stick with RAID-1, and SmartArray is fine -- just have a spare controller or server around, because you can't switch controller vendor without losing your data.
but proven to be true (and thus justifiable in hindsight)
You are assuming that it is justifiable just because it is true. Different jurisdictions have different views on that, so it is certainly not a safe assumption.
Yes. 64 bit only gives you a performance boost if any one task needs more than four gigabytes of ram. Most applications on the desktop do not and will not for a while.
64-bit kernel gives you a performance boost (or lack of a performance loss, if you prefer) on 1GB and up. Sure, the applications can easily stay 32-bit, but you can't do the classic 32-bit userland 64-bit kernel if the CPU is 32-bit.
is that better than people looking at the packaging, notice it says no linux support, and sticking with Windows?
Yes. Saves them from buying the wrong thing. An unhappy ex-user is worse than a user who doesn't know about Linux in the first place.
Or a crash dump when things go wrong that firmly puts the blame on the faulting driver (in big letters).
There are a million ways things can go wrong and not result in a nice dump like that. It's only lately that PC's have acquired rudimentary I/O isolation, and it isn't used much yet. Even with that in place, it would be tricky and possibly performance-limiting to enforce isolation for all devices.
There may have been a driver problem years ago, but today the problem is pretty much limited to graphics. And DVB, but the competition is doing just as badly there. Overall, Linux driver support is more complete than at least that of Windows Vista.
That would make it easier to manage as the number of them increases.
One of the great advantages of Linux is that improvements can be implemented for lots of devices at once.
I guess a lot of manufacturers will release binary-only drivers, but even if they are buggy, that doesn't leave in any worse state than we are already - those manufacturers aren't releasing drivers for Linux in the first place.
It means people will look at the packaging, notice that it says Linux support, and then find out that it doesn't actually work, and will then blame Linux. Manufacturer-written drivers are fairly universally crap.
It's quite difficult to get decent performance from USB2, because the design of the host controller is such that the CPU needs to be involved in the transfer. If the CPU doesn't respond fast enough (perhaps because you're trying to do actual work with the machine), performance suffers. The problem is less with quad-core CPU's, since you can just dedicate a core to USB when doing transfers.
Firewire and SATA controllers can handle transfers pretty much on their own. Supposedly USB3 can do the same.
mp3 and other lossy formats have as their whole point removing the kind of information you want to add -- sound that can't be heard. Compression is still a hot research topic with both academic and industry interests. In contrast, steganography is much more obscure. For now, the compression beats steganography.
According to the article we're talking at best 15% less coal burned per unit electricity, with no way to scale beyond that. Great for the power plants where it is viable, but definitely niche. Doesn't change the fact that we should stop building coal fired plants and decommission the existing ones.
WOL is not all that useful in a heavily-virtualized data center. Besides, if you have 100.000 hosts in one network, it's probably a bad idea to run an unauthenticated protocol like WOL.
You can achieve the same by ssh'ing to the management port and turning the server on anyway.
Slashdot Mirror
(if they haven't already).
Around here a lot of 3G is done with NAT, as is (surprisingly) a lot of fiber to the home. DSL and cable customers still seem to get public addresses.
Network firewalls are fine and dandy, but they don't help you when your employees connect to a hot spot in an airport or through 3G/WiMax...
The time for them has pretty much come and gone, except for their ability to detect infected hosts on the inside trying to connect out.
Mobile phones don't need public IP addresses
Mobile phones were originally invented for peer-to-peer communication...
Equipment that can do better in hw is extremely expensive, and out of reach of much of the market.
It's kind of the other way around than expected. Small ISP's have no problems, a full-table-capable Juniper J-series is quite cheap and a Mikrotik RB1000 is $695. A full table in a software router just isn't a problem anymore.
Once you need a lot of packet forwarding capacity you'll need hardware forwarding, and then you can hit problems. It isn't THAT hard (or costly) to double the CAM table size though, as long as you don't do it faster than Moore's law. Routing table growth is almost linear, and the last doubling in size has taken 4 or 5 years.
The growth of the IPv6 table is more uncertain, of course. Right now it's extremely small.
The question I have is how much squinting at fine fonts I'd do at 1920x1200 on only 17" of screen
Perhaps you should consider an operating system where you can adjust font sizes... The better ones even do it automatically for you depending on DPI.
I suspect that the pulses accually serve a purpose.
It seems more likely that all nature can provide is a pulse, and so the rest of the body just had to deal with it.
If we're lucky the body can do without a pulse, and in either case, a heart without a pulse is likely better than no heart at all.
It's fairly difficult to bungle traditional CPU-heavy loads. The kernel just needs to get out of the way and let userspace do whatever it wants to do. Try the same tests on Mac OS X and Windows (assuming they compile), and you'll see just about the same performance.
It doesn't take a long time just for the sake of taking a long time, it takes a long time to make sure everything is correct as it should be.
No, it takes a long time because BIOS programmers are the worst programmers in existence. For most of the boot sequence the machine just sits around doing nothing. Coreboot has shown how quickly it CAN be done.
Passing a message in a lockless ring buffer costs about as much as a function call
Only in the dreams of computer scientists. In reality, cache invalidates aren't free. Building an OS which is heavily dependent on inter-CPU communication through shared memory sounds rather short-sighted.
You are talking about worst case latency. Linux's best case latency (for e.g. system calls, context switches, reacting to interrupts) is somewhere between really good and fantastic, and so is the average case latency. The worst case latency is where QNX would likely win, and that's what matters for realtime.
Probably nothing nice about microkernels. Context switching is traditionally slow, so running everything in different contexts costs quite a bit of performance. Even if share all memory mappings between all "kernel-like" contexts so you avoid a traditional context switch, you're still stuck with a few extra non-predicted jumps, and at that point you have lost most of the benefit of microkernels.
I don't see customers ship back the SmartArray controllers.
There's no need to ship them back, especially the low end versions. The high end ones can't handle non-RAID-formatted disks, which is a bit of a pain, but they perform ok as long as you avoid using real RAID (anything that requires calculating parity.) So stick with RAID-1, and SmartArray is fine -- just have a spare controller or server around, because you can't switch controller vendor without losing your data.
but proven to be true (and thus justifiable in hindsight)
You are assuming that it is justifiable just because it is true. Different jurisdictions have different views on that, so it is certainly not a safe assumption.
Yes. 64 bit only gives you a performance boost if any one task needs more than four gigabytes of ram. Most applications on the desktop do not and will not for a while.
64-bit kernel gives you a performance boost (or lack of a performance loss, if you prefer) on 1GB and up. Sure, the applications can easily stay 32-bit, but you can't do the classic 32-bit userland 64-bit kernel if the CPU is 32-bit.
is that better than people looking at the packaging, notice it says no linux support, and sticking with Windows?
Yes. Saves them from buying the wrong thing. An unhappy ex-user is worse than a user who doesn't know about Linux in the first place.
Or a crash dump when things go wrong that firmly puts the blame on the faulting driver (in big letters).
There are a million ways things can go wrong and not result in a nice dump like that. It's only lately that PC's have acquired rudimentary I/O isolation, and it isn't used much yet. Even with that in place, it would be tricky and possibly performance-limiting to enforce isolation for all devices.
There may have been a driver problem years ago, but today the problem is pretty much limited to graphics. And DVB, but the competition is doing just as badly there. Overall, Linux driver support is more complete than at least that of Windows Vista.
That would make it easier to manage as the number of them increases.
One of the great advantages of Linux is that improvements can be implemented for lots of devices at once.
I guess a lot of manufacturers will release binary-only drivers, but even if they are buggy, that doesn't leave in any worse state than we are already - those manufacturers aren't releasing drivers for Linux in the first place.
It means people will look at the packaging, notice that it says Linux support, and then find out that it doesn't actually work, and will then blame Linux. Manufacturer-written drivers are fairly universally crap.
It would also mean that drivers would be stuck on 32-bit x86. Great.
It's quite difficult to get decent performance from USB2, because the design of the host controller is such that the CPU needs to be involved in the transfer. If the CPU doesn't respond fast enough (perhaps because you're trying to do actual work with the machine), performance suffers. The problem is less with quad-core CPU's, since you can just dedicate a core to USB when doing transfers.
Firewire and SATA controllers can handle transfers pretty much on their own. Supposedly USB3 can do the same.
A basic firewire controller with pass-through is cheaper than a 2-port 1000baseTX switch
In this day and age, what do you use a 2-port switch for? You don't know that plugging the cable directly between cards just works?
mp3 and other lossy formats have as their whole point removing the kind of information you want to add -- sound that can't be heard. Compression is still a hot research topic with both academic and industry interests. In contrast, steganography is much more obscure. For now, the compression beats steganography.
According to the article we're talking at best 15% less coal burned per unit electricity, with no way to scale beyond that. Great for the power plants where it is viable, but definitely niche. Doesn't change the fact that we should stop building coal fired plants and decommission the existing ones.
Why run on battery when decent switches (used by banks...) have PoE available?
WOL is not all that useful in a heavily-virtualized data center. Besides, if you have 100.000 hosts in one network, it's probably a bad idea to run an unauthenticated protocol like WOL.
You can achieve the same by ssh'ing to the management port and turning the server on anyway.
DHCP relay. Turns the broadcasts into unicast. Not much of a challenge, that one.