> 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 dependency wasn't targeting the right version. And you sit there debugging dependencies and errors and pulling your hair for two hours, trying to get someone else's mess to work, wondering how did we get this so wrong.
As long as it's behind and simple interface and it works, I don't care what it actually does.
(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.
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.
At the minimum I want to know what it does and where it puts stuff.
This assumes that the software package itself is trusted, which is (still?) a reasonable assumption to make for open-source and big name companies.
By the way, it's poor form to downvote someone just for disagreeing with them.
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?
"Make sure you're running Gogs 1.64.2 or above"
"Make sure you're running Gogs 1.64.2, OpenSSL 1.2e, libcrypt 3.73, leftpad 2.0..."
Especially when the deployment of said binaries doesn't involve anything installed on the host OS.
"Make sure you update to OpenSSL 1.2e and restart all services."
If you think of more than one program using the same module, shared libraries make a lot of sense.
Of course, if the user chooses to install software outside of the package manager, it is their responsibility to upgrade dependencies accordingly.
You'd be surprised how many users have no idea whether they are running the 32bit or 64bit version of their OS. For them, running a Go binary will be anything but easy.
Because some Salesforce product required a specific version of Java and Oracle's PMS software required a specific, different version of Java. And both vendors only support their products by having it run with only the correct version of Java installed.
And then I have this VM with this ancient version of Java I can't even find for download any more so that I can use the management interface for Brocade FC switches.
Usually you get the option to use the bundled one or whatever is available if one is detected already on the system.
To the point that is one of the options of the new Java application packer introduced with Java 8.
Also in all server deployments that we do for our customers, Java is just another configuration of the whole application packaging.
Also many companies don't mind paying for commercial Java AOT compilers to native code, which then puts their Java code in the same league as Go.
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.
That's exactly what I meant when I said
> Yeah, the missing bit is that this should be done by OS vendors which sadly is not true.
I've always believed that 100% of all dependencies should be included in projects. Whether that is raw source code, amalgamated source code, static libs, or dynamic libs I don't care. Give to me the things I need to run and/or build your project. Don't make me hunt shit down.
Once you bundle dependencies, you make the choice of having to track those dependencies for security fixes and bug fixes. Otherwise you end up exposing bugs and security issues to your users.
Too often, I've seen applications (specially in the "Enterprise" Java World) with hard pinned versions from 2, 3, 4 and even more years old, with tons of bugs and tons of security issues.
Bundling make sense in many cases, for example if you distribute a product, it permits to control most of the stack and to factor maintenance across several platforms.
Not bundling also make sense, for example if you are a distribution, you have tight control over what put in, and it reduces the effort to maintain stuff because you don't have to track x, y, z each in versions n, m, o.
Bundling or not is a trade-off, either way, it must be done properly.
Dependency handling is a complex task, and yeah, it sucks. And it's not technically that the problem will be solved, it's with proper organization, conventions and normalization.
Including libc, Mesa, and libX11?
It's pretty untenable to do this in the limit. Eventually you're forced into using a good package manager, and once you have one you might as well use it for the rest of your dependencies too.
There is a line. You shouldn't include operative systems. Nor language tools (C++ compiler, Python installer, etc). Nor hardware SDKs (DirectX, OpenGL, etc). But beyond that? My vote is strongly in favor of including dependencies.
Compiling OpensSSL on Windows is a god damn nightmare. I shouldn't have to fucking install StrawberryPerl. SQLite is beautiful in comparison. It's two .c files and two .h files. You can also download pre-compiled libs if you want.
Almost all open source projects could easily be single file. If it can be single file then, in my opinion, it should be.
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.
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.
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.
It's not zero requirements, though. (Go binaries still need platform-specific libc, AFAIK, but it's usually also a reasonable requirement.)
But the trend seems to go towards sacrificing disk space for isolation, i. e. NPM which makes it more or less impossible to use a system-wide 'node_modules'.
... as long as you downloaded the right binary.
Not just C and C++, either -- Python, Ruby etc software could be shipped as statically linked executables.
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.
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.
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.
Gogs is a great relief.
I had been using 5.1 for quite some time before. It wasn't really fast either, but things have gotten much worse with newer versions.
A quite forthright confession of memory leaks - with imo questionable countermeasures.
Also note that the latest version of GitLab is a lot faster than it used to be.
haven't tried other alternatives but a happy gitlab user. you guys rock.
the latest gitlab is much faster.
Glad to hear you're happy with GitLab.
If there is no objective way to set the bar you mentioned, we end up with double standard.
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.
I was just installing installing for evaluation and hopefully our sys admins will do the final install.
Gogs was just 'install Go', 'run binary', 'link to database/git ssh user' done.
I got gogs working in 5 minutes like OP said.
Also Gogs is >>>>>>>>>>>>>>>>>>>>>> faster. It baffles me that I can be pushing an initial commit to an empty repository and my terminal will hang for 10-15 seconds. What's going on with that?
I'm not sure what is up with the initial commit issue you describe and made an issue to investigate https://gitlab.com/gitlab-org/gitlab-ce/issues/14685
I don't understand what you mean with instantaneous merges, did merges seem faster in the past? We do have a feature that allows you to merge when the build is successful, saving many people lot of time http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....
We would love to support it officially but we do need customers to express the same. We're currently talking to a client that might make this happen, so I'm hopeful.
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/
For repository hosting, since you appear to be a Windows shop, try HgLab (disclaimer: I am the creator of HgLab).
Main reason was the resource utilization of GitLab was just too high. iirc, it was actually the CEO of GitLab that recommended the switch... ;)
Can't recommend it enough. Resource usage matters.
Gogs has probably 95% feature parity with Github and it is a lot faster (is Github still Ruby? That would explain it ...)
I run a personal Kubernetes cluster for services and getting Gogs up and running was super-simple: https://git.tazj.in/tazjin/infrastructure/src/master/gogs/go...
For my own projects it doesn't matter so much, few people contribute to my Emacs configuration or dotfiles :)
It is what I use for my misc things at home.
Anyway, I would love to see better integration on both with their mandatory complements, such as kanban, CI, ...
- How are static assets packaged in a single binary?
- Any simple tutorial or stack walkthrough you would recommend me reading?
- I also recommend going through Go's example wiki tutorial: https://golang.org/doc/articles/wiki/
- By default, Go binaries are statically linked. If by static assets you mean CSS, JS, etc., those are usually just deployed alongside the binary.
Also, many of the most popular solutions in this space are written in what some people would call "low performance languages", since the author here is using a "high performance language", its just good marketing too.
Something small, easy to setup, easy to use. Just as Gogs is.
All I want - integration with git/gogs (webhook?), status page (with detailed build/test info, especialy for fails), status image (for readme in gogs).
also after installation it refreshes into localhost:3000 instead of my-remote-host:3000, so you have a dead page after the installation.
yes they're easy to fix, but it's good if they're documented
- they only accept free projects
- they're still using a very old version of Gogs
If you want a single click install on a _private_ server and with a custom domain -
https://cloudron.io/appstore.html?app=io.gogs.cloudronapp. We track Gogs releases actively and keep it up to date with no effort on your part.
My own repos are hosted on gogs - https://git.girish.in
Edit: Since I got asked a couple of times about this (wow, you guys are fast), anyone can write apps for the Cloudron. It's docker based and you can find the Gogs app code here https://github.com/cloudron-io/gogs-app
Cloudron gives you a private server (we use DigitalOcean right now) on which you can install web apps. We automate everything about maintaining your server - DNS, certs, app updates, backups etc. In short, we want to make it possible for everyone to have their own server. Cloudron is more a consumer product than a development tool (of course, we have tooling that enables developers to create apps).
We have a demo at: https://my-demo.cloudron.me (username: cloudron password: cloudron)
(I know this is not something I should be asking, I'll not be sad if you do not answer)