As far as I have been able to tell, all the Linux GUI's are bottlenecked by the X windows architecture of using TCP/IP to interlink the application with its frame buffer, including GTK/Gnome and KDE. This is pure overhead when both the client and server reside on the same machine and serious framebuffer apps consequently perform like slugs. I use Linux where it is smaller and more efficient than Windows, but the Linux' GUIs just ain't it. If someone can point me to a substitute X client that bypasses the server and talks directly to the framebuffer or something I might be interested, but my tests have shown that OpenGL (for example) on Windows is orders of magnitude faster on Windows than it is on Linux.
If there's something I don't know about the availability of a graphics channel on Linux that holds a candle to Windows (besides svgalib, as everyone seems to be phasing support for that out for reasons that I can only conclude are brain-dead), please let me know and I'll stand corrected.
A lot of folks out there *claim* that my statement isn't true but haven't been able to show any evidence. I'd REALLY like to be proven wrong here...
Sure, graphics over a network is a cute idea, but WAKE UP-- a huge number of people aren't even using it, and we're *all* taking the performance hit for it.
Summary: I think it all depends on the type of programmers and what they are good at on if any methodology works
I think this hits the nail on the head. They've tried this sort of "one-size-fits-all" approach in education in the US, and we all probably know how well that has worked. Someone gets wind of the latest "teaching methods" and then trys to impose the "new" methodology on all the teachers which just pisses off the good ones while the bad ones don't care.
The basic problem is, managers just don't like to manage individuals, they'd prefer to manage things where the individuals involved are treated as faceless "resources." So, instead of managing individual programmers they manage some "representative" aggregate (read: stereotype) which produce (surprise) statistically average results. As long as you treat programmers as "presumed to be" incompetent in some areas and therefore require some imposed structure, that is what you'll get-- but that's not how the best programs are usually produced.
Linux is at least one example of how an anarchy of capable programmers can produce a solid and viable product. Managers get really uncomfortable when they can't keep as close a monitor on what is going on as you can when you impose a universal methodology-- but such techniques are not without costs themselves...
Slashdot Mirror
I don't need a 120G drive, 20G is plenty-- so when can I buy one for $20?... -- Kazoo
As far as I have been able to tell, all the Linux GUI's are bottlenecked by the X windows architecture of using TCP/IP to interlink the application with its frame buffer, including GTK/Gnome and KDE. This is pure overhead when both the client and server reside on the same machine and serious framebuffer apps consequently perform like slugs. I use Linux where it is smaller and more efficient than Windows, but the Linux' GUIs just ain't it. If someone can point me to a substitute X client that bypasses the server and talks directly to the framebuffer or something I might be interested, but my tests have shown that OpenGL (for example) on Windows is orders of magnitude faster on Windows than it is on Linux.
If there's something I don't know about the availability of a graphics channel on Linux that holds a candle to Windows (besides svgalib, as everyone seems to be phasing support for that out for reasons that I can only conclude are brain-dead), please let me know and I'll stand corrected. A lot of folks out there *claim* that my statement isn't true but haven't been able to show any evidence. I'd REALLY like to be proven wrong here...
Sure, graphics over a network is a cute idea, but WAKE UP-- a huge number of people aren't even using it, and we're *all* taking the performance hit for it.
Summary: I think it all depends on the type of programmers and what they are good at on if any methodology works
I think this hits the nail on the head. They've tried this sort of "one-size-fits-all" approach in education in the US, and we all probably know how well that has worked. Someone gets wind of the latest "teaching methods" and then trys to impose the "new" methodology on all the teachers which just pisses off the good ones while the bad ones don't care.
The basic problem is, managers just don't like to manage individuals, they'd prefer to manage things where the individuals involved are treated as faceless "resources." So, instead of managing individual programmers they manage some "representative" aggregate (read: stereotype) which produce (surprise) statistically average results. As long as you treat programmers as "presumed to be" incompetent in some areas and therefore require some imposed structure, that is what you'll get-- but that's not how the best programs are usually produced. Linux is at least one example of how an anarchy of capable programmers can produce a solid and viable product. Managers get really uncomfortable when they can't keep as close a monitor on what is going on as you can when you impose a universal methodology-- but such techniques are not without costs themselves...