@Miriam: all the examples you gave points to the hosting domain ( ibiblio.org ); we want pygame.org or similar with a hosting that allows DNS redirection from pygame.org to the content. That way, if at some future time we want to migrate or add a non-static part all that is needed is to change the DNS entries.
Probably size is not a problem : pygame site provides docs, articles and game announcements; it does not host the game downloads. On Thu, Dec 22, 2016 at 10:45 PM, Miriam English <m...@miriam-english.org> wrote: > The two repositories I mentioned, ibiblio.org and archive.org (I'm sure > there are more) have, as far as I know, no limits on storage. > > Have a look, for instance at the amount stored for Puppy Linux at ibiblio: > http://distro.ibiblio.org/puppylinux/ > > Each of those subdirectories you see relates to a different kind of Puppy. > > The packages directories contain programs specifically tailored for a > particular distribution of Puppy. The pet_packages-lucid directory alone > contains more than 10 Gigabytes of programs, and there are more than 30 > Puppy distros with associated package collections. > > The puppy-528 directory contains a couple of ISO CD images for Puppy Lucid > 528. It also contains an explanatory webpage: > http://distro.ibiblio.org/puppylinux/puppy-5.2.8/release-Lucid-528.htm > > Most of the main distro directories contain such a page. > > There is lots more on ibiblio, as a quick wander around > http://distro.ibiblio.org/ will show. > They also have multiple mirrors around the world, so if one set of servers > has a problem others are available. > > Cheers, > > - Miriam > > > Charles Cossé wrote: > >> Hi, >> >> On Thu, Dec 22, 2016 at 2:02 PM, Miriam English <m...@miriam-english.org >> <mailto:m...@miriam-english.org>> wrote: >> >> I don't see the point of using github for the web pages and >> keeping the content elsewhere. I don't have a lot of experience >> using github (I find it a pain actually). Github is intended as a >> versioning system. That has no utility for a pygame repository, as >> far as I can see -- or at least no advantage over an ordinary >> repository built purely with that purpose in mind. >> >> Wouldn't it be simpler to keep the whole thing in a repository? I >> mentioned 2 earlier: archive.org <http://archive.org> and >> ibiblio.org <http://ibiblio.org>, both of which are free and very >> >> secure. >> >> >> I can say a little bit that might help until someone with more knowledge >> has time to reply ... With GitHub pages your website is "just another" >> repo. That's the main thing I wanted to point out. There are no storage >> limits, and I'm pretty sure that GitHub would be happy to help pygame >> accomodation-wise if pygame needed anything special (within reason). I >> also know that there is a 4 gigabyte file limit on GitHub. (I know this >> because I once wanted to host an 8G SD card image and had to get it down to >> 4G in order to be housed on GitHub). >> >> FWIW, I have also managed to run webapps on GitHub via GitHub pages. For >> example http://asymptopia.github.io/TuxMathScrabble-2015/. >> >> And, not trying to direct traffic to my site or anything, but here's my >> own site using GitHub pages: https://asymptopia.github.io/ >> >> Best regards, >> Charles >> >> Cheers, >> >> - Miriam >> >> >> Thomas Kluyver wrote: >> >> Thanks everyone for your input. In the interests of making >> progress, I'd like to propose: >> >> - The informational site will be hosted on Github pages; I've >> used this for a number of websites before, it's reliable, we >> can point an external domain to it, and I imagine that most of >> the likely contributors have Github accounts already. >> - The pages will be generated by a Python static site >> generator. There doesn't seem to be a strong feeling between >> Sphinx/Nikola/Pelican, so it will likely depend on who is most >> excited to start building it. >> - The game feed will also be generated from content in Github, >> so /at first/ developers will need to submit a PR to add a >> game. Once that's working, we can build a simpler submission >> interface on Heroku/Appengine/similar which can push content >> to Github. Ideally the data will be in a format which would >> could move elsewhere later if necessary. >> >> I like the concept of drawing the game feed from an external >> source, but I don't think any of the sources proposed match >> what we want closely enough. >> >> Does anybody object to any of those proposals? >> >> Thanks, >> Thomas >> >> On 18 December 2016 at 20:18, Miriam English >> <m...@miriam-english.org <mailto:m...@miriam-english.org> >> <mailto:m...@miriam-english.org >> >> <mailto:m...@miriam-english.org>>> wrote: >> >> http://ibiblio.org is an enormous, free repository that also lets >> you have static webpages. Many of the Linux distros are hosted >> from there as well as much else too. I don't know how >> you'd set up >> a comments system there. It may be possible. >> >> http://archive.org is another gigantic free repository. They >> already have a comments system built into their pages. I don't >> know how it works. It might be worth checking out. >> >> Both these organisations are free and are aimed at helping >> make >> content available to the community which might otherwise >> be lost. >> You have complete control over the look of webpages at >> ibiblio.org <http://ibiblio.org> >> <http://ibiblio.org> because you simply upload static pages. >> >> I don't know how much control over the look archive.org >> <http://archive.org> >> <http://archive.org> provides because everything is dynamically >> >> served from xml data, I think. It might be possible to add >> static >> content, I don't know. >> >> But both are free, permanently available, and have >> excellent security. >> >> Cheers, >> >> - Miriam >> >> >> >> Peter Shinners wrote: >> >> Gitlab also has great static site support for free, >> and you >> can use custom domains. They also make it easy to run most >> static generation tools as a CI job. Although part of me >> thinks just pushing the static content is easiest. It >> sounds >> to me like there's a list of acceptable hosting >> choices that >> won't cost anything. >> >> Keeping the games list as a feed from other service sounds >> like it has the best chance of working. >> >> >> On 12/17/2016 10:51 PM, Lenard Lindstrom wrote: >> >> Bitbucket also has static web site support. I set >> one up >> for the Pygame docs awhile ago, but have not >> maintained it: >> >> http://pygame.bitbucket.org/docs/pygame/ >> <http://pygame.bitbucket.org/docs/pygame/> >> <http://pygame.bitbucket.org/docs/pygame/ >> <http://pygame.bitbucket.org/docs/pygame/>> >> >> The repository is here: >> >> https://bitbucket.org/pygame/pygame.bitbucket.org >> <https://bitbucket.org/pygame/pygame.bitbucket.org> >> <https://bitbucket.org/pygame/pygame.bitbucket.org >> <https://bitbucket.org/pygame/pygame.bitbucket.org>> >> >> Lenard Lindstrom >> >> On 16-12-17 09:16 PM, Daniel Foerster wrote: >> >> You know, I suppose we could just use GitHub >> pages. >> >> On Dec 17, 2016 17:32, "Charles Cossé" >> <cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com>> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com>>>> >> wrote: >> >> >> >> On Sat, Dec 17, 2016 at 4:12 PM, Daniel >> Foerster >> <pydsig...@gmail.com <mailto:pydsig...@gmail.com> >> <mailto:pydsig...@gmail.com <mailto:pydsig...@gmail.com>> >> <mailto:pydsig...@gmail.com <mailto:pydsig...@gmail.com> >> <mailto:pydsig...@gmail.com <mailto:pydsig...@gmail.com>>>> >> wrote: >> >> Using S3/CloudFront is a lot cheaper >> than the >> EC2 setup you're >> imagining (and which a Django stack would >> require). >> >> >> >> I never said to use Amazon at all. Just >> use the >> current server, >> whatever it is (unless it's Amazon). >> >> On 12/17/2016 05:11 PM, Charles Cossé >> wrote: >> >> Yikes! who's gonna pay the Amazon >> bill? >> >> On Sat, Dec 17, 2016 at 4:09 PM, Paul >> Vincent Craven >> <p...@cravenfamily.com <mailto:p...@cravenfamily.com> >> <mailto:p...@cravenfamily.com <mailto:p...@cravenfamily.com>> >> <mailto:p...@cravenfamily.com <mailto:p...@cravenfamily.com> >> <mailto:p...@cravenfamily.com >> <mailto:p...@cravenfamily.com>>>> wrote: >> >> If most of the site is static, >> then I >> think Django would >> be overkill. The static >> portion of the >> site can easily be >> deployed via Amazon >> S3/CloudFront and >> then we'd not have >> to maintain a server. >> >> Paul Vincent Craven >> >> On Sat, Dec 17, 2016 at 5:00 PM, >> Charles Cossé >> <cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com>> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com> >> <mailto:cco...@gmail.com <mailto:cco...@gmail.com>>>> wrote: >> >> >> On Sat, Dec 17, 2016 at >> 3:26 PM, >> Thomas Kluyver >> <tak...@gmail.com <mailto:tak...@gmail.com> >> <mailto:tak...@gmail.com <mailto:tak...@gmail.com>> >> <mailto:tak...@gmail.com <mailto:tak...@gmail.com> >> >> <mailto:tak...@gmail.com <mailto:tak...@gmail.com>>>> wrote: >> >> >> So far, I think the >> proposals >> for the static >> information part of >> the site >> are Nikola (a static >> site generator >> oriented around >> blogs) and Sphinx >> (oriented around >> docs). Both >> are written in >> Python. Does anyone >> want to >> make the case for any >> other system? >> >> >> Can Django factor-in there? I >> guess it would reside >> underneathe the other pkgs >> ... but >> might as well run >> Python through-and-through >> imho. >> >> >> >> >> >> -- >> Linkedin >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse> >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse>>> | >> E-Learning <http://www.asymptopia.org >> > >> >> >> >> >> >> >> -- >> Linkedin >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse> >> <https://www.linkedin.com/in/charles-cosse >> <https://www.linkedin.com/in/charles-cosse>>> | E-Learning >> <http://www.asymptopia.org> >> >> >> >> >> >> >> >> >> -- There are two wolves and they're always fighting. >> One is darkness and despair. The other is light and hope. >> Which wolf wins? >> Whichever one you feed. >> -- Casey in Brad Bird's movie "Tomorrowland" >> >> >> >> -- There are two wolves and they're always fighting. >> One is darkness and despair. The other is light and hope. >> Which wolf wins? >> Whichever one you feed. >> -- Casey in Brad Bird's movie "Tomorrowland" >> >> >> >> >> -- >> >> Linkedin <https://www.linkedin.com/in/charles-cosse> | E-Learning < >> http://www.asymptopia.org> >> >> >> > -- > There are two wolves and they're always fighting. > One is darkness and despair. The other is light and hope. > Which wolf wins? > Whichever one you feed. > -- Casey in Brad Bird's movie "Tomorrowland" > >
