Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
Because it does much less than Explorer does, and can do. Remember that the internal infrastructure can slow down things, at the expense of getting more stuff done (or being extensible, which ROX isn't).
>>>>>>>
Not explorer circa WinNT 4.0. Besides, there are tons of GTK+ apps that have comparable features to Windows ones and are just as fast. (Sylpheed and GIMP come to mind).
Ah, yes, but the underlying libs that "most Windows apps" depend on do. Much of the win32 api is kept in kernel space rather than user space. This is similiar to classic MacOS as well, with all Mac toolbox functions kept in the core OS. In the case of winXX, this includes GDI, parts of COM,
>>>>>>>>>>
A) Running in kernel space does not automatically make something faster. The reason that graphics in the kernel are often faster isn't because its in userspace (because a totally-userspace GUI would be the fastest of all, since kernel calls are slower than regular function calls) but because userspace GUIs usually have to run in a seperate address space to protect window manager data. When global data (such as a window list) isn't involved (which is most things in a UI), kernel space is no benifet. For most applications, running in kernel space really doesn't gain much of a speed benifet. Besides, the components that DO run in kernel space are often seperate processes (in Windows NT) and they have the IPC overhead. For example, to create a new process, the kernel is called to do some initialization, then a notification message is sent to the Win32 server. Win2K really has some performance-sapping uglyness in the design, and "tight integration" is not a design feature.
B) Most of Windows' libraries do *not* run in kernel space. Please read an OS book that covers Windows NT. Most of Windows is in a series of userspace DLLs. The only major part of Windows that runs in kernel space that doesn't do so on a UNIX system is the GDI. And since X is just as fast as the GDI, there goes that excuse.
Mozilla is quite a bit faster on Windows than Linux. It's as fast as explorer in turbo mode, for example.
>>>>>>>
Except its not. I've just downloaded it on a 750MHz Duron and its MUCH less zippy than IE.
This is done in a variety of environments. It's nothing new. KDE does it with XML-GUI. Gnome does it with libglade. Windows does it with.rc files. I beleive MacOSX also does it in special files in bundles.
>>>>>>>.
Windows.rc files are not straight text. They're binary packaged. Besides,.rc files don't store packaged GUIs, they simply store resources like bitmaps and icons.
Again, power versus speed.
>>>>>>>
But useless power is of no worth. CORBA might be powerful, but almost nobody can take advantage of it (when was the last time a desktop user needed to access remote objects?) COM, on the other hand, isn't as good for remote usage, but for local usage (the "common case") its faster. Also, power isn't always needed. Read some of Tannebaum's work. He points out that at some point, somebody has to say "no" to features. They should ask the question "would anything bad happen if we left this out?" Besides, features do not have an inverse relationship with speed. Case in point: the Linux kernel. Its got tons of features (its threading model, in particular, is really cool) but its really fast.
Both run quite zippy enough here.
>>>>>>>
Not over here. Of course, everyone has a different sense of "zippy." Some people consider GNOME zippy. Then there are normal people. Of course, it boils down to the fact that Windows 2000 is faster than either of them. That's the embarrasing part. These desktop environments are like American cars. Full of useless features and get their asses whooped by European models that are faster (and have nifty features too!)
Out of personal information, I can tell you that XP in fact, IS much slower than win2k on the same machine. It is certainly in mine!
>>>>>>>
Turn of Luna, since that skin really makes the comparison unfair. Its like using GTK+ (or Qt) with a pixmap theme!
Yes, but that is minor versions. If you take major versions into account, you see that this is not the case.
>>>>>>>
You were argueing that the early 3.x releases might be faster than 2.x, but later ones won't be. I was pointing out that later versions of the 2.x series were faster than the original.
Almost everyone I know that uses Photoshop can tell you that Photoshop was much faster in certain tasks than Photoshop 5.x and 6.x. That's why there are still many Photoshop 4.x users left.
>>>>>>>>
Use it here everyday. Some new (and useful!) features are slower, but the core stuff is still the same.
> 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Yes, but say a new version of 3d studio came out with 25% new features. It'd be certainly slower. However, people would move on to faster comps.
>>>>>>>>
First, new features do not `*necessarily* make something slower. Its just an excuse made by lazy programmers. You add a whole bunch of tools to an image editor, it shouldn't get any slower. Sure, if you add a fundemental new abstraction, things slow down, but can you honestly say that KDE or GNOME have so many new cool things to warrent their speed hits compared to Windows 2000?
It's not that bad! I track the XFS tree, so I tend to compile the kernel every few pre-patches (this is a personal workstation, so it doesn't matter). It takes 15 minutes to do the compile, as long as you keep your config files around. Quite painless, really.
Re:Mozilla (slightly OT too)
on
GTK-- vs. QT
·
· Score: 2
You know what I meant. Besides, if you make proper programs that are nicely split up into multiple shared libraries (or you have a good compiler that does incremental compiles), then you only have to compile the interface portion when it changes.
Re:Mozilla (slightly OT too)
on
GTK-- vs. QT
·
· Score: 1, Troll
Great. We'll have more slow, bloated apps that don't look native. No compilation step? Who CARES! You only compile it once! You're users have to deal with your shit mistakes every time they use the damn program!
Yes, but that's because Microsoft can do optimizations in the core OS.
>>>>>>>>>
And the KDE guys can't? They have the source to everything, it should be even easier!
In fact, this is a pretty sane argument. Don't bother to say something is slow unless you have modern hardware. It just makes people laugh at you. It's like all of the 386 users who bitched at win95 being slow on their boxes. comeon, it's the natural evolution of software.
>>>>>>
Except that Win95 was slower because it had tons of new features. Win2K matches KDE feature for feature, but KDE is slower, even though it is running on a better kernel/display layer (yes, XFree86 is faster than GDI these days, with good drivers). Are you telling me that there's nothing wrong with that?
That logic is total bullshit. There is absolutely no coorelation between faster applications being able to do more complex things.
>>>>>>>>
????? If my 3D modeler is faster, I can work on more complex models before the system becomes too slow to be comfortably usable. If my display layer is faster, I can make more complex graphics at an acceptable frame-rate. If my desktop is faster, I can have more windows open and switch between them quicker. Even if I upgrade to new hardware, the faster system will STILL be better.
Heh, people have been getting faster computers in order to run the "newest versions of software" forever.
>>>>>>>>
Under the Micro$haft regime. I thought OSS was supposed to be new and different! I honestly don't mind spending the cycles when I get features in return. But when I switched from Windows to Linux (which I did because I couldn't stand Windows anymore, even though it is a higher-quality OS) I lost features *and* speed. That leaves a sour taste in one's mouth.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
Yes, because it has tighter integration with the core of the OS. You really can't beat that easily.
>>>>>>>>>
Then how do you explain the fact that ROX is as fast as Explorer? XFree 4.x is *not* slower than Windows/GDI. In fact, for many things, like image blitting, its as fast as DirectX. Also, the integration thing is overblown. Most Windows apps run quickly, and you can't tell me that they all have tight integration with the core OS! Its just that Linux desktops have too many performance sapping paradigms. Take, for example, XUL. Parsing a text file to display a GUI? Are you insane! Then the use of CORBA instead of something nice and fast like COM. There are lots of KDE/GNOME features that make computer nerds cream, but do nothing except sap the performance of users' machines.
WinXP has *some* things that are faster than Win2k, but there are plenty of reviews out there that say that WinXP is actually slower than Win2k. I've noticed this myself. To be fair to WinXP, it adds things like being skinnable, which makes it naturally slower than Win2k.
>>>>>>>>>>>
I don't think so. Most of the reviews I've seen that say XP is slower are pased on the Release Candidates. XP sped up a *lot* between the those and the gold release.
That was said between KDE 1.x and KDE 2.x too. It may have been true initially, but probably will not be true later on. I don't think KDE 3.3 will be faster than KDE 2.3.
>>>>>>>>>
But KDE 2.2.x is *faster* than KDE 2.0.x! That's the KDE develoment model. Big features, then incremental quality improvements.
Nope.. evolution of all software almost always goes down in speed. this is offset by faster computers. win3.1 > win95 > win98 > win2k > winXP in speed. Whatever Microsoft has in store for the future will be slower than winXP.
>>>>>>>>>
Its really not like that all the time. There are tons of programs that don't keep getting slower. Photoshop, for example, has been pretty much the same since 4.x. 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Actually, there are several places where C++, properly used, can be much nicer than C. Take, for example, the standard Linux linked list code. When moving from entry to entry, the code uses the offsetof() macro to explicitly find the location of the "next" and "prev" pointers within an object. Templates could be used instead to make the code nicer. Actually, templates are great of generic data structures of all kinds. Instead of using callbacks (for comparison functions, for example) one can use an expression template and allow the compiler to adapt each instance to the data structure being used. This is not only more maintainable, but *faster*, since the comparison function can be inlined into the instance. Then there are all of the places (like the VFS) where a table of function pointers is explicitly initialized with callbacks. Instead, you could simply use an abstract base class for the interface and put the callbacks into the implementation.
Or maybe just about his linker? (I don't think he uses the standard Linux ld).
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
Actually, KDE 3.x will be faster than 2.x, according to the developers anyway. Also, its not GNOME vs KDE here. I am talking GTK+ vs KDE. If you don't run an actual GNOME desktop, GNOME apps whip KDE apps speedwise. Just go download Sylpheed and compare it to KMail. If you can't tell the difference, then you have infinate amounts of patience.
There should be no corrolation between age and CPU usage, only between features and CPU usage. Win2K might be older, but it has just as many features while being faster. That implies that the free software community cannot outcode Microsoft (which, I think, I something that they would rather not imply). Also, WinXP, while having more features than Win2K, is *faster* than Win2K. Why is it that the "evolution" of Microsoft software includes increases in speed while the "evolution" of GNOME and KDE don't?
64MB with KDE-2? So I take it that you're dead. Because that's the only way anybody could consider KDE-2 running on 64MB of RAM to be snappy. And I bet you thing the lines at the DMV run at lightning speed too?
Re:No speed difference
on
KDE 2.2.2
·
· Score: 3, Insightful
But then Windows (which has just as many features BTW) will be faster too, so KDE will STILL be slow (comparatively). The "buy a faster system" arguement is total bullshit. If the applications are faster, you can do more complex things, no matter what kind of system you have. I buy a faster system to do more of the things I want to do, not feed some stupid desktop environment.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
1) The phony link was/. screwing with my post. The real link is home.mindspring.com/~heliosc/linux_setup.html.
2) I never said anything about GNOME being quicker. GNOME (Nautilus, Evolution, and all that) is hideously slow. gnome-session slows everything down infinately. However, the applications themselves (run on something like IceWM) are fast. Glimmer, for example, is much faster than Kate. Sodipodi is faster than Kontour. AbiWord dialogues respond instantly while KWord dialogues take their sweet time.
3) I also said you should avoid GNOME apps if there are GTK+ counterparts available. Sylpheed, for example, blows KMail out of the water in terms of speed. Skipstone has an edge on Konqueror, and ROX-Filer makes everything else bow down and cringe.
4) GTK+ *is* faster than Qt. Try resizing any KDE program. You'll see a grey boarder before the app resizes its view and draws them in. Most GTK+ apps flicker when being resized, but redraw with much less drama.
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 2
A couple of points:
Actually, i586 optimization tends to run just as fast i686 optimization for most things. i386 optimization is just slightly slower. None of it matters much anyway, since GCC really doesn't optimize very well for x86 anyway (not even GCC 3.x so far, unfortunately)
Second, 32bit access and DMA are really important. Still, there are lots of things one can do to make everything smoother. The preemption patches (with the low-latency patches to break up some long spinlocks) do wonders for response under load. Before using the patches, the mouse cursor would skip in X whenever the disk got accessed, or whenever Galeon rendered a page. Now, I can run a compile in the background and flail the cursor like mad without having it skip. Also, custom compiling your kernel with only the needed options will gain you a couple of points.
As for Gentoo, its a very nice system. However, compiling programs all the time becomes a pain. If only they updated their binary packages more often. They're also the only Linux distro that has guys with any asthetic. Check out the graphics on www.gentoo.org and compare them to the cheesy purple icons in Mandrake...
Re:This is excellent news
on
KDE 2.2.2
·
· Score: 5, Insightful
I doubt KDE 2.2.2 will be *that* much better than 2.2.1. Certainly not enough to bridge the gap between KDE and Win2K in terms of performance. Linux, however, does have faster things to offer than KDE. Right now, I'm running IceWM with mostly GTK+ (and the occasional GNOME) applications. GTK+/GNOME seems to be a whole lot faster (on my machine anyway, 300MHz 256MB GeForce2 MX) and more responsive (especially in load time and resizing) than Qt/KDE-2. For example, starting a new Galeon window takes much less time than starting a new Konqueror window. Also, I can resize Sylpheed and AbiWord and Gnumeric without excessive rubber-banding, while KMail, KWord, and KSpread are significantly "springier." None of it is quite Win2K yet, but its almost there. Maybe it's even better on a faster machine.
If you chose to go the Linux/GNOME route, here are several hints:
1) Stay away from GNOME like the plague. Apps that use gnome-libs (like Galeon or Eye of GNOME) are for the most part fine, but actually running gnome-session (with the toolbar and control panel and whatnot) and Sawfish slows everything down enormously. Instead, use a fast window manager (IceWM, Blackbox, Window Maker, or even XFce) and GNOME apps.
2) Choose the GTK+ apps over the gtk+gnome apps. GTK+ apps tend to be more mature and snappier than their gnome counterparts. Specifically, Sylpheed is (IMO) a better mail client than Balsa, and GQView works better than Eye of GNOME. Also, ROX-Filer is the fastest Linux GUI application I have ever seen and you should try it out instead of going with the usual gmc.
3) You really have to tweek your system. Linux doesn't come nearly as well optimized as Windows out of box. Mainly, it boils down to making fonts look nice, making sure that X runs at a priority of -10, and setting up the Linux kernel to use preemption and low-latency patches. I've decided to write a HOWTO for this, it should be up here in a few days.
4) Use a good distro. I like Mandrake 8.x because it lets you install the XFS filesystem from the beginning, its i586 optimized, and its good about keeping packages up to date. Also, its urpmi tool mitigates many (but not all!) of the advantages Debian/APT has over the RPM-based distros. No matter what the distro, go minimalist. Install only the software you need and don't choose the bloated default installs. Also make sure you trim your startup so stuff that you don't need (like sendmail) doesn't get run when you start the computer.
Although the error rate seems rather high (0.2%) for a computer, there are all sorts of things that could be done to combat this. Someone mentioned something about CD-ROM read errors, and I'd like to expand it. On a data CD-ROM, well over half of each CD-ROM sector is used for error correcting code. Thus, CD-ROMs make lots of errors, but they're fixed before they get to the computer. Also, many uses of computers can handle the occasional error. Visualization programs could benifet greatly from the increased speed, and any uncaught errors would simpy be seen as the occasional visual defect. If the error rate is brought down enough (as it would be with good error checking) a human observer wouldn't even notice the rare glitch. Similarly, scientific simulations, which already take into account the somewhat random nature of physics, could deal with simulation errors the same way they deal with instrumentation errors: through repeated trials and finding trends.
But the DX 8.0 and DX 8.1 thing is very unusual. Its the first time such a split has happened in the DirectX world, and it will get resolved soon by Microsoft stepping in and making a proclomation (hey, SOMEONE has to control a standard). There are lots of other things, like vertex management extensions, etc, that are different between NVIDIA and ATI. Developers don't like extensions. Microsoft tried making DX extendible (so they wouldn't have to babysit it so much) and developers shot them down. There are problems with the extension mechanism, and its readily apparent.
Its incredible that the current UNIX file structure actually works. There are so many namespace conflicts that it must be an act of god that keeps it moving. Take, for example,/etc. Tons of different programs park their config files in that one directory. The take every user's root directory. There are so many.this_stupid_program files in their it's ridiculous (plus RPM doesn't remove them). Then take/bin. All these different programs sharing a single namespace. IMO, the evolution of the UNIX filesystem should take several steps:
1) Get rid of the current library structure. All libraries should be explicitly managed by the system. If a program wants a shared library loaded, it has to install it at install time through special APIs. That way the system make several improvements, such as prelocating common libraries so they don't have to be relocated at run time, manage conflicts between libraries, since the information is explicit and not dependent on the filesystem, get rid of the need for ldconfig, and allow more complex security/sharing policies than available with/lib and/usr/lib.
2) Revamp the include file namespace. Include files from so many libraries should NOT be sharing the same namespace. 'include' shouldn't even be part of the standard system, it should be an implementation detail left to compilers.
3) Revamp the configuration system. Again, no more allowing programs to directly access the filesystem. Configuration stuff should go through special APIs (like the Windows registry). Instead of a binary database, however, the registry should be a tree of text (probably XML) config files. This would also fix another problem. It would be much easier to write a unified configuration editor. Since there wouldn't be dozens of config file formats lying around, one could write a program that could read a standard XML format and allow the user to edit it.
4) Revamp application installation. That's the biggest problem with current OSs (even given package management like RPMS). Apps simply don't work right. Removing an RPM, for example, doesn't remove all traces of a program. Upgrading an application with a slightly different one is very difficult. The other day, I was trying to install TexStar's optimized KDE RPMs for Mandrake. Of course, I couldn't use RPM -uvh, since the they have two different tags (3mdk and 2tex). I had to remove the KDE rpms with --nodeps (which makes me cringe each time HOWTO suggests doing it) and install the new ones. Of course, it didn't work right, so I had to uninstall the whole KDE installation, reinstall with the tex RPMs, and reinstall all the apps. Of course, by then I had tons of stale config files lying around.
5) Paths. Paths are a huge problem. Just the very fact that a crashed program dumps core onto whatever happens to be the current directory shows how badly the UNIX hierarchy was thought out (or maybe how much its been streched beyond its original design). First, no programs should depend on explicit pathnames. Everything should go through at least one layer of abstraction. Maybe read paths for the standard config mechanism.
Why is anybody surprised about this? The US government is simply trying to protect citizens. They're using the time-tested and mature method of security through obscurity. If the terrorists have trouble getting information about something, how can they blow it up? Its the same method that made Microsoft products so damn bullet-proof, and it will definatly make the US a safer place to live!
worry about your computer crashing right before you defeat the final boss
>>>>>>>>
Given that you're running through a Windows compatibility layer, you have to worry more on Mandrake than on Windows!
Not on UNIX. On Windows, there are two types of drivers, MiniGL and ICD. MiniGL drivers only support specific functions for specific programs. ICDs implement the whole API. As far as I can see, the only model available under Linux is a full ICD.
The cost of supporting open code is pretty small (you just have to do documentation that you really ought to do to support your own in-house work). Closed source is a PR deal (we got something better than everyone else) or cover for hacks you don't want exposed (the ATI topic here) or a misguided idea it buys security (in some of the security and encryption packages). None make a lot of sense in the long term.
>>>
Not really. These are rather special circumstances. Everyone and their mother knows that ATI's hardware rocks, but ATI's drivers suck ass, and really hold the hardware back. It would be stupid of NVIDIA to open up their drivers and possibly give ATI a competitive advantage this way.
It could still be the limitations of MMX. We're talking an instruction set that conflicts with the basic FPU unit of the processor. I wouldn't be surprised if the speed increases were limited only to special cases where the numbers worked out right.
Slashdot Mirror
Because it does much less than Explorer does, and can do. Remember that the internal infrastructure can slow down things, at the expense of getting more stuff done (or being extensible, which ROX isn't).
.rc files. I beleive MacOSX also does it in special files in bundles.
.rc files are not straight text. They're binary packaged. Besides, .rc files don't store packaged GUIs, they simply store resources like bitmaps and icons.
>>>>>>>
Not explorer circa WinNT 4.0. Besides, there are tons of GTK+ apps that have comparable features to Windows ones and are just as fast. (Sylpheed and GIMP come to mind).
Ah, yes, but the underlying libs that "most Windows apps" depend on do. Much of the win32 api is kept in kernel space rather than user space. This is similiar to classic MacOS as well, with all Mac toolbox functions kept in the core OS. In the case of winXX, this includes GDI, parts of COM,
>>>>>>>>>>
A) Running in kernel space does not automatically make something faster. The reason that graphics in the kernel are often faster isn't because its in userspace (because a totally-userspace GUI would be the fastest of all, since kernel calls are slower than regular function calls) but because userspace GUIs usually have to run in a seperate address space to protect window manager data. When global data (such as a window list) isn't involved (which is most things in a UI), kernel space is no benifet. For most applications, running in kernel space really doesn't gain much of a speed benifet. Besides, the components that DO run in kernel space are often seperate processes (in Windows NT) and they have the IPC overhead. For example, to create a new process, the kernel is called to do some initialization, then a notification message is sent to the Win32 server. Win2K really has some performance-sapping uglyness in the design, and "tight integration" is not a design feature.
B) Most of Windows' libraries do *not* run in kernel space. Please read an OS book that covers Windows NT. Most of Windows is in a series of userspace DLLs. The only major part of Windows that runs in kernel space that doesn't do so on a UNIX system is the GDI. And since X is just as fast as the GDI, there goes that excuse.
Mozilla is quite a bit faster on Windows than Linux. It's as fast as explorer in turbo mode, for example.
>>>>>>>
Except its not. I've just downloaded it on a 750MHz Duron and its MUCH less zippy than IE.
This is done in a variety of environments. It's nothing new. KDE does it with XML-GUI. Gnome does it with libglade. Windows does it with
>>>>>>>.
Windows
Again, power versus speed.
>>>>>>>
But useless power is of no worth. CORBA might be powerful, but almost nobody can take advantage of it (when was the last time a desktop user needed to access remote objects?) COM, on the other hand, isn't as good for remote usage, but for local usage (the "common case") its faster. Also, power isn't always needed. Read some of Tannebaum's work. He points out that at some point, somebody has to say "no" to features. They should ask the question "would anything bad happen if we left this out?" Besides, features do not have an inverse relationship with speed. Case in point: the Linux kernel. Its got tons of features (its threading model, in particular, is really cool) but its really fast.
Both run quite zippy enough here.
>>>>>>>
Not over here. Of course, everyone has a different sense of "zippy." Some people consider GNOME zippy. Then there are normal people. Of course, it boils down to the fact that Windows 2000 is faster than either of them. That's the embarrasing part. These desktop environments are like American cars. Full of useless features and get their asses whooped by European models that are faster (and have nifty features too!)
Out of personal information, I can tell you that XP in fact, IS much slower than win2k on the same machine. It is certainly in mine!
>>>>>>>
Turn of Luna, since that skin really makes the comparison unfair. Its like using GTK+ (or Qt) with a pixmap theme!
Yes, but that is minor versions. If you take major versions into account, you see that this is not the case.
>>>>>>>
You were argueing that the early 3.x releases might be faster than 2.x, but later ones won't be. I was pointing out that later versions of the 2.x series were faster than the original.
Almost everyone I know that uses Photoshop can tell you that Photoshop was much faster in certain tasks than Photoshop 5.x and 6.x. That's why there are still many Photoshop 4.x users left.
>>>>>>>>
Use it here everyday. Some new (and useful!) features are slower, but the core stuff is still the same.
> 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Yes, but say a new version of 3d studio came out with 25% new features. It'd be certainly slower. However, people would move on to faster comps.
>>>>>>>>
First, new features do not `*necessarily* make something slower. Its just an excuse made by lazy programmers. You add a whole bunch of tools to an image editor, it shouldn't get any slower. Sure, if you add a fundemental new abstraction, things slow down, but can you honestly say that KDE or GNOME have so many new cool things to warrent their speed hits compared to Windows 2000?
It's not that bad! I track the XFS tree, so I tend to compile the kernel every few pre-patches (this is a personal workstation, so it doesn't matter). It takes 15 minutes to do the compile, as long as you keep your config files around. Quite painless, really.
You know what I meant. Besides, if you make proper programs that are nicely split up into multiple shared libraries (or you have a good compiler that does incremental compiles), then you only have to compile the interface portion when it changes.
Great. We'll have more slow, bloated apps that don't look native. No compilation step? Who CARES! You only compile it once! You're users have to deal with your shit mistakes every time they use the damn program!
Yes, but that's because Microsoft can do optimizations in the core OS.
>>>>>>>>>
And the KDE guys can't? They have the source to everything, it should be even easier!
In fact, this is a pretty sane argument. Don't bother to say something is slow unless you have modern hardware. It just makes people laugh at you. It's like all of the 386 users who bitched at win95 being slow on their boxes. comeon, it's the natural evolution of software.
>>>>>>
Except that Win95 was slower because it had tons of new features. Win2K matches KDE feature for feature, but KDE is slower, even though it is running on a better kernel/display layer (yes, XFree86 is faster than GDI these days, with good drivers). Are you telling me that there's nothing wrong with that?
That logic is total bullshit. There is absolutely no coorelation between faster applications being able to do more complex things.
>>>>>>>>
????? If my 3D modeler is faster, I can work on more complex models before the system becomes too slow to be comfortably usable. If my display layer is faster, I can make more complex graphics at an acceptable frame-rate. If my desktop is faster, I can have more windows open and switch between them quicker. Even if I upgrade to new hardware, the faster system will STILL be better.
Heh, people have been getting faster computers in order to run the "newest versions of software" forever.
>>>>>>>>
Under the Micro$haft regime. I thought OSS was supposed to be new and different! I honestly don't mind spending the cycles when I get features in return. But when I switched from Windows to Linux (which I did because I couldn't stand Windows anymore, even though it is a higher-quality OS) I lost features *and* speed. That leaves a sour taste in one's mouth.
Yes, because it has tighter integration with the core of the OS. You really can't beat that easily.
>>>>>>>>>
Then how do you explain the fact that ROX is as fast as Explorer? XFree 4.x is *not* slower than Windows/GDI. In fact, for many things, like image blitting, its as fast as DirectX. Also, the integration thing is overblown. Most Windows apps run quickly, and you can't tell me that they all have tight integration with the core OS! Its just that Linux desktops have too many performance sapping paradigms. Take, for example, XUL. Parsing a text file to display a GUI? Are you insane! Then the use of CORBA instead of something nice and fast like COM. There are lots of KDE/GNOME features that make computer nerds cream, but do nothing except sap the performance of users' machines.
WinXP has *some* things that are faster than Win2k, but there are plenty of reviews out there that say that WinXP is actually slower than Win2k. I've noticed this myself. To be fair to WinXP, it adds things like being skinnable, which makes it naturally slower than Win2k.
>>>>>>>>>>>
I don't think so. Most of the reviews I've seen that say XP is slower are pased on the Release Candidates. XP sped up a *lot* between the those and the gold release.
That was said between KDE 1.x and KDE 2.x too. It may have been true initially, but probably will not be true later on. I don't think KDE 3.3 will be faster than KDE 2.3.
>>>>>>>>>
But KDE 2.2.x is *faster* than KDE 2.0.x! That's the KDE develoment model. Big features, then incremental quality improvements.
Nope.. evolution of all software almost always goes down in speed. this is offset by faster computers. win3.1 > win95 > win98 > win2k > winXP in speed. Whatever Microsoft has in store for the future will be slower than winXP.
>>>>>>>>>
Its really not like that all the time. There are tons of programs that don't keep getting slower. Photoshop, for example, has been pretty much the same since 4.x. 3D Studio keeps getting faster. KDE 2.2.x keeps getting faster. It does slow down over time, but the stuff you see in the Linux world is *much* more dramatic than the same in the Windows world.
Actually, there are several places where C++, properly used, can be much nicer than C. Take, for example, the standard Linux linked list code. When moving from entry to entry, the code uses the offsetof() macro to explicitly find the location of the "next" and "prev" pointers within an object. Templates could be used instead to make the code nicer. Actually, templates are great of generic data structures of all kinds. Instead of using callbacks (for comparison functions, for example) one can use an expression template and allow the compiler to adapt each instance to the data structure being used. This is not only more maintainable, but *faster*, since the comparison function can be inlined into the instance. Then there are all of the places (like the VFS) where a table of function pointers is explicitly initialized with callbacks. Instead, you could simply use an abstract base class for the interface and put the callbacks into the implementation.
Or maybe just about his linker? (I don't think he uses the standard Linux ld).
Actually, KDE 3.x will be faster than 2.x, according to the developers anyway. Also, its not GNOME vs KDE here. I am talking GTK+ vs KDE. If you don't run an actual GNOME desktop, GNOME apps whip KDE apps speedwise. Just go download Sylpheed and compare it to KMail. If you can't tell the difference, then you have infinate amounts of patience.
There should be no corrolation between age and CPU usage, only between features and CPU usage. Win2K might be older, but it has just as many features while being faster. That implies that the free software community cannot outcode Microsoft (which, I think, I something that they would rather not imply). Also, WinXP, while having more features than Win2K, is *faster* than Win2K. Why is it that the "evolution" of Microsoft software includes increases in speed while the "evolution" of GNOME and KDE don't?
64MB with KDE-2? So I take it that you're dead. Because that's the only way anybody could consider KDE-2 running on 64MB of RAM to be snappy. And I bet you thing the lines at the DMV run at lightning speed too?
But then Windows (which has just as many features BTW) will be faster too, so KDE will STILL be slow (comparatively). The "buy a faster system" arguement is total bullshit. If the applications are faster, you can do more complex things, no matter what kind of system you have. I buy a faster system to do more of the things I want to do, not feed some stupid desktop environment.
1) The phony link was /. screwing with my post. The real link is home.mindspring.com/~heliosc/linux_setup.html.
2) I never said anything about GNOME being quicker. GNOME (Nautilus, Evolution, and all that) is hideously slow. gnome-session slows everything down infinately. However, the applications themselves (run on something like IceWM) are fast. Glimmer, for example, is much faster than Kate. Sodipodi is faster than Kontour. AbiWord dialogues respond instantly while KWord dialogues take their sweet time.
3) I also said you should avoid GNOME apps if there are GTK+ counterparts available. Sylpheed, for example, blows KMail out of the water in terms of speed. Skipstone has an edge on Konqueror, and ROX-Filer makes everything else bow down and cringe.
4) GTK+ *is* faster than Qt. Try resizing any KDE program. You'll see a grey boarder before the app resizes its view and draws them in. Most GTK+ apps flicker when being resized, but redraw with much less drama.
A couple of points:
Actually, i586 optimization tends to run just as fast i686 optimization for most things. i386 optimization is just slightly slower. None of it matters much anyway, since GCC really doesn't optimize very well for x86 anyway (not even GCC 3.x so far, unfortunately)
Second, 32bit access and DMA are really important. Still, there are lots of things one can do to make everything smoother. The preemption patches (with the low-latency patches to break up some long spinlocks) do wonders for response under load. Before using the patches, the mouse cursor would skip in X whenever the disk got accessed, or whenever Galeon rendered a page. Now, I can run a compile in the background and flail the cursor like mad without having it skip. Also, custom compiling your kernel with only the needed options will gain you a couple of points.
As for Gentoo, its a very nice system. However, compiling programs all the time becomes a pain. If only they updated their binary packages more often. They're also the only Linux distro that has guys with any asthetic. Check out the graphics on www.gentoo.org and compare them to the cheesy purple icons in Mandrake...
I doubt KDE 2.2.2 will be *that* much better than 2.2.1. Certainly not enough to bridge the gap between KDE and Win2K in terms of performance. Linux, however, does have faster things to offer than KDE. Right now, I'm running IceWM with mostly GTK+ (and the occasional GNOME) applications. GTK+/GNOME seems to be a whole lot faster (on my machine anyway, 300MHz 256MB GeForce2 MX) and more responsive (especially in load time and resizing) than Qt/KDE-2. For example, starting a new Galeon window takes much less time than starting a new Konqueror window. Also, I can resize Sylpheed and AbiWord and Gnumeric without excessive rubber-banding, while KMail, KWord, and KSpread are significantly "springier." None of it is quite Win2K yet, but its almost there. Maybe it's even better on a faster machine.
If you chose to go the Linux/GNOME route, here are several hints:
1) Stay away from GNOME like the plague. Apps that use gnome-libs (like Galeon or Eye of GNOME) are for the most part fine, but actually running gnome-session (with the toolbar and control panel and whatnot) and Sawfish slows everything down enormously. Instead, use a fast window manager (IceWM, Blackbox, Window Maker, or even XFce) and GNOME apps.
2) Choose the GTK+ apps over the gtk+gnome apps. GTK+ apps tend to be more mature and snappier than their gnome counterparts. Specifically, Sylpheed is (IMO) a better mail client than Balsa, and GQView works better than Eye of GNOME. Also, ROX-Filer is the fastest Linux GUI application I have ever seen and you should try it out instead of going with the usual gmc.
3) You really have to tweek your system. Linux doesn't come nearly as well optimized as Windows out of box. Mainly, it boils down to making fonts look nice, making sure that X runs at a priority of -10, and setting up the Linux kernel to use preemption and low-latency patches. I've decided to write a HOWTO for this, it should be up here in a few days.
4) Use a good distro. I like Mandrake 8.x because it lets you install the XFS filesystem from the beginning, its i586 optimized, and its good about keeping packages up to date. Also, its urpmi tool mitigates many (but not all!) of the advantages Debian/APT has over the RPM-based distros. No matter what the distro, go minimalist. Install only the software you need and don't choose the bloated default installs. Also make sure you trim your startup so stuff that you don't need (like sendmail) doesn't get run when you start the computer.
Although the error rate seems rather high (0.2%) for a computer, there are all sorts of things that could be done to combat this. Someone mentioned something about CD-ROM read errors, and I'd like to expand it. On a data CD-ROM, well over half of each CD-ROM sector is used for error correcting code. Thus, CD-ROMs make lots of errors, but they're fixed before they get to the computer. Also, many uses of computers can handle the occasional error. Visualization programs could benifet greatly from the increased speed, and any uncaught errors would simpy be seen as the occasional visual defect. If the error rate is brought down enough (as it would be with good error checking) a human observer wouldn't even notice the rare glitch. Similarly, scientific simulations, which already take into account the somewhat random nature of physics, could deal with simulation errors the same way they deal with instrumentation errors: through repeated trials and finding trends.
Nobody has asked the important question: Is it themable?
But the DX 8.0 and DX 8.1 thing is very unusual. Its the first time such a split has happened in the DirectX world, and it will get resolved soon by Microsoft stepping in and making a proclomation (hey, SOMEONE has to control a standard). There are lots of other things, like vertex management extensions, etc, that are different between NVIDIA and ATI. Developers don't like extensions. Microsoft tried making DX extendible (so they wouldn't have to babysit it so much) and developers shot them down. There are problems with the extension mechanism, and its readily apparent.
1) Right now, D3D stuff comes out LONG before standardized (ie. not vendor specific*) extensions do.
/. supports OpenGL extensions that are proprietory and lock developers into particular hardware!
2) Who cares what OpenGL runs on. If you're doing consumer level 3D, the x86 is all you have to worry about.
*> I'm so surpised that a GPL obsessed place like
Its incredible that the current UNIX file structure actually works. There are so many namespace conflicts that it must be an act of god that keeps it moving. Take, for example, /etc. Tons of different programs park their config files in that one directory. The take every user's root directory. There are so many .this_stupid_program files in their it's ridiculous (plus RPM doesn't remove them). Then take /bin. All these different programs sharing a single namespace. IMO, the evolution of the UNIX filesystem should take several steps:
/lib and /usr/lib.
1) Get rid of the current library structure. All libraries should be explicitly managed by the system. If a program wants a shared library loaded, it has to install it at install time through special APIs. That way the system make several improvements, such as prelocating common libraries so they don't have to be relocated at run time, manage conflicts between libraries, since the information is explicit and not dependent on the filesystem, get rid of the need for ldconfig, and allow more complex security/sharing policies than available with
2) Revamp the include file namespace. Include files from so many libraries should NOT be sharing the same namespace. 'include' shouldn't even be part of the standard system, it should be an implementation detail left to compilers.
3) Revamp the configuration system. Again, no more allowing programs to directly access the filesystem. Configuration stuff should go through special APIs (like the Windows registry). Instead of a binary database, however, the registry should be a tree of text (probably XML) config files. This would also fix another problem. It would be much easier to write a unified configuration editor. Since there wouldn't be dozens of config file formats lying around, one could write a program that could read a standard XML format and allow the user to edit it.
4) Revamp application installation. That's the biggest problem with current OSs (even given package management like RPMS). Apps simply don't work right. Removing an RPM, for example, doesn't remove all traces of a program. Upgrading an application with a slightly different one is very difficult. The other day, I was trying to install TexStar's optimized KDE RPMs for Mandrake. Of course, I couldn't use RPM -uvh, since the they have two different tags (3mdk and 2tex). I had to remove the KDE rpms with --nodeps (which makes me cringe each time HOWTO suggests doing it) and install the new ones. Of course, it didn't work right, so I had to uninstall the whole KDE installation, reinstall with the tex RPMs, and reinstall all the apps. Of course, by then I had tons of stale config files lying around.
5) Paths. Paths are a huge problem. Just the very fact that a crashed program dumps core onto whatever happens to be the current directory shows how badly the UNIX hierarchy was thought out (or maybe how much its been streched beyond its original design). First, no programs should depend on explicit pathnames. Everything should go through at least one layer of abstraction. Maybe read paths for the standard config mechanism.
Why is anybody surprised about this? The US government is simply trying to protect citizens. They're using the time-tested and mature method of security through obscurity. If the terrorists have trouble getting information about something, how can they blow it up? Its the same method that made Microsoft products so damn bullet-proof, and it will definatly make the US a safer place to live!
worry about your computer crashing right before you defeat the final boss
>>>>>>>>
Given that you're running through a Windows compatibility layer, you have to worry more on Mandrake than on Windows!
Not on UNIX. On Windows, there are two types of drivers, MiniGL and ICD. MiniGL drivers only support specific functions for specific programs. ICDs implement the whole API. As far as I can see, the only model available under Linux is a full ICD.
ATI's drivers are OSS (on Linux anyway) to begin with.
The cost of supporting open code is pretty small (you just have to do documentation that you really ought to do to support your own in-house work). Closed source is a PR deal (we got something better than everyone else) or cover for hacks you don't want exposed (the ATI topic here) or a misguided idea it buys security (in some of the security and encryption packages). None make a lot of sense in the long term.
>>>
Not really. These are rather special circumstances. Everyone and their mother knows that ATI's hardware rocks, but ATI's drivers suck ass, and really hold the hardware back. It would be stupid of NVIDIA to open up their drivers and possibly give ATI a competitive advantage this way.
It could still be the limitations of MMX. We're talking an instruction set that conflicts with the basic FPU unit of the processor. I wouldn't be surprised if the speed increases were limited only to special cases where the numbers worked out right.