I got them the same place as most analysts:-). The numbers are roughly what we've seen in other markets given similar situations but in the end it's all guesswork, of course.
Bookmark this puppy and get back to me in 2008 and we can see how I did. I save these predictions (I have them going back a decade on this particular subject) to see if I'm out to lunch. Aside from not seeing Linux coming until 1999, even though I was running it myself two years earlier, I've been doing way better than the big analysts. Like picking NT as crushing the UNIX workstation market in 1995 (in 1997 UNIX workstation sales started to collapse) and in 1997 saying Sun was going to start having financial problems no later than 2001 (didn't expect the dotcom boom to play out like that, but that didn't really do much did it?).
In any case if you get just one thing out of this commentary, let it be the cheapest thing that gets the job done wins. You too can be two to five years ahead of the analysts just by paying attention to that rule.
[..] we'll see Windows stabilize at 40-45% market share [..]
I agree with most of your analysis, but not with the above.
Windows marketshare will not stabilize at any percentage lower than 80% [of the PC-centric market (=x86 and AMD64), not the whole computing market] because Windows needs domination to be viable.
All but the last paragraph of my original posting refers to server penetration. Windows does not now have, nor has ever had, 80% share of servers. Last numbers I saw pegged it at somewhere in the mid-50% range (not sure if that was unit or revenue). I believe it'll pull another 10 percentage points, peak, and decline in that market.
Similar effects with software and support: The only real advantage Windows offers is a larger/better software library which is a result of their domination.
It also offers more integrated solutions that at least have the appearance of being easier to support, which will appeal to some audiences. And we really can't count out the value of.NET, which is a remarkable system.
Without domination, Windows loses all it's advantages - but the disadvantages remain.
We disagree on this count. Windows does offer value, at least in some cases. And inertia counts for a lot.
But of course just because Windows is doomed, doesn't mean Microsoft is doomed. They have just too much money to be doomed...
Like Lotus?
Money gives you additional chances at life, it doesn't give you immortality.
Increased sales can actually be indicative of a failing market. Consider two examples, DEC and Sun.
In DEC's case, the influx of workstation-class machinery caused a weakening of the mini market. This weakening killed off all but the strongest mini maker (DEC). Customers fleeing from failing makers split themselves between DEC and the new workstation vendors, thus causing a boost in DEC's sales right before the crash of the whole mini market -- DEC peaked amongst the carnage of their market, then crashed spectacularly.
Sun's case was a repeat of the behavior. Sun's market had migrated from workstations to servers from the late 80s through the mid 90s. By the mid 90s, however, we were already seeing a market shift towards PCs acting as servers. As the server vendors' market weakened (still prior to the Internet boom) we saw diminishing workstation/server sales for many companies in that sector (e.g. HP, SGI). Meanwhile Sun's sales skyrocketed, again attributable to a split in the market where some of the people leaving failing vendors went to Sun.
Sun would have had a crash in the 1999 timeframe if it weren't for the internet boom, which dramatically increased demand for large servers. When the boom ended, however, so did Sun's fortunes -- very fast. You can see in Dell's sales where the market went.
Microsoft has been benefitting from the failing of the server vendors, same as Sun. (Though, really, the biggest winner in this is Dell.) If this were a normal hardware-only migration Microsoft would rapidly capture upwards of 80% of he market and be dominant until the next hardware shift. But it's not normal because this is the first transition where the software is decoupled from the hardware.
Microsoft should have won by default, with customers shifting from server-class systems to PCs as customers went with the default option of Windows servers. And, in fact, Microsoft did extremely well for the first several years of the transition when there really wasn't much competition in the PC space.
Linux has thrown a huge wrench in the works. It's maturing very nicely and offers the huge win over Windows in that it's both cheaper for licenses and especially for migration.
If there's any one thing we can count on in this industry it's that the cheapest thing that gets the job done wins (which I've been saying so long now I call it Jim's Law). Until Linux came along the cheapest thing was Windows servers. Now it's not. The market impact of that is going to be phenomenal.
In a typical market transition you can expect more or less equal boosting of the various competitors in the market as people flee dying companies. But in a typical market transition there is not much price difference between the competitors -- usually within 10%, as everyone attempts to maximize the market opportunity.
Linux turns that on its head by offering a scale of prices starting at zero (no support) through prices that are more or less competitive with Microsoft's offerings (full support). That gives Linux a significant market advantage.
I expect we'll see a major market move towards mid-priced systems (some support, not "enterprise class" support, call it the $500 price point). Microsoft is trying hard to push for higher prices in that market just as Linux is depressing them.
If things continue the way they are going I would expect Microsoft to peak in the next one to three years at perhaps 65% of the market (by units) as the migration from server-class systems to PCs-as-servers completes, and then fall over the following five years to about 30% of the market as people migrate to more cost-effective Linux solutions.
But Microsoft won't take this laying down, they'll start reducing prices to match those of the midrange Linux products (more on that in a minute), to whatever degree they can afford. As such I think we're going to see the products come very close to price parity and we'll see Windows stabilize at 40-45% market share with
ig difference between 'digicam' 6MP and dSLR 6MP, especially depending on ISO
DSLRs are, to me, a class of "digicam." I was actually considering it from the DSLR angle. If you're talking lower end cameras the principal problem is crappy lenses; they're so bad that you can "recover" image detail lost by noise at high ISOs 'cause there wasn't going to be much real detail there anyway.
But on to my real reason for replying:
...your 'every random person' must be FAR more discerning than the random person around here.
I doubt that very much, given my sample:-).
While I agree with you that if you give someone a shot and say "does this look good" then by and large they're not going to notice subtle problems. But if you give them two images side by side and ask them to compare, many will be able to see differences.
This is what I did. I took a number of 6mpel RAW frames and converted to TIFF and fine JPEG. I then printed them both in several sizes and showed them to people and asked "which is better." At 4x6 nobody could tell the difference. But at 5x7 not one person has ever selected the JPEG image as superior. That is pretty definitive in my book.
To be honest, I was surprised by this result -- but I cannot deny it. To be honest, though, I shoot almost entirely in RAW simply for the enhanced exposure lattitude.
Personally I would much rather shoot raw, thus keeping the data as it came off the sensor, and then if I decide I don't like the T-Max emulation and would rather have, say, Velvia emulation (might as well go the exact opposite of B&W film:-), I can do that. In other words I would much rather have this as an option in my raw converter, not in my camera.
I think exactly the same way, but that does create a step in your workflow -- a step that didn't exist in the film world, and that adds cost to the process. I could entirely see some photographers wanting to skip that process (especially as it's quite time consuming, look at how long C1 takes to convert a frame).
You:the general consensus is that for every application that mere photographic mortals care about, digital cameras CAN take the place of film.
Me:But for the majority of photographic situations it's true that there's really no need for film anymore
You:How are those two statements significantly different from each other?
"The majority of situations" is not the same as "every application that mere photographic mortals care about."
For instance, I don't shoot sunrises that often but the limited lattitude of digital makes it difficult to get certain effects (like the bright colors of the sky combined with the wash of light over the scenery). In film you could take one frame and then bring out the subtle parts during print. In digital the only way to do it is take two frames at different exposures and composite them. If there's motion crossing the line between the bright and dark portions then compositing is not going to work out so well.
Also, the state of digital right now is such that it's difficult to rival the fineness of medium format, and for large format it's pretty much still-life-only. Digital at those resolutions is prohibitively expensive in any case. If the target of the print is large format (poster, wall, or billboard) then digital is not a very good choice.
Thus even though digital works fine in the majority of situations, there are still plenty of times you're still going to want film.
As for the inferred slight against professionals, none was intended. I shoot professionally and I only shoot digital. But I am aware that there are cases in which the format will not work, or will not work well. I have to take that into consideration when I'm selecting the jobs I'll do.
[limited gamut] might possibly be able to be fixed by an open camera (when combined with other tools to support it)
The gamut limitation is largely a result of the limitations of the sensor mask. If you want a wider gamut, you need a mask with more color channels. You're not going to fix that with an open camera.
Really what an open camera would get us is the ability to work around artificial limitations imposed on products by marketing trying to hit price points. For example, there is really no reason why the EOS-300D cannot support all of the modes of the EOS-10D -- except that if they gave you that flexibility, they'd sell fewer 10Ds. An open camera would allow aftermarket enhancements.
That is extremely consumer friendly, but not manufacturer friendly, as it makes hardware the only significant product discriminator. Hardware is a lot more expensive to change than software, so it's easy to see why they wouldn't want to do that even if you ignore competitive situations where you'd prefer not to give away your laboriously written code to your competitors.
It's true that the prosumer digicams are rivalling 35mm film; I find 6mpel to be roughly the same resolution as a typical ISO200 film, and as you say you can do much better than that with the professional models.
But let's look at that interpolation process, shall we?
Let's take 300dpi as a modest target resolution for printing. Your typical prosumer SLR is putting out roughly a 3k by 2k image (never mind that even that image is the result of Bayer mask interpolation; you've already lost color resolution versus film). That means that at 300dpi the biggest image you get before interpolation is necessary (and quality starts to drop) is roughly 7x10.
At 11x17 fully 65% of your image is the result of interpolation. Is that going to be visible on the output? Sure it is, even with an excellent interpolator -- TANSTAAFL applies. But I would agree that it's going to be quite reasonable, and in fact I do that kind of enlargement all the time in my printing.
Unfortunately quality drops off with the square of the increase in dimensions, it's not linear. A whopping 96% of his 24x36 image was guesswork by the interpolator. Ouch!
And all of this presumes you're starting from raw format. If you shot JPEG your effective resolution is reduced by at least half, if not more. I find that a 6mpel image at only 5x7 clearly shows loss of quality using fine JPEG (ie every random person I asked to compare RAW versus JPEG prints could easily tell me which was better).
Whether the print quality of a significant enlargement of a digital frame is worse than a similar 35mm enlargement is debatable, as grain is readily visible in 11x17 prints too, but the different character of pixellation versus grain makes it less pleasing in my opinion (but maybe that's a trained response, it's hard to say).
In any case I note that quite a lot of film photographers do not consider 35mm to be good enough at sizes much larger than 8x10; that is why they tend to use medium format cameras when intending to create such prints. I think, then, that that gives you a good idea of what kind of enlargements you can expect from digital.
In the end the acceptability is in the eye of the beholder, so Your Mileage May Vary. What I would suggest is doing your own experiments in reducing the frame, then enlarging it and printing it, and compare against the original. When you start to notice the difference, that's as much as you want to do. For me, with a full 6mpel frame, that limit is around 11x17.
I enlarged one of my 300d images to a 24"x36" and it was quite easy to see the individual pixels.
Hah, I wouldn't have even tried that:-). I max out at 11x17, give or take.
Can picture some fun stuff though that might be fun if it were possible to hack a camera though, such as how it'd be nice if it were possible to stuff a CF wireless card into the slot instead of a flash card.
Oh, wireless has long been possible on the high-end Kodak cameras. Possibly others, I never checked. But the problem I have with that is transfer rate; even at 54Mbps you're talking about more than a second a frame for one of those 14mpel cameras, and that's if everything's ideal. More realistically you're looking at 5+secs. Having a 300D myself I can tell you that 5sec save times suck; no matter how big your buffer you're gonna run out sooner or later and then you get to twiddle your thumbs forever waiting for the camera to catch up.
Which is, I suppose, one more plus for film at affordable price points -- although that Canon that sustains 8fps is really nifty if you've got a half dozen kilobucks burning a hole in your pocket. It's almost like a motion picture camera.
An exposure is based on a combination of three things, that's it: aperture, shutter speed, and sensitivity (ISO speed).
While this is true, the image is more than just the exposure. You get color and intensity sensitivity variations between different kinds of films, for instance. And grain, of course.
If your camera offers a raw format (again, the two I've owned do), these raw files will contain the EXACT values that came off the sensor. If you have a better processing algorithm, you can implement it on your computer, no need to try to shove it into the camera
There's some truth to this, too, but what if you don't want to post-process to get a particular effect (eg emulate T-Max film)? Some people really hate photoshopping every image. This is why there are so many parameters to tune in pro-level digicams.
Besides, the general consensus is that for every application that mere photographic mortals care about, digital cameras CAN take the place of film.
That may be the general consensus amongst laymen, but not amongst photographers. Not yet, anyway. Amongst the two serious limitations of digital versus film today are limited gamut and severely limited exposure lattitude.
It's technically possible to correct both of those, of course, for a price.
But for the majority of photographic situations it's true that there's really no need for film anymore, and a lot of economies in digital.
I have long wondered about all these technologically marvelous anti-counterfeiting driver's licenses. Is driver's license counterfeiting really common enough -- or serious enough -- to make these technologies economically worthwhile?
Sure, 20 years ago I <cough> knew some people who might have made fake Pennsylvania driver's licenses in order to purchase liquor. Back in those days the license was nothing but a Polaroid, very easy to clone. But when the states started going to those funny reflective laminations then cloning became a losing proposition (not that it was particularly hard to duplicate those, either, but it was even harder to make them look bad enough to be real).
Even when it was really easy to fake a license it was more or less a toss-up as to whether to make the license itself or the supporting documentation. For more than a decade now the easiest way to get a fake license (so I hear) is to print up the supporting docs and go get a real one. Way easier. They give out driver's licenses like candy on Halloween, after all.
This kind of fraud is certainly commonplace around colleges, but I find it hard to get worked up over some kids getting hold of alcohol. (It's pathetic that our drinking age is 21 yet the driver's license age is 16 -- that is a recipe for disaster. If anything, the two should be switched.) In a traffic stop the police call it in, in which case the computer wouldn't know about a false ID and it'd be obvious what's going on -- no matter if the ID is a fancy thing or just a slip of paper. Heck, they don't even need the physical driver's license anymore in most places.
So I figure the theory here is that it's for preventing identity theft (eg cashing checks in someone else's name -- although the reliance on driver's licenses, obtained via privilege rather than right, for that process is a rant in and of itself) and that doesn't seem like it's worth a lot of ID technology investment either.
I suspect that many pour misguided souls think that harder-to-fake driver's licenses would stop something like 9/11, in which case I would point out that the 9/11 hijackers had fraudulently obtained real driver's licenses, just like the college kids do. They were legitimate so far as the system knew.
Until they get around to fixing the lack of any real identity check during the process of applying for a license, not an easy or inexpensive thing to do, all these technologies are worthless.
Personally I prefer LCDs to CRTs for monitors because they are SHARP (no focus issues). Low power consumption doesn't hurt either (the LCD panel in front of me has a 48W rating, similar CRT is 200W).
Yes it does. His term of "order-of-magnitude". A 200% to 400% improvement certainly counts as that. Perhaps Mr. Brooks is unaware of Java. Perhaps you should point it out to him, so he can issue a retraction to his article.
I guess I have two rebuttals to that.
First, a factor of two to four is a lot less than an order of magnitude (by definition a factor of ten to one hundred). If you think Brooks didn't think so, then you need to read more closely because he talks about small integral factors of improvements in his dissertation on high level languages versus assembly language. Go look it up.
Second, you are making the presumption that using C/C++ in some way represented high-productivity practice prior to Java. That is emphatically not the case. C in particular was nice for low-level programming but it is and always has been a poor general purpose programming language. It is just too easy to make serious mistakes doing everyday things like manipulating strings. C++ adds a lot of sugar but doesn't really fix any of the problems of C (and, in fact, its attempts to retain C compatibility interact poorly with some of its new features -- like automatic type promotion in combination with overloaded methods). What makes C++ particularly bad in terms of productivity is that from its inception some really bad practices were touted as standards (e.g. iostreams.h use of operator overloading) and it had no standard container classes for years and by the time it got them (via STL) they sucked.
This is independent of the fact that C++ the language is so overcomplicated that there's a two-inch-thick reference to explain its finer points. Stuff like how an overloaded virtual method is hidden in the subclass if a subclass overrides one of its other signatures (gee, doesn't that defeat the point?). If you've used C++ for very long you've almost certainly wasted remarkable amounts of time here or there because some venomous corner of the language bit you.
C++ with a really nice class library, studious avoidance of some of its more dangerous features, and error detection tools ala Purify can yield a nice, productive environment. Too bad all of those are exceedingly rare in practice. Instead, we have millions of C++ programmers trying to be productive with MFC. Ha-ha!
Anyone who claims a 200% to 400% increase in productivity by switching to the Java language from C/C++ has some serious reality problems.
Or perhaps it is the case that they used both enough to know for sure. Nah, that can't be it, we all talk out our ass here don't we?
You mention Fred Brooks, but somehow I don't think you've read his essay
Well, you'd be wrong, it's one of my favorites. But I hardly think that my saying there is a 2-4x improvement over C/C++ equates to Brooks' hypothetical "silver bullet".
As for what the best hackers use, I will take some lumps on that since it's certainly true that many are still using C. 'Course many are happy to use other stuff when appropriate, too.
Dude, if what you think Java is good for is putting animations on web pages then you have been very sorely mislead. That is, IMO, the worst possible use you could put it to because you see all of the things it does poorly and none of the things it does well. Frankly I think Sun did Java a huge disservice by pushing it in that direction initially (although it did get a lot of people using it).
Rather, Java is particularly well suited for writing server applications, especially extensible server applications. It's downright trivial to write a server application in Java. It's too bad about J2EE, one wonders why Sun felt it necessary to create an environment that seems custom designed to make it difficult to run your code.
As for Microsoft corrupting it, the truth in the matter was that Netscape's variants (there were many) were always far more bastardized than Microsoft's. If Sun were really interested in Java compatibility they would have sued Netscape first.
But that's ok, Microsoft surely is going to have the last laugh over that lawsuit since.NET is just their JDK 1.1 implementation with new language front ends. If.NET kills MFC (quite possibly the worst class library of all time) then it'll all be worth it.
I do rather wish C# had kept mandatory exception handling and virtual as the default but at least they didn't go back to having automatic type promotion.
I guess I'd have to disagree, the two are useful in tandem. One very common combination is an adapter implementation of an interface; your class inherits from the adapter in order to get a basic implementation of the interface.
But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface, eg:
interface IFoo { void bar(); }
class MyClass implements IFoo { IFooAdapter adapter implements IFoo; }
In this case the compiler would automatically provide void foo() { adapter.foo(); } in MyClass. This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part).
If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics.
The real problem with your post is that nothing in it is specific to Java.
Certainly not. There's nothing whatsoever new in Java, it inherited every single feature from somewhere else. That in no way makes Java less interesting, since it does a pretty good job of combining a lot of good features in one place -- and being popular enough that you can pretty much count on an implementation being available, too.
Regarding Paul's article, you might notice that I didn't take issue with any part of it other than the idea that the best hackers avoid Java. His clique presumably does, but it's plenty easy to find high power hacks who either are building or have built significant amounts of code using Java.
For that matter, it's been my experience that the best are relatively language agnostic -- writing code in e.g. C, C++, C#, Python, and even -- god help 'em -- Perl. Pick J. Random Hacker and ask 'em what languages they've made significant use of over their career and you'll almost always get a laundry list.
Whatever gets the job done, right? The relative "goodness" of the language has little to do with it, which is easily proven by looking at how much work gets done in C and C++.
if you have a dev that has a low care-level, he's going to write crappy stuff in *any* language.
While true, such a developer cannot implicitly ignore such errors in Java. He has to handle them or pass them off. This raises the effort level enough that in general they get handled at the point of the problem.
This does help, I've seen it in practice over some eight years of working on large Java projects.
a well-designed and documented C API also "eliminates whole classes of memory mismanagement problems"
Yes, that's true. And yet in practice you almost never see such code. Look, for instance, at the poor quality of string management in C and standard C++. How many programs manipulate strings? What's that? Almost all of them? Huh.
But the problem is actually worse than that, C and C++ arrays are inherently dangerous to use. Ever see a C or C++ program that avoids the use of arrays entirely, deferring them to container functions/classes? Me either.
The rest of your arguments are pretty good ones, although rather specific to particular kinds of applications. Nobody ever said Java was the best tool to use all the time.
Well, except for the "ridiculously long method names" comment. Learn to type, or use an editor with autocompletion. It is more important that the code be understood at a glance, even by someone not familiar with the codebase, than it is to save a few characters per line during development.
I do realize that this opinion is not widely held in the industry. Then again, an appalling number of programmers don't know how to type, despite the keyboard being their primary input device.
studies have shown that coders churn out a pretty constant number of lines per day, regardless of the programming language
This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.
Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors:
1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.
2. Garbage collection eliminates whole classes of memory mismanagement problems.
3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality).
All three of these affect both time to deliver and quality of delivered code. We're not talking about minimal changes in productivity, either. I've been watching and working with Java and C++ since... well, pretty much since they made it out of the laboratory. The improvement in real world productivity seen with Java is a factor of two to four greater on average versus C/C++ (measured by "how long does it take to get this feature to work", which is not necessarily the same as "how much code did I have to write"). Often lower for GUI work (depending on which GUI toolkit/tools you're using) but much higher for network code. Moreover, bug counts in released code are dramatically lower, like one tenth as many, and they tend to be less serious (a feature may fail, but seldom does the entire application fail).
In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.
Your mileage may vary, contents may have settled during shipping, etc.
You know, I used to feel the same way, but the microprism screens of more recent vintage do offer one major advantage over the split-prism viewfinders while shooting faster-than-stillife -- you're not constrained to the center of your viewfinder to focus.
Actually microprism would be fine too. My film cameras have both split and microprism. But the lack of any manual focusing aids on my DSLRs bugs me.
Then autofocus took over (autofocus performance of F5, EOS-1v, and the D1/1D series are seriously good, with the F100/10D/E-1 class following fairly closely), and there was no reason for the split-prism screens.
I have to admit, autofocus on the Rebel is pretty good; usually better (without focusing aids anyway) and much faster than I can do manually. My number one desire when getting a DSLR was manual focus capability -- which I now find myself using only rarely -- because all of the autofocus systems I'd used previously sucked.
Today, I find myself using aperture priority and shutter priority modes too much to say those modes are not needed.
If I'm not manually metering I use Av mode almost exclusively these days. If it's wrong, I just toss an adjustment in. It's so easy.... For those really tough shots I'll fall back to manual, but I really don't have to do that very often.
It's nice that the image quality rivals 35mm now. I sacrificed a lot with my first digicam, but it was so much more convenient that I still rarely used the 35mm stuff. Now I can have the quality and the convenience too. And cost reduction; 600 frames this weekend and the only cost was the electricity to recharge the battery. Nice.
Between the 10% magnification difference and inherently dimmer pentamirror construction, the 10D will be much easier to use.
I don't know if I'd go so far as to say "much" easier to use with respect to these differences. There are way more important things to pick on it for.
The dim(mer) viewfinder is really not much of an issue. Since both cameras lack split viewfinders, and neither is particularly good at AF in low light situations, they both kind of suck in low light.
The focal length multiplier issue is a problem on the short end, since it's difficult/expensive to get a true wide angle lens for the thing. If you're making a lot of use of sub-35mm lenses you're going to hate the Rebel, but if you're using longer lenses on a traditional 35mm SLR the only real issue is having to mentally convert the lens lengths. (I dunno about you, but I have an ingrained mapping between "this is the shot" and "this is the lens I need" that has needed some tuning since going digital.)
If you like shooting with long lenses it can even be a bonus (although I realize that is stretching it:-). In any case this problem will be largely eliminated if/when Canon gets around to making decent EF-S lenses (possibly this fall).
The biggest usability difference between the two has to do with speed. The frame rate of the 300D is good, but only until you run out of buffer space... and that happens real fast. Multiframe shooting mode is next to useless, and that includes exposure bracketing. Exacerbating this situation is the slow I/O speed of the Rebel. No matter what media I use I can't get RAW write times below 5 seconds or so, whereas the 10D can halve that with fast media.
The poor performance of the Rebel in bursty shooting is a huge usability problem, by far its worst in my opinion. When you talk about the likelihood of losing shots, nothing is worse than looking at "busy" in the viewfinder.
Another irritation, although not nearly as serious, is the very limited metering capability of the Rebel; not only does it lack spot and center weighted metering, but there's no way to select different metering modes -- it's evaluative all the time except if you use exposure lock wherein it's partially metered. That has been far more of a pain in the neck than I anticipated. OTOH there's always manual mode and the Sekonic.
Both cameras have a number of the same annoyances: AIfocus mode is next to worthless (presuming you attempt to use the automatic modes of the Rebel, which I wouldn't recommend for several reasons); automatic white balance is awful; no focusing aids in the viewfinder or capability of switching viewfinders; limited frame coverage of viewfinder. Even so either one of them offers a lot of bang for the buck. Image quality in particular is rather good; good enough to make L lenses worth buying even for the Rebel.
It's unfortunate that the weaknesses of the Rebel stack up on each other. Slow write speed means you can't work around metering limitations with exposure bracketing, for instance (one shot nearly fills the buffer and it's like 15 seconds to clear it even using 40x media), and likewise the inability to shoot RAW format in automatic modes means you can't avoid dealing with the crappy on-camera white balance issue.
Before I bought the Rebel I spent some time considering the differences. As an amateur tool the price difference between the bodies -- $800 at the time -- was very substantial, enough to make the difference between buying crap lenses and an L. But as a pro tool you're right, the Rebel is not a good buy. It's just too slow; the other differences are moot next to that (what the heck, none of my SLRs have any of this newfangled automation anyway). If I'd known how I was going to use the camera I would have sprung for the 10D, no question. Ahh, hindsight.
Sun bought extensive rights on Unix from USL in 1994.
Around that time lots of hardware vendors were buying perpetual licenses to Unix -- in other words, the right to use the code without paying further royalties. That is not the same as having the right to give the code away.
IBM bought a similar license around the same time. Notice that they're in court....
I'll believe they open source Solaris the day it actually happens. It's pretty unlikely since Solaris is SVR4 based. Unless Sun has a really unusual license they don't own the code in the first place and cannot open source it without the blessing of SCO.
Professionals aren't likely to want to trust their bread and butter to a hack. They might buy a Rebel as a second body (which they might have anyways), and try the hack on that (as a second body).
I think a lot of you may be underestimating the geek level of many photo pros. While it's true that not too many pros use the Rebel, that may be in part because they had already jumped into the 10D, which is extremely popular despite being inferior to a number of other models in many respects.
I've known about the firmware hacks for about two months and I found out from a pro.
That said, the buffer size and write speed of the Rebel, not to mention the viewfinder limitations, are indeed poor enough that the 10D is far more appealing.
How many closed source companies copy code from various places?
I can't tell you about the industry as a whole, but so far I haven't seen even one case of a large body of source that didn't have code cribbed from somewhere else (my current employer excluded, I haven't been here long enough to know one way or the other).
Often this is not widely known, i.e. only one developer might know it happened.
I do note that over time the practice has become more strongly discouraged. I believe it was the GPL that was behind a lot of that, with smaller companies anyway, because the GPL has been a very tempting code base -- but with obvious legal strings attached.
Slashdot Mirror
Bookmark this puppy and get back to me in 2008 and we can see how I did. I save these predictions (I have them going back a decade on this particular subject) to see if I'm out to lunch. Aside from not seeing Linux coming until 1999, even though I was running it myself two years earlier, I've been doing way better than the big analysts. Like picking NT as crushing the UNIX workstation market in 1995 (in 1997 UNIX workstation sales started to collapse) and in 1997 saying Sun was going to start having financial problems no later than 2001 (didn't expect the dotcom boom to play out like that, but that didn't really do much did it?).
In any case if you get just one thing out of this commentary, let it be the cheapest thing that gets the job done wins. You too can be two to five years ahead of the analysts just by paying attention to that rule.
I agree with most of your analysis, but not with the above.
Windows marketshare will not stabilize at any percentage lower than 80% [of the PC-centric market (=x86 and AMD64), not the whole computing market] because Windows needs domination to be viable.
All but the last paragraph of my original posting refers to server penetration. Windows does not now have, nor has ever had, 80% share of servers. Last numbers I saw pegged it at somewhere in the mid-50% range (not sure if that was unit or revenue). I believe it'll pull another 10 percentage points, peak, and decline in that market.
Similar effects with software and support: The only real advantage Windows offers is a larger/better software library which is a result of their domination.
It also offers more integrated solutions that at least have the appearance of being easier to support, which will appeal to some audiences. And we really can't count out the value of .NET, which is a remarkable system.
Without domination, Windows loses all it's advantages - but the disadvantages remain.
We disagree on this count. Windows does offer value, at least in some cases. And inertia counts for a lot.
But of course just because Windows is doomed, doesn't mean Microsoft is doomed. They have just too much money to be doomed...
Like Lotus?
Money gives you additional chances at life, it doesn't give you immortality.
In DEC's case, the influx of workstation-class machinery caused a weakening of the mini market. This weakening killed off all but the strongest mini maker (DEC). Customers fleeing from failing makers split themselves between DEC and the new workstation vendors, thus causing a boost in DEC's sales right before the crash of the whole mini market -- DEC peaked amongst the carnage of their market, then crashed spectacularly.
Sun's case was a repeat of the behavior. Sun's market had migrated from workstations to servers from the late 80s through the mid 90s. By the mid 90s, however, we were already seeing a market shift towards PCs acting as servers. As the server vendors' market weakened (still prior to the Internet boom) we saw diminishing workstation/server sales for many companies in that sector (e.g. HP, SGI). Meanwhile Sun's sales skyrocketed, again attributable to a split in the market where some of the people leaving failing vendors went to Sun.
Sun would have had a crash in the 1999 timeframe if it weren't for the internet boom, which dramatically increased demand for large servers. When the boom ended, however, so did Sun's fortunes -- very fast. You can see in Dell's sales where the market went.
Microsoft has been benefitting from the failing of the server vendors, same as Sun. (Though, really, the biggest winner in this is Dell.) If this were a normal hardware-only migration Microsoft would rapidly capture upwards of 80% of he market and be dominant until the next hardware shift. But it's not normal because this is the first transition where the software is decoupled from the hardware.
Microsoft should have won by default, with customers shifting from server-class systems to PCs as customers went with the default option of Windows servers. And, in fact, Microsoft did extremely well for the first several years of the transition when there really wasn't much competition in the PC space.
Linux has thrown a huge wrench in the works. It's maturing very nicely and offers the huge win over Windows in that it's both cheaper for licenses and especially for migration.
If there's any one thing we can count on in this industry it's that the cheapest thing that gets the job done wins (which I've been saying so long now I call it Jim's Law). Until Linux came along the cheapest thing was Windows servers. Now it's not. The market impact of that is going to be phenomenal.
In a typical market transition you can expect more or less equal boosting of the various competitors in the market as people flee dying companies. But in a typical market transition there is not much price difference between the competitors -- usually within 10%, as everyone attempts to maximize the market opportunity.
Linux turns that on its head by offering a scale of prices starting at zero (no support) through prices that are more or less competitive with Microsoft's offerings (full support). That gives Linux a significant market advantage.
I expect we'll see a major market move towards mid-priced systems (some support, not "enterprise class" support, call it the $500 price point). Microsoft is trying hard to push for higher prices in that market just as Linux is depressing them.
If things continue the way they are going I would expect Microsoft to peak in the next one to three years at perhaps 65% of the market (by units) as the migration from server-class systems to PCs-as-servers completes, and then fall over the following five years to about 30% of the market as people migrate to more cost-effective Linux solutions.
But Microsoft won't take this laying down, they'll start reducing prices to match those of the midrange Linux products (more on that in a minute), to whatever degree they can afford. As such I think we're going to see the products come very close to price parity and we'll see Windows stabilize at 40-45% market share with
DSLRs are, to me, a class of "digicam." I was actually considering it from the DSLR angle. If you're talking lower end cameras the principal problem is crappy lenses; they're so bad that you can "recover" image detail lost by noise at high ISOs 'cause there wasn't going to be much real detail there anyway.
But on to my real reason for replying:
I doubt that very much, given my sample :-).
While I agree with you that if you give someone a shot and say "does this look good" then by and large they're not going to notice subtle problems. But if you give them two images side by side and ask them to compare, many will be able to see differences.
This is what I did. I took a number of 6mpel RAW frames and converted to TIFF and fine JPEG. I then printed them both in several sizes and showed them to people and asked "which is better." At 4x6 nobody could tell the difference. But at 5x7 not one person has ever selected the JPEG image as superior. That is pretty definitive in my book.
To be honest, I was surprised by this result -- but I cannot deny it. To be honest, though, I shoot almost entirely in RAW simply for the enhanced exposure lattitude.
I think exactly the same way, but that does create a step in your workflow -- a step that didn't exist in the film world, and that adds cost to the process. I could entirely see some photographers wanting to skip that process (especially as it's quite time consuming, look at how long C1 takes to convert a frame).
You: the general consensus is that for every application that mere photographic mortals care about, digital cameras CAN take the place of film.
Me: But for the majority of photographic situations it's true that there's really no need for film anymore
You: How are those two statements significantly different from each other?
"The majority of situations" is not the same as "every application that mere photographic mortals care about."
For instance, I don't shoot sunrises that often but the limited lattitude of digital makes it difficult to get certain effects (like the bright colors of the sky combined with the wash of light over the scenery). In film you could take one frame and then bring out the subtle parts during print. In digital the only way to do it is take two frames at different exposures and composite them. If there's motion crossing the line between the bright and dark portions then compositing is not going to work out so well.
Also, the state of digital right now is such that it's difficult to rival the fineness of medium format, and for large format it's pretty much still-life-only. Digital at those resolutions is prohibitively expensive in any case. If the target of the print is large format (poster, wall, or billboard) then digital is not a very good choice.
Thus even though digital works fine in the majority of situations, there are still plenty of times you're still going to want film.
As for the inferred slight against professionals, none was intended. I shoot professionally and I only shoot digital. But I am aware that there are cases in which the format will not work, or will not work well. I have to take that into consideration when I'm selecting the jobs I'll do.
[limited gamut] might possibly be able to be fixed by an open camera (when combined with other tools to support it)
The gamut limitation is largely a result of the limitations of the sensor mask. If you want a wider gamut, you need a mask with more color channels. You're not going to fix that with an open camera.
Really what an open camera would get us is the ability to work around artificial limitations imposed on products by marketing trying to hit price points. For example, there is really no reason why the EOS-300D cannot support all of the modes of the EOS-10D -- except that if they gave you that flexibility, they'd sell fewer 10Ds. An open camera would allow aftermarket enhancements.
That is extremely consumer friendly, but not manufacturer friendly, as it makes hardware the only significant product discriminator. Hardware is a lot more expensive to change than software, so it's easy to see why they wouldn't want to do that even if you ignore competitive situations where you'd prefer not to give away your laboriously written code to your competitors.
But let's look at that interpolation process, shall we?
Let's take 300dpi as a modest target resolution for printing. Your typical prosumer SLR is putting out roughly a 3k by 2k image (never mind that even that image is the result of Bayer mask interpolation; you've already lost color resolution versus film). That means that at 300dpi the biggest image you get before interpolation is necessary (and quality starts to drop) is roughly 7x10.
At 11x17 fully 65% of your image is the result of interpolation. Is that going to be visible on the output? Sure it is, even with an excellent interpolator -- TANSTAAFL applies. But I would agree that it's going to be quite reasonable, and in fact I do that kind of enlargement all the time in my printing.
Unfortunately quality drops off with the square of the increase in dimensions, it's not linear. A whopping 96% of his 24x36 image was guesswork by the interpolator. Ouch!
And all of this presumes you're starting from raw format. If you shot JPEG your effective resolution is reduced by at least half, if not more. I find that a 6mpel image at only 5x7 clearly shows loss of quality using fine JPEG (ie every random person I asked to compare RAW versus JPEG prints could easily tell me which was better).
Whether the print quality of a significant enlargement of a digital frame is worse than a similar 35mm enlargement is debatable, as grain is readily visible in 11x17 prints too, but the different character of pixellation versus grain makes it less pleasing in my opinion (but maybe that's a trained response, it's hard to say).
In any case I note that quite a lot of film photographers do not consider 35mm to be good enough at sizes much larger than 8x10; that is why they tend to use medium format cameras when intending to create such prints. I think, then, that that gives you a good idea of what kind of enlargements you can expect from digital.
In the end the acceptability is in the eye of the beholder, so Your Mileage May Vary. What I would suggest is doing your own experiments in reducing the frame, then enlarging it and printing it, and compare against the original. When you start to notice the difference, that's as much as you want to do. For me, with a full 6mpel frame, that limit is around 11x17.
Hah, I wouldn't have even tried that :-). I max out at 11x17, give or take.
Can picture some fun stuff though that might be fun if it were possible to hack a camera though, such as how it'd be nice if it were possible to stuff a CF wireless card into the slot instead of a flash card.
Oh, wireless has long been possible on the high-end Kodak cameras. Possibly others, I never checked. But the problem I have with that is transfer rate; even at 54Mbps you're talking about more than a second a frame for one of those 14mpel cameras, and that's if everything's ideal. More realistically you're looking at 5+secs. Having a 300D myself I can tell you that 5sec save times suck; no matter how big your buffer you're gonna run out sooner or later and then you get to twiddle your thumbs forever waiting for the camera to catch up.
Which is, I suppose, one more plus for film at affordable price points -- although that Canon that sustains 8fps is really nifty if you've got a half dozen kilobucks burning a hole in your pocket. It's almost like a motion picture camera.
While this is true, the image is more than just the exposure. You get color and intensity sensitivity variations between different kinds of films, for instance. And grain, of course.
If your camera offers a raw format (again, the two I've owned do), these raw files will contain the EXACT values that came off the sensor. If you have a better processing algorithm, you can implement it on your computer, no need to try to shove it into the camera
There's some truth to this, too, but what if you don't want to post-process to get a particular effect (eg emulate T-Max film)? Some people really hate photoshopping every image. This is why there are so many parameters to tune in pro-level digicams.
Besides, the general consensus is that for every application that mere photographic mortals care about, digital cameras CAN take the place of film.
That may be the general consensus amongst laymen, but not amongst photographers. Not yet, anyway. Amongst the two serious limitations of digital versus film today are limited gamut and severely limited exposure lattitude.
It's technically possible to correct both of those, of course, for a price.
But for the majority of photographic situations it's true that there's really no need for film anymore, and a lot of economies in digital.
Sure, 20 years ago I <cough> knew some people who might have made fake Pennsylvania driver's licenses in order to purchase liquor. Back in those days the license was nothing but a Polaroid, very easy to clone. But when the states started going to those funny reflective laminations then cloning became a losing proposition (not that it was particularly hard to duplicate those, either, but it was even harder to make them look bad enough to be real).
Even when it was really easy to fake a license it was more or less a toss-up as to whether to make the license itself or the supporting documentation. For more than a decade now the easiest way to get a fake license (so I hear) is to print up the supporting docs and go get a real one. Way easier. They give out driver's licenses like candy on Halloween, after all.
This kind of fraud is certainly commonplace around colleges, but I find it hard to get worked up over some kids getting hold of alcohol. (It's pathetic that our drinking age is 21 yet the driver's license age is 16 -- that is a recipe for disaster. If anything, the two should be switched.) In a traffic stop the police call it in, in which case the computer wouldn't know about a false ID and it'd be obvious what's going on -- no matter if the ID is a fancy thing or just a slip of paper. Heck, they don't even need the physical driver's license anymore in most places.
So I figure the theory here is that it's for preventing identity theft (eg cashing checks in someone else's name -- although the reliance on driver's licenses, obtained via privilege rather than right, for that process is a rant in and of itself) and that doesn't seem like it's worth a lot of ID technology investment either.
I suspect that many pour misguided souls think that harder-to-fake driver's licenses would stop something like 9/11, in which case I would point out that the 9/11 hijackers had fraudulently obtained real driver's licenses, just like the college kids do. They were legitimate so far as the system knew.
Until they get around to fixing the lack of any real identity check during the process of applying for a license, not an easy or inexpensive thing to do, all these technologies are worthless.
It ain't just the form factor.
I guess I have two rebuttals to that.
First, a factor of two to four is a lot less than an order of magnitude (by definition a factor of ten to one hundred). If you think Brooks didn't think so, then you need to read more closely because he talks about small integral factors of improvements in his dissertation on high level languages versus assembly language. Go look it up.
Second, you are making the presumption that using C/C++ in some way represented high-productivity practice prior to Java. That is emphatically not the case. C in particular was nice for low-level programming but it is and always has been a poor general purpose programming language. It is just too easy to make serious mistakes doing everyday things like manipulating strings. C++ adds a lot of sugar but doesn't really fix any of the problems of C (and, in fact, its attempts to retain C compatibility interact poorly with some of its new features -- like automatic type promotion in combination with overloaded methods). What makes C++ particularly bad in terms of productivity is that from its inception some really bad practices were touted as standards (e.g. iostreams.h use of operator overloading) and it had no standard container classes for years and by the time it got them (via STL) they sucked.
This is independent of the fact that C++ the language is so overcomplicated that there's a two-inch-thick reference to explain its finer points. Stuff like how an overloaded virtual method is hidden in the subclass if a subclass overrides one of its other signatures (gee, doesn't that defeat the point?). If you've used C++ for very long you've almost certainly wasted remarkable amounts of time here or there because some venomous corner of the language bit you.
C++ with a really nice class library, studious avoidance of some of its more dangerous features, and error detection tools ala Purify can yield a nice, productive environment. Too bad all of those are exceedingly rare in practice. Instead, we have millions of C++ programmers trying to be productive with MFC. Ha-ha!
Anyone who claims a 200% to 400% increase in productivity by switching to the Java language from C/C++ has some serious reality problems.
Or perhaps it is the case that they used both enough to know for sure. Nah, that can't be it, we all talk out our ass here don't we?
Well, you'd be wrong, it's one of my favorites. But I hardly think that my saying there is a 2-4x improvement over C/C++ equates to Brooks' hypothetical "silver bullet".
As for what the best hackers use, I will take some lumps on that since it's certainly true that many are still using C. 'Course many are happy to use other stuff when appropriate, too.
Rather, Java is particularly well suited for writing server applications, especially extensible server applications. It's downright trivial to write a server application in Java. It's too bad about J2EE, one wonders why Sun felt it necessary to create an environment that seems custom designed to make it difficult to run your code.
As for Microsoft corrupting it, the truth in the matter was that Netscape's variants (there were many) were always far more bastardized than Microsoft's. If Sun were really interested in Java compatibility they would have sued Netscape first.
But that's ok, Microsoft surely is going to have the last laugh over that lawsuit since .NET is just their JDK 1.1 implementation with new language front ends. If .NET kills MFC (quite possibly the worst class library of all time) then it'll all be worth it.
I do rather wish C# had kept mandatory exception handling and virtual as the default but at least they didn't go back to having automatic type promotion.
But I suppose it's arguable that you only do that as often as you do in Java because the language makes encapsulation too hard. It should have something to specify that a particular member is intended to provide the implementation for an interface, eg:
In this case the compiler would automatically provide void foo() { adapter.foo(); } in MyClass. This would save the programmer a lot of time writing trampoline code, and make it easier on the optimizer too (though of course the concept of "Java optimizer" seems to be one of deliberate neglect on Sun's part).If you want to complain about something Java has historically not done that it really should have done a long time ago I think I'd go with generics.
Certainly not. There's nothing whatsoever new in Java, it inherited every single feature from somewhere else. That in no way makes Java less interesting, since it does a pretty good job of combining a lot of good features in one place -- and being popular enough that you can pretty much count on an implementation being available, too.
Regarding Paul's article, you might notice that I didn't take issue with any part of it other than the idea that the best hackers avoid Java. His clique presumably does, but it's plenty easy to find high power hacks who either are building or have built significant amounts of code using Java.
For that matter, it's been my experience that the best are relatively language agnostic -- writing code in e.g. C, C++, C#, Python, and even -- god help 'em -- Perl. Pick J. Random Hacker and ask 'em what languages they've made significant use of over their career and you'll almost always get a laundry list.
Whatever gets the job done, right? The relative "goodness" of the language has little to do with it, which is easily proven by looking at how much work gets done in C and C++.
While true, such a developer cannot implicitly ignore such errors in Java. He has to handle them or pass them off. This raises the effort level enough that in general they get handled at the point of the problem.
This does help, I've seen it in practice over some eight years of working on large Java projects.
a well-designed and documented C API also "eliminates whole classes of memory mismanagement problems"
Yes, that's true. And yet in practice you almost never see such code. Look, for instance, at the poor quality of string management in C and standard C++. How many programs manipulate strings? What's that? Almost all of them? Huh.
But the problem is actually worse than that, C and C++ arrays are inherently dangerous to use. Ever see a C or C++ program that avoids the use of arrays entirely, deferring them to container functions/classes? Me either.
The rest of your arguments are pretty good ones, although rather specific to particular kinds of applications. Nobody ever said Java was the best tool to use all the time.
Well, except for the "ridiculously long method names" comment. Learn to type, or use an editor with autocompletion. It is more important that the code be understood at a glance, even by someone not familiar with the codebase, than it is to save a few characters per line during development.
I do realize that this opinion is not widely held in the industry. Then again, an appalling number of programmers don't know how to type, despite the keyboard being their primary input device.
This is true, but that is not the whole picture. One of the things that was obvious right away is that minimizing the number of things the programmer can do wrong causes a significant jump in the effective productivity of the programmer.
Brooks talks about this in the Mythical Man Month as it related to assembly versus high level languages, but we do see the same effect when moving between a language like C and something like Smalltalk or Java. It has been my experience that a good programmer writes more and higher quality code in Java versus C or C++, largely due to three factors:
1. Mandatory exception handling forces error handling down into the code where it can best be dealt with. In other words, you have to work harder to not handle abnormal situations.
2. Garbage collection eliminates whole classes of memory mismanagement problems.
3. Standard libraries contain many useful classes that had to be written independently in C/C++ (leading to a variety of different container classes, for instance, of widely varying usability and quality).
All three of these affect both time to deliver and quality of delivered code. We're not talking about minimal changes in productivity, either. I've been watching and working with Java and C++ since ... well, pretty much since they made it out of the laboratory. The improvement in real world productivity seen with Java is a factor of two to four greater on average versus C/C++ (measured by "how long does it take to get this feature to work", which is not necessarily the same as "how much code did I have to write"). Often lower for GUI work (depending on which GUI toolkit/tools you're using) but much higher for network code. Moreover, bug counts in released code are dramatically lower, like one tenth as many, and they tend to be less serious (a feature may fail, but seldom does the entire application fail).
In any case I guess I would have to vehemently disagree with Graham's contention that great hackers don't use Java. I suspect that is more a matter of which circles you run in, as that certainly doesn't hold true in my experience. There are fewer using it today than three or four years ago, but I surmise that that is mostly a matter of language maturity; the best programmers tend to sit on the bleeding edge, and that's not Java anymore.
Your mileage may vary, contents may have settled during shipping, etc.
Here's a link for you people who read boring books when you were kids:
http://www.norder.com/nostalgia/Danny-Dunn-Invisib le-Boy.html
These kinds of "sue them because the stock price dropped" are nuisance lawsuits, they happen all the time with publicly traded companies. No big deal.
Actually microprism would be fine too. My film cameras have both split and microprism. But the lack of any manual focusing aids on my DSLRs bugs me.
Then autofocus took over (autofocus performance of F5, EOS-1v, and the D1/1D series are seriously good, with the F100/10D/E-1 class following fairly closely), and there was no reason for the split-prism screens.
I have to admit, autofocus on the Rebel is pretty good; usually better (without focusing aids anyway) and much faster than I can do manually. My number one desire when getting a DSLR was manual focus capability -- which I now find myself using only rarely -- because all of the autofocus systems I'd used previously sucked.
Today, I find myself using aperture priority and shutter priority modes too much to say those modes are not needed.
If I'm not manually metering I use Av mode almost exclusively these days. If it's wrong, I just toss an adjustment in. It's so easy.... For those really tough shots I'll fall back to manual, but I really don't have to do that very often.
It's nice that the image quality rivals 35mm now. I sacrificed a lot with my first digicam, but it was so much more convenient that I still rarely used the 35mm stuff. Now I can have the quality and the convenience too. And cost reduction; 600 frames this weekend and the only cost was the electricity to recharge the battery. Nice.
I don't know if I'd go so far as to say "much" easier to use with respect to these differences. There are way more important things to pick on it for.
The dim(mer) viewfinder is really not much of an issue. Since both cameras lack split viewfinders, and neither is particularly good at AF in low light situations, they both kind of suck in low light.
The focal length multiplier issue is a problem on the short end, since it's difficult/expensive to get a true wide angle lens for the thing. If you're making a lot of use of sub-35mm lenses you're going to hate the Rebel, but if you're using longer lenses on a traditional 35mm SLR the only real issue is having to mentally convert the lens lengths. (I dunno about you, but I have an ingrained mapping between "this is the shot" and "this is the lens I need" that has needed some tuning since going digital.) If you like shooting with long lenses it can even be a bonus (although I realize that is stretching it :-). In any case this problem will be largely eliminated if/when Canon gets around to making decent EF-S lenses (possibly this fall).
The biggest usability difference between the two has to do with speed. The frame rate of the 300D is good, but only until you run out of buffer space ... and that happens real fast. Multiframe shooting mode is next to useless, and that includes exposure bracketing. Exacerbating this situation is the slow I/O speed of the Rebel. No matter what media I use I can't get RAW write times below 5 seconds or so, whereas the 10D can halve that with fast media.
The poor performance of the Rebel in bursty shooting is a huge usability problem, by far its worst in my opinion. When you talk about the likelihood of losing shots, nothing is worse than looking at "busy" in the viewfinder.
Another irritation, although not nearly as serious, is the very limited metering capability of the Rebel; not only does it lack spot and center weighted metering, but there's no way to select different metering modes -- it's evaluative all the time except if you use exposure lock wherein it's partially metered. That has been far more of a pain in the neck than I anticipated. OTOH there's always manual mode and the Sekonic.
Both cameras have a number of the same annoyances: AIfocus mode is next to worthless (presuming you attempt to use the automatic modes of the Rebel, which I wouldn't recommend for several reasons); automatic white balance is awful; no focusing aids in the viewfinder or capability of switching viewfinders; limited frame coverage of viewfinder. Even so either one of them offers a lot of bang for the buck. Image quality in particular is rather good; good enough to make L lenses worth buying even for the Rebel.
It's unfortunate that the weaknesses of the Rebel stack up on each other. Slow write speed means you can't work around metering limitations with exposure bracketing, for instance (one shot nearly fills the buffer and it's like 15 seconds to clear it even using 40x media), and likewise the inability to shoot RAW format in automatic modes means you can't avoid dealing with the crappy on-camera white balance issue.
Before I bought the Rebel I spent some time considering the differences. As an amateur tool the price difference between the bodies -- $800 at the time -- was very substantial, enough to make the difference between buying crap lenses and an L. But as a pro tool you're right, the Rebel is not a good buy. It's just too slow; the other differences are moot next to that (what the heck, none of my SLRs have any of this newfangled automation anyway). If I'd known how I was going to use the camera I would have sprung for the 10D, no question. Ahh, hindsight.
Sure do wish I could get a split viewfinder.
Around that time lots of hardware vendors were buying perpetual licenses to Unix -- in other words, the right to use the code without paying further royalties. That is not the same as having the right to give the code away.
IBM bought a similar license around the same time. Notice that they're in court....
What do you suppose the odds of that are?
I think a lot of you may be underestimating the geek level of many photo pros. While it's true that not too many pros use the Rebel, that may be in part because they had already jumped into the 10D, which is extremely popular despite being inferior to a number of other models in many respects.
I've known about the firmware hacks for about two months and I found out from a pro.
That said, the buffer size and write speed of the Rebel, not to mention the viewfinder limitations, are indeed poor enough that the 10D is far more appealing.
I can't tell you about the industry as a whole, but so far I haven't seen even one case of a large body of source that didn't have code cribbed from somewhere else (my current employer excluded, I haven't been here long enough to know one way or the other).
Often this is not widely known, i.e. only one developer might know it happened.
I do note that over time the practice has become more strongly discouraged. I believe it was the GPL that was behind a lot of that, with smaller companies anyway, because the GPL has been a very tempting code base -- but with obvious legal strings attached.