I use Mozilla and konqueror mainly, but I
also use dillo when I just quickly want to
look at a non feature heavy web document. It's
limited, but its damn fast..
How is the developer supposed to be liable for
software not working as expected when typically there is no legal relationship whatsoever between
developer and user that might be said to be the basis for these expectations?
There are problems wityh the liability exemption in any case. I don't suppose anyone would think that
a virus writer could avoid liability for damages by making GPLing their creation, so there have to be *some* limits.
Another explanation as to why open source might
start out worse than closed source is Linus'
"Release early, release often" maxim. It's meant
to get the widest class of feedback as early in the development cycle as possible, but of course it bumps up the defect rate in early releases.
Again, it would be interesting to see how open source projects that follow this maxim compare to ones that don't.
It would be interesting to see if outliers in
terms of code quality follow different development
methodologies than the median projects. Eg. does
Twisted Python's much vaunted attachment to
extreme programming make a difference?
Another thought along these lines is: perhaps the
projects that fail often fail due to project
management (in the most Bazaar sense of the word),
rather than the usually heard competing time pressures,
personality conflicts, loss of interest, and so on.
The law as it stands will not sustain
criminal charges, and getting a law passed
that makes DRM mandatory will be impossible
precisely because of
the absurd mismatch between the sizes of the
industries.
The entertainment industry is *not* going to
succeed in making
non-DRM PCs illegal. The size of the entertainment
industry is miniscule compared to the size of the
computer industry, and even if they have influence
beyond their economic weight, they are really
outclassed here. I recall a fun quote by an IBM
lobbyist who called the RIAA "the pimple on the
elephant's ass".
I agree with this, and I think it is quite
possible that the reason that the Supreme Court didn't want to hear this case is because it didn't
provide a good test of the interesting law. My
guess is that they would hear a similar case if the prosecutions case rested solely on violation
of an EULA.
BTW, a few posters appear to think the DMCA provisions can be combined with this precedent to
create very strong anti- reverse engineering safeguards. They shouldn't, since the DMCA is specifically worded to exclude reverse engineering.
I haven't actually read the law, but my guess is that the definition of dumping is either not there
or is one that an economist would regard as sane; the problem is the standards of evidence the law
specifies, or that the courts apply, to establish that dumping exists are not
so sane...
I tend to be suspicious of anti-dumping cases just
because the law has been so badly abused in the past.
It's *possible* that Hynix is using its
subsidy to finance a dumping strategy, but recall what dumping is: it means you sell goods now at below cost in order to win a price war and earn monopoly or oligopoly profits later. It doesn't look to me like Hynix's position is strong enough
to do this.
There are other reasons to sell at
below cost, eg. disastrously bad cashflow, closing
down a product line, etc.
I don't suppose too much of the US computer
industry will be happy about this, seeing as it
is bound to drive up prices when the sector is
on the edge...
The answer to the fifth question is interesting:
Andrew argues that there is a Bazaar-like quality
to Solaris development, since much code is
contributed by non-OS development teams at Sun.
An important aspect of Linus' management is his
anti-roadmap approach to leadership. I wonder how
this compares to Solaris?
In the short term I'm not persuaded by the case for
widespread application of formal methods, but in the long run I think it will
become very important. Two areas I think are areas that I think are most beneficial for formal methods:
firstly verified implementations of network protocols, and journalling file systems.
I can tell you that some of Plan 9's concepts will never make it back to UNIX
There's clearly a lot of work involved in bringing
some of plan 9's characteristics to Linux, but there
is a lot of sympathy for plan 9 among kernel developers, including Linus. A user-mode plan 9
might do wonders for creating the right kind of
experimental environment to bridge these difficulties...
About not putting setuid code in/sbin: quite so,
this is a quirk of the way I've run my systems, and is
surely *not* *recommended*:->... I've stopped
doing this since I discovered super (which is
much less tiresome than sudo).
Porting games from Windows to Linux I think is such
a niche. I gather these folks spend a great deal
of time looking at debugger output, and are
unusually likely to run into kernel mode errors.
The usual home is/bin, which is also supposed to be part of the root filesystem, and usually the criteria for an executable to be in/sbin rather than/bin is that it is setuid or otherwise privileged.
Which UNIXes put sh in/sbin? Linux and FreeBSD don't, and I think Solaris and IRIX don't either.
I guess the point is to limit the number of directories that need to be on the path of root and setuid processes. Makes sense, but still, it seems funny to me...
The court will need to agree that the code put into Linux is a derivative work. Since this code (i) does not contain any SysV code (being a new module) and (ii) does not form part of a SysV system (being part of a linux system), I think this will be a tough agreement for SCO to achieve...
A pet irritation with FreeBSD: ports works well *if* you keep your ports tree synchronised with the current version. If you *want* to mix the current version with old versions (there are reasons), it becomes a pain. Debian is much better at this kind of thing.
Probably a more crucial advantage to Linux in the desktop arena is its much wider range of device drivers. I'm composing this response on an Acer travelmate 340T, which has a touchpad/winmodem/USB mouse all of which work with Linux and don't with FreeBSD.
Given the current headaches about getting the development branch of Linux started, I am beginning to think that the advantages of the orderly world of FreeBSD development are rather bigger than I first presumed.
Slashdot Mirror
I use Mozilla and konqueror mainly, but I also use dillo when I just quickly want to look at a non feature heavy web document. It's limited, but its damn fast..
There are problems wityh the liability exemption in any case. I don't suppose anyone would think that a virus writer could avoid liability for damages by making GPLing their creation, so there have to be *some* limits.
Again, it would be interesting to see how open source projects that follow this maxim compare to ones that don't.
Another thought along these lines is: perhaps the projects that fail often fail due to project management (in the most Bazaar sense of the word), rather than the usually heard competing time pressures, personality conflicts, loss of interest, and so on.
The law as it stands will not sustain criminal charges, and getting a law passed that makes DRM mandatory will be impossible precisely because of the absurd mismatch between the sizes of the industries.
The entertainment industry is *not* going to succeed in making non-DRM PCs illegal. The size of the entertainment industry is miniscule compared to the size of the computer industry, and even if they have influence beyond their economic weight, they are really outclassed here. I recall a fun quote by an IBM lobbyist who called the RIAA "the pimple on the elephant's ass".
BTW, a few posters appear to think the DMCA provisions can be combined with this precedent to create very strong anti- reverse engineering safeguards. They shouldn't, since the DMCA is specifically worded to exclude reverse engineering.
I haven't actually read the law, but my guess is that the definition of dumping is either not there or is one that an economist would regard as sane; the problem is the standards of evidence the law specifies, or that the courts apply, to establish that dumping exists are not so sane...
It's *possible* that Hynix is using its subsidy to finance a dumping strategy, but recall what dumping is: it means you sell goods now at below cost in order to win a price war and earn monopoly or oligopoly profits later. It doesn't look to me like Hynix's position is strong enough to do this.
There are other reasons to sell at below cost, eg. disastrously bad cashflow, closing down a product line, etc.
I don't suppose too much of the US computer industry will be happy about this, seeing as it is bound to drive up prices when the sector is on the edge...
An important aspect of Linus' management is his anti-roadmap approach to leadership. I wonder how this compares to Solaris?
In the short term I'm not persuaded by the case for widespread application of formal methods, but in the long run I think it will become very important. Two areas I think are areas that I think are most beneficial for formal methods: firstly verified implementations of network protocols, and journalling file systems.
There's clearly a lot of work involved in bringing some of plan 9's characteristics to Linux, but there is a lot of sympathy for plan 9 among kernel developers, including Linus. A user-mode plan 9 might do wonders for creating the right kind of experimental environment to bridge these difficulties...
I've rather lost track of ICANN politics over the past year. Who's left on the ICANN board who can be trusted to act in the public interest?
About not putting setuid code in /sbin: quite so,
this is a quirk of the way I've run my systems, and is
surely *not* *recommended* :-> ... I've stopped
doing this since I discovered super (which is
much less tiresome than sudo).
Porting games from Windows to Linux I think is such a niche. I gather these folks spend a great deal of time looking at debugger output, and are unusually likely to run into kernel mode errors.
Which UNIXes put sh in
I guess the point is to limit the number of directories that need to be on the path of root and setuid processes. Makes sense, but still, it seems funny to me...
Very nice. Shame my laptop won't work with Plan-9, I was tempted to put a copy on it.
/ .
If you found the Plan-9 FAQ but saw the URL to the Plan-9 wiki was broken, try http://plan9.bell-labs.com/wiki/plan9/plan_9_wiki
Are there really UNIXes that put sh in /sbin?
Sun's contract with SCO gives it rights over
derivative UNIXes it makes.
The court will need to agree that the code put into Linux is a derivative work. Since this code (i) does not contain any SysV code (being a new module) and (ii) does not form part of a SysV system (being part of a linux system), I think this will be a tough agreement for SCO to achieve...
Read the post, stupido. I don't *want* to synchronise my ports tree.
A pet irritation with FreeBSD: ports works well *if* you keep your ports tree synchronised with the current version. If you *want* to mix the current version with old versions (there are reasons), it becomes a pain. Debian is much better at this kind of thing.
Given the current headaches about getting the development branch of Linux started, I am beginning to think that the advantages of the orderly world of FreeBSD development are rather bigger than I first presumed.