You do realize that comparing the maximum possible sentence for one crime to the sentence actually meeted out in a specific instance of a different crime is truly an apples-to-oranges comparison, right?
Now, if you were comparing maximum sentences for different types of crimes, or were comparing the sentence of the average copyright infringer to that of the average rapist, you might be on your way to a point. However, just because some lawyer somewhere once got his guilty client a light sentence doesn't mean that suddenly all sentences everywhere must be reduced or else the system as a whole is unsupportably unfair.
(The system may in fact be incredibly unfair, but you need more than one second-hand anecdote about a completely different crime)
As I read through the appellate court's reasoning, they seem to be saying that the knowledge at the time of sale that there is a license agreement, and that this purchase is subject to it, accompanied with the ability to reverse the entire transaction should the actual details of the agreement be unacceptable is sufficient to provide a EULA with enforceability. (Subject to the general things that would invalidate a contract, such as requiring one's first born in the fine print) A visible notice on the outside of the box saying "This software is subject to a license agreement which must be accepted before the software may be used" would be sufficient.
In your analysis, the relevant acceptance happened at the time of sale - you agreed to use the software only in accordance with whatever license agreement was inside, and to not use it if the terms inside were unacceptable.
Now, where I think current EULAs might get into trouble is that despite what the text of the EULA may say, you cannot in practice return opened software if you find the EULA unacceptable. Working this out requires more legal training than I have (none), but it may mean that EULAs are limited to what everyone expects EULAs to contain, which is a damn vague standard. (However, such a standard might throw out "no benchmarking" clauses)
Of course, if your state passes a law that explicitly delimits the scope and applicability of EULAs included in software sold over-the-counter, (e.g. UCITA) then that's a different matter.
Actually, that in and of itself isn't too hard - all an attacker would have to do is broadcast a very strong signal on a channel different than the one the accesspoint is using, but with the same SSID, and then have a second wireless card locked to the correct channel communicating with the "real" accesspoint. I don't know about Linux wireless, but my windows laptop has no problem reconnecting if I change the channel my access point is using. (and this is after I've locked it down so that it won't autoconnect to other networks, or even to my own if I disable WEP - the key has to match, but the channel can jump all over the place) Certainly if someone is going to connect to a network and sees two TMobile networks, one with a strong signal and one with a relatively weak signal, they'll choose the strong one. Also, who hasn't sat out in the Borders parking lot trying to use wireless that's normally only available inside Borders? And who would find it suspicious that the wireless signal now covered a much larger area?
If the accesspoint is set up as, for example, T Mobile accesspoints are, all access is initially blocked except web access, which is immediately redirected to a T-Mobile sign-on screen. Now I don't know whether the real sign-on screens use https or not, but certainly some phishers fake login screen wouldn't use https, and after a bit of niggly stuff left as an exercise for the reader, the victim has given the fake accesspoint all of the information necessary to log onto the network: either a TMobile userid and password, or their credit card details, etc.
And all of this because the victim never noticed that the login page he was automatically redirected to was served over http, and not https. Remember, the initial login redirect isn't an address anyone types in; they want to go where they want to go, and the login page is a familiar and accepted hurdle to jump over. Assuming that the attacker's setup does sufficiently complicated redirecting and rewriting of html on the fly, the page could in fact be an exact replica of the TMobile signon page, just served of plain http.
All this of course assumes that the initial login redirect is served over https to begin with. If the initial login page is served over plain http, then everything is much easier for the attacker, who just needs to forward packets back and forth and sniff like crazy. (there's still the minor problem of DHCP packets, which may need to be forwarded with the original MAC address intact, and so could make it difficult to phish many people at once, but...)
Instead, what you want to avoid this attack (unscrupulous network device in the middle) is SSL-enabled mail checking protocols.
Such as, say, secure POP and secure IMAP which the major mail clients have all supported for years, and which most mail servers now support out of the box, but which, for some reason, most ISPs don't make the default (or occasionally, don't even make possible)
GPG defends against J. unethical sysadmin at your mailhost reading the content of your email; while it would provide a protection against reading email here, it wouldn't prevent the sniffer from getting your username and password, which is probably what people are more worried about. (Besides, can you _guarantee_ that all of the people likely to send you sensitive email will use GPG? Even if you can, do you want to give some sniffer owner the ability to do whatever else he can with your email account, which may include filling webspace provided by your ISP with the latest warez, deleting all your email, setting up a "This dud got 0wn3d" auto-responder...)
The retirement age hasn't kept pace with advances in life expectancy. But it's not politically savy to tell people you can retire at 65...no wait, make that 67...oops hang on, better make that 70...or maybe 72.
Well, this makes sense only if you use the life expectancy at age 18 (or 21, or whatever your cutoff is for when someone enters the workforce). Life expectancy at birth is a stupid measure to use for this, because having a bunch of children die before the age of 1 affects social security not a bit. (They don't pay in, and they don't withdraw)
So how has life expectancy changed over the last century? Well, in one sense, it's risen dramatically - the life expectancy at birth is now something like 15 years longer than it was in 1940. However, most of that increase is due to advancements in keeping children from dying. At the other end of the spectrum, someone who made it to 65 in 1940 could expect to live, on average, another 12.7 years. Nowadays, they could expect to live another 15.3. That's a whopping 2.6 year increase. (I admit, the increase has been greater for women now that we've gotten better at diagnosing breast cancer - a woman who reaches age 65 now can look forward to 4.9 years more than one could who reached age 65 in 1940)
Remember this: life expectancy for adults today is not radically different than it was 60 years ago. The difference is that today we don't have as many children being wiped out by childhood diseases, so the average looks much higher if you watch the wrong statistic.
the Blacks went nuts at the Bell Curve, but the Bell Curve is solid facts.
its nothing more than a collection of studies.
Um, no. It's a collection of (some discredited, some not) studies with extensive commentary that explains the studies as seen by the authors of the book - to present it as a dispassionate collection of peer-reviewed journal entries is fraud.
Among other things, the authors several times implicitly use the idea that studies on certain African tribes (who may have almost no descendants in the US) are accurate guides for the US black population. Unless you believe that melanin affects brain development (a bizarre biochemical theory if ever I heard one), there's no reason to suppose that studying African tribesmen gives you any more insight into a US population than studying a tribe of Tuvan goatherders on the Asian steppe - the genetic diversity of Americans, even those who are all lumped into one "race", is simply much too large.
The authors also present the idea that a single underlying factor can be constructed which correlates positively with a wide variety of test scores as evidence of innate immuteable intelligence. Now, while there may well be such a thing as innate intelligence, the fact that such an underlying measure can be constructed shows you nothing; you can construct an underlying factor to "demonstrate" that there is one innate trait that links hair color and femur length. The correlation won't be strong, but it will be there - and the g factor the authors demonstrate is rather weakly correlated with the outcomes they wish to explain by it.
(I haven't even gotten into the bit that speculates about dysgenic pressure on the US black population caused by promiscuous black men with unusually large genitals - and yes, that's in there too, and no, there is no study cited on cross-racial penis size)
i just wish there was a secure way to open up sshd and add in those accounts they are trying with the passwords they want but redirecting to a 30 second timeout and then logoff that was secure enough to not break out.
There is. All you have to do is set them up with an ultra-restrictive shell, and with a home directory that no one but root can write to.
For example, you could write a simple C program that prints some specified string, sits and waits for some amount of time, then prints some other string and exits. Add some stuff to syslog along the way for fun (for example, log the arguments to see if they're trying sftp). Maybe you could even go a small tiny bit further and have an actual miniature shell, though that'd be too risky for my tastes.
Then, compile it statically - it shouldn't be an issue if you've got the home directory locked down, but I don't always trust that the attackers won't be able to sneak some harmful environmental variable in there somehow. Put it in/usr/bin and enter it as a valid shell in/etc/shells, then add these accounts they're trying to use to your system, with the home directory set to some root-owned directory. Sit back and watch.
What I suspect you'll see is that you won't actually end up slowing these people down much; as the fake shell doesn't handle the "-c" option, they'll see the same result from:
ssh yourhost.com echo I got in as they do from:
ssh yourhost.com and then it's pretty obvious that this isn't a real compromised account.
Well, as a demonstration that the idea is fundamentally sound, can you point to any currently-in-force software patents that are "good" in some sense? We have enough examples on the bad side of the fence - perhaps if we had examples on both sides it would be easier to tell where the line is.
If, on the other hand, there are no current software patents that are easily defineable as good, then I'd doubt your premise that the idea is fundamentally sound.
Are you sure? I thought the case was that while truth was an absolute defense, the burden of proof was on the defendant, and not, as it is in the US, initially on the petitioner.
Because we all know that no one now reading slashdot got started in computers before DOS 5 came out...
Sheesh. Someone just two or three years older than you wouldn't have had QBASIC to start with.
I mean, I'll admit that my first programs were in a BASIC variant, but they were on my TI-99/4A (which has been mentioned a few times here). After that, logo (TI LOGO II) on the same machine, and _then_ programming on a DOS box (gwbasic), followed by BASIC and 6502 assembly on Apple IIe's at school. (using a wonderful microcode simulator at first)
By the time QBASIC was available I was past using BASIC and had moved on to Turbo Pascal. (and intel assembly)
So what you're saying is that, under this binomial model, the combination: [ 1/2 share of stock, $45 liability on SOMEDATE ] is equivalent to the portfolio: [ Option to buy one share of stock at $100 on SOMEDATE ]
After mulling that over for a while, I can see how that's the case. What I'm having trouble with is how you determined that it costs $10 to put the combination portfolio together. The 1/2 share of stock costs $50, all but $5 of which is covered by the cost of the loan. Does obtaining the loan cost $5? Is there some cost in binding the two pieces of the loan together?
Another aspect that falls out of the above is one of respect. Since comprehending sloppily-written messages takes more time and effort, writing well is nothing less than displaying respect for the value of the time of one's readers, whereas writing poorly is stating that your time and effort is more valuable than that of the individual to whom you send your message. I make a serious effort to do this when writing material for others' consumption; consequently, I find it only reasonable for others to respond in kind.
I have found that, by and large, I hear messages as I type them. The end result is (I think) that I end up typing a message as I would say it. That is, the grammar, diction, etc. are as I'd say spoken words if I had the time to think about them generated by the typing delay. (I can only type at maybe 30 wpm tops)
Now granted, I'm being a bit more careful in this post than usual, because I'm thinking about it, but I just don't understand how people can possibly write the examples cited in that article - and I've seen it at my workplace too. I just don't understand how it is in any way easier to write in the sloppy, stream-of-consciousness manner that... well, let me exerpt something from my own emails (some proper names have been blanked out to protect, well, me)
I have also all XXXXXXXXX tables and sum others (XXXXXXX, sybase XXXXXX) to help u get familiar.
Let me know if u want to walk thru client connectivity and queries.
Now, I just don't understand how it is easier to produce this than it is to produce something that, say, has all the words there (I'm pretty sure there's supposed to be a verb before "all"), or something that spells "some", "through" or "you" correctly. I really don't.
I can understand someone occasionally swapping "it's" for "its" or "their" for "they're", or minor spelling mistakes along the lines of a dropped or added double letter (so long as the mistake doesn't result in another common word). I can also easily understand the occasional ambiguous antecedent or sentece fragment passed off as a complete sentence. I can even forgive the occasional accidentally omitted small grammar word ("to", "the", "a", "for", etc. though it's difficult to forgive when the omitted word is "not"). And stuff that happens naturally in English speech, such as the dreaded split infinitve, is fine too.
But that's not what's at issue here - here we're talking about people who write as they might talk when completely drunk. It honestly appears to me as though people who write this way are deliberately trying to make my life difficult, as I can't imagine anyone producing crud like this without real effort to confuse and slow down the reader. Just as it's common courtesy not to park your car any way you can in a parking lot, but to make at least a pretense of following the marked spaces, I really can't understand how producing crud as cited in the article isn't considered unthinkably rude.
Then again, I find writing documentation almost physically painful, so maybe I'm subconsciously engaging too much of my brain when I write prose, and would just be better off lobotomizing myself until the crud looks natural...
Ruby's remaining problems
on
RAD with Ruby
·
· Score: 3, Informative
Ruby still has two big problems that prevent it from being my scripting language of choice when compatibility with others isn't at issue:
I find Ruby's limited multi-language string support a bit surprising for a language that was created in Japan. Perl and python have had UTF support built into strings for... how long now? Come on, ruby, get with it. (I frankly would expect ruby to come with the swiss-army-knife character set support that you see in emacs+mule)
Performance. Compared to even, say, python, ruby has performance problems. Most of the time this isn't an issue, but when it is it makes me reach back for perl. Ruby's performance should be sufficiently good so that when I find ruby isn't fast enough, I'm at the point where what I need to do is reach for a compiled language.
Of course, any scripting language is a big disadvantage when compared to perl because only perl has CPAN. The organized central archive for extensions with support distributed as a standard module was a brilliant move by Larry Wall; every other scripting language is still playing catchup, and still no one else can compare to even where CPAN was four years ago. (RAA is better than nothing, but it's still not there. CPAN's hierarchical naming scheme, while occasionally inconsistent, was a really good idea)
For commercial use, I'd also want some of ruby's remaining licensing issues cleaned up, but I understand that's been taken care of. (I haven't checked lately)
There's a much bigger problem with the MM/DD/YY format. Namely, people who aren't American will misunderstand you.
In my office this is constantly a problem when people send out emails involving the dates various things will happen and write the date in the format MM/DD. For days after the twelfth of the month, that's fine. However, a significant minority of our office (who grew up Russian or British) will interpret "11/12" as December 11th.
The standard around here has been to switch to "DD MMM", e.g. "12 Nov.", or to do the full year-included ISO format. (Or occasionally 12Nov04, but that's silly) No one misinterprets either of those formats.
Also, it's not just computers that are more able to sort the ISO format. Sorting stacks of paper labeled with dates in the ISO format is visibly faster than sorting papers labeled with other date formats.
That just deals with the claim that the voting was miscounted in certain northern Florida counties that went solidly for Bush despite having an overwhelmingly Democratic (by registration) electorate.
Which, I'll notice, was not on the list.
An interesting thing, though, is why it was capable of being debunked: those counties use paper ballots (optical scan). Using the paper ballots does not seem to harm the counties in question any, and doesn't seem to delay results any more than other methods. Why people object to paper records is beyond me...
Actually, I can remember a recent Law and Order: SVU episode that portrayed people producing what many people would consider completely reprehensible porn - for urine fetishists - as just everyday businessmen out to make a buck. Of course, they spent all of about 30 seconds on camera, the main focus of the piece was the sicko-of-the-hour who turned out to be someone completely different.
I think that contributes to the bias that you see - those shows naturally don't spend much time on the perfectly well-adjusted porn star, because they don't spend much time on perfectly well-adjusted people of any stripe (except for the investigators).
You do realize that the vast majority of violent crimes are commited with melee weapons, don't you? Most violent crimes are acts of rage. Rage tends to be up-close and personal. And, gun-grabbers usually cite home-intrusion and domestic violence as the cases where a gun puts you at greater risk. Seems to me that both of these occur in relatively tight spaces.
Interesting assertion - got any statistics source to back it up?
If you look at murders - and not at violent crimes in general - this is demonstrably not true at all. Here's the FBI uniform crime report for 2003. Of the 14,408 murders reported to the FBI for 2003, 9638 were committed by firearm. That's over two-thirds (66.89%). If as you say the vast majority of violent crimes occur with non-firearm weapons, then this clearly shows that guns make violent crimes much more deadly than they would be otherwise.
When you break it up by category, you notice some more things, and those may help to explain the divide between people who can't see banning guns and those who can't understand why they're legal. Almost all (97%) juvenille gang killings happen with guns - moreover, although I suppose people could kill someone with a stray shot if bows were being used, I've never heard of a complete bystander being killed by a stray punch. It's the deadly consequences to people not directly involved in a conflict - as well as the increase in lethality when guns are involved - that leads to the call to ban guns.
Look at the most popular types of weapon bans: "assault" weapons, usually defined in law by some sort of criteria that boils down to how easy it is to fire X bullets in Y seconds. In other words, no one* is trying to ban weapons that will stop Tony Soprano from taking out someone with a loose tongue. They're trying to stop the public health threat from large numbers of flying metal particles.
By and large, the public doesn't care about the gangbanger who was killed in a shootout with a rival gang - they care about the three-year-old who was killed in front of her sister when a stray bullet from that shootout flew into their kitchen. Saying "guns don't kill people; people kill people" ignores this issue - if people with guns only killed their intended targets, there'd be little political will for any kind of gun ban.
The "you can't ban my gun" folks need to realize that the driving force behind gun bans is not that people are afraid of direct attacks by armed criminals (if they were, you'd see people buying their own guns for self defense, not urging a gun ban), but that guns present a public health danger above and beyond any criminal intentions of the gun weilder.
* I mean that practically no elected politician is trying to implement such a ban, as it would be political suicide. I don't deny that there are probably ban-all-firearms activist groups somewhere.
AKA "How to micro-optimize in perl"
on
Optimizing Perl
·
· Score: 3, Insightful
Look, this kind of "squeeze the last bit of performance" exercise can be nice fun for assembly, or possibly C, programmers, but when have you had something that was acceptable as a perl script, but only after extensive optimization?
Better yet, I would have liked pointers on how to test code snippets for performance (such as illustrating the use of Benchmark or Devel::SmallProf), and then possibly a few pointers like this. (and why was Memoize left out of an article like this?) This sounds like someone writing perl who'd rather be writing assembly code.
In optimizing my (and others') perl scripts, the best tools I've found are the profiler and an understanding of what the code is supposed to do. That, and changing the nature of deployment of the program - from a cgi script to mod_perl, for example. All these little techniques are chasing after grains of sand, when there's a big rock right in front of your face.
Gmail now will mark suspicious email with a banner that says something to the effect of "This email does not appear to be from who it claims. Learn More...", with a link to information about phishing scams.
Come on, mods. Up this one - the parent of it is at 5, but this (or the other reply that clarifies that Microsoft is proposing DRM-encumbered documentation) needs to be visible too. It's not plain MHT format that Microsoft is trying to use.
It has almost nothing to do with the format being one that (for the moment) only internet explorer can read. It has everything to do with the fact that the documentation is in a format designed to lock out free software. (I can't imagine that the license for Microsoft's DRM developers toolkit would allow one to release implementing code in source form)
On the other hand the court that made this decision must consist of the dumbest assholes ever. Ever. Unfucking believable.
One thing that I don't think anyone has mentioned in this discussion is that it is not the jury's job to determine whether a patent is valid. They must render their verdict based on the assumption that the patent is valid and that Kodak really owns it. The issue of patent validity is not one that the jury is allowed to consider. They just have to say, given that this patent exists and is valid, did Sun violate it? And the answer to that is that yes, Sun did.
It may well be that the jury, being drawn from an area where Kodak is a major, if not THE major, employer, was a bit biased. Fine; that's a legitimate concern. But since the jury could not find the patent invalid, everyone really needs to back off with their "how stupid does the jury have to be not to find this patent invalid?" comments.
Slashdot Mirror
You do realize that comparing the maximum possible sentence for one crime to the sentence actually meeted out in a specific instance of a different crime is truly an apples-to-oranges comparison, right?
Now, if you were comparing maximum sentences for different types of crimes, or were comparing the sentence of the average copyright infringer to that of the average rapist, you might be on your way to a point. However, just because some lawyer somewhere once got his guilty client a light sentence doesn't mean that suddenly all sentences everywhere must be reduced or else the system as a whole is unsupportably unfair.
(The system may in fact be incredibly unfair, but you need more than one second-hand anecdote about a completely different crime)
Well, look carefully at the ProCD ruling. (Again, IANAL, and even if I were this wouldn't be real legal advice) For example, see http://www.complaw.com/lawlibrary/procd.html.
As I read through the appellate court's reasoning, they seem to be saying that the knowledge at the time of sale that there is a license agreement, and that this purchase is subject to it, accompanied with the ability to reverse the entire transaction should the actual details of the agreement be unacceptable is sufficient to provide a EULA with enforceability. (Subject to the general things that would invalidate a contract, such as requiring one's first born in the fine print) A visible notice on the outside of the box saying "This software is subject to a license agreement which must be accepted before the software may be used" would be sufficient.
In your analysis, the relevant acceptance happened at the time of sale - you agreed to use the software only in accordance with whatever license agreement was inside, and to not use it if the terms inside were unacceptable.
Now, where I think current EULAs might get into trouble is that despite what the text of the EULA may say, you cannot in practice return opened software if you find the EULA unacceptable. Working this out requires more legal training than I have (none), but it may mean that EULAs are limited to what everyone expects EULAs to contain, which is a damn vague standard. (However, such a standard might throw out "no benchmarking" clauses)
Of course, if your state passes a law that explicitly delimits the scope and applicability of EULAs included in software sold over-the-counter, (e.g. UCITA) then that's a different matter.
Actually, that in and of itself isn't too hard - all an attacker would have to do is broadcast a very strong signal on a channel different than the one the accesspoint is using, but with the same SSID, and then have a second wireless card locked to the correct channel communicating with the "real" accesspoint. I don't know about Linux wireless, but my windows laptop has no problem reconnecting if I change the channel my access point is using. (and this is after I've locked it down so that it won't autoconnect to other networks, or even to my own if I disable WEP - the key has to match, but the channel can jump all over the place) Certainly if someone is going to connect to a network and sees two TMobile networks, one with a strong signal and one with a relatively weak signal, they'll choose the strong one. Also, who hasn't sat out in the Borders parking lot trying to use wireless that's normally only available inside Borders? And who would find it suspicious that the wireless signal now covered a much larger area?
If the accesspoint is set up as, for example, T Mobile accesspoints are, all access is initially blocked except web access, which is immediately redirected to a T-Mobile sign-on screen. Now I don't know whether the real sign-on screens use https or not, but certainly some phishers fake login screen wouldn't use https, and after a bit of niggly stuff left as an exercise for the reader, the victim has given the fake accesspoint all of the information necessary to log onto the network: either a TMobile userid and password, or their credit card details, etc.
And all of this because the victim never noticed that the login page he was automatically redirected to was served over http, and not https. Remember, the initial login redirect isn't an address anyone types in; they want to go where they want to go, and the login page is a familiar and accepted hurdle to jump over. Assuming that the attacker's setup does sufficiently complicated redirecting and rewriting of html on the fly, the page could in fact be an exact replica of the TMobile signon page, just served of plain http.
All this of course assumes that the initial login redirect is served over https to begin with. If the initial login page is served over plain http, then everything is much easier for the attacker, who just needs to forward packets back and forth and sniff like crazy. (there's still the minor problem of DHCP packets, which may need to be forwarded with the original MAC address intact, and so could make it difficult to phish many people at once, but...)
Instead, what you want to avoid this attack (unscrupulous network device in the middle) is SSL-enabled mail checking protocols.
Such as, say, secure POP and secure IMAP which the major mail clients have all supported for years, and which most mail servers now support out of the box, but which, for some reason, most ISPs don't make the default (or occasionally, don't even make possible)
GPG defends against J. unethical sysadmin at your mailhost reading the content of your email; while it would provide a protection against reading email here, it wouldn't prevent the sniffer from getting your username and password, which is probably what people are more worried about. (Besides, can you _guarantee_ that all of the people likely to send you sensitive email will use GPG? Even if you can, do you want to give some sniffer owner the ability to do whatever else he can with your email account, which may include filling webspace provided by your ISP with the latest warez, deleting all your email, setting up a "This dud got 0wn3d" auto-responder...)
Well, this makes sense only if you use the life expectancy at age 18 (or 21, or whatever your cutoff is for when someone enters the workforce). Life expectancy at birth is a stupid measure to use for this, because having a bunch of children die before the age of 1 affects social security not a bit. (They don't pay in, and they don't withdraw)
So how has life expectancy changed over the last century? Well, in one sense, it's risen dramatically - the life expectancy at birth is now something like 15 years longer than it was in 1940. However, most of that increase is due to advancements in keeping children from dying. At the other end of the spectrum, someone who made it to 65 in 1940 could expect to live, on average, another 12.7 years. Nowadays, they could expect to live another 15.3. That's a whopping 2.6 year increase. (I admit, the increase has been greater for women now that we've gotten better at diagnosing breast cancer - a woman who reaches age 65 now can look forward to 4.9 years more than one could who reached age 65 in 1940)
Remember this: life expectancy for adults today is not radically different than it was 60 years ago. The difference is that today we don't have as many children being wiped out by childhood diseases, so the average looks much higher if you watch the wrong statistic.
Reference: http://www.ssa.gov/history/lifeexpect.html
Um, no. It's a collection of (some discredited, some not) studies with extensive commentary that explains the studies as seen by the authors of the book - to present it as a dispassionate collection of peer-reviewed journal entries is fraud.
Among other things, the authors several times implicitly use the idea that studies on certain African tribes (who may have almost no descendants in the US) are accurate guides for the US black population. Unless you believe that melanin affects brain development (a bizarre biochemical theory if ever I heard one), there's no reason to suppose that studying African tribesmen gives you any more insight into a US population than studying a tribe of Tuvan goatherders on the Asian steppe - the genetic diversity of Americans, even those who are all lumped into one "race", is simply much too large.
The authors also present the idea that a single underlying factor can be constructed which correlates positively with a wide variety of test scores as evidence of innate immuteable intelligence. Now, while there may well be such a thing as innate intelligence, the fact that such an underlying measure can be constructed shows you nothing; you can construct an underlying factor to "demonstrate" that there is one innate trait that links hair color and femur length. The correlation won't be strong, but it will be there - and the g factor the authors demonstrate is rather weakly correlated with the outcomes they wish to explain by it.
(I haven't even gotten into the bit that speculates about dysgenic pressure on the US black population caused by promiscuous black men with unusually large genitals - and yes, that's in there too, and no, there is no study cited on cross-racial penis size)
There is. All you have to do is set them up with an ultra-restrictive shell, and with a home directory that no one but root can write to.
For example, you could write a simple C program that prints some specified string, sits and waits for some amount of time, then prints some other string and exits. Add some stuff to syslog along the way for fun (for example, log the arguments to see if they're trying sftp). Maybe you could even go a small tiny bit further and have an actual miniature shell, though that'd be too risky for my tastes.
Then, compile it statically - it shouldn't be an issue if you've got the home directory locked down, but I don't always trust that the attackers won't be able to sneak some harmful environmental variable in there somehow. Put it in
What I suspect you'll see is that you won't actually end up slowing these people down much; as the fake shell doesn't handle the "-c" option, they'll see the same result from:
ssh yourhost.com echo I got in
as they do from:
ssh yourhost.com
and then it's pretty obvious that this isn't a real compromised account.
Well, as a demonstration that the idea is fundamentally sound, can you point to any currently-in-force software patents that are "good" in some sense? We have enough examples on the bad side of the fence - perhaps if we had examples on both sides it would be easier to tell where the line is.
If, on the other hand, there are no current software patents that are easily defineable as good, then I'd doubt your premise that the idea is fundamentally sound.
Are you sure? I thought the case was that while truth was an absolute defense, the burden of proof was on the defendant, and not, as it is in the US, initially on the petitioner.
Because we all know that no one now reading slashdot got started in computers before DOS 5 came out...
Sheesh. Someone just two or three years older than you wouldn't have had QBASIC to start with.
I mean, I'll admit that my first programs were in a BASIC variant, but they were on my TI-99/4A (which has been mentioned a few times here). After that, logo (TI LOGO II) on the same machine, and _then_ programming on a DOS box (gwbasic), followed by BASIC and 6502 assembly on Apple IIe's at school. (using a wonderful microcode simulator at first)
By the time QBASIC was available I was past using BASIC and had moved on to Turbo Pascal. (and intel assembly)
"everyone" else. Kids these days...
So what you're saying is that, under this binomial model, the combination:
[ 1/2 share of stock, $45 liability on SOMEDATE ]
is equivalent to the portfolio:
[ Option to buy one share of stock at $100 on SOMEDATE ]
After mulling that over for a while, I can see how that's the case. What I'm having trouble with is how you determined that it costs $10 to put the combination portfolio together. The 1/2 share of stock costs $50, all but $5 of which is covered by the cost of the loan. Does obtaining the loan cost $5? Is there some cost in binding the two pieces of the loan together?
Now granted, I'm being a bit more careful in this post than usual, because I'm thinking about it, but I just don't understand how people can possibly write the examples cited in that article - and I've seen it at my workplace too. I just don't understand how it is in any way easier to write in the sloppy, stream-of-consciousness manner that... well, let me exerpt something from my own emails (some proper names have been blanked out to protect, well, me)
Now, I just don't understand how it is easier to produce this than it is to produce something that, say, has all the words there (I'm pretty sure there's supposed to be a verb before "all"), or something that spells "some", "through" or "you" correctly. I really don't.
I can understand someone occasionally swapping "it's" for "its" or "their" for "they're", or minor spelling mistakes along the lines of a dropped or added double letter (so long as the mistake doesn't result in another common word). I can also easily understand the occasional ambiguous antecedent or sentece fragment passed off as a complete sentence. I can even forgive the occasional accidentally omitted small grammar word ("to", "the", "a", "for", etc. though it's difficult to forgive when the omitted word is "not"). And stuff that happens naturally in English speech, such as the dreaded split infinitve, is fine too.
But that's not what's at issue here - here we're talking about people who write as they might talk when completely drunk. It honestly appears to me as though people who write this way are deliberately trying to make my life difficult, as I can't imagine anyone producing crud like this without real effort to confuse and slow down the reader. Just as it's common courtesy not to park your car any way you can in a parking lot, but to make at least a pretense of following the marked spaces, I really can't understand how producing crud as cited in the article isn't considered unthinkably rude.
Then again, I find writing documentation almost physically painful, so maybe I'm subconsciously engaging too much of my brain when I write prose, and would just be better off lobotomizing myself until the crud looks natural...
Of course, any scripting language is a big disadvantage when compared to perl because only perl has CPAN. The organized central archive for extensions with support distributed as a standard module was a brilliant move by Larry Wall; every other scripting language is still playing catchup, and still no one else can compare to even where CPAN was four years ago. (RAA is better than nothing, but it's still not there. CPAN's hierarchical naming scheme, while occasionally inconsistent, was a really good idea)
For commercial use, I'd also want some of ruby's remaining licensing issues cleaned up, but I understand that's been taken care of. (I haven't checked lately)
http://www.churchad.com/Preview.cfm?Name=802G
There's a much bigger problem with the MM/DD/YY format. Namely, people who aren't American will misunderstand you.
In my office this is constantly a problem when people send out emails involving the dates various things will happen and write the date in the format MM/DD. For days after the twelfth of the month, that's fine. However, a significant minority of our office (who grew up Russian or British) will interpret "11/12" as December 11th.
The standard around here has been to switch to "DD MMM", e.g. "12 Nov.", or to do the full year-included ISO format. (Or occasionally 12Nov04, but that's silly) No one misinterprets either of those formats.
Also, it's not just computers that are more able to sort the ISO format. Sorting stacks of paper labeled with dates in the ISO format is visibly faster than sorting papers labeled with other date formats.
That just deals with the claim that the voting was miscounted in certain northern Florida counties that went solidly for Bush despite having an overwhelmingly Democratic (by registration) electorate.
Which, I'll notice, was not on the list.
An interesting thing, though, is why it was capable of being debunked: those counties use paper ballots (optical scan). Using the paper ballots does not seem to harm the counties in question any, and doesn't seem to delay results any more than other methods. Why people object to paper records is beyond me...
Actually, I can remember a recent Law and Order: SVU episode that portrayed people producing what many people would consider completely reprehensible porn - for urine fetishists - as just everyday businessmen out to make a buck. Of course, they spent all of about 30 seconds on camera, the main focus of the piece was the sicko-of-the-hour who turned out to be someone completely different.
I think that contributes to the bias that you see - those shows naturally don't spend much time on the perfectly well-adjusted porn star, because they don't spend much time on perfectly well-adjusted people of any stripe (except for the investigators).
NASA probably didn't even tip them. Cheap bastards.
If you look at murders - and not at violent crimes in general - this is demonstrably not true at all. Here's the FBI uniform crime report for 2003. Of the 14,408 murders reported to the FBI for 2003, 9638 were committed by firearm. That's over two-thirds (66.89%). If as you say the vast majority of violent crimes occur with non-firearm weapons, then this clearly shows that guns make violent crimes much more deadly than they would be otherwise.
When you break it up by category, you notice some more things, and those may help to explain the divide between people who can't see banning guns and those who can't understand why they're legal. Almost all (97%) juvenille gang killings happen with guns - moreover, although I suppose people could kill someone with a stray shot if bows were being used, I've never heard of a complete bystander being killed by a stray punch. It's the deadly consequences to people not directly involved in a conflict - as well as the increase in lethality when guns are involved - that leads to the call to ban guns.
Look at the most popular types of weapon bans: "assault" weapons, usually defined in law by some sort of criteria that boils down to how easy it is to fire X bullets in Y seconds. In other words, no one* is trying to ban weapons that will stop Tony Soprano from taking out someone with a loose tongue. They're trying to stop the public health threat from large numbers of flying metal particles.
By and large, the public doesn't care about the gangbanger who was killed in a shootout with a rival gang - they care about the three-year-old who was killed in front of her sister when a stray bullet from that shootout flew into their kitchen. Saying "guns don't kill people; people kill people" ignores this issue - if people with guns only killed their intended targets, there'd be little political will for any kind of gun ban.
The "you can't ban my gun" folks need to realize that the driving force behind gun bans is not that people are afraid of direct attacks by armed criminals (if they were, you'd see people buying their own guns for self defense, not urging a gun ban), but that guns present a public health danger above and beyond any criminal intentions of the gun weilder.
* I mean that practically no elected politician is trying to implement such a ban, as it would be political suicide. I don't deny that there are probably ban-all-firearms activist groups somewhere.
Look, this kind of "squeeze the last bit of performance" exercise can be nice fun for assembly, or possibly C, programmers, but when have you had something that was acceptable as a perl script, but only after extensive optimization?
Better yet, I would have liked pointers on how to test code snippets for performance (such as illustrating the use of Benchmark or Devel::SmallProf), and then possibly a few pointers like this. (and why was Memoize left out of an article like this?) This sounds like someone writing perl who'd rather be writing assembly code.
In optimizing my (and others') perl scripts, the best tools I've found are the profiler and an understanding of what the code is supposed to do. That, and changing the nature of deployment of the program - from a cgi script to mod_perl, for example. All these little techniques are chasing after grains of sand, when there's a big rock right in front of your face.
Gmail now will mark suspicious email with a banner that says something to the effect of "This email does not appear to be from who it claims. Learn More...", with a link to information about phishing scams.
If you're going to take the time to type a word in ALL CAPS, is it too much to ask that you type the right word?
Come on, mods. Up this one - the parent of it is at 5, but this (or the other reply that clarifies that Microsoft is proposing DRM-encumbered documentation) needs to be visible too. It's not plain MHT format that Microsoft is trying to use.
It has almost nothing to do with the format being one that (for the moment) only internet explorer can read. It has everything to do with the fact that the documentation is in a format designed to lock out free software. (I can't imagine that the license for Microsoft's DRM developers toolkit would allow one to release implementing code in source form)
I admit that I'm usually above the base spelling troll, but seriously.
I mean, come on.
One thing that I don't think anyone has mentioned in this discussion is that it is not the jury's job to determine whether a patent is valid. They must render their verdict based on the assumption that the patent is valid and that Kodak really owns it. The issue of patent validity is not one that the jury is allowed to consider. They just have to say, given that this patent exists and is valid, did Sun violate it? And the answer to that is that yes, Sun did.
It may well be that the jury, being drawn from an area where Kodak is a major, if not THE major, employer, was a bit biased. Fine; that's a legitimate concern. But since the jury could not find the patent invalid, everyone really needs to back off with their "how stupid does the jury have to be not to find this patent invalid?" comments.