On Thu, Mar 28, 2002 at 03:53:46AM +0100, Erich Schubert wrote: > > I'm not sure it will increase the speed really much, it would at least > > make the Packages files a lot smaller. > > The problem is: will it help saving unnecessary download of files? > That way, apt-get update would have to load hundrets of files... No, it doesn't have to. Also see my other reply. > That's why i suggested using flavours. Our System is ready for flavours. > We have the package pool ;) > People running Debian on a desktop then wouldn't need to load infos > about Roxen Challenger for example. Yes, I also think that. But I think making those flavours with the Packages files for each source file would be nicer. > > IMHO debconf should be used for every configurable thing. It's nice to > > have a common interface for this. > > Sure, i'd love being able to configure even things as _user_ with > debconf, just to have this common interface. But there should be a > difference between install-time-questions, > any-time-configuration-questions and user-configuration-questions. > We don't have the last; debconf right now is designed for the first and > used for the first two things... (for example openldap confiugration > IMHO doesn't belong into the system installation phase... > Having an empty directory running is not much better than having none > running at all ;) Maybe it's just me, but I haven't had any problems like this. But of course if people want it we could add the necessary features. If just somebody writes a patch. :) > > I don't know how far Marcus is with his console server for the Hurd, I > > think mouse support doesn't exist, but when we add it it will probably > > a bit better. :) > > I have very high expectations of the Hurd... I have too. We only have a chicken-and-egg problem. The Hurd doesn't have enough developers because the current state isn't that great. And the current state of the Hurd doesn't improve much because we don't have enough developers. > Is speed improved by now? Last i heard, the hurd was still having speed > problems due to the many process and context switches. :-( Yes, the Hurd has speed problems. No, this isn't because of the context switches. Research has proven that microkernels can be fast, the problem is that the Hurd currently runs on an old, first generation microkernel (mach). We are going to switch to the second generation microkernel L4, this is a very fast microkernel. Of course it isn't only the microkernel. The Hurd itself is also very slow. Speed has never been a priority, there are other things which have a higher priority. The Hurd has never been profiled, we don't have good caching to name a few things. But this doesn't mean the Hurd can't be fast. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: jdekkers@jabber.org Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: jeroen@openprojects
Attachment:
pgptQJ5sjrxHJ.pgp
Description: PGP signature