2012/8/27 Arief M Utama <m...@arief-mulya.com> > > On 08/25/2012 08:52 PM, adi wrote: >> >> On Sat, Aug 25, 2012 at 03:00:21PM +0700, Arief M Utama wrote: >>> >>> Summary-nya gini, systemd itu dibuat oleh Redhat, upstart oleh >>> Canonical. Saat ini, dua software itu adalah "masa-depan" init-system di >>> linux. Untuk systemd sendiri, itu baru satu bagian utama dari plumbing >>> layers yang dibuat Redhat, ada beberapa hal lain. >> >> >> systemd dibuat oleh redhat? :-) kayaknya memang nggak perlu >> diterusin deh. >> > > Okeh, you got a point there, memang over simplified. > > Tapi memang main developersnya systemd dari redhat, dan jelas sekali > sepertinya redhat ingin menggunakan systemd secepatnya, dengan dipasangnya > systemd di fedora yang notabene adalah testing-ground untuk distro2 > enterprise-nya redhat. > > > >> kalau toh nanti debian pakai >> systemd, itu bukan karena mengekor redhat, tapi karena mereka >> sudah menemukan cara bagaimana systemd bisa comply dengan policy >> pemaketan debian. dan sejauh ini belum. >> > > Nah itu maksudnya, kalo debian gak sempet2 juga nemuin cara systemd bisa > comply (bukan dengan pemaketan, tapi dengan keseluruhan system, saat ini > systemd sudah dipaketkan dan bisa dicoba di debian), well, ada 3 pilihan > sepertinya, > > 1. debian pakai systemd (port2 lainnya terpaksa diturunkan levelnya atau > prioritasnya) => hilangnya kebebasan debian dalam mengembangkan sendiri > distronya. > > 2. atau debian ga pakai systemd tetap dengan sysvinit (atau alternatifnya > yang masih kompatibel) dengan resiko harus maintain sendiri udev. Apakah > debian punya resources-nya? > > 3. atau debian work with BSD dan bikin systemd works in there, unlikely, > karena ketergantungan systemd dengan fitur2 linux, dan Lennart jelas2 bilang > ga mau support OS lain, artinya akan susah integrasikan patches2 untuk bsd > di main-tree. > > Sebenarnya ketiga pilihan itu secara tidak langsung ditentukan oleh redhat > juga. Kalau saja redhat mau support develop systemd yang lebih portable, > mungkin ga sesulit itu kondisinya. Atau ada pilihan lain?
http://lwn.net/SubscriberLink/512719/b09926fd0aefd768/ Debian looks at OpenRC [LWN subscriber-only content] By Jake Edge August 22, 2012 While Debian has discussed systemd—and Upstart—over the past year or more, that's not the whole story: another potential init replacement has appeared on the debian-devel mailing list. OpenRC is a Gentoo Linux project that was proposed as an alternative to the venerable System V init (sysvinit) that is currently the Debian default. That proposal spawned a long thread, even by debian-devel standards, and a more recent revival of the topic is adding more to the discussion. Though OpenRC has some features that sysvinit lacks, it doesn't bring the number of new features that systemd or Upstart do, so it makes some in the Debian community wonder whether it makes sense to add yet another init replacement into the mix. OpenRC developer Patrick Lauer suggested that Debian look at OpenRC back in April. It is, he said, a "modern, slim, userfriendly init system with minimal dependencies". It would add support for stateful services (e.g. only one instance will be running at a given time), and dependency-based init scripts, without requiring all of what something like systemd requires ("dbus? udev? on my server?! and you expect a linux 3.0+ kernel? waaah!"). It would be a step up from sysvinit, while still in keeping with the "Unix way". In addition, it supports both Linux and the BSDs, which would eliminate one of the bigger gripes against systemd. But an incremental improvement to init is not what some are looking for. To many, sysvinit and other shell-script-based solutions have not kept up with the changing hardware and kernel environment, so an event-based init is the right way forward. As Arto Jantunen put it: Reliability in the case of modern kernels and modern hardware means event based, not static. The hardware in a modern computer comes and goes as it pleases (usb devices being the worst example, but scanning for pci or sata busses and loading drivers isn't exactly instant in all cases either), and the kernel has little choice in the matter. It can either sleep until "everything is surely detected by now" before passing control to userspace, or pass control and the problem along (by providing event notification when the device set changes). The kernel made its choice about this years ago, and we have been living on borrowed time and kludges since then. As might be expected, there are plenty of folks who don't quite see things that way. While there are vocal advocates of systemd—and rather less vocal Upstart advocates—there are numerous opponents as well. OpenRC might provide something of a middle ground as Roger Leigh described: While as others have mentioned that ideally a more dynamic init system such as systemd or upstart is where I think the general consensus is (we all know that sysvinit/insserv is flawed in many ways, even if we can't agree on what should replace it), there is always the possibility of having OpenRC as a sysvinit alternative in the interim, or potentially as a systemd/upstart alternative longer term. To that end, Leigh started looking more closely at OpenRC, with an eye toward packaging it for Debian. One problem that he noted early on was the lack of support for LSB dependencies in the init scripts. The LSB headers are comments that specify the runtime dependencies for each init script. OpenRC has its own dependency system, but Leigh believed that LSB dependency handling could be added to OpenRC. Over the intervening months, that is exactly what happened. On August 9, Benda Xu posted an intent to package (ITP) for OpenRC, which restarted the discussion. Leigh noted that Xu had gotten OpenRC to work with the LSB-based Debian init scripts, so that it could be a replacement for the sysv-rc package (which handles changing runlevels, starting and stopping services, and so on), while still using the init and scripts provided by sysvinit underneath. In addition, the OpenRC upstream is working on ways to allow other tools to access its dependencies, which would allow systemd or others to use OpenRC scripts. He concluded: Working on getting OpenRC to work on Debian is not without value. For me, the entire point of the exercise is to explore the [feasibility] to port it and evaluate it as an alternative/replacement for sysv-rc; this is almost completely orthogonal to work on systemd/upstart, which will for the most part be unaffected by this. Supporting multiple init systems is not without a cost, of course. There are now (or soon will be) at least four different kinds of configuration for init "scripts" (sysvinit, OpenRC, systemd, Upstart). While systemd and Upstart can use existing init scripts, and OpenRC is getting there as well, doing so loses much of the benefit of the alternatives. To some, there is simply an impedance mismatch between static dependency-based systems and those that are event-driven—though systemd advocates might not completely agree with the "event-driven" characterization. As Russ Allbery put it: And lest someone think this is a theoretical exercise, we *frequently* get bugs filed against packages like OpenAFS, the Kerberos KDCs, or OpenLDAP that are boot-order-dependent and network-dependent and either don't start or start in unuseful ways or at unuseful times because of lack of event notification for when interfaces are *actually* ready or when network devices are *really* available. Allbery said that these kinds of problems were not easily solvable with the existing init scripts: "The alternative is to add [significant] additional complexity to every package like those listed above that needs the network to loop and retry if the network isn't available when it first starts." That would be a "huge waste of effort". One of the potential blockers for systemd, though, has been its reliance on Linux-only features, which makes it problematic for Debian GNU/kFreeBSD (and Debian GNU/Hurd down the road). OpenRC might not provide all of the features that systemd (and Upstart) do, but it could be enough of an upgrade to sysvinit that it makes sense to make that switch. That might actually pave the way for an event-driven init default for Debian GNU/Linux as Philip Hands described: As a largely disinterested observer, it seems that this might at least provide a route to being able to provide enough support of the the features that make the systemd/upstart folk dizzy with excitement, such that non-linux platforms don't end up acting as a blocker for one of those two to be adopted for linux, while OpenRC covers non-linux enough so that init-agnostic start-up scripts can work anywhere. At least some in the Debian community are particularly annoyed by the systemd team's unwillingness to take patches for portability to kernels beyond Linux. That led Adam Borowski to jokingly dismiss OpenRC because it lacks "a hostile upstream". More seriously, Leigh pointed out that OpenRC uses some of the same features as systemd, but does so with portability in mind: OpenRC can (on Linux) use cgroups and hence do some of the more advanced stuff that systemd does. Yet it still runs on other platforms. This is in part due to the fact that OpenRC is written to be portable, while the systemd developers have an [astoundingly] bad attitude with respect to this. It would be perfectly possible for systemd to support other platforms if they really wanted to; it probably wouldn't even be that hard. Others see it somewhat differently (of course). Maintaining a package for multiple platforms has its costs, and for a low-level package like systemd those costs may be rather high. It's not that the systemd upstream is "hostile", according to Matthias Klumpp, but that systemd is difficult to port and its developers don't want to maintain an #ifdef-heavy code base. Instead, the systemd folks suggest forking systemd and maintaining a parallel repository for any ports. But that isn't easy, Klumpp said: "So far nobody has created a non-Linux fork of systemd, and the reason is mainly that it is too much work." There is also the underlying question of just how much "choice" there should be in a distribution's init system. Setting aside the "Linux is about choice" disagreements that always seem to arise in these kinds of discussions, there is a real question about how many different options Debian can and should support. As Allbery noted, Debian does not support switching to a different C library, for example. But Faidon Liambotis countered that it was only because no one had ever tried to show the "viability and usefulness" of switching to something other than glibc. Furthermore, things like kFreeBSD or building Debian with LLVM did not come about by some kind of consensus, rather it was due to someone deciding to make it work. For init systems, though, Leigh believes that if OpenRC proves to be a viable replacement, it should supplant sysv-rc, rather than providing a choice. It wouldn't resolve the question of defaulting to an event-driven init (for Linux at least), but it would allow the rest of the Debian community to "get on with life while the upstart and systemd folk take chunks out of one another for a decade or so", as Hands put it. While Linux may not be about choice exactly, its users are certainly accustomed to being able to fairly easily switch between different technologies: distributions, kernels, desktops, mail servers, web browsers, and so on. In some respects, Debian users are even more acclimated to a wide variety of choices. Its package repository is renowned for its breadth, and the distribution as a whole seems intent on providing choices whenever it is technically feasible. It is too soon to say for sure, but the addition of OpenRC may well provide a bridge that would upgrade init for those who aren't convinced of the "event-driven future", while staying out of the way of the systemd and Upstart efforts. -- Berhenti langganan: linux-aktivis-unsubscr...@linux.or.id Arsip dan info: http://linux.or.id/milis
