3 ms·

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.

by 0r30 3y ago

djbusby 3y ago
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".
jchw 3y ago
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.
- 0r30 3y ago
  >> 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.
jameshart 3y ago
So what are all these 200 line bash scripts that hold the world together?
- hhh 3y ago
  the EC2 networking script would be a good example…
llanowarelves 3y ago
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.

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.

by 0r30 3y ago

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.

djbusby 3y ago

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

jchw 3y ago

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.

0r30 3y ago
>> 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.

jameshart 3y ago

So what are all these 200 line bash scripts that hold the world together?

hhh 3y ago
the EC2 networking script would be a good example…

llanowarelves 3y ago

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.