Or more likely, the geek who does buy one will end up offsetting the savings by throwing it in his machine with a 750W power supply and monster graphics card(s).
Savings are savings. Their accidental proximity to waste means nothing. If an environment-hating, beef-eating, AC-loving, 50" TV-in-every-room asshole drives a Toyota Prius, he saves as much gas as a non-showering, grass-eating hippie who also drives a Prius. Actually, he'll probably save more, since he probably drives more. The fact that he doesn't have a consistent green ethos doesn't hurt the gas mileage on his Prius. The belief that inconsistency discounts the value of a beneficial action is based on the social advantages of having an identity that is easily identified and classified by other people. When people say things like, "Hybrid Ford Escapes don't make any sense; if you care about the environment, you shouldn't get an SUV, and if you don't, you should buy a standard SUV and save your money," they are ignoring real efficiency and concentrating solely on social identity. It's true that a hybrid SUV won't ingratiate you with anyone, but the energy savings are real no matter whether anyone gives you credit for it. A Ford Escape gets better city mileage than a Honda Fit.
"Mediocre" has nothing to do with statistics. It's just an English word with no mathematical definition. Something that is "mediocre" plays an adequate part in a process where most of the value is produced by superior components. A very good sports team may have several mediocre players. A good meal may start with a mediocre appetizer. You might have a great vacation while staying at a mediocre hotel. When all of the contributors are of mediocre quality, the combined result is crap. A team with nothing but mediocre players is a very, very poor team. An album with nothing but mediocre songs is a crap album, not worth buying or listening to. Software developed by a team of two brilliant programmers and six mediocre ones may be pretty good, but software developed by eight mediocre programmers will be crap.
In many contexts the great bulk of contributors will be mediocre. In some contexts, mediocrity is the exception. For example, if you buy a six-pack of excellent beer, you don't expect to get a mediocre bottle. You don't expect to get your mail delivered by a mediocre postman -- the job is too simple to screw up. And, of course, you very rarely get a mediocre hundred dollar bill. (What would that be? A hundred dollar bill with snot on it?)
no "product" is important enough to deprive them of what they have been using forever
The stuff they've been using "forever" is just another product made possible by a policy decision made a long time ago. They created their world, and now they want to stop us from doing the same thing. If they object on practical grounds, moral grounds, aesthetic grounds, economic grounds, etc. then that's fine -- they're just taking part like everyone should, and they have the right to do so until they die. If they object on the grounds that they can't cope with change, e.g., they're afraid they won't be able to cope when their favorite radio shows switch over to FM or satellite or internet radio, then that's different. Inability to cope with change is just another infirmity of aging, like not being able to control your bowels. We don't let old people shit all over McDonald's just because they're old. We accommodate their infirmities to a certain extent, but we don't, for example, mandate that all newspapers be printed in a 24-point typeface. If getting rid of AM radio means more services for more people, we should do it. Old people will still be a market, and some enterprising person will find a way of getting them their Paul Harvey fix.
The lower bound on latency for a mesh is the path distance divided by the speed of light.
I think you mean a lower bound, as in, "A lower bound on latency for me getting to the grocery store and back is the path distance divided by the speed of light." Other, higher, lower bounds might apply. There may be a per-hop cost that is not related to routing -- what if the per-hop cost is not subject to Moore's law?
Probably because more people listen to AM radio and watch broadcast TV that would ever be WiMax customers.
It'll take about twenty years for mortality to render this incorrect. AM radio is like horses and buggies in 1920. And, with the amount of money at stake for media and telecommunications companies, there is no way commercial media outlets will ever present this issue in a compelling way to American voters without carefully framing it to push the agenda of their controlling companies. I don't think *any* company has a stake in letting geriatrics stifle future economic growth. I think even the AM stations are ultimately owned by conglomerates that have more stake in the future than in a dying class of customers.
the office formats have been nailed for years (with little exception)
Really? For how many years have the Office 2003 formats been nailed? How about Office 2007? Office 2007 documents seem to degrade gracefully when viewed under Office 2003, but that doesn't mean they degrade gracefully with other programs that were designed to render Office 2003 documents. PowerPoint documents are a huge pain for me. Maybe the people sending me PowerPoint presentations are way too creative, but all the good information tends to disappear. Usually somebody creates a five-stage slide that starts out with a little bit of text, and then more text slides in from the right, then a screenshot materializes, and then a graph and set of bullet points slide in from the top. Everything before that last bit of animation is the setup, and the last bit contains the real information I'm supposed to see. OpenOffice can't get that far. Plus, the text and images often aren't lined up the way they are under PowerPoint, so if something is supposed to be labeling something or pointing at something, the correspondence is lost. I open PowerPoint presentations on my Linux box just to decide whether and when I really need to read them, and when I really need to read them, I look at them under Windows.
The only e-mail program I've -ever- seen an unititiated user using is Outlook Express, and Thunderbird is almost identical.
Are all the commands named the same thing and located in the same place in the same menu? No? Then one in five people is going to be completely lost. Granted, I don't have much sympathy for them, but I'm not going to subject myself to their helplessness. I just let them use Windows.
All those hardware devices (mp3 players, cameras, etc) come with 3rd party apps that often don't work too nicely with other Windows apps (like media player). In better-integrated environments that are already expecting cameras/music players (KDE/Gnome), that stuff's already taken care of.
I use Kubuntu 7.10, so I've got a pretty up-to-date and consumer-friendly system.
I have a Brother MFC-8440, and Ubuntu has a driver for exactly that model. It only took a few minutes from plugging in the printer to printing my first document. It took me slightly longer to find out that I can usually only get off one or two print jobs before CUPS reports that the printer is no longer responding. Linux's fault? Probably not. Probably there's a bug in the printer, and the Windows drivers has some obscure workaround developed by the same guys who developed the printer firmware. But whose fault is not the point -- the point is that it doesn't work the way it should.
As for generic replacements for the custom software supplied with hardware, some people are actually a bit intimidated by their camera, scanner, etc. (and afraid of breaking it) and read the manual to figure out how it works. The manual steps them through the performance of basic tasks using the supplied software (or the standard Windows software). If they don't see the application described in the manual, the manual becomes useless.
Also, you're a bit optimistic about how well things work. Plenty of hardware devices actually don't work unless you use the install disk. My mother's camera showed up like a flash drive in Windows until she installed the photo software it came with. My Fuji Finepix F20 doesn't generate any response in Kubuntu. Just to be extra fair, I just plugged it in and tried to detect it using digiKam. When I tried "autodetect", digiKam found no cameras. I tried to add it manually, choosing "Fuji FinePix F20" as the model, and still it fails to detect it. (The camera reports that it has a USB connection.) digiKam doesn't give me any configurations options for the F20, so there isn't even anything to fiddle around with. I'm stuck. However -- and I am not kidding about this -- it does display a little message telling me what to do if
4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.
It could be... but I admitted that was a possibility.:-)
You admitted there could be a difference in programming skill and database design, but those are a little bit different. I don't know much about database administration myself, but I know that our db admins don't do any programming or database design, and when there's a performance problem they often fix it before we (the developers) hear anything about it. They rebuild indexes, instantiate views, and do other mysterious things that I don't know anything about and probably am not using the right words for.
All three solve the same problem (ie: the report in question) which MUST (by law) utilize the same data, calculate it the exact same way, come up with the exact same results... so no, there is no difference there. Some of each tables are not needed for the report - and arent called at all. The others (which are called) require the same exact data...
That doesn't mean all three products were designed to solve only that one problem. From this page you linked, it appears that the.NET solution was built using a generic toolkit for building complete CMR systems. I think there may have been some excess baggage there:-) And you didn't mention who did the job of assembling the components of this toolkit to create the program that produced the report.
not like.NET plugs right into MySQL or Postgres.
As far as I can tell from Googling around, all you need to plug a database into the.NET environment is a sufficiently up-to-date ADO.NET connector for it. Of course, Microsoft is going to keep the requirements moving as quickly as possible so that their products have an advantage, but there is at least one MySQL ADO.NET connector available.
The object model comes with overhead. My example of x->work calls y->work calls z->work is something you find in virtually all C++ code.
That's just code complexity, managed using object-oriented programming. These days C evokes a design style, where a library does one thing and does it in very no-nonsense, straightforward way. Unfortunately, that just doesn't work for a lot of development tasks. Sometimes you have to have bells and whistles and a zillion super-configurable features. The people who implement the bells and whistles rarely use C anymore.
They *used* to use C, and it was damned ugly. They got to choose between two design paradigms: procedural programming and OO. I've had to use ancient procedural libraries from my C++ programs, and I just tear my hair out at the things people used to do before OO. Things that would be fairly simple in an OO style became arcane collections of systematically-named methods of fifteen parameters each. Large procedural systems were awful, so people started implementing large systems using OO. That was a big factor in the early success of C++: people were doing OO development in C and were suffering because of the lack of language support. Basically, C++ was invented so that nobody would ever again have to fake things like polymorphism and inheritance in C. (But of course they went ahead and invented Gnome/GTK+ anyway, and now they're stuck using C macros to express inheritance relationships.)
Really, comparing the simplicity of C to the complexity of C++ only takes two forms. Either you're mocking the skill of the C++ programmer, who overlooked a simpler C-style way of solving his problem, or you're regretting the complexity of the problem that has to be solved. Usually it's the second. I'm guilty of this kind of reasoning all the time, when I say things like, "I wish I could ride my bike to <my favorite restaurant>." My favorite restaurant is thirty miles away, and I actually *could* ride my bike there. It would be sweaty, time-consuming, and a bit dangerous, but I could do it. Obviously when I say I wish I could do it, I mean that I wish that the task of getting there was an easier one that could be reasonably managed with a simple, satisfying, human-scale tool instead of a noisy, smelly monstrosity that is impossible for one person to fully understand. Still, in the end I have to admit that the restaurant really is thirty miles away, it isn't going to get any closer, and consequently it's more pleasant to drive.
So we made the original data structure a bit more complex, having it keep track of the current node and its direct dependents, and instead only passed a reference to that "bookmarked" node with each recursive call.
Okay, I misread your original statement and thought the same object got passed in every call. With each call passing a different object, the stack is storing state for you (as well as the stack bookkeeping data that you don't care about) so it isn't entirely wasted space. Managing that state in a loop using your own Stack object would indeed destroy the simplicity of the code.
I think anything you can do in C++ can also be done in C and I know that anything you do in C++ can be done with less overhead using C.
Errm, not really. C++ language implementers have more freedom than C programmers. To take gcc as an example, for each C++ language construct, if there were a faster C equivalent, the C++ front-end would just generate the same intermediate code as for the C equivalent. You only get extra overhead if you can't do it in C -- and that doesn't make any sense. (Extra overhead compared to what?) Furthermore, for C++ features like dynamic dispatch that can be faked in C, the compiler has more information to work with when it is expressed via a more specific C++ construct (like a virtual function call) than through a more general C construct (such as calling a function pointer held in a struct). You aren't going to implement dynamic dispatch in C as efficiently as a C++ compiler.
C++ comes with a lot of overhead.
Do you mean C++ libraries, which are only a burden if you use them? Exceptions, which are only a burden when you throw them or offer to catch them? OO stuff, which you don't have to use if you don't want and is at least as cheap as achieving the same functionality in C? RTTI, which is only used to support other optional C++ features that you don't have to use?
C++ is only more expensive than C in the same way that a week in Las Vegas is more expensive than a week in Garden City, Kansas. The base cost is the same, but when you've got a little bit extra to spend, at least Vegas has something fun to spend it on.
I don't know why the parent got down-modded. I think it deserves visibility.
higher level languages are just ways to automate certain formal methods
A very nice way of putting it.
i will never understand the argument for using languages without declarations and type checking because it "makes people more productive" as long as they don't make spelling errors
That argument is based on the belief that static type-checking requires that the type of *every* function and variable be declared. I know, it's wrong, but it will be years before most programmers are able to name a counter-example. In the meantime, the benefit of static type-checking has a cost: ubiquitous type declarations that clutter up the code and bog down development. The overall value of static type-checking grows with the size of the codebase. In my experience with Python, I start to wish for static type-checking when a project grows to 2,000 to 5,000 lines of code. Most projects eventually reach that size, but it's very frustrating to use a language like Java or C++ for early development on a project, because you are forced to commit a great deal of effort (type declarations) to exploratory code that you know will be thrown away. Early in a project, when you are moving quickly and can keep most of the design in your head, it is better to use a dynamic language and just try not to make mistakes. Neither option works well for all stages and all aspects of a project.
Eventually we won't have to choose. Even mainstream, conservative languages are starting to be a bit more helpful. For example, the new C++ "auto" keyword will save a lot of keystrokes, though it would be better if it were not needed.
Even C# and Java use pointers, you're just forced to dereference them every time you use them.
I don't know if there's a formal distinction between pointers and references, but in common usage the difference seems to be that you can explicitly perform arithmetic on pointers, but not on references. Pointer arithmetic destroys type safety, makes garbage collection problematic, and enables "clever" programmers to be very, very "clever."
(Sorry to give a pedantic response to your witty statement, but I'm sure there are some beginning programmers who appreciate the clarification.)
I mean, this is an issue with recursion in ALL languages
In Stackless Python you get to keep recursing until you exhaust the heap:-) And of course tail-recursive languages mean no worries when you can express the function tail-recursively.
my guess is that it has to do with the types that Java stores on the stack as opposed to the types that it stores on the heap
Interesting. This suggests that Java does a better-than-average job of using stack allocation wherever possible instead of storing objects on the heap. It's more space-efficient overall, but it consumes stack space more quickly.
Practically, the best way I've found to avoid overflow conditions is to limit the use of local variables as much as possible, and do most the work by passing down a reference to an object. Objects are stored on the heap, and the only thing on the stack in each recursive call is the local var that holds the reference.
That's just an iterative loop, inefficiently implemented using recursion. Why not use 'for' or 'while'?
Given an experienced C# developer makes six figures, I'm not sure that is inexpensive.
For some definition of "experienced" that excludes the vast majority of working C# developers, I guess. There are forces in my company pushing for more.NET development, and one of the advantages that has been touted for.NET is that it's supposedly too expensive to hire good Linux developers. Of course, our current.NET development effort is pretty sad. I don't think that's a coincidence. Good development managers go for quality over quantity, so it's natural that in a given company the perception that one platform is superior goes hand-in-hand with the perception that developers for that platform are expensive -- all the results are coming from the team that hired a handful of good developers instead of a herd of lightweights.
Microsoft seems to focus on getting things done, rather than elegance. That's what you mean, I think.
Microsoft focuses on marketable, saleable products. Their pitch is always amazing. They promise miracles. Often, the products are just an honest attempt to live up to a pitch that got way out of hand. When you ask why something in Visual Studio is done a certain way, the answer too often is that it sounds better that way, or it works better in the best-case scenario (i.e., the demo scenario).
The biggest villain in this way is Visual Studio integration. It sounds good to have every single Microsoft code generator and development tool integrated into Visual Studio. Everything is right there under your hands. The downside is that EVERY bug fix to EVERY tool you use has to be released as a patch to Visual Studio. You may not get the bug fix you need when you need it, simply because it's too tightly integrated into Visual Studio to fix easily or it's just the wrong time in Visual Studio's patch/release cycle. Hmmm, maybe it would have been better if it hadn't been integrated quite so "well."
The second biggest villain is invisibility vs. transparency. Visual Studio often makes it difficult to see what's going on behind the code generators and development tools. Then, when you finally find the guts, it's not nearly as nice as it would be if they knew you'd be looking at it. It's like sneaking into your host's private bathroom and finding out how messy they REALLY are when they aren't expecting guests. For the sake of making things super-easy and super-amazing in the optimistic case, all of the troublesome cases (bugs in the code generator, need to get to the bottom of an ambiguous or misleading error message, need to parameterize the code generation in a way that Microsoft did not and could not predict) are made nearly intractable. Why? It isn't because the optimistic case is the predominant one. Murphy's Law still holds, even when using Microsoft development tools. It's because the optimistic case is what matters for sales and marketing. The optimistic case is what you sell . The imperfect case is what developers live with. It's clear which one Microsoft cares about more.
[P.S. To top this off with an intemperate rant: The real biggest Microsoft villain is not Microsoft software, but it is a Microsoft product in a sense: blinkered Microsoft-only developers. You know who I'm talking about, the ones who never program on anything but Microsoft platforms and treat Microsoft "educational" marketing materials as if they were impartial advice from God. They never see the messy failures of Visual Studio because they dogmatically follow the optimistic case completely disregarding business requirements, performance requirements, and interoperability requirements. "Oh, we had to do it this way, because...." NO! You "had" to do it that way because that was the only straightforward way to do it using Microsoft tools, and it never occurred to you to push back against the tools instead of throwing the project
You do have a point about the unnecessary "allowedRange" variable. Some people love the documentation provided by variable names and encourage the creation of extra variables expressly for that purpose. I'm less enthusiastic about that style of programming, and here, I would probably write something like:
if (new Range(startDate, endDate).Contains(enteredDate))
The need for "new" is a language wart here, held over in Java and C# because C/C++ programmers would have a heart attack if you were "hiding" memory allocation. In this case there would be no heap allocation; escape analysis would show that the Range object can be allocated on the stack, and you would be able to compile the code down to exactly the same instructions as the code you described above. (I wasn't a CS major and only took the equivalent of half a traditional undergraduate compilers class, but even by that point we could do this kind of optimization, at least on paper.)
It seems like a small difference, but given enough code, the clarity of Range(startDate, endDate).Contains(enteredDate) becomes a big advantage. The only downside is that you have to remember whether Range represents an open, closed, or half-open interval.
But we shouldn't argue; we should just wait for Fortress. Then we can all write enteredDate [ startDate, endDate ) and everyone will be happy:-) (There's an "element of" symbol between enteredDate and the interval, but I can't see it when I preview... I hope it's just my browser.)
Good DB admins make the money they make for a reason -- administration makes a HUGE difference in the performance of databases, and many of the techniques used to tune database performance are nonstandard and nonportable. Even if you had "exactly the same setup" on both databases, one would have been configured in an inferior way, because each database requires its own brand of trickery. 4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.
Worse, it seems you're talking about drastically different data models. Did.NET create the bad data model, or did it merely enable morons (or bright yet ignorant people) to create a product? There's nothing wrong with enabling morons (or bright yet ignorant people) to get a little bit of work done, even if it doesn't result in blazing performance. Even allowing for that difference, it's obvious that a 126-table model was solving a larger problem than your 9-table model. A design that doesn't scale is a crappy solution for *any* problem, but you have no evidence that you could have solved the larger problem well -- you solved a different one. You probably solved exactly the problem your company needed solved, which is possible for an insider to do, but a difficult thing for an outsider, even when creating bespoke software. How can you expect us to believe that.NET was the problem when the business analysis behind the.NET implementation was clearly drastically wrong?
In any case, the massive difference in performance is a common-sense giveaway that you aren't looking at a meaningful comparison between platforms or database engines. I'm a Linux guy, and I personally hate Visual Studio and its code generators, but your comparison is exactly the kind of thing that gives upper management an excuse to cut engineers out of the loop on technology platform decisions. There's no evidence that.NET had anything to do with the performance differences you saw. Alternative explanations (bad data modeling, bad requirements analysis) are screaming in your face, and you have no way of ruling out the possibility that the MSSQL database was poorly administered. Yet you are eager to implicate.NET (though you have now introduced MSSQL into the mix as well -- what exactly does its performance have to do with.NET?) The engineers are just anti-M$ whiners, right? Well, I guess sometimes they are. And that's a big part of the reason why CTOs end up wrapped around a M$ salesman's finger, floating in fantasies of systems that scale effortlessly and internal tools that magically integrate when you need them, while their engineers scream, "No! Wake up! Wake up!"
Each language out there has a large set of libraries available, either by default or a download away.
Sadly, this is not true. Even for languages such as C and Java, it is true in different ways for different languages. Here is roughly what you do when you need to do Z in different languages:
C It will take you approximately 3.7 seconds to locate seven thousand Z libraries and pick out a mature, tested one. This leaves lots of time to painstakingly learn its arcane (and usually underdocumented) macro usage and memory management conventions, and then write the fifteen hundred lines of C code needed to make three calls into the library.
C++ First, see if there is a Boost library for Z. If not, put your affairs in order and check out the handful of large, somewhat specialized C++ frameworks, which were designed for mysterious purposes evidently quite different from yours, and which (owing to compiler limitations that, trust us, were quite a force to be reckoned with in 1855, what with the Crimean War holding up the standardization effort) are very much like C libraries in their use of macros and memory management. With that caveat, I'm sure you can find a framework with a good Z library. Of course, you might as well use the framework's support for logging, concurrency, memory management, networking, file access, and containers. Otherwise, things could be... tense. Awkward. You know what I mean. A guy wakes up and his application architecture is all busted up. Nobody wants that.
Fortran Of course there's a stable, documented, highly performant library for Z. Wait a second, what is this Z thing you're talking about? I can't find it in my encyclopedia of numerical methods.
.NET languages There isn't a Z library per se, but Visual Studio will generate one for you in C#. Just walk through this wizard to generate 8,000 lines of Enterprise Web Z for the Web Enterprise code for your application. Microsoft will make sure that any bugs in the code generator will be scrupulously undocumented and then fixed in the next release of Visual Studio -- which is probably just a year or two away.
Java There are open source libraries, but why not use the official Sun-provided library? It's probably simple, complete, and powerful. Or it may be complex, complete, and powerful. Or it may be powerful, complete, and so complex that it sustains your entire career. You can be "The javax.Z Guy" at your company and make a living writing XML configuration files for people who need to do Z in Java.
Common Lisp Ask on comp.lang.lisp. You'll get one or both (probably both) of the following answers: Answer 1. "Why do you want a library to do Z? Common Lisp is so powerful you don't need a library." And, if you're lucky: "Look, here's thirty lines of Lisp that give you most of the functionality you need. Just another fifty lines or so to cover every possible feature." (Go ahead and copy and paste the code. It probably works.) Answer 2. "In 1542, Gustavus Flavius Adolphus wrote a Z library in Burgundian Lisp, and it was later translated into Common Lisp by a talented young scribe. It's so perfect nobody has ever dared to offer an alternative. It's available via oftp (Olde File Transfer Protocol) from a server at MIT, unless the server collapsed in a cloud of dust, in which case it is tragically lost forever." (Just download it. Ye olde ftp server is still running, miraculous as it seems, and the library is actually usable, though the culture shock will leave you a bit dazed.)
Scheme There's a Z library available... for another implementation of Scheme. Now is a great time to switch!
Python is actually fine across Mac OS X, Linux/Unix and Windows.
It also runs on.NET (IronPython) and Java (Jython). Jython lagged for a while, but it is catching up quickly, and Sun just hired a Jython developer to work full-time on the project. I believe there's a Python implementation for Parrot in the works as well, so Python's bases are well-covered.
I'm still waiting on someone to demonstrate how I can get Firefox to eat up all the memory on my computer.
As far as I know, the original problems were never completely deterministically reproducible, merely widely experienced. I had awful problems with Firefox until Firefox 2. With Firefox 1, I had to shut my browser down every couple of days or it would crash, under both Linux and Windows. Nothing changed about my browsing habits, but Firefox 2 works well for me. If people say they still experience the same problems under Firefox 2 and 3, I'm willing to believe they're telling the truth. On the other hand, given the outrageous denial and recriminations that some Firefox developers indulged in over the problems in Firefox 1, these continuing reports might just be from angry people and reverse-fanboys.
I think this is a good object lesson for developers, open-source and otherwise. If it hadn't been for the denial and name-calling by Firefox developers and fanboys over the original problems (which were eventually acknowledged to be real) people would try new versions of Firefox with an open mind. Instead, it looks like the lingering bad feelings will continue to cloud Firefox's reputation even after Firefox 3 is released.
I have about 10 of these out there now, and every one of them has said "they like their new program". They don't use Windows anymore.
"Why can't I use the photo program that came with my new camera?"
"Why can't I watch the video of your cousin's baby taking its first steps? She sent a link and I click on it and it doesn't work. Your goddamned aunt Agnes got to watch it and she's making me feel like a fool! It's just a bunch of flashing blocks!"
"I error-checked a PowerPoint presentation last night for my boss, and when he showed it to the executives today there was a bunch of stuff I hadn't seen! There were some mistakes I didn't catch, and now he's mad at me."
"This new email program doesn't have the commands I always use. It has a bunch of different ones that do the same things, but they're in different places. It's all screwed up."
"Grandma sent me a copy of the family newsletter so I could fill in our family news, but when I open it up or print it out, it's gobbledygook! Everything is on top of each other!"
"We were two hours late to the family reunion because we got lost because I couldn't print out the directions and then I rebooted to Windows and I couldn't find the file and... What? What do you mean I should have 'kicked cups-dee'? You're aunt's name is Mary-Dee, not Cups-Dee, and she's very nice. I don't know why you want me to kick her. It's not her fault we were late. It's that stupid program you put on our computer."
If you're not hearing these complaints, I sincerely doubt they're using Linux much:-)
This isn't a knock against Linux. Faithfully rendering the newest Microsoft Office file formats is an impossible standard. Keeping up with printer drivers is a thankless task, often with no help from manufacturers, so it's no surprise if something gets in a bad state occasionally. It isn't Linux's fault that the CD that came with Uncle Fred's new digital camera only contains Windows and Mac software.
All of these problems are fairly trivial for users like us: scp the Word and PowerPoint files to a Windows computer and view them there, learn the new email program, watch the baby video in VLC instead of Kaffeine, restart cupsd and/or power-cycle the printer. Treat the camera as a generic USB storage device and figure out the directory structure it presents. No problem for people like us, but not at all reasonable for non-geeks. Maybe your relatives are extraordinarily patient and adaptable people -- or maybe they're just using Windows and not telling you about it.
I've been left hunting for drivers several times on Windows, most recently for a USB-to-serial converter from a major manufacturer. I bought it new, plugged it in, and started using it. Windows seemed to detect it and handle it fine. After a few days I found out that when I unplugged the USB connection, half the time the driver would freeze Windows. I couldn't find the CD that came with the device, so I went to the manufacturer's web site. Even though I had the model name and product number of the device, I couldn't find the driver. I gave up looking several times, but the crashes kept sending me back. Eventually I sent an email to the manufacturer, and I got back a download link for a single file. What was I supposed to do with the file? I had no clue. I tried modifying the URL to the file to find another page, but no luck. I had to use Google to find install instructions. Then, after I installed the driver and rebooted, the behavior wasn't completely fixed. The crashes became less frequent, but they still happened often enough that I gave up on the device and bought another USB-to-serial converter, which turned out to have a similar problem.
I also have an old Dell that I couldn't install Windows XP Pro on because partway through the install process, the screen became garbled. It seemed like XP tried to load a better driver for the video card and ended up using one that was a little bit off. That was especially frustrating because the box came with Windows 2000 on it, and I had reinstalled Windows 2000 on it from scratch (using a retail copy of Windows 2000 Pro) in the past. I thought Windows XP's driver support was a superset of Windows 2000's, but maybe Microsoft stopped including a suitable driver for that model on its Windows install disks. I didn't bother hunting for a Windows driver; I just installed Linux.
It's wishful thinking. The idea that "a lot of gamers" would be "looking to Linux" as an alternative to Vista is silly. Gamers are not going to flock to Linux and camp out there, without games, until the gaming industry comes to them. Gamers will go to a platform where they expect the next generation of games to be available. In other words, they'll end up on Vista. The only way gamers will switch to Linux on the desktop is if they switch to console gaming.
At the moment the only significant consumer movement towards Linux is by people who want to save money and/or use low-end hardware. It's a small phenomenon, and the gaming industry has no interest in those people anyway, regardless of what platform they use.
I've always thought this was part of the appeal of PC gaming myself.
Sure, not everyone wants to stay on the upgrade treadmill... I fell off it a while back myself, and my system is nowhere near "bleeding edge" anymore... But it's nice to be able to constantly push the limits of what the hardware and software can do.
I think this is the point of the article -- PC gaming only works for people who think this way. People who want to be able to play games without understanding what goes on inside their computer are screwed. Say a kid's dad buys him a computer for his birthday. Then the kid can't play any games, because his father didn't understand that most computers have insufficient graphics to play currently available games. PC gaming is *only* for people who can at least name the major components of their computer, decipher the requirements on game boxes, read gaming websites to get the scoop on upcoming technologies and games, and spend their money efficiently to get the hardware required to play the games they want.
I don't blame PC retailers. They should sell cheap computers. They shouldn't artificially inflate the price of PCs just so every PC is a gaming box. The responsibility falls squarely on game creators who only want to work with the latest technology and make the prettiest games. Obviously this attitude alienates them from the majority of potential buyers, because most people aren't obsessed with the latest computer technologies. Given $300 to spend, many people will not choose to upgrade their computer. They might spend it on a tent, a new outfit, brewing equipment, clothes for their kids, medical care, or a trip to see their favorite band instead of blowing it on gaming technology. According to Tim Sweeney, this makes it impossible for him to market games to those people. Those ignorant bastards, spending money on their favorite pastimes instead of spending it on video cards and RAM upgrades. How horrible for the gaming industry to have to put up with that kind of behavior.
The computer industry should not take that choice away from them, and it seems to me that is what Tim Sweeney is asking for. He wants to close the 100x spread between gaming boxes and cheap retail boxes and reduce it to 10x or less. From the interview, this is how I understand his logic:
I only want to create games targeted at the newest and most expensive gaming platforms.
I can only scale a game's processing requirements down by about 10x.
Many people prefer to buy cheap computers with integrated graphics, which are 100x slower (for gaming) than high-end machines.
Clearly we would all be better off if every PC owner could buy current games.
Therefore, the PC industry should not enable people to make the "mistake" of buying cheap computers with integrated graphics. Retail sellers should only allow people to buy machines that have at least 10% of the gaming capacity of the newest machines.
Obviously if Tim Sweeney is concerned about people with integrated graphics, he could design games that run on integrated graphics. He wants to have his cake and eat it too -- he wants the prestige of designing for bleeding-edge gamers and the large market inherent in designing for average computer users. And he wants the retail PC industry to accomplish this for him by forcing everyone into a narrow range of hardware choices.
But I suspect that if you are a developer, you are blissfully unaware of the headaches you cause your sysadmins, who go to great lengths to protect the company from the hassles you cause by your un-considered assumption that whatever you want at any given moment is in fact the best possible idea.
Believe me, when one of the dev servers or QA servers (which are managed machines running a standard platform) goes haywire and starts screwing up the network, sysadmins raise the alarm pretty quickly. They don't go around covering up our screw-ups. They fix our screw-ups often enough, but they make sure we know what happened, with a cc: to the whole development group.
With that plus two more things, I can think of three factors that make our system workable that may not be present in other companies:
Our sysadmins aren't subservient to us. I known that if I muck up our internal systems, the guardians of those systems (the sysadmins) can call me to account.
We don't deploy our own code to unmanaged boxes, except for client programs that are only running when we use them.
Our sysadmins play an important role in the development process (allocating and configuring test boxes,) so we can't afford to piss them off.
Slashdot Mirror
Savings are savings. Their accidental proximity to waste means nothing. If an environment-hating, beef-eating, AC-loving, 50" TV-in-every-room asshole drives a Toyota Prius, he saves as much gas as a non-showering, grass-eating hippie who also drives a Prius. Actually, he'll probably save more, since he probably drives more. The fact that he doesn't have a consistent green ethos doesn't hurt the gas mileage on his Prius. The belief that inconsistency discounts the value of a beneficial action is based on the social advantages of having an identity that is easily identified and classified by other people. When people say things like, "Hybrid Ford Escapes don't make any sense; if you care about the environment, you shouldn't get an SUV, and if you don't, you should buy a standard SUV and save your money," they are ignoring real efficiency and concentrating solely on social identity. It's true that a hybrid SUV won't ingratiate you with anyone, but the energy savings are real no matter whether anyone gives you credit for it. A Ford Escape gets better city mileage than a Honda Fit.
(non-beef-eating Prius driver)
"Mediocre" has nothing to do with statistics. It's just an English word with no mathematical definition. Something that is "mediocre" plays an adequate part in a process where most of the value is produced by superior components. A very good sports team may have several mediocre players. A good meal may start with a mediocre appetizer. You might have a great vacation while staying at a mediocre hotel. When all of the contributors are of mediocre quality, the combined result is crap. A team with nothing but mediocre players is a very, very poor team. An album with nothing but mediocre songs is a crap album, not worth buying or listening to. Software developed by a team of two brilliant programmers and six mediocre ones may be pretty good, but software developed by eight mediocre programmers will be crap.
In many contexts the great bulk of contributors will be mediocre. In some contexts, mediocrity is the exception. For example, if you buy a six-pack of excellent beer, you don't expect to get a mediocre bottle. You don't expect to get your mail delivered by a mediocre postman -- the job is too simple to screw up. And, of course, you very rarely get a mediocre hundred dollar bill. (What would that be? A hundred dollar bill with snot on it?)
Really? For how many years have the Office 2003 formats been nailed? How about Office 2007? Office 2007 documents seem to degrade gracefully when viewed under Office 2003, but that doesn't mean they degrade gracefully with other programs that were designed to render Office 2003 documents. PowerPoint documents are a huge pain for me. Maybe the people sending me PowerPoint presentations are way too creative, but all the good information tends to disappear. Usually somebody creates a five-stage slide that starts out with a little bit of text, and then more text slides in from the right, then a screenshot materializes, and then a graph and set of bullet points slide in from the top. Everything before that last bit of animation is the setup, and the last bit contains the real information I'm supposed to see. OpenOffice can't get that far. Plus, the text and images often aren't lined up the way they are under PowerPoint, so if something is supposed to be labeling something or pointing at something, the correspondence is lost. I open PowerPoint presentations on my Linux box just to decide whether and when I really need to read them, and when I really need to read them, I look at them under Windows.
Are all the commands named the same thing and located in the same place in the same menu? No? Then one in five people is going to be completely lost. Granted, I don't have much sympathy for them, but I'm not going to subject myself to their helplessness. I just let them use Windows.
I use Kubuntu 7.10, so I've got a pretty up-to-date and consumer-friendly system.
I have a Brother MFC-8440, and Ubuntu has a driver for exactly that model. It only took a few minutes from plugging in the printer to printing my first document. It took me slightly longer to find out that I can usually only get off one or two print jobs before CUPS reports that the printer is no longer responding. Linux's fault? Probably not. Probably there's a bug in the printer, and the Windows drivers has some obscure workaround developed by the same guys who developed the printer firmware. But whose fault is not the point -- the point is that it doesn't work the way it should.
As for generic replacements for the custom software supplied with hardware, some people are actually a bit intimidated by their camera, scanner, etc. (and afraid of breaking it) and read the manual to figure out how it works. The manual steps them through the performance of basic tasks using the supplied software (or the standard Windows software). If they don't see the application described in the manual, the manual becomes useless.
Also, you're a bit optimistic about how well things work. Plenty of hardware devices actually don't work unless you use the install disk. My mother's camera showed up like a flash drive in Windows until she installed the photo software it came with. My Fuji Finepix F20 doesn't generate any response in Kubuntu. Just to be extra fair, I just plugged it in and tried to detect it using digiKam. When I tried "autodetect", digiKam found no cameras. I tried to add it manually, choosing "Fuji FinePix F20" as the model, and still it fails to detect it. (The camera reports that it has a USB connection.) digiKam doesn't give me any configurations options for the F20, so there isn't even anything to fiddle around with. I'm stuck. However -- and I am not kidding about this -- it does display a little message telling me what to do if
That's just code complexity, managed using object-oriented programming. These days C evokes a design style, where a library does one thing and does it in very no-nonsense, straightforward way. Unfortunately, that just doesn't work for a lot of development tasks. Sometimes you have to have bells and whistles and a zillion super-configurable features. The people who implement the bells and whistles rarely use C anymore.
They *used* to use C, and it was damned ugly. They got to choose between two design paradigms: procedural programming and OO. I've had to use ancient procedural libraries from my C++ programs, and I just tear my hair out at the things people used to do before OO. Things that would be fairly simple in an OO style became arcane collections of systematically-named methods of fifteen parameters each. Large procedural systems were awful, so people started implementing large systems using OO. That was a big factor in the early success of C++: people were doing OO development in C and were suffering because of the lack of language support. Basically, C++ was invented so that nobody would ever again have to fake things like polymorphism and inheritance in C. (But of course they went ahead and invented Gnome/GTK+ anyway, and now they're stuck using C macros to express inheritance relationships.)
Really, comparing the simplicity of C to the complexity of C++ only takes two forms. Either you're mocking the skill of the C++ programmer, who overlooked a simpler C-style way of solving his problem, or you're regretting the complexity of the problem that has to be solved. Usually it's the second. I'm guilty of this kind of reasoning all the time, when I say things like, "I wish I could ride my bike to <my favorite restaurant>." My favorite restaurant is thirty miles away, and I actually *could* ride my bike there. It would be sweaty, time-consuming, and a bit dangerous, but I could do it. Obviously when I say I wish I could do it, I mean that I wish that the task of getting there was an easier one that could be reasonably managed with a simple, satisfying, human-scale tool instead of a noisy, smelly monstrosity that is impossible for one person to fully understand. Still, in the end I have to admit that the restaurant really is thirty miles away, it isn't going to get any closer, and consequently it's more pleasant to drive.
C++ is only more expensive than C in the same way that a week in Las Vegas is more expensive than a week in Garden City, Kansas. The base cost is the same, but when you've got a little bit extra to spend, at least Vegas has something fun to spend it on.
A very nice way of putting it.
That argument is based on the belief that static type-checking requires that the type of *every* function and variable be declared. I know, it's wrong, but it will be years before most programmers are able to name a counter-example. In the meantime, the benefit of static type-checking has a cost: ubiquitous type declarations that clutter up the code and bog down development. The overall value of static type-checking grows with the size of the codebase. In my experience with Python, I start to wish for static type-checking when a project grows to 2,000 to 5,000 lines of code. Most projects eventually reach that size, but it's very frustrating to use a language like Java or C++ for early development on a project, because you are forced to commit a great deal of effort (type declarations) to exploratory code that you know will be thrown away. Early in a project, when you are moving quickly and can keep most of the design in your head, it is better to use a dynamic language and just try not to make mistakes. Neither option works well for all stages and all aspects of a project.
Eventually we won't have to choose. Even mainstream, conservative languages are starting to be a bit more helpful. For example, the new C++ "auto" keyword will save a lot of keystrokes, though it would be better if it were not needed.
(Sorry to give a pedantic response to your witty statement, but I'm sure there are some beginning programmers who appreciate the clarification.)
For some definition of "experienced" that excludes the vast majority of working C# developers, I guess. There are forces in my company pushing for more .NET development, and one of the advantages that has been touted for .NET is that it's supposedly too expensive to hire good Linux developers. Of course, our current .NET development effort is pretty sad. I don't think that's a coincidence. Good development managers go for quality over quantity, so it's natural that in a given company the perception that one platform is superior goes hand-in-hand with the perception that developers for that platform are expensive -- all the results are coming from the team that hired a handful of good developers instead of a herd of lightweights.
Microsoft focuses on marketable, saleable products. Their pitch is always amazing. They promise miracles. Often, the products are just an honest attempt to live up to a pitch that got way out of hand. When you ask why something in Visual Studio is done a certain way, the answer too often is that it sounds better that way, or it works better in the best-case scenario (i.e., the demo scenario).
The biggest villain in this way is Visual Studio integration. It sounds good to have every single Microsoft code generator and development tool integrated into Visual Studio. Everything is right there under your hands. The downside is that EVERY bug fix to EVERY tool you use has to be released as a patch to Visual Studio. You may not get the bug fix you need when you need it, simply because it's too tightly integrated into Visual Studio to fix easily or it's just the wrong time in Visual Studio's patch/release cycle. Hmmm, maybe it would have been better if it hadn't been integrated quite so "well."
The second biggest villain is invisibility vs. transparency. Visual Studio often makes it difficult to see what's going on behind the code generators and development tools. Then, when you finally find the guts, it's not nearly as nice as it would be if they knew you'd be looking at it. It's like sneaking into your host's private bathroom and finding out how messy they REALLY are when they aren't expecting guests. For the sake of making things super-easy and super-amazing in the optimistic case, all of the troublesome cases (bugs in the code generator, need to get to the bottom of an ambiguous or misleading error message, need to parameterize the code generation in a way that Microsoft did not and could not predict) are made nearly intractable. Why? It isn't because the optimistic case is the predominant one. Murphy's Law still holds, even when using Microsoft development tools. It's because the optimistic case is what matters for sales and marketing. The optimistic case is what you sell . The imperfect case is what developers live with. It's clear which one Microsoft cares about more.
[P.S. To top this off with an intemperate rant: The real biggest Microsoft villain is not Microsoft software, but it is a Microsoft product in a sense: blinkered Microsoft-only developers. You know who I'm talking about, the ones who never program on anything but Microsoft platforms and treat Microsoft "educational" marketing materials as if they were impartial advice from God. They never see the messy failures of Visual Studio because they dogmatically follow the optimistic case completely disregarding business requirements, performance requirements, and interoperability requirements. "Oh, we had to do it this way, because...." NO! You "had" to do it that way because that was the only straightforward way to do it using Microsoft tools, and it never occurred to you to push back against the tools instead of throwing the project
The need for "new" is a language wart here, held over in Java and C# because C/C++ programmers would have a heart attack if you were "hiding" memory allocation. In this case there would be no heap allocation; escape analysis would show that the Range object can be allocated on the stack, and you would be able to compile the code down to exactly the same instructions as the code you described above. (I wasn't a CS major and only took the equivalent of half a traditional undergraduate compilers class, but even by that point we could do this kind of optimization, at least on paper.)
It seems like a small difference, but given enough code, the clarity of Range(startDate, endDate).Contains(enteredDate) becomes a big advantage. The only downside is that you have to remember whether Range represents an open, closed, or half-open interval.
But we shouldn't argue; we should just wait for Fortress. Then we can all write enteredDate [ startDate, endDate ) and everyone will be happy
Good DB admins make the money they make for a reason -- administration makes a HUGE difference in the performance of databases, and many of the techniques used to tune database performance are nonstandard and nonportable. Even if you had "exactly the same setup" on both databases, one would have been configured in an inferior way, because each database requires its own brand of trickery. 4m37s vs. 14s could, potentially, be merely the difference between skillful and unskillful database administration.
.NET create the bad data model, or did it merely enable morons (or bright yet ignorant people) to create a product? There's nothing wrong with enabling morons (or bright yet ignorant people) to get a little bit of work done, even if it doesn't result in blazing performance. Even allowing for that difference, it's obvious that a 126-table model was solving a larger problem than your 9-table model. A design that doesn't scale is a crappy solution for *any* problem, but you have no evidence that you could have solved the larger problem well -- you solved a different one. You probably solved exactly the problem your company needed solved, which is possible for an insider to do, but a difficult thing for an outsider, even when creating bespoke software. How can you expect us to believe that .NET was the problem when the business analysis behind the .NET implementation was clearly drastically wrong?
.NET had anything to do with the performance differences you saw. Alternative explanations (bad data modeling, bad requirements analysis) are screaming in your face, and you have no way of ruling out the possibility that the MSSQL database was poorly administered. Yet you are eager to implicate .NET (though you have now introduced MSSQL into the mix as well -- what exactly does its performance have to do with .NET?) The engineers are just anti-M$ whiners, right? Well, I guess sometimes they are. And that's a big part of the reason why CTOs end up wrapped around a M$ salesman's finger, floating in fantasies of systems that scale effortlessly and internal tools that magically integrate when you need them, while their engineers scream, "No! Wake up! Wake up!"
Worse, it seems you're talking about drastically different data models. Did
In any case, the massive difference in performance is a common-sense giveaway that you aren't looking at a meaningful comparison between platforms or database engines. I'm a Linux guy, and I personally hate Visual Studio and its code generators, but your comparison is exactly the kind of thing that gives upper management an excuse to cut engineers out of the loop on technology platform decisions. There's no evidence that
It will take you approximately 3.7 seconds to locate seven thousand Z libraries and pick out a mature, tested one. This leaves lots of time to painstakingly learn its arcane (and usually underdocumented) macro usage and memory management conventions, and then write the fifteen hundred lines of C code needed to make three calls into the library.
First, see if there is a Boost library for Z. If not, put your affairs in order and check out the handful of large, somewhat specialized C++ frameworks, which were designed for mysterious purposes evidently quite different from yours, and which (owing to compiler limitations that, trust us, were quite a force to be reckoned with in 1855, what with the Crimean War holding up the standardization effort) are very much like C libraries in their use of macros and memory management. With that caveat, I'm sure you can find a framework with a good Z library. Of course, you might as well use the framework's support for logging, concurrency, memory management, networking, file access, and containers. Otherwise, things could be... tense. Awkward. You know what I mean. A guy wakes up and his application architecture is all busted up. Nobody wants that.
Of course there's a stable, documented, highly performant library for Z. Wait a second, what is this Z thing you're talking about? I can't find it in my encyclopedia of numerical methods.
There isn't a Z library per se, but Visual Studio will generate one for you in C#. Just walk through this wizard to generate 8,000 lines of Enterprise Web Z for the Web Enterprise code for your application. Microsoft will make sure that any bugs in the code generator will be scrupulously undocumented and then fixed in the next release of Visual Studio -- which is probably just a year or two away.
There are open source libraries, but why not use the official Sun-provided library? It's probably simple, complete, and powerful. Or it may be complex, complete, and powerful. Or it may be powerful, complete, and so complex that it sustains your entire career. You can be "The javax.Z Guy" at your company and make a living writing XML configuration files for people who need to do Z in Java.
Ask on comp.lang.lisp. You'll get one or both (probably both) of the following answers:
Answer 1. "Why do you want a library to do Z? Common Lisp is so powerful you don't need a library." And, if you're lucky: "Look, here's thirty lines of Lisp that give you most of the functionality you need. Just another fifty lines or so to cover every possible feature." (Go ahead and copy and paste the code. It probably works.)
Answer 2. "In 1542, Gustavus Flavius Adolphus wrote a Z library in Burgundian Lisp, and it was later translated into Common Lisp by a talented young scribe. It's so perfect nobody has ever dared to offer an alternative. It's available via oftp (Olde File Transfer Protocol) from a server at MIT, unless the server collapsed in a cloud of dust, in which case it is tragically lost forever." (Just download it. Ye olde ftp server is still running, miraculous as it seems, and the library is actually usable, though the culture shock will leave you a bit dazed.)
There's a Z library available... for another implementation of Scheme. Now is a great time to switch!
Anyone?
I think this is a good object lesson for developers, open-source and otherwise. If it hadn't been for the denial and name-calling by Firefox developers and fanboys over the original problems (which were eventually acknowledged to be real) people would try new versions of Firefox with an open mind. Instead, it looks like the lingering bad feelings will continue to cloud Firefox's reputation even after Firefox 3 is released.
"Why can't I use the photo program that came with my new camera?"
"Why can't I watch the video of your cousin's baby taking its first steps? She sent a link and I click on it and it doesn't work. Your goddamned aunt Agnes got to watch it and she's making me feel like a fool! It's just a bunch of flashing blocks!"
"I error-checked a PowerPoint presentation last night for my boss, and when he showed it to the executives today there was a bunch of stuff I hadn't seen! There were some mistakes I didn't catch, and now he's mad at me."
"This new email program doesn't have the commands I always use. It has a bunch of different ones that do the same things, but they're in different places. It's all screwed up."
"Grandma sent me a copy of the family newsletter so I could fill in our family news, but when I open it up or print it out, it's gobbledygook! Everything is on top of each other!"
"We were two hours late to the family reunion because we got lost because I couldn't print out the directions and then I rebooted to Windows and I couldn't find the file and... What? What do you mean I should have 'kicked cups-dee'? You're aunt's name is Mary-Dee, not Cups-Dee, and she's very nice. I don't know why you want me to kick her. It's not her fault we were late. It's that stupid program you put on our computer."
If you're not hearing these complaints, I sincerely doubt they're using Linux much :-)
This isn't a knock against Linux. Faithfully rendering the newest Microsoft Office file formats is an impossible standard. Keeping up with printer drivers is a thankless task, often with no help from manufacturers, so it's no surprise if something gets in a bad state occasionally. It isn't Linux's fault that the CD that came with Uncle Fred's new digital camera only contains Windows and Mac software.
All of these problems are fairly trivial for users like us: scp the Word and PowerPoint files to a Windows computer and view them there, learn the new email program, watch the baby video in VLC instead of Kaffeine, restart cupsd and/or power-cycle the printer. Treat the camera as a generic USB storage device and figure out the directory structure it presents. No problem for people like us, but not at all reasonable for non-geeks. Maybe your relatives are extraordinarily patient and adaptable people -- or maybe they're just using Windows and not telling you about it.
It happens on both systems.
I've been left hunting for drivers several times on Windows, most recently for a USB-to-serial converter from a major manufacturer. I bought it new, plugged it in, and started using it. Windows seemed to detect it and handle it fine. After a few days I found out that when I unplugged the USB connection, half the time the driver would freeze Windows. I couldn't find the CD that came with the device, so I went to the manufacturer's web site. Even though I had the model name and product number of the device, I couldn't find the driver. I gave up looking several times, but the crashes kept sending me back. Eventually I sent an email to the manufacturer, and I got back a download link for a single file. What was I supposed to do with the file? I had no clue. I tried modifying the URL to the file to find another page, but no luck. I had to use Google to find install instructions. Then, after I installed the driver and rebooted, the behavior wasn't completely fixed. The crashes became less frequent, but they still happened often enough that I gave up on the device and bought another USB-to-serial converter, which turned out to have a similar problem.
I also have an old Dell that I couldn't install Windows XP Pro on because partway through the install process, the screen became garbled. It seemed like XP tried to load a better driver for the video card and ended up using one that was a little bit off. That was especially frustrating because the box came with Windows 2000 on it, and I had reinstalled Windows 2000 on it from scratch (using a retail copy of Windows 2000 Pro) in the past. I thought Windows XP's driver support was a superset of Windows 2000's, but maybe Microsoft stopped including a suitable driver for that model on its Windows install disks. I didn't bother hunting for a Windows driver; I just installed Linux.
It's wishful thinking. The idea that "a lot of gamers" would be "looking to Linux" as an alternative to Vista is silly. Gamers are not going to flock to Linux and camp out there, without games, until the gaming industry comes to them. Gamers will go to a platform where they expect the next generation of games to be available. In other words, they'll end up on Vista. The only way gamers will switch to Linux on the desktop is if they switch to console gaming.
At the moment the only significant consumer movement towards Linux is by people who want to save money and/or use low-end hardware. It's a small phenomenon, and the gaming industry has no interest in those people anyway, regardless of what platform they use.
I don't blame PC retailers. They should sell cheap computers. They shouldn't artificially inflate the price of PCs just so every PC is a gaming box. The responsibility falls squarely on game creators who only want to work with the latest technology and make the prettiest games. Obviously this attitude alienates them from the majority of potential buyers, because most people aren't obsessed with the latest computer technologies. Given $300 to spend, many people will not choose to upgrade their computer. They might spend it on a tent, a new outfit, brewing equipment, clothes for their kids, medical care, or a trip to see their favorite band instead of blowing it on gaming technology. According to Tim Sweeney, this makes it impossible for him to market games to those people. Those ignorant bastards, spending money on their favorite pastimes instead of spending it on video cards and RAM upgrades. How horrible for the gaming industry to have to put up with that kind of behavior.
The computer industry should not take that choice away from them, and it seems to me that is what Tim Sweeney is asking for. He wants to close the 100x spread between gaming boxes and cheap retail boxes and reduce it to 10x or less. From the interview, this is how I understand his logic:
Obviously if Tim Sweeney is concerned about people with integrated graphics, he could design games that run on integrated graphics. He wants to have his cake and eat it too -- he wants the prestige of designing for bleeding-edge gamers and the large market inherent in designing for average computer users. And he wants the retail PC industry to accomplish this for him by forcing everyone into a narrow range of hardware choices.
With that plus two more things, I can think of three factors that make our system workable that may not be present in other companies: