> > Alexandru Juncu wrote: > > > I don't think it should be kicked off. First of all it's not like it's > > > a complex and time consuming topic. Also, I for one, use it (I'm using > > > Debian bases distributions). >
Remember, /etc/hostname != /etc/HOSTNAME Two entirely different files. ;) On Wed, Jul 17, 2013 at 3:16 AM, Anselm Lingnau < [email protected]> wrote: > It will also be first up against the wall when the systemd revolution > comes. I for one can't wait for that to happen because all these funny > little trivia will finally go away. It will make our lives that much more > straightforward. > > See http://0pointer.de/blog/projects/the-new-configuration-files.html > There has been a long-standing view that if something works and has been long adopted by Debian, it should be considered for Fedora. Many of the changes and even FreeDesktop.org standards are this way, including those from LP. Most of them are not only very "sane," but more "standard" than prior. Especially when it comes to resource and services management and monitoring. All systemd is finally doing is using what the OS already provides, but other systems (even Upstart too in many cases) ignore or don't leverage fully. The major issue, and related complaints, about systemd isn't Linux, but non-Linux. systemd is most definitely designed for Linux, udev, et al. And systemd is being adopted by more and more components, which are also used on non-Linux, which means there has to be alternative support for non-Linux. This is where LP and many others get mis-quoted. I.e., that's where the "*BSD isn't relevant" issues come from. In reality, since most other OSes (e.g., NT, Solaris, etc...) have gone beyond just "event-driven" init, but to real-time service, socket, resource, etc... and other "messaging" interaction with the "system manager" (i.e., systemd in the case of Linux), it's a real issue that needs to be solved for more than just Linux. For those OSes that don't have a message bus passing solution that hooks into resources, services, etc... and can be adopted for systemd ... yes, there are going to be issues in the future. Since Debian targets more than just GNU/Linux, some of their maintainers are the biggest complainers of what is going on "in-the-upstream." I can understand those complaints. But I can also see the "relevant" argument as well. Sometimes the old approach is not only lacking standards already, but really out-of-date and far, far from complete. Arguing such in Linux, against systemd, is a lesson in getting a serious smack-down, shot-after-shot is deflected. And then you turn to BSD, and it's ... "oh, yeah, we should think about that too." People used to complain about SSSD too, and now it's the greatest thing since sliced bread among Ubuntu folk, using far more up-to-date OpenLDAP libraries and clients (let alone is far more regulatory compliant), and has far, far more modules and support than legacy PAM, NSS and other modules (some of which are quite broken too) ... even though it's virtually Linux-only (although the Fedora team is always looking for non-Linux port interest). Anyone who knows anything about 389 and its iPlanet lineage understand how SSSD (and IPA) came about. But too many people also stuck their heads in the sand for a full decade, and some still think OpenLDAP codebase is the only thing there is. That's kinda like saying KHTML was the only open source codebase, resulting in things like Safari and the like, totally ignoring the Gecko/XULRunner lineage back through Netscape solutions and even Mosaic itself. Too many people only know what they know. And too many will assume for what they do not. And far too few bother to look ahead, and then realize they should have done something sooner. I think some of the *BSD camp is starting to realize this. People can complain all they want, but the GNU/Linux world and its upstream is no longer going to try to hack in advanced features, system management and monitoring in software for platforms that don't have the underlying capabilities to support it. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
