Google Photos could be the greatest thing ever, but it's too late for that. No thank you, I will pass on adopting Google's latest momentary fancy.
Google can't be trusted as a custodian of users' valuable data. Google has the attention span of a sleep-deprived toddler. In the past, it created amazing products, which I wove into my life. Then Google got bored and dropped those products, replacing them with other products I didn't like as much, again and again.
The incentive to destroy and replace products is baked in to Google's performance management ritual. I'm weary of the resulting churn and refuse to be burned again. In addition, I'm fed up with Google's fixation on low-contrast designs. I'm patiently disentangling myself of all Google dependencies.
Disclaimer: I was a software engineer at Google for four years. Hello to a friend who still works on Google Photos...
Glancing through the headlines with divided attention, I mentally juxtaposed the headings of two successive stories, yielding "Iran embraces oil immersion for critics".
In a pressurized light water reactor, the reactor-grade uranium fuel has to be replaced after 3% of the fuel has been burned up, leaving us with 97% useful fuel and some dangerous waste products. Since reprocessing was forbidden in the United States by President Carter, we've been making plans to vitrify and bury all of our leftover fuel in a way that would render it permanently inaccessible. Even if we reversed the ban on reprocessing, we would still be dealing with a lot of dangerous long-lived actinides that are highly radioactive but last longer than the human race has existed.
I recently read a detailed analysis of the thorium fuel cycle. Based on a probabilistic analysis of the decay product chain, it's believed that a practical thorium fuel cycle can be designed that burns up 97% of the fuel, leaving only 3% of the input material behind as nasty stuff. Thorium is also quite plentiful in comparison to uranium, and is isotopically pure unlike uranium.
Here are some interesting facts about the thorium fuel cycle from wikipedia:
There are several potential advantages to thorium-based fuels.
Thorium is estimated to be about three to four times more abundant than uranium in the earth's crust[3], although present knowledge of reserves is limited. Current demand for thorium has been satisfied as a by-product of rare-earth extraction from monazite sands. Also, unlike uranium, naturally occurring thorium consists of only a single isotope (232Th) in significant quantities. Consequently, all mined thorium is useful in thermal reactors.
Thorium-based fuels exhibit several attractive nuclear properties relative to uranium-based fuels. The thermal neutron absorption cross section (a) and resonance integral for 232Th are about three times and one third of the respective values for 238U; consequently, fertile conversion of the former is more efficient in a thermal reactor. Also, although the thermal neutron fission cross section (f) of the 233U is comparable to 235U and 239Pu, it has a much lower capture cross section () than the latter two fissile isotopes, resulting in fewer non-fissile neutron absorptions and improved neutron economy. Finally, the number of neutrons released per neutron absorbed () in 233U is greater than two over a wide range of energies, including the thermal spectrum; as a result, thorium-based fuels can be the basis for a thermal breeder reactor[1].
Because the 233U produced in thorium fuels is inevitably contaminated with 232U, thorium-based used nuclear fuel possesses inherent proliferation resistance. Uranium-232 can not be chemically separated from 233U and ha
I had several unproductive exchanges with Ameritrade last year about this problem. They claimed that my account was compromised by a dictionary attack (the address was lpm_ameritrade_xubz@...) or that it was leaked by a virus on my computer (running OpenBSD).
I changed it several times, eventually to an absurdly long string of random characters--a rhetorical ploy. Each time the address was compromised within weeks. Finally I closed my account and moved to another brokerage, which has kept my contact information delightfully secure.
I'm glad to see that Ameritrade is going to take its licks for this. I was quite unhappy with their handling of the situation. I interacted with one reasonable senior-level person after I had already initiated the closure of my account--he refunded my account termination charges and seemed interested in investigating the problem with an open mind. That doesn't right the wrong.
I usually tend to ignore class action lawsuits but in this case, sign me up! I've got complete, detailed documentation of my SPAM-related suffering at the hand of Ameritrade.
We're dying to use Ruby on Rails. Developers in my group talk about it almost daily. Unfortunately the lack of solid Oracle database support is a showstopper. I'm inquiring about whether we might allocate funding to sponsor development of a stable, complete Oracle driver; my employer has a history of funding open source projects.
I'm sure this is stated in their computer use policy, as it is in ours. Firing the employee was probably the correct action.
Firing him, sure. Going to the media to insult and vilify him, no. How can anyone rise to a senior management position without knowing that defaming former employees is asking for trouble? Who is the unintelligent one again?
when was the last time any of you/.'ers sat down and calmly thoroughly explained cyber security to another n00b and gave them true insight?
Just about every week, to some person or another! I explain clearly and persistently the nature of the problem, what is at stake, the vectors by which computers become infected, and the clear, precise steps required to prevent it. I provide references, and even drag them kicking and screaming, to articles by reputable agencies and media outlets, describing the severity and danger of endemic computer infections.
I recommend a few simple steps for average Windows users: 1) Install some antivirus software or other. (I don't use it myself but I figure it's valuable for people who aren't quite as vigilant about prevention.) 2) Boot in safe mode then run ad-aware. 3) Update system with current security patches. 4) Install ZoneAlarm and learn to use it properly, or at least a home NAT gateway/router. 5) Never use IE for any reason. Download free and vastly superior Mozilla/Firebird. 6) Never use Outlook [Express]. Use Mozilla/Thunderbird or *anything* else! 7) Don't open executable/scriptable attachments (e.g. MS Office,.exe, etc.) If absolutely necessary, scan them with AV software at the least.
People start to get kind of hesitant at step 4, then they always freak out and get really defensive once we reach steps 5 through 7. I don't understand this undying devotion people have to IE / Outlook, despite all the evidence in the world that those two products account for 90% of the problems on the average computer. It's like you offer than a new car that gets 1000 MPG, removes greenhouse gases from the atmosphere and never requires any maintenance, but they still insist to the death on driving their rusty old Microsoft Jalopy that gets 8 MPG, can't go over 22 MPH, fills the passenger compartment with noxious fumes and catches on fire at least twice a day.
Once in a while someone listens, perhaps combatively at first, but then gets religion and goes out to spread the gospel. A couple weeks ago one of my coworkers spent a half hour arguing that I was being terribly unfair and unrealistic, expecting him and other average users not to pass around word documents and "funny bouncy ball".exe programs, and even give up his beloved Internet Explorer (with ActiveX(tm)!) Well, about two days later, after he ran Ad-Aware, he came in to my office looking quite shell-shocked, and asked if I could write down all my suggestions again. Now he's planning to help no less than six of his friends and family members to clean up their computers and use them more responsibly in the future. He took me out for lunch as a thank you.
Anyway, spread the word; more and more people will come around in time.
Very good points. Don't forget, also, that coal is responsible for the increasing levels of mercury in the environment. Over time, the metallic mercury released by coal-burning plants is transformed into organic methyl mercury, which is phenomenally toxic and teratogenic. The FDA and EPA are recommending that pregnant and nursing women severely limit their intake of fish, and that humans should never eat certain kinds of fish high on the food chain (shark, tilefish, swordfish, etc.) Mercury levels in tuna have also risen to worrisome levels.
Until we change our outlook, the growing energy needs of our planet will be met primarily with toxic, dirty coal, and we will be suffering the consequences for a very long time.
Credible links with more information: http://www.pbs.org/now/science/mercu ryinfish.html http://www.epa.gov/ost/fishadvice/m ercupd.pdf
The DEP feature (buffer overrun protection) of XP SP2, or its equivalent in the Linux and BSD worlds, is only available if you are running a K8 based (Athlon 64, Opteron, etc.) processor from AMD. Intel CPUs do not feature hardware-based buffer overrun protection, so this feature is not available on Intel-based x86 systems.
What, therefore, stops [Cable/Sat companies] from ripping all of the DVD's in, say, NetFlix's library into their format, storing it on their server, and putting up a request system.
Answer: you're talking about the cable companies, not the most innovative or customer-focused industry.
The satellite providers show more promise, but I doubt it's feasible until/unless receiver boxes have PVR capabilities. I strongly doubt that satellites have infinite bandwidth to support pointcasting to thousands of distinct clients at once. It would be much more practical to: 1) Cache top-sellers on receivers at all times, flipping a bit to enable viewing when ordered; 2) Spool other movies to subscribers on demand, potentially segmenting the data into priority-queued sections in order to provide near-immediate gratification.
In other words: When people find collisions (two different datasets that result in the exact same digest), then that is the first step towards being able to "reverse" the digest process, and extract the original data from the digest, thus rendering the encryption useless.
Nooo.... Not even close.
Let me illustrate with a simple example. Imagine that a hash function produces a 2 bit digest value from an arbitrary input 500 bit string. It's not a good hash function, because in about three tries you find another input string that produces the same hash value. However, you don't have any hope of turning one of the hash values (0, 1, 2 or 3) back into the 500 bit input string, even though the hashing algorithm is clearly broken by any commonly accepted definition.
A more realistic example is the MD5 hashing algorithm, which produces a 128 bit digest value from an arbitrary input string. Assume, for the sake of simplicity, that you're hashing only 1024 bit strings (though the input strings could be of any length). Then there are 2^(1024-128) = 2^896 possible input strings for every hash value. Your chances of guessing the correct input string are 1 in 2^896 (i.e. zero.) Remove the restriction that the input string must be of fixed length and your chances suffer even further.
In reality, the problem with a broken hashing algorithm is that an attacker can manufacture an altered document without affecting the "tamper-resistant" seal, i.e. the hash function digest. Other applications of digest algorithms dependent on probabilistically-guaranteed uniqueness of digest values as a function of content, like the creation of content-based unique identifiers, are likewise endangered.
However, the mere existence of a few random collisions, while potentially a source of unease for system and application designers, is not in itself evidence that a hashing algorithm is broken. Brokenness implies that for a given input X and digest F(X), other inputs Y can be generated in limited time such that F(X)=F(Y).
Unfortunately (for you), your grade school science lecture on electricity is not applicable to the power consumption of a CPU. There is no meaningful comparison to be made between a passive device like a light bulb or a water pump, and a nonlinear device like a CPU.
The dominant term in the CPU power consumption function is proportional to the square of the supply voltage, relating to the power consumed when charging a capacitor (or transistor). Using higher voltage can enable a CPU to achieve a greater clock rate, at the expense of diminished reliability and operating lifespan. However, since the CPU is not a system designed for the primary purpose of transforming electrical energy into heat, mechanical or radiant energy, it is not necessary to compensate for lower voltage with increased amperage in order to keep power level constant.
You are using a circular argument to support your flawed assumption that a CPU must maintain a certain level of power consumption regardless of applied voltage. Moreover, you are incorrect in stating that reducing voltage (assuming constant amperage) does not increase battery life. The battery is used to drive an efficient DC to DC converter in the power supply, so reduced supply voltage for the CPU translates into reduced battery current and power consumption.
Finally, your example about the water-saving showerhead is oversimplified, to put it nicely.
It sounds like you need a Netflix subscription. They have about ten times the selection of your typical Blockbuster, with a strong emphasis on the interesting programming that Blockbuster avoids. It's $20 a month, you always have three movies in your possession or in transit at any given time, there are no late fees and postage both ways is free. I have no economic incentive to promote them; I'm just a satisfied customer. You should not have any difficulty locating their website.
Also, who builds any system using a Celeron?? Celerons suck. A 1800 MHz Duron + motherboard combo would have run him $49 at Fry's, utterly blowing the Celeron system out of the water by every conceivable measure of utility. I wonder if his anemic Celeron was responsible for the choppy playback he experienced.
He might as well have used a Via EPIA if he wanted a low-performance system. At least a Via system is tiny, silent, inexpensive and remarkably sparing in its power consumption. The newer multimedia-oriented EPIA motherboards even have integrated MPEG accelerators.
Unless I've totally failed to grasp the concept of SPF, it seems that in an "SPF-protected" world the spammers will ensure that they only spam others using your actual email address, not just some made-up email address from your domain. Hooray for progress. Meanwhile, be sure to ask your doctor to prescribe a whole spectrum of antibiotics for your next minor viral infection, to ensure that the rise of antibiotic-resistant bacteria continues unabated.
I will say that the spirit of the SPF concept is 100% AOL (not counting the former Netscape).
Mr. Lyons' portrayal of Linux and the open source community as unrepentant Marxist movements is absurd. Cooperation and openness do not equate to communism. Nobody accuses the scientific community and the peer review process of being proletariat uprisings, but Mr. Lyons seems to believe that a desire to subject software development to the same scientific rigor and transparency is akin to renouncing the concept of private property. The GPL is absolutely dependent on the legal concepts of private property, copyright, and contracts. Nobody is compelled to use GPL-licensed software. If the terms of the GPL license do not suit a developer's needs, he should buy from another vendor with more satisfactory licensing terms, use BSD-licensed software, or write his own code in-house. But he should not expect that he can steal intellectual property, violate the clear and simple licensing terms, and profit from his lawlessness with impunity. It is ironic that Mr. Lyons condemns the FSF for compelling intellectual property thieves to meet their licensing obligations (which is much less intrusive than taking away their profits or preventing the sale of their products), while he tacitly condones the lawless usurpation of intellectual property by corporate heavyweights. He accuses the open-source community of being Marxists, and yet he comes across as the real opponent of private property rights (unless that property is owned by a large and secretive corporation.) I can't decide whether Mr. Lyons is a Plutocrat or a Marxist, but he certainly doesn't come across as a capitalist.
If Mr. McBride is concerned with potential intellectual property infringements in software created by the open source community, I believe that he has no choice but to remove the potentially-infringing material from all SCO products. Otherwise he is willfully engaging in theft of intellectual property, not to mention hypocrisy. Consequently, I believe that SCO should issue an immediate worldwide recall of all their products containing Apache, Perl, PHP, SAMBA, Python, gcc and all other GNU software, Mozilla, PostgreSQL, MySQL, etc. SCO should then refrain from the use and distribution of these software products or any other products which may conceivably contain traces of contaminated code until all such code can be proven beyond question to be 100% clean.
Granted, that telephone service you ordered from your local carrier has a few nice features: * you get a fairly permanent phone number and the ability to receive incoming calls * there's no "activation procedure" required before each session of telephone use * 99.9999% uptime! * you can choose any long distance carrier * the network has sufficient capacity that under normal circumstances, you always get a dialtone when you pick up the phone, and your phone always rings when someone calls you * no arbitrary restrictions on calls to modems, fax machines, voicemail / answering machines and the like * no limit on your talk-time per day or month
I'm not a fan of SBC but I'll grant that they still provide quality local dial service at a fair price.
On the other hand, the same incumbent carriers' residential DSL services are pursuing a different model that negates all the features above: * bandwidth limits, connect time limits * no static / routable IPs * port blocking * badly oversubscribed networks
Consequently, CLECs are the only game in town if you plan on using your computer for anything more involved than checking your SBC/Yahoo DSL home page.
A few years ago I got an illegal left-hand turn ticket at a poorly marked intersection. I sent in the request for trial and $644 in bail (!!!) to the City of San Francisco via certified mail, return receipt requested. It was delivered two months later, well after the deadline, and I received my return receipt around 400 DAYS (!) after my original mailing. Fortunately I've been burned enough by bad service that I always check up by telephone before important deadlines pass, so I wasted a half day driving over there to make the request and payment in person. Good work, thanks USPS!
Likewise, all that waste is sitting around in pools (though warm as they are, I wouldn't want to swim in them) because Carter signed an executive order banning reprocessing (known as Presidential Directive 8, subsequently reaffirmed as President Clinton's Presidential Directive 13.) There are certainly issues to consider with reprocessing, but it's a fact that we wouldn't have all this nuclear waste lying around if we recycled it into useful component elements.
It would be feasible to diffuse the cost using a P2P distributed application model. Your profile information could be mirrored by others in your circle. Directory service would be a minor bottleneck. Facilitating the social connectivity graphing function without bogging down the network is where the interesting problem might lie.
My first inclination was to deplore this latest breach in the handling of our most sensitive personal data by its self-appointed custodians at Acxiom. But after reflecting for a couple hours, I realize that this makes no difference at all. Is this guy in trouble just because he took the data without paying for it? I'm sure that Acxiom could have accomodated him if he had just created his own marketing firm and forked over some $$$.
"But Acxiom would never sell your most sensitive personal data! They only use for internal modeling, aggregated statistical profiling, {cancer|AIDS} research, finding loving homes for stray kitties and puppies, etc." Or for sharing with affliliated partners, i.e. anyone who is willing to pay for it.
If Acxiom wasn't selling the information, you could still count on the DMV to sell your information to all comers.
This would be fantastic for billions of devices in the world that don't need massive bandwidth: fire and intrusion alarms, periodic appliance and vehicle telemetry dumps, remote controls for doorknobs and electrical items and so forth, electric and gas meters, cable box uplinks, sump pump failure alarms, water heater leak detectors, etc.
I've long desired to see a dynamically forming pervasive network based on a technology just like this, that would allow your car or child or laptop to tell you (via an embedded transponder) where it went if it got "lost". I'd like a battery-powered alarm in my storage unit that would notify me if someone broke in, or if water was leaking in, or the battery was low. Same goes for my home burglar alarm. It would be nice if you could connect a device to the network for pennies a day. I don't need 128Kbits/sec for a smoke detector (at $60/mo/node over CDMA!!!), but I do need always-on connectivity.
The example you always see about your refrigerator ordering more milk for you is completely stupid, but it would be nice if your washing machine could let the manufacturer know that preventative service was required before it died. Manufacturers would also love to be able to collect test data from deployed devices for defect tracking and analysis.
Presumably wall-powered devices would form more powerful repeaters for the battery-powered nodes, then network nodes would send the traffic through some wired network or the internet for further application-specific routing. Anyway, driving down the cost opens up a dramatic new frontier of wireless applications for any device with a modicum of state or intelligence.
Slashdot Mirror
Google Photos could be the greatest thing ever, but it's too late for that. No thank you, I will pass on adopting Google's latest momentary fancy.
Google can't be trusted as a custodian of users' valuable data. Google has the attention span of a sleep-deprived toddler. In the past, it created amazing products, which I wove into my life. Then Google got bored and dropped those products, replacing them with other products I didn't like as much, again and again.
The incentive to destroy and replace products is baked in to Google's performance management ritual. I'm weary of the resulting churn and refuse to be burned again. In addition, I'm fed up with Google's fixation on low-contrast designs. I'm patiently disentangling myself of all Google dependencies.
Disclaimer: I was a software engineer at Google for four years. Hello to a friend who still works on Google Photos...
Glancing through the headlines with divided attention, I mentally juxtaposed the headings of two successive stories, yielding "Iran embraces oil immersion for critics".
In a pressurized light water reactor, the reactor-grade uranium fuel has to be replaced after 3% of the fuel has been burned up, leaving us with 97% useful fuel and some dangerous waste products. Since reprocessing was forbidden in the United States by President Carter, we've been making plans to vitrify and bury all of our leftover fuel in a way that would render it permanently inaccessible. Even if we reversed the ban on reprocessing, we would still be dealing with a lot of dangerous long-lived actinides that are highly radioactive but last longer than the human race has existed.
I recently read a detailed analysis of the thorium fuel cycle. Based on a probabilistic analysis of the decay product chain, it's believed that a practical thorium fuel cycle can be designed that burns up 97% of the fuel, leaving only 3% of the input material behind as nasty stuff. Thorium is also quite plentiful in comparison to uranium, and is isotopically pure unlike uranium.
Here are some interesting facts about the thorium fuel cycle from wikipedia:
I had several unproductive exchanges with Ameritrade last year about this problem. They claimed that my account was compromised by a dictionary attack (the address was lpm_ameritrade_xubz@...) or that it was leaked by a virus on my computer (running OpenBSD).
I changed it several times, eventually to an absurdly long string of random characters--a rhetorical ploy. Each time the address was compromised within weeks. Finally I closed my account and moved to another brokerage, which has kept my contact information delightfully secure.
I'm glad to see that Ameritrade is going to take its licks for this. I was quite unhappy with their handling of the situation. I interacted with one reasonable senior-level person after I had already initiated the closure of my account--he refunded my account termination charges and seemed interested in investigating the problem with an open mind. That doesn't right the wrong.
I usually tend to ignore class action lawsuits but in this case, sign me up! I've got complete, detailed documentation of my SPAM-related suffering at the hand of Ameritrade.
We're dying to use Ruby on Rails. Developers in my group talk about it almost daily. Unfortunately the lack of solid Oracle database support is a showstopper. I'm inquiring about whether we might allocate funding to sponsor development of a stable, complete Oracle driver; my employer has a history of funding open source projects.
I'm sure this is stated in their computer use policy, as it is in ours. Firing the employee was probably the correct action.
Firing him, sure. Going to the media to insult and vilify him, no. How can anyone rise to a senior management position without knowing that defaming former employees is asking for trouble? Who is the unintelligent one again?
Feel free to share your thoughts with the agency in question:
ODJFS Feedback
Contact Ohio Governor Taft
Does anyone know of a Political Action Committee for IT Professionals, Computer Scientists, the Open Source movement, or anything along those lines?
The Electronic Frontier Foundation, perhaps?
when was the last time any of you /.'ers sat down and calmly thoroughly explained cyber security to another n00b and gave them true insight?
.exe, etc.) If absolutely necessary, scan them with AV software at the least.
.exe programs, and even give up his beloved Internet Explorer (with ActiveX(tm)!) Well, about two days later, after he ran Ad-Aware, he came in to my office looking quite shell-shocked, and asked if I could write down all my suggestions again. Now he's planning to help no less than six of his friends and family members to clean up their computers and use them more responsibly in the future. He took me out for lunch as a thank you.
Just about every week, to some person or another! I explain clearly and persistently the nature of the problem, what is at stake, the vectors by which computers become infected, and the clear, precise steps required to prevent it. I provide references, and even drag them kicking and screaming, to articles by reputable agencies and media outlets, describing the severity and danger of endemic computer infections.
I recommend a few simple steps for average Windows users:
1) Install some antivirus software or other. (I don't use it myself but I figure it's valuable for people who aren't quite as vigilant about prevention.)
2) Boot in safe mode then run ad-aware.
3) Update system with current security patches.
4) Install ZoneAlarm and learn to use it properly, or at least a home NAT gateway/router.
5) Never use IE for any reason. Download free and vastly superior Mozilla/Firebird.
6) Never use Outlook [Express]. Use Mozilla/Thunderbird or *anything* else!
7) Don't open executable/scriptable attachments (e.g. MS Office,
People start to get kind of hesitant at step 4, then they always freak out and get really defensive once we reach steps 5 through 7. I don't understand this undying devotion people have to IE / Outlook, despite all the evidence in the world that those two products account for 90% of the problems on the average computer. It's like you offer than a new car that gets 1000 MPG, removes greenhouse gases from the atmosphere and never requires any maintenance, but they still insist to the death on driving their rusty old Microsoft Jalopy that gets 8 MPG, can't go over 22 MPH, fills the passenger compartment with noxious fumes and catches on fire at least twice a day.
Once in a while someone listens, perhaps combatively at first, but then gets religion and goes out to spread the gospel. A couple weeks ago one of my coworkers spent a half hour arguing that I was being terribly unfair and unrealistic, expecting him and other average users not to pass around word documents and "funny bouncy ball"
Anyway, spread the word; more and more people will come around in time.
Very good points. Don't forget, also, that coal is responsible for the increasing levels of mercury in the environment. Over time, the metallic mercury released by coal-burning plants is transformed into organic methyl mercury, which is phenomenally toxic and teratogenic. The FDA and EPA are recommending that pregnant and nursing women severely limit their intake of fish, and that humans should never eat certain kinds of fish high on the food chain (shark, tilefish, swordfish, etc.) Mercury levels in tuna have also risen to worrisome levels.
u ryinfish.htmlm ercupd.pdf
Until we change our outlook, the growing energy needs of our planet will be met primarily with toxic, dirty coal, and we will be suffering the consequences for a very long time.
Credible links with more information:
http://www.pbs.org/now/science/merc
http://www.epa.gov/ost/fishadvice/
The DEP feature (buffer overrun protection) of XP SP2, or its equivalent in the Linux and BSD worlds, is only available if you are running a K8 based (Athlon 64, Opteron, etc.) processor from AMD. Intel CPUs do not feature hardware-based buffer overrun protection, so this feature is not available on Intel-based x86 systems.
What, therefore, stops [Cable/Sat companies] from ripping all of the DVD's in, say, NetFlix's library into their format, storing it on their server, and putting up a request system.
Answer: you're talking about the cable companies, not the most innovative or customer-focused industry.
The satellite providers show more promise, but I doubt it's feasible until/unless receiver boxes have PVR capabilities. I strongly doubt that satellites have infinite bandwidth to support pointcasting to thousands of distinct clients at once. It would be much more practical to:
1) Cache top-sellers on receivers at all times, flipping a bit to enable viewing when ordered;
2) Spool other movies to subscribers on demand, potentially segmenting the data into priority-queued sections in order to provide near-immediate gratification.
In other words: When people find collisions (two different datasets that result in the exact same digest), then that is the first step towards being able to "reverse" the digest process, and extract the original data from the digest, thus rendering the encryption useless.
Nooo.... Not even close.
Let me illustrate with a simple example. Imagine that a hash function produces a 2 bit digest value from an arbitrary input 500 bit string. It's not a good hash function, because in about three tries you find another input string that produces the same hash value. However, you don't have any hope of turning one of the hash values (0, 1, 2 or 3) back into the 500 bit input string, even though the hashing algorithm is clearly broken by any commonly accepted definition.
A more realistic example is the MD5 hashing algorithm, which produces a 128 bit digest value from an arbitrary input string. Assume, for the sake of simplicity, that you're hashing only 1024 bit strings (though the input strings could be of any length). Then there are 2^(1024-128) = 2^896 possible input strings for every hash value. Your chances of guessing the correct input string are 1 in 2^896 (i.e. zero.) Remove the restriction that the input string must be of fixed length and your chances suffer even further.
In reality, the problem with a broken hashing algorithm is that an attacker can manufacture an altered document without affecting the "tamper-resistant" seal, i.e. the hash function digest. Other applications of digest algorithms dependent on probabilistically-guaranteed uniqueness of digest values as a function of content, like the creation of content-based unique identifiers, are likewise endangered.
However, the mere existence of a few random collisions, while potentially a source of unease for system and application designers, is not in itself evidence that a hashing algorithm is broken. Brokenness implies that for a given input X and digest F(X), other inputs Y can be generated in limited time such that F(X)=F(Y).
Unfortunately (for you), your grade school science lecture on electricity is not applicable to the power consumption of a CPU. There is no meaningful comparison to be made between a passive device like a light bulb or a water pump, and a nonlinear device like a CPU.
The dominant term in the CPU power consumption function is proportional to the square of the supply voltage, relating to the power consumed when charging a capacitor (or transistor). Using higher voltage can enable a CPU to achieve a greater clock rate, at the expense of diminished reliability and operating lifespan. However, since the CPU is not a system designed for the primary purpose of transforming electrical energy into heat, mechanical or radiant energy, it is not necessary to compensate for lower voltage with increased amperage in order to keep power level constant.
You are using a circular argument to support your flawed assumption that a CPU must maintain a certain level of power consumption regardless of applied voltage. Moreover, you are incorrect in stating that reducing voltage (assuming constant amperage) does not increase battery life. The battery is used to drive an efficient DC to DC converter in the power supply, so reduced supply voltage for the CPU translates into reduced battery current and power consumption.
Finally, your example about the water-saving showerhead is oversimplified, to put it nicely.
I wonder if I just fell for a troll...
It sounds like you need a Netflix subscription. They have about ten times the selection of your typical Blockbuster, with a strong emphasis on the interesting programming that Blockbuster avoids. It's $20 a month, you always have three movies in your possession or in transit at any given time, there are no late fees and postage both ways is free. I have no economic incentive to promote them; I'm just a satisfied customer. You should not have any difficulty locating their website.
Also, who builds any system using a Celeron?? Celerons suck. A 1800 MHz Duron + motherboard combo would have run him $49 at Fry's, utterly blowing the Celeron system out of the water by every conceivable measure of utility. I wonder if his anemic Celeron was responsible for the choppy playback he experienced.
He might as well have used a Via EPIA if he wanted a low-performance system. At least a Via system is tiny, silent, inexpensive and remarkably sparing in its power consumption. The newer multimedia-oriented EPIA motherboards even have integrated MPEG accelerators.
Unless I've totally failed to grasp the concept of SPF, it seems that in an "SPF-protected" world the spammers will ensure that they only spam others using your actual email address, not just some made-up email address from your domain. Hooray for progress. Meanwhile, be sure to ask your doctor to prescribe a whole spectrum of antibiotics for your next minor viral infection, to ensure that the rise of antibiotic-resistant bacteria continues unabated.
I will say that the spirit of the SPF concept is 100% AOL (not counting the former Netscape).
Mr. Lyons' portrayal of Linux and the open source community as unrepentant Marxist movements is absurd. Cooperation and openness do not equate to communism. Nobody accuses the scientific community and the peer review process of being proletariat uprisings, but Mr. Lyons seems to believe that a desire to subject software development to the same scientific rigor and transparency is akin to renouncing the concept of private property. The GPL is absolutely dependent on the legal concepts of private property, copyright, and contracts. Nobody is compelled to use GPL-licensed software. If the terms of the GPL license do not suit a developer's needs, he should buy from another vendor with more satisfactory licensing terms, use BSD-licensed software, or write his own code in-house. But he should not expect that he can steal intellectual property, violate the clear and simple licensing terms, and profit from his lawlessness with impunity. It is ironic that Mr. Lyons condemns the FSF for compelling intellectual property thieves to meet their licensing obligations (which is much less intrusive than taking away their profits or preventing the sale of their products), while he tacitly condones the lawless usurpation of intellectual property by corporate heavyweights. He accuses the open-source community of being Marxists, and yet he comes across as the real opponent of private property rights (unless that property is owned by a large and secretive corporation.) I can't decide whether Mr. Lyons is a Plutocrat or a Marxist, but he certainly doesn't come across as a capitalist.
> 46 55 43 4B 20 5A 4F 55 21 21 21
What's scary is that I can read that at about 2 CPS without help from a computer -- !!!'s and all.
If Mr. McBride is concerned with potential intellectual property infringements in software created by the open source community, I believe that he has no choice but to remove the potentially-infringing material from all SCO products. Otherwise he is willfully engaging in theft of intellectual property, not to mention hypocrisy. Consequently, I believe that SCO should issue an immediate worldwide recall of all their products containing Apache, Perl, PHP, SAMBA, Python, gcc and all other GNU software, Mozilla, PostgreSQL, MySQL, etc. SCO should then refrain from the use and distribution of these software products or any other products which may conceivably contain traces of contaminated code until all such code can be proven beyond question to be 100% clean.
That will be a winning software platform.
Granted, that telephone service you ordered from your local carrier has a few nice features:
* you get a fairly permanent phone number and the ability to receive incoming calls
* there's no "activation procedure" required before each session of telephone use
* 99.9999% uptime!
* you can choose any long distance carrier
* the network has sufficient capacity that under normal circumstances, you always get a dialtone when you pick up the phone, and your phone always rings when someone calls you
* no arbitrary restrictions on calls to modems, fax machines, voicemail / answering machines and the like
* no limit on your talk-time per day or month
I'm not a fan of SBC but I'll grant that they still provide quality local dial service at a fair price.
On the other hand, the same incumbent carriers' residential DSL services are pursuing a different model that negates all the features above:
* bandwidth limits, connect time limits
* no static / routable IPs
* port blocking
* badly oversubscribed networks
Consequently, CLECs are the only game in town if you plan on using your computer for anything more involved than checking your SBC/Yahoo DSL home page.
Speaking of bad post office experiences:
A few years ago I got an illegal left-hand turn ticket at a poorly marked intersection. I sent in the request for trial and $644 in bail (!!!) to the City of San Francisco via certified mail, return receipt requested. It was delivered two months later, well after the deadline, and I received my return receipt around 400 DAYS (!) after my original mailing. Fortunately I've been burned enough by bad service that I always check up by telephone before important deadlines pass, so I wasted a half day driving over there to make the request and payment in person. Good work, thanks USPS!
Likewise, all that waste is sitting around in pools (though warm as they are, I wouldn't want to swim in them) because Carter signed an executive order banning reprocessing (known as Presidential Directive 8, subsequently reaffirmed as President Clinton's Presidential Directive 13.) There are certainly issues to consider with reprocessing, but it's a fact that we wouldn't have all this nuclear waste lying around if we recycled it into useful component elements.
Interesting discussion:
PBS Frontline
University of Minnesota Technology newsletter
It would be feasible to diffuse the cost using a P2P distributed application model. Your profile information could be mirrored by others in your circle. Directory service would be a minor bottleneck. Facilitating the social connectivity graphing function without bogging down the network is where the interesting problem might lie.
My first inclination was to deplore this latest breach in the handling of our most sensitive personal data by its self-appointed custodians at Acxiom. But after reflecting for a couple hours, I realize that this makes no difference at all. Is this guy in trouble just because he took the data without paying for it? I'm sure that Acxiom could have accomodated him if he had just created his own marketing firm and forked over some $$$.
"But Acxiom would never sell your most sensitive personal data! They only use for internal modeling, aggregated statistical profiling, {cancer|AIDS} research, finding loving homes for stray kitties and puppies, etc." Or for sharing with affliliated partners, i.e. anyone who is willing to pay for it.
If Acxiom wasn't selling the information, you could still count on the DMV to sell your information to all comers.
This would be fantastic for billions of devices in the world that don't need massive bandwidth: fire and intrusion alarms, periodic appliance and vehicle telemetry dumps, remote controls for doorknobs and electrical items and so forth, electric and gas meters, cable box uplinks, sump pump failure alarms, water heater leak detectors, etc.
I've long desired to see a dynamically forming pervasive network based on a technology just like this, that would allow your car or child or laptop to tell you (via an embedded transponder) where it went if it got "lost". I'd like a battery-powered alarm in my storage unit that would notify me if someone broke in, or if water was leaking in, or the battery was low. Same goes for my home burglar alarm. It would be nice if you could connect a device to the network for pennies a day. I don't need 128Kbits/sec for a smoke detector (at $60/mo/node over CDMA!!!), but I do need always-on connectivity.
The example you always see about your refrigerator ordering more milk for you is completely stupid, but it would be nice if your washing machine could let the manufacturer know that preventative service was required before it died. Manufacturers would also love to be able to collect test data from deployed devices for defect tracking and analysis.
Presumably wall-powered devices would form more powerful repeaters for the battery-powered nodes, then network nodes would send the traffic through some wired network or the internet for further application-specific routing. Anyway, driving down the cost opens up a dramatic new frontier of wireless applications for any device with a modicum of state or intelligence.