On 03-Jun-99 Wes Peters wrote:
http://www.nvidia.com/Marketing/Products/Pages.nsf/pages/NVIDIA_Drivers
Does anyone know how/if/when this will bleed over to FreeBSD? A
killer cheap OpenGL box might be kinda fun to have, and I'm already
in the market for another desktop. TNT cards have
On 03-Jun-99 Daniel O'Connor wrote:
On 03-Jun-99 Wes Peters wrote:
http://www.nvidia.com/Marketing/Products/Pages.nsf/pages/NVIDIA_Drivers
Does anyone know how/if/when this will bleed over to FreeBSD? A
killer cheap OpenGL box might be kinda fun to have, and I'm already
in the
Hello
Free downloads of source code of OpenVault here:
http://www.sgi.com/software/opensource/openvault/
Does anybody want to port it to FreeBSD?
--
Pavel Narozhniy
nic-hdl: PN395-RIPE
http://www.sumy.net
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers
Running 3.2 RELEASE, I have 2 fxp cards (one on the motherboard)
with two different addresses plugged into the same HP 2424M switch
(not broken into seperate VLANs yet). About once an hour, fxp0
seems to steal the arp for fxp1 for one second:
Jun 3 00:04:16 sgm1 /kernel: arp: 00:90:27:23:9e:ea
On 03-Jun-99 Chris Piazza wrote:
Just downloading the XFree86 source right now and I'm going to build it
overnight assuming it works. If not I'm sure it'll be fun (heh) to track
down.
Yeah.. Building X is a bit of a dog I've found..
---
Daniel O'Connor software and network engineer
for
On Wed, 2 Jun 1999, Wes Peters wrote:
Johan Jansson wrote:
NVIDIA has released OpenGL drivers for Linux/X, with source, for all
their chipsets. It also seems they intend these to be used as a base
for other platforms as well (BeOS for example). Here is from the faq:
This
On Thu, 3 Jun 1999, Daniel O'Connor wrote:
On 03-Jun-99 Chris Piazza wrote:
Just downloading the XFree86 source right now and I'm going to build it
overnight assuming it works. If not I'm sure it'll be fun (heh) to track
down.
Yeah.. Building X is a bit of a dog I've found..
Well
On 03-Jun-99 Alex Zepeda wrote:
On Thu, 3 Jun 1999, Daniel O'Connor wrote:
Yeah.. Building X is a bit of a dog I've found..
Well if you're interested in binaries the bzip2'd binary of XF86_SVGA
seems to be a little over 1 meg.
Hmm.. well I wouldn't mind a copy :)
Do they work OK?
---
On Thu, 3 Jun 1999, Daniel O'Connor wrote:
On 03-Jun-99 Alex Zepeda wrote:
On Thu, 3 Jun 1999, Daniel O'Connor wrote:
Yeah.. Building X is a bit of a dog I've found..
Well if you're interested in binaries the bzip2'd binary of XF86_SVGA
seems to be a little over 1 meg.
Hmm..
On Thu, 3 Jun 1999, Daniel O'Connor wrote:
Do they work OK?
MD5 (XF86_SVGA.bz2) = 2502eb1d8b48a052ffe831b147094fbd
-rwxr-xr-x 1 root wheel 1286643 Jun 2 23:27 XF86_SVGA.bz2
- alex
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the
On 03-Jun-99 Alex Zepeda wrote:
It seems to work, but I have no real way of testing any added
functionality as I've got a TNT based card (which a stock XFree86
supported already).
I've put a copy up at:
http://redwood203.marin.k12.ca.us/alex/XF86_SVGA.bz2
Thanks.
You could try
At 03/06/99, Daniel O'Connor wrote:
On 03-Jun-99 Alex Zepeda wrote:
It seems to work, but I have no real way of testing any added
functionality as I've got a TNT based card (which a stock XFree86
supported already).
I've put a copy up at:
On Thu, Jun 03, 1999 at 02:17:43AM -0400, Chuck Robey wrote:
On Wed, 2 Jun 1999, Wes Peters wrote:
Johan Jansson wrote:
NVIDIA has released OpenGL drivers for Linux/X, with source, for all
their chipsets. It also seems they intend these to be used as a base
for other platforms as well
Wes Peters writes:
And, as far as *word processors* go, troff, nroff, and ed pretty
much suck. Don't get me wrong, I completely agree they are useful
tools, as borne out by the number of books that have been typeset
over the years using troff. But a word processor they DO NOT make.
Clearly
Hi,
I have a Diamond Viper V770 (TNT2) and the patches appears to work 8)
It was not hard to build
cd /usr/ports/x11/XFree86
make
mid way of building the X makefiles I paused the build and apply
the NVidia's patches which are only for the nvidia software modules.
continue the build. Copy
On 03-Jun-99 Amancio Hasty wrote:
Will try later on to run xbench to see how fast is this card. my system
is a Pentium III 450 Mhz with 128mb of SDRAM and obscene amount
of memory compare to what I used to have to develop X Servers with
(8MB of memory) back in the 386bsd days.
Some info
On Thu, 3 Jun 1999, Pavel Narozhniy wrote:
Hello
Free downloads of source code of OpenVault here:
http://www.sgi.com/software/opensource/openvault/
Does anybody want to port it to FreeBSD?
--
Pavel Narozhniy
nic-hdl: PN395-RIPE
http://www.sumy.net
I guess there might be those
On Wed, 2 Jun 1999, Wes Peters wrote:
Johan Jansson wrote:
NVIDIA has released OpenGL drivers for Linux/X, with source, for all
their chipsets. It also seems they intend these to be used as a base
for other platforms as well (BeOS for example). Here is from the faq:
This
I'm getting tons of these in an IDE-only box. They started appearing
after I put in an IBM DTTA371010 to replace the old (and dying)
Quantum Fireball ST.
Trying to newfs a 9 GB file system on the IBM, newfs got wedged in
physst. At that point I had to reset (since I ran newfs on the serial
Dag-Erling Smorgrav d...@ifi.uio.no writes:
I'm getting tons of these in an IDE-only box. They started appearing
after I put in an IBM DTTA371010 to replace the old (and dying)
Quantum Fireball ST.
Following up on myself, the box just panicked (softdep_write_complete:
lock held).
DES
--
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
I'm getting tons of these in an IDE-only box. They started appearing
after I put in an IBM DTTA371010 to replace the old (and dying)
Quantum Fireball ST.
Following up on myself, the box just panicked
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
I'm getting tons of these in an IDE-only box. They started appearing
after I put in an IBM DTTA371010 to replace the old (and dying)
Quantum Fireball ST.
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
I'm getting tons of these in an IDE-only box. They started appearing
after I put in an IBM DTTA371010 to
It seems Dag-Erling Smorgrav wrote:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
Dag-Erling Smorgrav d...@ifi.uio.no writes:
I'm getting tons of these in an IDE-only box. They started appearing
On Jun 2, 11:40am, David E. Cross wrote:
} Subject: 3.2-STABLE, 11th panic
} Here is a backtrace from our latest. Does anyone have any ideas to try. Is
} there any way to loock at who has the other lock on the file? (Yes, I know
} it is the kernel who has it, but it is requested on behalf of a
The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
size. I am wondering why it is not set larger. The maxcontig value of FFS
is default to be 16, which means 16*8192 or 128K bytes (twice as big as
64K) . If we raise the value of MAXPHYS, we can put more data blocks of a
On Thu, Jun 03, 1999 at 10:40:10AM -0400, Zhihui Zhang wrote:
The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
size. I am wondering why it is not set larger.
Just a guess: maybe this has something to do with DMA address counters on ISA
cards being 16 bit? (ducks) Or is
Jos Backus wrote...
On Thu, Jun 03, 1999 at 10:40:10AM -0400, Zhihui Zhang wrote:
The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
size. I am wondering why it is not set larger.
Just a guess: maybe this has something to do with DMA address counters on ISA
cards
In v3.2 (and not in 3.1 or before) when we bring down a PTP interface (with
if_down(ifp)) we get a console messages
SIOCGIFADDR: Can't assign requested Address
What might this be?
Dennis
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the
On Thu, Jun 03, 1999 at 10:05:46AM -0600, Kenneth D. Merry wrote:
I think the 64K value may have been chosen because cards like the Adaptec
1542 can't handle more than that.
That's exactly the card I was thinking about (I used to own one). So I was
close :)
--
Jos Backus
Our home directory NFS server went down again today, same bat-panic.
This time it went down on .Maillock (usually it goes down on a netscape
cache file or .Xauthorit-c. Piecing some more together I modified my old
crash_patoot.c file (which didn't cause any problems), to the new and
improved
On 6/2/99 at 11:42 PM Wes Peters wrote:
Johan Jansson wrote:
NVIDIA has released OpenGL drivers for Linux/X, with source, for all
their chipsets. It also seems they intend these to be used as a base
for other platforms as well (BeOS for example). Here is from the
faq:
This distribution is
Just need to make a small amendment to the instructions for the previous
prgram. I am unable to cause a panic by running it on just one machine, I
need to have it run on 2 machines accessing the same file.
client1% ./crash_patoot cp1
client2% ./crash_patoot cp1
--
David Cross
Wes == Wes Peters w...@softweyr.com writes:
Wes If you mean lack of competition would make UNIX more homogenous and
Wes more viable to every Tom, Dick, and Jane that comes down the pike,
Wes I will agree with that. I just disagree that this is success. UNIX
Wes was never meant to be a word
As Zhihui Zhang wrote ...
The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
size. I am wondering why it is not set larger. The maxcontig value of FFS
is default to be 16, which means 16*8192 or 128K bytes (twice as big as
64K) . If we raise the value of MAXPHYS, we
As Jos Backus wrote ...
On Thu, Jun 03, 1999 at 10:40:10AM -0400, Zhihui Zhang wrote:
The value of MAXPHYS is chosen to be 64K for the maximum raw I/O transfer
size. I am wondering why it is not set larger.
Just a guess: maybe this has something to do with DMA address counters on ISA
of useless. It's like doing uphill testing of a fat guy on a bicycle
against a Lamborghini - you know the result beforehand.
Unfortunately, what you're probably not aware of is that the fat guy
also has a JATO unit strapped to the back of his bicycle. Don't make
assumptions. :-)
If
The patches applied almost cleanly to 4-CURRENT. Fixing the glitches was
easy. The PCCARD file was out of date with respect to CURRENT, so I
re-engineered it.
Great, thanks for doing this. I just talked to Tatsumi-san yesterday
about this work and would be very happy to see it go in if you'd
I'm not surprised. I think this is similar to the other known NFS panics.
I haven't had a chance to reproduce it yet ( may not be able to until
after USENIX ).
I have to say, though, that in order to fix these bugs I really do need
my commit privs back. If people want these
Silly me , I was wondering what happen to you . I vote that your commit
priviliges should not be taken away by the Dark Side of core and
should be re-instated.
Also wondering if this is perhaps a good time to split up FreeBSD
along commercial / professional lines -- we can leave the silly
core
Matthew Dillon wrote:
I have to say, though, that in order to fix these bugs I really do need
my commit privs back.
here here
-Matt
Matthew Dillon
:
:Silly me , I was wondering what happen to you . I vote that your commit
:priviliges should not be taken away by the Dark Side of core and
:should be re-instated.
:
:Also wondering if this is perhaps a good time to split up FreeBSD
:along commercial / professional lines -- we can leave the
Well, I found an ugly today. Nothing to do with FreeBSD, directly, just
one of those pitfalls that you run into that is juicy:
expr '1' : '\(.*\)'
returns 1, exit status of 0
expr '0' : '\(.*\)'
returns 0, exit status of 1
expr 0 + 0
returns 0, exit status of 1
Why is this an error
I really have gone over and over the issue of the Dark Side of core not
just with myself but with other hackers and I am afraid that there is
no easy solution on sight aside from having a commercial entity where
individuals are held accountable and when they step way out of line
they can be fire.
[
Some history: I'm not a core member (I gave that up responsibility years
ago), but I was one of the three weirdo's that started up FreeBSD back
when I had no life. My opinions are my own, and don't reflect the core
team. I don't know the exact reasons why the core team removed Matt's
commit
I have to say, though, that in order to fix these bugs I really do
need my commit privs back. If people want these things fixed,
complain to core. I have the time to fix the bugs with commit
privs, but I just don't have the time or inclination to fix them
without.
:Matthew Dillon writes:
:
: I have to say, though, that in order to fix these bugs I really do
: need my commit privs back. If people want these things fixed,
: complain to core. I have the time to fix the bugs with commit
: privs, but I just don't have the time or inclination
Perhaps we can cut through all the finger pointing and counter-finger
pointing here and just move on to the chase by asking one simple
question: Will you be at USENIX? That would be an excellent
opportunity to discuss it in person, where emotion and
facial-expression stripping isn't such a huge
I had the hunch that the problem I am dealing with related to the unlink
portion of NFS... So I have simplified the code down to this tiny snipet which
will reliably crash the system (I left it running by accident and it brought
my test machine down 3 times before I remembered to kill it :). This
I've been trying to understand some odd behavior in FreeBSD and I'm
wondering if anyone has an explanation for what's going on.
I'm using a FreeBSD box as a router in some tests. I cause congestion at
the router by sending more packets through it than the outgoing link can
handle (10Mbps).
What
:Perhaps we can cut through all the finger pointing and counter-finger
:pointing here and just move on to the chase by asking one simple
:question: Will you be at USENIX? That would be an excellent
:opportunity to discuss it in person, where emotion and
:facial-expression stripping isn't such a
Excellent. Let's assume then that all the core folk who are there,
plus any committers who have an interest in the issue (since core has
to listen to its developers' opinions too or we can no longer honestly
claim to represent their interests), will be getting together during
the week to discuss
:..
:behavior problem with Linux : I do an ftp download in a linux box and
:periodically I see a slight pause -- VA research snap back saying that
:the problem was due to the VM / Scheduler and that they couldn't
:fix it because Linus held tight control over that section of the kernel.
:
:I would
On Thu, Jun 03, 1999 at 07:30:20PM +0200, Wilko Bulte wrote:
20 bits. But older cards can do no more than 64 kB.
Indeed, 20 bits (=1 Mbyte) for the address, 16 bits for the transfer counter
(offset).
--
Jos Backus _/ _/_/_/ Reliability means never
:On Thu, Jun 03, 1999 at 07:30:20PM +0200, Wilko Bulte wrote:
: 20 bits. But older cards can do no more than 64 kB.
:
:Indeed, 20 bits (=1 Mbyte) for the address, 16 bits for the transfer counter
:(offset).
:
:--
:Jos Backus _/ _/_/_/ Reliability means never
MAXPHYS
MAXPHYS is ultimately a limitation on the size of the b_pages array in
the struct buf structure. The default is 128 KBytes. Device Drivers are
supposed to break up I/O's into manageable sections themselves.
Maybe when the buffer I/O / VFS subsystem is rewritten later
At 2:08 PM -0700 6/3/99, Jordan K. Hubbard wrote:
Excellent. Let's assume then that all the core folk who are there,
plus any committers who have an interest in the issue (since core
has to listen to its developers' opinions too or we can no longer
honestly claim to represent their
Leo Papandreou l...@talcom.net wrote:
On Tue, Jun 01, 1999 at 07:31:57PM -0600, Wes Peters wrote:
And, as far as *word processors* go, troff, nroff, and ed pretty
much suck.
...
Thats absolutely correct. They have no built-in diversion to cope
with writer's block. With MS-Word you can futz with
As Jordan Hubbard wrote ...
of useless. It's like doing uphill testing of a fat guy on a bicycle
against a Lamborghini - you know the result beforehand.
Unfortunately, what you're probably not aware of is that the fat guy
also has a JATO unit strapped to the back of his bicycle. Don't
As Matthew Dillon wrote ...
:..
:behavior problem with Linux : I do an ftp download in a linux box and
:periodically I see a slight pause -- VA research snap back saying that
:the problem was due to the VM / Scheduler and that they couldn't
:fix it because Linus held tight control over that
I second this. Even if it's a bit painful, somebody who has been working
diligently at this needs to be able to be make their work usable quickly.
I would guess that not too many things hinder progress, or quash desire
more than fixes to problems languishing.
There has to be some middle ground
I have found a small problem in nameser.h in the ns_rr structure.
This structure has a member named class that causes a compilation
problem if you include nameser.h into C++. I suspect that I may be
the only person to ever hit up against this (:. Any comments before
I summit a bug report?
--
On 03-Jun-99 Jaye Mathisen wrote:
I second this. Even if it's a bit painful, somebody who has been working
diligently at this needs to be able to be make their work usable quickly.
I would guess that not too many things hinder progress, or quash desire
more than fixes to problems
Hi,
I spent most of the day recompiling X and what not.
All the patches applied cleanly, there are some rejects with MESA,
but I think that has to do with tags and comments at the beginning of
files.
Everything compiled fine, and the module loads, now I just need to
get my hands on quake2 :)
On Thu, Jun 03, 1999 at 06:55:19PM -0400, Larry Baird wrote:
I have found a small problem in nameser.h in the ns_rr structure.
This structure has a member named class that causes a compilation
problem if you include nameser.h into C++. I suspect that I may be
the only person to ever hit up
It is a nice idea and I have proposed it in the past however most likely
such organization will devolve to the current status-quo with core;however,
if the oversight committee is composed of individuals from companies
using FreeBSD it may actually work for committee should have a vested
interest
+[ Matthew Dillon ]-
|
| addressed years ago were left to rot. All that is needed is a reality
| check.
You want to get Rowdy Roddy Piper on to the core team? d8)
--
Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew
On 03-Jun-99 Amancio Hasty wrote:
It is a nice idea and I have proposed it in the past however most likely
such organization will devolve to the current status-quo with core;however,
if the oversight committee is composed of individuals from companies
using FreeBSD it may actually work for
[I rearranged the things since these folks can't be bothered to comment
at the bottom]
Vince Vielhaber wrote:
Not knowing the FULL story from both sides, I feel it'd be inappropriate
if I were to comment on it. However knowing Matt's coding abilities,
having seen the eruption here a few
On 04-Jun-99 Chuck Robey wrote:
[I rearranged the things since these folks can't be bothered to comment
at the bottom]
Vince Vielhaber wrote:
Not knowing the FULL story from both sides, I feel it'd be inappropriate
if I were to comment on it. However knowing Matt's coding abilities,
Nate Williams said:
Case in point, John Dyson's comments explanation to the mailing list for
many of his design decisions explained to even an uninformed person like
me that some of the changes you've made were penalizing FreeBSD, not
helping it in some cases.
BTW, my frustration was due
Amancio Hasty said:
Silly me , I was wondering what happen to you . I vote that your commit
priviliges should not be taken away by the Dark Side of core and
should be re-instated.
It wasn't the dark side of core, it was the panic'ed and worried
part of core that was seeing things happening
Chuck Robey wrote:
[I rearranged the things since these folks can't be bothered to comment
at the bottom]
Vince Vielhaber wrote:
Not knowing the FULL story from both sides, I feel it'd be inappropriate
if I were to comment on it. However knowing Matt's coding abilities,
having
[.]
Someone who has this much spare energy for tracking down ancient
problems in technologically-uninteresting code should be getting
some reward for it. In a project like this, it seems to me that
the standard reward is a certain degree of respect, and I think
Matt's recent work has
:The learning curve would have been much less painful if questions
:would have been asked and/or the answers weren't ignored. (There were
:cases of my answers and suggestions not even being challenged, but
:were rejected out of hand.) After a while, the *only* way to be
:heard was to become
It wasn't the dark side of core, it was the panic'ed and worried
part of core that was seeing things happening without careful review.
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
The reaction was (IMHO)
On Thu, 3 Jun 1999, Vince Vielhaber wrote:
Just realize, IF you're loud enough, and succeed, the programmers will
all desert you, and you'll have a nice place to argue, but no more
software. Core here does an excellent job, with all the problems they
face, most committers will agree to
On Fri, 4 Jun 1999, Brian Somers wrote:
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
The reaction was (IMHO) the right thing to do.
I think where the problem lied is very relevent.
If the problems are
It wasn't the dark side of core, it was the panic'ed and worried
part of core that was seeing things happening without careful review.
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
The reaction was
On Fri, 4 Jun 1999, Brian Somers wrote:
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
The reaction was (IMHO) the right thing to do.
I think where the problem lied is very relevent.
If the
: It wasn't the dark side of core, it was the panic'ed and worried
: part of core that was seeing things happening without careful review.
:
:The system was becoming unstable due to Matts changes. Whether the
:instabilities were in Matts code or somewhere else is irrelevent.
:The reaction was
The biggest mistake that programmers working on a large project make is
when they do *not* rewrite portions of the code that need to be rewritten.
For a case in point you need look no further then the buffer cache and
device I/O code. It's so messed up that even I could only
On 04-Jun-99 Chuck Robey wrote:
On Thu, 3 Jun 1999, Vince Vielhaber wrote:
Just realize, IF you're loud enough, and succeed, the programmers will
all desert you, and you'll have a nice place to argue, but no more
software. Core here does an excellent job, with all the problems they
: I sure do not intend those hacks to remain in there forever! The I/O
: subsystem is a holy mess. The only reason I'm not working on it right
now
: is because I think Poul is intending to work on it later in the year.
:
:
:Now I'm getting a bit torqued at this. Yes, there are
On Thu, Jun 03, 1999 at 03:49:49AM -0700, Jordan Hubbard wrote:
of useless. It's like doing uphill testing of a fat guy on a bicycle
against a Lamborghini - you know the result beforehand.
Unfortunately, what you're probably not aware of is that the fat guy
also has a JATO unit strapped
:Now I'm getting a bit torqued at this. Yes, there are problems here,
:but rather than keeping it to yourself what the problems are, how about
:being constructive in suggesting ways we can all improve things.
A number of conversations and threads have already taken place on the
Hi Matt, -core, et al,
Speaking as a long time user of FreeBSD I am continually impressed by the
quality of _all_ the people involved, their work and their dedication.
I don't pretend to know the burdens of -core, but I do feel strongly that
this is the wrong medium for this discussion.
As has
Andrew Kenneth Milton wrote:
+[ Matthew Dillon ]-
|
| addressed years ago were left to rot. All that is needed is a reality
| check.
You want to get Rowdy Roddy Piper on to the core team? d8)
No. Jessie the Hack Ventura. Of
:I had the hunch that the problem I am dealing with related to the unlink
:portion of NFS... So I have simplified the code down to this tiny snipet which
:will reliably crash the system (I left it running by accident and it brought
:my test machine down 3 times before I remembered to kill it :).
John S. Dyson wrote:
On Fri, 4 Jun 1999, Brian Somers wrote:
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
The reaction was (IMHO) the right thing to do.
I think where the problem lied is
Brian Somers wrote:
It wasn't the dark side of core, it was the panic'ed and worried
part of core that was seeing things happening without careful review.
The system was becoming unstable due to Matts changes. Whether the
instabilities were in Matts code or somewhere else is irrelevent.
And this nonsense in another email about things being untested is also
complete bull. I had a machine dedicated to running test kernels 24 hours
a day. I still do.
Testing on local machines isn't generally sufficient, due to the need for
running diverse applications in various
Some sort of arrangement/understanding/procedure/whatever would need to be
worked out to make sure that everybody involved understands everybody's
angle so that we don't repeat it all over again. Maybe some of the
groundwork can be done at usenix next week, but not all everybody will be
93 matches
Mail list logo
