A good way to do this (which the above guys might be using) is to translucently log critical information, much like the techniques in the Translucent Databases book. In this case, information like the client IP address can be md5 hashed before being logged. In this way, if you need to investigate a particular IP address because of a court order or an attack, you can md5 the neccesary address and know what to search for. And if you're just analyzing patterns in your logfiles, the md5's will still uniquely identify client IPs so that you can see the real flow of events. You can also store the logs a while and not have privacy concerns. The md5'd addresses prevent the logs from being used as a wholesale database of private information, since you'd have to reverse md5 (computationally infeasible) seperately for every customer IP to get the original data back.
Of course I'll play devil's advocate to myself here. There's only 2^32 IP addresses (less than that because of private space and whatnot, but it's good to overestimate anyways), and each takes 4 bytes to store. If you stored the full md5 hashes with offsets as IPs, you'd be looking at a 64GB fool-proof solution. 64G of disk space in a database is not a hefty requirement by any means. Pre-computing 4 billion md5 hashes of 4 byte strings and writing them all to disk would take some time, but not an excessive amount. If I had the free space at home I could probably build this pre-cache of IP md5's in a few weeks tops. So the government could definitely do it.
A potential stop to this sort of precaching would be to mix in more data before hashing. For instance, store the current datestamp down to 1-hour resolution into the hash as well as the IP. You'll then need to know the horu you're looking for to index a specific IP address, and they'd have to do all the same computation and storage once per hour forever to keep the ability to index your hashes back to IPs. While you're at it, each site could also through their own primary IP address into the hash, so that several sites using this same scheme would have to be indexed seperately by the government. Toss in a random tidbit that nobody knows, like the programmer's dog's name or something, and you're set.
Almost any non-biometric system won't match your criteria. And of course, biometric is going to be too expensive for the most part.
You might consider (if you have a cheap PC laying around or one that can dual-purpose for this) using one of the cheap thumbprint scanners available for PCs. You'd just have to rig a little custom code and you could make it so that a valid thumbprint raises a signal on a parallel port. From there it would be easy to make a small relay control box to unlock a magnetic latch.
In windows these things are used for windows login. I don't know if any come with an SDK you could use for this. On linux the only hard part would be making sure you have a driver to understand the scanner, the rest would be cake to integrate.
Opera's page linked in your comment is exactly what I was talking about. Every browser needs to have that data documented in a roughly similar fashion. Preferably like in the Help documentation for the browser somewhere. Getting a browser and not knowing what standards it conforms to and how is like getting a car with no idea what type of fuel runs in it well or where the gas cap is.
IMHO, the browser vendors should be at the very least *documenting* their level of standards compliance. It's bad enough that none of them are actually complying fully with the standards, but docs would go a long way. I would want something of this kind of form:
BrowserX, V4.3:
Complies mostly to XHTML 1.0 Strict / Frameset *
Does not comply to XHTML 1.1
Complies mostly to CSS2 **
Complies to DOM Level 1
Does not comply to DOM Level 2....
* - Exceptions: Does not correctly implement img element alt property.
** - Exceptions: Does not render hover link colors correctly. Ignores paragraph font sizes.
If every browser vendor would publish a definite conformance guide like that with their releases and patches, the web would be a better place.
I wonder - has anyone ever put serious research money into sonic boom cancellation? Surely one way or another, human ingenuity can overcome the sonic boom created by a supersonic jet. I could imagine some crazy solution might end up working, like vibrating the air-bearing surfaces of the plane at some frequency, to disrupt and reduce the boom, or something else similar.
The accepted non-lunatic-ufo-watcher explanation of Area 51 is that it's an Air Force testing grounds for top secret new aircraft - the next generations of things like the SR-71. I believe slashdot had some coverage not that long ago about the unveiling (finally) of the Aurora test craft, which matches many of the "spacecraft" description from Area 51 watchers. Aurora is nifty, but it's clearly not alien inspired, just human engineered.
I thought that most commercial airliners were already just under the speed of sound, whereas the Concorde was between mach 1 and 2. I seem to remember mach 1 being somewhere around 600mph, and airliners I've flown on for years are cruising in the 500's. What was so special about this anyways?
DHCP "security" by only giving addresses to known mac addresses doesn't buy you anything. Anyone can still plug in and grab an address statically anyways. The only way to enforce this would be a manual static arp table in every machine (including the router) and disable true arp, and at that point you may as well stop using DHCP too. Even then you still have to take other measures to make it really work.
Just run plain old wide-open DHCP, and implement network policy where it belongs - at the L3 devices like firewalls, L3 switches, routers - and in user AAA, be it windows domain logon, LDAP, or what have you.
Yes but what's bad about the comment is that he uses the GNC-world's pseudo-scientific terms as if they mean something. People with brain cells know that ExoIsoLimboHydroCalifragilisticexpialodociousness doesn't mean jack. The companies that market over the counter drugs to athletes and body builders prey on the fact that many of their are scientifically illiterate (other than what they learned from these drug companies, and from freinds and coaches who learned it from the same, ad infinitum). They hype up pseudo-scientific words and descriptions - and 99% of the time a scientist can show that the claims don't mean jack, or at least mean nothing at all similar to what people usually take them to mean.
You could also say of course unix talk + finger + who, but those are seperate tools. IRC is an integrated chat client/server system that does everything they've patented about IM.
1) Backup the drives manually just in case (copy the raw drive data off to tape after booting from CD or floppy).
2) Go into the hardware raid setup and set the array up exactl as before, but dont let it initialize. If your hardware raid controller always initializes new divces by writing over them with zeros or something, this might be undoable or tricky. If you end up initializing, it's not that big a deal.
3) If you did it without initializing, you're probably good to go. If you ahd to initialize in order to configure the array, now boto off of CD again and restore the raw drive images from tape.
Your browser will probably go back to normal if look for and disable any features called "auto search", or "smart [browsing/urls/etc]". As a side note, one of the really annoying things about Netscape on Unix (at least the old 4.x versions), is that they actually read/etc/resolv.conf themselves, and query DNS servers themselves, instead of using the system's resolver library. You resolver might very well be configured to use some other source first, such as NIS+, but Netscape will have none of it.
After all, you download the game free of their site and can play for free - you just can't do all that much in the wolr dwithout dropping some cash in (have to buy a gun to hunt, or mining tools to mine, etc). But for free you can at least run around the world and see how things work and how well refined their technology is.
I've played it in "commercial open trial" for a while now off and on, and I've been quite un-impressed. Unless they make some serious balancing improvements in the economy, and overcome some serious technical difficulties they're having, it's gonna flop.
One their biggest design flaws, IMHO, is their attempt to make the client's view of the world simultaneously seamless (no zoning), lagless (client to server), and cheatproof. They've put a priority on cheatproof, as they should with real money involved. A cheatproof client means that you can't send the client any data ahead of time. In Everquest, for example, the client software is told everything in your zone ahead of time, even thigns you can't see yet. Very cheatable, but it improves performance - not as much has to be sent by the server as you walk around. By eliminating pre-caching of cheatable server data, and also going seamless (one huge world instead of broken up "zones" that take a few seconds to move between), the lag is unbearable. Even under good conditions, actions take place seconds after you push a button, mobs pop up in front of you "magically", etc, etc...
Being able to do this sort of "live" data feed between client and server with no predictive pre-caching of cheatable elements really requires the next generation of networking, where every PC in the world is connected to every other by extreme bandwidth with extremely low latency. On the modern net the latency is just too much to have such intimate real-time conversations over such long distances reliably.
Actually, the subject is highly debateable. I seem to remember there being a certain amount of finality in some interviews of the film crew (cast, director, etc..) at one point that led me to believe it went something like this (really rough, I don't remember the details):
SomeImportantGuy1 thought that Deckard shouldn't be a replicant, and so nothign specific was put in the movie that directly tells you he is.
SomeOtherGuysFromtheMovie thought he should be a replicant, and tried to sway the movie that way but failed.
InTheEnd they decided to leave it ambiguous and not clearly define it one way or the other.
Then much later, years and years later, one of the crew said he was supposed to be a replicant in an Interview. Then some of the rest of the crew set the strory straight that this wasn't neccesarily the truth at all... etc... etc...
Which version of Deckard you choose to believe in is really up to you, or perhaps up to which of the competing creative visions you think had more authority. I left out the names and positions of the people because I know I'd remember them wrong.
Once you devise a test system, someone can write non-AI software that can fake it and pretend to be human by knowing what it needs to for the test. Only a real human can tell human and machine intelligence apart, not a systematic test. That's why Bladerunners had to manually test the androids, instead of just letting a machine do it. Real-time human insight is key to testing machine intelligence.
The "right" way to make your data reliable is with mirroring of various sorts. On-site backups are kinda silly except when you're using them operationally because you dont have the disk capacity to do otherwise for infrequently used data. Backing up to removable media should be exclusively for offsite storage.
So get two drives and mirror your data, and you're covered in the case of drive failures. If your worried about a whole machine going up in smoke, maybe do a nightly or hourly rsync to another machine across the room.
If your home data is important enough to need offsiting (usually a home user's "important" data amounts to what could fit on a CDROM, not 220 gigs - the rest is probably multimedia fluff that you can stand to re-encode or download in teh case of a tornado or fire), then consider rsyncing with a freind at night over your DSL or cablemodems in a mutual arrangement. Encrypt the data before syncnig it over if it's sensitive.
If you're a business with large volumes of data that need to be offsite in case of disaster, then the best practice is still tape drives of some sort, and an offsite storage service like Iron Mountain.
Salesman: And here's the new top of the line Gateway, it's so fast you'll be able to browse the web and balance your checkbook in human time, just like you could on a 200Mhz Pentium.
Customer: Why does the mouse lag behind by 2-3 seconds when I move it.
Salesman: Uhhh.. because Gateway is selling the CPU cycles of their demo machines to someone else and Windows is giving the number cruncher more priority than the mouse interrupts.
Customer: Yeah, right - how about this iMac over here, it looks fast.
True true. Probably the answer would be instead measuring the real execution time in your engine, meaure it in number of various operations, and weight them by how expensive those operations are on a typical modern 32 bit processor.
There may be some cases where shellsort is more desirable for the exact data being sorted, I don't really know for sure. The importance of this is that he has used a GA to better the optimization work of humans on shellsort. He has laid the groundwork and circumstantial proof out for others to do the same with other algorithms. Of course he evolved a set of constants more than an algorithm itself.
The next logical place to go with this work, IMHO:
1) Invent a concise fake machine language for sorting algorithms (a convenience to make the rest of this easier). It should have basic instructions used in manipulating and sorting arrays (move, compare, copy, branching, etc...).
2) Write a "sort engine" that takes as input algorithms written in your fake language and uses them to sort things (outputting some performance numbers).
3) Implement every known array sorting algorithm you can find in your little fake machine sort language.
4) Let a GA evolve the whole algorithm by arbitrarily replacing bytes with other valid bytes from your specialized assembler language, starting with all the known sort algs as parents. Let it run until it stabilizes, using a relatively high mutation rate.
Of course, the big problem is that if your language implements any kind of looping construct, or any other way that code can be re-executed (and it will almost have to), then you face a "halting problem" when testing each new child. The pratical workaround is of course to know that any reasonable algorithm must finish the sort in a certain bounded amount of cpu cycles, and terminate any children who take longer.
5) Translate the winning candidate(s) custom machien source back into a generic language like C, and puzzle over exactly why it works so damn well.
Read the whole article, it is different. The difference is that:
1) They're using methanol, which at least some of the current commercial heatpipes don't.
2) They're using some sort of lithography to carve micron-scale curved pathways into the inside of the tubing. These are customized in order to wick the methanol to the correct locations. This allows them to really "shape" the methanol flow for much better efficiency (send 30% methanol to hot spot A and 70% to hot spot B, and release the heat at sink spot C), instead of just having the vapors/liquids roam around as they choose. This is a boon for any heatpipe, but especially if you have an embedded device that might need complex heatpipe routing to/from possibly multiple heat sources and heat sinks.
Troll? Can someone explain to me how two moderators thought this post was a troll? I can't envision it at all, even takign a contrary point of view to my post's opinions.
If anything will begin to leech some of the masses away from the M$ world, it will be these dirt cheap low end non-intel non-ms PCs selling at WalMart. If I were rich right now, I'd dump some money into supporting these companies. They may not have the whole Windowsy-seeming-end-user-linux-setup thing perfect, but they'll get there eventually. Remember that probably 70+ % of home windows users just want to read email and browse the web, and maybe write a document from time to time.
Slashdot Mirror
A good way to do this (which the above guys might be using) is to translucently log critical information, much like the techniques in the Translucent Databases book. In this case, information like the client IP address can be md5 hashed before being logged. In this way, if you need to investigate a particular IP address because of a court order or an attack, you can md5 the neccesary address and know what to search for. And if you're just analyzing patterns in your logfiles, the md5's will still uniquely identify client IPs so that you can see the real flow of events. You can also store the logs a while and not have privacy concerns. The md5'd addresses prevent the logs from being used as a wholesale database of private information, since you'd have to reverse md5 (computationally infeasible) seperately for every customer IP to get the original data back.
Of course I'll play devil's advocate to myself here. There's only 2^32 IP addresses (less than that because of private space and whatnot, but it's good to overestimate anyways), and each takes 4 bytes to store. If you stored the full md5 hashes with offsets as IPs, you'd be looking at a 64GB fool-proof solution. 64G of disk space in a database is not a hefty requirement by any means. Pre-computing 4 billion md5 hashes of 4 byte strings and writing them all to disk would take some time, but not an excessive amount. If I had the free space at home I could probably build this pre-cache of IP md5's in a few weeks tops. So the government could definitely do it.
A potential stop to this sort of precaching would be to mix in more data before hashing. For instance, store the current datestamp down to 1-hour resolution into the hash as well as the IP. You'll then need to know the horu you're looking for to index a specific IP address, and they'd have to do all the same computation and storage once per hour forever to keep the ability to index your hashes back to IPs. While you're at it, each site could also through their own primary IP address into the hash, so that several sites using this same scheme would have to be indexed seperately by the government. Toss in a random tidbit that nobody knows, like the programmer's dog's name or something, and you're set.
Almost any non-biometric system won't match your criteria. And of course, biometric is going to be too expensive for the most part.
You might consider (if you have a cheap PC laying around or one that can dual-purpose for this) using one of the cheap thumbprint scanners available for PCs. You'd just have to rig a little custom code and you could make it so that a valid thumbprint raises a signal on a parallel port. From there it would be easy to make a small relay control box to unlock a magnetic latch.
In windows these things are used for windows login. I don't know if any come with an SDK you could use for this. On linux the only hard part would be making sure you have a driver to understand the scanner, the rest would be cake to integrate.
Opera's page linked in your comment is exactly what I was talking about. Every browser needs to have that data documented in a roughly similar fashion. Preferably like in the Help documentation for the browser somewhere. Getting a browser and not knowing what standards it conforms to and how is like getting a car with no idea what type of fuel runs in it well or where the gas cap is.
That had nothing to do with NT, that was just plain poor security on the unix admins' part.
IMHO, the browser vendors should be at the very least *documenting* their level of standards compliance. It's bad enough that none of them are actually complying fully with the standards, but docs would go a long way. I would want something of this kind of form:
BrowserX, V4.3:
Complies mostly to XHTML 1.0 Strict / Frameset *
Does not comply to XHTML 1.1
Complies mostly to CSS2 **
Complies to DOM Level 1
Does not comply to DOM Level 2
* - Exceptions: Does not correctly implement img element alt property.
** - Exceptions: Does not render hover link colors correctly. Ignores paragraph font sizes.
If every browser vendor would publish a definite conformance guide like that with their releases and patches, the web would be a better place.
I wonder - has anyone ever put serious research money into sonic boom cancellation? Surely one way or another, human ingenuity can overcome the sonic boom created by a supersonic jet. I could imagine some crazy solution might end up working, like vibrating the air-bearing surfaces of the plane at some frequency, to disrupt and reduce the boom, or something else similar.
The accepted non-lunatic-ufo-watcher explanation of Area 51 is that it's an Air Force testing grounds for top secret new aircraft - the next generations of things like the SR-71. I believe slashdot had some coverage not that long ago about the unveiling (finally) of the Aurora test craft, which matches many of the "spacecraft" description from Area 51 watchers. Aurora is nifty, but it's clearly not alien inspired, just human engineered.
I thought that most commercial airliners were already just under the speed of sound, whereas the Concorde was between mach 1 and 2. I seem to remember mach 1 being somewhere around 600mph, and airliners I've flown on for years are cruising in the 500's. What was so special about this anyways?
I just got a renewal notice for a domain I have prepaid 5 years into the future
DHCP "security" by only giving addresses to known mac addresses doesn't buy you anything. Anyone can still plug in and grab an address statically anyways. The only way to enforce this would be a manual static arp table in every machine (including the router) and disable true arp, and at that point you may as well stop using DHCP too. Even then you still have to take other measures to make it really work.
Just run plain old wide-open DHCP, and implement network policy where it belongs - at the L3 devices like firewalls, L3 switches, routers - and in user AAA, be it windows domain logon, LDAP, or what have you.
Yes but what's bad about the comment is that he uses the GNC-world's pseudo-scientific terms as if they mean something. People with brain cells know that ExoIsoLimboHydroCalifragilisticexpialodociousness doesn't mean jack. The companies that market over the counter drugs to athletes and body builders prey on the fact that many of their are scientifically illiterate (other than what they learned from these drug companies, and from freinds and coaches who learned it from the same, ad infinitum). They hype up pseudo-scientific words and descriptions - and 99% of the time a scientist can show that the claims don't mean jack, or at least mean nothing at all similar to what people usually take them to mean.
You could also say of course unix talk + finger + who, but those are seperate tools. IRC is an integrated chat client/server system that does everything they've patented about IM.
1) Backup the drives manually just in case (copy the raw drive data off to tape after booting from CD or floppy).
2) Go into the hardware raid setup and set the array up exactl as before, but dont let it initialize. If your hardware raid controller always initializes new divces by writing over them with zeros or something, this might be undoable or tricky. If you end up initializing, it's not that big a deal.
3) If you did it without initializing, you're probably good to go. If you ahd to initialize in order to configure the array, now boto off of CD again and restore the raw drive images from tape.
Done
Your browser will probably go back to normal if look for and disable any features called "auto search", or "smart [browsing/urls/etc]". As a side note, one of the really annoying things about Netscape on Unix (at least the old 4.x versions), is that they actually read
After all, you download the game free of their site and can play for free - you just can't do all that much in the wolr dwithout dropping some cash in (have to buy a gun to hunt, or mining tools to mine, etc). But for free you can at least run around the world and see how things work and how well refined their technology is.
I've played it in "commercial open trial" for a while now off and on, and I've been quite un-impressed. Unless they make some serious balancing improvements in the economy, and overcome some serious technical difficulties they're having, it's gonna flop.
One their biggest design flaws, IMHO, is their attempt to make the client's view of the world simultaneously seamless (no zoning), lagless (client to server), and cheatproof. They've put a priority on cheatproof, as they should with real money involved. A cheatproof client means that you can't send the client any data ahead of time. In Everquest, for example, the client software is told everything in your zone ahead of time, even thigns you can't see yet. Very cheatable, but it improves performance - not as much has to be sent by the server as you walk around. By eliminating pre-caching of cheatable server data, and also going seamless (one huge world instead of broken up "zones" that take a few seconds to move between), the lag is unbearable. Even under good conditions, actions take place seconds after you push a button, mobs pop up in front of you "magically", etc, etc...
Being able to do this sort of "live" data feed between client and server with no predictive pre-caching of cheatable elements really requires the next generation of networking, where every PC in the world is connected to every other by extreme bandwidth with extremely low latency. On the modern net the latency is just too much to have such intimate real-time conversations over such long distances reliably.
Actually, the subject is highly debateable. I seem to remember there being a certain amount of finality in some interviews of the film crew (cast, director, etc..) at one point that led me to believe it went something like this (really rough, I don't remember the details):
SomeImportantGuy1 thought that Deckard shouldn't be a replicant, and so nothign specific was put in the movie that directly tells you he is.
SomeOtherGuysFromtheMovie thought he should be a replicant, and tried to sway the movie that way but failed.
InTheEnd they decided to leave it ambiguous and not clearly define it one way or the other.
Then much later, years and years later, one of the crew said he was supposed to be a replicant in an Interview. Then some of the rest of the crew set the strory straight that this wasn't neccesarily the truth at all... etc... etc...
Which version of Deckard you choose to believe in is really up to you, or perhaps up to which of the competing creative visions you think had more authority. I left out the names and positions of the people because I know I'd remember them wrong.
It's not support for the argument, it's just an example of where a sci-fi author thought the same thing I'm saying.
Once you devise a test system, someone can write non-AI software that can fake it and pretend to be human by knowing what it needs to for the test. Only a real human can tell human and machine intelligence apart, not a systematic test. That's why Bladerunners had to manually test the androids, instead of just letting a machine do it. Real-time human insight is key to testing machine intelligence.
The "right" way to make your data reliable is with mirroring of various sorts. On-site backups are kinda silly except when you're using them operationally because you dont have the disk capacity to do otherwise for infrequently used data. Backing up to removable media should be exclusively for offsite storage.
So get two drives and mirror your data, and you're covered in the case of drive failures. If your worried about a whole machine going up in smoke, maybe do a nightly or hourly rsync to another machine across the room.
If your home data is important enough to need offsiting (usually a home user's "important" data amounts to what could fit on a CDROM, not 220 gigs - the rest is probably multimedia fluff that you can stand to re-encode or download in teh case of a tornado or fire), then consider rsyncing with a freind at night over your DSL or cablemodems in a mutual arrangement. Encrypt the data before syncnig it over if it's sensitive.
If you're a business with large volumes of data that need to be offsite in case of disaster, then the best practice is still tape drives of some sort, and an offsite storage service like Iron Mountain.
Salesman: And here's the new top of the line Gateway, it's so fast you'll be able to browse the web and balance your checkbook in human time, just like you could on a 200Mhz Pentium.
Customer: Why does the mouse lag behind by 2-3 seconds when I move it.
Salesman: Uhhh.. because Gateway is selling the CPU cycles of their demo machines to someone else and Windows is giving the number cruncher more priority than the mouse interrupts.
Customer: Yeah, right - how about this iMac over here, it looks fast.
True true. Probably the answer would be instead measuring the real execution time in your engine, meaure it in number of various operations, and weight them by how expensive those operations are on a typical modern 32 bit processor.
There may be some cases where shellsort is more desirable for the exact data being sorted, I don't really know for sure. The importance of this is that he has used a GA to better the optimization work of humans on shellsort. He has laid the groundwork and circumstantial proof out for others to do the same with other algorithms. Of course he evolved a set of constants more than an algorithm itself.
The next logical place to go with this work, IMHO:
1) Invent a concise fake machine language for sorting algorithms (a convenience to make the rest of this easier). It should have basic instructions used in manipulating and sorting arrays (move, compare, copy, branching, etc...).
2) Write a "sort engine" that takes as input algorithms written in your fake language and uses them to sort things (outputting some performance numbers).
3) Implement every known array sorting algorithm you can find in your little fake machine sort language.
4) Let a GA evolve the whole algorithm by arbitrarily replacing bytes with other valid bytes from your specialized assembler language, starting with all the known sort algs as parents. Let it run until it stabilizes, using a relatively high mutation rate.
Of course, the big problem is that if your language implements any kind of looping construct, or any other way that code can be re-executed (and it will almost have to), then you face a "halting problem" when testing each new child. The pratical workaround is of course to know that any reasonable algorithm must finish the sort in a certain bounded amount of cpu cycles, and terminate any children who take longer.
5) Translate the winning candidate(s) custom machien source back into a generic language like C, and puzzle over exactly why it works so damn well.
Read the whole article, it is different. The difference is that:
1) They're using methanol, which at least some of the current commercial heatpipes don't.
2) They're using some sort of lithography to carve micron-scale curved pathways into the inside of the tubing. These are customized in order to wick the methanol to the correct locations. This allows them to really "shape" the methanol flow for much better efficiency (send 30% methanol to hot spot A and 70% to hot spot B, and release the heat at sink spot C), instead of just having the vapors/liquids roam around as they choose. This is a boon for any heatpipe, but especially if you have an embedded device that might need complex heatpipe routing to/from possibly multiple heat sources and heat sinks.
Troll? Can someone explain to me how two moderators thought this post was a troll? I can't envision it at all, even takign a contrary point of view to my post's opinions.
If anything will begin to leech some of the masses away from the M$ world, it will be these dirt cheap low end non-intel non-ms PCs selling at WalMart. If I were rich right now, I'd dump some money into supporting these companies. They may not have the whole Windowsy-seeming-end-user-linux-setup thing perfect, but they'll get there eventually. Remember that probably 70+ % of home windows users just want to read email and browse the web, and maybe write a document from time to time.