Here is what IBM thinks about using FreeBSD on their newer Thinkpads
jonas...@servicefactory.se
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
nba...@epcot.revenio.com
Well, I never liked their laptops, anyway. I'm surprised they don't
support RH Linux. I'm glad to know that they support all the lousy MS
operating systems ...
br...@lariat.org
move to AIX, not FreeBSD or Linux. Unfortunately, their PR people
have pretended to jump on the Linux bandwagon in a big way, and
this hurts the BSDs.
--Brett
>with "unsubscribe freebsd-chat" in the body of the message
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
msm...@freebsd.org
This was crossposted to too many lists, reply-to set to a useful subset.
> FWIW, the "recovery procedure" they allude to is to use their
> recovery CDROM, which will basically repartition and reinstall the
> default software that came with the machine. I'll guess that they
> don't recommend specific recovery instructions (and refer only to
> "various utilities") as a hold harmless measure, since the
> recovery CD will effectively blow away any user data on the drive,
> and they don't want to be held responsible for that.
Actually, the "recovery procedure" involves removing the harddisk, since
the BIOS code in question that fails does so before the boot process
starts, and with a FreeBSD partition on the disk, you never get to boot
at all.
This has been discussed on -mobile already, and any interested party is
encouraged to consult the archives.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
tlam...@primenet.com
> > recovery CDROM, which will basically repartition and reinstall the
> > default software that came with the machine. I'll guess that they
> > don't recommend specific recovery instructions (and refer only to
> > "various utilities") as a hold harmless measure, since the
> > recovery CD will effectively blow away any user data on the drive,
> > and they don't want to be held responsible for that.
>
> Actually, the "recovery procedure" involves removing the harddisk, since
> the BIOS code in question that fails does so before the boot process
> starts, and with a FreeBSD partition on the disk, you never get to boot
> at all.
>
> This has been discussed on -mobile already, and any interested party is
> encouraged to consult the archives.
I think this presumes that the HD is examined at boot time,
instead of stopping once the system sees a bootable CDROM,
which is the normal case when doing a recovery.
You should talk to Evan Oldford (ev...@whistle.com, eold...@us.ibm.com)
about his experiences recovering with the recovery CDROM, after
having trashed several models of thinkpads with FreeBSD installs
gone wrong.
Obviously, you could also recover by removing the hard drive
and zapping it, but the technical note referred to by the
original author of this subject specifically states that there
are utilities that can recover the HDD to a bootable state:
"The HDD can be recovered to make the system bootable
again using various utilities. However, IBM does not
recommend any specific utility or support the use of
any of these utilities."
I think the "magic" combo to force it to ignore the HDD is
something like "Alt-F6" during boot, but don't quote me: it's
printed in the ThinkPad manual that comes with each ThinkPad.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
rag...@sysabend.org
:I'd be happy if everybody could just stop cc'ing this discussion to
:THREE DIFFERENT MAILING LISTS. Really, -chat, -mobile AND -advocacy
:is just excessive. This is also covered in the mailing list charters
:so nobody should be able to claim ignorance or special dispensation
:for a thread with overlap. Please, trim those cc lines folks!
He's just mad because he wouldn't have seen it if it hadn't come across
-mobile.
Jamie Bowden
--
"It was half way to Rivendell when the drugs began to take hold"
Hunter S Tolkien "Fear and Loathing in Barad Dur"
Iain Bowen <ala...@alaric.org.uk>
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
gr...@lemis.com
> On Tuesday, November 28, 2000 9:32 AM, Jonas Bulow wrote:
>>
>> http://www.pc.ibm.com/qtechinfo/MIGR-4QHLS4.html
>
> Well, I never liked their laptops, anyway. I'm surprised they don't
> support RH Linux. I'm glad to know that they support all the lousy MS
> operating systems ...
I think this gives the lie to the whole thing. I suspect it's yet
another case of left hand/right hand syndrome, and I wouldn't be
surprised if it got revoked.
Greg
--
Finger gr...@lemis.com for PGP public key
See complete headers for address and phone numbers
br...@lariat.org
>I think this presumes that the HD is examined at boot time,
>instead of stopping once the system sees a bootable CDROM,
>which is the normal case when doing a recovery.
If the problem is a BIOS that can't handle a FreeBSD boot
sector, perhaps a special boot sector with replacement hard
disk BIOS code -- such as the one included in OnTrack Disk
Manager -- would serve as a workaround. The problem
could also be that the laptop has a suspend/resume feature
that's looking for a special partition or DOS file and not
finding it.
--Brett
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
tlam...@primenet.com
> >"omission", or the phrasing of the statements about "Caldera
> >OpenLinux" and "Do not install a non-supported operating system".
> >
> >The lawyers have quite a different take: if you want to use GPL
> >code, or any other code with a source distribution requirement,
> >you are required to attend a "handling toxic waste that will
> >destroy your patent rights" class, before you are allowed to even
> >touch it. You also have to get "cleared" copies of the code from
> >internal IBM servers, so that IBM patents aren't infringed by you
> >using a newer version of the code.
> >
> >There is an 18 page presentation that most of the internal search
> >engines will point you to, when you are going through the exercise
> >of trying to find information internally. It boils down to "how
> >to double-glove before putting on your biohazard suit to enter a
> >class 5 hot zone containing live Ebola".
>
> When IBM acquired Whistle, it acquired a product that included,
> and in fact depended upon, GPLed code because FreeBSD does. How
> did it handle this situation? Is there any chance that IBM might be
> interested in helping to free the BSDs from the GPL?
There is a difference between tools dependencies and product
dependencies. The InterJet is a closed box, and does not
ship with a ful developement environment.
The way IBM "handled it" was to do due dilligence on all the
code that shipped on the InterJet, and with one procedural
snag, vetted it for shipment.
The actual thing that gave them the most trouble was PHK's
"BeerWare" license, which they finally decided didn't really
constitute an obligation, since they could just decide to
not like the code or find it useful.
One thing they did do was force us to rip out SQUID (GPL),
since they believe that SQUID infringes a number of IBM
patents. They didn't indicate that they were willing to go
after the SQUID people about this (probably as suicidal as
USL attempting to mung UC Berkeley, from a pure marketing
standpoint), but they were unwilling to ship GPL code which
they believed embodied IBM patents, since they believed that
doing so would grant license to use the patents royalty free.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
br...@lariat.org
>There is a difference between tools dependencies and product
>dependencies. The InterJet is a closed box, and does not
>ship with a ful developement environment.
What about the many GNU userland utilities -- e.g. grep?
Surely some of these are available for administration,
debugging, recovery, execution by scripts, etc.
--Brett
tlam...@primenet.com
> >dependencies. The InterJet is a closed box, and does not
> >ship with a ful developement environment.
>
> What about the many GNU userland utilities -- e.g. grep?
> Surely some of these are available for administration,
> debugging, recovery, execution by scripts, etc.
Or SAMBA, which we also shipped on the box?
These were tactical, not strategic; shipping source for these
wouldn't matter, since they don't contain any intellectual
property that matters to anyone. Let people demand the code
if they want: we include a web page with links to the source
to everything they could demand, right on the box.
FWIW, though: no. These utilities are not available for
administration, recovery, or execution of scripts. They
are available for debugging, but only to Whistle engineering
people (or people who've left, like Archie, Julian, and me,
who happen to know the magic incantations and the secret
handshake). We all have FreeBSD systems or net access, so
we already have source code to these bits.
If you think these things would need to be exposed, then
you've missed the concept of "embedded system": all InterJet
administration was and is intended to be performed via a
limited set of externalized interfaces, predominantly the
web UI.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
br...@lariat.org
>Or SAMBA, which we also shipped on the box?
>
>These were tactical, not strategic; shipping source for these
>wouldn't matter, since they don't contain any intellectual
>property that matters to anyone. Let people demand the code
>if they want: we include a web page with links to the source
>to everything they could demand, right on the box.
It doesn't seem to me that this would avoid the problems
you mentioned earlier. GPLed code is still infectious.
[Snip]
>If you think these things would need to be exposed, then
>you've missed the concept of "embedded system": all InterJet
>administration was and is intended to be performed via a
>limited set of externalized interfaces, predominantly the
>web UI.
I understand embedded systems very well -- that's one of the
things I do. However, as we all know, selection is a much
less powerful paradigm than specification, and fixing a
box or using it to its full potential often requires the
power of a command line. What's more, the strategic UI code
almost certainly calls on such utilities to do its work and
therefore depends upon them.
--Brett
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
dke...@hiwaay.net
[...]
> There is a difference between tools dependencies and product
> dependencies. The InterJet is a closed box, and does not
> ship with a ful developement environment.
>
> code that shipped on the InterJet, and with one procedural
> snag, vetted it for shipment.
>
> The actual thing that gave them the most trouble was PHK's
> "BeerWare" license, which they finally decided didn't really
> constitute an obligation, since they could just decide to
> not like the code or find it useful.
I read most everything Terry Lambert posts to the FreeBSD lists for his
high S/N ratio and for the laughs I get from stuff like the above. :-)
Can you imagine trying to explain to an IBM executive that if he/she
were to meet PHK they were obliged to buy him a beer? And that it
wouldn't go under "entertainment expense account" but under "royalty
payments"? Its sure to add an entire viewgraph to the annual Ethics
Training. Complete with a picture of PHK so they would know him when
they meet him and not be tricked into buying beers for impostors.
--
David Kelly N4HHE, dke...@hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
br...@lariat.org
>Can you imagine trying to explain to an IBM executive that if he/she
>were to meet PHK they were obliged to buy him a beer?
Hey -- I'm still trying to explain to them that they're obliged to
make laptops that work!
--Brett
tlam...@primenet.com
> >instead of stopping once the system sees a bootable CDROM,
> >which is the normal case when doing a recovery.
>
> If the problem is a BIOS that can't handle a FreeBSD boot
> sector, perhaps a special boot sector with replacement hard
> disk BIOS code -- such as the one included in OnTrack Disk
> Manager -- would serve as a workaround. The problem
> could also be that the laptop has a suspend/resume feature
> that's looking for a special partition or DOS file and not
> finding it.
There are a lot of problems with the FreeBSD bootblocks in
"Dangerously Dedicated" mode:
1) Causes divide-by-zero because of invalid/unexpected
DOS partition table data, predominantly in a number
of SCSI controller BIOS'.
2) Doesn't pass all 7 common boot-sector validation
tests.
3) Looks like a boot-sector virus to some BIOS'.
4) Partition type 165 is not recognized by the BIOS in
some IBM laptops, resulting in a "suspend to disk"
overwriting the initial part of the FreeBSD disklabel
and "partition" 'a' with suspend data, trashing it.
These are just the immediate, and not incidental or consequential
problems.
The last one is resolved for Linux in recent BIOS by adding
the Linux partition number to the exclusion list, along with
the Windows and OS/2 exclusions. Technically, this would be
better resolved by using an _inclusion_ list, containing only
the permissable suspend partition ID. It can also be worked
around in FreeBSD by ensuring that the FreeBSD partition is
not the first one, and that the DOS partition table is intact,
with a FAT/VFAT partition at the start, and the suspend area
unadulterated, before the FreeBSD partition in the DOS table.
As you note, the OnTrack Disk Manager code does not have the
problem (personally, I use Boot Magic, which comes with Partition
Magic Pro from Power Quest Software). I even hacked up a little
daemon head bitmap so that it shows a deamon as the boot icon
image; I've had less luck replacing the background bitmap, but
it never struck me as being critical, anyway...
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
res0...@gte.net
get a mental picture of him wearing a shirt that reads "If you're from IBM,
you owe me a beer.".
[RC]
res0...@gte.net
the failure rate would be lost in the background noise.
The real question is why IBM is going after the Intel market with 5L,
when Sun has proven that a slow UNIX looks bad when compared with
*BSD and Linux.
Intel+commercial_UNIX=touch_of_death?
tlam...@primenet.com
> >
> >These were tactical, not strategic; shipping source for these
> >wouldn't matter, since they don't contain any intellectual
> >property that matters to anyone. Let people demand the code
> >if they want: we include a web page with links to the source
> >to everything they could demand, right on the box.
>
> It doesn't seem to me that this would avoid the problems
> you mentioned earlier. GPLed code is still infectious.
Only if you link against it. When was the last time you
linked against "grep"?
> >If you think these things would need to be exposed, then
> >you've missed the concept of "embedded system": all InterJet
> >administration was and is intended to be performed via a
> >limited set of externalized interfaces, predominantly the
> >web UI.
>
> I understand embedded systems very well -- that's one of the
> things I do. However, as we all know, selection is a much
> less powerful paradigm than specification, and fixing a
> box or using it to its full potential often requires the
> power of a command line. What's more, the strategic UI code
> almost certainly calls on such utilities to do its work and
> therefore depends upon them.
People who needed access to a command line, and could actually
use one, were such access granted, were not in our target
market.
There is a Ricoh photocopier and a Ricoh document capture
device, both based on FreeBSD. I rather seriously doubt
that they ship the code in such a state that you could get
a command line, period.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
rag...@sysabend.org
:As you note, the OnTrack Disk Manager code does not have the
:problem (personally, I use Boot Magic, which comes with Partition
:Magic Pro from Power Quest Software). I even hacked up a little
:daemon head bitmap so that it shows a deamon as the boot icon
:image; I've had less luck replacing the background bitmap, but
:it never struck me as being critical, anyway...
I used OS/2's boot manager for a very long time and still would if OS/2
Warp would install on my current hardware, but having also bought
Partition Magic, I have found Boot Magic to be a very good replacement.
Jamie Bowden
--
"It was half way to Rivendell when the drugs began to take hold"
Hunter S Tolkien "Fear and Loathing in Barad Dur"
Iain Bowen <ala...@alaric.org.uk>
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
w...@softweyr.com
>
> At 11:31 AM 11/29/2000, Terry Lambert wrote:
>
> >
> >These were tactical, not strategic; shipping source for these
> >wouldn't matter, since they don't contain any intellectual
> >property that matters to anyone. Let people demand the code
> >if they want: we include a web page with links to the source
> >to everything they could demand, right on the box.
>
> It doesn't seem to me that this would avoid the problems
> you mentioned earlier. GPLed code is still infectious.
I'd be concerned about that, too. We've studied the issue and have decided
that to put GPLed code in the standard system would be dangerous. It does
not appear to be a problem for optional components, so we may use GPL code
for elective add-on products. This even drove us to use PostgreSQL rather
than MySQL in our product, though MySQL would have been a better fit.
I must say I like pgsql a lot better.
> I understand embedded systems very well -- that's one of the
> things I do. However, as we all know, selection is a much
> less powerful paradigm than specification, and fixing a
> box or using it to its full potential often requires the
> power of a command line. What's more, the strategic UI code
> almost certainly calls on such utilities to do its work and
> therefore depends upon them.
Not if they're not in the box. Using my box to it's full potential doesn't
require a command line, because it doesn't have one.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
w...@softweyr.com http://softweyr.com/
tlam...@primenet.com
> that to put GPLed code in the standard system would be dangerous. It does
> not appear to be a problem for optional components, so we may use GPL code
> for elective add-on products. This even drove us to use PostgreSQL rather
> than MySQL in our product, though MySQL would have been a better fit.
The pre-GPL license on MySQL was actually incredibly _worse_
than the GPL.
> I must say I like pgsql a lot better.
I keep meaning to play with this; does it support triggered
mutual replication between two hosts running the code? I
really want fault tolerance, load balancing, and automatic
fail-over (basically, by having the load all move to one
machine instead of two [actually more complicated], so that
everyone gets degraded service, instead of some number being
denied service entirely).
I don't have triggers in the code, but I actuall have MySQL
set up for mutual replication via log replay, so that the
database and its replica stay more or less synchornized.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
br...@lariat.org
>> It doesn't seem to me that this would avoid the problems
>> you mentioned earlier. GPLed code is still infectious.
>
>Only if you link against it. When was the last time you
>linked against "grep"?
In this case, it's infectious in a different way: It is
eliminating truly free alternatives. Use it, and you are
facilitating another prong of the GPL agenda: to snuff
out other options. The fact that FreeBSD does not provide
a non-GPLed grep which is BSD-licensed means that the FSF
has succeeded.
Also, proponents of the GPL are now opting for an expanded
requirement based on the notion of "performance for profit."
Just running the code in a situation where you made money
from it would trigger a requirement to forfeit one's work.
>> I understand embedded systems very well -- that's one of the
>> things I do. However, as we all know, selection is a much
>> less powerful paradigm than specification, and fixing a
>> box or using it to its full potential often requires the
>> power of a command line. What's more, the strategic UI code
>> almost certainly calls on such utilities to do its work and
>> therefore depends upon them.
>
>People who needed access to a command line, and could actually
>use one, were such access granted, were not in our target
>market.
Ah, but I'm sure that the scripts that run your GUI activate
command line utilities behind the scenes -- including, most
likely, ones like grep.
>There is a Ricoh photocopier and a Ricoh document capture
>device, both based on FreeBSD. I rather seriously doubt
>that they ship the code in such a state that you could get
>a command line, period.
I'll have to check with Steve Savitzky on this. (He's a
strong open source advocate within Ricoh and may have
driven this choice.) My guess is that you can get a
command line for the purpose of servicing the machine,
perhaps via a TTY port inside the case. But that's not
the point. Even if YOU can't get the command line,
I'll bet their GUI invokes command line utilities.
--Brett
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
br...@lariat.org
>I used OS/2's boot manager for a very long time and still would if OS/2
>Warp would install on my current hardware, but having also bought
>Partition Magic, I have found Boot Magic to be a very good replacement.
Do the IBM Boot Manager and Boot Magic replace the BIOS hard disk code
as OnTrack Disk Manager does? It seems to me that this is what might be
needed to get things working if the original AT BIOS can't handle the
drive.
--Brett
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
rag...@sysabend.org
:At 07:10 AM 11/30/2000, Jamie Bowden wrote:
:
:>I used OS/2's boot manager for a very long time and still would if OS/2
:>Warp would install on my current hardware, but having also bought
:>Partition Magic, I have found Boot Magic to be a very good replacement.
:
:Do the IBM Boot Manager and Boot Magic replace the BIOS hard disk code
:as OnTrack Disk Manager does? It seems to me that this is what might be
:needed to get things working if the original AT BIOS can't handle the
:drive.
The IBM Boot Manager lives on it's own partition. You can put it at the
front or back of the disk free space. Boot Magic appears to takeover the
boot sector and the beginning of my Win98 partition, so you'd need a
minimal dos/win partition to use it.
Jamie Bowden
--
"It was half way to Rivendell when the drugs began to take hold"
Hunter S Tolkien "Fear and Loathing in Barad Dur"
Iain Bowen <ala...@alaric.org.uk>
tlam...@primenet.com
> >Only if you link against it. When was the last time you
> >linked against "grep"?
>
> In this case, it's infectious in a different way: It is
> eliminating truly free alternatives. Use it, and you are
> facilitating another prong of the GPL agenda: to snuff
> out other options. The fact that FreeBSD does not provide
> a non-GPLed grep which is BSD-licensed means that the FSF
> has succeeded.
The real "grep" source code is still available; sure it
means you have to assemble the parts instead of just taking
FreeBSD and running, but be honest: any product based on
FreeBSD, or any Open Source code, for that matter, has to
be productized before it is really useful.
> Also, proponents of the GPL are now opting for an expanded
> requirement based on the notion of "performance for profit."
> Just running the code in a situation where you made money
> from it would trigger a requirement to forfeit one's work.
I haven't heard this, and I have reason to doubt it: the
MySQL license was this way, and they moved away from that to
go with the GPL instead, which dropped the "no commercial
use" restrictions, including the performance for profit
restriction.
> >People who needed access to a command line, and could actually
> >use one, were such access granted, were not in our target
> >market.
>
> Ah, but I'm sure that the scripts that run your GUI activate
> command line utilities behind the scenes -- including, most
> likely, ones like grep.
You may be sure, but you're also wrong. 8-).
Actually, the UI code on the InterJet is predominantly written
in C++, using C++ objects as models for form, frame, table,
and other objects. The work was initiated at a time when you
could not write HTML code that would result in a consistant
user experience across different browsers, and the library
used to implement the code is called "libbif" for "Browser
Independent Framework".
The stuff that's not written that way is writen in C, and the
major guts of the system are also in C. I rewrote the mail
services subsystem and the agent database management subsystem,
to use subschema entries, so mail configuration, mailing lists,
users, user capabilities, account information, etc., was all
based on a common data modelling system.
In fact, the only things that weren't in this model were the
legacy code in the system agent, the web publishing, and the
scheduling agent (the system agent handled network and other
system configuration settings, and was written in C by Archie,
while the scheduling code was written by Larry).
Even in the startup and shutdown scripts (at least two of which
are shell scripts which call grep, but the majority of which
are actually special purpose binary programs or wrapped versions
of special purpose binary programs, with perl or sh doing the
wrapping), there's no GPL infection, since calling something
from a shell script is _not_ linking.
Even if you were right and the rest of the world were wrong
about what constitutes risk in this neighborhood, I'd like
to point out an obvious fact that appears to have escaped you...
IBM does not sell InterJets, any more than your local cable
company sells set-top boxes: IBM sells services. Since an
end user does not _buy_ an InterJet, they are not entitled to
the source code, even if it was all contaminated: they are
not being sold the software.
Consider if you were to run a program compilation service,
where people submitted code to be compiled, you compiled it
with GCC, and sent the object code back to them. You charge
for this service, and you've made modifications to GCC to
make it more efficient: are your customers entitled to your
modifications? No. They are merely _utilizing_ your service.
This is the same distinction between "use" and "utilize" that
GPL proponents try to obfuscate, only this time it is working
against them.
Likewise, I could that GCC, modify it, make a compiler that
generates vastly superior code, use it to compile the stock
GCC, get a compiler that compiles the same unimproved code
as the stock GCC... but does so three times faster. I now
sell binaries of this new compiler, and give away the source
code: after all, it's nothing more than the stock GCC source
code. I don't have to give away my modified compiler source
code at all, any more than I have to give away the source code
to the DEC/Compaq Alpha compiler when I compile GCC using it
and get a faster, tighter GCC binary as a result.
So much for any "performance for profit" clause which might
come along later being worked around. Until and unless the
entire software industry moves to the new model, _any_ new
model can be worked around, within the scope of it having to
be able to coexist with the current model for it to be able
to get anywhere.
> >There is a Ricoh photocopier and a Ricoh document capture
> >device, both based on FreeBSD. I rather seriously doubt
> >that they ship the code in such a state that you could get
> >a command line, period.
>
> I'll have to check with Steve Savitzky on this. (He's a
> strong open source advocate within Ricoh and may have
> driven this choice.) My guess is that you can get a
> command line for the purpose of servicing the machine,
> perhaps via a TTY port inside the case. But that's not
> the point. Even if YOU can't get the command line,
> I'll bet their GUI invokes command line utilities.
Doubtful. CGIs are underpowered, and scripted CGIs will
always lose out, performance-wise, to compiled code. If
you are right, then someone is just going to build the same
product, throw out the scripting, and take their market away
from them, based on higher performance on equivalent CPU
cycles, or the same performance on lower cost hardware with
lesser CPU cycles. Binary always beats scripts on everything
but prototyping. Scripts are not a good idea for deployment,
since they are fragile in the face of system upgrades and
other changes which might change the underlying components
implementing their functionality (e.g.: grep), and since it
is almost impossible to do formal verification against a
script: you'd have to verify every system comonent with
which the script interacted, and then you'd have to invent a
formal validation tool for sh or perl, which while not quite
an NP-incomplete problem, would be close enough for the amount
of time remaining before your product is obsolete.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
tlam...@primenet.com
> >Warp would install on my current hardware, but having also bought
> >Partition Magic, I have found Boot Magic to be a very good replacement.
>
> Do the IBM Boot Manager and Boot Magic replace the BIOS hard disk code
> as OnTrack Disk Manager does? It seems to me that this is what might be
> needed to get things working if the original AT BIOS can't handle the
> drive.
You are speaking about the LBA emulation mode, which uses the
boot sector to load a TSR that handles LBA mode by doing
translation/augmentation of the requests to the disk which
are normally fielded by the BIOS.
The answer is "No, they do not do this".
This is not relevent to the ThinkPad problem, since that's
related to the BIOS not having the FreeBSD partition ID in
their list of sacred partition IDs. They have the Linux
partition ID in this list in recent BIOS.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
w...@softweyr.com
>
> > I'd be concerned about that, too. We've studied the issue and have decided
> > that to put GPLed code in the standard system would be dangerous. It does
> > not appear to be a problem for optional components, so we may use GPL code
> > for elective add-on products. This even drove us to use PostgreSQL rather
> > than MySQL in our product, though MySQL would have been a better fit.
>
> The pre-GPL license on MySQL was actually incredibly _worse_
> than the GPL.
>
> > I must say I like pgsql a lot better.
>
> I keep meaning to play with this; does it support triggered
> mutual replication between two hosts running the code? I
It does support triggers, but I don't think it does replication.
> really want fault tolerance, load balancing, and automatic
> fail-over (basically, by having the load all move to one
> machine instead of two [actually more complicated], so that
> everyone gets degraded service, instead of some number being
> denied service entirely).
You might be able to do some interesting tricks with the commit code
for the generational mechanism. In PostgreSQL 7, there is a finite
point in time where every commit moves from a "new generation" record
to being fully integrated with the main data store; this might be an
excellent time to replicate the last phase of the commit across replicated
servers.
> I don't have triggers in the code, but I actuall have MySQL
> set up for mutual replication via log replay, so that the
> database and its replica stay more or less synchornized.
What sort of replay interval do you use -- more or less continuously?
I find MySQL to be unstable and rather toy-like compared to PG, which I've
not had a single problem with yet. The enumeration types in MySQL are
missed, though.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
w...@softweyr.com http://softweyr.com/
tlam...@primenet.com
Too bad; it's a requirement for my application. 8-(.
> > I don't have triggers in the code, but I actuall have MySQL
> > set up for mutual replication via log replay, so that the
> > database and its replica stay more or less synchornized.
>
> What sort of replay interval do you use -- more or less continuously?
Yes. It will effectively check every few minutes, and replicate
data not involved in an active session. An active session will,
by definition, have data private from all other sessions, and it
is this data that I'm interested in replicating (and only this
data).
If I had a trigger, I could delay the response to the client
until after the trigger had notified the replicas to replicate,
and they had done so (still have the problem of a downed server,
though).
> I find MySQL to be unstable and rather toy-like compared to PG,
> which I've not had a single problem with yet. The enumeration
> types in MySQL are missed, though.
Other than having to become the defacto AIX port maintainer to
use it on AIX and have any real chance of being able to upgrade
and have the next version work, I don't really have a problem
with MySQL (at least technically; I dislike its new license as
much as its old, but it's tactical, not strategic, so I don't
care that much).
The biggest problem is new data creates, and that's handled by
assigning record numbers partially based on a common space,
and partially on a reserved per server space. This lets me
create records without an inter-server interlock, since I know
all records created in one server will be prefixed with one 8-bit
value, and all records in the second server will have a different
8-bit value. Obviously, these values are externally configured,
rather than being in the database. 8-) 8-).
The delete replication problem is more ugly; if I get a server
that is not the same as my previous server, and I deleted on a
previous server, then when I iterate "my" records, I will see
deleted records "reappear" until the delete is replicated.
This problem also exists to a lesser extent in other data
change operations.
Creates are really not a problem, since connecting to server B,
after a create on server A, before replication to B, means that
the unreplicated data object is still "on its way" to server B.
Since I have a data object propagation delay from external
store and forward processing to get into A in the first place,
I can treat the data as "on its way" with no ill effects. The
round-trip from a client back to the same client also has a
latency, so even if a client sends a data object to itself, a
delay in propagation to the "slave" (all servers not getting the
data first are effectively "slaves") just looks like normal
latency.
I can maintain "synchronized/unsynchronized" state in an external
directory (I have an LDAP directory specifically for this type of
state information), but I have to modify LDAP replication to have
an "active listener list" off the master for this to be efficient
(the interval is like the TTL on an SOA update on a DNS sever with
notifications turned on, when using a stealth primary, and doing
DNSUPDAT against the primary, but reading from the secondary; I
basically have to implement "notifications" for LDAP).
With this information in hand, I could support an "unsynchronized"
DN that I would use, if present, to bind to the up to date server,
instead of attempting to load-balance. I'm at a loss as to what
to do about the case of a delete-unsynchronized-crash, since it
means that I can't use the replica until its synchronized. I
have the same problem with new data on the way in, since I want
to write it to the "most current" server (obviously), so I would
have to seperately queue that data until it could be delivered
(ugh). I would also be introducing a single point of failure,
since like DNS, the relationship between LDAP replicas is also
"master/slaves", so if the master goes down, an attempt to change
data in a slave would result in a referral to the master, and the
master is down. I _could_ define all unprocessable updates as
"in progress", but then the "most recent" state tracking becomes
queued, as well, so I couldn't permit deletes/changes until after
propagation.
Getting sick yet? 8-) 8-| 8-( 8-P 8-O...
Anyway, it's an interesting problem. Not storing volatile state
in the directory, I'm currently sitting at a single point of
failure only on the servers which serve the data, since I have
to marry the client to a particular server, and keep a hot
spare standing by on the otherside of a dual ported RAID array
(ugly, but it works; I supose I could use AFS, as well, but CODA
doesn't cut it, and neither does NFS).
Hope you're having as much fun in your project. }B-).
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
b...@skynet.be
> IBM does not sell InterJets, any more than your local cable
> company sells set-top boxes: IBM sells services. Since an
> end user does not _buy_ an InterJet, they are not entitled to
> the source code, even if it was all contaminated: they are
> not being sold the software.
Right. This is one of the key reasons why I never considered
getting an InterJet. If someone *sold* a BSD-based device that is
otherwise identical to this, I would have bought one in a nanosecond,
but I don't want to buy a Linux-based Qube, nor do I want to shackle
myself forever to a service provider.
Everyone is getting into the "give away a piece of hardware that
does something that used to be free and sell the services" business
model, but not everyone is buying it.
I'm not going to pay TiVo $$$ per month to take an electronic TV
schedule (the contents of which are printed for "free" in newspapers
and magazines around the world) and then have a computer digitally
record the stuff I want to watch.
If someone wants to *sell* me the box that does this via other
services that are already available (via broadcast during the
vertical blanking interval on PBS stations, etc...), I'll be more
than happy to spend lots of extra money to get that, but I simply
refuse to shackle myself to buying a set of services for the rest of
my life.
--
These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <b...@skynet.be> || Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
rs...@physics.iisc.ernet.in
Brett Glass said on Nov 30, 2000 at 17:10:40:
>
> Also, proponents of the GPL are now opting for an expanded
> requirement based on the notion of "performance for profit."
> Just running the code in a situation where you made money
> from it would trigger a requirement to forfeit one's work.
Typical Brett bullshit. What some proponents of GPL are suggesting
is that the GPL should cover ASP's -- people who don't distribute
the code itself in either source or binary form, but set it up on
their server and allow other people should use it via the web.
Personally it looks like a bad idea to me, and hard to enforce, but
it's quite different from a generic "situation where you made money
from it".
There's a sort of preview of GPL v3 at
http://www.newsforge.com/article.pl?sid=00/11/01/1636202
which largely agrees with what Stallman seems to be saying in other
places too.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
tlam...@primenet.com
> > company sells set-top boxes: IBM sells services. Since an
> > end user does not _buy_ an InterJet, they are not entitled to
> > the source code, even if it was all contaminated: they are
> > not being sold the software.
>
> Right. This is one of the key reasons why I never considered
> getting an InterJet. If someone *sold* a BSD-based device that is
> otherwise identical to this, I would have bought one in a nanosecond,
> but I don't want to buy a Linux-based Qube, nor do I want to shackle
> myself forever to a service provider.
Whistle sold InterJets; you could have bought one then. There is
even an aftermarket for setting a root password, adding more disk,
adding more RAM, and adding additional connectivity options, like
a faster modem (if you have the old box).
As far as the Cobalt stuff goes, NetBSD runs on the x86 RAQ and
Qube things, so getting FreeBSD going would probably be trivial,
if someone hasn't done it already.
> Everyone is getting into the "give away a piece of hardware that
> does something that used to be free and sell the services" business
> model, but not everyone is buying it.
FWIW: I agree that this model is fundamentally flawed; I think
the current dearth of funding for the ASP boondoggle and the
crashes left and right of the companies trying this model are
good indicators that it's not a long-term win.
That said, it's my opinion that IBM could sell InterJets with
little risk, if they wanted to (you can buy a Cobalt box through
REQCAT, the IBM internal purchasing facility, but not an InterJet).
IMO, there are other revenue models that _will_ work; I have an
outsourced service I've been working on, and I've identified 7
revenue models, only 3 of which are traditional, and only 1 of
which smacks of an ASP (I'm willing to commit to trying it, even
knowing in my heart that it'll fail, to get V.C. buy-in, after
which I'll convert to one or more of the others before letting
the mandate burn enough capitol to hurt me, since I know at
least two of them are killer models for that type of service; I
would find this route disingenuous enough that it'd be very
distasteful for me. I rather think I can find a V.C. with brains
or at least a healthy fear of ASP models these days, anyway).
> I'm not going to pay TiVo $$$ per month to take an electronic TV
> schedule (the contents of which are printed for "free" in newspapers
> and magazines around the world) and then have a computer digitally
> record the stuff I want to watch.
This is my problem with the so-called "Internet appliances"
that make you sign up for service from a particular provider,
and then deeply "discount" the hardware -- actually not giving
a discount at all, but instead amortizing the cost over the
service contract lifetime.
The companies that are selling these things, and then bitching
about people hacking them (because people want cool hardware,
and are willing to pay to play with it, if they are early
adopters) are missing the whole point.
I'll state this as fact: It's the applications that your
customers apply your product to _in spite of you_ that will be
"_the killer app_" for your product, not all of the nice little
corrals you've assembled in your stockyard to guide them into
your preferred revenue pens.
Or to make it short... sell what people want to buy, _not_ what
you want to sell.
Or a little longer.. to _hell_ with what you intended for your
product, if your customer wants to use your nifty multifunction
wrench as a hammer, then you should probably make a decision as
to the relative size of the multifunction wrench and hammer
markets. Once you do that, you get to decide whether you want
to sell both hammers and multifunction wrenches, add a hammer
head to the end of your multifunction wrench, or say "to hell
with it! I'm a hammer manufacturer! Print up new business cards!".
> If someone wants to *sell* me the box that does this via other
> services that are already available (via broadcast during the
> vertical blanking interval on PBS stations, etc...), I'll be more
> than happy to spend lots of extra money to get that, but I simply
> refuse to shackle myself to buying a set of services for the rest of
> my life.
Broadcasting the information you need, or offering it for free
through any internet connection that they already have would
turn the box into both a high demand item and a commodity over
night. I tend to think that broadcast would be more viable
(less moving parts to hook together the hard way), but you'd
have to lose a lot of your window through the standardization
needed to get the buy-in. Your margins would go from 30-40%,
down to 6%, as other people built boxes to use the same info.
You might be able to get away with this if the lifecycle of the
product was guaranteed to be 3 years or less, by offering the
service part toll free. Actually, I think the timing window on
this will open in 2002, given the conversion schedule for
digital broadcast (at least in the U.S.). If you could get
the local broadcaster to provide the programming data as part
of their signal, then 6% is OK, if you expect a lifetime of 3
years or more, since it all averages out. You'll just have to
content yourself with being a Walmart instead of a Woolworth's
(yeah, hard decision, that). If you could build brand, then
you could probably charge a premium for being a premium product,
in peoples minds, whether or not in reality.
Put another way: do you see a lot of VCR+ codes being published
in your local television guides, or the hardware for it out
there? How successful was DIVX? Pushing standards is not cheap,
and tends to benefit your competition as much as you, unless you
are prepared to execute on a dime; most sane standards are only
tactical. Attempts to make standards into something strategic is
usually not sane, unless you already have a monopoly.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message
tlam...@primenet.com
> > requirement based on the notion of "performance for profit."
> > Just running the code in a situation where you made money
> > from it would trigger a requirement to forfeit one's work.
>
> Typical Brett bullshit. What some proponents of GPL are suggesting
> is that the GPL should cover ASP's -- people who don't distribute
> the code itself in either source or binary form, but set it up on
> their server and allow other people should use it via the web.
> Personally it looks like a bad idea to me, and hard to enforce, but
> it's quite different from a generic "situation where you made money
> from it".
Actually, the ASP scenario was exactly how I'd interpreted
Brett's phrase "performance for profit". I just don't think
the model for doing that is going to be successful.
I'll agree that Brett ratholed into an adjacent topic, though.
> There's a sort of preview of GPL v3 at
> http://www.newsforge.com/article.pl?sid=00/11/01/1636202
> which largely agrees with what Stallman seems to be saying in other
> places too.
Stallman also specifically references the term "performance".
His concern is to get people who would not otherwise use the
GPL, to use the GPL.
The main thrust of his point is scripting languages, but it
appears to me to be "the camel's nose", since he doesn't
limit the performance to scripting languages. He presumes
that the payback of having access to modified (he seems to
assume tha this equals "improved", rather than "trade dress")
is enough to pay back the original company for releasing the
code that is not currently being released, under the GPL.
He may have a point on scripts. Scripts are generally in
the category "throw away code" (the same place I choose to
put "fetchmail"), and so cost relatively little to create.
If the creation cost is very low, then the amount one needs
to benefit from the code in order to amortize developement
costs is also very low, and so it could be that the value
they get back would easily exceed the value they lose by
releasing the code.
If he ties in performance in a general sense, though, he will
poison-pill the code: code that elects the license (even if
the clause is at the authors discretion) will prevent legal
use of GPL'ed code that must be "performed" in binary, by
linking against OS libraries, since the requirement becomes
providing all necessary code, as source, that is needed to
repeat the performance.
His ideology may eventually win (IMO, to the detriment of us
all), but I don't think that he is going to be able to force
the issue this way; it is more likely he will slit his own
throat with the attempt. Of course, this was always a
danger of the "or later version of the license".
I also see it as being problematic for things like Linux,
which unlike the FSF tools, accept contributions without
having to have the rights granted to a single legal
entity. The problem with that has always been that any
author could claim version differences for their code
contributed to the project. Having a trap-door clause
that lets any author do the same with a performance
clause will, I predict, open a can of worms that could
kill the GPL for good.
Increasing the amount of throw away code sitting in FTP
archives, being indexed by search engines, can't really
be good for anyone, though...
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
b...@skynet.be
> Whistle sold InterJets; you could have bought one then.
Sadly, I didn't find out about them until the announcement that
IBM was buying the company, and didn't think that the business model
would be changing, so I didn't race around trying to scrape up the
cash to buy one on the spur of the moment.
> As far as the Cobalt stuff goes, NetBSD runs on the x86 RAQ and
> Qube things, so getting FreeBSD going would probably be trivial,
> if someone hasn't done it already.
I'd be interested in hearing more about this, if anyone has any
information.
> Put another way: do you see a lot of VCR+ codes being published
> in your local television guides, or the hardware for it out
> there?
I'm not in the US anymore, so I can't say whether VCR+ still has
any penetration. I know that, as of the time I left (a couple of
years ago), they were still in wide use, and had been for a number of
years. IIRC, virtually all VCRs sold had this feature.
> How successful was DIVX?
Thankfully, it died very quickly. However, because of it, I will
never again buy anything at Circuit City.
--
These are my opinions -- not to be taken as official Skynet policy
======================================================================
Brad Knowles, <b...@skynet.be> || Belgacom Skynet SA/NV
Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124
Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels
http://www.skynet.be || Belgium
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
mwl...@blackhelicopters.org
> >Only if you link against it. When was the last time you
> >linked against "grep"?
> In this case, it's infectious in a different way: It is
> eliminating truly free alternatives. Use it, and you are
> facilitating another prong of the GPL agenda: to snuff
> out other options. The fact that FreeBSD does not provide
> a non-GPLed grep which is BSD-licensed means that the FSF
> has succeeded.
/usr/ports/text/freegrep
Not up to speed yet, but I bet the author would love patches.
--
Michael Lucas
mwl...@blackhelicopters.org
http://www.blackhelicopters.org/~mwlucas/
Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message
rs...@physics.iisc.ernet.in
> His ideology may eventually win (IMO, to the detriment of us
> all), but I don't think that he is going to be able to force
> the issue this way; it is more likely he will slit his own
> throat with the attempt. Of course, this was always a
> danger of the "or later version of the license".
As I said, I think this ASP clause is a bad idea. But I also think
ASPs are a bad idea and clueful people will prefer running
well-maintained code on their own systems. I don't even think the
usual arguments for freeing the code (fixing your own bugs, etc, as in
RMS's old story of the printer with the closed-source driver) work
for freeing ASP code. What will you do after you fix the bugs: set up
your own ASP server? If you can do that you didn't need to use an ASP
in the first place.
But the "or later version" is an option only, and code which is now
distributed under GPL2 can be distributed under GPL2 for all time.
Moreover, the author can choose not to allow that option. I seem to
remember Linus removing the "or later version" clause for the linux
kernel recently, though I may be wrong.
> I also see it as being problematic for things like Linux,
> which unlike the FSF tools, accept contributions without
> having to have the rights granted to a single legal
> entity. The problem with that has always been that any
> author could claim version differences for their code
> contributed to the project.
In the linux case, Linus could always refuse to accept patches
not contributed under GPL v2.
Rahul.
jcw...@nwlink.com
> I keep meaning to play with this; does it support triggered
> mutual replication between two hosts running the code? I
> really want fault tolerance, load balancing, and automatic
> fail-over (basically, by having the load all move to one
> machine instead of two [actually more complicated], so that
> everyone gets degraded service, instead of some number being
> denied service entirely).
Marc Fournier is both a FreeBSD guy and a Postgres guy. I think he may be
a developer for both. I have seen him active on lists for both projects.
I will take my lame newbie SQL shot at an answer. Postgres supports
triggers and transactions. I presume one could use these to keep two
seperate databases in synch. I don't know much more about it than these
functionalities exist.
Thank you,
Jason C. Wells
br...@lariat.org
>Actually, the ASP scenario was exactly how I'd interpreted
>Brett's phrase "performance for profit". I just don't think
>the model for doing that is going to be successful.
The phrase isn't mine. It's a standard part of music copyright
law, and Perens was the first to suggest that GPL activists
attempt to apply it to software.
>I'll agree that Brett ratholed into an adjacent topic, though.
I don't think it was "ratholing" at all. IBM's behavior is
important, and as you have already mentioned, it is influenced
by concerns about the GPL.
>His concern is to get people who would not otherwise use the
>GPL, to use the GPL.
And then to "trap" companies with it. Stallman specifically
advocates this in his essay "Why Software Should Not Have
Owners" -- an essay which, by the way, he hastily toned down
a few days after I pointed out his original exhortation to
programmers to sabotage their organizations.
>The main thrust of his point is scripting languages, but it
>appears to me to be "the camel's nose", since he doesn't
>limit the performance to scripting languages. He presumes
>that the payback of having access to modified (he seems to
>assume tha this equals "improved", rather than "trade dress")
>is enough to pay back the original company for releasing the
>code that is not currently being released, under the GPL.
>
>He may have a point on scripts. Scripts are generally in
>the category "throw away code" (the same place I choose to
>put "fetchmail"), and so cost relatively little to create.
>If the creation cost is very low, then the amount one needs
>to benefit from the code in order to amortize developement
>costs is also very low, and so it could be that the value
>they get back would easily exceed the value they lose by
>releasing the code.
The problem is that some programs written in "scripting
languages" are not throw-aways at all. Many companies who
add value to arcane systems by providing them with user-
friendly GUIs (of which Whistle was one!) do it via these
languages. I've worked for companies whose entire base of
IP (and expertise!) was embodied in Perl scripts.
>If he ties in performance in a general sense, though, he will
>poison-pill the code: code that elects the license (even if
>the clause is at the authors discretion) will prevent legal
>use of GPL'ed code that must be "performed" in binary, by
>linking against OS libraries, since the requirement becomes
>providing all necessary code, as source, that is needed to
>repeat the performance.
It could be worse than that. Since FreeBSD is compiled by GCC,
he could set things up so that that any binary of FreeBSD that's
compiled by a GPL3ed version of GCC is considered to be a
"performance" of a GPLed program, with all of the effects that
this might entail. He has a strong incentive to do this, since
it would throw alternatives to Linux -- including BeOS! -- into
turmoil. I personally believe that Stallman, Perens, and
others WILL attempt to close this noose; it's just a matter of
WHEN they'll do it.
>His ideology may eventually win (IMO, to the detriment of us
>all), but I don't think that he is going to be able to force
>the issue this way; it is more likely he will slit his own
>throat with the attempt. Of course, this was always a
>danger of the "or later version of the license".
What's more, all GNU utilities will immediately go to the new
license. This poses a big danger for FreeBSD, because it
tracks these utilities. Unless it freezes these utilities
at the last version that was released under the previous
license, and reimplements everything fast, it will immediately
be "infected" by the new requirements in a detrimental way.
>I also see it as being problematic for things like Linux,
>which unlike the FSF tools, accept contributions without
>having to have the rights granted to a single legal
>entity. The problem with that has always been that any
>author could claim version differences for their code
>contributed to the project. Having a trap-door clause
>that lets any author do the same with a performance
>clause will, I predict, open a can of worms that could
>kill the GPL for good.
In theory, yes. But in practice, the FSF will own so much
code that's vital to projects such as FreeBSD that, protest
as they will, they'll be between a rock and a hard place. I
believe that by adopting any GPLed code at all, FreeBSD is
painting itself into a corner. YMMV, of course.
--Brett
br...@lariat.org
>Brett Glass said on Nov 30, 2000 at 17:10:40:
>>
>> Also, proponents of the GPL are now opting for an expanded
>> requirement based on the notion of "performance for profit."
>> Just running the code in a situation where you made money
>> from it would trigger a requirement to forfeit one's work.
>
>Typical Brett bullshit. What some proponents of GPL are suggesting
>is that the GPL should cover ASP's -- people who don't distribute
>the code itself in either source or binary form, but set it up on
>their server and allow other people should use it via the web.
This is not the only situation they want it to cover. See the text
of Bruce Perens' speech at the February 2000 LinuxWorld. Like
Stallman, he explicitly states a desire to use the GPL as a "lever"
to force as many people and companies as possible to forfeit their
work. This goes MUCH farther than ASPs.
tlam...@primenet.com
> > all), but I don't think that he is going to be able to force
> > the issue this way; it is more likely he will slit his own
> > throat with the attempt. Of course, this was always a
> > danger of the "or later version of the license".
>
> ASPs are a bad idea and clueful people will prefer running
> well-maintained code on their own systems. I don't even think the
> usual arguments for freeing the code (fixing your own bugs, etc, as in
> RMS's old story of the printer with the closed-source driver) work
> for freeing ASP code. What will you do after you fix the bugs: set up
> your own ASP server? If you can do that you didn't need to use an ASP
> in the first place.
I actually have to weigh in against this. Logically, this
would mean that I would not buy Stronghold (Apache+SSL+X.509
certificate), since I can have the software for free, now that
OpenSSL includes an RSA implementation, and RSA is off patent.
$1000 is a lot to pay for just a certificate.
The fallacy here is that it devalues the installation and the
productization work that went into the package -- what Geoffrey
Moore calls "the whole product". Frankly, I think that the
idea of a "WhiteHat FreeBSD" has merit because of the value
that could be added through installation and productization
(but the FreeBSD trademark controllers have specifically said
that they would not permit the use of the trademark in that
context).
I think, most free software is only usable by technophiles,
and that a large part of the succes of Linux is attributable
to someone making the technology accessible to non-technophiles.
> But the "or later version" is an option only, and code which is now
> distributed under GPL2 can be distributed under GPL2 for all time.
> Moreover, the author can choose not to allow that option. I seem to
> remember Linus removing the "or later version" clause for the linux
> kernel recently, though I may be wrong.
This was a wise decision, IMO. Spo was the decision to treat
the kernel as a shared library for the purposes of kernel
modules, and several other decisions that have been made in
that same genre: this is where we see the distinction between
GPL ideology, and real-world practicality, most clearly.
> > I also see it as being problematic for things like Linux,
> > which unlike the FSF tools, accept contributions without
> > having to have the rights granted to a single legal
> > entity. The problem with that has always been that any
> > author could claim version differences for their code
> > contributed to the project.
>
> In the linux case, Linus could always refuse to accept patches
> not contributed under GPL v2.
I really doubt that the code is audited that closely, on the
assumption that the contributions in the form of patches are
a derivative work, and thus tmust themselves be GPL'ed. The
problem with this is that if I made my patches against a pre
modified license kernel, and they were incorporated, Linus
can not really legally change the license without violating
my copyright. For the code I've personally contributed, I
have no problem with giving him the rights to do this, but
realize that this is a place where political differences are
fairly prominent within the GPL community itself (I don't
count myself as a member, though I've contributed code to a
dozen or more GPL'ed projects).
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
tlam...@primenet.com
> > Qube things, so getting FreeBSD going would probably be trivial,
> > if someone hasn't done it already.
>
> I'd be interested in hearing more about this, if anyone has any
> information.
Apparently, the Cobalt MIPS runs NetBSD, but the x86 has custom
firmware to load the kernel, and the port to that is in progress
and has not yet been completed.
Sorry for the premature "it works".
rs...@physics.iisc.ernet.in
> > > I also see it as being problematic for things like Linux,
> > > which unlike the FSF tools, accept contributions without
> > > having to have the rights granted to a single legal
> > > entity. The problem with that has always been that any
> > > author could claim version differences for their code
> > > contributed to the project.
> >
> > In the linux case, Linus could always refuse to accept patches
> > not contributed under GPL v2.
>
> I really doubt that the code is audited that closely, on the
> assumption that the contributions in the form of patches are
> a derivative work, and thus tmust themselves be GPL'ed. The
> problem with this is that if I made my patches against a pre
> modified license kernel, and they were incorporated, Linus
> can not really legally change the license without violating
> my copyright. For the code I've personally contributed, I
> have no problem with giving him the rights to do this, but
> realize that this is a place where political differences are
> fairly prominent within the GPL community itself (I don't
> count myself as a member, though I've contributed code to a
> dozen or more GPL'ed projects).
I guess you're right that there is a problem in principle.
In practice, I doubt anyone would end up suing Linus over such
a thing, the worst that may happen is backing out the GPLv3 patches
after they "came to light." Much worse license problems (like KDE)
have been sorted out peacefully. However, if Brett wants to do to
linux what he always claims the GPL folks are trying to do to BSD,
I guess this is a possibility for him...
As for these conspiracy theories about the GPL crowd, Perens is loud
but not really so credible; the only one who counts eventually is
Stallman, and I don't believe he is really anti-BSD. I have
corresponded with him a couple of times, and he seemed to have a high
regard for the BSDs, though they aren't "his" projects. I've heard
the same from people who've met him. Also take a look at
http://www.LinuxMedNews.org/linuxmednews/974769856/index_html
where the original article said
"There are other licenses that have different restrictions,
particularly with regard to commercial use of software such as the
FreeBSD License. The Free Software Foundation does not consider
these licenses to be 'Free' licenses."
and he answers,
"Actually we do consider them free licenses. Both the original BSD
license, and the revised one preferred by the FreeBSD developers (and
adopted by Berkeley a couple of years ago) qualify as free software
licenses, like the X11 license. We have used code available under
these licenses as part of the GNU system since the 1980s."
This is not the main subject of the article and he did not really have
to correct this statement, but he does anyway.
R