> When the distributor would not use proprietary tools for their > maintenance, it would > be trivial for someone else to grab their distribution and sell > maintenance on top of it > using the distributor's tools like YOU or up2date. I want to believe > such issues is > also why the re-packaging of SuSE rpm's like k_deflt is so cumbersome.
:grumpy id=nocoffee. So we end up with half a dozen different maintenance strategies and tools based on making it as hard as possible to get consistency between multiple distributions. Boy, that's a step forward. Didn't we solve this problem a few decades ago... :egrumpy. Probably all too right. It still seems dumb not to use methods that don't depend on a central source, though. Our friends at Microsoft seemed to have had that amply demonstrated to them recently. The current approach also doesn't scale very well -- since it's not clear if/when you can set up local repositories with YOU/RHN, it seems remarkably wasteful to depend on WAN downloads. Even adding caching capability to YOU or RHN would seem to be a win for the distributors. The first instance of running a update utility could establish a repository, and then spool the updates as made from the vendor. Distributor could then do batch updates via jobs...hey, doesn't that sound familar.... Never mind. There I go thinking again. -- db PS -- anyone remember NIM for AIX? That was a decent update manager. Hey IBM, how about releasing NIM into open-source?
