The company I work for has a 5000 sq meter manufacturing facility packed full of robots - and only 5 engineers and 10 technicians. The manufacturing, assembly, packing and shipping are all automated. Even the maintenance is mostly automated.
IMHO, what we need is to establish standards of respect for this kind of personal data, where it's not socially acceptable to share potentially sensitive information about someone without their knowledge and consent.
Once upon a time, parents did teach their children this kind of respect. Over time, fewer parents did so. Mine (and my GF's) parents were probably amoung the last. Sadly, my GF and I are not able to give our daughter anywhere near the amount of privacy as our parents did. Not because we don't want to give her that level of privacy, but because the social climate demands that parents watch their children a lot more closely than prior generations of parents. We watch her get on the school bus in the morning (it stops close to our house and there is a public webcam at the stop, as well as a public webcam in the school bus) and watch her get off and walk home each day. When she visits a neighboring friend, we (and the friend's parents) are watching her go and return from the friend's house. Any further than that, one of us takes her to her destination, then gets her, later. And one of us goes with here when she goes bicycling. Within our house, all tools are in either workshop or the kitchen. When she's working on a project, one of us is watching as well as helping with the potentialy dangerous tools.
This is not what we think we should be doing. It was what society demands of us.
In contrast, I was allowed to play outside, roaming all over the neighborhood unsupervised. The only restrictions were that I either be able to hear my parents's bell and return home within 15min, or be where my parents had a phone number to call - and call them to let them know I was there. If I wanted to go beyond the neighborhood, I only had to ask and say how to contact me and about how long I expected to be away. The answer was usually "yes" and I could ride my bike to almost anywhere in town.
And I know I had almost no supervision as I roamed the neighborhood. There were many wooded areas when my friends and I could gather out of sight and out of hearing - something that would scare nearly all today's parents shitless.
As for tools, once I demonstrated I could handle a tool safely, I was allowed to use it - even tools my parents were not skilled enough to safely use. Forexample, when I was a Cub Scout, I built all my Pinewood Derby cars myself - no help from anyone and almost no supervision.
Well said. To expand on that a little, if someone's trying to crack your account then they can probably afford to have a human involved who will have a somewhat reasonable chance of getting your clues correct.
I recall reading, a few years ago, that some were using pr0n sites as a way to have humans answers CAPCHAs. They rigged their pr0n sites to "proxy" the CAPCHAs from the target websites. Once a human successfully answered a CAPCHA, a bot could then get into the target site while the human continued to browse the pr0n site.
It might actually be worse, since the scheme describes providing a list of descriptions to choose from, one of which is the one that the user originally provided when the inkblot was generated.
It is worse. The bot can just "choose" randomly. If the list is new each time. the correct answer will be the one item that is always in the list. If the items are the same each time, it will eventually get the right answer.
True, limiting the number of guesses at a given time will slow the bots down, but they can do a single to each account in a list long enough to provide enough delay between attempts with out having to idle between attempts.
I keep hearing how great Kentucky's ACA website is. Has anyone looked into getting whoever did that to find out what it would take to configure/adapt it to work for other states?
Assuming that's possible, make a website for each state the fed gov is handling and make healthcare.gov a redirecter to the state specific sites.
I just tested my PC's speakers / microphone... The power output is rock steady up to 15kHz, then falls to 75% by 20kHz, 50% by 30kHz, and about 10% by 40kHz. Then it stays that way to fiftish kHz, which is as far as my loop went.
How did you test it?
The typical PC sound card as a DAC frequency of 44.1kHz, so the frequency of the carrier tone would have to be less than 22kHz - probably around 15kHz - to reliably transmit data.
I'm not up on my Audio Engineering, so excuse me if this question is recockulous, but since mic / speakers basically work on the same principles, is there any chance that its theoretically possible they are transmitting ultrasonic with the mic and receiving on the speakers!?
No. The input and output circuit amplifiers are arranged to only allow signal flow in one direction.
FYI, amplifiers can be arranged to allow 2 way signal flow (aka "full duplex") over a 2 wire connection. An example is a basic, landline telephone. You can demo this with 2 basic, landline phones, 2 phone jacks and a 9V battery. Connect the red wire from one jack to the red wire from the other, then both to + on the battery. Likewise, the green wires to - on the battery. Then with an assistant, each of you pick up one of the 2 handsets. You will be able to talk and hear each other over the 2 wire connection between the phones.
Over simplified diagram: http://pastebin.com/hQN58jDd - Download and save with the extension ".svg" then open file with Firefox, Chrome or Opera to view it.
Is it fair to say that another shortcoming of PGP/GPG is that it encrypts the message body only, leaving the envelope in the clear?
That is actually a short coming of the network itself. In theory, every smart phone or tablet could run its own email server to receive incoming email, so elide the need for the envelope. Still, the network will know which device connected to which other device. Even wireless mesh networks have to exchange routing information between nodes. Even if manufacturers did not include logging source/destination addresses in their devices, it would only take a few "compromised" devices to gather and forward the meta data.
Many protocols used over Internet were not designed with encryption because it didn't seem that important at the time.
Contrary to popular belief, "designing in security" does not mean every protocol has encryption built-in. It does mean that when designing an implementation of a protocol, security is properly factored in. And, in a system, that encryption is used in the appropriate places.
Most protocols on the Internet are application level protocols. Some applications would benefit from application level encryption because this reduces (not eliminates) risk of exposing unencrypted data. For most applications it's more efficient to implement a common encryption service then have the applications use that. That also has the advantage of enabling including encrypting the (final) endpoint identification (and other application identification) by implementing the encryption between the Transport and Network layers. Applications with their own encryption would also benefit from this.
Even with application level encryption, many (maybe most) of the existing protocols are useful. Example: A subset of SMTP could be used in delivering email. The email client application would establish a secure connection to the destination email server then send the actual message(s) using SMTP. Both the client-server connection and the messages would be encrypted. The server needs some meta data to deliver the messages to the mailboxes, but the meta data would otherwise be encrypted on-the-net. The messages would be decrypted by the email client to display to the user. (Even if you used direct IM, the Transport layer meta data would still exist, so you only get a little extra protection from direct IM - but IM is only possible when both parties are online.)
There is also value in implementing encryption just below the Network layer as this will encrypt the routing information as well. Still end-to-end at either the Transport layer or in the application (or, both) is vitally important.
(For those not familiar, the Network layer is responsible for moving data packets around the network, ultimately delivering data to the destination host. The Transport layer is responsible for end-to-end communications and represents the host. The host is the collection of applications running in a machine (physical or virtual) that use the Transport layer to communicate with applications running in other hosts. The "final" endpoint is what TCP, UDP and several other transport protocols call the "port" (example: port 80 for HTTP/HTTPS servers))
There's a fun case in ARM's compiler, where you write something like this:
for (int i=0 ; i<10 ; i++)
y += x[i];
That looks a common error hidden by undefined behavior: The array size and loop bound are coded with "hard constants". The problem arises when the programmer changes some, but not all, of the constants, so there is a mismatch. Better to use symbolic constants. Then you only need to change the definition of the constant. Also, the symbol can be given a descriptive name.
* Fixation of two's complement as the integer format.
* For signed integers, shifting left a 1 bit out of the most-significant bit gets shifted into the sign bit.
In two's complement format, this already happens. Example (using int8_t for simplicity):
(int8_t)64 << 1 == (int8_t)-128
FWIW, everywhere I have worked, using shift operations on signed or non-integer values is not allowed. Furthermore, we don't allow shifts as shortcuts for arithmetic purposes - if you mean to divide by 64, then write x/64, not x>>6. Shifts are for aligning bits, not arithmetic.
I think shifts (and bitwise) operations on signed or non-integer values should be Implementation Defined - and highly discouraged.
Ardour is not lacking, rather the issue is the rest of the stack is more trouble than it's worth. For a serious studio a Protools licence is not a big deal. And very few people build from scratch on a GNU platform - mostly because most people are starting out as teenagers with no interest or exposure to FOSS.
Harrison Consoles's Mixbus is another commercial product that is supported on Linux. Couriously, AVLinux has a demo version included despite Harrison's claim to not provide demo versions. I guess their website is out of date. I have not tried it because I don't want to risk liking it (I cannot justify paying even Harrison's reasonable price - I've already spent too much on hardware).
AV Linux (http://www.bandshed.net/AVLinux.html)
Has Ardour, LMMS, JACK and many other multimedia tools configured to work together. Can run either as live DVD or install to your harddisk.
Having had to euthanise some of my pets, I can tell you that vets generally use an overdose of an anesthetic. Larger animals require more and take longer to die, but will die when given enough. The use of a poison is generally to stop the heart sooner than would otherwise happen. In that case, the subject then dies of oxygen deprivation - aka, suffocation.
An anesthesiologist points out that these procedures need to be foolproof enough for guards with nothing more than a high school education to do. If someone is dosed with anesthetic, pretty much any way of killing them is going to probably be painless, and meets at least some people's definition of humane. And the poison is presumably well tested and super effective.
The TFA also states that the anesthetic is part of the problem. The implication being, ultimately, that if the US continues to use any anesthetic to put subjects to death, the supply of all of these advanced anesthetics could be cut off.
Even in the face of that possibility, I don't see the US putting an end to the death sentence any time in the next 50 years or os. Therefore, an alternative is needed.
As for simplicity, the most basic heart monitor (3 connections: one to each wrist and one to either ankle - could make the elctrodes part of the straps) is super easy to use and more than good enough to make sure the subject is dead. Then keep the nitrogen flowing and the room closed for another 5 or 10 min after "flat line".
As for the subject ppossibly panicing, don't tell him when you open the nitorgen valve. Just let him keep talking. Maybe even ask him questions to keep him talking.