LXDE: Resource-Friendly Desktop Environment for X
Linked by Thom Holwerda on Wed 24th Jun 2009 14:10 UTC, submitted by TuxJournal.net
Window Managers We're all pretty much versed in the worlds of GNOME, KDE, and to a lesser degree, Xfce, and while there are lots of alternatives, none of the smaller ones really seem to gain much traction beyond their fans. An exception is LXDE, a small and resource efficient desktop environment.
E-mail Print r 1   · Read More · 45 Comment(s) http://osne.ws/gr7
Thread beginning with comment 370111
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by flynn
by FooBarWidget on Wed 24th Jun 2009 21:55 UTC in reply to "RE[3]: Comment by flynn"
FooBarWidget
Member since:
2005-11-11

And lowered quality, too? I'm just asking politely... :-)


If you define quality as speed, then yes. I define quality as the combination of performance, amount of bugs, number of features, usability and maintenance/development speed. In this case we're trading performance for everything else on the list.

That's the point. Instead of doing as you suggested - anhancing usability and fixing bugs - it seems that it is exactly the opposite: Bigger programs with more functions that don't work properly, more bugs, slower application speed. The loss of broken usability has been explained by my X-Chat example above.


There are exceptions of course. As a counterexample, Pidgin is a lot better than Gaim for Gtk 1.x. I do think that GNOME 2 is better than GNOME 1. As a developer the lack of configuration options felt weird at first, but after a while I came to appreciate the minimalism.

That's an opinion I haven't thought of yet. May I imply further ideas? For developers, it's not needed anymore to know fundamentals of application development, as well as coding skills. :-)


I wouldn't say that. But for example, back in 1990 every programmer *must* know how to do manual memory management. Manual memory management is hard and requires a lot of education and training. Today most programmers don't know how to do manual memory management because we have garbage collectors.
Programmers who know how to do manual memory management are more expensive, but for most applications we don't need these skills.

Only a suggestion: Today, some Linux users complain about things like skipping audio when playing MP3, or too much system startup time. On a 150 MHz Pentium with 64 MB RAM I could burn a CD, download an ISO via FTP, browse the web with Opera (good responding), compiling the system AND playing MP3s without skipping audio. Could it be that this isn't possible anymore? I can't imagine this, but...


I don't know. Back in 1999 my Pentium 166 didn't skip MP3 audio while doing those things, and in the 10 years that I've used Linux I've never ever seen it skip audio. Not on old hardware, not on newer hardware.

I'm guessing that these people have broken hardware or broken drivers. I wouldn't be so quick to call this bloat.

As for system startup time: yes it hasn't improved much. But system startup time is mostly dependent on I/O throughput, i.e. harddisk speed. Harddisks haven't become much faster.

Did you always upgrade your software as well? I can make a good comparison because I'm using the same hardware for several years now.


Yes, I always upgrade to the latest distribution at the time.

Edited 2009-06-24 21:58 UTC

Reply Parent Score: 2

RE[5]: Comment by flynn
by Doc Pain on Wed 24th Jun 2009 22:27 in reply to "RE[4]: Comment by flynn"
Doc Pain Member since:
2006-10-08

If you define quality as speed, then yes. I define quality as the combination of performance, amount of bugs, number of features, usability and maintenance/development speed. In this case we're trading performance for everything else on the list.


Well, I apply the same criteria.

There are exceptions of course.


I'm not quite sure about it. Maybe the feelings of the average users tend to be that way. As a counter-example, see what I wrote about the removed accessibility aspects of X-Chat.

As a counterexample, Pidgin is a lot better than Gaim for Gtk 1.x.


Complete agree.

I do think that GNOME 2 is better than GNOME 1. As a developer the lack of configuration options felt weird at first, but after a while I came to appreciate the minimalism.


It's not that "minimalism" is always bad. Especially Gnome's concept - that's why the quotes - is interesting: The more complicated a setting is, the more impact is has on the system, the more it is "hidden".

But for example, back in 1990 every programmer *must* know how to do manual memory management. Manual memory management is hard and requires a lot of education and training. Today most programmers don't know how to do manual memory management because we have garbage collectors.


Only those who create garbage need to collect it. :-)

