You can't effectively compare the prices of the two without a context, such as the lifetime of the server and the number of clients that are expected to be connected to it.
There's a feature missing from that list that's quite a terrible omission - "break all 3rd party MSN clients - again."
How often do they release without that gem of a feature? Hell, they even enhance and update it between releases!
In fairness, they're quite within their rights in doing so, but you'd think they'd break 3rd party clients PROPERLY if they were going to, eg require TLS with the right client cert. That way, third party products would have to bundle a cert that the MSN license said was only licensed for use with MSN. I suspect their legal ground would then be rather shakier (but then again, so would MS's anti-trust status).
I always hated functional programming, having been forced to learn to use utterly crippled pure-functional teaching languages. Uggh. Consequently, I thought functional programming was pointless academic wank.
I didn't forget how to do it, though.
With the Python 'map', 'filter', 'zip' and 'reduce' functions, I found myself breaking into segments of functional style again, where it was faster / simpler / safer / cleaner.
List comprehensions increased this further, largely by eliminating the horror that is the nested map and filter jungle.
Some programs, especially data processing ones, I now write almost purely functionally. I'll usually write a series of functional blocks that perform each major transformation, put them in separate one-line functions, then perform each block in series in the main() function.
I generally find this results in much less buggy, faster, and better designed code.
The most important thing is that I can use imperative code where it's more appropraite, and functional code where it fits best. That's just fantastic.
I'm doing it now, and I must agree - it's pretty slow going.
It's fairly fast and simple to implement a module and a bunch of functions, I'd find it hard to complain about that.
Unfortunately, the same cannot be said of building objects, which I find a considerably more irritating processes.
There are a bunch of tools that others have mentioned to help out, of course, but they don't fit every situation. I'm just having to code the lot by hand... *sigh*. Still, most of the low-level API is pretty good once you know it - it could just use a big improvement in the documentation.
What _is_ endlessly frustrating is the lack of a standard C++/Python interface shipping with Python. It really sucks to have to implement Python objects as plain C functions in C++.
The issue with 'float' is actually a hardware limitation. It's present in all languages that use the floating point hardware. Python, however, doesn't hide it from you when you print the floats - AFAIK that's pretty much the only difference.
What it boils down to is that floats are a PITA. That said, in practice I've had few issues, I just remember the usual rules like never comparing floats for equality, only by a range, and always truncating them when printing. I do exactly the same thing in C++.
You're quite right - functions in Python are first-class objects.
So are classes, bound and unbound methods, and everything else.
It's possible to do some serious magic with metaclasses, making use of the fact that classes are just objects. Stuff like that can hurt to look at, though, where 'a' is an instance of 'A', and 'b' is an instance of 'a'. *winces and rubs brain*.
A better example might be Zope. Memory hungry - yes. Slow - yeah, a bit. Absurdly powerful, also yes.
Personally, I think language choice depends a lot on the project. I've used C++ for some projects, Python for others. So far, I'm finding I get massively more done with Python (which I'm admittedly more experienced with), and write code that's less buggy and easier to maintain. In general, I've had no performance issues, and when I do they've been pretty easy to optimize away with a quick profiler run.
There's only one small problem with your contention - Linux/does/ scale out to at least 512 processors - hardly 'a few' - and is heading up to multiple thousands with SGI's current work.
Of course, one could argue that the Linux folks have more than one insane genius among them...
Seriously. SCO would be very unlikely to do something actually funny like this. Not the story replacement, which was really kind of lame, but that brilliant graphic.
Do you see them coming up with that? And fitting it in so neatly? I don't think they'd understand that - they'd just replace their frontpage with a 'hax0red by linux geekz' page.
If you think a package management system with remote repositories and automatic dependency resolution is the answer, basically any distro will do.
Unfortunately, that's not the answer. System management is much more than installed software managemnet - you must manage system and user configuration, user data, possibly additional software on top of the packaged stuff, etc. It's hardly impossible, but it'd be a real pain to do.
If the number of different types of systems is reasonable, it shouldn't be too bad. The PXE-based remote install tools and image generation options for recent Windows versions have been pretty impressive. You can roll a bunch of drivers, your own software, and all sorts of other things into the install process.
Of course, in action it's not as smooth as you'd hope, but really is anything? I haven't done it myself, but have seen others doing auto-install rollouts, and if they're well enough tested things seem to go fairly decently.
As for the NIC driver issue - buy better hardware, dude (the eepro/100 "just works") or slipstream install the NIC driver on your install media. Anyway, you're going to be doing a network install with a custom image on a large network.
I don't have a large number of nice things to say about Windows, but the job MS has done making installs of large bunches of machines less painful is pretty good.
Frankly, I think "a scant few" is pushing it... despite the number of clueless morons, many here do have at least some idea what's going on and how to sensibly address some IT problems.
As for managing large networks of desktops, that's another very different matter. Not many people have high-level experience doing that.
My network, for example, is only thirty machines. Hardly huge. In fact, it gives me the opposite perspective on a lot of issues, because I find many of the large-site friendly features of Windows networks utterly useless for a small site, and no small-site friendly managability features to compensate.
Personally, I've trialled XP at work as a possible upgrade for our 9x machines, and come to the conclusion that it's not worth the pain. It might be good if you have the management tools, a dedicated test network, and an admin team dedicated to designing and rolling out updates. For small sites, however, it's pure hell. Even controlling how the clients update themselves is hard without an extra server to do the job. I also found accessible information for small-site management to be very thin on the ground.
We're now using thin clients for some of our network, and seeing very good results. Yes, they're Linux based - MS looked good until we figured in the CALs and the isssues with NT-based terminal server security. I'm far from floored by the results with Linux - the bugs, oh, the bugs, I'm drowning in stupid f***ing bugs. There's also more than a little totally retarded design, and the classic issues with no two apps having the same open/save dialog.
That said, for our basic users the results have been very good. They need little support, hardware and software costs are both low, and things generally run very smoothly. Trials with more demanding users aren't going as well (see above rant about bugs and bad design), but current development in the OS is addressing most of the issues I've run into and I expect to be able to move the 9x users across to the thin clients mid-late next year.
I do agree with you that managing a large collection of Linux desktops would probably be pure hell. It's awful to even think about, frankly, especially upgrades. *shudder*. My solution would be to simply not use desktops, but instead move most users to department level thin client services hanging off a redundant set of beefy servers. I'd use LDAP to store user and sytem information (yes, much like AD) as I currently do on my network. For many users, such a setup can be expected to work very well, and dramatically reduces the admin nightmare compared to Linux desktops. I also wouldn't even try to migrate all users to Linux - only basic users for whom it would work well, such as those who only need email, a browser, a word processor, and access to a couple of specific in-house apps.
As for migration - I can't possibly imagine how it could be done in a sane way. I suspect a lot of custom tools would have to be written, the migration would need to be a rolling one, and there would need to be a lot of staff on hand to handle glitches. That doesn't sound like fun to me.
The worst part of moving my users over to the thin clients was migrating their data and settings. That despite the fact that almost all of it was already on the servers, and their systems were pretty basic and very uniform. Doing it in a large company wouldn't be nice.
maybe i'll decide to read some documentation instead
You can't be a programmer! Programmers must shrivel away at the sight of documentation - it's the only way to explain the lengths they go to to avoid it.
Now, I'd best go back to updating the GhostScript documentaton to reflect the changes I just made...
I think both have their place - as in the right circumstances do Firebird, SqLite, ASE, Oracle, DB2 and who knows maybe Ingres. (must play with that - they have Python bindings... mmm).
You can use PostgreSQL on *NIX (incl Linux) with Apache and Perl/PHP/Python/Java/C# if you want.
Personally, I'm placing my hopes on Python and IronPython. Python, because while a very far from perfect language it's heading in the right direction - OOP without the overly formalised pain, flexible enough to use functional ideas too, etc.
IronPython should be interesting because it should make it easier to use the entire.NET library base from Python, integrate Python even more easily into larger projects, and make Python even more able to call out to other languages to accomplish things better done in them (such as R for stats, or Haskell for hardcore functional code).
I, too, have seen more real "enterpreise" work actually get done with older languages - in my case a really scary 1983 4GL called Plain English - than with most "modern" languages.
Agreed - I've found static type checking more of a frustrating hinderance than a help in C++. I can't speak for C#, which is still on my to-learn list, or Java, which I've learned just enough of to know I don't want to use it in most of my apps.
To my mind, static type checking encourages the dangerous assuption that 'if it compiles it'll work'. Compilers only do a tiny subset of the static checking they could, and do so in a very myopic way. I favour the use of a full-fledged static checker that can view the entire codebase, and a good set of tests instead.
That's not to say that static typing done right (which C# may well be) isn't useful, it's just to me it's only a half measure that I can live without. I'll be writing my tests no matter what language I use.
To the OP of this subthread: I think you'll find that good Python programmers are in many cases far more pedantic than C++ or maybe (again, I lack the experience to know) C# programmers. Of course, Python does give you more rope to hang yourself with if you feel the need - but then in a way so does C++, given the pain of refactoring a bad design.
The general argument is that external static checkers can do a better job than the compiler, and can be implemented for any language - including Python. The other part is test-driven development - your unit tests will catch faults the compiler won't, and relying on the compiler to catch your errors for you may well be unsafe because it only catches a small class of errors.
Myself, I think that's reasonable, but there's also value in static typing. Python looks like it'll be getting optional type checks for function calls eventually, and I'll definitely like that.
The main large, successful Python code base that comes to mind is Zope/Plone. It certainly works:-)
As for Perl and PHP, I frankly think both are a different class. Python is a real language, though it can and often is used for scripting. PHP is a web scripting language, and does its job well - but IMO not much else. PHP5 looks a bit more like a real language, but not enough for me. As for Perl... people write large tools / apps in Perl. Whether this as such works is something I don't care to argue.
I do think Python has real validity for large projects. Even if you prefer to implement in C# or Java, Python can let you prototype and redesign it much faster. Once you have your prototype ready, you can code it up in C# or Java with much less pain caused by unexpected changes, refactoring, etc. In fact, with Jython you can even have a runnable app that's half written in Java and half in Python. The same may soon be true in C# with IronPython.
By choice, that's how I'd go. Prototype in Python, and as/if/when necessary translate to C#/Java.
I've used Python for a number of "large scripts" - small applications - and found it to work very well. Perl, on the other hand, has made me regret everything I've ever written in it, and PHP hasn't been all that much better. With Python I've had excellent results using tests and static checking.
Python is a dynamically typed, strongly typed language. This in contrast to C, a weakly typed statically typed language, or Java, a strongly typed statically typed PITA^Wlanguage.
Applications should have a target that is not moving all the time. A stable OS.
To a fair extent they have one - commercial UNIX. SunOS 4 apps still run on recent Solaris, for example.
The problem is, nobody wants to use it, because it's expensive, crufty, and not shiny and new. Do you use SCO OpenDesktop, HP-UX, or Solaris? They're the stable targets you're after... but most people don't find the trade-offs worth it.
Frankly, Windows isn't doing that bad on the stability front. It changes quite a bit, but it remains amazingly compatible with correctly written applications (all three of them - *sigh*). The problem is that so many Windows developers do so many scary, broken things that MS quite literally can't fix BUGS in their OS without breaking apps.
That said, I think MS do push a lot of crap into their OS, and have made their own lives much harder by "integrating" things like MSIE so they're part of the OS API.
The key problem is that a secure and stable OS, not breaking apps, and providing the features people want are to some extent muturally exclusive. At best, it's pick two of three.
I would be interested in seeing MS release a totally incompatible "Windows how we should've done it" and/then/ guarantee API stability for long periods. The should provide checkers and compliance tests with it and only guarantee compatibility for code that passed the tests. If you write bad code, they WILL break your app.
Alas, I just don't see it happening. When a developer writes a crap app and a new Windows release comes out, people blame MS not the developer.
Right. Gamers. The people we all know communicate so clearly and co-operate so well.
lol im l33t joo suxorz fo 111
Yep, that's them.
In fairness, far from all gamers are like that. The agressively stupid ones just seem to be everpresent, and make it hard for others to be heard (or go about their business quietly if they prefer).
Take the game Battlefield Vietnam for example. Yeah, it's an EA game. It could be an excellent game - varied, lots of opportunity for tactical operations, teamwork, things like airlifting vehicles and troops, etc. What do you see? two 16-people groups of individuals flailing randomly against each other, with a small sub-set trying to do something organized and being undermined by the moron-tide.
Somehome, I suspect something similar may show up in "real world" attempts to get gamers to organize and do something useful.
Many of the flaws in Windows are architectural. Fixing them will break things. SP2 did as much as possible to minmize breakage of apps that are in many cases frightening garbage internally, while making some big changes.
I'm no MS fan (and am typing this from a Linux box) but geez, give them credit where it's due. Nobody but MS would've gone to the incredible time and effort of including thousands of compatibility hacks and tweaks so braindead, broken apps could keep on working.
Most other OSes would simply break the apps and be done with it.
If I came across that way, I didn't mean to. When you work in prepress it's easy to write as if prepress is the only thing that matters, but that's usually not the intent.
GIMP is mostly - not totally - unusable for prepress without colour management and CMYK. That doesn't mean it's not good for other users.
I'd contend with 95% - but it really doesn't matter.
I found your comments very interesting. I do think there's a point where it becomes worth replacing cars - when they become extremely inefficient and dirty. Short term air pollution also matters, from a health perspective among other things.
That said, it does bring the Japanese policy of taxing even slightly old cars into oblivion into a whole new light. How... dodgy.
<i>After all, isn't that why many of us spend so much time maintaining existing code base?</i>
Certainly not because nobody understands the darn thing well enough to rewrite it like it needs, probably resulting in a code base 1/4 the size, 10x the speed, and twice as reliable...
Slashdot Mirror
RHEL: Annual subscription, unlimited clients
Win2k3: Outright license purchase, CAL cost per-client.
You can't effectively compare the prices of the two without a context, such as the lifetime of the server and the number of clients that are expected to be connected to it.
There's a feature missing from that list that's quite a terrible omission - "break all 3rd party MSN clients - again."
How often do they release without that gem of a feature? Hell, they even enhance and update it between releases!
In fairness, they're quite within their rights in doing so, but you'd think they'd break 3rd party clients PROPERLY if they were going to, eg require TLS with the right client cert. That way, third party products would have to bundle a cert that the MSN license said was only licensed for use with MSN. I suspect their legal ground would then be rather shakier (but then again, so would MS's anti-trust status).
I'm with you on the functional style issue.
I always hated functional programming, having been forced to learn to use utterly crippled pure-functional teaching languages. Uggh. Consequently, I thought functional programming was pointless academic wank.
I didn't forget how to do it, though.
With the Python 'map', 'filter', 'zip' and 'reduce' functions, I found myself breaking into segments of functional style again, where it was faster / simpler / safer / cleaner.
List comprehensions increased this further, largely by eliminating the horror that is the nested map and filter jungle.
Some programs, especially data processing ones, I now write almost purely functionally. I'll usually write a series of functional blocks that perform each major transformation, put them in separate one-line functions, then perform each block in series in the main() function.
I generally find this results in much less buggy, faster, and better designed code.
The most important thing is that I can use imperative code where it's more appropraite, and functional code where it fits best. That's just fantastic.
I'm doing it now, and I must agree - it's pretty slow going.
... *sigh*. Still, most of the low-level API is pretty good once you know it - it could just use a big improvement in the documentation.
It's fairly fast and simple to implement a module and a bunch of functions, I'd find it hard to complain about that.
Unfortunately, the same cannot be said of building objects, which I find a considerably more irritating processes.
There are a bunch of tools that others have mentioned to help out, of course, but they don't fit every situation. I'm just having to code the lot by hand
What _is_ endlessly frustrating is the lack of a standard C++/Python interface shipping with Python. It really sucks to have to implement Python objects as plain C functions in C++.
The issue with 'float' is actually a hardware limitation. It's present in all languages that use the floating point hardware. Python, however, doesn't hide it from you when you print the floats - AFAIK that's pretty much the only difference.
What it boils down to is that floats are a PITA. That said, in practice I've had few issues, I just remember the usual rules like never comparing floats for equality, only by a range, and always truncating them when printing. I do exactly the same thing in C++.
You're quite right - functions in Python are first-class objects.
So are classes, bound and unbound methods, and everything else.
It's possible to do some serious magic with metaclasses, making use of the fact that classes are just objects. Stuff like that can hurt to look at, though, where 'a' is an instance of 'A', and 'b' is an instance of 'a'. *winces and rubs brain*.
Yeah, mailman is 'interesting'.
A better example might be Zope. Memory hungry - yes. Slow - yeah, a bit. Absurdly powerful, also yes.
Personally, I think language choice depends a lot on the project. I've used C++ for some projects, Python for others. So far, I'm finding I get massively more done with Python (which I'm admittedly more experienced with), and write code that's less buggy and easier to maintain. In general, I've had no performance issues, and when I do they've been pretty easy to optimize away with a quick profiler run.
Of course, YYMV.
There's only one small problem with your contention - Linux /does/ scale out to at least 512 processors - hardly 'a few' - and is heading up to multiple thousands with SGI's current work.
Of course, one could argue that the Linux folks have more than one insane genius among them...
Seriously. SCO would be very unlikely to do something actually funny like this. Not the story replacement, which was really kind of lame, but that brilliant graphic.
Do you see them coming up with that? And fitting it in so neatly? I don't think they'd understand that - they'd just replace their frontpage with a 'hax0red by linux geekz' page.
I'm afraid I can't agree.
If you think a package management system with remote repositories and automatic dependency resolution is the answer, basically any distro will do.
Unfortunately, that's not the answer. System management is much more than installed software managemnet - you must manage system and user configuration, user data, possibly additional software on top of the packaged stuff, etc. It's hardly impossible, but it'd be a real pain to do.
If the number of different types of systems is reasonable, it shouldn't be too bad. The PXE-based remote install tools and image generation options for recent Windows versions have been pretty impressive. You can roll a bunch of drivers, your own software, and all sorts of other things into the install process.
Of course, in action it's not as smooth as you'd hope, but really is anything? I haven't done it myself, but have seen others doing auto-install rollouts, and if they're well enough tested things seem to go fairly decently.
As for the NIC driver issue - buy better hardware, dude (the eepro/100 "just works") or slipstream install the NIC driver on your install media. Anyway, you're going to be doing a network install with a custom image on a large network.
I don't have a large number of nice things to say about Windows, but the job MS has done making installs of large bunches of machines less painful is pretty good.
Frankly, I think "a scant few" is pushing it ... despite the number of clueless morons, many here do have at least some idea what's going on and how to sensibly address some IT problems.
As for managing large networks of desktops, that's another very different matter. Not many people have high-level experience doing that.
My network, for example, is only thirty machines. Hardly huge. In fact, it gives me the opposite perspective on a lot of issues, because I find many of the large-site friendly features of Windows networks utterly useless for a small site, and no small-site friendly managability features to compensate.
Personally, I've trialled XP at work as a possible upgrade for our 9x machines, and come to the conclusion that it's not worth the pain. It might be good if you have the management tools, a dedicated test network, and an admin team dedicated to designing and rolling out updates. For small sites, however, it's pure hell. Even controlling how the clients update themselves is hard without an extra server to do the job. I also found accessible information for small-site management to be very thin on the ground.
We're now using thin clients for some of our network, and seeing very good results. Yes, they're Linux based - MS looked good until we figured in the CALs and the isssues with NT-based terminal server security. I'm far from floored by the results with Linux - the bugs, oh, the bugs, I'm drowning in stupid f***ing bugs. There's also more than a little totally retarded design, and the classic issues with no two apps having the same open/save dialog.
That said, for our basic users the results have been very good. They need little support, hardware and software costs are both low, and things generally run very smoothly. Trials with more demanding users aren't going as well (see above rant about bugs and bad design), but current development in the OS is addressing most of the issues I've run into and I expect to be able to move the 9x users across to the thin clients mid-late next year.
I do agree with you that managing a large collection of Linux desktops would probably be pure hell. It's awful to even think about, frankly, especially upgrades. *shudder*. My solution would be to simply not use desktops, but instead move most users to department level thin client services hanging off a redundant set of beefy servers. I'd use LDAP to store user and sytem information (yes, much like AD) as I currently do on my network. For many users, such a setup can be expected to work very well, and dramatically reduces the admin nightmare compared to Linux desktops. I also wouldn't even try to migrate all users to Linux - only basic users for whom it would work well, such as those who only need email, a browser, a word processor, and access to a couple of specific in-house apps.
As for migration - I can't possibly imagine how it could be done in a sane way. I suspect a lot of custom tools would have to be written, the migration would need to be a rolling one, and there would need to be a lot of staff on hand to handle glitches. That doesn't sound like fun to me.
The worst part of moving my users over to the thin clients was migrating their data and settings. That despite the fact that almost all of it was already on the servers, and their systems were pretty basic and very uniform. Doing it in a large company wouldn't be nice.
maybe i'll decide to read some documentation instead
You can't be a programmer! Programmers must shrivel away at the sight of documentation - it's the only way to explain the lengths they go to to avoid it.
Now, I'd best go back to updating the GhostScript documentaton to reflect the changes I just made...
Unfortunately, CifsFS doesn't seem to support NT4. As NT4 is _still_ a significant part of the Windows user base, this appears to me to be a problem.
I'd be glad to be proved wrong, however.
I think both have their place - as in the right circumstances do Firebird, SqLite, ASE, Oracle, DB2 and who knows maybe Ingres. (must play with that - they have Python bindings ... mmm).
You can use PostgreSQL on *NIX (incl Linux) with Apache and Perl/PHP/Python/Java/C# if you want.
Personally, I'm placing my hopes on Python and IronPython. Python, because while a very far from perfect language it's heading in the right direction - OOP without the overly formalised pain, flexible enough to use functional ideas too, etc.
.NET library base from Python, integrate Python even more easily into larger projects, and make Python even more able to call out to other languages to accomplish things better done in them (such as R for stats, or Haskell for hardcore functional code).
IronPython should be interesting because it should make it easier to use the entire
I, too, have seen more real "enterpreise" work actually get done with older languages - in my case a really scary 1983 4GL called Plain English - than with most "modern" languages.
Agreed - I've found static type checking more of a frustrating hinderance than a help in C++. I can't speak for C#, which is still on my to-learn list, or Java, which I've learned just enough of to know I don't want to use it in most of my apps.
To my mind, static type checking encourages the dangerous assuption that 'if it compiles it'll work'. Compilers only do a tiny subset of the static checking they could, and do so in a very myopic way. I favour the use of a full-fledged static checker that can view the entire codebase, and a good set of tests instead.
That's not to say that static typing done right (which C# may well be) isn't useful, it's just to me it's only a half measure that I can live without. I'll be writing my tests no matter what language I use.
To the OP of this subthread: I think you'll find that good Python programmers are in many cases far more pedantic than C++ or maybe (again, I lack the experience to know) C# programmers. Of course, Python does give you more rope to hang yourself with if you feel the need - but then in a way so does C++, given the pain of refactoring a bad design.
The general argument is that external static checkers can do a better job than the compiler, and can be implemented for any language - including Python. The other part is test-driven development - your unit tests will catch faults the compiler won't, and relying on the compiler to catch your errors for you may well be unsafe because it only catches a small class of errors.
:-)
... people write large tools / apps in Perl. Whether this as such works is something I don't care to argue.
Myself, I think that's reasonable, but there's also value in static typing. Python looks like it'll be getting optional type checks for function calls eventually, and I'll definitely like that.
The main large, successful Python code base that comes to mind is Zope/Plone. It certainly works
As for Perl and PHP, I frankly think both are a different class. Python is a real language, though it can and often is used for scripting. PHP is a web scripting language, and does its job well - but IMO not much else. PHP5 looks a bit more like a real language, but not enough for me. As for Perl
I do think Python has real validity for large projects. Even if you prefer to implement in C# or Java, Python can let you prototype and redesign it much faster. Once you have your prototype ready, you can code it up in C# or Java with much less pain caused by unexpected changes, refactoring, etc. In fact, with Jython you can even have a runnable app that's half written in Java and half in Python. The same may soon be true in C# with IronPython.
By choice, that's how I'd go. Prototype in Python, and as/if/when necessary translate to C#/Java.
I've used Python for a number of "large scripts" - small applications - and found it to work very well. Perl, on the other hand, has made me regret everything I've ever written in it, and PHP hasn't been all that much better. With Python I've had excellent results using tests and static checking.
Python is a dynamically typed, strongly typed language. This in contrast to C, a weakly typed statically typed language, or Java, a strongly typed statically typed PITA^Wlanguage.
Oh, no! My sandwich!
Applications should have a target that is not moving all the time. A stable OS.
/then/ guarantee API stability for long periods. The should provide checkers and compliance tests with it and only guarantee compatibility for code that passed the tests. If you write bad code, they WILL break your app.
To a fair extent they have one - commercial UNIX. SunOS 4 apps still run on recent Solaris, for example.
The problem is, nobody wants to use it, because it's expensive, crufty, and not shiny and new. Do you use SCO OpenDesktop, HP-UX, or Solaris? They're the stable targets you're after... but most people don't find the trade-offs worth it.
Frankly, Windows isn't doing that bad on the stability front. It changes quite a bit, but it remains amazingly compatible with correctly written applications (all three of them - *sigh*). The problem is that so many Windows developers do so many scary, broken things that MS quite literally can't fix BUGS in their OS without breaking apps.
That said, I think MS do push a lot of crap into their OS, and have made their own lives much harder by "integrating" things like MSIE so they're part of the OS API.
The key problem is that a secure and stable OS, not breaking apps, and providing the features people want are to some extent muturally exclusive. At best, it's pick two of three.
I would be interested in seeing MS release a totally incompatible "Windows how we should've done it" and
Alas, I just don't see it happening. When a developer writes a crap app and a new Windows release comes out, people blame MS not the developer.
Right. Gamers. The people we all know communicate so clearly and co-operate so well.
lol im l33t joo suxorz fo 111
Yep, that's them.
In fairness, far from all gamers are like that. The agressively stupid ones just seem to be everpresent, and make it hard for others to be heard (or go about their business quietly if they prefer).
Take the game Battlefield Vietnam for example. Yeah, it's an EA game. It could be an excellent game - varied, lots of opportunity for tactical operations, teamwork, things like airlifting vehicles and troops, etc. What do you see? two 16-people groups of individuals flailing randomly against each other, with a small sub-set trying to do something organized and being undermined by the moron-tide.
Somehome, I suspect something similar may show up in "real world" attempts to get gamers to organize and do something useful.
Many of the flaws in Windows are architectural. Fixing them will break things. SP2 did as much as possible to minmize breakage of apps that are in many cases frightening garbage internally, while making some big changes.
I'm no MS fan (and am typing this from a Linux box) but geez, give them credit where it's due. Nobody but MS would've gone to the incredible time and effort of including thousands of compatibility hacks and tweaks so braindead, broken apps could keep on working.
Most other OSes would simply break the apps and be done with it.
If I came across that way, I didn't mean to. When you work in prepress it's easy to write as if prepress is the only thing that matters, but that's usually not the intent.
GIMP is mostly - not totally - unusable for prepress without colour management and CMYK. That doesn't mean it's not good for other users.
I'd contend with 95% - but it really doesn't matter.
I found your comments very interesting. I do think there's a point where it becomes worth replacing cars - when they become extremely inefficient and dirty. Short term air pollution also matters, from a health perspective among other things.
... dodgy.
That said, it does bring the Japanese policy of taxing even slightly old cars into oblivion into a whole new light. How
<i>After all, isn't that why many of us spend so much time maintaining existing code base?</i>
Certainly not because nobody understands the darn thing well enough to rewrite it like it needs, probably resulting in a code base 1/4 the size, 10x the speed, and twice as reliable...