For programming languages, there are several examples of commercially run package managers:
- the Java/Kotlin/Scala ecosystem is based around maven central, which is run by Sonatype, Inc.
- Go modules are hosted by Google. Previously, most libraries were hosted on Github
- Rust's crate index is on Github
- The Docker/Moby registry is run by Docker, Inc. (though that might be a stretch for "package manager" :))
Note that the crates.io index is just a single git repo that holds JSON metadata about each crate: https://github.com/rust-lang/crates.io-index . The actual code found on crates.io is hosted on S3. The index is an important part of the system, but there's nothing tying it to Github specifically.
Ah, neat! Works out well for them; I assume it's relatively cheap to just serve an S3 bucket on their CDN (though I guess bandwidth costs may rise rather dramatically if Rust ever reaches Node levels of popularity), while not taking on any other operational expenses of actually running a registry.
CDN bandwidth by nature of the reach of Cloudfront will mostly be offload onto the local peering fabrics. It basically costs nothing in per mbit billing - e.g. linx https://www.linx.net/wp-content/uploads/2017/10/Fees_Schedul.... 100gb hand. That's not to say there aren't other major costs in running a resilent edge network which go someway to justify 0.0Y/GB pricing where Y varies from 1-9 depending on location for non sponsored projects. tl;dr - it won't ever be a problem
Technically the Go module _proxy_ is hosted by Google. Even if the proxy went away, you'd still be able to get access to all of the packages as they're still hosted elsewhere. It just wouldn't be as fast.
Maven Central has mirrors and alternatives and you can trivially host your own repository, all you'd need is a plain web server serving a bunch of static files.
Some libraries aren't hosted on Maven Central actually, so it's not uncommon to see instructions for adding extra resolvers to your build config.
The Java ecosystem isn't as dependent on Maven Central as the JavaScript ecosystem is on npmjs.com
Almost every library out there is on Maven Central. Even Oracle JDBC drivers are now (finally) on Maven Central.
If MC goes away as it exists today, the Java Ecosystem will take a huge hit as almost every open source project would stop building in CICD environments from the get-go.
If it vanished instantly then yes, but a huge number of packages on Central are mirrors from jcenter. There are not only theoretical competitors to Maven Central but an actual widely used one (jcenter/bintray), which is easier to use anyway. There's also jitpack too. So people could migrate pretty quickly to alternatives.
You're not technically wrong, but I bet that 90% of the projects or at least the examples have some sort of intentional or unintentional reliance on Maven Central, that would break the build if it weren't there. Even a lot of companies that set up internal repositories don't realize that they hit still are gonna hit Maven Central initially, before everything is bootstrapped, depending on how things are configured. It would reflect just really poorly on the Maven ecosystem (or any ecosystem alike, I have to assume, but know less about) if the canonical repository would just... "poof".
I think the point is that you are using a commercial entity to host your code. There is a bill for the code you have hosted, and you aren't the one paying for it.
Our team at SC is looking for an experienced search engineer to help us help our users discover SoundCloud's huge and unique catalog of music and audio.
Working on one of the leading music platforms on the web, this is a great opportunity to apply your skills to make a measurable difference to millions of people around the globe. Our services tend to be written in Go and Scala; data munging happens with Elasticsearch and Spark. Familiarity with these is a plus, though frankly eagerness to learn is more important.
If you are experienced in information retrieval or a related field (such as recommendations, information extraction, question answering etc.) and passionate about developing and evaluating data-driven products, get in touch!
On a personal note, I've learned a lot and had a great time here. If search isn't your thing, take a gander at https://soundcloud.com/jobs, there's a bunch of interesting open positions.
Our team at SC is looking for an experienced search engineer to help us help our users discover SoundCloud's huge and unique catalog of music and audio.
Working on one of the leading music platforms on the web, this is a great opportunity to apply your skills to make a measurable difference to millions of people around the globe.
Our services tend to be written in Go and Scala; data munging happens with Elasticsearch and Spark. Familiarity with these is a plus, though frankly eagerness to learn is more important.
If you are experienced in information retrieval or a related field (such as recommendations, information extraction, question answering etc.) and passionate about developing and evaluating data-driven products, get in touch!
https://soundcloud.com/jobs/2016-02-19-search-engineer-berli...
On a personal note, I've learned a lot and had a great time here. If search isn't your thing, take a gander at https://soundcloud.com/jobs, there's a bunch of interesting open positions.
Our team at SC is looking for an experienced search engineer to help us help our users discover SoundCloud's huge and unique catalog of music and audio.
Working on one of the leading music platforms on the web, this is a great opportunity to apply your skills to make a measurable difference to millions of people around the globe.
Our services tend to be written in Go and Scala; data munging happens with Elasticsearch and Spark. Familiarity with these is a plus, though frankly eagerness to learn is more important.
If you are experienced in information retrieval or a related field (such as recommendations, information extraction, question answering etc.) and passionate about developing and evaluating data-driven products, get in touch!
On a personal note, I've learned a lot and had a great time here. If search isn't your thing, take a gander at https://soundcloud.com/jobs, there's a bunch of interesting open positions.
if you're piping the output of tar, instead of using "tar f -", you can leave off the f argument (since you don't want to specify a file anyway) and tar will default to stdin/stdout:
$ tar cz foo | ssh remote "cd /where/to/unpack && tar xz"
For GNU tar these days that's true, unless you can be sure $TAPE is in its environment. Historically, tar defaulted to a tape device, e.g. /dev/mt0, and you still find vestiges of that, e.g. OpenBSD defaults to /dev/rst0.
another gripe was the fact that the "backdoor within a backdoor" functionality (which AFAIK was ruled unlawful by German courts) is the only part of the trojan that tries to hide what it does.
[1]: https://blog.gitbutler.com/gitbutler-is-now-fair-source/