Re: New module proposal: LightDM
On Wed, May 18, 2011 at 4:03 AM, Robert Ancell robert.anc...@gmail.com wrote: If we look at the LightDM repository there is an example GTK greeter. This uses GTK, so it has ATK support. Yes, is has ATK support as the calculator has. However, the login manager should start also the AT technologies But I think the point you are making that I was missing is there is nothing that starts at-spi-registryd? So even though the greeter has ATK support, it will not do anything? That's right, but no only the registry. You also need to start the AT applications needed by the user, like the screen reader, on screen keyboard, sticky keys, etc... Just to make it clear, this is a common use case: - Bob is a blind users who has installed XX distrbution and configured to use GNOME in English with an screen reader and the voice he likes. - After turning on the computer the login manager starts - The login manager starts the accesibility registry., the greater and screen reader, so Bob can navigate the greater UI and type his name and password. Hope this helps to get a clear picture. Thanks! Salu2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
systemd as external dependency
Heya, I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. Currently the interfacing between GNOME and systemd is minimal. Bastien has been implementing a UI for changing the host name via a configuration UI in the control center which uses a tiny mechanism daemon included in systemd as backend. GLib already exposes g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose only implementation I know right now is in systemd. 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. 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. - gdm will interface with the new CK-replacing code I am working on. http://lwn.net/Articles/441328/ - 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. - 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. And I expect a couple of more interfacing points, however things get more and more into vaporware areas with those. With these interfaces I hope to bring the speed improvements we are providing for the system also to the session. Also it brings a ton of new user-visible features with it, like automatic multiseat, or the ability to change the system locale. systemd is Linux-only. That means if we still care for those non-Linux platforms replacements have to be written. In case of the timezone/time/locale/hostname mechanisms this should be relatively easy as we kept the D-Bus interface very much independent from systemd, and they are easy to reimplement. Also, just leaving out support for this on those archs should be workable too. The hostname interface is documented in a lot of detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed -- we plan to offer similar documentation for the other mechanisms. Not all Linux distributions currently use systemd. The majority of the big and small distributions however has switched by now or is planning to switch in their next versions, or at least provides packages in the distribution. The one exception is Ubuntu. While I have hopes this will be resolved next year, there is no official statement from Ubuntu on this. Distributions not interested in systemd which however are looking into having some of its features could probably compile systemd but remove all but the mechanism daemons. Integration between gnome-session and systemd I expect to be very lose, and can probably easily be #ifdef'ed out for conservative distros or other OSes. The closest integration I expect in gdm. Ideally I'd like to rip out the current CK support completely and replace it entirely by the more low-level systemd specific code. However, that I can only do if the outcome of this discussion is clear. 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). The first version i'd like to see blessed is systemd 26. Comments? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Lennart Poettering wrote: I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. There actually isn't a module proposal period anymore. We are using feature or design proposals now. But the process for external dependencies was different anyway. Recently I was trying to categorise our 2.x external dependencies, thinking about the way to handle this for 3.x, and came with three levels: ** 1st level ** Established, stable, system modules, they have been in place for a long time, with stable API and ABI, and they exist in sufficient versions in the distributions commonly used by GNOME hackers, even in older but still used versions (Fedora 13 for example). Examples : libxml2, libpng, dbus... Proposed guideline : mentioned as dependencies with a base version, not built by default by jhbuild. Rationale : we want to reduce the number of modules that need to be built to start developing on GNOME. ** 2nd level ** Modules developed outside GNOME, with little attention to our schedule, but with an active development, and where we want to track recent code. Examples : mozilla (js-185 nowadays), poppler. Proposed guideline : built from tarballs, version bumps whenever a module need a new version. Rationale : we need recent code, but we do not want to arrive on a release days with modules failing to build because they require some code only available in $DVCS. ** 3rd level ** Modules developed outside GNOME, with attention to our schedule (i.e. we can ask for a tarball and get it in two days). Examples : webkitgtk, polkit. Proposed guideline : treated like any other GNOME module, built from latest git. Rationale : we do not need to put extra burden on modules that are close to us. At which level would you see systemd integrated, now, and in the future? Also you are speaking about (D-Bus) interfaces, and it is already envisioned to have them implemented by other components, should we talk about D-Bus interfaces that we expect to be available for GNOME, instead of saying systemd? Something else is the ability to run development GNOME, the most common tool those days is jhbuild, which was created way before D-Bus, and it's not always straightforward to get it working with D-Bus services, do you believe it will be possible to have systemd built and useful from jhbuild, or do you expect systemd will have to come from the distribution? Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 14:09 +0200, Lennart Poettering wrote: Heya, I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. Currently the interfacing between GNOME and systemd is minimal. Bastien has been implementing a UI for changing the host name via a configuration UI in the control center which uses a tiny mechanism daemon included in systemd as backend. GLib already exposes g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose only implementation I know right now is in systemd. 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. 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. This should allow us to implement missing portions of the Region and Language control-center panel, and probably remove the D-Bus helper in gnome-settings-daemon for date time. We're already using the hostnamed interface in the info panel, allowing changing the machine's pretty hostname. snip Not all Linux distributions currently use systemd. The majority of the big and small distributions however has switched by now or is planning to switch in their next versions, or at least provides packages in the distribution. The one exception is Ubuntu. While I have hopes this will be resolved next year, there is no official statement from Ubuntu on this. Distributions not interested in systemd which however are looking into having some of its features could probably compile systemd but remove all but the mechanism daemons. I would really like to see the helpers compilable on their own, without systemd itself, so that we don't need to provide fallback mechanisms in gnome-settings-daemon (for date time). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 15:40, Michael Biebl (mbi...@gmail.com) wrote: We're already using the hostnamed interface in the info panel, allowing changing the machine's pretty hostname. Isn't that the kind of functionality that was supposed to be provided in gnome-system-tools and system-tools-backend? What will happen with g-s-t and s-t-b? Why is it better to have that functionality in systemd itself instead of g-s-t? Because it is tiny and simple and allows us to standardize configuration files as side-effect. Having 10 different projects for 10 tiny things is just borked. I want to ensure that everybody uses the same platform and offers the same set of basic services. I think Linux as a platform can only benefit if app developers don't have to keep 50 different platforms in mind when developing code; a platform consisting of a 100 different basic packages used in 200 different combinations. It is my intention to do my bit to clean this all up, so that we have the same combination of basic tools on Linux distros, with the same configuration files and only a small set of necessary base packages. If you keep all these things separate then you multiply the maintenance work, and Linux continues to be the mixmatch balkanized platform that is so difficult to develop for as a 3rd party developer. Because we can reuse a lot of code the end result will be much smaller, more robust and normalized than if we duplicate the setup code over a number of different base packages. I second that. Speaking as a member of the Debian GNOME team, having the independent parts be compilable on their own would definitely help us: - While Debian has a systemd package and we hope to have systemd as a supported alternative for wheezy, sysvinit is still the default. Having GNOME depend on systemd would definitely complicate things for us. - Debian's has non-Linux ports. Having the non-arch specific parts in a separate package would mean we can more easily make the GNOME packages depend on them. No, that's not going to happen. systemd is strictly Linux-only. I have no plans porting it to other kernels, and I will not merge any such patches. One of the reasons systemd is small and easy to read is that we don't waste time and resources on abstractions and use the power the Linux platform supports. For example our main loops are pure epoll(), and I have no plans at all supporting anything else with a metric ton of #ifdefs. If the other kernels matter, then the folks working on them should share our interfaces (such as the hostnamed bus iface), not our code. What I am willing to support is builds of systemd that consist only of the tiny mechanism daemons, and leave the core of it outside. That way folks can install these mechanisms and stick with their old init systems for a while. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 15:49, Josselin Mouette (j...@debian.org) wrote: Le mercredi 18 mai 2011 à 14:09 +0200, Lennart Poettering a écrit : 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). I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. Quite frankly, I'd like to question this. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 18 May 2011 14:49, Josselin Mouette j...@debian.org wrote: I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. I do have to wonder how many people are actually using GNOME on Debian on BSD, or even (ahah) Hurd... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le mercredi 18 mai 2011 à 16:18 +0200, Lennart Poettering a écrit : On Wed, 18.05.11 15:49, Josselin Mouette (j...@debian.org) wrote: I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. Quite frankly, I'd like to question this. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore. By definition, another kernel cannot « keep up with Linux » if you introduce the features you need in Linux and then expect others to have them instantly available. In contrast, they also have features that Linux does not. Frankly, BSD is doing quite well. They have ported upower and I expect to have a udisks port eventually. So far nothing has prevented GNOME from fully working on BSD, and adding an arbitrary dependency just because you don’t want to maintain some #ifdef’s in systemd would be a real loss. -- .''`. Josselin Mouette : :' : `. `' `- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Hi, Lennart Poettering wrote: On Wed, 18.05.11 15:49, Josselin Mouette (j...@debian.org) wrote: I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. Quite frankly, I'd like to question this. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore. This would be a major departure for the project, a big kick in the face for long-term partners like Oracle/Sun, and also for other free operating systems like BSD. Are you sure you're not taking the GNOME OS idea a bit far here? Are we going to start depending on kernels carrying specific patch sets next? Or specifying which package management system we expect GNOME distributors to choose? Cheers, Dave. -- Dave Neary GNOME Foundation member dne...@gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le mercredi 18 mai 2011 à 16:34 +0200, Dave Neary a écrit : Are you sure you're not taking the GNOME OS idea a bit far here? Are we going to start depending on kernels carrying specific patch sets next? Or specifying which package management system we expect GNOME distributors to choose? Isn’t it already the purpose of PackageKit? SCNR, -- .''`. Josselin Mouette : :' : `. `' `- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Hi, On Wed, May 18, 2011 at 9:49 AM, Josselin Mouette j...@debian.org wrote: Le mercredi 18 mai 2011 à 14:09 +0200, Lennart Poettering a écrit : 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). I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. For Debian perhaps. However, I don't think this is true for GNOME. The future of GNOME is as a Linux based OS. It is harmful to pretend that you are writing the OS core to work on any number of different kernels, user space subsystem combinations, and core libraries. That said, there may be value in defining an application development platform or SDK that exposes higher level, more consistent, and coherent API. But that is a separate issue from how we write core GNOME components like the System Settings. It is free software and people are free to port GNOME to any other architecture or try to exchange kernels or whatever. But that is silly for us to worry about. Kernels just aren't that interesting. Linux isn't an OS. Now it is our job to try to build one - finally. Let's do it. I think the time has come for GNOME to embrace Linux a bit more boldly. Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 16:34 +0200, Dave Neary wrote: Or specifying which package management system we expect GNOME distributors to choose? Yes please. And the package names as well. The current situation is a help and support nightmare. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Il giorno mer, 18/05/2011 alle 10.40 -0400, William Jon McCann ha scritto: Having optional Linux-only functionalities is OK; requiring Linux is not. For Debian perhaps. However, I don't think this is true for GNOME. The future of GNOME is as a Linux based OS. What's the official position adopted by GNOME Foundation about this statement? And was this statement communicated in a neat and undoubtful way to GNOME contributors and third parties? I mean stuff like: What is GNOME OS, Relationship between future GNOME OS and currently existing distro, and so on... Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Hi! What's the official position adopted by GNOME Foundation about this statement? And was this statement communicated in a neat and undoubtful way to GNOME contributors and third parties? I mean stuff like: What is GNOME OS, Relationship between future GNOME OS and currently existing distro, and so on... Well, until now, GNOME OS was quite an abstract thing (read: an idea). Now, it seems that it is going to become concrete. Defining GNOME OS is probably an interesting topic for the upcoming election though. But never forget - The GNOME Foundation is basically the people contributing to GNOME and as such there is hardly any official statement unless the Board of directors decides to make one. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 16:34, Josselin Mouette (j...@debian.org) wrote: Le mercredi 18 mai 2011 à 16:18 +0200, Lennart Poettering a écrit : On Wed, 18.05.11 15:49, Josselin Mouette (j...@debian.org) wrote: I don’t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. Quite frankly, I'd like to question this. In the light of GNOME OS I think we need to ask ourselves the question if we do ourselves any good if we continue to support all kinds of kernels that simply cannot keep up with Linux anymore. By definition, another kernel cannot « keep up with Linux » if you introduce the features you need in Linux and then expect others to have them instantly available. In contrast, they also have features that Linux does not. Frankly, BSD is doing quite well. They have ported upower and I expect to have a udisks port eventually. So far nothing has prevented GNOME from fully working on BSD, and adding an arbitrary dependency just because you don’t want to maintain some #ifdef’s in systemd would be a real loss. It's not just some #ifdefs. It's a ton. Lemme list a couple of Linux specific interfaces that are used in systemd, you'd have to find replacements for: - cgroups - timerfd - signalfd - epoll - autofs4 - inotify - fanotify - /proc/*/stat - /proc/*/comm - /proc/*/cmdline - libudev - POSIX mqueue as fd - AF_UNIX/SOCK_SEQPACKET - abstract namespace AF_UNIX - get_current_dir_name() - canonicalize_file_name() - O_CLOEXEC/SOCK_CLOEXEC - /proc/*/fd - numerous prctl() controls, like PR_SET_NAME, PR_CAPBSET_DROP, PR_SET_PDEATHSIG, ... - capabilities - numerous console ioctls, like TIOCLINUX, VT_ACTIVATE, TIOCSTTY/TIOCNOTTY ... - /sys - /dev/urandom - /dev/char/*, /dev/disk/by-label/*, /dev/disk/by-uuid/* - openat() and friends - O_DIRECTORY - waitid() - /sys/class/tty/console/active - /sys/class/dmi/id - ioprio - various rlimits, like RTPRIO/RTTIME - F_SETPIPE_SZ - IP_FREEBIND - oom score - binfmt_misc And this is just what I found while going through two files in systemd. Of course, a couple of these are easy to emulate, or have obvious counterparts on the other OSes, or could be made optinal (or even are already optional), but the point I want to make here is that it wouldn't be a couple of #ifdefs. It would turn every second line of systemd into #ifdefs. And I wouldn't want to maintain such a beast. That all said, git is your friend. If people want to port this over to other systems, they are welcome to do so and with git rebase they could keep it somewhat up-to-date. I will not share your suffering if you do. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 10:15 AM, Luca Ferretti lferr...@gnome.org wrote: Il giorno mer, 18/05/2011 alle 10.40 -0400, William Jon McCann ha scritto: Having optional Linux-only functionalities is OK; requiring Linux is not. For Debian perhaps. However, I don't think this is true for GNOME. The future of GNOME is as a Linux based OS. What's the official position adopted by GNOME Foundation about this statement? And was this statement communicated in a neat and undoubtful way to GNOME contributors and third parties? I mean stuff like: What is GNOME OS, Relationship between future GNOME OS and currently existing distro, and so on... Cheers, Luca Without talking to the whole board (yet), we have supported the Release Team's direction of defining GNOME core and a broader definition of GNOME applications. When talking to partners, we continue to talk about GNOME as two things: the GNOME desktop (which constitutes GNOME core + applications) and the GNOME Developer Platform, which allows partners to build on and extend GNOME technologies. Unity, MeeGo, Sugar and more are built on the GNOME Developer Platform and we're proud GNOME technologies can be used in other areas. Longer term, I personally believe there will be opportunities to define GNOME core as GNOME OS, which could also lead to some interesting decisions to be made about the GNOME brand. I will be adding this as an agenda topic in future Board meetings and I look forward to discussing this more at the Desktop Summit this year with Foundation members in person. Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 16:34, Dave Neary (dne...@gnome.org) wrote: Are you sure you're not taking the GNOME OS idea a bit far here? Are we going to start depending on kernels carrying specific patch sets next? Or specifying which package management system we expect GNOME distributors to choose? I have not said anything about package management systems or which Linux distros people should use. Please don't put wordsin my mouth. What you are doing here is not helpful at all. I have said something about OS kernels, more spefifically APIs. I am not sure what you consider the OS part of GNOME OS means, but I'd claim that the core piece of an OS is the kernel. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 12:34 PM, Lennart Poettering mzta...@0pointer.de wrote: On Wed, 18.05.11 16:34, Dave Neary (dne...@gnome.org) wrote: Are you sure you're not taking the GNOME OS idea a bit far here? Are we going to start depending on kernels carrying specific patch sets next? Or specifying which package management system we expect GNOME distributors to choose? I have not said anything about package management systems or which Linux distros people should use. Please don't put wordsin my mouth. What you are doing here is not helpful at all. I have said something about OS kernels, more spefifically APIs. I am not sure what you consider the OS part of GNOME OS means, but I'd claim that the core piece of an OS is the kernel. Lennart And a core piece of an OS is its package management system. If GNOME OS is an idea that warrants a hard dependency on Linux it's not far fetched to ask what other parts between the kernel and GNOME (ie. everything) are expected to be included as well. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 16:53, Josselin Mouette (j...@debian.org) wrote: Le mercredi 18 mai 2011 à 15:47 +0100, Alberto Ruiz a écrit : Resources are scarce, and I'm afraid that Sun/Oracle (and I'm talking as an ex-Sun that worked closely with the Solaris Desktop guys here) or any other group that cares about GNOME in other platforms can't expect that the GNOME community should carry the burden of cross platform support itself. Nobody has ever asked the GNOME community to do that. Actually, nobody even asked the Debian GNOME team to do that for non-Linux ports. But we could always integrate the necessary patches to support BSD (and even Hurd!) when people wrote them. For systemd this is another story, since Lennart always made it very clear that a port to another OS would have to live in another repository. Telling people to do the porting job is one thing, telling them to maintain a complete fork is another one. Again, I think the mode of cooperation here should not be that systemd/Linux and the other kernels share code here. Instead it should be to share interfaces. For example, in regards of the hostname/time/locale mechanisms reimplement the bus interface, it's well documented. It's free software, you can always start on our codebase, but in the end I don't think it makes sense for me to support the porting work in my upstream repo. I also doubt it even makes sense to port that stuff. Also, never forget that while me might be able to pull it off to use systemd as vehicle to standardize certain configuration files on Linux I have serious doubts we could do that on the other kernels. I.e. if we say /etc/locale.conf should be the only place to set locale settings then I have serious doubts the BSD or Solaris folks would be so keen on that. Also note that those other archs need very different code anyway. For example, Solaris isn't too much into PK. Our mechanisms use PK. Hence they'd have to do non-trivial porting work anyway. And given how trivial the locale code actually is there's really no point in porting it over. Rewriting isn't so difficult. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 05:15:43PM +0200, Luca Ferretti wrote: What's the official position adopted by GNOME Foundation about this statement? It was on the agenda for last meeting and we put it on the agenda of the next meeting: http://mail.gnome.org/archives/release-team/2011-May/msg00036.html -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 14:39, Frederic Peters (fpet...@gnome.org) wrote: Lennart Poettering wrote: I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. There actually isn't a module proposal period anymore. We are using feature or design proposals now. But the process for external dependencies was different anyway. Recently I was trying to categorise our 2.x external dependencies, thinking about the way to handle this for 3.x, and came with three levels: ** 1st level ** Established, stable, system modules, they have been in place for a long time, with stable API and ABI, and they exist in sufficient versions in the distributions commonly used by GNOME hackers, even in older but still used versions (Fedora 13 for example). Examples : libxml2, libpng, dbus... Proposed guideline : mentioned as dependencies with a base version, not built by default by jhbuild. Rationale : we want to reduce the number of modules that need to be built to start developing on GNOME. ** 2nd level ** Modules developed outside GNOME, with little attention to our schedule, but with an active development, and where we want to track recent code. Examples : mozilla (js-185 nowadays), poppler. Proposed guideline : built from tarballs, version bumps whenever a module need a new version. Rationale : we need recent code, but we do not want to arrive on a release days with modules failing to build because they require some code only available in $DVCS. ** 3rd level ** Modules developed outside GNOME, with attention to our schedule (i.e. we can ask for a tarball and get it in two days). Examples : webkitgtk, polkit. Proposed guideline : treated like any other GNOME module, built from latest git. Rationale : we do not need to put extra burden on modules that are close to us. At which level would you see systemd integrated, now, and in the future? Not sure. Depends. systemd is not fully established yet, but it definitely is a system component, and yes, I do keep an eye on GNOME schedules. In the long run I hope that systemd takes a position next to D-Bus. i.e. outside of GNOME, shared with other systems, a basic OS building block, but pretty close to GNOME. Also you are speaking about (D-Bus) interfaces, and it is already envisioned to have them implemented by other components, should we talk about D-Bus interfaces that we expect to be available for GNOME, instead of saying systemd? Really depends. In some cases dbus interface is fine (for example for the mechanisms). In some other cases not so much, for example replacing CK in gdm will be a different kind of interface. Something else is the ability to run development GNOME, the most common tool those days is jhbuild, which was created way before D-Bus, and it's not always straightforward to get it working with D-Bus services, do you believe it will be possible to have systemd built and useful from jhbuild, or do you expect systemd will have to come from the distribution? systemd is something that needs to be adopted in the distribution, with some exceptions. The session management stuff will only work on a systemd system (since it requires the cgroup hierarchy set up for it to work). There are a few exceptions though, like the time/locale/hostname mechanisms which should run without systemd around. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le mercredi 18 mai 2011 à 17:30 +0200, Lennart Poettering a écrit : It's not just some #ifdefs. It's a ton. Lemme list a couple of Linux specific interfaces that are used in systemd, you'd have to find replacements for: - get_current_dir_name() - canonicalize_file_name() (Just to be pedantic: these are from glibc, so are available with kFreeBSD as well.) And this is just what I found while going through two files in systemd. Of course, a couple of these are easy to emulate, or have obvious counterparts on the other OSes, or could be made optinal (or even are already optional), but the point I want to make here is that it wouldn't be a couple of #ifdefs. Sure, but what if people want to do the job? It would turn every second line of systemd into #ifdefs. And I wouldn't want to maintain such a beast. That all said, git is your friend. If people want to port this over to other systems, they are welcome to do so and with git rebase they could keep it somewhat up-to-date. I will not share your suffering if you do. Ah right, people won’t do the job, because you give them the finger from the very beginning. Sure. What could we need more right now than another glibc/eglibc disaster with a maintainer who doesn’t want to care about more than his chapel? Note that this is the primary reason preventing us from making good use of systemd features in Debian. This would imply, for each package providing a daemon, to maintain a sysv init script for insserv a service for systemd. So we’re stuck, at best, with using only the lowest common denominator between init systems. In the end, this behavior is not just making the life of porters impossible; it is making harder to actually embrace your software. -- .''`. Josselin Mouette : :' : `. `' `- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 18:03, Josselin Mouette (j...@debian.org) wrote: Le mercredi 18 mai 2011 à 17:30 +0200, Lennart Poettering a écrit : It's not just some #ifdefs. It's a ton. Lemme list a couple of Linux specific interfaces that are used in systemd, you'd have to find replacements for: - get_current_dir_name() - canonicalize_file_name() (Just to be pedantic: these are from glibc, so are available with kFreeBSD as well.) And this is just what I found while going through two files in systemd. Of course, a couple of these are easy to emulate, or have obvious counterparts on the other OSes, or could be made optinal (or even are already optional), but the point I want to make here is that it wouldn't be a couple of #ifdefs. Sure, but what if people want to do the job? They are welcome to do so. But I won't litter my simple sources with it. I do not want to think about ifdefs about abstractions. I don't want to think which OS I am breaking now when I add something new to systemd. You know, I maintain a lot of software, like Avahi and PulseAudio for example. These two are big projects, and both of them are portable, to the weirdest Unixes. And have been ported to them. I *know* the burden portability brings with it. I know it better than most people. I think I know it better than you. The lower you get in your stack the heavier the burden of portability becomes. While top level apps might have little problems maintaining compat with other OSes by using glib and friends the closer the come to the kernel the more you need to deal with kernel APIs, and the more work, the more ifdefs, the more madness it becomes to support multiple kernels. systemd is the lowest-level component in our entire stack, isn't it kinda obvious then that making it portable is simply crazy? It would turn every second line of systemd into #ifdefs. And I wouldn't want to maintain such a beast. That all said, git is your friend. If people want to port this over to other systems, they are welcome to do so and with git rebase they could keep it somewhat up-to-date. I will not share your suffering if you do. Ah right, people won’t do the job, because you give them the finger from the very beginning. Sure. What could we need more right now than another glibc/eglibc disaster with a maintainer who doesn’t want to care about more than his chapel? Thanks, I'll call it Josselin's law: As an online discussion grows longer, the probability of a comparison involving Ulrich Drepper approaches 1.. Note that this is the primary reason preventing us from making good use of systemd features in Debian. This would imply, for each package providing a daemon, to maintain a sysv init script for insserv a service for systemd. So we’re stuck, at best, with using only the lowest common denominator between init systems. In the end, this behavior is not just making the life of porters impossible; it is making harder to actually embrace your software. Dude, you are turning everything from its feet onto the head: I am not making things difficult: you are yourself making things difficult. Debian kFreeBSD is a toy OS. About 10 people on this earth use it. About 0.4 of those probably run GNOME on it. Of that half a person only about 0.2 probably expect it to work properly. I am not sure why you ask me to care about your interest into toy OSes. I am not sure why you think that your interest in toy OSes should set the agenda for GNOME. Also, I can only repeat: the cooperation mode with your OSes and systemd should be sharing interfaces, not sharing code. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Hi! Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. I think Lennart made the point that systemd is not portable and won't be ported. He also made the point that that doesn't mean other OS could share the same interfaces as systemd while providing a completely different backend and he also made clear that the parts GNOME will likely depend on apart from gdm will be buildable on any OS while not providing much use. I really don't think we can make a useful control-center that supports all kind of operating systems. People that care about configuring OS parts on non-linux systems should probably write their own control-center. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. Thank you Vincent, that is sooo true. Even from technical POV, could please someone explain - why cannot GNOME define some reasonable cross-desktop dbus interface (not tied to particular internals of systemd), standardize it on fd.o, provide single implementation (in systemd) and let other OSes care about themselves - in _friendly_ manner, as you Vincent say? If that interface is well designed - I do not think it would be hard for others to implement it. Why introduce hard dependency on the daemon which is not a total standard even in Linux world? The whole concept about GNOME OS seems to be more dangerous than useful... This idea comes up every time GNOME wants to alienate somebody or something. Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Le mercredi 18 mai 2011, à 19:08 +0200, Johannes Schmid a écrit : Hi! Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. I think Lennart made the point that systemd is not portable and won't be ported. He also made the point that that doesn't mean other OS could share the same interfaces as systemd while providing a completely different backend and he also made clear that the parts GNOME will likely depend on apart from gdm will be buildable on any OS while not providing much use. Oh yes, I'm not saying systemd should be ported to the non-Linux world; that's why I even mentioned the high cost for it in my mail. Sharing interfaces makes sense in that case. I really don't think we can make a useful control-center that supports all kind of operating systems. People that care about configuring OS parts on non-linux systems should probably write their own control-center. Two things here: - if we share interfaces, as suggested several times, surely we can have one control-center for many OS. Those OS just need to implement the interfaces. - I don't think all system settings panels need deep integration with the OS, so there's no need to build a completely different control-center for non-linux systems. We can disable some panels on some OS if needed. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
It seems discussion died down around this, which means the status quo of just a GNOME external app will prevail. But I'm going to go ahead and take some steps to increase potential cooperation between Deja Dup and GNOME, for those that are interested: 1) I'll try to stay more on top of the jhbuild moduleset. It got bit-rotten as Colin pointed out, but now it's up to date. 2) I'll move my mailing list to GNOME. That seems rather painless and seems to make it easier for GNOME people. It's super low traffic, so doesn't really matter. But I encourage people to make it high traffic. 3) I'll experiment with moving my trunk to GNOME git. This will let GNOME people more easily dip their toes in the Deja Dup waters. Ideally this will be as low-cost an experiment for me as possible, so I'm curious about other people having done similar conversions. I'll keep a bzr mirror in LP for existing developers. But could I move back to bzr and not lose anything? i.e. would a round-trip (bzr-git-bzr) imply some metadata loss? And also, does being in git imply that the translation team would automatically consider the module? But moving bugs out of LP is a step too far for me. As would be carving up pieces of Deja Dup into other modules (like gnome-control-center). So I'll just keep chugging along as a separate app for now. But hopefully these changes will let the GNOME community become more involved if ya'll desire. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Sorry for the double post. When I wrote my last post, it was not clear to me that systemd is not and won't be portable. If this is true, then that's probably okay for Oracle too, as long as GNOME can be made smart enough to just disable those aspects of the desktop that require it when systemd is not present. I am sure that we at Oracle can figure out ways to bolt on the support we need for our users using other interfaces. When I write my emails, I try to be even minded and inviting as I think befits a free software community. But I sometimes wonder why I bother considering some of the other posts I read. Brian On 05/18/11 12:08 PM, Johannes Schmid wrote: Hi! Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. I think Lennart made the point that systemd is not portable and won't be ported. He also made the point that that doesn't mean other OS could share the same interfaces as systemd while providing a completely different backend and he also made clear that the parts GNOME will likely depend on apart from gdm will be buildable on any OS while not providing much use. I really don't think we can make a useful control-center that supports all kind of operating systems. People that care about configuring OS parts on non-linux systems should probably write their own control-center. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 8:30 AM, Lennart Poettering mzta...@0pointer.dewrote: could keep it somewhat up-to-date. I will not share your suffering if you do. Haha! Lovely. ;) I just can imagine your face when you're typing that, ya bum! :) sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Lennart: The closest integration I expect in gdm. Ideally I'd like to rip out the current CK support completely and replace it entirely by the more low-level systemd specific code. However, that I can only do if the outcome of this discussion is clear. Is it possible to do this, but maintain the ConsoleKit CLI, D-Bus interfaces, and configuration interfaces (e.g. /etc/ConsoleKit) for backwards compatibility? If these interfaces need to change, can you provide some perspective about how much they need to change? I wonder if it might be reasonable for systems that do not support systemd to continue using ConsoleKit. Will #ifdef's be allowed in GDM? If GDM is changed to become Linux specific, then does this mean that non-Linux systems need to migrate to a different display manager? I now know GDM is a Core GNOME application. If a different display manager is used to access a GNOME desktop, then can you still call your desktop GNOME? Can you swap out a Core GNOME program and still call it GNOME? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Vincent: On 05/18/11 02:02 AM, Vincent Untz wrote: I'm obviously no security expert, but doesn't the fact that the greeter runs as the gdm user and not root mean that the audit on the daemon side is enough (since the daemon should clearly validate everything that comes via dbus from the greeter -- there can be other greeters, after all)? Compromising the gdm user is better than compromising root, but is still bad. The gdm user has access to all users Xauth keys, so someone running as the gdm user can easily connect, snoop, and inject events into any running Xserver. You could, for example, snoop for someone to enter the root password into an X terminal program. This is probably not such a big deal on a laptop or desktop where you have some degree of physical security to ensure that random people are not accessing your GDM process. This would be more of a concern in a terminal server environment with public consoles, such as a LTSP (Linux Terminal Server Project) setup using XDMCP. Of course, you can get issues that will break the gdm greeter, but then those will also most likely break the user session anyway. You seem to be thinking of Denial-of-Service attacks. We also need to make sure that there is no way for the user to hit a hotkey or swipe a gesture to cause access to the command line as the gdm user. So, I do not think an audit on the daemon side would really be a sufficient audit, unless some more elaborate and secure method were to replace how Xauth is managed by GDM to disallow the gdm user access to the Xservers once they become user sessions. GDM does provide a very limited UI, so this does limit the code the user runs at login time to a degree. So, this could focus an audit, but there is still a lot of GNOME infrastructure used by the greeter to review. Also, this infrastructure tends to rapidly change every 6 months. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 14:09 +0200, Lennart Poettering wrote: [setting the hostname and other little interfaces] 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. A while ago, Rodrigo Moya had a lovely idea. Back then we were discussing the problem of distros having different mechanism for stupid little tasks which should be uncontroversial, like the hostname, timezone, etc. The plan was to introduce D-Bus interfaces to frob these things, and then to cunningly provide an AdminKit with implementations of the corresponding services. Distros would realize, oh, hey, we can use this pre-made code instead of maintaining our own hacks - let's do that. And then AdminKit would be a de-facto standard interface and unicorns would excrete rainbows. Recalcitrant systems would be de-facto forced to implement those D-Bus interfaces however they please. Your idea, of course, is the same - except that it puts the services in systemd (maybe not systemd itself, but the systemd package). You need somewhere to put them, after all. There are *probably* hit-and-run services like set the hostname where D-Bus activation could launch a tiny helper process that changes the hostname and emits a signal, and dies quickly. These present no problem, except for how to ship them. There are *probably* services that need to be running constantly, but I can't think of one right now. Those need a daemon. I'm kind of unhappy of the proliferation of daemons that we had at one point - gnome-session, the user's D-Bus daemon, gnome-settings-daemon, etc. Maybe if we had One Standard Way of loading service-y things into a central daemon, we could save a little memory and context switches? Is this even worthwhile? (If one crashes, it would make things much worse...). Maybe putting your services in an AdminKit would make things more palatable to unenlightened^H^H^H^Htraditionalist systems that don't want to use systemd just yet? (Note: I don't care much where the services are shipped. But putting them in neutral ground may be better/easier in the medium term.) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 14:46 -0500, Federico Mena Quintero wrote: On Wed, 2011-05-18 at 14:09 +0200, Lennart Poettering wrote: [setting the hostname and other little interfaces] 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. A while ago, Rodrigo Moya had a lovely idea. Back then we were discussing the problem of distros having different mechanism for stupid little tasks which should be uncontroversial, like the hostname, timezone, etc. The plan was to introduce D-Bus interfaces to frob these things, and then to cunningly provide an AdminKit with implementations of the corresponding services. Distros would realize, oh, hey, we can use this pre-made code instead of maintaining our own hacks - let's do that. And then AdminKit would be a de-facto standard interface and unicorns would excrete rainbows. Recalcitrant systems would be de-facto forced to implement those D-Bus interfaces however they please. Your idea, of course, is the same - except that it puts the services in systemd (maybe not systemd itself, but the systemd package). You need somewhere to put them, after all. There are *probably* hit-and-run services like set the hostname where D-Bus activation could launch a tiny helper process that changes the hostname and emits a signal, and dies quickly. These present no problem, except for how to ship them. There are *probably* services that need to be running constantly, but I can't think of one right now. Those need a daemon. I'm kind of unhappy of the proliferation of daemons that we had at one point - gnome-session, the user's D-Bus daemon, gnome-settings-daemon, etc. Maybe if we had One Standard Way of loading service-y things into a central daemon, we could save a little memory and context switches? Is this even worthwhile? (If one crashes, it would make things much worse...). Maybe putting your services in an AdminKit would make things more palatable to unenlightened^H^H^H^Htraditionalist systems that don't want to use systemd just yet? (Note: I don't care much where the services are shipped. But putting them in neutral ground may be better/easier in the medium term.) Which is why I've asked Lennart to add a flag to systemd's configure to install only the little servicey bits, for Linux distros, and the docs would serve as basis for implementation of other OSes. This would solve the problem of distributions that don't want to use systemd as the init system, and the Debian/FreeBSD probleme where just the filesystem layout is the same as a Linux distribution. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 18 May 2011 14:49, Josselin Mouette joss debian org wrote: I don\u2019t have anything against requiring systemd, since it is definitely the best init system out there currently, but the Linux dependency is an absolute no-no for us. Having optional Linux-only functionalities is OK; requiring Linux is not. I do have to wonder how many people are actually using GNOME on Debian on BSD, or even (ahah) Hurd... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Well, I can speak for OpenBSD when I say there are hundreds, if not thousands of users of GNOME on OpenBSD. There are probably an equal or larger amount of people using GNOME on the other platforms, like Solaris, the other BSD's, etc. 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). You have got to be kidding right? Yes, apart from forcing a complete operating system/kernel as dependency, almost zero deps...way to go! (Yes, I'm rather cynical, if not sad..) I think the time has come for GNOME to embrace Linux a bit more boldly. And let the others choke? I mean seriously, embracing Linux more would mean more Linux-specific backends to use, and caring less about the others they should just catch up.. I think I can say that I speak for the whole BSD community, GNOME users and non-GNOME users, when I say that such steps as enforcing Linux-only dependencies even more is a clear sign GNOME does not care about portability to any OS other than Linux...and that this is very sad sign to everyone else. Even right now it's hard for us to keep up with new things like, various *kits, udev, udisks and the like. Most of these technologies require changes in the kernel, which is assumed to be there already, since you run Linux. Don't get me wrong, new technologies exploring new parts are cool and nice, but need carefull thinking when forced as a dependency. Both portability and security-wise. I think upower would be a good example of how things were done right. It's got clearly separated backends where support for various kernels can be added (and not the other way around where support for upower has to be added to the kernel!). It's like a race where the track keeps changing while we're driving, which isn't bad per se. But it gets very hard when it's decided to use race cars instead of bikes.. I hope my (and of everyone who really cares about portability) concern is clear and others step up to express theirs too. -- Cheers, Jasper Capable, generous men do not create victims, they nurture them. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 10:50:45PM +0200, Jasper Lievisse Adriaanse wrote: I think I can say that I speak for the whole BSD community, GNOME users and non-GNOME users, when I say that such steps as enforcing Linux-only dependencies even more is a clear sign GNOME does not care about portability to any OS other than Linux...and that this is very sad sign to everyone else. Portability is nice, but how many OpenBSD developers are there working on GNOME for a significant amount of time? How many OpenBSD developers work upstream (so not just porting after the fact)? How many maintain a GNOME module? This as I don't notice anyone non-Linux developers usually on desktop-devel-list. Only some complaints after a new GNOME is released and it doesn't work right away on e.g. FreeBSD. To me, it seems like we do not have any non-Linux developers at all. So as a result, non-Linux gets less effort. It seems a pretty logical result to me. Then obviously you'll get a thread asking to depend more on just Linux. It is still being *asked*; result is this discussion and eventually release-team will decide. I do wonder what portability gets us (benefits+drawbacks). I can think of extra users, and perhaps better abstractions, but what more? Above doesn't reflect any opinion on what I think GNOME should do btw. I have not made up my mind at all. I'm just wondering out loud and being critical. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Wow, crazy. I go debugging gdm for half a day, and come back to find press headlines about 'GNOME 3 is dropping FreeBSD support'... the reality is of course much more nuanced, and much less dramatic. There are many things that could be said here, and much has already been said, so I'll try to keep my points short: - GNOME will probably always work best on the platform used by most contributors, which is a fairly modern Linux distribution. But that doesn't imply that we strive to ship something that can only be built on bleeding edge distributions. Looking back at GNOME 3.0, the NetworkManager 0.9 situation was certainly not a showcase of great dependency handling. But even so, it was the right decision to finally have networking as an integrated part of the experience (it feels funny to even having to mention this in 2011...) - Posix is not good enough: we expect networking, usb, sound, hotplug, etc etc. Our unwillingness to settle and rely on suitable interfaces between the kernel and the desktop has hampered us for a long time. GOME 3 is the first release that has official built-in support for networking and printing, after all these years of coming and going interfaces and frontends. Many of the 'middleware' layer of d-bus services and other compontents that sit between the kernel and the desktop have been developed and maintained by people who are close to GNOME, to satisfy the needs of the desktop (or really just the needs of a modern OS, period). - Many of these services can serve as a vehicle for portability too: If there's just minor differences in the underlying platform, it may be possible to port the service by just adding a few select ifdefs. If the service is very close to the kernel (and /sbin/init typically is), then it may be more maintainable and practical to reimplement the dbus interfaces from scratch. But an important point is that we don't want these services to degenerate to pure portability layers; they need to be able to develop and adapt to improvements and changes as they happen in the kernel. If that means that alternative implementations have some catching up to do every now and then, then that is the price to pay for freedom -- there's freedom on both sides here: freedom to develop the OS without being constrained by overly strict, standardized interfaces, and freedom to take the OS and replace bits and pieces as you like. - In practice, our portability is story is already pretty nuanced, as can be seen in http://live.gnome.org/PortabilityMatrix, and it probably always will be. I don't think that will change; we will always welcome reasonable patches that make our software work on more systems. But portability is a secondary quality. The primary quality of our product is that it actually works, and is awesome. It is no good to produce something that can be built on any free unixoid system, but doesn't really work right on any of them. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Il giorno mer, 18/05/2011 alle 17.54 +0200, Olav Vitters ha scritto: On Wed, May 18, 2011 at 05:15:43PM +0200, Luca Ferretti wrote: What's the official position adopted by GNOME Foundation about this statement? It was on the agenda for last meeting and we put it on the agenda of the next meeting: http://mail.gnome.org/archives/release-team/2011-May/msg00036.html Yes, I know it :) But I've said foundation, not release team ;) Quoting foundation.gnome.org: the Foundation will coordinate releases of GNOME and determine which projects are part of GNOME. The Foundation will act as an official voice for the GNOME project. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Thu, May 19, 2011 at 12:20:01AM +0200, Luca Ferretti wrote: Yes, I know it :) But I've said foundation, not release team ;) Quoting foundation.gnome.org: the Foundation will coordinate releases of GNOME and determine which projects are part of GNOME. The Foundation will act as an official voice for the GNOME project. And that decision is made by the release-team (delegated responsibility). Keeping in mind that release-team doesn't dictate, foundation is a bunch of people working on GNOME, etc. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 21:50 +0100, Bastien Nocera wrote: Which is why I've asked Lennart to add a flag to systemd's configure to install only the little servicey bits, for Linux distros, and the docs would serve as basis for implementation of other OSes. That's fine. I still think other distros/systems may be feel it to be a little onerous to have to download a big system-level package (even if it's just perception) to install random services like that. (Maybe a system-services tarball, if you really don't like the name of AdminKit?) :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, May 18, 2011 at 6:51 PM, Federico Mena Quintero feder...@ximian.com wrote: (Maybe a system-services tarball, if you really don't like the name of AdminKit?) :) Or even a separate git repository? Is there a compelling reason to keep them in the systemd tree? Note if they were separate, they could e.g. use GLib and GIO. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 17:51, Federico Mena Quintero (feder...@ximian.com) wrote: On Wed, 2011-05-18 at 21:50 +0100, Bastien Nocera wrote: Which is why I've asked Lennart to add a flag to systemd's configure to install only the little servicey bits, for Linux distros, and the docs would serve as basis for implementation of other OSes. That's fine. I still think other distros/systems may be feel it to be a little onerous to have to download a big system-level package (even if it's just perception) to install random services like that. (Maybe a system-services tarball, if you really don't like the name of AdminKit?) :) I definitely don't want to split this off. It's systemd on both sides here, writing and reading the configuration files. For example, for the locale settings mechanism we need to apply changes to disk which are read by systemd on the next boot, and we also need to apply them to the running instance. If we maintain this together it is easy to ensure that this stays in sync. Also the hostnamed code actually shares substantial code with the rest of systemd (like file parsers, dbus glue, logging, utilities, ...). I don't want to duplicate that in another project having to sync things boths way all the time. My plan with systemd is to clean up the mess that we traditionally had with a chaotic collection of basic mix and match building blocks. I want to work against that, and hence splitting these things off is diametrically opposed to my goals. I am also a very lazy person. I maintain way too many packages of our stack already. I am pretty sure I don't want to add another to that. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 18.05.11 14:46, Federico Mena Quintero (feder...@ximian.com) wrote: There are *probably* hit-and-run services like set the hostname where D-Bus activation could launch a tiny helper process that changes the hostname and emits a signal, and dies quickly. These present no problem, except for how to ship them. hostnamed is a tiny bus activated service. It normally isn't running unless somebody is using it, i.e. is actually changing the hostname. There are *probably* services that need to be running constantly, but I can't think of one right now. Those need a daemon. I'm kind of unhappy of the proliferation of daemons that we had at one point - gnome-session, the user's D-Bus daemon, gnome-settings-daemon, etc. Maybe if we had One Standard Way of loading service-y things into a central daemon, we could save a little memory and context switches? Is this even worthwhile? (If one crashes, it would make things much worse...). I think the best way to save resources is not to run anything. For stuff like hostnames/locale/time which is used only every other moonphase having tiny single-purpose mini-services is perfectly appropriate. I don't think there would be any benefit in merging these mini daemons into one. Au contraire, I'd guess you'd waste even more resources with dlopen() and friends. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
I think the best way to save resources is not to run anything. For stuff like hostnames/locale/time which is used only every other moonphase having tiny single-purpose mini-services is perfectly appropriate. I don't think there would be any benefit in merging these mini daemons into one. Au contraire, I'd guess you'd waste even more resources with dlopen() and friends. Can all those services be standardized using DBus interfaces (DBus activation if necessary)? IMHO that's the only way to remain friendly to non-linux OSes, not having any bits of systemd (or distros that are not using it)? Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Am 18.05.2011 19:21, schrieb Michael Terry: And also, does being in git imply that the translation team would automatically consider the module? Not automatically, you have to be added[1] to l10n.gnome.org [1]: http://bugzilla.gnome.org/enter_bug.cgi?product=damned-liescomponent=l10n.gnome.org -- Greetings, Sebastian Pölsterl signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On 18 May 2011 20:06, Fernando Herrera fherr...@onirica.com wrote: On Wed, May 18, 2011 at 4:03 AM, Robert Ancell robert.anc...@gmail.com wrote: But I think the point you are making that I was missing is there is nothing that starts at-spi-registryd? So even though the greeter has ATK support, it will not do anything? That's right, but no only the registry. You also need to start the AT applications needed by the user, like the screen reader, on screen keyboard, sticky keys, etc... Just to make it clear, this is a common use case: - Bob is a blind users who has installed XX distrbution and configured to use GNOME in English with an screen reader and the voice he likes. - After turning on the computer the login manager starts - The login manager starts the accesibility registry., the greater and screen reader, so Bob can navigate the greater UI and type his name and password. Hope this helps to get a clear picture. Yes, thanks Fernando! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On Wed, 2011-05-18 at 18:59 +0200, Jan de Groot wrote: This is not just about kFreeBSD, but about any non-linux OS that GNOME runs on. If the attitude becomes screw them, they're different, then GNOME should officially screw every distribution that doesn't provide the latest and greatest software too. I support the notion of concentrating on Linux. But there's a dangerous slippery slope here. In the last few weeks I've been trying to run GNOME 3 and gnome-shell on Ubuntu via the gnome3 developers' PPA. The number of times I have been mocked and derided and laughed at on IRC is staggering. That's not a real distro. That's not maintained by real GNOME people. Don't use that Switch distros! Jesus. This package repository is maintained by a bunch of people (some Canonical employees, some employees of other companies, some volunteers, *all* by definition GNOME community members) who are clearly putting in a lot of effort to make it work. That PPA was set up in no small part because early GNOME 3.0 marketing efforts identified that it really mightn't be a bad idea if the large number of people running deployed Ubuntu systems could try the new GNOME experience. It was also setup (and is used because) this certain cluster of Debian-based Linux systems really does have a rather large installed base. For a lot of good reasons most of those people cannot easily change distros, even if that were to be desirable. [And it's not. Many installed sites made a technology decision (Fedora → RHEL, Ubuntu edge → Debian stable, etc) one way or another and have since built system management infrastructure on top of it. They're not going to be in a rush to revisit that]. I'm fairly certain that the GNOME community is not trying to say thou must run Fedora. Of course not. But people asking nervously about packaging formats in a thread about system level dependencies are honestly concerned that such a distro mandate might be next on the list. [Yes, I know it would make the documentation team's job easier, and I'm sorry to oppose anything in that direction]. I think that requiring the Linux Kernel and common Linux base system libraries is a reasonable step in the right direction for GNOME. We are competing with several 900 metric pound gorillas who have total control of their stack and laugh their heads off at us when they even bother to take notice of us. We're not them. And we collectively have limited bandwidth to go around. I'm sad if this means we can't easily support the cool efforts of smaller communities of people working on [fringe is the wrong word. Edge?] projects like Solaris and the *BSD distros, but I also think the interfaces argument is a reasonable one. But meanwhile our current and near future user developer base *is* fragmented across several Linux distros and I'd like to hope we can be tolerant of them. AfC Sydney signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
