Anyone remember when Github took down youtube-dl?
I wonder how much Big Brother data Microsoft is gathering on Github developers. "Oh, as part of our hiring process, just like we scan your FB and Twitter, we also scan your Github activity to evaluate your performance as best as our machine learning overlords can assess it. Do you create Github projects and then abandon them when unfixed issues accumulate? Our algorithm thinks you're a bad hire."
I would blame the law (DMCA), not those forced to abide by the law (Github)
Public support on which grounds?
Did GH ignore a counter notice?
What about those abusing [a misrepresentation of] the law (the RIAA) and the members who pay their dues (Microsoft)?
> I would blame the law (DMCA), not those forced to abide by the law (Github)
It seems even in the context of US-based companies that some companies are a little more "trigger-happy" with DMCA and other claims compared to others.
In another thread a few weeks ago about code signing, I mentioned we should just hand Apple Source code for the apps it distributes in the store, to make review more thorough and reliable. Replies objected "Why would you give your source code to another company?" ........ and github is still a thing? ( https://news.ycombinator.com/item?id=28794243)
Also, ironic De Icaza ended up working for... the company he wanted to work for all along, ...Microsoft. Though Friedman left Microsoft (or at least stepped down as GitHub CEO).
De Icaza was also featured in the Finnish movie The Code [1].
I'd say those people do have a point about how manipulation tactics work, but email being inconvenient is bullshit.
On the other hand, you have email: open-source clients are available for virtually every platform, it doesn't turn my laptop into an electric bar fire, it doesn't drain my phone's battery (or if it does, I could just install another client!), etc.
It's quite sad how something as beautiful as email is being replaced by corporate garbage like Teams, which comes bundled with Office 365 (and that's a whole 'nother crapfest). Uch.
This data is public and to be honest I’m amazed we haven’t yet seen a YC startup promoting that they do exactly this.
This is pretty much why many organizations out there, as well as i personally for my homelab use self-hosted GitLab instances: https://about.gitlab.com/
Though in practice there are a lot of other options out there, like Gitea (https://gitea.com/) and GitBucket (https://gitbucket.github.io/), though maybe less so for alternative source control systems (e.g. SVN has been all forgotten, however that's a personal pet peeve).
Not only that, but i also utilize my own Sonatype Nexus (https://www.sonatype.com/products/repository-oss?topnav=true) instances to great success: for doing everything from mirroring container images that i need from DockerHub (e.g. due to their proposed removal policies for old images and already adopted rate limits), to mirroring Maven/npm/NuGet/pip/Ruby and other dependencies, so i don't have to connect to things on the Internet whenever i want to do a new build.
That not only improves resiliency against things on the Internet going down (apart from situations where i need something new and it's not yet cached), but also improves performance a lot in practice, when only the company servers need to be hit, or my own personal servers in the data center for my cloud hosted stuff, or my own personal servers in my homelab for my own stuff.
Admittedly, all of that takes a bit of setup, especially if you happen to expose anything to the web in a zero trust fashion (permissible for my own stuff, as long as i'm okay with manually managing CVEs just to probably get hacked in the end anyways, but definitely not something that any corporation with an internal network would want to do), but in my eyes that's still worth the effort, if you value being in control of your own software stack and the ecosystem around it.
It's probably much less worth it, if you don't see that as a benefit and don't want to be the one responsible for whatever project you're working on getting hacked, e.g. if you'd fail to patch out the recent GitLab CVE where exiftools could execute arbitrary code, which is probably the case if you don't have the resources to constantly throw at maintenance, in comparison to companies with 100x - 1000x more resources than you have for that sort of stuff.
Otherwise nobody will notice how fragile their workflow is until it is too late to fix it!
All other tests, including the ones on the CI server, were connecting to the hosted integration environment for any unmocked call (and thus randomly modifying state there).
That's right. Someone should really come up with a decentralized VCS. /scnr
Setting up your own git server is not hard, but it's not as easy as just getting github or gitlab to run it for you. Way too many people take the easier path, even though the harder path is not actually that hard.
There are also multiple solutions.
Bullshit. Getting it set up in a secure and public way is an order of magnitude or two more difficult than it would need to be for mass use which is what we're talking about here.
When you have a situation where a the vast majority of people find something too difficult, the problem (from the perspective of actually getting it happen) is not the people the problem is with the proposed solution.
> There are also multiple solutions
Multiple solutions does not generally make things easier/better even if it's desirable for other reasons.
Rust has a robust memory model, but everything else about it insists on copying the fragility of the NPM ecosystem.
The recent hoopla around a bunch of Rust mods quitting revealed that my suspicions are precisely true — key Rust staff also sit on the NPM board!
For the worst offender I am aware of, try building a flutter project... it silent internet gets artifacts from at least three different packaging systems (node, cocoapods, android packages), all of which have caused hard-to-debug failures.
For example distris like Debian even mandate that you build software for them only relying on things that are already packaged. No arbitrary internet downloads allowed during build. The build environment contains only what is provided by the stated build-dependencies of your package, which are themself of course Debian packages, and some common minimal build base (like shell and some utils).
What if the distribution's version doesn't support the features you need?
What if it can't be built by relying only on things that are already packaged?
How do you distribute your software so it runs on other distributions? Do you maintain a different build for each package manager?
What if you want to run on platforms that don't have standard package managers, like MacOS or Windows?
How do you update the packages without internet downloads during provisioning the build?
The C/C++ model has proven to be fatally flawed. It hasn't worked, that's why modern languages eschew reliance on the distributions' package managers, and greenfield C/C++ projects use the same model.
I'd go so far as to say this model is a key reason why we need containerization to deploy modern software today - since you can't trust software written on distro X runs on distro Y because it packages dependency Z differently all the way up to the root of the dependency tree (glibc, usually).
The fundamental flaw of this model is that it inverts the dependency tree. Build time dependencies are local to individual projects and need to be handled separately from all other software. With few exceptions, Linux distros make this mistake and it's why we can't rely on distro package management for new projects.
You package it.
> What if the distribution's version doesn't support the features you need?
You package the version that does.
> What if it can't be built by relying only on things that are already packaged?
You package the dependencies first.
> How do you distribute your software so it runs on other distributions?
Give them the source so they can package it.
> Do you maintain a different build for each package manager?
Yes, that's the whole idea behind distributions.
> What if you want to run on platforms that don't have standard package managers, like MacOS or Windows?
Well, there you anyway downloaded random things form the internet…
But nowadays even those systems have package management that can be used!
> How do you update the packages without internet downloads during provisioning the build?
It's not about disabling package downloads (which come form a trusted source btw).
It's about disabling downloads form random places on the internet.
Also you can use a local package mirror. That's what the build systems of distributions do.
> The C/C++ model has proven to be fatally flawed. It hasn't worked, that's why modern languages eschew reliance on the distributions' package managers, and greenfield C/C++ projects use the same model.
Well, except for all packaged software out there…
> I'd go so far as to say this model is a key reason why we need containerization to deploy modern software today
Nobody needs that. Software form packages just works fine. All the Linux installations around the globe are a prove of that fact.
> since you can't trust software written on distro X runs on distro Y because it packages dependency Z differently all the way up to the root of the dependency tree (glibc, usually).
Of course you can. It works exceptionally fine. After you packaged it.
> The fundamental flaw of this model is that it inverts the dependency tree. Build time dependencies are local to individual projects and need to be handled separately from all other software. With few exceptions, Linux distros make this mistake and it's why we can't rely on distro package management for new projects.
More or less every distro does it wrong? And you know how to do it correctly?
Maybe you should share your knowledge with the clueless people building distributions! Get in touch with for example Debian and tell them they need to stop making this mistake.
By the way: How does your software reach the users when it's not packaged?
At least I hear "sometimes" that users demand proper software packages. But maybe it's just me…
>More or less every distro does it wrong? And you know how to do it correctly?
Yes, exactly. For distribution you use snap and flatpak, or application bundles on MacOS and Windows. For building you use a package manager that can install vendored dependencies pinned to specific versions, and do it locally to individual projects so they are not shared across multiple projects. This is the tact taken by modern tools and languages.
It's not my idea! It's what everyone building software in the last decade has migrated to.
Packaging software so it can be used by any distro's package manager is not viable, and reliance on such an outdated model is why using Linux sucks for everything but writing software to run on a single machine.
> At least I hear "sometimes" that users demand proper software packages. But maybe it's just me
And when they do you almost never go through the official/trusted mirrors because it will never be up to date, you host your own (maybe put up some signature that no one ever checks) so they just `sudo apt repository add ; sudo apt-get install -y` in your install instructions.
Well, everybody besides the biggest free software distributors out there, which are Linux distributions…
> Packaging software so it can be used by any distro's package manager is not viable, and reliance on such an outdated model is why using Linux sucks for everything but writing software to run on a single machine.
Yeh, I get it. That's why we need Docker…
Nobody is able to distribute software otherwise.
Well, except all those "distributions"…
> And when they do you almost never go through the official/trusted mirrors because it will never be up to date, you host your own (maybe put up some signature that no one ever checks) so they just sudo apt repository add ; sudo apt-get install -y in your install instructions.
Moment. Does this mean someone managed to build packages that work on different versions of even different distributions, which is obviously impossible as we just learned?
This starts getting hilarious!
I'm sorry for you that nobody want's to listen to your great ideas. Have you ever considered that you're completely wrong?
Sorry, could you elaborate on why Linux "sucks" for anything but single-user, please? I haven't heard this argument.
This way, if GitHub falls off of the face of the earth tomorrow, the packages still build. Also: If some open source maintainer deletes an older version of a package, replacing it with a new one with a different API, the local package will still build.
(The local build process will have to be set up to use the local artifactory to pull dependencies, of course.)
Note you also need to build differently if you go this route: `-mod=vendor`, otherwise the directory will be ignored in modern Go.
-mod mode
module download mode to use: readonly, vendor, or mod.
By default, if a vendor directory is present and the go version in go.mod
is 1.14 or higher, the go command acts as if -mod=vendor were set.
Otherwise, the go command acts as if -mod=readonly were set.
See https://golang.org/ref/mod#build-commands for details.
As for building with a flag: true, but very minor, as it's rare to execute 'go build' directly. In most projects I've seen, it's either Bazel, or some kind of "build.sh".
If one of the goals of your build process is to be able to guarantee reproducible builds for software you've shipped to customers, and you depend on open source libraries from third parties you don't control, hosted on external services you don't control, then you probably need your own copies of those dependencies. Maybe vendored into version control, maybe sitting in your server of mirrored dependencies which you back up in case the upstream project permanently vanishes from the internet. But setting up and maintaining it takes time and effort and maybe it's not worth paying that cost if the context where your software is used doesn't value reproducible builds.
Go doesn't use a repository as a single source either, which is another problem in of itself.