<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 11:34 AM, ibi sum <span dir="ltr"><<a href="mailto:ibisum@gmail.com" target="_blank">ibisum@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> <a href="http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html" target="_blank">http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html</a><br>
><br>
<br>
This kills the Unix.<br>
<br>
<a href="http://ewontfix.com/14/" target="_blank">http://ewontfix.com/14/</a></blockquote><div><br></div><div>We've hit a local optimization with Linux IMHO. We need disruptive changes that are going to cause pain in the short term to actually get to somewhere significantly better.</div><div><br></div><div>Are you a PulseAudio hater too now? (ignoring the botched releases *Ubuntu* made at first which is where most people's dislike of PulseAudio comes from)</div><div><br></div><div>His points about how companies use Linux for appliance development are totally spot on. As someone who's been working for the last year or two with all of the network vendors who are transitioning from proprietary OSes to Linux/BSD distributions, there's an enormous world of pain out there.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> What do you think Mint is doing a better job at?<br>
<br>
<br>
</span>Making an out-of-the-box distro that ‘just works’ upon installation without much tweaking, yet still continues to offer all the power and privilege that a modern Linux distribution has to offer.<br></blockquote><div><br></div><div>That's fair, but that's just incremental change and paying attention to constructing good defaults. It's not to be sneezed at, but it's not pushing the state of the art forward.</div><div> </div><div>At least Ubuntu have tried to invent a bunch of useful technology, even if it's mostly failed in the wider ecosystem. cloud-init is the only thing I can think of that has actually gotten traction anywhere else, and there's a much longer list of failures like bazaar, JuJu, AppArmor etc.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I dunno, I’m not seeing much more that RH does though.  Perhaps its time I booted CentOS and all the other RedHat Things, and had a closer look.<br>
<span class=""><br>
<br>
> It's basically a different release process of Debian/Ubuntu, with different opinions around including proprietary software.<br>
><br>
<br>
</span>I guess if you don’t like Debian/Ubuntu, its a moot argument.<br></blockquote><div><br></div><div>I *love* Debian. It's my first love (at least out of distros that still exist), and I think it's absolutely critically important that we continue to have strong distributions that don't have corporate interests at heart first. (See also: web browsers :/)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> They do work in userland, but other than Cinnamon, I don't see anything they've done that substantially pushes Linux forward.<br>
<br>
</span>Cinnamon is no small thing!  But I think you’re into the ‘rewrite all the inits’ stage of this argument, which I haven’t quite agreed is a necessity at this point. systemd is flawed from the outset.  Putting all that crap into init1?  Fuck, its just not cricket, man ..<br></blockquote><div><br></div><div>Do you have the same complaints around launchd and think OS X is fundamentally flawed? Did you live through the SystemStarter -> launchd transition? We're seeing *exactly* the same story play out here, just as we did with Solaris and SMF.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I'm genuinely not trolling, although I realize it looks just like I am :) I think systemd is exactly the right kind of disruptive change that needs to happen to Linux, particularly in the world of<br>
<br>
<br>
</span>If by disruptive you mean “introduces countless headaches for anyone who has admin’ed a Linux system up to this point, is not at all secure even in the slightest bit, and doesn’t actually *add* features but rather takes them away”, I guess you have a point.<br></blockquote><div><br></div><div>Pure hyperbole :) </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
> As a desktop OS only it's not as bad, but Ubuntu Server LTS has many issues.<br>
<br>
<br>
</span>Okay, on this I think you have a fair and valid point, but then I don’t think that server problems should be solved by distributions, a technique which only makes sense with desktops (imho), but rather the server install problem should be solved by competent individual server administrators - who are given good tools to solve this problem..  Tools like RancherOS, which is too new school I admit, but still, RancherOS is everything a good server distribution should be: absolutely bare-bones enough to run Docker containers, and thats *it*.  That is to say, I don’t think “collective distribution maintained by the mob” is the right way to approach server-distribution politics.  Well, maybe my mind isn’t settled yet, but I’d love to know what is a ‘good server OS’ out of all the distro’s out there - besides RancherOS, that is ..<br></blockquote><div><br></div><div>I think "good server OS" is insufficiently specified to actually come up with an answer. Are you running large enterprise monolithic apps? in-house developed apps? microservices? Deploying a PaaS? internal cloud? hybrid cloud? The right answer changes depending upon what you're actually doing with those servers.</div><div><br></div><div>This rapidly changing world is why distros need to care about server problems and you can't just solve it all with tooling.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> For one or two machines, sure, and for orchestration sure. Not for actual config management :)<br>
<br>
<br>
</span>Why can’t you do CM with Ansible, but you can with Puppet?  Oh, I know .. because client-server.  Yuck!  YUCK!  BTW, doesn’t scale.  Oh wait, yes it does: if you put your manifests in git and then checkout with ssh on all/multiples-of the recipients, but then you’ve just re-invented Ansible and may as well just use it, coz YAML and stuff.<br></blockquote><div><br></div><div>No, it's much more that shell scripts are a poor way to do idempotent configuration management as soon as scale matters at all, either scale of people or scale of systems.</div><div><br></div><div>Also YAML is bad enough without trying to shoe-horn a programming language into it :) I thought we learnt that lesson with XML!</div><div><br></div><div>It's got nothing to do with client-server. You don't have to run a server with Puppet, you can do everything locally.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And I’m really only baiting you into explaining all the things I don’t know about Puppet because I’ve been using Ansible for the last year and therefore haven’t caught up with how super-duper Puppet has become, lately .. I’m prepared to be enlightened, but probably I should just go watch a hipstercast on the subject and get my ass kicked into the 21st Century, somehow.  Because “python all the things”, right?<br><br></blockquote><div><br></div><div>I think Ansible is really quite excellent at solving a certain kind of problem, but it has huge issues scaling, is a shitty way to represent state, and completely fails at providing any reasonable auditing of history.</div><div><br></div><div>I'm always happy to argue around this space, but I suspect we're pretty far off course for the music bar :)</div></div></div></div>