--- Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2003 at 03:13:59AM -0700, James Michael DuPont wrote:
> > > Yes, it is very consistent and abstract. But, it is also
> incredible
> > > slow
> > > and resource heavy, and enforces a lot of policy on the user.
> This
> > > slows
>
=== BUG #6034: FULL BUG SNAPSHOT ===
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6034&group_id=30
Submitted by: ogi Project: The GNU Hurd
Submitted on: Sat 10/18/03 at 16:44
Category: None Severity:
On Sat, Oct 18, 2003 at 03:13:59AM -0700, James Michael DuPont wrote:
> > Yes, it is very consistent and abstract. But, it is also incredible
> > slow
> > and resource heavy, and enforces a lot of policy on the user. This
> > slows
> > down the fast path, and introduces some interesting DoS attac
Patch #2104 has been updated.
Project:
Category: None
Status: Open
Summary: rpctrace: Don't assert that local port names are valid
Follow-Ups:
Date: Sat 10/18/03 at 14:17
By: ogi
Comment:
Bug report can be found at
http://mail.gnu.org/archive/html/bug-hurd/2002-11/msg00222.html
I don't kn
Patch #2104 has been updated.
Project:
Category: None
Status: Open
Summary: rpctrace: Don't assert that local port names are valid
---
For more info, visit:
http://savannah.gnu.org/patch/?func=detailpatch&patch_id=2104&group_id=30
__
James Michael DuPont <[EMAIL PROTECTED]> writes:
> > And the Hurd is not difficult to compile either :)
>
> No, it was quite easy once I cleaned out the mach code, I dont see why
> the entry costs for compiling should be so high? Cannot mach/hurd run
> in user mode and be implemented as a set of
--- Marcus Brinkmann <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2003 at 01:52:14PM -0700, James Michael DuPont wrote:
> > > I was a bit surprised at your assertions about Mach and Hurd,
> too.
> >
> > I think that mach has a very interesting and clean api for IPC. The
> > usage of ports every
Quoting Andrej Czapszys <[EMAIL PROTECTED]>:
> Hello. I'm relatively new to the Hurd. After building from CVS, I'm
> rather impressed with the current state. That being said, I was mildly
> surprised at the lack of these features:
> * devfs
You may want to look at udev[0] instead of devfs, as
