[bug #20656] Init machinery: ``kill -HUP 1''

URL: Summary: Init machinery: ``kill -HUP 1'' Project: The GNU Hurd Submitted by: tschwinge Submitted on: Thursday 08/02/07 at 01:20 Category: Hurd Severity: 1 - Wish

git for Debian GNU/Hurd (was: Setting ones's priorities)

Hello! On Wed, Apr 11, 2007 at 09:21:21AM -0700, Thomas Bushnell BSG wrote: > No, you should spend your time on the Hurd, because there are fewer > people that can do that work. Keep track of programs that have PATH_MAX > or access(NULL) problems, and when people say, "how can I help", we can > p

Re: Confusion about where to go in Hurd

Hi, [EMAIL PROTECTED], le Wed 01 Aug 2007 18:30:20 +0200, a écrit : > > The main reason parts of Hurd are slow and such is that code in > > the translators (such as the pager code in ext2fs) haven't been > > optimized. > > Well, that is only partially true: Nobody has ever really profiled it; > b

Re: Yet another updated entropy patch

Hi, On Mon, Jul 23, 2007 at 08:39:55AM +0200, Marcus Brinkmann wrote: > It could be different if we had a good single entropy source in every > computer. Unfortunately, entropy devices are a rarity. That's not true. Intel introduced hardware random number generators in their chipsets like ten y

Re: Confusion about where to go in Hurd

Hi, On Thu, Jul 26, 2007 at 01:33:12PM +0200, Anders Breindahl wrote: > I recall something about fork()s being expensive on the Hurd/Mach, and > that someone ran tests that showed 500forks per second versus a > somewhat larger figure on Linux. The "somewhat larger figure" was actually something

Re: Defualt socket server overriding

Hi, On Mon, Jul 23, 2007 at 09:05:14PM +0800, Wei Shen wrote: > I made a try to implement a basic way of socket servers (pfinet and > pflocal) overriding, as described below. Great :-) > (1) Should we disable the overrding mechanism for SUID or SGID > processes ( e.g. substituting *__secure_ge

Re: Channel sessions

Hi, On Thu, Jul 26, 2007 at 09:24:32PM +0200, Carl Fredrik Hammar wrote: > My solution is simple enough; they should all be implemented in > channels (as opposed to being implemented in channelio.) This will be > more general and give the user more control. The downside is that it > will be a b

Re: Maintenance of the Hurd parts in glibc (was: about GNU Hurd)

Hi, On Thu, Jul 26, 2007 at 12:59:39PM +0200, Marcus Brinkmann wrote: > It's delusional to think that the problems of the Hurd are related to > a choice of the version control system. Well, part of the problems are. We have to start somewhere. And fixing the VCS issue seems the most trivial, so

Re: Confusion about where to go in Hurd

Hi, On Wed, Jul 25, 2007 at 09:17:49PM -0400, Michael Casadevall wrote: > Hurdng - the project of porting hurd translators to another > microkernel beside mach such as L4. That is not fully correct. The original port to L4 was simply named Hurd/L4 -- which is exactly what it was: A port of the e

Re: Maintenance of the Hurd parts in glibc

On Mon, 2007-07-23 at 02:05 +0200, Thomas Schwinge wrote: > > Getting non-invasive (read: bug-fixing and the like) changes into the > Hurd's code base is not an issue, as I can do (and actually do) all that. > For getting invasive (read: interface changes and the like) changes into > the Hurd we'd

Re: fifo, bogus-fifo, new-fifo

Hello! On Sun, Jul 29, 2007 at 07:40:38PM +0200, Thomas Schwinge wrote: > What's the story behind `[Hurd]/trans/{,bogus-,new-}fifo.c'? We're > currently using `fifo.c', however `new-fifo.c' is also being built and > installed and can be used, which I did just today (read below). Where is > `bogu

Re: weak _pthread_mutex_lock()

Hi, Thomas Schwinge, le Fri 27 Jul 2007 23:49:29 +0200, a écrit : > As Neal told me that these inline functions are just an optimization > which he copied (when writing libpthread) from Mark Kettenis' code, > perhaps just removing them would already help? I'd recommend that, yes. Having these opt

Re: Maintenance of the Hurd

I always hoped that the project's seniors, Thomas Bushnell and Roland McGrath, would get more active again and make some decision about existing interface-changing (category (c)) issues, but this hasn't really happened yet. It is good to have their input, when they give it. But if