Live data from Hacker News

Gogs – Go Git Service

gogs.io

171–180 of 186 posts

Re: Gogs – Go Git Service

#171

I use gogs at home, but run Gitlab At work - it just has so more many more features and far more customisable - also Gitlab CI rocks, it seems to scale really well - 60 active developers on a tiny vm and its lightening quick and we can easily do more than 100 releases a day.

Glad to hear that you like GitLab CI. Continuous Delivery FTW!

Re: Gogs – Go Git Service

#173
post #76
post #69

Earlier quoted context omitted.

Same here. Gitlab is soooo extremely slow. Even on their own site many pages take several seconds to load. And no one really seems to care. Gogs is a great relief.

GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42

Are you still on Azure or have you moved on? You had several blog/twitter posts about how unreliable Azure is and documented some quirks like failed reboots. But arguable you got Azure cloud for free. Don't look a gift horse in the mouth. But what's worse? I read about the problems since November 2015. Maybe invest in Google/AWS cloud and don't run it on a single NFS.

Re: Gogs – Go Git Service

#174
post #173
post #76

Earlier quoted context omitted.

GitLab.com is slow because of operational issues, like everything running from one NFS server. GitLab on your own server with enough memory should be fast. The slowness of GitLab.com is unacceptable to us, work to improve it is ongoing in https://gitlab.com/gitlab-com/operations/issues/42

Are you still on Azure or have you moved on? You had several blog/twitter posts about how unreliable Azure is and documented some quirks like failed reboots. But arguable you got Azure cloud for free. Don't look a gift horse in the mouth. But what's worse? I read about the problems since November 2015. Maybe invest in Google/AWS cloud and don't run it on a single NFS.

We're still on Azure. We got a lot of help from Microsoft to work out the things we encountered. They have been very helpful and we plan to stay on Azure for now. Getting rid of the single NFS server is our next step.

Re: Gogs – Go Git Service

#175
post #140

Earlier quoted context omitted.

The problem is that we should distribute the load over multiple servers https://gitlab.com/gitlab-com/operations/issues/1 Right now the lonely repository server has over 200k context switches per second.

Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)

Thanks for the advice, do you maybe have a link with more details?

Re: Gogs – Go Git Service

#176
post #161

Earlier quoted context omitted.

The truth is, nobody personally vets the source of all the software they use. Even people who compile everything themselves aren't reading the source code that came over the wire. It baffles me when people fret over "don't blindly run that curl|bash installation script because security!" when nobody would bat an eye at a .deb downloaded from the same web site.

There are many that take an interest in securing their workstations, just as there are many negligent individuals who blindly run things they download from somewhere. A minimum amount of care when installing things (checking signatures/checksums, reading install scripts, etc) should be common sense and not doing that is grossly negligent.

What's the point of reading an install script if you don't also read the source of what the script is installing? That's like a proofreader only editing the intro paragraph and then signing off on the entire essay.

Re: Gogs – Go Git Service

#177
post #151

Earlier quoted context omitted.

That's how WAR files get built. It's a very standard mechanism for deploying Java apps. I think having Java on your machine is a reasonable requirement. I mean the equivalent in Ruby would be to have Ruby, install all gems and THEN launch the app.

If you actually want to run this software, JVM is a reasonable requirement: it's well-known, well-tested, easy to install, and comes in one package. It's not zero requirements, though. (Go binaries still need platform-specific libc, AFAIK, but it's usually also a reasonable requirement.)

Actually, they mostly don't. Go doesn't use libc, fortunately.

Re: Gogs – Go Git Service

#178
post #129

Earlier quoted context omitted.

It's not really a static Python .exe, but PyInstaller can create a single executable that embeds all of its dependencies in the file. Except for a small delay at startup it works really well.

This is how I distribute Grow (grow.io), a Python program. It's worked really well so far, but it's also produced a few issues in development, for me. For example, PyInstaller itself changes drastically from version-to-version, and I've previously had to spend hours picking away at why "compiled" Grow worked before but no longer works post-PyInstaller updates. Overall happy though, and much happier to write in Python…

The python distribution story is far behind Go. This article goes into more details: https://glyph.twistedmatrix.com/2015/09/software-you-can-use...

PS: I'm the original author of PyInstaller. I obviously love it but it's a gross hack around the fact that Python doesn't have a serious distribution story.

Re: Gogs – Go Git Service

#179
post #175

Earlier quoted context omitted.

Your engineers probably know this, but CephFS is not well known for handing high IOPS loads; make sure to architect accordingly :)

Thanks for the advice, do you maybe have a link with more details?

Mirantis gave a talk last year at OpenStack with real-world numbers... They had to scale to 500 storage nodes to achieve 50k IOPS aggregate.

https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...

Re: Gogs – Go Git Service

#180
post #175

Earlier quoted context omitted.

Thanks for the advice, do you maybe have a link with more details?

Mirantis gave a talk last year at OpenStack with real-world numbers... They had to scale to 500 storage nodes to achieve 50k IOPS aggregate. https://www.openstack.org/summit/vancouver-2015/summit-video... https://www.slideshare.net/mobile/mirantis/ceph-talk-vancouv...

Wow, thanks for those numbers and the links, I've added them to https://gitlab.com/gitlab-com/operations/issues/1#note_44836...
Post reply on HN