So we are in the “extend” phase of Microsoft’s standard strategy? Can’t see how Microsoft replacing Maven is a good thing.
GitHub Package Registry
291–300 of 389 posts
Re: GitHub Package Registry
#292Re: GitHub Package Registry
#293Re: GitHub Package Registry
#294Re: GitHub Package Registry
#295It will be a little strange though, since Nimble packages just need to be tagged in git and then you've got a release. It doesn't seem that GitHub implemented it this way.
Re: GitHub Package Registry
#296There's something slightly concerning about ceding responsibility for distributing the world's open-source projects from a family of strong independent repositories to a centralized platform owned by a tech giant.
It's a good reason to seriously consider Gitlab.
Or if you are looking for self-hosted git servers:
Re: GitHub Package Registry
#297I agree the artifacts should live alongside the code that produced them. But doesn’t Github killing npm, Inc. and Docker, Inc. in one move indicate Github is too powerful and, therefore, a huge liability? We need decentralized solutions, not another monopoly.
Re: GitHub Package Registry
#298Earlier quoted context omitted.
The problem is that hosting and bandwidth aren’t free and abuse is a big problem. Managing a distributed petabyte-scale archive which gets updated so frequently is a significant engineering problem even for a single party — now consider how you’d handle redundancy and routing when you can’t rely on any of the parties involved, and you have enough different objects being accessed to turn away most participants unless…
I hear those concerns, but I think there are clear ways to use decentralization to provide real benefit without running afoul of the issues you describe. For example, you can simply cache the packages you/your team are interested in locally, or on a shared local server for your entire office to use - which gives you fast p2p transfers, offline resiliency, and avoids serving any evil BLOBs or running into giant perf i…
I’ve seen this cycle with Linux distributions, Java, and Python packages (arguably even Git), and several digital preservation systems (I work at a library so this is a popular topic) and each time there either ended up being strong user demand to switch to the performance/stability/consistency of a centralized service, that happening de-facto with one or two big players doing most of the work, or falling apart because the contributed resources were insufficient. Getting the incentives aligned for something like this is really tricky.
Re: GitHub Package Registry
#299Earlier quoted context omitted.
> MS's core competency has always been developers. As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract. Classically, MS has been good to developers who agree to be chained to their platform, but has made life extremely difficult for developers who want or need to be platfor…
>As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract. Yes, Active X, Windows, Java etc, and god knows how many awful things they did I cant remember them all. But years later Bill Gate decide to donate his wealth to good cause. Not only is this not a PR / Marketing Stunt, h…
Did he? Bill Gates has consistently been getting richer according to Google, and now has a staggering 90B.
Re: GitHub Package Registry
#300It's a really nice project overall, having a registry that supports many different projects and run by a company that today is good, is always nice. But we been here before. We trusted npm and now they are trying to squeeze out a profit, and it ruins it for the users. I'm happy to be proven wrong, but every for-profit company that runs a package registry, eventually stagnates, and ends up implementing things that are…
That said, the market's moving towards a universal registry for package management, across tech - npm, docker, linux packages, jars etc.
With that perspective, GitLab's initiative (https://about.gitlab.com/direction/package/) is something I'd likely prefer. The software's open-source and deployable, which means the software's fate isn't tied to that of a single company.
It's already ironic enough, that the world's biggest collection of open source projects is managed by a single closed-source software - GitHub.