[gentoo-user] JDK 7 on server
Hello, I'm planning to run GlassFish on my server. I'm pondering whether I should just go away with the default icedtea-bin package or use oracle-jdk-bin. I'll be renting out services to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Java EE will work perfectly with icedtea-bin? Automatic update is also an issue. Emerge will do it for me in case of icedtea-bin but not in case of Oracle JDK .. or is there some other option? (Non-portage solution is okay, something is better than nothing.)
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. As for all the other supposed benefits of systemd - I don't see them in my world; perhaps they do exist in someone else's worls, I can't really comment on that. But they don't exist in mine and therefore that makes systemd's solutions theoretical for me. Everything I might like in systemd is already implemented in OpenRC so I have no compelling need to switch. Besides, my computers do not break when they boot and shutdown, service management works reliably and well, there are no race conditions on boot that affect me and I still to this day do not understand why I would need cgroups at all. Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. Systemd is there, Gnome decided to use it. the Gnome team could just as easily have decided to not use it, or use bits of it, or whatever. Using systemd in Gnome was a choice, not something that had to be done due to a constraint. So overall, systemd might very well solve a particular vertical problem (point to them if it does), but I truly do not see how it can be the OneTrueInitSystem, the One That In The Darkness Binds Us. My 0.02 millicents -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. If you believe so (like I and many others do), then systemd is several orders of magnitude better than OpenRC. If you don't believe so (like many... although apparently they are less and less as time goes by), then systemd is the spawn of the devil and it should be killed with fire. For General Purpose Linux distributions, systemd is a godsend since it solves and centralizes a lot of stuff that matters to a lot of people. It's fast and small (if you remove the optional dependencies), so the embedded guys like it. It offers (for the first time ever) proper daemon control and management and O(log n) access logs, so the server guys like it. And if offers proper session monitoring and seat control, so the desktop guys like it too. But all those advantages only will be so, if you agree with having a tightly integrated plumbing interface directly above the kernel and below PAM and/or X (soon Wayland) sessions. It gets kind of philosophical, which is why a lot of people taunts the fuzzy term UNIX philosophy so much when they rave against systemd. As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc It's because they are cons only if you agree with systemd's view of the world. I do. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 16 Feb 2014 16:50:26 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. If you believe so (like I and many others do), then systemd is several orders of magnitude better than OpenRC. If you don't believe so (like many... although apparently they are less and less as time goes by), then systemd is the spawn of the devil and it should be killed with fire. For General Purpose Linux distributions, systemd is a godsend since it solves and centralizes a lot of stuff that matters to a lot of people. It's fast and small (if you remove the optional dependencies), so the embedded guys like it. It offers (for the first time ever) proper daemon control and management and O(log n) access logs, so the server guys like it. And if offers proper session monitoring and seat control, so the desktop guys like it too. But all those advantages only will be so, if you agree with having a tightly integrated plumbing interface directly above the kernel and below PAM and/or X (soon Wayland) sessions. It gets kind of philosophical, which is why a lot of people taunts the fuzzy term UNIX philosophy so much when they rave against systemd. As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc It's because they are cons only if you agree with systemd's view of the world. I do. I think what people primarily object to is not the parts that systemd does well or does better than other init process start up systems. The main objection from what I understand is the removal of choice that systemd developers have forced upon users, by making certain architectural decisions. These are decisions which may look optimal for RHL, but appear to be less so for the rest of the *nix ecosystem given the objections to systemd across the populace. For some Gentoo users in particular, removing the choice of running /usr on a separate partition (without *forcing* the use of initramfs) created the first pain point, or wakeup call. Many complaints were posted on this M/L, centering on this removal of choice. Unlike binary distros Gentoo is all about choice, so the complaints were perhaps louder than elsewhere. People speaking of *nix design philosophy are not necessarily having a rant, but can be legitimately concerned that architectural decisions to hardwire systemd into Linux will remove choice from its wider user base. I am similarly concerned that a monoculture has less success of survival. The fact that Debian decided to embrace the systemd option will no doubt have an impact on what Gentoo follows. I am not educated in init start up systems to know why other options were not considered as part of the Debian debate. Is it that runit, or epoch or what- else are not even close in terms of functionality, versatility and choice? Framing a question can narrow the answers. I hope that
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 15.02.2014 16:16, schrieb Tanstaafl: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. Read it here: http://vsido.org/index.php?topic=653.45 I'd really like to see a similar discussion/debate by those far more knowledgeable than I with respect to systemd vs OpenRC, but the above does bring up a lot of salient points. http://ewontfix.com/14/
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 17:50, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. or it is an idiotic decision. Because features means complexity. Complexity means bugs. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. You know, the unix way. Do one thing, do it well. Use text to communicate. That stuff. That makes things easy. And flexible. And replaceable.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 20:50, Canek Peláez Valdés wrote: [ ... ] It's because they are cons only if you agree with systemd's view of the world. I do. Isn't there too many if you believe and if you agree? A church of systemd? ;) I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote: On 16.02.2014 20:50, Canek Peláez Valdés wrote: [ ... ] It's because they are cons only if you agree with systemd's view of the world. I do. Isn't there too many if you believe and if you agree? A church of systemd? ;) I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 23:26, Mick wrote: On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote: [ ... ] But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: Sorry, by the time Volker posted his message, I was already writing mine. ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? Do you disagree with my statement that in near future 90% of new distro versions will be systemd-based? Or with some other statement of mine? If the former, then I intentionally put it down to money with no regard to technical performance because money is usually what ultimately matters for maintainers. From a Software User's POV, as I said, I agree that systemd is a load of bul^W things whose significance is at the least overrated. From a technical POV, I bet, most systemd's cookies could be implemented within any other init system as well, if required. But in the Real World, software users either develop theirs own if they have the resources, or get what they are given by those who have. So my whole message was about -- whether OpenRC/upstart/anything guys have resources to show'em or eventually fall to systemd. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 12:31 PM, Mick michaelkintz...@gmail.com wrote: [ snip ] well or does better than other init process start up systems. The main objection from what I understand is the removal of choice that systemd developers have forced upon users, by making certain architectural decisions. These are decisions which may look optimal for RHL, but appear to be less so for the rest of the *nix ecosystem given the objections to systemd across the populace. I'm sorry, but what is being forced on whom? Everything is Free Software, anyone can choose to use SysV, OpenRC, or Upstart if they so do desire. *Someone* needs to support that software, though. In the case of SysV and OpenRC, I don't think they will have problem; they will probably live forever. Upstart, on the other hand, could be easily be dead in a couple of months: its original author actually endrses systemd [1]. For some Gentoo users in particular, removing the choice of running /usr on a separate partition (without *forcing* the use of initramfs) created the first pain point, or wakeup call. That has nothing to do with systemd, nor udev; they actually work with /usr in another partition, they just print a warning. And presently OpenRC also requires an initramfs if you have /usr on another partition. Again, that is not *forcing* anything on anyone. It's just maintainers (Gentoo devs in the case of Gentoo's council decision) limiting the total number of supported combinations, because the number of developers/maintainers we have is finite. Again, if anyone wants *every*, possible combination, *someone* has to write the software to support them. Many complaints were posted on this M/L, centering on this removal of choice. Unlike binary distros Gentoo is all about choice, so the complaints were perhaps louder than elsewhere. Gentoo and Linux in general are about choice, as long as someone is willing and able to write the software to support that choice. People speaking of *nix design philosophy are not necessarily having a rant, but can be legitimately concerned that architectural decisions to hardwire systemd into Linux will remove choice from its wider user base. *Any* choice will be *always* available as long as someone willing and able to write the software to support that choice. I am similarly concerned that a monoculture has less success of survival. I think that's a legitimate concern, but it's again kind of philosophical; all the software it's out there: systemd, Upstart, OpenRC, SysV, the kernel (including all the versions from the last 22 years), GNOME, KDE, etc., and it's libre. If systemd dies, we will replace it with something cooler. I'm willing to bet the functioning of all my machines to that (as I'm currently doing). The fact that Debian decided to embrace the systemd option will no doubt have an impact on what Gentoo follows. For sure. I am not educated in init start up systems to know why other options were not considered as part of the Debian debate. Is it that runit, or epoch or what- else are not even close in terms of functionality, versatility and choice? Framing a question can narrow the answers. I don't know those init systems enough to give you an answer. What I do know if that none of them has the momentum of systemd, or as many developers (and their undeniable talent), as systemd. But who knows, if someone willing and able keeps punching at it (with code, not rants), maybe from there it will come the next big thing. I hope that whatever the Gentoo decision may be one day, it will not irreversibly remove choice from us Gentoo-ers. The only way a choice will be always available, is that someone is willing and able to write the software to support it. It's really that simple. Regards. [1] https://plus.google.com/u/0/+ScottJamesRemnant/posts/4eHMc2tvp7C -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. All the configuration and APIs are documented, public and open source. Everything is replaceable if there is someone willing and able to write a replacement. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. That's how free software works. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... I don't think neither time nor money had to do with Debian's (nor Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision. It's just technically superior. But's that's just my opinion, and what I believe ;) So, amen? :D Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. There is actually little code inside PID 1; most of systemd functionality comes from separated binaries. You know, do one thing, do it right? From [1]: If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). You can get rid of *everything*, if so you desire. But *someone* needs to write/patch the code. Regards. [1] http://0pointer.de/blog/projects/the-biggest-myths.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:27, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. There is actually little code inside PID 1; most of systemd functionality comes from separated binaries. You know, do one thing, do it right? From [1]: If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. and all are linked (not compilelink) in such a manner that you can't just pick and choose. Oh no, you get the full treatment if you like it or not. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). yeah, as soon as everybody had worked out devfs it got scrapped. As soon as hal was usable, it was replaced with something new, that never stopped changing since then. And then came pulseaudio. The solution to a problem that does not exist. And because of pulseaudio, all the things that led. to systemd happened. You can get rid of *everything*, if so you desire. But *someone* needs to write/patch the code. Regards. [1] http://0pointer.de/blog/projects/the-biggest-myths.html I am not trusting the people who lied about udev.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? Besides - why is garbage essential for booting in /usr? Looks broken. Broken by design. The worst form of broken. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. oh really? because everything is done by the magical Pöttering? All the configuration and APIs are documented, public and open source. Everything is replaceable if there is someone willing and able to write a replacement. and that has been debunked by others.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:19, schrieb Canek Peláez Valdés: Why GNOME started using it? because of redhat. Seriously, you had to ask that?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. Besides - why is garbage essential for booting in /usr? Is not. Most of it is optional, in a server I have there are much less binaries. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. But it does, you can cat with journalctl; it's one of its output options: -o, --output= cat generates a very terse output only showing the actual message of each journal entry with no meta data, not even a timestamp. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. oh really? because everything is done by the magical Pöttering? OK, sorry, I thought you wanted to have a civil, serious, technical conversation. I'm done with you in this thread. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/2014 20:11, Samuli Suominen wrote: On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to? It's a poor design. It's also unmaintained currently. But I don't want to debate consolekit, it's OT for this thread. It runs on my machines currently because ebuilds pulled it in. It seems to do what it should, so for the moment I'm happy to leave it in place. But I don't regard it as a good design, it's one of those things I list in the risk register in my head and keep an eye on as I consider it brittle. I only brought it up as an example, an illustration of my position. If you feel it's a lousy analogy then so be it, but I'd rather not detract from the topic of the thread, which is systemd. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] JDK 7 on server
On Sun, 16 Feb 2014 14:14:24 +0530 Nilesh Govindrajan m...@nileshgr.com wrote: rvices to customers, so compatibility is definitely a concern. I'm not exactly sure what the differences are between Oracle JDK OpenJDK; the differences I found so far on Google are old and make sense only for Java 6. Hello, To my understanding, Oracle JDK binary is created from the source code released from the OpenJDK project with some Oracle's own propriety code. The other difference is Oracle's JDK binary is released under Oracle Technology Network Developer License Terms for JAVA EE SDK,JDK where as OpenJDK code is under GPL + linking exceptions. More info at: https://blogs.oracle.com/henrik/entry/java_7_questions_answers Best regards ED -- Learing Linux with Gentoo to earn LPIC1.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/14 23:28, Alan McKinnon wrote: On 16/02/2014 20:11, Samuli Suominen wrote: On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to? It's a poor design. It's also unmaintained currently. How long has it been since Debian decided to go with systemd? Like, three? So, up until three days ago I would have disagreed since despite original upstream ditching ConsoleKit, it was still being maintained by Debian and Gentoo maintainers (me) and last release, 0.4.6, was in fact a result of that. But still, the fact that there is no more active development, doesn't mean it's obsolete. It still works fine as it ever did and there has been no need to cut any of it's features for any reason. Since logind works only on systemd, ConsoleKit is nothing less than what dhcp-client is to dhcpcd. So, it's definately not 'deprecated', or 'obsolete'. I call it 'mature'. Many BSDs still use it, and with Xfce upstream including a OpenBSD developer, and Xfce's commitment to keeping it working with BSDs in otherway too, I'm not worried about it becoming one of these nasty words of 'unmaintained', 'deprecated', 'obsolete' and co. even if I didn't do the legwork myself. So no, we don't get to blame ConsoleKit for any of this what has been happening. Take my word for it, it's not going to go anywhere from Portage anyday soon. But OK, it's a bit off-topic to this thread, I'm just getting ugly itch when people are so eager to call it anything else than mature despite it still working fine. - Samuli
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
17.02.2014 00:19, Canek Peláez Valdés пишет: On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Even religious. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). Oh I have read so many discussions already... :) To me, systemd's technical superiority is far not obvious. Just another init system would be, but as long as systemd is much more that one, I can't say that. It should NOT be compared to OpenRC / upstart alone, rather to a whole bunch of tools it replaces, and probably even those it's ambitious to replace. I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Well, I said that technical superiority matters little for maintainers; what matters is money. If I'd write some super-puper fancy init system and kernel replacement, who would be interested? It's not the time of Linus' rise, now you don't deal with USENET freaks, but with Intel, RedHat and other billionaire corps. Do you have the guts and means to keep up with competitors, even not about kernel/init subsystems, but a user app like mailer/browser/messenger... A kernel subsystem requires much more technical competence to maintain and is far more critical for functioning, so much more important here is not any 'technical superiority' but simply resources, human and financial, spared if using RH-maintained systemd. Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. Once you mentioned technical superiority, let's compare other stuff technically too. :) A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. You don't care about Emacs and Inkscape but do you care the same nought about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks HTTP rather than SHiTP? Do you care that once after a couple of years your systems get unmaintained and unmaintainable because the software on them becomes a load of bashed up crap which only a world's head lennart can deal with? Well, you'll say that red hat tralala, but we've seen the rise and fall of many giants e.g. Sun with their once 'technically superior' Solaris and SPARCs, well one can name many I just don't have time, also we seen MySQL bought by Oracle, and all. Nothing is eternal, and it's (Again!) quite not always technical matters that matters. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. At present, no. But the trend is clear. That's how free software works. Actually, free software (one you don't pay for) works like any other software you pay for. You probably wanted to say that's how the OSS model works but it's getting less and less true. The OSS model in many cases retains only its open source. Take MySQL, take KDE, take GNOME. Who cares about users? We do what we deem feasible regardless if you like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's technically superior. C'mon, who are you? An admin? A programmer? A Bachelor/PhD? Ha, man, we're BILLIONAIRES. That
