Linked by Thom Holwerda on Tue 15th Apr 2008 20:12 UTC, submitted by Craig Barth
Thread beginning with comment 309754
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by asr4096
by sakeniwefu on Tue 15th Apr 2008 22:12
in reply to "RE: Comment by asr4096"
Hopefully Moore's law decline will bring back the great coders from the 80s that used to be able to write a real time 3D game for a monochrome 8bit microcomputer with 64 k of addressable memory.
If people cannot just upgrade to a new computer, fast programs will be profitable again.
Linux, Apple and Microsoft will have to change their ways.
RE[3]: Comment by asr4096
by lemur2 on Wed 16th Apr 2008 00:18
in reply to "RE[2]: Comment by asr4096"
Hopefully Moore's law decline will bring back the great coders from the 80s that used to be able to write a real time 3D game for a monochrome 8bit microcomputer with 64 k of addressable memory.
If people cannot just upgrade to a new computer, fast programs will be profitable again.
Linux, Apple and Microsoft will have to change their ways.
If people cannot just upgrade to a new computer, fast programs will be profitable again.
Linux, Apple and Microsoft will have to change their ways.
Linux is not "one size fits all" unlike OSX and Vista.
Linux runs on mainframes and all the way down to mobile phones, photo frames and even wristwatches.
http://www.freeos.com/articles/3800
http://www.top500.org/charts/list/30/osfam
As for speed and lack of bloat on desktops running current versions of applications:
http://www.puppylinux.org/user/viewpage.php?page_id=1
http://www.zenwalk.org/
RE[3]: Comment by asr4096
by gustl on Thu 17th Apr 2008 19:29
in reply to "RE[2]: Comment by asr4096"
Linux, Apple and Microsoft will have to change their ways.
Small correction: Apple and Microsoft will have to change their ways.
A Debian 4.0 Linux install (current stable release) runs on my 1.2 GHz single processor Athlon (bought cheap in 2003) with 512 MB RAM quite satisfactory.
At my workplace I have to use a Windows XP on a 3GB double Dual Xeon with 3 GHz, which should have approximately 6 to 8 times higher performance. But in reality it "feels" like being only 50% faster. It is easily outdone by a Linux computer which I also can use at work with a dual 2.5GHz P4 setup.
No, Linux already has a different way, and that is: Choose your level of bloat!
You want 3D effects and all the graphical whizbang you can think about? No problem, if you have the machine for it, go for it.
You want to have a decent low-cost Office+Internet machine with limited RAM? Get a stripped down, optimized for speed Distro.
Today I can put myself a quite silent PC together with a processor which has similar speed as a 1 GHz Celeron, 1 GB RAM and a 100 GB Hard disk for as much as EUR 250,- (including Software).
RE[3]: Comment by asr4096
by TemporalBeing on Thu 17th Apr 2008 02:05
in reply to "RE[2]: Comment by asr4096"
Just because something is written in C or assembly doesn't make it fast. One can write crappy and slow C/ASM just like they can write crappy and slow Java code.
True, but one generally has to out of one's way to make C or Assembly code run slow - at least once one gets past the learning curve (but even during the learning curve it can be hard to do so).
Oddly enough:
Case in point: GNOME
:-)
That said, Linux is not immune to the 'bloat' either. In fact, F/OSS can sometimes be worse at bloat because every developer chooses their preferred system to build upon (Qt, KDE, Gtk, WxWidgets, SDL, Motif, X11, to name a few) so you end up with a lot of duplicated effort.
Granted, under Windows you have everyone and their brother providing the same copy of the same library all over the place (b/c of how Microsoft handles library versions - e.g. mfc42.dll, mfc60.dll, mfc71.dll, etc. - or rather, the lack for proper support of it).







Member since:
2007-06-15
Some bloat may be explained by advanced features of certain apps or OS, some may be no optimization in code or concept at all.
Indeed, the "bloat" is universal and not only due to advanced featores or no optimization but often due to frameworks decreasing development time.
Of course everything ran fast when developed in c or assembly, but when you start using java or python or whatever, development costs go down and speed decreases (which is offset by hardware improvements)