From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6324 Path: news.gmane.org!not-for-mail From: William Haddon Newsgroups: gmane.linux.lib.musl.general Subject: Wiki Hosting (Re: Release very far behind schedule) Date: Tue, 14 Oct 2014 16:13:47 -0400 Message-ID: <1413317627.19157.2@debian> References: <20141010053104.GZ23797@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1413332498 5000 80.91.229.3 (15 Oct 2014 00:21:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Oct 2014 00:21:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6337-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 15 02:21:32 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XeCLG-0000SI-GP for gllmg-musl@plane.gmane.org; Wed, 15 Oct 2014 02:21:27 +0200 Original-Received: (qmail 7836 invoked by uid 550); 15 Oct 2014 00:21:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5539 invoked from network); 15 Oct 2014 00:18:55 -0000 In-Reply-To: <20141010053104.GZ23797@brightrain.aerifal.cx> (from dalias@libc.org on Fri Oct 10 01:31:04 2014) X-Mailer: Balsa 2.4.12 Content-Disposition: inline Xref: news.gmane.org gmane.linux.lib.musl.general:6324 Archived-At: Hi all. I am a lurker on this mailing list, and have also contributed=20 occasional patches to musl. I am also running a small business that=20 provides web hosting. While I am unfortunately not in a position to be=20 able to provide hosting for free, I could rent a separate VPS and host=20 the musl wiki using Alpine Linux for a slightly higher fee than I=20 charge for shared hosting. As a fan of musl, if I like working with=20 Alpine Linux, I might consider using it for other customers. It looks=20 like you were previously using ikiWiki based on Perl for the wiki. I=20 could use ikiWiki, or if there were problems with that, I could instead=20 use any other wiki software of your choice, or for an additional fee=20 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 > 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=20 > 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? >=20 > While not essential, this would certainly be nice. >=20 > > Well, it would be a shared hosting on an existing system, so the os > > cannot be changed, I'm afraid. >=20 > 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: >=20 > - 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=20 > system > image, individual software components need to be installed and > configured to match the expectations of the site. >=20 > - 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=20 > concern, > but it still counts for something. >=20 > 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=20 > 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. >=20 > Rich >=20 =