On 08/21/2011 09:31 AM, todd rme wrote:
On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu k...@rusu.info wrote:
On 08/20/2011 02:11 PM, Oswald Buddenhagen wrote:
A cross-desktop specification, but we still use kwallet. There's no reason
to
dump it in favour of another implementation. So I see
On Friday 19 August 2011, Scott Kitterman wrote:
On Monday, August 15, 2011 05:31:26 PM Alexander Neundorf wrote:
5) Required cmake version
David noted that we (KDE) are very conservative with the required CMake
version, i.e. we still depend on CMake
On Sunday 21 August 2011, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote:
What instability? If kded crashes, what makes you think individual
services
won't crash, in addition to taking longer to load and use more memory?
look at it from the
On Saturday 20 August 2011, Thiago Macieira wrote:
On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
On Tue, Aug 16, 2011 at 08:58:02PM +0200, Thiago Macieira wrote:
frameworks (qt-based), applications and workspace, that sounds pretty
much what the KDE Platform is.
On Sat, Aug 20, 2011 at 02:43:49PM +0200, Thiago Macieira wrote:
On Saturday, 20 de August de 2011 14:11:32 Oswald Buddenhagen wrote:
yeah, at the cost of rather considerable instability.
we should see whether regular service activation isn't the better
option, now that we have it.
What
On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote:
What instability? If kded crashes, what makes you think individual
services
won't crash, in addition to taking longer to load and use more memory?
look at it from the perspective of the daemon, not the modules.
there have
On Sun, Aug 21, 2011 at 11:28:02AM +0200, Thiago Macieira wrote:
Sure, if each of 10 modules has a certain chance of failure or MTBF, the
whole
process has a much greater chance of failure or smaller MTBF. But if you look
from the point of view from the system that requires each of those
On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote:
yes, when the faulty module crashes. not so when it deadlocks or
busy-loops. also, a restart typically loses state.
True, but I don't remember that happening a single time to me in the past 3
years. I remember seeing people
On Saturday 20 Aug 2011 13:11:32 Oswald Buddenhagen wrote:
On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
It needs a global spec too, since global shortcut grabbing with X11 libs
only is sorely lacking. I think the solution we made for KDE 4 is
actually quite good. Anyone
A Diumenge, 21 d'agost de 2011, John Layt vàreu escriure:
On Saturday 20 Aug 2011 13:11:32 Oswald Buddenhagen wrote:
On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
It needs a global spec too, since global shortcut grabbing with X11
libs only is sorely lacking. I think
On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote:
yes, when the faulty module crashes. not so when it deadlocks or
busy-loops. also, a restart typically loses state.
True, but I don't remember that happening
On Saturday 20 Aug 2011 10:14:20 Oswald Buddenhagen wrote:
On Tue, Aug 16, 2011 at 08:00:19PM +0100, John Layt wrote:
I've certainly seen him state that he doesn't care about KDE, that we are
irrelevent to anything he does, and he sees no reason to collaborate on
anything with us.
and
On Sunday 21 August 2011 Aug, Oswald Buddenhagen wrote:
On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote:
yes, when the faulty module crashes. not so when it deadlocks or
busy-loops. also, a restart
On Sunday, 21 de August de 2011 16:40:32 Oswald Buddenhagen wrote:
If there is, you return QString::fromRawData.
uhm, no, you must make a deep copy, otherwise you get a time bomb.
but yeah, no conversion, so pretty cheap.
You can also use a QStringData with a regular refcount and just watch
On Sun, Aug 21, 2011 at 05:23:14PM +0200, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 16:40:32 Oswald Buddenhagen wrote:
If there is, you return QString::fromRawData.
uhm, no, you must make a deep copy, otherwise you get a time bomb.
You can also use a QStringData with a
On Sunday, 21 de August de 2011 17:46:22 Oswald Buddenhagen wrote:
but maps become invalid when the underlying data changes. in fact, it
would seem that reads must be locked out while a write is in progress.
By design it is.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
On Sunday, 21 de August de 2011 17:30:39 Oswald Buddenhagen wrote:
That sounds very much like the GnomeOS idea...
yes, it does. i'm fully sold on that idea. if kde is ever going to have
any globally significant market share (*), then as applications and
possibly an alternative shell - on
[: Thiago Macieira :]
I once wrote a benchmark comparing iterating over a QString to iterating
over a gchar UTF-8 string using glib functions to get each UCS-4 character
(ostensibly to prove that UTF-16 was better than UTF-8). The result was
clear: Qt code was much faster, over 10x, compared
On Sun, Aug 21, 2011 at 06:26:19PM +0200, Chusslove Illich wrote:
Also, with library being native C++, can there be any problem with C
bindings?
once upon a time, there were (maybe still are, i dunno) more or less
full c bindings for qt and kde, and they even served as a base for
bindings to
On Sunday, 21 de August de 2011 18:26:19 Chusslove Illich wrote:
Do you perhaps still have that benchmark code? Do you have (or know of)
The code exists, but I don't have it. It's part of the QCharIterator work I
did while at Nokia but never published, so I don't have rights to that code
On Sun, Aug 21, 2011 at 06:15:53PM +0200, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 17:30:39 Oswald Buddenhagen wrote:
if kde is ever going to have
any globally significant market share (*), then as applications and
possibly an alternative shell - on top of gnome os.
(*)
if we start from an all-privileged daemon like systemd. It's privilege
elevation that suffers.
does the session systemd run privileged in the first place?
I have no clue. I don't even know if there's a session systemd.
I'm not sure exactly how you people are planning to make use of
On Sun, Aug 21, 2011 at 11:28 AM, Thiago Macieira thi...@kde.org wrote:
On Sunday, 21 de August de 2011 10:19:26 Oswald Buddenhagen wrote:
if we start from an all-privileged daemon like systemd. It's privilege
elevation that suffers.
does the session systemd run privileged in the first
On Sun, Aug 21, 2011 at 08:32:07PM +0200, Thiago Macieira wrote:
On Sunday, 21 de August de 2011 19:13:43 Oswald Buddenhagen wrote:
Considering the audience and considering that KDE has more deployments
than GNOME, why can't it be the other way around?
this is where we started from.
On Monday, 22 de August de 2011 00:07:54 Oswald Buddenhagen wrote:
kio and kparts, just like qstyles and some other plugin systems we have
are not really part of the os platform. as far as the user is
concerned, only the settings which govern network behavior, widget
looks, etc. and the url
On Tue, Aug 16, 2011 at 08:58:02PM +0200, Thiago Macieira wrote:
frameworks (qt-based), applications and workspace, that sounds pretty much
what the KDE Platform is. What are you excluding in your definition?
kded, klauncher, kdeinit, kglobalaccel, kwallet?
yes, among other things.
kded's
On Tue, Aug 16, 2011 at 08:00:19PM +0100, John Layt wrote:
On Tuesday 16 Aug 2011 15:55:57 Oswald Buddenhagen wrote:
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote:
So you are going to let a guy that has stated publicly that hates KDE
where has he done that? and i
On Wed, Aug 17, 2011 at 11:03:44AM +0200, Aaron J. Seigo wrote:
Ossi's email demonstrates an utter lack of understanding on his part
as to what kdelibs is.
errrm ... right. i hope you had enough time now to rethink that
statement. ;)
we do not control all (or even most) of the
Linux OS
On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
On Tue, Aug 16, 2011 at 08:58:02PM +0200, Thiago Macieira wrote:
frameworks (qt-based), applications and workspace, that sounds pretty much
what the KDE Platform is. What are you excluding in your definition?
kded,
On Saturday 20 August 2011 12:20:55 Thiago Macieira wrote:
That I agree: klauncher is systemd for KDE only, so we should see about
getting the same benefits from systemd instead.
There are two drawbacks with that, though:
1) systemd will not likely ever run on non-Linux systems, not even
On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
kded's module activation is redundant with systemd.
But not at all the same impact. Starting an application and negotiating its
connection to D-Bus is
On Saturday, 20 de August de 2011 14:11:32 Oswald Buddenhagen wrote:
On Sat, Aug 20, 2011 at 12:20:55PM +0200, Thiago Macieira wrote:
On Saturday, 20 de August de 2011 10:02:31 Oswald Buddenhagen wrote:
kded's module activation is redundant with systemd.
But not at all the same impact.
On Wednesday 17 August 2011 07:11:21 henry7...@gmail.com wrote:
Very interesting, but it appears to assume all the world is linux x86 (these
days probably x86-64, but the such VMs wouldn't run on any 32 bit machines
that might be left). Many of our big problems are things that work fine
there,
On Thursday 18 August 2011 09:14:09 Volker Krause wrote:
We of course also want coverage of different hardware architectures and OS,
but that basically requires individual setups, and each of those requires
someone to maintain it. If you have access to such systems, running
automated builds on
On Monday, August 15, 2011 05:31:26 PM Alexander Neundorf wrote:
5) Required cmake version
David noted that we (KDE) are very conservative with the required CMake
version, i.e. we still depend on CMake 2.6.4, which is more than a year
old. Me (Alex) noted
On Monday 15 August 2011 23:31:26 Alexander Neundorf wrote:
-
8) Testing
-
We shortly discussed testing, continuous builds and nightly builds.
I hope Volker (or somebody) can write a better summary.
Volker has
On Wednesday, 17 de August de 2011 08:59:43 Simon Hausmann wrote:
On Tuesday, August 16, 2011 09:05:53 PM ext Thiago Macieira wrote:
On Tuesday, 16 de August de 2011 20:53:45 Alexander Neundorf wrote:
Your main function will contain an absolute, non-relocatable address to a
variable in the
On Tuesday, August 16, 2011 09:05:53 PM ext Thiago Macieira wrote:
On Tuesday, 16 de August de 2011 20:53:45 Alexander Neundorf wrote:
However, it's still not perfectly correct: the issue is the difference
between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that
this ELF
On Tuesday, August 16, 2011 20:58:02 Thiago Macieira wrote:
frameworks (qt-based), applications and workspace, that sounds pretty
muchwhat the KDE Platform is. What are you excluding in your definition?
indeed; Ossi's email demonstrates an utter lack of understanding on his part
as to what
Hi,
On Wed, 17 Aug 2011, Thiago Macieira wrote:
Can you think of any other example where PIE would differ from PIC?
One idea is that variables are moved and the compiler uses a simpler,
32-bit PC-relative relocation to access them, as opposed to a 64-bit
indirect as would be expected.
On Tuesday, 16 de August de 2011 22:56:06 Laszlo Papp wrote:
Also: we need to be sure that prelinkers do prelink PIE, despite the
article that Laszlo linked to.
1) prelink tries very very hard to skip PIE
2) ld.so ignores prelink information for PIE anyways so even if you
force a PIE
Very interesting, but it appears to assume all the world is linux x86 (these
days probably x86-64, but the such VMs wouldn't run on any 32 bit machines that
might be left). Many of our big problems are things that work fine there, but
months latter someone gets around to doing that config on:
Hi,
last week at Desktop Summit we had a KDE buildsystem BoF, where we discussed
the state of our buildsystem with regard to Qt5 and the KDE frameworks
modularization efforts.
The nice thing is it seems there is a small community building up around this
topic :-)
Attendees were: Marco Martin,
On Monday, 15 de August de 2011 23:31:26 Alexander Neundorf wrote:
-
7) (Getting rid of) kdeinit
-
There was a discussion about what makes a KDE application different from a
non-KDE application. One thing is
On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote:
In my opinion, kdeinit should stay.
try to convince lennart of that. when i suggested to add kdeinit-like
functionality to systemd his response was no way. and if we ignore
systemd, we'll lose in the longer run.
the selinux guys
Hi,
kdeinit can be replaced by prelinking, assuming you are not a user of the
NVidia binary drivers. If you are, you can't prelink, so kdeinit is a help:
/usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared
library /usr/lib/nvidia-current/libGL.so.1
The nvidia driver
On Monday 15 August 2011 Aug, Alexander Neundorf wrote:
Me (Alex) argued
that most of the stuff in these macros adds only convenience for (lazy) KDE
developers, and will probably not be accepted.
Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of
all the KDE
There was an article by Jakub explaining this. I can not seem to find it
right now.
Found! :) The first one: http://lwn.net/Articles/190495/
Why PIE should not be prelinked and in general about the main purpose of PIE.
btw, why cannot non-pic libs be prelinked? works for non-pie executables,
On Tuesday, 16 de August de 2011 12:50:47 Laszlo Papp wrote:
Hi,
kdeinit can be replaced by prelinking, assuming you are not a user of the
NVidia binary drivers. If you are, you can't prelink, so kdeinit is a
help:
/usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC
On Tuesday, 16 de August de 2011 13:16:44 Laszlo Papp wrote:
btw, why cannot non-pic libs be prelinked? works for non-pie executables,
after all.
Well, by definition, non-pic libraries cannot be prelinked since the
symbols are at fixed addresses. You can not change the symbols using
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote:
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote:
In my opinion, kdeinit should stay.
try to convince lennart of that. when i suggested to
Boudewijn Rempt wrote:
Lazy is good... When doing a pure Qt app with CMake, I actually use a copy
of all the KDE cmake extensions :-).
Which do you use? Do you also use them when creating libraries, not just
apps?
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote:
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote:
In my opinion, kdeinit
On Tuesday 16 August 2011 Aug, Stephen Kelly wrote:
Boudewijn Rempt wrote:
Lazy is good... When doing a pure Qt app with CMake, I actually use a copy
of all the KDE cmake extensions :-).
Which do you use? Do you also use them when creating libraries, not just
apps?
Yes, also for
On Tuesday 16 August 2011, Albert Astals Cid wrote:
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote:
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 10:59:18AM
On Monday 15 August 2011 23.31.26 Alexander Neundorf wrote:
[...]
-
8) Testing
-
We shortly discussed testing, continuous builds and nightly builds.
I hope Volker (or somebody) can write a better summary.
On Tuesday 16 August 2011, Thiago Macieira wrote:
...
Another advantage of PIE is that the executable itself is position-
independent, meaning that the code can be shared if more than one instance
is loaded. For single-instance applications, this is not a gain.
The disadvantage of PIE is the
On Tue, Aug 16, 2011 at 07:24:19PM +0200, Alexander Neundorf wrote:
When looking at this statement carefully, applications, the underlying qt-
based frameworks and a workspace is actually pretty much what we do.
we actually do a bit more, and the side threads of the recent
systemsettings
On Tuesday 16 August 2011, Boudewijn Rempt wrote:
On Tuesday 16 August 2011 Aug, Stephen Kelly wrote:
Boudewijn Rempt wrote:
Lazy is good... When doing a pure Qt app with CMake, I actually use a
copy of all the KDE cmake extensions :-).
Which do you use? Do you also use them when
On Tuesday 16 August 2011, Torgny Nyblom wrote:
On Monday 15 August 2011 23.31.26 Alexander Neundorf wrote:
[...]
-
8) Testing
-
We shortly discussed testing, continuous builds and nightly builds.
I
On Tuesday 16 August 2011 19.48.39 Alexander Neundorf wrote:
[...]
There are currently several parties interested in running builds/test.
There is you working on Jenkins, Volker is working on setting up virtual
machines so users can do builds in a seti@home style, and Marcus is trying
to see
On Mon, Aug 15, 2011 at 3:31 PM, Alexander Neundorf neund...@kde.orgwrote:
**
snip
-
7) (Getting rid of) kdeinit
-
There was a discussion about what makes a KDE application different from a
non-KDE
On Tuesday, 16 de August de 2011 19:36:17 Alexander Neundorf wrote:
The idea here was not to get rid of this mechanism completely.
If I understood correctly, with a PIE executable it is possible to dlopen
the executable and call a symbol from it.
This would make it possible to simply create
On Tuesday 16 August 2011, Thiago Macieira wrote:
On Tuesday, 16 de August de 2011 19:36:17 Alexander Neundorf wrote:
The idea here was not to get rid of this mechanism completely.
If I understood correctly, with a PIE executable it is possible to dlopen
the executable and call a symbol
On Tuesday, 16 de August de 2011 16:55:57 Oswald Buddenhagen wrote:
in fact, the pragmatic solution would be dropping the kde platform and
concentrating on what we are good at: applications (and the underlying
qt-based frameworks). and a workspace, for those 50% of our community
who can
On Tuesday 16 Aug 2011 15:55:57 Oswald Buddenhagen wrote:
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote:
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure:
On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote:
In my opinion, kdeinit should
On Tuesday, 16 de August de 2011 20:53:45 Alexander Neundorf wrote:
However, it's still not perfectly correct: the issue is the difference
between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that
this ELF module is the first open loaded,
Sorry, I don't understand that
Also: we need to be sure that prelinkers do prelink PIE, despite the article
that Laszlo linked to.
1) prelink tries very very hard to skip PIE
2) ld.so ignores prelink information for PIE anyways so even if you
force a PIE prelink you don't get anything
There is no point in prelinking PIE
68 matches
Mail list logo
