| Steve Langasek 2005-03-19, 7:47 am |
| Hi Greg,
On Tue, Mar 15, 2005 at 02:10:47PM -0500, Greg Folkert wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> Okay, I have to comment here, seeing that I personally have at two
> separate locations, two complete mirrors, that I use nearly everyday.
> They only update when a change in the archive is detected. That means
> *MY* $PRETTY_BIG_NUMBER of usages of my own mirrors in each locale will
> mean nothing. I do my own mirror(s) so as to reduce the load on the
> Debian network. I actually scaled back what I use, now only having 5
> arches I support, SPARC(and UltraSPARC), Alpha, HPPA-RISC, PowerPC and
> x86(Intel and otherwise). I dropped IA64 a while ago and will pickup
> X86_AMD64 when it become part of Sid Proper.
> How would you address the fact the bulk of my usage is not even seen by
> your network.
Hrm, in what sense is this something that needs to be "addressed" at all?
If you use an internal mirror for your heavy internal usage, then surely
you, as a user, don't need a diverse network of full public mirrors -- you
just need one, solid mirror to download from, don't you?
It makes perfect sense to me that if i386(+amd64) represents 10x as many
downloads as all other archs combined, and the other archs combined
represent 10x as much disk space needed as i386(+amd64), it's to our
advantage to split the two so that we can benefit from mirror operators
with either high bandwidth and little disk space (i386) or lots of disk
space but less bandwidth (SCC).
[vbcol=seagreen]
> I am currently in the process of acquiring rotated out of production
> machines for 3 of the 5 architectures I support. I make a run to the
> right-coast of the US once every 2 months and pickup sometimes 10 - 4-16
> processor machines with disk and typically a dozen of GB of memory and
> gaggles of disk. I rebuild/recondition most of these machines and
> distribute them to NPOs that need this kind of horsepower but can't
> afford current stuff or even used stuff from those same suppliers. I put
> Debian on them and this makes a huge investment in the long term health
> of these Orgs.
> If these machines are no longer fully supported by Debian... how can I
> continue to do this.
What does "fully supported" mean to you? What are the use cases for these
machines? Which aspects of stable are required by these users?
> How much is the difference between Debian running on "Humidifier in the
> Basement" reputation, and a "We release more often than Ubuntu"
> reputation?
> But, serious, how much do you think Debian will be hurt with:
> Compare these:
> 1. Debian the "Universal OS"
> 2. Debian the "Almost-Sorta-Kinda-used-to-be Universal OS"
> 3. "Old as fossilized dinosaur poo, and as stable, but runs on
> everything including the humidifier in the basement"
> 4. "Very recent, since it doesn't really support NON-big 4
> processors anyway, so why not run Fedora Core"
> Personally, I like 1 and 3. They are the 2nd and 3rd most important
> technical reasons I chose Debian. 1st technical reason is the Debian's
> maintainability. Please oh please let us not change my mind for me.
I'm assuming your humidifier isn't connected to the public Internet, and
doesn't need ongoing security support...?
We're also constantly hearing from users who are using Debian in settings
where they *would* benefit from security support, but are running testing
or unstable because woody's fossilization factor is too high for them. How
would you suggest that we balance these users' needs for a more frequent
stable release, against the needs of users like yourself who need broader
arch coverage?
[vbcol=seagreen]
> Me, too. How about we have a CORE of Debian mirror infrastructure or
> Base Install only for Stable, Testing, Unstable.
> Then either on the same machine(s) or not, a separate mirror
> infrastructure for anything beyond that. IOW, any packages that are not
> included in the Base install. Including main, contrib and non-free for
> Stable, Testing, Unstable and Experimental. Where as the Experimental is
> only on the secondaries mainly for major changes testing anyhow.
I really don't understand what problem you're trying to solve here.
Mirroring is not the problem that causes release delays.
> This is a very feasible, well thought out and scalable option. Heck, we
> could release "Base-Install" and let the Buildd(s) for all the arches on
> the secondaries catch up.
If it's useful at all to do a stable release of just the "base-install",
then we should question whether it makes sense to build the rest of the
archive for these archs. But the first question is probably, what would be
included in this base install?
> This gives us five benefits:
> 1. We will not have be worried about Stable being to OLD. It always
> lets us have faster upgrade cycles to the Stable Base-install.
> The Applications would follow shortly. Once the Stable
> Application buildds get updated, they'll start churning out the
> updated applications.
I'm not willing to manage two-part releases; and there's no infrastructure
in place to allow it.
> 2. It allows nearly any number of architectures to be supported by
> Debian. As long as they have a buildd to keep up with stable it
> should be a no-brain-er.
Um, one of the fundamental reasons we're looking at this question is because
of the difficulty in ensuring, on an ongoing basis, that it is *possible* to
build the packages in stable across all architectures (whether for toolchain
reasons, or for reasons of hardware scarcity).
I think your design really reduces to a restatement of the question, "why do
we ask all of our architectures to build all of the packages?" I think this
is a very pertinent question, and perhaps this discussion will lead us to an
understanding of whether, and for which architectures, we should be asking
for this.
--
Steve Langasek
postmodern programmer
|