On Monday, 27 April 2020 03:53:38 PDT Alexander Volkov wrote:
> As for KIO slaves, they are started from processes that are already
> linked with many KDE libraries and there is no
>
> much benefit in starting them from kdeinit.
That's an incorrect conclusion. Your premis
On 04/27/20 12:53, Alexander Volkov wrote:
So, does it still makes sense to use kdeinit?
https://phabricator.kde.org/T12140
Hi,
The documentation https://api.kde.org/frameworks/kinit/html/index.html
states:
"Using kdeinit to launch KDE applications makes starting a typical KDE
applications 2.5 times faster
(100ms instead of 250ms on a P-III 500) It reduces memory consumption by
approx. 350Kb per applic
On Dienstag, 9. Juli 2013 10:51:16 CEST, David Faure wrote:
Then the problem is elsewhere.
Yes, seems. Sorry for the noise.
Compiling kwin as "regular" exec brought no change.
The nvidiahack lib is inoperative for other reasons.
We'll have to find another solution for the issue.
Cheers,
Thoma
n the problem is elsewhere.
Ok.
Let's first establish kdeinit as guilty for sure
By the above assurance, it's not kdeinit - sorry for the noise.
The nvidia blob might as well just have somewhen changed behavior - or ldd
could have or it's because of the hack around the fpic i
- the setenv calls have no
> effect, while setting the environment in the shell clearly works.
> > A gut feeling and brief google consultation make me "blame" the fact that
> > kwin is "now" a kdeinit executable (for a while...)
I don't see the relation. I m
le i'm not sure whether the current process in CMakeLists is actually
> correct, not even LD_PRELOADing the lib works - the setenv calls have no
> effect, while setting the environment in the shell clearly works.
>
> > A gut feeling and brief google consultation make me "blame&q
even LD_PRELOADing the lib works - the setenv calls have no
effect, while setting the environment in the shell clearly works.
A gut feeling and brief google consultation make me "blame" the fact that kwin is
"now" a kdeinit executable (for a while...)
So the question is:
---
On Wed, Sep 14, 2011 at 3:11 PM, Tom Gundersen wrote:
> I couldn't see this, but maybe I missed it. At least you can get the
> cgroup, and then you can look in the "procs" file to get a list of
> pids belonging to the group.
I think you should be fine with traversing the cgroup hierarchy.
Without
Jaroslav Reznik wrote:
> - Original Message -
>> On Sun, Aug 21, 2011 at 4:54 PM, John Layt wrote:
>> > Ummm, Pulse Audio? It completely broke sound under KDE. It caused a
>> > lot of
>> > users a lot of pain before Colin come along to fix it for us and for
>> > Gnome
>> > users too. I do
On Wed, Sep 14, 2011 at 11:13 AM, John Tapsell wrote:
> Regarding integration - for a long time I've been interested in adding
> support to System Activity (ctrl+esc thingy). In Windows, the task
> manager has a tab for both processes and for services, and you can
> switch between the two. So yo
Regarding integration - for a long time I've been interested in adding
support to System Activity (ctrl+esc thingy). In Windows, the task
manager has a tab for both processes and for services, and you can
switch between the two. So you can right click on a process and jump
to its service, and vic
- Original Message -
> On Sun, Aug 21, 2011 at 4:54 PM, John Layt wrote:
> > Ummm, Pulse Audio? It completely broke sound under KDE. It caused a
> > lot of
> > users a lot of pain before Colin come along to fix it for us and for
> > Gnome
> > users too. I don't want to see a repeat of that
On Thursday, August 25, 2011 09:46:51 PM Alex Fiestas wrote:
> Something I'm going to do, and I hope that some of the metalworkers will
> follow is to get involved in the new platform (uStuff, NM, BlueZ...),
> only by winning our relevance we will be able to control the platform
> again.
Good plan
Something I'm going to do, and I hope that some of the metalworkers will
follow is to get involved in the new platform (uStuff, NM, BlueZ...),
only by winning our relevance we will be able to control the platform again.
Also, I'd like to point something: In number of people I think that KDE
ha
On Tue, Aug 23, 2011 at 4:48 PM, Stefan Majewsky
wrote:
>> the only thing that might be interesting is to provide a serviceForSource
>> implementation that allows interacting with a unit, if a user is able to do
>> anything useful (such as activate/deactive a unit?). i'm not sure that's
>> possibl
On Tue, Aug 23, 2011 at 4:48 PM, Stefan Majewsky
wrote:
> I don't see such signals, and this can be a real problem.
Looked again, and there is a single change signal, plus a set of
properties which are invalidated by this signal. Should be enough to
keep the cache sane.
Greetings
Stefan
On Tue, Aug 23, 2011 at 8:10 AM, Aaron J. Seigo wrote:
> is there a way to get notified from systemd when a unit changes activation or
> load state? because those would also be useful in the engine, obviously.
I don't see such signals, and this can be a real problem. libqsystemd
currently impleme
On Sunday, August 21, 2011 17:59:33 Stefan Majewsky wrote:
> unit? There's an proof-of-conceptdataengine in the repo [1], but the subject
> is in need of someone whoknows his way around Plasma dataengines and
once the unitAdded/unitRemoved signals are added to QsdManager, then those can
easily b
> > much what the KDE Platform is. What are you excluding in your
> > > definition?
> > >
> > > kded, klauncher, kdeinit, kglobalaccel, kwallet?
> >
> > yes, among other things.
> >
> > kded's module activation is redundant with system
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
On 08/21/2011 09:31 AM, todd rme wrote:
> On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu 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 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 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 starte
On Sunday, 21 de August de 2011 21:07:05 Alex Merry wrote:
> On 21/08/11 15:23, John Layt wrote:
> > So lets turn that on its head. Lets write a statement saying why we
> > need a spec and what it needs to achieve. Mention we have an existing
> > solution that would be a good starting point, but do
On Sun, Aug 21, 2011 at 5:59 PM, Stefan Majewsky
wrote:
> Once I can get a current version of systemd to
> compile on my machine, I will try to look into this, but of course
> help is appreciated on all fronts.
Feel free to drop by #systemd if you are having trouble with compiling
/ dependencies
On Sun, Aug 21, 2011 at 11:28 AM, Thiago Macieira 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 place?
>
>> > 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
On 21/08/11 15:23, John Layt wrote:
So lets turn that on its head. Lets write a statement saying why we
need a spec and what it needs to achieve. Mention we have an existing
solution that would be a good starting point, but don't actually
detail it. Then send that to xdg and Gnome and Unity and
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. gnome is now serious about making a
> complete platform. if they su
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.
> >
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
anymo
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
> [: 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, compa
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 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.or
On Sun, Aug 21, 2011 at 4:54 PM, John Layt wrote:
> Ummm, Pulse Audio? It completely broke sound under KDE. It caused a lot of
> users a lot of pain before Colin come along to fix it for us and for Gnome
> users too. I don't want to see a repeat of that, so figuring out how to get
> Lennart to
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 w
On Sun, Aug 21, 2011 at 03:54:12PM +0100, John Layt wrote:
> On Saturday 20 Aug 2011 10:14:20 Oswald Buddenhagen wrote:
> > and he's right. show me one case where the outcome of his low-level work
> > did not meet kde requirements.
>
> Ummm, Pulse Audio? It completely broke sound under KDE.
>
it
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 w
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 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.
>
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 happ
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
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.
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 co
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 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.
> th
even
> be a security risk [...]
>
yeah, both of these concern result from systemd being "a bit" more than
kdeinit. they could be mitigated by forking off the actual launcher
process very early, but this may turn out ugly.
> It's far easier to introduce the feature we want
On Sun, Aug 21, 2011 at 12:09 AM, Valentin Rusu 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 no arguments at all in
>>> favour of dropping
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 no arguments at all in
>> favour of dropping it -- in fact, I see more in keeping it.
>>
> ksecretservice
osx has something similar - launchd. it is to be seen whether
> kde could make use of it.
Yup.
> > 2) Lennart is also very much opposed to the fork-no-exec solution that
> > kdeinit and booster use to pre-initialise.
>
> yes, he made it pretty clear to me that he doesn&#x
are simply going to be
even less relevant than they already are.
https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
and the subthreads have all the gory details.
fwiw, macosx has something similar - launchd. it is to be seen whether
kde could make use of it.
> 2) Lennart is
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
your definition?
> >
> > kded, klauncher, kdeinit, kglobalaccel, kwallet?
>
> yes, among other things.
>
> 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 hardly compara
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 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?
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, amo
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 P
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 expect
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 kd
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
> > > th
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 i
> 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 si
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
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:
> &g
> who can believe in that plasma thingie.
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?
--
Thiago Macieira - thiago (AT) macieira.info - thiago
executable and call a symbol from it.
> > This would make it possible to simply create regular-looking, standalone
> > executables instead of the combination of plugin+tiny executable, and at
> > the same time keep the kdeinit instance around, which would then not
> > dlopen t
le to simply create regular-looking, standalone
> executables instead of the combination of plugin+tiny executable, and at
> the same time keep the kdeinit instance around, which would then not
> dlopen the plugin, but dlopen the PIE executable, and call the symbol from
> the PIE execut
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 thr
his one.
Maybe I didn't express clearly what I wanted to say, or I misunderstood Dirk,
or Dirk was wrong.
So, I try again, just to make sure there are no misunderstandings.
Right now, for kdeinit-apps, we create a "kdeinit module" or plugin, which
contains the actual application c
gt; > > 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
> > > > functio
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&
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
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 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/prelin
> 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 executable
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/li
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 lo
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 appl
Hello,
Adding kde-hardware-devel in CC, as that's likely where the authors of that
code are hiding. ;-)
Cheers.
On Friday 29 October 2010 19:48:49 Dawit A wrote:
> Hi,
>
> The upower backend, more specifically the XRandrBrightness class,
> causes kdeinit to crash on my sys
81 matches
Mail list logo
