The main problem of software development is the messy area of knowing what the program is supposed to do in the first place. Once you know that with 100% certainty, writing a program to do it is (infeasible/intractable problems aside) relative childsplay - formal methods or not. You can't prove a program's correctness if you don't have a definition of 'correct'...
The 'man' system (including whatis, apropos etc.) is one of the most user-friendly help systems I've ever come across. It would be a pity to see it die because someone thinks the bloat of html, hyperlinks, graphics etc. is in some way "better".
<flamebait>
gnu-info, on the other hand, is downright hostile
</flamebait> --
A slightly less easy-to-use power button would be really nice. One of the first things my now 13-month-old son learned was how to turn a computer on & off.
He's a real menace when I bring him to the office. Fortunately he hasn't found the power switch on my Sun yet.
And veering towards off-topic... why is it that all the cables in the back of a PC can be secured by screws, clamps, little clips, whatever, _except_ for the power cable?
--
Re:and on their website too...
on
The DeCSS Haiku
·
· Score: 2
Why is no-one reading the words here. MPAA are claiming that CSS is a copy-protection mechanism. According to DMCA, circumventing an access control mechanism is illegal. DeCSS circumvents a copy control mechanism (by MPAA's own admission) and so does not violate the DMCA.
What MPAA are trying to hide is the real wording of the DMCA. Whatever your opinions of the WIPO treaty that started all this, the DMCA goes much further. The US has enacted a law that benefits MPAA (and others) under the guise of implementing a WIPO treaty.
Let's hope the rest of the world's lawmakers aren't bought so easily. --
I foresee a market for 3rd-party installation software that will allow you to install the software from ithe original CDs of (e.g.) "Murk-o-soft Off-Fizz 2001" without all that tedious clicking on license agreements first.
Here's something from the DMCA (as quoted in this article) that I didn't notice before:
"(A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access
to a work protected under [the Copyright Act];
If a "technological measure" can be circumvented, there's no way it can be described as "effective".
Kill 'em with their own words.;-)
PS Sorry about the subject line. Something must be interfering with transmission.
Some time ago (in the UK at least), you actually had to publish your work in order to claim copyright. Then some laws were changed. I remember the company I was working for at the time had to put new notices on the front of all their documents saying something like "This is an unpublished work, the copyright in which vests in...".
Heh. I remember all the fun we had trying to fit all that text onto an EPROM label;-)
I agree that the quoted statment doesn't make sense - because GPLed code isn't in the public domain either.
But many developers of closed-source embedded systems will have problems where other closed-source application developers don't. The crucial point is the linking to the kernel. Many (most?) embedded systems are memory-only (no secondary storage). So there's no filesystem for a stand-alone application program to sit on until it's loaded and run by the rc.d scripts - in fact there are no rc.d scripts. So it has to be linked to the kernel to some extent, and that's when you enter the grey zone.
Does a loadable kernel module
have to be GPL? What if the entire kernel is executing in place in the ROM? Can your application also sit in the ROM and be started by the kernel (e.g. by calling a fuunction at an absolute address?)
The real problem is that linked or not linked isn't black-and-white but several shades of grey.
If you're in the clear, usually all that's needed if you receive threatening messages from an "enforcement agency" is an equally strongly worded response, threatening counter-claims for harassment etc. and preferably copied to whoever they claim to be representing. While you're about it, you can threaten to sue their client too.
It worked with a debt collection agency in the UK that I had "dealings" with a couple of years ago. Never heard from them since. --
Quality would not be as good as a direct rip but the vast majority of folks either don't notice the subtle differences or really don't care.
Quite. If you can't tell the difference between a 128kbps MP3 and a direct rip, then you won't spot a single digital-analogue-digital round trip either. 'speshly if it's done using good gear.
If you read the article, you'd see that eReferee won the ICANN arbitration, but then Referee(tm) took the matter to some federal court and won there.
IMHO it's time to get businesses like this (Referee, not eReferee) off the internet. Maybe ICANN should have the right to suspend or withdraw domain names for companies who bring the internet into dispute.
Here is my suggestion for modifying the patent process to try to eliminate some of this madness.
1. Patent applications should be published shortly after filing but before the patent is granted. This would allow interested parties to review patent applications and sumbit challenges before the patent is issued. Claims of "obviousness" might also be entertained here, but beware: anyone can have 20:20 hindsight.
2. An invalidation of any claim in a patent should invalidate the whole patent. This would prevent applicants from filing a whole load of questionable/frivolous/fraudulent claims alongside one arguably valid claim. It might also encourage applicants to research the prior art a bit more carefully.
Just my 2[insert minor currency here]
Comments, anyone?
I think that many people are confused about the purpose of insurance.
I agree. You are one of them.
Insurance cannot protect you from everything bad.
Insurance cannot protect you from anything, despite the claims in some of the advertisements. Insurance (in this case, specifically life insurance) can only protect your dependants from the financial consequences of your (premature) death.
The reason insurance works is that it spreads the risk over as large a number of people as possible. To screen people for the presence of selected traits, over which they have no control, and which may or may not cause premature death, is just plain wrong. If they were screening for all causes of premature death, it might become acceptable, but it is not acceptable to charge you a higher price because you might die of breast cancer, while charging me a lower rate because I won't - despite the fact that I might be more likely to die of something else they're not screening.
You never find questions like "Do you drive a car?
If so, how many kilometres per year?" or "Do you make frequent long-distance flights in economy class?"
OK, I admit that they ask if you smoke, or if you participate in dangerous sports. Maybe that's wrong too - but all those potential causes of death are under the control of the insured. If you don't like your premiums being higher, then stop doing it. --
I can see the publishers point, too. Just not very well, that's all.
Ask yourself this: what do the publishers gain out of publishing electronically instead of on dead trees? Greatly reduced production and distribution costs, that's what. It seems that the publishers want the advantages of the digital distribution without the disadvantages - or worse, they want to turn the disadvantages into advantages, removing some essential rights and freedoms along the way.
So my message to publishers is this: If you're worried about copying the electronic version, publish a paper version instead. Most readers would probably prefer the dead-tree edition for sheer ease-of-use reasons anyway. --
doesn't look like much of an achievement. Drive a car onto the bridge, tie a rope to it, chuck it over...
Now, if they'd strung it between the towers of the WTC in NY, that would have been impressive. --
X over slow connection? - no joke!
on
Cheap Linux PDAs
·
· Score: 1
The X protocol itself has no problems with low bandwidth connections - only the applications that use it.
Some years ago I wrote a couple of "real-time" status monitoring apps. One day I ran them over a 14400 dialup connection while doing some support work for the customer. One of the apps was quite good, the other was a dog. The reason for the lack of performance was a bug in the code which made the app update the screen far too often. On the local machine, and even on a 10Mbps ethernet, the bug wasn't obvious.
The moral of the story for X developers - always test your code on a slow link - it'll make bugs like that stick out like a sore thumb.
Of course, I wouldn't want to use an X word-processor or something like that over a slow link, but for some applications it works just fine. --
1. The original case was filed sometime in 1999
2. DMCA became law in... when???
So the alleged infringements may have been committed before DMCA became law. If that's true (and assuming that the crazy US legal system doesn't allow retrospective laws to be enacted), this case will have little use as precedence for cases being prosecuted under DMCA.
A simple way around EULAs - get your 3-year-old child, dog, or whatever to open the packaging or
click the "I accept" button.
Unless someone at the point of sale actually gets a signature from you that you have read, fully understand and accept the agreement (or unless you're stupid enough to send in such a signed agreement voluntarily), No-one can prove that you were ever aware of the EULA, let alone have read it or (shock, horror) actually agree to it.
In fact, if the software comes pre-installed, you can even reverse engineer it without anyone ever having to click on the "I accept" button. --
Slashdot Mirror
The main problem of software development is the messy area of knowing what the program is supposed to do in the first place. Once you know that with 100% certainty, writing a program to do it is (infeasible/intractable problems aside) relative childsplay - formal methods or not. You can't prove a program's correctness if you don't have a definition of 'correct'...
--
FWIW, Auntie Beeb has an email address for reporting factual errors in their stories:
newsonline.errors@bbc.co.uk
Already done it.
--
The 'man' system (including whatis, apropos etc.) is one of the most user-friendly help systems I've ever come across. It would be a pity to see it die because someone thinks the bloat of html, hyperlinks, graphics etc. is in some way "better".
<flamebait>
gnu-info, on the other hand, is downright hostile
</flamebait>
--
A slightly less easy-to-use power button would be really nice. One of the first things my now 13-month-old son learned was how to turn a computer on & off.
... why is it that all the cables in the back of a PC can be secured by screws, clamps, little clips, whatever, _except_ for the power cable?
He's a real menace when I bring him to the office. Fortunately he hasn't found the power switch on my Sun yet.
And veering towards off-topic
--
Why is no-one reading the words here. MPAA are claiming that CSS is a copy-protection mechanism. According to DMCA, circumventing an access control mechanism is illegal. DeCSS circumvents a copy control mechanism (by MPAA's own admission) and so does not violate the DMCA.
What MPAA are trying to hide is the real wording of the DMCA. Whatever your opinions of the WIPO treaty that started all this, the DMCA goes much further. The US has enacted a law that benefits MPAA (and others) under the guise of implementing a WIPO treaty.
Let's hope the rest of the world's lawmakers aren't bought so easily.
--
I foresee a market for 3rd-party installation software that will allow you to install the software from ithe original CDs of (e.g.) "Murk-o-soft Off-Fizz 2001" without all that tedious clicking on license agreements first.
Open-source installer, anyone?
--
"(A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under [the Copyright Act];
If a "technological measure" can be circumvented, there's no way it can be described as "effective".
Kill 'em with their own words. ;-)
PS Sorry about the subject line. Something must be interfering with transmission.
--
Heh. I remember all the fun we had trying to fit all that text onto an EPROM label ;-)
--
Maybe so (it doesn't violate the license). But try it with Linux and you're GPLed ;-)
--
Who are? The disks, or the people who are leaving?
--
But many developers of closed-source embedded systems will have problems where other closed-source application developers don't. The crucial point is the linking to the kernel. Many (most?) embedded systems are memory-only (no secondary storage). So there's no filesystem for a stand-alone application program to sit on until it's loaded and run by the rc.d scripts - in fact there are no rc.d scripts. So it has to be linked to the kernel to some extent, and that's when you enter the grey zone.
Does a loadable kernel module have to be GPL? What if the entire kernel is executing in place in the ROM? Can your application also sit in the ROM and be started by the kernel (e.g. by calling a fuunction at an absolute address?)
The real problem is that linked or not linked isn't black-and-white but several shades of grey.
--
If you're in the clear, usually all that's needed if you receive threatening messages from an "enforcement agency" is an equally strongly worded response, threatening counter-claims for harassment etc. and preferably copied to whoever they claim to be representing. While you're about it, you can threaten to sue their client too.
It worked with a debt collection agency in the UK that I had "dealings" with a couple of years ago. Never heard from them since.
--
Looks like another application for DeCCS.
--
Quite. If you can't tell the difference between a 128kbps MP3 and a direct rip, then you won't spot a single digital-analogue-digital round trip either. 'speshly if it's done using good gear.
Forget the mike, though. :-O
--
This reminds me of something ...
Allchin: Open-source software is like a stream of bat's piss.
Spin Doctor: What he meant was that it shines out like a shaft of gold when all around is dark.
--
I suppose, with it being such a small fraction of a Kelvin, we could call it Kelvin Klein.
--
'nuff said.
--
If you read the article, you'd see that eReferee won the ICANN arbitration, but then Referee(tm) took the matter to some federal court and won there.
;-) ... well, maybe.
IMHO it's time to get businesses like this (Referee, not eReferee) off the internet. Maybe ICANN should have the right to suspend or withdraw domain names for companies who bring the internet into dispute.
Oh, and
--
Here is my suggestion for modifying the patent process to try to eliminate some of this madness.
1. Patent applications should be published shortly after filing but before the patent is granted. This would allow interested parties to review patent applications and sumbit challenges before the patent is issued. Claims of "obviousness" might also be entertained here, but beware: anyone can have 20:20 hindsight.
2. An invalidation of any claim in a patent should invalidate the whole patent. This would prevent applicants from filing a whole load of questionable/frivolous/fraudulent claims alongside one arguably valid claim. It might also encourage applicants to research the prior art a bit more carefully.
Just my 2[insert minor currency here]
Comments, anyone?
--
I agree. You are one of them.
Insurance cannot protect you from everything bad.
Insurance cannot protect you from anything, despite the claims in some of the advertisements. Insurance (in this case, specifically life insurance) can only protect your dependants from the financial consequences of your (premature) death.
The reason insurance works is that it spreads the risk over as large a number of people as possible. To screen people for the presence of selected traits, over which they have no control, and which may or may not cause premature death, is just plain wrong. If they were screening for all causes of premature death, it might become acceptable, but it is not acceptable to charge you a higher price because you might die of breast cancer, while charging me a lower rate because I won't - despite the fact that I might be more likely to die of something else they're not screening.
You never find questions like "Do you drive a car? If so, how many kilometres per year?" or "Do you make frequent long-distance flights in economy class?"
OK, I admit that they ask if you smoke, or if you participate in dangerous sports. Maybe that's wrong too - but all those potential causes of death are under the control of the insured. If you don't like your premiums being higher, then stop doing it.
--
I can see the publishers point, too. Just not very well, that's all.
Ask yourself this: what do the publishers gain out of publishing electronically instead of on dead trees? Greatly reduced production and distribution costs, that's what. It seems that the publishers want the advantages of the digital distribution without the disadvantages - or worse, they want to turn the disadvantages into advantages, removing some essential rights and freedoms along the way.
So my message to publishers is this: If you're worried about copying the electronic version, publish a paper version instead. Most readers would probably prefer the dead-tree edition for sheer ease-of-use reasons anyway.
--
Now, if they'd strung it between the towers of the WTC in NY, that would have been impressive.
--
The X protocol itself has no problems with low bandwidth connections - only the applications that use it.
Some years ago I wrote a couple of "real-time" status monitoring apps. One day I ran them over a 14400 dialup connection while doing some support work for the customer. One of the apps was quite good, the other was a dog. The reason for the lack of performance was a bug in the code which made the app update the screen far too often. On the local machine, and even on a 10Mbps ethernet, the bug wasn't obvious.
The moral of the story for X developers - always test your code on a slow link - it'll make bugs like that stick out like a sore thumb.
Of course, I wouldn't want to use an X word-processor or something like that over a slow link, but for some applications it works just fine.
--
Some points everyone seems to be missing:
... when???
1. The original case was filed sometime in 1999
2. DMCA became law in
So the alleged infringements may have been committed before DMCA became law. If that's true (and assuming that the crazy US legal system doesn't allow retrospective laws to be enacted), this case will have little use as precedence for cases being prosecuted under DMCA.
--
A simple way around EULAs - get your 3-year-old child, dog, or whatever to open the packaging or
click the "I accept" button.
Unless someone at the point of sale actually gets a signature from you that you have read, fully understand and accept the agreement (or unless you're stupid enough to send in such a signed agreement voluntarily), No-one can prove that you were ever aware of the EULA, let alone have read it or (shock, horror) actually agree to it.
In fact, if the software comes pre-installed, you can even reverse engineer it without anyone ever having to click on the "I accept" button.
--