With FreeBSD once I synchronized sources and rebuilt
Why?
If you're running a recent 4.x release (that is, 4.7 or 4.8) then the security/freebsd-update port will fetch and install updates without needing you to keep a complete source tree.
EINVAL means "invalid argument". EAGAIN means "resource temporarily unavailable". Neither means "woah, something wierd happened here -- we've recovered, but this Needs To Be Fixed".
No, it's not as good as using assert -- it's better.
Returning EDOOFUS has the benefits provided by assert(0) -- it makes the problem apparent -- without the disadvantages. Since this is being used in cases where the offending data can be fixed safely, fixing it and reporting the error is much better than panicking the entire system.
The assumption that anyone who makes a mistake is a 'doofus' doens't surprise me much at all.
I think people are misunderstanding the purpose of this error. EDOOFUS doesn't mean "someone has made a stupid mistake" -- it means "*I* have made a stupid mistake". People aren't editing each others' code to add EDOOFUS; they're using it in their own code.
Much better than simply writing/* this should never happen */ into your code.
Right... it's easier to fix software bugs than hardware bugs. So why do we complain about hardware bugs when the vendor offers to ship free replacements to their customers, but not complain about software bugs for which fixes are not provided at all?
Any legal action taken by the P2P companies against RIAA would fail under equitable estoppel (aka. the "clean hands doctrine").
If the networks were simply being flooded with random garbage, they might have a case. But since the complaint is one of misrepresentation -- that the files appear to be valid copyrighted material -- the P2P networks clearly do not have "clean hands" with respect to people searching for those files.
That's my point. The problems with building a spam-classifier are practical, not theoretical. Until we agree upon exactly how we define "spam" we can't build a perfect classifier; but there is no analogue to the halting problem (Turing), the incompleteness-inconsistency theorem (Godel), or the diagonal argument (Cantor).
At this point, Cantor's diagonalization is trivial.
You have an interesting definition of "trivial".
Ok, suppose I have a function which I claim distinguishes with perfect accuracy between spam and non-spam. How do you propose to construct a message which it mis-identifies?
It is entirely possible that my code contains bugs. However, I wrote it with an awareness of modern attack methods, which cannot be said of a certain commonly used ssl library; further, my code does exactly what I need it to do, and no more. ASCII armor, ASN encoding, and other features are sometimes useful, but I don't need them; by not including those I cut out a range of possible bugs.
C'mon, this is an old one. It's been proven again and again that exposing crypto code to peer review is the only way to know that it's safe.
That's not true. "Many eyes" does not necessarily mean that bugs will be found -- many security holes are found years after they were introduced. A much better approach is formal proofs.
That said, see that link just above this post? My code is there; feel free to examine it.
"Free as in free" isn't necessarily better, especially where security is concerned. A good example of this is qmail -- djb offers a guarantee that it is secure, and he can do that because he wrote qmail entirely himself. If he was accepting code from around the world, it would be much harder for him to provide such a guarantee; and if qmail was changing as rapidly as many open source programs, it would be impossible.
Open source means that lots of people can fix bugs; it also means that lots of people can introduce bugs. For security critical applications, I'd prefer to use code which was written carefully by a single person or small group of people whom I trust, rather than using code contributed by a large number of effectively anonymous people whom I don't know.
"Bush administration expresses concern about Canada's weapons of mass destruction."
The crazy thing is, Canada is far more capable of producing nuclear weapons than Iraq ever was. Canada has lots of highly trained nuclear scientists and has large reserves of uranium. But Canada decided early on that it didn't want to get involved in the nuclear arms race.
Slashdot Mirror
Downloads of binaries could take more bandwidth
You're right -- today. In a few days I'll be bringing a binary diff tool into FreeBSD Update, which will cut the bandwidth significantly.
Also, I like having the complete source tree
True. OTOH, more often than not I end up looking at cvsweb rather than my local copy of the source tree.
No, not cron. It looks suspicious if you send emails at the same time in the middle of every night. ;)
at(1) is more appropriate.
With FreeBSD once I synchronized sources and rebuilt
Why?
If you're running a recent 4.x release (that is, 4.7 or 4.8) then the security/freebsd-update port will fetch and install updates without needing you to keep a complete source tree.
Well, of course you shoot the spammer. Left to their own devices, Osama bin Laden and Saddam Hussein would kill each other.
EINVAL means "invalid argument". EAGAIN means "resource temporarily unavailable". Neither means "woah, something wierd happened here -- we've recovered, but this Needs To Be Fixed".
No, it's not as good as using assert -- it's better.
Returning EDOOFUS has the benefits provided by assert(0) -- it makes the problem apparent -- without the disadvantages. Since this is being used in cases where the offending data can be fixed safely, fixing it and reporting the error is much better than panicking the entire system.
The assumption that anyone who makes a mistake is a 'doofus' doens't surprise me much at all.
/* this should never happen */ into your code.
I think people are misunderstanding the purpose of this error. EDOOFUS doesn't mean "someone has made a stupid mistake" -- it means "*I* have made a stupid mistake". People aren't editing each others' code to add EDOOFUS; they're using it in their own code.
Much better than simply writing
Right... it's easier to fix software bugs than hardware bugs. So why do we complain about hardware bugs when the vendor offers to ship free replacements to their customers, but not complain about software bugs for which fixes are not provided at all?
Any legal action taken by the P2P companies against RIAA would fail under equitable estoppel (aka. the "clean hands doctrine").
If the networks were simply being flooded with random garbage, they might have a case. But since the complaint is one of misrepresentation -- that the files appear to be valid copyrighted material -- the P2P networks clearly do not have "clean hands" with respect to people searching for those files.
Postgresql is not GPL. Postgresql is distributed under the BSD license.
That's my point. The problems with building a spam-classifier are practical, not theoretical. Until we agree upon exactly how we define "spam" we can't build a perfect classifier; but there is no analogue to the halting problem (Turing), the incompleteness-inconsistency theorem (Godel), or the diagonal argument (Cantor).
At this point, Cantor's diagonalization is trivial.
You have an interesting definition of "trivial".
Ok, suppose I have a function which I claim distinguishes with perfect accuracy between spam and non-spam. How do you propose to construct a message which it mis-identifies?
Life discovered on earth. Scientists uncertain if it is intelligent.
Classifying spam is essentially the same problem as classifying programs into those that terminate that those that don't (the halting problem).
What an amazing claim. Could you elaborate on this? For example, how do you apply Cantor's diagonalization argument to email?
Because obviously, you never make mistakes.
It is entirely possible that my code contains bugs. However, I wrote it with an awareness of modern attack methods, which cannot be said of a certain commonly used ssl library; further, my code does exactly what I need it to do, and no more. ASCII armor, ASN encoding, and other features are sometimes useful, but I don't need them; by not including those I cut out a range of possible bugs.
C'mon, this is an old one. It's been proven again and again that exposing crypto code to peer review is the only way to know that it's safe.
That's not true. "Many eyes" does not necessarily mean that bugs will be found -- many security holes are found years after they were introduced. A much better approach is formal proofs.
That said, see that link just above this post? My code is there; feel free to examine it.
The 2.4.x kernel -- isn't that the "stable" kernel which had a complete VM subsystem change and two filesystem corruption bugs?
Stable trees might *theoretically* only include bug fixes, but in practice they tend to have rather more than that.
You're right; I would trust GPG more than PGP. I was making a general remark about "free as in freee" software not *necessarily* being more secure.
That said, for non-email uses I don't use either PGP or GPG; I use my own RSA code, which I trust more than either of those.
"Free as in free" isn't necessarily better, especially where security is concerned. A good example of this is qmail -- djb offers a guarantee that it is secure, and he can do that because he wrote qmail entirely himself. If he was accepting code from around the world, it would be much harder for him to provide such a guarantee; and if qmail was changing as rapidly as many open source programs, it would be impossible.
Open source means that lots of people can fix bugs; it also means that lots of people can introduce bugs. For security critical applications, I'd prefer to use code which was written carefully by a single person or small group of people whom I trust, rather than using code contributed by a large number of effectively anonymous people whom I don't know.
You'll be able to bitch on IRC for BSD help years after all the funding is cut and SCO sues the different BSD forks.
SCO is a linux problem, not a BSD problem. Berkeley settled with SCO a decade ago.
Qmail isn't far off.
"Bush administration expresses concern about Canada's weapons of mass destruction."
The crazy thing is, Canada is far more capable of producing nuclear weapons than Iraq ever was. Canada has lots of highly trained nuclear scientists and has large reserves of uranium. But Canada decided early on that it didn't want to get involved in the nuclear arms race.
First landing outside the US. Landing implies the presence of land.
Don't forget to patch the base system:
/usr/ports/security/freebsd-update && make all install /usr/local/freebsd-update/update.conf.sample /usr/local/freebsd-update/update.conf /usr/local/sbin/freebsd-update fetch /usr/local/sbin/freebsd-update install /usr/local/sbin/freebsd-update cron" >> /etc/crontab
# cd
# mv
#
#
# echo "0 2 * * *
From the article:
After the satellite was switched off it became impossible to communicate with the spacecraft.
Is this supposed to come as a surprise to anyone?
The canonical discussion forum for this topic is WebHostingTalk.