Bitching about that would be just like bitching about the fact that you could open a terminal under linux and type "umount -f/mnt/fd1" to unmount a floppy.
No, it would be like bitching about being able to open a terminal under linux and type "rm -rf/mnt/fd1" to unmount a floppy.
Great T-shirts notwithstanding (and I do appreciate the humour in that T-shirt, but it is just humour)...
No scientific dogmatist is ever going to convince me that that incredible sequence happened because of a lot of coin flips by random forces.
I don't think any respectable scientist will try to convince you of that. However, they might try to convince you that "that incredible sequence" happened because of a lot of coin flips and natural selection.
Your argument boils down to Creation by Design which (as another poster rightly mentioned) is fallacious because it relies on a creator who "just is" whereas the univerise (for some reason) isn't allowed to "just be".
Also, this may shed some light on just how fantastic (our and other species') DNA is.
Only if the semantics are the same. If the semantics differ (subtly) it's not a good thing. Besides, you still haven't shown your original claim (that svn is strictly superior to darcs). Yes, svn is superior to darcs in some ways, but darcs is also superior to svn in some regards.
I suspect your footnote is incorrect (although it been a long time since I looked at darcs and may remember incorrectly). IIRC, the patches themselves don't vary once distributed, just the ordering of them, so it should be possible to sign individual changes. Of course, this isn't nearly enough to verify repository integrity/authenticity, but I think something could be added relatively easily.
I fail to see how. It isn't strictly superior in all categories, and there are certainly some significant differences which would make either (but not both) viable in certain scenarios.
Disclaimer: I'm currently using Arch for all my repos, but that's mainly because Haskell is not really supported properly on my architecture (by my distro). Yet.
Darcs is must less strict: For example, it doesn't have a built-in concept of branches/versions (which is necessary in Arch because of the patch ordering/application constraints).
All working directories are repositories themselves. This can be very useful (for example, it makes it trivial to manage/etc using darcs), but also somewhat dangerous.
Interactive approval of every recorded diff chunk (change). This may not sound like a big deal, but if you have spurious changes in a tree which you'd rather not record(*) in a given changeset, interactive prompting makes it a a lot easier to achieve clean changesets which only touch one "aspect" of the source at a time.
(*) Such as typo fixes, comment fixes, etc. which you just happened to notice while fixing a particular bug.
I can recommend shorewall. Very easy to set up and "secure by default" (ie. has built-in rules to prevent various forms of spoofing, denies incoming traffic by default, etc).
that you can always just get the security patches of the kernel mailing list (or simply find the BK changesets) and apply them to your chosen kernel yourself -- sure you may have to fiddle a bit with the patches to get them to apply cleanly, but at least it's possible. This is not the case with closed source software.
requires whitespace for syntax (literally the worst syntax idea i've ever heard, which is why i avoid that language like the plague)
I always wonder why people think it's such a bad idea, since the syntaxes of almost all current languages require indentation/whitespace to be readable anyway... Just stay away from tabs (or alternatively stay away from stupid editors that treat tabs as anything other than aligned on 8-char columns) and you'll be fine.
I sort of agree about the syntax: The thing that really annoys me is that it's a sort strange mix of whitespace-is-important and whitespace-is-not-important (try nested match clauses for one example). I have no problems with Python (which heavily favours whitespace, of course) or C-like syntax (which uses lexical tokens), it's just this strange mix I have a problem with.
However, after switching to revised syntax, I've never looked back. Some of the revised syntax is a bit too verbose for my liking, esp. the requirement that one must always use a do {... } block for multiple statements where a "chain statements" delimiter might have sufficed, but overall it was a win for me.
And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!)
I guess there's no accounting for personal taste, but IMHO MetaOCaml doesn't seem too bad (and I agree that it's much much better than C++ templates:)). I do wish they'd try to stabilize and incorporate some of that stuff into the INRIA Ocaml distribution so that people could actually start using it.
[Stuff about lackluster optimization]
I believe someone has been working towards an LLVM backend for OCaml, which might end up providing better performance and optimization opportunities (since LLVM can also take into account run-time profiling info).
[Stuff about COCaml interface]
I kind of agree that this bit could be better, but for simple interface you can almost always use camlidl to great effect. For complex interfaces, I usually find that camlidl becomes more of a hinderance than help, and I almost invariably end up implementing the C stubs manually. YMMV.
Some Jabber clients (eg. psi) allow client-to-client OpenPGP encryption of messages. That means that nobody except the intended recipient (and possibly the NSA:)) gets to read the message. I'm not really sure how integrated-into-Jabber this is, but it obviously does require some client support since only the client software can encrypt messages before they are sent over the wire.
(Oh, and like someone pointed out, SSL only encrypts your connection to the server not to the other client.)
Sorry, but wrong.
on
Hacking Vodka
·
· Score: 4, Informative
Methanol makes you go blind and very likely dead (unless you only drink a tiny amount and get treated immediately), Ethanol gives you a hangover.
You're confusing the the envelope From (ie. where bounces and suchlike go) and the From: mail header. DomainKeys/SPF still allow completely arbitrary From: mail headers.
... don't enter into it (to paraphrase a famous skit w/John Cleese).:)
The GP was suggesting that OO was somehow not implementable on a TM and I felt compelled to correct him/her/it.
IIRC, it has also been shown that algorithms always stay within their "class" (P, NP, P-space, etc.) when transformed from a TC language to another TC language. So your observation about complexity is only half true in that an O(n) algorithm may turn into an O(n^10), but it will never turn into an exponential-time algorithm when transformed. Of course, the difference is huge in practical terms, but at the same time the algorithm doesn't really become more 'difficult' from a computational perspective.
... but AFAICT it doesn't really counter anything I said about TC language equivalence. Granted, the languages might actually be supersets of (classical) TMs, but that's nitpicking... they're still computationally equivalent since their only non-TM mechanism is I/O and they would both posses equivalent I/O mechanisms.
All Turing Complete languages (which BF is) are equivalent. That means that any OO Turing Complete language can be implemented in a non-OO Turing Complete language. Case in point: C++ compiles to assembly/machine code which is certainly not OO.
How to implement an OO language on a Turing Machine: Do something equivalent to how OO is implemented in C, ie. store "function pointers" (tape addresses) along with the data and use indirection to call those every time a virtual method is needed.
If spam gets to your Bayesian filter (regardless of whether it's filtered or not), that means that some of your bandwidth is being consumed to transmit that spam. If spammers are forced to compute hashes (thus lowering their total output), less of your bandwidth is wasted on their crap. You still pay the same for your bandwidth, it's just that you get to use it, not you+spammers.
it's still a win, simply because the number of spam mails sent out is still reduced -- even if there are lots of zombies computing hashes, they take longer to send out each individual message compared to zombies which aren't forced to compute hashes.
storage bandwidth/throughput is really the issue here. If you can't transfer as fast or faster than the storage media decay you have a problem. Otherwise, you can just keep transferring to newer media like you suggested.
Slashdot Mirror
No, it would be like bitching about being able to open a terminal under linux and type "rm -rf
I don't think any respectable scientist will try to convince you of that. However, they might try to convince you that "that incredible sequence" happened because of a lot of coin flips and natural selection.
Your argument boils down to Creation by Design which (as another poster rightly mentioned) is fallacious because it relies on a creator who "just is" whereas the univerise (for some reason) isn't allowed to "just be".
Also, this may shed some light on just how fantastic (our and other species') DNA is.
Only if the semantics are the same. If the semantics differ (subtly) it's not a good thing. Besides, you still haven't shown your original claim (that svn is strictly superior to darcs). Yes, svn is superior to darcs in some ways, but darcs is also superior to svn in some regards.
linguists don't define English. The people who speak/write it do. That's why e.g. doh is now a valid English word.
I suspect your footnote is incorrect (although it been a long time since I looked at darcs and may remember incorrectly). IIRC, the patches themselves don't vary once distributed, just the ordering of them, so it should be possible to sign individual changes. Of course, this isn't nearly enough to verify repository integrity/authenticity, but I think something could be added relatively easily.
I fail to see how. It isn't strictly superior in all categories, and there are certainly some significant differences which would make either (but not both) viable in certain scenarios.
Disclaimer: I'm currently using Arch for all my repos, but that's mainly because Haskell is not really supported properly on my architecture (by my distro). Yet.
the implied "generally". As in: It's only [generally] true for numbers which...
Major differences:
(*) Such as typo fixes, comment fixes, etc. which you just happened to notice while fixing a particular bug.
I can recommend shorewall. Very easy to set up and "secure by default" (ie. has built-in rules to prevent various forms of spoofing, denies incoming traffic by default, etc).
that you can always just get the security patches of the kernel mailing list (or simply find the BK changesets) and apply them to your chosen kernel yourself -- sure you may have to fiddle a bit with the patches to get them to apply cleanly, but at least it's possible. This is not the case with closed source software.
I always wonder why people think it's such a bad idea, since the syntaxes of almost all current languages require indentation/whitespace to be readable anyway... Just stay away from tabs (or alternatively stay away from stupid editors that treat tabs as anything other than aligned on 8-char columns) and you'll be fine.
I sort of agree about the syntax: The thing that really annoys me is that it's a sort strange mix of whitespace-is-important and whitespace-is-not-important (try nested match clauses for one example). I have no problems with Python (which heavily favours whitespace, of course) or C-like syntax (which uses lexical tokens), it's just this strange mix I have a problem with.
... } block for multiple statements where a "chain statements" delimiter might have sufficed, but overall it was a win for me.
However, after switching to revised syntax, I've never looked back. Some of the revised syntax is a bit too verbose for my liking, esp. the requirement that one must always use a do {
I guess there's no accounting for personal taste, but IMHO MetaOCaml doesn't seem too bad (and I agree that it's much much better than C++ templates
I believe someone has been working towards an LLVM backend for OCaml, which might end up providing better performance and optimization opportunities (since LLVM can also take into account run-time profiling info).
I kind of agree that this bit could be better, but for simple interface you can almost always use camlidl to great effect. For complex interfaces, I usually find that camlidl becomes more of a hinderance than help, and I almost invariably end up implementing the C stubs manually. YMMV.
the Moderator-on-crack Syndrome.
Some Jabber clients (eg. psi) allow client-to-client OpenPGP encryption of messages. That means that nobody except the intended recipient (and possibly the NSA :)) gets to read the message. I'm not really sure how integrated-into-Jabber this is, but it obviously does require some client support since only the client software can encrypt messages before they are sent over the wire.
(Oh, and like someone pointed out, SSL only encrypts your connection to the server not to the other client.)
Methanol makes you go blind and very likely dead (unless you only drink a tiny amount and get treated immediately), Ethanol gives you a hangover.
You're confusing the the envelope From (ie. where bounces and suchlike go) and the From: mail header. DomainKeys/SPF still allow completely arbitrary From: mail headers.
You can always get a new smartcard, you can't get new fingerprints (or retinas, or whatever).
... don't enter into it (to paraphrase a famous skit w/John Cleese). :)
The GP was suggesting that OO was somehow not implementable on a TM and I felt compelled to correct him/her/it.
IIRC, it has also been shown that algorithms always stay within their "class" (P, NP, P-space, etc.) when transformed from a TC language to another TC language. So your observation about complexity is only half true in that an O(n) algorithm may turn into an O(n^10), but it will never turn into an exponential-time algorithm when transformed. Of course, the difference is huge in practical terms, but at the same time the algorithm doesn't really become more 'difficult' from a computational perspective.
... but AFAICT it doesn't really counter anything I said about TC language equivalence. Granted, the languages might actually be supersets of (classical) TMs, but that's nitpicking... they're still computationally equivalent since their only non-TM mechanism is I/O and they would both posses equivalent I/O mechanisms.
All Turing Complete languages (which BF is) are equivalent. That means that any OO Turing Complete language can be implemented in a non-OO Turing Complete language. Case in point: C++ compiles to assembly/machine code which is certainly not OO.
How to implement an OO language on a Turing Machine: Do something equivalent to how OO is implemented in C, ie. store "function pointers" (tape addresses) along with the data and use indirection to call those every time a virtual method is needed.
If spam gets to your Bayesian filter (regardless of whether it's filtered or not), that means that some of your bandwidth is being consumed to transmit that spam. If spammers are forced to compute hashes (thus lowering their total output), less of your bandwidth is wasted on their crap. You still pay the same for your bandwidth, it's just that you get to use it, not you+spammers.
it's still a win, simply because the number of spam mails sent out is still reduced -- even if there are lots of zombies computing hashes, they take longer to send out each individual message compared to zombies which aren't forced to compute hashes.
storage bandwidth/throughput is really the issue here. If you can't transfer as fast or faster than the storage media decay you have a problem. Otherwise, you can just keep transferring to newer media like you suggested.
Personally, I find the < form uglier -- I'm not sure why, but I guess it has something to do with the pipeline
...
...
:)
$ cat bla | prog1 | prog2 |
"flowing" purely from left-to-right, as opposed to
$ prog1 < bla | prog2 |
where input flows from right-to-left then right again.
Also, the former is marginally easier to modify if you need another stage of processing before prog1.
To each his own, I guess.