>>I think the idea of patches for -current is very good for all 
>>that can't use SUP. It is not necessary to generate these patches
>>'by hand' from SUP'ed files and their backups - CVS already is able
>>to provide diffs between ANY releases! 
> 
>I am aware of this, but the NetBSD core team has indicated in the past
>that they won't do this, and I don't have an account on sun-lamp.

while it would be nice to do, it's hard to do 'consistently' -- i.e.
so that things don't get mucked up, esp. if there are commits
around the time that the diffs are created.

there's also the fact that with 'sup', only the latest copies need
to be kept around, not diffs from time immemorial...

>>I would like to see another mailing list (e.g. netbsd-current-patches) where
>>the daily or weekly diffs are mailed.
>>Another possibility would be a mailserver that can mail diffs between
>>any two NetBSD-current releases -- so one can update from 20.NOV to 2.DEC
>>with a single set of patches.
>>This would allow people that can't use SUP to upgrade easily and also should
>>be cheaper (less network traffic) than SUP.
> 
>I suspect that this would be a heavy load on sun-lamp, which is probably
>why they don't want to do it.

it would be an insane amount of load...

some interesting stats:
lamp has currently been up for 2 days, 9.5 hours.

in that time, it's averaged:
ahb0 irq11      6669248       32
ed0 irq10       8022038       38
(and for a while, it was averaging 50/s of each...)

we allow 3 anon-ftp users at a time, and 6 sup users at a time.

over the last 2 or so weeks, we've averaged 2.6k per second,
transmitted via ftp (i.e. 2.6k xferred for every second of that 2
weeks).  that doesn't include sup, non-anon ftp, or anything other
than standard anonymous ftp.

some typical output of "vmstat 1" (i just went over to the other
window, and selected some...):

 0 5 0 10340   416  574  62  11   1   0   1  0  0  0  0  201  886  93 28 30 42
 0 5 0 10492   264  529  50  10   1   0   1  0  0  0  0  195  879 101 33 22 45
 0 5 0 10496   268  622  67   2   1   0   3  0  0  0  0  191  854  86 33 23 44
 0 5 0 10536   236  632  67   1   1   0   3  0  0  0  0  185  900  76 32 33 35
 0 5 0 10468   356  583  67  13   1   0  14  0  0  0  0  198  683 105 20 29 51
 0 5 0 10428   392  551  62   1   1   0   1  0  0  0  0  155  678  54 23 28 49
 0 5 0 10624   212  549  50   8   3   0  14  0  0  0  0  246  929 152 31 28 41

way short on available RAM, way heavy usage...



adding new classes of services is not something that's going to happen
in the very near future...


chris

------------------------------------------------------------------------------