Great news :) We switched to Gitlab at Arch Linux recently as well: https://gitlab.archlinux.org/ (well, we're still migrating projects and users, it's a long process)
This past year, on my Thinkpad P50, I've switched between Ubuntu, Fedora, and Arch; Arch has by far been the least buggy. With Ubuntu, things would go haywire when docking/undocking. With Fedora, putting it to sleep was always a risk because after putting it to sleep I would sometimes I would open up my laptop to a black screen that I couldn't recover from. I was fine with that and just wouldn't put my laptop to sleep but eventually I started using Zoom and Fedora would crash within an hour and a half of using it. This pushed me over the edge to wipe my laptop and install Arch; I'm really glad I did.
I still have an issue where the system is not detecting when my laptop lid closing but at least it's not crashing every day or two.
Plain vanilla Debian is a lot more solid than Ubuntu as long as the hardware is well-supported. With very new hardware you end up having to stay on the testing or unstable release channel for a while, which is quite a bit messier since, e.g. some security updates may be delayed. Still more predictable than Arch or Manjaro though.
This fragmentation between what works on what dists makes me sad. Philosophically I've always admired BSD for the consistency, considering how there's just 3-ish of them, realistically I'm a Manjaro user as I don't have enough Linux-fu to set Arch up.
Long ago I decided to use Debian STABLE with Gnome. There is no fuss. There are no surprises. You just get back to work and (the infrequent) upgrades don't break.
There are some apps which I have to install outside the regular repositories (RStudio, Google Chrome, Zoom, etc.) but they all provide binaries specifically for Debian, and it seems this is becoming more commonplace. I recently installed Mattermost for a client on Debian Stable, and it was trivial given their provided binary and instructions. Time is valuable, folks.
Honestly you don't need any particular skills to install Arch. Just time and access to the instructions. It's a neat way to spend an afternoon once, but I just switched to Manjaro too on future installations,
That is sadly what you get with an non-commercial all-volunteer distribution. We only have so much time on our hands and Security Team members are productive members of the community holding several roles.
I'm one of those that when I fiddle with something I really wanna know what I'm doing too,so my arch installation would probably take weeks (and I'd learn a lot).
If you already know the basics, you won't find too much surprising stuff. That's actually the reason I like Arch, whenever I wanted to customize something, I would find the steps in other distros more esoteric and made with a lot of assumptions, in that regard Arch seems simpler to me.
If you want to investigate what you're executing in your system, as opposed to find what fedora does under the hood during install, you might find Arch install is nice an simple.
> This fragmentation between what works on what dists makes me sad. Philosophically I've always admired BSD for the consistency,
what use is that consistency if even all combined together they only support a percent of the consumer hardware support that the average Linux distro has though ?
Absolutely none in practice, which is why I run Linux on my machine while hoping dearly for systemd, networkmanager and some distro agnostic package manager to succeed and make "distros" more OS less redundant.
And what 3ish are those? Serious question. Of the top of my hat I can come up with freebsd, netbsd, openbsd and dragonfly bsd. And those fork like crazy in ghost bsd, pcbsd (I think that's dead), freenas, trueos and pfsense just to name a few. I don't follow the BSD ecosystem closely, but I got interested in trying it out again (since the last time I tried a bsd was over 10 years ago), but my impression was always that the BSD ecosystem had way harder forks that didn't share code between each other (or rarely do) and makes it harder to know what works and what doesn't.
At one CCC event there was a talk about a security vulnerability and it was interesting to see how the response times of the different BSDs was and how they tackled the security fix.
I wouldn't call FreeNAS/TrueNAS and pfSense distros in the sense of a Linux dist (since they are non generic, I see them as an "application" that happens to include an operating system).
"All" "distro bsds" seem to follow FreeBSD very closely and building upon it rather than modifying it (providing installers and such while still being a true FreeBSD).
Dragonfly being the exception here, don't know enough about it.
Disclaimer: I'm no expert and do not mean to step on anyones toes.
Great to see GitLab gain momentum in FOSS. It's a great fit for small teams too, it's easy to setup and keep updated. It's more important than ever to help GitLab gain adoption with GitHub making it free for private repos. I love GitHub as much as any developer, but I believe having a free, open alternative to it is important.
I wish GitLab would improve their free-version of Merge Request reviews though, Github's is much much better right now.
I'd love to hear more about what you dislike about merge request reviews. At work we've been talking about migrating looking for alternatives to GitHub over dissatisfaction with its code review interface, and, of course, GitLab is on the list of ones to check out.
Ability to review diff between two versions of PR is a great missing feature in GitHub. When dealing with large changes, GitLab review flow is IMHO easier for reviewer. Gitlab store each push of a MR branch as different version (as hidden refs), which make the feature possible. In GH, you force push a branch, you loose the old code for good, so reviewer has to remember why he did that comment before to see if it is still relevant.
This is such an important feature that has a direct impact on code quality and time savings that I'm not sure why it isn't a priority feature. As a reviewer, having to choose between "review everything again" or "trust the submitter didn't introduce extra changes in the revised pr" is such a terrible choice to have to make.
In the top left, there should be a "changes from..." drop down menu that will let you choose which commits you want to view. The default is "changes from all commits".
If you're on GitHub Enterprise, availability will depend on the last time your company has installed updates.
That is not the same feature.
It requires you to always add your fix in a new commit add opposed to amending the commits and maintain a clear purposed commit list.
I think the more official Git way of doing it would be to collect all the changes in separate commits, and then squash merge them at the end of the code review.
In my experience, GitLab's MR UI really lacks performance when the diffs pass a certain length. Similarly sized diffs in GitHub don't seem to have this problem, though.
I think of it as additional incentive to maintain smaller patches for ease of review, but sometimes changes are necessarily large due to complexity. It can be obnoxious to be hamstrung like this.
Honest question: isn't it far better to review the patch locally on your laptop? I always do this, primarily because I like to be able to go through the callers of functions that the patch modifies, look at the callers of functions that have been introduced, etc.
My decades-long complaint with every single code review system I've been forced to use at my workplaces (which no system I've seen fixes so far) is that they don't let you browse code and examine the diff in its native setting, so to speak.
I mostly like their merge request UI but one big missing feature for me as an easy way to view and review commit messages. For complex patches the commit messages can be vital.
One thing I find annoying and occasionally hazardous about Gitlab merge requests is that per-file diffs which exceed a certain length are collapsed by default. This introduces risk since it is very easy for a reviewer to skim right past the collapsed file name, since one's eye tends to be drawn to the more salient red/green diff.
I have developed a habit of going through my own pull requests immediately after opening them, and adding a "don't forget this file" comment to all the ones that get collapsed.
'Cuz yeah, I've seen some nasty stuff sail past code review simply because it's so easy to accientally miss those files.
Good one, I'm going to do that too, thanks. It's pretty nuts how broken a UI is that it forces us to do stuff like this though.
I feel like everything about the GitHub PR UI is targeted at reducing the code review job to being a human style checker. Minimal context, no code navigation, abysmal rename following.. it's really hard to review the design of a change.
The reason for the automatic collapse is due to performance. Also it's not uncommon (depending on the language and framework you are using) for the biggest files to be just a mere dependency lock file kind-of update.
Code search, Gitlab doesn't have a code search feature. Paraphrasing The code search functionality can be achieved by adding Elasticsearch. We haven't added elasticsearch yet so cannot comment on the experience of using it.
Our current approach is to make code search available for Bronze/starter and above.
We appreciate your feedback on enabling it for non-paid.
This is the Epic we are working on, feel free to leave feedback here as well.
https://gitlab.com/groups/gitlab-org/-/epics/1736
Although not at GitLab.com scale, I've worked on a few search-related projects (often using Elasticsearch) in the past and would consider offering some ideas.
Does GitLab have a policy for attribution/licensing of technical design input from external contributors? (this is partly out of curiosity in general -- I don't know for sure whether I'd have anything to add that your team wouldn't already have thought of themselves)
Merge requests seem to merge both branches in to each other. This is not the behavior I would expect. It doesn’t seem to be that way on github but I could be wrong. I see this behavior when to long lived branches are merged.
My git-fu is average level so its possible that I’m missing something obvious here. For me the easy solution is to just merge on the command line.
Does anyone else have things that make the switch from GitHub to GitLab a hard sell?
I'm always curious why open source projects don't embrace an open platform, although I get that GitHub is fantastic in a lot of ways. I'm guilty of it myself, but I've reached the 50/50 GL/GH split as I try using GL more.
I don't think there's any one single blocker that's keeping me on GitHub. It's just a bunch of little annoyances with GitLab that add up to make it not worth it -- either UI quirks, or ways in which third-party tools integrate just a little more easily with GitHub.
Yes, GitHub absolutely has a bunch of annoyances, too. (I listed a bunch of them here on HN in response to a question by Nat, just the other day!) If everyone were using GitLab first, we'd probably find excuses to put off switching to GitHub, too.
To attract users, you've got to have a pull. If that's "open source", then it needs to be a way in which the closed-source nature of GitHub is hurting my daily workflow. If it's "user interface", you need to be such an improvement over GitHub that it's worth the cost of switching. If it's "cost", that's tough because GitHub dropped prices and is now $0 for many users, and you probably don't want to get in a price war with Microsoft (see: Netscape).
It doesn't have to be the same pull for every customer, but every customer needs at least one.
"We're just as good as that big popular project" isn't a pull. I've seen hundreds of projects try that, and it never works.
This sums up my attitude towards it. Opportunity costs factor into switching cost; am I getting enough ROI for the switching costs vs something else I could be working on?
The community edition is a castrated mess with ads in it. I administrate a gitlab instance for a university and gitlab is hurting me in so many ways.
1) it had a message that tells you that the elastic search is so much better and that your admin can enable it (if he would only switch to enterprise)
2) it pretends to have functionality only to have it hidden behind an "available in ee" banner
3) it has a new functionality where it annoys everyone that has a new ip (24h disconnect anyone) that can't be disabled (only through patching) and suggests that enabling 2fa helps, but is send regardless of 2fa
And every function that gets cut out and hidden behind the enterprise banner iy forever lost to you, because even if you implement it yourself it will nevet get merged since the function exists, in enterprise...
Ps yeah there is a free enterprise license for universities, but it is not available for staff or external users (other universities) and the licensing model is so unflexible that you can't mix "free for students" and "pay for staff" or "students get enterprise" and "staff get basic features"
Pps I had to patch out more than one thing over the years this was just the first thing that came to mind
Thanks for the feedback on the GitLab for Education program. In the spirit of iteration, we started the program as an MVC - offering free licenses for teaching and learning related purposes. The program has grown significantly since then and through meaningful feedback from our members, we’ve come to realize the structure is not ideal for Universities to implement at an enterprise level. We have an epic open to restructure the program and welcome constructive input. https://gitlab.com/groups/gitlab-com/marketing/community-rel...
Thanks for reaching out through hn. I will take a look at the epic you linked. Those are indeed many issues we faced (and other universities as well. there was even a discussion of somehow trying to license one github instance for all universities in the state although I'm not sure if this ever amounted to anything)
I'm really interested in the development of this issue so thank you again for reaching out.
Ok I can't edit my original comment so just to clarify:
GitLab doesn't serve ads it only pushes out messages to users that they could have a better product if only the admin would shill out some bucks.
It's ok if admin settings are greyed out with a remark like in old freewares to tell you features you could have in the enterprise product, but if the software tells any user that they are missing out it is more unnescessary work for the admin to explain that we don't have the money to pay for every single student, most of which only create an account without pushing any code, just so that the search can work over all wikis and not only the selected one.
So again it's more like the "buy winrar" or "go pro now" nag and _not ads_. Sorry for the confusion
> The community edition is a castrated mess with ads in it.
I understand your frustration with FOSS pushing you toward buying proprietary software.
But your lede will mislead people into thinking CE gets revenue by serving up third-party ads because that is what "ads" mean for web services 99.99% time the term is used on HN.
I called it ads, but it really is more the promotion of enterprise features and yes it is "new" since it only started popping up in the last year or so. It also seems that they are trying to dial it back, but gitlab really started getting aggressive with annoying little things like that and is getting on my nerves from time to time.
On a positive note it got quite a bit more responsive in the last 4 or 5 five years since I started hosting it and even thought we got some regressions and bugs and problems with releases we didn't have any data loss (that we know of) or major security problems. Most of the security problems are in the enterprise functionality anyway (elasticsearch and grafana pop up regulary)
Sorry since I only provide access to students, faculty and collaborating universities (so no open registration) I never needed antispam functionality, but can't remember seeing any entry in the administration interface or config as well.
I truly believe it's because github has become a social network and developers use it as popularity contest. They want their commits to be there just like influencer wants to be on Instagram not on my fairly unknown platform.
I can confirm, this is the exact reason I made two copies of (shameless plug) the SpicaStack project earlier this month. GitHub's reach, network and stars help fellow devs and users discover our forks, while GitLab's exportability and amazing CI will let us actually work on it.
I use multiple hosts to backup my repos: I host gitolite.org on a $5 VM and then have it configured to automatically push to gitlab and GitHub on every change.
Absolutely - people now ask to see your Github repo as an integral part of your CV without even really considering if you might use another service.
And you don't exactly want to pitch to them how you don't have your code on Github because you use this other "fringe" service which even if they look at it they are going to find unfamiliar.
I now host 50/50 on Gitlab / Github because I'm not really affected by this, but I'm conscious of it.
I use Gitea for my own projects, i.e. I do the setup myself and it's trivial. It uses SQLite as backend, so no complex DB deployment.
It's very easy to deploy, consumes few resources (you can run it on a low-end VPS). It even has Jenkins integration.
However I don't know how it scales to big teams and projects since I only use it for myself.
And I'm not entirely convinced by its security track record, but it looks like things are improving.
A Turing complete language executing unsigned code in a sandbox that allows HTTP and HTTPS requests to 0.0.0.0/0 and ::/0 is not something everyone wants in their life.
It's not a hard sell, but it is certainly an inconvenience. I prefer to browse with javascript off by default and only enable it for sites that absolutely need it. I've had issues where sites using JS have caused a single core on my laptop to spin at 100% thus affecting battery life negatively.
In some cases "I'm browsing GitLab" might be the exact impetus for someone's attempt to disable JS. As noted above, GitLab is sluggish. I was an early adopter/advocate for GitLab, but you can feel the bloat on every page and I no longer use it.
Gitlab CI pipeline was a deal breaker for our organization. Lots of UI bugs, quite a few issues with CI nodes hanging, and ultimately their yaml job configuration system turned out to be too constrained for our needs. We eventually switched back to github and jenkins. This was more than a year ago though, so I expect some of those issues have improved during that time.
Product director for CI/CD here - we have tried to focus on improvements around making more complex pipelines easier to manage, but I would love to hear what you ran into just to make sure we are closing the loop on all the important ones.
I like GitLab and GitHub quite a bit, but I lean toward GitLab for the simplicity of a unified tool chain.
However, I think GitLab can only really shine when you host it yourself. In 2020, on-premise/self-managed anything is kind of a hard sell, but the reliability and performance of gitlab.com leaves a lot to be desired. (So much so, I often think about trying to work for GitLab so I could help from a reliability perspective.) I stuck my neck out for GitLab in a previous organization and we ended up migrating from github.com to gitlab.com. This set me up for some embarrassment for every outage they experienced last year which felt surprisingly frequent. But if you have the resources, self-managed GitLab is great!
I find Gitlab UI quite a bit bloated and slow compared to Github. They have some amazing features but I can't get past how many (2-5 seconds) to load a page and sometimes upto 10 seconds (analytics). I hope that's being addressed in future. Usually, I spend at least 2 hours on Github in a given day - and probably access the website about 50 times a day or more. These UI issues add up tremendously.
As noted in other comments, GL.com does have some performance problems. A self-hosted instance is a completely different story, thankfully. All of the on-prem or cloud hosted instances I’ve gotten to use were quite snappy.
Phew. I’m not alone. I also fine the interface a bit confusing. It’s probably no worse than GitHub, but just less familiar. Or maybe I prefer too nav to side nav...
I’ve been using Gitea for my personal hosting because it’s small, quick, and easy to grok. It isn’t nearly as fully featured as GitLab though, but I don’t mind. I’m not a team and I’m happy to glue different services together rather than use a large all in one (Gitea + Drone + Wekan).
Hi Emily, can you guys do an upper limit, say maximum 1.5 seconds load time for any page? Ruthelessly disapprove features unless it meets this spec time.
When a website or service becomes too slow, it is on its way to an impending death. Then people wonder why some service fell apart? Put users and usability first and foremost before features.
Fantastic news for Xfce and for Gitlab self-hosted software. While already being self-hosted using cgit, this sounds like a sensible move for Xfce instead of using GitHub. They recently migrated their CI to Gitlab CI with fosshost [0].
I'll be forever grateful for what GitHub has done for the OSS community. People today don't remember what they replaced, namely Sourceforge and various home-grown tools of various levels of dysfunction.
Would anyone doubt that open source contributions, and individual contributers even more so, have grown by an order of magnitude or more in the last decade or so? And that GitHub's process improvements and standardisation were the major factor in this?
It used to be, you had to mail patches to some mailing list, with each projects having their own set of arcane rules, sometimes written and sometimes informal, but always enforced with that very special enthusiasm stale organisations devote to policing arbitrary norms because that's the sole remaining source of the old timer's power differential.
Or at least that's how it seemed to me, for I never felt courageous enough to try.
These days, I fire off smaller contributions several times a week, and contribute some medium-sized feature once or twice a year.
Meanwhile, the most impressive thing about GitLab keeps being this strange quirk of them, that among all the companies I know, they are closest to being a total clone of an existing product. Or at least they were in the beginning, when their CSS still had ".gh-wide-3" class names.
Yet despite this, or maybe because of it, they are also the only company that repeatedly lorded it over their competitor when they came late to implementing some minor feature. Seriously: I noticed it the first time because it's a level of pettiness not usually seen. And since then, there have been three or four more instances.
> [...] always enforced with that very special enthusiasm stale organisations devote to policing arbitrary norms because that's the sole remaining source of the old timer's power differential. Or at least that's how it seemed to me, for I never felt courageous enough to try.
Why the same people that seem afraid of email, can however gratuitously accuse others of being on an ego trip on a public forum, I wonder.
GitHub wasn't the only service responsible for replacing Sourceforge. Lots of open source projects used to be hosted on Bitbucket before Git gained total domination among the version control systems.
Not strictly related, but every time I see projects moving to Gitlab it makes me happy. GitHub certainly has been adding some very sweet features, a lot of great integrations - but with each one you lock yourself in. We cannot afford another monopoly.
I've witnessed and worked with on-prem installations of GitLab that are remarkably fast. Of course not every instance shares a load similar to the .com version.
Is there any resource somewhere explaining why they migrated away from gitolite ? Not trying to sound negative, I'm just interested in the reasoning behind and see what really differentiates the two in this kind of usage.
Gitolite is just managing raw git repositories. I'm using gitolite for personal (read: non-public) projects, and I wouldn't want to use anything else. I love how minimal it is, and the way it works.
However, how do you manage issues? Bugzilla is, IMHO, horrible. You can replace it with something much more lean, such as Mantis, but you still lack true integration with the repository (ie: knowing when a bug has been closed and which versions/branches it was dealt with).
This is something I struggle with even when working alone on a simple project. I've used both sd (simple defects) and bugs-everywhere, however it seems that development on these has pretty much stalled, which is A Great Shame. I keep using "be" in these cases.
However as soon as you have 2-3 devs, it's easier to fire up something like gitlab and have all features such as reviews/CI in a single shot than having to setup these separately.
Bugzilla is still superior to GitLab/-Hub style issues, at least for bigger projects. Especially regarding search queries. Saying this from experience working in LibreOffice QA. Sadly upstream Bugzilla has been deprived of all the Mozilla-developed goodness for years, but finally the harmonisation is being wrapped up: https://dylan.hardison.net/2020/02/09/bugzilla-project-updat...
I'm pretty fond of Mantis, as mentioned, but I've seen effective usage of both github/lab issues with good usage of labels and a little bit automation. Since much more automation is required to integrate even a lean bugtracker into your source, I cannot recommend using a separate bugtracker unless you have an extremely good reason for it.
Factor in that ease of reporting both for you and for your users should be in the top #3 reasons for using a specific bug tracker.
Bugzilla IMHO only works as an internal-only tracker for developers or testers directly involved with the code and decent overview/discipline of the triaging process.
"Issues" is a very good reason for switching, it's very nice to be able to link them and code directly. I know Gitlab also offers easy CI/CD, but I don't know what the workflow of Xfce is so I don't know if they would benefit from it.
Took a quick look into their GitLab account and they seem to use some continuous integration, which is a native GitLab feature.
Gitea does integrate with some external CI/CD services, but it's not a part of the core product: https://docs.gitea.io/en-us/ci-cd/. Gogs makes no mention of CI/CD in its documentation.
I've switched from Gitea to GitLab for that same reason for my personal projects, and I'd bet that's by far the largest selling point of GitLab when compared to other self-hosted solutions. You just do a "git push" and stuff gets automatically tested in a VM or even deployed in a live environment.
> You just do a "git push" and stuff gets automatically tested in a VM or even deployed in a live environment.
Yea, same with my Gitea + Drone servers.
It’s cool that GitLab has everything built in, but I don’t mind having distinct tools. Especially when both are very performance static binaries in a language I’m fond of working in (Golang) so that I can patch upstream.
Truth be told, if it weren’t for GitLabs sluggishness on my very cheap VPS, I’d probably give it more of a go so I’d have less to maintain.
> Please poke us on IRC or the mailinglist if you’re lacking repository access or ownership. (By default new users cannot fork before being manually approved. Yes. We are afraid of the spambots.)
Do forks introduce potential PR spam or something of that sort on GitLab?
I help manage a Gitlab instance for a FOSS project with around 800 users, and we had spammers post spam on personal repos 3-4 times in the past 2 years. It can be hard to catch (I keep an eye on the latest new projects).
Urgh, sad to see one more FOSS project move there. No browsing of code or issues without Javascript. If the Javascript actually enhanced something and made the experience better, then it could probably be tolerable, but it doesn't, GitLab feels slower and more bloated than any other Git repository manager I know of.
I had not been surprised if Microsoft had ruined GitHub by "enhancing" the site with loads of Javascript and other things that would make the site worse, but this hasn't happened. GitHub has actually improved steadily since the acquisition. Ironically, it's the FOSS alternative that is slow and bloated this time.
Good luck and hope this leads to better productivity for Xfce developers. You are doing an amazing job, has been my go to desktop env for the last 9-10 years.
Migrating away from a development model based on attaching patches to bugzilla tickets is sure to improve the development experience, especially for new contributes. Good move switching.
Microsoft buying github just felt so wrong on so many levels to me. While I find it wierd gitlab hosts their servers in azure, or at least used to, I really like the ci/cd integration in GL and hope this works out for them.
XFCE is awesome, and is my second most used desktop after, well, Awesome.
I should probably move https://github.com/pmarks-net/ipvfoo to GitLab at some point, because its source repository hasn't supported IPv6 since Google Code shut down.
This is a great news for FOSS & XFCE! GitLab is a great company with great services to provide for the FOSS community. We should embrace an open alternative and not a closed garden ecosystem. Can't wait to see more collaboration in XFCE project due to this change!
It's also high time we look at the motivation and principles when it comes to products and services from a company, not just their technical superiority.
