4 ms·
> For this project and its day-to-day maintenance, unequivocally. Insisting on personal assertions does not pass as a justification, particularly one based on
by chipdart 2y ago
> For this project and its day-to-day maintenance, unequivocally.
Insisting on personal assertions does not pass as a justification, particularly one based on such specious reasoning.
> One of Richard's philosophies is "freedom means being able to take care of yourself," (...)
That's fine. Irrelevant to the discussion, though. If you're really really concerned with somehow losing access to a build tool managed by a third-party, nothing prevents you from storing the tool anywhere, including in a separate Git repository.
Just say it's personal taste and technical merits play no role in the decision. All these wild claims just sound silly.
- sgbeal 2y ago> Just say it's personal taste and technical merits play no role in the decision. Reducing long-term maintenance burden and simplifying the developers' work is arguably the best technical merit we could hope for. > All these wild claims just sound silly. And, with that, i'm stepping out of this sub-thread.
- pjc50 2y agoThis is such a HN answer, presenting your own personal taste as technical merits and the technical merits of other's approaches as wild claims.
- HelloNurse 2y agoIt isn't about losing access to the tool, it's about lacking control of what the tool does. For example, suppose that the CMake developers, due to last-straw Unicode bugs, lose sanity and decide that from next version (in a few weeks) an initial BOM and UTF-8 encoding in all files will be mandatory: are you ready to check and adjust all your source files and review your text editors (or to fork CMake)? More realistic scenarios include users discovering novel CMake bugs and changed defaults after updating CMake and developers discovering useful things that are impossible with CMake because of old bugs and limitations.