41–50 of 71 posts
Earlier quoted context omitted.
> If GitHub achieves feature parity, GitLab is dead. Maybe , assuming GH matches them at the same price points per feature and including self-hosting as a feature.
GitHub does offer self-hostable enterprise edition, but its price is not publicly available.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
GitLab don't have to worry too much. Their uptime has been fine for us over the course of several years. And it's good that GitLab is around, so that we don't have to worry quite so much about Microsoft/GitHub messing around with the code in international projects. They have a great history[1] of co-operating with nefarious people. (And no, most people do not sign their commits and watering hole attacks are an obviou…
Some will continue to prefer a self-hosted GitLab instance over GitHub, but requiring at least 4GB of RAM [1] for a low traffic instance sounds like an aberration. There should be better ways to manage memory consumption, and a lean GitLab instance that we have full control over could still be their selling point over GitHub. [1] https://docs.gitlab.com/ce/install/requirements.html#memory
What a strange post. GitLab is under siege from GitHub. The argument for GitLab has always been that they are more feature-rich, the argument for GitHub has been that their uptime is >80% and their UX is excellent. If GitHub achieves feature parity, GitLab is dead.
The arguments for gitlab are that they are open source and that self-hosting isn't an afterthought. We need more of both.
I ran a company that was in the GitHub marketplace and was a partner. At the GH partner day a few years ago they shared their view the world: their thinking was that it was preferable for devs to be able to use “best in class” tooling for CI, project management, etc, with gitHub’s version control at the center.
GitHub contrasted this with the “one stop shop” approach where you get all your Dev needs met with (presumably) inferior tools from a single vendor.
Because, the thinking went, how could one vendor do everything better than many vendors? Especially if you have sets of vendors focused on one tool in the Dev toolchain?
Between Projects, Actions, and CI/CD, it seems GItHub has indeed come around to the one stop shop view of the developer toolchain.
I guess each of those only has to be good enough and not best in class. And there are efficiencies to be gained for customers from an integrated approach.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
GitLab don't have to worry too much. Their uptime has been fine for us over the course of several years. And it's good that GitLab is around, so that we don't have to worry quite so much about Microsoft/GitHub messing around with the code in international projects. They have a great history[1] of co-operating with nefarious people. (And no, most people do not sign their commits and watering hole attacks are an obviou…
That said, I do SOME work in GitHub to stay familiar with it. And I've set up web gonna to push to lambdas, but I would probably hate that process if I wanted to clone a private repo and had to deal with the security there.
Every time github releases a feature this is the response. These posts are so pathetic. I’m surprised that they continue to play this angle. It’s a very polarizing way to address the community that will definitely continue to stir up us vs them mentality between GitHub and Gitlab users.
It's especially rich considering Gitlab is, or at least was, an almost identical clone of Github. Didn't they actually use Github's exact HTML at the beginning, including several instances of "GH" or "GitHub" as class names etc?
The Unix Philosophy is dead today, but I don't believe that's because of any inherent flaw in the principle of "composability". It's that we no longer have a good composition mechanism for the types of programs that people run.
In 1975 or 1985, you were running a command-line tool to process some data. (That kind of sucked, but whatever, that's what we had.) The idea of being able to pipe bytes from the output of one to the input of another is pure win. Fewer steps, no temp files, see results as they are completed -- and the cost is literally one character. No wonder it took off.
Today, the types of programs people run are native apps (which don't have an obvious I/O mechanism, apart from the filesystem, if that) and web pages (i.e., programs awkwardly split across my computer and some server in Virginia, speaking an ad-hoc protocol). Making them talk to each other takes a developer and a month.
I'd love to be able to have a web app, a word processor, my contact list, etc., talk to each other and easily and meaningfully pass data between them (and I'm working on software to do just that -- see my bio). Why can't I pipe my Facebook friends list straight to a spreadsheet, or a map?
They speak of the efficiencies of having a single application. It's more the lack of an efficient standardized way to combine different applications. Back when it was "type one character", the efficiency argument went the other way. We need to get back to where sharing data with every other program is the default.
Auto patching and deploying to production in an automated fashion sounds like a terrible idea. Do people actually do this? Does it work for them?