<div dir="auto">You're a bit over the top, regarding Ruby on Rails. And if you are bothered by the performance or resource use, consider converting the code to Crystal.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019, 23:45 Rick Moen <<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Thorsten Glaser (<a href="mailto:tg@mirbsd.de" target="_blank" rel="noreferrer">tg@mirbsd.de</a>):<br>
<br>
> I will not use the Debian-provided Gitlab even for Debian packages<br>
> if I can avoid it, both because I’m <insert four-letter word here/><br>
> by their badly coordinated move and because of its proprietaryness.<br>
<br>
Anyone's GitLab is also (IMVAO) grossly overengineered.  From my own<br>
Operations / sysadmin perspective, I regard anyone who relies on a<br>
monstrosity like GitLab as naive about software history and/or drunk on<br>
long feature lists - or, alternatively, inexplicably driven by unclear<br>
motives to abandon the likes of FusionForge (as Debian did[1]) for<br>
GitLab bloatware before the emergence of saner-scoped and<br>
better-designed alternatives such as Gogs and Gitea.<br>
<br>
<a href="https://gitea.io/" rel="noreferrer noreferrer" target="_blank">https://gitea.io/</a><br>
<a href="https://gogs.io/" rel="noreferrer noreferrer" target="_blank">https://gogs.io/</a><br>
<br>
As with Discourse, the bad news about GitLab (from the point of view of<br>
software architecture) starts with Ruby on Rails.  Have you actually run<br>
Ruby on Rails for anything significant?  You quickly find out that RoR<br>
is (a) very brittle[2], (b) unbelievably slow and resource-hungry, and<br>
(c) unscalable.<br>
<br>
And, as if RoR weren't enough of an albatross, GitLab plonks on top of<br>
that a second heavy layer of JavaScript using the Vue.js library,<br>
exactly as Discourse does with Ember.js.<br>
<br>
The result in both cases is _theoretically_ open source (well, open<br>
core in GitLab CE's case), but you'd be a masochist to actually run<br>
them, and even the portability of data they host is doubtful.<br>
<br>
But hey, if you're, let's say, a lawyer and not a sysadmin or coder,<br>
they look 'smart'.  And you can just outsource, making the<br>
overengineering and consequent headaches Somebody Else's Problem.<br>
<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Alioth_(Debian)" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Alioth_(Debian)</a>.  FusionForge <br>
is the surviving open-source fork of the SourceForge architecture <br>
invented by the late Tim Perdue and colleagues at my then-firm VA Linux<br>
Systems, back when it still supporte open source.  Like you, I'm<br>
perplexed that Debian Project EOLed its perfectly adequate Alioth site<br>
for, of all things, GitLab CE.  They must hate their Operations team.<br>
<br>
[2] There's an entire consulting industry devoted to fixing RoR <br>
glitches and failures that shouldn't even exist in the first place.<br>
<br>
<br>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank" rel="noreferrer">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>