4 ms·
Because it completely violates the UNIX philosophy and mission creeps into taking over essentially every part of the system. It was shoved down the throats of e
by hi-v-rocknroll 2y ago
Because it completely violates the UNIX philosophy and mission creeps into taking over essentially every part of the system. It was shoved down the throats of every user because the major distros kowtowed to a FOSS diva with a spotty track record, creating a monoculture built on awfulness and bloat.
- 7bit 2y agoI 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.
- palata 2y agoHad it not been for the philosophy, Linux would not have been a thing. If you don't care about philosophy, consider going to Windows?
- ranger207 2y agoI seem to remember a lot of debates on whether or not Linux followed that philosophy compared to a microkernel
- lmm 2y agoProbably less than it might. I expect microkernels to eventually displace Linux, whether explicitly or by gradually turning Linux into a microkernel.
- qu4z-2 2y agoWhy would they have to go to Windows when systemd is bringing Windows to Linux?
- mariusor 2y ago> 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.
- delta_p_delta_x 2y agoHot 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).
- wakawaka28 2y agoNo, 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.
- dale_glass 2y agoYeah, 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.
- hulitu 2y agoThen why do we need binaries when we have ld.so ?
- wakawaka28 2y agoA 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.