Wiki Hosting (Re: Release very far behind schedule)

[William Haddon <whaddon@munodisolutions.com>]

Hi all.

I am a lurker on this mailing list, and have also contributed 
occasional patches to musl. I am also running a small business that 
provides web hosting. While I am unfortunately not in a position to be 
able to provide hosting for free, I could rent a separate VPS and host 
the musl wiki using Alpine Linux for a slightly higher fee than I 
charge for shared hosting. As a fan of musl, if I like working with 
Alpine Linux, I might consider using it for other customers. It looks 
like you were previously using ikiWiki based on Perl for the wiki. I 
could use ikiWiki, or if there were problems with that, I could instead 
use any other wiki software of your choice, or for an additional fee 
develop new wiki software. Just another option for you to consider.

Cheers,
William Haddon

On 10/10/2014 01:31:04 AM, Rich Felker wrote:
> On Thu, Oct 09, 2014 at 12:57:46PM +0200, Tim Tassonis wrote:
> > >> On October 8, 2014 4:53:36 PM Rich Felker <dalias@libc.org>
> wrote:
> > >> > Jeremy is aware that the wiki is down but doesn't have much
> > >> > time to devote to it, so we should look for a new solution for
> hosting
> > >> > and maintaining it in the future.
> > >>
> > >> I could do the hosting for free, as me and a friend run a little
> hosting
> > >> business.
> > >> I'd have to know what software you'd need on the server, but 
> this
> shouldn't
> > >> be a problem, we have ubuntu servers with apache, php, mysql and
> postgres,
> > >> normal stuff. If you need something else, we could install that,
> too.
> > >
> > >How about using Alpine Linux for it so its powered by musl libc?
> 
> While not essential, this would certainly be nice.
> 
> > Well, it would be a shared hosting on an existing system, so the os
> > cannot be changed, I'm afraid.
> 
> I don't want to be micro-managing things like hosting and maintenance
> of the wiki, which is obviously something of a time-drain. However, I
> do tend to think shared hosting is a poor solution these days:
> 
> - It makes it a lot more of a pain to move, if we need to do so again
>   in the future -- instead of just re-deploying a fully working 
> system
>   image, individual software components need to be installed and
>   configured to match the expectations of the site.
> 
> - It's generally much less robust and secure. Security bugs, or just
>   out-of-control memory usage and load, from another site on the same
>   hosting can bring down or compromise the wiki. Being that it's just
>   the wiki and not the git/release hosting, that's not a huge 
> concern,
>   but it still counts for something.
> 
> I'm ok with keeping any options open for now, but let's see if we can
> get some more to consider too. All in all, the more-important issue
> anyway seems to be making sure we have somebody who's going to be 
> with
> the project for at least a moderately long term and have time and
> resources to devote to keeping the wiki running well -- dealing with
> spam, account troubles, hosting problems, etc.
> 
> Rich
>