I have no problem with it, BUT, (and I speak personally here), there are some people that will not use it because it's just too big (500MB is larger than some of the monthly data transfer caps in New Zealand (200MB/mo), I personally, only have 700MB/day.
Also remember that even though it may produce a 500MB noarch rpm, it also means quite likely a 500MB srpm making it 1 gig in total.
Another consideration would be the size of the community behind vegastrike, if we have 100+ then thats great, if it's only 10 then I become doubtful over it's usefulness in regards to resources. (Don't get me wrong, just trying to put a slightly different perspective on it.)
Just my two cents,
Nigel
On Fri, April 25, 2008 6:59 pm, Hans de Goede wrote:
Hi All,
I'm planning on updating vegastrike to the new 0.5.0 upstream release for F-10 and maybe later F-9 / F-8 too, but vegastrike has been dead for a while and now makes some huge changes, so better to keep the old trusted version for F-8 / F-9 for a while.
However the 0.5.0 datafiles are 500 Mb b2zipped! So is this a problem?
Regards,
Hans
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
2008/4/27 Nigel Jones dev@nigelj.com:
I have no problem with it, BUT, (and I speak personally here), there are some people that will not use it because it's just too big (500MB is larger than some of the monthly data transfer caps in New Zealand (200MB/mo), I personally, only have 700MB/day.
Also remember that even though it may produce a 500MB noarch rpm, it also means quite likely a 500MB srpm making it 1 gig in total.
Another consideration would be the size of the community behind vegastrike, if we have 100+ then thats great, if it's only 10 then I become doubtful over it's usefulness in regards to resources. (Don't get me wrong, just trying to put a slightly different perspective on it.)
Don't forget that Vegastrikes community has a strong potential to grow because we offer it and upstream will expect us to offer the lastest stable version. 0.5.0 represents a lot of work in the right direction for them and they are excited about their new features, let's not be buzzkills and carry older versions, be friends with upstream and give them a gateway to millions of Fedora users.If we treat them well they will be likely to recommend Fedora to their users and everybody wins. I, for one, have never played Vegastike but following this thread my attention has been drawn to it I would like to see what 0.5.0 has to offer.
- David
David Nielsen wrote:
Don't forget that Vegastrikes community has a strong potential to grow because we offer it and upstream will expect us to offer the lastest stable version. 0.5.0 represents a lot of work in the right direction for them and they are excited about their new features, let's not be buzzkills and carry older versions, be friends with upstream and give them a gateway to millions of Fedora users.If we treat them well they will be likely to recommend Fedora to their users and everybody wins. I, for one, have never played Vegastike but following this thread my attention has been drawn to it I would like to see what 0.5.0 has to offer.
I've never played it either, but praise is definitely deserved for an open source game shipping 500Mb of content (provided its actually all freely licensed resources). That represents an enormous effort for that team.
On Sun, Apr 27, 2008 at 10:24:29AM +0200, David Nielsen wrote:
they are excited about their new features, let's not be buzzkills and carry older versions, be friends with upstream and give them a gateway to millions of Fedora users.If we treat them well they will be likely to recommend Fedora to their users and everybody wins. I, for one, have never played Vegastike but following this thread my attention has been drawn to it I would like to see what 0.5.0 has to offer.
Multiple packages would be nice however, especially for content. There are several reasons for that
1. So I can install the basic minimal set and play a quick "demo" game and get told where to pull the rest
2. So bugs can be corrected in one piece at a time - 500MB redownloads for a packing error missing a small file kind of sucks
3. yum will cache downloads so a break in downloading of a set of smaller packages is preferable to one giant one (even if requires still eventually sucks them all in)
On Sun, 2008-04-27 at 19:23 +1200, Nigel Jones wrote:
I have no problem with it, BUT, (and I speak personally here), there are some people that will not use it because it's just too big (500MB is larger than some of the monthly data transfer caps in New Zealand (200MB/mo), I personally, only have 700MB/day.
Also remember that even though it may produce a 500MB noarch rpm, it also means quite likely a 500MB srpm making it 1 gig in total.
Another consideration would be the size of the community behind vegastrike, if we have 100+ then thats great, if it's only 10 then I become doubtful over it's usefulness in regards to resources. (Don't get me wrong, just trying to put a slightly different perspective on it.)
500mb may seem big compared to what's in Fedora so far, but from the perspective of the modern video game industry, it's on the small side.
Ever used Steam? "Digital content delivery" is the future for Windows users and console gamers, but us open source people have been doing it for *decades*. We pioneered it. Lets not start taking steps backward.
My "steamapps" directory on my Wintendo is currently totaling 15gb. That's 15gb of potentially downloadable content. The last MMORPGs I played were Ashron's Call and Anarchy Online back around 2001, and we had to put up with monthly 100-200mb+ updates even back then. How big are WoW updates?
Hell, Fedora updates seem to average in the range of 100-200mb per *week*. Now multiply that by the 6 fedora machines in my apartment, and 500mb starts to look small. Assuming vegastrike refrains from updating content every week... :)
On Sun, Apr 27, 2008 at 1:23 AM, Nigel Jones dev@nigelj.com wrote:
I have no problem with it, BUT, (and I speak personally here), there are some people that will not use it because it's just too big (500MB is larger than some of the monthly data transfer caps in New Zealand (200MB/mo), I personally, only have 700MB/day.
This sounds like a new yum plugin. "Cap my downloads to X/day" so that packages that are larger than that cap get marked etc.
Also remember that even though it may produce a 500MB noarch rpm, it also means quite likely a 500MB srpm making it 1 gig in total.
Another consideration would be the size of the community behind vegastrike, if we have 100+ then thats great, if it's only 10 then I become doubtful over it's usefulness in regards to resources. (Don't get me wrong, just trying to put a slightly different perspective on it.)
Just my two cents,
Nigel
On Fri, April 25, 2008 6:59 pm, Hans de Goede wrote:
Hi All,
I'm planning on updating vegastrike to the new 0.5.0 upstream release for F-10 and maybe later F-9 / F-8 too, but vegastrike has been dead for a while and now makes some huge changes, so better to keep the old trusted version for F-8 / F-9 for a while.
However the 0.5.0 datafiles are 500 Mb b2zipped! So is this a problem?
Regards,
Hans
--
fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, 2008-04-27 at 14:21 -0600, Stephen John Smoogen wrote:
On Sun, Apr 27, 2008 at 1:23 AM, Nigel Jones dev@nigelj.com wrote:
I have no problem with it, BUT, (and I speak personally here), there are some people that will not use it because it's just too big (500MB is larger than some of the monthly data transfer caps in New Zealand (200MB/mo), I personally, only have 700MB/day.
This sounds like a new yum plugin. "Cap my downloads to X/day" so that packages that are larger than that cap get marked etc.
While that's appealing, it's _much_ harder to be 100% accurate than it might appear. The problems include:
1. presto
2. User hitting Control-c in middle of download.
3. Metadata downloads.
4. Yum/urlgrabber re-downloading broken downloads.
...I'll probably have a go at being "good enough" anyway. Although yum really needs info. from other layers and a couple of UI things already have above related problems anyway, so fixing this layering problem would solve a couple of things.
-
Alan Cox -
Andrew Farris -
Callum Lerwick -
David Nielsen -
James Antill -
Nigel Jones -
Stephen John Smoogen