[Foundation-l] Alternative approach for better video support
Daniel Arnold
arnomane at gmx.de
Mon Jul 23 15:44:51 UTC 2007
On Monday 23 July 2007 15:48:24 Anthony wrote:
> Well, you suggest that cost of bandwidth is the reason, but that
> contradicts what the developers have been consistently saying - that
> there is no bandwidth problem.
Well according to my rough estimate the Wikimedia media repository has a size
of 500 GB.
Now assume one can download that with his new 10Mbit/s at home DSL line at
full speed: You'd need almost 5 days until the download is complete (and
although you might have a flatrate, I am pretty sure your ISP will have some
fair flat policy and makes some troubles sooner or later).
Now let us assume a somewhat more likely download rate of 200kB/s (you know
concurrent downloaders and other things). You'd need 30 days for a complete
download.
You're mixing seveal things: Wikimedia has no bandwith problem for its
_current_ operation but you shouldn't forget that bandwith alone is only the
half trouth. There is transfer size as well and transfer size costs money
right now. Money from many many donators. If we reject a material donation
that reduces our transfer costs and thus makes better use of our money
donations we'd be pretty stupid and furthermore we'd waste donated money for
no good reason.
So if we're going to provide video and audio streaming on a large scale we
will have greatly increased transfer costs.
> Yes, you present one solution to a problem which the foundation says
> it doesn't have.
Sorry but you mix up several things. See above. If the Foundation wouldn't
have a problem with media file database downloads and large scale video
streaming you'd implicitely assume that they are lazy people that just don't
want to provide the media repository for some evil reasons...
> There are lots of other solutions too, once we get
> past the step of identifying exactly why there is no tarball for all
> commons images.
Sorry to be so unfriendly but you simply have no clue. HTTP and FTP simply
weren't designed for downloading moving targets in the size of 500 GB! Rsync
is not just a random geek software none else uses. Rsync exists for a very
good reason: Use cases like our, namely sncronisation of huge amounts of
constantly changing data between a master and a mirror slave.
My suggested solution (I can only recomend reading the initial post again) is
an approach to solve both the streaming issue and the media download without
even requiring usual Wikipedia readers to use "new" software like Rsync.
> Who would be a good central point of contact at the WMF for answering this?
These people are reading here (most times carefully ;-).
Arnomane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.wikimedia.org/pipermail/wikimedia-l/attachments/20070723/3a4dca80/attachment-0001.pgp>
More information about the wikimedia-l
mailing list