It seems to me that "Safe" requires "Consistent." Otherwise, it's just "theoretically safe," not actually safe. And having just been through a house-buying process, I gotta tell you...I wouldn't entrust all the realtors with the safety of airspace. Especially since they seem to have no real guidance given to them on what "safe" commercial use of a drone actually entails.
They already do this. Check points in Iraq and other countries like Israel are known for being blown up. Buses are more typical because they are enclosed making the blast more effective. The thing is that the death toll usually isn't much higher than a bad car wreck compared to other methods so i think they are targeting the mechanism moreso than what we consider terrorist goals to be. But thats just my limited guess to why they aren't more popular in weatern nations.
The way the Israelis learned to deal with this is very simple. You have a population coming through a checkpoint...almost always, in the case of Israel, a checkpoint between Israel proper and one of the Occupied Territories (Gaza, West Bank). The people coming through are, overwhelmingly, the population from where the risk comes...Palestinians. The cordon is designed so that a suicide bomber will not 1, be able to blow a hole through the barrier that the checkpoint acts as a valve for, and 2, be able to kill the people manning the checkpoint. That leaves only the Palestinians as potential victims...with the deterrent effect that results. Hamas doesn't win bonus points for blowing up their own people.
Load balanced or mirrored systems. You can upgrade part of it any time, validate it, then swap it over to the live system when you are happy.
Having someone with little or no sleep doing critical updates is not really the best strategy.
First off, you can't mirror everything. Lots of infrastructure and applications are either prohibitively expensive to do in a High Availability (HA) configuration or don't support one. Go around a data center and look at all the Oracle database instances that are single-instance...that's because Oracle rapes you on licensing, and sometimes it's not worth the cost to have a failover just to reach a shorter RTO target that isn't needed by the business in the first place. As for load balancing, it normally doesn't do what you think it does...with virtual machine farms, sure, you can have N+X configurations and take machines offline for maintenance. But for most load balancing, the machines operate as a single entity...maintenance on one requires taking them all down because that's how the balancing logic works and/or because load has grown to require all of the systems online to prevent an outage. So HA is the only thing that actually supports the kind of maintenance activity you propose.
Second, doing this adds a lot of work. Failing from primary to secondary on a high availability system is simple for some things (especially embedded devices like firewalls, switches and routers) but very complicated for others. It's cheaper and more effective to bump the pay rate a bit and do what everyone does, for good reason...hold maintenance windows in the middle of the night.
Third, guess what happens when you spend the excess money to make everything HA, go through all the trouble of doing failovers as part of your maintenance...and then something goes wrong during that maintenance? You've just gone from HA to single-instance, during business hours. And if that application or device is one that warrants being in a HA configuration in the first place, you're now in a bit of danger. Roll the dice like that one too many times, and someday there will be an outage...of that application/device, followed immediately after by an outage of your job. It does happen, it has happen, I've seen it happen, and nobody experienced who runs a data center will let it happen to them.
If a sufficiently large population of interested people can be induced to correct the map it shouldn't be an insurmountable problem. Wikipedia suffers and reverts many thousands of bits of misinformation daily. Not to say it's perfect but it's good enough.
Issue #1: Wikipedia is actually in crisis at the moment, over this very issue. So...hm. We'll see if they actually do survive it.
Issue #2: With Google Maps, there's the larger population that has a very small incentive to edit everything, and although they have a greater incentive to offset information that's false...those incidences are like needles in a haystack, and it's very very hard to find out which ones they are. There will be enormous duplication of effort as well, since the best-patronized businesses will invariably be monitored by many people while others will go ignored due to smaller constituent populations or populations that tend to be less tech-savvy. Conversely, the attacker needs to do very little to do their damage, and requires a far lower degree of vigilance to be successful at it. So, the "sufficiently large population" of "interested people" is extremely hard to accomplish, and even harder to use efficiently.
I'm missing the part where something in Dubai is waiting to be a dystopia...
Check the record. EVERY Tea Party member is opposed to this program.
Probably. I'm gonna go check the record.
This is like saying "Hey, he ran a mile nonstop. Don't think he's unhealthy, just because he has full-blown AIDS..." Even a broken watch is right twice a day.
This article doesn't mention the incredible upgrades of the F-35. It has incredible situational awareness (SA), highly networked to acquire SA from all sources, sensors onboard to provide SA, smaller that the F-22, more stealthy, and a range of other characteristics that the pentagon desires (wiki). Those capabilities are the top reason for the F-35 to exist at all. As development has progressed, then the money problems and failures came up as they always do. The capability needs don't justify the failures of the program, but they need to be taken into consideration when there's talk of changing or canceling the program.
Everyone has a different concern. Congressmen are probably concerned about money staying in their state to stay elected. The Pentagon is worried about capability and not being embarrassed over a big failure. The tax payers are worried about not wasting money and some of them about keeping an F-35 job. It's a complicated issue with lots of caveats.
Ah, excellent points. If only we'd have had these planes in Iraq and Afghanistan, we'd have...oh, wait a minute. NOTHING WOULD HAVE CHANGED.
Our weak points do not hinge on air superiority. The current aircraft with our current pilots are demonstrably far and above better than anyone else on the planet. Yes, we do need to plan ahead...but is a radical new level of sophistication important and/or useful? Consider that no other nation on the planet retains even the ability to project power over distance from their home country, absent an ally where they can stage aircraft. The Russians have one aircraft carrier (the Kuznetsov) which is a steaming pile of shit that's only ever been out 4 times, and never far from home. It lacks catapults, so as a result aircraft that fly from it must go light on both munitions and fuel. It suffers from massive problems with its power plant, and is unreliable. The Chinese have a carrier too...but no ships to support it. Oh, and it's a carbon copy of the Kuznetsov and heads have rolled among the people who managed the purchase of it from the Russians. So it's shit too.
Meanwhile, Congress is doing all they can to axe...the A-10. The A-10 Warthog has killed more tanks than any other weapon in our arsenal, not to mention how many soldiers it's saved via close air support missions. It's universally loved among the pilots who fly it and the troops who have been protected by it, it's tried and true, and it's cheap as hell. Simple, rugged, incredibly durable even when shot to bits and indescribably lethal to ground targets, it's a much better indication of the kind of aircraft role that will be central to future conflicts we face.
So yeah...the F-35 has all sorts of whiz-bang cool stuff, stuff that we don't need, while being unreliable, insanely wasteful of money, and the wrong place for our primary focus to go for the future of war.
Actually, it's probably something more like TIBCO BusinessEvents with an orchestration engine added
Back in my time, we called what they have done now "an expert system". I fail to see why that designation should be suddenly inadequate.
Because back then, that was a conceptual description that (if it became real) described an entirely custom system that was built from the ground up. These days, there are multiple types of such systems, most of which are built along specific architectural lines using COTS. Just like once upon a time, "car" was a pretty good descriptor because the next level of detail went WAY into the weeds. Now, there are sports cars, SUVs, minivans, coupes, etc.
In other words, this is basically Drools, plus a ton of billable consulting hours?
Actually, it's probably something more like TIBCO BusinessEvents with an orchestration engine added. But what's really cool is that they did the hard part: codifying the actual rules under which the overall system operates. That's where these kinds of systems either fly or fall. There are tons of rules that organizations use to make decisions, but a lot of those rules are quite informal and don't operate at a central point of authority. It takes a lot of digging to find them all, so that the undocumented process (for example) used by the foreman of the team that does rail maintenance to manage overtime among his crew gets incorporated into the overall chaining logic. Otherwise, the new system will either fail to reflect reality as teams rearrange their own schedules out of sync with their directives, or will wreak havoc among the employees.
By "change jobs," do you mean change employers as well? What about lateral moves within the same company, or between different organizations within the same company?
Ultimately, how often you change roles (either change in job description, responsibilities, or employer, as I'm defining it) depends on the following things:
1, demand in your field. If your field has more demand than supply, these are the salad days...moving from company to company can be beneficial. These days will not last forever, so make sure you take advantage of them, but also be wary of reaching the pinnacle of compensation. At some point, the market will catch up, and you may end up being more expensive than you're worth when that day comes.
2, the company/organization you work for and the opportunity it provides. If you have growth still ahead of you and are continuing to grow in your current place, then moving is probably not a great idea. Money's good, but development is better. A lot of companies don't have a career path that's technical (instead of automatically turning you into a manager who never will touch technology again), so that's a consideration as well. Which way do you want your career to go?
3, your current happiness in the role you occupy. This is for you to define, and the rationale behind it should be obvious.
4, how long you've been there/industry tolerance for job-hopping. If you've been at the last 4 jobs for less than a year each, this may not look so great on a resume. But some industries/career paths are quite tolerant of such things, understanding the current state of the market.
At least, that's how I see it, in broad strokes.
Noise? Or the encrypted output of a signal generator? Prove it.
Spend some time in a DMS operations center of a power company. They watch for noise too...noise is variation in that waveform, and a sign that something somewhere (a transformer, for example) is in distress. A power company would notice noise on their lines like the phone company would notice Rick Astley playing instead of a dial tone on their landlines.
Tracking someone through landlines has been a Thing for many years now. Ever hear of a "lock and trace"? You can SORT OF do the same thing for power, by embedding a signal in a given substation. It's nontrivial, and it's horribly complicated, but it IS feasable. As for the "hum" thing, that's just standard TEMPEST, been a Thing now for going on thirty years, where you can fingerprint electronics via EM signatures and you can read those EM signatures via physical phenomena including audio hums and induced currents in surrounding circuits. This is why the LASER mike was actually developed, not for actual sounds (standard shotgun mikes do wonders there, because the glass reresonates sound just fine), but to get a good frequency signature on TEMPEST EM leakage. So, in sum, they're not specifically taking a van out and following lines to see what location an interviewee is at, but a lot of that is that they don't really need to because they can get all the information they need through older technologies that approximate the capabilities
HUGE problem with this theory.
The power grid operates on incredibly tight tolerances with regard to frequency. Additionally, within that margin (which is the same, everywhere, within a certain grid...and by grid, I mean, like "The United States" or "Great Britain") there is a small degree of variation that is the same for that grid and all that are built using the same equipment...which is a significantly humongous population.
Imagine a metropolitan area like, say, San Antonio. San Antonio has several power stations that service its region. Each generation turbine produces what's known as "three-phase power," which is kind of like TDMA for AC electricity. Those three phases get broken out and separated into three outputs that then go into a substation and transformers, then out on the grid. The three phases equally and perfectly distribute around the 360-degree rotation of the "exciter," which is basically the generator's key component. If that distribution gets out of whack, power spikes in a really nasty way, and copper vaporizes fast enough that it's actually a detonation.
But I digress. The point is this: AC power is a waveform, oscillating at 60 Hz. It cannot vary much at all...because within the same grid, everything is interconnected. Every generator is in sync, or has a syncrophasor to re-sync the power coming from it before it hits the grid. Otherwise, you get some power from A and some from B, with waveforms that are out of sync...and the frequency changes in both rate and amplitude, and shit blows up. (Including generators themselves...the "Aurora Vulnerability" that DoE is so batshit scared of is essentially a manifestation of this at the generator itself.)
So...I've been trying to think of how there could possibly be enough variation to fingerprint someone based on the hum caused by that 60Hz frequency noise. I've been in transmission control centers where they monitor, regulate and occasionally wet themselves over frequency shifts, and I've seen that the amount of variation needed to cause sheer panic is shockingly low..and it rarely ever happens for even a second. And those tolerances have been the same everywhere I've gone.
So no, it's not at all like TEMPEST. Because if it were, it'd be the equivalent of being able to figure which monitor you were looking at by EM emissions...when all the monitors in the country show the exact same thing.
Yes, but, you can run R and Python over data in pretty much any backend (Teradata, Hadoop, etc.). That's usually the second conversation - how you want to accomplish your goals.
That you think that just "Teradata" or "Hadoop" is the other thing needed in addition to Python or R to replace an SAS implementation tells volumes about how much you don't know about SAS and what it really does to satisfy customer requirements. You don't replace SAS with nothing more than a bare database and a Python interpreter.
And you can't just say "I want you to throw out your existing infrastructure just so that I can use X programming language...you figure out how to make it happen" to the company you work for. This is an RGE..."Resume Generating Event."
SAS is not a language; it's a full multi-tiered solution for the aggregation, normalization, and analysis of data. There's a language as well, but that's just one part of the whole solution. Python and R, while absolutely fantastic languages, are not a full solution.
So, first step...if you're going to offer an alternative, actually have an alternative. I don't know your SAS buildout nor do I know the data sources it consumes, so I can't really point to what else you need to add or how you need to construct it to produce a more flexible replacement to your existing and current SAS infrastructure.
Second step...a roadmap for migration. It's one thing to sign a lease for a new apartment or to buy a new house, and another to shift your life from the old place to the new. If you don't have a plan, at least in broad strokes, then you're going to be doomed when you look for executive sponsorship. You need to make sure that you get all the stakeholders' input as well, lest you leave something out in your roadmap...and then end up with someone who sees you as a problem. That person will most likely be in a position to scuttle the whole thing, as well.
Third step...figure out how to define the benefits in terms of the stakeholders' needs. You're going to replace a system they use; why should they want you to do so? And you have to define it from their perspective, with regard to things they care about. Beware of getting geeky on this...it's very likely that at least one of the people whose support you will need will not be a geek and will be concerned with the output more than the technical means used to produce it. Don't hard-sell, either...pushing too hard will get the door slammed in your face, and even potentially polarize people against you. (See above, under "in a position to scuttle the whole thing.")
There will be steps after that, but those will be largely determined by how the first three steps go. It may involve bringing in outside vendors, doing requirements analysis...a lot of it depends on details of your company as well and how they normally do things. But above all else, remember this: don't buck the system too hard, and don't knock the company you work for. Trying to get a lot of people to support and cooperate with you while telling them that their way of doing things sucks is suicide.
Everyone's freaking out over things like phone calls on planes over this. People, this isn't a change to the ruling that smartphones and tablets have to be in "airplane mode" during the flight...they still do. This is just a rule allowing you to use the phones in that mode during takeoff and landing.
I travel a lot for business, and I can say from personal experience that the ruling has made an enormous difference; I don't know from where the FAA is getting their numbers. I might see one person with a smartphone every fourth flight I was on in the past, whereas now I can see several in use on every flight during takeoff and landing. And people seem happier for it.
We want to create puppets that pull their own strings. - Ann Marion
