Any interest in unused hardware being made available for remote developer use?

I have a Compaq ML370 Proliant server here which is likely to remain unused for the foreseeable future. Some of its key specs are: - Dual 800MHz PIII/133MHz/256MB CPU - 1.25GB ECC Memory - 2 x 9G 10k SCSI-UW2 - 1 x 18G 10k SCSI-UW2 - 2 x Intel EtherExpress PRO/100 Ethernet I've been

Re: fs/udf: vm pages overlap while reading large dir

on 04/02/2008 17:55 Scott Long said the following: Andriy Gapon wrote: [snip] After some code reading and run-time debugging, here are some facts about udf directory reading: 1. bread-ing is done via device vnode (as opposed to directory vnodes), as a consequence udf_strategy is not involved

Re: fs/udf: vm pages overlap while reading large dir [patch]

on 05/02/2008 20:16 Pav Lucistnik said the following: Andriy Gapon píše v út 05. 02. 2008 v 16:40 +0200: Yay, and can you fix the sequential read performance while you're at it? Kthx! this was almost trivial :-) See the attached patch, first hunk is just for consistency. The code was

Re: fs/udf: vm pages overlap while reading large dir [patch]

on 05/02/2008 22:43 Scott Long said the following: Andriy Gapon wrote: But there is another issue that I also mentioned in the email about directory reading. It is UDF_INVALID_BMAP case of udf_bmap_internal, i.e. the case when file data is embedded into a file entry. This is a special case

C99 Posix

Hi hackers, is there any other source of information about the status of Posix and C99 conformity in FreeBSD than the two (outdated) pages below? http://www.freebsd.org/projects/c99/index.html http://people.freebsd.org/~schweikh/posix-utilities.html I would like to do something in this field,

Re: fs/udf: vm pages overlap while reading large dir [patch]

on 06/02/2008 18:34 Andriy Gapon said the following: Actually the patch is not entirely correct. max_size returned from udf_bmap_internal should be used to calculate number of continuous sectors for read-ahead (as opposed to file size in the patch). Attached is an updated patch. The most

Interesting development discipline model - PostgreSQL

I've just read an interesting post about a new model accepted for developing PostgreSQL, and I'm finding parallels in how their release 8.3 was delayed similar to our 7.0. http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php I also see some possible reasons why it couldn't work