There is a group of German lawyers who have founded
IFROSS, a
private institution to study legal problems with
open source in Germany. They have quite a few publication on this issue, including a detailed
study of the GPL.
They conclude that under German law, the authors liability is
most probably limited to intentional damage and
gross negligence.
Also, they argue that clause 2 (allowing
modifications) and clause 9 ("and any later
version") may be problematic.
The problem with clause 2 is that modifications of
a program may (e.g.) tarnish the reputation of the author, and legally one cannot waive one's right
to sue for that (at least in Germany). Also,
apparently the author may claim that modifications
violate the artistic integrity of her work. However,
the analysis foresees problems mainly for
works of art, rather than utility programs.
Clause 9 is problematic because here the author
waives rights for future usage modes that she
cannot yet foresee. But licences can only apply
to usage modes presently known.
The baseline of problems with the GPL seems to be
that in Germany (and, I think, also in other
european states), waiving or selling of
basic personal
rights is usually not possible.
Perhaps there will be some pressure now towards bullet proofing
your code, but until customers stop demanding more features and
start demanding quality code, software won't change.
Capitalism is all about creating new needs
that make people demand your product (which
in reality is as unneccessary as 95 per cent of all
other products), because capitalism depends on continuous growth, which can only be achieved by
creating new products - and demand for them - all the time. So-called market demand is quite frequently created by good marketing/advertising. IMHO, the lack of quality software is mainly due to the failure of
marketing departments to create a demand for it.
[an objects gravity is "centered" at it's center, thus the gravitational force at the center of the > earth is infinite (r = 0)].
beg your pardon, but that's nonsense. the formula
you quoted (Gravitational Force = GMm/r^2) is only
valid for two masses m and M, if their centres
of mass are distant by r, and both are spherical,
or can be considered as point-like (e.g. if they are small compared to r). in particular, it is
not valid if their smallest enclosing spheres overlap.
the case of a mass m within (say, a cavity of) mass M is different, and the above formula
is invalid. at the centre of the earth, earth's
gravitational force is zero, just as one would
expect - in the centre of a symmetric mass
distribution, all forces cancel.
in a subway tunnel, your formula would also
be invalid, strictly speaking, but the difference
would be insignificant.
I would agree that even in the open-source world,
many apps are popular because (a) they were the
first on the market, or (b) have the better marketing department.
However, having coded in C both for MySQL and
PostgreSQL, I have to say that the MySQL docs
are clearly better, and that their client library is more feature-rich than PostgrSQL. The MySQL
database may lack features, but on the client side
it is much easier to get simple things running.
After reading the article, I would say he tries to
use XML for something it is not very suitable for, and
argues that in this case the available libraries
are not useful (surprise...).
XML is not a stream - it has a hierarchical tree
structure, and IMHO is not useful for anything that (a)
by its very nature is a continuous stream of data
(say, a log file), or (b) wants to be processed as a
stream (because it's big, and would require too much
memory to be handled as a single data structure).
The problem seems to be that XML is good for
portability and standardization, and therefore is abused for things it's not well suited for (the well-known 'if all
you have is a hammer, every problem looks like a nail' syndrome).
The thing I would be most interested in would be
some solid, quantitative data on the
success/usefulness of various types of security
software/solutions (like firewalls, IDSs, etc.).
Like, what percentage of attacks are actually prevented
by such measures ? E.g., how many sites have
been protected from the SQL Slammer worm by
their firewall, and on how many sites has the
firewall failed, and why ?
Despite the flood of publications entering the market, I have never seen any in-depth discussion of quantifyable merits of security software. Usually
the argument for investments into security is
that you will save the cost caused by incidents
(so the hidden assumption seems to be that
the measures taken will be 100 per cent effective ?). Does this book provide any more insight ?
Depends very much on the popularity of an application. From my own experience, probably only
the Top 500 (maybe the Top 1000) get enough
feedback to maintain some level of quality.
On the other hand, every day design flaws and bugs
are found in some proprietary applications.
The fact that in the 'proprietary world' you
could enforce 'great developmental practices', apparently does not mean that it is really done.
Furthermore, customers look for features, and
certainly do not easily perceive the value of
good design in the code they never see.
Therefore, in the 'proprietary world' there is
little (or no) incentive to follow 'great developmental practices', whatever these may be.
If anywhere at all, I would expect good design
in OSS where return on investment is much less of
an issue sometimes.
I don't have any experience with PDL, but the
name clearly alludes to IDL. Does that mean that there is any
compatibility between both ? Can PDL interpret
an IDL macro ?
I develop and maintain a few small utilities on sf.net, and on roughly a thousand downloads all i have received are two bug reports.
I am authors of a few apps, some popular, some less.
According to my experience, your rate of bug reports
is quite average. There simply is little
feedback from users, and the given enough
eyeballs, all bugs are shallow really only
applies to the very popular applications. I would
guess that anything below popularity rank
500-1000 on freshmeat has too little feedback for
efficient bug hunting.
As for features, I would say the rate of requests is similar
to that for bug reports.
Almost invariably, they're on the list because their ISP persistently ignores spam complaints and prefers spammer money to honest customer money.
Bullshit. My ISP actively fights spam, yet still it
gets blocked by SPEWS. SPEWS is blocking so overzealously
that it's just a matter of (bad) luck
whether you get blocked or not. And even if your
ISP is spam-friendly, why should you switch
if bad luck can/will strike everywhere ?
Fighting spammers by causing as much collateral damage as possible (like SPEWS) does not work, and
it is simple to see why:
1. I am customer of a small ISP. I don't send spam,
and my ISP actively fights spam. Nevertheless, my
ISP is on SPEWS - bad luck, wrong netblock.
2. I have zero incentive to change my ISP, and thus my ISP has zero incentive to
put pressure on their upstream network operator.
3. Why ? Because I am blocked by bad luck,
nothing else. I could change the ISP, but any new ISP might have the same bad luck.
Changing providers will cost money, and will not
secure me from future problems of that sort.
In short: the overzealous blocking by SPEWS
removes any incentive to change ISP or exert any
pressure on upstream providers. If it's just bad
luck to be blocked, it may happen anywhere and anytime, and changing providers does not make any sense.
In my experience, it is always a good idea to test both compilers for your specific application. I have seen cases where icc performs far worse than gcc, apparently because the compiled code causes much more page faults.
On the other hand, icc supports OpenMP, which means
that on an SMP machine you might be able to parallelize a loop by inserting just a single line of code, like:
#pragma omp parallel...
I just re-installed win98 on a (dual-boot)
machine because
when some user scanned a few pictures, upon saving
the scans to disk win98 managed to completely trash
the C: partition. Fortunately there was GNU parted and a spare disk with a copy of that partition.
I also think I am spending much more time on windows
than on Linux, because there are so much more annoying problems to fix on the windows side.
These blacklists tend to block one or more complete
C-class netblock(s) for each spammer, so you will
loose most probably as much (or more) legitimate e-mail as with filtering by content.
I am not talking from an ISP's pespective, rather from the perspective of the small customer of an
equally small web hosting provider. Our provider
actively fights spam - they even go after bad
formmail scripts - but neither we nor our provider
has any influence on the network operator (Level3).
"internally multiplexes the connections" usually means a select(2) loop in a single-threaded server rather than having a separate thread or subprocess for each connection.
As much as I dislike spam (2/3 of my daily mail is spam), I dislike spamhouse/spews as well. Their idea of blocking complete netblocks is IMHO an utter failure - the damage is done to many small websites that are on the netblock perchance.
The 'bad guys' are too high up to care if one of their C-class netblocks has some problem. After all, it is the webhosting companies on that netblock who will loose customers, not the network operators.
While this may not end the conspiracy theories, detecting the Apollo lunar landers on the Moon would
be a spectacular demonstration of the VLTs' superb
performance.
The VLT can achieve a resolution as good as
the Hubble Space Telescope (and far better, once the interferometer is installed).
Unfortunately, it has neither the staff nor
the money of the HST public relation office, so pretty much nobody outside the scientific community knows that.
Unfortunately, almost nobody cares to verify
signatures. And exactly nobody ever tries to
verify the signature key.
And worst of all, gpg has no option that would
enforce checking the signature on signed data,
or at least would make it difficult to access them
without checking the signature.
I was talking about the problems of upstream authors, not users. With "dead end" I mean that
bugs that are reported to distros often don't
get through to the upstream author. Which is bad,
because it deprives the author from the feedback
required for improving her software.
Re:damaged error handling, incompatible discs, yay
on
BMG Stops Producing CDs
·
· Score: 3, Insightful
It is quite revealing that
apparently no slashdot reader ever mentions the number one reason to copy a CD: children.
It is a widely recommended practice for parents with
a small child to burn and use copies of their
CDs, and keep the 'master' (the original CD) in a safe place.
That's true, sadly. In principle, it should be a good thing to have ones application in a distro, because the number of potential users will be much larger, hence the application more thoroughly tested. In practice, the upstream author typically will not see the bug reports at all.
If it is not, they forward the report (or fix) upstream.
Umm, no, at least not in general (may depend on the maintainer). Bug reports to distributors are often
a dead end - the minimum you should do is looking in the man pages or docs for the e-mail of the
upstream author,and cc her the bug report.
IAASA - I am a software author, I know what I'm talking about.
I don't care whether an installer is graphical or
not, as long as it works. And having installed
Debian, Redhat, and Gentoo lately, I have to say
that the Debian install was the only one that went
without even the slightest problem, quite contrary
to Redhat (failed when configuring X, machine
locked up, reboot, finish install manually) and Gentoo (trouble with the PCMCIA
ethernet card).
Plus, Debian doesn't have a multi-Gb default
install full of crap, contrary to some other distros...
Slashdot Mirror
They conclude that under German law, the authors liability is most probably limited to intentional damage and gross negligence.
Also, they argue that clause 2 (allowing modifications) and clause 9 ("and any later version") may be problematic. The problem with clause 2 is that modifications of a program may (e.g.) tarnish the reputation of the author, and legally one cannot waive one's right to sue for that (at least in Germany). Also, apparently the author may claim that modifications violate the artistic integrity of her work. However, the analysis foresees problems mainly for works of art, rather than utility programs. Clause 9 is problematic because here the author waives rights for future usage modes that she cannot yet foresee. But licences can only apply to usage modes presently known.
The baseline of problems with the GPL seems to be that in Germany (and, I think, also in other european states), waiving or selling of basic personal rights is usually not possible.
Capitalism is all about creating new needs that make people demand your product (which in reality is as unneccessary as 95 per cent of all other products), because capitalism depends on continuous growth, which can only be achieved by creating new products - and demand for them - all the time. So-called market demand is quite frequently created by good marketing/advertising. IMHO, the lack of quality software is mainly due to the failure of marketing departments to create a demand for it.
I remember long time ago there was a ./ story that was
basically an advertisement for a product called FreeVeracity.
The product is dead now ...
beg your pardon, but that's nonsense. the formula you quoted (Gravitational Force = GMm/r^2) is only valid for two masses m and M, if their centres of mass are distant by r, and both are spherical, or can be considered as point-like (e.g. if they are small compared to r). in particular, it is not valid if their smallest enclosing spheres overlap.
the case of a mass m within (say, a cavity of) mass M is different, and the above formula is invalid. at the centre of the earth, earth's gravitational force is zero, just as one would expect - in the centre of a symmetric mass distribution, all forces cancel.
in a subway tunnel, your formula would also be invalid, strictly speaking, but the difference would be insignificant.
However, having coded in C both for MySQL and PostgreSQL, I have to say that the MySQL docs are clearly better, and that their client library is more feature-rich than PostgrSQL. The MySQL database may lack features, but on the client side it is much easier to get simple things running.
XML is not a stream - it has a hierarchical tree structure, and IMHO is not useful for anything that (a) by its very nature is a continuous stream of data (say, a log file), or (b) wants to be processed as a stream (because it's big, and would require too much memory to be handled as a single data structure).
The problem seems to be that XML is good for portability and standardization, and therefore is abused for things it's not well suited for (the well-known 'if all you have is a hammer, every problem looks like a nail' syndrome).
Like, what percentage of attacks are actually prevented by such measures ? E.g., how many sites have been protected from the SQL Slammer worm by their firewall, and on how many sites has the firewall failed, and why ?
Despite the flood of publications entering the market, I have never seen any in-depth discussion of quantifyable merits of security software. Usually the argument for investments into security is that you will save the cost caused by incidents (so the hidden assumption seems to be that the measures taken will be 100 per cent effective ?). Does this book provide any more insight ?
Depends very much on the popularity of an application. From my own experience, probably only the Top 500 (maybe the Top 1000) get enough feedback to maintain some level of quality.
On the other hand, every day design flaws and bugs are found in some proprietary applications. The fact that in the 'proprietary world' you could enforce 'great developmental practices', apparently does not mean that it is really done.
Furthermore, customers look for features, and certainly do not easily perceive the value of good design in the code they never see. Therefore, in the 'proprietary world' there is little (or no) incentive to follow 'great developmental practices', whatever these may be. If anywhere at all, I would expect good design in OSS where return on investment is much less of an issue sometimes.
I don't have any experience with PDL, but the name clearly alludes to IDL. Does that mean that there is any compatibility between both ? Can PDL interpret an IDL macro ?
I am authors of a few apps, some popular, some less. According to my experience, your rate of bug reports is quite average. There simply is little feedback from users, and the given enough eyeballs, all bugs are shallow really only applies to the very popular applications. I would guess that anything below popularity rank 500-1000 on freshmeat has too little feedback for efficient bug hunting. As for features, I would say the rate of requests is similar to that for bug reports.
Bullshit. My ISP actively fights spam, yet still it gets blocked by SPEWS. SPEWS is blocking so overzealously that it's just a matter of (bad) luck whether you get blocked or not. And even if your ISP is spam-friendly, why should you switch if bad luck can/will strike everywhere ?
1. I am customer of a small ISP. I don't send spam, and my ISP actively fights spam. Nevertheless, my ISP is on SPEWS - bad luck, wrong netblock.
2. I have zero incentive to change my ISP, and thus my ISP has zero incentive to put pressure on their upstream network operator.
3. Why ? Because I am blocked by bad luck, nothing else. I could change the ISP, but any new ISP might have the same bad luck. Changing providers will cost money, and will not secure me from future problems of that sort.
In short: the overzealous blocking by SPEWS removes any incentive to change ISP or exert any pressure on upstream providers. If it's just bad luck to be blocked, it may happen anywhere and anytime, and changing providers does not make any sense.
On the other hand, icc supports OpenMP, which means that on an SMP machine you might be able to parallelize a loop by inserting just a single line of code, like: ...
#pragma omp parallel
I also think I am spending much more time on windows than on Linux, because there are so much more annoying problems to fix on the windows side.
These blacklists tend to block one or more complete C-class netblock(s) for each spammer, so you will loose most probably as much (or more) legitimate e-mail as with filtering by content.
I am not talking from an ISP's pespective, rather from the perspective of the small customer of an equally small web hosting provider. Our provider actively fights spam - they even go after bad formmail scripts - but neither we nor our provider has any influence on the network operator (Level3).
"internally multiplexes the connections" usually
means a select(2) loop in a single-threaded server
rather than having a separate thread or subprocess
for each connection.
As much as I dislike spam (2/3 of my daily mail
is spam), I dislike spamhouse/spews as well. Their
idea of blocking complete netblocks is IMHO
an utter failure - the damage is done to many small
websites that are on the netblock perchance.
The 'bad guys' are too high up to care if one of their
C-class netblocks has some problem. After all,
it is the webhosting companies on that netblock
who will loose customers, not the network operators.
While this may not end the conspiracy theories, detecting the Apollo lunar landers on the Moon would be a spectacular demonstration of the VLTs' superb performance. The VLT can achieve a resolution as good as the Hubble Space Telescope (and far better, once the interferometer is installed). Unfortunately, it has neither the staff nor the money of the HST public relation office, so pretty much nobody outside the scientific community knows that.
And worst of all, gpg has no option that would enforce checking the signature on signed data, or at least would make it difficult to access them without checking the signature.
I was talking about the problems of upstream authors, not users. With "dead end" I mean that bugs that are reported to distros often don't get through to the upstream author. Which is bad, because it deprives the author from the feedback required for improving her software.
It is a widely recommended practice for parents with a small child to burn and use copies of their CDs, and keep the 'master' (the original CD) in a safe place.
That's true, sadly. In principle, it should be a good thing to have ones application in a distro, because the number of potential users will be much larger, hence the application more thoroughly tested. In practice, the upstream author typically will not see the bug reports at all.
Umm, no, at least not in general (may depend on the maintainer). Bug reports to distributors are often a dead end - the minimum you should do is looking in the man pages or docs for the e-mail of the upstream author,and cc her the bug report.
IAASA - I am a software author, I know what I'm talking about.
Plus, Debian doesn't have a multi-Gb default install full of crap, contrary to some other distros ...