On 04/30/2014 11:22 AM, Lamar Owen wrote: > On 04/30/2014 10:41 AM, m.roth at 5-cent.us wrote: >> Define "stable". please. > I define stable in this context as 'behaving in a completely consistent > and predictable fashion.' > >> I have servers (and I really, REALLY want to >> reboot them, but they're home directory or project servers, and so it's >> really hard to get to do that, since people have jobs that run for days or >> weeks, that have run flawlessly for > 300 days, with nothing vaguely >> significant problems. > Truly stable systems allow rolling reboots with no interruption of > services. EMC and others have had this licked for years with their > storage arrays; Tandem had it solved for CPU's and RAM inside a single > system image, back in the 80's (and even though it was a bit, ah, > interestingly implemented). Truly stable system remain stable even when > their parts are unstable. A truly stable system will be stable even > when every one of the constituent parts are inherently unstable. And a > truly stable system is hard to make. > >> That's a complete misrepresentation of the other side of [the always >> disable SELinux] argument. > I said it reminds me of it, not that it's identical to it. > >> I'm not a huge fan of "if it ain't broke, don't fix it", but fixing >> something that, 90% of the time, is no big deal to configure and run, >> with layers of complexity that have created both new issues, and >> broken things that are set up in a given way for a reason, does not >> endear it to me. > Reliable and highly available networking using the the traditional Linux > networking way is broken for many use cases, not all of which are > desktop-oriented. It is broken, and it needs fixing, for those cases. > And I *am* a fan of 'it it ain't broke don't fix it.' > >> *Configuring* *Nix [the Windows] way *is* a Bad Thing. > A Bad Thing is not a capital crime, and Windows does do some things > right, as much as I don't like saying that. What I meant about Windows is everything seems to be hidden behind some gui interface, which leads people to not really understand the underpinnings of what is truly happening. NM seems akin to this, at least the last time I tried to use several years ago. I work in a development environment where we are constantly adding and removing systems and connections and for me it just gets in the way. I can quickly type ip a a ..., ip r a ... and be done with it. > >> That *does* come off as snide and supercilious, esp. in this specific >> forum, with the backgrounds of most of us. > I really try hard to not be snide or offend very often, but the idea > that something needs to stay a certain way either just because it's > always been that way or because we can't do it the way someone else who > we don't like has done it deserves a bit of a reality check, really. Or > do we want to go back to the Way It Was Done before this pun called Unix > launched? I've run ITS on an emulated DECsystem 10 in SIMH; I'm glad a > better way was developed. > > The perl mantra is and always has been 'there's more than one way to do > it.' NetworkManager is a different way to do it, and while far from > perfect it is the means Red Hat has decided to use in EL7. > >> Just you wait: maybe we should all join some fedora list where we can >> vote, before they try to force us all to ... EMACS! > And, if there were no alternatives I'd use it. It's not that big of a > deal to learn something different, even as busy as I am. Who knows, I > might even find that I like it. > >>> Older does not mean better, and many times newer things have to be tried >>> out first to see if they are, or aren't, better. >> Again, newer does not mean better, either. > Very correct; and in EL6 at least you can use the older way or the newer > way. But if the newer way can be fixed to meet Red Hat's needs, then > they're going to use it. If it can't, well, the RH distributions' > histories prove that they're not afraid to pull the new and go with > something else, too, when the need arises. > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark at netwolves.com http://www.netwolves.com