12 Feb
2012
12 Feb
'12
10:35 a.m.
(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.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
12 Feb
12 Feb
11:56 a.m.
New subject: [trinity-devel] Poll
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
12:33 p.m.
New subject: [trinity-devel] Poll
On Sunday 12 February 2012 02:56:08 pm Darrell Anderson wrote:
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 ;-) )
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
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.
1:43 p.m.
New subject: [trinity-devel] Poll
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
1:58 p.m.
New subject: [trinity-devel] Poll
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
2:06 p.m.
New subject: [trinity-devel] Poll
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 ;-)
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
2:16 p.m.
New subject: [trinity-devel] Poll
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
2:21 p.m.
New subject: [trinity-devel] Poll
On Sunday 12 February 2012 04:58:58 pm Timothy Pearson
wrote:
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.
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 ;-)
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
2:22 p.m.
New subject: [trinity-devel] Poll
On Sunday 12
February 2012 04:58:58 pm Timothy Pearson wrote:
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.
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 ;-)
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
2:42 p.m.
New subject: [trinity-devel] Poll
On Feb 12, 2012 5:22 PM, "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net>
wrote:
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
>> 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
2 p.m.
New subject: [trinity-devel] Poll
On Sunday 12 February 2012 04:43:53 pm Darrell Anderson wrote:
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.
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. 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.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
4702
days inactive
4702
days old
10 comments
4 participants
participants (4)
-
Darrell Anderson -
Kristopher Gamrat -
Kristopher John Gamrat
-
Timothy Pearson