1 |
On Sat, Sep 17, 2011 at 2:45 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
2 |
> On Friday, September 16, 2011 10:53:47 AM Canek Peláez Valdés wrote: |
3 |
>> On Fri, Sep 16, 2011 at 5:08 AM, Joost Roeleveld <joost@××××××××.org> wrote: |
4 |
>> > On Thursday, September 15, 2011 05:05:00 PM Canek Peláez Valdés wrote: |
5 |
>> >> "Last time I checked, neither GNOME nor Emacs demanded that Gentoo |
6 |
>> >> developers or users had to write a fork/replacement for a core |
7 |
>> >> component of the system. GNOME and Emacs just need ebuilds and |
8 |
>> >> adapting their configuration to Gentoo-isms. Testing and bug |
9 |
>> >> reporting, as usual. The only code needed is some small patches for |
10 |
>> >> both and around 200 lines of emacslisp for site-gentoo.el." |
11 |
>> > |
12 |
>> > Funny that you mention this. There might be something similar brewing |
13 |
>> > for |
14 |
>> > users of Gnome where quite a few low-level parts will end up being |
15 |
>> > mandatory for Gnome: |
16 |
>> > |
17 |
>> > "...but I'm increasingly seeing talk on the |
18 |
>> > gnome side of the "Gnome OS", to include pulse-audio, systemd, |
19 |
>> > policykit, |
20 |
>> > udev/u* (thus forcing lvm as well, at least lvm installation tho nothing |
21 |
>> > forces one to use it... yet, since lvm is required for udisks), etc." |
22 |
>> |
23 |
>> I'm pretty sure the last part is false. I certainly have udisk |
24 |
>> installet (it's pulled by gnome-disk-utility), but I don't use LVM. So |
25 |
>> there. |
26 |
> |
27 |
> I don't use Gnome and haven't looked into all this. Udev also doesn't appear |
28 |
> to have a LVM-useflag. But as I do use LVM, I can't actually check. |
29 |
> Do you have "sys-fs/lvm2" on your system? |
30 |
> |
31 |
> The ebuild does list it as "RDEPEND". |
32 |
|
33 |
Yes, I got it installed. I didn't noticed until now. Then again, it |
34 |
takes 1 minute to install in my puny laptop, and uses 7 Mb of hard |
35 |
drive. But anyhow, I was mistaken: it is forced by udisks. |
36 |
|
37 |
>> > It's a reply in the gentoo-dev thread I started. |
38 |
>> > |
39 |
>> > Requiring pulse-audio and policykit, I can understand. But requiring a |
40 |
>> > specific init-system for the desktop seems a bit overkill. |
41 |
>> |
42 |
>> I don't think that will happen, although certainly is what Lennart |
43 |
>> (and probably Kay) wants. What I think will happen is that, if |
44 |
>> available, GNOME will use systemd. FreeBSD does not have udev, and |
45 |
>> GNOME works there (with diminished functionality). |
46 |
>> |
47 |
>> That's the future, I believe: you will be able to use GNOME without |
48 |
>> systemd, but it will be like more awesomer with systemd. |
49 |
> |
50 |
> I still think Gnome (or any other desktop environment) should not care about |
51 |
> which init-system is being used. |
52 |
|
53 |
And they will not. They will only use some capabilities that a system |
54 |
provides, and use it if available. It's the exact same thing as udev. |
55 |
|
56 |
>> > I'm not a gnome user and am happy with my KDE-desktop. But the same post |
57 |
>> > also mentions KDE seems to be headed in a similar direction. Just |
58 |
>> > slower. |
59 |
>> Because it makes sense for the full-fledge desktop. Notice that |
60 |
>> Gustavo Barbieri (who works a lot on e17) is a heavy promoter of |
61 |
>> systemd. Maybe even makes sense for Xfce, but that I don't know. |
62 |
>> |
63 |
>> At the end of the day, systemd manages how to start and stop |
64 |
>> processes. Which is basically the task of gnome-session-manager (and |
65 |
>> whatever is the equivalent in KDE). |
66 |
> |
67 |
> systemd, like any init-system, should start services. |
68 |
> KDE has some "kde-services" like akonadi, nepomuk,... that get controlled by |
69 |
> the kde-system internally. I would NOT want to see these controlled by |
70 |
> systemd. |
71 |
|
72 |
It would be a different process from PID 1. systemd call be called |
73 |
with --user: every user will get it's own instance (replacing what now |
74 |
is controlled by gnome-session-manager and [I presume] kde-system), |
75 |
but that instance will be able to use all the plumbing that systemd |
76 |
provides. |
77 |
|
78 |
> These are running for the user that is logged in. Having these running for all |
79 |
> users at once leads to the multi-user-kludge that MS Windows tries to have and |
80 |
> for which Citrix was invented ontop of MS Windows.... |
81 |
|
82 |
As I explained, it will be an instance per user. Nothing like Windows. |
83 |
|
84 |
> We already have a decent multi-user environment, why would we want to kill |
85 |
> that? If I wanted a single-user system, I'd be running MS Windows. |
86 |
|
87 |
See above, you are wrong on how systemd will handle it. |
88 |
|
89 |
>> > Mind you, I do think systemd is nice and usefull on a desktop machine, |
90 |
>> > but I don't see much need for this on a server where the sysadmins |
91 |
>> > generally prefer to have a much more detailed control of what is |
92 |
>> > happening. |
93 |
>> |
94 |
>> I think systemd gives you that in servers. With OpenRC and Apache with |
95 |
>> user CGI scripts, ¿do you know how to list the httpd daemon spawned |
96 |
>> processes, and only those? Remember that a CGI script can double fork. |
97 |
>> |
98 |
>> With systemd is a matter of: |
99 |
>> |
100 |
>> systemctl status apache-httpd.service |
101 |
> |
102 |
> Did you look at the output of pstree? |
103 |
> Try "pstree -pu" and you see all the PIDs and whenever there is a "user- |
104 |
> switch", it also lists the new user. |
105 |
|
106 |
Yeah, and I specifically said: "do you know how to list the httpd |
107 |
daemon spawned processes, **and only those**?" (emphasis mine). pstree |
108 |
(or ps) will show the processes with **user** apache, not those |
109 |
spawned by httpd. |
110 |
|
111 |
>> And you can kill every process related to a daemon, no matter how many |
112 |
>> forks its children process make. That alone makes systemd more usefull |
113 |
>> for servers thatn SysV+OpenRC, I think. |
114 |
> |
115 |
> Systemd handles this through process-groups. This can be done in different |
116 |
> ways. |
117 |
|
118 |
Of course it can. Only systemd does it for you, including setting OOM |
119 |
score, IO scheduling, CPU scheduling, permissions. Everything can be |
120 |
done manually; and it will be possible to do it manually with systemd |
121 |
also. |
122 |
|
123 |
But you can manage all of that in a single well documented way using systemd. |
124 |
|
125 |
>> > Then again, I don't feel Gnome or KDE have any reason to be installed on |
126 |
>> > a server, but that's just how I see it. |
127 |
>> |
128 |
>> Dear evolution, of course not. Why would you install GNOME or KDE in a |
129 |
>> server? My two servers run with systemd, and not a single GUI library |
130 |
>> is installed in them. |
131 |
> |
132 |
> I consider dbus to be part of the GUI as I don't see a reason for apache, |
133 |
> syslog, nfs, samba,.... to be using dbus to communicate with each other. |
134 |
|
135 |
a) dbus is not part of the GUI, b) like it or not, it's the |
136 |
standardized IPC mechanism in Linux. If it's available, let's use it. |
137 |
|
138 |
> There are already well-tested and working mechanisms for communication where |
139 |
> needed. |
140 |
|
141 |
I would like for you to be more specific about them. |
142 |
|
143 |
Regards. |
144 |
-- |
145 |
Canek Peláez Valdés |
146 |
Posgrado en Ciencia e Ingeniería de la Computación |
147 |
Universidad Nacional Autónoma de México |