Re: Xfree86 and console server (and VT_ACTIVATE, etc)

2003-07-18 Thread Gaël Le Mignot
Hello Robert! Fri, 18 Jul 2003 01:36:51 +, you wrote: > We just spoke in IRC about a possible solution of the Xfree86 problem with > the console server. Just to remind you that it's not the console _server_ which conflicts with X, but the console _client_ using vga or a keyboard driver

creation time as Hurd extension?

2003-07-18 Thread Marcus Brinkmann
Hi, what about having the creation time of a file as an Hurd extension, which is maintained across copies, like the author? Thanks, Marcus ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd

Re: creation time as Hurd extension?

2003-07-18 Thread Neal H. Walfield
> what about having the creation time of a file as an Hurd extension, which is > maintained across copies, like the author? It seems far more useful than the author bits. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/

Re: creation time as Hurd extension?

2003-07-18 Thread Farid Hajji
> > what about having the creation time of a file as an Hurd extension, which is > > maintained across copies, like the author? > > It seems far more useful than the author bits. Why restricting meta data to a fixed set of attributes? I've read about a (user-)extensible meta-data scheme some year

Re: creation time as Hurd extension?

2003-07-18 Thread Ludovic Courtès
Hi, On Fri, Jul 18, 2003 at 12:29:08PM +0200, Farid Hajji wrote: > Why restricting meta data to a fixed set of attributes? > I've read about a (user-)extensible meta-data scheme some > years ago in a paper. Unfortunately, I didn't copy that or > its reference (arghhh) back then, and I can't find i

Re: creation time as Hurd extension?

2003-07-18 Thread Alfred M. Szmidt
what about having the creation time of a file as an Hurd extension, which is maintained across copies, like the author? Why? Can't really see the point in preserving the creation time since I seldom look at it, the modification time is far more interesting. But then, I still don't see the j

Re: creation time as Hurd extension?

2003-07-18 Thread Farid Hajji
> > Why restricting meta data to a fixed set of attributes? > > I've read about a (user-)extensible meta-data scheme some > > years ago in a paper. Unfortunately, I didn't copy that or > > its reference (arghhh) back then, and I can't find it now :( > > A particular filesystem implementation can h

Re: creation time as Hurd extension?

2003-07-18 Thread Peter 'p2' De Schrijver
On Fri, Jul 18, 2003 at 04:56:15AM -0500, Marcus Brinkmann wrote: > Hi, > > what about having the creation time of a file as an Hurd extension, which is > maintained across copies, like the author? > In that case, why not add an extended attribute scheme ? So everyone can add whatever metadata h

Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)

2003-07-18 Thread Robert Millan
[ I'm changing CC to [EMAIL PROTECTED], so it gets archived too ] Hi Gael, On Fri, Jul 18, 2003 at 11:41:10AM +0200, Gaël Le Mignot wrote: > Hello Robert! > > Just to remind you that it's not the console _server_ which conflicts > with X, but the console _client_ using vga or a keyboard drive

[PATCH (long)] hello.c follow-up

2003-07-18 Thread PUYDT Julien
Hi, this long patch is supposed to make hello.c correct and "robust"... it includes the previously posted patch. Notice that in storeio, trivfs_S_io_seek uses open_seek, which doesn't check the offset sanity either; I'll take a look at it when I'll have understood things a little more. Here is a

Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)

2003-07-18 Thread Gaël Le Mignot
>> I don't think the correct solution would be for X and the console to >> directly speak to each other like X saying to the console client "stop >> please", but rather a per-ressource (VGA, keyboard, mouse) way to say >> "I want exclusive access to this ressource". The console client itself

Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)

2003-07-18 Thread Robert Millan
On Fri, Jul 18, 2003 at 04:24:17PM +0200, Gaël Le Mignot wrote: > > My idea was to implement the driver in userspace and force X to use it. > > Following this dessign, we could end up seeing X running as non-root. > > That would require a huge amount of work I fear, especially if we want > to su

Bug#185450: Xfree86 and console server (and VT_ACTIVATE, etc)

2003-07-18 Thread Daniel Wagner
Robert Millan <[EMAIL PROTECTED]> writes: > At this point, I think it'd be better to use Oskit instead. To the people > who have played with Oskit already, do you think it's viable to use it > as a backend for userspace drivers? Well, Oskit provides lot's of drivers but also forces you to emulate

Re: creation time as Hurd extension?

2003-07-18 Thread Marco Gerards
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > what about having the creation time of a file as an Hurd extension, which is > maintained across copies, like the author? That would be cool for fatfs, because that makes it possible to use the stored creation time fatfs already has. And personally

Patch for ncursesw (bug-fixes, other resolutions)

2003-07-18 Thread Marco Gerards
Hi, This patch adds support for non-80x25 resolutions to the ncursesw driver. It also adds a generic interface to tell the display driver which resolution to use. If that resolution is not available it uses the next best resolution. I made some changes to ncursesw so it uses a "pad", from the cur

Re: creation time as Hurd extension?

2003-07-18 Thread Marco Gerards
Farid Hajji <[EMAIL PROTECTED]> writes: > > > what about having the creation time of a file as an Hurd extension, which is > > > maintained across copies, like the author? > > > > It seems far more useful than the author bits. > > Why restricting meta data to a fixed set of attributes? > I've re

Bug#190732: [PATCH] hurd/libdiskfs/dir-renamed.c

2003-07-18 Thread Marco Gerards
Ognyan Kulev <[EMAIL PROTECTED]> writes: > Please run exactly the following commands and tell us what's happening > after _the last one_. > > $ mkdir d > $ cd d > $ mkdir x > $ mv x y > $ mv y x I've tested this both with and without your patch. Nothing (weird) happened. -- Marco _