"But of course, I have no clue and I could be totally wrong."
You have several clues and you are almost completely right.
"it just depends on how much of a hit you will take in duplicating and/or emulating the environment (cpu, chipset, sound hardware, etc) that the target OS expects. MIPS, ARM, x86, Cell, you name it. For x86 it's a pretty big hit (for now at least)."
You don't even need to consider emulation. Most OSes (Linux, *BSD, Windows, etc) have been ported to PowerPC and can run natively.
"So it's not like you've got a 9-way cpu workstation thundering away... you only get benefit when you take advantage of DSP-friendly code like what you see in media players."
Yes. And for the most part, people only need to decode things. x86 might be less efficient, but nobody cares as long as you're not dropping frames.
"However, if I'm not mistaken, these DSP's do not support branch prediction, and can only get instructions fed to them via the main CPU (they can't get it DMA-style from RAM)."
This is true enough to understand the weakness of the Cell. The SPEs can't work independantly, and the overhead of sending jobs to them is significant.
"Cell chips are essentially insanely fast PowerPC chips. Apple could have OS X running on a Cell chip in about the same time it takes for them to support any other new PowerPC chip that comes out."
True.
However, they would then say "Oh look, these codecs that are fast but everything else is many times slower. We should have gone with Intel chips because more people care about web browsing than encoding HD video in realtime.".
"The PPC implementation isn't all that hot, and the other cores won't help because they don't run PPC code."
"Uh, no.
Although, kudos to Apple in managing to get that damage control meme out into the computing public's minds."
What are you talking about?
IBM's documentation states specifically that the SPEs won't run PowerPC code.
The PPE front end is an in-order core, and despite the fact that it has SMT it's so minimalist that it can't keep up with G5s, and G5s are falling behind everyone else. Cell is much faster at a few tasks that basically don't matter for most Mac users, and much much slower at the tasks that do matter.
Since Macs will be running on PowerPC and Intel processors, this won't happen. Cell optimizations are not terribly portable.
"Macs are too expensive. With the mac mini and potential price drops with soon to be intel CPUs - a shrill cry Looks like all the reasons to not go with mac are evaporating. I won't even mention the traditional windows problems..."
It depends on what you mean by "too expensive". If you mean "Are they too expensive for people to be able to buy?", then you're right. They're not too expensive.
If you mean "Are they more expensive than the hardware justifies?", then you're wrong. You're not even paying a premium for the same computer, you're paying a premium for less computer. Even in areas where the CPU architechture is irrelevant, Macs have slower hardware than they should (slower hard drives and GPUs in minis/portables, displays with worse resolution, contrast ratio, response time, disabled dual-output video in iBooks/iMacs, etc).
They're also too expensive because gaps in the product line leave many users without a computer that meets their needs for a reasonable price. The cheapest PowerMac is CDN$2500, and that is simply an unreasonable amount to pay when all you want is a second display or a PCI card. People tell me that professionals probably need a second CPU anyway, which is funny because I am a professional and I know I don't.
That's basically the only reason I don't have a Mac desktop now. I was able to put together a very nearly comparable machine for about half the money, the only major differences are that it's not OS X and it doesn't have a second CPU. Given how much faster Athlon64s are than G5s at the same mhz, the performance is pretty close. I can live without OS X when I save about $1500. And hey, since it cost less than half I can buy another one in a few years, I'll still be ahead on money, and this future machine will be way faster than PowerMac I otherwise would have had to stick with.
The Cell front end processor is PowerPC. With the right drivers it probably could run OS X. That said, it won't because Apple doesn't want to support OS X on someone else's hardware and Sony doesn't need a general purpose OS.
The OS X userspace is nice but a bit redundant for a machine that only needs a few utilities and games. The OS X OpenGL implementation isn't the fastest, and the spiffy display technologies (and they are spiffy) aren't necessary. Sony just needs a subset of OpenGL but it needs to be fast.
The Darwin kernel isn't the fastest either, and Sony can do a lot better whether or not they're willing to pay for it (Linux or NetBSD on the free side, any number of real-time kernels on the other side).
"What if it means that the equipment will accept connections if it passes a rigerous sshv2-dsa key handshake, with a really, really big key size? I don't see that being insecure, setting aside concerns about the stupid feds being bitches in power games leaking the key. Technically, there's nothing stopping them from making it secure (as secure as you or I have our home systems, that is)."
The dominant SSH implementation (OpenSSH) isn't even based in the US, so the FCC doesn't have the power to mandate backdoors in it.
The server you're tunneling to will have a public key to authenticate itself. If you make sure you have a fingerprint (there are various ways to do this, it's usually doable even if you have to pick up a phone), you can be reasonably sure you're getting the server you wanted.
"However, when the last steps are "electrolysis of water" and then "burning the hydrogen", there's additional energy input, namely, those come from the water/hydrogen - it is not merely a "fire transfer system" anymore."
There is no additional energy input. This device, like any other, must obey the laws of thermodynamics. The energy from burning the hydrogen can never be greater than the energy required for electrolysis to split the hydrogen and water in the first place.
If this device were more than 100% efficient, I assure you this company would have more ambitious goals than selling fancy fireplaces to rich people.
"Take Blender for instance, where the wheel is expected to such a degree that using a stylus instead of a mouse (otherwise great precision and all, quite common graphics/CAD device) gets quirky."
I don't know that software or CAD input devices so I'll have to take your word for it. I agree that's a problem.
"Basically the same point as with single/multiple buttons: with clever developers this wouldn't ever be a problem, unfortunately some developers are not that clever when it comes to UI design and need some (artificial) restrictions."
I agree. But we're essentially faced with a choice between two problems: developers that can't read a HIG, and artificially restricting users.
"You are right, scrolling is unavoidable in some circumstances (such as editing printout documents) but the scroll wheel rings too loud on the "add another poorly integrated feature" bell."
I disagree. It's not adding a poorly integrated feature, it's refining one that's been around since GUIs were born.
"I propose the much simpler solution of using the "hand" cursor to move around, in any read-only document like web pages it should be the default tool."
Your idea would work, but given the size of the motion necessary to do it and the repetitive nature I think it would be tiring. I'm not just saying that in a theoretical sense either, Adobe's Linux PDF reader didn't always support the scroll wheel and you were stuck with the hand tool/scroll bar. I found that very annoying, and now that the wheel is supported I'm much happier.
This can and has been argued back and forth endlessly, but I think there's a middle ground most people have been missing. Most people can figure things like the scroll wheel and the right mouse button out in minutes regardless of how much experience they have. We're not talking about inexperienced users here, we're talking about users who aren't capable of figuring it out, ever. A good interface is discoverable, but those users are not capable of discovery.
I'm not saying these users are stupid because I know some smart ones. I'm not opposed to leaving a lowest-common-method around for them, but the majority of us can do better and I don't see why we should sacrifice so a minority can be protected from things they're not going to figure out.
"And before anyone says the scroll wheel/ball is easier: why do we retain that mouse underneath the scroll wheel then?"
The scroll wheel doesn't generalize as a pointing device. A wheel is better at scrolling, not everything. Similarly, a keyboard can be used to handle a graphical interface, but expediency leads us towards the mouse because it's so much better at what it does that it would be stupid to use anything else.
People that want the most orthogonal interface possible miss something: expediency. There are situations where something that takes minutes learn makes a task so much easier and faster that it becomes impractical to do it any other way. We use mice instead of keyboards or touch screens because they're way better at the job. We (most of us anyway) use scroll wheels because there's a graphical operation that is so common it justifies dedicated hardware for the job, and that hardware is much better at it.
"On another note: if you're gonna buy the MM for Linux use, make sure the drivers support 2-dimensional scrolling since it's reportedly not functioning in windows."
Thanks for pointing that out. It had occured to me (I was going to wait to see how that turned out), but it's probably best that the warning is in a public place.:)
The union might be just as bad, but the union doesn't want to sell me anything. Telus is the only party I can meaningfully impact with a boycott and now that they're both the bad guys, I will.
I've had technical problems with Shaw. Nothing unusual, about what you'd expect. But they really shine if you have a business account and need support.
I know support people have it rough, so I try to be accomodating. I'm happy to plug in a machine with an officially supported OS because I know it'll be easier for both of us if we can get through the script without any fuss. But their support people tell me "No, that's alright. What have you done to troubleshoot?" They're perfectly capable of understanding what I've done and what it implies.
These aren't the senior people that you talk to once you get escalated, these are the first-line people that first answer the phone. I've moved around a bit and dealt with a lot of ISPs, and Shaw's first-line business support people are better than most of the senior people elsewhere.
Shaw gives me a better deal on bandwidth, but I'd use them even if they didn't.
"Then, isn't arguing against the Mighy Mouse (and for regular Logitechs) is to argue that you don't need to scroll in both directions)"
It would be, yes. Which is why I'm not arguing against it.
I like what I've seen of the MM enough that I'm considering buying one for my Linux box as soon as the retailers around here get them in stock so I can make sure I like the feel of it. I've seen mice with a horizontal wheel but never a ball.
"I would say that to argue against scroll wheels is sensible, like defending a single mouse button, the need for a scroll wheel is just a symptom of poor interface design."
No it's not.
Scroll bars are a ubiquitous UI component. There's not really any way around them because we need to display more information than can fit on a screen. But they're terrible from an HCI standpoint, because the misstep rate is high and they're a difficult target to hit with a mouse.
Since they're terrible and they can't be avoided, improvements are welcome. Scroll wheels are rediculously easy to use and the misstep rate is very low. They're very intuitive, almost as intuitive as a mouse itself. Therefore, they're a good idea.
"I don't think Apple ever believed people "can only handle one button at a time", just that most of the time a second button was a product of poor interface design and not a product of necessity. and they're right."
That's a strawman.
MacOS has used hold-click and CMD-click for a long time. Those take the place of a second button. That all the options are generally available from menus is a result of programmers making it that way, even when the alternate click was available. The Mac implementation might be a bit better (I'm not going to argue this either way), but it's equivilant to the PC implementation in difficulty and functionality. This whole issue can be ignored.
The important issue is the (until now) lack of a scroll wheel. To argue against PC-style mice is to argue against scroll wheels, and that is a very difficult position to take. They're as intuitive as the mouse itself, and they make scrolling operations vastly easier. This omission is what has been making Apple mice inferior, and what continues to make non-premium mice inferior.
The extra buttons aren't that big a deal for me, it's the scroll wheel.
It's deeply intuitive, just like moving the mouse itself. While right-clicking can be confusing (and Apple doesn't really get around this because they have hold-click), I've seen inexperienced users using the scroll wheel instinctively within minutes of being exposed to it. There was no reason to leave it out.
I think the primary motivation was to release a mouse with scrolling capability because people were willing to buy a third party mouse over the lack of it. The extra features are gravy.
"I think the fact that linux kernels (and for that matter, BSD kernels also) are (almost) infinitely configurable makes it very hard to do regression tests. It is much easier to do regression tests when you have a fixed set of kernel options and a fixed set of hardware pieces."
This is exactly the issue that is causing problems.
For Linux, there is no substitute for time. There is no substitute for new features being given time to settle before they are dumped into everyone's lap. This is why the new development model is a problem. There's no time.
Hopefully these new policies will give enough time.
"you still have the TCP/IP traffic to deal with so that packets get TO the game."
Stateful firewalls know all they need to know about TCP/IP to handle packets on a per-connection level. The game is running on another system, so the firewall need only needs to get a packet out onto the appropriate interface. I know PF can do this at the firewall level (see the fastroute keyword). Even if it does have to use the network stack (IPFW or IPF might not be able to route independantly, I'm not sure) FreeBSD can route packets very quickly[1].
"If you RTFA this "game router" is really only adding traffic shaping/prioritization, which is something a middle of the road router can do anyway in FIRMWARE which will be lots faster than that software."
Firmware is software that gets loaded onto a general purpose processor. Usually ARM or MIPS for broadband routers, IIRC. It doesn't matter whether it comes from an EEPROM, a flash memory chip, or a hard drive. Once it's in memory it's pretty much the same. The traffic shaping available with this will be a lot more configurable, and they wrapped the OS up into an easy-to-use distribution. It's not unusual for gamers to have unused computers sitting around, given their upgrade cycle, so it would be cheaper to use this if you have the hardware.
"Also you have to use good NICs (more $$$) on the old PC, which if it is an ISA bus PC good luck finding them, and if you find then you still got a 66MHz backplane in that old Pentium."
How many spare NICs do you have? Be honest. Until they started putting them on the motherboard most computers had one and whenever the computer died the NIC was always left over.
Pretty much any NIC will do for the purposes of broadband routing. The 66 mhz bus on a Pentium is also more than you need. A 486 can handle it. I've used a 486 with ISA NICs as a firewall on a cable modem with 5 megabits downstream bandwidth.
"There are lots of complexities here, it's not something your average gamer is going to build."
An easy to use package that runs on PCs a gamer already has? All they need to do is add a NIC or two? When they spend half their time putting in new video cards and RAID arrays on their other PC? When it'll save them enough money to get more game hardware? Sounds pretty plausible to me.
1 - http://people.freebsd.org/~andre/FreeBSD-5.3-Netwo rking.pdf - FreeBSD 5.3 can route 1m packets per second on a 2.8 ghz Xeon, while it's doubtful it would have to do about 1/10000 that for a cable modem on a computer about 1/50 as fast.
Slashdot Mirror
" But does the FCC have the power to prevent "import" of OpenSSH if they don't comply??"
Probably, at least legally. Not practically though. As you say, it would be utterly trivial to download your own.
"But of course, I have no clue and I could be totally wrong."
You have several clues and you are almost completely right.
"it just depends on how much of a hit you will take in duplicating and/or emulating the environment (cpu, chipset, sound hardware, etc) that the target OS expects. MIPS, ARM, x86, Cell, you name it. For x86 it's a pretty big hit (for now at least)."
You don't even need to consider emulation. Most OSes (Linux, *BSD, Windows, etc) have been ported to PowerPC and can run natively.
"So it's not like you've got a 9-way cpu workstation thundering away... you only get benefit when you take advantage of DSP-friendly code like what you see in media players."
Yes. And for the most part, people only need to decode things. x86 might be less efficient, but nobody cares as long as you're not dropping frames.
"However, if I'm not mistaken, these DSP's do not support branch prediction, and can only get instructions fed to them via the main CPU (they can't get it DMA-style from RAM)."
This is true enough to understand the weakness of the Cell. The SPEs can't work independantly, and the overhead of sending jobs to them is significant.
"Cell chips are essentially insanely fast PowerPC chips. Apple could have OS X running on a Cell chip in about the same time it takes for them to support any other new PowerPC chip that comes out."
True.
However, they would then say "Oh look, these codecs that are fast but everything else is many times slower. We should have gone with Intel chips because more people care about web browsing than encoding HD video in realtime.".
"The PPC implementation isn't all that hot, and the other cores won't help because they don't run PPC code."
"Uh, no.
Although, kudos to Apple in managing to get that damage control meme out into the computing public's minds."
What are you talking about?
IBM's documentation states specifically that the SPEs won't run PowerPC code.
The PPE front end is an in-order core, and despite the fact that it has SMT it's so minimalist that it can't keep up with G5s, and G5s are falling behind everyone else. Cell is much faster at a few tasks that basically don't matter for most Mac users, and much much slower at the tasks that do matter.
"No games. not if sony releases PS games for mac"
Since Macs will be running on PowerPC and Intel processors, this won't happen. Cell optimizations are not terribly portable.
"Macs are too expensive. With the mac mini and potential price drops with soon to be intel CPUs - a shrill cry Looks like all the reasons to not go with mac are evaporating. I won't even mention the traditional windows problems..."
It depends on what you mean by "too expensive". If you mean "Are they too expensive for people to be able to buy?", then you're right. They're not too expensive.
If you mean "Are they more expensive than the hardware justifies?", then you're wrong. You're not even paying a premium for the same computer, you're paying a premium for less computer. Even in areas where the CPU architechture is irrelevant, Macs have slower hardware than they should (slower hard drives and GPUs in minis/portables, displays with worse resolution, contrast ratio, response time, disabled dual-output video in iBooks/iMacs, etc).
They're also too expensive because gaps in the product line leave many users without a computer that meets their needs for a reasonable price. The cheapest PowerMac is CDN$2500, and that is simply an unreasonable amount to pay when all you want is a second display or a PCI card. People tell me that professionals probably need a second CPU anyway, which is funny because I am a professional and I know I don't.
That's basically the only reason I don't have a Mac desktop now. I was able to put together a very nearly comparable machine for about half the money, the only major differences are that it's not OS X and it doesn't have a second CPU. Given how much faster Athlon64s are than G5s at the same mhz, the performance is pretty close. I can live without OS X when I save about $1500. And hey, since it cost less than half I can buy another one in a few years, I'll still be ahead on money, and this future machine will be way faster than PowerMac I otherwise would have had to stick with.
Darwin is not a particularly strong kernel. There are a large number of kernels, both open source and commercial that would do the job better.
The Cell front end processor is PowerPC. With the right drivers it probably could run OS X. That said, it won't because Apple doesn't want to support OS X on someone else's hardware and Sony doesn't need a general purpose OS.
The OS X userspace is nice but a bit redundant for a machine that only needs a few utilities and games. The OS X OpenGL implementation isn't the fastest, and the spiffy display technologies (and they are spiffy) aren't necessary. Sony just needs a subset of OpenGL but it needs to be fast.
The Darwin kernel isn't the fastest either, and Sony can do a lot better whether or not they're willing to pay for it (Linux or NetBSD on the free side, any number of real-time kernels on the other side).
"The backdoor could be, for example, a certain username/password account for logging in via ssh, a piece of GPL'd software."
The dominant SSH implementation (OpenSSH) is BSD, not GPL.
"What if it means that the equipment will accept connections if it passes a rigerous sshv2-dsa key handshake, with a really, really big key size? I don't see that being insecure, setting aside concerns about the stupid feds being bitches in power games leaking the key. Technically, there's nothing stopping them from making it secure (as secure as you or I have our home systems, that is)."
The dominant SSH implementation (OpenSSH) isn't even based in the US, so the FCC doesn't have the power to mandate backdoors in it.
The server you're tunneling to will have a public key to authenticate itself. If you make sure you have a fingerprint (there are various ways to do this, it's usually doable even if you have to pick up a phone), you can be reasonably sure you're getting the server you wanted.
220 V * 60 A = 13.2 kw
I don't know many places that need 13 kW of heating that don't already have it.
"However, when the last steps are "electrolysis of water" and then "burning the hydrogen", there's additional energy input, namely, those come from the water/hydrogen - it is not merely a "fire transfer system" anymore."
There is no additional energy input. This device, like any other, must obey the laws of thermodynamics. The energy from burning the hydrogen can never be greater than the energy required for electrolysis to split the hydrogen and water in the first place.
If this device were more than 100% efficient, I assure you this company would have more ambitious goals than selling fancy fireplaces to rich people.
"Take Blender for instance, where the wheel is expected to such a degree that using a stylus instead of a mouse (otherwise great precision and all, quite common graphics/CAD device) gets quirky."
I don't know that software or CAD input devices so I'll have to take your word for it. I agree that's a problem.
"Basically the same point as with single/multiple buttons: with clever developers this wouldn't ever be a problem, unfortunately some developers are not that clever when it comes to UI design and need some (artificial) restrictions."
I agree. But we're essentially faced with a choice between two problems: developers that can't read a HIG, and artificially restricting users.
"You are right, scrolling is unavoidable in some circumstances (such as editing printout documents) but the scroll wheel rings too loud on the "add another poorly integrated feature" bell."
:)
I disagree. It's not adding a poorly integrated feature, it's refining one that's been around since GUIs were born.
"I propose the much simpler solution of using the "hand" cursor to move around, in any read-only document like web pages it should be the default tool."
Your idea would work, but given the size of the motion necessary to do it and the repetitive nature I think it would be tiring. I'm not just saying that in a theoretical sense either, Adobe's Linux PDF reader didn't always support the scroll wheel and you were stuck with the hand tool/scroll bar. I found that very annoying, and now that the wheel is supported I'm much happier.
This can and has been argued back and forth endlessly, but I think there's a middle ground most people have been missing. Most people can figure things like the scroll wheel and the right mouse button out in minutes regardless of how much experience they have. We're not talking about inexperienced users here, we're talking about users who aren't capable of figuring it out, ever. A good interface is discoverable, but those users are not capable of discovery.
I'm not saying these users are stupid because I know some smart ones. I'm not opposed to leaving a lowest-common-method around for them, but the majority of us can do better and I don't see why we should sacrifice so a minority can be protected from things they're not going to figure out.
"And before anyone says the scroll wheel/ball is easier: why do we retain that mouse underneath the scroll wheel then?"
The scroll wheel doesn't generalize as a pointing device. A wheel is better at scrolling, not everything. Similarly, a keyboard can be used to handle a graphical interface, but expediency leads us towards the mouse because it's so much better at what it does that it would be stupid to use anything else.
People that want the most orthogonal interface possible miss something: expediency. There are situations where something that takes minutes learn makes a task so much easier and faster that it becomes impractical to do it any other way. We use mice instead of keyboards or touch screens because they're way better at the job. We (most of us anyway) use scroll wheels because there's a graphical operation that is so common it justifies dedicated hardware for the job, and that hardware is much better at it.
"On another note: if you're gonna buy the MM for Linux use, make sure the drivers support 2-dimensional scrolling since it's reportedly not functioning in windows."
Thanks for pointing that out. It had occured to me (I was going to wait to see how that turned out), but it's probably best that the warning is in a public place.
The union might be just as bad, but the union doesn't want to sell me anything. Telus is the only party I can meaningfully impact with a boycott and now that they're both the bad guys, I will.
I've had technical problems with Shaw. Nothing unusual, about what you'd expect. But they really shine if you have a business account and need support.
I know support people have it rough, so I try to be accomodating. I'm happy to plug in a machine with an officially supported OS because I know it'll be easier for both of us if we can get through the script without any fuss. But their support people tell me "No, that's alright. What have you done to troubleshoot?" They're perfectly capable of understanding what I've done and what it implies.
These aren't the senior people that you talk to once you get escalated, these are the first-line people that first answer the phone. I've moved around a bit and dealt with a lot of ISPs, and Shaw's first-line business support people are better than most of the senior people elsewhere.
Shaw gives me a better deal on bandwidth, but I'd use them even if they didn't.
They must have paid through the nose for that domain name.
"Then, isn't arguing against the Mighy Mouse (and for regular Logitechs) is to argue that you don't need to scroll in both directions)"
It would be, yes. Which is why I'm not arguing against it.
I like what I've seen of the MM enough that I'm considering buying one for my Linux box as soon as the retailers around here get them in stock so I can make sure I like the feel of it. I've seen mice with a horizontal wheel but never a ball.
"I would say that to argue against scroll wheels is sensible, like defending a single mouse button, the need for a scroll wheel is just a symptom of poor interface design."
No it's not.
Scroll bars are a ubiquitous UI component. There's not really any way around them because we need to display more information than can fit on a screen. But they're terrible from an HCI standpoint, because the misstep rate is high and they're a difficult target to hit with a mouse.
Since they're terrible and they can't be avoided, improvements are welcome. Scroll wheels are rediculously easy to use and the misstep rate is very low. They're very intuitive, almost as intuitive as a mouse itself. Therefore, they're a good idea.
"I don't think Apple ever believed people "can only handle one button at a time", just that most of the time a second button was a product of poor interface design and not a product of necessity. and they're right."
That's a strawman.
MacOS has used hold-click and CMD-click for a long time. Those take the place of a second button. That all the options are generally available from menus is a result of programmers making it that way, even when the alternate click was available. The Mac implementation might be a bit better (I'm not going to argue this either way), but it's equivilant to the PC implementation in difficulty and functionality. This whole issue can be ignored.
The important issue is the (until now) lack of a scroll wheel. To argue against PC-style mice is to argue against scroll wheels, and that is a very difficult position to take. They're as intuitive as the mouse itself, and they make scrolling operations vastly easier. This omission is what has been making Apple mice inferior, and what continues to make non-premium mice inferior.
The extra buttons aren't that big a deal for me, it's the scroll wheel.
It's deeply intuitive, just like moving the mouse itself. While right-clicking can be confusing (and Apple doesn't really get around this because they have hold-click), I've seen inexperienced users using the scroll wheel instinctively within minutes of being exposed to it. There was no reason to leave it out.
I think the primary motivation was to release a mouse with scrolling capability because people were willing to buy a third party mouse over the lack of it. The extra features are gravy.
"I think the fact that linux kernels (and for that matter, BSD kernels also) are (almost) infinitely configurable makes it very hard to do regression tests. It is much easier to do regression tests when you have a fixed set of kernel options and a fixed set of hardware pieces."
This is exactly the issue that is causing problems.
For Linux, there is no substitute for time. There is no substitute for new features being given time to settle before they are dumped into everyone's lap. This is why the new development model is a problem. There's no time.
Hopefully these new policies will give enough time.
It'll be a lot more than one. There will be at least a half-dozen repeats.
"And no, don't say Linux - I don't have enough time to learn it well enough to use it as a desktop machine on a daily basis."
pfft
Looks like Linux will support DRM soon anyway.
"you still have the TCP/IP traffic to deal with so that packets get TO the game."
o rking.pdf - FreeBSD 5.3 can route 1m packets per second on a 2.8 ghz Xeon, while it's doubtful it would have to do about 1/10000 that for a cable modem on a computer about 1/50 as fast.
Stateful firewalls know all they need to know about TCP/IP to handle packets on a per-connection level. The game is running on another system, so the firewall need only needs to get a packet out onto the appropriate interface. I know PF can do this at the firewall level (see the fastroute keyword). Even if it does have to use the network stack (IPFW or IPF might not be able to route independantly, I'm not sure) FreeBSD can route packets very quickly[1].
"If you RTFA this "game router" is really only adding traffic shaping/prioritization, which is something a middle of the road router can do anyway in FIRMWARE which will be lots faster than that software."
Firmware is software that gets loaded onto a general purpose processor. Usually ARM or MIPS for broadband routers, IIRC. It doesn't matter whether it comes from an EEPROM, a flash memory chip, or a hard drive. Once it's in memory it's pretty much the same. The traffic shaping available with this will be a lot more configurable, and they wrapped the OS up into an easy-to-use distribution. It's not unusual for gamers to have unused computers sitting around, given their upgrade cycle, so it would be cheaper to use this if you have the hardware.
"Also you have to use good NICs (more $$$) on the old PC, which if it is an ISA bus PC good luck finding them, and if you find then you still got a 66MHz backplane in that old Pentium."
How many spare NICs do you have? Be honest. Until they started putting them on the motherboard most computers had one and whenever the computer died the NIC was always left over.
Pretty much any NIC will do for the purposes of broadband routing. The 66 mhz bus on a Pentium is also more than you need. A 486 can handle it. I've used a 486 with ISA NICs as a firewall on a cable modem with 5 megabits downstream bandwidth.
"There are lots of complexities here, it's not something your average gamer is going to build."
An easy to use package that runs on PCs a gamer already has? All they need to do is add a NIC or two? When they spend half their time putting in new video cards and RAID arrays on their other PC? When it'll save them enough money to get more game hardware? Sounds pretty plausible to me.
1 - http://people.freebsd.org/~andre/FreeBSD-5.3-Netw
On BSD, NAT lives in the firewall and that doesn't use the network stack.