they'll be moving to places with more sensible security policies
I assume you mean places with more sensible security polices and practices, and which are out of reach of foreign national intelligence and law enforcement agencies.
Let us know when you find such a place, but don't bother if it's within ICBM range of America or if it requires more than a month of space travel to get there.
How many 360KB floppies does it take to hold each movie in your collection?
Also, "per second" may introduce rounding errors. "Per fortnight" is the traditional unit of time for things as large as a feature film (or rather, for truckloads/planeloades of the same).
Using multiple beams formed by an array of antennas. No single user gets all that data bandwidth, but the total data bandwidth can be directed in multiple directions, using spatial structure to increase the total data rate with the same radio bandwidth.
This. Very much this.
Even so, a 1:10000 ratio of bandwidth to bit-rate is noteworthy.
I don't see this being practical except in either 1-box-to-many-boxes "point-to-points" situations or in situations where reflection and other characteristics are either very predictable or ascertainable in real-time. The former is uncommon and the latter is hard.
A case of 1-to-many might be in a home or office where a single node is connecting to many fixed-point antennas in an "Internet of things" environment or even to fixed location computers (look ma, no more running wires through the ceiling!).
The NSA program can flash permanently any HDD. FOREVER!!
There are some older drives out there that aren't flashable, at least not over the normal computer/drive connection (look for "service" connections on late-1990s/early-2000s drives).
In light of these revelations, expect vendors to sell (at a premium of course) drives which can't be "flashed" without setting a physical switch/jumper.
When Nighthawk214 wrote that security wasn't hard, he wasn't wrong, but he was incomplete.
Security by itself isn't necessarily hard. If I want to secure data that I won't need to use without 1 business day's notice, I can just take two disks, each with a copy of the data, to my bank and put it in the safe-deposit box. Not hard at all. With a little extra effort I can encrypt each with a one-time pad and put the 4 disks in different banks.
Security with online or near-online usability requirements by a large number of people is harder/more expensive, and the more usability you want (just a few key employees at one physical location? all employees worldwide? customers too?), the harder/more expensive it can get for a given amount of security.
Yes, for some applications the level of security you need and the level of usability you need do make it a hard/expensive problem for that use case. But if you are at that point, you've probably determined that lack of security and/or lack of usability is more expensive or you wouldn't be going down this path.
The big problem I see in industry is people incorrectly assuming that it's cheaper to skimp on security than to pay for it up-front. A smaller problem is people over-doing it on security, spending $BIGBUCKS to prevent and mitigate a disaster when the actual cost of a compromise multiplied by the risk of that compromise is known to be well below $BIGBUCKS - or it would be well known if they bothered to spend a little time analyzing their particular risk environment.
Long before the Internet was more than just a government/university/defense-contractor environment, traffic lights had 2-way communication.
Were they hackable? Yes, to someone with physical access to the communications wires and by the 70s or 80s, maybe to someone who had access to the telephone-company infrastructure. That meant someone in the same metro area as the traffic lights themselves. But they probably were not hackable by someone sitting in his mother's basement or in a terrorist's cave in East Elbonistan.
That's just one example.
My personal pet peeve is companies that allow more than "harmless" remote control of their HVAC over either the Internet or telephone without routing all remote access through a very secure gateway/vpn/whatever. It's not so bad if they allow people to remotely turn on the lights or change the HVAC from "night/energy-saving" mode to "day/occupied" mode, as that just wastes money. But if I can remotely change the temperature to 40F or 100F or remotely shut down the HVAC completely, or remotely turn OFF the lights, that's a bad idea unless strong security is in place. Over the Internet, strong security typically means a VPN or other extremely-hard-to-hack pathway in.
Some things just should never be put "on the Internet."
If you must have remote access, either use a dedicated physical connection (with appropriate anti-tampering/tamper-mitigation measures of course) or tunnel them through a rock-solid VPN, but for goodness sake don't put them "on the Internet."
Yes, companies that run industrial equipment, traffic lights, etc., I'm looking at you too.
legitimate question: what slashdotter still uses the stock OS on a laptop they purchase?
If by "OS" you mean the factory-installed crypto-signed firmware/bootloader/OS stack which can't be changed without keys the end-user doesn't have, then the answer is "probably more than we would like to think."
We can and do use the insecure internet to securely transmit information.
All to often we do it wrong though. Doing it wrong means we can be fooled.
Sometimes we do it wrong on a technical level, such as using out of date encryption, fundamentally broken encryption, or worse.
Sometimes we do it on a human level, such as not occasionally verifying that the account-holder or bank employee is the one and only person who has used his credendials recently using a non-technical means.
Sometimes we do it wrong in our business practices, such as by not doing frequent-enough random audits and not forseeing that a particular type of attack is worth monitoring for. I will grant some leeway here in that "ridk management" != "risk elimination."
Give me a light bulb with the luminosity and color spectrum of a traditional "soft white" light bulb, the power consumption of a "100W incandescent-bulb-equivalent" LED, and an acceptably-low cost and I'll start replacing all the bulbs in my abode tomorrow.
Bonus points if the bulbs do NOT offer any communications ability or any other I/O other than the electrical on/off switch - that way I know they aren't going to be hacked or used against me.
The OSes that ran on 8086-era computers and on very early Macs, as well as most consumer 8-bit OSes could in principle be patched or even completely overwritten without a reboot.
I vaguely remember an early Mac implementation of Lisp which basically "took over" the machine and gave you a command-line environment (look Ma! No menus!). You "ran" it by running a standard Mac application which basically took over the machine.
I seem to remember some DOS (if you can call that an OS) programs that worked basically the same way: They loaded themselves into memory, kicked the OS out, then when they quit, they asked you to insert a DOS disk and re-loaded DOS from disk without doing a hardware/BIOS-level reboot (or they knew how to read the hard disk boot tracks and loaded it from there).
With the advent of chips that provided real privilege levels and OSes that actually took advantage of them, such "takeovers" without the cooperation of the already-loaded OS became impossible by design (but still possible using exploits of course).
From the 1970s, Tandem Computers (now part of HP) specialized in high-availability computing. I'm pretty sure they've had the ability to patch their equivalent of a kernel for ages.
1980s-era electronic/digital telephone switches (the kind at telco switching offices, NOT your run-of-the-mill PBX) had uptimes measured in DECADES. I don't know if these switches had "live 'kernel' update" capability or not but they did have an "half and half" mode with "live fail-over" capability. One way of doing updates was to shut down one "half" gracefully, update it, bring it back up, leave it running for awhile, then repeat with the other "half". From a customer perspective, the switch was never "down".
As others have show, you can use nested conditionals, status variables, and/or other means to avoid using Goto.
Yes, conditionals, case: statements, and similar constructs are really "goto" statements under the hood, but they are generally easier for humans to read and maintain and easier for compilers to optimize than a goto statement.
Which of the options listed below should you use? In many cases that will depend on the "coding style" of the developer or development team rather than any minor differences in "technical merit."
If as you suggest the quality of therapists is all over the map, getting a "statistically significant representative sample" may require many more data points than you could get by asking/.
Not to mention that people who reply here will be self-selected and unlikely to be "representative" even if you were able to get enough data points.
Unfortunately, there are many things in this world that you have to decide whether to "buy in" to them or not long before you know if it's likely to be "worth the money" or not.
Slashdot Mirror
Pics, er, I mean, peer-reviewed study with independent confirmation of results or it didn't happen.
Ask her school if you can give a Last Lecture to them and, if you choose to put it online, to 6th-grade students everywhere.
As important as it might be to encourage her geek talents, instilling and encouraging humanitarian values is far more important.
Make sure she knows she is loved. If you are religious, ask your wife to keep making it a priority to encourage those values in your daughter.
Make sure she knows that human beings have value and should be respected and treated well, just as you and your wife have treated her well.
Encourage her to use her talents and interests to make the world a better place.
Human: "Get me a drink"
Robot: "I'm sorry,sir, you've had too many."
Human: " Sudo get me a drink"
Robot: "Ok"
Robot: And stop calling me Sudo.
... people will serve robots alcohol. Or the robots will just take it.
I know it's true because I saw it on a Fox TV channel.
Romney signed it. He is a Republican.
What's the difference? Obamacare was based on Romneycare, which itself was bipartisan.
Is Astrology bipartisan? If so, then I'm wrong about that being the difference.
they'll be moving to places with more sensible security policies
I assume you mean places with more sensible security polices and practices, and which are out of reach of foreign national intelligence and law enforcement agencies.
Let us know when you find such a place, but don't bother if it's within ICBM range of America or if it requires more than a month of space travel to get there.
how exactly, other than brute force, is the NSA going to get access to the data?
BINGO! Only it will be applied to the person encrypting the data, not the data itself.
How many 360KB floppies does it take to hold each movie in your collection?
Also, "per second" may introduce rounding errors. "Per fortnight" is the traditional unit of time for things as large as a feature film (or rather, for truckloads/planeloades of the same).
Using multiple beams formed by an array of antennas. No single user gets all that data bandwidth, but the total data bandwidth can be directed in multiple directions, using spatial structure to increase the total data rate with the same radio bandwidth.
This. Very much this.
Even so, a 1:10000 ratio of bandwidth to bit-rate is noteworthy.
I don't see this being practical except in either 1-box-to-many-boxes "point-to-points" situations or in situations where reflection and other characteristics are either very predictable or ascertainable in real-time. The former is uncommon and the latter is hard.
A case of 1-to-many might be in a home or office where a single node is connecting to many fixed-point antennas in an "Internet of things" environment or even to fixed location computers (look ma, no more running wires through the ceiling!).
The NSA program can flash permanently any HDD. FOREVER!!
There are some older drives out there that aren't flashable, at least not over the normal computer/drive connection (look for "service" connections on late-1990s/early-2000s drives).
In light of these revelations, expect vendors to sell (at a premium of course) drives which can't be "flashed" without setting a physical switch/jumper.
of at least 12 new titles, including one that's categorized as a malicious trojan by a major antivirus provider.
Why aren't they all categorized as malicious trojans by all major antivirus providers?
Security isn't hard
LOOOOOOOOOOOOOOOOOOOOL
When Nighthawk214 wrote that security wasn't hard, he wasn't wrong, but he was incomplete.
Security by itself isn't necessarily hard. If I want to secure data that I won't need to use without 1 business day's notice, I can just take two disks, each with a copy of the data, to my bank and put it in the safe-deposit box. Not hard at all. With a little extra effort I can encrypt each with a one-time pad and put the 4 disks in different banks.
Security with online or near-online usability requirements by a large number of people is harder/more expensive, and the more usability you want (just a few key employees at one physical location? all employees worldwide? customers too?), the harder/more expensive it can get for a given amount of security.
Yes, for some applications the level of security you need and the level of usability you need do make it a hard/expensive problem for that use case. But if you are at that point, you've probably determined that lack of security and/or lack of usability is more expensive or you wouldn't be going down this path.
The big problem I see in industry is people incorrectly assuming that it's cheaper to skimp on security than to pay for it up-front. A smaller problem is people over-doing it on security, spending $BIGBUCKS to prevent and mitigate a disaster when the actual cost of a compromise multiplied by the risk of that compromise is known to be well below $BIGBUCKS - or it would be well known if they bothered to spend a little time analyzing their particular risk environment.
Connectivity != Internet.
Take traffic lights for example:
Long before the Internet was more than just a government/university/defense-contractor environment, traffic lights had 2-way communication.
Were they hackable? Yes, to someone with physical access to the communications wires and by the 70s or 80s, maybe to someone who had access to the telephone-company infrastructure. That meant someone in the same metro area as the traffic lights themselves. But they probably were not hackable by someone sitting in his mother's basement or in a terrorist's cave in East Elbonistan.
That's just one example.
My personal pet peeve is companies that allow more than "harmless" remote control of their HVAC over either the Internet or telephone without routing all remote access through a very secure gateway/vpn/whatever. It's not so bad if they allow people to remotely turn on the lights or change the HVAC from "night/energy-saving" mode to "day/occupied" mode, as that just wastes money. But if I can remotely change the temperature to 40F or 100F or remotely shut down the HVAC completely, or remotely turn OFF the lights, that's a bad idea unless strong security is in place. Over the Internet, strong security typically means a VPN or other extremely-hard-to-hack pathway in.
Some things just should never be put "on the Internet."
If you must have remote access, either use a dedicated physical connection (with appropriate anti-tampering/tamper-mitigation measures of course) or tunnel them through a rock-solid VPN, but for goodness sake don't put them "on the Internet."
Yes, companies that run industrial equipment, traffic lights, etc., I'm looking at you too.
legitimate question: what slashdotter still uses the stock OS on a laptop they purchase?
If by "OS" you mean the factory-installed crypto-signed firmware/bootloader/OS stack which can't be changed without keys the end-user doesn't have, then the answer is "probably more than we would like to think."
Now that the vendor knows this, they may be legally obligated to do a "voluntary" factory recall or face a government-mandated involuntary recall.
We can and do use the insecure internet to securely transmit information.
All to often we do it wrong though. Doing it wrong means we can be fooled.
Sometimes we do it wrong on a technical level, such as using out of date encryption, fundamentally broken encryption, or worse.
Sometimes we do it on a human level, such as not occasionally verifying that the account-holder or bank employee is the one and only person who has used his credendials recently using a non-technical means.
Sometimes we do it wrong in our business practices, such as by not doing frequent-enough random audits and not forseeing that a particular type of attack is worth monitoring for. I will grant some leeway here in that "ridk management" != "risk elimination."
Give me a light bulb with the luminosity and color spectrum of a traditional "soft white" light bulb, the power consumption of a "100W incandescent-bulb-equivalent" LED, and an acceptably-low cost and I'll start replacing all the bulbs in my abode tomorrow.
Bonus points if the bulbs do NOT offer any communications ability or any other I/O other than the electrical on/off switch - that way I know they aren't going to be hacked or used against me.
The OSes that ran on 8086-era computers and on very early Macs, as well as most consumer 8-bit OSes could in principle be patched or even completely overwritten without a reboot.
I vaguely remember an early Mac implementation of Lisp which basically "took over" the machine and gave you a command-line environment (look Ma! No menus!). You "ran" it by running a standard Mac application which basically took over the machine.
I seem to remember some DOS (if you can call that an OS) programs that worked basically the same way: They loaded themselves into memory, kicked the OS out, then when they quit, they asked you to insert a DOS disk and re-loaded DOS from disk without doing a hardware/BIOS-level reboot (or they knew how to read the hard disk boot tracks and loaded it from there).
With the advent of chips that provided real privilege levels and OSes that actually took advantage of them, such "takeovers" without the cooperation of the already-loaded OS became impossible by design (but still possible using exploits of course).
I think mainframes had this long before the '90s.
From the 1970s, Tandem Computers (now part of HP) specialized in high-availability computing. I'm pretty sure they've had the ability to patch their equivalent of a kernel for ages.
1980s-era electronic/digital telephone switches (the kind at telco switching offices, NOT your run-of-the-mill PBX) had uptimes measured in DECADES. I don't know if these switches had "live 'kernel' update" capability or not but they did have an "half and half" mode with "live fail-over" capability. One way of doing updates was to shut down one "half" gracefully, update it, bring it back up, leave it running for awhile, then repeat with the other "half". From a customer perspective, the switch was never "down".
As others have show, you can use nested conditionals, status variables, and/or other means to avoid using Goto.
Yes, conditionals, case: statements, and similar constructs are really "goto" statements under the hood, but they are generally easier for humans to read and maintain and easier for compilers to optimize than a goto statement.
Which of the options listed below should you use? In many cases that will depend on the "coding style" of the developer or development team rather than any minor differences in "technical merit."
FART: printf("FART\n"); goto FART;
OK fine do it this way if you are using BASIC or some other language where GOTO is a common idiom.
But in most common procedural languages something akin to
while (true) do print("FART\n") ; done
or
do print("FART\n") until (false)
is easier to read, if only because you don't have to remember that lines can have labels.
If as you suggest the quality of therapists is all over the map, getting a "statistically significant representative sample" may require many more data points than you could get by asking /.
Not to mention that people who reply here will be self-selected and unlikely to be "representative" even if you were able to get enough data points.
Unfortunately, there are many things in this world that you have to decide whether to "buy in" to them or not long before you know if it's likely to be "worth the money" or not.