Le samedi 05 janvier 2008 à 22:26 -0500, Casey Dahlin a écrit : > There's a few issues with prcsys internally that make it very difficult > to add the features we want (dbus etc), as well as some not-so-trivial > implementation issues (use of pthreads in a circumstance under which > they were a very poor choice), so Harald Hoyer and myself decided that a > rewrite was in order, so I went ahead and started working on a new app > (which I have titled 'rrn') which is now near feature parity with > prcsys. It would be very nice if the next-gen init system didn't limit itself to the system init part but also covered session init steps. The desktop team is dead-set against system-wide daemons¹, and as a result we've seen a flourishing of in-session "helpers", all launched in a more-or-less hackish, racish and unsatisfactory way: – when the state of the art for PA is to pretend it's ESD to be launched, there are clearly huge problems in our session init handling. – sometimes you do a ps and see stray session daemons remaining alive hours after session close – it's not uncommon for GNOME to start doing things before initialising its settings, causing users to wonder why the theme or fonts change 3s after starting an app – etc Session init and system init seem very similar problems to me, and if we ever want to go early login like windows, we'll need to coordinate session init steps with the system init steps not finished yet. Of course there are complications (you need to merge system presets and user preferences, take the kind of login² and DE into account) but the similarities should far outweight the differences. Regards, ¹ with some good and a lot of bad (IMHO) reasons ² is it so different from classical system init levels? -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
