zlacker

For your consideration. A single tool that does many jobs is in some ways contrary to linux/unix philosophy of creating tools that do a single job.

>>0r30+(OP)
I thought the philosophy was to just build tools you want. So we have, eg systemd and OpenRC. Where one is many-tools and the other is composed of many-small-tools.

Choice is better than "one true way".

>>0r30+(OP)
I am not really asking for tools that do a lot of jobs, though. A simple program that manages systemd services or provides a nice UI around journald logs seems completely reasonable to me.

That said, I don't take the UNIX philosophy to be gospel, and frankly, very little of the Linux kernel or desktop really seems to. That seems to be closer to what the *BSD derivatives would steer towards. I just want a functional operating system, and the specific ideology or design of packages isn't too big of a concern so as long as the end result seems solid.

>>jchw+9e
>> A simple program that manages systemd services or provides a nice UI around journald logs seems completely reasonable to me.

Completely Agree

>> [...] the specific ideology or design of packages isn't too big of a concern so as long as the end result seems solid.

The framework of thinking, while I agree is not gospel, is helpful in guiding design thinking towards a shared goal.

>>0r30+(OP)
There's limits on either end of that spectrum (pile of bespoke pipes vs. Lotus Notes), that we can see a demonstrated interest in, somewhere in the middle: the success of tools like Docker, and arguably even something as banal as the concept of an OS (distribution). Any user-facing software, etc.

You don't want everyone wasting too much time handrolling slightly-differing monstrosities instead of a cohesive design if it's not a business or engineering differentiator.

>>0r30+(OP)
So what are all these 200 line bash scripts that hold the world together?

>>jamesh+Zm
the EC2 networking script would be a good example…