It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype.
On the other hand, it took me three days to release a new version of one of my artifacts the other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I'm glad that getting that artifact out wasn't an emergency.
This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it's only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.
All packages are GPG signed, come with companion source and javadoc artifacts, and are guaranteed a certain amount of other metadata in the POM. There are "easier" repositories (like Bintray jcenter) but anyone who has used something from there that didn't include sources or proper licensing information soon comes to appreciate why it is that Maven Central (and not jcenter) that is the center of the Java ecosystem.
Not everyone and not all of them, of course. But while I was looking around to figure out which repository to choose as my main, JCenter has put me off. I still can't understand how people can easily trade convenience for quality.
Also, not all artifacts have sources and javadoc. Most do but some certainly don't.
I may be wrong but source and javadoc are requirements. Maybe there are some old packages without it, but new ones should be complete.
Not true. The GPG signature means the key belongs to an account with access to the group id (namespace, usually a domain), and that sonatype has verified the group id belongs to the original admin account for that group id.
It's not a lot of guarantees, but you cannot just generate a GPG key, sign a package, and publish to maven central.
I don't see it as such. A key reason that this offering from GitHub (and the corresponding one for GitLab) is useful is that it simplifies the enterprise stack - things that will never get posted to Maven or npm or DockerHub in the first place.
From the announcement:
> Packages in GitHub inherit the permissions of the repository, and you no longer need to manage third party solutions and sync team permissions across systems.
This impacts locally hosted Nexus repositories. The artifacts that I build for my team that currently get pushed to internal systems can now live along side the source code repository.
From the "What our customers are saying":
> GitHub Package Registry has allowed us to spend more time solving hard problems, and improving patient care. Since it uses the same permissions and security as the rest of GitHub, we spend less time managing multiple accounts, ACLs, and on-premise infrastructure, which leaves us with more time to code what matters!
That is exactly where it is useful.
For maven central, I am pleased to have the governance and management of those systems be part of my deployment chain for third party libraries and I will continue to prefer to pull something from Maven Central rather than somewhere else whenever possible.
That said, would be interesting what Github's effort comes to. It's always better to have alternatives.
Giving money to sonatype or somebody like that will be forgotten in a week by outsiders.
So does GitHub's package registry. In terms of ROI for dollars spent, that seems pretty good.
Indeed, Microsoft has sold and added 100M more Micecraft licenses and accounts since.
From an account acquisition point of view alone, which fairly often is the main driver of these transactions, the deal was a steal. I'd estimate the value of a fresh user account in a desirable demographic to be around $250 for Microsoft. Even the short term projected revenue would be close to $10.
Microsoft projected the deal to pay for itself in 1 year, and while not having followed the case up close, chances are it did.
It's made by JFrog (makers of Artifactory), it's been around for while, it supports lots of formats including harder ones like apt, and it makes package distribution about as easy as it can be.
Their Gradle plugin is pretty bad too; kinda ironic given their prominent position in the Android and Java community. But then, Gradle itself is crazy town so it's hard to blame them too much.
- Central has a global namespace of artifacts. com.google.guava is the same for everyone. This will probably stay the default of open-source libraries.
- GitHub Package Registry has a per-user maven repository, so a local namespace (https://maven.pkg.github.com/OWNER). This is likely to be used by companies internally.
In order to use GH Registry instead of Central, I would have to add a dozen maven repositories to my settings.xml. I doubt many developers will be up for that.
It looks like from that post they only support Docker, Maven and NPM right now so they also have some catching up to do in the genericization world.
I'm willing to admit I was probably doing it wrong, but I'm glad it forced me to look at other options. There are definitely easier methods of package/publishing out there, and GitHub package registry sounds awesome.
I've also gotten the impression that StackOverflow's recruiting product isn't doing so well. It seems to be a few hundred dollars a month for a single job posting, but the results for recruiters are apparently mixed.
It's probably worth it for companies with greater hiring needs than ours, but LinkedIn (begrudgingly), and ZipRecruiter have provided enough quality candidate-flow for far less money that it doesn't make any sense for our uses.
IIRC it uses ASP.Net MVC or something like that, and might have been the first and/or biggest site using it?
It is a matter of taste and I'm sure these guys (Atwood/Spolsky) love Windows to work on, but with .NET Core (we started porting when the first stable ASP.NET Core came out), we ported/migrated everything from Windows/MS (SQL server, Windows Server, AD, etc) to Linux + MySQL/Postgresql on ASP.NET Core.
I guess it's what you are used to, but everything is faster, smoother, more stable/consistent and easier to manage now. I would never go back.
We have moved most of the library to docs, with redirects in place, so hopefully you won't get too many 404s. If you do - feel free to report them here: https://aka.ms/sitefeedback, and we'll address them.
What's the second major search engine?
I'm genuinely asking, not meaning to poke if it's Bing - I use DDG but just don't have a feel at all for what's most popular after the obvious one.
Wikipedia has just 7% market share left for the second, and the rest - thinking about it's probably one that's popular in China and unheard of elsewhere?
Baidu in China. Yandex in Russia. Google in the US. Not sure for India and Latin America.
The poster was probably thinking of Bing though, which is ironic because it's maybe less used than these.
If we are to believe these stats, Google is at 3% market share in China. It's basically non existent. http://gs.statcounter.com/search-engine-market-share/all/chi...
Microsoft has developers everywhere in the world, who need docs. There are major search engines besides Google and Bing.
Each one will serve a niche which is much harder to supplant because there's a common purpose. In contrast, when people think of Facebook, people just associate it as 'the' social network but not one for a special purpose.
I think Github issues has already started doing that. Personally, I've been finidng more help from Github issues than Stack Overflow, plus I find myself asking questions or submitting bugs on GH a lot more than asking something on Stack Overflow. In fact, I've not asked anything on SO for years now.
I'm all for giving. I happily write tutorial blog posts, but I don't feel obligated to give more help than I already gave.
> People should grow up
Not sure what this childish quip adds to your otherwise sensible comment?
I definitely see some people (ab)using Issues as a way to ask fairly generic coding questions. It might be time they open up another avenue for questions generally.
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 platform independent.
Platform vendors and developers will forever have conflicting interests.
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, he is actually using his time and energy running it. That alone halves whatever hatred I have had.
Ever since they lost the Smartphone OS race ( if you consider they were even part of it ), I don't consider M$ a monopoly or threat any more.
And given the amount of Good things they have done since new CEO took helm, WSL, and now WSL2, VS Code, .Net Fully Open Sources with MIT license, ditching IE ( God that feels good ) , Direct X RT, along with lots of Research put out, I think it is worth reevaluating that hatred against M$ we once had.
We have no lasting friends, no lasting enemies, only lasting interests.
MS was mainly known for its languages and its apps, more than the OS. IBM PCs still came with CP/M or PCDOS (MSDOS).
Then when Windows 3 came out, MS started to act like IBM but on steroids, thinking they owned the "stack" (as it was). OS/2 was the last attempt to extract the "PC compatible" world from the Windows domination.
Then IE6 and ActiveX ensconced MS in the enterprise. What used to be "you won't get fired for buying IBM" became "you won't get fired for buying MS because there's no choice".
The onset of the web and competitors in MS's dominant space (well except for apps, Office still rules the world) and the demise of the Ballmer years (especially the death of their mobile/phone ecology) means that MS is now actually doing what IBM did about 15 years ago when they adopted Linux.
To quote Vonnegut, "So it goes".
MS were acting like mini IBM throughout the 80s, and before the mid 80s had very much gained a negative reputation globally. It was against Microsoft, not IBM, that was the usual target of complaint when the first AT clones were coming out - 84? 85? I think Windows 1 was about the same time. Certainly enough of a reputation to be amazed they were still collaborating with IBM to produce the first OS/2, again around the mid 80s.
Did he? Bill Gates has consistently been getting richer according to Google, and now has a staggering 90B.
Fraud in charities is a real thing. There are a lot of "charities" that do some good work, but primary exist for the benefit for the benefit of someone. Often the primary purpose is to hide bribes: the CEO's spouse is a high government official. It is very easy to get mess up in such a charity and end up not doing well with your money.
The other problem is 90B is to much money for any charity to handle at once. Any charitable program that has a lasting (and thus useful) impact will take time. Even if the charity sets up a trust, there is nothing to stop the CEO from raiding that trust in latter years. Several charities started good, but over time have slowly - and legally - morphed into something that is very different from what the founders intended.
Staying in charge of his money is the best way to ensure that it is used well.
Eg their main focus for .net Core has been multi platform - ie the last 3-4 years!
Visual Studio Code.
And on browsers they are building what will probably be a better Chromium than Google's Chrome, in the new Edge.
Platform vendors benefit when developers are locked in by network effects. Developers maximize their value when their skills are transferable.
And that goes for Github and its package registry. Concentration of power is problematic.
The costs of supporting multiple cloud providers is still a cost. K8S, Docker, Pulumi, Packer are starting to reduce that interoperability gap, but it's still a friction.
I've moved to .NET on Ubuntu for our current project (I'm an Engineer Manager/Architect, but the team is C#). It's been remarkably smooth and low friction.
So it's a balance, the interests of a platform vendor are of course that you stay on their platform. But currently there's enough competition that it's still a buyers market.
AWS is getting a bit too powerful, Azure is doing a good job of keeping MS shops in the MS world, but GCP is disappointing.
Taken to an ad absurdum conclusion, developers want all platform vendors to coordinate in order to minimize switching costs. Of course there are lots of good reasons such a level of coordination will never be realized. :)
In the meantime, there will always be efforts to create adapters which generalize the interfaces of multiple platforms and put them behind a common wrapper interface. But while such interoperability efforts serve developer interests, they work against the interest of vendors in encouraging platform lock-in.
The dynamic isn't pure in terms of real product offerings because vendors also understand that portability provides value to developers, and so some vendors will provide at least some portability in order to differentiate themselves. But I maintain that the fundamental interest structure is unchanging.
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 not for the users, but for their own profits.
I think package management, especially for open source, should not be run by for-profit entities. We need to have something similar to public utilities, where the community funds the registry itself, and the community can own it as well, where the only changes allowed, are changes that are good for the users.
This is not that. npm and docker are already run by for-profit companies, so this move by GitHub just adds another centralized package registry for those. It's not worse, by it's not better either. I'm a bit mad about the RubyGems part though, as RubyGems is a community project, and they are trying to make it not so, making it worse.
What I'm currently working on, is how I think a Open Source Public Utility would look like. I just submitted a Show HN to show it off, you can see the submission here: https://news.ycombinator.com/item?id=19885502 Website is https://open-registry.dev
It's basically a community funded decentralized package registry, where the community funds it, and is a part of the ownership of the registry, handled via a governance followed by the contributors. All the finances, development and planning is happening in the open, and Open-Registry is committed to never making changes that are for increasing profits, only changes for making the service better for users.
Please, if you have some free minutes, check it out and write down some feedback. We might not be the perfect package registry over night, but I'm hard at work getting as close as possible, without compromising the user value for it.
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.
Yes, I agree with you. Open-Registry isn't tied to being just a JS registry. Open-Registry focuses it's energy on unlocking the for-profit registries first though, like npm, docker and packagist, before we'd consider moving on to other already non-profit registries. Currently, there are no plans regarding expanding it, but it wouldn't be very hard and the architecture of the application makes it very easy to expand too.
While GitLabs effort is (in my mind) more well-meant than GitHubs, since it's open source, I don't think having the software open source is enough. The full development, funding and finance has to be open as well, and I don't think GitLab fits that. Basically, we need Open Source Public Utilities for core infrastructure projects like these.
Edit: Also, opened a issue in Open-Registry regarding implementing support for more package registries here: https://github.com/open-services/open-registry/issues/34
Please chime in if you think there are other registries out there than needs to be supported by more than a for-profit entity.
I actually think Github might be different, because they have a pretty solid monetization model already: companies paying per user for private source repositories. This easily extends to companies private artifact repositories.
Github benefits from the network effect of providing free source repositories to open source projects, so this is probably enough incentive to start and keep providing high-quality free artifact repositories to open source projects.
The moment the outlook of earning a profit changes, the company has to adjust and sometimes that doesn't affect the users. But sometimes it does, and it's those cases Open-Registry is trying to prevent from ever happening.
Let's say the community comes up with a feature that would be great for the GitHub Package Registry to provide, but it would make the earnings from private repositories lower. Since GitHub rely on earning from private repositories, the decision will probably be to not implement that feature, even though it would be good for the Package Registry users.
Today, they can afford not earning as much on their new Package Manager as they earn money elsewhere. But that's no guarantee they will act the same way tomorrow.
We've seen Microsoft go back and forth in the developers minds, and I'm sure we will see more movements back and forth in the future. Right now, things are good though.
If a company is running two divisions, one that doesn't make any profit and another where they make a massive profit, which one will they focus on? If shit hits the fan, which one gets cut first?
Having some core infrastructure like a package registry be the loosing option in that case, does not feel like a no brainer when you're a user choosing a service.
It's noble that you are building a non-profit, neutral registry, but framing the contrarian view as evil, and pitching this as a sacred good vs evil fight is bad.
Maybe your value-add is that the registry works for the good of more than the parent funding org, and that in itself is valuable. However, not-for-profit is scary because you will refuse to go the extra mile for any one customer, even if they pay you money, and only prioritize whatever YOU deem fit and moral.
I completely understand why this all happened (centralization is just so easy and convenient; federation is hard), and it was probably inevitable in its timeframe, but I also wish it wasn't so. It's not quite what we imagined when we made the leap to dscms in the early aughts.
All the good stuff is still in there, though, and it's still as possible as ever to do different things, so it's not a bleak situation.
For example, if GitHub ever started using a very proprietary application, I would just switch over to using regular git, and I'm guessing many others would too.
I'm all in on git in a way that I might not have been without GitHub making it so huge. Without GitHub, we'd probably all be using git at home but SVN at the office.
GitHub then took the server-side bits of git, and effectively built a web-based interface with social features on top. Git itself is still very much a decentralized tool (just add a new remote and off you go), only the social GUI is centralized.
It would be cool if somebody could build "Github over P2P" (I guess with a bit of blockchain, because hype). At that point the entire stack would be fully decentralized.
Well hot dog.
And it uses LISP for scripting? Nice.
Interesting approach to saving state, too.:
One only needs the address of the latest input, the "head", to be able to recover the whole log. The owner of a machine uses an IPNS link to point to the head of the list, and the name of this link is then the name of the machine also.
Thanks for sharing that. Definitely going to give it a whirl this weekend.
The other thing that seems to be lacking, from a quick reading of the docs, is a way to generate pull requests (or "patches" in Rad terms) from a branch, and then merge them on another branch. Obviously you can do it manually in git, but GH is definitely a superior experience.
It's a matter of perspective. My first thought when reading the docs was, "All someone needs to do is slap a GUI on this baby. Good thing the designers made a simple CLI that it could interface with."
They've already done most of the heavy lifting. At this point a GUI is trivial to add. "Terminal–first" doesn't imply "terminal-only". In fact, quite the opposite. I wouldn't be so quick to assume that they don't envision a GUI at some point-- Why not contribute to the project and get the ball rolling?
The patch command  has a propose subcommand that describes what you're talking about. It generates a patch from a commit (on any branch, I presume). This can be applied however you see fit. And the checkout subcommand even lets you generate branches from patches similar to GH. What seems to be missing?
> The patch command  has a propose subcommand that describes what you're talking about.
Yeah but in the tutorial it says it will fail to work if you are on a different branch from master - I took it to mean that the patch command can only target the same branch it was generated on. If that's the case, obviously the maintainer can then do the manual merge-and-delete routine; I'm just saying that on github it's a one-click operation.
One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish).
I'm not really sure how to go about that sort of thing either myself or as a community effort but I'd appreciate any advice from the HN community.
I use Artemis for issue tracking, and that uses maildir (a widely supported standard). I compose issues with Emacs message-mode and render them to HTML using mhonarc.
Uh, thanks but no thanks. I thought we had learnt that the honor system does not scale.
Linus didn't want to achieve a change in workflow of kernel development, he just made a tool to make which would ease the pain, Linux development was decentralized since forever.
I still wonder if Larry McVoy feels sore that git basically destroyed BitKeeper and became what it did. “It could have been me” and all that...
Tickets and the wiki are stored as part of the repo and don't depend on a completely separate web interface.
I prefer Gitlab for a multitude of reasons but since all the action takes place on Github, my Gitlab account just serves as a repo mirror.
As an example I think SourceHut is mostly based around email (which it provides a Web UI for) https://sourcehut.org
It's possible many people have forgotten, or are to young to remember, how the ecosystem worked pre-Github. There was sourceforge, which wasn't quite the disaster it is today, but also not very good. But mostly I remember every project using different, often hand-rolled systems. PRs had to be sent in by mail. Every project had their own conventions of where to send patches, what formats to use, what additional information to provide etc.
Just try figuring out how to get a patch into Debian, which is still where most projects were ca. 2005. I won't wait.
I never contributed to OSS pre-Github. These days, I routinely send in a patch for smaller things I encounter a few times per week. Over time, I have also started becoming a more involved contributed to two projects. I doubt this would have happened without the flat learning curve that Github provides.
I wouldn't be surprised if both the number of contributors and total contributions to OSS have soared by a factor like 5x even above just the growth in OSS usage, and Github is the obvious reason for it.
Hypothetically, and, currently, only hypothetically:
If Microsoft is still of the old spirit, then what we see now, would be the biggest "Embrace, Extend, Extinguish" coup, they have ever done.
It won't happen now, it won't happen tomorrow. For that, this would be too big of an effort. But Microsoft is trying big to win back the hearts of "The Community" and "The Market". As people, especially developers, have gotten more clever about the computers, since the advent of the web has made it possible, to live in IT without "getting shown" and "taught" by "Big Daddy" type companies, since all and everybody is much more self-organizing these days, there is much more competition to MS, that has been in the past. So they try to get it back, what they have lost.
* VSCode, is very sweet and candy, with lots of bells and whistles, major software companies writing plugins for it (the most active being Microsoft). As a programmer's text editor it sits right at the core of every development.
VSCode, especially, is attractive to people outside of MS Windows (they might use VisualStudio). I am talking about web- and "App" developers. Mostly frontend or mobile.
* By buying Github, they bought the "source of all sources". They won't ever own the code, but as long as they own the popular infrastructure, everybody is playing on their grounds. The next step, in two years, or so, may be
the need for a MS account to log into Github. They integrate it.
Out of curiosity, what else did MS buy in the last years, that would fit into this pattern?
I share your concerns, but I've also long had the feeling that both NPM and Maven are a security disaster in the making.
Having the dependencies being published from the same place that stores the actual code, gives me a little hope that things will improve from the security and design perspective.
So far I believe that Maven and NPM have failed to deliver on that front.
The dependencies being resolved from the code store provides a decent mechanism to resolve that issue.
But as long as it's being done on closed software, it's going to be hard to move towards a standard.
There are a lot of moving parts to this and it's impossible to distill it down to a single sentence or even paragraph.
Or if you are looking for self-hosted git servers:
- https://gitea.io / https://gogs.io/
I fear a future where everything one requires to develop "socially" depends on a single super-entity. GitHub and VSCode were the first steps in that direction, and now package management. My guess would be for CI/CD to be next on their list, with more integration of Azure somehow (potentially under the hood).
Lots of us use GitLab at work because it's such a complete product. Source code, container registry, CI/CD, Issues (via GitLab or Jira), Maven repository, NPM repository, etc. etc.
Microsoft is trying to build out GitHub so that they can more effectively compete for GitLab's corporate customers. Since buying GitHub they've added many of GitLab's key features to GitHub and these are some of the biggest adds so far.
You might be right that this hurts NPM and Docker, but I think it'll hurt GitLab more.
IBM I believe tried to do this with their 'Rational' tool line and they're still buying into the game (UrbanCode).
But npm has recently changed their nice-people-matter CEO to a now-print-money dude, so I suspect investors' patience has run out.
And now GitHub went directly after the one thing that npm is supposed to be making money on.
The npm registry started out as a hobby project that was eventually backed by the company its creator worked for. He then decided to pull out his project into his own startup, which raised some eyebrows because suddenly it looked like there was a lot of hostility between him and the company that previously footed the bill for little more than marketing value. Also it was completely unclear how the startup was supposed to make enough money to be viable.
Additionally during its "nice people matter" phase npm Inc seemed to be more focussed on creating a nice environment for its employees and maintaining its ethical values than creating anything that might generate a profit.
The two most obvious monetisation options were private packages and enterprise self-hosting. But when private packages had become a thing there were already third-party open source clones of the npm registry that offered this feature (first sinopia, now verdaccio).
There's really no way to monetise the registry itself directly because users simply aren't willing to pay for a service they expect to be free (like maven, rubygems, PyPI, etc). It would have been more logical to create a non-profit (or at this point transferring the registry to the OpenJS Foundation being the more obvious choice) instead of a for-profit startup.
npm Inc was doomed from the start. Even after acquihiring ^Lift to build the security audit feature there's simply no significant value in what npm Inc offers for money compared to what's already available for free.
The recent CEO change feels like a desperate move by the stakeholders to avoid becoming the next RethinkDB (which also ultimately failed to come up with a way to make money other than support licensing, i.e. renting out access to their developer time).
This is what people criticised when npm Inc was initially spawned: investor money isn't free money and having investors doesn't mean you can perpetually operate at a loss. Investors want significant return on investment, at least eventually. That means either selling out by being acquired (and likely killed) or becoming massively profitable (or surviving long enough while generating enough "value" to go public).
A package registry is a cost center that in order to be valuable needs to be practically guaranteed to exist forever. Maybe if GitHub manages to kill npm Inc they'll finally admit this and transfer the registry and client to a non-profit like the OpenJS Foundation.
There is two problems with this for where I work.
1. What if NPM goes bust? what happens to our packages?
2. What if NPM gets hacked? what happens to our packages?
3. The increase in price was HUGE.. which was probably the reason for forcing us to migrate to their new cloud hosted option.
Look it's an open secret at this point that NPM is in trouble, it's fired a bunch of staff, other staff have quit. The new CEO is all about profit, and its just the beginning.
Here's what we did.
We spun up a nexus instance
It has a NPM plugin, so we get our private repo .. we host it ourselves.. it's exactly what we want.
Honestly if you're an Enterprise customer, this is something to consider
Abuse is the other huge problem: think about what happens when you’re hosting some BLOBs and the FBI shows up at your door because someone uploaded some kind of contraband and some of it was available from your IP address. How many people are going to setup completely independent hosting accounts to avoid fallout from something like that which happens so regularly?
The closest thing which comes to mind is the Debian mirror network and that is something of a historical fluke, predating centralized hosting being possible, and scoped to a much smaller set of more trusted participants. That also hits the big problem that even with a fair amount of infrastructure backing it, it’s hard to match the user experience of something like Github or NPM so the most likely case is spending a lot of time in hard problems but not overcoming the basic economics, as seems to be happening to IPFS.
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.
When I have tried to promote them I've been downvoted. It seems pretty strange to me.
In the livestream he pokes around a github repo, sees it's one author, and decides that what makes it trustworthy? No GPG signing?
The new Actions support (about 50 minutes into the live stream) for auto-publishing from master is pretty sweet. From the very cursory demo, it seems very much like Gitlab's CI pipelines.
You can sign up for the beta here: https://github.com/features/actions
I'm a little bit anxious because the pricing has not yet been published. Both GitHub Actions and package registry will be free for public repositories but it is not yet known how much it will cost for private repositories after the beta.
As for registries, I didn't like Docker's URLs when I first started, but now I'm convinced it's a good scheme. I can "own" my (domain) namespace by running my own registry. The implementation could have been a bit better though:
* The daemon should allow the user to force the use of a local mirror / cache as a registry.
* The daemon should pass full URLs to the registry for requests (https://github.com/docker/distribution/issues/1620).
That way something like Sonatype Nexus could be used as a local caching proxy for all Docker images and could automatically request images from (public) upstream repositories without any additional config.
The new TLDs make perfect identities / namespaces and there are plenty to go around.
Owns it for now. It’s a similar problem to TLS certs but with longer term consequences as people don’t generally expect published libraries to expire.
No. Unless you consider the URL the namespace, but it's not.
E.g. I can download the deb "vscode" from https://packages.microsoft.com/repos/vscode
Or I could download that it from a GitHub-user controlled URL, or someone's random website. The name of the package is still "vscode", regardless of what location it was fetched from.
It is for docker images. `foo/bar` is implicitly `hub.docker.com/foo/bar`.
I think people are pretty well accustomed to that though. Dockerhub, AWS ECR, Google Cloud, etc.
This is a sufficient hassle that one of my colleagues maintains an entire tool devoted entirely to this purpose: https://github.com/pivotal/image-relocation
Say I wan't to install artifacts from two GitHub users. I would have to add these two Maven repositories:
Another case - someone deletes their GH account and another user takes it:
As for account hijacking... I guess GH needs to track account deletions and append incrementing suffixes to usernames under the repository.
Also, people strangely do not seem to be aware of the potential of truly decentralized p2p technologies to provide alternatives.
Downside of this approach is that almost any PHP project requires you to configure Composer with a personal access token for Github due to the amount of API requests causing rate limiting. Folks sometimes end up wondering why Composer needs an API token to download otherwise public code. (https://getcomposer.org/doc/articles/troubleshooting.md#api-...)
I wouldn't consider the Github personal token to be an issue either. It's a one-time setup per device, and my server (which only pulls code) never needed one, because it uses the lock files to download the exact commit/tag, and this significantly reduces the number of API calls made.
NPM's major problem is there's no official link between the package and the repo, any code/branch can be published, and unless I'm missing something, this doesn't really solve that issue.
AFAIK most cases where npm etc. have been compromised are scenarios where maintainer of a popular package re-used a password, and the password became compromised in some unrelated hack. Other attack vectors (compromising access tokens on maintainer's computer, compromising 2FA, compromising a git repo) really are a notch harder.
Even if these hacks are not the fault of npm per se, they make them look bad, and looking bad security-wise is really really something you don't want to happen to you when your whole business model is founded on user trust (public package repo).
There are some challenges, though. If the repository requires a build step to derive a package from it then the author has to provide the proper package.json lifecycle hooks, e.g. a prepare script. Also, there's presently no git/hub-install support for a package nested inside a monorepo.
A simple tool like https://github.com/andreineculau/npm-publish-git does the job (it's regularly used and tested within my current company TobiiPro https://github.com/tobiipro).
We publish npm packages to git tags that get installed exactly the same as packages received from a registry, no build step necessary.
vs having an npm package named (for example) nodejs, are you sure the npm package is authored by and owned by the same person or people that own the nodejs git repository? How do you verify that?
There are many problems this doesn't solve of course but it does seem like it helps with the one I describe above, the connection between the source and the package.
Unsolved problems of course would include things like 'did someone get unauthorized access to the git repo and put an artifact there' and 'did someone with unauthorized access push code to the repo and then have an artifact built'. Those are tough and real problems but I don't know if that's any different between this and say, npm. Code signing Helps with that but you have the same unauthorized access problem if some bad actor gets their signing key instead of repo access.
I think if they required a user or org-namespaced package name, you'd get that. For example, if https://exiftool-vendored.js.org was `@mceachen/exiftool-vendored`, or `@photostructure/exiftool-vendored`, it's explicit, in the package name, who you're trusting.
> ... did someone get unauthorized access ...
If they required publishing to be via 2FA-authenticated users, and (if I can dream), GPG-signed commits, I think you get most of the way there.
Github is starting greenfield here, and it's frustrating they didn't (at least afaict) require these small steps.
When I'm looking at a given package, I'd like:
1. Assurance that the package was published by the author
2. Assurance that the package contents were generated, in an externally repeatable way, from a release tag.
It seems like they could have lifted 1. by requiring 2FA and GPG.
It seems like their new Actions tab could have given us 2. It may, I can't tell from the demo.
And when I update my dependencies, I also want to see the diffs from the version I'm updating from. Github already has nice comparison views for arbitrary commit shas, so this should be doable as well.
That said, I'm sure Python, Go, Rust and other languages will be supported very soon.
You can also link directly to a package with `--find-links` if you specify an egg fragment, e.g. 'https://github.com/project/reponame/tarball/version#egg=pack.... (The version must match that in setup.py.)
There's no technical or political obstacle here.
Keep in mind it's in beta.
So, it's not really all that surprising of an initial set of choices for them to make.
There only other that I heard is anaconda, but that's made by 3rd party (not affiliated fir PSF), it is not just Python but also R since it targets scientific community. I also believe it is primarily used by windows users.
It is packaging for scientific tools that happen to also have python.
Edit: from another comment I see that underneath anaconda apparently uses PyPI for python packages (I didn't know, since I never used it) so it is not even a proper repo, just an abstraction to PyPI (and possibly whatever R is using)
Not saying Python doesn't have enterprise value, but we have to consider that this is an MVP, so it makes sense for them to limit to a subset of languages they feel comfortable about.
Installing directly from github is possible, but it works ok for a one off, if you have a package with your own dependencies then that doesn't scale.
It also covers source installations it doesn't work well for compiled.
The ability to provide any one with access to the repo access to the packages created from it removes an often frustrating management step.
I would be shocked if GitHub rate limited this new package registry. They're just serving tarballs and static content, and it's a new system so they can fully architect it with scale in mind (i.e. a CDN). They rate limit current repository-related content because they have to dynamically generate most of it in response to requests (I assume they have caching here as well, but not static-file-behind-CDN level caching).
I think, as many have said, that this is going after GitLab more than anyone else, although I can see a lot of users migrating away from Docker Hub given 1) the latest snafu/breach and 2) why keep my container repo over here and my container build pipeline over there? Doesn't make any sense and Docker Hub doesn't come with the pedigree of CDN baked in. I'm sure the same arguments work for other technologies in this consideration, but... Docker seems to continually be behind the 8-ball on the shifting field. My guess is Microsoft buys them in the next 3 years at a discount anyway. It fits their pattern of getting in front of the modern ecosystem and since Docker has leverage with containerd right now it would be an unsurprising move.