Re: Debian GNU/Hurd installation wizard and live cd
On Thursday 22 July 2010 20:27:41 Michael Banck wrote: > Maybe try assigning more RAM to KVM if you assigned much less than > 512MB. Just a wild guess. That might be a good hit → -m megs set virtual RAM size to megs MB [default=128] 128MiB might be a bit too little… :) (I don’t use kvm – I don’t know if my CPU supports it: no svm flag (amd64)) … I tried it now, but installation still stalls. Seems to need a bit more testing from my side. Best wishes, Arne -- Ich hab' nichts zu verbergen – hab ich gedacht: - http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen signature.asc Description: This is a digitally signed message part.
Re: Debian GNU/Hurd installation wizard and live cd
Arne Babenhauserheide, le Fri 23 Jul 2010 17:57:46 +0200, a écrit : > 128MiB might be a bit too little… :) Yes. At least 256MiB is a must. > (I don’t use kvm – I don’t know if my CPU supports it: no svm flag (amd64)) no svm on amd64 -> no kvm (vmx on intel). Samuel
Re: [PATCH] Bump HURD_INTERFACE_VERSION
Hi, On Mon, Jul 19, 2010 at 10:57:48AM +0200, Thomas Schwinge wrote: > On Fri, Jul 16, 2010 at 12:19:21PM +0200, Emilio Pozuelo Monfort wrote: > > * hurd/version.h (HURD_INTERFACE_VERSION): Bumped for the > > recently added RPCs. > > I don't see a need for doing this unless you conditionalize anything on > the increased version number. The only example that I can find where > this is done, is [glibc]/sysdeps/mach/hurd/configure.in for the ``new > Hurd RPC interfaces supporting 64-bit file sizes'' (ChangeLog.13). > > Perhaps we should get rid of this one-dimensional scalar, and only use > real functionality probes instead? Indeed, that's what I suggested last time this topic came up. A linear interface version number doesn't make much sense with a non-linear development/deployment model... Of course checking individual interface changes requires coming up with a good autoconf test for the new interfaces. I hope Emilio already started an extra thread on this... Also, what to do with the existing interface version number? Update it nevertheless for any new interfaces? Leave it there but don't ever update it? Drop it alltogether? -antrik-
Re: Usable translators: nsmux details
Hi, On Tue, Jul 13, 2010 at 12:05:51PM +0300, Sergiu Ivanov wrote: > On Tue, Jul 13, 2010 at 10:31:26AM +0200, Arne Babenhauserheide wrote: > > And that means: nothing missing, nsmux works as it should? > > Apparently, nsmux is capable of performing a basic subset of > functionality it was designed to be capable of doing. I can remember > myself trying a number (not a considerable one, though) of tests that > proved that nsmux starts translators nicely, but I never tried to see > whether anonymous translators went away on their own. > > You'd better wait until antrik has his final answer to this question, Not sure what question you mean... -antrik-
Re: Usable translators: nsmux details
Hi, On Mon, Jul 12, 2010 at 12:58:53PM +0300, Sergiu Ivanov wrote: > Frankly speaking, my memory holds no remembering of discussions about > how to shut down anonymous translators. In the current implementation > an nsmux client obtains a port to an nsmux node which redirects all > requests to the corresponding anonymous translator. Perhaps, nsmux > could use a node cache and discard those translators which are pointed > to by nodes which are about to be evicted from the cache. > > I don't think making nsmux capable of shutting down translators is a > hard task in itself: the central problem is that I am not sure we have > agreed on how to implement it best. My memory is also rather dim on that... At some point we discussed the possibility of shutting down the anonymous translators immediately, instead of waiting for a timeout, if we *know* there are no further outstanding client ports -- meaning the translator won't ever be used anymore. But I don't remember how and in what situation we would know that... This is just an optimization though. (Albeit a rather important one, in case of translators that don't have an automatic timeout...) Some of the other outstanding TODO items however were much more fundamental IIRC?... -antrik-
