I think I see his point from a UI design standpoint. It's due to the rather unique requirements of web browsers.
Normally, you *never* have scrolling forms containing controls. Doing so is bad, bad UI design. However, in the case of web browsers, you have a scrolling page which contains widgets which may scroll. If the widget passes under the mouse cursor in the scrolling page (hard to avoid), then all of a suddent the widget starts grabbing the scroll events.
I don't really see the point of having the scroll wheel interact comboboxes either. I mean, a click and a movement of the mouse actually lets you see what you're choosing from.
Except a single corrupted file doesn't take out the entire systemwide configuration.
I've thought about this too -- there are definite advantages. However, there are also a few drawbacks.
* Some of the difference in config file formats is because a single format can't really cleanly express some of the zany things people can do with their own formats. * Everything depends on libxml. I hope it doesn't have any bugs and has good performance...currently, it uses much more RAM and CPU time than a simple ad hoc single-line parser. * XML is hand-editable, but working in "xml tag" units is somewhat less easy than working in "line units". There's been a string convention in UNIX for using the line as the basic unit of config file information, and the editing environments reflect this -- witness Emacs' kill-line (and vi's operate-on-line commands).
And if you're using a totally different display, you should have a new Screen entry in XF86Config. You're misusing the program and complaining that it's hard to misuse.
Just because you don't get it, doesn't mean it's not a problem.
Just because *you* don't get it doesn't mean it's a problem.
Mozilla-based browsers are the best. They render most pages correctly and enjoy the commercial support of being the basis for Netscape. However, Mozilla is not integrated with any desktop environment, making tasks such as printing, accessing the file open or save dialogs, and cut-n-paste unpleasant
I disagree. First, I take issue with the misuse of the word "integrated". "Integration" is not a good thing from an engineering standpoint -- it's a bad thing. Having compatibility between two pieces of software, or conforming to a standard interface, has nothing to do with integration. MSIE is "integrated" into the Windows operating system -- bits of each rely on each other, a break in one bit breaks other stuff, and updating or removing one messes up the other. Modularity -- not integration -- is a good thing. Of course, having modular software with standard interfaces and supporting standard IPC mechanisms is important.:-)
Second, cutting and pasting has never been a problem in the X environment with *any piece of software* but KDE 1 and 2. There have been established standards for cut-and-paste interoperability for X some time (Athena era, at least). KDE broke those, and didn't enter compliance until KDE 3.0. If KDE doesn't work with a compliant piece of software, that's KDE's fault. Mozilla is not to blame here.
Prompting for a filesystem scan...Who in the _world_ wants their bootup process interrupted by this busy work? The interoduction of journalling filesystems has greatly helped this (it happens only 1 time in 20 on an unclean shutdown, rather than about 1 in 4), but it's still bad
Wow. Where to start?
First, AFAIK, in every distro that I've ever seen, there is *no* prompting for a filesystem scan. It happens automatically on unclean boots and periodically. If you don't like the periodical scan, you can disable it. As a matter of fact, in at least Red Hat (and all the others, for all I know) fsck is told to automatically repair filesystems by default. Now, if there is *serious damage* that might result in your filesystem going to the big Disk in the Sky, then yes, you will get asked to make some decisions about what happens. I *much* prefer to know if my filesystem might be totally trashed in a minute than to just have it happen because a system blindly started guessing what to do.
Scanning on an improperly unmounted filesystem is not busy work. If it isn't done, you could wipe out your filesystem, lose data, whatever. You can't possibly convince me that you're better off skipping fsck. If you have some specialized needs -- must boot in small amount of time and data integrity matters nothing, then you can modify your init system to not run fsck. Frankly, though, I think that for almost any user, power users included, the current convention is easily the best. Windows provides a mechanism for skipping scandisk, which is probably the stupidest thing I've ever seen done, as people who have no idea what they're doing consistently skip the check, compounding corruption problems.
I don't know what this 1 time in 20 on an unclean shutdown rather than 1 in 4 business is. A journalling filesystem does not need to run fsck. The entire point of journalling is so that you have a system founded on transactions in such a way that you *cannot* corrupt the filesystem. fsck should *always* run on a non-journalling fs in any distro I've used after a bad shutdown. Yes, it also periodically runs on filesystems, but that's pretty rare, and if you don't like it, it's pretty easy to shut off. I personally think the added data integrity makes it worthwhile, but that's just me.
I have written a total of three device drivers for the kernel...
That's funny...I can't find anything in my kernel source tree grepping for your name. What exactly was it that you wrote, again?
For years I struggled with/etc/printcap; I never could seem to get it to work quite right, especially for sharing printers on the network
Perhaps *you* don't like it, but for some of us that have special needs, having a dumbed down printing system would be incredibly frusterating (I'll give you a pass on this if you just want a new front end). However, I salvaged a nice LaserWriter some time ago. The thing doesn't have enough RAM to print any modern PostScript files, but I *could* write a custom print filter that used the excellent psrender.sh script to render the thing to a bitmap, and then send it to the printer as a fax-compressed bitmap in a postscript document...I can reliably print my files on this aging (but well-made) machine. Try doing the same in the "easy to use" Windows environment...you'd be shelling out for a new printer.
Make it easy for the user to find out how to do things
I don't really care whether this is done or not, as long as it doesn't force a bunch of annoying wizards or assistants on people that don't want them.
When an app has no windows open (or the main window is not open), the WM should attempt to kill them (first normally, then with -9)
This is the most idiotic suggestion I've heard in some time. Not all apps have a window. What about xbindkeys? There's a damn good reason for this. What about programs (such as daemons on Windows) that just occasionally pop up a warning dialog? You going to kill them off as well?
Sorry, but if you really have truly stray processes, that's a bug in the program, and the program should be fixed. I see tons of idiots killing off "stray" processes on Windows. "Well, I don't know what this is, so it must not be important". Grr.
Easy way of sharing files
Sounds like a KDE flaw. There are plenty of front ends people have made for this sort of thing. This has nothing to do with Linux. Also, I really dislike the idea of adding a small daemon running as root tied to Konqueror. This is starting to sound more and more like the hideously insecure Windows environment.
Sound support
So you have no complaint?
I'd like to see a decent sound system (maybe via a sound server if there's a way to do so with very low latency, though I think there might actually be an argument for doing this in alsa) where sound goes out hardware channels (and is mixed in hardware) until the channels run out, and then the streams for any other sounds playing automatically fall back to being mixed in software. It's an embarrassment to Linux, especially since Windows does this so well in DirectX. On Linux, you have to have all software mixing (currently high latency and with a nasty tendancy to skip, since existing sound systems don't run out of box with elevated priority) or all hardware mixing (requires a fancy sound card, limited in the number of channels).
No common editor which supports "soft wrapping"
Okay, here I'll agree. There needs to be a set of code written that can do this quickly and flexibly (with an arbitrary set of word separation characters), and then have the thing used throughout various programs. It's kind of sad that Emacs doesn't have a mode to do this (there are modes to add hard returns automatically, but no good native mode that simply displays text that internally has no linefeeds onscreen in multiple lines). This may suck for coding, but for some text this makes sense. The days of the 24x80 terminal are long gone -- even terminal fans are using all sorts of wacky sizes (For example, I use a higher resolution vga display), and handing out text files that are hard-wrapped to 80 characters is just silly.
No easy way to configure X -- especially change resolution on the fly
You're full of it. There are tons of front ends to configure X. It's terribly easy to change resolution on the fly in X -- ctrl alt kp+ and ctrl alt kp-. Changing the desktop resolution during runtime isn't supported (though if you had to you could hack it up via DGA modes)...but why would you want to do this? The only reason people did this in Windows was because they wanted to run games or software that needed a lower resolution. They were *forced* to change their desktop size to change their resolution. X simply doesn't force this upon you. I *always* want my desktop using the maximum possible resolution that my video card/monitor can support. If I want larger fonts, I increase the font size (as one should do...trying to read lower res, pixelated fonts is just stupid). If I want bigger borders or titlebars, I enlarge those. If I want to play a game, I just run the thing and it switches res automatically via DGA calls. XFree 4.x does this nicely and cleanly.
Basically, it's because the X server you use stores the pixmaps in itself rather than in the application. There's no extra RAM use going on...it's just what's using the RAM that's different. In a MS Windows-like design, the applications would use more RAM to store those same pixmaps -- in X, the applications use less but the X server uses correspondingly more.
X gets blamed for tons of things, and usually doesn't deserve it.
a) So if this is really the product manager, why does roxio.com have nothing whatsoever like this, a disclaimer or anything, on their website? Toast is their big product, and they're publicly traded. You'd think bad PR is something they'd want to quash.
b) If they have no intention of ever hitting users with DRM stuff, why the license agreement making users agree to allow Roxio control over their system?
c) If this doesn't make you a wee bit suspicious about Roxio and DRM, then you're naive.
d) The people at Roxio are not nice folks -- they went after the excellent Open Source project cdrtoaster (a Tk front end to cdrecord) as being trademark infringement and forced a name change.
I believe these nasty Roxio folks are the same people that made the cdrtoaster (Tk frontend to cdrecord) folks change their name based on trademark threats.
I also remember Roxio's Toast costing some huge sum of money back when burners first came out -- hundreds and hundreds of dollars. Unbelivably exorbant.
This isn't a direct attack on Linux. It might hurt Linux long-term, but you can use Linux on a Palladium-enabled system. It just means that more and more things can become impossible to use on Linux.
Of course, I'd like to point out where trying to exclude Linux folks got the DVD Consortium. Palladium is better designed, and nastier, but the payoff for breaking it is also higher.
Code review has never been sufficient to ensure that code has no security holes. Trust me, code signing is not in the least about security -- it's about MS getting the power to exclude whoever they want.
First, MS may *allow* other CAs, but undoubtedly have agreements with a few as to criteria used in selecting okay software. Guess which ones are going to be "trusted by default" in shipped versions of Windows...yup, the "MS partners".
Second, this ensures that Open Source development is much more difficult and may be monitored -- applying for code signatures frequently costs time (if not money).
Third, this gives MS a nice foothold into the juicy, lucrative DRM field.
You phase things out slowly. Intel and AMD support this, so all new PCs support Palladium. All new copies of Windows sold support Palladium. Five years down the road, media folks start requiring DRM to use their products, where 80% of the folks out there have DRM systems.
I mean, it's nice that you think that people will never move away, but that doesn't mesh with history. Lots of websites require Javascript, and there aren't always alternatives. Gopher is long gone...I can't visite gopher-only sites any more. I don't use Windows much, but I suspect that people still using Windows 95 are pretty much out in the cold when it comes to using new games.
Presumably he's either a home user suffering from MS's "never fix bugs unless you buy the next version with new buggy features" model or a corporate IT guy suffering from inane licensing terms.
Apple also has somewhat less leverage to screw its customers over than MS does.
It isn't just Mac users -- precious few consumers like the idea of DRM. It's just that MS may be able to tell everyone that they're darn well going to use it anyway.
Better quote: "Biddle also denied widespread speculation that Palladium will involve changes to the existing TCP/IP protocol of the Internet, and would be used to disable or lock out other vendor's software, saying, "What IT manager in his right mind -- what Microsoft in its right mind would roll that out?".
I don't have any huge problems with the NT line of kernels (NT, 2k, XP). They're a bit slow, and the VM subsystem sucks in performance compared to Linux. They also lack a lot of cool functionality that the Linux kernel has (uber-powerful packet filtering and routing, low latency/realtime extensions). OTOH, they have very finely grained protection schemes, which is nice.
However, the 2k kernel is not what bothers me -- it's the software that comes with the kernel -- the file browser, the file search utility, the web browser, the dock. They suck. The dock isn't anywhere near as flexible as any but the worst of the UNIX docks. The file browser isn't very flexibile, keeps forgetting saved views on me, is slow and RAM hungry, and has security problems out the wazoo. The file search utility is incredibly slow and weak (combine locate, find, and grep and you have a far faster, more powerful system). I don't like the networking subsystem -- trying to get NT to have two configurations to switch between (where I have a PPP connection at home and an Ethernet connection at school) without uninstalling drivers was a pain -- disabling interfaces resulted in screwy routing. I dislike the lack of symlinks. I think the command shell sucks, lacking basic functionality and running extremely slowly. I'm unhappy with network file system performance -- SMB from Windows box to Windows box is sloooowwwww. I think the ACL system has some bad design decisions. I can't figure out why MS has never updated some of the truly ancient, lame software (Solitaire, Notepad (a bit better in 2k), the Calculator) that comes with the OS. I *really* don't like the file locking scheme -- an open file cannot be moved or renamed or deleted, unlike UNIX. I also think that it's really dumb that there's no concept of "limited right drivers" that can't barf all over your kernel (granted, Linux lacks this too).
I will say that the NT kernel is pretty stable, and that it's better than the truly horrific 9x line. But as for "hard pressed to find a better OS"? Nah.
At work when moving from NT to 2k, I discovered that the sound card in the system was made by a company that no longer existed and never put out working drivers for anything above NT. Happily, they released enough technical information for Linux to support it, and now it'll probably be supported until the end of all time.:-)
Windows 2000/XP are damn good server...environments
Relative to the Win 9X line, perhaps. I very much disagree when compared to Linux, in terms of performance, flexability, tunability, and security. In my mind, these are pretty important points.
Slashdot Mirror
I'll call your bluff.
Oh, and Konqueror is a take on Netscape Navigator, which is the proper name of the browser that you're calling Netscape.
Outlook, Kmail
Powerpoint, Kpresenter
Acrobat Reader, Xpdf
Visual Studio, GNU Compiler Collection
I think I see his point from a UI design standpoint. It's due to the rather unique requirements of web browsers.
Normally, you *never* have scrolling forms containing controls. Doing so is bad, bad UI design. However, in the case of web browsers, you have a scrolling page which contains widgets which may scroll. If the widget passes under the mouse cursor in the scrolling page (hard to avoid), then all of a suddent the widget starts grabbing the scroll events.
I don't really see the point of having the scroll wheel interact comboboxes either. I mean, a click and a movement of the mouse actually lets you see what you're choosing from.
Opera for speed, all the way.
Dillo beats opera in the speed department by a mile, and if you're willing to go text-based, I believe lynx renders faster than dillo.
Sounds a lot like Windows, doesn't it
Except a single corrupted file doesn't take out the entire systemwide configuration.
I've thought about this too -- there are definite advantages. However, there are also a few drawbacks.
* Some of the difference in config file formats is because a single format can't really cleanly express some of the zany things people can do with their own formats.
* Everything depends on libxml. I hope it doesn't have any bugs and has good performance...currently, it uses much more RAM and CPU time than a simple ad hoc single-line parser.
* XML is hand-editable, but working in "xml tag" units is somewhat less easy than working in "line units". There's been a string convention in UNIX for using the line as the basic unit of config file information, and the editing environments reflect this -- witness Emacs' kill-line (and vi's operate-on-line commands).
And there are plenty of front ends to do exactly this.
And if you're using a totally different display, you should have a new Screen entry in XF86Config. You're misusing the program and complaining that it's hard to misuse.
Just because you don't get it, doesn't mean it's not a problem.
Just because *you* don't get it doesn't mean it's a problem.
Mozilla-based browsers are the best. They render most pages correctly and enjoy the commercial support of being the basis for Netscape. However, Mozilla is not integrated with any desktop environment, making tasks such as printing, accessing the file open or save dialogs, and cut-n-paste unpleasant
:-)
/etc/printcap; I never could seem to get it to work quite right, especially for sharing printers on the network
I disagree. First, I take issue with the misuse of the word "integrated". "Integration" is not a good thing from an engineering standpoint -- it's a bad thing. Having compatibility between two pieces of software, or conforming to a standard interface, has nothing to do with integration. MSIE is "integrated" into the Windows operating system -- bits of each rely on each other, a break in one bit breaks other stuff, and updating or removing one messes up the other. Modularity -- not integration -- is a good thing. Of course, having modular software with standard interfaces and supporting standard IPC mechanisms is important.
Second, cutting and pasting has never been a problem in the X environment with *any piece of software* but KDE 1 and 2. There have been established standards for cut-and-paste interoperability for X some time (Athena era, at least). KDE broke those, and didn't enter compliance until KDE 3.0. If KDE doesn't work with a compliant piece of software, that's KDE's fault. Mozilla is not to blame here.
Prompting for a filesystem scan...Who in the _world_ wants their bootup process interrupted by this busy work? The interoduction of journalling filesystems has greatly helped this (it happens only 1 time in 20 on an unclean shutdown, rather than about 1 in 4), but it's still bad
Wow. Where to start?
First, AFAIK, in every distro that I've ever seen, there is *no* prompting for a filesystem scan. It happens automatically on unclean boots and periodically. If you don't like the periodical scan, you can disable it. As a matter of fact, in at least Red Hat (and all the others, for all I know) fsck is told to automatically repair filesystems by default. Now, if there is *serious damage* that might result in your filesystem going to the big Disk in the Sky, then yes, you will get asked to make some decisions about what happens. I *much* prefer to know if my filesystem might be totally trashed in a minute than to just have it happen because a system blindly started guessing what to do.
Scanning on an improperly unmounted filesystem is not busy work. If it isn't done, you could wipe out your filesystem, lose data, whatever. You can't possibly convince me that you're better off skipping fsck. If you have some specialized needs -- must boot in small amount of time and data integrity matters nothing, then you can modify your init system to not run fsck. Frankly, though, I think that for almost any user, power users included, the current convention is easily the best. Windows provides a mechanism for skipping scandisk, which is probably the stupidest thing I've ever seen done, as people who have no idea what they're doing consistently skip the check, compounding corruption problems.
I don't know what this 1 time in 20 on an unclean shutdown rather than 1 in 4 business is. A journalling filesystem does not need to run fsck. The entire point of journalling is so that you have a system founded on transactions in such a way that you *cannot* corrupt the filesystem. fsck should *always* run on a non-journalling fs in any distro I've used after a bad shutdown. Yes, it also periodically runs on filesystems, but that's pretty rare, and if you don't like it, it's pretty easy to shut off. I personally think the added data integrity makes it worthwhile, but that's just me.
I have written a total of three device drivers for the kernel...
That's funny...I can't find anything in my kernel source tree grepping for your name. What exactly was it that you wrote, again?
For years I struggled with
Perhaps *you* don't like it, but for some of us that have special needs, having a dumbed down printing system would be incredibly frusterating (I'll give you a pass on this if you just want a new front end). However, I salvaged a nice LaserWriter some time ago. The thing doesn't have enough RAM to print any modern PostScript files, but I *could* write a custom print filter that used the excellent psrender.sh script to render the thing to a bitmap, and then send it to the printer as a fax-compressed bitmap in a postscript document...I can reliably print my files on this aging (but well-made) machine. Try doing the same in the "easy to use" Windows environment...you'd be shelling out for a new printer.
Make it easy for the user to find out how to do things
I don't really care whether this is done or not, as long as it doesn't force a bunch of annoying wizards or assistants on people that don't want them.
When an app has no windows open (or the main window is not open), the WM should attempt to kill them (first normally, then with -9)
This is the most idiotic suggestion I've heard in some time. Not all apps have a window. What about xbindkeys? There's a damn good reason for this. What about programs (such as daemons on Windows) that just occasionally pop up a warning dialog? You going to kill them off as well?
Sorry, but if you really have truly stray processes, that's a bug in the program, and the program should be fixed. I see tons of idiots killing off "stray" processes on Windows. "Well, I don't know what this is, so it must not be important". Grr.
Easy way of sharing files
Sounds like a KDE flaw. There are plenty of front ends people have made for this sort of thing. This has nothing to do with Linux. Also, I really dislike the idea of adding a small daemon running as root tied to Konqueror. This is starting to sound more and more like the hideously insecure Windows environment.
Sound support
So you have no complaint?
I'd like to see a decent sound system (maybe via a sound server if there's a way to do so with very low latency, though I think there might actually be an argument for doing this in alsa) where sound goes out hardware channels (and is mixed in hardware) until the channels run out, and then the streams for any other sounds playing automatically fall back to being mixed in software. It's an embarrassment to Linux, especially since Windows does this so well in DirectX. On Linux, you have to have all software mixing (currently high latency and with a nasty tendancy to skip, since existing sound systems don't run out of box with elevated priority) or all hardware mixing (requires a fancy sound card, limited in the number of channels).
No common editor which supports "soft wrapping"
Okay, here I'll agree. There needs to be a set of code written that can do this quickly and flexibly (with an arbitrary set of word separation characters), and then have the thing used throughout various programs. It's kind of sad that Emacs doesn't have a mode to do this (there are modes to add hard returns automatically, but no good native mode that simply displays text that internally has no linefeeds onscreen in multiple lines). This may suck for coding, but for some text this makes sense. The days of the 24x80 terminal are long gone -- even terminal fans are using all sorts of wacky sizes (For example, I use a higher resolution vga display), and handing out text files that are hard-wrapped to 80 characters is just silly.
No easy way to configure X -- especially change resolution on the fly
You're full of it. There are tons of front ends to configure X. It's terribly easy to change resolution on the fly in X -- ctrl alt kp+ and ctrl alt kp-. Changing the desktop resolution during runtime isn't supported (though if you had to you could hack it up via DGA modes)...but why would you want to do this? The only reason people did this in Windows was because they wanted to run games or software that needed a lower resolution. They were *forced* to change their desktop size to change their resolution. X simply doesn't force this upon you. I *always* want my desktop using the maximum possible resolution that my video card/monitor can support. If I want larger fonts, I increase the font size (as one should do...trying to read lower res, pixelated fonts is just stupid). If I want bigger borders or titlebars, I enlarge those. If I want to play a game, I just run the thing and it switches res automatically via DGA calls. XFree 4.x does this nicely and cleanly.
Basically, it's because the X server you use stores the pixmaps in itself rather than in the application. There's no extra RAM use going on...it's just what's using the RAM that's different. In a MS Windows-like design, the applications would use more RAM to store those same pixmaps -- in X, the applications use less but the X server uses correspondingly more.
X gets blamed for tons of things, and usually doesn't deserve it.
You just automatically get charged per MAC. They control the WAP now. :-)
a) So if this is really the product manager, why does roxio.com have nothing whatsoever like this, a disclaimer or anything, on their website? Toast is their big product, and they're publicly traded. You'd think bad PR is something they'd want to quash.
b) If they have no intention of ever hitting users with DRM stuff, why the license agreement making users agree to allow Roxio control over their system?
c) If this doesn't make you a wee bit suspicious about Roxio and DRM, then you're naive.
d) The people at Roxio are not nice folks -- they went after the excellent Open Source project cdrtoaster (a Tk front end to cdrecord) as being trademark infringement and forced a name change.
In a hospital being treated for cancer?
I believe these nasty Roxio folks are the same people that made the cdrtoaster (Tk frontend to cdrecord) folks change their name based on trademark threats.
I also remember Roxio's Toast costing some huge sum of money back when burners first came out -- hundreds and hundreds of dollars. Unbelivably exorbant.
I really loathe Roxio.
This isn't a direct attack on Linux. It might hurt Linux long-term, but you can use Linux on a Palladium-enabled system. It just means that more and more things can become impossible to use on Linux.
Of course, I'd like to point out where trying to exclude Linux folks got the DVD Consortium. Palladium is better designed, and nastier, but the payoff for breaking it is also higher.
Code review has never been sufficient to ensure that code has no security holes. Trust me, code signing is not in the least about security -- it's about MS getting the power to exclude whoever they want.
First, MS may *allow* other CAs, but undoubtedly have agreements with a few as to criteria used in selecting okay software. Guess which ones are going to be "trusted by default" in shipped versions of Windows...yup, the "MS partners".
Second, this ensures that Open Source development is much more difficult and may be monitored -- applying for code signatures frequently costs time (if not money).
Third, this gives MS a nice foothold into the juicy, lucrative DRM field.
"Give me all your money or I'll shoot you."
Muggers do an excellent job of providing a solution that people want to take, as well.
You phase things out slowly. Intel and AMD support this, so all new PCs support Palladium. All new copies of Windows sold support Palladium. Five years down the road, media folks start requiring DRM to use their products, where 80% of the folks out there have DRM systems.
I mean, it's nice that you think that people will never move away, but that doesn't mesh with history. Lots of websites require Javascript, and there aren't always alternatives. Gopher is long gone...I can't visite gopher-only sites any more. I don't use Windows much, but I suspect that people still using Windows 95 are pretty much out in the cold when it comes to using new games.
Presumably he's either a home user suffering from MS's "never fix bugs unless you buy the next version with new buggy features" model or a corporate IT guy suffering from inane licensing terms.
Apple also has somewhat less leverage to screw its customers over than MS does.
It isn't just Mac users -- precious few consumers like the idea of DRM. It's just that MS may be able to tell everyone that they're darn well going to use it anyway.
Better quote:
"Biddle also denied widespread speculation that Palladium will involve changes to the existing TCP/IP protocol of the Internet, and would be used to disable or lock out other vendor's software, saying, "What IT manager in his right mind -- what Microsoft in its right mind would roll that out?".
Wow.
Also, the models he uses are impressive.
$ mv dlltool.dasm2 /dev/null :-)
mv: cannot move `dlltool.dasm2' to `/dev/null': Invalid cross-device link
I'm dubious about XP being a good OS.
I don't have any huge problems with the NT line of kernels (NT, 2k, XP). They're a bit slow, and the VM subsystem sucks in performance compared to Linux. They also lack a lot of cool functionality that the Linux kernel has (uber-powerful packet filtering and routing, low latency/realtime extensions). OTOH, they have very finely grained protection schemes, which is nice.
However, the 2k kernel is not what bothers me -- it's the software that comes with the kernel -- the file browser, the file search utility, the web browser, the dock. They suck. The dock isn't anywhere near as flexible as any but the worst of the UNIX docks. The file browser isn't very flexibile, keeps forgetting saved views on me, is slow and RAM hungry, and has security problems out the wazoo. The file search utility is incredibly slow and weak (combine locate, find, and grep and you have a far faster, more powerful system). I don't like the networking subsystem -- trying to get NT to have two configurations to switch between (where I have a PPP connection at home and an Ethernet connection at school) without uninstalling drivers was a pain -- disabling interfaces resulted in screwy routing. I dislike the lack of symlinks. I think the command shell sucks, lacking basic functionality and running extremely slowly. I'm unhappy with network file system performance -- SMB from Windows box to Windows box is sloooowwwww. I think the ACL system has some bad design decisions. I can't figure out why MS has never updated some of the truly ancient, lame software (Solitaire, Notepad (a bit better in 2k), the Calculator) that comes with the OS. I *really* don't like the file locking scheme -- an open file cannot be moved or renamed or deleted, unlike UNIX. I also think that it's really dumb that there's no concept of "limited right drivers" that can't barf all over your kernel (granted, Linux lacks this too).
I will say that the NT kernel is pretty stable, and that it's better than the truly horrific 9x line. But as for "hard pressed to find a better OS"? Nah.
My experience has been that once Linux supports something, it generally stays supported.
At work when moving from NT to 2k, I discovered that the sound card in the system was made by a company that no longer existed and never put out working drivers for anything above NT. Happily, they released enough technical information for Linux to support it, and now it'll probably be supported until the end of all time. :-)
Windows 2000/XP are damn good server...environments
Relative to the Win 9X line, perhaps. I very much disagree when compared to Linux, in terms of performance, flexability, tunability, and security. In my mind, these are pretty important points.