A few years ago when I was attending at UDS-M, the Kubuntu guys and I tried to understand why KDE took so long to start, we used bootchart and started debugging startkde & friends, after disabling lots of kded modules and a bunch of stuff we couldn’t get rid of the ~10 seconds marker.
Time has passed and no matter how fast your computer is we still have to wait a lot for KDE to start, is KDE slow? Is Qt Slow? Is C++ slow? All these questionings kept coming to my mind, and well lots of friends ask why is KDE slow to start, after it has started it’s fast. So the other day I decided to try Unity to know if all the FUD were true or not, and I got stunned with a desktop bloated with python scripts and stuff it was much faster than KDE to start, it’s really fast to load, after a few hours trying to use it and not being able to even move the panel to the bottom I gave up and installed Kubuntu again…
I keep seeing Martin (KWin maintainer) blogging about the milliseconds he was able to get rid of, and make KWin startup faster, still I can’t notice it, it’s like there is a 10 seconds timer for KSplash to go away…
So I decided to dissemble it, and created a thing called “sessionk” (yeah like systemd but with a K), the idea behind sessionk was to debug and understand all phases of startup and find who is being slow. The very first code started KWin and plasma but KRunner couldn’t launch anything, so I had to go deeper and deeper till I think now I fully understand what happens today:
- ligthdm launches X, DBus, startkde
- startkde do some X calls (using cmd line tools) to set mouse pointer, RandR
- startkde starts kdeinit with an option to load KCMInit modules (which do pretty much the same as the above, but the code is in KDE modules) – takes around 2 seconds
- kdeinit also auto launches kded which loads KCModules that have phase= 0 or 1
- startkde then starts ksmserver which only returns after the session is closed so startkde script continues and quits killing the X session
- ksmserver now launches the window manager, normally KWin, here is were ksmserver shows it’s age (around 13 years), it has a 4 seconds timer to make sure KWin will have enough time to start so that when the auto start phases start it’s loaded.
- after those 4 seconds ksmserver starts autostart phase 0, 1, 2 at these phases apps like plasma, nepomuk, polkit-kde are loaded
- after all those phases are reportedly to be finished ksmserver restores the user session (if the settings say so) lauching the apps there were open when the user left.
In short our code works but it’s showing it’s age, surelly KWin starts much faster than that, actually it hardly takes more than one second to start.
What needs improvements? Lots of stuff, even without those 4 seconds timer plasma still takes quite a while to load, with Plasma 2 it’s said that it’s starting almost instantly, but you can get that behavior in trade of removing some widgets 😛 another killer is kded4, if I load all the modules before Plasma and KWin, it delays startup by around 2 seconds and makes plasma to freeze a lot…
A suggestion would be to improve ksmserver, so I took a look at the job, and really I don’t feel I can make “safe” changes in it, I mean it’s 13 years old code that WORKS! If I change anything and break it your session is gone, startkde will return and X is closed. A second reason is it’s current license BSD, and I refuse to code using this license (won’t get into the license merit), a third reason is that I want to sessionk to be small with the fewer deps it can have (like removing the shutdown dialog from the main process), the fourth and last reason is that I don’t think ksmserver is doing a good job on restoring sessions, for instance Chromiun always complain that it was closed abruptally, it could be fixed but due to the code license, age and well the code isn’t easy for me to understand I decided to push sessionk a bit further, I might not replace ksmserver/startkde but it will surely show other components of KDE that we have a large room for improvements.
What sessionk does:
- lightdm launches X, DBus, sessionk
- sessionk setups some stuff, including shortcuts (which also have OSX shortcuts due to my Mac keyboard), when the shortcuts are loaded it loads kdeinit because of kglobalaccel
- kdeinit auto loads kded and klauncher (kded is loaded without any modules)
- when klauncher is loaded sessionk starts KWin and Plasma
- sessionk listen for X events to know if a desktop window was created, then it tells KDED to load all modules
- after all kded modules are loaded autostart phases 0, 1, 2 are loaded (which loads, policykit-kde, nepomuk …)
- restore the apps that were open on last session (TODO)
Videos say more than a thousand words…
Looking for code? Be careful as it’s still work in progress and might crash your session…
http://quickgit.kde.org/?p=scratch%2Fdantti%2Fsessionk.git
Have fun!
EDIT : Forgot to thank Kai Uwe Broulik for that awesome plasma zoom in effect 🙂
Dantti's Blog 
KDE 4.10? I have a pretty full desktop, dual monitor and its responsive in under 5 seconds. I am booting from a SSD though.
If the theory is correct here, then with something like sessionk you’ll have everything running in ~2 seconds (your 5 seconds – 4 seconds delay + a second to load what is loading with that delay). It would be nothing short of amazing, BTW.
exactly my thought, this may be an amazing improvement, thanks daniel!
Interesting, when I first skimmed your article I just thought sessionk was a analysis tool, I didn’t realise it was actually speeding startup.
When i get some time (hah!) I’ll give it a spin on my system (Kubuntu 13.04, 64bit).
Yup, KDE 4.10, notice that I have an old MacBook (2008) without SSD, and as Alejandro said in theory you would be up and running in around ~2 seconds I’d say…
Looking forward to a stabler release!
Have you considered discussing it in the kde(-core)-devel mailing list? I think it would be very interesting
Well right now all I have is a half solution, also I want to provide an alternative to our current solution, so we don’t break people’s desktop, once I think it’s good enough to replace something I think we could discuss merging it in ksmserver or using sessionk…
IIRC there was an approach to let systemd do the initialization of all desktop services as it already provides all the infrastructure for proper dependency handling instead of using such beautiful non-deterministic “workarounds” as sleep(4).
Can’t find it anymore right now, but it sounded really interesting and would be IMHO (at least from a engineering point of view) the best approach.
On the other hand, this would make KDE depend upon systemd which is a bad idea when it comes to flexibility and cross-platform support.
But in the end, this could still serve as an inspiration how to approach this issue… systemd is L-GPL 2.1, so maybe we could even borrow some code for the core functionality to handle the session initialization and dependency handling from it?
I like systemd (crossing fingers to see it soon in ubuntu), but it’s Linux only, and not all distros have it, and definetily not all UNIXes.
Another point is that KLauncher launches KDE apps much faster than systemd could, dependency handlying on the desktop should be addressed by DBus imo, what a desktop session should worry is just launch a Window Manager and a Shell, given I only care about KDE sessionk is very KDE specific, tho you can use another shell the rest of the KDE session will also be loaded
Just for the record: https://wiki.archlinux.org/index.php/Systemd/User#Using_systemd_–user_To_Manage_Your_Session 🙂
Depending on how much time I will have, I want to check how KDE could make use of systemd without dropping compatibility for !Linux. Ubuntu, unfortunately, is only switching to logind so far and builds a systemd compatibility layer for it (it looks like they’re building compat-layers for nearly everything :P) – let’s see what happens next.
Well even with systemd one needs UI dialogs for shutdown, an implementation of XSMP which ksmserver has, I really don’t see what advantages would we have with it other than something that get very tied to a specific operating system, but well you know, we can’t stop each other of trying, if you find out it has advantages and we can keep an alternative for !linux and !systemd (as I believe there are some distros that prefrer old bsd style 😛 ) I’ll be +1 😀
That LightDM code you’re using has a 0.4 second delay just to show a fading animation before doing anything. That’s most of the delay between pressing and enter and the cursor changing to a black cross in a “pointless” animation.
Do you have stats on the startup time for each component? It would be really interseting to see.
*thumbs up* David
@dantti: Thanks. The desktops startup time is something that gives a first impression 🙂 And of course smoothness that we all are gratefull for each time we login 🙂
Pretty much the stats that I have is what I posted on this blog but sessionk had lots of timer debuging to help me find the turtles..
I would say let it go with the current situation and add another path with systemd user session. It work really well and does all what you want and more. It start stuff in parallel, propagate environment variable correctly, restart service that dies. It is a very neat solution and easy to use.
It is really stray forward to use it, look at : https://github.com/sofar/user-session-units . I know it is best to support everyone and improve the situation for everyone. But wont your time be spend better on improving the speed of each task once you have written the unit for kde or do you prefer to duplicate systemd user session…
Well systemd doesn’t fit KDE needs out of Linux, also we already have KCrash and KLaunch is faster than systemd when launching kde apps, + a desktop session should be very tied to the applications it manages, so I don’t think such a system might actually help us here.
Could you tell me why do you think it would be faster than systemd? I don’t know what kde require there, but for c desktop it does everything that is needed.
Socket activation and dependency handling are well done in systemd. Give it a look and you will soon think you are duplicating the work. I say sip,because I did it in enlightenment.
As for other system,that don’t support systemd unit,you already have a working solution. No need to change it! That’s just my point.but if you have fun doing it,enjoy!
systemd doesn’t AFAIK provide X session manager protocol XSMP and it shouldn’t, KLancher forks itself and load kdemain which makes loading faster as all libs are already binded.
Dependency handlying can be easly achieved by DBus activation, I like systemd but I don’t see it fitting in KDE, and it’s Linux only which KDE is not. Also why support two things systemd and mine for non linux? mine is already duplicating ksmserver which isn’t very good by itself… 😛
Great work, I also often wondered why KDE starts up so slowly but never dared to dive into the initialisation code…
Why shouldn’t kdeinit (or KLaunch or however it is called) be used anymore just because systemd is used? I don’t see why they should be mutually exclusive. Using systemd would have the advantage of integrating well with the logind, which you’d otherwise have to do manually (or use console-kit).
Sure KDE needs something else for non-Linux systems, but the two approaches could share the XSMP implementation. Or maybe systemd already does that… anyone knowing how Gnome handles this?
I didn’t say that we shouldn’t use KLaunch anymore, I’m saying that the startup get’s faster due to using klaunch to launch them, I don’t think systemd handles the XSMP thing, it would need to link to X stuff and I’m not sure about what we will have in Wayland regarding XSMP (tho we could still use it since it works on top of ICE). Afaik Gnome has gnome-session to handle that…
what surprises me is the timer for KWin. Ksmserver should have the info when KWin is started – KWin talks with Ksmserver over D-Bus and most important KWin sends an X Event to the root window once it’s ready to go for the splash update. So all the info is there.
That kind of explains why it takes so long between the KWin splash item and the next one.
Sure 🙂
BTW I’m trying to have an X filter to know about a Window Manager too, so maybe I only launch the Shell after KWin is ready so the effect is ready.
For the 4 seconds kwin: that’s the max time till bootup continues. The second condition to continue bootup before that 4 seconds are reached is when kwin registered at dbus what usually happens in half a second second. See related patch at https://svn.reviewboard.kde.org/r/2034/
When I last investigated startup, long years ago, it was Plasma taking most of the time. I think caused by serial init of plasmoids. But before Plasma is even started lots of time is spend to init modules and block startup while doing so without good reason. Solution imho: parallelize more* 🙂
* eg start kwin/plasma parallel and save ~3 seconds, see https://svn.reviewboard.kde.org/r/3331/
@eliasp
There is no sleep(4) but a detailed AND portable dependency-system that can be very fine granulated configured and makes sure certain things are only started after certain conditions became true 🙂
Well that doesn’t seem to be merged all I have is QTimer::singleShot( 4000, this, SLOT(autoStart0()) ); – so yes a sleep(4), on kde-workspace master branch, so that 2 year old patch seems to never reached ksmserver or I’m missing something…
What sessionk is doing is starting both in parallel as you mentioned but this doesn’t fix it all, when we load kded modules the desktop start freezing a lot due to it being in a single process, I’m working on a solution to this too by having each module has it’s own process, but need more discussing…
autoStart0() is also called by clientSetProgram() (seems to be called from xsmp)
and from resumeStartupInternal() which is called over dbus by kwin.
ok, my bad it seems I missed this part, thanks
Dantti this is amazing! I’m quite confident that if we’d drive this effort forward and it does end up being released at some point we have this mentioned in every release-review. Compared to other desktops the splash in general feels out-of-date, good to not see it being included in your recordings, doesn’t feel like its missing at all!
In PHP-land I’ve learned about the concept of a “Dependency Injection Container”, see it as a conceptual tree of things you need that automatically loads everything it can once the individiual dependencies are available. Perhaps this is practically what SystemD does and so your sessionk’s following as well. I think it would also make sense – as Plasma mainly needs Qt at its core – to provide a “initial” mode and a “full desktop loaded” mode in which it connects to kded and further sets up stuff like the system tray, reducing the visual loading even more.
I’d be happy to discuss further thoughts on this, extremely cool effort!
Sure, I have told Aaron that showing just the desktop container like in the short video would be great, then load the widgets and panel, of course it needs more convincing and Plasma2 is already much faster (I’m told)
I have been told each succeeding version of KDE is faster, only to realize that its exactly the same- SLOW !
Startup speedy doesn’t mean KDE is slow (right now it’s only hiding behind the splash curtain), it’s indeed faster in many releases, see KWin’s improvements…
Agreed, plasma is certainly not that slow and hiding behind the splashscreen on many secondary processes. Simply put thinking KDE is slow due the current way of bootstrapping is understandable as the time makes them perceive its slow. So by for instance starting with loading the container and panels (keeping systray and other higher level plasmoids empty till further notice) will hugely change this perception of slowness.
[…] que alguien se pusiera manos a la obra para solucionarlo. Daniel Nicoletti, desarrollador de KDE, acaba de presentar sessionk, un nuevo proyecto destinado a acelerar drásticamente los tiempos de inicio del escritorio Plasma. […]
Shouldn’t you think about wayland, when writing such stuff ? It is cool anyway. I have an SSD to in my 15z dell so it loads really quick. But good new stuff is always welcome 🙂
Sure I think about wayland (which well I dunno how a Session Manager fits there since it’s a X protocol that doesn’t use X), but X doesn’t have a date to die, think about BSD and other UX running it, they can’t have Wayland…
[…] preguntita de marras no se me ha ocurrido a mí, sino a Daniel Nicoletti, uno de los desarrolladores de KDE -entre otros, desarrollador del gestor de paquetes Apper-, que […]
that’s awesome. could you please add an INSTALL file to the git with instructions on how to set your solution up on a standard kubuntu system? and most importantly, how to restore the old setup 😉
is it possible to use it with kdm? (i had troubles with lightdm coming with KDE 4.10 update and had to go back to kdm — can it be because intel atom n2600 is uncapable of running opengl on linux?)
the more testing your solution receives the more chances it will get to be integrated into mainline.
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr
make
sudo make install
Add a new user for testing, and login using “KDE Plasma (sessionk)”
It won’t change anything that you have it’s a new entry.
I’ll add an INSTALL file as it probably helps, about KDM I didn’t test,
but it should just show a sessionk entry. About opengl I don’t think
it should influence it…
Thanks
thanks. when you get to the polishing stage, please add
libsm-dev libice-dev libxcb-xtst-dev
to cmake checks now it complained for missing headers even though cmake config passed well.
also, trying to compile on raring i get the following linkage errors:
http://pastebin.com/RncF4WbF
so i tried sessionk on kubuntu precise, with kdm and KDE updated to 4.10.
at first try only black screen with mouse pointer appeared immediately after i entered credentials in the kdm. i waited for 40 seconds.
the log said:
“KConfigIni: In file /tmp/kde-test/kconf_updategR8094.tmp, line 1: ” Invalid entry (missing ‘=’)
kdeinit4: Fatal IO error: client killed
klauncher: Exiting on signal 15
before the second try, I logged in into ‘test’ user with the default session, and i have also removed kwin4_effect_zoomdesktop folder from /usr/…
the second try was successful and took 15 seconds instead of usual 20.
BUT instead of plasma-netbook plasma-desktop was launched.
–Nick
Ok, it seems I need to test it with KDM too, thanks for the info.
the most important for me is to make sessionk restore plasma-netbook and kwin settings. i have replaced “plasma-desktop” with “plasma-netbook” in the code, but with each sessionk login i see default setup even though i added several icons into favorites area on the top before.
Right, choosing between netbook and desktop is a bit hackish, which means I’ll need to worry about the autostart scripts on sessionk, which makes sense since some autostarted app may have a session to restore…
Looking forward to use a KDE with these startup times. Kudos dantti!!
Just tested it for the sake of it. It’s way fast, but Plasma Desktop crashed and, after that, QML settings were lost and Plasma loaded in English (in a Spanish desktop), so, you are not loading all required modules in the required order. However, for alpha-quality code, this is simply spectacular.
Keep up the good work.
did you save the backtrace? can you post it to the pastebin?
Thanks for doing this.
Ok, I had a go on my Kubuntu 13.04 (raring), 64 bit.
Qt: 4.8.4
KDE Development Platform: 4.10.00
kde4-config: 1.0
Dual monitor, complicated plasma setup on desktop.
Normal Login to Desktop (no apps restored):
– 10 seconds
sessionk:
– First monitor: 5 seconds
– Second Monitor: 10 seconds
– Also second try, the first monitor blanked out and couldn’t be restored.
– Also the sessionk desktop was much simpler.
I did multiple logins for both and averaged the values.
So for me – no improvement.
Well It’s a work in progress project as I said, and I don’t have SSD and have on my desktop the full session at around 5 seconds, but I still working on doing some additional changes to make sure only the minimal modules are required before launching the shell, and paralyzing kded which has proven to be a big eater of startup time..
To be clear, I’m not criticising or complaining 🙂 just trying to give you more data points. I appreciate your efforts to improve start-up time, its been a bug bear for a lot of people 🙂
Sure I understand, lots of people have been testing this and telling some stuff aren’t being loaded in the right order or something, on my tests they were fine, I hope I can make it more stable soon, so thanks for testing…
If you need any specific tests, logs or info feel free to ask.
Finally after 5 years someone noticed it!! Thank you and make it good. This is ridiculous sittuation and should be fixed once and for all.
Thank you for your tests!
Do I understand it correctly that what you’re doing essentially boils down to:
– use X-events to find out when a desktop is available.
– load all kded modules together – after the desktop is there.
It looks like loading the desktop might be IO bound due to the serial calls: Just reading the programs to run from disk can take quite some time. Can you check how much of the time all CPUs are running at 100%?
And maybe check how long a dbus call needs to be registered? If you need dbus for coordination and dbus gets slow, that could create a lot of invisible overhead.
Actually the idea is to load the minimal required for the desktop.
recently I found out that the kded modules are one the things that require a lot of time
mainly because they run single threaded and each one has to init and setup,
so my next approach is to coordinate the loading of each kded module in a separated process and launch the autostarted services using sessionk so I can filter apps like the plasma-shell as when one has plasma-desktop or netbook it gets confusing…
That sounds pretty cool.
Also it sounds like you’re actually unifying startkde and ksmserver – which might add a bit of needless bloat.
Would it be possible to just use ksmserver for session restore but not for loading anything? That way you would add clean separation between starting basic services and restoring sessions. The difference between the two is that starting services does not require any data from the last session (it only relies on explicitly stored data), while session restore changes operation at every new start.
Also you could treat session restore as just another program with some dependencies.
Yup getting rid of startkde (maybe not entirely as it could provide a fallback mode to check if sessionk crashed), but most importantly it could provide a single place to look at if you want to make further improvements on the starup process, as of now it’s quite sparse I’d say which is one of the reasons making changes to it is hard as you need to change lots of components.
About ksmserver code I already carry a copy of XSMP implementation and login/logout/lockscreen, as soon as I finish reading SM lib docs I plan to write it from scratch as I’m quite upset by Chromiun not being properly closed which sometimes leads to loosing my precious open tabs 😛
… the first “Also” should be an “although”… sorry for the confusion…
that’s great! I hope it works out!
Can you selectively disable kded modules and identify particularly bad offenders?
can somebody share a nice way to do this? i want to identify kded modules with memory leaks
“System Settings” -> “Startup and Shutdown” -> “Service Manager” : “Startup Services”
The best way imo would run valgrind kded4 –nofork (+ the required flags to track mem leaks)
Dantii, i need to file a bug report. Best place to do it? sessionk doesnt have its own section under bugs.kde.org
Please send me an email, as I’m not sure this component will be official some time.
Yeah I was looking through quickgit to see if commits had an email for you attached and didnt see anything. And I’m not seeing any email listed here on your blog sooooo >.> email?
“I like systemd (crossing fingers to see it soon in ubuntu), but it’s Linux only, and not all distros have it, and definetily not all UNIXes.”
Keep it up with that logic and you will not see KDE going anywhere beyond a few geeks. Keep duplicating the same stuff over and over again because it is *KDE with a *K.
Also keep blaming ubuntu for not switching to systemD and wayland.. but you do the same thing with systemD.
No, you are wrong, I don’t do the same thing with systemd. systemd is linux only and kde is not.
KDE doesn’t need me to go beyong a few geeks, it has survived many many years without me so I
can’t be the one to blame if it sink which will never going to happen.
I never blamed ubuntu for not switching to systemd and wayland, it’s just that people have short memory and forget Ubuntu started as being different from RH and SUSE, where it would never have a “closed” version, it would be community friendly, which everyone knows now that it’s not the case anymore. And it shouldn’t be, Cannonical is a company which needs money, which is why having an enterprise version makes sense, they need to make their clients happy not the community. I have no issue with Mir and Upstart, Upstart works just fine for me, but I can’t be in place to vote for a different option. Fragmentation is not bad, if we don’t have it we have a monopoly which is the first thing we should fight against.
I’m tired of people complaining about forks, forks are bad when they tell wrong information to justify it, I don’t need an excuse I want to see something working great. Ubuntu can do whatever they want, it’s their money just don’t keep telling lies, and if you accidentally do, apologize.
I rather see systemd as duplicating the same stuff over and over again, so that logic applies both ways.
How about letting other people take their choices? KDE is cross-plattform, and that’s great!
For me, Linux only is not what I want. I want people to be able to reuse the work done in free software to create other free kernels. Linux-only stuff prevents that.
But don’t forget you can’t achieve some awesomeness of systemd if it’s code is cross plataform… one would need other kernels to provide the same features, and flooding the code with IFDEFs is horrible for maintainance…
KDE manages to provide awesomeness on many platforms. So maybe focussing exclusively on Linux misguided them into choosing the wrong abstractions. They might have created an optional Linux-is-cool layer which chooses short code paths for stuff which Linux can do well – and which other kernels could have used to add their own awesomeness.
What I currently see is that more and more tools are pulled into a Linux-only mashup instead of keeping as much cross platform as possible and only providing a small platform dependent part.
In Gentoo we actually run into problems because udev is being subsumed into systemd and requires quite up to date kernels. Untangling the mess one of its updates did took me almost a day, and if I were to update it on my OLPC, I would likely kill it, because I cannot yet build a new kernel there which actually boots.
Such strategies make the system much too interdependent, and interdependent systems are brittle – which is the exact opposite of the stability for which GNU/Linux is often praised (because most of GNU/Linux actually provides that stability).
Hi Dantti,
This stuff sounds really great. I’m very happy to see people looking into KDE startup.
I’m a systemd dev, and I am very interested in working on using systemd for session management under KDE, I have not looked properly into it yet though. Your blog is a very useful starting point. For what it is worth, I think the problems that needs to be solved are independent of using ksmserver / sessionk or systemd, so hopefully we can all coordinate and learn from eachother.
I have a couple of questions and comments:
1) Do you happen to know if there is any more detailed documentation available about how this stuff is meant to work than http://techbase.kde.org/KDE_System_Administration/Startup ?
2) Would it not make sense to split out XSMP handling into a minimal self-contained daemon? That way it could be a) be reused by a systemd (or anything else really) system and b) be replaced by something else if Wayland ends up not using XSMP.
3) Just to briefly make the case for systemd: While it’s Linux-only nature obviously is a problem for KDE, and hence an alternate solution such as yours is also needed, I think KDE-on-Linux users really would benefit a lot from systemd in the long-run. Really a lot of the features we put in systemd for the system level can be reused very nicely on the session level. Take socket/dbus activation, which should lead to much faster start-up when done via systemd rather than pure dbus (which can only do lazy dbus activation afaik). Also the security/sandboxing features or the resource limits done via cgroups should be interesting.
4) As to the issue of KLauncher, the ideal situation would be to make it redundant somehow, but I see that this is a hard problem which likely will not be solved anytime soon. Luckily, there is nothing precluding you from using KLauncher for KDE application under systemd. Rather than putting your application binary in ExecStart=, you would put the dbus call to KLauncher and the binary would be launched via KLauncher as now.
5) Lastly, it would be very interesting if you could explain (maybe another blog post) a bit about why the various serialization points are still needed.
In a perfect world, we’d have the dbus session daemon and the Xorg server both being socket activated (i.e., your phase 1 could be done entirely in the background), and everything else would be dbus activated and only communicate with other programs via dbus (e.g., if KLauncher is dbus activated, then Plasma and KWin wouldn’t need to wait for it to start loading).
In such a perfect world all your phases could be collapsed into one and you could e.g. start Konqueror before X has finished starting. Any insight into why this is not the case at the moment, and why it is impossible (which I assume, but don’t know, it to be) would be very interesting.
Thanks for your work on this,
Tom
Hi thanks,
I’d surely love to have an IRC chatting with systemd devs, I have never user systemd (don’t blame me), but all I hear are good things, I like the linux-only thing which to me is what it should be since I don’t care about others, but we can’t at KDE do the same…
1. well I never saw that page, all the info I got was from kded/ksmserver README’s
2. yes, it might make sense indeed, which is sort of I’m doing with sessionk, I have put all it’s code into a separate dir once I have my own implementation (if I find it would be actually useful)
3. I’d really like to see which options could be useful in a session
4. well actually now that I now a bit more about klauncher one could call kdeinit4_wrapper and the name of the executable providing the kde_init skell.
5. What I see today is that more code should be written using dbus watchers so they don’t break is something is not available, secondly imo kded needs to launch each module on a separated thread that’s something that take a lot to load since it loads them in serial and single threaded. I’m trying to provide an alternative version of it to see if it provides benefits and if it’s developers would agree on a change.
Sure I really like the dbus activation, but this requires some hard changes that will surely take some time.
for the konqueror before X, it’s impossible because if it can’t communicate with the display server it will close.
Do you mean each module in a separate process? I didn’t think kded modules were safe to thread.
Yes, they aren’t safe, in fact I started to put all my kded modules in a separate thread, but some stuff can’t run in different thread other than the main one, also I can’t just move the kded modules to a thread since some of them have GUI which would just break them, so yes the idea would be separating them in process, especially because we now have too many which makes them start fighting for the event loop
thx!
Wouldn’t it be possible to use systemd’s user session support to do this kind of stuff?
Yes, but as I already said systemd is linux only and doesn’t have a xsmp implementation, also I’m trying to find which apps needs improvements regarding startup time.
[…] https://dantti.wordpress.com/2013/02/27/1-2-3-plasma/ […]
[…] Sessionk – taką nazwę nosi nowy projekt mający na celu przyspieszyć uruchamianie pulpitu KDE. Daniel Nicoletti na swoim blogu opisał jak wygląda obecna sytuacja startu środowiska graficznego KDE oraz wyjaśnił w jaki sposób jego projekt jest w stanie poprawić sytuację skracając proces startu wszystkich komponentów takich jak KWin, KDEinit, KLauncher, czy Plasma-Desktop nawet o połowę. Efekt prac dewelopera można zobaczyć na poniższych filmach, a kod źródłowy pobrać z GIT. […]
I had kubuntu installed in two computers, home and office, and using it for around two years in office. I never experienced these long delays.
Regarding systemd user sessions, have you seen http://lists.freedesktop.org/archives/systemd-devel/2013-March/009685.html ?
No, reading that link shows that Englightment has a similar design as KDE, but I’m not totally sure what did you want me to look at.
Don’t be a pussy about the BSD license…
Who’s gonna still your code? Apple? Like they did with KHTML (GPL)? Other free software projects?
Yes, like Apple. Webkit is only open source because KHTML was GPL, otherwise they would just copy and close.
Doesn’t matter if someone will want to close my code or not, the fact is that I will only ever code free software as long as it would remain free, otherwise I’d just code proprietary stuff on my own…
I love that stance!
Ideally I would wish for all programs to be AGPL to ensure that when they get used on a server, the operating code has to be free, too. But for KDE that is not *yet* essential (because it is optimized on being installed on a desktop). This could change, though…
Some additional notes on Apple and Free Software: http://draketo.de/licht/politik/leserbriefe-und-kommentare/apple-helps-free-software-myth
> “otherwise they would just copy and close”
You don’t know that, it’s an asumtion.
Apple is now the copyright holder of CUPS, and it is not close. Apple is one of the biggest collaborators of LLVM, yet it is open, as is Darwin, launchd, Bonjour, etc.
haha CUPS, right, really take a look at the news about it, they simply dropped everything we used on Linux, last year we even considered starting printd – a CUPS replacement (by we I mean that I’m involved with these people as I also maintain a CUPS client). Also you are again mentioning a product that is GPL not BSD, launchd was a failed attempt to get contributors in the name of openness, and Bonjour according to wikipedia is a proprietary free software, if that wasn’t the case why the hell would we create avahi?
You mean LLVM, the “we are not GPL, so you can steal all you want, but please give us money till we pushed out GCC” compiler? Apple does not like GCC, and with reason: New versions are under GPLv3, which does not allow the kind of perverted user-lockdown Apple practises.
Anybody know if there are advances in “sessionk”? I have been checking the GIT repo but the last commit is form June (2013) and I haven’t found any news about the status of the project.
IMHO, Kde needs a lot of time to startup (even in powerful computers), and I felt really happy when I read about “sessionk”
it basically became https://gitorious.org/lemuri/lemuri-session and could be used to start a Plasma/KDE session.
IMHO the work to truly improve startup time goes much deeper than I thought, and I somehow gave up.
KF5’s Plasma will very likely use systemd for the session startup (see also: http://goo.gl/YVq9sE).
Now that even Ubuntu finally decided to use systemd instead of Upstart, this is even easier to argument, as at least for Linux environments systemd can be relied on.
Non Linux-/systemd environments will still be able to use the legacy startup shell script.
systemd session startup isn’t capable of starting real desktop sessions, all one can do is setup units that would be started on both gnome/kde because they lack the concept of a session, so no KDE’s Plasma can’t use it because it’s not ready yet, and the systemd devs told me there is no ETA
Even if systemd should one day be capable of starting desktop sessions, it would be very important to me to have a non-systemd way to start KDE: I do not want systemd in PID1 – neither on my Gentoo box nor on any other – and even after the CTTE-decision, Debian will still support other init systems, so I would be very disappointed to see KDE forcing users to use a fixed init system.
@arnebab: As KDE Plasma should still be able to start on non-Linux/systemd systems, the legacy shell startup script will continue to exist.
Pity you had to give this up. I’m using Plasma 5 and still it takes like a minute or so to get ready my KDE desktop at 100% (well, it’s a Core2 Duo with 3GB on RAM, but still…).
afaik the main time-eater during startup is kbuildsycoca, which reads .desktop files and builds a metadata database based on them, there is a movement to get rid of .desktop files in favour of embeddable json metadata, so there is a hope that in the future startup time will be improved.
btw, plasma starts in just 5 seconds on my laptop with ssd (using btrfs)
Removing .desktop files would break compatibility with every other desktop system. And why would json be any faster to parse than .desktop files, which are syntactically simpler?