Merge branch 'master' of flubber:~hurd-web/hurd-web

1 files changed, 125 insertions, 1 deletions

diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn
index bf8ae70a..1d774307 100644
--- a/open_issues/systemd.mdwn
+++ b/open_issues/systemd.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -24,3 +24,127 @@ Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)*
 Daniel Gollub, Stefan Seyfried, 2010-10-14.
 
 Likely there's also some other porting needed.
+
+
+# IRC, OFTC, #debian-hurd, 2011-05-19
+
+    <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the
+      "systemd as dependency" and all the messages in it don't give me a bright
+      future for gnome on hurd...
+    <pochu> yeah, I've read the thread
+    <pochu> it's only a proposal so far... hopefully it'll be rejected, or they
+      will only accept the interfaces that other OSes can implement...
+    <pochu> we'll see
+    <pinotree> you can always help me with kde on hurd, would be nice ;)
+    <pochu> hehe
+    <pinotree> pochu: well, even if the depenency is rejected, the whole «don't
+      give a damn about non-linux and only bless linux for the "gnome os"» is a
+      bit... worrying attitude
+    <pochu> yeah... it doesn't come from all the community though
+    <pochu> I'm sure some people have always thought that way
+    <tschwinge> Or we could get systemd going?  :-)
+    <pochu> good luck with that :p
+    <guillem> tschwinge: haha!? :)
+    <tschwinge> That bad?
+    <guillem> tschwinge: if you mean by that forking indefinitely then maybe
+    <guillem> tschwinge: upstream has expressely stated multiple times, no
+      interest whatsoever in any kind of portability to anything non-Linux
+    <guillem> or even older Linux versions!
+    <guillem> to the point of rejecting patches, because they "clutter" the
+      source code...
+    <tschwinge> Well, then let's ``just'' implement the Linux interfaces.  :-)
+    <guillem> tschwinge: then you'll be always playing catch up
+    <guillem> tschwinge: for example several of the Linux-only things upstream
+      makes heavy use of, are pretty recent Linux-only additions to the kernel,
+      but equivalents have been present on FreeBSD for years
+    <tschwinge> Yeah.  I'm half-serious, half-joking.
+    <tschwinge> I haven't looked at the systemd code at all.
+    <guillem>
+      https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
+      for a list of its dependencies
+    <guillem> some are just glibc extensions though
+    <guillem> and some are IMO optional and should be conditionalized, but...
+    <guillem> pochu: I don't think that attitude is that old, there was a time
+      when Linux was not used widely, or even that functional, I think it has
+      been taking strength since the Linux Plumbers Cartel started :)
+    <guillem> as in one thing is not caring about anything non-Linux, the other
+      is outright rejecting portability fixes
+    <guillem> tschwinge: in any case, these "recent" events are "pissing me
+      off" to the point of having considered several times implementing
+      portable replacements for some of those Utopia projects, the problem as
+      always is time though :)
+    <guillem> tschwinge: and the issue is not only with systemd, upstart's
+      upstream has the same approach to portability, if you want to port it,
+      you'll have to maintain a fork
+    <pochu> let's create our own init system, make it better than anyone else,
+      and when people start switching to it, let's start using hurd-only APIs
+      :)
+    <tschwinge> We already had someone work on that.  Like ten years ago.  DMD.
+      Daemon Managing Daemons.  <http://directory.fsf.org/project/DMD/>
+    <guillem> the real problem with that attitude is not the lack of care for
+      portabilty, the real problem is that these people are pushing for their
+      stuff all over the stack, and most of the time deprecating their own
+      stuff after a while when they have rewritten it from scratch, leaving the
+      burden of maintaining the old stuff to the other ports
+    <guillem> witness HAL, ConsoleKit, etc etc
+    <guillem> (anyway enough ranting I guess :)
+    <tschwinge> Yeah, it's true, though.
+    <pochu> agreed
+
+
+# Requires Interfaces
+
+In the thread starting
+[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a
+[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been
+posted that contains the following list (no claim for completeness) of
+interfaces that are used in (two source code files of) systemd:
+
+  * cgroups
+  * namespaces
+  * selinux
+  * autofs4
+  * capabilities
+  * udev
+  * oom score adjust
+  * RLIMIT_RTTIME
+  * RLIMIT_RTPRIO
+  * ionice
+  * SCHED_RESET_ON_FORK
+  * /proc/$PID/stat
+  * fanotify
+  * inotify
+  * TIOCVHANGUP
+  * IP_TRANSPORT
+  * audit
+  * F_SETPIPE_SZ
+  * CLONE_xxx
+  * BTRFS_IOC_DEFRAG
+  * PR_SET_NAME
+  * PR_CAPBSET_DROP
+  * PR_SET_PDEATHSIG
+  * PR_GET_SECUREBITS
+  * /proc/$PID/comm
+  * /proc/$PID/cmdline
+  * /proc/cmdline
+  * numerous GNU APIs like asprintf
+  * SOCK_CLOEXEC, O_CLOEXEC
+  * /proc/$PID/fd
+  * /dev/tty0
+  * TIOCLINUX
+  * VT_ACTIVATE
+  * TIOCNXCL
+  * KDSKBMODE
+  * /dev/random
+  * /dev/char/
+  * openat() and friends
+  * /proc/$PID/root
+  * waitid()
+  * /dev/disk/by-label/
+  * /dev/disk/by-uuid/
+  * /sys/class/tty/console/active
+  * /sys/class/dmi/id
+  * /proc/$PID/cgroup
+  * \033[3J
+  * /dev/rtc
+  * settimeofday() and its semantics