I don't see any reason for the ASPCA to complain. I mean really, who here believes that the game Black and White would entice youngins around the world to commit cruelty to animals? Since when is enslaving the soul of a wild beast and feeding it with pure magic until it grows in a pathetic attempt to escape the confines and restrictions of it's natural body considered "cruelty". It's doing them a favor really. What mouse or bunny rabbit wouldn't want to tower over it's former predators, crushing them into a bloody pulp under it's hideously enlarged paws? No cruelty that I can see.
I think I've just figured out something about the whole situation. The way I see it, Intel, IBM, and co seem to be pushing access control technology with almost religious zeal, despite loud protests from the general public, and organisations like the EFF. Why would they want to do this? At first glance, it doesn't seem to make good business sense:
First, it's not their content they are protecting. Sure, both IBM and 20th Century Fox are both big greedy corporations, but that's where the similarity ends.
It will cost more money to make these drives because of the extra electronics required.
They will be inundated with support calls from people that won't be able to work out why their movies or mp3s no longer work.
Drivers will become much more complex to write, and less reliable.
It's not like people are refusing to buy harddrives today because they don't have technology embedded into them to scramble movies. Most costumers, including myself, don't see why they should pay extra to get less.
So then, despite all these reasons not to use content restriction, why are all the major hard drive manufacturers and Microsoft seem so hell bent on implementing it anyway? For one, perfectly obvious reason: Because the protocols and keys will be a secret required for any kind of interoperability. They will obviously have to keep one or both secret, otherwise the technology is worthless, since it requires secrecy to operate. They can defend their need to keep the secret with the excuse that it protects copyrights (it doesn't), and hence they will not have to make it public. With the new laws against reverse engineering, even if somone broke the encryption, they couldn't use it without commiting a crime. This could effectively put a stop to competition in several types of software and hardware with one move. It's not about your MP3s, or you movies, it's simply a way of preventing small competitors becoming big competitors. If you think about it, this kind of technology could put a stop to innovation in more areas than just hard drives. It includes operating systems (Linux), motherboards (Various Taiwanese companies that don't have Intel's best interests in mind), and even video and sound cards, which will require encryption hardware to play encrypted movies.
You're kidding, right? Xerces-C is the best third-party C/C++ library I've ever seen! It has a neat Java-like design, but with the speed and flexibility of C++. (I just wish they used std::wstring instead of XMLString, but the conversion is trivial) What I love about it is that it uses Java-like autodoc comments, so I can produce unified documentation for my code as well as xerces-c using an external tool called DOXYGEN which also generates class-hierarchy and dependency graphs. Very cool.
It's typical NVIDIA behavior. I'd love to work for their PR depertment, because they consider it "work" to answer every question with some variant of "I can't say". I wonder if any of them are ex-NSA employees...
The best teacher(s) I've ever had where the two Johns at the University of New South Wales. John Storey and John Smith tought us electronics, and they actually cared about the students and their interests. For example, one day I noticed the little yellow flash that precedes the fluorescent lights turning on. I remembered that it's called a "condenser" and it has to be replaced every now and then. I remarked about this a fellow student, and after unsuccessfuly trying to work out what the condenser does and why it flashes, we went back to work. The next day, John gave me seven photocopied pages from a magazine and a textbook about what condensers are and how they work. Apparently, he overheard us and decided to satisfy my curiosity. I didn't even have to ask.
While interesting in an academic sense, such a discovery is rather trivial in a practical sense. Superconductivity itself has a number of astonishing uses that can sometimes look like magic, but they're only useful when we can get them to occur at useful temperatures. Unfortunately, cooling something to 1K will require something along the lines of laser cooling in order to achieve, and this turns out to not be very practical. Superconductors with a very low critical temperature cannot conduct much current before they exceed their critical energy level and "go normal".
Laser cooling only works for gases. 1K is usually achieved by first cooling using liquid Helium, then using various tricks to go a few degrees lower. Releasing pressure, or realignment of magnetic fields can all cause temperature drops sufficient to reach 1K, or even lower. Laser cooling is used to reach temperatures far lower than 1K.
Useful superconductors are more in the line of HTC's, high temperature superconductors. The simplest of these are the superconductors that work when cooled to the order of 70 degrees Kelvin (-200C) by liquid nitrogen (which is cheaper than beer). If I recall correctly, the highest published HTC was around 175K, which is only 100 degrees below freezing. I've heard rumors of higher temperature superconductors, but haven't seen any referreed publications of results yet. Keep your eyes peeled, we'll see room-temperature superconductors within the lifetimes of most slashdotters.
That might not be possible. Many physicists now question if RTSCs are possible, because the thermal energy of the lattice might break apart the delicate electron-electron pairing. Certainly, there is a lot of territory to cover, like strained crystal lattices, doped bucky tubes and the like, but don't get your hopes up. Also, most HTSCs are brittle, difficult to manufacture, very expensive, and often toxic.
To be fair to lower temperature superconductors, I believe the maglev train in Japan uses a lower temperature superconductor cooled by liquid helium, which is somewhere down on the order of 10K.
Most modern experiments involve liquid Nitrogen temperatures, or no superconductors at all. It's just cheaper. Liquid Helium is expensive, and requires complex insulation systems.
Superconductors aren't too useful for their property of not conducting current, since they have a critical maximum current level anyway. They are mostly used for their diamagnetic properties (they repel magnetic flux lines). This is the basis for how an MRI works, or for how super-fast magnetic trains work.
Their maximum current capacity is huge, but unlike copper, if you stay under the maximum, superconductors can transfer the current with zero loss, even at lower voltages. They are already in use at several powerplants for short-haul, high-current lines, etc... I've heard of at least one powerplant that uses a superconducting ring (inductor) to smooth out demand surges.
That's just a fault of the early compilers, not the language itself. The newer compilers have been known to beat hand-tuned assembler at many problems. For example, I'm writing a real time 3D engine, and there is not one instance where I had to resort to C or assembler. Even virtual functions can be inlined by clever compilers that analyze the entire source database at once. Even if they are not, I've seen benchmarks of C function calls vs C++ virtual function calls, and the difference is peanuts. It's only stupid coders who put reams of trivial one line code into virtual functions that pay the price.
I laugh every time I hear the clocks per instruction "benchmark". A higher CPI is better. Only assembler can approach a 1.0 CPI, because it's the most primitive language. More abstract languages have a higher CPI, but less instructions. I can describe the equivalent of 10 lines of C in a single elegant line of C++!
Re:Programmers Make Computers Slower Year by Year
on
Netscape 6 Vs. 4.7x
·
· Score: 1
I don't understand these conservate people who lament about the "good old days", as if it was a golden age. It wasn't. I was programming back in the days when an XT with two floppy drives was "high end", and a good assembler coder could squeeze a VGA animation, some music, and an ANSI BBS logo into a 4kb COM executable. However, I gladly gave up my trusty turbo assembler in favor of DirectX 8 and VIsual C++. Sure, the SDK is a 120MB download not counting the 2-3GB of compilers, documents, samples, tools, and media, but frankly, I don't care. I have the bandwidth to download it, the disk space to store it, and the memory to load it into. Why should I waste my time saving bytes that don't need to be saved instead of adding features?
What non-programmers don't understand is that modern applications are huge exactly because they use superior algorithms. It's possible to write an editor in a few minutes these days only because of powerful new libraries like the SGI STL's rope class, which is designed to replace the old C strings. Unlike C strings which are just simple 32bit pointers, ropes are trees of nodes allocated on the heap. This seems like a waste, but a rope can insert a character into a multi-megabyte string in microseconds, and the same code that can efficiently manipulate 10 character strings can manipulate 10 GB strings without a performance hit. I'm quite willing to pay the once-off 100kb overhead for that kind of power.
The point is that if even a moron can produce a useable editor with tools like that at his disposal, image what a seasoned programmer could do!
You think that's bad? When NASA finally shut off the communications with the Voyager II space probe, we lost one of our major links with the outside world...
AFAIK, virtual tables are about as good as you can get. I've heard of efforts like HP's emulator code that can "flatten" code at runtime, but that's pretty fugging complicated. Do you have any URLs that give more info about the alternatives?
What kills me about MFC is that it's not just one OO system, but at least THREE layered on top of each other.
The first layer is Win32, which is an OO system extending C/Asm. It uses strings as class identifiers that are created at runtime, and numeric method/event identifiers that are distributed through hierarchial switch statements. Half of it runs in the operating system, and half of it runs in your app, a combination that is extremely confusing and difficult to debug.
MFC is a C++ wrapper around this. The problem is that C++ classes are fixed at compile time, C++ names can't be exported to a C app (and hence can't be called from kernel), and it uses virtual tables (arrays of function pointers) instead of switch statements. MFC is largely massive hack to make C++ and Win32 coexist. The C++ CWnd class creates matching HWND handles to the Win32 classes, and translates between the two OO styles. This translation is by no means trivial, and as others have mentioned it involves massive macros and templates, and all sorts of custom extensions and language abuse.
Just when you though it couldn't get any worse, Microsoft came up with OLE/COM. COM uses 64 bit GUIDs to identify classes that can be running anywhere, even in another process or computer. It imports platform/compiler independent virtual tables at runtime, uses assembler hacks to get the function call translation going, etc... One of the big disadvantages of COM is that it's not really an Object Oriented system, but an Object Based system. It uses classes, but it's very difficult, if not impossible, to subclass from them. For example, DirectX is a popular COM based API, but I've never heard of anyone subclassing from, say, IDirect3DDevice7. COM requires some pretty strange things, and all of this has to be interfaced to C++ too, while maintaining compatibility with Win32.
In my experience, programming in MFC is mostly cut-and-paste from the help, because it's practically impossible to work out the steps required to accomplish any given task. Sure, making a dialog box with a few standard controls is trivial, but if you want to step out of the given bounds in the slightest way, you're up the proverbial creek without a paddle.
--
"If you would be a real seeker after truth, it is necessary that at least
once in your life you doubt, as far as possible, all things."
>>I work at a company where we used mixed NT4, W2K and Linux boxes, but all the sysadmins (and servers) are
>>linux or solaris.
>And have you ever considered why this might be the case? For that matter, if this is such a problem for you, why are you still working there? Are you just trolling Slashdot in order to vent your frustrations?
Did I say I have a problem with it? IMHO, the NT4 boxes should be upgraded to Win2k, and the Linux boxes kept as they are, but that's not my decision to make. Actually, if I had a choice, I'd have Win2k PCs only with the option to telnet/x-session into some beefy backend Linux server for those that want the power.
>> Every argument against Windows basically breaks down into:
>>"But the command prompt doesn't have color directory listings!"
>>"I can't recompile the kernel!"
>>"The 'telnet' sucks!"
>Holy cats! These are only the tip of the iceberg. Nice straw man, though.
Straw man? These are actual quotes from my fellow employees! It's understandable, considering that many of them were first introduced to computers at university, where all the boxes run Solaris. Many have never actually used Windows for any length of time. My point is that I've heard few rational arguments against Win2k, which seems to perform quite well in the real world. My home PC is running Win2k Server, and avarages an uptime of about a month. (I only reboot because it's a gaming PC, so I update the video drivers often.)
I can live with a planned 5 minute downtime every month.
>>What I can't seem to explain to Linux users is that in Windows, you don't NEED any of those, so it makes not one bit of difference if they are not implemented in the same way as in linux. I could very well come back and say:
>>"But Linux sux because it doesn't have a visual file explorer tool!" Of course, the answer is that it doesn't need it, the command line tools are sufficient.
>No, that's _not_ the answer. The answer is that you have several equivalent GUI tools to do the same thing, but for the poweruser the generally just get in the way.
I am a poweruser, and those GUI tools are NOT equivalent. Is there a GUI equivalent of, say, "head"? No! That's my point. Linux users keep searching for precisely equivalent tools to do things like they always did. Needless to say, they are always dissapointed.
>>However, I still prefer to mouse to writing a ten mile long command to select those (and only those!) files I want copied.
>That's about the _only_ operation where using a mouse (perhaps) makes sense. The rest of the time I don't want to be locked into the GUI (RSI, time and frustration factor, ya know.)
My ass. Any time you're manipulating a small-to-medium sized list of data to do anything even remotely complex, the mouse wins hands down. I have a rule I apply to code or applications to see how good they are. It's called the "1,10,1M" rule. It goes like this:
For any interface, be it a C++ class, or a GUI, how quick/easy is it to perform a task:
o Once?
o Ten times?
o A million times?
In the first case, Windows spanks Linux in every imaginable way. It's faster and easier to do practically anything once in Windows than it is in Linux. For example, I set up Network Address Translation on my cable internet connection in 2m:30s without even reading the docs. Linux can NEVER compare to that.
In the second situation, it often becomes painful to repeat the same action 10 times, but writing a script would take too long. Deeply nested menus, or clumsy interfaces can make this the most annoying situation. The ability to "block select", drag-and-drop, or generally batch commands helps a lot. Windows and Linux are roughly equal in this area.
In the last case, it's scriptability that counts, and performance becomes a major issue. At this stage, Linux is ahead, but I can't judge by how much. Win2k has definately made big strides forward in this area with the new scripting APIs and related support.
>>The moral of the story: Windows (especially 2k, the previous versions just sucked), can do everything Linux can
>>in the abstract sense,
> No, you're missing the main points of this whole discussion, which are stability, maintainability, etc.
That's exactly what I mean by "abstract", I am not missing the point at all.
>> but don't expect it to have the same command line options for the "cp/copy" command!
> How can you compare a modern shell to that POS DOS?! I find it nearly totally unusable as a command line shell. Face, MS _doesn't want_ you using a command line. I prefer not to let my OS tell me what I can or cannot do.
My point exactly. The command line is not the main interface in Windows. I can't remember the last time I needed to use "copy" for anything. I don't feel like I've been forced to do so, I just have no need to use it.
I work at a company where we used mixed NT4, W2K and Linux boxes, but all the sysadmins (and servers) are linux or solaris. Every argument against Windows basically breaks down into:
"But the command prompt doesn't have color directory listings!"
"I can't recompile the kernel!"
"The 'telnet' sucks!"
What I can't seem to explain to Linux users is that in Windows, you don't NEED any of those, so it makes not one bit of difference if they are not implemented in the same way as in linux. I could very well come back and say: "But Linux sux because it doesn't have a visual file explorer tool!" Of course, the answer is that it doesn't need it, the command line tools are sufficient. However, I still prefer to shift-select 100 files and drag them with the mouse to writing a ten mile long command to select those (and only those!) files I want copied.
The moral of the story: Windows (especially 2k, the previous versions just sucked), can do everything Linux can in the abstract sense, but don't expect it to have the same command line options for the "cp/copy" command!
Slashdot Mirror
I don't see any reason for the ASPCA to complain. I mean really, who here believes that the game Black and White would entice youngins around the world to commit cruelty to animals? Since when is enslaving the soul of a wild beast and feeding it with pure magic until it grows in a pathetic attempt to escape the confines and restrictions of it's natural body considered "cruelty". It's doing them a favor really. What mouse or bunny rabbit wouldn't want to tower over it's former predators, crushing them into a bloody pulp under it's hideously enlarged paws? No cruelty that I can see.
I think I've just figured out something about the whole situation. The way I see it, Intel, IBM, and co seem to be pushing access control technology with almost religious zeal, despite loud protests from the general public, and organisations like the EFF. Why would they want to do this? At first glance, it doesn't seem to make good business sense:
So then, despite all these reasons not to use content restriction, why are all the major hard drive manufacturers and Microsoft seem so hell bent on implementing it anyway? For one, perfectly obvious reason: Because the protocols and keys will be a secret required for any kind of interoperability. They will obviously have to keep one or both secret, otherwise the technology is worthless, since it requires secrecy to operate. They can defend their need to keep the secret with the excuse that it protects copyrights (it doesn't), and hence they will not have to make it public. With the new laws against reverse engineering, even if somone broke the encryption, they couldn't use it without commiting a crime. This could effectively put a stop to competition in several types of software and hardware with one move. It's not about your MP3s, or you movies, it's simply a way of preventing small competitors becoming big competitors. If you think about it, this kind of technology could put a stop to innovation in more areas than just hard drives. It includes operating systems (Linux), motherboards (Various Taiwanese companies that don't have Intel's best interests in mind), and even video and sound cards, which will require encryption hardware to play encrypted movies.
You're kidding, right? Xerces-C is the best third-party C/C++ library I've ever seen! It has a neat Java-like design, but with the speed and flexibility of C++. (I just wish they used std::wstring instead of XMLString, but the conversion is trivial) What I love about it is that it uses Java-like autodoc comments, so I can produce unified documentation for my code as well as xerces-c using an external tool called DOXYGEN which also generates class-hierarchy and dependency graphs. Very cool.
It's typical NVIDIA behavior. I'd love to work for their PR depertment, because they consider it "work" to answer every question with some variant of "I can't say". I wonder if any of them are ex-NSA employees...
Umm... exactly which thing did you have a problem with, it wasn't clear to me from your post!
The best teacher(s) I've ever had where the two Johns at the University of New South Wales. John Storey and John Smith tought us electronics, and they actually cared about the students and their interests. For example, one day I noticed the little yellow flash that precedes the fluorescent lights turning on. I remembered that it's called a "condenser" and it has to be replaced every now and then. I remarked about this a fellow student, and after unsuccessfuly trying to work out what the condenser does and why it flashes, we went back to work. The next day, John gave me seven photocopied pages from a magazine and a textbook about what condensers are and how they work. Apparently, he overheard us and decided to satisfy my curiosity. I didn't even have to ask.
While interesting in an academic sense, such a discovery is rather trivial in a practical sense. Superconductivity itself has a number of astonishing uses that can sometimes look like magic, but they're only useful when we can get them to occur at useful temperatures. Unfortunately, cooling something to 1K will require something along the lines of laser cooling in order to achieve, and this turns out to not be very practical. Superconductors with a very low critical temperature cannot conduct much current before they exceed their critical energy level and "go normal".
Laser cooling only works for gases. 1K is usually achieved by first cooling using liquid Helium, then using various tricks to go a few degrees lower. Releasing pressure, or realignment of magnetic fields can all cause temperature drops sufficient to reach 1K, or even lower. Laser cooling is used to reach temperatures far lower than 1K.
Useful superconductors are more in the line of HTC's, high temperature superconductors. The simplest of these are the superconductors that work when cooled to the order of 70 degrees Kelvin (-200C) by liquid nitrogen (which is cheaper than beer). If I recall correctly, the highest published HTC was around 175K, which is only 100 degrees below freezing. I've heard rumors of higher temperature superconductors, but haven't seen any referreed publications of results yet. Keep your eyes peeled, we'll see room-temperature superconductors within the lifetimes of most slashdotters.
That might not be possible. Many physicists now question if RTSCs are possible, because the thermal energy of the lattice might break apart the delicate electron-electron pairing. Certainly, there is a lot of territory to cover, like strained crystal lattices, doped bucky tubes and the like, but don't get your hopes up. Also, most HTSCs are brittle, difficult to manufacture, very expensive, and often toxic.
To be fair to lower temperature superconductors, I believe the maglev train in Japan uses a lower temperature superconductor cooled by liquid helium, which is somewhere down on the order of 10K.
Most modern experiments involve liquid Nitrogen temperatures, or no superconductors at all. It's just cheaper. Liquid Helium is expensive, and requires complex insulation systems.
Superconductors aren't too useful for their property of not conducting current, since they have a critical maximum current level anyway. They are mostly used for their diamagnetic properties (they repel magnetic flux lines). This is the basis for how an MRI works, or for how super-fast magnetic trains work.
Their maximum current capacity is huge, but unlike copper, if you stay under the maximum, superconductors can transfer the current with zero loss, even at lower voltages. They are already in use at several powerplants for short-haul, high-current lines, etc... I've heard of at least one powerplant that uses a superconducting ring (inductor) to smooth out demand surges.
That's just a fault of the early compilers, not the language itself. The newer compilers have been known to beat hand-tuned assembler at many problems. For example, I'm writing a real time 3D engine, and there is not one instance where I had to resort to C or assembler. Even virtual functions can be inlined by clever compilers that analyze the entire source database at once. Even if they are not, I've seen benchmarks of C function calls vs C++ virtual function calls, and the difference is peanuts. It's only stupid coders who put reams of trivial one line code into virtual functions that pay the price. I laugh every time I hear the clocks per instruction "benchmark". A higher CPI is better. Only assembler can approach a 1.0 CPI, because it's the most primitive language. More abstract languages have a higher CPI, but less instructions. I can describe the equivalent of 10 lines of C in a single elegant line of C++!
I don't understand these conservate people who lament about the "good old days", as if it was a golden age. It wasn't. I was programming back in the days when an XT with two floppy drives was "high end", and a good assembler coder could squeeze a VGA animation, some music, and an ANSI BBS logo into a 4kb COM executable. However, I gladly gave up my trusty turbo assembler in favor of DirectX 8 and VIsual C++. Sure, the SDK is a 120MB download not counting the 2-3GB of compilers, documents, samples, tools, and media, but frankly, I don't care. I have the bandwidth to download it, the disk space to store it, and the memory to load it into. Why should I waste my time saving bytes that don't need to be saved instead of adding features?
What non-programmers don't understand is that modern applications are huge exactly because they use superior algorithms. It's possible to write an editor in a few minutes these days only because of powerful new libraries like the SGI STL's rope class, which is designed to replace the old C strings. Unlike C strings which are just simple 32bit pointers, ropes are trees of nodes allocated on the heap. This seems like a waste, but a rope can insert a character into a multi-megabyte string in microseconds, and the same code that can efficiently manipulate 10 character strings can manipulate 10 GB strings without a performance hit. I'm quite willing to pay the once-off 100kb overhead for that kind of power.
The point is that if even a moron can produce a useable editor with tools like that at his disposal, image what a seasoned programmer could do!
You think that's bad? When NASA finally shut off the communications with the Voyager II space probe, we lost one of our major links with the outside world...
AFAIK, virtual tables are about as good as you can get. I've heard of efforts like HP's emulator code that can "flatten" code at runtime, but that's pretty fugging complicated. Do you have any URLs that give more info about the alternatives?
What kills me about MFC is that it's not just one OO system, but at least THREE layered on top of each other.
The first layer is Win32, which is an OO system extending C/Asm. It uses strings as class identifiers that are created at runtime, and numeric method/event identifiers that are distributed through hierarchial switch statements. Half of it runs in the operating system, and half of it runs in your app, a combination that is extremely confusing and difficult to debug.
MFC is a C++ wrapper around this. The problem is that C++ classes are fixed at compile time, C++ names can't be exported to a C app (and hence can't be called from kernel), and it uses virtual tables (arrays of function pointers) instead of switch statements. MFC is largely massive hack to make C++ and Win32 coexist. The C++ CWnd class creates matching HWND handles to the Win32 classes, and translates between the two OO styles. This translation is by no means trivial, and as others have mentioned it involves massive macros and templates, and all sorts of custom extensions and language abuse.
Just when you though it couldn't get any worse, Microsoft came up with OLE/COM. COM uses 64 bit GUIDs to identify classes that can be running anywhere, even in another process or computer. It imports platform/compiler independent virtual tables at runtime, uses assembler hacks to get the function call translation going, etc... One of the big disadvantages of COM is that it's not really an Object Oriented system, but an Object Based system. It uses classes, but it's very difficult, if not impossible, to subclass from them. For example, DirectX is a popular COM based API, but I've never heard of anyone subclassing from, say, IDirect3DDevice7. COM requires some pretty strange things, and all of this has to be interfaced to C++ too, while maintaining compatibility with Win32.
In my experience, programming in MFC is mostly cut-and-paste from the help, because it's practically impossible to work out the steps required to accomplish any given task. Sure, making a dialog box with a few standard controls is trivial, but if you want to step out of the given bounds in the slightest way, you're up the proverbial creek without a paddle.
--
"If you would be a real seeker after truth, it is necessary that at least
once in your life you doubt, as far as possible, all things."
>>I work at a company where we used mixed NT4, W2K and Linux boxes, but all the sysadmins (and servers) are
>>linux or solaris.
>And have you ever considered why this might be the case? For that matter, if this is such a problem for you, why are you still working there? Are you just trolling Slashdot in order to vent your frustrations?
Did I say I have a problem with it? IMHO, the NT4 boxes should be upgraded to Win2k, and the Linux boxes kept as they are, but that's not my decision to make. Actually, if I had a choice, I'd have Win2k PCs only with the option to telnet/x-session into some beefy backend Linux server for those that want the power.
>> Every argument against Windows basically breaks down into:
>>"But the command prompt doesn't have color directory listings!"
>>"I can't recompile the kernel!"
>>"The 'telnet' sucks!"
>Holy cats! These are only the tip of the iceberg. Nice straw man, though.
Straw man? These are actual quotes from my fellow employees! It's understandable, considering that many of them were first introduced to computers at university, where all the boxes run Solaris. Many have never actually used Windows for any length of time. My point is that I've heard few rational arguments against Win2k, which seems to perform quite well in the real world. My home PC is running Win2k Server, and avarages an uptime of about a month. (I only reboot because it's a gaming PC, so I update the video drivers often.)
I can live with a planned 5 minute downtime every month.
>>What I can't seem to explain to Linux users is that in Windows, you don't NEED any of those, so it makes not one bit of difference if they are not implemented in the same way as in linux. I could very well come back and say:
>>"But Linux sux because it doesn't have a visual file explorer tool!" Of course, the answer is that it doesn't need it, the command line tools are sufficient.
>No, that's _not_ the answer. The answer is that you have several equivalent GUI tools to do the same thing, but for the poweruser the generally just get in the way.
I am a poweruser, and those GUI tools are NOT equivalent. Is there a GUI equivalent of, say, "head"? No! That's my point. Linux users keep searching for precisely equivalent tools to do things like they always did. Needless to say, they are always dissapointed.
>>However, I still prefer to mouse to writing a ten mile long command to select those (and only those!) files I want copied.
>That's about the _only_ operation where using a mouse (perhaps) makes sense. The rest of the time I don't want to be locked into the GUI (RSI, time and frustration factor, ya know.)
My ass. Any time you're manipulating a small-to-medium sized list of data to do anything even remotely complex, the mouse wins hands down. I have a rule I apply to code or applications to see how good they are. It's called the "1,10,1M" rule. It goes like this:
For any interface, be it a C++ class, or a GUI, how quick/easy is it to perform a task:
o Once?
o Ten times?
o A million times?
In the first case, Windows spanks Linux in every imaginable way. It's faster and easier to do practically anything once in Windows than it is in Linux. For example, I set up Network Address Translation on my cable internet connection in 2m:30s without even reading the docs. Linux can NEVER compare to that.
In the second situation, it often becomes painful to repeat the same action 10 times, but writing a script would take too long. Deeply nested menus, or clumsy interfaces can make this the most annoying situation. The ability to "block select", drag-and-drop, or generally batch commands helps a lot. Windows and Linux are roughly equal in this area.
In the last case, it's scriptability that counts, and performance becomes a major issue. At this stage, Linux is ahead, but I can't judge by how much. Win2k has definately made big strides forward in this area with the new scripting APIs and related support.
>>The moral of the story: Windows (especially 2k, the previous versions just sucked), can do everything Linux can
>>in the abstract sense,
> No, you're missing the main points of this whole discussion, which are stability, maintainability, etc.
That's exactly what I mean by "abstract", I am not missing the point at all.
>> but don't expect it to have the same command line options for the "cp/copy" command!
> How can you compare a modern shell to that POS DOS?! I find it nearly totally unusable as a command line shell. Face, MS _doesn't want_ you using a command line. I prefer not to let my OS tell me what I can or cannot do.
My point exactly. The command line is not the main interface in Windows. I can't remember the last time I needed to use "copy" for anything. I don't feel like I've been forced to do so, I just have no need to use it.
I work at a company where we used mixed NT4, W2K and Linux boxes, but all the sysadmins (and servers) are linux or solaris. Every argument against Windows basically breaks down into:
What I can't seem to explain to Linux users is that in Windows, you don't NEED any of those, so it makes not one bit of difference if they are not implemented in the same way as in linux. I could very well come back and say: "But Linux sux because it doesn't have a visual file explorer tool!" Of course, the answer is that it doesn't need it, the command line tools are sufficient. However, I still prefer to shift-select 100 files and drag them with the mouse to writing a ten mile long command to select those (and only those!) files I want copied.
The moral of the story: Windows (especially 2k, the previous versions just sucked), can do everything Linux can in the abstract sense, but don't expect it to have the same command line options for the "cp/copy" command!