Once you go mini...

[Nigel Kersten]

On Wed, Feb 25, 2015 at 11:34 AM, ibi sum <ibisum at gmail.com> wrote:

> >
> >
> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> >
>
> This kills the Unix.
>
> http://ewontfix.com/14/


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.

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)

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.


> What do you think Mint is doing a better job at?
>
>
> 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.
>

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.

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.


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.
>
>
> > It's basically a different release process of Debian/Ubuntu, with
> different opinions around including proprietary software.
> >
>
> I guess if you don’t like Debian/Ubuntu, its a moot argument.
>

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 :/)


> They do work in userland, but other than Cinnamon, I don't see anything
> they've done that substantially pushes Linux forward.
>
> 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 ..
>

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.

> 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
>
>
> 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.
>

Pure hyperbole :)


>
> > As a desktop OS only it's not as bad, but Ubuntu Server LTS has many
> issues.
>
>
> 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 ..
>

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.

This rapidly changing world is why distros need to care about server
problems and you can't just solve it all with tooling.



>
> >
> > For one or two machines, sure, and for orchestration sure. Not for
> actual config management :)
>
>
> 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.
>

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.

Also YAML is bad enough without trying to shoe-horn a programming language
into it :) I thought we learnt that lesson with XML!

It's got nothing to do with client-server. You don't have to run a server
with Puppet, you can do everything locally.


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?
>
>
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.

I'm always happy to argue around this space, but I suspect we're pretty far
off course for the music bar :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.music-bar.org/pipermail/music-bar/attachments/20150225/779595f6/attachment.html>