Alessandro Selli <[email protected]> wrote: > I did notice, to my mighty disappointment, that you sneaked your > comment through just minutes before I did! :-)
Yeah, well, I also have read a lot of non-public discussions on the matter as well. Interesting times indeed. But I wanted to wait until Canonical-Ubuntu decided, not just Debian. That way, if it was both projects, then there was a clear reason to start developing _full_ set of *d subsystem objectives, not just systemd identification. Because, in reality, I try not to get involved with the politics. It's easy to drop into contributor agreements, organizations and projects unable to finish developments or get things working, etc... I mean, we haven't even talked Mir v. Weyland ... as yet another example. Some people look at these things as win/lose, them/us, etc... I never do. I look at the real case of what open source developments are getting adopted, what mindshare do they have, and what things do they solve. I mean ... even Red Hat adopted Upstart for RHEL6, as Fedora had done so by Fedora 9. It was the best solution at the time. Fedora 15 changed to systemd, and RHEL7 is now doing the same. Not everything is there, and some legacy components will ship. But many *d solutions will be in RHEL7. I always have and will continue to advocate people fund organizations so they can hire more GPL developers so we all -- the community -- win. E.g., if your organization is operating in the black, and that is because you rely on Ubuntu LTS, please purchase Canonical Advantage. I still advocate identification of Upstart and related event files in the next iteration, Blooms Knowledge and possibly even Understand (weight 1-2). But the objectives will need a good refresh eventually to appropriate cover *d, because its far more than just an init system. In fact, if you read some of the DTC posts and debates -- at least the non-political ones -- there's reason why most of the people who were not employees of one company recognized the *d solutions for what they were. And that includes very, very broad adoption, development, standards and related support from more than just the "two big enterprise names." It's ironic how many people "paint" things ... until they look at them closely. Then the technical merits are able to take hold, and choices can be made. I'm not saying the *d solutions are flawless. But I am very frustrated at times when people say *d solutions introduce issues, when those issues not only already existed, but *d solutions address them better. I've started to call such people who blame *d for things that are not *d issues, much less often not addressed or made worse by legacy mechanisms or one-off solutions, "SysV Assumists." The same could be said of Red Hat's KVM "ecosphere." A lot of people said a lot of things about KVM, not recognize Red Hat developed not only libvirt, but oVirt, deltaCloud, SPICE and other solutions so they not only work with KVM, but also Xen and VMware. Unfortunately, something like oVirt -- a full, open source management framework and GUI -- was a financial threat to EMC/VMware and XenSource, respectively. So their interfaces lagged. But lo'n behold, here comes OpenStack. Basically Canonical, NASA and Rackspace made Red Hat, without involving them, the #3 contributor because they used all those components (Red Hat instantly became #1 when it focused on OpenStack). This also resulted in 95% of OpenStack deployments being on KVM. Why? I think Shuttleworth himself pegged it best in the Wired magazine interface last year. Without Red Hat, you don't run OpenStack on anything, much less outside of an Ubuntu distribution, including competitors like VMware. Because most of what Red Hat developments is not just for Fedora/RHEL, not just for Linux, but a lot of interfaces in general, including commercial vendors, if they want to interface. I mean, Red Hat can only do so much without their involvement, and I've seen that in everything from Cluster Suite to OpenStack now. And I'm not even touching SSSD/IPA, and how all those years of distros ignoring and not packaging 389 and NSS (Netscape Security Services) is now coming back to haunt them. SSSD is pretty much the best solution, and could be considered the Linux equivalent of NT LSA. And IPA ... well ... it's cake. No longer do you have to be a DNS, Kerberos, LDAP guru ... let alone IPAv3 now emulates itself as an AD Forest with a Global Catalog ... solving the greater problem is a very different way than Samba has, all while handling multi-domain/multi-forest. Heck, SSSD is far better than Winbind too. A lot of people say this or that based on vendor alignment. I don't know if that's the long-standing issue with people feeling ties or even loyalty to brand names. But I do know good solutions when I see them, especially when others ignore the real, production issues that are constantly going on at major accounts and major partners I deal with. -- bjs P.S. As always, my opinions are mine alone. -- Bryan J Smith - UCF '97 Engr - http://www.linkedin.com/in/bjsmith ----------------------------------------------------------------- "In a way, Bortles is the personification of the UCF football program. Each has many of the elements that everyone claims to want, and yet they are nobody's first choice. Coming out of high school, Bortles had the size and the arm to play at a more prestigious program. UCF likewise has the market size and the talent base to play in a more prestigious conference than the American Athletic. But timing and circumstances conspired to put both where they are now." -- Andy Staples, CNN-Sports Illustrated _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
