The "hardware" support is not in any real hardware. We're talking DSP code for most portable devices, AFAIK. All it takes is writing some more code to support it just as well. Or am I wrong?
I'm not so sure about SL having "about the same bugs" as Windows. My up to date Windows XP VM instance blue-screens about once a week, and I know of one way of getting it to reproducibly blue screen -- it's some weird interaction of the VS9 debugger and the USB stack (unrelated to VMware -- happens on bare hardware, too). The underlying OS X has never had a kernel panic for me, and I have only had to do hard reboots due to a frozen system twice (some AFS-over-WiFi issues) -- that's over combined 4 years of owning OS X machines (3 years for iMac, 1 year for MacBook Pro). For me, that's a track record better than up-to-date rather stock RHEL 5 installs.
Some control happens at the local (OR) site. For example, if you want to maintain a frame of reference that's locked onto the moving heart surface, then there's no reason to have the loop closed across the ocean. Locally is just fine. All that the remote (surgeon) site has to do is to flip a bit to enable the lock.
I'd actually like to have a good bastard doctor like House. So far my experience has been with lots of residents, who -- when subjected to any sort of unknown/unexpected stuff that they don't have an instant answer to -- turn into clueless bastards.
I'd much rather have a clueful bastard, than a clueless bastard who is a bastard to mask his/her cluelessness.
BTW, this is all from recent experience at a big ten ED. I think by now even I would know how to do a less painful pelvic exam than that girl had done.
I think NeoOffice has a slightly better track record -- for me at least. I have had it crash once in the last 1.5 years of using it. Maybe I'm just a weird user or something. I know it's just OO.org, but methinks the use of their custom (java-based) UI frontend somehow helps with things, somehow.
I've tried native OO.org for OS X recently, and it felt like crap in comparison. And yes, it did crash -- twice during one day of testing.
So I hold NeoOffice folks in high esteem. But that's just me.
Quite seriously, I would call a city-wide WAN (particularly on the scale of SF) considerably more complex than flying the space shuttle. Even a highly competent network engineer might take months to map the whole thing out starting with nothing but a handful of router passwords.
A lot of the Space Shuttle "documentation", such as mission checklists, is public. Feel free to browse through it. You'd need a week of hard work just to familiarize yourself with the acronyms. If you think that a city-wide WAN is more complex than a shuttle mission, you must have never listened to realtime feeds from NASA TV. Just listen to landing replays -- those are played after the touchdown at KSC (or AFB), and include realtime audio as they shut down things before egress. It takes an hour+ just to shut it down. That's after you're down at the end of the runway and, if you were you, you'd feel like just opening the hatch and going for a walk.
Sure, people fail, but when that failure is criminal, then the organisation shouldn't assist in covering it up, and certainly not allow it to continue. I can accept that bad stuff happened in the '60s and '70s, and that they weren't prepared to deal with it then. But once high-ranking officials became aware that abuse occurred, they should have made absolutely sure that it wouldn't happen again.
Umm, why weren't they 'prepared to deal with it then'? What's so special about '60s and '70s. Were we somehow all less aware, as a human race, that pedophilia and child abuse are bad back then? WTF?!
California law regulates what you can do when you find lost property in the state. Section 2080 of the Civil Code provides that any person who finds and takes charge of a lost item acts as "a depositary for the owner." If the true owner is known, the finder must notify him/her/it within a reasonable time and "make restitution without compensation, except a reasonable charge for saving and taking care of the property."
But Section 2080 of the Civil Code is not the Penal Code. He can't be jailed for violating Section 2080, only sued; and since Apple got their prototype back, that's unlikely, because they won't be able to show damages; the main obligation of a depositary (detailed in CCC 1822-1828) is to give the item back.
California Penal Code 485 requires only "reasonable and just efforts to find the owner and to restore the property to him".
It is fine with me if he wants to be compensated for an act of God. However, the being responsible for the act of God should be paying the compensation, not the British government.
It is morons like the guys you are responding to, who take flying for granted, that demand to never be inconvenienced in this amazing world, who really don't deserve to be let on a plane again.
I guess he will ask for a govt bailout once the bill comes. After all, the govt didn't "protect" them enough (from their own stupidity), right? Yea, right.
Not only that. Let's not forget two important fluids: fuel and engine oil. Engine shaft seals may not be dust-tight enough at the concentrations of ash encountered here, so you risk contaminating engine oil with an abrasive. Considering that engine oil film is *the* bearing for a lot of parts in the engine, that's not good.
As for fuel: the fuel tanks are vented to the atmosphere. Ash will settle down and contaminate the fuel. So you'll have to periodically flush the fuel system. Downtime = $$.
It's not even that "abnormal distractions would be bad" -- it would be completely, absolutely crazy to drive like that.
Landing a plane, on the other hand -- that I could potentially agree on. Some studies show pilots staring at the far end of the runway say from 200ft down to ground contact, so that could potenitally work. It's sort of a reflex thing they do in visual conditions.
Driving on a long stretch of straight road sometimes looks like that too, when you analyze the eye movements.
But in "normal" driving, not only the instantaneous eye position is uncorrelated with desired steering wheel input, but also long-term averages are generally uncorrelated.
Basically, to drive with eye position as the control input is to become blind, to a large extent. I have played a little bit with using eye movement in various control input scenarios, and the only conclusion I came to (in an informal study) was that you can obviously learn rather well to use eye position as the control input. Heck, with audio feedback you can learn even faster, but you become progressively more oblivious to what's going on around you. This may, perhaps, be thought to be "OK" at first sight, as you'd think it rather keeps you focused on a particular area of the surroundings -- just that on curves it usually ends up being anywhere but on the road. So you literally feel like driving in a tunnel. Forget looking at street signs, or navigating in unfamiliar environment. And you better never had to change lanes.
Remember that the raison d'être of our visual system is exploration of our environment. This also happens when we drive. Eye position will depend on what interesting stuff is out there, not on which way you are driving.
There's a lot of "eye movments to control this or that" type of studies. Unfortunately, the idea came from science fiction, and belongs on the same shelf with "cleaning up" SD interlaced surveillance video full of compression artifacts to "clearly" see a face that's six pixels across. Such studies certainly have a lot of appeal to the general public, and to anyone who doesn't quite think it through or understand the basic conflicts of purpose involved in using eye movments for something they just can't do while simultaneously maintaining visual awareness. This is the same fantasy as using eye movments for interacting with machine user interfaces: all fine and dandy, as long as you don't need to see/explore the damn interface. If you have the UI all memorized, and ideally are provided with audible cues to help you navigate, you can use eye movments. But the moment you want to look around, it becomes all screwed up.
Now, in situations where you don't give a damn about maintaining visual input -- you can use eye movements for whatever control inputs you please, and they are quite good for that. Heck, the input is at least 3-dimensional: you can choose not only the direction vector, but to some extent the amplitude of the initial saccade.
So -- eye movements are great for controlling a car, as long as you're in the passenger seat, and the driver makes sure you won't run over the old lady, and won't drive off the end of a closed bridge -- IOW, as long as you don't need to actually see most of what's outside the window.
There are of course ways to devise some special patterns of eye movements that switch the modality of the controlled device/interface, so that you can work around the conflict between controlling and visual exploration. But those hardly feel natural. Those are very fine things to do if the alternative is even worse -- say, if you're paralyzed and all that's left is eye motion. But without training and adaptation the eye movement control has anything but "natural feel" to it.
Burglars no longer need to visit an area to scout it to check for targets. The common argument from the pro-street view group against this is that well anyone could come down and take a picture for the same effect- that's true, but here's the difference, using my house an example. I live on a cul-de-sac, to get to my house and take pictures without someone noticing a guy with a camera would take some doing, everyone on our street knows everyone else, if someone came down, and turned around, someone would see them. If there was a subsequent burglary, then there would be witnesses who could point the police in the right direction in terms of a number plate, or a description of a person, or person(s) looking dodgy.
If you seriously believe that, you live in a fantasy.
If what you claim is true, then what was the make/model/plate# of the google street view van? Was the driver a male or female? How many of your all-the-time-alert neighbors saw it? After all, those things aren't exactly inconspicuous!
I live on a cul-de-sac, too. There's noone here during regular working hours. You could literally have a film crew here for 2-3 hours a day, and noone would know.
If your cul-de-sac has a house or two with retirees, or stay-at-home moms, I really doubt all they do is sit by the window the whole time, and write down every license plate number.
My bet is thus: if I wanted to, I'd just take an HD camcorder, give it to my wife in the passenger seat -- or, heck, to my kid on the back seat, one of them would take the shot, while I'd drive into the cul de sac, turn around, and drive out. I'd say my chances are 1:50 that anyone would recall an "out of place" car being there, 1:1000 that anyone would know the make/model, and 1:10'000 that someone would know how many people were in the car, that someone was filming, and the license plate #.
The reality is exactly opposite to what you insist: if I want to physically scout a location, I won't be seen, there will be no witnesses, and there will be no suspicion. Cameras these days are rather inconspicuous, even HD cameras. I can have one in my hat, and just walk around, with a kid or two in tow. Or I can just drive around with a dash camera. Heck, I could probably get something flat and inconspicuous-looking magnetically attached to one of the mailboxes around here, if I wanted to see the people's comings-and-goings in real time, from a safe distance.
About the only point you may have is that the high vantage point requires a sufficiently tall vehicle, and couldn't really be inconspicuously replicated without having a camera in, say, a gyroscopically stabilized ball. Maybe it's a good idea for a project! Let's see who can throw the ball higher in the air, kiddo! And when we come home, we can review how high it flew;)
Provable as to what? In any case, a lot of code written in dynamic languages is really not that hard to reason about. Everything depends on what features of the language do you use, and how you use them. You can write perfectly functional side-effect-free code in Python. The compiler won't enforce it for you, but you can do it.
Caller ID is *not* in-band any more than connection routing is.
I have a T1 ISDN link in the U.S. There are 7 dynamic voice trunks on that T1 link. We have a pool of multiple phone numbers.
When the call is being set up, my switch (asterisk) sends out a message indicating the calling number. The contents of this message are taken by our telco's switch at face value, as long as the number is 10 digits long.
This number is recorded in the detailed billing statement we get (for international / overage long distance), but it is not actually used for billing by our telco! Any call going out through our T1 link is billed for by the telco, no matter what garbage is being sent out as the calling number identification.
I can set asterisk to send any number, and that is the number that will be displayed to the called party. I have been experimenting with setting up a local GSM mini-cell to make use of cellphones within the building essentially "free", and obviously if such calls were routed over our ISDN link, the indicated numbers would be those assigned to the cell subscriber, not those of our number pool.
We obviously don't use it for anything nefarious, but I presume that many VoIP trunk providers will do it in the same way. It's somewhat hard for them to really filter the phone numbers on egress, since they may not have full knowledge of all phone numbers assigned to us: for example, we may have an 800 number through another provider that we want to display, or even a bunch of regular numbers via another provider B, that are being routed out via provider A due to -- say -- link loss caused by a backhoe two blocks down the street.
So this is nothing about in-band vs. out-of-band. It is about making the phone system work as you'd expect, vs. making things hard.
The only technical solution would be a realtime database used for egress filtering of calling number identification -- it'd link together all phone numbers assigned to a particular subscriber. And then we again run into problems of what really is a subscriber: suppose you have separate units of a big corporation, that get separately billed for service, and are really considered separate subscribers. Now suppose that for redundancy and continuity of service, the IT/comms people in Unit A and Unit B agree to carry the other unit's data and voice traffic to maintain service in cases of various failures. Now the realtime database needs respond as if both subscribers were one. And so it goes -- it's not exactly trivial.
Making it illegal to purposefully mislead people is OK in my book.
Don't believe that big corporations are omniscient. They have no experience flying through such conditions, and have no fscking clue as to how much that will cost. All they're doing now is betting that flying will cost less than standing down. They really don't know how it's going to turn out. You can't even go out there and hire a consultant to figure it out: noone was routinely flying in such conditions.
AFAIK, there are no piston-driven prop planes in scheduled transport airline use in Europe. Everything out there is turboprop - a turbine with a gearbox driving the prop. It will have same problems as any other turbine would.
1. Windshields will get sandblasted. Maybe not during one flight, but give it a week or two and they'll be replacing their windshields. $100k is the order of magnitude I believe.
2. Every part of the engine that runs at high temperature will get ash caked on it. Does wonders to high pressure turbine efficiency. I don't know if APUs on modern airlines power hydraulics, but they better did, and you better hoped that the APU will survive the ash treatment as well.
3. Seals that are airtight usually are not dust tight -- I know, it's counter-intuitive, but that's how it is, especially with seals over rotating shafts. The oil in those engines will make sure that the ash is redistributed to the bearing surfaces running at highest temperatures -- where it can do most damage.
When you get crap caked on inside of the engine, you don't "replace things earlier". You're talking about replacing the engine, and doing a full overhaul on the one you took out. Figure $1M o.m. for two high bypass turbofans maybe?
Look up on wikipedia or elsewhere as to what county she lives in. Go to that county's auditor's website, look up her property by name. That's about it.
Maybe just for curiosity's sake, you should have her genetically tested to see if maybe she has some mutation that is a "partial" Williams: mental only without physical problems.
Slashdot Mirror
And you can use crutches as beating sticks, too.
The "hardware" support is not in any real hardware. We're talking DSP code for most portable devices, AFAIK. All it takes is writing some more code to support it just as well. Or am I wrong?
What prevents you from buying a bunch of AAPL stock and getting rich with them? I just don't get it :(
I'm not so sure about SL having "about the same bugs" as Windows. My up to date Windows XP VM instance blue-screens about once a week, and I know of one way of getting it to reproducibly blue screen -- it's some weird interaction of the VS9 debugger and the USB stack (unrelated to VMware -- happens on bare hardware, too). The underlying OS X has never had a kernel panic for me, and I have only had to do hard reboots due to a frozen system twice (some AFS-over-WiFi issues) -- that's over combined 4 years of owning OS X machines (3 years for iMac, 1 year for MacBook Pro). For me, that's a track record better than up-to-date rather stock RHEL 5 installs.
Some control happens at the local (OR) site. For example, if you want to maintain a frame of reference that's locked onto the moving heart surface, then there's no reason to have the loop closed across the ocean. Locally is just fine. All that the remote (surgeon) site has to do is to flip a bit to enable the lock.
I'd actually like to have a good bastard doctor like House. So far my experience has been with lots of residents, who -- when subjected to any sort of unknown/unexpected stuff that they don't have an instant answer to -- turn into clueless bastards.
I'd much rather have a clueful bastard, than a clueless bastard who is a bastard to mask his/her cluelessness.
BTW, this is all from recent experience at a big ten ED. I think by now even I would know how to do a less painful pelvic exam than that girl had done.
I think NeoOffice has a slightly better track record -- for me at least. I have had it crash once in the last 1.5 years of using it. Maybe I'm just a weird user or something. I know it's just OO.org, but methinks the use of their custom (java-based) UI frontend somehow helps with things, somehow.
I've tried native OO.org for OS X recently, and it felt like crap in comparison. And yes, it did crash -- twice during one day of testing.
So I hold NeoOffice folks in high esteem. But that's just me.
Quite seriously, I would call a city-wide WAN (particularly on the scale of SF) considerably more complex than
flying the space shuttle. Even a highly competent network engineer might take months to map the whole thing out starting
with nothing but a handful of router passwords.
A lot of the Space Shuttle "documentation", such as mission checklists, is public. Feel free to browse through it. You'd need a week of hard work just to familiarize yourself with the acronyms. If you think that a city-wide WAN is more complex than a shuttle mission, you must have never listened to realtime feeds from NASA TV. Just listen to landing replays -- those are played after the touchdown at KSC (or AFB), and include realtime audio as they shut down things before egress. It takes an hour+ just to shut it down. That's after you're down at the end of the runway and, if you were you, you'd feel like just opening the hatch and going for a walk.
Sure, people fail, but when that failure is criminal, then the organisation shouldn't assist in covering it up, and certainly not allow it to continue. I can accept that bad stuff happened in the '60s and '70s, and that they weren't prepared to deal with it then. But once high-ranking officials became aware that abuse occurred, they should have made absolutely sure that it wouldn't happen again.
Umm, why weren't they 'prepared to deal with it then'? What's so special about '60s and '70s. Were we somehow all less aware, as a human race, that pedophilia and child abuse are bad back then? WTF?!
But Section 2080 of the Civil Code is not the Penal Code. He can't be jailed for violating Section 2080, only sued; and since Apple got their prototype back, that's unlikely, because they won't be able to show damages; the main obligation of a depositary (detailed in CCC 1822-1828) is to give the item back.
California Penal Code 485 requires only "reasonable and just efforts to find the owner and to restore the property to him".
That! Wish I had mod points.
It is fine with me if he wants to be compensated for an act of God. However, the being responsible for the act of God should be paying the compensation, not the British government.
So, Earth's Mantle should pay him??
It is morons like the guys you are responding to, who take flying for granted, that demand to never be inconvenienced in this amazing world, who really don't deserve to be let on a plane again.
Yep.
I guess he will ask for a govt bailout once the bill comes. After all, the govt didn't "protect" them enough (from their own stupidity), right? Yea, right.
Not only that. Let's not forget two important fluids: fuel and engine oil. Engine shaft seals may not be dust-tight enough at the concentrations of ash encountered here, so you risk contaminating engine oil with an abrasive. Considering that engine oil film is *the* bearing for a lot of parts in the engine, that's not good.
As for fuel: the fuel tanks are vented to the atmosphere. Ash will settle down and contaminate the fuel. So you'll have to periodically flush the fuel system. Downtime = $$.
Ahh, you're in the "let's kill all quadriplegics to shorten their suffering" camp.
Get in the car, get an eye tracker, and have your eye movements recorded and superimposed over the head camera. Then come back.
It's not even that "abnormal distractions would be bad" -- it would be completely, absolutely crazy to drive like that.
Landing a plane, on the other hand -- that I could potentially agree on. Some studies show pilots staring at the far end of the runway say from 200ft down to ground contact, so that could potenitally work. It's sort of a reflex thing they do in visual conditions.
Driving on a long stretch of straight road sometimes looks like that too, when you analyze the eye movements.
But in "normal" driving, not only the instantaneous eye position is uncorrelated with desired steering wheel input, but also long-term averages are generally uncorrelated.
Basically, to drive with eye position as the control input is to become blind, to a large extent. I have played a little bit with using eye movement in various control input scenarios, and the only conclusion I came to (in an informal study) was that you can obviously learn rather well to use eye position as the control input. Heck, with audio feedback you can learn even faster, but you become progressively more oblivious to what's going on around you. This may, perhaps, be thought to be "OK" at first sight, as you'd think it rather keeps you focused on a particular area of the surroundings -- just that on curves it usually ends up being anywhere but on the road. So you literally feel like driving in a tunnel. Forget looking at street signs, or navigating in unfamiliar environment. And you better never had to change lanes.
Remember that the raison d'être of our visual system is exploration of our environment. This also happens when we drive. Eye position will depend on what interesting stuff is out there, not on which way you are driving.
There's a lot of "eye movments to control this or that" type of studies. Unfortunately, the idea came from science fiction, and belongs on the same shelf with "cleaning up" SD interlaced surveillance video full of compression artifacts to "clearly" see a face that's six pixels across. Such studies certainly have a lot of appeal to the general public, and to anyone who doesn't quite think it through or understand the basic conflicts of purpose involved in using eye movments for something they just can't do while simultaneously maintaining visual awareness. This is the same fantasy as using eye movments for interacting with machine user interfaces: all fine and dandy, as long as you don't need to see/explore the damn interface. If you have the UI all memorized, and ideally are provided with audible cues to help you navigate, you can use eye movments. But the moment you want to look around, it becomes all screwed up.
Now, in situations where you don't give a damn about maintaining visual input -- you can use eye movements for whatever control inputs you please, and they are quite good for that. Heck, the input is at least 3-dimensional: you can choose not only the direction vector, but to some extent the amplitude of the initial saccade.
So -- eye movements are great for controlling a car, as long as you're in the passenger seat, and the driver makes sure you won't run over the old lady, and won't drive off the end of a closed bridge -- IOW, as long as you don't need to actually see most of what's outside the window.
There are of course ways to devise some special patterns of eye movements that switch the modality of the controlled device/interface, so that you can work around the conflict between controlling and visual exploration. But those hardly feel natural. Those are very fine things to do if the alternative is even worse -- say, if you're paralyzed and all that's left is eye motion. But without training and adaptation the eye movement control has anything but "natural feel" to it.
Burglars no longer need to visit an area to scout it to check for targets. The common argument from the pro-street view group against this is that well anyone could come down and take a picture for the same effect- that's true, but here's the difference, using my house an example. I live on a cul-de-sac, to get to my house and take pictures without someone noticing a guy with a camera would take some doing, everyone on our street knows everyone else, if someone came down, and turned around, someone would see them. If there was a subsequent burglary, then there would be witnesses who could point the police in the right direction in terms of a number plate, or a description of a person, or person(s) looking dodgy.
If you seriously believe that, you live in a fantasy.
If what you claim is true, then what was the make/model/plate# of the google street view van? Was the driver a male or female? How many of your all-the-time-alert neighbors saw it? After all, those things aren't exactly inconspicuous!
I live on a cul-de-sac, too. There's noone here during regular working hours. You could literally have a film crew here for 2-3 hours a day, and noone would know.
If your cul-de-sac has a house or two with retirees, or stay-at-home moms, I really doubt all they do is sit by the window the whole time, and write down every license plate number.
My bet is thus: if I wanted to, I'd just take an HD camcorder, give it to my wife in the passenger seat -- or, heck, to my kid on the back seat, one of them would take the shot, while I'd drive into the cul de sac, turn around, and drive out. I'd say my chances are 1:50 that anyone would recall an "out of place" car being there, 1:1000 that anyone would know the make/model, and 1:10'000 that someone would know how many people were in the car, that someone was filming, and the license plate #.
The reality is exactly opposite to what you insist: if I want to physically scout a location, I won't be seen, there will be no witnesses, and there will be no suspicion. Cameras these days are rather inconspicuous, even HD cameras. I can have one in my hat, and just walk around, with a kid or two in tow. Or I can just drive around with a dash camera. Heck, I could probably get something flat and inconspicuous-looking magnetically attached to one of the mailboxes around here, if I wanted to see the people's comings-and-goings in real time, from a safe distance.
About the only point you may have is that the high vantage point requires a sufficiently tall vehicle, and couldn't really be inconspicuously replicated without having a camera in, say, a gyroscopically stabilized ball. Maybe it's a good idea for a project! Let's see who can throw the ball higher in the air, kiddo! And when we come home, we can review how high it flew ;)
Provable as to what? In any case, a lot of code written in dynamic languages is really not that hard to reason about. Everything depends on what features of the language do you use, and how you use them. You can write perfectly functional side-effect-free code in Python. The compiler won't enforce it for you, but you can do it.
Caller ID is *not* in-band any more than connection routing is.
I have a T1 ISDN link in the U.S. There are 7 dynamic voice trunks on that T1 link. We have a pool of multiple phone numbers.
When the call is being set up, my switch (asterisk) sends out a message indicating the calling number. The contents of this message are taken by our telco's switch at face value, as long as the number is 10 digits long.
This number is recorded in the detailed billing statement we get (for international / overage long distance), but it is not actually used for billing by our telco! Any call going out through our T1 link is billed for by the telco, no matter what garbage is being sent out as the calling number identification.
I can set asterisk to send any number, and that is the number that will be displayed to the called party. I have been experimenting with setting up a local GSM mini-cell to make use of cellphones within the building essentially "free", and obviously if such calls were routed over our ISDN link, the indicated numbers would be those assigned to the cell subscriber, not those of our number pool.
We obviously don't use it for anything nefarious, but I presume that many VoIP trunk providers will do it in the same way. It's somewhat hard for them to really filter the phone numbers on egress, since they may not have full knowledge of all phone numbers assigned to us: for example, we may have an 800 number through another provider that we want to display, or even a bunch of regular numbers via another provider B, that are being routed out via provider A due to -- say -- link loss caused by a backhoe two blocks down the street.
So this is nothing about in-band vs. out-of-band. It is about making the phone system work as you'd expect, vs. making things hard.
The only technical solution would be a realtime database used for egress filtering of calling number identification -- it'd link together all phone numbers assigned to a particular subscriber. And then we again run into problems of what really is a subscriber: suppose you have separate units of a big corporation, that get separately billed for service, and are really considered separate subscribers. Now suppose that for redundancy and continuity of service, the IT/comms people in Unit A and Unit B agree to carry the other unit's data and voice traffic to maintain service in cases of various failures. Now the realtime database needs respond as if both subscribers were one. And so it goes -- it's
not exactly trivial.
Making it illegal to purposefully mislead people is OK in my book.
Don't believe that big corporations are omniscient. They have no experience flying through such conditions, and have no fscking clue as to how much that will cost. All they're doing now is betting that flying will cost less than standing down. They really don't know how it's going to turn out. You can't even go out there and hire a consultant to figure it out: noone was routinely flying in such conditions.
AFAIK, there are no piston-driven prop planes in scheduled transport airline use in Europe.
Everything out there is turboprop - a turbine with a gearbox driving the prop. It will have
same problems as any other turbine would.
Two things will happen:
1. Windshields will get sandblasted. Maybe not during one flight, but give it a week or two and they'll be
replacing their windshields. $100k is the order of magnitude I believe.
2. Every part of the engine that runs at high temperature will get ash caked on it. Does wonders to
high pressure turbine efficiency. I don't know if APUs on modern airlines power hydraulics, but they better
did, and you better hoped that the APU will survive the ash treatment as well.
3. Seals that are airtight usually are not dust tight -- I know, it's counter-intuitive, but that's how it is,
especially with seals over rotating shafts. The oil in those engines will make sure that the ash is redistributed
to the bearing surfaces running at highest temperatures -- where it can do most damage.
When you get crap caked on inside of the engine, you don't "replace things earlier". You're talking about
replacing the engine, and doing a full overhaul on the one you took out. Figure $1M o.m. for two high bypass
turbofans maybe?
Look up on wikipedia or elsewhere as to what county she lives in. Go to that county's auditor's website, look up her property by name. That's about it.
If you use citicards, the URL you're looking for is
here.
Maybe just for curiosity's sake, you should have her genetically tested to see if maybe she has some mutation that is a "partial" Williams: mental only without physical problems.