I'd say that an OS is more akin to a scripting API or a programming language, which i am completely fine with.
modifications/plugins are literally just advanced scripts. some even are literally just scripts.
It's not ad-hominem because the analogue has direct relevance to the debate.
wow you're acting like such a capitalism here, continually defending your beliefs even when they don't make sense. (it is very relevant for me to ascribe your behaviour to that of a capitalist)
anyway, why are you so stubborn in your beliefs? you made this thread like a question, and then argue like it's a debate. if you really had genuine curiosity, then why do you refuse to accept the given answer?
is it because you're still curious on the specific details? well it's not like we're going to explain human sociology to you to say why humans want to have multiple modifications working together and modularly, with an easy and convenient way to achieve that. you've got the best answer we can reasonably give.
You're acting like a capitalist, trying to prove your own point by simply saying it again instead of refuting the refutations of others.
i never knew capitalism was about proving points via repeating oneself infinitely. i thought it was about the ruthless drive for profit above literally everything else. but i suppose it's about being a poor debater?
hey, speaking of poor debate skills, i'm pretty sure calling someone a capitalist, or « acting like a capitalist » is some kind of fallacy. it's certainly name-calling. ad hominem perhaps?
I don't think that a modification API helps with anything.
ok, i guess you don't need an operating system then. just flash software to your ROM directly. since, an OS is literally a modification API for computers.
I know that the work itself never addresses that
and therefore, is not a valid counterpoint. if it's so trivial to derive, then provide a point-by-point breakdown of your trivial derivation.
I think that forks rarely become many because most attempts to fork a project will invariably get absorbed into the main project or one of the few forks that fills a unique niche different from the original project.
and also a plugin API. that's a very important reason that cannot be overlooked.
the document is not an essay explaining how the fear of an overwhelming number of incompatible forks of a project is not upheld by reality.
it is about the legal fear of forks. as in incompatible licensing and cetera. there's a reason it's under a subdirectory literally titled « Licensing and Law ».
the document does not address the psychological overwhelming of many forks to choose from, which is only a counterargument addressing your argument that many modifications to choose from is overwhelming.
all reasonable discussion ended when bmh posted a link to a completely unrelated legal document about the law regarding forks in response to a valid point that a lot of forks would be an overwhelming choice to the user too
that's a faster cache. some caches are faster than others. the instructions are only for if the faster cache of a package not being available in an external repository or in the AUR does not yet exist.
the installation instructions act as a cache. people can read them, which is fast, instead of doing computations that could take a long time. ergo, the developer precomputes how to install the software, and writes it down so future computation on how to install the software can be performed in amortised Ο(1) time