ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Main Area and Open Discussion > General Software Discussion

Microsoft to buy GitHub in $7.5B all-stock deal

<< < (7/13) > >>

f0dder:
(Although I wonder why most people ignore the fact that they are mad about their preferred "DVCS" hoster being bought... Git's target audience does not seem to be the brightest of all.)-Tuxman (June 04, 2018, 01:56 PM)
--- End quote ---
Are you implying they're silly because "it's DVCS, they can just move elsewhere"?

In that case, please keep in mind that the repository hosting is the smallest part of what GitHub offers - it's all the stuff built on top and around that makes it worthwhile.

Also, many projects and even programming languages (talking to you, Go!) natively integrate GitHub as their package repository. That means that not only the official source would be gone for a while - large parts of the software world wouldn't even compile anymore. That's a bad sign.-Tuxman (June 05, 2018, 12:57 AM)
--- End quote ---
Same goes for the JVM world and the main maven repository, the node.js hipsters and npm, et cetera.

Is there any language/ecosystem that has a nice package repository without a single point of failure?

Tuxman:
Are you implying they're silly because "it's DVCS, they can just move elsewhere"?-f0dder (July 15, 2018, 04:20 PM)
--- End quote ---

I am implying that the hostname of the upstream DVCS repository does not matter to anyone who even remotely understands his shiny plaything.

In that case, please keep in mind that the repository hosting is the smallest part of what GitHub offers - it's all the stuff built on top and around that makes it worthwhile.-f0dder (July 15, 2018, 04:20 PM)
--- End quote ---

Like what? The issue tracker? Indeed, it is a rather dumb idea to sacrifice yourself to voluntary vendor lock-in - but that's not Microsoft's fault at all. As if Microsoft would endanger your precious bug reports...

Same goes for the JVM world and the main maven repository, the node.js hipsters and npm, et cetera.-f0dder (July 15, 2018, 04:20 PM)
--- End quote ---

Agree.

Is there any language/ecosystem that has a nice package repository without a single point of failure?-f0dder (July 15, 2018, 04:20 PM)
--- End quote ---

Every centralized repository is a single point of failure. IMO, the sanest approach is C's: You'll just get your headers/libs from your OS vendor.

f0dder:
I am implying that the hostname of the upstream DVCS repository does not matter to anyone who even remotely understands his shiny plaything.-Tuxman (July 15, 2018, 04:33 PM)
--- End quote ---
Yes, this detail doesn't matter that much - there's an inconvenience in getting all the references fixed, and that's it. That you're suggesting this is the issue is silly, though, since it's really about #2.

Like what? The issue tracker? Indeed, it is a rather dumb idea to sacrifice yourself to voluntary vendor lock-in - but that's not Microsoft's fault at all. As if Microsoft would endanger your precious bug reports...-Tuxman (July 15, 2018, 04:33 PM)
--- End quote ---
Issue tracker, pull requests, wiki, github pages, discoverability, the social aspect. The integrated two-factor auth stuff... teams... stats... the commercial support... access control... vulnerability scanning... GitHub is a really well-working and polished product. It gives you loads of features you don't get with a bare "just a file storage bucket" repository.

You can't avoid vendor lock-in unless you go for an on-premise solution. It's been a while since I checked out GitLab (but they do both cloud and on-prem, right?) - but I've worked a fair bit with Atlassians Stash/BitBucket. It can run on-prem, but it's not open-source, and while it's a good product, it's lagging quite a bit behind what GitHub offers.

And sure, Git is a DVCS. But in and by itself it's not super effective for collaboration, especially when you're outside a single team or company... you need an additional layer on top of the raw DVCS. If everybody runs different systems, collaboration gets harder.

Every centralized repository is a single point of failure. IMO, the sanest approach is C's: You'll just get your headers/libs from your OS vendor.-Tuxman (July 15, 2018, 04:33 PM)
--- End quote ---
You've got to be joking.

There's so much wrong with this idea that I don't even know where to start - that'll be for tomorrow :)

Tuxman:
If you absolutely don't want to self-host your stuff, you will be surprised how evil all companies are when it comes to making money ...  :D
Atlassian makes absolutely awesome software IMO.

And no - I'm never joking!

Shades:
It's been a while since I checked out GitLab (but they do both cloud and on-prem, right?)
-f0dder (July 15, 2018, 04:56 PM)
--- End quote ---

@f0dder:
Yes in both cases. Last Friday I started running a docker image of GitLab (Community Edition) on a test server in my own network, just to see for myself what the fuss is about. So far it leaves a good impression, but you can expect to lose quite some time configuring it. The enterprise edition has more features, so that will be even more "fun".

Although it is more work, I would recommend to do a GitLab installation from the ground up. The Docker solution (or similar software) is decent, but I barely see how Docker is helping me for my particular use-cases.

In any case, GitLab does work on-premise. Documentation is handled well. As far as I have seen it at least. But don't expect it to run on a Windows server any time soon, if at all. It looks like it will be a Linux and MacOS only product. On my Ubuntu Server 18.04 LTS computer it works fine. The Docker website indicates that there is a 'Docker for Windows' application available (which doesn't work on Windows Server 2012 R2), but that it not officially supported. And if you do have 'Docker for Windows' running on your system, the GitLab website says that they will not support GitLab with that software anyway. In short, if you want to run GitLab on Windows, you are on your own.
 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version