Windows Vista and XP Head To Head
thefickler sends in an article comparing Windows Vista and Windows XP in the areas of security, home entertainment, GUI, parental controls, and networking. The author clearly believes that Vista wins across these categories.
If thats what you need IE for perhaps you should read http://it.slashdot.org/article.pl?sid=06/11/14/143 9215 about FireFox.
Why don't you go out and get laid and quit worrying so much about dumb shit? Honestly, so what if the article has bad grammar. Shut your mouth and don't read it. Now wasn't that difficult?
Erm, what about MOST OF THE FUCKING UNIVERSE, who just wants to play Flash games online, and for whom integrated graphics are JUST FUCKING FINE? Why do we NEED to have more expensive, hotter-running, battery-draining dedicated graphics? Oh, right, because some snobby geek on Slashdot things integrated graphics are the spawn of the Devil himself.
You realize that integrated graphics today are better than the best standalone cards of just a few years ago, right? So, what, NOBODY should have been using computers a few years ago? It is NOT the job of the OS to needlessly soak up hardware for no good reason. Win95/Office97 run about as well on a P233 than WinXP/OfficeXP do on a PC with 10x the CPU.* Sure, there are some nice new features in the newer versions, but enough to negate a 10x speed increase and a decade's worth of advancement? Not in my opinion.
* not just pulling numbers out of my ass--I recently built a machine like that and was amazed at how it compares to the 2.4 GHz Dell on my desk at work.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Yes, I didn't say that OO was poor, I said that it was "poorly used." I meant to imply (and I think I did) that you could write small code in an OO language. And you can write poor code in a non-OO language too, but you don't generally have anywhere near the magnitude of the OPC (other people's code) bloat factor you often have in an OO system. I was just observing that generally speaking, we don't see it nearly as much in C programs. I'm not limiting that assessment to MS, either. Examples: Linux:Openoffice. MS:Office. MS+OSX:Photoshop. OSX:Delicious Library.
Consider these three graphics apps aimed at image manipulation, prepress, art and effects:
45 megs (includes libs,exe,no docs), medium feature count, medium speed. Mixed. Commercial.
15 megs (includes libs, compressed for download, no docs), low feature count, medium speed. C. Collaboration.
4 megs (includes libs,exe, no docs), very high feature count, very high speed. C. Commercial.
I give the gimp some room because with really loose collaboration on a complex project, you're going to lose a lot of potential internal code reuse. It's just difficult for programmer A to know all the cool ins and outs of programmer B's work, and take advantage of them, and vice-versa. The gimp is very slow to start, but runs OK once it is going. Googling it seems to indicate its in C. The gimp is also larger in size because it was developed for Linux, which has no modern GUI -- so you end up downloading the huge GTK widget set so the gimp can have user controls / widgets. This isn't really related to the coding style for the application itself, but then again, you have to have it, so you have to count it.
WinImages, written in C, is by far the leader in features, speed and minimum size. It is so tight because it doesn't use other people's libraries except for just a few (Twain, MNG, JPEG) that have been completely reworked by the coding team, and because with regard to code reuse, the development approach makes sure that once an optimum implementation has been worked out for something (eg, layer re-display or draw mode rendering), everyone has to use that. Extensive code reviews between the programmers result in remarks like "this section is essentially the same as module so-and-so" which have to be addressed (meaning, the code must become shared or decently explained as to why it is not prudent to do that) before the code can ship. And -- ironically -- it is tight because it uses C-based OO for its hundreds of operators, OO that carries no bloat whatsoever because no feature of it is ever unused, overloaded, or redundant. WinImages starts as fast as the OS can load it, which generally, these days, means before you can get your finger off the mouse button the first time, and even faster after that (because of OS executable caching.) Operators (think filters, sort of, only much more flexible) are near-realtime (with the exception of things like full bore ray tracing or real-world simulations like exfoliation), and even the area selections have been tuned to reduce unnecessary UI interactions which means the user gets more done with less UI work... it feels faster because it is more efficient.
Photoshop's size pretty much speaks for itself. Startup time is quite long, operations are medium speed (basically comparable to the gimp, typically 2x-4x slower than winimages) and in terms of major features, again in count it is roughly comparable to the gimp, but far behind winimages. I assume the reason for the oversized executable is not just bad C coding. I suppose it could be, but man... Be interesting to see how big CS3 for the Mac is. That'll come out of an OO development system; they don't have any choice.
The three applications do not have complete overlap -- gimp does some cool and unique things especially in supplied plug-
I've fallen off your lawn, and I can't get up.