You could say exactly the same about any purchase. The reality is, spending money is not a cost to the economy - it's exactly the transaction the economy is built from.
True enough. My point was that you're talking about real money, rather than the hypothetical money that the RIAA claims to be losing.
It doesn't bar real competition. [...] Patents bar clones - you can't just go and write your own RealPlayer, assuming they've patented that, but you can go and write your own video player, just as Apple and Microsoft did.
Clones are the real competition. If you need to play RealPlayer content, a video player from Apple or Microsoft doesn't do you any good when it can't play that content. You're locked into using RealPlayer. Since Real has a monopoly in this market, they can charge any price, no matter how exorbitant. And as the consumer, you can't go to a competitor offering a better price -- the competitor's product (while similar) doesn't meet your needs. You're stuck with the monopolist.
Economists call this "inefficient", while fair markets are called "efficient". Prices in an efficient market tend toward the marginal cost. Of course, this tends towards minimal profit, since a "perfectly efficient" market would set the price equal to the marginal cost, which would mean zero profit. That doesn't tend to happen, since there's no incentive to stay in a market without any profit, but highly competitive markets for commodity goods do tend to operate on razor-thin profit margins...
The money still gets spent, just in a different place. No net gain, you're just taking money from Thompson and giving it to another company instead. What about when Thompson spends the money they get in license fees? What about the development it would otherwise have funded - where do you think MP3Pro came from?
Yes, the monopolist will spend their money too. That doesn't mean it's a wash for society. Monopoly rents extract substantial costs from society at large (in various ways) for the benefit of the monopolist. When the monopolist spends that money, the value to society and the economy doesn't match the costs that were extracted. This is exactly why economists call it "inefficient" and are very wary of monopolists...
Ah, the RIAA argument: it's "costing" billions, because you think billions might otherwise be made. Nice try. It's creating money for the owners. Perhaps some other system would make them more money, perhaps not - but you cannot claim it is "costing" the economy anything.
The money the owners get isn't created out of thin air. It's paid by those who license the patent. That's money they can't spend on other things -- it's quite legitimate to say that the license fees on a patent are a real cost to the economy. More importantly, the patent bars competition, which lowers prices -- another cost to the economy. Talk to any economist. They'll tell you that the impact of "monopoly rents" on the economy is real, not imaginary.
The RIAA argument is different -- they assume (like the BSA does) that everyone who "pirates" their products would have otherwise purchased those unauthorized copies at full retail price. This conveniently ignores the fact that most casual "piracy" occurs because it's low-cost, low-risk, and doesn't harm anyone else, and most of that material would not be purchased at full price otherwise.
On the other hand, if nobody has to pay monopoly rents to license a patent, that's real money they don't have to spend, and they'll certainly find another way to spend it. So the costs involved in patents are real, unlike RIAA's imaginary "losses". (Patent licensing fees lost because people refuse to pay for a license, yet use the patented code, would be more analogous.)
Interesting... this seems to be saying that, through the use of the GPL, the FSF is, perhaps unwittingly, attempting to create a monopoly.
Unwittingly? The FSF's goal has always been to dominate all software with GPL software, and to render proprietary software irrelevant (ideally, to extinguish it entirely) -- this agenda has never really been secret.
What, then, is the FSF's dirty little secret? GPL software is also proprietary software. Try as they might to clothe their arguments in "freedom", the truth of the matter is that the proprietary benefits of the GPL are only available to those who are willing to accept the GPL's mandate and place their related code under the GPL.
Admission to this group is open and "free", except of course for the cost of writing all the code which can only be given away. (Yes, I know you can sell GPL code, but your first customer can give it away free to any other potential customers, so good luck recouping development costs from GPL sales!)
It's still the user's choice whether or not to *use* the software. Simply because they can't take GPL'd software and package it without the source and sell it doesn't mean that the software is part of a monopoly... geez! The GPL certainly is another form of *contract*... but monopoly? Give me a break.
GPL software is proprietary, but not yet a monopoly in the marketplace. This is a chicken-and-egg problem -- traditional commercial proprietary software gets more paid developers working on the code because the promise of profits down the road spurs this sort of investment. GPL proprietary software (and other open-source software, including non-proprietary BSD software) tends to suffer from a relative lack of development resources, which makes it hard to keep up with the commercial proprietary software. We might hate to admit it, but there is a kernel of truth to Microsoft's "chasing the taillights" argument. (After all, the GNU project was created to reimplement Unix as an open system, not to create something new and innovative...)
In the short term, commercial proprietary software tends to have the advantage over GPL proprietary software, because of the resource advantages that come from having paid developers work full-time on the code instead of (mostly) volunteers working in their (often scarce) spare time. The "viral" aspect of the GPL (which makes it proprietary) thus serves as a means to level the playing field. This is reasonable, as long as GPL software remains the underdog.
However, GPL code never goes away. If a commercial product dies, it may never see the light of day again (it may even be destroyed), but GPL code will linger on forever, as long as even one user cares. And a dead GPL project can be resurrected at any time by anyone. This is a fundamental advantage that traditional commercial proprietary software can't match. Remember, slow but sure wins the race.
And what is the race, anyhow? It's not about money. It's about determining the path of the software industry. It's about monopoly. While GPL software may not monopolize the market today, it certainly could at some point in the future. Microsoft is racing toward the monopoly finish ling (rapidly), yet they can't crush GPL software because it never goes away. They can stall and slow the adoption and progress of GPL software and other open-source software in various ways, but it just keeps growing, inexorably.
If the GPL "wins", as it might, it will be a monopoly at that time. Since GPL code can be had for zero cost, it is (by definition) "dumping" on the market. While this is legal behavior for a non-monopolist, antitrust laws prohibit dumping by monopolists because it stifles competition. When Photoshop is "chasing the taillights" to catch up to the GIMP (instead of the other way around), how could Adobe afford to pay their developers to improve Photoshop, when the GIMP has a monopoly and is available free of charge? Obviou
No, but Usenet II does. Of course, I'm not sure if Usenet II is active or not. The web pages are old, but the idea seems sound. Does anyone know the status of Usenet II?
Well, it doesn't look like there are other software projects titled "Pheonix."
I had a software project under the name of "Phoenix" from April 21, 1994 until November 30, 2001. At that time, I renamed the project to "Gangplank" to coincide with the first open-source release of the source code. I never distributed the code under that name, but it's been running on a publicly-accessible Internet server since April 21, 1994. (I haven't actually upgraded that server to the Gangplank codebase yet, but I will.)
I didn't want to continue using the name "Phoenix" partly because it seemed overused, and people also seemed to have some difficulty spelling it correctly (as you did). Most importantly, I wasn't able to register a domain name to use for the website. After an exhaustive search of random dictionary words, I rather arbitrarily chose "Gangplank" as the new name, since I was able to register the gangplank.org domain name...
Well, if the date was simply wrong, and the story was brand-new, wouldn't you expect the story to show up as 24 hours and a couple minutes old? When I posted, it was showing around 22-23 hours old, so a simple error in dates doesn't seem likely.
Someone else suggested that a bug kept the story from appearing on the front page. This seems much more likely...
This is a cute April Fool's RFC (although I prefer the classic "TELNET Subliminal Message Option" or "IP Transmission Over Avian Carriers" RFCs), but did we really need to be told about this three times today?
This is why I hate Slashdot. I've never contracted for the US government, so I take your rather interesting comments on that as fact. I have no reason to doubt them, and they seem intelligent and observant. But then you start in on Perl and start pulling assertions out of your ass. And anyone who's reading this and doesn't know Perl well will likely just take your assertions as facts, due to how your earlier statements on government contracting seem authoritative, and you communicate your (mistaken) Perl oppinions as fact, as if "no one reasonable" can disagree with them. And your comment is rated a 5, so some pointy headed boss who's reading this flamewar because he's wondering what the difference between "scripting" and "coding" is is going to see "Perl is not an appropriate choice of language for production systems" and see your 5 rating and think it's a fact.
But it is a LIE.
I have to chime in here. I've been programming in C for 15 years, Perl for 13 years and C++ for 10 years. Consistently, I've found that Perl takes much less time and effort to program, because it encourages coding at a higher level of abstraction.
Note that I'm not talking about the rich CPAN library of modules you can leverage. (Java isn't the only language with a rich API library available.) I'm talking about new code, not slapping together API calls.
I remember an occasion (about 11 years ago) where I was wrestling with a 20-page COBOL program designed to export data from native COBOL files into flat ASCII text files to be imported into another system. This COBOL program was very slow and kept failing randomly. I could have spent weeks trying to fix this program, but I didn't. Instead, I spent an hour or two analyzing the data format. Before long, I understood the string format and the BCD-encoded number format used by that COBOL compiler, and determined the field layout in the binary data records. Armed with this knowledge, I wrote a Perl script to export the COBOL data into flat files.
The Perl script was literally around 8-10 lines of code -- the "unpack" line took the most effort, because all that data analysis went primarily into that one line of code. If I recall correctly, there was also a line or two that finished decoding numbers. There was a print statement to output the decoded records as flat ASCII data, and a read loop around the whole thing. It took VERY little code, and most of the effort was analyzing the data format. Writing and debugging the actual code took somewhere between 10-30 minutes beyond the time spent on data analysis.
This Perl script was bug-free when I finished -- it exported all data records correctly, and was even able to export the record(s) which caused the COBOL program to crash. Moreover, it converted the entire data file in 1-3 minutes, while the COBOL program took several hours to reach the point where it crashed about halfway through. (This was on 386 machines at the time.)
Now, some people would look at the Perl script, see that it's only a few lines of code in a "scripting" language and conclude that it's not "real programming". That's bullshit. Real programming is about problem solving, not the amount of effort expended. As a programmer, I'll choose the best tool for the job, instead of trying to make one tool (C, C++, Java, etc.) fit every job.
The same people who would disdain that Perl script would look at that 20-page COBOL program (i.e. >1000 lines of code) and say that was "real programming". It sure took someone a lot more time than I spent on the Perl script, and it looks like a more impressive piece of code to a manager, but both programs solved the same problem. To claim that one solution is more "real" than another is ludicrous.
Moreover, the Perl program solved the problem better -- it was literally about 1/100 of the size (in terms of lines of code), ran about 100-300 times faster on the same data, and it was more robust (the COBOL program crashed on certain records, the Perl script didn't). By any useful metric, the Perl code was easily 100 times better. (Ironic, given that the COBOL program was handling its native data formats, while Perl had to decode a foreign data format!) The COBOL program could be considered better for the programmer only in terms of politics. It's a lot of work (keeping busy is good for job security) and it's complex enough to impress the non-technical bosses that usually pay the bills, while the Perl code makes this programming stuff look easy by comparison.
The main reason my boss was impressed with this Perl script was that I had the COBOL program in hand as a baseline for comparison, so he could objectively see that my code was a fraction of the size, orders of magnitude faster, and that it didn't crash when the COBOL program did. Without that COBOL program for comparison (which someone else wrote), my Perl script probably would have looked rather utilitarian. (Which it was, actually!)
People often believe that I think Perl is the best solution for every problem. That's not actually true, but often time is of the essence, and when optimizing programmer time is a top priority (which is usually is these days), Perl often wins hands-down as the most effective tool. Why spend a few days or weeks writing something in Java or C++ when the same problem can be solved with Perl in a few minutes or hours? With Perl, I can be off to solving the next problem much sooner, which is important these days, when TODO lists always seem to grow faster than items can be checked off. C++ may be faster at runtime, but it takes longer to write the code, and often the added runtime performance isn't critical.
Perl is a real programming language, and an excellent general-purpose language for many tasks, especially backend processing. Good Perl code isn't cryptic or hard to maintain. If anything, it's easier to maintain because you don't lose sight of the forest for the trees. However, to maintain it you have to know Perl. If the existing developers don't have the Perl skills, isn't that what training is for?
I still have my Tunnels and Trolls rulebook and a number of the adventures, though I haven't played it in many years. My brother was an AD&D addict, but it always seemed to demand too much of a commitment. T&T was simpler and solo play was possible. Yes, it was a cheap ripoff of D&D, but it was still fun to play, and much less expensive!
Whatever happened to T&T? I'm assuming the company must have gone out of business many years ago now. Who inherited the copyrights?
Moral: spammers hoover slashdot, so don't post your email here, ever.
Screw that. I refuse to hide or obfuscate my email address. I've been using the Internet for 15 years. I remember the time when the Internet was mostly spam-free, and people rarely forged email addresses even though everyone knew how to.
My real email address is deven@ties.org -- this is my primary personal email address, not a spam-trap address. I know that the spammers are harvesting address from Slashdot and everywhere else. I don't care. Let them have the address. I've never hidden it, and I never will. I'm stubborn that way. (It's akin to refusing to change your lifestyle in response to terrorism, even when you know you're at risk...)
Of course, since I don't hide my email address, I get tons of spam, along with "Joe job" bounces/replies for spams forged in my name, plus more bounces copied to postmaster, since I receive postmaster mail for several domains. Bring it on! It just provides me with a larger corpus of bogus email to use for Bayesian filtering, or whatever other technique I may experiment with...
I firmly believe that a technical solution will be required to solve the spam problem. Legislation won't prevent the virtually-untraceable international spams, and may not even prevent local ones if it's not zealously enforced. Social controls haven't been effective. We need to prevent the spam from being delivered in the first place, or at least mark it as suspicious so legitimate mail doesn't drown in the noise so easily.
Beyond basic filtering like SpamAssassin and Bayesian filtering, there are other technical solutions worth exploring. Human validation techniques like TMDA might help. Finding a way to punish spammers and drive up their costs, such as E-Stamps or selling interrupt rights (original paper: HTML or PDF), might be effective. (But likely a higher barrier to legitimate mail.) Some sort of PGP-style Web of Trust might be very effective if done well, but it would be difficult to build. Perhaps some "soundness" principles could be borrowed from Usenet II to create a similar system for email...
Let's cross our fingers and hope to find a truly effective solution (or combination of solutions) in the near future!
Are you guilty of "destroying evidence"? Is your company? Is the furnace guy?
IANAL, but I believe intent probably matters here. If you're honestly trying your best to prevent the expected destruction of the evidence, and you fail to do so, I doubt you'd be held responsible for it. On the other hand, if the evidence is destroyed because you took a coffee break for 20 minutes after receiving the subpoena, and it was destroyed during that time, then you'd probably be in trouble. (You might even be in trouble if it wasn't possible to prevent the destruction -- not making the effort could be damning in itself.)
In the case of computer logs, if you know that the logs in question are about to be deleted by a cron job, you should take whatever steps are necessary to prevent that deletion from occurring. If you try and fail, maybe they'd still crucify you, but I rather doubt it. If you "try" but they can prove you had some passive-aggressive delays that were unnecessary, you might well be in trouble.
I don't think consulting a lawyer about the subpoena would be a defense either -- you should prevent the destruction of evidence first, then consult your lawyer about whether or not to turn over that evidence. If the delay from such a consultation results in the (foreseeable) destruction of evidence, you probably have no defense at all, if you could have prevented that destruction by acting in a timely fashion.
I think the key is knowledge of the subpoena -- if you have knowledge of it, you should act to preserve the evidence. If it is deleted through no fault of your own, and you could not have prevented that deletion after receiving the subpoena, then you're probably in the clear. In the Crematorium example, everyone would probably be in the clear. But suppose instead that the furnace guy knew of the subpoena? Then you may be in the clear for trying to preserve the evidence but the furnace guy may be in trouble for not answering the phone, hiding on a break, etc.
I believe it comes down to knowledge (of the subpoena), intent (to destroy evidence or not prevent its destruction) and ability (if it's possible to prevent the destruction). It would turn on the specific facts of the situation.
But again, I'm not a lawyer, so this certainly isn't legal advice!
By the way, although it took some effort for me to calculate 9^9, calculating 8^8 is a snap for me. That's 16777216. Since I work with computers, I've had lots of practice with powers of two. I've memorized all the powers of two cold through 2^23 (8388608), and 8^8 is 2^24 (i.e. (2^3)^8), so doubling that number took little effort. Since I'm more certain of the values of each power of two than which power of two each is, I started from a point I know for sure (2^20 = 1048576) and doubled it 4 more times (2097152, 4194304, 8388606, 16777216). Only that last one required double-checking; I know the others by rote.
Why do I know the powers of two so well? Practice. Lots and lots of practice. You run into them all the time with computers, but beyond that, I've been doubling numbers in my head since I was a child, just as mental exercise. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288, 1048576, 2097152, 4194304, 8388608 -- I've memorized all of these, and 16777216 is starting to become familiar. 33554432 isn't familiar yet, but it's a nice simple pattern. 67108864 will be a little harder, but all it takes is practice!
I used to only know through 2^16 (65536) well, but I've taken to doubling numbers in my head if I'm having trouble falling asleep -- I'll mentally recite as many as I know by rote, then start calculating additional ones in my head, until I fall asleep. Other times, I'll do it in the middle of the day as a mental exercise. One of these days, I'll have the powers through 2^32 down cold, then I guess I'll have to start working towards 2^64!
Granted, there comes a point where memorizing numbers is of questionable value. For example, in 10th grade (18 years ago), I memorized over 100 digits of Pi from a poster on the wall, over the course of a year. I can still recite about 50 digits effortlessly after more than 17 years. This is useless for any calculations I might do, although I've used it as a password. Slightly modified, of course.:-)
My rote memorization of powers of 2 is quite useful, but my knowledge of Pi mostly isn't. Perhaps I should work on memorizing some powers of 3 through 9, on general principle... (Or at least the first few prime numbers!)
Most people are not good at doing both(look at how many people fail math) however, also we have enough human calculators, the number crunching followers do not innovate, its the creative ones who understand how things work who make all the innovation. What good are you if you can do well on jepordy? you dont help society at all.
Conceptual understanding and number-crunching skills are not mutually exclusive. If anything, they're mutually-reinforcing. Encouraging children to rely on using calculators as a crutch will severely limit their mathematical abilities. Calculators can be useful to check an answer, but if you can't do a problem with pencil and paper, you're in trouble.
I think the main reason so many people have trouble with math is that they never really had a solid understanding of the basics. Often this is the fault of the teacher, who may rely too heavily on rote memorization (never revealing concepts like "multiplication is repeated addition") or simply fail to teach some (or all) of their students effectively, often ignoring them (say, because "girls can't do math").
Unfortunately, if your grasp of basic math isn't solid, you'll really struggle with higher math, because it builds so heavily on basic math. Many people seem to struggle with math for many years because of one bad math teacher in their past, who failed to teach them properly. From that point on, it's usually nearly impossible to recover, because the pace of the new material assumes a solid understanding of the previous material, and without that understanding, math becomes a constant struggle.
Consider how many people loathe "word problems". Because there is no rote procedure to translate a word problem into a math formula, any student who depends on rote mechanisms for formula solving may end up guessing as to that initial formula for the word problem. Students with a solid understanding of the concepts involved usually find it quite straightforward to translate the word problem into a formula. Those who are already struggling, and probably have only learned rote skills with no comprehension of what they're doing or why, tend to be downright terrified of word problems, because they know that getting the initial formula wrong will ruin the solution, yet it can look fine to them when they turn it in!
The irony is that "word problems" are exactly how we teach young children basic math in the first place! Such problems help to connect abstract math to the real world, and makes it easier to understand. If anything, math students should do more word problems, and not move on to more advanced concepts until such problems become second nature to the students. Of course, this would take more time (and the problems are harder to construct), but students would actually learn math better, and it would give them a more solid foundation for higher math work.
The reason to teach them the formulas without teaching them the numbers is it teaches them what really matters. The formula is simple.
Simple? Maybe for 3^3. Now try the formula for 9^9 and tell me if that still seems "simple" to solve as repeated addition. Conceptually, it may be straightforward, but in practice, it's useless. Moreover, if you only understand multiplication as repeated addition and cannot multiply directly, it's much harder to understand why 9^9 = (9^4) * (9^4) * 9, and in turn, 9^4 = (9^2) * (9^2).
On paper, I just calculated 9^2 (= 9*9 = 81), then 9^4 (= 9^2 * 9^2 = 81 * 81 = 6561), then 9^8 (= 9^4 * 9^4 = 6561 * 6561 = 43046721), and finally 9^9 (= 9^8 * 9 = 43046721 * 9 = 387420489). Have fun trying to calculate that number by adding 9 to itself 43,046,721 times to get the answer your way. I hope you have a lot of time to waste.
Unfortunately, my number-crunching skills are not what they once were. I could only get to 9^4 in my head, and even on paper I only got to 9^8 without error. In the last step, multiplying 7 * 9, I accidently came up with 56 (7 * 8) instead of 63. So I got the wrong answer, 387419789 -- which was obvious when I checked my answer with a calculator. This is why memorizing multiplication tables by rote is important -- without knowing the right answer for a simple multiplication, I could have resorted to repeated adding, but that would have been much more prone to error.
It's been 15 years since I graduated high school, and I haven't kept in practice since then. Back in high school, my brother and I were both on the Math Team (geeks!) and our team often clobbered the competition. Everyone competing was good at math, and calculators were forbidden. How did we get to be so good? Practice. Yes, we had a solid understanding of the concepts, as we needed to. But it also took lots of practice.
Believe it or not, if you do the same type of problem often enough, it really does become second nature, and you can solve it almost effortlessly. Yes, the Math Team took this to levels far beyond what ordinary math students would, but the principle is the same. Go ahead and try to multiply a couple 8-digit numbers by using repeated addition in place of every multiplication and you'll be pulling your hair out. And you'll almost certainly get the wrong answer. It's important to learn the multiplication tables well, so that the trivial multiplications become second nature and the harder ones become manageable.
If you can't even calculate 30% of 70 in your head, that's pathetic. 10% of 70 is 7 (shift the decimal), 7 times 3 is 21. I don't care if numbers aren't your thing, this is a basic skill. There's a reason why "'rithmetic" is one of the "three R's" of traditional education, after all. If you allow yourself to rely on calculators too much, you'll find yourself crippled without them. And while there may not be a lot of need for calculus in everyday life, there's a lot of use for basic math, and even a little algebra.
Despite the availability of calculators, everyone should learn basic math skills. To neglect such basic skills is foolish.
RPI's rich history of CMC ("chat" or "IM") systems
on
AOL Patents IM
·
· Score: 2
AOL definitely predates 1993. I knew AOL users in 1988. Try again.
As I recall, IRC was available as early as 1987-1988. It was definitely around in early 1990, so it certainly predates the patent.
Also, there are older CMC systems (Computer Mediated Communication systems) invented by members of the student ACM chapter at Rensselaer Polytechnic Institute (RPI). (Not all of these CMC systems were Internet-based.)
In particular, CONNECT was a network server (but not Internet-based) which allowed users to connect to the server over the network and login, see what other people are signed on, and send public and/or private messages to other online users. CONNECT dates back to the spring of 1986, and replaced ACM:CB, a program which students previously used to chat -- but that program only worked between users logged into the MTS mainframe system; CONNECT was a true network server. (It, in turn, took the place of "vamp-mode" on *FORUM -- that is, people used to use the MTS forum software for interactive conversations, although it wasn't designed for that purpose. ACM:CB was, and CONNECT even moreso.)
After CONNECT was shutdown in 1991 for political reasons, another program called Clover took its place. Clover was an Internet-based server running on a Unix machine, licensed under the GPL. It had a client-server architecture and used a UDP-based protocol. Clover ran for several years until about 1994, when it was replaced by lily, a MOO-based server using a TCP-based protocol and new client software. Lily remains active today and is the current home of the online community which formed on the MTS mainframe in the mid-1980s.
I myself wrote a Unix-based server imitating CONNECT. This server was started in 1992, running on a server open to public access (via guest access) since early 1993, and eventually released last year. This server uses the standard TELNET protocol to avoid the need for a custom client.
By and large, customers only figure this stuff out after the fact. They learn that the online store they trusted with their credit card number had lax security, and a thief now has their credit card number, along with thousands of others. Does the customer shop at that online store again? Probably not. Do others who've never shopped there avoid it? Probably. Is the business damaged by such an incident? Obviously -- it scares away existing and potential customers!
Smarter corporations may learn this lesson the easy way, by observing the damage to other businesses from security incidents. Those companies may manage to avoid an embarassing incident. Dumb or callous corporations will learn the hard way -- by having their own business damaged by a security incident, sooner or later.
Security is a cost center. Companies don't like to spend money on things that don't make money. Nevertheless, the potential cost of a lapse in security can far outweigh the cost of providing security. Thus, it makes good business sense to be concerned about security. (At least for those few corporations smart enough to be concerned with long-term viability of the business, and not only short-term profitability...)
Although corporate databases CAN be made to hinder or thwart gathering personal information, WHY would said corporations bother to implement this?
To reduce liability and to avoid adverse publicity, in the event the database is compromised. Sensitive databases have been compromised before, and will be again. The potential damage is limited if the data is encrypted in the database. Corporations don't care about our privacy, but they certainly do care about liability and adverse publicity! (A PR campaign doesn't provide those benefits, only the illusion of them...)
Think about it. That 300 KHz computer may still be running after 50 years, but those 50 years of CPU time add up to about 43 hours of CPU time on a 3.06 GHz Pentium 4. And that's just clock cycles; the Pentium 4 probably gets far more instructions per clock cycle. And, of course, the on-chip cache on the Pentium 4 far exceeds the 2 KB of RAM on that 50-year-old machine.
All in all, today's fastest Pentium could easily exceed the lifetime processing power of the CSIRAC in just a few hours, at a tiny fraction of the cost. Sure, it's cool that the computer still runs after 50 years, but let's put it into perspective here -- we get far more computing power out of modern chips, even if they fail within a couple years! Longevity isn't everything...
I can't remember a single case of two Spanish words sounding identical. The closest I can recall is the words for "yes" and "if". Of course "yes" in Spanish is "si", pronounced like "see"; as in "Si, senor." But "if" in Spanish is also spelled "si", but with an accent mark over the 'i', so the way it is pronounced in a sentence is different.
You've got it backwards. "Sí" (with the accent) is "yes", while "si" (without the accent) is "if". Thy're also pronounced slightly differently; "sí" is a stressed syllable because of the accent (that's what the accent means) while "si" is unstressed. (By default, the next-to-last syllable in a Spanish word is stressed, unless an accent mark denotes a different syllable to stress.)
But yes, they're pretty similar and potentially confusing, but usually pretty clear from context even if you can't catch the pronunciation. (This is about all I still remember from several years of studying Spanish!:-)
While I'm being pedantic, you also spelled "señor" incorrectly; "n" and "ñ" are considered different letters. For that matter, "ll" is considered a single letter as well, distinct from the letter "l"...
You can bet the former Bell Atlantic customers do think of Verizon as a descendent of the Bell monopoly. (And I believe Bell Atlantic was larger than GTE, but I'm not certain.)
While it's true that soda has a high elasticity (and hense viability for high profit margins), [...]
Okay, it's been a long time since I took an economics class, but I believe you've got this backwards. (But don't take my word for it, I could be misremembering!)
As I recall, soda would be characterized as relatively inelastic because the demand doesn't vary much when the price changes. If they sell that soda for $0.25 instead of $1.25, you're not going to buy 5 times as much. (Maybe you'll buy twice as much.)
My understanding from my economics class was that the inelastic products offered the highest potential profit margins, because the more inelastic the demand, the more room there is to raise prices with relative impunity. If the demand is relatively constant, why not set the prices as high as possible?
Any economics experts out there want to confirm which usage of the terminology is correct?
Too bad Wal-Mart doesn't have a PC or two in their stores that could access their website.
That's a good idea, if they're going to have products that are available only online. Better yet, they could even accept cash payments at the register for an online order, for those without credit cards. They could either have a kiosk or simply a computer at the customer service counter where the CSR could place the order.
Why don't you write to their corporate offices and suggest it? Maybe they'll recognize a good idea when they see it...
Slashdot Mirror
You could say exactly the same about any purchase. The reality is, spending money is not a cost to the economy - it's exactly the transaction the economy is built from.
True enough. My point was that you're talking about real money, rather than the hypothetical money that the RIAA claims to be losing.
It doesn't bar real competition. [...] Patents bar clones - you can't just go and write your own RealPlayer, assuming they've patented that, but you can go and write your own video player, just as Apple and Microsoft did.
Clones are the real competition. If you need to play RealPlayer content, a video player from Apple or Microsoft doesn't do you any good when it can't play that content. You're locked into using RealPlayer. Since Real has a monopoly in this market, they can charge any price, no matter how exorbitant. And as the consumer, you can't go to a competitor offering a better price -- the competitor's product (while similar) doesn't meet your needs. You're stuck with the monopolist.
Economists call this "inefficient", while fair markets are called "efficient". Prices in an efficient market tend toward the marginal cost. Of course, this tends towards minimal profit, since a "perfectly efficient" market would set the price equal to the marginal cost, which would mean zero profit. That doesn't tend to happen, since there's no incentive to stay in a market without any profit, but highly competitive markets for commodity goods do tend to operate on razor-thin profit margins...
The money still gets spent, just in a different place. No net gain, you're just taking money from Thompson and giving it to another company instead. What about when Thompson spends the money they get in license fees? What about the development it would otherwise have funded - where do you think MP3Pro came from?
Yes, the monopolist will spend their money too. That doesn't mean it's a wash for society. Monopoly rents extract substantial costs from society at large (in various ways) for the benefit of the monopolist. When the monopolist spends that money, the value to society and the economy doesn't match the costs that were extracted. This is exactly why economists call it "inefficient" and are very wary of monopolists...
Ah, the RIAA argument: it's "costing" billions, because you think billions might otherwise be made. Nice try. It's creating money for the owners. Perhaps some other system would make them more money, perhaps not - but you cannot claim it is "costing" the economy anything.
The money the owners get isn't created out of thin air. It's paid by those who license the patent. That's money they can't spend on other things -- it's quite legitimate to say that the license fees on a patent are a real cost to the economy. More importantly, the patent bars competition, which lowers prices -- another cost to the economy. Talk to any economist. They'll tell you that the impact of "monopoly rents" on the economy is real, not imaginary.
The RIAA argument is different -- they assume (like the BSA does) that everyone who "pirates" their products would have otherwise purchased those unauthorized copies at full retail price. This conveniently ignores the fact that most casual "piracy" occurs because it's low-cost, low-risk, and doesn't harm anyone else, and most of that material would not be purchased at full price otherwise.
On the other hand, if nobody has to pay monopoly rents to license a patent, that's real money they don't have to spend, and they'll certainly find another way to spend it. So the costs involved in patents are real, unlike RIAA's imaginary "losses". (Patent licensing fees lost because people refuse to pay for a license, yet use the patented code, would be more analogous.)
Interesting... this seems to be saying that, through the use of the GPL, the FSF is, perhaps unwittingly, attempting to create a monopoly.
Unwittingly? The FSF's goal has always been to dominate all software with GPL software, and to render proprietary software irrelevant (ideally, to extinguish it entirely) -- this agenda has never really been secret.
What, then, is the FSF's dirty little secret? GPL software is also proprietary software. Try as they might to clothe their arguments in "freedom", the truth of the matter is that the proprietary benefits of the GPL are only available to those who are willing to accept the GPL's mandate and place their related code under the GPL.
Admission to this group is open and "free", except of course for the cost of writing all the code which can only be given away. (Yes, I know you can sell GPL code, but your first customer can give it away free to any other potential customers, so good luck recouping development costs from GPL sales!)
It's still the user's choice whether or not to *use* the software. Simply because they can't take GPL'd software and package it without the source and sell it doesn't mean that the software is part of a monopoly... geez! The GPL certainly is another form of *contract*... but monopoly? Give me a break.
GPL software is proprietary, but not yet a monopoly in the marketplace. This is a chicken-and-egg problem -- traditional commercial proprietary software gets more paid developers working on the code because the promise of profits down the road spurs this sort of investment. GPL proprietary software (and other open-source software, including non-proprietary BSD software) tends to suffer from a relative lack of development resources, which makes it hard to keep up with the commercial proprietary software. We might hate to admit it, but there is a kernel of truth to Microsoft's "chasing the taillights" argument. (After all, the GNU project was created to reimplement Unix as an open system, not to create something new and innovative...)
In the short term, commercial proprietary software tends to have the advantage over GPL proprietary software, because of the resource advantages that come from having paid developers work full-time on the code instead of (mostly) volunteers working in their (often scarce) spare time. The "viral" aspect of the GPL (which makes it proprietary) thus serves as a means to level the playing field. This is reasonable, as long as GPL software remains the underdog.
However, GPL code never goes away. If a commercial product dies, it may never see the light of day again (it may even be destroyed), but GPL code will linger on forever, as long as even one user cares. And a dead GPL project can be resurrected at any time by anyone. This is a fundamental advantage that traditional commercial proprietary software can't match. Remember, slow but sure wins the race.
And what is the race, anyhow? It's not about money. It's about determining the path of the software industry. It's about monopoly. While GPL software may not monopolize the market today, it certainly could at some point in the future. Microsoft is racing toward the monopoly finish ling (rapidly), yet they can't crush GPL software because it never goes away. They can stall and slow the adoption and progress of GPL software and other open-source software in various ways, but it just keeps growing, inexorably.
If the GPL "wins", as it might, it will be a monopoly at that time. Since GPL code can be had for zero cost, it is (by definition) "dumping" on the market. While this is legal behavior for a non-monopolist, antitrust laws prohibit dumping by monopolists because it stifles competition. When Photoshop is "chasing the taillights" to catch up to the GIMP (instead of the other way around), how could Adobe afford to pay their developers to improve Photoshop, when the GIMP has a monopoly and is available free of charge? Obviou
I already have Video on Demand. It's called TiVo...
Usenet, unfortunately, has no ejection mechanism.
No, but Usenet II does. Of course, I'm not sure if Usenet II is active or not. The web pages are old, but the idea seems sound. Does anyone know the status of Usenet II?
Well, it doesn't look like there are other software projects titled "Pheonix."
I had a software project under the name of "Phoenix" from April 21, 1994 until November 30, 2001. At that time, I renamed the project to "Gangplank" to coincide with the first open-source release of the source code. I never distributed the code under that name, but it's been running on a publicly-accessible Internet server since April 21, 1994. (I haven't actually upgraded that server to the Gangplank codebase yet, but I will.)
I didn't want to continue using the name "Phoenix" partly because it seemed overused, and people also seemed to have some difficulty spelling it correctly (as you did). Most importantly, I wasn't able to register a domain name to use for the website. After an exhaustive search of random dictionary words, I rather arbitrarily chose "Gangplank" as the new name, since I was able to register the gangplank.org domain name...
The date's wrong. OF COURSE.
Well, if the date was simply wrong, and the story was brand-new, wouldn't you expect the story to show up as 24 hours and a couple minutes old? When I posted, it was showing around 22-23 hours old, so a simple error in dates doesn't seem likely.
Someone else suggested that a bug kept the story from appearing on the front page. This seems much more likely...
This is a cute April Fool's RFC (although I prefer the classic "TELNET Subliminal Message Option" or "IP Transmission Over Avian Carriers" RFCs), but did we really need to be told about this three times today?
How is it that any story on Slashdot can survive without any comments at all for nearly 24 hours? Is the system broken? This is unusual!
This is why I hate Slashdot. I've never contracted for the US government, so I take your rather interesting comments on that as fact. I have no reason to doubt them, and they seem intelligent and observant. But then you start in on Perl and start pulling assertions out of your ass. And anyone who's reading this and doesn't know Perl well will likely just take your assertions as facts, due to how your earlier statements on government contracting seem authoritative, and you communicate your (mistaken) Perl oppinions as fact, as if "no one reasonable" can disagree with them. And your comment is rated a 5, so some pointy headed boss who's reading this flamewar because he's wondering what the difference between "scripting" and "coding" is is going to see "Perl is not an appropriate choice of language for production systems" and see your 5 rating and think it's a fact.
But it is a LIE.
I have to chime in here. I've been programming in C for 15 years, Perl for 13 years and C++ for 10 years. Consistently, I've found that Perl takes much less time and effort to program, because it encourages coding at a higher level of abstraction.
Note that I'm not talking about the rich CPAN library of modules you can leverage. (Java isn't the only language with a rich API library available.) I'm talking about new code, not slapping together API calls.
I remember an occasion (about 11 years ago) where I was wrestling with a 20-page COBOL program designed to export data from native COBOL files into flat ASCII text files to be imported into another system. This COBOL program was very slow and kept failing randomly. I could have spent weeks trying to fix this program, but I didn't. Instead, I spent an hour or two analyzing the data format. Before long, I understood the string format and the BCD-encoded number format used by that COBOL compiler, and determined the field layout in the binary data records. Armed with this knowledge, I wrote a Perl script to export the COBOL data into flat files.
The Perl script was literally around 8-10 lines of code -- the "unpack" line took the most effort, because all that data analysis went primarily into that one line of code. If I recall correctly, there was also a line or two that finished decoding numbers. There was a print statement to output the decoded records as flat ASCII data, and a read loop around the whole thing. It took VERY little code, and most of the effort was analyzing the data format. Writing and debugging the actual code took somewhere between 10-30 minutes beyond the time spent on data analysis.
This Perl script was bug-free when I finished -- it exported all data records correctly, and was even able to export the record(s) which caused the COBOL program to crash. Moreover, it converted the entire data file in 1-3 minutes, while the COBOL program took several hours to reach the point where it crashed about halfway through. (This was on 386 machines at the time.)
Now, some people would look at the Perl script, see that it's only a few lines of code in a "scripting" language and conclude that it's not "real programming". That's bullshit. Real programming is about problem solving, not the amount of effort expended. As a programmer, I'll choose the best tool for the job, instead of trying to make one tool (C, C++, Java, etc.) fit every job.
The same people who would disdain that Perl script would look at that 20-page COBOL program (i.e. >1000 lines of code) and say that was "real programming". It sure took someone a lot more time than I spent on the Perl script, and it looks like a more impressive piece of code to a manager, but both programs solved the same problem. To claim that one solution is more "real" than another is ludicrous.
Moreover, the Perl program solved the problem better -- it was literally about 1/100 of the size (in terms of lines of code), ran about 100-300 times faster on the same data, and it was more robust (the COBOL program crashed on certain records, the Perl script didn't). By any useful metric, the Perl code was easily 100 times better. (Ironic, given that the COBOL program was handling its native data formats, while Perl had to decode a foreign data format!) The COBOL program could be considered better for the programmer only in terms of politics. It's a lot of work (keeping busy is good for job security) and it's complex enough to impress the non-technical bosses that usually pay the bills, while the Perl code makes this programming stuff look easy by comparison.
The main reason my boss was impressed with this Perl script was that I had the COBOL program in hand as a baseline for comparison, so he could objectively see that my code was a fraction of the size, orders of magnitude faster, and that it didn't crash when the COBOL program did. Without that COBOL program for comparison (which someone else wrote), my Perl script probably would have looked rather utilitarian. (Which it was, actually!)
People often believe that I think Perl is the best solution for every problem. That's not actually true, but often time is of the essence, and when optimizing programmer time is a top priority (which is usually is these days), Perl often wins hands-down as the most effective tool. Why spend a few days or weeks writing something in Java or C++ when the same problem can be solved with Perl in a few minutes or hours? With Perl, I can be off to solving the next problem much sooner, which is important these days, when TODO lists always seem to grow faster than items can be checked off. C++ may be faster at runtime, but it takes longer to write the code, and often the added runtime performance isn't critical.
Perl is a real programming language, and an excellent general-purpose language for many tasks, especially backend processing. Good Perl code isn't cryptic or hard to maintain. If anything, it's easier to maintain because you don't lose sight of the forest for the trees. However, to maintain it you have to know Perl. If the existing developers don't have the Perl skills, isn't that what training is for?
I still have my Tunnels and Trolls rulebook and a number of the adventures, though I haven't played it in many years. My brother was an AD&D addict, but it always seemed to demand too much of a commitment. T&T was simpler and solo play was possible. Yes, it was a cheap ripoff of D&D, but it was still fun to play, and much less expensive!
Whatever happened to T&T? I'm assuming the company must have gone out of business many years ago now. Who inherited the copyrights?
Moral: spammers hoover slashdot, so don't post your email here, ever.
Screw that. I refuse to hide or obfuscate my email address. I've been using the Internet for 15 years. I remember the time when the Internet was mostly spam-free, and people rarely forged email addresses even though everyone knew how to.
My real email address is deven@ties.org -- this is my primary personal email address, not a spam-trap address. I know that the spammers are harvesting address from Slashdot and everywhere else. I don't care. Let them have the address. I've never hidden it, and I never will. I'm stubborn that way. (It's akin to refusing to change your lifestyle in response to terrorism, even when you know you're at risk...)
Of course, since I don't hide my email address, I get tons of spam, along with "Joe job" bounces/replies for spams forged in my name, plus more bounces copied to postmaster, since I receive postmaster mail for several domains. Bring it on! It just provides me with a larger corpus of bogus email to use for Bayesian filtering, or whatever other technique I may experiment with...
I firmly believe that a technical solution will be required to solve the spam problem. Legislation won't prevent the virtually-untraceable international spams, and may not even prevent local ones if it's not zealously enforced. Social controls haven't been effective. We need to prevent the spam from being delivered in the first place, or at least mark it as suspicious so legitimate mail doesn't drown in the noise so easily.
Beyond basic filtering like SpamAssassin and Bayesian filtering, there are other technical solutions worth exploring. Human validation techniques like TMDA might help. Finding a way to punish spammers and drive up their costs, such as E-Stamps or selling interrupt rights (original paper: HTML or PDF), might be effective. (But likely a higher barrier to legitimate mail.) Some sort of PGP-style Web of Trust might be very effective if done well, but it would be difficult to build. Perhaps some "soundness" principles could be borrowed from Usenet II to create a similar system for email...
Let's cross our fingers and hope to find a truly effective solution (or combination of solutions) in the near future!
Are you guilty of "destroying evidence"? Is your company? Is the furnace guy?
IANAL, but I believe intent probably matters here. If you're honestly trying your best to prevent the expected destruction of the evidence, and you fail to do so, I doubt you'd be held responsible for it. On the other hand, if the evidence is destroyed because you took a coffee break for 20 minutes after receiving the subpoena, and it was destroyed during that time, then you'd probably be in trouble. (You might even be in trouble if it wasn't possible to prevent the destruction -- not making the effort could be damning in itself.)
In the case of computer logs, if you know that the logs in question are about to be deleted by a cron job, you should take whatever steps are necessary to prevent that deletion from occurring. If you try and fail, maybe they'd still crucify you, but I rather doubt it. If you "try" but they can prove you had some passive-aggressive delays that were unnecessary, you might well be in trouble.
I don't think consulting a lawyer about the subpoena would be a defense either -- you should prevent the destruction of evidence first, then consult your lawyer about whether or not to turn over that evidence. If the delay from such a consultation results in the (foreseeable) destruction of evidence, you probably have no defense at all, if you could have prevented that destruction by acting in a timely fashion.
I think the key is knowledge of the subpoena -- if you have knowledge of it, you should act to preserve the evidence. If it is deleted through no fault of your own, and you could not have prevented that deletion after receiving the subpoena, then you're probably in the clear. In the Crematorium example, everyone would probably be in the clear. But suppose instead that the furnace guy knew of the subpoena? Then you may be in the clear for trying to preserve the evidence but the furnace guy may be in trouble for not answering the phone, hiding on a break, etc.
I believe it comes down to knowledge (of the subpoena), intent (to destroy evidence or not prevent its destruction) and ability (if it's possible to prevent the destruction). It would turn on the specific facts of the situation.
But again, I'm not a lawyer, so this certainly isn't legal advice!
By the way, although it took some effort for me to calculate 9^9, calculating 8^8 is a snap for me. That's 16777216. Since I work with computers, I've had lots of practice with powers of two. I've memorized all the powers of two cold through 2^23 (8388608), and 8^8 is 2^24 (i.e. (2^3)^8), so doubling that number took little effort. Since I'm more certain of the values of each power of two than which power of two each is, I started from a point I know for sure (2^20 = 1048576) and doubled it 4 more times (2097152, 4194304, 8388606, 16777216). Only that last one required double-checking; I know the others by rote.
:-)
3 75 ...
Why do I know the powers of two so well? Practice. Lots and lots of practice. You run into them all the time with computers, but beyond that, I've been doubling numbers in my head since I was a child, just as mental exercise. 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288, 1048576, 2097152, 4194304, 8388608 -- I've memorized all of these, and 16777216 is starting to become familiar. 33554432 isn't familiar yet, but it's a nice simple pattern. 67108864 will be a little harder, but all it takes is practice!
I used to only know through 2^16 (65536) well, but I've taken to doubling numbers in my head if I'm having trouble falling asleep -- I'll mentally recite as many as I know by rote, then start calculating additional ones in my head, until I fall asleep. Other times, I'll do it in the middle of the day as a mental exercise. One of these days, I'll have the powers through 2^32 down cold, then I guess I'll have to start working towards 2^64!
Granted, there comes a point where memorizing numbers is of questionable value. For example, in 10th grade (18 years ago), I memorized over 100 digits of Pi from a poster on the wall, over the course of a year. I can still recite about 50 digits effortlessly after more than 17 years. This is useless for any calculations I might do, although I've used it as a password. Slightly modified, of course.
3.141592653589793238462643383279502884197169399
My rote memorization of powers of 2 is quite useful, but my knowledge of Pi mostly isn't. Perhaps I should work on memorizing some powers of 3 through 9, on general principle... (Or at least the first few prime numbers!)
Most people are not good at doing both(look at how many people fail math) however, also we have enough human calculators, the number crunching followers do not innovate, its the creative ones who understand how things work who make all the innovation. What good are you if you can do well on jepordy? you dont help society at all.
Conceptual understanding and number-crunching skills are not mutually exclusive. If anything, they're mutually-reinforcing. Encouraging children to rely on using calculators as a crutch will severely limit their mathematical abilities. Calculators can be useful to check an answer, but if you can't do a problem with pencil and paper, you're in trouble.
I think the main reason so many people have trouble with math is that they never really had a solid understanding of the basics. Often this is the fault of the teacher, who may rely too heavily on rote memorization (never revealing concepts like "multiplication is repeated addition") or simply fail to teach some (or all) of their students effectively, often ignoring them (say, because "girls can't do math").
Unfortunately, if your grasp of basic math isn't solid, you'll really struggle with higher math, because it builds so heavily on basic math. Many people seem to struggle with math for many years because of one bad math teacher in their past, who failed to teach them properly. From that point on, it's usually nearly impossible to recover, because the pace of the new material assumes a solid understanding of the previous material, and without that understanding, math becomes a constant struggle.
Consider how many people loathe "word problems". Because there is no rote procedure to translate a word problem into a math formula, any student who depends on rote mechanisms for formula solving may end up guessing as to that initial formula for the word problem. Students with a solid understanding of the concepts involved usually find it quite straightforward to translate the word problem into a formula. Those who are already struggling, and probably have only learned rote skills with no comprehension of what they're doing or why, tend to be downright terrified of word problems, because they know that getting the initial formula wrong will ruin the solution, yet it can look fine to them when they turn it in!
The irony is that "word problems" are exactly how we teach young children basic math in the first place! Such problems help to connect abstract math to the real world, and makes it easier to understand. If anything, math students should do more word problems, and not move on to more advanced concepts until such problems become second nature to the students. Of course, this would take more time (and the problems are harder to construct), but students would actually learn math better, and it would give them a more solid foundation for higher math work.
3+3+3 = A+A+A
(A+A+A + A+A+A + A+A+A) + (A+A+A + A+A+A + A+A+A) + (A+A+A + A+A+A + A+A+A) = A^3
The reason to teach them the formulas without teaching them the numbers is it teaches them what really matters.
The formula is simple.
Simple? Maybe for 3^3. Now try the formula for 9^9 and tell me if that still seems "simple" to solve as repeated addition. Conceptually, it may be straightforward, but in practice, it's useless. Moreover, if you only understand multiplication as repeated addition and cannot multiply directly, it's much harder to understand why 9^9 = (9^4) * (9^4) * 9, and in turn, 9^4 = (9^2) * (9^2).
On paper, I just calculated 9^2 (= 9*9 = 81), then 9^4 (= 9^2 * 9^2 = 81 * 81 = 6561), then 9^8 (= 9^4 * 9^4 = 6561 * 6561 = 43046721), and finally 9^9 (= 9^8 * 9 = 43046721 * 9 = 387420489). Have fun trying to calculate that number by adding 9 to itself 43,046,721 times to get the answer your way. I hope you have a lot of time to waste.
Unfortunately, my number-crunching skills are not what they once were. I could only get to 9^4 in my head, and even on paper I only got to 9^8 without error. In the last step, multiplying 7 * 9, I accidently came up with 56 (7 * 8) instead of 63. So I got the wrong answer, 387419789 -- which was obvious when I checked my answer with a calculator. This is why memorizing multiplication tables by rote is important -- without knowing the right answer for a simple multiplication, I could have resorted to repeated adding, but that would have been much more prone to error.
It's been 15 years since I graduated high school, and I haven't kept in practice since then. Back in high school, my brother and I were both on the Math Team (geeks!) and our team often clobbered the competition. Everyone competing was good at math, and calculators were forbidden. How did we get to be so good? Practice. Yes, we had a solid understanding of the concepts, as we needed to. But it also took lots of practice.
Believe it or not, if you do the same type of problem often enough, it really does become second nature, and you can solve it almost effortlessly. Yes, the Math Team took this to levels far beyond what ordinary math students would, but the principle is the same. Go ahead and try to multiply a couple 8-digit numbers by using repeated addition in place of every multiplication and you'll be pulling your hair out. And you'll almost certainly get the wrong answer. It's important to learn the multiplication tables well, so that the trivial multiplications become second nature and the harder ones become manageable.
If you can't even calculate 30% of 70 in your head, that's pathetic. 10% of 70 is 7 (shift the decimal), 7 times 3 is 21. I don't care if numbers aren't your thing, this is a basic skill. There's a reason why "'rithmetic" is one of the "three R's" of traditional education, after all. If you allow yourself to rely on calculators too much, you'll find yourself crippled without them. And while there may not be a lot of need for calculus in everyday life, there's a lot of use for basic math, and even a little algebra.
Despite the availability of calculators, everyone should learn basic math skills. To neglect such basic skills is foolish.
AOL definitely predates 1993. I knew AOL users in 1988. Try again.
As I recall, IRC was available as early as 1987-1988. It was definitely around in early 1990, so it certainly predates the patent.
Also, there are older CMC systems (Computer Mediated Communication systems) invented by members of the student ACM chapter at Rensselaer Polytechnic Institute (RPI). (Not all of these CMC systems were Internet-based.)
In particular, CONNECT was a network server (but not Internet-based) which allowed users to connect to the server over the network and login, see what other people are signed on, and send public and/or private messages to other online users. CONNECT dates back to the spring of 1986, and replaced ACM:CB, a program which students previously used to chat -- but that program only worked between users logged into the MTS mainframe system; CONNECT was a true network server. (It, in turn, took the place of "vamp-mode" on *FORUM -- that is, people used to use the MTS forum software for interactive conversations, although it wasn't designed for that purpose. ACM:CB was, and CONNECT even moreso.)
After CONNECT was shutdown in 1991 for political reasons, another program called Clover took its place. Clover was an Internet-based server running on a Unix machine, licensed under the GPL. It had a client-server architecture and used a UDP-based protocol. Clover ran for several years until about 1994, when it was replaced by lily, a MOO-based server using a TCP-based protocol and new client software. Lily remains active today and is the current home of the online community which formed on the MTS mainframe in the mid-1980s.
I myself wrote a Unix-based server imitating CONNECT. This server was started in 1992, running on a server open to public access (via guest access) since early 1993, and eventually released last year. This server uses the standard TELNET protocol to avoid the need for a custom client.
By and large, customers only figure this stuff out after the fact. They learn that the online store they trusted with their credit card number had lax security, and a thief now has their credit card number, along with thousands of others. Does the customer shop at that online store again? Probably not. Do others who've never shopped there avoid it? Probably. Is the business damaged by such an incident? Obviously -- it scares away existing and potential customers!
Smarter corporations may learn this lesson the easy way, by observing the damage to other businesses from security incidents. Those companies may manage to avoid an embarassing incident. Dumb or callous corporations will learn the hard way -- by having their own business damaged by a security incident, sooner or later.
Security is a cost center. Companies don't like to spend money on things that don't make money. Nevertheless, the potential cost of a lapse in security can far outweigh the cost of providing security. Thus, it makes good business sense to be concerned about security. (At least for those few corporations smart enough to be concerned with long-term viability of the business, and not only short-term profitability...)
Although corporate databases CAN be made to hinder or thwart gathering personal information, WHY would said corporations bother to implement this?
To reduce liability and to avoid adverse publicity, in the event the database is compromised. Sensitive databases have been compromised before, and will be again. The potential damage is limited if the data is encrypted in the database. Corporations don't care about our privacy, but they certainly do care about liability and adverse publicity! (A PR campaign doesn't provide those benefits, only the illusion of them...)
Think about it. That 300 KHz computer may still be running after 50 years, but those 50 years of CPU time add up to about 43 hours of CPU time on a 3.06 GHz Pentium 4. And that's just clock cycles; the Pentium 4 probably gets far more instructions per clock cycle. And, of course, the on-chip cache on the Pentium 4 far exceeds the 2 KB of RAM on that 50-year-old machine.
All in all, today's fastest Pentium could easily exceed the lifetime processing power of the CSIRAC in just a few hours, at a tiny fraction of the cost. Sure, it's cool that the computer still runs after 50 years, but let's put it into perspective here -- we get far more computing power out of modern chips, even if they fail within a couple years! Longevity isn't everything...
I can't remember a single case of two Spanish words sounding identical. The closest I can recall is the words for "yes" and "if". Of course "yes" in Spanish is "si", pronounced like "see"; as in "Si, senor." But "if" in Spanish is also spelled "si", but with an accent mark over the 'i', so the way it is pronounced in a sentence is different.
:-)
You've got it backwards. "Sí" (with the accent) is "yes", while "si" (without the accent) is "if". Thy're also pronounced slightly differently; "sí" is a stressed syllable because of the accent (that's what the accent means) while "si" is unstressed. (By default, the next-to-last syllable in a Spanish word is stressed, unless an accent mark denotes a different syllable to stress.)
But yes, they're pretty similar and potentially confusing, but usually pretty clear from context even if you can't catch the pronunciation. (This is about all I still remember from several years of studying Spanish!
While I'm being pedantic, you also spelled "señor" incorrectly; "n" and "ñ" are considered different letters. For that matter, "ll" is considered a single letter as well, distinct from the letter "l"...
You can bet the former Bell Atlantic customers do think of Verizon as a descendent of the Bell monopoly. (And I believe Bell Atlantic was larger than GTE, but I'm not certain.)
While it's true that soda has a high elasticity (and hense viability for high profit margins), [...]
Okay, it's been a long time since I took an economics class, but I believe you've got this backwards. (But don't take my word for it, I could be misremembering!)
As I recall, soda would be characterized as relatively inelastic because the demand doesn't vary much when the price changes. If they sell that soda for $0.25 instead of $1.25, you're not going to buy 5 times as much. (Maybe you'll buy twice as much.)
My understanding from my economics class was that the inelastic products offered the highest potential profit margins, because the more inelastic the demand, the more room there is to raise prices with relative impunity. If the demand is relatively constant, why not set the prices as high as possible?
Any economics experts out there want to confirm which usage of the terminology is correct?
Too bad Wal-Mart doesn't have a PC or two in their stores that could access their website.
That's a good idea, if they're going to have products that are available only online. Better yet, they could even accept cash payments at the register for an online order, for those without credit cards. They could either have a kiosk or simply a computer at the customer service counter where the CSR could place the order.
Why don't you write to their corporate offices and suggest it? Maybe they'll recognize a good idea when they see it...
This is a major WalMart product now.
I'll consider it a major Wal-Mart product when they put it in all the retail stores.
In case anyone doubts the existence of a bar/laundromat, check out Sudsy Malone's website...