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

151–160 of 186 posts

Re: Gogs – Go Git Service

#151

Post by nine_k »

sandGorgon wrote: post #87
geodel wrote: post #49

Earlier quoted context omitted.

40MB download + requirement of Java Runtime (~100MB) to be present is not quite same. Though to their credit they have packaged all jar dependencies besides JRE in WEB-INF/lib

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.)

Re: Gogs – Go Git Service

#152

Post by voltagex_ »

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.

Sure, but if I'm really worried, egress filtering will catch it or the VM won't be allowed to connect out to any non-whitelisted hosts.

Security is about defense in depth, not just "don't run anything you haven't read in detail" - have you read the code of the web browser you posted with?

Re: Gogs – Go Git Service

#153

Post by robmccoll »

raimue wrote: post #71
robmccoll wrote: post #64

Earlier quoted context omitted.

You do run into false dependencies causing needless headaches with dynamic libraries though. There's a vulnerability in hash X in OpenSSL. One (or worse zero) of my 15 installed applications that depend on OpenSSL actually uses hash X, but in order to upgrade, I have to carefully manage those 15 dependencies. With statically linked dependencies, the hash X code wouldn't be in any of the other binaries and I only upda…

What do you mean by managing dependencies? You upgrade to an OpenSSL version that fixes hash X and be done with it? I don't understand your point.

I guess under the assumption of everyone following sane versioning practices, maintaining alias symlinks, and/or really solid package management and compatibility testing, this isn't such an issue. If the system admin was compiling a lot of their own libraries and binaries that don't necessarily follow those best practices, it becomes more of a problem. The system admin doesn't know what functionality in the library is used by each binary and weather or not the upgrade is really necessary. If the binaries are self-contained and statically linked, the maintainer of the actual software can stay abreast of security updates in the libraries that they are using and ship updates only when vulnerabilities affect functionality that they use. The sys-admin then only has to download updated binaries if truly necessary and tracking any dependencies on the end-user system becomes unneeded. Not really arguing that it's a better setup. It does mean that software maintainers have to stay active and on-top of security patches. The complexity is inherent, it's just a matter of shifting it around onto different people.

Re: Gogs – Go Git Service

#154

Post by LukeShu »

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.

Well, it's more like:

(2) run bin/whatever which is a 500 line bash script for setting up the jvm environment that has a 50% chance of not working if you are on a distro that's not Ubuntu or RHEL, and probably also fails if it takes a filename and you give it a filename containing a space.

Re: Gogs – Go Git Service

#155

Post by beefsack »

gnuvince wrote: post #30
Mahn wrote: post #27

> How to use downloads? > 1. Extract the archive. > 2. cd into the directory just created. > 3. Execute ./gogs web and you’re done. Can't beat the simplicity of running Go applications. It's funny because running a compiled binary is so incredibly basic to computing, and yet 90% of the time installing a new shiny toy in a server involves dealing with 342525 dependencies, half of which broke because god knows what dep…

A lot of Java software is "(1) download the jar file, (2) java -jar thefile.jar". Agree it's good for the user, but when people talk about distributing a statically-linked program the "what about security updates" question invariably comes up.

Assuming you have the JVM installed.

Re: Gogs – Go Git Service

#156

Post by sandGorgon »

geodel wrote: post #96
sandGorgon wrote: post #87

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.

Why Java on machine is reasonable requirement? The Gogs service does not need Go to run. So having Java is extra requirement for Gitbucket. I know about packaging and running Java web apps. I am pointing out that compare to Gogs, Java based solution has extra requirement of JRE which I have to keep patched and updated. And this is independent of any fix/improvement of Gitbucket itself.

Your patched and updated argument is an equivalent one.

Are you saying if go gets updated, you will not have to rebuild your gogs binary? Go does not provide a better security infrastructure than Java. I grant that just running a binary is cool, but as I said, having Java is OK as far as requirements go IMHO. others may have different opinions.

Atleast its better than installing a ruby app.

Re: Gogs – Go Git Service

#157

Post by jeremydw »

kej wrote: post #129
spenczar5 wrote: post #104

Earlier quoted context omitted.

People often _do_ ship C and C++ software this way with dpkg. Static linking is sometimes discouraged because it makes it harder to identify what needs to be upgraded in case of (for example) security vulnerables in core libraries like libc. Could you elaborate on how Python software can be shipped as a statically linked executable? I'm not familiar an easy way to do that, and it would help me quite a bit.

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 and distribute a single executable without requiring folks to muck around with Python versions, pip, dependencies, etc.

Re: Gogs – Go Git Service

#158

Post by eropple »

weberc2 wrote: post #130
sandGorgon wrote: post #87

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.

One runtime dependency isn't bad, but it's still worse than zero. :/

Did libc stop being a runtime dependency when I wasn't looking?

Re: Gogs – Go Git Service

#159

Post by nicoster »

sytse wrote: post #110
endymi0n wrote: post #77

Earlier quoted context omitted.

That's what has been the deciding part for us in the end. While Gogs is super lightweight, Gitlab is so feature rich, stable and user focused, that it's the only piece of Ruby that's running in our stack. We were right in the decision phase for a CI and had already set up a Jenkins machine when Gitlab integrated their CI which has been super simple, reliable and well integrated so far, no comparison to the monster th…

Thanks for your kind words! What do you think we can improve in the pull/merge request workflow and in code review support?

make ?w=1 a default behavior

haven't tried other alternatives but a happy gitlab user. you guys rock. the latest gitlab is much faster.

Re: Gogs – Go Git Service

#160

Post by neandrake »

merpnderp wrote: post #15

We downloaded and installed Gogs, Gitlab, and Bitbucket. I liked Gogs the best, but Gitlab seemed more enterprise-y, and Bitbucket had an issue we could never figure out. We're trying to replace TFS, so we'll probably end up with Gitlab. But since I was the one doing the installing, I sure wish we'd go with Gogs. It was 5 minutes from start to finish.

If you're still open for suggestions/alternatives, have a look at Phabricator. August-December of 2014 I looked at several different solutions for my company (though primarily my focus was on code review features - today we also use it in some areas for task management and documentation/wiki). I nearly moved forward with GitLab before (re)discovering Phabricator. I like to keep up to date with new features in the alternatives (GitLab, GitBucket, Gogs, Reviewboard, etc.) but at this point I can't imagine wanting to move off Phab.

Homepage, http://phabricator.org/

Their self-hosted install (browse but they prefer that you don't create/test data on this install), https://secure.phabricator.com/

They have paid hosting as well, http://phacility.com/

Post reply on HN