There's also the possiblility of paying for 95 percentile bandwidth usage - the highest KB/s you achieved in the month after discarding the 5% highest time windows. This seems to be quite popular with colocation providers.
Actually UUNET for one has offered that since at least 1992 on at least T1 service, and they have had resale terms on lines (T1 wholesale) for roughly that long too.
The questions is whether consumers move towards wanting to pay that way, because providers already want to charge that way:-)
More specifically, I was looking at how I can use ProjectBuilder.app's CVS integration.
The help files claim the CVS stuff works if you are working on a project already under CVS. So i guess checking whatever your working on in, and out again should make that stuff work.
I have never tried it though, I didn't even realize it was there. Using a GUI to write and manage code is still new to me:-)
(well, to be honest I used a crappy on on the Atari ST where I first learned C...)
If they are stupid enough to stop people just for looking like shoplifters then they deserve to go down.
But I see no harm done to you if they will watch you because you resemble known shoplifter.
The story was pretty unclear on whether they watch people closely, or eject them. If they watch closely, that probably doesn't harm anyone much (secondary uses of the images may though). However I'm kinda thinking they will eject people. Ironicly the closer the software gets to perfect the larger the chance that it will be misused, eh?
You can always use RSA authentication to avoid the attack when ssh'ing to another host. The authentication agent (try "man ssh-agent") can be used so that the passphrase used for protecting the RSA keys is not sent to the network, but only used locally at the workstation you're sitting at.
I didn't know ssh-agent on machine A could help you log into machine C from machine B. How does that work given that ssh-agent only binds to a unix domain socket (single host IPC)? Does ssh magically tunnel it? I didn't see anything in the RFC about that when I implemented my ssh client!
It definitely didn't work magically for me when I logged into my work account from my home machine and tried to have it RSA authenticate to my SourceForge account -- it does work from my home account.
Lastly, what makes you think that the kind of wanker that can't trust ssh and makes you bounce through a firewall is going to leave RSA auth on? Eh?
That's great, but how do they know when somebody is entering a password locally? It's not as though they can read all your keystrokes and tell exactly what you're doing. The only way they could do so is if they're also logged on to the remote computer so that they can process monitor and see exactly what you're doing. Otherwise they won't know whether you're typing in a password or replying to a message on/. in Links.
That's what I thought before I read the paper. However you can guess when passwords are typed. One big hint would be lack of an echo. Sure, that might be someone typing a long vi command sequence, or the far end being slow, but the traffic information is only used to help guess passwords, it isn't relied on to actually be 100% accurate!
How do I configure it to setup to connect to a CVS server and corresponding project so that I can commit my sources?
Same way you normally would? Check out an existing project with "cvs -d user@server:/path/to/cvsroot get projectname"
It works for me under OS X at least. Try reading the CVS FAQ for help. Or any CVS FAQ google turns up.
Setting up your own repository is a bit harder. One way around that is to open source your project and have SourceForge set up a repository for you. You get free off site backups that way:-)
CVS has some big flaws, but it is quite nice. I haven't seen a source code control system that didn't have problems. Anyway I think you should look at subversion they are directly addressing CVSs big flaws. It looks like the authors know a lot about CVS, and like CVS, so whatever they build will probably not suck more then CVS...
...except they have a lot of dependence on Apache and the DAV module. So that part at least sucks differently then CVS, and maybe more. Hopefully subversion will get far enough along that I can find out for myself though.
If McVoy would stop playing silly license games with Bitkeeper so he can try to become the next Sourceforge (sorry, but you lost), then the world would probably beat a path to his door.
Bitkeeper does look cool. I don't think subversion can do the same sort of hierarchy of repositories that bitkeeper can. Anyway I don't think McVoy wants to be the next SourceForge (are they making money?), he want to be the next PerForce, CodeSafe, or whoever else has made a ton of money directly off version control software.
In the meantime, are there any robust and free alternatives to cvs?
No, unless by "robust" you really mean "alpha quality, not trusted to be self hosting yet". Try again in six months:-)
most GUI implementations do. SecureCRT, MacSSH, etc. Most of the Linux lovers that I know (and myself) use the commandline version which has you enter your password in the standard way.
Not really, even the command line ssh sends the ssh password in a single CMSG_AUTH_PASSWORD packet. The attack isn't talking about that password. It is talking about passwords you use after you are logged in. Say by running sudo, or ssh'ing to another host (maybe one that a firewall prevents reaching directly).
You could avoid this by cut n' pasting your password, but that has other problems (like forgetting the password was the last thing in the buffer and pasting it somewhere you don't want it!), and is just ugly. The ssh client could buffer multiple characters, but it doesn't know when it should do that. Most of the time having that done would suck huge. The ssh client could also pad packet sizes, but that only helps so much.
A real answer would change the ssh client, the ssh server, the ssh protocol, and anything that prompts for a password. Even if you assume that "anything that prompts for a password" all uses libc's getpass that is still a whole whole lot of work.
What would the change do? It would have getpass do a tty ioctl letting the master side of tty know we are in "read password mode". The master side of the tty would be sshd in this case, it would send a new ssh message to the client asking for all keys typed to be buffered until the end line char, interrupt char, or other special control chars are typed, and transmit the whole buffer. The ssh client's role should be obvious.
Come to think of it, that sounds alot like the telnet line mode, so maybe the tty driver has an appropriate mode, but a quick look turned up nothing.
Or with SSH by just not sending the password across the network at all. Using RSA euthentication completely nullifies this potential vulnerability.
They are talking about passwords entered after you log in. To things like sudo, or SQL front ends, or other crap like that. Or loging into another machine.
The SliMP3 firmware is, AFAIK, the only modern IP stack to have been entirely hand-coded in assembler.
Modern in what way?
You are right, the other microcontroler IP stack I know of is quite old (late 80s, or at least pre-1992). Steve Holmgrin's (may be misspelled) IP stack for some random microcontroler that had 8K of OTP ROM and 4K of RAM, and I think a 6502 like instruction set. He wrote a small FORTH like language, and then a IP stack including TCP, and some of the small servers (chargen, quote). It didn't drive an ethernet, it did SLIP (I'm pretty sure it predated PPP).
As I recall one of his proof of concepts was to replace the serial part on an ADM3A terminal, once done you could hook it up to a terminal server with SLIP, and when you turned on the terminal you got a TELNET> prompt. Too bad he didn't have enough RAM to let you switch between multiple telnet sessions.
As I recall Hariss Semiconductor bought the implementation, and as far as I know never did anything with it.
By the time you've got 30 people on this wonderful grass-roots network of yours, each person's slice of the internet bandwidth is roughly equivalent to a 56K modem.
100 to one oversubscription for DSL subscribers isn't uncommon. People really use their line less then you think. 10 to one oversubscription is actually pretty nice.
Web usage is a really good fit here. Click, use a ton of bandwidth for 3 to 8 seconds, then read for five minutes. Click again...
Someone downloading ISOs of the latest Linux distro will throw that off for an hour or two, but that's not too bad as long as only a few people do it at once... Of corse someone trying to run an ISP off their 2Mbits will hurt you:-)
The real problem is affording a T1 to an ISP that lets you resell bandwidth, or funding a lawyer to assert that your co-op is not a reseller since there is no money exchanged between the co-op members...
UUCP support still gets built when I rebuild world on my FreeBSD boxen, but that's not my primary method of interaction with the Internet, nor is it for most folks...because it's slow and cranky. Let's hear it for convenience.
Actually UUCP over TCP is a really good way to get net news if you only have one feed. It is much more tolarent of high latency then NNTP.
Other then that it doesn't have that much use any more... at least not that I can think of off the top of my head.
It varies a lot, no name 80min CDRs bought in nominally overpriced retail stores are about $25 for 50 CDRs (on a spindle, not in cases). Frequently those come out to $0 with a mail in rebate (that takes 2-3 months to process, and many people don't send it). I have seen 50 CDRs for $10 with cases though, and other places selling them closer to $1 each.
Since I'm not in a hurry (it normally takes me about three weeks to take enough pictures to fill a CDR), I buy CDRs when I see them for "about free", and I burn a set of pictures onto two different CDRs, different brands if I can. I figure that reduces the chance of a bad batch taking out my pictures. Some time soon I'll be doing the off site storage thing, but I'm not yet.
Name me one person you know who is at least moderately computer savvy, has a cd burner and uses a computer as a hobbyist device who has not done something illegal with their cd burner within a week of owning it.
As far as I know, me. Twice.
I bought a SCSI CD Burner (for my Unix box) referb at a "good price" because it was cheap and I thiught I wanted one. It didn't go into a machine for six months (give or take). It also didn't work once put in, which makes me feel extra dumb since I can't really return it under the 90 warente if I didn't look at it for twice that long...
I also bought another drive (Firewire for my laptops). That one I did use almost right away. So far I have only burned two music CDs, both of which contain only music I owned at the time, and still own. I have burned a pile of CDs with copyrighted pictures as well. Of corse since they are copyrighted by me I'm going to say that was quite legal.
That's partly the reason why we Canadians pay a CD levy tax
Right, so I should pay money to the music cartel to store pictures of my dog? I don't think so. They got the DCMA, if that hunk of un-constitutional crap can't protect them, I really don't care. They should repeal that before they go begging for another way to screw 100% of the people to catch the 75% they think are riping them off.
DVD recordable media is about AU$30 and i shudder to think what RW is going to be worth
$15 according to the article (and I have seen the "normal" DVD recordables for $50 for 5). Not all that costly, even if it isn't price competitive with CD-R (which I have been buying at $20 for 50, with a $20 rebate).
I still want to know what the difference between DVD-RW and DVD+RW is, and who thought it would be a good idea to name them so closely.
I'm not sure, but I don't think that the individual characters of the password are sent in separate packets at the start of an ssh session. Feel free to check and correct me:-)
Hmmm, I think you may be right. I don't know enough about the normal SSH code to check, but taking a quick look at mine the password is in a single CMSG_AUTH_PASSWORD packet not the CMSG_STDIN_DATA packets, so I expect everything sends the initial packet as a single chunk. The only thing open to this attack would be passwords sent during a session.
Which means either the authors of the paper took into account the difficulty of guessing what input text is (or might be) the passwords, and we are all in a (modest) bit of trouble, or something fishy is going on here.
That won't quite work; ssh has no idea when you are typing in a password, and when you're expecting an interactive response. Imagine using the passwd command during an ssh session; how does ssh know?
The ssh client doesn't know in general when you are typing a password, but it does know in specific when you are typing the one to start the session. My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password. I expect a lot of other window system dependent ssh clients work the same way.
The only problem with this solution, though, is that su-ing can reveal a password.
Or entering passwords for things on the remote host (like things on the serial devices). However the attacker needs to somehow know when you are entering this other password. It won't normally be easy for them to know. Unless they have created a problem, and called you to ask you to fix it... you can type you password locally and paste them into the ssh client, but that seems painful, and it also mean you password is in the local cut buffer which is an attackable location (and also you might paste it somewhere you didn't want to...). Blech.
But you can't get at the inode without the file's name and location. Inodes are not suitable as file identifiers since they are not guaranteed to be unique across the multiple disks that make up a given file system. The combination of the file name and location is unique in a given file system. "inode + data blocks" do constitute a file, but the file is inaccessible unless the file name and location are known.
Actually there have been a number of (frequently ill-considered) non-standard ways to open a file by i-number. Sun's backup co-pilot was the first I had heard of (in '91), but it turns out there were a lot before it, and after. Most allowed only root to do it, but some did not. The ones that didn't broke some of the Unix security semantics.
Also you can get to a file a few other ways without involving it's name. Like recvmsg, regrettably something else had to know a name to the file at one point for them to work (that name may be gone now though -- all of the names may be gone in fact).
double clicking the in Mail does NOT launch the file
Um, yes it does. I just mailed myself FontExamplar.app, and double clicking on it did run it (after telling me it might have a virus and stuff, then I clicked the "What's a virus, please bone me" button and it ran).
And we know that under Mac OS X.0.4 Mail.app doesn't hide extensions, but I'm not sure that OS X.1's Mail.app won't. I would expect it to follow the finder setting. We also don't know what OS X.1 does with more then one "extension", does it strip them all? None? Or just one? I'm guessing just one, but I'm aware that it is a guess.
This isn't nearly the case, if the code IS DONE RIGHT [...] "Those packages that use autoconf/configure have been amazingly easy to port, usually needing a few lines of editing at most. Those that don't require enormous ammounts of effort."
That doesn't really mean autoconf/configure is a magic bullet. If I write something that uses kqueue and want to port it to Linux (or Solaris) I have to write non-kqueue code. Autoconf will merely figure out which part of my code to enable or disable, it won't take my kqueue code and make it work elsewhere.
So to use the new interfaces, and be portable I have to write code to use the old interfaces. If the old interface doesn't exist I have to disable part of my application's features.
Using kqueue as an example (once again), if I have an X program using a toolkit that lets me write my own file I/O callbacks and timeouts, but no callback for wait4 or the like, but I want to know when a child process exits, I don't have that many good choices. I can use kqueue which pretty trivially converts a process exit into file I/O (or at least a read ready event, plus a call to kevent rather then read). Then it will only run on two or three Unix systems. I can write a SIGCHLD handler that sets a flag and use a periodic timeout, but then I either burn CPU, or it takes too long to see the event. I could skip the SIGCHLD handler and just call wait4 with W_NOHANG in the timer callback. That has roughly the same problems that the SIGCHLD answer does.
I could write both, and then use autoconf to decide which to compile. Then I have to test both. The documentation has to say "On some platforms there can be a noticeable gap between the tracks, on others you get no gap in the tuneage".
In other words it's not that doing the code right helps, it's doing the code twice, and it only helps so much.
Last comment: yeah, the stuff that already uses autoconf ports easier then the rest of it because someone already did a lot of work to make it run multiple places, and may have decided to ditch features to avoid more problems.
Yep. You'll get MUCH more gaming for your bucks if you get yourself a console. I know it's hurting our gaming pride, but it's really dumb to upgrade your computer to play games.
Yeah....except the PC games have more strategy (at least real-time strategy) games then consoles, and more kinda odd ball games (theme park simulator anyone? -- I don't think that is on any consoles, but I could be wrong).
It also at least use to be the case that PCs had better force feedback stuff (the DreamCast's idea of force feedback is a shaker from a pager).
Now if "all" I wanted was some Kick-Fu games (and there is nothing wrong with that -- that's why I have a DreamCast!), and a few gun games, a console makes sense. If I want Civ-III then a console isn't so hot.
Slashdot Mirror
Actually UUNET for one has offered that since at least 1992 on at least T1 service, and they have had resale terms on lines (T1 wholesale) for roughly that long too.
The questions is whether consumers move towards wanting to pay that way, because providers already want to charge that way :-)
The help files claim the CVS stuff works if you are working on a project already under CVS. So i guess checking whatever your working on in, and out again should make that stuff work.
I have never tried it though, I didn't even realize it was there. Using a GUI to write and manage code is still new to me :-)
(well, to be honest I used a crappy on on the Atari ST where I first learned C...)
That's what I was expecting when I went there a few years ago, but the food was wonderful (as was the "warm" beer).
The story was pretty unclear on whether they watch people closely, or eject them. If they watch closely, that probably doesn't harm anyone much (secondary uses of the images may though). However I'm kinda thinking they will eject people. Ironicly the closer the software gets to perfect the larger the chance that it will be misused, eh?
...unless you look a lot like someone who shoplifts...
Ah I get it:
Don't steal stuff, and don't look like other people and you are unlikely to get in trouble
I didn't know ssh-agent on machine A could help you log into machine C from machine B. How does that work given that ssh-agent only binds to a unix domain socket (single host IPC)? Does ssh magically tunnel it? I didn't see anything in the RFC about that when I implemented my ssh client!
It definitely didn't work magically for me when I logged into my work account from my home machine and tried to have it RSA authenticate to my SourceForge account -- it does work from my home account.
Lastly, what makes you think that the kind of wanker that can't trust ssh and makes you bounce through a firewall is going to leave RSA auth on? Eh?
That's what I thought before I read the paper. However you can guess when passwords are typed. One big hint would be lack of an echo. Sure, that might be someone typing a long vi command sequence, or the far end being slow, but the traffic information is only used to help guess passwords, it isn't relied on to actually be 100% accurate!
Same way you normally would? Check out an existing project with "cvs -d user@server:/path/to/cvsroot get projectname"
It works for me under OS X at least. Try reading the CVS FAQ for help. Or any CVS FAQ google turns up.
Setting up your own repository is a bit harder. One way around that is to open source your project and have SourceForge set up a repository for you. You get free off site backups that way :-)
CVS has some big flaws, but it is quite nice. I haven't seen a source code control system that didn't have problems. Anyway I think you should look at subversion they are directly addressing CVSs big flaws. It looks like the authors know a lot about CVS, and like CVS, so whatever they build will probably not suck more then CVS...
...except they have a lot of dependence on Apache and the DAV module. So that part at least sucks differently then CVS, and maybe more. Hopefully subversion will get far enough along that I can find out for myself though.
Bitkeeper does look cool. I don't think subversion can do the same sort of hierarchy of repositories that bitkeeper can. Anyway I don't think McVoy wants to be the next SourceForge (are they making money?), he want to be the next PerForce, CodeSafe, or whoever else has made a ton of money directly off version control software.
No, unless by "robust" you really mean "alpha quality, not trusted to be self hosting yet". Try again in six months :-)
Not really, even the command line ssh sends the ssh password in a single CMSG_AUTH_PASSWORD packet. The attack isn't talking about that password. It is talking about passwords you use after you are logged in. Say by running sudo, or ssh'ing to another host (maybe one that a firewall prevents reaching directly).
You could avoid this by cut n' pasting your password, but that has other problems (like forgetting the password was the last thing in the buffer and pasting it somewhere you don't want it!), and is just ugly. The ssh client could buffer multiple characters, but it doesn't know when it should do that. Most of the time having that done would suck huge. The ssh client could also pad packet sizes, but that only helps so much.
A real answer would change the ssh client, the ssh server, the ssh protocol, and anything that prompts for a password. Even if you assume that "anything that prompts for a password" all uses libc's getpass that is still a whole whole lot of work.
What would the change do? It would have getpass do a tty ioctl letting the master side of tty know we are in "read password mode". The master side of the tty would be sshd in this case, it would send a new ssh message to the client asking for all keys typed to be buffered until the end line char, interrupt char, or other special control chars are typed, and transmit the whole buffer. The ssh client's role should be obvious.
Come to think of it, that sounds alot like the telnet line mode, so maybe the tty driver has an appropriate mode, but a quick look turned up nothing.
They are talking about passwords entered after you log in. To things like sudo, or SQL front ends, or other crap like that. Or loging into another machine.
Modern in what way?
You are right, the other microcontroler IP stack I know of is quite old (late 80s, or at least pre-1992). Steve Holmgrin's (may be misspelled) IP stack for some random microcontroler that had 8K of OTP ROM and 4K of RAM, and I think a 6502 like instruction set. He wrote a small FORTH like language, and then a IP stack including TCP, and some of the small servers (chargen, quote). It didn't drive an ethernet, it did SLIP (I'm pretty sure it predated PPP).
As I recall one of his proof of concepts was to replace the serial part on an ADM3A terminal, once done you could hook it up to a terminal server with SLIP, and when you turned on the terminal you got a TELNET> prompt. Too bad he didn't have enough RAM to let you switch between multiple telnet sessions.
As I recall Hariss Semiconductor bought the implementation, and as far as I know never did anything with it.
100 to one oversubscription for DSL subscribers isn't uncommon. People really use their line less then you think. 10 to one oversubscription is actually pretty nice.
Web usage is a really good fit here. Click, use a ton of bandwidth for 3 to 8 seconds, then read for five minutes. Click again...
Someone downloading ISOs of the latest Linux distro will throw that off for an hour or two, but that's not too bad as long as only a few people do it at once... Of corse someone trying to run an ISP off their 2Mbits will hurt you :-)
The real problem is affording a T1 to an ISP that lets you resell bandwidth, or funding a lawyer to assert that your co-op is not a reseller since there is no money exchanged between the co-op members...
Actually UUCP over TCP is a really good way to get net news if you only have one feed. It is much more tolarent of high latency then NNTP.
Other then that it doesn't have that much use any more... at least not that I can think of off the top of my head.
It varies a lot, no name 80min CDRs bought in nominally overpriced retail stores are about $25 for 50 CDRs (on a spindle, not in cases). Frequently those come out to $0 with a mail in rebate (that takes 2-3 months to process, and many people don't send it). I have seen 50 CDRs for $10 with cases though, and other places selling them closer to $1 each.
Since I'm not in a hurry (it normally takes me about three weeks to take enough pictures to fill a CDR), I buy CDRs when I see them for "about free", and I burn a set of pictures onto two different CDRs, different brands if I can. I figure that reduces the chance of a bad batch taking out my pictures. Some time soon I'll be doing the off site storage thing, but I'm not yet.
I noticed it, and figured you could convert back to your own currency.
Taxed for death too.
As far as I know, me. Twice.
I bought a SCSI CD Burner (for my Unix box) referb at a "good price" because it was cheap and I thiught I wanted one. It didn't go into a machine for six months (give or take). It also didn't work once put in, which makes me feel extra dumb since I can't really return it under the 90 warente if I didn't look at it for twice that long...
I also bought another drive (Firewire for my laptops). That one I did use almost right away. So far I have only burned two music CDs, both of which contain only music I owned at the time, and still own. I have burned a pile of CDs with copyrighted pictures as well. Of corse since they are copyrighted by me I'm going to say that was quite legal.
Right, so I should pay money to the music cartel to store pictures of my dog? I don't think so. They got the DCMA, if that hunk of un-constitutional crap can't protect them, I really don't care. They should repeal that before they go begging for another way to screw 100% of the people to catch the 75% they think are riping them off.
$15 according to the article (and I have seen the "normal" DVD recordables for $50 for 5). Not all that costly, even if it isn't price competitive with CD-R (which I have been buying at $20 for 50, with a $20 rebate).
I still want to know what the difference between DVD-RW and DVD+RW is, and who thought it would be a good idea to name them so closely.
Hmmm, I think you may be right. I don't know enough about the normal SSH code to check, but taking a quick look at mine the password is in a single CMSG_AUTH_PASSWORD packet not the CMSG_STDIN_DATA packets, so I expect everything sends the initial packet as a single chunk. The only thing open to this attack would be passwords sent during a session.
Which means either the authors of the paper took into account the difficulty of guessing what input text is (or might be) the passwords, and we are all in a (modest) bit of trouble, or something fishy is going on here.
The ssh client doesn't know in general when you are typing a password, but it does know in specific when you are typing the one to start the session. My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password. I expect a lot of other window system dependent ssh clients work the same way.
Or entering passwords for things on the remote host (like things on the serial devices). However the attacker needs to somehow know when you are entering this other password. It won't normally be easy for them to know. Unless they have created a problem, and called you to ask you to fix it... you can type you password locally and paste them into the ssh client, but that seems painful, and it also mean you password is in the local cut buffer which is an attackable location (and also you might paste it somewhere you didn't want to...). Blech.
Actually there have been a number of (frequently ill-considered) non-standard ways to open a file by i-number. Sun's backup co-pilot was the first I had heard of (in '91), but it turns out there were a lot before it, and after. Most allowed only root to do it, but some did not. The ones that didn't broke some of the Unix security semantics.
Also you can get to a file a few other ways without involving it's name. Like recvmsg, regrettably something else had to know a name to the file at one point for them to work (that name may be gone now though -- all of the names may be gone in fact).
Um, yes it does. I just mailed myself FontExamplar.app, and double clicking on it did run it (after telling me it might have a virus and stuff, then I clicked the "What's a virus, please bone me" button and it ran).
And we know that under Mac OS X.0.4 Mail.app doesn't hide extensions, but I'm not sure that OS X.1's Mail.app won't. I would expect it to follow the finder setting. We also don't know what OS X.1 does with more then one "extension", does it strip them all? None? Or just one? I'm guessing just one, but I'm aware that it is a guess.
That doesn't really mean autoconf/configure is a magic bullet. If I write something that uses kqueue and want to port it to Linux (or Solaris) I have to write non-kqueue code. Autoconf will merely figure out which part of my code to enable or disable, it won't take my kqueue code and make it work elsewhere.
So to use the new interfaces, and be portable I have to write code to use the old interfaces. If the old interface doesn't exist I have to disable part of my application's features.
Using kqueue as an example (once again), if I have an X program using a toolkit that lets me write my own file I/O callbacks and timeouts, but no callback for wait4 or the like, but I want to know when a child process exits, I don't have that many good choices. I can use kqueue which pretty trivially converts a process exit into file I/O (or at least a read ready event, plus a call to kevent rather then read). Then it will only run on two or three Unix systems. I can write a SIGCHLD handler that sets a flag and use a periodic timeout, but then I either burn CPU, or it takes too long to see the event. I could skip the SIGCHLD handler and just call wait4 with W_NOHANG in the timer callback. That has roughly the same problems that the SIGCHLD answer does.
I could write both, and then use autoconf to decide which to compile. Then I have to test both. The documentation has to say "On some platforms there can be a noticeable gap between the tracks, on others you get no gap in the tuneage".
In other words it's not that doing the code right helps, it's doing the code twice, and it only helps so much.
Last comment: yeah, the stuff that already uses autoconf ports easier then the rest of it because someone already did a lot of work to make it run multiple places, and may have decided to ditch features to avoid more problems.
Yeah....except the PC games have more strategy (at least real-time strategy) games then consoles, and more kinda odd ball games (theme park simulator anyone? -- I don't think that is on any consoles, but I could be wrong).
It also at least use to be the case that PCs had better force feedback stuff (the DreamCast's idea of force feedback is a shaker from a pager).
Now if "all" I wanted was some Kick-Fu games (and there is nothing wrong with that -- that's why I have a DreamCast!), and a few gun games, a console makes sense. If I want Civ-III then a console isn't so hot.