Interestingly enough, the same story mentions a bill that codifies into law your right to kill off objectional material.
I assume that this is probably related to the problems that Clean Flicks and similar companies have been having with their technology. There's apparently a big market for movies that have been edited to remove objectionable content. Some of these are fairly crude- the companies buy legitimate video tapes and physically splice out the naughty scenes- but others are quite sophisticated. An especially clever one is essentially an automated time skipper for a DVD player; it has a record of the time points of objectionable bits and time jumps past them. Hollywood claims that using any of these techniques constitutes making an unauthorized derivative work, and hence is illegal under copyright law. This is presumably a legislative countermove to head off that objection.
According to this article one of the defenses of Akamai is the big diversity of their hardware: 'We deliberately use different operating systems, different name server implementations, different kinds of routers, different kinds of switches, different kinds of CPUs, and especially, different operational procedures.' So says Paul Vixie, architect of BIND and president of the ITC.
Actually, according to the article the diversity approach is part of what's used to defend the DNS root servers, not Akamai. Vixie specifically mentions that this approach is not practical for an ordinary content provider like Akamai because, 'the cost would "drive their accountants crazy."' I'm dubious about just how helpful diversity would be against a DDoS attack in the first place. Diversity won't solve the problem of requests coming in faster than they can be processed.
They have--see C# and.NET. Longhorn will be entirely.NET-based.
Which doesn't really address the underlying issue. Yes, managed languages like C# and.NET are essentially immune to some classes of exploits that cause problems in C and C++. That doesn't mean that they're completely secure, though; there are still plenty of classes of security holes that apply to managed languages. You can bet that bad programmers will find plenty of them.
Any lens that has more than 3x optical zoom will be making some heavy compromises to do so.
The 3x rule is less relevant than it used to be. It's possible to build zooms with higher ranges than that and good optical performance by incorporating one or more aspherical lenses. This drives up the price, since the aspherics are radically more expensive to produce, and it keeps the maximum aperture down, since the lenses would tend to get impossibly heavy otherwise, but distortion is much less of an issue in wide range zooms than it used to be.
Ergonomics and size can be pretty important, too. It's pretty easy to ruin a shot because you pushed the wrong button somehow and got the settings wrong. Even worse, you may fail to take any picture, even a bad one, if you're still fiddling with the controls when the perfect shot happens, or if you left your camera at home because it was too heavy and bulky to bring along.
Even if the new format isn't backward compatible, you won't need to buy new versions of all your existing movies any more than you needed to replace all your LPs and tapes with CDs when CDs were introduced. You may want to buy the new version if it looks better, has more features, etc., but the existence of the new format won't magically break all your existing equipment. If you keep your existing DVD player (and possibly your TV if they are such jerks that they force new TVs not to take DVD inputs) you'll be able to keep watching in the old format until the equipment finally fails.
What I'm wondering is when everyone expects that the TV/movie industries will start filming exclusively with HD cameras instead of the traditional cameras that most are still using.
It's going to take quite a while for TV to switch, especially because there's a chicken and egg problem. There's not much poing in TV switching to higher quality cameras if nobody has TVs that will show the high quality video, and there's less reason to get a HDTV without TV shows that take advantage of it. It's also a lot more expensive to shoot TV with higher quality cameras. It's not just a matter of replacing the old cameras. It turns out that traditional TV is able to get away with using low quality sets and props because the limited resolution doesn't let the viewer see how poor they are. HDTV is much less forgiving, so the whole production process has to change to accomodate it.
Movies should be much less of a problem. Most movies are still shot on 35mm film, which is capable of capturing much more detail than HDTV can show. That means that producing a good HDTV version is mostly a matter of producing a high quality digital transfer and encoding. That will require time, effort, and money, but it's certainly doable. The recent movies that were shot (and in some cases projected) digitally to start with should be even easier to work with, as the big studios work at higher digital resolutions than HDTV to start with.
Nautilus does things the way you suggest. If you click on one of the icons on your desktop, Nautilus will open in spatial mode, so the folder opens in the same location and with the same display options as the last time you opened it. If you go under the Applications menu and choose "Browse Filesystem", it opens in browser mode. I know that you can change the default behavior from desktop icons to browser mode, albeit only by editing GConf, and I'd assume that there's some way of changing the behavior for the version under the Applications menu.
One thing that makes me really, really happy with Linux is that I can automate things that I'd have no idea how to automate under Windows. I have my system set up to perform an automated backup of my user and configuration data once a week. With Linux this is easy; a short bash script in/etc/cron.weekly does the job. I'm not sure if it would even be possible to do the same thing under Windows, at least without either spending a good sized chunk of change on specialized backup software or cheating by doing the same thing under Cygwin. The same thing is true of a lot of what I do under Linux; there are enough useful built-in tools that I can do what I need to do without having to pay for a bolt-on program to do it for me.
I now use a location-based directory tree (country/state/placename/*.jpg), with the files themselves in the format "YYYYMMDD-some_sort_of_description.jpg".
That sounds reasonable, but it seems to me that it might get kind of painful when you start taking lots of pictures. For instance, I took about 400 pictures of this year's Rose Parade (I would have taken more except for camera speed and storage space limitations), plus about 200 more pictures of the street festivities the night before. It seems to me that giving a descriptive label to each of those photos would have been way more effort that it was worth.
What I do instead is to group pictures first by the year when they were taken- this keeps the 2004 Rose Parade pictures separate from the 2003 pictures- and then by topic or picture taking session. Whithin each subfolder, I use a free-form subdirectory structure to break things up into as many nested categories as necessary. So if I go on a driving trip across the country, I can have one major folder called "Driving_Vacation" and subfolders for each place I stopped or thing I did. If I stopped at the Grand Canyon, the "Grand_Canyon" subfolder would have further subfolders for every observation point where I stopped to take pictures. By that point, the pictures are generally well enough broken down by topic that there's no need for further descriptions, and the sorting process is usually pretty fast because consecutive pictures are frequently of the same thing.
The best part for me is that I also have a (homebrewed) program that will create a HTML-based catalog of all of the files. It recursively descends through the directory structure, and creates an index page for each directory with thumbnails linking to all of its subdirectories and the photos it contains. Each individual full-sized photo is on its own page, with links that let you page through the pictures instead of needing to go back to the thumbnail page and open each separately. Every page also has a link back to all of its parent directories. It's a quite convenient structure that lets me get to the pictures I'm interested in very quickly.
Most camera manufacturers provide converter software as part of the package, and in some cases it's of a higher quality than the stuff built into the camera. This shouldn't be surprising, since there are fewer time and processing power constraints in off-line processing.
AFAIK, though, the best available software is Dave Coffin's dcraw program. It's available as free software under a non-advertizing BSD-style licence. It can be used either as a standalone converter (with Windows, Mac, and Linux versions available) or as a GIMP plugin. The author also claims that the program, or at least parts of it, is used in many commercial programs including Photoshop. I've been pretty pleased with the results so far.
With most digital cameras, you click, it takes a second to autofocus, then it takes the pictures.
Most cameras, even cheap ones, can get around this using the poor man's focus lock. When you press the shutter button half way to autofocus the camera, it stays focused at that distance for as long as you hold the halfway position. Pushing the shutter the rest of the way will take the picture without a focus delay. That's obviously a poor solution to the problem, but it's certainly better than nothing.
However, what I would like is a camera that saved as PNG. Checked about 15 digital cameras last week in the 4 and 5 mega pixel range and found that most suffered from compression artifacts because of JPEG.
You might check for TIFF capability, which is what manufacturers tend to use instead of PNG. What you probably really want, though, is a camera that has raw photo capability. Most reasonably high end cameras now offer the ability to save the raw data off the image sensor, rather than the processed data in some image format. Many people describe the raw file as the digital equivalent of a negative. It's usually losslessly compressed, but other than that it's unprocessed- no white balance correction, saturation adjustment, sharpening, or the like. It hasn't even been color interpolated, as a TIFF or PNG would be. That turns out to be a bigger issue than you might think, as the interpolation algorithms in most cameras are optimized for speed rather than quality, and going to a better algorithm can make an obvious difference in the photo.
The simplest and most obvious reason to make the computer case sensitive is because it's much, much easier to program that way. Any time you want to know if two filenames are the same you can just compare them bit by bit and see if they're exactly equal. Making the computer understand which characters are upper or lower case versions of which other ones adds some complication in a coding system as simple as ASCII. If you want to use something more complex, like Unicode, the problems multiply tremendously. Including a full Unicode library in the kernel- which you'd need to do in order to make things case insensitive at the filesystem level- would be a source of innumerable bugs and performance problems.
I realize that it comes as a surprise to many people, but the standard Unix filesystem arrangment is not just a random pile of stuff that's accumulated over time. The directory structure- though not necessarily the names- is the result of a great deal of experience and careful thought. While it might make sense to rename standard directories with more descriptive names, like "libraries" instead of "lib" or even "temp" instead of "tmp", any suggestions to change their basic structure need strong justification. Just read the Filesystem Hierarch Standard, and you'll see that there are some very good reasons for the existing structure. Proposed alternatives should include a reason why their ideas will work better than the existing layout.
Saying "transgenic organisms are one of the primary means of constructing bioterror organisms" is a bit like saying "chemistry is one of the primary means of creating explosives," or "machining is one of the primary means of creating automatic weapons."
Actually, the comment that "transgenic organisms are one of the primary means of constructing bioterror organisms" is substantially less accurate than either of your statements. People are worried about the use of transgenic technologies in the production of biological agents, but that's a worry rather than an accomplished fact. It's not as though there are a host of known bioterrorists who we can interview to find out how they're planning on killing us all.
Moreover, it seems rather doubtful that transgenic technology is all that important for creation of bioweapons, anyway. Why go to the trouble of trying to create a novel pathogen when there are so many natural ones to work with?
The limited real world experience seems to back up your suggestion. There have been a small number of real attacks and a slightly larger number of groups that have been stopped before they had a chance. AFAIK, though, none of those cases have involved bioengineered diseases. Most of them used fairly crudely cultured lab strains of reasonably boring pathogens. One one that I know of- the 2001 anthrax letters- used anything approaching military grade material.
Having a big cache is nice, but it's not a substitute for fast write speed. Your picture taking speed is ultimately limited to how fast you can write the pictures to your memory card. If it takes 2 seconds to write one picture, your average speed can't be faster than 30 pictures per minute. A cache might let you take those 30 pictures in a single 4 second burst, but then you'll have to wait to write the cache out to your memory card before you can take another one. Fast write speed is still very important.
There's quite a bit on that list that can benefit from OS level intervention. A more secure operating system might cut down on spyware that autoinstalls itself by taking advantage of security holes. A better written OS might be able handle some of the eyecandy more efficiently, reducing the penalty for using it. And a better OS can certainly cut down on fragmentation. A well written filesystem won't get get fragmented as fast in the first place, and the OS can include background defragmentation to help out with what fragmentation you do see. Apple did include the last one with Panther, as you might have noticed had you read the article, and something similar is going to be included in ReiserFS4.
I can think of several things that might explain the difference. Maybe I was trying harder to notice the creak. It was something that I was specifically warned to consider when buying so I made a deliberate effort to see if it was going to be an issue. The "creak" is also not that bad. With the 10D, you squeeze it and you can feel the rubber bits on the outside giving just a bit, but then you run out of give because the frame isn't going anywhere. With the Digital Rebel you get the same feel that the rubber bits are squeezing a bit, but the give never completely stops. It's not as though the camera feels as though it's going to fall apart in your hands or anything, just that it doesn't feel like a solid piece of metal the way some other cameras do.
Another important consideration is that I've been holding floor models, which probably have a harder life than a camera you're borrowing from a friend. It's possbile that some of the flex comes from abuse, though that's not particularly reassuring when considering the long-term lifespan of the camera. I sort of doubt this possibility, though, since I've felt three different ones and had about the same feeling from each.
What I don't understand is that if you can build a camera with these features at this price, why someone doesn't, and eat Canon's lunch in the process!
Nikon is doing its best to do so. The new D70 is $100 more expensive than the Digital Rebel/300D, but it has a big enough performance advantage that the price difference looks pretty small. It doesn't come with cripled firmware and has a tougher body. Nikon also makes DX format (i.e. DSLR only) lenses with focal lengths down to 10.5mm so that you can shoot true wide angle shots with the D70; Canon's only EF-S (DSLR only) lens is the 18-55mm zoom sold as the box lens with the Digital Rebel.
More significantly, the D70 completely demolishes both the Digital Rebel and the 10D (and AFAIK every other camera within the price range of an ordinary consumer) in sustained shooting speed. Its primary shooting speed limitation seems to be how fast it can save data to its flash memory card. It has an intitial burst speed of 2.9 shots per second (a bit faster than the Digital Rebel), and with a very fast memory card it can keep up a rate of 1 per second in raw mode or 2.2 per second in highest quality JPEG mode until the card is full.
The only problem the D70 has right now is that it's so popular that it's very hard to find. I just ordered mine, but it'll be a week or two before it's delievered. If you look online, you'll find that every seller (or every seller who's honest enough to mention these things) describes it as out of stock, deliver when available. I'm guessing that Nikon could probably lower the price to match the Digital Rebel, but there's no sense in doing so when the thing is already selling like hotcakes.
I have to disagree about the plastic vs. metal case. I can feel the 300D creak just a bit when I grip it firmly, which is not reassuring compared to the physical solidity of the 10D. I also find that the 10D's larger body is easier for me to hold; there's no place for my pinky on the 300D. That could be important when working with a heavy lens. OTOH, I do have quite large (and strong) hands, so not everyone is going to feel the same way.
It's not just the sturdier body, either. The 300D has a very small buffer, with space for just 4 shots instead of 9 on the 10D. That's a pretty big disadvantage given the slow write speed of Canon's cameras (or at least the ones with the original DIGIC chip). I can imagine cases- like taking studio portraits- where that kind of limited burst size wouldn't be a serious disadvantage, but I doubt that the crippled firmware in the 300D would be a serious problem in those cases either.
No. The idea behind a motion for summary judgment is that the judge decides that there is no substantive factual dispute, so he can rule on who is right and wrong as a matter of law. Once the judge makes a summary judgment, the matter is treated just as though it had been decided by a jury. If IBM wins this motion (and any possible appeals) it is final. Somebody who buys SCO's rights in their bankruptcy liquidation won't be able to turn around and sue IBM over the same point, because it will already have been decided.
Equally important, IBM is asking for a ruling covering Linux as a whole. IBM is claiming that:
IBM is entitled to a declaratory judgment pursuant to 28 U. C. 9 2201 that IBM does not infringe, induce the infringement of, or contribute to the infringement of any SCO copyright through its Linux activities, including its use, reproduction and improvement of Linux...
IOW, they're not only not guilty of violating any SysV copyrights from having contributed code to Linux, but they're not guilty from simply copying it. That would only be true if there were no code over which SCO has a claim, so an IBM victory will have the side effect of protecting anyone else from copyright infringement claims.
Well, this one actually is a bit different, and the headline is a bit misleading. What's been going on so far is that IBM has been saying, with varying degrees of politeness, that SCO needs to put up. The last couple of rounds have involved IBM getting the judge to say it for them. Now they're going to the judge and saying that since SCO has failed to put up, the judge should make them shut up. This is a big deal because it will decide the most important part of the case- SCO's allegations of copyright infringement- should the judge rule in IBM's favor. If IBM wins this motion, neither SCO nor anyone who buys their rights to UNIX will be able to sue for copyright violations in Linux.
Slashdot Mirror
I assume that this is probably related to the problems that Clean Flicks and similar companies have been having with their technology. There's apparently a big market for movies that have been edited to remove objectionable content. Some of these are fairly crude- the companies buy legitimate video tapes and physically splice out the naughty scenes- but others are quite sophisticated. An especially clever one is essentially an automated time skipper for a DVD player; it has a record of the time points of objectionable bits and time jumps past them. Hollywood claims that using any of these techniques constitutes making an unauthorized derivative work, and hence is illegal under copyright law. This is presumably a legislative countermove to head off that objection.
Actually, according to the article the diversity approach is part of what's used to defend the DNS root servers, not Akamai. Vixie specifically mentions that this approach is not practical for an ordinary content provider like Akamai because, 'the cost would "drive their accountants crazy."' I'm dubious about just how helpful diversity would be against a DDoS attack in the first place. Diversity won't solve the problem of requests coming in faster than they can be processed.
Which doesn't really address the underlying issue. Yes, managed languages like C# and .NET are essentially immune to some classes of exploits that cause problems in C and C++. That doesn't mean that they're completely secure, though; there are still plenty of classes of security holes that apply to managed languages. You can bet that bad programmers will find plenty of them.
The 3x rule is less relevant than it used to be. It's possible to build zooms with higher ranges than that and good optical performance by incorporating one or more aspherical lenses. This drives up the price, since the aspherics are radically more expensive to produce, and it keeps the maximum aperture down, since the lenses would tend to get impossibly heavy otherwise, but distortion is much less of an issue in wide range zooms than it used to be.
Ergonomics and size can be pretty important, too. It's pretty easy to ruin a shot because you pushed the wrong button somehow and got the settings wrong. Even worse, you may fail to take any picture, even a bad one, if you're still fiddling with the controls when the perfect shot happens, or if you left your camera at home because it was too heavy and bulky to bring along.
Even if the new format isn't backward compatible, you won't need to buy new versions of all your existing movies any more than you needed to replace all your LPs and tapes with CDs when CDs were introduced. You may want to buy the new version if it looks better, has more features, etc., but the existence of the new format won't magically break all your existing equipment. If you keep your existing DVD player (and possibly your TV if they are such jerks that they force new TVs not to take DVD inputs) you'll be able to keep watching in the old format until the equipment finally fails.
It's going to take quite a while for TV to switch, especially because there's a chicken and egg problem. There's not much poing in TV switching to higher quality cameras if nobody has TVs that will show the high quality video, and there's less reason to get a HDTV without TV shows that take advantage of it. It's also a lot more expensive to shoot TV with higher quality cameras. It's not just a matter of replacing the old cameras. It turns out that traditional TV is able to get away with using low quality sets and props because the limited resolution doesn't let the viewer see how poor they are. HDTV is much less forgiving, so the whole production process has to change to accomodate it.
Movies should be much less of a problem. Most movies are still shot on 35mm film, which is capable of capturing much more detail than HDTV can show. That means that producing a good HDTV version is mostly a matter of producing a high quality digital transfer and encoding. That will require time, effort, and money, but it's certainly doable. The recent movies that were shot (and in some cases projected) digitally to start with should be even easier to work with, as the big studios work at higher digital resolutions than HDTV to start with.
Nautilus does things the way you suggest. If you click on one of the icons on your desktop, Nautilus will open in spatial mode, so the folder opens in the same location and with the same display options as the last time you opened it. If you go under the Applications menu and choose "Browse Filesystem", it opens in browser mode. I know that you can change the default behavior from desktop icons to browser mode, albeit only by editing GConf, and I'd assume that there's some way of changing the behavior for the version under the Applications menu.
One thing that makes me really, really happy with Linux is that I can automate things that I'd have no idea how to automate under Windows. I have my system set up to perform an automated backup of my user and configuration data once a week. With Linux this is easy; a short bash script in /etc/cron.weekly does the job. I'm not sure if it would even be possible to do the same thing under Windows, at least without either spending a good sized chunk of change on specialized backup software or cheating by doing the same thing under Cygwin. The same thing is true of a lot of what I do under Linux; there are enough useful built-in tools that I can do what I need to do without having to pay for a bolt-on program to do it for me.
That sounds reasonable, but it seems to me that it might get kind of painful when you start taking lots of pictures. For instance, I took about 400 pictures of this year's Rose Parade (I would have taken more except for camera speed and storage space limitations), plus about 200 more pictures of the street festivities the night before. It seems to me that giving a descriptive label to each of those photos would have been way more effort that it was worth.
What I do instead is to group pictures first by the year when they were taken- this keeps the 2004 Rose Parade pictures separate from the 2003 pictures- and then by topic or picture taking session. Whithin each subfolder, I use a free-form subdirectory structure to break things up into as many nested categories as necessary. So if I go on a driving trip across the country, I can have one major folder called "Driving_Vacation" and subfolders for each place I stopped or thing I did. If I stopped at the Grand Canyon, the "Grand_Canyon" subfolder would have further subfolders for every observation point where I stopped to take pictures. By that point, the pictures are generally well enough broken down by topic that there's no need for further descriptions, and the sorting process is usually pretty fast because consecutive pictures are frequently of the same thing.
The best part for me is that I also have a (homebrewed) program that will create a HTML-based catalog of all of the files. It recursively descends through the directory structure, and creates an index page for each directory with thumbnails linking to all of its subdirectories and the photos it contains. Each individual full-sized photo is on its own page, with links that let you page through the pictures instead of needing to go back to the thumbnail page and open each separately. Every page also has a link back to all of its parent directories. It's a quite convenient structure that lets me get to the pictures I'm interested in very quickly.
Most camera manufacturers provide converter software as part of the package, and in some cases it's of a higher quality than the stuff built into the camera. This shouldn't be surprising, since there are fewer time and processing power constraints in off-line processing.
AFAIK, though, the best available software is Dave Coffin's dcraw program. It's available as free software under a non-advertizing BSD-style licence. It can be used either as a standalone converter (with Windows, Mac, and Linux versions available) or as a GIMP plugin. The author also claims that the program, or at least parts of it, is used in many commercial programs including Photoshop. I've been pretty pleased with the results so far.
Most cameras, even cheap ones, can get around this using the poor man's focus lock. When you press the shutter button half way to autofocus the camera, it stays focused at that distance for as long as you hold the halfway position. Pushing the shutter the rest of the way will take the picture without a focus delay. That's obviously a poor solution to the problem, but it's certainly better than nothing.
You might check for TIFF capability, which is what manufacturers tend to use instead of PNG. What you probably really want, though, is a camera that has raw photo capability. Most reasonably high end cameras now offer the ability to save the raw data off the image sensor, rather than the processed data in some image format. Many people describe the raw file as the digital equivalent of a negative. It's usually losslessly compressed, but other than that it's unprocessed- no white balance correction, saturation adjustment, sharpening, or the like. It hasn't even been color interpolated, as a TIFF or PNG would be. That turns out to be a bigger issue than you might think, as the interpolation algorithms in most cameras are optimized for speed rather than quality, and going to a better algorithm can make an obvious difference in the photo.
The simplest and most obvious reason to make the computer case sensitive is because it's much, much easier to program that way. Any time you want to know if two filenames are the same you can just compare them bit by bit and see if they're exactly equal. Making the computer understand which characters are upper or lower case versions of which other ones adds some complication in a coding system as simple as ASCII. If you want to use something more complex, like Unicode, the problems multiply tremendously. Including a full Unicode library in the kernel- which you'd need to do in order to make things case insensitive at the filesystem level- would be a source of innumerable bugs and performance problems.
I realize that it comes as a surprise to many people, but the standard Unix filesystem arrangment is not just a random pile of stuff that's accumulated over time. The directory structure- though not necessarily the names- is the result of a great deal of experience and careful thought. While it might make sense to rename standard directories with more descriptive names, like "libraries" instead of "lib" or even "temp" instead of "tmp", any suggestions to change their basic structure need strong justification. Just read the Filesystem Hierarch Standard, and you'll see that there are some very good reasons for the existing structure. Proposed alternatives should include a reason why their ideas will work better than the existing layout.
Actually, the comment that "transgenic organisms are one of the primary means of constructing bioterror organisms" is substantially less accurate than either of your statements. People are worried about the use of transgenic technologies in the production of biological agents, but that's a worry rather than an accomplished fact. It's not as though there are a host of known bioterrorists who we can interview to find out how they're planning on killing us all.
The limited real world experience seems to back up your suggestion. There have been a small number of real attacks and a slightly larger number of groups that have been stopped before they had a chance. AFAIK, though, none of those cases have involved bioengineered diseases. Most of them used fairly crudely cultured lab strains of reasonably boring pathogens. One one that I know of- the 2001 anthrax letters- used anything approaching military grade material.
Back in my day, we had to calculate 2+2 IN OUR HEADS! And we LIKED IT that way!
Having a big cache is nice, but it's not a substitute for fast write speed. Your picture taking speed is ultimately limited to how fast you can write the pictures to your memory card. If it takes 2 seconds to write one picture, your average speed can't be faster than 30 pictures per minute. A cache might let you take those 30 pictures in a single 4 second burst, but then you'll have to wait to write the cache out to your memory card before you can take another one. Fast write speed is still very important.
There's quite a bit on that list that can benefit from OS level intervention. A more secure operating system might cut down on spyware that autoinstalls itself by taking advantage of security holes. A better written OS might be able handle some of the eyecandy more efficiently, reducing the penalty for using it. And a better OS can certainly cut down on fragmentation. A well written filesystem won't get get fragmented as fast in the first place, and the OS can include background defragmentation to help out with what fragmentation you do see. Apple did include the last one with Panther, as you might have noticed had you read the article, and something similar is going to be included in ReiserFS4.
I can think of several things that might explain the difference. Maybe I was trying harder to notice the creak. It was something that I was specifically warned to consider when buying so I made a deliberate effort to see if it was going to be an issue. The "creak" is also not that bad. With the 10D, you squeeze it and you can feel the rubber bits on the outside giving just a bit, but then you run out of give because the frame isn't going anywhere. With the Digital Rebel you get the same feel that the rubber bits are squeezing a bit, but the give never completely stops. It's not as though the camera feels as though it's going to fall apart in your hands or anything, just that it doesn't feel like a solid piece of metal the way some other cameras do.
Another important consideration is that I've been holding floor models, which probably have a harder life than a camera you're borrowing from a friend. It's possbile that some of the flex comes from abuse, though that's not particularly reassuring when considering the long-term lifespan of the camera. I sort of doubt this possibility, though, since I've felt three different ones and had about the same feeling from each.
Nikon is doing its best to do so. The new D70 is $100 more expensive than the Digital Rebel/300D, but it has a big enough performance advantage that the price difference looks pretty small. It doesn't come with cripled firmware and has a tougher body. Nikon also makes DX format (i.e. DSLR only) lenses with focal lengths down to 10.5mm so that you can shoot true wide angle shots with the D70; Canon's only EF-S (DSLR only) lens is the 18-55mm zoom sold as the box lens with the Digital Rebel.
More significantly, the D70 completely demolishes both the Digital Rebel and the 10D (and AFAIK every other camera within the price range of an ordinary consumer) in sustained shooting speed. Its primary shooting speed limitation seems to be how fast it can save data to its flash memory card. It has an intitial burst speed of 2.9 shots per second (a bit faster than the Digital Rebel), and with a very fast memory card it can keep up a rate of 1 per second in raw mode or 2.2 per second in highest quality JPEG mode until the card is full.
The only problem the D70 has right now is that it's so popular that it's very hard to find. I just ordered mine, but it'll be a week or two before it's delievered. If you look online, you'll find that every seller (or every seller who's honest enough to mention these things) describes it as out of stock, deliver when available. I'm guessing that Nikon could probably lower the price to match the Digital Rebel, but there's no sense in doing so when the thing is already selling like hotcakes.
I have to disagree about the plastic vs. metal case. I can feel the 300D creak just a bit when I grip it firmly, which is not reassuring compared to the physical solidity of the 10D. I also find that the 10D's larger body is easier for me to hold; there's no place for my pinky on the 300D. That could be important when working with a heavy lens. OTOH, I do have quite large (and strong) hands, so not everyone is going to feel the same way.
It's not just the sturdier body, either. The 300D has a very small buffer, with space for just 4 shots instead of 9 on the 10D. That's a pretty big disadvantage given the slow write speed of Canon's cameras (or at least the ones with the original DIGIC chip). I can imagine cases- like taking studio portraits- where that kind of limited burst size wouldn't be a serious disadvantage, but I doubt that the crippled firmware in the 300D would be a serious problem in those cases either.
No. The idea behind a motion for summary judgment is that the judge decides that there is no substantive factual dispute, so he can rule on who is right and wrong as a matter of law. Once the judge makes a summary judgment, the matter is treated just as though it had been decided by a jury. If IBM wins this motion (and any possible appeals) it is final. Somebody who buys SCO's rights in their bankruptcy liquidation won't be able to turn around and sue IBM over the same point, because it will already have been decided.
Equally important, IBM is asking for a ruling covering Linux as a whole. IBM is claiming that:
IOW, they're not only not guilty of violating any SysV copyrights from having contributed code to Linux, but they're not guilty from simply copying it. That would only be true if there were no code over which SCO has a claim, so an IBM victory will have the side effect of protecting anyone else from copyright infringement claims.
Well, this one actually is a bit different, and the headline is a bit misleading. What's been going on so far is that IBM has been saying, with varying degrees of politeness, that SCO needs to put up. The last couple of rounds have involved IBM getting the judge to say it for them. Now they're going to the judge and saying that since SCO has failed to put up, the judge should make them shut up. This is a big deal because it will decide the most important part of the case- SCO's allegations of copyright infringement- should the judge rule in IBM's favor. If IBM wins this motion, neither SCO nor anyone who buys their rights to UNIX will be able to sue for copyright violations in Linux.