[Gambas-user] "New" gambas-basic.org website

Sat Feb 10 18:45:45 CET 2018

Le 10/02/2018 à 14:10, Christof Thalhofer a écrit :
> Am 10.02.2018 um 12:50 schrieb Adrien Prokopowicz:
> 
>> We could find another hosting provider than GitLab so we don't have as
>> many things relying on them, but it only shifts the problem : we still
>> depend on a provider.
> 
> We could do that at Hostsharing, where we have the mailinglist. There's
> plenty enough space free for a static Gambas website.
> 
> Hostsharing is a firm, that donates the webspace to the Gambas
> community. It is a german cooperation (Coop) where I host my websites at
> since 15 years. I am member of that coop. I asked the others, whether
> they would like to donate to the Gambas community, and they did.
> 
> As easy as Benoît delegatet the subdomain "lists" to the HS-server he
> could also do it with "www".

Ooh okay, I thought you wanted to personally host it. Of course having 
this handled by professionnals is much better. :-)

>> The only real alternative would be to host it ourselves (or rather,
>> hosted by someone), but that has several downsides has well :
>>
>> - We have to find someone nice enough to host and maintain the site at
>> their own cost (both in time and money). I know there are plenty of nice
>> people on this list, but I don't think many can afford both the monetary
>> and time (although I would love to be proved wrong here ;-) ).
>> - If that person can't handle the hosting anymore (because life
>> happens), we're back to the same problem we had by choosing GitLab (or
>> even SF) : we will have to move again. If I remember correctly, this was
>> exactly the situation we were in with the old wiki (gambasdoc.org).
>> - Personnally, I would pefer if this very nice person would spend its
>> free time contributing to the Gambas project or community, rather than
>> juggling with servers. :-)
>> - If we end up not liking GitLab's service, we can just dump them (just
>> like we did with SF). It's harder to do that with a personally-donated
>> service.
> 
> If we generate a website with a static generator like Hugo the sources
> can reside in Git and a switch to another provider or webspace is
> child's play.

Indeed. That's why I love sites that work without any kind of data layer 
: it's so simple. :-)

> gambas-basic.org belongs to Benoît, he decides where the DNS delegates a
> subdomain to.

Of course! I'm not trying to decide for him, I'm just exploring and 
questionning all the possibilities. :-)

>> And there are still quite some technical requirements to have a service
>> on par with GitLab's : keeping the servers up-to-date (see Heartbleed,
>> Meltdown & Spectre …), handling the hardware, having a redundant
>> architecture with multiple servers (preferably on separate physical
>> locations), managing horizontal scalability, setting up a deployment
>> system for all the nodes, handling automatic failover and load-balancing
>> (preferably at the IP layer), having monitoring and alerts for the
>> administrator, and probably a whole bunch more…
> 
> At HS we habe servers runing on Debian, with physical failover (DRBD),
> backupped to another data center in another town at night. The servers
> are managed (and kept updated) by hostmasters. The Webspace is shared,
> but of high quality, with SSH access. There can be a couple of users
> with webspace and mailadresses.

That's pretty cool! The only missing feature that I'm used to is having 
some form of horizontal scalability (with some load balancing), but as 
you said in an earlier message, I don't think we should be too worried 
about load. ;-)

>> My point is : it's just as likely for a person to disappear as it is for
>> a service, but most likely the quality won't be the same. And
>> considering how little it would cost to change hosting providers (this
>> is litteraly just a repository to move and a domain config to edit), I
>> don't think it is worth the hassle of getting someone to support the
>> site. :-)
>>
>> (Disclaimer : I spent two years at work wasting time struggling to get
>> servers running rather than doing actual development. I might be biased!)
> 
> You're right, thats a hell of a job, but we have admins to do that.

And personally I'm very glad they are there. :-)

> 
>>> It is already there :-) ... in the repo :-) ... in my repo :-)
>>
>> Can you give me a link ? I searched for "Christof Thalhofer" on GitLab
>> but with no success …
> 
> No, the repo is on my computer ;-) that was a joke.
> 

Oh, I didn't get that, sarcasm doesn't get transcribed very well on text 
(which is why /s was invented I guess).

>>>> I've noticed there is some code that is specific to Benoît's file
>>>> system, so right now I'm working on making this code into a portable
>>>> Static Site Generator (i.e. a script that anyone can run without issues,
>>>> and which simply outputs the static files in a given directory).
>>>
>>> Like Hugo and such?
>>
>> The principle is the same yes (source code => some process => static
>> files), but not nearly as sophisticated as any established generators
>> out there. I'm cleaning it up a little, but in the end it's just going
>> to be some simple template files being rendered to HTML (for every
>> supported language). :-)
> 
> On HS servers we could even get Gambas running. Mnogosearch which
> provides the mailinglist search, runs there, it was compiled by me on
> that webspace.

That's great !
Do you think it is possible to have an automatic deployment system 
similar to what GitLab does, so the website could be generated and 
deployed by simply pushing to the master branch ?

If you want to check out the site generator project to see how it works, 
you can get the source here[0]. As you can see it is quite a simple 
project in the end. :-)

Also, since I added a GitLab CI config file, it automatically deployed 
it to GitLab pages, so you can see the generated result here[1] (which, 
theoratically, should be the exact same thing as the original site).

The only problem for now is that the HTTPS site doesn't really work, 
since the inner frame loads gambaswiki.org in plaintext, and browsers 
(rightfully) block mixed-content requests. Fixing it requires deploying 
HTTPS on gambaswiki.org, which we should do at some point, but it's not 
too much of a deal for now.

[0] https://gitlab.com/prokopyl/gambas.gitlab.io
[1] http://prokopyl.gitlab.io/gambas.gitlab.io

-- 
Adrien Prokopowicz