3 Mar
2012
3 Mar
'12
2:36 a.m.
Raspberry Pi is the kind of device that can work reasonably with Trinity
but not KDE4. Last time I checked I had Trinity running in 80MB for RAM
while KDE4 was having trouble fitting in 600MB. For people who asked about
reasons to keep KDE3 alive in Trinity, I would point to a working testbed,
if we ever get to assemble one.
Best regards,
Tiago
On Wed, Feb 29, 2012 at 8:24 PM, Timothy Pearson <
kb9vqf(a)pearsoncomputing.net> wrote:
Hello All,
Raspberry Pi is on it's way to being launched and is no available for
preorder. I think this product would be a good candidate for Trinity
and ARM. Raspberry Pi is a $35 arm board.
I am going to order one, any maybe one of you would be interested in
purchasing them as well.
Currently we have ARM builds, but no arm devices have been physically
tested (right?) so I think this could be a opportunity for us to do
that with a very low cost
Calvin
Sounds like a good idea! Load up Debian Squeeze and TDE on it (Wheezy has
massive ARM problems at the moment, gcc crashes and other nastiness) and
see what happens...
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
3 Mar
3 Mar
10:49 a.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Sat, 3 Mar 2012 02:36:00 +0000
Tiago Marques <tiagomnm(a)gmail.com> wrote:
Raspberry Pi is the kind of device that can work
reasonably with
Trinity but not KDE4. Last time I checked I had Trinity running in
80MB for RAM while KDE4 was having trouble fitting in 600MB. For
people who asked about reasons to keep KDE3 alive in Trinity, I would
point to a working testbed, if we ever get to assemble one.
With a sane
configuration KDE SC 4 is not heavy. On my 32-bit Slackware
13.1, I had 200M used by the entire system. After firing up KDE4 from
another console with another user on another X server, I had 340M used,
still by the entire system. The Raspberry Pi having a good GPU and 256M
of RAM, I think KDE SC 4 can run without problem on it.
Best regards,
Tiago
4 Mar
4 Mar
2:36 a.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Sat, Mar 3, 2012 at 10:49 AM, /dev/ammo42 <mickeytintincolle(a)yahoo.fr>wrote;wrote:
On Sat, 3 Mar 2012 02:36:00 +0000
Tiago Marques <tiagomnm(a)gmail.com> wrote:
Not my experience in ANY way. Not even with Nepomuk and other "bloat
disabled". Still, 200MB is a huge amount, you won't be able to run almost
anything else and you won't have 256MB available either, so... tough.
Best regards
Raspberry Pi is the kind of device that can work
reasonably with
Trinity but not KDE4. Last time I checked I had Trinity running in
80MB for RAM while KDE4 was having trouble fitting in 600MB. For
people who asked about reasons to keep KDE3 alive in Trinity, I would
point to a working testbed, if we ever get to assemble one.
With a sane
configuration KDE SC 4 is not heavy. On my 32-bit Slackware
13.1, I had 200M used by the entire system. After firing up KDE4 from
another console with another user on another X server, I had 340M used,
still by the entire system. The Raspberry Pi having a good GPU and 256M
of RAM, I think KDE SC 4 can run without problem on it.
Best regards,
Tiago
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
10:10 a.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Sunday 04 March 2012 02:36:51 Tiago Marques wrote:
http://www.linuxatemyram.com/
You cannot deduce from the amount of RAM used the amount of RAM needed. This
is extremely important for KDE based environments. KDE has a very strong I/O
usage at startup which results in an initial high "RAM usage", but does not
say anything about whether that amount of RAM is actually needed or used. On
my system currently only 280 MB of RAM of my 8 GB of RAM are free.
Long story short: getting correct values for RAM usage on Linux is non-
trivial. I am not able to say how much RAM is really used, but at least I know
that it is non-trivial to get this numbers.
On Sat, Mar 3, 2012 at 10:49 AM, /dev/ammo42
<mickeytintincolle(a)yahoo.fr>wrote;wrote:
On Sat, 3 Mar
2012 02:36:00 +0000
Tiago Marques <tiagomnm(a)gmail.com> wrote:
Not my experience in ANY way. Not even with Nepomuk and other "bloat
disabled". Still, 200MB is a huge amount, you won't be able to run almost
anything else and you won't have 256MB available either, so... tough.
Raspberry Pi is the kind of device that can work
reasonably with
Trinity but not KDE4. Last time I checked I had Trinity running in
80MB for RAM while KDE4 was having trouble fitting in 600MB. For
people who asked about reasons to keep KDE3 alive in Trinity, I would
point to a working testbed, if we ever get to assemble one.
With a sane configuration KDE SC 4 is not heavy. On my 32-bit Slackware
13.1, I had 200M used by the entire system. After firing up KDE4 from
another console with another user on another X server, I had 340M used,
still by the entire system. The Raspberry Pi having a good GPU and 256M
of RAM, I think KDE SC 4 can run without problem on it.
1:03 p.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Sun, 04 Mar 2012 11:10:48 +0100
Martin Gräßlin <mgraesslin(a)kde.org> wrote:
On Sunday 04 March 2012 02:36:51 Tiago Marques wrote:
http://www.linuxatemyram.com/
You cannot deduce from the amount of RAM used the amount of RAM
needed. This is extremely important for KDE based environments. KDE
has a very strong I/O usage at startup which results in an initial
high "RAM usage", but does not say anything about whether that amount
of RAM is actually needed or used. On my system currently only 280 MB
of RAM of my 8 GB of RAM are free.
Long story short: getting correct values for RAM usage on Linux is
non- trivial. I am not able to say how much RAM is really used, but
at least I know that it is non-trivial to get this numbers.
I already know that, that is why my numbers are from the +/-
buffers/cache line.
On Sat, Mar 3, 2012 at 10:49 AM, /dev/ammo42
<mickeytintincolle(a)yahoo.fr>wrote;wrote:
On Sat, 3
Mar 2012 02:36:00 +0000
Tiago Marques <tiagomnm(a)gmail.com> wrote:
Not my experience in ANY way. Not even with Nepomuk and other "bloat
disabled". Still, 200MB is a huge amount, you won't be able to run
almost anything else and you won't have 256MB available either,
so... tough. Raspberry Pi is the kind of device that can work
reasonably with
Trinity but not KDE4. Last time I checked I had Trinity running
in 80MB for RAM while KDE4 was having trouble fitting in 600MB.
For people who asked about reasons to keep KDE3 alive in
Trinity, I would point to a working testbed, if we ever get to
assemble one.
With a sane configuration KDE SC 4 is not heavy. On my 32-bit
Slackware 13.1, I had 200M used by the entire system. After
firing up KDE4 from another console with another user on another
X server, I had 340M used, still by the entire system. The
Raspberry Pi having a good GPU and 256M of RAM, I think KDE SC 4
can run without problem on it.
3 Mar
3 Mar
1:47 p.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Saturday 03 March 2012 02:36:00 Tiago Marques wrote:
Raspberry Pi is the kind of device that can work
reasonably with Trinity
but not KDE4. Last time I checked I had Trinity running in 80MB for RAM
while KDE4 was having trouble fitting in 600MB. For people who asked about
reasons to keep KDE3 alive in Trinity, I would point to a working testbed,
if we ever get to assemble one.
Hi Trinity developers,
it is great that you start to find reasons for Trinity. This is really needed
and can only improve your product.
But please stop comparing to KDE. I have pointed it out before and I say it
again: for a successful Trinity you may not be in competition with KDE.
Finding arguments for the existance of Trinity based on "shortcomings" of KDE
is not the right way. It only makes KDE developers not wanting to have
anything to do with you. And also there is (like in this case) a high risk
that you embarrass yourself.
Now I placed "shortcomings" in quotes. Why? Well because you are pretty bad
informed about the state of KDE and ARM based devices like the Raspberry Pi.
Have a look at for example [1].
What you have to understand is that lightweight hardware and old hardware are
two different type of kinds. While it is reasonable that Trinity works better
on old hardware than KDE the same is not even closely true for lightweight
hardware.
Let's have a look at the application I maintain (KWin) which exists both in
Trinity and in KDE 4. Trinity's answer to compositing is either no compositing
or XRender based compositing. Now hardware like the Raspberry Pi is not meant
for no compositing or XRender. The driver just does not accelerate the
rendering there. So if you use XRender or no compositing everything is
rendered on the CPU. That's quite bad. What the GPU does really good is OpenGL
ES based rendering. That's what KWin 4 uses on such hardware. KWin 4 is
optimized to run well on lightweight modern hardware, but is not optimized for
old hardware which does not provide OpenGL (ES). So this is a nice example to
understand that old != lightweight.
May I ask how much experience the Trinity project has on working well on ARM?
My guess is pretty much none. Do you expect any of your software to be
optimized for ARM? Do you have any software running on ARM? Do you think Qt 3
works as well as Qt 4 on ARM?
Well let's check the facts. Trolltech has been bought by a major mobile
devices company which uses ARM CPUs in all of their products after Qt 4 has
been released (also after KDE 4 has been released). Since then Qt has been
optimized for the usage on ARM. I have here a Maemo (N900), a MeeGo (N950) and
a Symbian 3 (C7) based device which uses Qt as the primary toolkit. Do you
really think Qt 3 is anywhere up to what Qt 4 provides?
Now what about KDE? Did you know that the N9 ships KDE based software on the
default installation? Did you know that there are quite some applications
available in the OVI store (e.g. Marble) and some applications have been
packaged (like Kontact touch)? Did you know that many developers have had ARM
based devices like the PandaBoard for quite some time? Did you know that there
are distributions actually testing that everything of KDE at least compiles on
ARM? Did you know that you can very soon buy an ARM based tablet with KDE
Plasma Active preinstalled? It comes also only with 512 MB of RAM, so no big
difference to the Raspberry Pi.
I have taken the time to write this mail not to upset you, but to show you how
dangerous such statements may be.
Kind Regards
Martin Gräßlin
[1] http://twitpic.com/7dfw5p
4 Mar
4 Mar
2:51 a.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
On Sat, Mar 3, 2012 at 1:47 PM, Martin Gräßlin <mgraesslin(a)kde.org> wrote:
On Saturday 03 March 2012 02:36:00 Tiago Marques
wrote:
As previously discussed, this was more of an argument of: Trinity has a
reason to exist as a fork from KDE3, it has different goals than KDE4. It
makes sense to have a different desktop environment, one that is more
lightweight but still has a lot of functionality that XFCE or LXDE lack.
What I also meant, from my experience, is that there is a class of devices
that cannot handle the memory requirements of modern DEs but can accomodate
Trinity - that doesn't mean competition.
Raspberry Pi is the kind of device that can work
reasonably with Trinity
but not KDE4. Last time I checked I had Trinity running in 80MB for RAM
while KDE4 was having trouble fitting in 600MB. For people who asked
about
reasons to keep KDE3 alive in Trinity, I would
point to a working
testbed,
if we ever get to assemble one.
Hi Trinity
developers,
it is great that you start to find reasons for Trinity. This is really
needed
and can only improve your product.
But please stop comparing to KDE. I have pointed it out before and I say it
again: for a successful Trinity you may not be in competition with KDE.
Finding arguments for the existance of Trinity based on "shortcomings" of
KDE
is not the right way. It only makes KDE developers not wanting to have
anything to do with you. And also there is (like in this case) a high risk
that you embarrass yourself.
Now I placed "shortcomings" in quotes. Why? Well because you are pretty bad
informed about the state of KDE and ARM based devices like the Raspberry
Pi.
Have a look at for example [1].
What you have to understand is that lightweight hardware and old hardware
are
two different type of kinds. While it is reasonable that Trinity works
better
on old hardware than KDE the same is not even closely true for lightweight
hardware.
Let's have a look at the application I maintain (KWin) which exists both in
Trinity and in KDE 4. Trinity's answer to compositing is either no
compositing
or XRender based compositing. Now hardware like the Raspberry Pi is not
meant
for no compositing or XRender. The driver just does not accelerate the
rendering there. So if you use XRender or no compositing everything is
rendered on the CPU. That's quite bad. What the GPU does really good is
OpenGL
ES based rendering. That's what KWin 4 uses on such hardware. KWin 4 is
optimized to run well on lightweight modern hardware, but is not optimized
for
old hardware which does not provide OpenGL (ES). So this is a nice example
to
understand that old != lightweight.
May I ask how much experience the Trinity project has on working well on
ARM?
My guess is pretty much none. Do you expect any of your software to be
optimized for ARM? Do you have any software running on ARM? Do you think
Qt 3
works as well as Qt 4 on ARM?
One expects it, at least, to be compiled with modern compilers that provide
some optimization. Rendering is a whole other issue.
Well let's check the facts. Trolltech has been bought by a major mobile
devices company which uses ARM CPUs in all of their products after Qt 4 has
been released (also after KDE 4 has been released). Since then Qt has been
optimized for the usage on ARM. I have here a Maemo (N900), a MeeGo (N950)
and
a Symbian 3 (C7) based device which uses Qt as the primary toolkit. Do you
really think Qt 3 is anywhere up to what Qt 4 provides?
Now what about KDE? Did you know that the N9 ships KDE based software on
the
default installation? Did you know that there are quite some applications
available in the OVI store (e.g. Marble) and some applications have been
packaged (like Kontact touch)? Did you know that many developers have had
ARM
based devices like the PandaBoard for quite some time? Did you know that
there
are distributions actually testing that everything of KDE at least
compiles on
ARM? Did you know that you can very soon buy an ARM based tablet with KDE
Plasma Active preinstalled? It comes also only with 512 MB of RAM, so no
big
difference to the Raspberry Pi.
It's a 256MB difference. It's double and it's night and day. 512MB
actually
still let's you use a computer nowadays. OLPC had 256MB on the XO-1 and you
couldn't do much with it without having something to use as swap space (and
I tried). I've used computers with XFCE, Gnome 2 and KDE3 with 512MB of RAM
and one could (and still can) do quite a lot with a PC and that much RAM.
I have taken the time to write this mail not to upset you, but to show you
how
dangerous such statements may be.
I appreciate the discussion Martin, especially coming from you. You have to
understand that there are no distros (I've tried a few) that have KDE 4
running in even 200MB quoted on the previous e-mail. I've previously saw
~350MB on Gentoo, stripped down install, and never less than 600MB on
Ubuntu. Gnome 3 and Unity are similar, for whatever reason. That's just a
class of memory usage that's not suited to a lot of devices. If you think
it's possible to go lower, much lower, I'd love to see that in default
installs, as currently RAM usage on Linux desktops is up to Windows
standards and going higher with each passing year, for no apparent reason
to the end-user.
Best regards,
Tiago
Kind Regards
Martin Gräßlin
[1] http://twitpic.com/7dfw5p
1:47 p.m.
New subject: [trinity-devel] ARM and Trinity and Raspberry Pi
I appreciate the discussion Martin, especially coming
from you. You
have to understand that there are no distros (I've tried a few) that
have KDE 4 running in even 200MB quoted on the previous e-mail. I've
previously saw ~350MB on Gentoo, stripped down install, and never
less than 600MB on Ubuntu. Gnome 3 and Unity are similar, for
whatever reason. That's just a class of memory usage that's not
suited to a lot of devices. If you think it's possible to go lower,
much lower, I'd love to see that in default installs, as currently
RAM usage on Linux desktops is up to Windows standards and going
higher with each passing year, for no apparent reason to the end-user.
1) Sorry for
my misleading previous e-mail, the 200MB were for
Trinity+system and the 140 supplemental MBs for KDE4+new X server.
I did the tests again just after having uninstalled gtk+2 for the
purposes of the test (I have some python/gtk2 autostarted applets I
suspected of taking up some significant amounts of RAM):
-On console mode (with Intel KMS) the system takes 110 MB RAM (but it
could be better since I use the "huge" kernel, which is basically a
"make allyesconfig" kernel).
-With just KDE4 started, and a Konsole fired up from the Plasma
desktop, the total memory usage went up to 201 MB: 91 MB for KDE SC
4.4.3 + X server (Nepomuk, strigi and KWin desktop effects not
activated).
-With just Trinity started, and a Konsole fired up from kicker, the
total memory usage (KDE4 was exited) went up from 110 MB to 159 MB: 49
MB for Trinity 3.5.13 + X server.
2) Tiago, do you use x86 or amd64 ? There is a significant increase in
memory usage if you use amd64. The system on which I gave the RAM
measurements has x86 userland and amd64 kernel.
3) +1 for the defaults, I don't consider for example that setting the
Oxygen effects by default at "Very high CPU" is sane.
Best regards,
Tiago
>
> Kind Regards
> Martin Gräßlin
>
> [1] http://twitpic.com/7dfw5p
4708
days inactive
4709
days old
7 comments
3 participants
participants (3)
-
/dev/ammo42 -
Martin Gräßlin -
Tiago Marques