On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <jo...@antarean.org> wrote: > On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote: >> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <jo...@antarean.org> wrote: >> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote: >> >> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo >> >> developers or users had to write a fork/replacement for a core >> >> component of the system. GNOME and Emacs just need ebuilds and >> >> adapting their configuration to Gentoo-isms. Testing and bug >> >> reporting, as usual. The only code needed is some small patches for >> >> both and around 200 lines of emacslisp for site-gentoo.el." >> > >> > Funny that you mention this. There might be something similar brewing >> > for >> > users of Gnome where quite a few low-level parts will end up being >> > mandatory for Gnome: >> > >> > "...but I'm increasingly seeing talk on the >> > gnome side of the "Gnome OS", to include pulse-audio, systemd, >> > policykit, >> > udev/u* (thus forcing lvm as well, at least lvm installation tho nothing >> > forces one to use it... yet, since lvm is required for udisks), etc." >> >> I'm pretty sure the last part is false. I certainly have udisk >> installet (it's pulled by gnome-disk-utility), but I don't use LVM. So >> there. > > I don't use Gnome and haven't looked into all this. Udev also doesn't appear > to have a LVM-useflag. But as I do use LVM, I can't actually check. > Do you have "sys-fs/lvm2" on your system? > > The ebuild does list it as "RDEPEND".
Yes, I got it installed. I didn't noticed until now. Then again, it takes 1 minute to install in my puny laptop, and uses 7 Mb of hard drive. But anyhow, I was mistaken: it is forced by udisks. >> > It's a reply in the gentoo-dev thread I started. >> > >> > Requiring pulse-audio and policykit, I can understand. But requiring a >> > specific init-system for the desktop seems a bit overkill. >> >> I don't think that will happen, although certainly is what Lennart >> (and probably Kay) wants. What I think will happen is that, if >> available, GNOME will use systemd. FreeBSD does not have udev, and >> GNOME works there (with diminished functionality). >> >> That's the future, I believe: you will be able to use GNOME without >> systemd, but it will be like more awesomer with systemd. > > I still think Gnome (or any other desktop environment) should not care about > which init-system is being used. And they will not. They will only use some capabilities that a system provides, and use it if available. It's the exact same thing as udev. >> > I'm not a gnome user and am happy with my KDE-desktop. But the same post >> > also mentions KDE seems to be headed in a similar direction. Just >> > slower. >> Because it makes sense for the full-fledge desktop. Notice that >> Gustavo Barbieri (who works a lot on e17) is a heavy promoter of >> systemd. Maybe even makes sense for Xfce, but that I don't know. >> >> At the end of the day, systemd manages how to start and stop >> processes. Which is basically the task of gnome-session-manager (and >> whatever is the equivalent in KDE). > > systemd, like any init-system, should start services. > KDE has some "kde-services" like akonadi, nepomuk,... that get controlled by > the kde-system internally. I would NOT want to see these controlled by > systemd. It would be a different process from PID 1. systemd call be called with --user: every user will get it's own instance (replacing what now is controlled by gnome-session-manager and [I presume] kde-system), but that instance will be able to use all the plumbing that systemd provides. > These are running for the user that is logged in. Having these running for all > users at once leads to the multi-user-kludge that MS Windows tries to have and > for which Citrix was invented ontop of MS Windows.... As I explained, it will be an instance per user. Nothing like Windows. > We already have a decent multi-user environment, why would we want to kill > that? If I wanted a single-user system, I'd be running MS Windows. See above, you are wrong on how systemd will handle it. >> > Mind you, I do think systemd is nice and usefull on a desktop machine, >> > but I don't see much need for this on a server where the sysadmins >> > generally prefer to have a much more detailed control of what is >> > happening. >> >> I think systemd gives you that in servers. With OpenRC and Apache with >> user CGI scripts, ¿do you know how to list the httpd daemon spawned >> processes, and only those? Remember that a CGI script can double fork. >> >> With systemd is a matter of: >> >> systemctl status apache-httpd.service > > Did you look at the output of pstree? > Try "pstree -pu" and you see all the PIDs and whenever there is a "user- > switch", it also lists the new user. Yeah, and I specifically said: "do you know how to list the httpd daemon spawned processes, **and only those**?" (emphasis mine). pstree (or ps) will show the processes with **user** apache, not those spawned by httpd. >> And you can kill every process related to a daemon, no matter how many >> forks its children process make. That alone makes systemd more usefull >> for servers thatn SysV+OpenRC, I think. > > Systemd handles this through process-groups. This can be done in different > ways. Of course it can. Only systemd does it for you, including setting OOM score, IO scheduling, CPU scheduling, permissions. Everything can be done manually; and it will be possible to do it manually with systemd also. But you can manage all of that in a single well documented way using systemd. >> > Then again, I don't feel Gnome or KDE have any reason to be installed on >> > a server, but that's just how I see it. >> >> Dear evolution, of course not. Why would you install GNOME or KDE in a >> server? My two servers run with systemd, and not a single GUI library >> is installed in them. > > I consider dbus to be part of the GUI as I don't see a reason for apache, > syslog, nfs, samba,.... to be using dbus to communicate with each other. a) dbus is not part of the GUI, b) like it or not, it's the standardized IPC mechanism in Linux. If it's available, let's use it. > There are already well-tested and working mechanisms for communication where > needed. I would like for you to be more specific about them. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
