Re: Discouraging use of sync APIs
On Tue, 10.02.15 13:59, Philip Withnall (phi...@tecnocode.co.uk) wrote: > > I am pretty sure if you do async IO like gio does for every single > > file access you'll just complicate your program and make it > > substantially slower. For small files normal, synchronous disk access > > is a ton faster than dispatching things to background threads, and > > back... > > The problem is that GIO can’t know which accesses are to small, local > files, and which aren’t. It already optimises reads from pollable > streams (sockets) by keeping them in the main thread and adding them > into the main poll() call. Well, but the developer frequently knows that. He knows that the config file in ~/.config is not going to be more than a few K. And that it hence is fine to access it synchronously... > > Also, glib has wrappers for making mmaping available to programs, to > > improve seldom-accessed sparse databases efficient, do you want to > > prohibit that too? > > No, mmap() is clearly a tool for a different kind of problem. If you’re > accessing an mmap()ed file, you need to be sure it’s local anyway, I > think? GMappedFile doesn’t have async versions of its methods, > presumably for this reason. mmap() works pretty Ok these days over NFS. Concurrent access doesn't. But as long as you just want to access something, it's fine... That said it's probably not a good idea to use mmap() for stuff below $HOME... > As above, how about making that line the distinction between calling > functions from gstdio.h and using GIO? In the former case, you know > you’re operating on local files. In the latter, you could be operating > on files from the moon. I'd always leave some freedom for the developers. It is certainly good to document things and push people into the right directions, but I think there are many cases where the developer should have every right to prefer sync access for valid reasons, even from the main loop... Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
On Mon, 09.02.15 10:47, Philip Withnall (phi...@tecnocode.co.uk) wrote: > Hi all, > > From some feedback from real-world users of GLib/GIO (see the ‘Feedback > from downstreams’ thread), and just from looking at our own code in > GNOME, it seems that people persistently use sync versions of APIs in > the main thread when they should be using async ones.* [...] > * There are definitely legitimate uses of sync APIs, but not from the > main thread, ignoring trivial command line utilities (and even then, if > they want to handle signals properly, they should be running a main > loop). Uh, oh. This is really oversimplifying things. Note that on Linux disk IO is generally synchronous, and it's good that way, and you cannot really avoid it. I mean, never forget that your executable and its shared libraries are all mapped into memory and access to their pages results in synchronous IO. Even if you wanted you couldn't make that async... I am pretty sure if you do async IO like gio does for every single file access you'll just complicate your program and make it substantially slower. For small files normal, synchronous disk access is a ton faster than dispatching things to background threads, and back... Also, glib has wrappers for making mmaping available to programs, to improve seldom-accessed sparse databases efficient, do you want to prohibit that too? Moreover on Linux file systems like /proc, /sys, /run, /tmp are known to not be backed by slow physical IO, hence its really pointless accessing them via async IO... Then, during start-up of your app, when you need to read some config file or so before you can do your first steps, why bother with async stuff? You need to wait for for reading/parsing that file anyway before you can proceed? I think async IO is great, but it's definitely not the magic wand to apply to every single bit of IO. Linux synchronous IO is pretty damn fast, it's hard to optimize on that from userspace... Hence, my recommendation would be to draw the line somewhere between: "potentially unbounded user payload" data and "configuration/control" data. For the former it would be wise to encourage async IO but for the latter certainly not. If you follow what I want to say... Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Tue, 03.02.15 18:29, Cosimo Cecchi (cosi...@gnome.org) wrote: > On Mon, Feb 2, 2015 at 3:22 AM, Lennart Poettering > wrote: > > > Oh no, that's not what I meant. I was more proposing to pull them > > once, while you develop your stuff, and then shipping them in your own > > tarball. So, don't pull them dynamically when you start building, but > > you keep your own copy of the XML bits of other APIs, frozen and > > stable in time in your own project. > > > > That's what some modules are doing today already, but I don't think it > really addresses my use case. > I would like to be able to easily build client code that interacts with a > DBus service on the system without manually hunting for that interface from > the service's git repository, ideally with a nice autotool integration like > Philip proposed at the beginning of this thread. Well, don't hunt it down from some git repo, just pull it ouf some running daemon you are testing against. > So it seems that if we were to do that we're saying: > - services should install one of those files for each interface > - such files should have the same name as the interface and not contain > other nodes Well, are you sure the gdbus tools can even read introspection files right now that do not start with but with ? > - tooling would verify that the above two are true? > - it wouldn't be a great idea to use this for clients that ends up exposing > the generated code through a public API > > Lennart, you also mentioned about cross-build problems, but I'm not really > sure what those would be with this proposal - could you expand on that? Well, in sd-bus you define your bus interfaces in a C struct, with some syntactic sugar made of macros. The XML stuff is something you never see, it's generated at runtime from these structs. If you wanted to store the XML stuff on disk you'd thus have to run the program, and oull it out from there. But people who cross-build generally don't like it if they have to run the stuff they just built to complete the build process, because that usually requires the build and the target arch to be the same... Also note that sd-bus' XML introspection data is very reduced, it contains no parameter names or anything. In sd-bus we actually try to hide the fact that XML is used for this as much as we can, developers don't come into contact with it if at all possible... I figure it all boils down to the difference in philosophy: in gdbus the XML introspection data is the source of evertyhing and the C code built from that. In sd-bus the C code is the source of everything and the XML introspection data generated from that. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Sat, 31.01.15 18:29, Philip Withnall (phi...@tecnocode.co.uk) wrote: > Since Cosimo’s goal here is using gdbus-codegen to generate code using > those interfaces, I don’t think it makes sense to pull the introspection > XML from processes which would have to be running at build time. Oh no, that's not what I meant. I was more proposing to pull them once, while you develop your stuff, and then shipping them in your own tarball. So, don't pull them dynamically when you start building, but you keep your own copy of the XML bits of other APIs, frozen and stable in time in your own project. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Tue, 13.01.15 10:43, Cosimo Cecchi (cosi...@gnome.org) wrote: > Hi all, > > I was wondering if there's any reason we typically don't install on the > system DBus XML interface files for services. On my system, I can see a > bunch of definitions in /usr/share/dbus-1/interfaces, but it's by no means > a complete list of all the services in the system. Well, systemd at least used to install them, but we don't do this anymore, since there's really no clear consumer of it. Also, it's not clear how precisely to put them there. Most projects that put the files their, put a full descriptition of an object node there, which might have multiple interfaces. So you end up encoding multiple interfaces in a single file. But now, if you have 8 different interfaces, and use them in different combinations, what would you even place on disk? each interface only once? or every possible combination of interfaces (which would be highly redundant? We eventually decided to remove all this from systemd since this also created issues with cross-platform builds, since the introspection was created dynamically, and thus required built code to be executed to get them... I think it's probably a better idea to pull out the stuff from running daemons. Or, if you really want to keep the dir, then at least standaridze what should be in it, how the files are named, and such. AMong other things that means that it really should only include , but no elements, if you follow what i mean... Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Power switch to actually turn off my computer
On Wed, 09.04.14 20:20, Charles T. Smith (cts.private.ya...@gmail.com) wrote: > Hello, how can I configure my SuSE 13.1 system to shut down when I press the > power button? > > In SuSE 12, you had to make a change in: > > /etc/acpi/events/power_button > > but that directory doesn't exist in 13.1. > > I don't want it to shutdown when a user is logged in, only when at the gdm > welcome screen. > > I looked in xorg.conf(5), but didn't see anything appropriate. Install gnome-tweak-tool and go to "Power". You'll find it there. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hooking up gnome-session with dbus/kdbus/systemd
On Tue, 28.01.14 09:56, Sriram Ramkrishna (s...@ramkrishna.me) wrote: > > c) gnome-session currently has some special .desktop file support that > >it uses to set up the session and run it (parsing stuff from > >/etc/xdg/autostart). For that it forks off all > >processes on its own, and will wait for SIGCHLD to bind the lifecycle > >of the session to the lifecycle of gnome-settings-daemon + > >gnome-shell. It also uses that to implement "phases". I'd like to see > >this minimally changed to watch for the > >existance of the respective bus names instead, and use normal bus > >activation to start everything. The phase logic can stay in > >gnome-session even if gnome-session doesn't fork anything of > >anymore but uses bus activation for every> > > So this seems like we are going to continue to use gnome-session in > order to maintain support for non-systemd operating system. My > question is, why not at least move everything to systemd --user for > systemd sessions instead of maintaining gnome-session? That way we > get the benefits of things like bootchart and have more direct control > of how GNOME starts? gnome-session does a number of things where we don't want to see systemd get involved with. For example, in .desktop files there are some GNOME specific settings which allow you to bind it to a specific dconf key, and I am pretty sure systemd should not hook into that (not because dconf was bad, but simply because we should try hard to avoid making systemd a client of the daemons it manages). Also, note that we systemd we actually are changing the scope of things a bit. While previously gnome-session would be run inside the original user session and would then fork everything off directly, also inside the user session, we want a different layout in a systemd world: instead of having everything run inside session scope, we want to move things to user scope. Which means everything is forked off a singleton per-user systemd --user instance that is shared by all active sessions. Now, to start a service we still need one component though that continues to run in the session and just tells the systemd --user instance to spawn gnome-settings-deamon, gnome-shell and all the other services... We want this one component to be gnome-session. > I've heard some unsubstantiated claims that KDE is moving to this > model and is replacing startkde with systemd --user session. I'm not > sure what they are planning to do with non-systemd OS, but apparently > they seem to be calling them "legacy" systems. Maybe not an > appropriate label IMHO. But it seems that there is room to at least > consider moving wholesale to systemd --user instead of maintaining a > frontend and then changing everything behind the scenes. My expectation is that they'd follow the same scheme here: continue to have some small tool that goes to the systemd --user instance and just asks it to start whatever is needed. But then again, I haven't talked to the KDE guys about this. I probably should though. Maybe Ryan, we should do another fdo summit like last year? What do you say? Maybe organized next to some other European conference, like LinuxTag or so? Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hooking up gnome-session with dbus/kdbus/systemd
On Wed, 22.01.14 21:31, Matthias Clasen (matthias.cla...@gmail.com) wrote: > The only thing I've seen in this discussion that I disagree with is the > idea to make the distinction between starting a service (in the background) > and launching the application (opening a window) implicit, by looking at > somewhat obscure environment variables. That should be rather be explicit, > I think, and we want to limit the extent to which applications are allowed > to do that (run in the background). Yeah, I agree with this. As discussed with Ryan and others on IRC yesterday: I think the way forward here is to introduce a seperate ExecService= (or maybe ExecBusService= or so) field here, and for .desktop files without DBusActivatabe= set prorgams should just contiue forking off the binaries directly. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hooking up gnome-session with dbus/kdbus/systemd
On Wed, 22.01.14 11:01, Martyn Russell (mar...@lanedo.com) wrote: Heya, > >a) I'd like to see native D-Bus ".service" activation files deprecated > >in dbus. Instead, for the user/session bus, I'd like to see > >everything moved to .desktop files. Ryan recently extended the > >.desktop spec for declaring bus names in .desktop files so that > >applications no longer need to be forked off directly, but can simply > >be bus activated. I'd like to take this one step further: > > That's pretty cool, didn't know about this. > > You suggest moving everything to .desktop files (presumably .service > file information too), but later say you're not keen on Simon's idea > to merge the two. Can't we have that as an alternative to native > service definition files? What are your concerns here? Well, I am against just merging the file contents unmodified, i.e. having two sections, one for the desktop file entry, and one for the bus service. I think that's kinda pointless, given that the file will still have the ".desktop" suffix, and the bus name is implied for the file from the .desktop file name, much unlike dbus1 .service files where the file name is basically irrelevant and the bus name encoded in the file. So, I simply think the old .service files from dbus1 are unnecessarily weakly defined, and much prefer the stricter naming rules introduced by Ryan's logic. Thus, I'd prefer if we'd just do a minimal extension regarding the ExecService= or so, and be done with it, instead of integrating the whole section of old into the new. I want .deskop files to cover everything that dbus1 .service files did, but with clean, newly defined semantics, rather than the old baggage of weak naming rules... Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hooking up gnome-session with dbus/kdbus/systemd
On Tue, 21.01.14 20:21, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: > > On 21/01/14 19:22, Lennart Poettering wrote: > > On Tue, 21.01.14 19:49, Giovanni Campagna (scampa.giova...@gmail.com) wrote: > >> This won't work, because the Exec line from .service has a different > >> purpose than the Exec line from .desktop: the first runs the service, > >> the second activates the application provided by the service (ie, it > >> opens a window) > ... > >> So we would need a new line, ExecService=, that has the same purpose > >> as the Exec= key from service files. > > > > Well, this seems unnecessary. And app should just check for > > $DBUS_STARTER_BUS_ADDRESS or $DBUS_STARTER_BUS_TYPE. If that is set it > > is bus actviated. If it isn't it is not. In the latter case it should > > pop up a window. > > No, that doesn't work; child processes of an activated process will > inherit DBUS_STARTER_* from it, but should normally be starting in > "interactive, pop up a window" mode. For instance, run gvim from > gnome-terminal, then look in /proc/`pgrep gvim`/environ - the actual > terminal bit of gnome-terminal is an activated service. > > libdbus used to try to remove these variables from the environment so > that the activated process' children wouldn't get them, but this was (a) > not thread-safe, and (b) broken for several years with no apparent harm > done (the names of the variables were changed years ago, but the code to > remove them wasn't updated to the new names), so we removed the > offending code. > > If you want the protocol for activation to involve testing these > variables, then it would need to include a variable with the pid of the > process that is expected to obey those variables, similar to the systemd > LISTEN_FDS/LISTEN_PID protocol - but to be honest I think ExecService > might well be a nicer way to do this anyway. An alternative might be to also check $MANAGERPID == getppid() or so... But yeah at that point it might make sense to go ExecService, indeed... > Possibly slightly silly idea: desktop files are .ini-style, D-Bus > services are .ini-style, so a file containing both would not be > unreasonable... > > [Desktop Entry] > Name=Terminal > ... > TryExec=gnome-terminal > Exec=gnome-terminal > Icon=utilities-terminal > Type=Application > ... > [D-BUS Service] > Name=org.gnome.Terminal > Exec=/usr/lib/gnome-terminal/gnome-terminal-server Umpf. Can't say I like that... > Using .desktop for service-activation is a nice idea, although for it to > be merged, I'd want to have some D-Bus Specification text and a > regression test. Sure, of course this would need to be added to the spec. I'll bring this up on the dbus ML as soon as we have a rough idea that we actually want this all... > > If we instead ran it as part of a specific user session > > then it would go away as soon as that one session died, which is less > > desirable... > > When you say "session" here do you mean in the PAM sense: thing that a > user can have more than one of at a time, all sharing a "systemd --user" > if in use? Yes. > AIUI, we have traditionally had: > > * one session dbus-daemon per "login" > * one (gnome-shell, gnome-settings-daemon, ...) per "login" (if X11) Correct. > and you're proposing: > > * up to one (user bus, systemd --user) per (user, machine) at a time Correct. > * up to one "login" per (user, seat, machine) at a time, > potentially several sharing a systemd --user Well, we were just discussing this bit on IRC. I'd actually allow as many "login"s per user, per seat, and per machine as people want. The display manager would merge them all into one big "xinerama" workspace. However, it obviously makes little sense to log in twice on the same seat as the same user if this happens, because that way you could see a some parts of the workspace never at the same time. Hence, on the lower-level we'd not make restrictions here, howeber, I'd expect that gdm would not allow this and simply activate the existing login on the same seat when the user tries to log in multiple times on the same seat (pretty much the same as it already does that right now). > * one (gnome-shell, gnome-settings-daemon, ...) per systemd --user > (if at least one "login" is X11 or Wayland) Correct. > where by "login" I mean situations like "user sits down at a gdm prompt > and types in their password" or, if you're @1990sLinuxUser, "user logs > in on a tty and runs startx". Yupp. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hooking up gnome-session with dbus/kdbus/systemd
ome-clocks do as well. > gnome-sound-recorder could be switched easily too (because it uses > gnome-weather's infrastructure). > OTOH, I have a gnome-weather branch that replaces the .service file > with .busname and .service units, which would be nice because I would > get proper starting and stopping, and the ability to be started not > just by busname but also at session start (for a background service > polling NWS advisories). Well, but you could get all of this with .desktop files too, if systemd understood them natively. (Not saying that you shouldn't ship native systemd unit files, there are many reasons one might still want to do that, since it opens up so many additional settings...) > > c) gnome-session currently has some special .desktop file support that > >it uses to set up the session and run it (parsing stuff from > >/etc/xdg/autostart). For that it forks off all > >processes on its own, and will wait for SIGCHLD to bind the lifecycle > >of the session to the lifecycle of gnome-settings-daemon + > >gnome-shell. It also uses that to implement "phases". I'd like to see > >this minimally changed to watch for the > >existance of the respective bus names instead, and use normal bus > >activation to start everything. The phase logic can stay in > >gnome-session even if gnome-session doesn't fork anything of > >anymore but uses bus activation for everything. The hookup that these > >desktop files have with dconf would also stay unmodified. > > Well, at least in the interesting cases (gnome-shell and > gnome-settings-daemon), gnome-session hooks the phase logic to an > explicit notification, through XSMP for gnome-shell and through DBus > for gnome-settings-daemon. > The dependencies for the three components are quite complex > (especially as the order is reversed in the X11 and Wayland sessions), > so I'd rather not touch that, and keep "gnome-session + gnome-shell + > gnome-settings-daemon" as a unit. > Everything else could be hooked to bus - except for legacy XSMP > semantics that we need to preserve... Hmm, do we actually really want XSMP still? This has come up a couple of times already in the past, isn't it time to finally let it go? I'd really prefer if mutter/gnome-shell and gnome-settings-daemon would be forked off systemd. To explain this, a bit more about the bigger picture regarding sessions and seats and the user bus: I'd expect that the display manager (at least in a Wayland world) would be something that is started when the user first logs in and then stays around until he last logs out, grabbing all devices attached to the seats of the sessions of the user as the user logs in and out. i.e. I'd like to see the display manager as a per-user singleton that manages not just one session but everything that pops up for the user it runs under and merges this into one big xinerama-style display. Or in other words: if the same user logs into two local seats he would get a single gnome-shell that spans all seat's displays. (optionally, the user could also move this to "clone" mode, as he already can). As David Hermann just assured me on IRC me something like this is not too hard to make work for both Wayland and X11 actually. Now with that in mind, gnome-shell/mutter/wayland would be started when the first user session is created, and would stay around until it sees that the last session is gone. If we instead ran it as part of a specific user session then it would go away as soon as that one session died, which is less desirable... Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hooking up gnome-session with dbus/kdbus/systemd
and suchlike, it would probably make sense if GNOME would try to actviate this via explicit systemd calls rather than forking off directly. But that should be easily doable in a safe way that doesn't add a strict dependency to systemd). To me at least this all sounds reasonably simple and straightforward. I' like to begin this discussion here on the GNOME ml for now. If we have some form of agreement I'll involve the xdg + dbus mailing lists too, i figure the other desktops want to be kept in the loop for this too, as they are in a very similar situation in probably wanting to use systemd, but not as struct dep. On the systemd side the only missing bit here is to teach it native support for .desktop files. But that shouldn't be too hard. On the GNOME side the missing parts are making everything actually use the bus activation bits in .desktop files, which might be a bit more work covering a lot of individual components, since it also means exposing the dbus interfaces Ryan defined (GtkApplication...). And then gnome-session would need to push one more var, and be able to track its services not by PID+SIGCHLD but by bus names. Does this make sense? Suggestions? Ideas? Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 22.04.13 14:36, Allan Day (allanp...@gmail.com) wrote: > Hi all, > > This is something that me, Jon and Jakub have been thinking about for > some time, and is now at the stage where we can start to think about > implementation. I'm proposing it as a feature for 3.10 [1]. > > The main element of the design is to combine the sound, network, > bluetooth, power and user menus into a single menu. This will enable > us to resolve a number of UX issues we've encountered with the > existing design (badness on touch, difficulties having the user name > in the top bar, lots of complexity in some menus, like network, > virtually none in others, like sound...). It will also give us greater > flexibility, and will allow us to deal with some features - like > airplane mode - in a more elegant and discoverable manner. This all looks so ... crowded in the wireframes. So very very crowded. That can't be good? I understand that much of this is not supposed to be shown when not in use, but this does open a lot of questions to me. i.e. you have to figure out what "in use" means, i.e. for audio you probably have to think about some latency after each action that audio is still considered in use, and what about the usecase, where I am in a presentation at a conference and somebody sends me a video, and i want to see it, but want to turn off audio first, so that nobody notices that i watch a video rather than watch the speaker? And regarding the networking thing: if you want to show the networking bit only when traffic is required, then you create a chicken and egg problem, where the first network operation of an app will always fail, because you use it as a trigger but can't offer the network immeidately yet... So, I see tons of problems coming up when you try to be "context sensitive"... You need a lot of magic where you have to anticipate actions of the user before he actually does them. Because the user might want to change the volume *before* playing audio, and set up the network *before* doing something, and so on and so on... Also, if this menu shows when we are in airplane mode, and I presumably can use it to get out of airplane mode: how do i actually get into airplane mode if the option isn't shown then? But first and foremost, this all looks so crowded. Looks more like some feature-loaded KDE menu to me, rather then a minimalistic GNOME menu... Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature proposal: combined system status menu
On Mon, 22.04.13 15:58, Bastien Nocera (had...@hadess.net) wrote: > > On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote: > > 2013/4/22 Allan Day : > > > > However, while switching wi-fi networks will require an extra step, I > > > actually think that the the experience will be better with the new > > > design. The current network menu contains a lot of information that > > > isn't related to wi-fi, and isn't exactly straightforward to use - in > > > many respects, the new design will be more straightforward to use, > > > even if there is an extra click involved. Also, we are planning a new > > > wi-fi selection dialog, which should be a big improvement in those > > > situations where you are not already connected to a network. > > > > My main concern is the detection of "application needs network" and > > how it will properly integrate without > > modifying all applications so they interact with NetworkManager to > > request "I need network access". > > That can be implemented as a kernel feature with a user-space helper, > very much in the same way that "fieryfilter", a desktop-ish firewall > akin to what exists on Windows, used to do it: > http://0pointer.de/lennart/projects/fieryfilter/screenshots/fieryfilter-0.2-connection.png > > We might even get help from the original author ;) > (The code there is likely not the way it would be finally implemented, > the kernel infrastructure has changed quite a bit since 2008) Hmm, this gives me a bit of a headache... Hooking this into the firewall sounds like a questionabble place. We probably want something where we can get notifications about any unroutable, locally generated traffic, and we'd need meta data such as the PID for it, and we don't want to change the routing decision for it. I am not sure we could hack this up with the firewall... But humm, something to think about, and see whether some other place in the IP stack might provide us with what we need for this... Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
On Sat, 20.10.12 09:21, Jasper St. Pierre (jstpie...@mecheye.net) wrote: > > (Somehow you manage to reply with "Florian Max"@gmail, "Florian > Mullner"@gmail, and "Florian Muller"@gnome. I won't question it) > > On Fri, Oct 19, 2012 at 1:15 PM, Florian Müllner wrote: > > On Fri, Oct 19, 2012 at 7:10 PM, Jasper St. Pierre > > wrote: > >> This is what I feel. DBus is our system abstraction layer. I feel that > >> making ConsoleKit support the logind interface wouldn't be that big of > >> a patch and solve this issue, at least. > > > > Unless I'm mistaken ConsoleKit only provides a subset of logind's > > functionality though. > > logind provides the union of UPower and ConsoleKit, no? I wonder if it > would make sense to have a separate org.freedesktop.powerd interface > that UPower would provide, then. logind only took over calls to suspend/hibernate the machine from upower. Stuff like battery management and suchlike remains in upower and doesn't belong in logind. logind never was intended to be an abstraction layer of any kind. In the contrary, in order to keep the stack thin we export a lot of things that do not really apply to non-Linux, or are hard to translate. That's stuff like the cgroup path we expose for sessions, but plays much farther into the logic even, in that we build on the Linux audit framework, or expose calls such as GetSessionByPID() which securely determine the session ID of a PID. Something like that is hard to implement if the underlying OS doesn't have anything like cgroups which allows us to attach a session id safely and securely to processes and where unprivileged processes cannot escape. We also implement multi-seat based on udev device paths and that's directly visible in the API. Then, logind hooks into the handling of the ACPI keys and things like that, which might have counterparts on other Unixes, but not obvious ones (and the key handling *is* actually exposed in the API). The low-level C API we expose (which can be used as more lightwight, passive way to watch session/user/seat states in addition to D-Bus) exposes concepts as systemd unit names, and is built around inotify. And the list goes on... Some of these APIs could be turned into NOPs on non-Linux, or faked, or one could find alternatives for. But the gist simply is: logind and its APIs is not portable to non-Linux really. It never was intended to be. When we started to work on it we tried to figure out what precisely we wanted to do with logind, and one of the first things we found was that multi-seat should work right-away, and not be an afterthought. If you think about that, then you are in device management land. And if you are in device management land, then portability is a foreign country. So yupp, I am sorry to say, but logind is something that is in both code and API Linux-specific (heck, even systemd-specific), and porting it to other systems will necessarily be a painful. Note that many of the other APIs we came up with in the systemd context are actually designed to be mostly portable to other Linuxes/Unixes, for example hostnamed, timedated and localed, because it was easy there, and there was no reason to break portability of the APIs, but for logind this didn't appear like a good option for us, if we wanted to get the Linux story right. For a list of the interfaces systemd and the portability of them we have this list BTW: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart If portability matters for tracking seats/sessions/logins, yadda yadday, then it has to take place at the client side I am sure. logind's bus interfaces and C interfaces are not the right place. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 17:08, Ted Gould (t...@gould.cx) wrote: > > I already maintain a ton of stuff, and I try to keep maintenance burden > > and bureaucracy small for myself. Hence the Wiki, and not a complex > > standards process and a git repo. All API versioning we need should be > > done within the D-Bus interface itself (where the right place is for it > > anyway) and all documentation versioning by using the history > > functionality of the wiki. > > I guess that I don't see that as adequate (hence why I suggested > something more formal). What could be more formal than a machine readable interface definition as it is included in the Wiki page? > One way that I had thought this could work on the Debian packaging > side of things would be using the Requires/Provides labels in the > package. So then something like systemd could provide > "freedesktop-system-interfaces-45" and GNOME could require that. Right. What could be a better identifier for an interface and its version, than, well, the interface name which includes the version? i.e. use "org.freedesktop.timedate1" for that. And if you don't like the dots, then replace them by dashes or so, for use by your package manager. > There could also be other providers and users who wanted to switch > would then get their choice. Pulling the version number from the wiki > for all the different interfaces would make that complex and > burdensome to maintain for the packagers involved. Which is why I > suggested something with a more stable and uniform release process. I am not sure how better to achieve uniformity and stability than by by using the version information that is embedded in the interface definition itself? I am sorry, but you explicitly *don't* want another level of naming or versioning here, because then you'd have to maintain multiple versioning streams for the same stuff, and that'd suck. 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 16:29, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 23:20 +0100, Lennart Poettering wrote: > > On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > > > It seems to me that this would be a good usage of Freedesktop. I'd be > > > happy to maintain such a repository if people would be willing to use > > > it. > > > > Yeah, it's a great use of fdo, and that's why I put it on fdo. > > Just to be clear, you'd be happy if the interfaces were moved to a > different repository that was versioned independently of systemd? And > then systemd could depend on a particular release of those interfaces. Honestly, I don't see why. The wiki is just fine. The interfaces are versioned independently of systemd (that's why their interface names and object paths contain version numbers (currently at "1"). And those version numbers are specific to the API, and entirely unrelated to systemd. It's basically how D-Bus versioning is generally accepted to work). I already maintain a ton of stuff, and I try to keep maintenance burden and bureaucracy small for myself. Hence the Wiki, and not a complex standards process and a git repo. All API versioning we need should be done within the D-Bus interface itself (where the right place is for it anyway) and all documentation versioning by using the history functionality of the wiki. > So then, for instance, GNOME could say it depends on release 45 of the > interfaces and a particular version of systemd could implement that > version of the interfaces. It should just say it depends on the D-Bus interface org.freedesktop.hostname1, and that should be sufficiently exact, and is easily readable from the GNOME sources... > If you're happy with that, I'm happy, let's set up a repo. Thanks, but no thanks. 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:25, Bastien Nocera (had...@hadess.net) wrote: > > Then we need to clearly communicate what we expect distributors to > > provide. What systemd interfaces are we allowed to depend on without > > asking? > > The systemd interfaces that don't rely on systemd being the init system. > In this case, hostnamed, localed and timedated. > > I'm sure we'll get to have discussions again when ConsoleKit goes away. > For now, the multi-seat support code in systemd is a compile-time option > for gnome-control-center, and soon for gnome-settings-daemon. gdm's coming multi-seat support is a compile and runtime option. 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 09:39, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 10:22 -0500, Ryan Lortie wrote: > > On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: > > > I think that this would be more apparent if the DBus interface > > > descriptions were maintained outside of the systemd codebase. > > > >http://www.freedesktop.org/wiki/Software/systemd/timedated > > > > I won't comment on if you accept this as being sufficiently divorced > > from systemd or not... > > From the wiki page: > > systemd 30 and newer include systemd-timedated > > I would conclude that any dependency on that interface is a dependency > on systemd version 30 or newer. Therefore, GNOME has that as a > dependency in 3.4 on systemd > 30. > > To be clear, I don't think that's a problem in how the page is written, > I think that's a reality of where the interface is defined. Hmm, cool. If it's from the systemd project it must be evil? I totally see that, thank you. 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 08:59, Ted Gould (t...@gould.cx) wrote: > On Fri, 2012-01-20 at 12:37 +, Emmanuele Bassi wrote: > > the dependency is not on systemd - it's on a DBus API. systemd provides > > one implementation of that DBus API. > > I think that this would be more apparent if the DBus interface > descriptions were maintained outside of the systemd codebase. Yes, and they are. http://www.freedesktop.org/wiki/Software/systemd/timedated http://www.freedesktop.org/wiki/Software/systemd/hostnamed http://www.freedesktop.org/wiki/Software/systemd/localed That's the problem with you people: one tries to be nice to you, and document it all in much detail outside of the codebase, keep the systemd name out of all the interfaces, to make it really easy for you guys to adopt this without having to touch this evil systemd stuff at all, but you don't appreciate it, you just complain anyway that we'd mistreat you and everything was just an evil plot against you. You guys were in the loop, you guys even wrote alternate implementation of this stuff already, you guys discussed it in detail at the last UDS. And I was very nice to you by keeping the systemd name out of it and documenting it on fdo, and Bastien even showed you how easy it is two build the relevant systemd components without having to adopt systemd all the way. So you have multiple ways out of your perceived problem! So, what more do you want? There's nothing to complain about. Instead, I'd very much appreciate a "thank you" though. > It seems to me that this would be a good usage of Freedesktop. I'd be > happy to maintain such a repository if people would be willing to use > it. Yeah, it's a great use of fdo, and that's why I put it on fdo. 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:06, Sebastien Bacher (seb...@ubuntu.com) wrote: > > Le 20/01/2012 13:00, Olav Vitters a écrit : > >It is called systemd, and it is NOT a dependency. What we depend on is > >a few simple dbus APIs. If an OS doesn't implement those APIs, certain > >functionality won't work. These APIs have been implemented in systemd, > >but they can (and are being) implemented elsewhere. > > > >What I've said above is nothing new btw (to me). It has been discussed > >openly, think on this mailing list. > > > >What I am suggesting now is that we clearly document this (depend on the > >API being implemented). > Hi, > > Ok, so as a distributor of GNOME I think that what we (Ubuntu) would > like to see: > - some public list of what services GNOME rely on to be fully working > - some public announce earlier in the cycle, or if possible one > cycle in advance of what API will need to be provided for the next > GNOME release to be fully working > - some details (spec?) about the API used for those who want to > implement compatible ones > > It's fine to be using new services but if GNOME wants distributors > to provide a good GNOME experience system requirements should be > announced in advances with a clear description of the protocol to > give enough time to integrators to work on providing those services. You know, your complaining would be a bit more believable if Google wouldn't find this for us: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit So, the problem set has been known for a while, a number of Canonical desktop team members have been subscribed to that page, the documentation for the interfaces is all available, some code has already been written by Canonical. So I really don't see what went wrong here, except maybe that Canonical's internal communication didn't work out so well? 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 21:50, Steve Frécinaux (nudr...@gmail.com) wrote: > > On 01/20/2012 06:33 PM, Nirbheek Chauhan wrote: > >Try to think of it as a freedesktop standard for time and date (like > >org.fdo.Notifications). It even uses the same DBus namespace! Once a > >provider is implemented (by porting timedated or whatever) it can be > >reused everywhere. > > It might be wise to just make it a plain, documented, dbus spec. Thank god I am so wise: http://www.freedesktop.org/wiki/Software/systemd/timedated 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 10:29, Ryan Lortie (de...@desrt.ca) wrote: > As mentioned above -- Lennart has no intention of making it easy to use > his code outside of systemd (and I don't blame him). This is not a > matter of some simple packaging -- more like reimplementing a D-Bus > interface in a new code base (which could originally be copied out of > systemd, but then would have to be maintained separately). This is not > an afternoon's work. Given that Ubuntu already has code for these mechanisms, and a lots of DONEs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit I'd assume that their code is already quite far ahead. It's targeted for their 12.04 release, which I think is the current one that is developed... 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 08:47, Ryan Lortie (de...@desrt.ca) wrote: > > hi Bastien, > > On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: > > No, the distributions/systems that choose not to use systemd will have > > to provide a compatible D-Bus service. > > This is what I guessed you'd say. > > > It can be something "extracted" from systemd, or something new and > > revived from the old date and time mechanism, but it won't be something > > we support and maintain in gnome-settings-daemon. > > > And I'm glad I have 3000 less lines code to maintain. > > I'm just a little bit concerned about how this looks. I love when we > can delete code, but we're doing it by disabling a previously-working > feature for a portion of our users. > > If we introduced new optional features that depended on a particular > systemd functionality in order to operate, it would be one thing. We do > that often. This change is a regression of existing functionality in > the name of "I don't feel like maintaining it anymore". > > I'd also feel a bit better if I thought you had made efforts to get in > touch with those that would be affected by this regression. Ubuntu > isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for > the last week I've been trying to convince them that they should. If I > had succeeded (which I am now glad I didn't) then this change would have > been a royal pain, creating a whole lot of new work to fit into an > already full schedule. > > Many of our own end-users will still want to install GNOME 3.4 onto > their Ubuntu systems (myself included). I look forward to the mention > in our release notes about how they can no longer change their time > because we wanted to delete a bit of code. Note that The Ubuntu folks have been well aware of all of this coming. How I know that? Because at their last UDS they scheduled a session about rewriting those mechanisms for Ubuntu, and they even have a project page up on launchpad: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 20.01.12 15:13, Ionut Biru (io...@archlinux.ro) wrote: > I know the discussion and if I'm not wrong, the overall conclusion was a > big no no no to systemd. > > Also Lennart promised that providers can be used standalone and > absolutely no effort was made to ensure that and packaging separately > will require some hacking to the build systems. I did? I am pretty sure I didn't, why would I bother? 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: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Thu, 19.01.12 17:49, Ryan Lortie (de...@desrt.ca) wrote: > > hi Bastien, > > On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: > > commit 27fa171efe4179c0a42ec79e0dc501077f042a08 > > Author: Bastien Nocera > > Date: Thu Jan 19 22:33:21 2012 + > > > > datetime: Remove datetime D-Bus mechanism > > > > Now that gnome-control-center uses systemd's date & time mechanism[1], > > we don't need to ship our own mechanism for that purpose. This also > > removes the last user of dbus-glib in gnome-settings-daemon [2]. > > Are there plans to provide a systemd-compatible backend for those > systems that cannot run systemd? IIRC ubuntu did some work there: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit 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: Formal complaint concerning the use of the name "System Settings" by GNOME
On Mon, 25.07.11 17:40, Giovanni Campagna (scampa.giova...@gmail.com) wrote: > > The spec does not provide a list of shared keys, does such a list exist? > > If there is no such list I don't see how we could share anything. > > http://wiki.freedesktop.org/wiki/Specifications/XSettingsRegistry This isn't really up-to-date as it appears. These are the settings that Gtk currently knows: http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdksettings.c#n37 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
[REMINDER] Please submit BoF proposals for the Deskop Summit (aka GUADEC) in Berlin!
Heya, If you plan to run a BoF or two at the Desktop Summit, please consider submitting a request for them *now*: https://desktopsummit.org/program/workshops-bofs While it is not strictly necessary to submit your BoF in advance (you can also get ad-hoc BoF rooms at the conference) we strongly encourage you to, so that we can plan, can make sure to provide you with a nice room and time and can include your BoF in the printed schedule. The deadline for this is July 3rd, i.e. *this* *sunday*, so submit something *now*! Right now most submitted BoFs are KDE related, and we wouldn't want to have more KDE than GNOME BoFs at the conference, would we? So, hurry, submit your proposal! List of current proposals: http://wiki.desktopsummit.org/index.php?title=Category:DS2011WorkshopProposal The BoF days of the Desktop Summit are a bit inspired by the Boston GNOME Summit, but with a printed schedule. So if your BoF idea is right for the GNOME Summit, it is right for the Desktop Summit BoF days too! Oh, and while we are at it, please consider signing up as a volunteer for the desktop summit as well: https://desktopsummit.org/news/call-for-volunteers Thank you, 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
team) should follow a technical approach or a > "political" approach to this question? Why? I dont understand the question. I tried to outline the mode of cooperation I am suggesting on these interfaces. > 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? There is no lock-in. I think it is amazingly widely adopted. fedora, meego, suse, mandriva/mageia will do their coming releases with it by default. Debian, Gentoo, Arch have it, too. > 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")? I think if the distributions put enough trust in systemd to make it the default then this should be more than enough for GNOME. I have a very clear vision of systemd on non-Linux systems: it makes no sense. I have made that clear repeatedly. See above. > > 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? They integrate systemd with other stuff. If you have gtk you get a gtk frontend. If you have PAM you get a PAM module. If you have libcryptsetup you get automatic handling of cryptodisks, if you have libaudit then systemd will write audit records for you. If you have libselinux systemd will put proper SELinux labels on everything. If you have tcpwrap then systemd will check tcpwrap for sockets. Nothing of that is really relevant for GNOME. > > 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? http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise 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 Thu, 19.05.11 15:19, Lennart Poettering (mzta...@0pointer.de) wrote: > (also, all big distributions but one have announced their plans to > switch to systemd by now) OK, before somebody nitpicks on this: replace "switch to" by "include". Many will make it the default, but some just include it, leaving sysvinit the default. 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 Thu, 19.05.11 13:13, Maciej Piechotka (uzytkown...@gmail.com) wrote: > On Wed, 2011-05-18 at 17:51 -0500, Federico Mena Quintero 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?) :) > > > > Federico > > +1 for AdminKit. > > I don't think all distros switch for systemd in nearer future. Correct > me if I'm wrong but they seems to be perfectly suited and superior for > desktop enviroment but lack the fine-tuning servers admin requires (I > heard complains that in some situations Gentoo scripts, which are > dependencies, are wrong as they do not control the implied > correspondence between some servers in some setup). Yes, you are wrong. With systemd we actually try to cover the full bandwith from embedded to mobile to desktop to servers. But why does this even matter for GNOME? (also, all big distributions but one have announced their plans to switch to systemd by now) > In such way (i.e. AdminKit): > > - We/you[1] allow to replace systemd if it will be out-of-date (say in > 30 years ;) ) Well, the abstraction layers tend to be swapped out more often then backends. Just think about the Phonon story. 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 Thu, 19.05.11 00:50, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: > > > 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)? Some can. Not all. The hostname mechanism is explained in very much detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed As suggested a couple of times I believe the mode of cooperation with the Solaris/BSD folks here should be to share those interfaces, not the code behind it. Something similar is true for the locale/timezone/time mechanisms. 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
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 12:16, Brian Cameron (brian.came...@oracle.com) wrote: > In my discussions with people at Oracle, there is some concern about > how interfaces like systemd are being managed. Interface management is > something that Sun (and now Oracle) obsesses about, as many of you who > have heard about our "ARC" process know. Many people at Oracle ask me > questions about what is going on, but I myself have trouble following > the evolution from HAL to systemd or how exactly this impacts GNOME on > non-Linux systems. I am still digesting the fact that ConsoleKit is > going away. Is there a clear big picture, timeline, or roadmap yet? My and Kay's plans regarding systemd have been circulated and discussed widely. http://lwn.net/Articles/441328/#Comments I think our approach here is as transparent as it can get. > I know that people in the GNOME community understand how important good > documentation is, but there is probably more that could be done to get > the systemd message out there in an inviting manner, especially if > there is a serious interest to get wider, especially non-Linux, > involvement. Hey, pick something else to criticize us with, than documentation. I think systemd is much better there than the majority of open source projects, and we have been blogging about its features regularly. http://0pointer.de/public/systemd-man/ http://0pointer.de/blog/projects/systemd-for-admins-1.html http://0pointer.de/blog/projects/the-new-configuration-files These docs even have been translated to other languages, and there's a substantial body of other localized documentation available: http://wiki.opennet.ru/Systemd_%D0%B4%D0%BB%D1%8F_%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2 https://www.ibm.com/developerworks/mydeveloperworks/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/systemd_parte_1 > At the very least, I hope we can design a desktop so that if systemd is > not present this just disables those parts of the desktop that require > it. Not having systemd may disable support for things like removeable > media, power management, etc. There should not be a reason why not > having systemd should prevent GNOME from being used at all. Yes, this is pretty much in line with what I suggested with the time/locale/hostname mechanisms, and the g-s interfacing. It's basically what Solaris has been doing with PulseAudio as well. > The only thing HAL is currently used for in Solaris is removeable > media (e.g. USB) support. Sun Ray client devices do have USB jacks, so > it would be neat to have better removeable media support for them. > Sadly, HAL on Solaris today only supports the desktop on the console, > so there really is not any removeable media support in GNOME for Sun > Ray users. We need to rework all this code anyway. Perhaps it makes > sense to solve this problem together via systemd? systemd does not really cover that. That's mostly done in gio now, with a bit of udisks thrown in, both sitting on top of libudev. 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 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
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
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, 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, 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, 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 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 mix&match 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
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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Tue, 17.05.11 12:36, David Zeuthen (zeut...@gmail.com) wrote: > However, when you emit the PropertiesChanged signal on the > org.fd.DBus.Properties interface, you could pretty please include the > value for the property that changed as well [0]? The fact you > currently don't (which Bastien found out after I helped him debug his > app using your service) means that each instance of each app using > your interface manually using your service will have to issue a > Property.Get() method invocation. This is both inconvenient [1] and it > also causes extra over-head in terms of wakeups etc. from handling > these extra messages. > > It is true that @invalidated_properties has its place (consider huge > Blob-like properties), but in this particular case we're talking about > tens of bytes extra that is emitted every six months or so that > property changes. So I don't think there's any performance impact. It's mostly a question of laziness on my side. The invalidated_properties stuff I can hook up in matter of seconds. The other props need more work. I am note against this at all, just lazy ;-) 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Mon, 16.05.11 18:44, Ross Burton (r...@burtonini.com) wrote: > > On 16 May 2011 18:22, Lennart Poettering wrote: > > conmann also does geoloc? Is there something it doesn't do? Sounds > > almost as crazy as systemd ;-) > > AFAIK (and I may be wrong), but that's part of its "am I really > online" ping to connman.net, which acts as a captive portal detection. > The response packet contains a continent, or something. Oh my. Conmann phones home? This gets more and more interesting... 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Mon, 16.05.11 13:23, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello Lennart, > > Lennart Poettering [2011-05-16 1:06 +0200]: > > Next question: can you point me to some sources? (or alternatively some > > project name I could google for?) Would like to have a look on it, > > before I spend time on this. > > [1] has the backend code plus polkit files. But please NB that I > wouldn't like to see this being perpetuated a lot longer. > > I'm not sure whether GNOME 3 already has a D-BUS backend for storing > system-wide configurations, similar to the obsolete > gconf-defaults-service. If so, it might make more sense to integrate > it there instead of having a separate backend for this. Well, I think the different "smaller" system settings we want to make configurable, like the system locale, or the hostname or the timezone probably all need a tiny bit of intelligence on the server side, in order to ensure compat and provide change notification. So my approach would be to provide carefully mini-sevices for these things which we ship along systemd, which do PK and write sane config files like /etc/hostname and friends, and have no further complex over-arching infrastructure for that. > In Ubuntu we already have a catch-all "ubuntu-system-service" package > [2] which provides a backend for setting system-wide proxy and > keyboard settings. These weren't accepted upstream back then, but > perhaps with GNOME 3 we should make another attempt to get this > functionality upstream and make it work for everyone else? If that's > still not desired, then depending on the fate of the language > selection bits the ls-dbus-backend bits might go into the upstream > control-center D-BUS backend or ubuntu-system-service. I think proxy control probably belongs into NM. Keyboard stuff is complex. It's out of my focus for now. So I'll chicken out from it for now. On Fedora we have a service which always keeps console and X11 kbd settings in sync. I think this is needlessly complex though, and we could simplify this. Just not sure how precisely. 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Mon, 16.05.11 07:28, Ross Burton (r...@burtonini.com) wrote: > > On 16 May 2011 00:09, Lennart Poettering wrote: > > Ah, very interesting. This is good to know. Interesting place though, in > > connman. > > Yeah, it is "interesting". I discovered this because I'd floated the > idea of a tiny TimeKit daemon, mainly to deal with setting the system > timezone and emitting signals when it changes. It's almost like we've > all got the same problem. :) I think the right place for tiny mini-daemons like that is probably systemd. Since MeeGo is using that too this should be fine for you guys too. We already have a tiny daemon to deal with changing hostnames, and pretty hostnames/icon names, while guaranteeing that it always stays resolvable. My next steps are to fix locale and time/timezone like this too. > IIRC, the rationale was that connman is already doing a fair amount of > time manipulation: it has a NTP client and can also (or will, can't > recall) auto-set the timezone based on your geo-IP. From that it's > just a matter of allowing the user to manually set the timezone. conmann also does geoloc? Is there something it doesn't do? Sounds almost as crazy as systemd ;-) > Personally I'd hope that if a cross-desktop DBus interface was > proposed, that connman would implement it as a wrapper. Well, since you guys use systemd anyway, we might just ship it as systemd component. But yeah, we probably need to get the story regarding geoloc right before we do that. > > Hmm, do you happen to know where connman stores the high-level timezone > > name? i.e. "Europe/Berlin"? We'd like to standardize some place for this > > in the systemd context, and I am currently figuring out if we can just > > adopt an existing solution. > > http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=src/timezone.c;h=263ee4efe619e7f59a4844477131b09fb0e2cca1;hb=HEAD#l292 > > It takes the contents of the zoneinfo file and writes it to > /etc/localtime. It also reads /etc/sysconfig/clock at startup, but > doesn't appear to write that file. I can't seen where the name is > written though. This support is pretty new so might have some missing > pieces. Obviously for more details the connman list is the place to > go. Urks, so it seems to actively compare the /etc/localtime file with all possible candidates. That's kinda evil. I think it is time to introduce /etc/timezone or so which includes the pretty name. Or maybe use a symlink for /etc/localtime, which would allow us encode that info in the symlink path. And then write /etc/timezone only for those crazyfolks who want to stick /usr on a separate partition. 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sun, 15.05.11 22:01, Ross Burton (r...@burtonini.com) wrote: > > Let's try that again... > On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: > > (Background: I am > > working on cleaning up all those little services that can change > > locale/clock/timezone/hostname/... in the context of systemd) > > > In case you were not aware, in MeeGo 1.2 we've added a "clock" interface to > connman. This mainly handles NTP client functionality but can also control > (manually or automatically) the system timezone. > > http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt Ah, very interesting. This is good to know. Interesting place though, in connman. Hmm, do you happen to know where connman stores the high-level timezone name? i.e. "Europe/Berlin"? We'd like to standardize some place for this in the systemd context, and I am currently figuring out if we can just adopt an existing solution. Thanks a lot, 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sun, 15.05.11 22:50, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello Lennart, Heya, > Lennart Poettering [2011-05-15 21:10 +0200]: > > Sure, that I know, but what I was wondering is how the unprivileged user > > code that g-c-c is can make changes to this root-owned file. What is the > > machanism used here? > > Right, our language-selector has a polkitified D-BUS service for this > purpose. For package installation it uses aptdaemon (a PackageKit-like > D-BUS service for package installation which provides the necessary > Debianism). Ah, thanks a lot! That's what I was wondering about. Next question: can you point me to some sources? (or alternatively some project name I could google for?) Would like to have a look on it, before I spend time on this. Thanks! 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sun, 15.05.11 19:25, Martin Pitt (martin.p...@ubuntu.com) wrote: > > Hey Lennart, > > Lennart Poettering [2011-05-15 18:26 +0200]: > > Just out of curiosity, what's the mechanism Ubuntu uses to forward > > user locale settings to the system? i.e. what's the path to make locale > > configuration system-wide with Ubuntu? > > Debian/Ubuntu store the system-wide default in /etc/default/locale. It > is a plain "source with /bin/sh" style file like Sure, that I know, but what I was wondering is how the unprivileged user code that g-c-c is can make changes to this root-owned file. What is the machanism used here? A D-Bus service? sudo hackery? (Background: I am working on cleaning up all those little services that can change locale/clock/timezone/hostname/... in the context of systemd) > -- 8< - > $ cat /etc/default/locale > LANG="de_DE.UTF-8" > LANGUAGE="en" > LC_MESSAGES="en_US.UTF-8 > -- 8< - 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: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sat, 14.05.11 12:31, Martin Pitt (martin.p...@ubuntu.com) wrote: > Hello Matthias, Dave, > > Matthias Clasen [2011-05-13 8:33 -0400]: > > > * Language Selector, which allows you to configure your language and > > > fallbacks ($LANGUAGE/$LC_MESSAGES), locale ($LANG), list of > > > installed languages (packages which provide translations, > > > dictionaries, OO.o help, etc.), and input method.This can probably > > > be integrated into the now existing GNOME 3 module. > > > > Language selection is in the region panel, and the plan is indeed to > > have input method configuration integrated there as well. > > Unfortunately, we lack a person with the necessary skills and > > knowledge to really drive this, currently. Cooperation in this area > > would be highly appreciated. > > I am not quite happy about some parts of the current Ubuntu language > selector UI, so we want to make some changes anyway. It got quite a > bit more complex over the years due to user demands in some regions of > the world (like separate LC_MESSAGES and LANG setting), as well as > integration of extra package installation (language specific word > lists, hyphenation patterns, spell check dicts, etc.). If at least > some of these features are desired to have in upstream c-c, I'd be > happy to discuss the design with Dave and/or c-c maintainers (not in > this thread though, please) and then work on an implementation, and > then we can provide the rest of it (like packaging integration) as an > Ubuntu patch. If we stop having a separate package for this, I'm of > course interested in keeping the latter relatively small. Just out of curiosity, what's the mechanism Ubuntu uses to forward user locale settings to the system? i.e. what's the path to make locale configuration system-wide with Ubuntu? 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: New module proposal: LightDM
On Fri, 13.05.11 14:59, Robert Ancell (robert.anc...@gmail.com) wrote: > I'm proposing LightDM [1] as a replacement for GDM. I started the > proposal for this in GNOME 3.0 [2] but due to the young age of the > project I thought it better to wait until 3.2 before making a full > proposal. This is it. I apologise this has been done after the > proposal period. > > Why replace GDM? > > - LightDM is a cross-platform solution. Ubuntu is planning to switch > to it this cycle, and other distributions have expressed interest in > the project. By sharing this piece of infrastructure GNOME can spend > more time working on important GNOME components. I am pretty sure more platforms currently use GDM than use lightdm, how can you claim this as a reason that lightdm was better? In fact, what you claim here could be used as a good reason to convince Ubuntu to use GDM, since that is what the majority uses, not as a reason to convince the others to use lightdm, since that is only used by one relevant distro so far, Ubuntu? > LightDM is aligned with freedesktop.org. What is this supposed to mean? > - I am confident that the LightDM architecture is simpler than GDM. > Some indicators of this: > - Smaller code size > - Well defined interface between greeter and session > - Less dependencies > - Less internal interfaces But do you support everything that gdm supports, too? Like all the a11y stuff? Or the fprint auth, the extensibility and stuff like that? > - By having a well defined interface between the greeter and daemon, > it is significantly easier to develop a greeter without knowledge of > how display management works. This is useful as the skillset and > motivations of these two sets of developers are different. But why is that a benefit? I think we want one good one, instead of a lot of bad ones? Modern forms of authentication, like the biometric stuff, or auth tokens usually need some kind of specific UI integration. Why do you think that it is in our interest to complicate that even further, by requiring that 10 greeters need to be updated for this, instead of just one? > - LightDM is a platform for future work and is investigating the use > of new technologies like Wayland. Hey, that's a non-issue. Grand plans don't count. The gdm devs can promise us Skynet integration and they could be as convincing with that as you are as with a promise of Wayland integration. In general I do believe it is completely OK to replace existing components with complete rewrites from time to time. I have pushed that through myself more than once. But if you do you better have your arguments ready for this. You must have a very good case. You must support everything the old software you are replacing can provide, or have very good reasons why you do not want to support specific features (I have not seen such a list from you). You must support a lot of new features. You must have made clear that you fully understood the problem, you must show that you tried to fix the existing component, or you must have a good reason why you think the current solution is so broken that there is no value in trying to fix it. You must be able to deal with criticism and respond to it. You must show that you can rethink the set of problems, and that you have a good idea where you want to go with this. You need a vision. Right now the only benefit I can see with lightdm is that it allows writing greeters in Qt more easily. I am not sure why that would be interesting to GNOME however. In fact I believe a goal of GNOME should be to head for stricter vertical integration of the platform, not to make balkanization even easier. I too believe the gdm source code is not as simple as it could be. But I think lightdm mostly trades features against simplicity here. And the features you drop are not crazy features that nobody will mind, they are core features, they are features we want and that took us a long time to get. In line with my work on systemd and related techs I have quite a number of things I'd like to see improved in gdm. For example, I want the login screen to show up during early boot. I want background auto-logins with foreground auth queries (i.e. what Alex already suggested here). I want automatic multi-seat. I want hotplug support. I want things to be more dynamic. I want more flexible auth mech support, I want stronger Ply integration. If want soft session switching. But lightdm does not offer any of this, and doesnt make anything of this easier to implement. In fact it puts us even further away from it. Progress might require rewriting components, but just rewriting things is not automatically progress. gdm might not be perfect software. But it is powerful software, and its problems can be fixed in an evolutionary, not a revolutionary way. Lennart -- Lennart Poettering - Red Hat, Inc. __
GUADEC/Desktop Summit CFP ends in one week!
Heya, Just wanted to remind everybody that the GUADEC/Desktop Summit CFP ends next friday! Make sure to submit your proposals quickly, before it is too late! Berlin in summer is fantastic, you don't want to miss that, do you? First, read the CFP text: https://www.desktopsummit.org/cfp And then, submit your talk proposal: https://www.desktopsummit.org/submit Sorry for the KDE identity requirement. The DS web team is short on manpower and this was the easiest way to get things up and running. Thanks, 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: Gnome 3 system sounds
On Tue, 18.01.11 20:41, Gendre Sebastien (ko...@romandie.com) wrote: > Hello everybody. > > Some news features and a new Shell for Gnome 3, but any plans for the > system sound? Using sound theme from Freedesktop like in Fedora? Well, unfortunately sound themes don't grow on trees and before we can change the default we'd first need a theme we actually could change to. Unfortunately we never managed to attract many sound artists and the number of standard compliant sound themes is pretty minimal. Recently Canonical started an attempt to create a new sound theme but was kinda dickish about it and refused to contribute anything to the upstream s-t-fdo. Not sure what happened with that but if they actually accomplished anything this might be something we could steal for GNOME 3. 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: Session DBus protocol
On Mon, 25.10.10 16:01, Ryan Lortie (de...@desrt.ca) wrote: > hi, > > Vincent and I are sitting on a couch here at UDS reviewing the DBus > protocol used by gnome-session. > > I am interested in adding support to GtkApplication. > > My biggest concern is that the "emit signal and wait 1 second" approach > for checking which clients want to stop the logout from happening is > really bad. > > 1) Some clients might miss the deadline (if they are swapped, or the > system is really bogged down). Data loss here. > > 2) We may end up waiting for 1 second completely unnecessarily. > > > I was wondering if maybe we could improve this interface to work more > like the following: > > 1) Clients that may want to block the logout register themselves with > gnome-session. > > 2) gnome-session does a AddMatch on their NameOwnerChanged so it can > tell if they exited (and unregister them). > > 3) At logout time, gnome-session makes a method call to each registered > app and *waits for a reply*. The length of time to wait should be > much longer than 1 second. Similar to the close button on > unresponsive windows, we could pop up a "this application is stuck" > dialog in that case allowing the user to kill it if they explicitly > choose to (but never assuming that no reply equals "no data to > save"). Instead of having clients register with gnome-session I'd simply make them take a prefixed name on the bus. i.e. take "org.freedesktop.SessionInhibitor.Foobar" or so in an app "Foobar" (or include the PID or some other id as suffix). Then g-s should just watch all those prefixed names and log off as soon as none of them remain. And of course, add some dbus iface to the apps to make those apps quit (but I figure gtkapplication has that anyway?). In general I do believe we should use the dbus name registration for all those "registration" use cases, instead of having client-to-client registration. It's nicer for loose coupling (because clients can just take the name, and need no fallbacks/error checking in case g-s isn't around), and also more robust, and less duplication. And, last but not least, it allows for a greater amount of parallelization, which (with my systemd hat on) I can only welcome! Also, it minimizes the dbus function calls you have to do. On startup of all apps you just need to take a name, which only travels to the bus, and can be done asynchronously without expecting a reply. On shutdown of the apps, don't do anything. On session logout in many case you just need EnumerateServices, which needs to be sync. And to ping the individual clients you just need one sync msg each. I don't think it can get any better than 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: Module Proposal: Zeitgeist
On Sun, 25.04.10 22:44, Patryk Zawadzki (pat...@pld-linux.org) wrote: > On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey wrote: > > My suggestion is to support the Zeitgeist's community's culture of code > > reviews. GNOME does not have an official code review tool. Neither does > > GitHub, which is why projects that host in GitHub also use Launchpad for > > code reviews. > > Actually this is not true. GitHub lets you review any commit and the > usual workflow is fork → commit → request pull → get review. Gitorious has that too apparently: http://blog.gitorious.org/2009/11/06/awesome-code-review/ BTW: What happened to those plans to run our own gitorious instance on gnome.org or have a gnome subdomain on the real gitorious.org the way qt has? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 19:05, Zeeshan Ali (Khattak) (zee...@gmail.com) wrote:
> > Should we really keep the UI at all? The options offered therein appear
> > very esoteric to me, and a trivial addition to
> > gnome-file-share-properties that would just introduce one simple
> > checkbox "Share my Music" (and "Share my Videos", yadda yadda) seems a
> > lot more appropriate to me.
>
> Hmm.. sounds right now that I looked at that UI.
>
> > I don't see why anybody would want to disable transcoding or choose the
> > interface to listen on (Rygel should listen on all of them
> > anyway...).
>
> Agree on transcoding but not interfaces. We don't want media to be
> shared on public networks. The plan is to be able to select network by
> ESSID so user can decide where the media is shared (home) and where
> its not (office, cafe). Unless there is a better way to achieve this?
Oh, please don't.
This is absolutely nothing you should try to hack into Rygel. This needs
to be implemented system-wide as a simple firewall/profile selection
thing, possibly in networkmanager where you can choose from three simple
profiles ("home", "work", "cafe", i.e. trusted, semi-trusted, not
trusted at all, and whateever other profile an admin might want to add
in addition to those). You certainly don't seperate subsystems that
enable/disable rygel and apache+webdav+avahi independently.
Also, the ESSID is unsuitable for authentication.
We don't do this for g-u-s/apache either.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Sun, 21.02.10 14:50, Bastien Nocera (had...@hadess.net) wrote: > - The preferences UI is pretty horrible Should we really keep the UI at all? The options offered therein appear very esoteric to me, and a trivial addition to gnome-file-share-properties that would just introduce one simple checkbox "Share my Music" (and "Share my Videos", yadda yadda) seems a lot more appropriate to me. I don't see why anybody would want to disable transcoding or choose the interface to listen on (Rygel should listen on all of them anyway...). And the "plugins" pane of rygel preferences is redundant too. Rygel should use tracker if it is installed and otherwise and automatically fall back to the gvfs backend. No need to configure anything there. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 15:27, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: > > That is because you seem to be keen on admin intervention while I am > > keen on each user to be as free (from admin) as possible. :) > I do not really care about admin intervention, honestly. I just prefer > to have a single server process on my system, regardless of the number > of users. That sounds like a pretty weak argument, of the "Unix nostalgia" kind. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 14:29, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote: > > Just because others do it in a particular way, doesn't make it > > right. Although Rygel can be run as a system-wide service, the main > > target use-case is that of providing services per-user[1] so for > > example each user can choose to share his media on the network rather > > than every user's media. > That use case is perfectly served by samba - having ONE system-level > daemon and multiple per-user shared directories (controlled by users) Samba is software for big installations, and primarily used on non-desktop servers. tbh I'd find it quite useful if we could run samba from inside a user session too, the same way we can run apache in it for gnome-user-share. > > Lets assume for a second that we want rygel to run as a > > system-service, how does rygel then communicate to processes running > > on session-bus (e.g tracker, rhythmbox, totem)? > AFAIK the typical model is working the other way around. If these > process have anything to say to system-level daemons, they "initiate" > communications. CMIIW. Why is that model bad for Rygel? It would be kinda weird if a system Rygel would share the audio streams of a user PulseAudio instance. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 12:08, Sergey Udaltsov (sergey.udalt...@gmail.com) wrote:
> > From reading description, it seems to me that Rygel would be better
> > suited as system service. Just like for example mt-daapd (which seem
> > to have the same purpose as Rygel but for DAAP). How does it fit GNOME?
> Absolutely correct point! Folks, when did you decided that GNOME is
> for PCs only ("personal computers", in the worst of all possible
> interpretations - computer for one single user)? That is ok for
> tablets, smartphones etc - but not for general purpose desktop.
>
> If some computer provides media collection through UPnP/DAAP, it
> should do it as a system-level service, just like mt-daapd (even
> though it can be flexible enough to accomodate per-user dirs, just
> like apache or smb).
Well, we already run apache as part of the user session from
gnome-user-share.
GNOME is certainly focussed on the desktop, or similar user
interfaces. As such it should provide services for building user
interfaces, not server machines.
Lennart
--
Lennart PoetteringRed Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Mon, 22.02.10 09:13, Tomasz Torcz (to...@pipebreaker.pl) wrote: > > > I hate unneeded redundancy so I'll just ask you to read the home page: > > > http://live.gnome.org/Rygel > > > > pbor pointed out on IRC that I didn't really have a nice description > > on the homepage so I corrected that. Please check it out if you didn't > > understand what rygel is all about. :) > > From reading description, it seems to me that Rygel would be better > suited as system service. Just like for example mt-daapd (which seem > to have the same purpose as Rygel but for DAAP). How does it fit GNOME? I strongly disagree. Sharing user files should be a job for user processes. Why? First of all, the directory is called ~/Music, not /srv/music. You certainly don't want to have all this permission madness that you need to deal with if you run a file server like that as a system service. User file sharing should live in the user session. Also, look at the examples of bluetooth/obex and gnome-user-share. I think one should carefully distuingish between desktop file sharing and server file sharing. By desktop file sharing I mean file sharing enabled and configured by a normal user, who has a local account, and wants to quickly share files from within his active session. And as such this kind of file sharing should also run under his user ID, and follow his own access permissions (and that is actually the most important issue). UPnP A/V is certainly not a protocol datacenters will depend on, it is simply something that is handy on a peer-to-peer network of user desktops. And due to that the "desktop file sharing" model is generally more applicable to it then the "server file sharing" model. The only drawback of running file sharing services like this inside the normal user session is of course that files are not shared when the user isn't logged in. But that is something we need to fix in the bigger picture. We should not blame Rygel for the fact that there is no real infrastructure for running user daemons outside of a session. But I am sure this can and will be fixed eventually. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Rygel
On Sun, 21.02.10 14:50, Bastien Nocera (had...@hadess.net) wrote: > - The plugin API should instead be a convenience library around using > the D-Bus API, which would make implementing other front-ends to those > plugins easier. With D-Bus API you mean http://live.gnome.org/Rygel/MediaServerSpec? I thought the general approach to D-Bus these days was not to provide any wrapper libraries but have clients use the D-Bus APIs directly, with the native interfacing of their programming language/environment, be that eggdbus, python-dbus or Vala's native D-Bus support. > I guess it wouldn't be powerful enough for some plugins > though, Can you elaborate on that? Which ones do you mean? > so maybe it should be an interface with 2 possible > implementations, and the more powerful one having some extra > functionality. Hmm, I am not sure I follow? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Backup
On Wed, 18.11.09 17:06, Sandy Armstrong (sanfordarmstr...@gmail.com) wrote: > > On Wed, Nov 18, 2009 at 5:03 PM, Bastien Nocera wrote: > > On Wed, 2009-11-18 at 17:30 -0600, Michael Terry wrote: > >> Is GNOME interested in shipping an official backup program? I (as a > >> long-time lurker) haven't ever noticed discussion about it. > > > > Where's the code? :) > > https://launchpad.net/deja-dup Hmm. This doesn't even do backups on optical disks, does it? Isn't that a bit weird? I mean, I am not asking for support for tape drives, but CDs at least? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
On Tue, 10.11.09 21:58, Rodrigo Moya (rodr...@gnome-db.org) wrote: > On Tue, 2009-11-10 at 17:00 +0200, Peteris Krisjanis wrote: > > Google for 'PulseAudio Hate' and then maybe try to understand what > > dangerous road have GNOME project taken last two releases. > > > wow, I just googled, and yeah, you're right! but don't worry, we are > sending Lennart to an empty island without Internet soon, just be > patient Not sure what PA has to do with all of this, but if I google for "I Love PulseAudio" I get > 21K results. If I google for "I Hate PulseAudio" I only find < 16K results. Not sure what Peteris wanted to say, but I am quite sure that PA is not really suitable as an example for whatever it is. There are those who create and those who complain. And yes it is absolutely right if the former choose to disregard the latter, if they have reason to and they want to get things done. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Fri, 06.11.09 20:22, Alexander Larsson (al...@redhat.com) wrote: > There is one problem with POSIX_FADV_DONTNEED. If you do it on a file > the kernel will drop it from its caches. This is generally what you want > if you just indexed a 100 meg text file that no other app cares about > atm, since it means we won't throw out 100 megs of otherwise useful > caches. However, if you're reading a file that some other app actually > cares about this may be a problem, since you're now ensuring that the > file has to be re-read the next time that app wants to use the file. Not > sure if there is a better way though... Shoudln't MADV_SEQUENTIAL do this? Enables aggressive read-ahead and quick freeing according to the man page. Not sure though if the latter is actually implemented by the VM in the way we'd want it here. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound system - user perspective
On Mon, 14.09.09 08:50, Stefan Kost (enso...@hora-obscura.de) wrote: > > Unfortunately GStreamer does not have a nice API for tagging streams > > yet (this limitation can be circumvented via using environment > > variables which PA will pick up, but that's not a very nice > > solution). Also, GStreamer does not actually forward the pause request > > message to the applications and hence you'll effectively only see the > > muting taking happen, not the pause/unpause in current media players. > > > > To make this all work nicely jut a little bit glue code needs to be > > written for Gst and some minor patches be prepared for the various > > telephony apps/media players. If someone wants to pick this up and > > push this through this would be really great! > > THis is the one about tagging the stream, right > https://bugzilla.gnome.org/show_bug.cgi?id=567656 > It would be easy to implement. The reason its stalled is that as gstreamer is > abstracting various technologies, we neeed to study where this could apply and > if it's generic enough. Yepp that seems to be the bug. (Though ideally we'd have more interfaces for meta data about streams, for example some to attach a stream to a GtkWidget and so on) > Lennart, is there is ticket about the pause? I still wonder how it should be > done (just forwarding to the app so that it will pause the pipeline). Also > wonder if simmilar features could be mapped to other technologies. Finally we > ned to figure how to merge such events, as e.g. a video editor might get this > for a recording source and the playback sink (despite that a phone call should > not interruppt a recoding session, but there is a category for that too). Yesterday wtay mentioned on IRC that he wanted to look into it and that there apparently already is some infrastructure that allows downstream elements ask for state changes. Wim? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound system - user perspective
On Sun, 13.09.09 19:18, Maciej Piechotka (uzytkown...@gmail.com) wrote: > I spotted an area in which Gnome desktop can offer better user > experience. > > Imagine I use VoIP (skype, empathy or anything like that) and some music > player (Banshee, Rhythmbox etc.). I listen to some music or a podcast > when someone ring. > > I have to stop the music and answer the phone. However I guess that > music/podcast should actually be paused (i.e. state in application > should be stopped) instead of being just volume down. > > I'm not sure if current architecture would allow such integration and > probably it would require changes to few packages (music player and > empathy at least) I prefer to post the idea here firstly. This logic is actually already supported in PulseAudio and activated by default. This all depends on that applications properly tag their audio streams, i.e. so that it is clear which stream is telephony, which one is event sounds, and which one is music. Some apps have now started to do this properly. In fact the next beta of Skype will do this too. And if your favourite telephony or music app still doesn't then please complain and file a bug and ask them to read this: http://0pointer.de/blog/projects/tagging-audio.html and this: http://pulseaudio.org/wiki/ApplicationProperties The logic in PA will mute every stream tagged as "music" as soon as a stream tagged as "phone" is active. It will also send an asynchronous event to each music playing client requesting that it should pause its playback. If the "phone" stream goes away the "music" streams will be unmuted again and the apps notified that it is a good idea to unpause playback again. Unfortunately GStreamer does not have a nice API for tagging streams yet (this limitation can be circumvented via using environment variables which PA will pick up, but that's not a very nice solution). Also, GStreamer does not actually forward the pause request message to the applications and hence you'll effectively only see the muting taking happen, not the pause/unpause in current media players. To make this all work nicely jut a little bit glue code needs to be written for Gst and some minor patches be prepared for the various telephony apps/media players. If someone wants to pick this up and push this through this would be really great! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Would this be a break?
On Sat, 12.09.09 17:01, Nirbheek Chauhan (nirbh...@gentoo.org) wrote: > > On Sat, Sep 12, 2009 at 4:45 PM, Philippe Rouquier > wrote: > > I just got a patch today that add a minor feature to brasero (see > > https://bugzilla.gnome.org/show_bug.cgi?id=594954). Once applied the patch > > allow brasero to emit a sound. the code is quite small but I was wondering > > if it would be considered as a break for any of the freezes. > > This won't break UI Freeze + String Freeze if there's no option in the > menu(s) to disable it (is it supposed to be there? Or is it supposed > to be globally controlled? Lennart should know this.) With very few exceptions event sounds should be controlled globally in the sound capplet. There you can globally disable/enable event sounds or choose a different sound theme that disables or enables specific sounds. I think it would be bad UI if all apps had seperate checkboxes for enabling event sounds. (BTW, the very few exceptions I mentioned above are probably IM and email notifications. Many people receive such a high volume of emails/IMs that it is probably a good idea to allow them to disable these sounds in the application) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 21:00, Ivan Frade (ivan.fr...@gmail.com) wrote: Ivan, Thanks, this mail is very helpful! > > I guess a problem here is that nobody except the Tracker people > > themselves even know what an ontology or Nepomuk actually is. > > You can consider an ontology as high level language to describe data, a > language to write "db schemas". Why ontologies and not SQL files? In few > words, because ontologies are easier to describe the things, classify them > into a hierarchy and express their properties. > > Nepomuk was a EU-funded project about "the semantic desktop". In that > project, some research centers/companies defined a set of ontologies to > describe the desktop and wrote some code for KDE. Nowadays we use "Nepomuk" > to talk about the ontologies, and the KDE software using them is > Nepomuk-KDE. > > > Just > > throwing around buzzwords that nobody understands doesn't really help > > dumb people like me actually get a grip on what tracker actually is, > > and help them understand that it isn't what they thought it was. > > > Tracker 0.6 is a "usual" index engine: crawl the filesystem and extract > words, so the user can use those words to find the content. > > The new tracker (0.7) is pretty different. Now we have a stand-alone store > (tracker-store) with a well-define schema to store the information (Nepomuk > ontologies). That information is provided by miners: one for the filesystem > (tracker-miner-fs), another for RSS Feeds, another for Emails (a plugin in > evolution), and there could be more... (e.g. Zeitgeist could provide links > between documents). Then the queries are not (only) free text, but (also) > structured queries using categories and properties. > > The benefits? Having all the information together under a common schema, > > 1) we can _link_ the information. So you could ask: "all messages with > Martyn" and get a list of IM conversations (coming from telepathy), Email > threads (coming from evo) and his blog posts (coming from the RSS miner). > 2) we make the data more cross-application: your Bookmarks can be shared > between epiphany and firefox. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 15:15, Jamie McCracken (jamie.mccr...@googlemail.com) wrote: > > I should also add, inotify is not the ONLY technology which we have been > > discussing, setrlimit() is another and I could probably list a few > > others which we have been talking about with kernel developers. > > I would prefer if we avoid relying on kernel and inotify anyway (it will > never work on NFS in any event). We certainly dont want trackers > progress held up by kernel slackage kernel slackage? hehe. No disrespect but I am pretty sure that the kernel still gets at least a 100 times more commits per month than tracker does? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 15:12, Jamie McCracken (jamie.mccr...@googlemail.com) wrote: > > > tracker would provide a centralised storage of metadata which means > > > multiple apps can share metadata safely, get notifications when it > > > changes and know at design time what metadata is potentially available > > > (via a schema similar to gconf) > > > > Seriously. I cannot parse this. > > well that was my best attempt - sorry it would not be productive for me > to go and on about this That's a pity. > > Uh? What's the point of 'centralizing' it? I mean Epiphany can do all > > of this just fine anyway? You want to sell tracker to me listing > > features that Epiphany can do anyway? > > Epiphany does not share its metadata with anyone else nor can you cross > query it Share? With who? What does "cross query" mean? > > > 4) Make web service integration easier with optional indexing of > > > flickr/facebook > > > > flickr/facebook are indexed anyway by, ... eehr ..., flickr and > > facebook. What's tracker giving me here on top of that? > > amalgamated view with local files. Eg get me all images could show both > local files and images on facebook/flickr Wouldn't a much simpler approach of doing that in the search tool itself be the better idea here? > > Hmm? Isn't that what eds does? > > AFAIK it does not extend into web services realm but eds could use > tracker as backend and get the web ones And why not simply teach eds getting the data from the web services itself? Why stack things? We're not KDE. And what do actually the eds people things of your great plans? > > > 6) Allow common database to be used for things like music players > > > > Most people are using just one music player anyway... Do the media > > player folks actually plan to rip out the databases and replace them > > with tracker? > > If it was fast and efficient why not? It would mean less code for them > to maintain and allow users to seamlessly switch music players and get > all the tags set elsewhere "Why not" is not a good reason. If "seamlessly switching music players" is the only advantage you can come up with then please try again. Seriously. > > > 7) Allow more thin client development as minimal code would be needed to > > > integrate search and metadata in apps if done from scratch without > > > tracker > > > > Could you be more explicit please? Sounds like you hope that "more > > awesome software other people will write for us will appear one day". > > Well you would not have to write your own metadata server to get > equivalent functionality. Combined with tracker aware widgets you could > produce tracker powered apps much more quickly Hope is not a good argument here. Just hoping that you will eventually have more apps using this is not a convincing reason. With Hope you can win elections, not convince technical people. And even if you could, Tracker is not quite Obama yet, is it? ;-) > > > 8) Allow for different views of data such as get me all images instead > > > of traditional file/folder view > > > > Isn't this Nautilus' job? > > Nautilus remains wedded to file/folder > > Think media centres here So what does tracker give a media center that a simple "ls *.jpeg" (or the gvfs equivalent) wouldn't give? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 21:09, Patryk Zawadzki (pat...@pld-linux.org) wrote: > > On Tue, Aug 18, 2009 at 8:57 PM, Lennart Poettering > wrote: > > (I don't want to create the impression that I am opposed to the idea > > of a desktop search engine. I actually do believe it makes sense, but > > really, you need to do a better job selling the specific technology > > tracker does.) > > Don't think of the RDF store as Google where you enter two words and > get back top 10 results. Think of it as a database that has all kinds > of weird relations for different objects. You could ask it for the > last.fm track that was playing while you were looking at lolcat images > on the second day od GCDS while chatting with people whose last name > contained a lowercase "n" :) > > More real life examples: > > - show me all the party pics > - give me files and data related to gnome bug #123 > - list all the files I received from Lennart during the last week > (over Jabber, e-mail etc.) Nice idea, but is this even realistic? How's a UI for this supposed to look like? I mean, Google is so awesome because you type stuff in a text field with only a minimal syntax requirements and will spit out useful stuff. But how would you expose in the UI a search mask that allows you to formulate queries like "give me files and data related to gnome bug #123"? Are you planning to duplicate the bugzilla search form in the GNOME Search interface? If that's the case, then www, stop right there! This reminds me of the story of network service discovery. Back in the days there was a protocol SLP which was accepted as an RFC and blessed by all the big players. It allowed you to do searches likes "give me a list of printers on the third or seventh floor that takes A4 and does at least 600dpi". Turns out while this idea is generally nice it was completely unrealistic designing a UI for this and it is incredibly hard teaching secretaries how to formulate a query in the SLP query language -- just because they need to find a bloody printer. -- And then came mDNS/DNS-SD and drasticallly simplified this and became popular and took over the world. Again, I am not saying that the whole idea of having semantic search is stupid. But your use cases above are just lame and unrealistic. Sorry. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 18:43, Martyn Russell (mar...@lanedo.com) wrote: >>>> So you are telling me file system notification does not matter much >>>> for Tracker's usefulness? That's news to me indeed. But of course >>>> leads to the question: what is it then what it offers that desn't need >>>> file system notification? Please explain. >>> >>> Well, for a start, we don't index . prefixed directories, so for >>> applications that want to store their bookmarks, contacts, etc they can >>> use tracker for that. The Nepomuk ontology describes all of that and how >>> the data relates. Those updates do not come from file system updates, >>> they come from applications sending us data. >> >> I guess a problem here is that nobody except the Tracker people >> themselves even know what an ontology or Nepomuk actually is. Just >> throwing around buzzwords that nobody understands doesn't really help >> dumb people like me actually get a grip on what tracker actually is, >> and help them understand that it isn't what they thought it was. > > You could say the same about pulseaudio ;) Not sure this really compares that well... I didn't really play buzzword bingo that much, I guess. I often use words like 'glitch-free' and stuff, but at least I wrote a couple of blog articles about it, explaing what is supposed to be. Still waiting for a really good explanation on planet gnome what ontology or nepomuk was. It doesn't matter that you explain to everyone and his dog what tracker is about, but it would be good if at least the desktop-devel folks would understand what it was about. And as I read the comments here I am not the only one who doesn't. (but then again, this is of course a matter of perspective. Maybe I never did a better job explaining what PA is about then you did with explaining what Tracker is -- but then again I never tried to make PA a module of GNOME...) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 14:48, Jamie McCracken (jamie.mccr...@googlemail.com) wrote: > On Tue, 2009-08-18 at 20:26 +0200, Vincent Untz wrote: > > Le mardi 18 août 2009, à 20:19 +0200, Philip Van Hoof a écrit : > > > We'll do our best and are committed to formulate our answers in a > > > non-vague way and improve the communication of the project's members, > > > about the project, towards the community. > > > > Maybe just clearly state what tracker (or tracker-store, the thread > > already lost me :/) will bring to GNOME if integrated. I don't want to > > hear about ontology, sparql, data store, indexer, or whatever. I want to > > know what it will bring me as a user, and what opportunity it gives me as a > > hacker, for my modules. > > > > So, yeah. Just list use cases. (Somebody already gave a few examples in > > a mail, iirc, but it got lost in the noise for me). > > tracker would provide a centralised storage of metadata which means > multiple apps can share metadata safely, get notifications when it > changes and know at design time what metadata is potentially available > (via a schema similar to gconf) Seriously. I cannot parse this. > All metadata can be cross referenced in queries allowing for powerful > search capabilities all via a uniform api and search language > > Use cases: > > 1) Centralised storage, tagging, search and query of bookmarks for > Epiphany Uh? What's the point of 'centralizing' it? I mean Epiphany can do all of this just fine anyway? You want to sell tracker to me listing features that Epiphany can do anyway? > 2) Zeitgeist integration of events with said search and query > capabilities Hmm, I cannot really parse this either. > 3) Centralisation of all tags (nautilus, zeitgeist, fspot. > facebook/flickr etc). No need to duplicate tagging in different apps Hmm, why should this be in tracker? not in gvfs? > 4) Make web service integration easier with optional indexing of > flickr/facebook flickr/facebook are indexed anyway by, ... eehr ..., flickr and facebook. What's tracker giving me here on top of that? > 5) Allow for possibility of uniform services for things like contacts > instead of them being redefined for all clients (evolution, pidgin, web > services) - this would require a separate contacts service but a > federated db like tracker is an essential component for this Hmm? Isn't that what eds does? > 6) Allow common database to be used for things like music players Most people are using just one music player anyway... Do the media player folks actually plan to rip out the databases and replace them with tracker? > 7) Allow more thin client development as minimal code would be needed to > integrate search and metadata in apps if done from scratch without > tracker Could you be more explicit please? Sounds like you hope that "more awesome software other people will write for us will appear one day". > 8) Allow for different views of data such as get me all images instead > of traditional file/folder view Isn't this Nautilus' job? Everything you listed above is available already in other applications -- or I just don't get it. (I don't want to create the impression that I am opposed to the idea of a desktop search engine. I actually do believe it makes sense, but really, you need to do a better job selling the specific technology tracker does.) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 17:44, Martyn Russell (mar...@lanedo.com) wrote: >> And that exists? What providers are there besides the indexer? > > Yes, there are some in progress right now. So there's nothing usable yet? >>> We also are using breadth based monitoring so top level folders always >>> get priority here. >> >> That's just trying to make the best of a f*ed up situation. It's not >> even a work-around, let alone a fix. > > So we should just tell users, sorry, the kernel is shit and we can't be > arsed to *try* to make things better for you with what's available? We are in the lucky position that we are in control over the full platform here: If the kernel isn't good enough for some userspace use cases then it can be fixed. >> Also I doubt that this logic even ameliorates things. I for one tend >> to edit the leaves of my $HOME tree, not the trunk of it. You seem too >> assume that this was the other way around for most people. For me at >> least the top level directories have few (and seldomly edited) files >> in them, the deepest levels most. I mean, do you edit >> ~/projects/tracker/src/indexer.c more often that ~/indexer.c? (file >> names made up, but you get the idea) > > Right but source is less important and as I have said earlier in this > thread (and others agree) we should probably be ignoring source > checkouts. This is not about source code. It's the same for photos. I place my photos in "~/photos/2009/Gran Canaria/img_4711.jpg" not in "~/img_4711.jpg". And I edit them there too. It's the same for music. I place my music in "~/muzhak/Brazil/Sebastião Tapajós/Sebastião Tapajós - Aquarelas do Brasil/Afro Samba.mp3", not in "~/Afro Samba.mp3". >> So you are telling me file system notification does not matter much >> for Tracker's usefulness? That's news to me indeed. But of course >> leads to the question: what is it then what it offers that desn't need >> file system notification? Please explain. > > Well, for a start, we don't index . prefixed directories, so for > applications that want to store their bookmarks, contacts, etc they can > use tracker for that. The Nepomuk ontology describes all of that and how > the data relates. Those updates do not come from file system updates, > they come from applications sending us data. I guess a problem here is that nobody except the Tracker people themselves even know what an ontology or Nepomuk actually is. Just throwing around buzzwords that nobody understands doesn't really help dumb people like me actually get a grip on what tracker actually is, and help them understand that it isn't what they thought it was. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 16:11, Colin Walters (walt...@verbum.org) wrote: > > On Tue, Aug 18, 2009 at 3:32 PM, Jamie > McCracken wrote: > > > > we could use the Gtk Recent files stuff for this and that would work for > > ordinary users but not devs fetching source code or other command line > > stuff > > Unless it's really REALLY compelling and fast, I don't want my source > code in any kind of database, at least by default. We should leave > this to IDEs. Hmm, I'd personally love if I had my own little google codesearch that could quickly tell me where I already used a specific API call and how I did it. My emacs doesn't offer me that unfortunately. I believe indexing code is very very useful. And I am apparently not the only one, given that there are things like google codesearch or krugle and all the others. > The important files to index are word processor documents, graphic > files, PDFs, web browser downloads. Recent files could be used for > this with a bit of work (i know Firefox would need a patch at least). I'd assume music files are among the most important ones? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 18:55, Xan Lopez (x...@gnome.org) wrote: > > If tracker-store is not useful on its own and currently not used by > > anything else in GNOME, does it really make sense to push it into > > GNOME? > > > > Also, even if the store has uses besides the indexer, just be honest: > > does it *really* add any measurable benefit to GNOME if this is in > > GNOME if the most important user (which is the indexer) is not? > > > > Does it really make sense to push the store independantly of the > > indexer? > > Well, on one side this is the classical chicken-egg problem, isn't it? No, it's not. Many libraries have been made nothing more than maybe blessed dependencies and are nonetheless being used everywhere. I don't think it would be a good idea to use GNOME solely as a vehicle to make things more popular with other developers... Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 18:16, Maciej Piechotka (uzytkown...@gmail.com) wrote: > > Licensing wise, those libinotify and rasqal both share the LGPL, as does > > libtracker. The rest is GPLv2 or later. > > > > /discuss ;) > > > > Well. Currently there are two projects which, at least for the first > sight, are similar - Tracker and Beagle. So the first question is why > should Gnome include Tracker and not Beagle? Maybe (among other things) for the simple reason that they didn't propose it? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 16:44, Martyn Russell (mar...@lanedo.com) wrote: >> As I see it the usefulness of Tracker stands or falls with the >> scalablity of inotify. As long as inotify does not natively support >> recursive watches tracker is not viable. > > Well file monitoring really is just one part of Tracker. If you want to > keep data from your web applications (say Facebook, etc) in Tracker too, > it is completely unrelated. And that exists? What providers are there besides the indexer? >> Right now installing tracker on a non-trivially sized $HOME has the >> effect of taking away all inotify watches and thus making inotify >> unavailable for other applications. > > This is also not true. Tracker never uses ALL resources, it always > leaves 512 available for other desktop applications. Ah, interesting. It didn't do that the last time I checked. How do you verify this? by reading the sysctl and then allocating only 512 less than that? So running tracker means the sysctl is effectively set to 512 from the perspective of other apps? This is still an ugly hack, wouldn't you agree? With a vanilla kernel this leaves 7680 dirs to be watched by tracker. A single git checkout repo takes away 400 of those here. Sure, I might not be the typical user, but my music directory already has > 7000 dirs. My entire $HOME has 82283. >> -- where they usally are more >> appropriately used, such as Nautilus. And all that even without fully >> working properly since if the limit of inotify handles is reached the >> view tracker has on the file system will necessarily become >> out-of-date quickly. Or more drastically spoken: installing Tracker on >> a machine with a non-trivially sized $HOME breaks Nautilus and other >> software. > > I would also argue that some file 20 levels deep in a directory that is > never updated is quite unlikely to change and so the chances are quite > remote. > > We also are using breadth based monitoring so top level folders always > get priority here. That's just trying to make the best of a f*ed up situation. It's not even a work-around, let alone a fix. Also I doubt that this logic even ameliorates things. I for one tend to edit the leaves of my $HOME tree, not the trunk of it. You seem too assume that this was the other way around for most people. For me at least the top level directories have few (and seldomly edited) files in them, the deepest levels most. I mean, do you edit ~/projects/tracker/src/indexer.c more often that ~/indexer.c? (file names made up, but you get the idea) > Tell me about it. I would love to know that some file in folder x > changed due to the mtime change at the top most level. But actually, > from our experience with the Maemo platform, this is not portable anyway > and Windows doesn't even update the current parent's mtime when a file > changes in the folder. I would also stress that this likely varies from > file system to file system slightly. mjg59 has some ideas about this. Ping him. We were discussing this a bit at gcds with a couple of folks. > I think you clearly don't understand what Tracker 0.7 offers. It is not > ALL about the file system, in fact the file system takes a back seat and > is there as a convenience to provide the database with data. > Applications also use the data store. So you are telling me file system notification does not matter much for Tracker's usefulness? That's news to me indeed. But of course leads to the question: what is it then what it offers that desn't need file system notification? Please explain. >> As I see it Tracker is not ready for inclusion in the desktop. It >> might not be entirely Tracker's fault though, it's more the kernel's >> fault, but that doesn't change the conclusion. > > Well, again, that assumes that Tracker is all about file monitoring, > which it isn't. So, what's it about then? >> Or in short: just f*ing fix the kernel first. > > Are you volunteering? :) I am not hacking on Tracker, am I? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 18:24, Xan Lopez (x...@gnome.org) wrote: > >> The main part tracker-store is just a database with querying and is to > >> be used by zeitgeist > >> > >> If the consensus is that indexer is not suitable for inclusion then the > >> separate tracker-store should be considered for inclusion separately > >> > >> the store does not do any indexing or file monitoring nor does it cosume > >> significant resources > > > > I have no idea what "tracker-store" is. Please elaborate. It sounds as > > it was the database that is normally filled by the indexing data, but > > what could it be good for if you rip out the indexer? > > It can be used directly by applications that feed it data through an > API. Zeitgeist is an example, another could be bookmarks/history > storage in Epiphany. I might not be fully up to date on all these things, but has Zeitgeist even been submitted as a module yet? If tracker-store is not useful on its own and currently not used by anything else in GNOME, does it really make sense to push it into GNOME? Also, even if the store has uses besides the indexer, just be honest: does it *really* add any measurable benefit to GNOME if this is in GNOME if the most important user (which is the indexer) is not? Does it really make sense to push the store independantly of the indexer? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 17:26, Patryk Zawadzki (pat...@pld-linux.org) wrote: > > On Tue, Aug 18, 2009 at 5:23 PM, Lennart Poettering > wrote: > > Uh, generally bugs should be fixed, not worked around. Especially if > > they are as crucial as this one. > > Sure but getting a recursive inotify will likely take years as with > most kernel features (= development time + significant adoption time). That is not true. And even if it was, distributions tend to merge kernel patches into the distribution kernels before they are merged upstrem if it is likely that it will end up there eventually. So this is really not an argument here. We are in the lucky position to have control on the full system, the kernel as well as userspace. While the general processes might be a bit different in the end it's not that much harder to get something into the kernel than into is to get it into glib or glibc or whatever. Don't believe that the kernel folks are inacessible people one couldn't talk to. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 17:20, Patryk Zawadzki (pat...@pld-linux.org) wrote: > > On Tue, Aug 18, 2009 at 5:18 PM, Jamie > McCracken wrote: > > The indexer part is optional > > > > The main part tracker-store is just a database with querying and is to > > be used by zeitgeist > > > > If the consensus is that indexer is not suitable for inclusion then the > > separate tracker-store should be considered for inclusion separately > > > > the store does not do any indexing or file monitoring nor does it cosume > > significant resources > > Couldn't you just make gio (or gedit or OpenOffice) notify you every > time it closes a file instead of monitoring bazillions of files? I'm > not very likely to search for files I've never opened anyway. Uh, generally bugs should be fixed, not worked around. Especially if they are as crucial as this one. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 11:18, Jamie McCracken (jamie.mccr...@googlemail.com) wrote: > > The indexer part is optional > > The main part tracker-store is just a database with querying and is to > be used by zeitgeist > > If the consensus is that indexer is not suitable for inclusion then the > separate tracker-store should be considered for inclusion separately > > the store does not do any indexing or file monitoring nor does it cosume > significant resources I have no idea what "tracker-store" is. Please elaborate. It sounds as it was the database that is normally filled by the indexing data, but what could it be good for if you rip out the indexer? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, 18.08.09 13:05, Martyn Russell (mar...@lanedo.com) wrote: > Hi all, > > So we recently polled the tracker mailing list to make sure the core > developers and others interested had an opinion on GNOME module > inclusion for Tracker. You can see the thread here: > > http://mail.gnome.org/archives/tracker-list/2009-August/msg7.html > > The response was positive. So I would like to propose Tracker as a new > GNOME module. Hmm. The beef I have with Tracker (and Beagle fwiw) is that they build something on infrastructure that currently is not good enough to sustain it: inotify. inotify is simply not suitable for recursively watching $HOME, but Tracker tries that nonetheless. And that is a big big failure, it should not do that. There's something I like to call the "tracker paradox": if you have a large data set tracker is useless because inotify doesn't scale and the database is quickly out-of-date -- and if you have a small data set then you don't need a search engine and hence tracker is useless too. As I see it the usefulness of Tracker stands or falls with the scalablity of inotify. As long as inotify does not natively support recursive watches tracker is not viable. Right now installing tracker on a non-trivially sized $HOME has the effect of taking away all inotify watches and thus making inotify unavailable for other applications -- where they usally are more appropriately used, such as Nautilus. And all that even without fully working properly since if the limit of inotify handles is reached the view tracker has on the file system will necessarily become out-of-date quickly. Or more drastically spoken: installing Tracker on a machine with a non-trivially sized $HOME breaks Nautilus and other software. And no, increasing the inotify limits is a band-aid, not a fix. Oh and inotify is not the only area where the Linux file system layer is not ready to sustain Tracker, it's just the most obvious. Another thing that come to my mind is that we curently lack recursive mtimes so that tracker could identify changes on filesystems that happened while tracker was unable to access them (i.e. due to reboot, logout, hot unplug). Really guys, before pushing forward with getting this into the desktop make sure that your infrastructure is actually suitable for what you want to do. And right now it simply is not! All these things are fixable. Apple has shown that one can get all these things fixed. It's just a matter of someone sitting down and actually fixing the kernel. But as long as that hasn't happened you are roofing your house before you built its foundation. As I see it Tracker is not ready for inclusion in the desktop. It might not be entirely Tracker's fault though, it's more the kernel's fault, but that doesn't change the conclusion. Or in short: just f*ing fix the kernel first. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 22.07.09 13:40, Jason D. Clinton (m...@jasonclinton.com) wrote: > > However, for people who make their living developing GNOME software, IMHO > > it behooves them as professional open source software engineers to respect > > the requirements of the other people who will be using the code they write, > > insofar as those requirements are known up front. And right now, every > > professional GNOME developer knows up front that GNOME isn't confined to > > running on Linux, so that should figure fairly strongly into their design > > work. > > I am extremely grateful for all that Sun has done to move GNOME forward over > the years--indeed much of that has benefited everyone including Linux. But, > pardon me for pointing out the pink elephant in the room: why doesn't Sun > just admit that (Open)Solaris is a dead-end? > > I mean, we all understood that Solaris was proprietary until recently. But > now that Sun has admitted that wasn't going to work, why not just go the > next logical step? ZFS is nice and all but you *do* hold the copyright. If > the right managerial decision were to be made--say tomorrow--we wouldn't be > having this conversation and Sun wouldn't even be out any business. Please don't turn this in pointless and off-topic flamewar about the point or pointlessness of Solaris. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
On Wed, 22.07.09 12:50, Christian Fredrik Kalager Schaller (ura...@gnome.org) wrote: > A topic that was discussed in the hallways in Gran Canaria is the fact > that GNOME has gone from not letting non-linux platforms hold back > development of features (ie. introduction of HAL) to making choices that > basically means we are abandoning any attempts of allowing GNOME to run > on non-linux platforms. > > The switch from HAL to udev is maybe the clearest one, but the push > towards PulseAudio for a lot of things have the same effect, as I think > Lennart has said multiple times that none of the non-linux systems like > Solaris or FreeBSD got a sound system capable of supporting > PulseAudio. That's not really true. PA has an OSS and a SunAudio backend. It has also been ported to other systems, including Windows (though that one isn't up-to-date in the lastest PA versions), and even exotic stuff like Hurd. For PA my policy is generally to say that I am happy to merge clean portability patches, but I don't consider non-Linux systems release-critical in any way, i.e. I won't delay a release for making sure PA works on non-Linux systems, and I am happy to break non-Linux support in the process of adding a new feature somewhere, leaving it for the folks interested in the other operating systems to fix it again. Also, I make clear that I write my software focussed on Linux, and not on any other OS. It might be a good idea to adopt a similar practice in GNOME, too. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Fri, 17.07.09 09:41, Josselin Mouette (j...@debian.org) wrote: > > In all cases, pass-thru setups are too hard to setup on Linux, so it's > > not like the extra fiddling will hurt anyone (for now anyway). > > Currently, using ALSA, it’s just a check box to tick in gst-mixer. > Unless you can detect automatically whether the SP/DIF output is being > used (and it’s not always possible), I don’t know how you can make it > easier. Pass-thru by just ticking a check-box? Uh? For AC3 pass-thru the apps need to provide AC3 in the first place. And switching the apps to do that is certainly nothing you can trigger by changing an ALSA mixer control. If you mean normal PCM SPDIF, then I can tell you that PA supports that just fine. You can switch between analog and SPDIF during runtime, without even having to stop your playback. Dunno how else I could understand your remark, but to me it appears to be just bogus. > > In the future, I don't see how we could have reasonable support for the > > use cases we want to handle (say, move one stream from internal > > speakers/soundcard to USB speakers) without having something like PA > > available. Using only ALSA (or a sound system with similar capabilities > > such as OSSv4) is a dead-end. > > To do things like that with Linux, you’ve always needed JACK until now. > And if we want to cover all uses cases JACK covers, PA will end up just > reimplementing JACK. Sorry, but this is just bogus. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Wed, 15.07.09 04:46, Brian Cameron (brian.came...@sun.com) wrote: >> Why don't we remove gst-mixer, vu-meter, gnome-cd and cddb-slave2 >> completely from gnome media 2.27. People that want to keep on building >> them can use the 2.26 branch > > PulseAudio doesn't provide as much value on Solaris since > OSSv4 provides mixing functionalities directly in the OSS layer. Haha! Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Wed, 15.07.09 12:00, Patryk Zawadzki (pat...@pld-linux.org) wrote: > On Wed, Jul 15, 2009 at 11:46 AM, Brian Cameron wrote: > > Solaris continues to use gst-mixer since Solaris does not yet provide > > PulseAudio. PulseAudio doesn't provide as much value on Solaris since > > OSSv4 provides mixing functionalities directly in the OSS layer. > > Would introducing PA have any downsides? Having a common abstraction > layer for sound would likely make it easier to develop portable apps. Choosing PA because it can be used as an abstraction layer is choosing it for the wrong reasons. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Wed, 15.07.09 09:00, Diego Escalante Urrelo (die...@gnome.org) wrote: > > On Tue, 2009-07-14 at 20:02 +0200, Cosimo Cecchi wrote: > > On Tue, 2009-07-14 at 19:49 +0200, Jaap A. Haitsma wrote: > > > > > Why don't we remove gst-mixer, vu-meter, gnome-cd and cddb-slave2 > > > completely from gnome media 2.27. People that want to keep on building > > > them can use the 2.26 branch > > > > Not sure if somebody still uses gst-mixer (at least Fedora is using > > gnome-volume-control instead of it) but the README here [1] says at > > least the other three applications are disabled from the default build > > anyway, and I agree with you it's not worth the effort to patch them to > > use up-to-date platform technologies. > > > > I use it because of the simplest ever use case not yet covered by PA: > - PCM volume at 100% -> jerky sound > > PA assumes that I have PCM at 100% and I only need to adjust Master, This is not really true. PA does not care about volume 'percentages', it only cares about the dB values ALSA exports for those volume steps. And for the 'inner' controls 0dB should equal no attenuation/no amplification, i.e. be the value where you get the loudest output without having to fear clipping. > this is broken at least in my card (intel8x0) because if I were to put > PCM at 100% I would get quite jerky sound (imagine a batteries fm > radio). Right now PA only allows me to adjust Master, which is quite > useless for me. "alsactl init" should reset your control levels to 0dB, i.e. to a position where you should not get clipping. If it doesn't file a bug against ALSA. Also, on PA 0.9.16 we actually merge the volume sliders that are in the pipeline into one, where the 'outermost' slider applies the biggest volume adjustment, while the inner ones are usually fixed to 0dB. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 26.05.09 21:03, Hubert Figuiere (h...@figuiere.net) wrote: > > On 05/26/2009 08:48 PM, Lennart Poettering wrote: >> The initial Apple implementation of mDNS/DNS, which was Rendezvous >> (later renamed to Bonjour) was licensed under APSL -- which is not a >> Free Software license. > > Not to remove any argument, but for the sake of accuracy, it should be > noted that APSL 2.0 is Free Software, according to the FSF: > http://www.gnu.org/philosophy/apsl.html > > Albeit APSL 2.0 is not compatible with the GPL (like the Apache v2 > license isn't compatible with GPLv2), which is a problem when it comes > to GNOME. Hmm, Bonjour was licensed under the original APSL license when it was released. Also I think the Debian folks still don't consider it DFSG-free... But anyway, I guess it doesn't matter anymore. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Thu, 21.05.09 11:36, Matej Cepl (mc...@redhat.com) wrote: > Stefan Kost, Mon, 18 May 2009 22:39:21 +0300: > > Now that apple has closed the whole bonjour stack, I would prefer to > > build on upnp. We have gupnp, which is actively developed and fitting > > nicely here. > > a) Nothing can be more closed than closed ... which Microsoft's UPNP > IIRC. Not true. For both technologies there is freely available documentation. The UPnP docs suck ass though, apparently. ;-) > b) UPNP is known security threat and the only sensible advice to > anybody> caring a bit about security is to switch it off (on Windows, don't > know > the situation on Linux). I am pretty sure that Avahi is much more careful when it comes to security than the average upnp implementation, but generally the lower layers of upnp and mdns are equally safe or unsafe. The bad security record of UPnP stems from UPnP IGD which allows you to reconfigure routers and does provide no authentication. But if you'd build a similar technology on top of mDNS/DNS-SD it wouldn't be any better. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Thu, 21.05.09 21:30, Stefan Kost (enso...@hora-obscura.de) wrote: > > Bastien Nocera schrieb: > > On Tue, 2009-05-19 at 17:15 +0300, Stefan Kost wrote: > >> Bastien Nocera schrieb: > >>> On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote: > >>> > >>>> Shaun McCance schrieb: > >>>> > >>> > >>> > >>>>> Avahi -- Service discovery. This is used in quite a few > >>>>> places. I know some people in the past had talked about > >>>>> having a simple wrapper in GLib. How much do we push it? > >>>>> > >>>>> > >>>> Now that apple has closed the whole bonjour stack, > >>>> > >>> Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed, > >>> but it doesn't matter to us as we have our own stack in Avahi. > >>> > >>> Citation needed here. > >>> > >> See my previous email. > > > > The Wikipedia article? There's nothing there saying Apple closed the > > Bonjour stack. > > > > > >>> You might be confusing mDNS and service discovery with the protocols > >>> implemented on top of it. We want to use both UPNP and mDNS for > >>> interoperability purposes, but I don't see the point in re-coding mDNS > >>> applications to use UPNP instead > >> I just pointed to the legal situation. I know that those are two > >> different things and idealy we support them both as needed. > > > > A trademark problem? Why is that an issue to us what Apple calls their > > mDNS stack? > > > > I still don't understand what you're worried about... > > > this is from lennarts blog: > http://0pointer.de/blog/projects/bonjour-apache-license.html > would be good if avahi developers could comment here. This blog posting of mine refers to the Bonjour software. Not an abstract technology. The license of Bonjour (the software) does not matter to us at all. Since we have an independant implementation called "Avahi" which shares no code with Bonjour (the software). The license of Bonjour (the trademark) does not matter to us at all either since we don't use that for anything. All that should matter to us are mDNS/DNS-SD (the technology) and Avahi (the software) both of which are open and free. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Tue, 19.05.09 12:00, Bastien Nocera (had...@hadess.net) wrote: > > On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote: > > Shaun McCance schrieb: > > > > Avahi -- Service discovery. This is used in quite a few > > > places. I know some people in the past had talked about > > > having a simple wrapper in GLib. How much do we push it? > > > > > Now that apple has closed the whole bonjour stack, > > Huh? Bonjour (or Rendezvous as it used to be called) was BSD licensed, > but it doesn't matter to us as we have our own stack in Avahi. > > Citation needed here. Bonjour was initially APSL licensed. They switched to Apache then. It never was BSD licensed, except for a tiny header file. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
u. Which is why both technologies have their validity even if they share a bit functionality. -- If you start a new project/protocol however I'd probably recommend going for mDNS/DNSD, except for a few cases, but again I am biased and Zeeshan might disagree. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Tue, 05.05.09 23:00, Lennart Poettering (mzta...@0pointer.de) wrote: > Heya! > > Trailing whitespace sucks. git is only half as much fun when people > have trailing whitespace in their code. diffs get cluttered up by > changes that actually aren't changes. > > Many other project these days enforce pretty rigid whitespace regimes > and I wonder if that would be something to enforce globally on > git.gnome.org, too? Given that there wasn't much opposition to enforcing a more rigid whitespace regime I have now prepared this patch for gnome-common http://bugzilla.gnome.org/show_bug.cgi?id=581930 This is an easy way to enforce whitespace cleanliness and also allows folks to overwrite it if they want to. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Fri, 08.05.09 11:31, Davyd Madeley (da...@madeley.id.au) wrote: > > On Wed, 2009-05-06 at 00:01 +0200, Vincent Untz wrote: > > > Are there places where trailing whitespaces are "valid" (ie, we want > > them)? Or are the checks only looking at code files? > > It's a bit of an edge-case, but Markdown files give > trailing-double-space a meaning. Really? Just grepped through the spec, couldn't find any mention of that. Am I blind? Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Tue, 05.05.09 17:06, Behdad Esfahbod (beh...@behdad.org) wrote: > > On 05/05/2009 05:00 PM, Lennart Poettering wrote: > >> Anyway, Owen said he didn't want to fight this fight. I guess I can >> understand that, and I don't really want to fight this fight >> either. Nonetheless I think this would be good to have and the least I >> can do is mentioning this on desktop-devel and asking for opinions. So >> here I go. >> >> Opinions? > > The default git pre-commit scripts (disabled by default) has a check for > that. In cairo, we recommend enabling it (by way of chmod +x > .git/hooks/pre-commit), but with gtk-docs, it's necessary to turn that > off at times. Something to keep in mind. Maybe autogen.sh should include a "test -f .git/hooks/pre-commit && chmod +x .git/hooks/pre-commit" or so to automatically enable it by default? Would be an easy change and folks who think they have a right to override this could just move that file away. > I personally always do a "git diff" before commit, and look for > red-background blocks that represent trailing whitespace and fix them > myself. I just have these lines in my ~/.emacs: (autoload 'nuke-trailing-whitespace "nuke-trailing-whitespace" nil t) (add-hook 'write-file-hooks 'nuke-trailing-whitespace) And then I don't have to think about anything. Except that it breaks my patches for other peoples' project which don't care about trailing whitespace. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Wed, 06.05.09 00:01, Vincent Untz (vu...@gnome.org) wrote: > > This is not a question of coding style. Whatever kind of indenting > > you choose, trailing whitespace cleanliness is about making git more > > fun without losing anything. > > > > Of course, enforcing this is a controversial issue and there are many > > different ways one could implement this: > > Are there places where trailing whitespaces are "valid" (ie, we want > them)? Or are the checks only looking at code files? I was wondering about that too myself, and have asked quite a few folks if they knew any cases where trailing whitespace was intended and useful. Noone ever came up with anything. So, I am pretty sure there is no sensible use of trailing whitespace, but uh, we can never know with absolute certainty. What is pretty clear though is that trailing whitespace in .c files makes no sense, so a conservative approach could be to check just those files. (and .cc, and so on) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
