If you keep the salt secret, the client is required to send a plaintext password to the server to have it hashed. If the salt is public (sent to the client), the client can do the hashing locally and avoid ever sending the plaintext password to the server (which might be compromized). So my guess for a fairly secure login/authentication scheme (IANACE):

client: Hi I'm foo@bar, give me a nonce and my salt.
server: Here is you nonce with a salt.
client: sents hash(hash(secret+salt)+nonce)
server: compares hash(hash(secret+salt)+nonce)==hash(DB[user][passwd]+nonce)

It keeps the password secret even from the server, the nonce prevents replay attacks. Login could even be done over an unencrypted connection. Could be wrapped with another nonce to prevent sending foo@bar as plaintext.

The weakest point is sending the newly created saltedhash to the server at account creation as the saltedhash is essentially the password. Add a little PKI to increase safety.

You simply have the legislature more than the lobbiest are paying to get the content blocked.

"Is the link you providing link to a metalic look wedge shaped object? Are the feet the same sizes? are the ratios the same? Does the lid and base tapper the same way?"

So change 1 thing and the patent doesn't apply, what is stopping other manifacturers from chaning the angle by a tenth of a degree or putting the feet a fraction to the edge to avoid infringing the patent. Are you telling me the design patent only applies to the _exact_ _same_ design.

Take a look at the patent, only the solid grey lines are important. That means only the bottom of the device and the lid are covert by the design patent. The ac-100 has the same lid design IMHO, the edge of the ac-100 is a but thicker/less sharp.

Take the look at the filing date: Oct 2010. So prior art for a wedge design.

Toshiba AC-100 Android netbook:
http://uk.computers.toshiba-europe.com/innovation/jsp/SUPPORTSECTION/discontinuedProductPage.do?service=UK&PRODUCT_ID=1091301

Physical dimensions W x D x H : 262.0 x 189.8 x 14.0 (front) / 21.0 (rear) mm
weight : starting at 0.87 kg

Release date: aug 2010

"Hmmmm, reminds me of the phrase, "Just recompile the kernel". Hey hairyfeet, is this starting to remind you of something?"

So writing a script to do some text transformation equals to recompiling a kernel! It's about creating small tools to make your live/work easier, you are a strange sort of contractor if you are not willing to mold stuff to your needs (unless your clients are paying by the hour).

But whatever you think or experience as a problem, get used to it and adapt since ipv4 will run out of space eventually. Stick to the ipv4-in-ipv6 for internal use and just learn the new tricks for connecting to the outside world.

"Thank you. Now imagine its 3AM, you haven't had ANY coffee yet, and they are screaming at you that parts of the network aren't working. Quick, could you look at a whole pile of IPV6 numbers in a list and spot which ones don't conform? Bet most can't because our brains just don't process hexadecimal nearly as well as it does numbers. But if they gave you that same list in IPV4 octets you'd spot the 194. numbers in less than 3 seconds."

You do know you don't have to use "random" ipv6 addresses? Use usefull patterns/prefixes if you are afraid you'll miss the tree your are looking for in your forest. Or write a script to convert hex to octets if that helps you. But be sure to use a fixed font, that helps a lot with hex.

"What planet do you live on where you can read hex as fluently as numbers?"

Earth, hex is numbers + 6 extra letters [a-f]. Reading them takes less knowledge then reading this message (contains even more different characters). For example the first 3 parts of my ipv6 address:
two zero zero one colon six one zero colon seven dee three (2001:610:7d3)
It's not like I'm converting them to decimal or something. What you see is what you get.

But please explain why reading them would be harder compared to ipv4 octets? What are you trying to do that makes your head hurt reading them? The only "hard thing" about ipv6 addresses is converting one to it's reverse ipv6.arpa counterpart, but there is app for that (host).

"But they should have made IPV6 backwards compatible and just used numbers instead of hex. We humans just don't think in hex"

Q: So what is your ipv6 adress
A: what format would you like:
decimal: 11579208 92373161 95423570 98500868 79078532 69984665 64056403 94575840 07913129 639936
(added some spaces to pass the lame filter)
hex: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
octets: 255.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255

You don't have to think that much about ipv6 addresses, netmask got a bit simpeler. And the hex notation are small grouped numbers just like you propose.

So what else about religions shouldn't be taken literaly?

You are missing the point, the cellphone (without voice remember) is a SIP client to his PBX over either wifi (at home) or 3G (outside). It will ring at the same time other extensions in the house are ringing (if so configured).

4k should be enough to contain most information a paramedic might need (alergies, medication), esp. if that info is app generated (shortcodes, compression). There is absolutly no need to upload al this to an external party to have it downloaded again in an emergency, in effect adding a couple points of failure.

Just put the info in to QR.

Define malware.

From an Apple point of view apps with hidden features are malware, esp. if those features are locked down in iOS on telco request:
http://www.wired.com/gadgetlab/2010/07/apple-approves-pulls-flashlight-app-with-hidden-tethering-mode/

So here you have a piece of software posing as A but having hidden feature B. Somehow the reviewer missed a flashlight app creating a server socket to receive connections, something a piece of malware might do (though opening a connection to a botnet is easier and less conspicuous) and a flashlight app has no purpose for. That really makes me doubt how Apple certifies apps, surely they can get an overview of all API calls of an application!

But since this app was not really evil and was removed after the real purpose got known I guess you will just ignore this example (and it happened so long ago ofcourse, this problem has been fixed by Apple for sure).

I'm guessing ofcourse, but in my favour are:
-it's either propietary satnav from the car manufacturer build into the dashboard
-it's an easy to spot standalone GPS device in the middle of the windscreen (blocking lots of the viewport (IMHO))

I rarely noticed people using phones, they might be positioned somewhere I can't see them though. BTW I'm always on my bike (BMW 1200GS) riding in the middle of my lane, I have a good view into cars.