No, seriously: Today, there are even programmers who do not know what memory is.

Things lige GC are a very good help to keep things "tidy". Of course, they add certain overhead, but there's a definite benefit from it. I always speak out about overhead that does NOT add any benefit.

Programmers who know how to do manual memory management are more expensive, but for most applications we don't need these skills.


Still, there are fields where such skills are needed, either at implementation level (coding) or for testing purposes when things don't work as expected (debugging) - and the desired tools for this task fail.

I don't know. Back in 1999 my Pentium 166 didn't skip MP3 audio while doing those things, and in the 10 years that I've used Linux I've never ever seen it skip audio. Not on old hardware, not on newer hardware.

I'm guessing that these people have broken hardware or broken drivers. I wouldn't be so quick to call this bloat.


I didn't do so, because I am aware that there can be several reasons. But as a Linux user you surely know that, not matter what's the real reason, first of all the OS is blamed, and the OS is identical with the desktop environment. :-)

As for system startup time: yes it hasn't improved much. But system startup time is mostly dependent on I/O throughput, i.e. harddisk speed. Harddisks haven't become much faster.


It's not that I don't care much about boot time because this is only performed once. But I noticed that with every major upgrade of FreeBSD, it booted faster - on the same hardware. It's not that I want to start every service that exists. :-)

Reply Parent Score: 2

RE[6]: Comment by flynn
by FooBarWidget on Wed 24th Jun 2009 22:39 in reply to "RE[5]: Comment by flynn"
FooBarWidget Member since:
2005-11-11

Still, there are fields where such skills are needed, either at implementation level (coding) or for testing purposes when things don't work as expected (debugging) - and the desired tools for this task fail.


Of course. I wouldn't hire those people for hacking kernel-level stuff. But these people can still get a lot of good work done. For example there are many excellent Ruby on Rails developers who have never written a line of C and don't know how to do manual memory management, but they do write great web applications.

It's not that I don't care much about boot time because this is only performed once. But I noticed that with every major upgrade of FreeBSD, it booted faster - on the same hardware. It's not that I want to start every service that exists. :-)


Yes I'm not surprised that FreeBSD boots faster. FreeBSD is very much a server-oriented and "conservative" operating system. It expects the end user to configure a lot of things manually. Desktop Linux distributions on the other hand try to set up as many things for you as possible. I wouldn't use FreeBSD as a desktop because it takes too much time to get the graphical environment right, whereas on Linux the graphical environment usually works out of the box, assuming that your hardware is supported.

Reply Parent Score: 2

Read more of this thread... >
RE[5]: Comment by flynn
by OSGuy on Thu 25th Jun 2009 07:14 in reply to "RE[4]: Comment by flynn"
OSGuy Member since:
2006-01-01

I wouldn't say that. But for example, back in 1990 every programmer *must* know how to do manual memory management. Manual memory management is hard and requires a lot of education and training. Today most programmers don't know how to do manual memory management because we have garbage collectors.
Programmers who know how to do manual memory management are more expensive, but for most applications we don't need these skills.

What exactly is hard in manual memory management? You just need to keep track of every object you create. You delete it when you are done with it. I always allocate the objects I need within classes and in the class' destructor, I delete them if they are not NULL.

Edited 2009-06-25 07:18 UTC

Reply Parent Score: 2

RE[6]: Comment by flynn
by FooBarWidget on Thu 25th Jun 2009 08:21 in reply to "RE[5]: Comment by flynn"
FooBarWidget Member since:
2005-11-11

What exactly is hard in manual memory management? You just need to keep track of every object you create. You delete it when you are done with it. I always allocate the objects I need within classes and in the class' destructor, I delete them if they are not NULL.


You really make it sound easier than it is. It's very easy to forget destroying an object. Sometimes the life time of an object is hard to determine, and if you specified the conditions under which the object must be freed incorrectly then it can very easily lead to memory corruption. Manual memory management is hard for most apps larger than hello world.

Even something like manual reference counting is easy to get wrong. Witness the tons of iPhone developers who came from PHP and must now suddenly write Objective C code. Many of these apps leak memory because these developers don't correctly reference count their objects.

Edited 2009-06-25 08:27 UTC

Reply Parent Score: 2