I don't know about you, but after eight or more hours on a plane I'd like to get at least eight hours of sleep and a shower before I board another plane.
The only benefit that US citizenship has in this situation that they can't put you on the next flight back to where you came from. But they can still give you the special search treatment.
Why would CBP care if you paid duty in Ireland or not?
That wasn't the purpose of the question. They wanted to know whether those bottles were bought from a shop and therefore contain what's on the label, or whether they were not bought at the duty free shop and therefore could have been refilled with something that provides a little more kick.
However, it hides many of the basic but elementary constructs from the user. You may not want to write your fourteenth sorting algorithm, but for someone who's just starting, making bubble sort work is a learning experience.
I'm still looking for a better beginners ('kids') programming language, that still uses basic control structures (if/then/else, loops, etc) and has some graphics functionality (primitives like lines, boxes, circles) ready to use. Python either requires extra modules or dealing with tkinter for the latter.
Sorry, but "creative use" of any feature of a programming language might impress your geek buddies, but it will also make your code utterly hard to comprehend and maintain for anyone - including yourself - in a matter of a few months.
(And I'm not saying 'goto' is a bad thing. Using it to uncreatively break out of multiple nested loops or do error handling is easier to understand than the alternative. Also, in about every programming language, there are pretty much always several ways to achieve a certain behavior. The one that is easiest to understand should be chosen unless there are pressing reasons for one of the other ways.)
Disregard my rant about maintainability if you code one-shot things that no one - including you - will look at again once you're done.
Because encryption may keep someone from accessing the device in an emergency, and the manufacturer will be confronted with a "patienty XYZ died because of a feature you intentionally put into your device" charge.
Of course they are intentionally overbooking flights, based on statistical analysis of what percentage of people who book a flight don't show up for it, and actually data of what it costs them to bump people off flights.
Indeed. How many locks do you want to see on an emergency exit or a fire extinguisher?
Another thing to consider is battery life. Changing the pacemaker requires cutting holes in the patient, which poses a small, but (over a large number of procedures) real risk (anesthesia, infection, etc).
A programming session is started by pairing the programmer and the pacemaker with a wand that requires 10cm proximity (this provides the security key).
How is the distance verified? Is it merely a matter of signal strength, or do they actually measure response times and signal trip times?
If signal strength is the only criterion, all an attacker needs is a powerful transmitter and a sensitive receiver.
Why? Why is simply firing someone a better solution than giving them exactly what they are doing wrong and what they need to change if they want to keep their job?
Simple: The person about to be fired has already demonstrated that they failed to perform their duties. If you hire a new person, you get the change of hiring someone who can do things right the first time. If not, you're not worse off than before.
I know weight and volume are at a premium on such craft but a barometric sensor (even one capable of operating in Mars's rarefied atmosphere, is the size of a thumbnail and weighs just a fraction of a gram.
Even one that works at the velocity encountered during atmospheric entries?
Sounds like you're suggesting putting a Pitot tube on a space probe...
No basic sanity checks? As in "This phase must last at least X seconds", or "No switching to landing behavior if altitude measurement from 1 second ago still said '2 miles above surface'"?
readable and maintainable code is somewhat overemphasized these days.
Well, in my line of work I've realized there is a fair chance of products coming back to bite me for a couple of years after they are released. Making the code maintainable is a sanity issue, since I'm the one who will be doing the maintenance if necessary.
PS - assembler is quite "debuggable"
Yes, if you stick to a few simple rules (like avoiding overly long functions and such), and if you use an architecture with an assembly dialect that's easy to understand (which wasn't the case in this project - delayed execution, pipelining and features like zero-overhead-looping might make the processor very well suited to certain tasks, but the resulting assembly is very hard to understand).
In fact, the assembly dialect spoken by that particular DSP is so full of unusual things that the compiler only used about 40% of the instruction set.
Slashdot Mirror
I don't know about you, but after eight or more hours on a plane I'd like to get at least eight hours of sleep and a shower before I board another plane.
I agree it's not a huge benefit though.
The only benefit that US citizenship has in this situation that they can't put you on the next flight back to where you came from. But they can still give you the special search treatment.
That wasn't the purpose of the question. They wanted to know whether those bottles were bought from a shop and therefore contain what's on the label, or whether they were not bought at the duty free shop and therefore could have been refilled with something that provides a little more kick.
Two words: Diplomatic incident.
However, it hides many of the basic but elementary constructs from the user. You may not want to write your fourteenth sorting algorithm, but for someone who's just starting, making bubble sort work is a learning experience.
I'm still looking for a better beginners ('kids') programming language, that still uses basic control structures (if/then/else, loops, etc) and has some graphics functionality (primitives like lines, boxes, circles) ready to use. Python either requires extra modules or dealing with tkinter for the latter.
(And I'm not saying 'goto' is a bad thing. Using it to uncreatively break out of multiple nested loops or do error handling is easier to understand than the alternative. Also, in about every programming language, there are pretty much always several ways to achieve a certain behavior. The one that is easiest to understand should be chosen unless there are pressing reasons for one of the other ways.)
Disregard my rant about maintainability if you code one-shot things that no one - including you - will look at again once you're done.
I can see it now.
"Gentlemen, I present to you a room temperature superconductor!"
...
"What? No one said anything about ambient pressure."
Because encryption may keep someone from accessing the device in an emergency, and the manufacturer will be confronted with a "patienty XYZ died because of a feature you intentionally put into your device" charge.
> A phone is not. The phone didn't harm anyone in this particular case; it didn't explode or anything.
Of course they are intentionally overbooking flights, based on statistical analysis of what percentage of people who book a flight don't show up for it, and actually data of what it costs them to bump people off flights.
I hope that by the time coal becomes competitive again, I can move to a newly-terraformed Mars or Venus (or maybe even farther out).
Statistics is always a bit of a gamble.
Another thing to consider is battery life. Changing the pacemaker requires cutting holes in the patient, which poses a small, but (over a large number of procedures) real risk (anesthesia, infection, etc).
How is the distance verified? Is it merely a matter of signal strength, or do they actually measure response times and signal trip times?
If signal strength is the only criterion, all an attacker needs is a powerful transmitter and a sensitive receiver.
But:
1. It can run Angry Birds.
2. It can sync with a local PC, without depositing your address book and everything else on MS/Google/Apple servers
3. It used to be open source, before it became open ... for business.
4. It can run DOSBox.
> The politicians shoot the citizens. No. The politicians order the army to shoot the citizens. And the army obeys.
Simple: The person about to be fired has already demonstrated that they failed to perform their duties. If you hire a new person, you get the change of hiring someone who can do things right the first time. If not, you're not worse off than before.
If they didn't, I guess there will be an increase in demand for such services.
Golden ages are driven by great games, not by technology. The technology merely needs to be good enough to allow the games to be realized.
Um ... this is about a joint mission by ESA and Roscomos.
Even one that works at the velocity encountered during atmospheric entries?
Sounds like you're suggesting putting a Pitot tube on a space probe ...
No basic sanity checks? As in "This phase must last at least X seconds", or "No switching to landing behavior if altitude measurement from 1 second ago still said '2 miles above surface'"?
Yes. And that's damage control after the ship got shot at, not damage control after some simple mechanical breakdown.
Well, in my line of work I've realized there is a fair chance of products coming back to bite me for a couple of years after they are released. Making the code maintainable is a sanity issue, since I'm the one who will be doing the maintenance if necessary.
PS - assembler is quite "debuggable"
Yes, if you stick to a few simple rules (like avoiding overly long functions and such), and if you use an architecture with an assembly dialect that's easy to understand (which wasn't the case in this project - delayed execution, pipelining and features like zero-overhead-looping might make the processor very well suited to certain tasks, but the resulting assembly is very hard to understand).
In fact, the assembly dialect spoken by that particular DSP is so full of unusual things that the compiler only used about 40% of the instruction set.
In that particular case, it wasn't just testing.
The bug could have been caught by someone reviewing the code, if the manufacturer had spent the money.
The bug could have been caught during testing ... maybe (there was some randomness involved).
The bug could have been caught after the first reports from users about erratic behavior of the device came in.