Yeah, was more poking fun of people who cling to the while Unix Philosophy stuff like it’s some unwritten rule that must be followed.
I honestly think there’s tons of Linux software that could be broadly defined as “multiple things”.
Even looking at the links other responders have posted, I even think a lot of linux software is made up of components which are tightly coupled together.
one example of a program that did multiple things is sfdisk, it used to make the kernel reload the new partition table but that was not its main job, only changing them.
the extra functionality moved to blockdev which is nearer to doing such as it also triggers flushing buffers and i think setting read/write status.
i am fully ok with that change as it removes code from a program that doesn’t need it to another that already does similar things so that other partitioning programs like gdisk fdisk or parted could go the same way so that maintainers of the reread-partition-table things can concentrate on one solution at one place (in userspace) instead of opening issues at an unknown number of projects that also alter partitioning. the “do one thing” paradigma is good for developers who maintain the code and i pretty much appreciate their work. if you are up to only want one-day-flies that either die or take huge amounts of resources only for keeping them alive (image of a mayfly in an emergency room and a heart-lung machine attached while chirurgs rushing around trying to enlenghten its life a few seconds more) then you are good with monolithic tools that could hardly be maintained and suck allday as no one wants to fix any bugs or cannot without creating new ones due to the tightened dependency hell it has internally.
the point is not a lack of examples doing wrong but where one wants to be heading towards.
Yeah, was more poking fun of people who cling to the while Unix Philosophy stuff like it’s some unwritten rule that must be followed.
I honestly think there’s tons of Linux software that could be broadly defined as “multiple things”.
Even looking at the links other responders have posted, I even think a lot of linux software is made up of components which are tightly coupled together.
one example of a program that did multiple things is sfdisk, it used to make the kernel reload the new partition table but that was not its main job, only changing them. the extra functionality moved to blockdev which is nearer to doing such as it also triggers flushing buffers and i think setting read/write status. i am fully ok with that change as it removes code from a program that doesn’t need it to another that already does similar things so that other partitioning programs like gdisk fdisk or parted could go the same way so that maintainers of the reread-partition-table things can concentrate on one solution at one place (in userspace) instead of opening issues at an unknown number of projects that also alter partitioning. the “do one thing” paradigma is good for developers who maintain the code and i pretty much appreciate their work. if you are up to only want one-day-flies that either die or take huge amounts of resources only for keeping them alive (image of a mayfly in an emergency room and a heart-lung machine attached while chirurgs rushing around trying to enlenghten its life a few seconds more) then you are good with monolithic tools that could hardly be maintained and suck allday as no one wants to fix any bugs or cannot without creating new ones due to the tightened dependency hell it has internally.
the point is not a lack of examples doing wrong but where one wants to be heading towards.