Walmart lets you ship for free to your local Walmart store? I'm not aware of that, nor is their web site documentation.
Can I order at Walmart.com and pick up at a store?
Yes, you can for Photo Center and Vision Center items and for some tires. Other items we deliver via the shipping method of your choice, straight to your door or to another address you enter during checkout.
And for a limited time, if you live in the Dallas-Fort Worth, Texas area, you can purchase select items available only online and pick them up at a Dallas-Fort Worth area store.
I submitted this as a story back on June 4. Since it was rejected (too
verbose?), I posted it to
my/. journal. My main question to other folks relates to how this
would compare to using a regular ramdisk. The main deficiency with a
ramdisk is that you'd have to reload the contents every time you reboot.
Here's my article, with all its links:
Giga-byte Technology recently came out with a DRAM-based PC card that
operates as a SATA hard drive. The product, iRAM, uses power from the
motherboard to keep memory active when the system is shut down. During power
outages, the product uses a on-board battery to retain memory for up to 90
minutes. The iRAM card is being talked about in the news (InfoWorld,
itWorldCanada,
engadget,
PCWorld,
multiplay forum) as a means of booting Windows faster. That is, you install
Windows onto the iRAM drive to take advantage of the RAM's faster read-access
time. Just hope that you don't lose power for more than 90 minutes.
Is boot time really that important, since many computers are on all the time?
A ramdisk might have better uses, perhaps for caching frequently-accessed files
such as databases and webservers. Or, if you insist on having faster bootup,
instead of putting Windows on the iRAM disk, why not just store the hibernation
file there?
I implemented a RAM-based database for an internet tool in 1998 to alleviate
the read/write load on my local hard drive. It turned out to be a simple
solution for the problem. At the time, it was just a matter of using a DOS-based
ramdisk driver (ramdisk.sys). On application startup, it copied the database
files to the ramdisk. During operation, everything was read/written to the
ramdisk, and periodic backups were made to the physical disk. There are some
inherent risks, such as loss of data during a crash since data isn't immediately
written to a physical hard drive, so it may not be a great solution for a
mission-critical production database. The iRAM product would make this type of
database even more stable, in that the risk of loss of data is much less.
That was a while ago, so I thought I'd look into setting up a ramdisk in XP
for some amusement. Follows are the results of that search. It seems that the
options are relatively sparse beyond the DOS-based driver. A few freeware and
commercial packages are available, though. One key factor beyond price is the
size limit of ramdisk.
Microsoft's
ramdisk offerings since Win2k are limited. Included with the XP OS is a
ramdisk sample driver that "provides an example of a minimal driver.
Neither the driver nor the sample programs are intended for use in a production
environment. Rather, they are intended for educational purposes and as a
skeletal version of a driver." Installation isn't simple enough for most users
to benefit.
My interpretation of the definitions indicates that "To" would be an example of kerning, not ligature.
From
morrcom.com, "Kerning refers to improving the appearance of type by
adjusting the spacing between selected pairs of letters. The most problematic
pairs of letters are AV, AY, FA, AW, PA, and AT. Kerning becomes of greater
importance as type size increases such as in headlines and poster copy which
uses all caps."
From
Webster, a ligature is a "printed or written character (as æ
or [ff]) consisting of two or more letters or characters joined together."
What I want is my Aibo controlled by a real brain, even if it is only a
cockroach brain
(see also,./).
Imagine, a robot that can think for itself! You could make a whole herd of
them for your own insect/Aibo colony. As the technology progresses, you
can move up to reptiles (gecko, iguana, etc) and finally into mammals (mice,
rats, cats, dogs, monkeys, hobos). Soon enough, you'll be able to get your
own Hobo Aibo.
Even in the beginning, this has a lot of potential. If we can wire up a
cockroach into an Aibo, it might be our next congressbug. Who knows, maybe it
could even be our next president. Unfortunately, it probably won't get elected,
since it likely can't lie, scheme, cheat, take bribes, and deceive as well as
the real thing.
On first blush, this seems like a "look at me!" article. But I
think the author does bring up some good points on methodologies used in
fighting spam on a large scale. However, one thing that isn't emphasized
is how little
deliverable email he gets. It looks like it averages 5-10 messages per
hour.
So the next question is, how would his techniques scale to a domain that
processes
3.5 million emails per day and rejects 0.25-3.0 million spam emails per day.
Plus, to reduce the risk of false positives, much of the spam is actually
delivered to users. All delivered email has a spam score added to the
email headers for the individual user to decide their threshold for filtering.
For those of you out there who are IT for domains that handle millions of
emails per day, how do you handle spam? How many servers and how
much bandwidth does it require?
If you're curious, I get 100 emails per day delivered and 78.2% of that is
spam. Unfortunately, I've found that I can't rely on the spam score added
to the headers by the aforementioned domain. My filter (k9,
Bayesian) currently has a false negative rate of 0.49% and false positive rate
of 0.00%. Yeah, that means I see a single piece of spam every two days on
average. In reality, I'll usually get a surge of spam where on a single
day I might get two or three pieces of spam, followed by a week of nothing once
the filter has adapted.
For protection on the net, especially for usenet and web forms, I use
disposable email addresses (ie:
spamgourmet, mailinator).
Thanks for the link. It's an interesting idea. I doubt it will catch on or replace ASL any time soon, though. Signaling 4 (or worse, 132) to someone might cause problems. And a slight correction to your post... you could only count up to 1023, not 1024.
It might be more interesting to exclude the thumbs. Then you could signal a byte of information at a time.
In any case, it's not very practical for general use. It could potentially find a niche in certain areas.
I submitted this same story with a lot more detail (but not the
InformationWeek link) 28 hours prior to the timestamp on this story. It
was rejected. Sure, mod me off-topic if you think I'm whining.
I posted my write-up in
my journal for posterity's sake. Replies are welcome on this post in
regards to the actual news story. Comments as to why you think the
submission was rejected should only be posted in the journal. (You don't
want to be off-topic, right?) Did I submit at the wrong time of day?
Was the submission too long? Ok... enough whining.
What's to keep someone from buying five copies of XP Pro from an overseas vendor for $5-10 a piece and then getting legitimate licenses from MS via this offer?
Is MS planning on affecting offshore folks? It seems that their legal reach is limited to select countries.
I had an idea to do this about a year ago. Alright... I didn't build it yet (let alone patent it!), so I guess I really can't complain.
I thought it would be better to automate the process a little more. Set up each blind with an auto-targeting rifle using machine vision for target identification and tracking. It would be feasible using off-the-shelf components. One could go so far as having a system that even automatically compensates for range, air density, and wind, and targeting appropriate kill-zones on the animal.
I considered the risk of erroneous identification. At this time, I felt the best way to handle this is via photo/video confirmation via cell or network. That way the kill shot would have to be confirmed by a human. It would be limiting if the dial-up/login/confimation takes too long, though.
Another advantage would be to have multiple hides with autonomous systems. It would be especially useful running multiple hides simultaneously from one managing remote console. In fact, in this case they wouldn't even have to be automated, just remote controlled. My preference would still be having automated sighting, identification, and tracking. Then it's just pulling the trigger (or clicking the mouse) over a secure (or closed-loop) connection.
Would laws pertaining to hunting from vehicles pertain to this scenario? It seems the intent of that law might prohibit automated systems.
Obviously each component of the system would have to be thoroughly tested in many unloaded scenarios.
It would probably be a lot more practical (and with considerably less legal concern) to do all this with cameras only. The ideal situation would be a wide-view camera for motion detection and targeting. A high-quality high-zoom camera would be the "rifle" camera. It could be set to take video, sequenced frames with a delay, or single shot, depending on preference. This sort of setup could acquire very high quality photographs of wildlife without much effort. No remote console/control would be necessary.
It could be made less expensive by only using one camera with variable zoom, using it as both the spotting scope and the capture camera. Another cost-cutting measure would be to drop the bulk of the image recognition for identifying the animal. It could be simplified to look for motion and apparent size to find objects of interest and capture those. Human or automated post-processing could decide the value of the image/video.
Upon doing a web search, I found that there are lots of camera traps/hides/blinds. But most are tripwire-triggered (IR beam gate or IR motion). None I found incorporate image motion detection, image recognition, and automatic camera pan/tilt/zoom.
So how much should I charge when I start selling these?;)
Regarding the short time for SEARCH and large GET requests...
Most likely it has *nothing* to do with script kiddies. You're just seeing others on your ISP infected with worms. While it is possible that it's someone manually looking for a vulnerability, it's a lot more likely to be a worm.
This same misunderstanding is often used by firewall manufacturers, whose products scream "look at all these probes I blocked!" The users think their investment is well worth it, even though a properly patched system wouldn't be affected. Of course a new worm/vulnerability can affect systems before a patch is available, but it can also affect systems before firewall/AV updates are available as well.
You're just seeing your Apache logs fill up with these unusual requests. If you are running the latest version (and run AV, firewall, etc. to reasonably secure your system), they are more of an annoyance than anything else.
And you thought it was bad when your pet got worms. Now it's your much-beloved computer at risk.
It seems that some of the basic needs for a voting system are:
Voters trust the system to be accurate and unbiased
Some means is available to re-count the votes. For digital systems, this may include *backups* or a combination paper/electronic system as mentioned in the parent comment
A means for voters to affirm their voting intent (perhaps a sub-point of 'trust')
I was pondering a means of doing electronic voting at normal voting locations. If system crashes / HD crashes are a concern, why not just keep real-time backups? Local backups could be via RAID or a locally networked backup system. A receipt could be given to indicate the vote was recorded *and* backed up. Once you go this far, why not have a networked centralized system to do live collection and reporting?
If the link to the central server is lost, queue the data for later uploading. The only problem with this is if you want to give a voting receipt to confirm the cast vote was received by the central server. Maybe if data are queued for later uploading, allow the voter to confirm that the vote was sent to the central server. Each receipt would be unique, but not tied to a specific voter, so anonymity isn't an issue.
And once you go that far... make the entire election database available for download. Then we each can perform our own re-count.
Once we move to an electronic voting system, can't the choice of anonymity be left up to the voter?
When a vote is cast, the voter would get two receipts. The first receipt would confirm that his/her vote has been recorded locally, backed up, and received by the central site. The other receipt would detail the vote (the vote cast, non-identifying demographic information, etc.)
No database would record any information to tie the two reciepts/records together, so identifying information is independent of the vote.
If voters continue to have trust issues regarding their vote being recorded accurately, the receipts could include hashes/keys that allow online databases to be queried. The identifying ticket's hash would be unique. This allows one to verify that their vote was received. A series of these hashes over the years could also be used to show a voting history (that votes were cast, not the votes' contents). The second ticket would include a hash that indicates the vote's contents and non-identifying demographic data. This would allow one to verify the contents of the vote online.
The only concern with anonymity is if the voter chooses to release both receipts together. If the vote contents are up for blackmail, then maybe only the first receipt would be issued and not the second. Is blackmail really a realistic concern?
The upside of the second voting receipt is that it would allow a person to verify that their vote has been accurately recorded on the central server and that the system isn't corrupt (at least that one part).
Slashdot Mirror
I submitted this as a story back on June 4. Since it was rejected (too verbose?), I posted it to my /. journal. My main question to other folks relates to how this
would compare to using a regular ramdisk. The main deficiency with a
ramdisk is that you'd have to reload the contents every time you reboot.
Here's my article, with all its links:
Giga-byte Technology recently came out with a DRAM-based PC card that operates as a SATA hard drive. The product, iRAM, uses power from the motherboard to keep memory active when the system is shut down. During power outages, the product uses a on-board battery to retain memory for up to 90 minutes. The iRAM card is being talked about in the news (InfoWorld, itWorldCanada, engadget, PCWorld, multiplay forum) as a means of booting Windows faster. That is, you install Windows onto the iRAM drive to take advantage of the RAM's faster read-access time. Just hope that you don't lose power for more than 90 minutes.
Is boot time really that important, since many computers are on all the time? A ramdisk might have better uses, perhaps for caching frequently-accessed files such as databases and webservers. Or, if you insist on having faster bootup, instead of putting Windows on the iRAM disk, why not just store the hibernation file there?
I implemented a RAM-based database for an internet tool in 1998 to alleviate the read/write load on my local hard drive. It turned out to be a simple solution for the problem. At the time, it was just a matter of using a DOS-based ramdisk driver (ramdisk.sys). On application startup, it copied the database files to the ramdisk. During operation, everything was read/written to the ramdisk, and periodic backups were made to the physical disk. There are some inherent risks, such as loss of data during a crash since data isn't immediately written to a physical hard drive, so it may not be a great solution for a mission-critical production database. The iRAM product would make this type of database even more stable, in that the risk of loss of data is much less.
That was a while ago, so I thought I'd look into setting up a ramdisk in XP for some amusement. Follows are the results of that search. It seems that the options are relatively sparse beyond the DOS-based driver. A few freeware and commercial packages are available, though. One key factor beyond price is the size limit of ramdisk.
Microsoft's ramdisk offerings since Win2k are limited. Included with the XP OS is a ramdisk sample driver that "provides an example of a minimal driver. Neither the driver nor the sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeletal version of a driver." Installation isn't simple enough for most users to benefit.
Alternatives include a shareware ramdisk, AR ramdisk (archive link: http://web.archive.org/web/20041011170408/http:/ww w.arsoft-online.de/products/product.php?id=1) (freeware, 2GB limit, discontinued, available for download here), a freeware (64MB limit) and shareware (2GB limit) version here,
My interpretation of the definitions indicates that "To" would be an example of kerning, not ligature.
From morrcom.com, "Kerning refers to improving the appearance of type by adjusting the spacing between selected pairs of letters. The most problematic pairs of letters are AV, AY, FA, AW, PA, and AT. Kerning becomes of greater importance as type size increases such as in headlines and poster copy which uses all caps."
From Webster, a ligature is a "printed or written character (as æ or [ff]) consisting of two or more letters or characters joined together."
What I want is my Aibo controlled by a real brain, even if it is only a cockroach brain (see also, ./).
Imagine, a robot that can think for itself! You could make a whole herd of
them for your own insect/Aibo colony. As the technology progresses, you
can move up to reptiles (gecko, iguana, etc) and finally into mammals (mice,
rats, cats, dogs, monkeys, hobos). Soon enough, you'll be able to get your
own Hobo Aibo.
Even in the beginning, this has a lot of potential. If we can wire up a cockroach into an Aibo, it might be our next congressbug. Who knows, maybe it could even be our next president. Unfortunately, it probably won't get elected, since it likely can't lie, scheme, cheat, take bribes, and deceive as well as the real thing.
On first blush, this seems like a "look at me!" article. But I think the author does bring up some good points on methodologies used in fighting spam on a large scale. However, one thing that isn't emphasized is how little deliverable email he gets. It looks like it averages 5-10 messages per hour.
So the next question is, how would his techniques scale to a domain that processes 3.5 million emails per day and rejects 0.25-3.0 million spam emails per day. Plus, to reduce the risk of false positives, much of the spam is actually delivered to users. All delivered email has a spam score added to the email headers for the individual user to decide their threshold for filtering.
For those of you out there who are IT for domains that handle millions of emails per day, how do you handle spam? How many servers and how much bandwidth does it require?
If you're curious, I get 100 emails per day delivered and 78.2% of that is spam. Unfortunately, I've found that I can't rely on the spam score added to the headers by the aforementioned domain. My filter (k9, Bayesian) currently has a false negative rate of 0.49% and false positive rate of 0.00%. Yeah, that means I see a single piece of spam every two days on average. In reality, I'll usually get a surge of spam where on a single day I might get two or three pieces of spam, followed by a week of nothing once the filter has adapted.
For protection on the net, especially for usenet and web forms, I use disposable email addresses (ie: spamgourmet, mailinator).
You're mistaken.
If the case goes her way and she's awarded $3 million, she'll get $100k. The remaining $2.9 million is for the attorneys.
And then she and her ex-boyfriend will each get $2 million book deals and appearances on Oprah and Letterman.
Thanks for the link. It's an interesting idea. I doubt it will catch on or replace ASL any time soon, though.
Signaling 4 (or worse, 132) to someone might cause problems.
And a slight correction to your post... you could only count up to 1023, not 1024.
It might be more interesting to exclude the thumbs. Then you could signal a byte of information at a time.
In any case, it's not very practical for general use. It could potentially find a niche in certain areas.
I submitted this same story with a lot more detail (but not the InformationWeek link) 28 hours prior to the timestamp on this story. It was rejected. Sure, mod me off-topic if you think I'm whining.
I posted my write-up in my journal for posterity's sake. Replies are welcome on this post in regards to the actual news story. Comments as to why you think the submission was rejected should only be posted in the journal. (You don't want to be off-topic, right?) Did I submit at the wrong time of day? Was the submission too long? Ok... enough whining.
I won't make you do unnecessary clicking, so here are some of the relevant links that I found:
Penn State's own news article
Chronicle of Higher Education article
ZDnet article
The journal entry also has comments taken from a PSU IT personnel listserv, as well as other links.
What's to keep someone from buying five copies of XP Pro from an overseas vendor for $5-10 a piece and then getting legitimate licenses from MS via this offer?
Is MS planning on affecting offshore folks? It seems that their legal reach is limited to select countries.
I had an idea to do this about a year ago. Alright... I didn't build it yet (let alone patent it!), so I guess I really can't complain.
;)
I thought it would be better to automate the process a little more. Set up each blind with an auto-targeting rifle using machine vision for target identification and tracking. It would be feasible using off-the-shelf components. One could go so far as having a system that even automatically compensates for range, air density, and wind, and targeting appropriate kill-zones on the animal.
I considered the risk of erroneous identification. At this time, I felt the best way to handle this is via photo/video confirmation via cell or network. That way the kill shot would have to be confirmed by a human. It would be limiting if the dial-up/login/confimation takes too long, though.
Another advantage would be to have multiple hides with autonomous systems. It would be especially useful running multiple hides simultaneously from one managing remote console. In fact, in this case they wouldn't even have to be automated, just remote controlled. My preference would still be having automated sighting, identification, and tracking. Then it's just pulling the trigger (or clicking the mouse) over a secure (or closed-loop) connection.
Would laws pertaining to hunting from vehicles pertain to this scenario? It seems the intent of that law might prohibit automated systems.
Obviously each component of the system would have to be thoroughly tested in many unloaded scenarios.
It would probably be a lot more practical (and with considerably less legal concern) to do all this with cameras only. The ideal situation would be a wide-view camera for motion detection and targeting. A high-quality high-zoom camera would be the "rifle" camera. It could be set to take video, sequenced frames with a delay, or single shot, depending on preference. This sort of setup could acquire very high quality photographs of wildlife without much effort. No remote console/control would be necessary.
It could be made less expensive by only using one camera with variable zoom, using it as both the spotting scope and the capture camera. Another cost-cutting measure would be to drop the bulk of the image recognition for identifying the animal. It could be simplified to look for motion and apparent size to find objects of interest and capture those. Human or automated post-processing could decide the value of the image/video.
Upon doing a web search, I found that there are lots of camera traps/hides/blinds. But most are tripwire-triggered (IR beam gate or IR motion). None I found incorporate image motion detection, image recognition, and automatic camera pan/tilt/zoom.
So how much should I charge when I start selling these?
Regarding the short time for SEARCH and large GET requests...
Most likely it has *nothing* to do with script kiddies. You're just seeing others on your ISP infected with worms. While it is possible that it's someone manually looking for a vulnerability, it's a lot more likely to be a worm.
This same misunderstanding is often used by firewall manufacturers, whose products scream "look at all these probes I blocked!" The users think their investment is well worth it, even though a properly patched system wouldn't be affected. Of course a new worm/vulnerability can affect systems before a patch is available, but it can also affect systems before firewall/AV updates are available as well.
You're just seeing your Apache logs fill up with these unusual requests. If you are running the latest version (and run AV, firewall, etc. to reasonably secure your system), they are more of an annoyance than anything else.
And you thought it was bad when your pet got worms. Now it's your much-beloved computer at risk.
I think your idea has some merit.
It seems that some of the basic needs for a voting system are:
I was pondering a means of doing electronic voting at normal voting locations. If system crashes / HD crashes are a concern, why not just keep real-time backups? Local backups could be via RAID or a locally networked backup system. A receipt could be given to indicate the vote was recorded *and* backed up. Once you go this far, why not have a networked centralized system to do live collection and reporting?
If the link to the central server is lost, queue the data for later uploading. The only problem with this is if you want to give a voting receipt to confirm the cast vote was received by the central server. Maybe if data are queued for later uploading, allow the voter to confirm that the vote was sent to the central server. Each receipt would be unique, but not tied to a specific voter, so anonymity isn't an issue.
And once you go that far... make the entire election database available for download. Then we each can perform our own re-count.
Once we move to an electronic voting system, can't the choice of anonymity be left up to the voter?
When a vote is cast, the voter would get two receipts. The first receipt would confirm that his/her vote has been recorded locally, backed up, and received by the central site. The other receipt would detail the vote (the vote cast, non-identifying demographic information, etc.)
No database would record any information to tie the two reciepts/records together, so identifying information is independent of the vote.
If voters continue to have trust issues regarding their vote being recorded accurately, the receipts could include hashes/keys that allow online databases to be queried. The identifying ticket's hash would be unique. This allows one to verify that their vote was received. A series of these hashes over the years could also be used to show a voting history (that votes were cast, not the votes' contents). The second ticket would include a hash that indicates the vote's contents and non-identifying demographic data. This would allow one to verify the contents of the vote online.
The only concern with anonymity is if the voter chooses to release both receipts together. If the vote contents are up for blackmail, then maybe only the first receipt would be issued and not the second. Is blackmail really a realistic concern?
The upside of the second voting receipt is that it would allow a person to verify that their vote has been accurately recorded on the central server and that the system isn't corrupt (at least that one part).