Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and a megabyte of storage (at best).

No, the UNIX philosophy persisted since the 70s because it is great default philosophy for building software. Not all kinds of software but most, I'd say. Doing one thing well plus all the other stuff (like preferring plain text output) means that users can easily assemble whatever they need. When applications are doing only one thing, you can thoroughly test them as well and enjoy a level of security that monolithic programs have to add via sketchy hacks. And when a monolithic system is compromised, it is a bigger threat than one with smaller scope.

Yeah, that works best in the 70s.

With modern software it's a pain in the butt. Remember CD burning software? That at least used to invoke cdrecord underneath, and whenever that went wrong it was awful, because text is an awful interface for a complex system.

Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.

Then why do we need binaries when we have ld.so ?

A GUI program invoking a program not designed to be a GUI in the laziest fashion is fringe example. Such a GUI would have been a herculean feat to implement if the authors could not piggyback off of an existing, simple tool. If the GUI authors really wanted, they could have tried to parse the output of cdrecord and/or contribute to making the output of cdrecord suitable for easy processing.

>Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.

There are tradeoffs to this simplicity. Your "library" is most likely a pain in the ass to use even for people using the same language, much less other languages. The output and invocation of a simple program is less likely to add a breaking change than its code. Do you think libraries were just invented, or what?

I like the idea of making the library first and then using that to build a tool. But that may not make sense in all cases, and it's extra work as well. For people using other languages, or trying to write simple shell scripts, a library alone is not going to work.

I appreciated it. I fucking hated all these init scripts and find it muuuuuch easier to get services running under systemd. I don't care about philosophy when it gets in my way of managing systems.

Had it not been for the philosophy, Linux would not have been a thing. If you don't care about philosophy, consider going to Windows?

Why would they have to go to Windows when systemd is bringing Windows to Linux?

I seem to remember a lot of debates on whether or not Linux followed that philosophy compared to a microkernel

Probably less than it might. I expect microkernels to eventually displace Linux, whether explicitly or by gradually turning Linux into a microkernel.

> Had it not been for the philosophy, Linux would not have been a thing

I'm not entirely sure what you mean by this, but linux (the kernel) is very much not a "do one thing and do it well" kind of program. You'd need a microkernel for that.