On Fri, Oct 20, 2000 at 10:52:06PM +0300, Eray Ozkural wrote:
> Anthony Towns wrote:
> > Well, that might not be necessary: we might find that we top out the
> > number of packages we want at 10k, and decide to focus more on just
> > maintaining and enhancing those rather than packaging more stuff, or
> > we might find that disk and network keep pace with Debian so while
> > we're always large and time consuming to mirror, it's not all that
> > unpleasant.
> [I have a disturbing feeling that "we" doesn't refer to debian here,
> but only a few sysadmins...]
Well, considering I'm not a sysadmin for any Debian machines, that's
obviously not the case.
For a frame of reference, btw, if James or I were being particularly
unaccountable, da-katie and testing would be in place, and we'd be saying
"oh, btw, yesterday we did [..]", if you don't like it, too bad. As
opposed to discussing it on mailing lists in advance, inviting people
to look at the code, and so on.
> With this rate of development in the free world, there's going
> to be more than 10k high quality software packages in Debian.
That assumes that the rate stays predicatble: that it continues being
exponential (in which case we'll hit 10k packages sometime early in 2002
and 20k packages mid 2003ish, by my guess), or it at least stays roughly
constant at its current level (in which case we'll hit 10k packages
sometime around 2004, and 20k packages around 2010).
> > Or we might find that disk keeps pace, but bandwidth doesn't
> > so we have to find some better way to mirror stuff as far as bandwidth
> > usage goes, but that actually storing packages is easy and fine. Or
> > something else might happen.
> Good, then it means we'd have to find a better way to distribute
> software than plain ftp. Not necessary for a couple of years I guess.
Well, if these things actually *happen* we might. But then again, they
might *not* happen too. If you want to research how we might overcome
these problems, feel free, when one of them eventually does happen,
feel free to come back and say "I told you so, oh and by the way here's
an analysis of the problem your facing and some ways you can overcome it".
> > > yea, rough consensus and working code, right? i guessed that, but it
> > > was presented as the best implementation strategy (and it hadn't seemed
> > > to me that way)
> > It's a best implementation strategy given our existing desires and
> > constraints. One of which is programmer time, and another of which is
> > acceptability to the existing ftpadmin people. It's not an academic
> > solution, although obviously it's informed by academic pursuits.
> Okay. Shall we say, it's the decision of the programmers involved in
> a particular implementation of "package pools" which has no guarantee
> of completeness.
"completeness"? It is complete. It does everything that it needs to do:
it provides a compatibility layer between the old dinstall and the new
software, it handles the key features of package pools, it handles the
old and new release mechanisms.
> > > i would rather write a new fs that does dirs and symbolic
> > > links right :)
> > That'd be more useful for the BTS than the ftp system. (You can't
> > guarantee all our mirrors will use said fs, eg)
> yea? what about symlink-farms for distribution dirs?
What symlink-farms would this be? The ones that won't exist?
> > Academic solutions probably won't be directly applicable to Debian
> > though. Debian's far too political and complicated and entrenched to end
> > up with ideal solutions. So if you want to do something pristine and pure
> > and *correct*, you're probably better off just writing a paper.
> That's true about pure theoretical work which doesn't apply directly to
> situations like this. But if you're related to computer science in a way,
> you'll know that practical work is a very important part of the whole
> enterprise.
Actually, from my experience, it's not at all important. Take our fondness
of Linux, for example: it's written in a basic procedural language
that hasn't really had significant changes since 197x (think object
inheritance, lambda functions, generics, namespacing), it's external and
internal design basically just mirror previous versions of the same thing
(compare to microkernels (Hurd, say), capability oriented systems (Eros),
object based systems (Self, if you'll let me push things), or distributed
systems (the best of which I can name is Plan9)).
> For instance in the field I study, that is algorithms/parallel programming,
> you need to write a program that *no one else* can top, including
> some random hacker who knows a bit C and a few scripting languages.
> It's pretty much like that in many areas. How do you think B+ trees
> that you see in the database implementations got here? From heaven?
And continuing the example, you'll not how B+ trees, even though they're
old enough and standard enough to be taught to undergraduates, aren't
actually the basis of the main database we actually work with ever
day: ext2.
You say you're into algorithms. Maybe, then, you'd like to do some
peer review of the algorithm used in "testing", which is hidden away in
auric:~ajt/testing/testing/dpkg.c in the check_installable() function.
Hmm. Except you can't look at that because you're not an actual developer.
Well, try http://auric.debian.org/~ajt/code/testing/dpkg.c instead. Read
up on the SAT problem first, perhaps.
> If Debian's far too political and complicated and entrenched to end up
> with ideal solutions, *it's debian's mistake* Debian organization should
> be revamped to focus on "getting things right", then.
If you want to get rid of the "entrenched" thing, all you have to do
is start ignoring all the existing users and packages and start from
scratch. If you want to get rid of the "political" thing, you just have
to get rid of all the maintainers who've put their time and effort
into making Debian useful for *them*. If you want to get rid of the
"complicated" thing, you need to trim down the number of packages,
users and maintainers to something much smaller: you're not going to
end up with an uncomplicated distribution with 20k packages.
> Free software doesn't mean low-quality software.
Nor does imperfection.
> So those papers that you're implicity disgracing probably has a lot
> more work put into them than many of the fellows here did.
Heaven forbid! Writing a paper is a *great* thing to do. But it's a
*different* thing to do than to help Debian out *today*. The point of
research and papers and such is to become useful in a year, or ten,
or whenever it's *needed*.
Going back to the ext2/BTree example, you'll note that now that Linux is
being used for really large scale things, there are suddenly a handful of
new (or ported) filesystems that use BTrees appearing. (Although reiserfs,
at least, has problems gaining acceptance because its focussed too much
on solving the problems the author wants to focus on rather than the
problems that are stopping it from being widely accepted: stability and
forwards and backwards compatability, and security for example)
> And quality
> software. I suppose no one would ever write "make" or "yacc" if everyone had
> this simple ideas. Being simplistic doesn't always work.
You'll note the "make" is a long way from prolog.
> > If you want to do something that'll work with Debian, tattoo "compromise"
> > on the inside of your eyelids, and get something that's an incremental
> > improvement on what currently happens.
> ad hoc things don't always build up to better things. that's what
> they teach to any engineer.
> you know, that's why people first do some design and then get
> to realizing it.
Well, before va.d.o crashed, I could've pointed you at
http://www.debian.org/~ajt/, and if the lists archives worked I could've
pointed you at http://lists.debian.org/debian-devel-9808/msg00002.html
and two other urls, but suffice to say we've been designing this (in
public) since at least '98 (others have pondered it before then, too,
but I won't presume to speak for them).
> > I'm sure there's some simple version of all the highfalutin ASCII art you
> > drew for the sectioning business, that you could demo and get added to apt
> > which would be useful, [...]
> Have a look at some the papers I referred to on that thread, there
> are various technical issues to be thought there. [this isn't
> a trivial matter, you need to do some paperwork]
If I cared I might have to do some paperwork. I don't. Please, go ahead
and get something that works to demo so people can judge it for themselves
without having to read boring academic papers they don't care about.
> It also needs some understanding of knowledge engineering in general.
Categorisation will be useless if you need a degree in knowledge engineering
to work out how to find a package, or to see why some ideal way of doing
things is better than the current way.
> I'd be very glad to hear some concrete suggestions for package
> categorization. [ie, not involving patching "Section:" field]
You have a very strange definition of the word "concrete".
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpF8tevH3tRj.pgp
Description: PGP signature