Most of the spam today comes through compromised home machines on a broadband line.
But usually those zombies connect directly to port 25 of the recipient's SMTP server. That would be prevented by SPF if the sender domain doesn't include the zombie machine's IP in its SPF record. If the zombie is actually using the user's proper (sender) domain and sending through the ISPs mail server, then SPF doesn't help directly, but it gives the ISP the power to simply monitor what is sent and shut the zombie down if spam is being sent.
Hailing a conviction rate over 90% means that the vast majority of people do not end up in court unless they are guilty.
No, it doesn't. Here's a free hint: "convicted" is not necessarily the same as "guilty". Statistics without detailed analysis of causation are utterly meaningless and show nothing.
The point of al those repeated tags is that machine time and bandwidth is very cheap now, but human time is not. The beauty of XML is "agreed-upon" is optional now. We can understand the data without a formal meeting to come to an agreement.
No. You. Can't.
You simply cannot know what the data means without specified semantics (which you have to agree upon somehow; they aren't magically apparent from the XML itself -- that's why such abominations as DTD and XML-Schema exist).
They are not bogus, they are statics that indicate the conviction rate of the cases brought to court.
Yes, but as he was pointing out, hailing 90% conviction rates as evidence of the 'success' of the criminal justice system is unreasonable. There are a number of alternative explanations for the statistics aside from the "we convict almost all criminals we catch". For example, the statistics could just as easily be evidence of significant bias in the judicial process in favour of the prosection.
If you can't recognize that, then you are beyond help.
Methodology2 leads to buggy software therefore we must use Methodology1
(which is essentially what you are arguing with your comparison to Linux) -- is not a logically valid assertion.
Methodology1 leads to buggy software therefore we must
NOT use Methodology1
(which is what the poster was saying by pointing out that no comparable (in terms of development effort/expenditure/etc.) software is as bad as Windows -- this supports the premise that Methodology1 leads to buggy software) is logically valid.
But I really must applaud your troll -- it contains lots of great red herrings and lots of highly contentious (but ultimately irrelevant) details. Well done, sir!
for all intents and purposes the drivers are a necessary part of the OS, and as such are a valid point of comparison (if they were exactly identical from OS to OS they wouldn't be, but they aren't and so they are... if that makes any sense:)). Whether or not that is reflects poorly or well on any particular OS is left as an exercise for the reader -- one which certainly won't be answered by anecdotal evidence posted on Slashdot.
Ah, of course, sometimes I forget that not everyone releases their code as source.:)
But regardless, the probability of such an error occurring is still far lower than that of another piece of system software introducing errors.
For example, if doing a static compile, there are probably lots of bugs hiding in libraries, and any of these is more likely to cause problems for his users than some random memory error.
Hell, even compiler bugs are probably more likely (e.g. gcc >=3.2 is notoriously buggy on Pentium4).
So, just to be absolutely clear about what I was saying: He's effectively guarding against a failure which is so unlikely that it can be considered irrelevant when considering the stability of his software.
Well, I do use my PC for software development, and I surely don't want to be shipping buggy software to customers because I saved $2 buying non-ECC RAM.
Umm... dude. You using ECC RAM is not going to protect users of your software from memory-related bugs(*). Your users using ECC RAM is going to protect them from memory-related bugs.
Don't get me wrong: Using ECC is always better than using non-ECC (it isn't really all that much more expensive), but you seem to be under the impression that non-ECC memory errors are more likely to corrupt your data than simple programmer errors in the OS, your filesystem code, your revision control system, etc. That impression is wrong.
(*) Unless you are talking about the extremely unlikely scenario of a memory-related bug causing random chances to your source code and another memory-related bug causing the revision control software (you do use RCS, don't you?) to not notice the random change when you do a "$RCS diff". Programmer error in the $RCS source code is far far far more likely to screw up your source than any random bit-flip error in memory.
that you disagree with the
majority of those in your community who continue to grant permission
(Emphasis mine). The composition of government can be quite different from what the majority wants (see this) and so the argument that the voters have implicitly granted permission is not necessarily correct (esp. in the US where 'vote for the lesser of two evils' is prevalent). This may not apply to you specifically, but it does apply in the US and GB.
[...] a market that can (and will) take care of itself.
The market (by which is assume you meant "free market") cannot "take care of itself" as you put it if there are monopolies within the market. That's why there are anti-trust laws and government regulation of utilities.
Blocking outbound port 25 has the effect that zombies cannot send mail to SMTP servers listening on port 25. (Incidentally, it also has the effect that completely legitimate and well-behaving mail servers on the network cannot do so either -- unless there is some form of more or less manual unblocking which the customers can apply for/use)
I'm sure that spammers are probably all familiar with this trick by now, and just s/+.*@//g their spam list. I have postfix set up with an alternate domain, where everything goes to my primary email address.
Simple solutions:
Make sure your primary email address contains at least 1 instance of the separating character. Most mail servers handle that situation correctly, but it defeats the simple "strip-everything-after-$CHAR" tactic.
Don't accept mail to the "primary email adress", only accept mail to particular extensions. If you think about it, the "primary email adress" functions as a sort of catch-all address for your little "virtual" subdomain, so eliminating it is exactly the same as having a full domain at your disposal and just creating specific aliases that work (as opposed to just accepting anything sent to any address at the domain).
There is no way to implement verification of senders without breaking forwarding when using legacy MTAs. So my response would to you would be:
I think it's a tad silly to say "Well, we can't ever make a better system for e-mail because we must stay 100% compatible with an old, broken standard".
(Translation: Sometimes we must break things to move forward, technologically speaking)
So wrong that it's not even funny. You know why people aren't advocating buying never hard drives to speed up your compiles? Because compilation is not IO-bound, that's why.
Thanks for the pointer. But alas, he seems to have fallen victim to the same "meme" that many other people in that area have: That the hierarchical organization is not scalable. It is scalable (moreso than Keyword search which only works for things which are keyword-search-friendly and where you actually put in appropriate keywords) as long as you (as the user) know how to use it properly. His insistence (in the paper) on getting rid of the traditional file system is just not sensible, as there are many reasons that a hierarchical file system is desirable, not the least of which is predictable organization for e.g. Version Control Systems.
In effect, what I want is to be able to is:
Keep my hierarchical file system and put my files in there (however I damn well please, thankyouverymuch:)).
Build a virtual hierarchy somewhere else in the file system based on a "pattern" (as shown in the grandparent). This would work sort of like having lots of 'bind' mounts in that the files are completely equivalent to each other, except that the hierarchy itself it organized differently (e.g. using different keys for sorting/categorization).
You could trivially add "Search for all files with this key value and lump them into one folder" functionality, so this is in effect a more flexible superset of what he proposes.
Of course, it's easy to criticize, but unfortunately I currently don't have the time to build a prototype of this.
It depends entirely on the particular RNG you are using.
From man 3 rand:
The versions of rand() and srand() in the Linux C Library use the same random number generator as random() and srandom(), so
the lower-order bits should be as random as the higher-order bits. However, on older rand() implementations, and on current implementations on different systems, the lower-order bits are much less random than the higher-order bits. Do not use this function in applications intended to be portable when good randomness is needed.
(emphasis mine)
So:
If you are on Linux, use rand() -- no need to shift, low bits are just as random as high bits.
If you are not on Linux, find a usable implementation of a good rand() and don't use the C library one (they are usually broken in various ways).
[...] to make the headlines funny enough such that somebody just tuning in would not confuse it with the real Fox News ticker.
Hehe, maybe they thought that the fact that the news was being presented by a cartoon character wouldn't be enough indication that the ticker was not real.
Gstreamer can probably handle this kind of thing. For rhythmbox to remember htat kind of tagging might require creating a plugin for that metadata. It's possible to do. it's certainly not unsurmountable.
I was thinking along the lines of something like an enhanced slocate, which would also index metadata.
Exactly where it's implemented doesn't matter all that much, just as long as it's not tied/restricted to a particular application and/or file format (i.e. it should work equally well for documents and music).
Even find . -type f -name "artist" -print is going to take awhile on that much data
That's why I use "slocate" instead.:) The key here is indexing which is sort of what a file system is supposed to do -- granted, current file systems don't really index your files, but only let you create the index yourself (via a sensible hierarchical organization).
In any case, you're not going to be using a browser or spatial software going about it.
Agreed on the spatial bit (I just don't see it scaling well enoguh), but the hierarchical origanization is actually surprisingly powerful and scalable if you allow for "virtual folders". The idea is that you (the user) can specify which ways (plural!) of organizing the hierarchy you like. Example: Since I like to browse by Artist/Album/Track and sometimes by Year, I could just specify that I want folders:
%Artist%/%Album%/%Title%
%Year%/
and the file system (or virtual file system or whatever) would automatically populate those directories with the appropriate files (regardless of how they are really organized on disk).
Someone else could choose
%Artist%/%Year%/%Title%
%Artist%/ALL/%Title
if that would be more convenient to them. This type of organization and flexibility works brilliantly for email (I'm using 'mairix' to do this, btw), and I could imagine it working really quite well for media files/documents as well. (Even when we're into hundres of thousands or even millions of individual files).
No, it isn't. Giving out bogus details is like giving out bogus details. There is no point in making up an analogy where none is needed. Arguing from a bogus analogy is like a broken pencil... pointless (to paraphrase Blackadder).
But as long as nobody's using them, it doesn't really matter all that much...
It seems Reiser4 will add support for arbitrary meta-data like this and make it easily accessible through the already existing UNIX open() interface, so hopefully this will change. Probably not for a few years, though...:(
You still need some sort of efficient indexing of the metadata to be able to search it quickly and efficiently, but w/Reiser4 you could quite conceivably do this using just shell-level scripting... which would be nice.
Its called gconf-editor. Thats your "Expert" mode. Gconf editor is set up as a heirarchy, ie. browser mode, so I don't know why people think its THAT difficult to use.
You're ignoring another group of users, namely the ones who know just enough about the way they like to use the interface to know that they would like to use "browser" mode instead of "spatial" mode, but who might still be too intimidated to use gconf (since that's where "the esoteric and possibly dangerous" options live).
Double-middle click to open the folder[...]
That is the stupidest 'shortcut' I have ever heard. Do these people not realize that on most mice, the 'middle' mouse button is in fact the mouse wheel (which of course also acts as a button)? It is much harder to double-click the mouse wheel than it is to double-click any of the other buttons, simply because you have to be very careful to avoid scrolling the wheel as you click. Yes, you might argue that this is the fault of the mouse producers, but ignoring reality is just stupid.
Slashdot Mirror
But usually those zombies connect directly to port 25 of the recipient's SMTP server. That would be prevented by SPF if the sender domain doesn't include the zombie machine's IP in its SPF record. If the zombie is actually using the user's proper (sender) domain and sending through the ISPs mail server, then SPF doesn't help directly, but it gives the ISP the power to simply monitor what is sent and shut the zombie down if spam is being sent.
and no reasonable way to bookmark "pages" (state). That is the killer of Flash as far as I'm concerned.
No, it doesn't. Here's a free hint: "convicted" is not necessarily the same as "guilty". Statistics without detailed analysis of causation are utterly meaningless and show nothing.
Apparently you are beyond help.
No. You. Can't.
You simply cannot know what the data means without specified semantics (which you have to agree upon somehow; they aren't magically apparent from the XML itself -- that's why such abominations as DTD and XML-Schema exist).
No, the "zero" or relational databases is the empty set.
Yes, but as he was pointing out, hailing 90% conviction rates as evidence of the 'success' of the criminal justice system is unreasonable. There are a number of alternative explanations for the statistics aside from the "we convict almost all criminals we catch". For example, the statistics could just as easily be evidence of significant bias in the judicial process in favour of the prosection.
If you can't recognize that, then you are beyond help.
(which is essentially what you are arguing with your comparison to Linux) -- is not a logically valid assertion.
(which is what the poster was saying by pointing out that no comparable (in terms of development effort/expenditure/etc.) software is as bad as Windows -- this supports the premise that Methodology1 leads to buggy software) is logically valid.
But I really must applaud your troll -- it contains lots of great red herrings and lots of highly contentious (but ultimately irrelevant) details. Well done, sir!
for all intents and purposes the drivers are a necessary part of the OS, and as such are a valid point of comparison (if they were exactly identical from OS to OS they wouldn't be, but they aren't and so they are... if that makes any sense :)). Whether or not that is reflects poorly or well on any particular OS is left as an exercise for the reader -- one which certainly won't be answered by anecdotal evidence posted on Slashdot.
Ah, of course, sometimes I forget that not everyone releases their code as source. :)
But regardless, the probability of such an error occurring is still far lower than that of another piece of system software introducing errors.
For example, if doing a static compile, there are probably lots of bugs hiding in libraries, and any of these is more likely to cause problems for his users than some random memory error.
Hell, even compiler bugs are probably more likely (e.g. gcc >=3.2 is notoriously buggy on Pentium4).
So, just to be absolutely clear about what I was saying: He's effectively guarding against a failure which is so unlikely that it can be considered irrelevant when considering the stability of his software.
Umm... dude. You using ECC RAM is not going to protect users of your software from memory-related bugs(*). Your users using ECC RAM is going to protect them from memory-related bugs.
Don't get me wrong: Using ECC is always better than using non-ECC (it isn't really all that much more expensive), but you seem to be under the impression that non-ECC memory errors are more likely to corrupt your data than simple programmer errors in the OS, your filesystem code, your revision control system, etc. That impression is wrong.
(*) Unless you are talking about the extremely unlikely scenario of a memory-related bug causing random chances to your source code and another memory-related bug causing the revision control software (you do use RCS, don't you?) to not notice the random change when you do a "$RCS diff". Programmer error in the $RCS source code is far far far more likely to screw up your source than any random bit-flip error in memory.
EULAs on those things, and you know it.
(Emphasis mine). The composition of government can be quite different from what the majority wants (see this) and so the argument that the voters have implicitly granted permission is not necessarily correct (esp. in the US where 'vote for the lesser of two evils' is prevalent). This may not apply to you specifically, but it does apply in the US and GB.
The market (by which is assume you meant "free market") cannot "take care of itself" as you put it if there are monopolies within the market. That's why there are anti-trust laws and government regulation of utilities.
Blocking outbound port 25 has the effect that zombies cannot send mail to SMTP servers listening on port 25. (Incidentally, it also has the effect that completely legitimate and well-behaving mail servers on the network cannot do so either -- unless there is some form of more or less manual unblocking which the customers can apply for/use)
Simple solutions:
Your "counterexample" is a straw man.
There is no way to implement verification of senders without breaking forwarding when using legacy MTAs. So my response would to you would be:
I think it's a tad silly to say "Well, we can't ever make a better system for e-mail because we must stay 100% compatible with an old, broken standard".
(Translation: Sometimes we must break things to move forward, technologically speaking)
So wrong that it's not even funny. You know why people aren't advocating buying never hard drives to speed up your compiles? Because compilation is not IO-bound, that's why.
In effect, what I want is to be able to is:
You could trivially add "Search for all files with this key value and lump them into one folder" functionality, so this is in effect a more flexible superset of what he proposes.
Of course, it's easy to criticize, but unfortunately I currently don't have the time to build a prototype of this.
It depends entirely on the particular RNG you are using.
From man 3 rand:
(emphasis mine)
So:
Hehe, maybe they thought that the fact that the news was being presented by a cartoon character wouldn't be enough indication that the ticker was not real.
I was thinking along the lines of something like an enhanced slocate, which would also index metadata.
Exactly where it's implemented doesn't matter all that much, just as long as it's not tied/restricted to a particular application and/or file format (i.e. it should work equally well for documents and music).
That's why I use "slocate" instead.
Agreed on the spatial bit (I just don't see it scaling well enoguh), but the hierarchical origanization is actually surprisingly powerful and scalable if you allow for "virtual folders". The idea is that you (the user) can specify which ways (plural!) of organizing the hierarchy you like. Example: Since I like to browse by Artist/Album/Track and sometimes by Year, I could just specify that I want folders:
%Artist%/%Album%/%Title%
%Year%/
and the file system (or virtual file system or whatever) would automatically populate those directories with the appropriate files (regardless of how they are really organized on disk).
Someone else could choose
%Artist%/%Year%/%Title%
%Artist%/ALL/%Title
if that would be more convenient to them. This type of organization and flexibility works brilliantly for email (I'm using 'mairix' to do this, btw), and I could imagine it working really quite well for media files/documents as well. (Even when we're into hundres of thousands or even millions of individual files).
No, it isn't. Giving out bogus details is like giving out bogus details. There is no point in making up an analogy where none is needed. Arguing from a bogus analogy is like a broken pencil... pointless (to paraphrase Blackadder).
But as long as nobody's using them, it doesn't really matter all that much...
:(
It seems Reiser4 will add support for arbitrary meta-data like this and make it easily accessible through the already existing UNIX open() interface, so hopefully this will change. Probably not for a few years, though...
You still need some sort of efficient indexing of the metadata to be able to search it quickly and efficiently, but w/Reiser4 you could quite conceivably do this using just shell-level scripting... which would be nice.
Fair enough.
You're ignoring another group of users, namely the ones who know just enough about the way they like to use the interface to know that they would like to use "browser" mode instead of "spatial" mode, but who might still be too intimidated to use gconf (since that's where "the esoteric and possibly dangerous" options live).
That is the stupidest 'shortcut' I have ever heard. Do these people not realize that on most mice, the 'middle' mouse button is in fact the mouse wheel (which of course also acts as a button)? It is much harder to double-click the mouse wheel than it is to double-click any of the other buttons, simply because you have to be very careful to avoid scrolling the wheel as you click. Yes, you might argue that this is the fault of the mouse producers, but ignoring reality is just stupid.