Having not got selected for this year's Google Summer Of Code, I applied for Season of KDE. Season of KDE (SoK) was set up in 2006 to provide some of the benefits of Google Summer of Code to those students whose projects did not get selected. Season of KDE provides students with experienced mentors and a well defined project, just like Google Summer of Code. SoK does not provide payment to students. Season of KDE doesn't provide the same benefits as Google Summer of Code, but it offers valuable mentoring, along with a vibrant and friendly environment, its more about Passion and of-course a cool T-Shirt. SoK allows us to work on a Cutting edge Project, and helps to take first steps developing KDE software and becoming worthy members of the KDE community. Each SoK student works on their chosen project with a mentor from KDE with experience in that area to help and guide them.
I too applied for Season of KDE. The application procedure was very straight-forward. Soon after getting the --> "sorry we couldn't select you, mail" from Google. I received a mail from a small Google Summer Of Dissapointment community. And came to know about Season Of KDE. Even students have to eat and so SoK participants often have other jobs and can only work on their projects part time. As a result, SoK projects may have smaller scope than Google Summer of Code projects or happen over a longer period. KDE benefits from new additions to our software and our community, and students get a SoK t-shirt, a certificate, some Google goodies and a great experience. SoK can also be a springboard to future Google Summer of Code success, with several past SoK participants going on to secure Google Summer of Code acceptance. Equally, SoK has provided opportunities for students to continue a Google Summer of Code project from previous years.
Having filled out the initial details on Lydia's Blog.
http://blog.lydiapintscher.de/
I received a mail next day, about my Project Details, I had earlier very vaguely suggested a project on Kde Speed Optimisation.
Project : Speed Optimisation of KDE start-up time.
I was Bombarded with a lot of well directed suggestions like, :-
: A possibility would be to help the Platform modulation effort to cut down dependencies.
: Another could be to reduce the number of dependencies that are loaded during startup. That is to convert some of the static libraries and see if we can load them Dynamically, that may have slight performance issues, but that would greatly reduce start-up time.
Having filled out the initial details on Lydia's Blog.
http://blog.lydiapintscher.de/
I received a mail next day, about my Project Details, I had earlier very vaguely suggested a project on Kde Speed Optimisation.
Project : Speed Optimisation of KDE start-up time.
I was Bombarded with a lot of well directed suggestions like, :-
: A possibility would be to help the Platform modulation effort to cut down dependencies.
: Another could be to reduce the number of dependencies that are loaded during startup. That is to convert some of the static libraries and see if we can load them Dynamically, that may have slight performance issues, but that would greatly reduce start-up time.
And finally I hope to implement the project as Tom Gundersen suggested :-
: Having a look at how systemd has improved startup speeds of system services, and try to do something similar to kdestartup. The idea is to allow sockets/dbus activation to synchronise daemon startup, rather than explicitly calling one daemon after another is up.
Idealy something similar should be possible (and much easier) for KDE apps/daemons as most desktop things are already able to do dbus activation. The idea would be to start all apps/daemons/services simultaneously as soon as the dbus session bus is running, and if one app needs a service it will block in the call to dbus waiting for it to start. As much as possible everything should be in the first autostart phase.
: The way to go here would to use bootchart and a profiler to find out where most of the time is spent, and then making that code faster. systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic.
It looks like these are going to be a great summer, I am so very excited. I hope my project would get selected.
Really nice indeed! Are you planning to use systemd for starting up KDE apps / daemons, and how does this relate to the discussion in GNOME about having systemd as external dependency? (http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html)
ReplyDeleteHi Anonymous,
ReplyDeleteThanks a Lot.
I don't think we can add systemd directly to our start-up scripts (I may be wrong), what I am trying to achieve here is very similar to what systemd does, i.e. parell-ising the startup of daemons as much as possible, by initialising the sockets, like systemd does. systemd as an external dependency, sounds very nice... But I have no/ very slight idea of how it would work. http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html ---> Thanks for the link I would go through it as soon as possible, thanks a lot, bcz I dont think that there would be much difference to KDE and gnome in adopting the method..
Regards,
Aaditya