on my 64bit systems (alpha) running rh 7.1, this is not true. Upgrading is not really an option for me, and I consider them "remotely modern" because they are about 2.5 years old.
The person who submitted this Ask Slashdot question is considering buying a new AMD64 machine. Although I don't mean this in a harsh way, your own personal experience with a 2.5 year old linux distribution is not relevant to the submitter's situation, and you should not be using such experience as a basis for advice to someone in that situation.
If someone is purchasing new hardware today, it is pretty safe to say that the new hardware will be running a new operating system. To advise against the purchase based on your experiences with 2.5 year old versions of linux is, at best, not helpful.
Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.
Linking to a two year old kernel trap article is not very convincing, especially since the kernel trap article in question contains a fix for the very problem itself. I am quite sure the 2Tb limit for 64-bit platforms is fixed in Linux 2.6. The Linux LFS page dated 2004-04-21 claims that the 2Tb limit is only on 32-bit. However, I admit that I have not yet actually tried to create such a large block device.
platform does matter, how?
You take a look at this screenshot (again) and try to tell me that platform doesn't matter. The 32-bit platform on the left doesn't work, and the 64-bit platform on the right does work. That's pretty clear cut evidence to me.
Most of this post is just pure misinformation. Some of it has already been corrected in the replies. I will focus on the bits that have not yet been corrected.
Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs.
For example, cat over_2Gig_file >/dev/null will fail
I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.
Perhaps your problem is that you're not compiling your applications using the large file support API, which all modern distributions do for you whenever possible.
You will find these limitations from time to time, and rarely does the platform matter.
You take a look at this screenshot and try to tell me that platform doesn't matter.
Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).
Ironically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.
We could populate every planetary system in the milky way, create Trillions of humans, maybe even 10^100 humans, and take up MAYBE.005 % of the available planetary sytems in the universe.
10^100 is more than.005 % of the planetary systems. In fact, 10^100 is several dozen orders of magnitude larger than the estimated number of atoms in the known universe, and as far as we know every planetary system must contain at least one atom.
You might try to argue that the universe is much larger than the portion that we can detect right now, but that is a purely unscientific opinion with (by definition of the term "known universe") no data to back it up.
But honestly, if services are going to be mandated, we have to expect to pay for them.
The complaint is not that we have to pay for them. The complaint is that these fees are not honestly disclosed to the customer until after the customer is already signed up, in many cases to a long term contract.
Without up front disclosure of the amounts of the fees, it is impossible to make an informed choice of telecom company based on what the service really costs. The practice of hidden fees also unfairly penalizes those companies that satisfy the mandates more efficiently and thus can charge lower fees.
In short, nobody minds fees. The problem is the way the telecom companies deceptively advertise their prices without the fees.
What finally convinced me to switch to Apache 2.0 in at least one case is the external filters feature. I find filters useful enough to be worth all the extra baggage that 2.0 brings.
Even if you don't use mod_ext_filter directly, the extra programming hooks offered by the filter functionality are very useful for writing your own modules.
No, but opposing the only thing that seems to work makes you pro-spam.
Blocklists do not work. Paul Graham's site has done more to reduce my spam burden than all the blocklists in the world combined.
Furthermore, I do not oppose all blocklists. Please don't put words into my mouth like that. In fact the truth is SPEWS is the only major blocklist that I adamantly dislike. I oppose the SPEWS blocklist(s) because the SPEWS blocklists in particular have a false positive rate which is far too high to make them useful except in the most specialized of situations. There are many other blocklists that I do support (e.g. RBL and SBL) because the other blocklists take a more reasoned approach and do more net good than harm.
If the spam stops, ISPs are gradually delisted. It of course also helps if the ISP publicly (in the appropriate newsgroups) explains what they have done to get rid of spammers.
My opinion (unsubstantiated, subjective, but one that matches with most peoples' anecdotal experience) is that the SPEWS delisting process is too cumbersome for the database to be useful.
As for the effectiveness of the newsgroups, it has already been discussed in the other reply in this thread.
If you were serious about getting rid of spam, you would applaud the use of SPEWS and other blocklists.
Your attitude right here is the one that really bugs me. It's like George Bush saying "if you're not with us, you're against us." Well I beg to differ. I am quite serious about getting rid of spam. The difference between you and I is that when I see a bad anti-spam tactic being used I am not going to blindly support that tactic just because it might reduce spam, and heedless of the other costs involved.
Opposing the PATRIOT act does not make me unpatriotic or pro-terrorism. Likewise, opposing ineffective databases that do more damage than they solve does not make me pro-spam.
Your donation of 300 lines has not given you anything at all, except maybe a warm, fuzzy feeling.
If you had actually read my post, you would have discovered that I wrote those 300 lines because I specifically needed them for my own use. I certainly did personally gain from writing those 300 lines.
Once those 300 lines were written, the cost of donating them was exactly zero. With GPL software, there is not even any opportunity cost involved, since your only choices (literally) are to donate the software under the GPL, or not donate it at all to anyone under any terms.
It is therefore hard to see how any alternative action could possibly be logical under the circumstances. I wrote the code because I personally needed it, and I donated the code because I gained nothing from not donating it.
Free software is not capitalism... Capitalism assumes that people want to be reimbursed in some way.
Your problem is that you are narrow-mindedly assuming all reimbursement must be in the form of financial payment.
I have personally contributed about 300 lines of code to Debian, for free. In return, I have received all 15 million lines of code contained in Debian, available to use for free. If that doesn't count as reimbursement, I don't know what does.
Free software makes no logical sense, because people do it out of altruism and stupidity.
Let's logically analyze how stupid and altruistic my above mentioned contribution really is. I contributed 300 lines of useful code and got back 15 million lines.
Is this stupid? No. The 300 lines I contributed only took a few hours to write. The 15 million lines I got back takes a lifetime.
Is this altruistic? Not in my case. I wrote those 300 lines of code out of pure self interest. The only reason I wrote the code was because I needed it for my own use.
Does it make logical sense? It sure does. Each of the thousands of contributors receives far more value than he alone contributes.
How can this work while Communism failed? Because software is infinitely copiable. Communism tries to apply the sharing philosophy to material goods, which unlike software are not infinitely copiable.
What about the freeloader problem? Freeloaders are irrelevant for infinitely copiable goods. As long as the contributors themselves are adequately reimbursed, freeloaders do no harm.
The moral is, do not blindly assume that the economics of material goods apply to software. And please, for the love of god, do not attack all free software as having "no logical sense". If you're not gonna participate yourself (as is your right), at least don't interfere with other people who wish to participate out of their own free will (as is their right).
The best advice is to change to an ISP that doesn't support spammers.
SPEWS (and you, and all others who support this kind of blacklisting) would do well to realize that this advice is not always practical.
I'm thinking specifically of geographical areas that have only one monopoly broadband provider, who happens to be insufficiently zealous against spam. Are you seriously suggesting that people who live in such areas uproot their jobs, their families, and move to another town, to get another ISP, just to send a message to the ISPs?
The depressing part is that from reading the SPEWS FAQ their answer is clearly "yes".
What's more, since there is no way to get off the SPEWS database, there is also no incentive at all for rogue ISPs to improve their policies. SPEWS needs to realize that vigilantly removing reformers is just as important as vigilantly adding infringers. So far it is completely obvious that they are much more interested in adding people than removing people.
I'm not pro-spam here (nobody is). I'm not telling SPEWS to chill out because I want more spam. I'm telling SPEWS to chill out because their extreme radical position is not in their own self interest. Every mail server administrator I know (including myself) avoids SPEWS like the plague because their database is so heedless of false positives as to be useless.
I'm rapidly approaching the point where I need support for file sizes greater than 2GB. Quite frankly, most of what I've found about file sizes and file systems is 2 to 4 years old... Everyone's too concerned with speed!
Here's some real world information on the state of large file support in 2004. Filesystem driver support is the least of your worries -- almost any linux filesystem you can think of (except for maybe umsdos) supports over 2GB files at the kernel level. The Linux LFS page, dated April 2004, contains reasonably updated information on large file support in linux.
The bigger problem is that many userspace applications cannot yet read or write to the large files. This failure arises from non-use of the LFS API combined with just plain unfortunate use of a signed 32-bit int in the wrong place. So for instance mkisofs will reject all input files larger than 2GB in size, and cdrdao will simply abort at 2GB if you try to rip a DVD larger than 2GB in size. In some extreme cases there are programs that can't even handle large files off of the disk; one example is
which fails spectacularly on any x86 linux system (hint: the DVD is not really 84MB in size). In general, the "core" system utilities such as dd, cp, mv, cat are fully compatible with large files whereas third party applications are much more hit-or-miss.
Even today, by far the most practical solution to large file woes is to migrate to a 64-bit system, the most affordable of which is AMD64 by a long shot. I've been using an Athlon 64 system for the past few weeks and it has handled large files perfectly in all respects so far.
Re:WEP (in)security assumptions
on
Wi-Fi in the Sky
·
· Score: 1
You can't get the SSID with kismet if SSID broadcast is disabled and you can only get the MAC off the AP.
Both of these statements are absolutely false and indicate to me that you have no firsthand experience with using Kismet.
I have personally verified firsthand that Kismet can display cloaked SSIDs (provided the network is being used while you're running Kismet), and that Kismet does display the MAC addresses of the network cards connected to the AP
(again, assuming that the network is actively being used while you are running Kismet).
All you need in order to verify these claims yourself is any Prism II 802.11b card running in monitor mode in Linux with the Linux WLAN-ng drivers, and the latest version of Kismet. When any actively used network is in range, the program will display the above information 100% of the time.
Re:WEP (in)security assumptions
on
Wi-Fi in the Sky
·
· Score: 1
In addition to the ease of sniffing and spoofing MAC addresses, there remains the problem that anybody can sniff the contents of your wireless packets even if they aren't connected to your access point. MAC address checks can block attackers from connecting, but they won't block attackers from sniffing.
IPsec performs host authentication as well as data encryption, both using strong cryptography. Done properly it can solve both problems at once.
Re:WEP (in)security assumptions
on
Wi-Fi in the Sky
·
· Score: 4, Insightful
WEP is known to be insecure. However, for the average joe, it is good enough... would you as a hacker, spend a night in your car outside some dudes house in the hopes that they might compplete an online transaction with a CC?
I agree that for most people (and maybe even for me), WEP is good enough. However I should point out that I did actually spend a night cracking my own access point's WEP encryption and my success in that effort is what motivated me to seek a better solution.
My bigger objection is with the article's premise that the unWEP'd networks are automatically insecure. WEP is neither necessary nor (fully) sufficient for really good security. People who really know what they're doing don't actually use WEP. The writers of this article (and many other writers) present a very simple "TURN ON WEP" message that does not adequately convey the subtleties of what is in fact a very complicated security situation.
I don't necessarily expect a sermon in every article, but I would appreciate a more moderated message and at least some kind of acknowledgement that there is more going on behind the scenes.
WEP (in)security assumptions
on
Wi-Fi in the Sky
·
· Score: 5, Interesting
The article incorrectly assumes that WEP enabled networks are more secure
than non-WEP enabled networks. You can tell by the red/green color choices
and the choice imprecations that the authors think poorly of un-WEPd
networks. Unfortunately, in reality the best way to secure
a wireless network is one that does not involve WEP. It is well known that WEP is insecure and thus one must resort to other means in order to secure a wireless network against known attacks.
As a starting point, the WaveSEC homepage describes a way to secure a wireless network entirely using IPsec,
without relying on WEP. In addition, for a small
home network you can get away with static IP addressing instead of using
DHCP, and in this way you can gain all the benefits of WaveSEC security
without needing any software patches (since if you look closely all the
software patches are DHCP related).
IPsec is supported in Windows 2000 and up, Linux 2.6 (natively) or 2.0 and up (with Free S/WAN patches), and FreeBSD; unfortunately I have no firsthand knowledge of MacOS support. The main drawback of IPsec is that it is a very complicated protocol and takes
a lot of effort to set up. Making different systems interoperate with each other is especially challenging -- for this task, I recommend the Free S/WAN interop page which links to an eclectic pile of guides covering
most of the possible combinations.
My own home wireless network is a mix of Linux and Windows XP clients
all connected via IPsec, and I have much more confidence in its security
than I would otherwise have with WEP.
Although the Times doesn't pay retail for the service, the FBI calculated Lamo's damages using the full Lexis-Nexis rate, which added up to a shocking $300,000. It was clearly a punitive figure. Had Lamo simply bought an unlimited three-month account with Lexis-Nexis rather than piggybacking off the Times, it would have cost him just $1,500.
I know this recommendation sounds silly to many people here who hate touchpads to death, but let me finish this post before you pass judgment.
The FingerWorks iGesture touchpad is a zero force, no button, standard USB interface mouse that has none of the annoying features of standard touchpads and is just as efficient as a standard mouse with none of the strain.
It uses different finger combinations to trigger different mouse functions such as left click, right click, drag, scroll wheel, and so on. It can sense which fingers you are using, and most importantly, it doesn't trigger mouse motion when you accidentally brush your hand against it because it can tell the difference between your fingers and your hand.
The iGesture pad is good enough to recommend even to people without wrist pain. But for anyone who actually is suffering physical strain from mouse use, it's almost a no-brainer.
(I have no relationship to FingerWorks except as a user of their products.)
I'm not here to defend the submitter, but if you ignore the submitter and read the patent application itself (N.B. the link you provide is only a patent application, not an approved patent), there is still plenty enough prior art to invalidate the claims.
We first note that the application date is January 31, 2001, so any examples of prior art have to predate this date. I can think of several examples of prior art off the top of my head and I'm not even an expert in this field:
Top level domain name services, such as register.com or even VeriSign, existed well before 2001 and do exactly what this patent describes. The patent seems to be written as if the term "domain name" means "second level domain name under the COM, NET, or ORG hierarchies," but it never actually specifies this. In reality, COM itself is a "domain name" and the concept of licensing sub-domains of COM via an internet portal is not new.
Even if we restrict our prior art search to second level domain names, there are many country-specific second level domain names such as co.uk and ne.jp that have been selling subdomain registrations via internet servers since well before 2001.
This patent application has no legal merit and should clearly be rejected. If it is accepted, it will be fairly easy to invalidate in court, although the cost of mounting a court battle would be a regrettable loss.
The information in the drive is actually just a number that says what region the drive is supposed to be. The drive will still read all of the information off of the disc.
Absolutely false. Used to be true before 1999, but it is not true anymore. I wrote the Linux DVD Playback HOWTO, so I should know.
The interaction between region flags and CSS encryption is confusing and it is not surprising that people often get it wrong. For computer DVD players there are actually three levels of region playback enforcement:
A player application such as WinDVD or PowerDVD will refuse to play back discs that do not match the region setting stored in the application.
An operating system such as Microsoft Windows will refuse to read data from discs that do not match the region stored in the OS registry.
For RPC-2 drives manufactured after 1999, the drive firmware itself will refuse to apply CSS decryption to discs that do not match the region stored in the drive firmware.
Obviously points 1 & 2 are trivial to bypass in software, but 3 is harder. In order to bypass 3 you need to actually crack the CSS encryption (assuming there is any; not all movies use CSS), or modify the drive firmware to ignore region flags. Point 3 is often used to justify CSS decryption tools on the grounds that CSS decryption is needed for out of region discs, but there's no actual dependency between region flags and CSS. The relationship between the two is just an accidental consequence of how RPC-2 is implemented.
The problem is that everyone has an issue like yours.
It's not my issue. I don't actually care that deeply about drunk driving laws. If anything my number one legal concern in this country is the (overreaching) state of intellectual property and digital copyright laws, which has far fewer lives at stake but happens to affect my life, career, hobbies, and livelihood directly.
The only point I am trying to make about drunk driving is that, by any conceivable rational analysis, drunk driving deserves to be one of the top areas of legal regulation, if not the top area. I am not arguing that everybody's top issue should be independently honored or debated. In fact I am saying quite the opposite: even if you already have another pet issue (as I do), you have to be in denial if you think yours is much more important than drunk driving.
I have already mentioned that auto accidents are the leading cause of death for people my age. If that alone is not enough justification to make driving regulations a top issue, I don't know what is.
Drunk driving laws should not be a "bitch" issue with deep support from a small minority of special interest voters. Heck, I don't even support them that deeply. It should instead be a universal issue with broad support, because it affects all our lives more than any other single regulatable issue.
The only reason I brought up terrorism deaths is that a lot of people in slashdot are comparing DUI regulations with anti-terrorism regulations. They argue that since the latter is bad the former must be bad too.
My point which you seem to have missed is that I think DUI regulations are far more justified than anti-terrorism regulations. I am against the PATRIOT act, I am against TIA, I am against our new ineffective airline security measures, but I am supportive of limited government intervention against drunk driving, because drunk driving kills far more people than terrorism.
You also seem to have missed the sentence where I pointed out that auto accidents are by far the leading cause of death in my age group. Even if it "isn't that much", the fact that it is #1 already means that it deserves more attention than any other cause.
I'd like to chime in a bit here with a little perspective. I'm normally extremely opposed to government intervention in individual rights -- read any of my past posts if you don't believe me. I think government policy on terrorists, drugs, music downloading, and DVD restrictions are just plain wrong.
But if there ever is a situation where strong government regulation is justified, it would have to be drunk driving. Automobile accidents, even the fraction involving alcohol, are far and away the leading cause of death for Americans in my age group (18-30). Every year, in the US alone, car crashes kill ten times more people than died in 9-11. Drunk driving is not an illusory threat with no real impact on innocent people. It is a very real threat and most of its impact falls on innocent people.
Yes, you read that last sentence right -- innocent parties are more likely to die in drunk driving accidents than the drunk driver, because a limp body survives accidents better than a braced body (even without mentioning that the innocent party is not always in a car). That's why so many drunk drivers are repeat offenders: they survive their accidents. It's also why jailing drunk drivers has just about the largest payoff-to-cost ratios of almost any type of incarceration.
Now I am not saying I necessarily support New Mexico's proposed action (I need to think about it more), but the fact that I need to think about it is saying a lot, for someone with my views.
You can greatly increase the storage life of a battery by putting it in the refrigerator. See the battery faq for storage guidelines. Proper storage conditions can limit li-ion batteries to 2% loss per year.
In general I agree that battery purchases should be delayed until you need them, but the availability of the battery must also be considered. Oftentimes, new batteries will no longer be available from the manufacturer if you wait five years to buy one.
While NTSC technically uses 30 frames per second, it is interlaced. This means there are 60 fields per second. This makes it almost look like its going at 60 frames per second.
I have to say that you're the one who is confused here. Do you know what interlacing really means?
It means that each individual pixel by itself only has to refresh 30 times per second, but the image as a whole refreshes 60 times per second. This is accomplished by refreshing half the pixels on the screen each time, and doing this for 60 times per second.
In other words, a 16ms per-pixel response time is way more than enough to display 60 fields per second interlaced without blurring.
You are also (deliberately?) confusing screen refresh with motion refresh. No LCD in the world uses a screen refresh of 60hz. The 60hz refresh time for LCDs only applies to changing images. Static images on an LCD have effectively infinite refresh rate because of the inertia of the crystal state.
Moreover, computer video often does not use any interlacing at all because the video on a DVD is often encoded as full frame progressive non-interlaced video with subsequent interlacing added by the DVD player when (and only when) displaying on a normal television set. In these situations, computer playback yields a cinematic rate of 24 frames per second with no absolutely no field level interlacing.
In fact even video which is encoded interlaced often allows the original progressive frames to be recovered 100% perfectly using inverse telecine techniques. I wrote the Linux Digital Fansubbing Guide and I have watched a lot of digital video which uses telecine -- I know what I'm talking about here.
I should note that I'm not really trying to defend LCD screens here. I find LCDs perfect for text and office work but I do not use them for video work, not because of refresh rate, but because of color accuracy (or lack thereof). However I do feel that your reasons for rejecting LCDs are not based on any legitimate or correct reasons.
The proof in modern math is rarely an absolute certainty and almost never starts with axioms.
I agree that practical obstacles prevent certainty from being achieved in many cases, but this is not any reason to dismiss the concept of proof as misconceived.
Perhaps a weaker statement would illustrate the difference that I am trying to present: there exist proofs in mathematics that do start with axioms and have been verified with absolute certainty. Even this very weak existential level of certainty is theoretically impossible under any empirical paradigm.
Slashdot Mirror
The person who submitted this Ask Slashdot question is considering buying a new AMD64 machine. Although I don't mean this in a harsh way, your own personal experience with a 2.5 year old linux distribution is not relevant to the submitter's situation, and you should not be using such experience as a basis for advice to someone in that situation.
If someone is purchasing new hardware today, it is pretty safe to say that the new hardware will be running a new operating system. To advise against the purchase based on your experiences with 2.5 year old versions of linux is, at best, not helpful.
Logical volumes can be created beyond 2Tb, but block devices cannot. There are many kernel posts about this and this kernel trap article about it.
Linking to a two year old kernel trap article is not very convincing, especially since the kernel trap article in question contains a fix for the very problem itself. I am quite sure the 2Tb limit for 64-bit platforms is fixed in Linux 2.6. The Linux LFS page dated 2004-04-21 claims that the 2Tb limit is only on 32-bit. However, I admit that I have not yet actually tried to create such a large block device.
platform does matter, how?
You take a look at this screenshot (again) and try to tell me that platform doesn't matter. The 32-bit platform on the left doesn't work, and the 64-bit platform on the right does work. That's pretty clear cut evidence to me.
Just today I had a user mail me with an error with rcp because it could not transfer a file that was 2.1Gigs.
For example, cat over_2Gig_file > /dev/null will fail
I could see this as being true "6 or 7 years" ago, but any remotely modern linux distribution will NOT have a problem with this, even on 32-bit platforms. Here is a screenshot debunking your claims for both rcp and cat.
Perhaps your problem is that you're not compiling your applications using the large file support API, which all modern distributions do for you whenever possible.
You will find these limitations from time to time, and rarely does the platform matter.
You take a look at this screenshot and try to tell me that platform doesn't matter.
Also, Linux has other limitations like it cannot access a block device over 1 or 2 Tb (depending on the kernel version).
Ironically, the one limitation that you do state correctly is also one of the limitations that only applies to 32-bit systems. It sounds like you need a 64-bit system after all, preferably a modern distribution like Fedora 2 or SuSE 9.1 that doesn't have any of the weird userspace problems that you bring up.
10^100 is more than .005 % of the planetary systems. In fact, 10^100 is several dozen orders of magnitude larger than the estimated number of atoms in the known universe, and as far as we know every planetary system must contain at least one atom.
You might try to argue that the universe is much larger than the portion that we can detect right now, but that is a purely unscientific opinion with (by definition of the term "known universe") no data to back it up.
The complaint is not that we have to pay for them. The complaint is that these fees are not honestly disclosed to the customer until after the customer is already signed up, in many cases to a long term contract.
Without up front disclosure of the amounts of the fees, it is impossible to make an informed choice of telecom company based on what the service really costs. The practice of hidden fees also unfairly penalizes those companies that satisfy the mandates more efficiently and thus can charge lower fees.
In short, nobody minds fees. The problem is the way the telecom companies deceptively advertise their prices without the fees.
Even if you don't use mod_ext_filter directly, the extra programming hooks offered by the filter functionality are very useful for writing your own modules.
Blocklists do not work. Paul Graham's site has done more to reduce my spam burden than all the blocklists in the world combined.
Furthermore, I do not oppose all blocklists. Please don't put words into my mouth like that. In fact the truth is SPEWS is the only major blocklist that I adamantly dislike. I oppose the SPEWS blocklist(s) because the SPEWS blocklists in particular have a false positive rate which is far too high to make them useful except in the most specialized of situations. There are many other blocklists that I do support (e.g. RBL and SBL) because the other blocklists take a more reasoned approach and do more net good than harm.
My opinion (unsubstantiated, subjective, but one that matches with most peoples' anecdotal experience) is that the SPEWS delisting process is too cumbersome for the database to be useful. As for the effectiveness of the newsgroups, it has already been discussed in the other reply in this thread.
If you were serious about getting rid of spam, you would applaud the use of SPEWS and other blocklists.
Your attitude right here is the one that really bugs me. It's like George Bush saying "if you're not with us, you're against us." Well I beg to differ. I am quite serious about getting rid of spam. The difference between you and I is that when I see a bad anti-spam tactic being used I am not going to blindly support that tactic just because it might reduce spam, and heedless of the other costs involved.
Opposing the PATRIOT act does not make me unpatriotic or pro-terrorism. Likewise, opposing ineffective databases that do more damage than they solve does not make me pro-spam.
If you had actually read my post, you would have discovered that I wrote those 300 lines because I specifically needed them for my own use. I certainly did personally gain from writing those 300 lines.
Once those 300 lines were written, the cost of donating them was exactly zero. With GPL software, there is not even any opportunity cost involved, since your only choices (literally) are to donate the software under the GPL, or not donate it at all to anyone under any terms.
It is therefore hard to see how any alternative action could possibly be logical under the circumstances. I wrote the code because I personally needed it, and I donated the code because I gained nothing from not donating it.
Your problem is that you are narrow-mindedly assuming all reimbursement must be in the form of financial payment.
I have personally contributed about 300 lines of code to Debian, for free. In return, I have received all 15 million lines of code contained in Debian, available to use for free. If that doesn't count as reimbursement, I don't know what does.
Free software makes no logical sense, because people do it out of altruism and stupidity.
Let's logically analyze how stupid and altruistic my above mentioned contribution really is. I contributed 300 lines of useful code and got back 15 million lines.
- Is this stupid? No. The 300 lines I contributed only took a few hours to write. The 15 million lines I got back takes a lifetime.
- Is this altruistic? Not in my case. I wrote those 300 lines of code out of pure self interest. The only reason I wrote the code was because I needed it for my own use.
- Does it make logical sense? It sure does. Each of the thousands of contributors receives far more value than he alone contributes.
- How can this work while Communism failed? Because software is infinitely copiable. Communism tries to apply the sharing philosophy to material goods, which unlike software are not infinitely copiable.
- What about the freeloader problem? Freeloaders are irrelevant for infinitely copiable goods. As long as the contributors themselves are adequately reimbursed, freeloaders do no harm.
The moral is, do not blindly assume that the economics of material goods apply to software. And please, for the love of god, do not attack all free software as having "no logical sense". If you're not gonna participate yourself (as is your right), at least don't interfere with other people who wish to participate out of their own free will (as is their right).SPEWS (and you, and all others who support this kind of blacklisting) would do well to realize that this advice is not always practical.
I'm thinking specifically of geographical areas that have only one monopoly broadband provider, who happens to be insufficiently zealous against spam. Are you seriously suggesting that people who live in such areas uproot their jobs, their families, and move to another town, to get another ISP, just to send a message to the ISPs?
The depressing part is that from reading the SPEWS FAQ their answer is clearly "yes".
What's more, since there is no way to get off the SPEWS database, there is also no incentive at all for rogue ISPs to improve their policies. SPEWS needs to realize that vigilantly removing reformers is just as important as vigilantly adding infringers. So far it is completely obvious that they are much more interested in adding people than removing people.
I'm not pro-spam here (nobody is). I'm not telling SPEWS to chill out because I want more spam. I'm telling SPEWS to chill out because their extreme radical position is not in their own self interest. Every mail server administrator I know (including myself) avoids SPEWS like the plague because their database is so heedless of false positives as to be useless.
Here's some real world information on the state of large file support in 2004. Filesystem driver support is the least of your worries -- almost any linux filesystem you can think of (except for maybe umsdos) supports over 2GB files at the kernel level. The Linux LFS page, dated April 2004, contains reasonably updated information on large file support in linux.
The bigger problem is that many userspace applications cannot yet read or write to the large files. This failure arises from non-use of the LFS API combined with just plain unfortunate use of a signed 32-bit int in the wrong place. So for instance mkisofs will reject all input files larger than 2GB in size, and cdrdao will simply abort at 2GB if you try to rip a DVD larger than 2GB in size. In some extreme cases there are programs that can't even handle large files off of the disk; one example is
wget http://mirror.linux.duke.edu/pub/fedora/linux/core /test/1.92/i386/iso/FC2-test3-i386-DVD.iso
which fails spectacularly on any x86 linux system (hint: the DVD is not really 84MB in size). In general, the "core" system utilities such as dd, cp, mv, cat are fully compatible with large files whereas third party applications are much more hit-or-miss.
Even today, by far the most practical solution to large file woes is to migrate to a 64-bit system, the most affordable of which is AMD64 by a long shot. I've been using an Athlon 64 system for the past few weeks and it has handled large files perfectly in all respects so far.
Both of these statements are absolutely false and indicate to me that you have no firsthand experience with using Kismet.
I have personally verified firsthand that Kismet can display cloaked SSIDs (provided the network is being used while you're running Kismet), and that Kismet does display the MAC addresses of the network cards connected to the AP (again, assuming that the network is actively being used while you are running Kismet).
All you need in order to verify these claims yourself is any Prism II 802.11b card running in monitor mode in Linux with the Linux WLAN-ng drivers, and the latest version of Kismet. When any actively used network is in range, the program will display the above information 100% of the time.
IPsec performs host authentication as well as data encryption, both using strong cryptography. Done properly it can solve both problems at once.
I agree that for most people (and maybe even for me), WEP is good enough. However I should point out that I did actually spend a night cracking my own access point's WEP encryption and my success in that effort is what motivated me to seek a better solution.
My bigger objection is with the article's premise that the unWEP'd networks are automatically insecure. WEP is neither necessary nor (fully) sufficient for really good security. People who really know what they're doing don't actually use WEP. The writers of this article (and many other writers) present a very simple "TURN ON WEP" message that does not adequately convey the subtleties of what is in fact a very complicated security situation.
I don't necessarily expect a sermon in every article, but I would appreciate a more moderated message and at least some kind of acknowledgement that there is more going on behind the scenes.
As a starting point, the WaveSEC homepage describes a way to secure a wireless network entirely using IPsec, without relying on WEP. In addition, for a small home network you can get away with static IP addressing instead of using DHCP, and in this way you can gain all the benefits of WaveSEC security without needing any software patches (since if you look closely all the software patches are DHCP related).
IPsec is supported in Windows 2000 and up, Linux 2.6 (natively) or 2.0 and up (with Free S/WAN patches), and FreeBSD; unfortunately I have no firsthand knowledge of MacOS support. The main drawback of IPsec is that it is a very complicated protocol and takes a lot of effort to set up. Making different systems interoperate with each other is especially challenging -- for this task, I recommend the Free S/WAN interop page which links to an eclectic pile of guides covering most of the possible combinations.
My own home wireless network is a mix of Linux and Windows XP clients all connected via IPsec, and I have much more confidence in its security than I would otherwise have with WEP.
From Wired's interview:
The FingerWorks iGesture touchpad is a zero force, no button, standard USB interface mouse that has none of the annoying features of standard touchpads and is just as efficient as a standard mouse with none of the strain.
It uses different finger combinations to trigger different mouse functions such as left click, right click, drag, scroll wheel, and so on. It can sense which fingers you are using, and most importantly, it doesn't trigger mouse motion when you accidentally brush your hand against it because it can tell the difference between your fingers and your hand.
The iGesture pad is good enough to recommend even to people without wrist pain. But for anyone who actually is suffering physical strain from mouse use, it's almost a no-brainer.
(I have no relationship to FingerWorks except as a user of their products.)
We first note that the application date is January 31, 2001, so any examples of prior art have to predate this date. I can think of several examples of prior art off the top of my head and I'm not even an expert in this field:
This patent application has no legal merit and should clearly be rejected. If it is accepted, it will be fairly easy to invalidate in court, although the cost of mounting a court battle would be a regrettable loss.
Absolutely false. Used to be true before 1999, but it is not true anymore. I wrote the Linux DVD Playback HOWTO, so I should know.
The interaction between region flags and CSS encryption is confusing and it is not surprising that people often get it wrong. For computer DVD players there are actually three levels of region playback enforcement:
- A player application such as WinDVD or PowerDVD will refuse to play back discs that do not match the region setting stored in the application.
- An operating system such as Microsoft Windows will refuse to read data from discs that do not match the region stored in the OS registry.
- For RPC-2 drives manufactured after 1999, the drive firmware itself will refuse to apply CSS decryption to discs that do not match the region stored in the drive firmware.
Obviously points 1 & 2 are trivial to bypass in software, but 3 is harder. In order to bypass 3 you need to actually crack the CSS encryption (assuming there is any; not all movies use CSS), or modify the drive firmware to ignore region flags. Point 3 is often used to justify CSS decryption tools on the grounds that CSS decryption is needed for out of region discs, but there's no actual dependency between region flags and CSS. The relationship between the two is just an accidental consequence of how RPC-2 is implemented.It's not my issue. I don't actually care that deeply about drunk driving laws. If anything my number one legal concern in this country is the (overreaching) state of intellectual property and digital copyright laws, which has far fewer lives at stake but happens to affect my life, career, hobbies, and livelihood directly.
The only point I am trying to make about drunk driving is that, by any conceivable rational analysis, drunk driving deserves to be one of the top areas of legal regulation, if not the top area. I am not arguing that everybody's top issue should be independently honored or debated. In fact I am saying quite the opposite: even if you already have another pet issue (as I do), you have to be in denial if you think yours is much more important than drunk driving.
I have already mentioned that auto accidents are the leading cause of death for people my age. If that alone is not enough justification to make driving regulations a top issue, I don't know what is.
Drunk driving laws should not be a "bitch" issue with deep support from a small minority of special interest voters. Heck, I don't even support them that deeply. It should instead be a universal issue with broad support, because it affects all our lives more than any other single regulatable issue.
My point which you seem to have missed is that I think DUI regulations are far more justified than anti-terrorism regulations. I am against the PATRIOT act, I am against TIA, I am against our new ineffective airline security measures, but I am supportive of limited government intervention against drunk driving, because drunk driving kills far more people than terrorism.
You also seem to have missed the sentence where I pointed out that auto accidents are by far the leading cause of death in my age group. Even if it "isn't that much", the fact that it is #1 already means that it deserves more attention than any other cause.
But if there ever is a situation where strong government regulation is justified, it would have to be drunk driving. Automobile accidents, even the fraction involving alcohol, are far and away the leading cause of death for Americans in my age group (18-30). Every year, in the US alone, car crashes kill ten times more people than died in 9-11. Drunk driving is not an illusory threat with no real impact on innocent people. It is a very real threat and most of its impact falls on innocent people.
Yes, you read that last sentence right -- innocent parties are more likely to die in drunk driving accidents than the drunk driver, because a limp body survives accidents better than a braced body (even without mentioning that the innocent party is not always in a car). That's why so many drunk drivers are repeat offenders: they survive their accidents. It's also why jailing drunk drivers has just about the largest payoff-to-cost ratios of almost any type of incarceration.
Now I am not saying I necessarily support New Mexico's proposed action (I need to think about it more), but the fact that I need to think about it is saying a lot, for someone with my views.
In general I agree that battery purchases should be delayed until you need them, but the availability of the battery must also be considered. Oftentimes, new batteries will no longer be available from the manufacturer if you wait five years to buy one.
I have to say that you're the one who is confused here. Do you know what interlacing really means?
It means that each individual pixel by itself only has to refresh 30 times per second, but the image as a whole refreshes 60 times per second. This is accomplished by refreshing half the pixels on the screen each time, and doing this for 60 times per second.
In other words, a 16ms per-pixel response time is way more than enough to display 60 fields per second interlaced without blurring.
You are also (deliberately?) confusing screen refresh with motion refresh. No LCD in the world uses a screen refresh of 60hz. The 60hz refresh time for LCDs only applies to changing images. Static images on an LCD have effectively infinite refresh rate because of the inertia of the crystal state.
Moreover, computer video often does not use any interlacing at all because the video on a DVD is often encoded as full frame progressive non-interlaced video with subsequent interlacing added by the DVD player when (and only when) displaying on a normal television set. In these situations, computer playback yields a cinematic rate of 24 frames per second with no absolutely no field level interlacing.
In fact even video which is encoded interlaced often allows the original progressive frames to be recovered 100% perfectly using inverse telecine techniques. I wrote the Linux Digital Fansubbing Guide and I have watched a lot of digital video which uses telecine -- I know what I'm talking about here.
I should note that I'm not really trying to defend LCD screens here. I find LCDs perfect for text and office work but I do not use them for video work, not because of refresh rate, but because of color accuracy (or lack thereof). However I do feel that your reasons for rejecting LCDs are not based on any legitimate or correct reasons.
I agree that practical obstacles prevent certainty from being achieved in many cases, but this is not any reason to dismiss the concept of proof as misconceived.
Perhaps a weaker statement would illustrate the difference that I am trying to present: there exist proofs in mathematics that do start with axioms and have been verified with absolute certainty. Even this very weak existential level of certainty is theoretically impossible under any empirical paradigm.