Il giorno mer, 18/05/2011 alle 14.09 +0200, Lennart Poettering ha scritto: A really long list of questions, but I suppose I'll have to vote about this proposal, so...
> In the future I expect more interfacing with GNOME however, and I'd thus > like to see the discussion regarding acceptance as blessed > dependency started early. Are you planning to "delegate" single module maintainers to implement those interfaces? Do they agree on it? Do you have a list of involved "core" modules (apart the ones listed below: gdm, gnome-session and gnome-control-center)? > In the long run I expect the following additional interfaces used by > GNOME or one of its components: > > - I am working on two more mechanisms generalizing control of the system > locale and system clock/timezone for use in the control center and by > other UIs. Reducing this to a yes-or-no-feature view: distro/kernels without systemd will have to apply a (big?) patch gnome-control-center in order to provide the ability to change locale and time settings. Is this correct? Also, if I haven't misunderstood, 'cause you will not maintain a systemd version for non-linux kernels, if FreeBSD (just and example) will switch to systemd, FreeBSD developers will have to maintain their own forked or patched version of systemd, haven't they? > - gdm will interface with the new CK-replacing code I am working on. > > http://lwn.net/Articles/441328/ Same previous yes-or-no question (to simplify: no systemd, no login), plus I suppose this bond between systemd and gdm will add another -1 to lightdm. > - gnome-session will be augmented by a per-user systemd instace, > leveraging the benefits that systemd gives you for system startup also > for session startup. You suggested to use #ifdef here, so I suppose we should be able to log in and run GNOME even without systemd. > - Later on I hope that we can use per-application cgroups to create > reliable mapping between desktop files and processes. (i.e. place each > app in a cgroup and name it after the .desktop file), integrated into > the systemd cgroup hierarchy, so that this can be used for g-s and > other UIs to relate desktop files to processes. Is this the only way to create a relationship between processes and .desktop files? For example, another solution to this feature seems to be BAMF (https://launchpad.net/bamf/ ), and I remember it was suggested as a viable solution (maybe by vuntz?). Advantages? Drawbacks? Do you think systemd approach will be used by or can be shared to non-GNOME stuff too (for instance firefox or libreoffice or qt apps and so on)? > systemd is Linux-only. That means if we still care for those non-Linux > platforms replacements have to be written. So, IIRC, the release team will have to choose between "have features" (or enhancements to currently available features) and "create a lockin" (or something that, at least currently, resembles a lockin). Do you think we (release team) should follow a technical approach or a "political" approach to this question? Why? We are still at 3.2 release and systemd is a young project and not widely adopted solution. Any special reason to introduce this "lockin" in GNOME now? Isn't better to wait next releases and systemd maturity (read: a more clear vision about systemd adoption in linux world and in non-linux environments)? Do you have any plan to "sponsor" systemd outside linux world (apart "here is the code, but I will not introduce your non-linux stuff")? > systemd itself has very minimal external dependencies. You need Linux, > udev, D-Bus, and that's it. (there are a couple of additional optional > deps however). Could you please list those optional deps and explain how they are useful? > The first version i'd like to see blessed is systemd 26. Do you have any plan about API/ABI/interface/other/whatever stability or similar? How will a break effect GNOME modules? Cheers and thanks in advance for your reply. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
