3 ms·

1. There are 5 competing standards. 2. This is clearly unacceptable, so we've created the one standard to unite them all™. 3. There are 6 competing standards.

• advisedwang 3mo ago
  The author is proposing a new feature on existing package managers, not replacing package managers with a new one.
  • JKolios 3mo ago
    It was a tongue-in-cheek comment, not really a perfect analogy to the situation. Still, the author expects teams with different priorities and design philosophies to follow a new standard, that can easily end up in more fragmentation.
  • WorldMaker 3mo ago
    The author is proposing replacing a suite of security tools that integrate with package managers in a variety of ways (directly inside the package manager, through package manager hooks when available, as firewalls/repo hosts/network proxies) with a single security tool that "universally" works for every package manager that supports a new standard ("global hooks"). Some security experts are still going to prefer the firewalls or network proxies given the choice. Some security experts are still going to prefer package manager-specific security tools rather than a single "universal" one.
    • captn3m0 3mo ago
      Hooks are not a new standard. Package managers have always supported hooks. It is just a call to get us to parity.
      • WorldMaker 3mo ago
        Package managers have individually supported hooks, configured in different ways, and with different metadata available unique to the package manager in each hook. Any attempt to standardize hooks "globally" would be a new standard. It might borrow elements from existing implementations of this package manager or that package manager, but it doesn't sound like you build a "universal" hook without some deeper standard on which events get hooked, what metadata is presented and how, etc. It stands to reason as you start to standardize that sort of stuff the final standard won't resemble any specific package manager's existing hooks.