So I'll bite, why would there be enough advantage to a space-based solar array to offset the problems that a space-based solar array would have over a terrestrial solar array?
Well that IS the question they were trying to address a handful of years ago. Most of the "pros" were known, a lot of the "cons", and they were toying around with it to see if they could make it get near break-even within the immediate future. Then counting on future advances in technology to bridge the gap and push it into positive-leaning statistics.
I think what everyone is seeing is a much higher risk scenario... the advantages are huge, but so are the disadvantages. Maybe it costs you 50x as much to install the array, but it produces 300x the power over its expected lifespan. So then you have to try to measure the expected losses and see if you've made enough to cover them on the average.
And 50x really isn't that bad off an off-the-cuff estimate. No atmospheric losses, runs 24/7, no property costs or footprint. (think places where it's an issue, the USA is an anomaly, think Europe, or even Japan)
I see power transmission as the big obstacle here. The ISS doesn't need to move it anywhere. If you consider using it to crack water to make rocket fuel on the moon, same thing, you'd prefer to make the fuel outside earth's gravity well anyway if you're going to mars. Getting energy back down to earth is where it gets tricky. That's probably the next innovation we're waiting on here - we haven't really seen any serious improvements in energy transmission technology in decades. AC, high voltage, copper... we need a new angle. (superconductors are new, but we haven't found a way to leverage that here, and AFAIK they haven't really applied that down on earth yet) Thinking different like how the solar furnaces are using salt for storing energy as heat instead of say water behind a dam or a battery. Heat's a great storage format because you don't have to worry about losses due to heat, which is a serious problem in all other areas. Finding an elegant solution like that to the transmission problem will be a game-changer in solar tech, terrestrial as well as in space.
Addressing your specific concern about service.... look at how NASA solves that problem, pretty much exclusively with variations on redundancy, along with a healthy dose of flexibility to adapt to unexpected events. Instead of sending up 100 panels, send up 150 of them, along with load balancing and switching gear that can route around panels that are damaged or go defective. The initial cost goes up, but the maintenance cost goes down too. It's cheaper to press a button than to send out a truck. And while you're waiting for a failure, you are producing more energy than you initially spec'd for anyway, so you're banking ahead. Terrestrial installations aren't usually built with anywhere near as much fault tolerance in them just because they have the "truck option". If a panel goes down, it takes down a string of 25 panels. "OK that's fine, we'll just send out a truck, we'll be at 75% capacity for a day." Meanwhile if a panel goes down in orbit, "OK we're down to 149 panels, the bad one's been automatically routed around, now we're down to 149% capacity. Notify the remote support engineers, see if they can get that arm over to the panel and see if it's something we can fix remotely."
About your logging, do you enable different flags for log verbosity? I've alternated between having different amounts of verbosity and just logging the maximum, regardless.
I've experimented with different strategies over the years. I initially liked the debug/info/warn/error set that is used a lot, but the period of time that adjustable of granularity is useful is small and adjusting the debug calls is tedious. Nowadays I generally use two debug flags, "-d" and "-debug", for "function block" level and "inner loop level" debugging. I don't enable/disable the debug calls, I just check the flag in the debug function and decide if I need to display anything or not. I rarely have to comment out debug calls due to impacted performance. So it sounds like we do it in a similar way. I can set another internal flag in some cases to send calls to debug to log also, as in most cases I don't log debug text. (a lot of what I deal with is ran frequently and would fill up disk space with excessive logging) My debug calls are more for live-debugging than historical recording. For that I have a Log call of course. I also occasionally have a History call that writes to a separate file to record more "permanent" information, like when a disused account is removed from a computer, etc. Database-manipulating code often gets its own database log file also to record changes to the database. The historical log file is the only one that is likely to not be subject to periodic clearing.
One of my recent evolutions is to set up a generalized assert. So for example in bash, after trying to do something (rm a file, stat a folder, ssh a command, whatever) I always call my Assert function. I pass in $LINENO, a description of what I was trying to do, and the string of the command I just executed. The Assert function first grabs the previous exit code, and then sends a success message to the verbose debug function if successful. If not, passes the exit code, the try and the command to the abort function. So verbose debugging "by default" catches most errors and provides useful information (where/what/how) to the log. You just have to remember to always use it. This form of debug call also introduces an element of "self-documentation" to your code, although I am always very generous with my comments anyway.
"A computer can follow my instructions quickly and flawlessly, but they have to be VERY simple instructions and they will make NO attempt to deviate from their plan regardless of what comes up. So I have to train something much stupider than your average four-year-old how to reliably perform a complex task, despite the child being both blind and deaf."
They usually either "get it", or insist it can't be that difficult.
If they want more, I usually start going into how the key is to plan for as many different situations as you can, make as few assumptions as possible at the beginning of and throughout the process, and add in as many contingencies as is practical. Imagine a car repair manual where you have to specifically tell the mechanic to shut off the engine and open the hood when describing an air filter change. (or any of a limitless number of other relatable examples)
My specialty is process automation, so I tend to go the extra mile to make my code as autonomous as possible and log the piss out of everything so malfunctions are easily identifiable and can be coded for down the road when Murphy starts getting extra-creative.
then if you need to see the images they embed, click the "load remote content" button in the viewing window when you open it.
I actually got a surprise recently, an email from a vendor saying "you haven't engaged with any of our recent emails, here's a 10% off coupon for your next purchase". Well, we know what they mean by "engaged", don't we?:)
I doubt this will come down to whether or not RedBox is violating the terms. It's more likely to come down to whether or not those terms are legal and enforceable, and that's the angle you'll see RedBox use in their defense.
I for one find it insulting that I buy something and then am held to some terms of its use. It's mine, I paid for it, and you should have no right to tell me how I'm allowed to use it now that it's my property not yours. So I'd like to see RedBox win this.
The minor action isn't what needs to be stopped, it's the extreme over-reaction that needs to be addressed.
If I'm driving down the road and forgot to turn off my turn signal, and suddenly I've got road blocks and swat teams and snipers ahead trying to stop my car, we don't say "!ow guess he shouldn't have left his turn signal on, look at that huge commotion he caused, we gotta do something about those turn signals!" Yes the signal was a problem and you might want to do something about it, but it's the extreme over-reaction that really demands some examination, because there's no reasonable justification my turn signal should lead to an evacuation of two city blocks.
I also cringe when the wrong unit of measure is used, however why did you specify 8 ( or 9) fold difference? There are 8 bits in a byte, period. Where did the 9 come from?
I've done a lot of work with benchmarking data transfer rates, (mainly in attached storage) and it's been my experience that/9 almost always yields more accurate real-world estimates than/8. That comes from a mix of things like parity, frame and packet overhead, processing overhead, latency, retransmission, and a bunch of other things that are really hard to separate. So/9 unless suggested otherwise if you want an accurate estimate from a "absolute maximum" that's measured in n-bits. Except when dealing with pre-USB-C - that requires a significantly larger divisor because of how inefficient the earlier USB protocols are for bulk data transport. (ie 480Mbps won't ever get you more than 39MBps) I simply don't have fast enough hardware to benchmark C well yet, but I do hope they've significantly improved its efficiency.
RTFA please before you post about it. gigaBITS, with a small "b". There's an 8 (or 9) fold difference between "Gb" and "GB". If you can't remember what the abbreviation stands for, quit using it and just spell it out properly.
(from TFA: "A bigger pipe (48 gigabits per second) allows more information for higher resolutions, ")
Pisses me off to no end when broadband providers get it wrong in their ads. "can I get that in writing?" (long hold) "actually sir what we meant to say was..."
"the hacker in question" refused to agree to their terms
You don't just get to dictate any terms to anyone you want to and then say it's all their fault if they don't just accept whatever you throw at them. Sounds like the behavior of your stereotypical spoiled brat child.
Attacking responsible disclosure is bad enough, but when you invite people to pen test with a bug bounty, you're already essentially surrendering your right to apply hacking laws to them. If you then are following up outright refusing to indemnify them and then starting up the legal threats, you're in severe need of a reality check. And a visit from the Streisand Effect too.
"We DEMAND that you break the laws of statistics and mathematics and decrypt these files immediately without the key!"
The judge ought to get a good laugh out of it at least. You just can't expect to use a court order to force someone to violate the laws of nature.
(you also can't use a court order to demand that a private citizen go out of their way to DO something for you - you can order them to STOP doing something, but not to assist you with your investigation - sorry officer but you can't make me do your work for you)
Those pesky laws, constitutions, and amendments, we should just do away with them since they're interfering with investigations, right? Bring back the Writ of Assistance too I suppose?
Methinks they're just lazy, they need to relearn how to do investigations without relying on the crutch of stealing all our rights away to make their jobs easier. This is just a technological barrier, and has done far less to "interfere" with their work than has the constitution. If every time they ran into an investigative challenge they changed a law, we'd have no rights left inside a week.
Well this appeal was lodged while they still had a few pennies left, so although there's an order now that allows the appeal, whether or not they can actually do it is a very different question.
Most (all?) of the SCO core have been disbarred, and most of the lawyers that have helped them in the past have been threatened by judges, so them finding someone to go in front of a judge with a straight face could be challenging.
The problem here all along has been one of odds. If you have a 1 in 100 chance of winning, but the reward is more than 100x your cost of litigation, AND you have enough of a warchest to file hundreds of lawsuits, you go for it. That's what they've been doing the last few years. That's why big companies like MS and Apple and IBM are frequent targets... not because their complaints have merit, but because of the slim chance of a huge payout. If they can win 1 in 100 and get enough of a win to refill their warchest, they just keep it up. This continues until they empty their warchest by either a long string of losses or a few major countersuits.
What I don't understand is how it can possibly benefit you in the long-run to sue the customer you want to keep the business of? Sort of a "biting the hand that feeds you" isn't it?
he is sooo fired. and in the inevitable reference to windows 95 crashing on the live demo, at least in that case the presenter had Bill himself on stage to save him.. Presenter: "And watch as we plug in this.... (BSoD) whoa...." Bill: " and that's why we're not shipping it just yet..."
I think it's not just about repercussions, but also about sending a message. Every now and then someone takes a step WAY over the line and Apple has to give them a public flogging to remind the rest of the employees that they need to take that NDA they signed very seriously.
People complaining about Apple being nasty..... no, not really. If Apple had filed a lawsuit against this guy, then OK that's taking it too far. But they ARE within their right to do so. So anyone that says they "took it too far" isn't looking at how far they can go. He's in breech of contact, and has caused harm to Apple that they can probably prove some value of in court. I think this guy got exactly what he deserved, no more, and no less.
I wonder has everyone forgotten the last time this happened? The guy that left a prototype iPhone at a bar? It's not like Apple hasn't been periodically reminding people how seriously they take their trade secrets. This engineer was well-aware of it and was still careless.
I bet the next engineer to take a prototype home will have this in mind when his kid begs him to show off his prototype. And that's precisely why Apple had to do it.
Yes and no. I'm obviously against slavery and I'm glad the North intervened to stop slavery. With that said, yes, the South had the right to declare independence. It is probably turned out better for both the North and the South long term that the North won, but, yes, South had right to secede, even if they did it for an utterly despicable reason.
There is NO provision in the constitution for secession, it's legally a one-way-trip to join the union and they had no legal right to declare independence. CGP Grey did an excellent explanation of how this pertained to Texas's recent exploration of the option https://www.youtube.com/watch?... while also commenting in passing on the confederate secession. "Could they succeed? Yes. Is it legal? NO!"
As a developer I can see exactly how something like this can happen, and I've had variations of it happen to me numerous times over the years. This is a case of the person writing the app making assumptions about how the user interface behaves, and these assumptions turning out to be wrong OR the interface not behaving as documented. (more likely the latter)
The person that wrote the app was probably "safe to assume" that taps on the screen will be buffered during animations and other gui actions. So the app waits for you to tap, and the user taps a coordinate on the screen and your app is notified of this. You look at the location on the screen, figure out the user pressed "2, remember it, and tell the gui to do the fade on the "2" to indicate the press was accepted. Then you go back to waiting for another tap.
If in the meanwhile, the gui is displaying the fading of the "2", the user taps "3", the interface should buffer the tap, and it can either notify the app immediately (during the animation) of the new tap, OR it can wait until the animation is done and then notify the app.
I don't know which approach the gui takes. If it notifies immediately, I would expect the app to tell the gui to stop the "2" animation and start the "3" animation, as this leads to better response time. SOME apps I've seen just linearly buffer and the app won't be notified of the "3" until the "2" is done animating. In those cases you can mash a bunch of keys and then look at the screen as they are animated one at a time until all keys are animated. This is generally considered poor design but I still see it from time to time.
So what went wrong here? There's several possibilities, depending on what the gui supports. - the gui always disables tap detection while the specific sort of animation used on the "2" is being done - the developer used an animation api that specifically does not buffer taps when there was a buffering api available he should have used - the application told the gui to disable buffering during the animation (or neglected to indicate it wanted buffering, if it's not the default action) - a bug in the app caused it to not buffer taps made while the gui was still rendering an animation
There are probably a few other possibilities but that's the 99% of it. Could be a bug in the API, could be a documentation problem with the API, could be the developer used the wrong API, or used the right API in the wrong way, or got all the information he needed but just bumbled it and lost it in this specific circumstance. There's just no way to know who to blame, and I wouldn't care to take a bet either way.
But really... a user interface bug in a calculator app makes front page news on slashdot? Must be a slow news day?
So.... drug users that consume higher doses of their addictive drugs increase their drug consumption over time, not lower it.
And so who does this surprise? That's the nature of addiction!
I thought we were told that the intention of the nicotine-containing vapes was to try to wean the addicts off the stuff in a more public-friendly and medically-safe manner than reducing their cigarette consumption? Clearly they're just changing their form of addictive behavior, and in too many cases, increasing it.
There ought to be a cap on the amount of nicotine in the vapes, and that cap should be lowered at a steady rate over a fixed number of years until it hits zero. We need to stop supporting these legalized addictive drug dealers as a permanent establishment and seek to shut down the addictive drug industry entirely in the foreseeable future.
if "inconveniencing the law" is grounds for legislative changes, clearly we need to repeal the 4th amendment. I'm sure that one's a constant thorn in their sides and has no doubt hindered countless investigations over the years. (you wouldn't mind unless you were trying to hide something, right?)
Or I suppose they could just (re?)learn how to do their jobs without the crutch of a Free Pass around the law?
BS, several updates have clearly started on their own on my 5S despite my deliberately avoiding updating.
Then I suggest you file a bug report or take your device in for service, because it's not working like it's supposed to and not like anyone else's. iOS on all devices has always required both your approval to install an update and your password. It will become a pest after a point however, constantly reminding you that there's an update available, but it will never install it without your permission and passcode.
(also unlike the desktop Mac OS, iOS doesn't have periodic security patches, some of which can install themselves automatically. This is a somewhat new feature or Mac OS, but is not present in iOS)
The only exception to this is if you boot your phone into recovery mode and use iTunes to nuke and pave it.
(I used to work for an AASP, and I currently work with hundreds of macintoshes and ipads on a daily basis)
The company's former CEO blamed a single careless employee for the entire snafu.
A "single employe" shouldn't be able to pull this off. If they can, then the problem isn't with the employee, it's with the process the employee is working within. If your company is set up where a single peon can ruin your business, it's past time for a come-to-jesus meeting with management.
Slashdot Mirror
Well that IS the question they were trying to address a handful of years ago. Most of the "pros" were known, a lot of the "cons", and they were toying around with it to see if they could make it get near break-even within the immediate future. Then counting on future advances in technology to bridge the gap and push it into positive-leaning statistics.
I think what everyone is seeing is a much higher risk scenario... the advantages are huge, but so are the disadvantages. Maybe it costs you 50x as much to install the array, but it produces 300x the power over its expected lifespan. So then you have to try to measure the expected losses and see if you've made enough to cover them on the average.
And 50x really isn't that bad off an off-the-cuff estimate. No atmospheric losses, runs 24/7, no property costs or footprint. (think places where it's an issue, the USA is an anomaly, think Europe, or even Japan)
I see power transmission as the big obstacle here. The ISS doesn't need to move it anywhere. If you consider using it to crack water to make rocket fuel on the moon, same thing, you'd prefer to make the fuel outside earth's gravity well anyway if you're going to mars. Getting energy back down to earth is where it gets tricky. That's probably the next innovation we're waiting on here - we haven't really seen any serious improvements in energy transmission technology in decades. AC, high voltage, copper... we need a new angle. (superconductors are new, but we haven't found a way to leverage that here, and AFAIK they haven't really applied that down on earth yet) Thinking different like how the solar furnaces are using salt for storing energy as heat instead of say water behind a dam or a battery. Heat's a great storage format because you don't have to worry about losses due to heat, which is a serious problem in all other areas. Finding an elegant solution like that to the transmission problem will be a game-changer in solar tech, terrestrial as well as in space.
Addressing your specific concern about service.... look at how NASA solves that problem, pretty much exclusively with variations on redundancy, along with a healthy dose of flexibility to adapt to unexpected events. Instead of sending up 100 panels, send up 150 of them, along with load balancing and switching gear that can route around panels that are damaged or go defective. The initial cost goes up, but the maintenance cost goes down too. It's cheaper to press a button than to send out a truck. And while you're waiting for a failure, you are producing more energy than you initially spec'd for anyway, so you're banking ahead. Terrestrial installations aren't usually built with anywhere near as much fault tolerance in them just because they have the "truck option". If a panel goes down, it takes down a string of 25 panels. "OK that's fine, we'll just send out a truck, we'll be at 75% capacity for a day." Meanwhile if a panel goes down in orbit, "OK we're down to 149 panels, the bad one's been automatically routed around, now we're down to 149% capacity. Notify the remote support engineers, see if they can get that arm over to the panel and see if it's something we can fix remotely."
I've experimented with different strategies over the years. I initially liked the debug/info/warn/error set that is used a lot, but the period of time that adjustable of granularity is useful is small and adjusting the debug calls is tedious. Nowadays I generally use two debug flags, "-d" and "-debug", for "function block" level and "inner loop level" debugging. I don't enable/disable the debug calls, I just check the flag in the debug function and decide if I need to display anything or not. I rarely have to comment out debug calls due to impacted performance. So it sounds like we do it in a similar way. I can set another internal flag in some cases to send calls to debug to log also, as in most cases I don't log debug text. (a lot of what I deal with is ran frequently and would fill up disk space with excessive logging) My debug calls are more for live-debugging than historical recording. For that I have a Log call of course. I also occasionally have a History call that writes to a separate file to record more "permanent" information, like when a disused account is removed from a computer, etc. Database-manipulating code often gets its own database log file also to record changes to the database. The historical log file is the only one that is likely to not be subject to periodic clearing.
One of my recent evolutions is to set up a generalized assert. So for example in bash, after trying to do something (rm a file, stat a folder, ssh a command, whatever) I always call my Assert function. I pass in $LINENO, a description of what I was trying to do, and the string of the command I just executed. The Assert function first grabs the previous exit code, and then sends a success message to the verbose debug function if successful. If not, passes the exit code, the try and the command to the abort function. So verbose debugging "by default" catches most errors and provides useful information (where/what/how) to the log. You just have to remember to always use it. This form of debug call also introduces an element of "self-documentation" to your code, although I am always very generous with my comments anyway.
I sort of go along the same lines.
"A computer can follow my instructions quickly and flawlessly, but they have to be VERY simple instructions and they will make NO attempt to deviate from their plan regardless of what comes up. So I have to train something much stupider than your average four-year-old how to reliably perform a complex task, despite the child being both blind and deaf."
They usually either "get it", or insist it can't be that difficult.
If they want more, I usually start going into how the key is to plan for as many different situations as you can, make as few assumptions as possible at the beginning of and throughout the process, and add in as many contingencies as is practical. Imagine a car repair manual where you have to specifically tell the mechanic to shut off the engine and open the hood when describing an air filter change. (or any of a limitless number of other relatable examples)
My specialty is process automation, so I tend to go the extra mile to make my code as autonomous as possible and log the piss out of everything so malfunctions are easily identifiable and can be coded for down the road when Murphy starts getting extra-creative.
Those seem to be the only actual common words (ignoring "password")... I wonder why those two are so common? Are they used in a movie?
just uncheck this in your email reader. done.
then if you need to see the images they embed, click the "load remote content" button in the viewing window when you open it.
I actually got a surprise recently, an email from a vendor saying "you haven't engaged with any of our recent emails, here's a 10% off coupon for your next purchase". Well, we know what they mean by "engaged", don't we? :)
besides Trump and Big Business / the cable providers I mean...
it wasn't about the facts, it was about supplementing the headline with some clickbait
Oh so that's what he meant when he said the rocket would have an artificial intelligence autopilot!
I doubt this will come down to whether or not RedBox is violating the terms. It's more likely to come down to whether or not those terms are legal and enforceable, and that's the angle you'll see RedBox use in their defense.
I for one find it insulting that I buy something and then am held to some terms of its use. It's mine, I paid for it, and you should have no right to tell me how I'm allowed to use it now that it's my property not yours. So I'd like to see RedBox win this.
The minor action isn't what needs to be stopped, it's the extreme over-reaction that needs to be addressed.
If I'm driving down the road and forgot to turn off my turn signal, and suddenly I've got road blocks and swat teams and snipers ahead trying to stop my car, we don't say "!ow guess he shouldn't have left his turn signal on, look at that huge commotion he caused, we gotta do something about those turn signals!" Yes the signal was a problem and you might want to do something about it, but it's the extreme over-reaction that really demands some examination, because there's no reasonable justification my turn signal should lead to an evacuation of two city blocks.
I've done a lot of work with benchmarking data transfer rates, (mainly in attached storage) and it's been my experience that /9 almost always yields more accurate real-world estimates than /8. That comes from a mix of things like parity, frame and packet overhead, processing overhead, latency, retransmission, and a bunch of other things that are really hard to separate. So /9 unless suggested otherwise if you want an accurate estimate from a "absolute maximum" that's measured in n-bits. Except when dealing with pre-USB-C - that requires a significantly larger divisor because of how inefficient the earlier USB protocols are for bulk data transport. (ie 480Mbps won't ever get you more than 39MBps) I simply don't have fast enough hardware to benchmark C well yet, but I do hope they've significantly improved its efficiency.
RTFA please before you post about it. gigaBITS, with a small "b". There's an 8 (or 9) fold difference between "Gb" and "GB". If you can't remember what the abbreviation stands for, quit using it and just spell it out properly.
(from TFA: "A bigger pipe (48 gigabits per second) allows more information for higher resolutions, ")
Pisses me off to no end when broadband providers get it wrong in their ads. "can I get that in writing?" (long hold) "actually sir what we meant to say was..."
You don't just get to dictate any terms to anyone you want to and then say it's all their fault if they don't just accept whatever you throw at them. Sounds like the behavior of your stereotypical spoiled brat child.
Attacking responsible disclosure is bad enough, but when you invite people to pen test with a bug bounty, you're already essentially surrendering your right to apply hacking laws to them. If you then are following up outright refusing to indemnify them and then starting up the legal threats, you're in severe need of a reality check. And a visit from the Streisand Effect too.
"We DEMAND that you break the laws of statistics and mathematics and decrypt these files immediately without the key!"
The judge ought to get a good laugh out of it at least. You just can't expect to use a court order to force someone to violate the laws of nature.
(you also can't use a court order to demand that a private citizen go out of their way to DO something for you - you can order them to STOP doing something, but not to assist you with your investigation - sorry officer but you can't make me do your work for you)
Those pesky laws, constitutions, and amendments, we should just do away with them since they're interfering with investigations, right? Bring back the Writ of Assistance too I suppose?
Methinks they're just lazy, they need to relearn how to do investigations without relying on the crutch of stealing all our rights away to make their jobs easier. This is just a technological barrier, and has done far less to "interfere" with their work than has the constitution. If every time they ran into an investigative challenge they changed a law, we'd have no rights left inside a week.
Well this appeal was lodged while they still had a few pennies left, so although there's an order now that allows the appeal, whether or not they can actually do it is a very different question.
Most (all?) of the SCO core have been disbarred, and most of the lawyers that have helped them in the past have been threatened by judges, so them finding someone to go in front of a judge with a straight face could be challenging.
The problem here all along has been one of odds. If you have a 1 in 100 chance of winning, but the reward is more than 100x your cost of litigation, AND you have enough of a warchest to file hundreds of lawsuits, you go for it. That's what they've been doing the last few years. That's why big companies like MS and Apple and IBM are frequent targets... not because their complaints have merit, but because of the slim chance of a huge payout. If they can win 1 in 100 and get enough of a win to refill their warchest, they just keep it up. This continues until they empty their warchest by either a long string of losses or a few major countersuits.
What I don't understand is how it can possibly benefit you in the long-run to sue the customer you want to keep the business of? Sort of a "biting the hand that feeds you" isn't it?
he is sooo fired. and in the inevitable reference to windows 95 crashing on the live demo, at least in that case the presenter had Bill himself on stage to save him.. Presenter: "And watch as we plug in this.... (BSoD) whoa...." Bill: " and that's why we're not shipping it just yet..."
I think it's not just about repercussions, but also about sending a message. Every now and then someone takes a step WAY over the line and Apple has to give them a public flogging to remind the rest of the employees that they need to take that NDA they signed very seriously.
People complaining about Apple being nasty..... no, not really. If Apple had filed a lawsuit against this guy, then OK that's taking it too far. But they ARE within their right to do so. So anyone that says they "took it too far" isn't looking at how far they can go. He's in breech of contact, and has caused harm to Apple that they can probably prove some value of in court. I think this guy got exactly what he deserved, no more, and no less.
I wonder has everyone forgotten the last time this happened? The guy that left a prototype iPhone at a bar? It's not like Apple hasn't been periodically reminding people how seriously they take their trade secrets. This engineer was well-aware of it and was still careless.
I bet the next engineer to take a prototype home will have this in mind when his kid begs him to show off his prototype. And that's precisely why Apple had to do it.
There is NO provision in the constitution for secession, it's legally a one-way-trip to join the union and they had no legal right to declare independence. CGP Grey did an excellent explanation of how this pertained to Texas's recent exploration of the option https://www.youtube.com/watch?... while also commenting in passing on the confederate secession. "Could they succeed? Yes. Is it legal? NO!"
As a developer I can see exactly how something like this can happen, and I've had variations of it happen to me numerous times over the years. This is a case of the person writing the app making assumptions about how the user interface behaves, and these assumptions turning out to be wrong OR the interface not behaving as documented. (more likely the latter)
The person that wrote the app was probably "safe to assume" that taps on the screen will be buffered during animations and other gui actions. So the app waits for you to tap, and the user taps a coordinate on the screen and your app is notified of this. You look at the location on the screen, figure out the user pressed "2, remember it, and tell the gui to do the fade on the "2" to indicate the press was accepted. Then you go back to waiting for another tap.
If in the meanwhile, the gui is displaying the fading of the "2", the user taps "3", the interface should buffer the tap, and it can either notify the app immediately (during the animation) of the new tap, OR it can wait until the animation is done and then notify the app.
I don't know which approach the gui takes. If it notifies immediately, I would expect the app to tell the gui to stop the "2" animation and start the "3" animation, as this leads to better response time. SOME apps I've seen just linearly buffer and the app won't be notified of the "3" until the "2" is done animating. In those cases you can mash a bunch of keys and then look at the screen as they are animated one at a time until all keys are animated. This is generally considered poor design but I still see it from time to time.
So what went wrong here? There's several possibilities, depending on what the gui supports.
- the gui always disables tap detection while the specific sort of animation used on the "2" is being done
- the developer used an animation api that specifically does not buffer taps when there was a buffering api available he should have used
- the application told the gui to disable buffering during the animation (or neglected to indicate it wanted buffering, if it's not the default action)
- a bug in the app caused it to not buffer taps made while the gui was still rendering an animation
There are probably a few other possibilities but that's the 99% of it. Could be a bug in the API, could be a documentation problem with the API, could be the developer used the wrong API, or used the right API in the wrong way, or got all the information he needed but just bumbled it and lost it in this specific circumstance. There's just no way to know who to blame, and I wouldn't care to take a bet either way.
But really... a user interface bug in a calculator app makes front page news on slashdot? Must be a slow news day?
So.... drug users that consume higher doses of their addictive drugs increase their drug consumption over time, not lower it.
And so who does this surprise? That's the nature of addiction!
I thought we were told that the intention of the nicotine-containing vapes was to try to wean the addicts off the stuff in a more public-friendly and medically-safe manner than reducing their cigarette consumption? Clearly they're just changing their form of addictive behavior, and in too many cases, increasing it.
There ought to be a cap on the amount of nicotine in the vapes, and that cap should be lowered at a steady rate over a fixed number of years until it hits zero. We need to stop supporting these legalized addictive drug dealers as a permanent establishment and seek to shut down the addictive drug industry entirely in the foreseeable future.
if "inconveniencing the law" is grounds for legislative changes, clearly we need to repeal the 4th amendment. I'm sure that one's a constant thorn in their sides and has no doubt hindered countless investigations over the years. (you wouldn't mind unless you were trying to hide something, right?)
Or I suppose they could just (re?)learn how to do their jobs without the crutch of a Free Pass around the law?
Then I suggest you file a bug report or take your device in for service, because it's not working like it's supposed to and not like anyone else's. iOS on all devices has always required both your approval to install an update and your password. It will become a pest after a point however, constantly reminding you that there's an update available, but it will never install it without your permission and passcode.
(also unlike the desktop Mac OS, iOS doesn't have periodic security patches, some of which can install themselves automatically. This is a somewhat new feature or Mac OS, but is not present in iOS)
The only exception to this is if you boot your phone into recovery mode and use iTunes to nuke and pave it.
(I used to work for an AASP, and I currently work with hundreds of macintoshes and ipads on a daily basis)
A "single employe" shouldn't be able to pull this off. If they can, then the problem isn't with the employee, it's with the process the employee is working within. If your company is set up where a single peon can ruin your business, it's past time for a come-to-jesus meeting with management.