1. 24
  1. 14

    Oh, ssg in the wild. Tom, thank you for sharing your how-to.

    1. 3

      I wish I had used something similar/smaller instead of going the Jekyll route. However I’ve written too many custom plugins to really consider changing now, or even upgrading past Jekyll 3.0.1. I just toss all my dependencies into a Docker image.

      1. 4

        Yep, your websites are quite complex, but nothing is impossible. :)

    2. 12

      You basically copy-pasted the article I wrote from http://2f30.org/guides/openbsd-httpd-cgit.html . The referenced link in your post is wrong (typo 2c30 -> 2f30). Booo!

      Here is the most up-to-date version (as linked from 2f30): https://codemadness.org/openbsd-httpd-and-cgit.html . It has some notes to make cgit tarball snapshots working.

      A related article for git hosting: https://codemadness.org/setup-git-hosting.html

      Edit: thanks hir0 for updating the article! It is totally fine now.

      1. 5

        I will admit I used a lot of the advice on your blog post to help me set up my server. I’m sorry it came across so copy-pasted. I’ve added a section to the top of the post to make it very clear that this post wouldn’t exist without your work. Also, sorry about the typo, that’s fixed now.

        1. 1

          Are you suggesting this is plagiarism?

          1. 3

            Quickly comparing the two, the submission is actually less helpful than the parent comment’s article, which says what stuff to install. The submission leaves that exercise to the reader.

          2. 1

            Just wanted to drop by to say thank you for writing that article. I’ve been running my own git server for a couple of months now.

            Now I only have to find one for setting up an email server ^_^.

          3. 9

            I run a couple of hg servers too. It’s pretty easy to do, and the docs give a good run down of how to do so:


            While we’re diversifying away from github, let’s also diversify on VCSes. :-)

            1. 1

              Do you just use ssh+hg on a private server, or use a ‘package’ (ala gitlab, but for hg)?

              Not looking for a suggestion so much as appraising actual usage for a potential OSS project.

              1. 1

                I use ssh+hg; haven’t yet had to host a server for a large amount of people were manually managing ssh keys wasn’t a possibility.

                But yeah, improving Kallithea or Rhodecode or giving gitlab hg support would all be great things.

                1. 1

                  Right - so my plan was actually a more (in my mind anyway) natural progression from what it sounds like you’re using now.


                  • rely on the system ssh still, either direct as you’re using it for small installs, or via LDAP for larger/multi-server setups
                  • rely on Filesystem ACL’s to allow group based write access to repos
                  • use a vcs-specific “shell” for Git, Hg (heck even SVN) sessions

                  To clarify on the ‘improving’ topic:

                  • RhodeCode is AGPL or commercial. That isn’t going to fly.
                  • Kallithea is GPL. That isn’t going to fly.
                  • Gitlab is IMO a Rube Goldberg machine at this point. The number of services required is crazy.
                  1. 3

                    The AGPL is flying quite well in Mastodon. People have been scared of copyleft forever, and great copylefted things have flown.

                    The constant push back against copyleft is how we got github in the first place: hosts all of the code, shows none of its own.

                    1. 3

                      Right, I understand the premise but given that (a)gpl gives rhodecode inc exclusive permission to do a GitHub (which they do, via the enterprise edition) I have zero incentive as either a developer or as a business owner to contribute to that project.

                      Everything I create (as opposed to forks) is bsd-3-clause, specifically because I see the main targets for things like this as being small/medium business.

                      1. 1

                        The only reason it gives them “exclusive permission” is because people like you are afraid of touching the AGPL for no good reason. It’s the fear around the AGPL that does it, it’s the very same undermining of copyleft.

                        Small/medium business can use AGPLed stuff; it’s not the cancer that people said the GPL was in the late 90s. It’s not some kind of plague to avoid. Rhodecode is abusing that plague fear that others have created.

                        1. 1

                          rhodecode inc is able to produce an enterprise edition with closed source additions.

                          No other entity on earth can do the same thing, either hosted or distributed, because any changes they distribute must be returned upstream.

                          How is that not exclusive permission.

                          And frankly the gpl is a cancer. Good companies contribute back to/release permissiviely licensed projects.

                          Shitbag ones are unlikely to do that regardless of the license.

                          1. 3

                            Interesting discussion on this topic. We’re actually in the process of changing AGPL for RhodeCode CE edition into MIT/BSD. We did the same move with our other project already - RhodeCode-Appenlight.

                            MIT+CLA works fine for Gitlab. We believe this will help RhodeCode, and we’ll execute on this very soon.

                            1. 1

                              I don’t know if you have much content that would fit lobste.rs, but it’d be great to see blog posts or something here about RhodeCode.

                              Also, does RhodeCode support FreeBSD?

                              1. 2

                                We do occasionally post release notes. Lots of our stuff doesn’t fit lobsters and it felt kind of “too much marketing” But if there’s something related to Mercurial, e.g evolve support or narrow support (which is supported by 4.12 release) we’ll post it here for sure.

                                FreeBSD is supported if you run rhodecode from source. Afair installer have some problems because of older NIX we used.

                            2. 1

                              You can make private modifcations to AGPLed code. You can grab Rhodecode, modify it in-house, and you don’t have to distribute anything back to anyone.

                    2. 1

                      RhodeCode has full SSH Key management together with SSH access in the Free CE edition since few releases.

                      Source code here: https://code.rhodecode.com/rhodecode-enterprise-ce

                2. [Comment from banned user removed]

                  1. 3

                    But it goes the other way too. Github (and Gitlab/BitBucket to some extent) really promoted the “social coding” … the ability to fork, edit, commit and pull request back into a project has really sped up development of a lot of projects; allowing developers to start contributing to projects to minor bug fixes all the way up to large feature branches.

                    I wish this was built into the protocol itself; to allow a means to offer contributions to custom/federated domains in a standards compliant way. Fossil at least provides its own standard web interface and issue tracker.

                    I suppose you could run your own version of Gitlab or Gogs and allow limited signups only for project forks …

                    1. 7

                      It actually kind of is built into the “protocol” (well, into git). It’s why git request-pull exists and why github decided to call these things “pull requests” when they’re more usually merge requests.

                      1. 4

                        Yes I agree. I think we either need to write an activitypub implementation for issue tracking / wiki / project management or have some good set of tools for bugs/wiki/pm for git that are all bundled together under one project that are accessible from a web interface like cgit.

                        1. 3

                          I’ve taken to using http://mrzv.org/software/artemis for issue tracking. It just uses a maildir for each issue (identified by hashes), stored in a .issues directory. Metadata (status, assignee, whatever) are just headers of the ‘root’ messages of the maildirs.

                          I’ve made a few convenience scripts around this, e.g. an EDITOR script which opens emacsclient in an email-composing mode. Generating Web pages from these is easy enough using MHonArc, although it’s not the prettiest ;)

                          1. 3

                            I haven’t tried Artemis myself but anything like this that embeds issues in the repo itself (and as regular files, so it’ll work across VCS’) is a good thing IMO.

                            The missing part is usually a web viewer (or editor!) for issues, so that non-dev staff can make use of it too.

                      2. 2

                        I also self-host git and really like klaus.

                        1. 1

                          I would also look at stagit

                          Stagit looks pretty nice. I’ve been using git2html, but the filesize gets a bit ridiculous. I’ve ended up skipping all commits except HEAD, which is obviously not ideal.

                        2. 2

                          Going to spin up a vmm-vm to build this. Thanx!

                          1. 2

                            Definitely not applicable to all use cases, but I realized at some point that I didn’t actually need a web UI for my personal git repositories, and have been much happier since I stopped trying to deploy them in favor of simply using ssh:// remotes.

                            1. 1

                              That’s true but it doesn’t make your code very accessible to outsiders and that seems to go against the spirit of free, open source code. True, it is possible to find the code still, but it makes it harder for someone to find.

                            2. 1

                              I’ve self-hosted git using gitolite on OpenBSD, CentOS and Ubuntu in the past, I’ll definitely try cgit.

                              1. 1

                                I think these kind of articles miss the point. It’s never been difficult to setup your own code hosting. 15 years ago many shared hosting services would even include Subversion and CVS hosting with web support for free as part of their hosting service.

                                The problem is letting other people find, use and contribute to your project. For me personally, if a project isn’t on GitHub, BitBucket, or GitLab the chances of me even thinking about contributing are about zero.

                                Obviously, that’s not important to everybody, but it’s something to think about.

                                1. 1

                                  For me personally, if a project isn’t on GitHub, BitBucket, or GitLab the chances of me even thinking about contributing are about zero.

                                  Can you explain why that is? I’ve been thinking about self hosting projects vs using github, and am trying to think of specific weaknesses in the self-hosting option, or reasons it would deter would-be contributors.

                                  1. 1

                                    It’s a combination of laziness on my part and the fact that I don’t make many large contributions to other people’s projects. I have accounts on those services, and I know the generally accepted workflow for opening pull requests and getting changes submitted. The time from me saying, “Hey, this is a small bug I can fix,” to writing the code and opening a pull request can be as little as 5 minutes.

                                    But with somebody’s self-hosted Git repos, I don’t automatically know what the process is. Sometimes they’ll say, and sometimes they won’t, but it’s almost always more work than the third party hosts and it’s potentially different for everybody’s self-hosted code.

                                  2. 1

                                    My problem with GitHub at least is the fact that they inflict a double standard. They want everyone to open source their code, which I completely stand behind, while keeping a large proportion of their own codebase proprietary and closed. Not only that, but for the other two, the fact you have to pay for access to certain chunks of a service I host myself does not agree with me. If i’m hosting something, it’s all or nothing, not to mention they are all massively bloated and dependency-heavy