(hopefully this posts to the correct thread since it was started before I re-subscribed, I tend to unsubscribe when I'm not able to pay attention to the mailing lists)
I'd probably either keep the latest stable TDE release, or I'd switch back to KDE 3.5 and use that for as long as I can get it to compile on my systems (and I'dmake my own packages). I might even make my own efforts to pick up where it left off once my programming skills were up to par.
Failing that, I'd probably fall back to Fluxbox. It has always been fast and stable on all my systems, and it is extremely difficult to work in unneeded dependencies due to it's minimalistic design/featureset and minimal dependencies (such as when package maintainers pull in GTK libs for KDE3/TDE with no qt-gtk-engine or GNOME stuff for Firefox/Iceweasel).
What I don't like about Fluxbox is the right-click root menu (I prefer that to be from my panel, such as with the KMenu/TMenu), and the lack of extra apps, such as file manager, PIM, etc. Another problem is the lack of icons on the desktop (this one is very minor since I'm rarely working with my desktop, and I can always use fbdesk or the likes). I usually end up using my KDE3/TDE apps from within Fluxbox, however.
My second choise would probably be LXDE. It already includes most of the components that I am used to having, and it (mostly) resembles my default KDE/TDE setup. The downside is that it doesn't include all the apps needed to fully replace my TDE desktop (the first thing that comes to mind PIM, such as email, calendar, and chat). Also, it looks a bit clunky. The default color scheme looks a bit off, as do some of the dialogs (either that, or my eyes just aren't used to the general theming and arrangement).
I guess the main reason I use TDE is for the available apps (everything I need is there, and more), the default theme is easy on the eyes, and I'm obsessed with tweaking.
The primary downside (for me) of TDE when compared to Fluxbox and LXDE is speed -- both Fluxbox and LXDE are faster with the initial loading, and with loading apps when my CPU is under stress; TDE apps are slow loading compared to LXDE when my CPU usage jumps up, but they are both roughly equal under light load. (I can do some testing on this and provide results once I have my new hard disk)
The only other disadvantage of TDE that I can think of is small screens. On a (now considered) small 1024x768 screen, I feel a bit cramped, but it's bearable; LXDE is slightly less cramped, and Fluxbox fits perfectly. Going smaller than that, it barely fits, even with all the tweaking I can do to fit things in. Only Fluxbox would be my choice in this situation (admittedly, I haven't tried LXDE with anything smaller than 1024x768). With netbooks out, this definately needs to be taken into consideration. Unfortunately, I don't use netbooks, so I won't be able to test any changes on smaller screens.
The primary downside (for me) of TDE when compared to Fluxbox and LXDE is speed -- both Fluxbox and LXDE are faster with the initial loading, and with loading apps when my CPU is under stress; TDE apps are slow loading compared to LXDE when my CPU usage jumps up, but they are both roughly equal under light load. (I can do some testing on this and provide results once I have my new hard disk)
Tim, a while ago you asked for recommendations for post R14 goals. I'd like us to address this issue.
There are a few bug reports addressing speed concerns: 258, 283, 693, 699, 731, and 760 for example.
Yet, even in the pre KDE4 days, KDE3 had a reputation for being slow and bloated. Whether fully true or false is not the point because the reputation exists one way or another. I can attest that KDE3 has always been and Trinity is slow on old hardware. I suspect the problem with old hardware is the hard drive and bus speeds.
My own perception is Trinity seems a tad snappier than KDE3, but we probably can improve a lot more. For example, not a fair comparison (apples and oranges), Xfce starts and exits significantly faster than Trinity. I won't compare to window managers because that would be an unfair comparison.
Although Konqueror can be preloaded, my own perception is that the very first launch of any app is slow. Launching certain apps will always be slow but the desktop itself should always be snappy.
I would like to see us address these concerns post R14. Can we add that item to our goals list?
Darrell
On Sunday 12 February 2012 02:56:08 pm Darrell Anderson wrote:
The primary downside (for me) of TDE when compared to Fluxbox and LXDE is speed -- both Fluxbox and LXDE are faster with the initial loading, and with loading apps when my CPU is under stress; TDE apps are slow loading compared to LXDE when my CPU usage jumps up, but they are both roughly equal under light load. (I can do some testing on this and provide results once I have my new hard disk)
Tim, a while ago you asked for recommendations for post R14 goals. I'd like us to address this issue.
There are a few bug reports addressing speed concerns: 258, 283, 693, 699, 731, and 760 for example.
Yet, even in the pre KDE4 days, KDE3 had a reputation for being slow and bloated. Whether fully true or false is not the point because the reputation exists one way or another. I can attest that KDE3 has always been and Trinity is slow on old hardware. I suspect the problem with old hardware is the hard drive and bus speeds.
I remember running KDE3 on "old" hardware, e.g. 256MB RAM and a 1ghz CPU. I've heard people say it works fine on 128MB RAM and 700mhz if you run a minimal install. I doubt many people would be using such hardware, but it's definitely possible and needs consideration.
My best suggestion (this will probably take several releases) is to see how much the code can be trimmed without removing functionality, possibly separate packages further for a sort of "old computer" install -- for example (though I can't say for sure, I personally never checked, don't take my word for it unless one of the devs can confirm), some of the libs from tdelibs probably wouldn't be needed for an absolute barebones system. It may also be good to try to separate functionality where possible.
Needless to say, we don't have to take that to an extreme, otherwise packagers might end up having to build 1,000,000 packages, and download times would slow down since the package manager has to send individual requests for individual packages through the DNS and all the way to the server and wait for individual responses. But definitely something to consider.
(now back to our regularly schedule topic ;-) )
I remember running KDE3 on "old" hardware, e.g. 256MB RAM and a 1ghz CPU. I've heard people say it works fine on 128MB RAM and 700mhz if you run a minimal install. I doubt many people would be using such hardware, but it's definitely possible and needs consideration.
I have used KDE3 on my PI (with a 400 MHZ K6-III+) and PII machines. KDE3 is usable but requires serious patience. Likewise Trinity. On the other hand, NT4 is installed on both machines and run very fast. The PI has 256 MB RAM and the PII 448 MB.
There is a point of diminishing returns with tweaking the code base for older hardware. On the other hand, if people run LXDE or Xfce on such hardware then there will be unavoidable comparisons. Even if we draw a line with older hardware, I believe we should focus attention on improving performance.
Tim mentioned in a previous thread something called tdeinit_phase1 that eventually will improve the Trinity start time. That's good news. :)
My best suggestion (this will probably take several releases) is to see how much the code can be trimmed without removing functionality, possibly separate packages further for a sort of "old computer" install -- for example (though I can't say for sure, I personally never checked, don't take my word for it unless one of the devs can confirm), some of the libs from tdelibs probably wouldn't be needed for an absolute barebones system. It may also be good to try to separate functionality where possible.
There probably are places we can trim code. For example, do we want to continue supporting Cervisia, which is a KDE specific wrapper to CVS? I don't know.
Your comments run close to what I proposed a while ago: Trinity Light. The focus there is primarily knowledge about build issues. People using older hardware probably would not install tdesdk let alone build the package. Trinity Light likely would not include that package or at most, only as an optional package.
Older hardware more than likely are standalone home or small-office machines. If we had a wiki page addressing such build issues we could offer a Trinity Light without sacrificing developer time toward tweaking code. All we need is information and then let packagers handle the details. Trinity Light is not something we support officially. That is, we don't provide the packages, we provide the information needed to build Trinity Light. We probably post to our web site that the basic Trinity installation runs best with hardware of PIII or faster and 512 MB RAM. For people wanting a lighter version we refer them to the build instructions at the wiki.
The wiki page would address which build options could be removed and why. For example, building tdepim without sasl support builds a leaner package and theoretically faster KMail, but probably is a bad idea because that mechanism is how secure email logins are handled.
My PI and PII qualify as old hardware and would serve as great test environments for running Trinity Light. :)
Darrell
I remember running KDE3 on "old" hardware, e.g. 256MB RAM and a 1ghz CPU. I've heard people say it works fine on 128MB RAM and 700mhz if you run a minimal install. I doubt many people would be using such hardware, but it's definitely possible and needs consideration.
I have used KDE3 on my PI (with a 400 MHZ K6-III+) and PII machines. KDE3 is usable but requires serious patience. Likewise Trinity. On the other hand, NT4 is installed on both machines and run very fast. The PI has 256 MB RAM and the PII 448 MB.
There is a point of diminishing returns with tweaking the code base for older hardware. On the other hand, if people run LXDE or Xfce on such hardware then there will be unavoidable comparisons. Even if we draw a line with older hardware, I believe we should focus attention on improving performance.
Tim mentioned in a previous thread something called tdeinit_phase1 that eventually will improve the Trinity start time. That's good news. :)
My best suggestion (this will probably take several releases) is to see how much the code can be trimmed without removing functionality, possibly separate packages further for a sort of "old computer" install -- for example (though I can't say for sure, I personally never checked, don't take my word for it unless one of the devs can confirm), some of the libs from tdelibs probably wouldn't be needed for an absolute barebones system. It may also be good to try to separate functionality where possible.
There probably are places we can trim code. For example, do we want to continue supporting Cervisia, which is a KDE specific wrapper to CVS? I don't know.
Your comments run close to what I proposed a while ago: Trinity Light. The focus there is primarily knowledge about build issues. People using older hardware probably would not install tdesdk let alone build the package. Trinity Light likely would not include that package or at most, only as an optional package.
Older hardware more than likely are standalone home or small-office machines. If we had a wiki page addressing such build issues we could offer a Trinity Light without sacrificing developer time toward tweaking code. All we need is information and then let packagers handle the details. Trinity Light is not something we support officially. That is, we don't provide the packages, we provide the information needed to build Trinity Light. We probably post to our web site that the basic Trinity installation runs best with hardware of PIII or faster and 512 MB RAM. For people wanting a lighter version we refer them to the build instructions at the wiki.
The wiki page would address which build options could be removed and why. For example, building tdepim without sasl support builds a leaner package and theoretically faster KMail, but probably is a bad idea because that mechanism is how secure email logins are handled.
My PI and PII qualify as old hardware and would serve as great test environments for running Trinity Light. :)
Darrell
Just to jump in here, there is one use case for a lightweight DE that doesn't involve obsolete hardware: multiuser mainframe-type systems. When you have 50 users on one central server, each with a session that is being accessed via a remote desktop protocol such as VNC or even the X protocols, slight reductions in the overhead of each session make a big difference overall.
Just something to think about in these odd times, when the personal computer is being "replaced" with a variant of the old central mainframe model....
Tim
On Sunday 12 February 2012 04:58:58 pm Timothy Pearson wrote:
Just to jump in here, there is one use case for a lightweight DE that doesn't involve obsolete hardware: multiuser mainframe-type systems. When you have 50 users on one central server, each with a session that is being accessed via a remote desktop protocol such as VNC or even the X protocols, slight reductions in the overhead of each session make a big difference overall.
Just something to think about in these odd times, when the personal computer is being "replaced" with a variant of the old central mainframe model....
Tim
Are you talking about cloud computing?
I've been wandering how that would actually work. I mean, if we all get rid of our boot devices and use "the cloud" to boot our computers and run our apps, how would we configure our computers to know what server(s) to boot from? How would TDE tie into that (as in, how will it work being loaded from "the cloud", and how would the TDE desktop environment change as a whole)? I know that's thinking way far in advance as far as TDE goes, but I'm just curious ;-)
Are you talking about cloud computing?
I've been wandering how that would actually work. I mean, if we all get rid of our boot devices and use "the cloud" to boot our computers and run our apps, how would we configure our computers to know what server(s) to boot from? How would TDE tie into that (as in, how will it work being loaded from "the cloud", and how would the TDE desktop environment change as a whole)? I know that's thinking way far in advance as far as TDE goes, but I'm just curious ;-)
I got the impression of terminal servers rather than the cloud. For example, running Trinity in a LTSP (Linux Terminal Server Project) environment.
And probably a good subject to merge into the discussion about optimizing Trinity. :) In fact, optimizing Trinity for an LTSP environment would be a great way to use old PI and PII hardware. Those machines come with 10/100 network support. Trinity could be an ideal desktop for LTSP environments. :)
Darrell
On Sunday 12 February 2012 04:58:58 pm Timothy Pearson wrote:
Just to jump in here, there is one use case for a lightweight DE that doesn't involve obsolete hardware: multiuser mainframe-type systems. When you have 50 users on one central server, each with a session that is being accessed via a remote desktop protocol such as VNC or even the X protocols, slight reductions in the overhead of each session make a big difference overall.
Just something to think about in these odd times, when the personal computer is being "replaced" with a variant of the old central mainframe model....
Tim
Are you talking about cloud computing?
A specific type of cloud computing, yes. Most cloud computing is Web based, but there are a few instances of cloud computing where the entire desktop GUI is handled on the remote server and the client is just an I/O device with a network connection.
I've been wandering how that would actually work. I mean, if we all get rid of our boot devices and use "the cloud" to boot our computers and run our apps, how would we configure our computers to know what server(s) to boot from? How would TDE tie into that (as in, how will it work being loaded from "the cloud", and how would the TDE desktop environment change as a whole)? I know that's thinking way far in advance as far as TDE goes, but I'm just curious ;-)
Remember these?
http://en.wikipedia.org/wiki/Network_Computing_Devices
Make the monitor into a touch flatscreen, update the network conection with WiFi and Gigabit Ethernet, integrate the optional monitor and keyboard into a laptop- or tablet-like device and I think you have where we are going.
Truly scary for developers, content producers, or anyone with data worth stealing, but for the masses it might actually work rather well (and there would be big bucks to be made in providing computing services to these devices).
Just my $0.02. :-)
Tim
On Sunday 12 February 2012 04:58:58 pm Timothy Pearson wrote:
Just to jump in here, there is one use case for a lightweight DE that doesn't involve obsolete hardware: multiuser mainframe-type systems. When you have 50 users on one central server, each with a session that is being accessed via a remote desktop protocol such as VNC or even the X protocols, slight reductions in the overhead of each session make a big difference overall.
Just something to think about in these odd times, when the personal computer is being "replaced" with a variant of the old central mainframe model....
Tim
Are you talking about cloud computing?
A specific type of cloud computing, yes. Most cloud computing is Web based, but there are a few instances of cloud computing where the entire desktop GUI is handled on the remote server and the client is just an I/O device with a network connection.
I've been wandering how that would actually work. I mean, if we all get rid of our boot devices and use "the cloud" to boot our computers and run our apps, how would we configure our computers to know what server(s) to boot from? How would TDE tie into that (as in, how will it work being loaded from "the cloud", and how would the TDE desktop environment change as a whole)? I know that's thinking way far in advance as far as TDE goes, but I'm just curious ;-)
Remember these?
http://en.wikipedia.org/wiki/Network_Computing_Devices
Make the monitor into a touch flatscreen, update the network conection with WiFi and Gigabit Ethernet, integrate the optional monitor and keyboard into a laptop- or tablet-like device and I think you have where we are going.
Truly scary for developers, content producers, or anyone with data worth stealing, but for the masses it might actually work rather well (and there would be big bucks to be made in providing computing services to these devices).
Just my $0.02. :-)
Tim
Whoops--that should obviously read "optional *mouse* and keyboard" above.
Tim
On Feb 12, 2012 5:22 PM, "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
Are you talking about cloud computing?
A specific type of cloud computing, yes. Most cloud computing is Web based, but there are a few instances of cloud computing where the entire desktop GUI is handled on the remote server and the client is just an
I/O
device with a network connection.
I've been wandering how that would actually work. I mean, if we all get rid of our boot devices and use "the cloud" to boot our computers and run our apps, how would we configure our computers to know what server(s)
to
boot from? How would TDE tie into that (as in, how will it work being loaded from "the cloud", and how would the TDE desktop environment change as a whole)? I know that's thinking way far in advance as far as TDE goes, but I'm just curious ;-)
Remember these?
http://en.wikipedia.org/wiki/Network_Computing_Devices
Make the monitor into a touch flatscreen, update the network conection with WiFi and Gigabit Ethernet, integrate the optional monitor and keyboard into a laptop- or tablet-like device and I think you have where we are going.
Truly scary for developers, content producers, or anyone with data worth stealing, but for the masses it might actually work rather well (and
there
would be big bucks to be made in providing computing services to these devices).
Just my $0.02. :-)
Tim
Whoops--that should obviously read "optional *mouse* and keyboard" above.
Tim
That would be a good way to bring in funds :-)
Of course, you would need a more reliable connection, and it might not catch on right away.
-- Kris
On Sunday 12 February 2012 04:43:53 pm Darrell Anderson wrote:
Tim mentioned in a previous thread something called tdeinit_phase1 that eventually will improve the Trinity start time. That's good news. :)
I'd be willing to test. Even on my "semi-new" hardware (~2.4ghz dual core with 4GB RAM), I'm still trying to tweak for performance ;-)
My best suggestion (this will probably take several releases) is to see how much the code can be trimmed without removing functionality, possibly separate packages further for a sort of "old computer" install -- for example (though I can't say for sure, I personally never checked, don't take my word for it unless one of the devs can confirm), some of the libs from tdelibs probably wouldn't be needed for an absolute barebones system. It may also be good to try to separate functionality where possible.
There probably are places we can trim code. For example, do we want to continue supporting Cervisia, which is a KDE specific wrapper to CVS? I don't know.
Most people will want GUI apps for just about everything. When I was still new to Linux, I had actually considered designing a Qt app for the compile process (e.g. configure, make, install). Depends on whether or not there is enough demand for CVS support.
Your comments run close to what I proposed a while ago: Trinity Light. The focus there is primarily knowledge about build issues. People using older hardware probably would not install tdesdk let alone build the package. Trinity Light likely would not include that package or at most, only as an optional package.
tdesdk is optional -- if it isn't needed to operate properly, it's optional. I don't have it installed on my TDE system because I currently have no use for it :-)
Older hardware more than likely are standalone home or small-office machines. If we had a wiki page addressing such build issues we could offer a Trinity Light without sacrificing developer time toward tweaking code. All we need is information and then let packagers handle the details. Trinity Light is not something we support officially. That is, we don't provide the packages, we provide the information needed to build Trinity Light. We probably post to our web site that the basic Trinity installation runs best with hardware of PIII or faster and 512 MB RAM. For people wanting a lighter version we refer them to the build instructions at the wiki.
The wiki page would address which build options could be removed and why. For example, building tdepim without sasl support builds a leaner package and theoretically faster KMail, but probably is a bad idea because that mechanism is how secure email logins are handled.
My PI and PII qualify as old hardware and would serve as great test environments for running Trinity Light. :)
Definitely worth doing IMO. But even doing that, we could still probably trim the code a bit. I'm not talking which features to enable or which packages to install, I'm talking more of going through the code, removing what we don't need, and seeing what we could combine and/or reorganize (and if it would be practical to do so). The more the code can be shrunk without removing functionality or making the code difficult to work with, the smaller the binaries will be (in theory), and smaller binaries mean quicker load time, in theory at least. At a minimum, smaller binaries would (for the most part) mean less to load, which in turn means more RAM free (in general) for other stuff, or to at least more RAM for the loaded binaries to work with. As most anyone would tell you, RAM is generally the biggest factor in determining the speed of your computer (i.e. less swapping, since hard disks are slower than RAM).
I certainly wouldn't expect a small dev team to have made much progress by R14, but if it's doable, it's certainly worth considering.
-
Darrell Anderson -
Kristopher Gamrat -
Kristopher John Gamrat
-
Timothy Pearson