On Tue, 12 Apr 2005, Kedar Sovani wrote:
>I was wondering if working on git, is in anyway, in violation of the
>Bitkeeper license, which states that you cannot work on any other SCM
>(SCM-like?) tool for "x" amount of time after using Bitkeeper ?
Technically, yes, it is. However, as BitMover has
On Tue, 12 Apr 2005, Christoph Hellwig wrote:
>On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
>> However, when the copyright holder says "No, please don't add that
>> code",
>> and gives *GOOD* reasons why, you should respect that decision.
>
>You didn't not give a single good
On Tue, 12 Apr 2005, Christoph Hellwig wrote:
On Tue, Apr 12, 2005 at 10:30:19AM -0500, Kilau, Scott wrote:
However, when the copyright holder says No, please don't add that
code,
and gives *GOOD* reasons why, you should respect that decision.
You didn't not give a single good reason. Only
On Tue, 12 Apr 2005, Kedar Sovani wrote:
I was wondering if working on git, is in anyway, in violation of the
Bitkeeper license, which states that you cannot work on any other SCM
(SCM-like?) tool for x amount of time after using Bitkeeper ?
Technically, yes, it is. However, as BitMover has
On Tue, 29 May 2001, Pavel Roskin wrote:
>> You can a few nice tricks with it like plug in two PS/2 keyboards. I
>> have this for my home setup. The only thing is make sure you don't
>> have both keyboards plugged in when you turn your PC on. I found BIOS
>> get confused by two PS/2 keyboards. As
On Tue, 29 May 2001, Pavel Roskin wrote:
You can a few nice tricks with it like plug in two PS/2 keyboards. I
have this for my home setup. The only thing is make sure you don't
have both keyboards plugged in when you turn your PC on. I found BIOS
get confused by two PS/2 keyboards. As you can
On Sat, 26 May 2001, Jan Sembera wrote:
>i've got a problem compiling drivers/media/video/buz.c as module. When
>i'm trying to compile, i get couple of errors:
...
Actually, it broke at 2.4.3. Go look at the first change to buz.c from
that patch.
--Ricky
PS: I really hate it when people
On Sat, 26 May 2001, Jan Sembera wrote:
i've got a problem compiling drivers/media/video/buz.c as module. When
i'm trying to compile, i get couple of errors:
...
Actually, it broke at 2.4.3. Go look at the first change to buz.c from
that patch.
--Ricky
PS: I really hate it when people break
On Mon, 5 Feb 2001, Ricky Beam wrote:
>Interesting... I just checked my machine (2.4.1-SMP) to see it only saw
>64MB when it has 256MB.
...
>Nothing at all has changed in either the BIOS setup, compiler, etc. All I
>did was reboot (and not pay it any attention.) The configuration w
On Mon, 5 Feb 2001, Alan Olsen wrote:
>The capture features are undocumented and unsupported (to my knowledge).
(your knowledge is incorrect.)
>As far as I have heard, the Rainbow Runner card is not supported in Linux
>and Matrox has no plans of doing it.
Unsupported by whom? Matrox? That
On Wed, 31 Jan 2001, Dunlap, Randy wrote:
...
Interesting... I just checked my machine (2.4.1-SMP) to see it only saw
64MB when it has 256MB.
>From 2.4.0-test5:
Linux version 2.4.0-test5-SMP (root@chickenboo) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #12 SMP Thu Aug 10
On Wed, 31 Jan 2001, Dunlap, Randy wrote:
...
Interesting... I just checked my machine (2.4.1-SMP) to see it only saw
64MB when it has 256MB.
From 2.4.0-test5:
Linux version 2.4.0-test5-SMP (root@chickenboo) (gcc version egcs-2.91.66
19990314/Linux (egcs-1.1.2 release)) #12 SMP Thu Aug 10
On Mon, 5 Feb 2001, Alan Olsen wrote:
The capture features are undocumented and unsupported (to my knowledge).
(your knowledge is incorrect.)
As far as I have heard, the Rainbow Runner card is not supported in Linux
and Matrox has no plans of doing it.
Unsupported by whom? Matrox? That would
On Mon, 5 Feb 2001, Ricky Beam wrote:
Interesting... I just checked my machine (2.4.1-SMP) to see it only saw
64MB when it has 256MB.
...
Nothing at all has changed in either the BIOS setup, compiler, etc. All I
did was reboot (and not pay it any attention.) The configuration was the
same
On Fri, 3 Nov 2000, bert hubert wrote:
>> Thanks! That patch did the trick - our machine is now running lovely.
>
>Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
>support shops try and fail to deliver 4 hour response times - this makes me
>feel warm inside :-)
To be
On Fri, 3 Nov 2000, bert hubert wrote:
Thanks! That patch did the trick - our machine is now running lovely.
Your very rare problem was solved in 3 hours and 50 minutes. Most commercial
support shops try and fail to deliver 4 hour response times - this makes me
feel warm inside :-)
To be fair,
On Thu, 26 Oct 2000, Igmar Palsenberg wrote:
>> Per chance are you running the name service caching daemon (nscd)? I'd
>> also guess you aren't disabling fsync() for your sysylog files (it's part
>> of the syslog.conf format) -- this is a conciderable drain on syslogd.
>
>Agree. It is there for
On Thu, 26 Oct 2000, Igmar Palsenberg wrote:
Per chance are you running the name service caching daemon (nscd)? I'd
also guess you aren't disabling fsync() for your sysylog files (it's part
of the syslog.conf format) -- this is a conciderable drain on syslogd.
Agree. It is there for a reason
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Once the name resolution times out, you might expect things to become
>unstuck. But they don't.
Negative. Things have been queued. The deadlock will only go away if the
very next message processed is the named local message. And then it would
have
On 23 Oct 2000, Patrick J. LoPresti wrote:
>So I have the glibc maintainer (and others) saying that syslog
>messages should never be dropped, and you saying that named should be
>dropping its syslog messages.
No, I didn't say they "should" be dropped but merely that dropping them
would fix your
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Turning down the DNS timeout would affect *all* name resolution on the
>system, right? That is not acceptable.
You should be able to set it on a per-process basis (via an ENV var.)
>As I said, I already have a workaround, which is to have named log
On 23 Oct 2000, Patrick J. LoPresti wrote:
>Ulrich Drepper <[EMAIL PROTECTED]> writes:
>> If anything has to be changed it's (as suggested) the configuration
>> or even the implementation of syslogd. Make it robust.
>
>OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
>If I
On 23 Oct 2000, Patrick J. LoPresti wrote:
Ulrich Drepper [EMAIL PROTECTED] writes:
If anything has to be changed it's (as suggested) the configuration
or even the implementation of syslogd. Make it robust.
OK, but my current syslogd only listens to /dev/log as a SOCK_DGRAM.
If I wanted
On 23 Oct 2000, Patrick J. LoPresti wrote:
Turning down the DNS timeout would affect *all* name resolution on the
system, right? That is not acceptable.
You should be able to set it on a per-process basis (via an ENV var.)
As I said, I already have a workaround, which is to have named log to
a
On 23 Oct 2000, Patrick J. LoPresti wrote:
So I have the glibc maintainer (and others) saying that syslog
messages should never be dropped, and you saying that named should be
dropping its syslog messages.
No, I didn't say they "should" be dropped but merely that dropping them
would fix your
On 23 Oct 2000, Patrick J. LoPresti wrote:
Once the name resolution times out, you might expect things to become
unstuck. But they don't.
Negative. Things have been queued. The deadlock will only go away if the
very next message processed is the named local message. And then it would
have to
On Thu, 19 Oct 2000, Richard B. Johnson wrote:
>Cary, NC. can't be very large. There are, probably, three persons in
Why "can't" it? Just because it's in NC and not CA? Even CA has it's
sparse areas (ok, maybe that's "a sparse area" now-a-days.)
FYI, most of Cary is a townhouse/strip mall
On Thu, 19 Oct 2000, Richard B. Johnson wrote:
Cary, NC. can't be very large. There are, probably, three persons in
Why "can't" it? Just because it's in NC and not CA? Even CA has it's
sparse areas (ok, maybe that's "a sparse area" now-a-days.)
FYI, most of Cary is a townhouse/strip mall
On Mon, 16 Oct 2000, Alan Cox wrote:
>> Umm, doesn't cdrecord know how to address IDE devices directly?
>
>IDE cd burners talk ATAPI. ATAPI is just a scsi variant. SCSI won the battle
>at the protocol level
...
Yeah yeah yeah. What I meant was "you don't have to use ide-scsi." However,
after
On Mon, 16 Oct 2000, Alan Cox wrote:
>> is in cdrecord itself, since I have seen that if the FIFO ever hits 0%
>> during CD burning, cdrecord has a tendency to bomb. =20
>
>If you empty the fifo and the drive fifo you burn a coaster. Thats a feature
>of CD burning and one reason I use 640Mb
On Mon, 16 Oct 2000, Alan Cox wrote:
is in cdrecord itself, since I have seen that if the FIFO ever hits 0%
during CD burning, cdrecord has a tendency to bomb. =20
If you empty the fifo and the drive fifo you burn a coaster. Thats a feature
of CD burning and one reason I use 640Mb magneto
On Mon, 16 Oct 2000, Alan Cox wrote:
Umm, doesn't cdrecord know how to address IDE devices directly?
IDE cd burners talk ATAPI. ATAPI is just a scsi variant. SCSI won the battle
at the protocol level
...
Yeah yeah yeah. What I meant was "you don't have to use ide-scsi." However,
after
On Thu, 28 Sep 2000, Nick Loman wrote:
>I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT
>SmartRAID V support) into the kernel. I got it working as a module, but
>now I want it compiled directly in.
I run with it compiled in (I boot from the SR-V.)
I've put diffs for
On Thu, 28 Sep 2000, Nick Loman wrote:
I'm trying to compile in Ricky Beam's patched dpt_i2o.c file (for DPT
SmartRAID V support) into the kernel. I got it working as a module, but
now I want it compiled directly in.
I run with it compiled in (I boot from the SR-V.)
I've put diffs for
On Mon, 25 Sep 2000, Nick Loman wrote:
>So as far as I can tell, the i2o stack in Linux 2.4 doesn't support the
>DPT SmartRAID V i2o controller.
"We know." It never has. (and arguablly never will.)
>Am I right in thinking then the only option is to combine DPT's drivers
>into the kernel by
On Mon, 25 Sep 2000, Nick Loman wrote:
So as far as I can tell, the i2o stack in Linux 2.4 doesn't support the
DPT SmartRAID V i2o controller.
"We know." It never has. (and arguablly never will.)
Am I right in thinking then the only option is to combine DPT's drivers
into the kernel by hand?
On Sat, 23 Sep 2000, Horst von Brand wrote:
>Some other funny stuf is happening, I'll try on monday without NFSv3 in
>kernel, and mounting from the PC.
I will add, Solaris ignores the capabilities of mountd and will attempt
an NFSv3 connection if it sees a v3 nfsd registered. You can tell
On Sat, 23 Sep 2000, Horst von Brand wrote:
Some other funny stuf is happening, I'll try on monday without NFSv3 in
kernel, and mounting from the PC.
I will add, Solaris ignores the capabilities of mountd and will attempt
an NFSv3 connection if it sees a v3 nfsd registered. You can tell mountd
On Wed, 20 Sep 2000, Lyle Coder wrote:
>You cannot use MMX registers in the kernel either, since the kernel doesen't
>save and restore FX state (fxsave, fxrstor) either (just like
>(fsave/frstor).
You might want to tell the software RAID maintainers that... RAID5 CRC
calculations can be done
On Wed, 20 Sep 2000, Lyle Coder wrote:
You cannot use MMX registers in the kernel either, since the kernel doesen't
save and restore FX state (fxsave, fxrstor) either (just like
(fsave/frstor).
You might want to tell the software RAID maintainers that... RAID5 CRC
calculations can be done with
On Sun, 17 Sep 2000, Bryan Whitehead wrote:
>A guy in the down under (.au) sent me this driver. Aparently Adaptec
>developes their OpenSource driver privatly and only gives out copies to
>"special" customers.
You've never had to deal with Adaptec. I'd rather build my own SCSI
controller out of
On Sun, 17 Sep 2000, Alan Cox wrote:
>> It might be a problem for places like Redhat, Suse, etc. that sell linux
>> distributions. Of course, the GPL has the same clause and no one's had
>> a problem with selling linux distributions so far.
>
>The GPL allows commercial sale. I threw the i2o sig
On Sun, 17 Sep 2000, Alan Cox wrote:
>> Has anyone thought about including the DPT I2O driver in the main kernel?
>> The license in the files don't preclude doing this. Yeah, I'm more than
>
>They do. The i2o headers can only be distributed by someone who is an
>i2o sig member.
Have you read
On Sun, 17 Sep 2000, Alan Cox wrote:
>They do. The i2o headers can only be distributed by someone who is an
>i2o sig member.
Ah, here's the magic clause:
+ * This information is provided for the purpose of recompilation of the
+ * driver code provided by Distributed Processing Technology only.
On Sun, 17 Sep 2000, Alan Cox wrote:
>> It goes on to stipluate no "selling" the headers, leave the I2O SIG copyright
>
>Selling covers distributing for money. I've been talking to them about using
>the linux/i2o.h headers which are not so encumbered but heard nothing for
>a month or so now
On Sun, 17 Sep 2000, Bryan Whitehead wrote:
A guy in the down under (.au) sent me this driver. Aparently Adaptec
developes their OpenSource driver privatly and only gives out copies to
"special" customers.
You've never had to deal with Adaptec. I'd rather build my own SCSI
controller out of
On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> Have you bothered tell us what that error is? I've not seen anything on
>> dpt's mail-list. (Which is where this should be discussed.)
>
>I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
>do for help) MANY times pleading
On Sat, 16 Sep 2000, Bryan Whitehead wrote:
>> The driver should be on DPT's site. Im not sure on the current state with the
(The driver _IS_ on DPT's site. It always has been.)
>The driver directory is on thier web site. true. But it only works for
>specific versions of kernel's from RH. They
On Sat, 16 Sep 2000, Bryan Whitehead wrote:
The driver should be on DPT's site. Im not sure on the current state with the
(The driver _IS_ on DPT's site. It always has been.)
The driver directory is on thier web site. true. But it only works for
specific versions of kernel's from RH. They do
On Sat, 16 Sep 2000, Bryan Whitehead wrote:
Have you bothered tell us what that error is? I've not seen anything on
dpt's mail-list. (Which is where this should be discussed.)
I've emailed [EMAIL PROTECTED] (that's what the linuxi2oreadme.txt says to
do for help) MANY times pleading for help.
On Thu, 14 Sep 2000, Nick Pollitt wrote:
...
>And second, why is the 4K limit there in the first place?
Primarily because it was never designed for 90% of the crap that's in there
now. I have long hated the BS required to get more than 4k worth of stuff
out of /proc. The way around the limit
On Thu, 14 Sep 2000, Nick Pollitt wrote:
...
And second, why is the 4K limit there in the first place?
Primarily because it was never designed for 90% of the crap that's in there
now. I have long hated the BS required to get more than 4k worth of stuff
out of /proc. The way around the limit is
On Fri, 8 Sep 2000, Andreas Eibach wrote:
...
>ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:pio, hdb:pio
>ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:pio, hdd:pio
...
>hda: 120060864 sectors (61471 MB) w/2048KiB Cache, CHS=7473/255/63, UDMA(33)
> hda:hda: timeout waiting for
On 8 Sep 2000, Juan J. Quintela wrote:
>Could we make it _easy_ to put all the
>modules/System.map/bzImage/ in boot/ and make it easy to do
>a tar of that directory and make easy to install that dir in another
>machine (perhaps puting a tiny Makefile/script there to do that).
Well, one can
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
>> However, NO ONE has taken the time (I'm talking weeks of doing nothing
>> but screwing with Makefiles) to completely rewrite the build system.
>
>I have done exactly that.
And how much did RedHat pay you to do it?
>And I gave you the URL.
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
>> Well, there's butt-loads of ugly Makefile shit all over the place. It
>> isn't going away.
>
>Some of it went away when Keith Owens rewrote modules-install.
Some, but not all. Some of the things necessary/desired for the kernel
build
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
>(1) Rules.make had a load of ugly code to translate from the source tree
>to the symlink farm. This code had plenty of bugs and race conditions
>(e.g. if two subdirectories have the same MOD_LIST_NAME and make
>runs in parallel).
What's the point of running depmod at the end of modules_install? The
System.map doesn't contain any versioned symbols so it just bitches about
everything as being undefined. (depmod needs a "-i" to temporarily ignore
versioning and it still bitches) And looking at the System.map is a bad way
What's the point of running depmod at the end of modules_install? The
System.map doesn't contain any versioned symbols so it just bitches about
everything as being undefined. (depmod needs a "-i" to temporarily ignore
versioning and it still bitches) And looking at the System.map is a bad way
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
(1) Rules.make had a load of ugly code to translate from the source tree
to the symlink farm. This code had plenty of bugs and race conditions
(e.g. if two subdirectories have the same MOD_LIST_NAME and make
runs in parallel).
On Thu, 7 Sep 2000, Michael Elizabeth Chastain wrote:
However, NO ONE has taken the time (I'm talking weeks of doing nothing
but screwing with Makefiles) to completely rewrite the build system.
I have done exactly that.
And how much did RedHat pay you to do it?
And I gave you the URL. You
On 8 Sep 2000, Juan J. Quintela wrote:
Could we make it _easy_ to put all the
modules/System.map/bzImage/whatever in boot/ and make it easy to do
a tar of that directory and make easy to install that dir in another
machine (perhaps puting a tiny Makefile/script there to do that).
Well, one can
On Tue, 5 Sep 2000, Albert D. Cahalan wrote:
>First of all, the "250,000" is wrong:
I was just making up a number. I can go scan ARIN for all their netblocks
and give you the exact number of address that would have to be scanned.
(I won't. It's alot.)
>Second, dialup users don't have enough
On Mon, 4 Sep 2000, Gregory Maxwell wrote:
>> Then they need more competant admins. It isnt _hard_ to transproxy outgoing
>> smtp traffic via a spamtrapper that checks for valid src/destination and
>> headers.
>
>I can't believe that you are suggesting this.
Mindspring did this (maybe still
On Mon, 4 Sep 2000, Alan Cox wrote:
>FreeServe in the UK have over 3 million dialup users and no spam problem.
Well, the economics of the UK is very different than the US. Besides,
aren't their laws against that sorta stuff over there?
>> It's the same problem EVERY ISP has. RR is just higher
On Mon, 4 Sep 2000, John Kennedy wrote:
> Ping seems to be spending its time in a sendto()/poll() loop:
>
> sendto(3, "U\3Z\241\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0"..., 56, 0,
>{sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
>
On Sun, 3 Sep 2000, Horst von Brand wrote:
>"Albert D. Cahalan" <[EMAIL PROTECTED]> said:
>> The rr.com service is expanding across the US. It is a cable
>> service recently bought by AT It serves areas without ISDN
>> or DSL, so the only alternative is a POTS modem. The rr.com
>> service is much
(OK, I've read enough of this crap.)
On Sat, 2 Sep 2000, David Luyer wrote:
>I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
>of our backbones.
Why is it the people placed in charge of networks usually have no clue
how they work? (don't answer that.)
[broken
(OK, I've read enough of this crap.)
On Sat, 2 Sep 2000, David Luyer wrote:
I'm seeing a problem between Linux 2.2 and BSD/OS 4.1 in the situation on one
of our backbones.
Why is it the people placed in charge of networks usually have no clue
how they work? (don't answer that.)
[broken
On Sun, 3 Sep 2000, Horst von Brand wrote:
"Albert D. Cahalan" [EMAIL PROTECTED] said:
The rr.com service is expanding across the US. It is a cable
service recently bought by ATT. It serves areas without ISDN
or DSL, so the only alternative is a POTS modem. The rr.com
service is much cheaper
On Mon, 4 Sep 2000, John Kennedy wrote:
Ping seems to be spending its time in a sendto()/poll() loop:
sendto(3, "U\3Z\241\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\3\0"..., 56, 0,
{sin_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("127.0.0.1")}}, 16) = 56
poll([{fd=3,
On Mon, 4 Sep 2000, Alan Cox wrote:
FreeServe in the UK have over 3 million dialup users and no spam problem.
Well, the economics of the UK is very different than the US. Besides,
aren't their laws against that sorta stuff over there?
It's the same problem EVERY ISP has. RR is just higher
On Tue, 5 Sep 2000, Albert D. Cahalan wrote:
First of all, the "250,000" is wrong:
I was just making up a number. I can go scan ARIN for all their netblocks
and give you the exact number of address that would have to be scanned.
(I won't. It's alot.)
Second, dialup users don't have enough
On Tue, 29 Aug 2000, Alan Cox wrote:
>At 2Tb in a single partition you might well start hitting barriers. I think
>there is a 1Tb limit per device somewhere. You also need to ask yourself how
>long 2Tb would take to fsck on a power failure. Right now 2.2 doesnt support
>journalling over software
On Tue, 29 Aug 2000, Alan Cox wrote:
At 2Tb in a single partition you might well start hitting barriers. I think
there is a 1Tb limit per device somewhere. You also need to ask yourself how
long 2Tb would take to fsck on a power failure. Right now 2.2 doesnt support
journalling over software raid
75 matches
Mail list logo
