yup.. 128k as the bandwidth limit sorta limits what we could do with
that connection. Its hard to also hard to donate or expense any
connection to something like this. However a cache community could
make a difference.
On 4/20/07, Mike Tibor <tibor@tibor.org> wrote:
> When Mike says opening up the server to the world might get a little
> dicey, he's not kidding. Depending on what's hosted on the server, we
> could max out 128K in no time at all.
>
> Several years ago when the server was hosted at Core, I'd got it ready to
> host a mirror of the soon-to-be-released Red Hat 9. When the release
> notice came out, we maxed out Core's T1 in about 10 minutes.
>
> Mike
>
> On Fri, 20 Apr 2007, barsalou wrote:
>
> > Shane, thanks for rambling...not sure what message your trying to
> > convey here, but one thing I can add to this is that our link to
> > ftp.aklug.org is a 128KB link and is provided by Dee McKinney of Alaska
> > Wireless.
> >
> > The other thing that should be known is that the current ftp server
> > only has about 60G. Currently only .5G is online at the moment. I'm
> > working to correct that soon.
> >
> > So opening up the ftp server to the world gets a little dicey.
> >
> > Given the relatively slow link and small amount of space, it's hard to
> > do much more with this resource.
> >
> > Which is why I mentioned the meeting. We will be talking about this
> > and other such issues.
> >
> > Mike B.
> >
> > Quoting Shane Spencer <shane@bogomip.com>:
> >
> >> I wish I had time to ramble on about why I can't regularly show up to
> >> the meetings. A lot of us have our own reasons for it. However our
> >> support doesn't waver.
> >>
> >> Mike, from what I gather you are primarily responsible for the machine
> >> responding to ftp.aklug.org, is this the same for the uplink it is
> >> using? I'm not 100% sure on my assumption, I wasn't really looking
> >> for something 'fun' to investigate when I asked for what I thought
> >> would be clear answers.
> >>
> >> So..
> >>
> >> My apologies if I am about to be horribly redundant or incredibly
> >> stubborn about a single simple issue. This has crossed the list
> >> before because of this silly obsession I have.
> >>
> >> I... love... caching.
> >>
> >> I have used CoralCDN for content distribution and caching and hoped to
> >> make a test node or seperate network in Alaska some day (coming soon I
> >> hope). I use caching apt repository proxies like approx in tandem
> >> with apache or squid to offer what appears to be a full working
> >> repository by directly proxying or redirecting all non package based
> >> content requests to the original servers, while caching all packages.
> >>
> >> More important than just caching is high speed networks distributing
> >> cached content. I use Flickr, tinypic and the like along side some
> >> custom programs to offload my content to their distributed caching
> >> network and away from my 10G quota MTA dsl connection. Using certain
> >> FTP "push" techniques you can even offload large content dynamically
> >> to your ISP's free web hosting account on the fly using redirects and
> >> smart programming techniques. This method pushes updated content to
> >> your ISP web account for them to serve out multiple times on their
> >> high speed network instead of your slow ass hell upload speed and
> >> using up your monthly transfer limit. Hell even I love having a rice
> >> cooker that has rice "cached" and ready for me when I get home.
> >>
> >> HTML and HTTP spec encourages caching and content distribution, yet
> >> the world forgot to segregate cachable HTML content from dynamic
> >> content for a single web page until recently, thank you Web 2.0.
> >>
> >> Bittorent and Zsync take chunks of data, hash them, and allow chunk
> >> level synchronization of compressed and raw data via HTTP and
> >> distributed content delivery. Preemptive caching! Thats not really
> >> the term used however in essence thats what is happening.
> >>
> >> Everybody in AKLUG knows our public IP network is highly segregated
> >> from the rest of the world. It is important that if we have space,
> >> somewhere, to offer caching to our members and linked to non-members
> >> as needed, many LUG groups gain a wider name exposure by becoming
> >> mirrors for popular data. The release of "The Fawn" for instance
> >> being a primary example of this. Now I bet peeps and folks like
> >> Arthur and Mike at AT&T can do the math and tell AKLUG beyond a shadow
> >> of a doubt that if we started using our connection to the lower 48
> >> less, that things may get more expensive for either AT&T or any of the
> >> ISP's that depend on AT&T for their IP service. I assume this based
> >> on the supply and demand model. The more of us that try to squeeze
> >> out of Alaska and get the same damned thing just increases the demand.
> >> I love hypothetical situations on the list so please put me in my
> >> place for the benefit of all of us. We could finally have a good well
> >> thought out idea of the interactions and ISP governing we deal with in
> >> Alaska.
> >>
> >> Thank you Damien for taking the Feisty ISO's offline to CD for people
> >> to use, its very thoughtful if not the ultimate sneakernet caching
> >> system.
> >>
> >> Shane
> >>
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >
> > ---------
> > To unsubscribe, send email to <aklug-request@aklug.org>
> > with 'unsubscribe' in the message body.
> >
> ---------
> To unsubscribe, send email to <aklug-request@aklug.org>
> with 'unsubscribe' in the message body.
>
>
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Fri Apr 20 12:59:55 2007
This archive was generated by hypermail 2.1.8 : Fri Apr 20 2007 - 12:59:55 AKDT