I enjoyed Celda as well. Unfortunately, it's pretty much the only Gamecube game I've truly enjoyed so far (enough so that I played it entirely through). I admit that I only have a small library of Gamecube games, but that library does include Mario Sunshine and Metroid Prime, both of which were extremely disappointing to me. In fact, Metroid was extremely disappointing, considering that it was the reason I bought my Cube. Luckily, Celda made up for Metroid and made me not totally regret the purchase.
Right now, I've been playing Mario Golf, and it's enjoyable, but it's certainly not going to hold my attention for more than another week or two (just up until Soul Calibur II hits the XBox, at which point Mario Golf will go back on the shelf with Mario Sunshine and Metroid Prime, to eventually be sold or traded away).
For completeness, my Cube library consists of:
Mario Sunshine (came with the Cube)
Metroid Prime (disappointing)
Wind Waker (and the Zelda: OOT remake)
Rogue Squadron II (I was pretty disappointed with this one, so much so that I don't care that RS3 is coming soon)
Skies of Arcadia. I liked this one, but Knights of the Old Republic made me put it off to the side, and I don't see me picking it back up any time soon. Also, this was almost a straight port from the Dreamcast, so I'm not sure I'd really consider it a win for the Gamecube
Mario Golf. After Celda, this would be my best Cube game. It's fun to play through a round or two of golf, and I guess that's a plus because I can sit down and play for fifteen minutes or half an hour and then put it away. However, I don't anticipate it holding my attention long.
Any suggestions on what would be some good Cube games to pick up? I don't have time to really play something like Animal Crossing (plus, I played the old Harvest Moon on the SNES, which seems to be similar in style to AC, and wasn't that enthralled), and I generally don't have enough friends over at my place to make something like Smash Brothers: Melee worth a purchase (and when I do have enough people over, we generally will play Halo on two XBoxs and TVs). And no cross-platform games, please. I'd rather play those on my XBox, though if there's a good game that's only on the Cube and PS2, I may consider picking it up for the Cube (no PS2, and no interest in a PS2).
Are future submissions always going to have some sort of character assasination buzzwords attached to them as well?
Haven't past submissions already set that precedent? Go back and look at nearly any Microsoft submission, or SCO submission, and get back to me on that. Now, the thing is, if you want objectivity you have to take the good with the bad. That means that if you don't want to see an Open Source (err, I mean Free Software) "luminary" like RMS called a zealot (which he clearly and obviously is, and I would bet he would say that himself), then you should be equally incensed when the same is done against Microsoft or SCO, regardless of whether or not you feel they are the "bad guys". If, on the other hand, you don't want to accept that, then don't pretend that the submissions should be objective.
Personally, I agree with you. These kinds of things should be edited from the submissions, or if the editors don't want to edit user submissions then they should at least choose one of the hundreds of similar submissions that do not have inflammatory remarks and such off-hand comments. At the same time, I think that this should be applied across the board, and not just to articles dealing with the "good guys" (my own opinion differs on who is the "good guys", but that's irrelevant).
Can I say more? This whole Outlook/Exchange thing has been one long nightmare as a provider. This is the best news I've heard in a long time. Just hoping it is true!
It's not, of course. Outlook Express != Outlook, and Outlook Express does not interface with Exchange. Outlook is not going away, and will not any time soon.
"Full version"? You say that as though Outlook Express is "Outlook Lite", based on the same codebase but with fewer features. It's not. The two are completely separate.
So here's where the problem begins. Should people make free open software on their own time and do it for the good of the community, or should companies sell closed software that works better?
Why not both? If you enjoy writing software on your own time and giving it away, more power to you. I've done that myself once or twice (though I've tended to prefer the BSD or MIT/X licenses over GPL). At the same time, it takes a lot to make professional-grade software, and if that means a company paying people to write it, test it, and sell it, then so be it. So long as people are buying, where's the harm?
I think what a lot of people don't consider is that with p2p, all software becomes free whether it's legal or not. That is a totally different issue and lets not get all worked up over it, but a good amount of the software that home desktop users have on their windows boxes is pirated, so the free linux idea doesn't mean much. However, in a business situation this is very different and I think that's where linux should be focused for now.
I think you overestimate the popularity of p2p file sharing. Most p2p'ers I know are pretty technically savvy (maybe not in the "linux geek" sense, but at the very least in the "gamer geek" sense). At the same time, I think I'd have to disagree with you about a large amount of home desktop software being pirated. For the average Joe or Jane, they use what comes with their computer, or the $20 specials at Best Buy they find while looking for the latest Britney CD. What pirated software they may have generally comes in the form of borrowing CDs from friends or work, not from downloading via p2p. While that's still piracy, it's a pretty minor form because by its nature it's not widespread. Just as the FBI won't bother with fraud cases that don't garner more than a grand or two in damages, the powers that be (BSA) tend not to worry about "small time" pirates like that.
As for linux targetting businesses, "free" isn't always enough. There needs to be good, high quality support as well as accountability. Businesses measure in "total cost of ownership" because they know that the purchase price (even if that price is free) is just the tip of the iceberg.
She commented that "How would I have known to click 'k3b' to burn CDs?" I replied, "How would you have known to use Nero?"
Well, first off, the link is generally called "Nero Burning ROM", which gives a good impression that it's what you'd want to "burn" a CD-"ROM". Second, either you bought Nero and installed it (by simply putting the disc in the drive and clicking Next a few times), or it came with your PC and was advertised both at the store and with papers in the box the machine came in. What is "k3b"? What does it stand for? How would I associate that with burning a CD? Make the name a little more descriptive (cdrecord is a good name, but commandline recording won't suffice), "advertise" it as the app to use to burn CDs, and people will have no problem finding it.
How would a newbie go from "how do I get this video card to work on $distro" to a Google query that returns a solution in the first 20 hits? Please document your thought process.
This scenario has happened quite often in #linux. It goes something like:
<user> How do I get this video card to work on $distro? <me> What have you tried so far? <user> Nothing, really, I'm still too new to this. <me> Okay, try searching for "$distro videocardtype" (or something similar, depending on the question and the time I've taken to do a google search) at www.google.com, and see what comes up. <user> Thanks (user goes off, does the search, and helps himself)
Like the original anonymous coward said, IRC is not a place for others to do your work for you (well, there are plenty of such channels, but #linux isn't one of those). We'll give you a point in the right direction, and if we can we'll help you out when you've exhausted other resources, but we shouldn't be your first resource except for a point in the direction of the docs.
Really, how do you expect newbies to learn if you just keep giving them the answers? They need to know how to find what they need in the ample documentation available. One day, Linux will be easy enough to use that all of that will be unnecessary, but that day is still far off.
Oddly enough, I think doing so makes it sound a tad more rude somehow. But, seeing as how you were being very pedantic and annoying already, this probably isn't of import.
But I strive to be pedantic and annoying in an agreeable manner! And I agree, my sentence structure was crap.
Of course it was painfully awkward. You can't fit "reconnoitered" into that sentence without it being painfully awkward, because it just doesn't fit. That was the point. See how awkward the sentence is when I replace the incorrect word with the meaning of that word?
If, on the other hand, you meant my overusage of commas, you'd be correct. It's a fault of mine (along with extraneous parenthetical quotes) that I'm constantly fighting against.
Nope. Locking can only be done on an open file. See flock(2) and fcntl(2).
Oops. My fault:) I was thinking more along the lines of a critsec or mutex to avoid cross-thread race conditions, and it totally slipped my mind we were talking about the filesystem. Hehe. Anyway, I was advocating not writing your code this way, unless you can't avoid it. However, I'm not sure it's too big of an issue. You'll still need to catch exceptions on the filestream open call anyway, in case something else fails, and the race condition of finding the file there but having it removed before you can open it would truly be an exceptional issue. My main concern is using the exception as flow control. By checking for existence first, you'll know if you shouldn't even bother with the call to open the file. If you think the file is there and it turns out it's not, that's an exception. If you think the file isn't there and it turns out it is, your rectification code is where that should be handled.
I assume you meant that you reckon, or think or assume, that it might offend, and not that you reconnoitered, or made a preliminary inspection or scouted, that it would offend ("recon" being an accepted shortened form of "reconnoiter" in the verb sense you used, or "reconnaissance" in the noun form which you didn't).
That method is completely wrong. It contains a race condition: the file can be deleted or renamed after it is checked but before it is opened.
I didn't say it was right, just that it had been done. And of course you can use locking methods to mitigate the race condition, though by doing so it's unclear whether it's still a better approach than just catching the exception, performance-wise.
Ah, but in practice, exceptions are used for just such not-so-exceptional circumstances. This is not a choice that can be made by Java applications programmers since a bajillion Java API classes work this way. One could argue that this is a good thing, that checking for things like file not found in a catch block instead of checking return values inline can lead to cleaner code.
If Java forces you into using non-exceptional exceptions and using exceptions for program flow, then Java is poorly designed (I'll admit that I haven't used Java in some four years, though I have been using C# for the past 6 months and I've not yet run into a scenario in C# that requires me to handle an exception for a non-exceptional error case). And as far as making the code cleaner, I disagree. The extra syntax you need to handle an exception is clutter, and can put significant space between the error handling code and the code that caused the exception, making the flow harder to follow. Most importantly, however, exceptions are expensive. In C++, for example, an exception costs you around 1000 processor cycles. Compare that to two or three cycles to check a return value, and you'll see why exceptions should only be used for exceptional cases. Java and C# may handle exceptions differently so that they're not as costly, but they'll still be more costly than a simple comparison and jump.
You may think I'm splitting hairs, but you'll notice a marked performance increase if you rewrite your code to use normal flow control constructs to control the flow of your code, rather than using exceptions.
I'd be interested in anyone's favorite references on when it is better to report non-success status in return codes, and when it is better to throw an exception. That is a class design issue that comes up all the time.
I don't have any references, just this rule of thumb: If an error is unexpected, then it's exceptional and should be handled with an exception. If it's an expected error, then it should be handled with a return code. To go back to the example of opening a non-existent file that I used in my original post, it's pretty obvious that a file not existing is non-exceptional (now, if the file that's missing is a critical config file that your application requires and can't generate on the fly, you should throw an exception, but the library method to open a file stream should not). What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream. Personally, I wouldn't write a method in that manner, preferring to return an error code if opening the stream failed so that it's not necessary for the user to make an existence check first.
Exceptions are one of the more fundamental (and useful) features of the Java language. Whether or not they are "in your face" (as far as source code is concerned), they exist and have the potential to greatly change the flow of your program. Considering them "rare" is a tremendous disservice to those learning how to use Java in a productive manner. I hope that this is simply the reviewer's choice of language, and not a flaw in the book iteslf.
The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.
I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.
The problem I've generally had with books about programming languages is that they almost invariably start out with several chapters (anywhere from one to five) dedicated to concepts that either you should already know, or that you should learn elsewhere. If I have a library of 50 computer books, I only want one book that covers object oriented programming concepts, for example. I don't need nor do I want all 50 to cover OOP. Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts. Rather than dedicating the first 200 pages of a 600 page book to that and selling for $50, they should cut those pages and sell the 400 page book for $30.
Yes, I understand that beginners need books too, but even they don't need a discourse on object oriented programming every time they buy a Java, C++, or C# book. Why can't we have one or two definitive books covering basics, and get rid of that stuff in the rest of the books?
Well... we all knew that it would happen, halo is becomeing the next fourm for the acadamy awards... "And now to present the award for best Halo performance is Keanue Reaves." "Thank you, here are the nomonies..."
Leave it to Keanu Reeves to butcher the word nominees at the Academy Awards...
Is there going to be a Mars probe launched on this date of closest approach
Launching a mission on the date of closest approach would be poor timing. To take advantage of this, missions would need to be launched prior to that date (how long before can be figured out, but I don't know the data to do so). If you launch on the day when Mars and Earth are closest, you'll immediately begin chasing Mars and the trip will not be optimal. If instead you launch before hand, you're travelling towards mars while it's travelling towards you. The rate of movement may be so minimal that it won't make a difference, but I don't know.
After 10 years of Windows NT technology (yeah, it's built into W2K and XP too), Microsoft has failed to gain even an appreciable share in the Intel server market.
Just a small nitpick. XP is not a server operating system. It's analogous to Windows 2000 Professional, a workstation OS. If you're talking about competition in the server space, you should change "XP" to "W2K3".
Secondly, I have yet to be shown why I need this technology. Which goes right to the point of my statement: "I don't think I will be warming up to Mono and C# any time soon." I have not been shown why I should care. I didn't say "Man, Microsoft sucks dick!!! W00T!!" or something assinine like that. Nor was it implied. In fact, it's people like you that seem to be drawing these conclusions on your own.
That's all you had to say. You don't see C# being useful for you, fine. That's good enough for me. But when you just say, "I won't be warming up to Mono and C# any time soon," without adding something like, "because I don't see any need for them," or similar, it's not a far reach for us to assume your reasoning is, "because I hate/fear Microsoft," being that this is Slashdot after all.
Thirdly, I'm not sure how it was "unnecessary commentary." Dashboard is a program. It implements a certain idea through a certain means. Both the idea and the means are highly relevant for discussion as developers.
Either the story should have been only about the dashboard program, in which case your Mono/C# comment was superfluous, or you should've mentioned that the Dashboard app was written using Mono, and used that as a springboard to create good discussion about Mono and C#. Instead, you just tacked on an inflammatory statement and caused only flames, not the coherent discussions which were supposedly your goal.
The merits or faults of C# seem to be a relevant topic for the developers section. Since I was interested in hearing other peoples' ideas one way or the other, I threw in that statement to generate some conversation. Seems to have worked in some way or another once you filter out the troll posts.
So you admit to intentionally inciting this? How mature.
You still haven't backed up your position, by the way. Do you have a good reason why you won't like C#/Mono/.NET, or is it just blind Microsoft hating?
Neat stuff, but I don't think I will be warming up to Mono and C# any time soon.
Was this commentary really necessary? This software looks like neat stuff, just as pheared said, so why the barb? Could you at least give a reason for your statement? What, if anything, does it have to do with the article, save that the software in question was written using C# via Mono?
Editors, I know you've explained why you won't edit user submissions before, and I know it's a losing battle to suggest you change, but this is a perfect candidate for editing. That remark had no business being left on the submission, and removing it would not detract from the story one bit. If there has ever been a perfect example of why editors should take their jobs seriously, this is it. Was pheared so unsure of the quality of his submission that he needed to try to stir up debate over Mono and C#, rather than let the story stand on its own? Or worse, were there really no other submissions for this story, or did the editors purposely choose this one submission because of the added barb at the end?
All kidding aside, the more a car weighs, the more it tends to deform objects it runs into, as opposed to being deformed by them.
Ah, the SUV school of auto safety. "Fuck the other guy, I'm going to make it through this accident!" Of course, that flies in the face of all the studies and crash tests done that show that crumple zones work well to absorb the kinetic energy of a crash. As well, more weight means less maneuverabilty. In other words, you're less likely to be able to avoid an accident.
Ever seen an Indy car hit the wall at 200 mph and the driver walks away? Those open-wheel-well cars have bodies about as wide as this "golf cart".
Indy cars also weigh less than half of this glorified golf cart. As well, the ability to handle a crash at 200mph is more about sacrificing the body of the car to protect the driver than it is about being heavier than the wall.
Properly designed crumple zones, good safety restraints, strong brakes, good tires, and a stable suspension do more to protect the driver than weight. In fact, more weight impacts three of the above items.
Safety? It has jet-pilot seat belts and a racing-regulation roll cage; it weighs more than 3,000 pounds, about the same as a Toyota Camry, including 1,100 pounds of Yellow Top batteries under the floorboards as ballast, so it's not tippy on turns.
At what point did "heavy" become synonymous with "safe"? This car is heavier than mine, and it's smaller!
As far as device drivers containing IP, too fscking bad. Your options are these: don't make your hardware so cheap and crappy that device driver code gives away the company secrets
I don't know of anyone who would call nVidia's hardware "crappy", yet they have consistently been able to increase the performance of even older hardware by making algorithmic enhancements to their drivers. You can claim that these enhancements should not be intellectual property, but nevertheless they are, and for a competitor like ATI to get ahold of them would be detrimental to nVidia, its shareholders, and its customers.
or ignore these OSes altogether and suffer one of two fates: users of Free OSes pan your product and company and you lose lots of sales, or someone reverse-engineers your product and writes an open-source driver anyway.
I don't share your confidence in the size of the open source community. You might lose a couple thousand sales, but when 95% of your target audience uses Windows, that's what butters your bread. If by chance that would change in the future, then you would have a point, but that's going to be a long time coming (how many years now have we been told that the open source desktop revolution is "just around the corner?). As far as reverse-engineering goes, I'll go back to nVidia. nVidia had been making hardware for years before they decided to release 3D accelerated drivers for Linux, and in that time no one was able to successfully reverse-engineer their product. Sure, it can happen, but even if it does it's generally a sub-par solution (witness the performance differential between Windows and Linux for the old 3dfx cards, for example).
For Free OSes, there is no one solution to drivers; the open source community has no dictators (at least none that reign without popular support), and anyone or any company is free to come up with any solutions it wants.
I disagree. Taking Linux in particular, if Linus were to decide that minor kernel revisions must be binary compatible with all other kernels in a series, it would become law. If Linus proposed that kernel modules could be closed-source binaries, it would become law (hasn't that already been done?). The point being that compromises can be made to give IHVs a more favorable impression of Linux, and all it would take is some decisions from the top. Yes, if the decisions were unpopular the kernel could be forked, and that's a good thing about open source, but guess which fork would get the hardware vendor support? You can have your version where drivers must be open source. I'll take the one that provides better hardware support.
What we as a community can do, however, is make writing good quality device drivers as EASY as possible for the hardware vendors. Then they will have no excuse not to write a driver for at least the top 3 platform OSes other than laziness.
Exactly! The question is, though, how do you make it easier? Certainly licensing comes into play. If I'm a major hardware developer with significant investments in IP, I'm not going to want to release my drivers as open source. So, I'll target Windows, and I'll target OS X, but forget about Linux. There are ways around the licensing issue, but they create their own set of problems. For example, look at nVidia. The kernel driver they provide for their cards is rather thin, with most of the useful stuff being done in their closed source driver for X. That means you don't get good acceleration for the framebuffer/console, and it means that nVidia has to manage this more complex approach, and it means that they can't use the kernel's DRI architecture, because that would mean putting important IP in the open source kernel driver.
Driver model unification is more than we can hope for, but accomodations can be made via licensing, and by guaranteeing module compatibility across kernels (at least across minor revisions, like 2.4.x) so that IHVs can decouple their driver releases from the kernel release cycle.
Slashdot Mirror
I enjoyed Celda as well. Unfortunately, it's pretty much the only Gamecube game I've truly enjoyed so far (enough so that I played it entirely through). I admit that I only have a small library of Gamecube games, but that library does include Mario Sunshine and Metroid Prime, both of which were extremely disappointing to me. In fact, Metroid was extremely disappointing, considering that it was the reason I bought my Cube. Luckily, Celda made up for Metroid and made me not totally regret the purchase.
Right now, I've been playing Mario Golf, and it's enjoyable, but it's certainly not going to hold my attention for more than another week or two (just up until Soul Calibur II hits the XBox, at which point Mario Golf will go back on the shelf with Mario Sunshine and Metroid Prime, to eventually be sold or traded away).
For completeness, my Cube library consists of:
Any suggestions on what would be some good Cube games to pick up? I don't have time to really play something like Animal Crossing (plus, I played the old Harvest Moon on the SNES, which seems to be similar in style to AC, and wasn't that enthralled), and I generally don't have enough friends over at my place to make something like Smash Brothers: Melee worth a purchase (and when I do have enough people over, we generally will play Halo on two XBoxs and TVs). And no cross-platform games, please. I'd rather play those on my XBox, though if there's a good game that's only on the Cube and PS2, I may consider picking it up for the Cube (no PS2, and no interest in a PS2).
Haven't past submissions already set that precedent? Go back and look at nearly any Microsoft submission, or SCO submission, and get back to me on that. Now, the thing is, if you want objectivity you have to take the good with the bad. That means that if you don't want to see an Open Source (err, I mean Free Software) "luminary" like RMS called a zealot (which he clearly and obviously is, and I would bet he would say that himself), then you should be equally incensed when the same is done against Microsoft or SCO, regardless of whether or not you feel they are the "bad guys". If, on the other hand, you don't want to accept that, then don't pretend that the submissions should be objective.
Personally, I agree with you. These kinds of things should be edited from the submissions, or if the editors don't want to edit user submissions then they should at least choose one of the hundreds of similar submissions that do not have inflammatory remarks and such off-hand comments. At the same time, I think that this should be applied across the board, and not just to articles dealing with the "good guys" (my own opinion differs on who is the "good guys", but that's irrelevant).
It's not, of course. Outlook Express != Outlook, and Outlook Express does not interface with Exchange. Outlook is not going away, and will not any time soon.
"Full version"? You say that as though Outlook Express is "Outlook Lite", based on the same codebase but with fewer features. It's not. The two are completely separate.
Why not both? If you enjoy writing software on your own time and giving it away, more power to you. I've done that myself once or twice (though I've tended to prefer the BSD or MIT/X licenses over GPL). At the same time, it takes a lot to make professional-grade software, and if that means a company paying people to write it, test it, and sell it, then so be it. So long as people are buying, where's the harm?
I think you overestimate the popularity of p2p file sharing. Most p2p'ers I know are pretty technically savvy (maybe not in the "linux geek" sense, but at the very least in the "gamer geek" sense). At the same time, I think I'd have to disagree with you about a large amount of home desktop software being pirated. For the average Joe or Jane, they use what comes with their computer, or the $20 specials at Best Buy they find while looking for the latest Britney CD. What pirated software they may have generally comes in the form of borrowing CDs from friends or work, not from downloading via p2p. While that's still piracy, it's a pretty minor form because by its nature it's not widespread. Just as the FBI won't bother with fraud cases that don't garner more than a grand or two in damages, the powers that be (BSA) tend not to worry about "small time" pirates like that.
As for linux targetting businesses, "free" isn't always enough. There needs to be good, high quality support as well as accountability. Businesses measure in "total cost of ownership" because they know that the purchase price (even if that price is free) is just the tip of the iceberg.
Well, first off, the link is generally called "Nero Burning ROM", which gives a good impression that it's what you'd want to "burn" a CD-"ROM". Second, either you bought Nero and installed it (by simply putting the disc in the drive and clicking Next a few times), or it came with your PC and was advertised both at the store and with papers in the box the machine came in. What is "k3b"? What does it stand for? How would I associate that with burning a CD? Make the name a little more descriptive (cdrecord is a good name, but commandline recording won't suffice), "advertise" it as the app to use to burn CDs, and people will have no problem finding it.
This scenario has happened quite often in #linux. It goes something like:
<user> How do I get this video card to work on $distro?
<me> What have you tried so far?
<user> Nothing, really, I'm still too new to this.
<me> Okay, try searching for "$distro videocardtype" (or something similar, depending on the question and the time I've taken to do a google search) at www.google.com, and see what comes up.
<user> Thanks
(user goes off, does the search, and helps himself)
Like the original anonymous coward said, IRC is not a place for others to do your work for you (well, there are plenty of such channels, but #linux isn't one of those). We'll give you a point in the right direction, and if we can we'll help you out when you've exhausted other resources, but we shouldn't be your first resource except for a point in the direction of the docs.
Really, how do you expect newbies to learn if you just keep giving them the answers? They need to know how to find what they need in the ample documentation available. One day, Linux will be easy enough to use that all of that will be unnecessary, but that day is still far off.
But I strive to be pedantic and annoying in an agreeable manner! And I agree, my sentence structure was crap.
Of course it was painfully awkward. You can't fit "reconnoitered" into that sentence without it being painfully awkward, because it just doesn't fit. That was the point. See how awkward the sentence is when I replace the incorrect word with the meaning of that word?
If, on the other hand, you meant my overusage of commas, you'd be correct. It's a fault of mine (along with extraneous parenthetical quotes) that I'm constantly fighting against.
Oops. My fault :) I was thinking more along the lines of a critsec or mutex to avoid cross-thread race conditions, and it totally slipped my mind we were talking about the filesystem. Hehe. Anyway, I was advocating not writing your code this way, unless you can't avoid it. However, I'm not sure it's too big of an issue. You'll still need to catch exceptions on the filestream open call anyway, in case something else fails, and the race condition of finding the file there but having it removed before you can open it would truly be an exceptional issue. My main concern is using the exception as flow control. By checking for existence first, you'll know if you shouldn't even bother with the call to open the file. If you think the file is there and it turns out it's not, that's an exception. If you think the file isn't there and it turns out it is, your rectification code is where that should be handled.
I assume you meant that you reckon, or think or assume, that it might offend, and not that you reconnoitered, or made a preliminary inspection or scouted, that it would offend ("recon" being an accepted shortened form of "reconnoiter" in the verb sense you used, or "reconnaissance" in the noun form which you didn't).
I didn't say it was right, just that it had been done. And of course you can use locking methods to mitigate the race condition, though by doing so it's unclear whether it's still a better approach than just catching the exception, performance-wise.
If Java forces you into using non-exceptional exceptions and using exceptions for program flow, then Java is poorly designed (I'll admit that I haven't used Java in some four years, though I have been using C# for the past 6 months and I've not yet run into a scenario in C# that requires me to handle an exception for a non-exceptional error case). And as far as making the code cleaner, I disagree. The extra syntax you need to handle an exception is clutter, and can put significant space between the error handling code and the code that caused the exception, making the flow harder to follow. Most importantly, however, exceptions are expensive. In C++, for example, an exception costs you around 1000 processor cycles. Compare that to two or three cycles to check a return value, and you'll see why exceptions should only be used for exceptional cases. Java and C# may handle exceptions differently so that they're not as costly, but they'll still be more costly than a simple comparison and jump.
You may think I'm splitting hairs, but you'll notice a marked performance increase if you rewrite your code to use normal flow control constructs to control the flow of your code, rather than using exceptions.
I don't have any references, just this rule of thumb: If an error is unexpected, then it's exceptional and should be handled with an exception. If it's an expected error, then it should be handled with a return code. To go back to the example of opening a non-existent file that I used in my original post, it's pretty obvious that a file not existing is non-exceptional (now, if the file that's missing is a critical config file that your application requires and can't generate on the fly, you should throw an exception, but the library method to open a file stream should not). What has been done before is to provide two methods. One checks the existence of a file, and will return true or false, and the other opens a stream and throws an exception if the file's not there. In that scenario, you really should check for the file's existence before opening the stream. Personally, I wouldn't write a method in that manner, preferring to return an error code if opening the stream failed so that it's not necessary for the user to make an existence check first.
The problem with exceptions is that they're not so exceptional anymore. Think about it. The name implies that an exception is something that shouldn't have happened (you ran out of memory, a parameter was bad, something just totally blew up). That doesn't mean that you tried to open a file that doesn't exist -- that's not an exceptional case for a filesystem-handling object, because it happens all the time. Exceptions should be used as error handling, and nothing more. If you can clean up after an exception and try again or continue on, great. Otherwise, you should be showing/logging a useful error and bailing out. You certainly should not be basing program flow on exceptions.
I agree that exceptions are a fundamental part of Java and other languages, and they should definitely be covered by any good Java book, but any book that covers exceptions should take the time to teach the user how not to use them as well as how to use them.
The problem I've generally had with books about programming languages is that they almost invariably start out with several chapters (anywhere from one to five) dedicated to concepts that either you should already know, or that you should learn elsewhere. If I have a library of 50 computer books, I only want one book that covers object oriented programming concepts, for example. I don't need nor do I want all 50 to cover OOP. Even if I only have a library of 5 books, I'd still rather have only one that covers the basics. That way, I don't have to dig through five different, sometimes conflicting, explanations of the same concepts. Rather than dedicating the first 200 pages of a 600 page book to that and selling for $50, they should cut those pages and sell the 400 page book for $30.
Yes, I understand that beginners need books too, but even they don't need a discourse on object oriented programming every time they buy a Java, C++, or C# book. Why can't we have one or two definitive books covering basics, and get rid of that stuff in the rest of the books?
Leave it to Keanu Reeves to butcher the word nominees at the Academy Awards ...
(PS: becoming)
Launching a mission on the date of closest approach would be poor timing. To take advantage of this, missions would need to be launched prior to that date (how long before can be figured out, but I don't know the data to do so). If you launch on the day when Mars and Earth are closest, you'll immediately begin chasing Mars and the trip will not be optimal. If instead you launch before hand, you're travelling towards mars while it's travelling towards you. The rate of movement may be so minimal that it won't make a difference, but I don't know.
Just a small nitpick. XP is not a server operating system. It's analogous to Windows 2000 Professional, a workstation OS. If you're talking about competition in the server space, you should change "XP" to "W2K3".
(ignoring the Microsoft fear mongering ...)
That's all you had to say. You don't see C# being useful for you, fine. That's good enough for me. But when you just say, "I won't be warming up to Mono and C# any time soon," without adding something like, "because I don't see any need for them," or similar, it's not a far reach for us to assume your reasoning is, "because I hate/fear Microsoft," being that this is Slashdot after all.
Either the story should have been only about the dashboard program, in which case your Mono/C# comment was superfluous, or you should've mentioned that the Dashboard app was written using Mono, and used that as a springboard to create good discussion about Mono and C#. Instead, you just tacked on an inflammatory statement and caused only flames, not the coherent discussions which were supposedly your goal.
So you admit to intentionally inciting this? How mature.
You still haven't backed up your position, by the way. Do you have a good reason why you won't like C#/Mono/.NET, or is it just blind Microsoft hating?
From the submitter:
Was this commentary really necessary? This software looks like neat stuff, just as pheared said, so why the barb? Could you at least give a reason for your statement? What, if anything, does it have to do with the article, save that the software in question was written using C# via Mono?
Editors, I know you've explained why you won't edit user submissions before, and I know it's a losing battle to suggest you change, but this is a perfect candidate for editing. That remark had no business being left on the submission, and removing it would not detract from the story one bit. If there has ever been a perfect example of why editors should take their jobs seriously, this is it. Was pheared so unsure of the quality of his submission that he needed to try to stir up debate over Mono and C#, rather than let the story stand on its own? Or worse, were there really no other submissions for this story, or did the editors purposely choose this one submission because of the added barb at the end?
Ah, the SUV school of auto safety. "Fuck the other guy, I'm going to make it through this accident!" Of course, that flies in the face of all the studies and crash tests done that show that crumple zones work well to absorb the kinetic energy of a crash. As well, more weight means less maneuverabilty. In other words, you're less likely to be able to avoid an accident.
Indy cars also weigh less than half of this glorified golf cart. As well, the ability to handle a crash at 200mph is more about sacrificing the body of the car to protect the driver than it is about being heavier than the wall.
Properly designed crumple zones, good safety restraints, strong brakes, good tires, and a stable suspension do more to protect the driver than weight. In fact, more weight impacts three of the above items.
From the article:
At what point did "heavy" become synonymous with "safe"? This car is heavier than mine, and it's smaller!
I don't know of anyone who would call nVidia's hardware "crappy", yet they have consistently been able to increase the performance of even older hardware by making algorithmic enhancements to their drivers. You can claim that these enhancements should not be intellectual property, but nevertheless they are, and for a competitor like ATI to get ahold of them would be detrimental to nVidia, its shareholders, and its customers.
I don't share your confidence in the size of the open source community. You might lose a couple thousand sales, but when 95% of your target audience uses Windows, that's what butters your bread. If by chance that would change in the future, then you would have a point, but that's going to be a long time coming (how many years now have we been told that the open source desktop revolution is "just around the corner?). As far as reverse-engineering goes, I'll go back to nVidia. nVidia had been making hardware for years before they decided to release 3D accelerated drivers for Linux, and in that time no one was able to successfully reverse-engineer their product. Sure, it can happen, but even if it does it's generally a sub-par solution (witness the performance differential between Windows and Linux for the old 3dfx cards, for example).
I disagree. Taking Linux in particular, if Linus were to decide that minor kernel revisions must be binary compatible with all other kernels in a series, it would become law. If Linus proposed that kernel modules could be closed-source binaries, it would become law (hasn't that already been done?). The point being that compromises can be made to give IHVs a more favorable impression of Linux, and all it would take is some decisions from the top. Yes, if the decisions were unpopular the kernel could be forked, and that's a good thing about open source, but guess which fork would get the hardware vendor support? You can have your version where drivers must be open source. I'll take the one that provides better hardware support.
Exactly! The question is, though, how do you make it easier? Certainly licensing comes into play. If I'm a major hardware developer with significant investments in IP, I'm not going to want to release my drivers as open source. So, I'll target Windows, and I'll target OS X, but forget about Linux. There are ways around the licensing issue, but they create their own set of problems. For example, look at nVidia. The kernel driver they provide for their cards is rather thin, with most of the useful stuff being done in their closed source driver for X. That means you don't get good acceleration for the framebuffer/console, and it means that nVidia has to manage this more complex approach, and it means that they can't use the kernel's DRI architecture, because that would mean putting important IP in the open source kernel driver.
Driver model unification is more than we can hope for, but accomodations can be made via licensing, and by guaranteeing module compatibility across kernels (at least across minor revisions, like 2.4.x) so that IHVs can decouple their driver releases from the kernel release cycle.