freebsd-chat-digest V5 #719
owner-freebs...@freebsd.org
freebsd-chat-digest Friday, March 7 2003 Volume 05 : Number 719
In this issue:
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: FYI: SCO Group Slaps IBM with $1B Suit
A question about kernel modules
Re: FYI: SCO Group Slaps IBM with $1B Suit
Re: A question about kernel modules
Re: A question about kernel modules
Re: A question about kernel modules
Re: A question about kernel modules
Re: A question about kernel modules
Re: A question about kernel modules
Why I hate Redhat and Oracle .....
Re: A question about kernel modules
Re: A question about kernel modules
----------------------------------------------------------------------
Date: Thu, 06 Mar 2003 21:22:49 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
Bakul Shah wrote:
> http://www.eweek.com/article2/0,3959,920733,00.asp
>
> ...
> At that time he also confirmed to eWeek that the company
> had hired high-profile attorney David Boies and his legal
> firm to investigate whether Windows, Mac OS X, Linux and
> versions of BSD infringed on the Unix intellectual
> property it owned.
> ...
I have to really laugh.
First, the USL/UCB lawsuit settlement, once and for all, decided
the question of whether or not the UNIX source code contains
trade secrets: it doesn't.
Second, Sun bought out of their royalty agreements, with a license
in perpetuity, and, among other things, they published the Solaris
Source code: even if it could be argued that trade secrets were
added after the version from which the UCB code was licensed, the
trade secrets are well and truly disclosed now, by Sun.
The fact that they are going after IBM for disclosure seems to
indicate that this is an attempt to cast it as a trade secret
disclosure issue; otherwise we would be reading about them going
after Red Hat.
Third, one of the things that USL sold, prior to its sale by AT&T
to Novell, was transferrable licenses to universities; one of the
ones I went to bought one of these, and we went around and grabbed
the serial numbers off of every piece of class A and class B
computing equipment that qualified as a recipient of the license.
That included every VT100, VT102, VT220, Televideo 910, 915, 925,
modem, etc. that we had, so that we would be assured of our ability
to have it for 100 times the number of CPUs than we had at the time,
as a way of planning for the future. It'd probably be pretty cheap
for IBM to buy one of these licenses (they say they have over 30,000
licensees, and these were probably common terms for most of the
educational licensees) off a University that's not using the SVR4
source code any more (e.g. using BSD or Linux instead). I know my
University, which was relatively small, ended up with some 300 and
something transferrable licenses. Assuming 1/3 of their licensees
are similar educational licenses, and that our university was
average, there's a good 3,000,000 of those things out there and
available for purchase at rock bottom prices. 8-).
The only real issue they have might be Copyright; however... the
thing they claim they are upset about is disclosure of code to
the Linux community. But, this is, I think, an error on their
part: perhaps they are not understanding that the JFS code that
IBM released was derived from OS/2, and not from AIX? I'm not
sure what other code they could mean.
IBM delayed the DOJ on an antitrust action for what, 10 years?
And they delayed a second one for what, 20 years, until the DOJ
just gave up? Who here thinks SCO is going to last that long if
this is their new revenue model?
- -- Terry
------------------------------
Date: Thu, 06 Mar 2003 22:03:23 -0800
From: Bakul Shah <ba...@bitblocks.com>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
> I have to really laugh.
I figured you guys needed something to laugh about.
I wonder if next they will sue AT&T. Imagine DMR's machine
being confiscated for running Unix. Good thing he has moved
on to Plan9.
------------------------------
Date: Fri, 07 Mar 2003 08:25:27 +0100
From: Dag-Erling Smorgrav <d...@ofug.org>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
Bakul Shah <ba...@bitblocks.com> writes:
> At that time he also confirmed to eWeek that the company
> had hired high-profile attorney David Boies and his legal
> firm to investigate whether Windows, Mac OS X, Linux and
> versions of BSD infringed on the Unix intellectual
> property it owned.
*groan* not again...
DES
- --
Dag-Erling Smorgrav - d...@ofug.org
------------------------------
Date: Fri, 7 Mar 2003 01:31:58 -0600
From: "Kevin Kinsey, DaleCo, S.P." <k...@daleco.biz>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
- ----- Original Message -----
From: "Dag-Erling Smorgrav" <d...@ofug.org>
To: "Bakul Shah" <ba...@bitblocks.com>
Cc: <ch...@FreeBSD.ORG>
Sent: Friday, March 07, 2003 1:25 AM
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
> Bakul Shah <ba...@bitblocks.com> writes:
> > At that time he also confirmed to eWeek that the company
> > had hired high-profile attorney David Boies and his legal
> > firm to investigate whether Windows, Mac OS X, Linux and
> > versions of BSD infringed on the Unix intellectual
> > property it owned.
>
> *groan* not again...
>
> DES
> --
Wow, heard that echo on this side o' the pond...
or was that "me, too!" ?
Kevin Kinsey
DaleCo, S.P.
------------------------------
Date: Fri, 07 Mar 2003 02:06:29 -0700
From: Brett Glass <br...@lariat.org>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
At 09:09 PM 3/6/2003, Bakul Shah wrote:
> ...
> At that time he also confirmed to eWeek that the company
> had hired high-profile attorney David Boies and his legal
> firm to investigate whether Windows, Mac OS X, Linux and
> versions of BSD infringed on the Unix intellectual
> property it owned.
All they need to do is take it to the Supreme Court, which
didn't seem to think much of Boies the last time.
- --Brett
------------------------------
Date: Fri, 7 Mar 2003 11:04:50 -0500
From: Larry Sica <lom...@mac.com>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
On Thursday, March 6, 2003, at 11:09 PM, Bakul Shah wrote:
> http://www.eweek.com/article2/0,3959,920733,00.asp
>
> ...
> At that time he also confirmed to eWeek that the company
> had hired high-profile attorney David Boies and his legal
> firm to investigate whether Windows, Mac OS X, Linux and
> versions of BSD infringed on the Unix intellectual
> property it owned.
> ...
The dying gasps of SCO. SCO is not going to be able to deal with the
IBM legal juggernaut. I see this as an attempt to drum up cash and
maybe some press for them
- --Larry
------------------------------
Date: Fri, 7 Mar 2003 11:17:23 -0500
From: Larry Sica <lom...@mac.com>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
On Friday, March 7, 2003, at 04:06 AM, Brett Glass wrote:
> At 09:09 PM 3/6/2003, Bakul Shah wrote:
>
>> ...
>> At that time he also confirmed to eWeek that the company
>> had hired high-profile attorney David Boies and his legal
>> firm to investigate whether Windows, Mac OS X, Linux and
>> versions of BSD infringed on the Unix intellectual
>> property it owned.
>
> All they need to do is take it to the Supreme Court, which
> didn't seem to think much of Boies the last time.
>
> --Brett
>
It won't reach there. IBM is very good at delaying things. Also They
have to go through the normal legal process which I don't think SCO has
the money to do. They are trying to bully ibm for a payoff. IBM does
not get bullied either heh.
- --Larry
------------------------------
Date: Fri, 7 Mar 2003 11:34:27 -0500
From: Damien Tougas <dam...@tougas.net>
Subject: A question about kernel modules
Is there any advantage/disadvantage to using kernel moduls vs. staticly
linking stuff in the kernel? I would like to eliminate everything from my
kernel config that can be loaded as a module, then load them at boot using
loader.conf. Is there any reason I would not want to do that? It seems to me
that it would make things much easier.
Why does FreeBSD not do this by default for the GENERIC kernel?
Thanks.
- --
Damien Tougas
------------------------------
Date: Fri, 07 Mar 2003 11:09:25 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: FYI: SCO Group Slaps IBM with $1B Suit
Larry Sica wrote:
> It won't reach there. IBM is very good at delaying things. Also They
> have to go through the normal legal process which I don't think SCO has
> the money to do. They are trying to bully ibm for a payoff. IBM does
> not get bullied either heh.
They also have the patent portfolio from hell. IBM files more
patents each year than all other US filers combined.
The can always just say "We're so sorry; we're quite willing to
pay; there's just this small matter of these 11,731 patents of
ours that UNIX infringes".
IBM has 5 patents they belive SQUID infringes; that why we were
not allowed to ship SQUID on the InterJet II, due to the GPL
giving away licensing for that patent. It's also why there is
no "IBM Linux", and they always partner with a Linux company to
provide Linux for their machines, when they sell a Linux-based
solution. If SQUID or Linux ever became a threat in the hands
of a commercial competitor, they could crush them like a bug.
I have a real love/hate relationship with IBM over tactics like
this: they are incredibly smart about some things, but incredibly
dumb about others.
- -- Terry
------------------------------
Date: Fri, 07 Mar 2003 11:27:46 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: A question about kernel modules
Damien Tougas wrote:
> Is there any advantage/disadvantage to using kernel moduls vs. staticly
> linking stuff in the kernel? I would like to eliminate everything from my
> kernel config that can be loaded as a module, then load them at boot using
> loader.conf. Is there any reason I would not want to do that? It seems to me
> that it would make things much easier.
Code in the boot path which must operate before the kernel is
fully up can not be handled as modules.
In general, drivers which require large contiguous chunks of physical
memory (e.g. video capture cards) must obtain their memory before
much has been done, since physical memory fragments quickly under the
influence of aggressive page caching, etc..
Some interfaces do not have the indirect references necessary to
allow modules which attach to them to be dynamically loaded (e.g.
networking stacks in general, or the TCP and IP protocol boundary,
as a specific example).
> Why does FreeBSD not do this by default for the GENERIC kernel?
The GENERIC kernel is loaded from a CDROM controller BIOS faked-up
floppy drive, which is how CDROMs are able to boot. Even if all
other issues were resolved, this floppy image would be unable to
contain all the necessary modules. For the modules to be read off
the CDROM or other boot media, all the code in the module loading
path would have to be statically present (ISO9660 FS, ATA and SCSI
drivers, CDROM driver, etc., etc.). By including all the drivers
in the GENERIC kernel, it makes it much more likely that you will
b able to actually install FreeBSD in the first place.
- -- Terry
------------------------------
Date: Fri, 07 Mar 2003 14:39:32 -0500 (EST)
From: John Baldwin <j...@FreeBSD.org>
Subject: Re: A question about kernel modules
On 07-Mar-2003 Terry Lambert wrote:
> The GENERIC kernel is loaded from a CDROM controller BIOS faked-up
> floppy drive, which is how CDROMs are able to boot. Even if all
> other issues were resolved, this floppy image would be unable to
> contain all the necessary modules. For the modules to be read off
> the CDROM or other boot media, all the code in the module loading
> path would have to be statically present (ISO9660 FS, ATA and SCSI
> drivers, CDROM driver, etc., etc.). By including all the drivers
> in the GENERIC kernel, it makes it much more likely that you will
> b able to actually install FreeBSD in the first place.
FreeBSD hasn't used the floppy-emulation mode of CD booting since
4.6. See /usr/src/sys/boot/i386/cdboot/cdboot.s and an El Torito
standard for more details.
- --
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
------------------------------
Date: Fri, 07 Mar 2003 11:48:45 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: A question about kernel modules
John Baldwin wrote:
> > The GENERIC kernel is loaded from a CDROM controller BIOS faked-up
> > floppy drive, which is how CDROMs are able to boot. Even if all
> > other issues were resolved, this floppy image would be unable to
> > contain all the necessary modules. For the modules to be read off
> > the CDROM or other boot media, all the code in the module loading
> > path would have to be statically present (ISO9660 FS, ATA and SCSI
> > drivers, CDROM driver, etc., etc.). By including all the drivers
> > in the GENERIC kernel, it makes it much more likely that you will
> > b able to actually install FreeBSD in the first place.
>
> FreeBSD hasn't used the floppy-emulation mode of CD booting since
> 4.6. See /usr/src/sys/boot/i386/cdboot/cdboot.s and an El Torito
> standard for more details.
Oops; I was looking at a 4.5 box, which is what I mostly use to
do scratch work.
The main point was that we get to load only one file, and have no
CDROM access after that, except through drivers which must be
present in the kernel. I think that's still valid to say.
- -- Terry
------------------------------
Date: Fri, 07 Mar 2003 15:25:59 -0500 (EST)
From: John Baldwin <j...@FreeBSD.org>
Subject: Re: A question about kernel modules
On 07-Mar-2003 Terry Lambert wrote:
> John Baldwin wrote:
>> > The GENERIC kernel is loaded from a CDROM controller BIOS faked-up
>> > floppy drive, which is how CDROMs are able to boot. Even if all
>> > other issues were resolved, this floppy image would be unable to
>> > contain all the necessary modules. For the modules to be read off
>> > the CDROM or other boot media, all the code in the module loading
>> > path would have to be statically present (ISO9660 FS, ATA and SCSI
>> > drivers, CDROM driver, etc., etc.). By including all the drivers
>> > in the GENERIC kernel, it makes it much more likely that you will
>> > b able to actually install FreeBSD in the first place.
>>
>> FreeBSD hasn't used the floppy-emulation mode of CD booting since
>> 4.6. See /usr/src/sys/boot/i386/cdboot/cdboot.s and an El Torito
>> standard for more details.
>
> Oops; I was looking at a 4.5 box, which is what I mostly use to
> do scratch work.
>
> The main point was that we get to load only one file, and have no
> CDROM access after that, except through drivers which must be
> present in the kernel. I think that's still valid to say.
Nope. cdboot loads up a /boot/loader and you are free to load
whatever modules you want off the CD just as if you were booting
from a hard drive. That said, I personally favor static kernels
and only use modules when I'm testing things.
- --
John Baldwin <j...@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
------------------------------
Date: Fri, 07 Mar 2003 20:51:19 +0000
From: Mark Murray <ma...@grondar.org>
Subject: Re: A question about kernel modules
Terry Lambert writes:
> Damien Tougas wrote:
> > Is there any advantage/disadvantage to using kernel moduls vs. staticly
> > linking stuff in the kernel? I would like to eliminate everything from my
> > kernel config that can be loaded as a module, then load them at boot using
> > loader.conf. Is there any reason I would not want to do that? It seems to m
> e
> > that it would make things much easier.
>
> Code in the boot path which must operate before the kernel is
> fully up can not be handled as modules.
Rubbish. Such modules may have a problem with being loaded at
runtime, but they can be loaded by the bootloader.
> In general, drivers which require large contiguous chunks of physical
> memory (e.g. video capture cards) must obtain their memory before
> much has been done, since physical memory fragments quickly under the
> influence of aggressive page caching, etc..
No problem. bktr_mem is such a module.
> Some interfaces do not have the indirect references necessary to
> allow modules which attach to them to be dynamically loaded (e.g.
> networking stacks in general, or the TCP and IP protocol boundary,
> as a specific example).
That may be a problem today, but it is not insurmountable.
> > Why does FreeBSD not do this by default for the GENERIC kernel?
>
> The GENERIC kernel is loaded from a CDROM controller BIOS faked-up
> floppy drive, which is how CDROMs are able to boot. Even if all
> other issues were resolved, this floppy image would be unable to
> contain all the necessary modules. For the modules to be read off
> the CDROM or other boot media, all the code in the module loading
> path would have to be statically present (ISO9660 FS, ATA and SCSI
> drivers, CDROM driver, etc., etc.). By including all the drivers
> in the GENERIC kernel, it makes it much more likely that you will
> b able to actually install FreeBSD in the first place.
50% correct.
M
- --
Mark Murray
iumop ap!sdn w,I idlaH
------------------------------
Date: Sat, 08 Mar 2003 00:00:27 +0000
From: Andrew Boothman <and...@cream.org>
Subject: Re: A question about kernel modules
John Baldwin wrote:
>>The main point was that we get to load only one file, and have no
>>CDROM access after that, except through drivers which must be
>>present in the kernel. I think that's still valid to say.
>>
>>
>
>Nope. cdboot loads up a /boot/loader and you are free to load
>whatever modules you want off the CD just as if you were booting
>from a hard drive. That said, I personally favor static kernels
>and only use modules when I'm testing things.
>
I guess this is really the nub of the question.
Why do you "personally favour" static kernels over modules?
I, like you, tend to compile everything into my kernel but that's more
out of habit than for any other reason as I have been compiling kernels
since about 2.2.7 which I think pre-dates kernel modules.
Andrew.
------------------------------
Date: Fri, 7 Mar 2003 16:53:22 -0800
From: Ulf Zimmermann <u...@Alameda.net>
Subject: Why I hate Redhat and Oracle .....
So our company decides to switch our Oracle servers from Solaris
to Redhat x86 because of Oracle RAC and having to pay so much more
on Solaris (Veritas is required).
Working with HP on this (no, they are still really Compaq people).
They got propritary scripts and as it looks like drivers for their
hardware and Redhat AS. Redhat offers AS Developer Edition, in theory
a platform fo you to test your application or third party drivers/
applications on.
But no:
This does not appear to be the correct distribution.
expecting redhat-release:
Red Hat Linux Advanced Server release 2.1AS (Pensacola)
Found /etc/redhat-release:
Red Hat Linux Advanced Server release 2.1ASDE Developer Edition (Destin)
Won't work .... ok, bite the bullet, buy AS now ... loading www.redhat.com
Advanced Server Basic ... sold out
Advanced Server Standard ... Available
Advanced Server Premium ... Available.
What is the difference between them ? The type of support you get.
Try to call their sales line ... all gone home already...
PLEASE ORACLE, PORT YOUR DAMN PRODUCT TO FREEBSD.
- --
Regards, Ulf.
- ---------------------------------------------------------------------
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204
You can find my resume at: http://seven.Alameda.net/~ulf/resume.html
------------------------------
Date: Fri, 7 Mar 2003 22:46:18 -0500
From: Damien Tougas <dam...@tougas.net>
Subject: Re: A question about kernel modules
On Friday 07 March 2003 07:00 pm, Andrew Boothman wrote:
> >Nope. cdboot loads up a /boot/loader and you are free to load
> >whatever modules you want off the CD just as if you were booting
> >from a hard drive. That said, I personally favor static kernels
> >and only use modules when I'm testing things.
>
> I guess this is really the nub of the question.
>
> Why do you "personally favour" static kernels over modules?
Yes, that really is the question. I have traditionally always done the same,
compiling everything into my kernel. I guess I am wondering what the point of
kernel modules are, and if they are considered to be a stable, viable way of
configuring my kernel. If there are good reasons why I should not use them
(or not use them in specific situations), I would be intersted in knowing
what those are.
> I, like you, tend to compile everything into my kernel but that's more
> out of habit than for any other reason as I have been compiling kernels
> since about 2.2.7 which I think pre-dates kernel modules.
I don't know much about the technology behind kernel modules, but I get the
sense that people get used to doing things a certain way, and stick with it
because it is what they have always done, regardless if there is another way
(even if it might be technically better - although I am in no position to be
the judge of that in this situation).
From a convenience standpoint, kernel modules seem much more practical to me.
I like the idea of being able to load/unload device drivers, etc. at runtime.
I, however, have no idea what the impact is on things like stability and
performance.
- --
Damien Tougas
------------------------------
Date: Fri, 07 Mar 2003 22:47:16 -0800
From: Terry Lambert <tlam...@mindspring.com>
Subject: Re: A question about kernel modules
Damien Tougas wrote:
> On Friday 07 March 2003 07:00 pm, Andrew Boothman wrote:
> > >Nope. cdboot loads up a /boot/loader and you are free to load
> > >whatever modules you want off the CD just as if you were booting
> > >from a hard drive. That said, I personally favor static kernels
> > >and only use modules when I'm testing things.
> >
> > I guess this is really the nub of the question.
> >
> > Why do you "personally favour" static kernels over modules?
>
> Yes, that really is the question. I have traditionally always done the same,
> compiling everything into my kernel. I guess I am wondering what the point of
> kernel modules are, and if they are considered to be a stable, viable way of
> configuring my kernel. If there are good reasons why I should not use them
> (or not use them in specific situations), I would be intersted in knowing
> what those are.
The dependency tracking sucks, and so does demand-loading. If
you look at the module code with the idea of loading *at least
one* ethernet driver before you could load IP, and having to
load IP before you could load TCP, and then look at the code to
see what this would take, you will be enlightened.
There are also certain options which cause structure sizes to
change, which are associated with particular things. As an
example, the IPSEC stuff can't really be modularized, because
there's per connection state that has to be there for it to
be happy.
Another issue having to do with structure size is that if the
module you are trying to load was not compiled with the same
options as the kernel you are trying to load it into, even if
all the version stuff matches, including the proposed new
versioning data, the structure sizes expected by the module
and by the kernel can be different. A good example of this is
something like "WITNESS" or "INVARIANTS", etc..
The fact that the API contracts are not as fixed as they should
be adds to the uncertainty (e.g. there is no DDI or DKI, as such,
in FreeBSD).
Basically, it's not really "ready for prime time", in terms of
third party binary-only modules, which is the most interesting
use for them, by far.
> > I, like you, tend to compile everything into my kernel but that's more
> > out of habit than for any other reason as I have been compiling kernels
> > since about 2.2.7 which I think pre-dates kernel modules.
>
> I don't know much about the technology behind kernel modules, but I get the
> sense that people get used to doing things a certain way, and stick with it
> because it is what they have always done, regardless if there is another way
> (even if it might be technically better - although I am in no position to be
> the judge of that in this situation).
If something's in the kernel, proper, I'm guaranteed it woun't
have a problem loading, so that when I need it, it will be there.
With a module, theres an element of risk, due to reasons stated
previously, and the reasons above.
> >From a convenience standpoint, kernel modules seem much more practical to me.
>
> I like the idea of being able to load/unload device drivers, etc. at runtime.
> I, however, have no idea what the impact is on things like stability and
> performance.
The normal performance cost is all interfaces being indirected
through a pointer. For most interfaces, this overhead is there
anyway, so that all access is uniform. For other things, like
schedulers, for example, the functions are linked directly, so
they have to be resolved at compile time.
- -- Terry
------------------------------
End of freebsd-chat-digest V5 #719
**********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-chat-digest in the body of the message