Wandering Thoughts archives

2008-04-30

Why apt is always going to be faster than yum

One of the things that people report (to put it politely) when they switch between a Debian-derived distribution and Fedora is that apt is faster than yum. This is indeed the case, and it is always going to be the case, because yum is simply doing far more work than apt is.

(Whether or not the speed difference matters in practice is another debate. It doesn't bother me, but then I use fairly fast and beefy machines.)

As I understand it, the different amount of work is ultimately due to a basic difference in how each system approaches dependencies. In Debian, the approach to dependencies is entirely package based; package A declares that it requires packages B, C, and D. In RPMs, the dependencies are mostly on things, like files and libraries; while you can make your RPM explicitly depend on packages, you generally don't.

The end result is that there are a lot more dependencies running around an RPM-based system than there are around a Debian one, and many of them are indirect dependencies (you don't depend on a package directly, you depend on something provided by a package). Thus, doing things on an RPM-based system means checking a lot more dependencies, in bigger indexes, and generally taking more steps in resolving each dependency to a package. In short, more work that deals with more data, which means slower.

(The RPM based system has bigger dependency indexes because it has to include files and libraries and so on in them, not just packages.)

As a side note, I suspect that it doesn't help that yum has larger indexes and downloads them a lot more often than apt does.

linux/WhyAptIsFaster written at 23:59:03; Add Comment

Why you can't stop 'abuse' of file sharing services

I hope that everyone will agree that filtering 'banned' content (whatever that is in your local jurisdiction) is in practice impossible. Users are happy to rename files and otherwise obscure them in order to evade machine inspection, and no one can afford to hand audit everything that is being shared.

(Arguing that people must hand audit things anyways basically amounts to arguing that no one can run a file sharing service.)

This means that the only thing you can really do to deter this banned content is to make your service 'too unattractive' for it. But because you can't tell good content from banned content, this means making your service too unattractive for sharing things freely in general, and this means dooming your service to at best obscurity and at worse complete failure (regardless of whether it is commercial or just some free software that you want to see widely used). This is not exactly an attractive proposition, to put it one way.

(There are all sorts of ways to make your service unattractive; restricting what sorts of content you'll accept, making it awkward to upload or download, insisting on detailed registration for people who want to upload stuff so that you can trace 'abusers' precisely, and so on.)

(Demanding that people take steps to deter sharing of banned content anyways is tantamount to demanding that new file sharing services cripple themselves right from the start, right when they most need to get people interested.)

The inevitable result is that every file sharing service that is actually useful has and will always have 'banned' content; the more useful the service is, the more banned content it will have. The only way to have no banned content is to have an all but useless service, or one that is extremely restricted in scope.

tech/DeterringAbuseProblem written at 00:15:34; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.