On 2013-11-14 10:37:21, Tollef Fog Heen wrote:
> ]] anarcat
>
>> On 2013-11-14 05:20:12, Tollef Fog Heen wrote:
>> > ]] anarcat
> I'm not aware of any open source 40GE PHYs for instance? Most of what
> I've seen done is around SDN, which is all nice and good, but doesn't
> actually make the PHY and MAC firmware free. I haven't been trawling
> around, so maybe it's further ahead than I thought.
>
> Even if you restrict yourself to the main UEFI implementation, can you
> even get anything free for a modern server there? With warranties?
> Having to void your warranty to run a free UEFI implementation is not
> something we'd like to do.
Well, those are pretty specific examples, which apply to all hardware we
are currently using. With that argument, we might as well say we are not
running free software at all. :)
There's some inevitable proprietary hardware out there, sure, but it
shouldn't be an argument to letting more proprietary software into our
infrastructure.
>> > This is not a two-tone discussion and trying to make it one will not
>> > lead to a useful outcome.
>>
>> And saying that "because there's proprietary firmware in your BIOS it's
>> okay to offload all of Debian's infrastructure to a non-free CDN is okay"
>> seems to me to be a slippery slope.
>
> Nobody has talked about moving all of Debian's infrastructure.
Okay, "some". The argument remains: it's still a slippery slope argument. :)
The concern for me is moving a critical part of the infrastructure
there. If we are just talking about adding resources, I think that's an
interesting idea, but the title of this thread and the original post
were suggested to "move" some of that critical infrastructure over
proprietary and heavily surveilled commercial providers. I am
uncomfortable with that idea.
>> > It's not a vote, and it's easy for the people who do not have to do
>> > anything but send mails to a mailing list to say «we should spend more
>> > effort».
>>
>> Well, if it's not a vote, and if my opinion doesn't actually matter, why
>> are we discussing this on -project in the first place?
>
> We were hoping to get some useful feedback.
I hope you did! It certainly encouraged me to look further into hosting
our own Debian mirror now. :)
>> And the improvements necessary to get this to a "commercial-grade" CDN
>> doesn't seem to me like much more: some IP alias on the mirror machine,
>> and BGP announcements.
>>
>> Am I missing something?
>
> Yes. If you're just anycasting an IP, you'll get pretty poor
> performance.
Can you expand on that?
> You need monitoring to make sure the mirror is up to date
> and something that automatically updates DNS when it isn't, and puts it
> back in when it is.
That is a problem we're having already, and that we'll probably have
with commercial CDNs, or at least that we'll have to resolve so get a
consistent state across the mirrors.
> You need to herd the mirror operators, keep them happy, make sure
> they're using the right tools so you don't get transient breakages in
> the middle of a mirror run.
Right. We could start with a smaller subset...
> If you're going to do anycast, you'll need to have BGP announcements
> sent from a diverse set of places.
This seems like something we have, with the variety of mirrors out
there. :)
> You need to monitor your BGP stuff, trace down why you get suboptimal
> routing for a given user and get that fixed.
I am not sure how or why you could get suboptimal routing through BGP
links, but I am fairly new with this technology (a few years) so maybe I
am missing something here again.
> You'll need to run GeoDNS and correlate that with routing so
> hopefully, the user hits the best server.
I was thinking that using anycast would alleviate the need for geoDNS
hacks...
> And that's just a few items off the top of my head.
I responded to those, I hope you don't mind having that discussion. :)
If you are tired of it or were just giving examples, feel free to
disregard.
> Running a CDN is not hard. Running a CDN well, over time, is hard. It's
> something that DSA would not add value by doing ourselves, just like we
> would not add value by creating our own OOB solutions or soldering
> together our own UPSes. It's not that we can't, it's that it's cheaper
> and more reliable to buy a ready-made solution and most important of
> all: it's not part of our core mission. It's a means to an end, not an
> end goal in itself.
I see your point, although I think there is a few orders of magnitudes
between adding improvements to the current mirror infrastructures versus
soldering PCBs... It just seems to me that providing the basic tools for
sponsors to join the CDN doesn't seem that complicated. After all, DSA
doesn't manage all mirrors right now.
I guess what I am saying is that doing incremental improvements over the
mirror infrastructure should be considered. I am worried that migrating
to a commercial CDN will be detrimental to the current infrastructure,
which are based on a spirit of free access and open knowledge, something
commercial CDNs seem to be alien to...
Cheers,
A.
--
Be who you are and say what you feel
Because those who mind don't matter
And those who matter don't mind.
- Dr. Seuss
Attachment:
pgpD7UpU2Xe36.pgp
Description: PGP signature