The actor who stars in the show is pronounced Cole-bert.
If this is true, it's not just The Colbert Report where he's pronounced it that way. That goes back to his Daily Show days; indeed even before Jon Stewart arrived on the scene, Craig Kilborn introduced him as "Cole-bare." I've also always heard him introduced on other shows the same way.
Make a typo, or try to do something that LaTeX doesn't like (there are many things that fall in this category) and try to decipher the error message -- 9 times out of 10, it's several pages long and offers absolutely no hint as to what the actual error was.
Oh, be fair. The error is intelligible at least half the time.;-)
I'm being sort of tongue-in-cheek, but this is a big problem. Errors for simple things like most command typos are fine, but the error detection in more difficult cases leaves a ton to be desired.
I also like how I know tons of people who use Latex, but I don't know any of them use the actual interface Latex provides for dealing with errors; I usually just type 'q' a couple times until it's gone away and go look in the editor.
All word is doing is embedding some image, and generally any program that generates that image can also save it to a file.
The convenience factor of having it embedded shouldn't be underestimated though; it has the same general benefits of WYSIWYG editors in general, which is that you don't have to rebuild stuff to see what the effect is.
Also, the ability to macroize things (i.e. type \rlcn{} for really long chemical name) makes life much easier and less error prone to typos.
You can do something similar in Word though... just set up an autocorrect from rlcn to "really long chemical name". The main difference is you should be more careful about picking something you don't actually want to appear in-text at all.
There's a lot to recommend Latex, and it wouldn't be unreasonable. That said, I have a hard time saying, for sure, yes. It probably depends on personal preference.
I'm a bit of a typography snob, so I like the things that Latex does that I don't know how to get Word to do. For instance, when typing in Word, when the line gets too long, it wraps. In Latex, the line breaks are not inserted by such a simple algorithm; perhaps breaking this line a little earlier will prevent a nasty break later. For more even more snobby examples, see here.
Another of Latex's benefits is its programmability; this will sometimes come in handy. If you look at the diversity of the Latex packages out there, it should become apparent what benefits this can have. It also means that it's a bit more complex.
Latex will do stuff like automatic table of contents too. For citations, there is Bibtex. I haven't used Zotero, but it's at least better than the experience I had of using a really old version of EndNote. Bibtex works pretty slick: you just put ~\cite{some-key} into your document, and it will look through the Bibtex database, find the reference marked {some-key}, put it into your bibliography, automatically number/name everything in the bibliography (using one of any number of styles), and insert the citation into the text of your document.
Finally, the fact that Latex works really well with version control because you can get reasonable diffs is almost a killer feature for me.
At the same time, I've also found that getting Latex to do stuff it wasn't built to do can often be a pain.
Also, if what you're doing is table-heavy, I might recommend you stay away; if you've ever hand-programmed in HTML and had to do tables and found it really annoying, you'll have the same problems with Latex.
Basically what it boils down to is that I think that Latex would be a reasonable choice for you, but I can't say with any certainty that it'd be a better choice than Word, or that Word would be better than Latex.
You can do a diff with an external program that deals with intraline in a less retarded way.;-)
I'm actually not sure what there is available for running from the command line (though 'svn diff --diff-cmd' will let you run something other than 'diff', if you can find a command-line replacement), but a lot of SVN graphical front ends also have a graphical diff program, many of which will do this better. (They'll usually highlight the whole line, but then word-by-word changes in a darker shade of red/green.)
Also very awesome is latex-diff. This takes two versions of a document, and marks changes in it using latex markup. You then pass the result through latex, and the result is a PDF that looks like what you get from an old version of Word or (current version of; this is one area it's far behind Word) Open Office Writer with track changes on.
Usually when people blather about "secret undocumented Windows APIs" they're ranting about MS keeping the good stuff for themselves. That's just not the case anymore.
Oh, I agree with that.
Actually, I've heard that back in the days when other MS products were using the at-the-time undocumented interfaces (which I assume means the Native API), when the Windows team heard about it, they were livid because that interface is not supposed to be targeted so they can change it without breaking stuff.
I think you mean "Win32", as that's the library most user-mode systems guys program against.
"Win32" hasn't been the official name for a while, and it's now called the Windows API. (After all, it also works on 64-bit builds of Windows.) See the second sentence on Wikipedia.
I don't know why people keep imagining all these "undocumented" interfaces. Microsoft lost all those lawsuits long ago, and everything is documented (though sometimes crapily, as with anything).
I'm not as convinced I'm right, but I'm still seeing some evidence. For instance, there are several functions on an old Sysinternals page on the Native API that I can't find documentation of (either under the Nt* name, Zw* name, or Ke* name), such as NtCreateSemaphore. undocumented.ntinternals.com has a bunch that I can't find on MSDN. Still, I'm willing to concede I might be wrong on this point, and merely say that until relatively recently (even in terms of the history of NT), it was undocumented.
Your post would make more sense if you didn't say "Windows API". There are multiple system libraries in Windows (multiple ways to get kernel functionality from user-mode programs). Win32, WOW16, WOW64, POSIX compatibility layer, OS/2 compatibility layer, and maybe others.
But only one thing that's actually called "the Windows API"; the Win32 and 64 subsystem and WOW subsystems implement it (and all implement it the same with respect to what I'm talking about).
This isn't a "hole" or an "undocumented interface", it's an entirely different system library.
I would argue it is a hole, because writing a program that will be able to properly detect virus or whatnot in files "hidden" by the Windows subsystems (i.e. Win32/64, WOW) case insensitivity becomes non-trivial. You either need to use native system calls (and thus an undocumented interface) or write part of your component to use document calls in a subsystem that DOES provide access to these files -- to my knowledge, this is only the POSIX subsystem/SFU/SUA/Interix/whatever you want to call it. Since you can't mix your uses of the subsystems, this means that your program now needs to be split in two parts, one that runs in the Windows subsystem and provides the UI, and one that runs in the POSIX subsystem and does the actual scanning. Oh, and you can't use a lot of the Windows API calls in that part. Oh, and no one writing security software actually does this, because they don't want to make people install SFU. This means that, based on what I know, either current security software will miss such files or they are making calls to the undocumented system call interface. (Given the syscall hooking and such that a lot of security software does, I know which one I would guess.)
Of course we got our POSIX ACLs and security labels.
By my understanding, doing something as simple as saving a file in Emacs will kill any ACLs associated with it. It definitely will kill other extended attributes associated with the file. Am I wrong on this?
I third that one; I have a pair of Grado SR-125 headphones and they're brilliant. Bright, odd to get used to wearing, but brilliant. I want to get a pair of the SR-325i at some point...
I tried the SR-125s, and I liked them a little better, but not $50 better or whatever the difference is. If I used a stereo with a 1/4" plug instead of 3.5mm one I might have gone for it. In any case, that whole line (SR-60/80/125) are really great, highly recommended, and not too expensive.
Then I try it with classical or rock; and realise it might just be that electronic music, already intentionally sounding artificial, survives that process a lot better than most. It's night and day with classical, and God help you if there's harpsichord.
Interesting... classical and rock is basically all I listen to, which may have something to do with the fact that I find the people this article applies to really weird.;-)
Then I bought a decent $70 set of headphones (Grado Labs, in case anyone cares) to listen with at work and my whole mp3 collection sounds like crap.
I second this. If you listen to a lot of music, good headphones are a godsend, and once you get a set, the differences are much more noticable. (I also second Grados; I have the SR-80s on right now; mdarksbane probably has the SR-60s. Both are way better than anything I've used in the past. I like them more than the Sennheisers I tried on at twice the price of the SR-80s.)
They aren't headphones for jogging or working out at the gym or anything, but they are great for listening to at work.
Memory's not the problem, because read-only pages (like code) can be shared. It's more like just taking the existing memory space and dividing it up into different ones. There might be a little slop because of pages not being complete, but that's at most a couple per process, so even with 50 processes you're looking at 1MB of additional memory.
Of more concern is the increased context switching time, increased TLB misses, etc.
There is no alternative namespace, there are merely alternate streams in a file - named locations for storing meta data. The file is right there in the filesystem, obvious to all. The file data may be a bit hidden, requiring normal Windows system calls to read (just like one uses normal Windows system calls to create alernate data streams), instead of Notepad. Oh, wait, you can read them with Notepad too. What a bunch of FUD.
This... is actually not the whole story.
NTFS is actually a case-sensitive file system. You can illustrate this by installing Services for Unix. This is an alternative subsystem that doesn't go through the normal Windows API (or the DLLs implementing it) and collection of Unix programs that have been "ported" to it. Once you install this, programs that are part of SFU are able to create files with the same case-sensitive name but different case.
Instead, the reason you normally can't do this is because the DLLs that are part of the Windows subsystem (the one providing the normal Windows API) hides this case-sensitivity in concert with the file system driver. (IIRC, open commands in the driver get a flag saying whether to be case-sensitive or not.) Instead of making calls through the Windows API, you can either use another subsystem like SFU or make native system calls directly (though that interface isn't supported).
Finally, the implementation of the Windows API is such that if you create two files with different case but the same name, only one will be visible through the Windows API, at least with NTFS's implementation of all of this.
This means that if you want to write security software for Windows, to catch malware written by people who know about this hole, you need to make API calls to an undocumented interface if you don't want to require people to install SFU. (Of course, security software does so much other stuff that's even worse that's hardly a drop in the bucket.)
It's always interesting when long-time Windows users experiment with Linux for the first time. You'll see some tech writer blog about this every few months; sometimes they are a bit boring, but I always learn something from watching a Linux newbie try things out for the first time.
I'm pretty interested in usability, so I also find them interesting.
I just got done reading your blog and posted a couple comments (MS Paint & Crop, "I hate Office", and "Options"). They tend to be defensive of Windows, both because I am generally disposed to that anyway and because your posts are almost all negative.;-)
PPT is easily heads and shoulders above where OpenOffice is, and for 98% of presentaitons, above where anything but maybe keynote is. (I haven't used keynote, but it does make very nice presentations.) The only realistic option for most presentations that would be better than PPT is to forgo anything from a computer, and in many situations that's not very realistic.
(For math-heavy ones, Latex Beamer is also an option. Without the math-heavy though, I don't think it's as good.)
Another excuse why windows is better than linux, you mentioned 3 Microsoft products, you don't want to leave.
He also gave reasons for why he doesn't want to, especially for #1. Personally, I think your post is indicative of the worst part of the culture sometimes seen with Linux people, which is refusing to see places where Office or Windows or whatever still does things better.
Windows users have a mental model of computers which is Windows-specific...
Calling it Windows-specific I think is a bit of a misnomer, even if it was caused by Windows. I'm a heavy Linux user (posting from a tiling WM under RHEL if that gives me any cred on that point) and even I agree with some of these points.
For instance, 2: "Reading is for web pages, not system configuration". I like the fact that I can just browse around a GUI for options and see what's available rather than read a man page or whatever to figure out what you can configure. Sometimes packages are nice enough to give you a default conf file with a bunch of options commented out (basically putting the documentation in comments), and that's a nice analogy in the text world, but not all packages do this and even ones that do often don't put everything into it.
I like the fact that if I have a GUI I can look and have high assurance that I can explore around and find things -- usually there won't be options that are hidden. (Not always true. The default shutdown dialog in Win XP has options to log out, shut down, and stand by or something like that, but you can also press 'h' to hibernate. I'm not actually sure how to hibernate without this feature actually! Office 2007 allows you to use keyboard shortcuts from previous versions, but doesn't provide any affordances for it.) About the only exploration you can do with a command line program is type --help after it and see what happens; you basically have to read the man page.
Out of curiosity, do you know if most Windows applications also remove your personal preferences from the hidden directories in your home folder?
Not in general.
There are a ton of good reasons (on any platform) why you probably don't want to do this, and a few for why you would. I tend to think that the former reasons are more compelling, so I think programs get it right.
One place to manage applications, one place to manage updates, and one place to manage packages.
What's the difference between an application and a package? Hell, I'm a geek posting this from RHEL running a tiling window manager (totally the way to go BTW) and have a few gigs of applications on this computer I've installed with the 'configure && make && make install' sequence, and even I am not really sure what the answer is. I mean, I know what I would say if someone asked me and it's I think a good answer, but if I go by those definitions I'm not sure what the GUI to manage applications would be.
Furthermore, why should the update manager be separate? After all, presumably it's managing updates to packages in the end, so why should that be separate from the package manager?
Because Microsoft actually carries out and pays attention to usability tests, and the usability tests said that's what people did to turn off their computer.
You haven't actually used Linux, have you? Linux is and has been for several years *much* easier to use than MS-windows.
I use both extensively, and I disagree that Linux is easier -- for almost everything, they're about the same. Each has its own quirks. You give a list of a bunch of things that Linux does a little better, but I could easily give just as many similar things that Windows does better -- both from a beginner point of view and my own.
I agree with the other poster who responded: if you're used to one of the systems, the other will look much harder for beginners, because everything with the one that you use makes sense to you.
(My other take is that there are a few things that I think are far harder on Linux (installing software with non-root is one of them; I have yet to see a package manager that actually deals with this well, so the only way I know how to do this most of the time is to go through 'configure && make && make install' after dealing with the dependency hell that make package managers such an essential part of Linux) but are less likely to be important to beginners.)
Ah, didn't realize that. To be fair, I did also check the SD1000 page, which is the camera I've had for two years now, and it also doesn't have that information, nor do I see a detailed review of it, nor do I remember there being one when I was in the market.
Their reviews of non-DSLRs are a bit spotty -- you're definitely not guaranteed to find one for the camera you're looking at. (Though you will be able to find one in the same family around the right time.)
I'm not saying that you shouldn't go look at dpreview or something like that (I used them heavily for both my cameras); I'm just saying that there is rather a bit of value to actually trying the thing yourself too.
Interesting that I did it in both Circuit City and Best Buy before buying my camera then. Not everything worked, but most things will. Cameras nowadays will usually even let you take a picture without a memory card, and display it to you, so you can at least see what you would have gotten.
You need to go to better stores -- and considering that that's in comparison to Circuit City and Best Buy, that says a lot.
Slashdot Mirror
The actor who stars in the show is pronounced Cole-bert.
If this is true, it's not just The Colbert Report where he's pronounced it that way. That goes back to his Daily Show days; indeed even before Jon Stewart arrived on the scene, Craig Kilborn introduced him as "Cole-bare." I've also always heard him introduced on other shows the same way.
In other words, [citation needed].
Make a typo, or try to do something that LaTeX doesn't like (there are many things that fall in this category) and try to decipher the error message -- 9 times out of 10, it's several pages long and offers absolutely no hint as to what the actual error was.
Oh, be fair. The error is intelligible at least half the time. ;-)
I'm being sort of tongue-in-cheek, but this is a big problem. Errors for simple things like most command typos are fine, but the error detection in more difficult cases leaves a ton to be desired.
I also like how I know tons of people who use Latex, but I don't know any of them use the actual interface Latex provides for dealing with errors; I usually just type 'q' a couple times until it's gone away and go look in the editor.
All word is doing is embedding some image, and generally any program that generates that image can also save it to a file.
The convenience factor of having it embedded shouldn't be underestimated though; it has the same general benefits of WYSIWYG editors in general, which is that you don't have to rebuild stuff to see what the effect is.
Also, the ability to macroize things (i.e. type \rlcn{} for really long chemical name) makes life much easier and less error prone to typos.
You can do something similar in Word though... just set up an autocorrect from rlcn to "really long chemical name". The main difference is you should be more careful about picking something you don't actually want to appear in-text at all.
(using some version control software called RCS)
What other people have said. If you make me use RCS, I'm probably going to wind up killing you. CVS is bad enough.
There's a lot to recommend Latex, and it wouldn't be unreasonable. That said, I have a hard time saying, for sure, yes. It probably depends on personal preference.
I'm a bit of a typography snob, so I like the things that Latex does that I don't know how to get Word to do. For instance, when typing in Word, when the line gets too long, it wraps. In Latex, the line breaks are not inserted by such a simple algorithm; perhaps breaking this line a little earlier will prevent a nasty break later. For more even more snobby examples, see here.
Another of Latex's benefits is its programmability; this will sometimes come in handy. If you look at the diversity of the Latex packages out there, it should become apparent what benefits this can have. It also means that it's a bit more complex.
Latex will do stuff like automatic table of contents too. For citations, there is Bibtex. I haven't used Zotero, but it's at least better than the experience I had of using a really old version of EndNote. Bibtex works pretty slick: you just put ~\cite{some-key} into your document, and it will look through the Bibtex database, find the reference marked {some-key}, put it into your bibliography, automatically number/name everything in the bibliography (using one of any number of styles), and insert the citation into the text of your document.
Finally, the fact that Latex works really well with version control because you can get reasonable diffs is almost a killer feature for me.
At the same time, I've also found that getting Latex to do stuff it wasn't built to do can often be a pain.
Also, if what you're doing is table-heavy, I might recommend you stay away; if you've ever hand-programmed in HTML and had to do tables and found it really annoying, you'll have the same problems with Latex.
Basically what it boils down to is that I think that Latex would be a reasonable choice for you, but I can't say with any certainty that it'd be a better choice than Word, or that Word would be better than Latex.
You can do a diff with an external program that deals with intraline in a less retarded way. ;-)
I'm actually not sure what there is available for running from the command line (though 'svn diff --diff-cmd' will let you run something other than 'diff', if you can find a command-line replacement), but a lot of SVN graphical front ends also have a graphical diff program, many of which will do this better. (They'll usually highlight the whole line, but then word-by-word changes in a darker shade of red/green.)
Also very awesome is latex-diff. This takes two versions of a document, and marks changes in it using latex markup. You then pass the result through latex, and the result is a PDF that looks like what you get from an old version of Word or (current version of; this is one area it's far behind Word) Open Office Writer with track changes on.
Usually when people blather about "secret undocumented Windows APIs" they're ranting about MS keeping the good stuff for themselves. That's just not the case anymore.
Oh, I agree with that.
Actually, I've heard that back in the days when other MS products were using the at-the-time undocumented interfaces (which I assume means the Native API), when the Windows team heard about it, they were livid because that interface is not supposed to be targeted so they can change it without breaking stuff.
Because the kernel varies from machine to machine, no one writes against the kernel.
Oh, I forgot to reply to this before. Malware sometimes does. After all, it doesn't have to run everywhere it tries, just a lot of the time.
I think you mean "Win32", as that's the library most user-mode systems guys program against.
"Win32" hasn't been the official name for a while, and it's now called the Windows API. (After all, it also works on 64-bit builds of Windows.) See the second sentence on Wikipedia.
I don't know why people keep imagining all these "undocumented" interfaces. Microsoft lost all those lawsuits long ago, and everything is documented (though sometimes crapily, as with anything).
I'm not as convinced I'm right, but I'm still seeing some evidence. For instance, there are several functions on an old Sysinternals page on the Native API that I can't find documentation of (either under the Nt* name, Zw* name, or Ke* name), such as NtCreateSemaphore. undocumented.ntinternals.com has a bunch that I can't find on MSDN. Still, I'm willing to concede I might be wrong on this point, and merely say that until relatively recently (even in terms of the history of NT), it was undocumented.
Your post would make more sense if you didn't say "Windows API". There are multiple system libraries in Windows (multiple ways to get kernel functionality from user-mode programs). Win32, WOW16, WOW64, POSIX compatibility layer, OS/2 compatibility layer, and maybe others.
But only one thing that's actually called "the Windows API"; the Win32 and 64 subsystem and WOW subsystems implement it (and all implement it the same with respect to what I'm talking about).
This isn't a "hole" or an "undocumented interface", it's an entirely different system library.
I would argue it is a hole, because writing a program that will be able to properly detect virus or whatnot in files "hidden" by the Windows subsystems (i.e. Win32/64, WOW) case insensitivity becomes non-trivial. You either need to use native system calls (and thus an undocumented interface) or write part of your component to use document calls in a subsystem that DOES provide access to these files -- to my knowledge, this is only the POSIX subsystem/SFU/SUA/Interix/whatever you want to call it. Since you can't mix your uses of the subsystems, this means that your program now needs to be split in two parts, one that runs in the Windows subsystem and provides the UI, and one that runs in the POSIX subsystem and does the actual scanning. Oh, and you can't use a lot of the Windows API calls in that part. Oh, and no one writing security software actually does this, because they don't want to make people install SFU. This means that, based on what I know, either current security software will miss such files or they are making calls to the undocumented system call interface. (Given the syscall hooking and such that a lot of security software does, I know which one I would guess.)
Of course we got our POSIX ACLs and security labels.
By my understanding, doing something as simple as saving a file in Emacs will kill any ACLs associated with it. It definitely will kill other extended attributes associated with the file. Am I wrong on this?
I third that one; I have a pair of Grado SR-125 headphones and they're brilliant. Bright, odd to get used to wearing, but brilliant. I want to get a pair of the SR-325i at some point...
I tried the SR-125s, and I liked them a little better, but not $50 better or whatever the difference is. If I used a stereo with a 1/4" plug instead of 3.5mm one I might have gone for it. In any case, that whole line (SR-60/80/125) are really great, highly recommended, and not too expensive.
Then I try it with classical or rock; and realise it might just be that electronic music, already intentionally sounding artificial, survives that process a lot better than most. It's night and day with classical, and God help you if there's harpsichord.
Interesting... classical and rock is basically all I listen to, which may have something to do with the fact that I find the people this article applies to really weird. ;-)
Then I bought a decent $70 set of headphones (Grado Labs, in case anyone cares) to listen with at work and my whole mp3 collection sounds like crap.
I second this. If you listen to a lot of music, good headphones are a godsend, and once you get a set, the differences are much more noticable. (I also second Grados; I have the SR-80s on right now; mdarksbane probably has the SR-60s. Both are way better than anything I've used in the past. I like them more than the Sennheisers I tried on at twice the price of the SR-80s.)
They aren't headphones for jogging or working out at the gym or anything, but they are great for listening to at work.
Memory's not the problem, because read-only pages (like code) can be shared. It's more like just taking the existing memory space and dividing it up into different ones. There might be a little slop because of pages not being complete, but that's at most a couple per process, so even with 50 processes you're looking at 1MB of additional memory.
Of more concern is the increased context switching time, increased TLB misses, etc.
There is no alternative namespace, there are merely alternate streams in a file - named locations for storing meta data. The file is right there in the filesystem, obvious to all. The file data may be a bit hidden, requiring normal Windows system calls to read (just like one uses normal Windows system calls to create alernate data streams), instead of Notepad. Oh, wait, you can read them with Notepad too. What a bunch of FUD.
This... is actually not the whole story.
NTFS is actually a case-sensitive file system. You can illustrate this by installing Services for Unix. This is an alternative subsystem that doesn't go through the normal Windows API (or the DLLs implementing it) and collection of Unix programs that have been "ported" to it. Once you install this, programs that are part of SFU are able to create files with the same case-sensitive name but different case.
Instead, the reason you normally can't do this is because the DLLs that are part of the Windows subsystem (the one providing the normal Windows API) hides this case-sensitivity in concert with the file system driver. (IIRC, open commands in the driver get a flag saying whether to be case-sensitive or not.) Instead of making calls through the Windows API, you can either use another subsystem like SFU or make native system calls directly (though that interface isn't supported).
Finally, the implementation of the Windows API is such that if you create two files with different case but the same name, only one will be visible through the Windows API, at least with NTFS's implementation of all of this.
This means that if you want to write security software for Windows, to catch malware written by people who know about this hole, you need to make API calls to an undocumented interface if you don't want to require people to install SFU. (Of course, security software does so much other stuff that's even worse that's hardly a drop in the bucket.)
It's always interesting when long-time Windows users experiment with Linux for the first time. You'll see some tech writer blog about this every few months; sometimes they are a bit boring, but I always learn something from watching a Linux newbie try things out for the first time.
I'm pretty interested in usability, so I also find them interesting.
I just got done reading your blog and posted a couple comments (MS Paint & Crop, "I hate Office", and "Options"). They tend to be defensive of Windows, both because I am generally disposed to that anyway and because your posts are almost all negative. ;-)
1. Power point! nuff said
PPT is easily heads and shoulders above where OpenOffice is, and for 98% of presentaitons, above where anything but maybe keynote is. (I haven't used keynote, but it does make very nice presentations.) The only realistic option for most presentations that would be better than PPT is to forgo anything from a computer, and in many situations that's not very realistic.
(For math-heavy ones, Latex Beamer is also an option. Without the math-heavy though, I don't think it's as good.)
Another excuse why windows is better than linux, you mentioned 3 Microsoft products, you don't want to leave.
He also gave reasons for why he doesn't want to, especially for #1. Personally, I think your post is indicative of the worst part of the culture sometimes seen with Linux people, which is refusing to see places where Office or Windows or whatever still does things better.
Windows users have a mental model of computers which is Windows-specific...
Calling it Windows-specific I think is a bit of a misnomer, even if it was caused by Windows. I'm a heavy Linux user (posting from a tiling WM under RHEL if that gives me any cred on that point) and even I agree with some of these points.
For instance, 2: "Reading is for web pages, not system configuration". I like the fact that I can just browse around a GUI for options and see what's available rather than read a man page or whatever to figure out what you can configure. Sometimes packages are nice enough to give you a default conf file with a bunch of options commented out (basically putting the documentation in comments), and that's a nice analogy in the text world, but not all packages do this and even ones that do often don't put everything into it.
I like the fact that if I have a GUI I can look and have high assurance that I can explore around and find things -- usually there won't be options that are hidden. (Not always true. The default shutdown dialog in Win XP has options to log out, shut down, and stand by or something like that, but you can also press 'h' to hibernate. I'm not actually sure how to hibernate without this feature actually! Office 2007 allows you to use keyboard shortcuts from previous versions, but doesn't provide any affordances for it.) About the only exploration you can do with a command line program is type --help after it and see what happens; you basically have to read the man page.
I was only responding to the specific apps listed by the GP which are all well supported by CrossOver. CS3 and CS4 don't yet have support...
Oxymoronic much?
(The post you responded to only mentioned "Photoshop", not a specific version of it. Hence it's not correct to say "Photoshop is well-supported".)
Out of curiosity, do you know if most Windows applications also remove your personal preferences from the hidden directories in your home folder?
Not in general.
There are a ton of good reasons (on any platform) why you probably don't want to do this, and a few for why you would. I tend to think that the former reasons are more compelling, so I think programs get it right.
One place to manage applications, one place to manage updates, and one place to manage packages.
What's the difference between an application and a package? Hell, I'm a geek posting this from RHEL running a tiling window manager (totally the way to go BTW) and have a few gigs of applications on this computer I've installed with the 'configure && make && make install' sequence, and even I am not really sure what the answer is. I mean, I know what I would say if someone asked me and it's I think a good answer, but if I go by those definitions I'm not sure what the GUI to manage applications would be.
Furthermore, why should the update manager be separate? After all, presumably it's managing updates to packages in the end, so why should that be separate from the package manager?
"Why would I click on 'Start' to shut down?"
Because Microsoft actually carries out and pays attention to usability tests, and the usability tests said that's what people did to turn off their computer.
You haven't actually used Linux, have you? Linux is and has been for several years *much* easier to use than MS-windows.
I use both extensively, and I disagree that Linux is easier -- for almost everything, they're about the same. Each has its own quirks. You give a list of a bunch of things that Linux does a little better, but I could easily give just as many similar things that Windows does better -- both from a beginner point of view and my own.
I agree with the other poster who responded: if you're used to one of the systems, the other will look much harder for beginners, because everything with the one that you use makes sense to you.
(My other take is that there are a few things that I think are far harder on Linux (installing software with non-root is one of them; I have yet to see a package manager that actually deals with this well, so the only way I know how to do this most of the time is to go through 'configure && make && make install' after dealing with the dependency hell that make package managers such an essential part of Linux) but are less likely to be important to beginners.)
Who knows, it hasn't been released yet.
Ah, didn't realize that. To be fair, I did also check the SD1000 page, which is the camera I've had for two years now, and it also doesn't have that information, nor do I see a detailed review of it, nor do I remember there being one when I was in the market.
Their reviews of non-DSLRs are a bit spotty -- you're definitely not guaranteed to find one for the camera you're looking at. (Though you will be able to find one in the same family around the right time.)
I'm not saying that you shouldn't go look at dpreview or something like that (I used them heavily for both my cameras); I'm just saying that there is rather a bit of value to actually trying the thing yourself too.
Interesting that I did it in both Circuit City and Best Buy before buying my camera then. Not everything worked, but most things will. Cameras nowadays will usually even let you take a picture without a memory card, and display it to you, so you can at least see what you would have gotten.
You need to go to better stores -- and considering that that's in comparison to Circuit City and Best Buy, that says a lot.