gnu.hurd.bug
  Home FAQ Contact Sign in
gnu.hurd.bug only
 
Advanced search
July 2008
motuwethfrsasuw
 123456 27
78910111213 28
14151617181920 29
21222324252627 30
28293031    31
2008
 Jan   Feb   Mar   Apr 
 May   Jun   Jul   Aug 
 Sep   Oct   Nov   Dec 
2008 2007 2006  
total
gnu.hurd.bug Profile…
RELATED GROUPS

POPULAR GROUPS

more...
 Up
  Re: New machine for shitbox         


Author: olafBuddenhagen
Date: Jul 4, 2008 17:16

Hi,

On Thu, Jul 03, 2008 at 10:56:17PM -0400, Barry deFreese wrote:
> I'm still a little concerned about the HD but I'm not sure how much
> trouble it would be to get it up on a new one. I'm up for
> suggestions, etc.

Shouldn't be a problem I think... Just copy the whole disk :-)
> I also have a nicer machine P4 (2.4Ghz or so I think) that I was
> thinking about replacing flubber with but I am wondering if that makes
> the most sense? Since flubber is now the wiki code and such, should
> it be taken out of the more "public" role? I'm thinking maybe using
> the gnubber hardware for flubber and set up a new gnubber might make
> more sense.

Well, I'm always feeling a bit strange about the fact that a public
machine prone to frequent crashes is also used for the wiki...

On the other hand, the wiki seems to need a fast machine, so using it
for the wiki exclusively would be a waste...

Not sure what the best approach is. Ideally, they should run in two
distinct VMs sharing the hardware :-)

-antrik-
no comments
  Re: The patch of glibc which allows the user to override the pfinet server         


Author: olafBuddenhagen
Date: Jul 4, 2008 15:21

Hi,

On Wed, Jul 02, 2008 at 08:42:43PM +0200, zhengda wrote:
> The new version of the patch is below.

Hm, what about dropping/replacing the "_PATH" bit, as discussed in the
other subthread?...
> I wonder if I can use __snprintf(). The code in the original glibc
> doesn't use it.

I'm not a glibc hacker; but I would be very surprised if it was a
problem...
> + __snprintf (sock_serv_env_name, 30, "SOCK_SERV_%%d_PATH", domain);

I'd say use "sizeof sock_serv_env_name", rather than hard-coding 30, for
better robustness...

-antrik-
no comments
  Re: GSoC: the plan for the project network virtualization         


Author: olafBuddenhagen
Date: Jul 4, 2008 14:51

Hi,

On Fri, Jul 04, 2008 at 12:24:56AM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:
> So if I'm right, the filter translator has to implement the RPC in
> device.defs to communicate with the client and it calls the RPC to
> communicate with the multiplexer.

Yes. The filter simply proxies the interface it is attached to.
> the filter translator actually doesn't have to be used with the
> multiplexer in every case. We use it only for enforcing policies.

Exactly.
> The only situation I think it can be used is that a user's
> multiplexer or a pfinet server opens a virtual network interface
> created by the root's multiplexer (so the user's multiplexer can
> access the external network). The filter translator doesn't need to
> sit on the user's multiplexer.

Well, depends on the use case. The user might want to enforce policies
on his own clients, too.
Show full article (2.61Kb)
no comments