Graphics:
OpenGL, if you accept vendor extensions, exposes comparable hardware accelleration to DirectX. The programming paradigm is different between the two, but they're both adequate.
Sound:
DirectSound is way more powerful than SDL or SDL_mixer, which (SDL_mixer) has a seriously underpowered interface. It's adequate only for very rudimentary sound capabilities.
Input:
DirectInput is a big pain in the ass to use. It's extremely powerful though, supporting all kinds of whizz-gizzers like force feedback and so on. SDL has a more limited feature set, but is super-easy to use. I consider the extra features provided by DirectInput unimportant.
Network:
SDL provides you with a portable sockets interface. I've never used DirectPlay, but it is much higher level.
Timing, Threads:
SDL provides you with portable (high-ish resolution) timing and threading. DirectX does not, but the Win32 API does.
To summarize and generalize: SDL provides fewer features than DirectX, but tends to be easier to learn/use (plus it's portable). Which may very well be what you want.
cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.
Public service announcement
If you're in windows and trying CVS, check out tortoise
I used write firmware for a company that made high end injet printers and here's what I learned about this there:
1) HP replacement cartridges contain not just ink but also the jets themselves. While this makes the cartridges more expensive it means if you get clogged jets or burned out heaters, (both of which WILL happen) just buy a new cartridge rather than sending your printer off to be repaired (a la Epson). Hell, if you know what you're doing, you can even clean them yourselves, if they're readily acecssible (Which they tend not to be unless they're part of the cartridge, though this obviously isn't necessary)
2) Additionally the circuitry is able to keep track of how much ink is in a cartridge. This allows the cartridge to know its own capacity and allows the software to let you know when it's empty. Depending on how you use your printer it may not matter, but if you're queuing up large print jobs and then leaving it to churn away, it is a benefit to know when you're out of ink, rather than putting stripes vaguely resembling your output on 200 sheets of paper.
3) For high end color printers, if you're actually doing high end stuff ideally the print cartridge should be able to report information about the color profile of the ink in it. An alternative is to have each print cartridge come with a little card that you feed to the printer - that's what my former employer does, but that means you have more parts and more plastic, plus it adds another step to the process which people can screw up.
The biggest difference between unsolicited bulk snailmail and unsolicited bulk email is who pays for it. In email both parties pay for it (as well as some intermediate parties which have no involvement etiher way), whereas with snailmail it's the sender who pays postage.
Yeah, if you're not going to screw up, then you don't need any type checking at all! However, if you want to compiler to tell you in the unlikely event that you or someone else using your code DOES screw up, static type checking is a great thing, and this allows you to do more without giving up that benefit.
But I'd rather have salty soup than starve to death. Similarly I'm not going to neglect a significant component (attending live performance) of a big part of my life (music) just because some shithead is charging $4.00 more than I think is reasonable.
So to rebutt "Beauty and the Beast won Best Film, so maybe Spirited Away could" you say "nononono, Spirited Away is way better than Beauty And The Beast!"...
Okay, the reason it won't work isn't that the microphone is shitty, which it probably is. It's not that the computer isn't fast enough (which it probably is).
The problem is that the microphone is not near your ear.
In order for noise cancelling speakers to work, they need to maintain a constant and known spatial relationship with your ears relative to the sound source. The only practical way to do this is to locate them at the ear (that's how noise cancelling headphones work).
Thus unless the laptop's microphone is at the loci of both your ears, you're not going to do any better than just add to the racket.
I think the reason "foo" is not of type string instead of type const char[] is that one of the design principles of C++ is: if you don't use a feature, it doesn't affect you. Which means that "foo" has to be the same type it used to be.
Backwards compatability may have done C++ a lot of good in the first 5 years, but now I think it hurts more than it helps.
1,3,5: A common argument for why I should use linux is exemplified here: "It will do most of the things you want to do nearly as well as you can do under what you're already using". I don't find that argument very compelling. (I am being very generous leaving 5 in this category, as the gimp does NOT fare very favorably to Photoshop in any comparison I've heard made by anyone who actually knows how to use Photoshop well)
6: I have tried my code on linux. It works. Not that there's any reason why it shouldn't, using OGL and SDL. Make is one of the main reasons I don't want to develop under linux. I've never had to spend 6 hours fucking around with any other project file just to get it to a) autodetect dependencies, and b) put the intermediate files where I want them. I don't like vim very much, but I'm plenty comfortable in emacs, and while I do find it perfectly usable, I find prefer Microsoft's development environment.
Your assumption that my preference is borne out of ignorance is invalid.
I accept that with the introduction of the desktop environments X has improved to the point where it may well be a very usable interface. How long will it take before I'm as comfortable in it as I am on an UI I've used variants of for the last 7 years? And how much better is it?
I guess I should add that I do have a linux box, that I use for the stuff that I think it's better at - irc, email, firewall, and a bunch of server stuff.
Developing games and other graphicsy stuff (in my free time)
#2,#4 would be as easy or easier in linux. #1 and #5 would be limited/impossible. I really like Trillian Pro for #3, and I doubt there's a Jabber client that approaches its level of usability. And as for #6, while I do write portable code, I actually quite like Microsoft's development environment.
I also like Window's GUI. I haven't tried X for a few years, so I'm sure it's less awful, but I haven't heard anyone even claim it's surpassed anything but its awful past.
Buffer overflows go away because you can safely allocat 256 bytes per string, and no string can exceed that.
Because you can't even fit a paragraph as a single string.
If you really wanted to cache the result of your strlen, you could have your string class do that, IN AN INT. An extra 3 bytes per string probably isn't going to kill anyone.
Collaborative filtering sucks. Your idea is valid, just that's not the right recommendation technology to use. Collaborative filtering has a tendency to say "You like A, B, and C, and everyone likes U2, so here, try some U2". Which is doubly useless; not only is it dumb (in that it can give essentially the same recommendation to everyone), it also is a worthless recommendation - you already know whether you like U2.
For more examples spend any amount of time on cdnow or allmusic - generally it's smart enough to recognize coarse genres, but rarely does it give a truly insightful or, indeed, helpful recommendation.
This may be true of some genres, but it's absolutely not true for electronic music. I would say at least half of music I listen to is on relatively small labels. Though it's also not uncommon for larger labels to pick up the distribution for some albums they think are going to be good - but they certainly don't own the rights. (For instance: Boards Of Canada - Music Has The Right To Children has logos for the labels Skam (tiny), Warp (medium), and Matador (medium) on it. According to the internet none of these are riaa members.) In a lot of these cases it's not so much that their lack of overwhelming commercial success is because if their lack of technical skill or creativity, but because they're styles don't happen to coincide with what the masses want.
Also, the hardware vendors sure don't want to pay for mp3 forever so it's in their interest that another format replaces it. (Even if it takes a long time - like a decade or even longer.)
In a bit more than a decade, the mp3 patent will have expired, so it's more the 3-5 year timeline that this makes sense for.
The funny thing about that is that you seem to think that if they stole some personal or business (ie, private) data from your computer, and you tried to sue them, this EULA would make a whit of difference. It wouldn't.
Slashdot Mirror
Graphics:
OpenGL, if you accept vendor extensions, exposes comparable hardware accelleration to DirectX. The programming paradigm is different between the two, but they're both adequate.
Sound:
DirectSound is way more powerful than SDL or SDL_mixer, which (SDL_mixer) has a seriously underpowered interface. It's adequate only for very rudimentary sound capabilities.
Input:
DirectInput is a big pain in the ass to use. It's extremely powerful though, supporting all kinds of whizz-gizzers like force feedback and so on. SDL has a more limited feature set, but is super-easy to use. I consider the extra features provided by DirectInput unimportant.
Network:
SDL provides you with a portable sockets interface. I've never used DirectPlay, but it is much higher level.
Timing, Threads:
SDL provides you with portable (high-ish resolution) timing and threading. DirectX does not, but the Win32 API does.
To summarize and generalize: SDL provides fewer features than DirectX, but tends to be easier to learn/use (plus it's portable). Which may very well be what you want.
Let's see what happens if we phrase that a little differently:
Find a very difficult problem (running a realtime simulation across an imperfect network) and improve your attempted solution to it.
Or how about this: Look for areas in which improvement to your product could actually provide notable gains for the user, and improves those areas.
Pretty evil.
cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.
Public service announcement
If you're in windows and trying CVS, check out tortoise
That seems like the best of both worlds. I didn't realize anyone did it that way; thanks!
I used write firmware for a company that made high end injet printers and here's what I learned about this there:
1) HP replacement cartridges contain not just ink but also the jets themselves. While this makes the cartridges more expensive it means if you get clogged jets or burned out heaters, (both of which WILL happen) just buy a new cartridge rather than sending your printer off to be repaired (a la Epson). Hell, if you know what you're doing, you can even clean them yourselves, if they're readily acecssible (Which they tend not to be unless they're part of the cartridge, though this obviously isn't necessary)
2) Additionally the circuitry is able to keep track of how much ink is in a cartridge. This allows the cartridge to know its own capacity and allows the software to let you know when it's empty. Depending on how you use your printer it may not matter, but if you're queuing up large print jobs and then leaving it to churn away, it is a benefit to know when you're out of ink, rather than putting stripes vaguely resembling your output on 200 sheets of paper.
3) For high end color printers, if you're actually doing high end stuff ideally the print cartridge should be able to report information about the color profile of the ink in it. An alternative is to have each print cartridge come with a little card that you feed to the printer - that's what my former employer does, but that means you have more parts and more plastic, plus it adds another step to the process which people can screw up.
Also it only does bounds checking in a debug build.
The biggest difference between unsolicited bulk snailmail and unsolicited bulk email is who pays for it. In email both parties pay for it (as well as some intermediate parties which have no involvement etiher way), whereas with snailmail it's the sender who pays postage.
Is this testing whether I'm a replicant or a lesbian?
Yeah, if you're not going to screw up, then you don't need any type checking at all! However, if you want to compiler to tell you in the unlikely event that you or someone else using your code DOES screw up, static type checking is a great thing, and this allows you to do more without giving up that benefit.
But I'd rather have salty soup than starve to death. Similarly I'm not going to neglect a significant component (attending live performance) of a big part of my life (music) just because some shithead is charging $4.00 more than I think is reasonable.
So to rebutt "Beauty and the Beast won Best Film, so maybe Spirited Away could" you say "nononono, Spirited Away is way better than Beauty And The Beast!"...
Okay, the reason it won't work isn't that the microphone is shitty, which it probably is. It's not that the computer isn't fast enough (which it probably is).
The problem is that the microphone is not near your ear.
In order for noise cancelling speakers to work, they need to maintain a constant and known spatial relationship with your ears relative to the sound source. The only practical way to do this is to locate them at the ear (that's how noise cancelling headphones work).
Thus unless the laptop's microphone is at the loci of both your ears, you're not going to do any better than just add to the racket.
I think the reason "foo" is not of type string instead of type const char[] is that one of the design principles of C++ is: if you don't use a feature, it doesn't affect you. Which means that "foo" has to be the same type it used to be.
Backwards compatability may have done C++ a lot of good in the first 5 years, but now I think it hurts more than it helps.
1,3,5: A common argument for why I should use linux is exemplified here: "It will do most of the things you want to do nearly as well as you can do under what you're already using". I don't find that argument very compelling. (I am being very generous leaving 5 in this category, as the gimp does NOT fare very favorably to Photoshop in any comparison I've heard made by anyone who actually knows how to use Photoshop well)
6: I have tried my code on linux. It works. Not that there's any reason why it shouldn't, using OGL and SDL. Make is one of the main reasons I don't want to develop under linux. I've never had to spend 6 hours fucking around with any other project file just to get it to a) autodetect dependencies, and b) put the intermediate files where I want them. I don't like vim very much, but I'm plenty comfortable in emacs, and while I do find it perfectly usable, I find prefer Microsoft's development environment. Your assumption that my preference is borne out of ignorance is invalid.
I accept that with the introduction of the desktop environments X has improved to the point where it may well be a very usable interface. How long will it take before I'm as comfortable in it as I am on an UI I've used variants of for the last 7 years? And how much better is it?
If the browser succeeded in making the OS irrelevant, why are we even talking about the OS?
Hint: Because it's not irrelevant.
I guess I should add that I do have a linux box, that I use for the stuff that I think it's better at - irc, email, firewall, and a bunch of server stuff.
- Playing Games
- Web browsing
- IM
- SSHing to a linux box for IRC & email.
- PhotoShop
- Developing games and other graphicsy stuff (in my free time)
#2,#4 would be as easy or easier in linux. #1 and #5 would be limited/impossible. I really like Trillian Pro for #3, and I doubt there's a Jabber client that approaches its level of usability. And as for #6, while I do write portable code, I actually quite like Microsoft's development environment.I also like Window's GUI. I haven't tried X for a few years, so I'm sure it's less awful, but I haven't heard anyone even claim it's surpassed anything but its awful past.
Buffer overflows go away because you can safely allocat 256 bytes per string, and no string can exceed that.
Because you can't even fit a paragraph as a single string.
If you really wanted to cache the result of your strlen, you could have your string class do that, IN AN INT. An extra 3 bytes per string probably isn't going to kill anyone.
Collaborative filtering sucks. Your idea is valid, just that's not the right recommendation technology to use. Collaborative filtering has a tendency to say "You like A, B, and C, and everyone likes U2, so here, try some U2". Which is doubly useless; not only is it dumb (in that it can give essentially the same recommendation to everyone), it also is a worthless recommendation - you already know whether you like U2.
For more examples spend any amount of time on cdnow or allmusic - generally it's smart enough to recognize coarse genres, but rarely does it give a truly insightful or, indeed, helpful recommendation.
This may be true of some genres, but it's absolutely not true for electronic music. I would say at least half of music I listen to is on relatively small labels. Though it's also not uncommon for larger labels to pick up the distribution for some albums they think are going to be good - but they certainly don't own the rights. (For instance: Boards Of Canada - Music Has The Right To Children has logos for the labels Skam (tiny), Warp (medium), and Matador (medium) on it. According to the internet none of these are riaa members.) In a lot of these cases it's not so much that their lack of overwhelming commercial success is because if their lack of technical skill or creativity, but because they're styles don't happen to coincide with what the masses want.
A necessary qualifier would be "You agree not to compete with us in any markets that we are actively pursuing."
Why? If someone else can offer the same songs for cheaper, you're doing business wrong.
With RAM at $100/GB, it's almost time to kill off paging to disk. Besides, it runs down the battery.
I agree with you except that having a gig or more of RAM won't exactly do wonders for your battery life either.
Also, the hardware vendors sure don't want to pay for mp3 forever so it's in their interest that another format replaces it. (Even if it takes a long time - like a decade or even longer.)
In a bit more than a decade, the mp3 patent will have expired, so it's more the 3-5 year timeline that this makes sense for.
All in all a terrorist attack could be expected to kill hundreds and close the system for weeks.
That's better than our airline system
The funny thing about that is that you seem to think that if they stole some personal or business (ie, private) data from your computer, and you tried to sue them, this EULA would make a whit of difference. It wouldn't.