<div class="gmail_quote">On Fri, Jul 19, 2013 at 10:43 AM, William Hopkins <span dir="ltr"><<a href="mailto:we.hopkins@gmail.com" target="_blank">we.hopkins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I pretty much discount anyone who uses "gasp" as a rhetorical device.</blockquote><div><br></div><div>It's not rhetorical, it's literal. ;)</div><div><br></div><div>I.e., I've heard a few when I showed people it at work (did a LUG presentation a few months back to a not-so-Red-Hat-loving group). That's when and why I use the word "gasp" in a phrase. It's when people have that "epiphany" they didn't recognize before, until they saw it first-hand, and then it clicked. That usually changes their view rather quickly, and better than anything I could say.</div>
<div><br></div><div>First-hand experience with someone familiar always change everything.</div>
<div><br></div><div>People can argue meta -- from not liking a saracasm to just disliking an individual maintainer -- but that does nothing. In fact, one of my favorite, recent retorts to such was made by one of the Arch maintainers. [1] But until people actually get into the technical meat, and reflect on actual history and not assumption, then we can move forward.</div>
<div><br></div><div>Technologists want to debate on technical merits, not meta-ones or assumptions. It's difficult to deal with assumptions and unfamiliarity. And the common complaints are they are for X and not Y as well as not being UNIX/Linux-like. But until people adopt them and understand the improvements, they will never see this.</div>
<div><br></div><div>But at least the UNIX/Linux world changes on decades, instead of years (Microsoft) and even sometimes just months (Google). ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You're also pretty naïve if you think whatever you're talking about will be the silver<br>
bullet for standarization.<br></blockquote><div><br></div><div>I never argued "standardization."</div><div><br></div><div>I only argued what customers have been asking for, first-hand, on-site ... for servers, not desktops. Arch, SuSE and many others are adopting the new *d solutions as well. There are technical reasons why, and not just conformity.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is a good point. Shame that things like nss-pam-ldapd will gain so much<br>
acceptance because they're fixing problems, forcing others to live with the<br>
poor engineering decisions they've made.</blockquote><div><br></div><div>Compliance and certification is a huge driver ... everything from centralizing user/resource objects/attributes to signatures on DNS zones. Many legacy solutions are based on some of the exact same codebases, but they are legacy. And they have not adopted new interfaces that have been in the system for years, so they are out-of-date.</div>
<div><br></div><div>A lot of times people complain about changing something, when it really hasn't. Some device control, message passing and other things might be newer, but sockets, resources and others solutions are not, they *are* the most legacy of UNIX/Linux. We've just never implemented solutions over the years to handle them proper ... until now.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I don't really enjoy the choice I'm presented with between outdated systems or new, poorly designed ones.<br>
</blockquote><div><br></div><div>Again ... is "poorly designed" an argument made from usage? Or unfamiliarity?</div><div><br></div><div>I can understand the former, and completely respect it. But if one has not learned how to deploy the new solution, evaluated it fully, and seen what happens when the older solutions don't address the needs of users, then it makes a little more sense why the new solution came about.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting community to highlight, given Ubuntu-ers are the laziest linux<br>
users anywhere. I don't begrudge them their pretty and automatic 'don't think<br>
about it' interfaces, but I will resist any efforts to bring them to the server<br>
world.<br></blockquote><div><br></div><div>I won't argue with you about the typical "Ubuntu fanboy" that overstates all sorts of "innovations" that were in Fedora first and (c) Red Hat. There's always going to be a backlash against such individuals because their pulling over the "marketing trash" from the traditional, commercial software world ... and I left for a reason.</div>
<div><br></div><div>However, commercial Canonical and Ubuntu LTS users and administrators are some of the most capable sysadmins (and several know Red Hat too). Several, including one of my favorite colleagues works for Canonical, are extremely knowledgeable, and recognize Fedora/Red Hat developments for their merit. So I was merely pointing out that the new stacks and modular solutions -- which use some of the same codebase as old stuff, just with more capability and newer libraries -- is being adopted out of merit.</div>
<div><br></div><div>Merit is what is the foundation of Fedora and Red Hat. It always has been. It always will be. And if anything, Red Hat has had a history of changing things where everyone "rides the coattails" and forgets 3-5 years down the road and <br>
"conveniently forget" they were complaining in the first place. E.g., GLibC (threading), ANSI C++ (long-term ABI), NPTL (Watson anyone?), etc...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"people complained before and were wrong.. they must be wrong now"<br></blockquote><div><br></div><div>People have been complaining about a lot of Red Hat things, typically several big ones per year.</div><div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not afraid of change. I am arguing that these systems are poorly designed<br>
and make system administration more difficult. I do not need to run SSSD,<br>
NSLCD, NSCD, D-BUS, upower, udisks, etc. etc. etc. just to have a vanilla<br>
system.</blockquote><div><br></div><div>Again, unfamiliarity.</div><div><br></div><div>E.g., SSSD and NSCD do _not_ work together, and NSCD should _not_ be used with SSSD. ;)</div><div><br></div><div>SSSD's caching is designed to be a more deterministic superset of NSCD (and even Winbindd caching for that matter). It works extremely well and has solved several problems at many sites I've been at. SSSD itself is really just a modular system with a superset of updated libraries and capabilities, along with a single point of caching/control.</div>
<div><br></div><div>I've also deployed SSSD and when I had problems, it's only because the site configuration was not compliant with their own security policies.</div><div><br></div><div>E.g., before, older solutions would blindly not do certificate checking and various authentication, things required and poorly presumed to be working. With SSSD, you have to set flags not to, and it's very good at ensuring compliance, while still being able to set an exception.</div>
<div><br></div><div>Once I document this at this one client, the IT department was ecstatic, and loved SSSD from then on. They learned the few option I taught them, and never went back.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some systems are worse than others (gconf is especially a horror from<br>
the depths),</blockquote><div><br></div><div>Again, many new solutions are not for desktop, but server. The desktop just ends up adopting some of the server components, with others that are desktop-only (e.g., gconf).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">but nonetheless the new method of running software to add layers </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
of abstraction that then become hard requirements because everyone assumes<br>
they'll be present is totally off base and disconnected from the open-world<br>
mentality of Linux.<br></blockquote><div><br></div><div>I'm not going to convince you. You're just going to have to learn and evaluate the solutions and decide. I know SSSD seems daunting, but it's not. And authconfig really does a great job.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not surprised any longer that people in IT tend to be very bad at arguing;<br>
we all have big egos. But you should be aware that this sentence takes your<br>
conclusions as assumed fact, and paints anyone who disagrees as near-luddites<br>
afraid of change and unfamiliarity. It's pretty rude.<br></blockquote><div><br></div><div>Well ... I apologize. But I see a lot of meta-arguments combined with unfamiliarity.</div><div><br></div><div>As I said, I think the Arch maintainer pegged it very well. We no longer focus on the technology, and real, customer and user needs why changes come about. We focus on the meta-arguments, alleged UNIX history, and even demonization of individuals (not saying you did, but it's common in these cases).</div>
<div><br></div><div>Best of luck, and if you ever need assistance with SSSD, IPA, the new *d services, etc..., please feel free to ask. Don't know if anyone will convince you on the more "meta" arguments, but best of luck regardless of what you deploy.</div>
<div><br></div><div>-- bjs</div><div><br></div><div>[1] <a href="https://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023392.html">https://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023392.html</a></div>
<div><span style="white-space:pre-wrap"><br></span></div><div>"w<span style="white-space:pre-wrap">e have a patch to make systemd optional </span><span style="white-space:pre-wrap">at runtime, we request users to test it, and instead of testing it we </span><span style="white-space:pre-wrap">end up with a 300+ posts thread about how bad Lennart is, with nearly </span><span style="white-space:pre-wrap">no-one trying to investigate what is wrong about the patch and in which </span><span style="white-space:pre-wrap">situations it doesn't work."</span></div>
<div><br></div><div>Pretty much sums it up better than I ever could.</div><div><br></div><div>--</div></div>Bryan J Smith - Professional, Technical Annoyance<br>b.j.smith at <a href="http://ieee.org" target="_blank">ieee.org</a> - <a href="http://www.linkedin.com/in/bjsmith" target="_blank">http://www.linkedin.com/in/bjsmith</a><br>
<br>