Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gogs – Go Git Service

gogs.io

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Gogs – Go Git Service

#131

Post by dumbguy »

ycmbntrthrwaway wrote: post #123
tschellenbach wrote: post #93

Earlier quoted context omitted.

They should. Github obviously spent countless hours perfecting their UI. Other apps shouldn't be allowed to copy it. (I have no affiliation with Github, other than that I'm a developer and respect the hard work they've put into their product.)

It is even worse than copyrighted APIs. Such attitude will allow Microsoft to sue KDE for Windows look-and-feel and LibreOffice for Office look-and-feel, even without patents. Good features and ideas should be copied as widely as possible instead of reinventing the wheel for the sake of difference.

Someone needs to pay the bills.

Re: Gogs – Go Git Service

#133

Post by mh-cx »

sytse wrote: post #108
mh-cx wrote: post #81

Earlier quoted context omitted.

Can't confirm that. I have to work with gitlab with different customers on several independent project teams. No installation feels fast. Memory is >2GB. Also have it here on a machine with 4GB. No page loads under 1 s. And the ajax requests seem to take even longer than a full page reload. Its a pitty you now load almost everything with Ajax and there's no option to turn that off. I often find myself to click a seco…

Thanks for your feedback. As we added more and more functionality to GitLab it probably has gotten slower. Since a few months we have 2 people working on improving performance fulltime. As you can see in https://gitlab.com/gitlab-com/operations/issues/42 our focus is GitLab.com performance but many of the changes should also improve the speed for on-premises installations. Changes include fewer calls to git, better c…

Sounds good. But honestly since I've read this my faith in the ruby/rails stack (or is it the gitlab devs?) is somewhat limited: http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.ht...

A quite forthright confession of memory leaks - with imo questionable countermeasures.

Re: Gogs – Go Git Service

#134

Post by tbrock »

jonathankoren wrote: post #89
schmichael wrote: post #53

Earlier quoted context omitted.

A lot of Java software is also "(1) download the tar, (2) run bin/whatever which is a 500 line bash script for setting up the jvm environment"

6 of one, half a dozen of the other. As long as it's behind and simple interface and it works, I don't care what it actually does.

And..., just like that, you are part of a bot net.

Re: Gogs – Go Git Service

#135

Post by [deleted] »

shimon wrote: post #115
Spivak wrote: post #109

Earlier quoted context omitted.

Does the argument really change if they spent a weekend on the UI?

Yes, because if the design is trivial, or obvious given the problem domain, then the thing being copied doesn't meet the bar for being a creative work.

[deleted]

Re: Gogs – Go Git Service

#136

Post by BHSPitMonkey »

tbrock wrote: post #134
jonathankoren wrote: post #89

Earlier quoted context omitted.

6 of one, half a dozen of the other. As long as it's behind and simple interface and it works, I don't care what it actually does.

And..., just like that, you are part of a bot net.

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.

Re: Gogs – Go Git Service

#137

Post by sytse »

mh-cx wrote: post #133
sytse wrote: post #108

Earlier quoted context omitted.

Thanks for your feedback. As we added more and more functionality to GitLab it probably has gotten slower. Since a few months we have 2 people working on improving performance fulltime. As you can see in https://gitlab.com/gitlab-com/operations/issues/42 our focus is GitLab.com performance but many of the changes should also improve the speed for on-premises installations. Changes include fewer calls to git, better c…

Sounds good. But honestly since I've read this my faith in the ruby/rails stack (or is it the gitlab devs?) is somewhat limited: http://doc.gitlab.com/ce/operations/sidekiq_memory_killer.ht... A quite forthright confession of memory leaks - with imo questionable countermeasures.

Blame us more than the stack. These memory leaks are hard to diagnose. Our meta issue to do this is https://gitlab.com/gitlab-org/gitlab-ce/issues/3700 We're currently we're more focussed on improving responsiveness and plan to address the memory leaks and a multithreaded app server https://gitlab.com/gitlab-org/gitlab-ce/issues/3592 after that.

Re: Gogs – Go Git Service

#138

Post by patrickaljord »

kevinSuttle wrote: post #82
skj wrote: post #14

Earlier quoted context omitted.

Why? Github is about distribution and collaboration with a community. This product seems to be about private self-owned hosting.

Then why aren't they hosting on their own product?

Because that would be public hosting, parent just explained that gogs is great at _private_ hosting. When it comes to public hosting of open source projects with network effect, github is still king. I don't think anyone denies that.

Re: Gogs – Go Git Service

#139

Post by andor »

mateuszf wrote: post #68
andor wrote: post #60

Earlier quoted context omitted.

If package management is important to you, you might want to try an operating system that integrates it natively.

The point of "run anywhere" is to not have to search for a special operating system.

I wouldn't conflate the "run anywhere" aspect with OS-level package management.

How operating systems handle updates is unrelated to Java, and affects other applications on the system as well. Think about other "run anywhere" technology like Flash, PDF (Adobe Reader), Microsoft Office, Browsers -- they also don't have a great security story and need constant updates. Adobe and Sun decided to ship their software with "Update Managers". Everybody loved them (not), but at least they fulfilled their purpose. 10 years later, Google added background updates with binary patching to Chrome on Windows and Mac OS (not needed on Linux). They decided to just install updates without the user's consent, because that will at least keep them safe. Google can get away with it because everybody expects them to know what they're doing. But I certainly don't want downloading code at runtime to become the norm.

That's why distributing updates for third-party apps should be an operating system feature, as it is in all popular Linux distributions. Microsoft and Apple, please feel free to copy.

Re: Gogs – Go Git Service

#140

Post by sytse »

matheweis wrote: post #127
sytse wrote: 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

Properly tuned NFS should be extremely fast... I've managed NFS clusters for HPC that exceeded 800Mbit/s and 20k IOPS

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.
Post reply on HN