Alternatively, local apps that synchronize to a server could serve both purposes. In an ideal world, the only case where web apps would be more convenient than native apps is when you don't have your own computer with you, e.g. using somebody else's computer for checking your mail or whatever. It's also a security hole so big you can drive a truck through it, so one could reasonably argue that this is a bad idea....
ISPs have a strong incentive to reduce heavy bittorrent traffic on their networks so they don't have to upgrade as often. If they can delay these upgrades under the guise of supporting intellectual property rights, it's a win win for them. I'm not saying I support this kind of thing, but it makes business sense.
On the flip side, ISPs have a strong incentive to reduce heavy BitTorrent traffic that goes into or comes out of their networks far, far more than traffic within their network. If I were managing an ISP, I'd be analyzing BitTorrent traffic to find out how much of it is staying locally, and using that to decide whether it's worth looking for a way to extend the protocol to prefer nearby seeds by adding additional DHCP response fields, by doing something clever with mDNS, etc. Heck, if I were managing an ISP, I'd be contributing code to BitTorrent to allow ISPs to specify information about the IP ranges within our regional network and the cost of uploads/downloads through our various peer ISPs, thus allowing the P2P client to weight its traffic towards connecting to other P2P peers that are cheaper for the ISP if all other things are equal, and allowing the P2P client to more effectively use bandwidth by making sure that only one P2P client within the regional network pulls each chunk of a given file through the expensive upstream pipes, then seeds it to the other peers through the faster regional network. Performance should improve on the average *and* the cost to the ISPs would go down.
Also, it's not entirely true that web apps don't interact with the clipboard. They are, however, limited to certain types of content (basically plain text, styled text, or HTML, IIRC) when doing so.
Only from another web window from the same domain, though. Local file URIs cannot be pasted in because it would be a cross-domain violation. And when you copy and paste between email messages, you're really just copying and pasting a URI. Since the server knows about that URI, it can deal with that. If it's a file URI on your local hard drive, the server has no way to fetch the image from your hard drive, nor does the recipient, so the other person would get a broken image icon (if the server even bothered to pass the <img> tag through at all).
Actually, in a proper web app, you take advantage of onbeforeunload. For example, consider the fairly minimal web app used in the Safari Client-Side Storage and Offline Applications Programming Guide. It's not described in the documentation, but in the complete sample (part of the companion files archive), it does this:
/*! This returns a string if you have not yet saved changes. This is used by the onbeforeunload
handler to warn you if you are about to leave the page with unsaved changes. */
function saveChangesDialog(event)
{
var contentdiv = document.getElementById('contentdiv');
var contents = contentdiv.contentDocument.body.innerHTML;
var origcontentdiv = document.getElementById('origcontentdiv');
var origcontents = origcontentdiv.innerHTML;
// alert('close dialog');
if (contents == origcontents) {
return NULL;
}
return "You have unsaved changes.";// CMP "+contents+" TO "+origcontents;
}
/*! This sets up an onbeforeunload handler to avoid accidentally navigating away from the
page without saving changes. */
function setupEventListeners()
{
window.onbeforeunload = function () {
return saveChangesDialog();
};
}
When you are using this and you try to navigate away from the page, whether with back/forward buttons or with the close button, the browser displays a dialog box. If users click "OK", then yeah, they lose their changes. If they click "Cancel", then the back/forward/close clicks are ignored and they're dropped back into the web app.
Note that the handler function must *not* call alert() itself. It must do as little work as possible and must return a string for the browser to display. The "You have unsaved changes." bit comes from the script. The rest of the dialog box is browser-specific. Note that you cannot do very much in this function or the browser will ignore the handler entirely. That's why a lot of folks seem to believe that Safari doesn't support onbeforeunload.... In the case of Safari, this bit of code generates a dialog box that looks something like this:
JavaScript
Are you sure you want to leave this page?
You have unsaved changes.
Click OK to continue, or Cancel to stay on this page.
Many, if not most, have electronic keys that can only be duplicated at a dealership and are expensive.
But those keys can't be stolen, wiped, and used for anything other than unlocking similar models of cars, they don't run down and deny you access to your car (or at least not until they're more than a decade old), and they don't require you to enter a complex set of PIN numbers on a touch screen while you're holding stuff in your arms trying desperately to get your car unlocked. Not to mention that people over about 25 are likely to not use a PIN at all, so now when they leave their iPods lying around accidentally, they've also potentially lost their cars.
I could see this being useful for families with kids so that they can unlock the car when they need to get something without having to ask their parents for the keys. Beyond that, this concept only makes sense if they drop the PIN requirement and license the technology to others, e.g. for use in the actual car keys. Even then, passive RFID makes a *lot* more sense for power consumption reasons.
I would kill to be able to walk up to my car and have the doors unlock when I got within a few feet. No buttons, no PIN numbers, just the physical proximity of the key. Why don't we have this yet? It's trivial, obvious, and all the required technology has been in existence for at least a decade. I don't think I'd want it to be tied to something like my iPhone, though, simply because it is so much easier to lose a phone than a bunch of keys.
Just to be clear, I'm not saying it wasn't hopeless. It probably was. I'm just saying that I wouldn't automatically assume that her prognosis was obvious nearly as early as you think it was, assuming they treated her correctly. The questions you didn't provide the answers for (e.g. are the pupils blown, is there EEG activity, does an MRI show hematomas, does an fMRI show dead areas, is part of her head physically missing, etc.) are far more important for determining prognosis than the amount of swelling, IMHO.
The amount of swelling of the brain is not always a good indication of the level of damage. There are many causes of swelling, some of which are pretty much guaranteed to indicate serious damage (e.g. a hematoma caused by severe hemorrhaging) and some of which aren't (e.g. edema that might not cause too much permanent damage if the skull is opened up and the brain is allowed to expand temporarily until it can heal). A lot of the more serious damage in traumatic brain injuries occurs well after the initial impact, due to edema compressing the brain against the skull, causing further bruising and cell death. And a lot of damage due to the initial bruising can be headed off by prompt administration of the right medications (steroids, anti-inflammatory drugs, possibly blue dye #1...).
In other words, a lot of the things you saw as signs of hopelessness were actually part of the normal course of treating such an severe head injury and might or might not have been sufficient to consider her prognosis poor. Her prognosis probably was poor, but it wasn't poor for those reasons....
That said, IANAMD, so take this with a grain of salt.
The tens of thousands of lines of code I was referring to are the underlying XML parser. The libxml2 library that the majority of open source XML libraries are built on top of is almost 239,000 lines of C code, and that's not counting headers....
I'm assuming by "brain leaking out", you mean that they performed a decompressive craniectomy. With such treatment, even someone with a severe head injury has some chance of survival without serious damage. What the doctor did in this case might not be at all unreasonable, depending in large part on a lot of subtle considerations like whether the patient had good pupil response on admission, the age of the patient (which in this case leads to a much better prognosis than with an older person), etc.
In one (admittedly small) study of severe head injury cases (all of which, AFAIK, would likely have been described in much the way you described this case), fully half of the people who underwent such surgery survived, and a third survived with no or minor disability.
In other words, the outcome is not always clear from outward appearance or even from the severity of impact. The doctor might well have legitimately thought the girl had a reasonable chance of recovery. Nine days is not really unreasonable. Brain swelling can easily continue for a couple of weeks, and I actually had a teacher once who was in a coma for many months (or was it years, I forget). I'd have to know a lot more than you've given me before I would agree that the case was hopeless.
It's a fine line, though. If it has to be delivered once, perhaps. The fifth time you make a programmer spend $10 in fuel to deliver a $1.50 soup cube, the programmer you canned will already have a job at a better shop while you, the manager, will be asking people for change at the highway off-ramp.:-)
For most things, performance isn't that important, but in aggregate, performance is pretty important. It's not a big deal if it takes ten extra seconds to do a task because the server is a little slow, but if you do that every couple of minutes, you've just wasted forty minutes per day. It's a constant balancing act between using higher-level frameworks that save development time and using lower-level code that improves performance.
Agreed, mostly. If you have an XML parser for free (e.g. in a web browser), them XML is a great way to push structured data around. If you have to roll it yourself, it's horrible. Using libraries, it's somewhere in-between, depending. If you're going into a toolchain that expects XML or if you're working with a lot of structured text data, XML is probably a good choice. That said, it's quite possibly the most overused technology. Far too many people just automatically use XML where CSV file or tab-delimited text file would do the same job with tens of thousands of lines less code.....
And regular expressions are for light text processing and/or single-use (write-only) tools. Using them where a parser would normally be used is the quickest way to create fragile code that breaks constantly.:-) Been there, tried to maintain that, then ripped it all out and wrote a token-based parser.
First of all, animals raised in human company are pretty much permanently stuck in a juvenile state. They have not been taught to fend for themselves and the urban and suburban environments aren't the same thing as "the wild" - available resources are far more restricted. Don't think that because your cat occasional brings a bird to the stoop that it could live a healthy life without any human support. It is certainly not humane to release an animal only to have it starve or be maimed by a car.
I never said domestication doesn't make their chances worse. I said that it doesn't make their chances zero, and probably doesn't even come close.
Tell you what. I'm guessing you're pretty domesticated. Centuries of not hunting makes you unprepared to live in the wild. What would you if I gave you a similar choice? Somebody can euthanize you or we can turn you loose in a forest and you can learn to kill things with sticks and hunt roots and berries. Your choice. Somehow, I don't expect you to choose the first choice. I can't imagine that pets would, either.
It's irrelevant whether domestication contributes to some of the deaths. A lot of factors that aren't an animal's choice affect their survival, from weather-induced changes in food supply or snowfall making brown-furred animals more visible to airborne predators to injured wings, broken legs, etc. It makes no sense to suggest that if an animal would be disadvantaged in the wild, it is better for that animal to be put down than to allow it to have a chance at surviving. Animals are randomly disadvantaged in the wild all the time and we don't intervene and kill all of them. What matters is not whether an animal is disadvantaged, but rather how much it is disadvantaged.
What percentage of pets would be able to survive in the wild? Is it 30%? Is it 80%? Is it 3%? At 3%, most people would suggest that euthanizing them is more humane. At 80%, most people would suggest turning them loose. At 30%, there's a lot of room for debate. I'd expect it to be a lot closer to 80% than to 3%, but there's only one way to find out for certain: turn loose a whole s**tload of unwanted pets with tracking collars and see what happens. Short of doing that, we're really just guessing here.
You're dodging the issue, though. They are not unable to find food and water because of their domestication. They are unable to find it because it is not there to be found. The links I provided make it obvious that a certain percentage survive even in relatively harsh environments where they were never meant to live on their own. Nobody is suggesting releasing animals in such environments. There are plenty of places where food and water are plentiful. Release them in the woods near a continuous stream out in the country and most cats should do fine---probably most dogs, too, with the exception of the tiny ones....
Yes, animals die if they can't find food or water. That's a pretty big duh. Whether pets can survive in the wild or not depends in large part on the location. My point was that escaped pets can and do survive in the wild all the time. Heck, the entire reason we have feral house cats in the wild at all is that some of them got out at one time.
Regarding the feral cats in Hawaii being hungry, that is in large part due to it being an island, cut off from the rest of the world, with limited space and resources. Although they merely survive in such an inhospitable environment, they can (and do) thrive in Tennessee on farms where there is a plentiful population of mice, moles, birds, insects, etc. for them to feed on and nearly unlimited space for them to spread out, thus not having to compete for a highly limited food supply. There's simply no good reason to euthanize cats unless they are severely injured or diseased. There are tens of thousands of farms out there, and I doubt you'd find even one that would refuse an extra mouser.
The question was not whether it's ethical to release animals out into the wild. That's a much more complex question involving the impact on the population of other animals, and there's really not an easy answer to that question, as it depends highly on the specifics---the animal, the location, the local flora and fauna, etc. The questions were whether it is humane for those animals, and whether they are so dependent on humans that they can't survive on their own. Clearly the answers to those questions are "yes" and "no", respectively.
...don't even address the fact that just because some animals survive doesn't mean all of them will, nor that they will even thrive...
Not all wild animals survive in the wild, either. Do pets have worse odds of surviving than animals that grew up in the wild? Sure. That said, if I were given the choice of being tossed out in the wilderness with only a 20% chance of surviving or being shot and killed, you'd better believe I'd take my changes with the woods. I find it rather hard to believe that anyone rational would choose otherwise for themselves. How is it, then, that animals with any sense of self should be treated differently?
No. First of all, animals raised in human company are pretty much permanently stuck in a juvenile state. They have not been taught to fend for themselves and the urban and suburban environments aren't the same thing as "the wild" - available resources are far more restricted. Don't think that because your cat occasional brings a bird to the stoop that it could live a healthy life without any human support.
I'm glad somebody brought that up. I'd much rather have an animal abuser registry than a sex offender registry for precisely this reason, though both of them are pretty bad ideas.
Animal abuse tends to be fairly narrowly defined to include the sorts of cruelty indicative of serious psychological problems on the part of the abuser. These folks have a significantly higher risk of harming people later in life according to numerous studies.
By contrast, there are teenagers on the sex offender registry for having sex with their 17-year-old girlfriends. The sex offender registries are sufficiently over-broad and diluted so as to make them nearly useless in practice. They stigmatize people who should not be stigmatized, and the result is that may people who otherwise would not commit a crime are forced into very limited lives that make them far more likely to commit crimes in the future.
That said, being a convicted criminal makes someone's life harder. People won't hire them, and they are marginalized by society. The result is predictable. They get desperate and do whatever it takes to survive, which usually involves committing another crime. The absolute last thing we should be doing is making it even harder for them to reestablish their lives, but that's precisely what these registries do. These registries are essentially like being on parole for life.
If a crime is committed and the person is believed to be likely to commit that crime again, they should not be released. If they are believed unlikely to commit that crime again, then there's no benefit to having them the registry. Either way, the registries are just a Band-Aid for a broken system of justice that is inept at judging the risk of recidivism. We need to fix the real problem, not patch around it with hack on top of hack that each create ten problems for every one problem that they solve.
The thing is, to the degree that the USB device doesn't require a special driver, that's because their hardware is conforming to the USB HID spec, which is a lot like conforming to the Bluetooth HID spec, just without the pairing/key exchange stuff.
It's true that the Bluetooth spec is a lot more complex because you have software control over the key exchange process on the user's machine (as opposed to presumably having to do some similar process once at the factory). Fortunately, that's all somebody else's problem (the silicon vendor). This makes it important to choose wisely when picking the Bluetooth silicon, but that's still a lot easier than designing equivalent parts from scratch.
I think what's going on is it's losing its connection with the mouse and wanting to reauthorize it before it starts doing its bidding. I would even be willing to bet that it isn't the software or the driver, but the OS doing this!
I'm not a Bluetooth protocol specialist by any means, but IIRC, the device generates a key, and both ends have to store that key. The computer doesn't reject a device arbitrarily. Communication fails because the device's key no longer matches any key that the computer knows, and thus the computer cannot talk to the device at all. It seems unlikely that the computer would lose a key unless the stack implementation is just plain broken. After all, it has a hard drive to write the keys onto. It's much more likely that the device itself is losing the key or is deciding to generate a new key for some reason, probably either because of the pairing button getting pressed (intentionally, accidentally, due to insufficient case clearance near the button, etc.) or due to the batteries running down.
For example, I have one Bluetooth device that destroys its old key and generates a new one if you hit the pairing button (this is normal), and fails to restore it if you cancel pairing by power-cycling the device (this is annoying). I solved this little accident waiting to happen with a piece of tape and a penny on the bottom of the unit....:-)
And that's a pretty serious problem. In my experience (which admittedly is mostly as a user, not an admin), most OSes aren't happy with high-latency wireless networks. With a fast, low-latency network with no packet loss, it can take a couple of seconds to do a DHCP request. With a slow, high-latency link with packet loss, I've seen it take a couple of *hours* to do a successful DHCP request. Sadly, such connections are easy to get when you have a few dozen people on an AP downloading porn^H^H^H^Hmovies^H^H^H^H^H^Hlegitimate software bits.
Something you might do to alleviate this is to use the 10 network for all your access points. Never reuse IPs and set your DHCP server to cache IP assignments and always ack when a host requests to extend its assignment. Oh, and set the lease time to a month or something. Doing this should reduce the number of DHCP packets that have to be sent. IIRC, for a re-request, you're down to one packet in each direction instead of (at least) two in each direction. Of course, if you can't get the response back within about two seconds, the client is likely to give up and fall back to a full-blown DHCPDISCOVER....
You should probably use a fast switch with a fast backbone between the APs and your core router/DHCP server to minimize latency between the AP and your DHCP server.
I would not use the same machine for the upstream router and the DHCP server. By keeping those separate, you are further reducing the wired portion of your latency because your DHCP discover/request packets aren't getting backed up behind outbound network traffic on the wire. Be sure to use a reasonably fast box for the DHCP server and a FAST box for your router/firewall/NAT box. Do not, under any circumstances, use the NAT built into any consumer router boxes.... The CPUs just aren't anywhere near fast enough.
Get several radios going, crank the gain down as much as is practical without losing bars of signal as seen from the devices, use directional antennas to dice up the space into as many distinct zones as possible, and organize the zones to maximize the distance between APs on the same channel. I'd probably put external antennas spaced periodically down each wall in alternation, forming a series of alternating cone-shaped zones. The exact distances depend on the spread angle of the antenna and the width of the room. Alternatively, you might consider hanging them from the ceiling pointing down, spaced in a grid formation.
If you can, try to make your APs give top priority to DHCP messages, thus minimizing the number of these packets that get dropped before they make it out (in either direction).
Oh, yes, and turn off 802.11b support if you can. Allowing 802.11b means that every packet sent at high speed requires additional crap before and after it so that the 802.11b radios don't choke. If that's not possible, set up a separate segregated network for legacy 802.11b clients and stick it on its own channel---probably one AP for the whole room.
Finally, if at all possible, make sure your DHCP server sends ACK using unicast where possible. AFAIK, every major OS should be able to handle this. IIRC, broadcast packets on 802.11 are particularly expensive. The more you can minimize them, the better off you are. While you're at it, crank up the multicast rate (basically, the minimum signal level that a client must maintain before the AP throws you out). This will force clients to associate with new stations more frequently, but should increase network performance and decrease latency under (particularly multicast/broadcast) load.
Oh, and one more thing. I'd like to echo the comments about not using home router gear. Get yourself Cisco APs. Most home routers just don't have the CPU to keep latency low enough when routing that much traffic, and many don't have sufficient control over power levels, external antenna jacks, etc.
You're grossly underestimating how hard it is to get the physical layer working with sufficient noise immunity. When designing a cheap device, you can't spend a lot of money on R&D. You have two choices:
Custom hardware. With custom hardware, you first have to make a reliable physical layer that moves the bits through the air reliably even in the presence of interference. Then, you have to write custom drivers for the transmitter silicon, custom drivers for the device on the other end, and custom firmware for the device.
Bluetooth hardware. With bluetooth hardware, the physical layer is basically designed and debugged for you except for the antenna. The drivers for the transmitter are written for you. So you just have to write some very minimal custom firmware for the device to map electrical inputs to buttons and *maybe* write a custom driver for the device if you're doing something particularly unusual (e.g. handlers for extra buttons).
If your hardware sucks and you can't reliably get a signal through the noise (which has been the case with almost every non-Bluetooth wireless device I've seen), you're pretty much screwed. By contrast, if your firmware sucks in the first rev, it's no big deal. You just flash the thing with new firmware. That's the advantage to using Bluetooth. The hardware layer is already completely designed and debugged for you, so you can focus on the protocol layer above it and get that right instead of having to do that *and* build your own (usually awful) hardware.
I view these things basically the same way as companies that write custom crypto algorithms. The results are almost invariably worse than if they used off-the-shelf technology underneath and focused on the upper layers instead.
Sounds like the mouse sucked, yes. That's certainly not normal. With good hardware, you have to explicitly hit a button to cause it to repair.
As for me, I won't buy wireless hardware that isn't Bluetooth. Bluetooth gear, in my experience, works reliably at 20-30 feet on average. Non-bluetooth gear gets jammed by random environmental noise and barely works at a foot or two from the receiver. I've seen this with many, many wireless keyboards and mice from many companies (including the major ones).
Proprietary communications technology SUCKS. A few bad devices notwithstanding, Bluetooth devices will always be more reliable than proprietary hardware because Bluetooth has hundreds of companies all working together to design the communication protocols and hardware instead of one company hacking something together on their own. When it comes to keyboards, mice, trackballs, etc., if it's not Bluetooth, as far as I'm concerned, it isn't really wireless.
Slashdot Mirror
Alternatively, local apps that synchronize to a server could serve both purposes. In an ideal world, the only case where web apps would be more convenient than native apps is when you don't have your own computer with you, e.g. using somebody else's computer for checking your mail or whatever. It's also a security hole so big you can drive a truck through it, so one could reasonably argue that this is a bad idea....
Err... line 2.
Syntax error line 4. got ) without matching (.
On the flip side, ISPs have a strong incentive to reduce heavy BitTorrent traffic that goes into or comes out of their networks far, far more than traffic within their network. If I were managing an ISP, I'd be analyzing BitTorrent traffic to find out how much of it is staying locally, and using that to decide whether it's worth looking for a way to extend the protocol to prefer nearby seeds by adding additional DHCP response fields, by doing something clever with mDNS, etc. Heck, if I were managing an ISP, I'd be contributing code to BitTorrent to allow ISPs to specify information about the IP ranges within our regional network and the cost of uploads/downloads through our various peer ISPs, thus allowing the P2P client to weight its traffic towards connecting to other P2P peers that are cheaper for the ISP if all other things are equal, and allowing the P2P client to more effectively use bandwidth by making sure that only one P2P client within the regional network pulls each chunk of a given file through the expensive upstream pipes, then seeds it to the other peers through the faster regional network. Performance should improve on the average *and* the cost to the ISPs would go down.
Also, it's not entirely true that web apps don't interact with the clipboard. They are, however, limited to certain types of content (basically plain text, styled text, or HTML, IIRC) when doing so.
Only from another web window from the same domain, though. Local file URIs cannot be pasted in because it would be a cross-domain violation. And when you copy and paste between email messages, you're really just copying and pasting a URI. Since the server knows about that URI, it can deal with that. If it's a file URI on your local hard drive, the server has no way to fetch the image from your hard drive, nor does the recipient, so the other person would get a broken image icon (if the server even bothered to pass the <img> tag through at all).
Actually, in a proper web app, you take advantage of onbeforeunload. For example, consider the fairly minimal web app used in the Safari Client-Side Storage and Offline Applications Programming Guide. It's not described in the documentation, but in the complete sample (part of the companion files archive), it does this:
handler to warn you if you are about to leave the page with unsaved changes. */
function saveChangesDialog(event)
{
var contentdiv = document.getElementById('contentdiv');
var contents = contentdiv.contentDocument.body.innerHTML;
var origcontentdiv = document.getElementById('origcontentdiv');
var origcontents = origcontentdiv.innerHTML;
if (contents == origcontents) {
return NULL;
}
return "You have unsaved changes.";
}
page without saving changes. */
function setupEventListeners()
{
window.onbeforeunload = function () {
return saveChangesDialog();
};
}
When you are using this and you try to navigate away from the page, whether with back/forward buttons or with the close button, the browser displays a dialog box. If users click "OK", then yeah, they lose their changes. If they click "Cancel", then the back/forward/close clicks are ignored and they're dropped back into the web app.
Note that the handler function must *not* call alert() itself. It must do as little work as possible and must return a string for the browser to display. The "You have unsaved changes." bit comes from the script. The rest of the dialog box is browser-specific. Note that you cannot do very much in this function or the browser will ignore the handler entirely. That's why a lot of folks seem to believe that Safari doesn't support onbeforeunload.... In the case of Safari, this bit of code generates a dialog box that looks something like this:
JavaScript
Are you sure you want to leave this page?
You have unsaved changes.
Click OK to continue, or Cancel to stay on this page.
(OK) (Cancel)
Good to know.
But those keys can't be stolen, wiped, and used for anything other than unlocking similar models of cars, they don't run down and deny you access to your car (or at least not until they're more than a decade old), and they don't require you to enter a complex set of PIN numbers on a touch screen while you're holding stuff in your arms trying desperately to get your car unlocked. Not to mention that people over about 25 are likely to not use a PIN at all, so now when they leave their iPods lying around accidentally, they've also potentially lost their cars.
I could see this being useful for families with kids so that they can unlock the car when they need to get something without having to ask their parents for the keys. Beyond that, this concept only makes sense if they drop the PIN requirement and license the technology to others, e.g. for use in the actual car keys. Even then, passive RFID makes a *lot* more sense for power consumption reasons.
I would kill to be able to walk up to my car and have the doors unlock when I got within a few feet. No buttons, no PIN numbers, just the physical proximity of the key. Why don't we have this yet? It's trivial, obvious, and all the required technology has been in existence for at least a decade. I don't think I'd want it to be tied to something like my iPhone, though, simply because it is so much easier to lose a phone than a bunch of keys.
Just to be clear, I'm not saying it wasn't hopeless. It probably was. I'm just saying that I wouldn't automatically assume that her prognosis was obvious nearly as early as you think it was, assuming they treated her correctly. The questions you didn't provide the answers for (e.g. are the pupils blown, is there EEG activity, does an MRI show hematomas, does an fMRI show dead areas, is part of her head physically missing, etc.) are far more important for determining prognosis than the amount of swelling, IMHO.
The amount of swelling of the brain is not always a good indication of the level of damage. There are many causes of swelling, some of which are pretty much guaranteed to indicate serious damage (e.g. a hematoma caused by severe hemorrhaging) and some of which aren't (e.g. edema that might not cause too much permanent damage if the skull is opened up and the brain is allowed to expand temporarily until it can heal). A lot of the more serious damage in traumatic brain injuries occurs well after the initial impact, due to edema compressing the brain against the skull, causing further bruising and cell death. And a lot of damage due to the initial bruising can be headed off by prompt administration of the right medications (steroids, anti-inflammatory drugs, possibly blue dye #1...).
In other words, a lot of the things you saw as signs of hopelessness were actually part of the normal course of treating such an severe head injury and might or might not have been sufficient to consider her prognosis poor. Her prognosis probably was poor, but it wasn't poor for those reasons....
That said, IANAMD, so take this with a grain of salt.
The tens of thousands of lines of code I was referring to are the underlying XML parser. The libxml2 library that the majority of open source XML libraries are built on top of is almost 239,000 lines of C code, and that's not counting headers....
I'm assuming by "brain leaking out", you mean that they performed a decompressive craniectomy. With such treatment, even someone with a severe head injury has some chance of survival without serious damage. What the doctor did in this case might not be at all unreasonable, depending in large part on a lot of subtle considerations like whether the patient had good pupil response on admission, the age of the patient (which in this case leads to a much better prognosis than with an older person), etc.
In one (admittedly small) study of severe head injury cases (all of which, AFAIK, would likely have been described in much the way you described this case), fully half of the people who underwent such surgery survived, and a third survived with no or minor disability.
In other words, the outcome is not always clear from outward appearance or even from the severity of impact. The doctor might well have legitimately thought the girl had a reasonable chance of recovery. Nine days is not really unreasonable. Brain swelling can easily continue for a couple of weeks, and I actually had a teacher once who was in a coma for many months (or was it years, I forget). I'd have to know a lot more than you've given me before I would agree that the case was hopeless.
It's a fine line, though. If it has to be delivered once, perhaps. The fifth time you make a programmer spend $10 in fuel to deliver a $1.50 soup cube, the programmer you canned will already have a job at a better shop while you, the manager, will be asking people for change at the highway off-ramp. :-)
For most things, performance isn't that important, but in aggregate, performance is pretty important. It's not a big deal if it takes ten extra seconds to do a task because the server is a little slow, but if you do that every couple of minutes, you've just wasted forty minutes per day. It's a constant balancing act between using higher-level frameworks that save development time and using lower-level code that improves performance.
Agreed, mostly. If you have an XML parser for free (e.g. in a web browser), them XML is a great way to push structured data around. If you have to roll it yourself, it's horrible. Using libraries, it's somewhere in-between, depending. If you're going into a toolchain that expects XML or if you're working with a lot of structured text data, XML is probably a good choice. That said, it's quite possibly the most overused technology. Far too many people just automatically use XML where CSV file or tab-delimited text file would do the same job with tens of thousands of lines less code.....
And regular expressions are for light text processing and/or single-use (write-only) tools. Using them where a parser would normally be used is the quickest way to create fragile code that breaks constantly. :-) Been there, tried to maintain that, then ripped it all out and wrote a token-based parser.
Certainly read that way to me.
I never said domestication doesn't make their chances worse. I said that it doesn't make their chances zero, and probably doesn't even come close.
Tell you what. I'm guessing you're pretty domesticated. Centuries of not hunting makes you unprepared to live in the wild. What would you if I gave you a similar choice? Somebody can euthanize you or we can turn you loose in a forest and you can learn to kill things with sticks and hunt roots and berries. Your choice. Somehow, I don't expect you to choose the first choice. I can't imagine that pets would, either.
It's irrelevant whether domestication contributes to some of the deaths. A lot of factors that aren't an animal's choice affect their survival, from weather-induced changes in food supply or snowfall making brown-furred animals more visible to airborne predators to injured wings, broken legs, etc. It makes no sense to suggest that if an animal would be disadvantaged in the wild, it is better for that animal to be put down than to allow it to have a chance at surviving. Animals are randomly disadvantaged in the wild all the time and we don't intervene and kill all of them. What matters is not whether an animal is disadvantaged, but rather how much it is disadvantaged.
What percentage of pets would be able to survive in the wild? Is it 30%? Is it 80%? Is it 3%? At 3%, most people would suggest that euthanizing them is more humane. At 80%, most people would suggest turning them loose. At 30%, there's a lot of room for debate. I'd expect it to be a lot closer to 80% than to 3%, but there's only one way to find out for certain: turn loose a whole s**tload of unwanted pets with tracking collars and see what happens. Short of doing that, we're really just guessing here.
You're dodging the issue, though. They are not unable to find food and water because of their domestication. They are unable to find it because it is not there to be found. The links I provided make it obvious that a certain percentage survive even in relatively harsh environments where they were never meant to live on their own. Nobody is suggesting releasing animals in such environments. There are plenty of places where food and water are plentiful. Release them in the woods near a continuous stream out in the country and most cats should do fine---probably most dogs, too, with the exception of the tiny ones....
Yes, animals die if they can't find food or water. That's a pretty big duh. Whether pets can survive in the wild or not depends in large part on the location. My point was that escaped pets can and do survive in the wild all the time. Heck, the entire reason we have feral house cats in the wild at all is that some of them got out at one time.
Regarding the feral cats in Hawaii being hungry, that is in large part due to it being an island, cut off from the rest of the world, with limited space and resources. Although they merely survive in such an inhospitable environment, they can (and do) thrive in Tennessee on farms where there is a plentiful population of mice, moles, birds, insects, etc. for them to feed on and nearly unlimited space for them to spread out, thus not having to compete for a highly limited food supply. There's simply no good reason to euthanize cats unless they are severely injured or diseased. There are tens of thousands of farms out there, and I doubt you'd find even one that would refuse an extra mouser.
The question was not whether it's ethical to release animals out into the wild. That's a much more complex question involving the impact on the population of other animals, and there's really not an easy answer to that question, as it depends highly on the specifics---the animal, the location, the local flora and fauna, etc. The questions were whether it is humane for those animals, and whether they are so dependent on humans that they can't survive on their own. Clearly the answers to those questions are "yes" and "no", respectively.
Not all wild animals survive in the wild, either. Do pets have worse odds of surviving than animals that grew up in the wild? Sure. That said, if I were given the choice of being tossed out in the wilderness with only a 20% chance of surviving or being shot and killed, you'd better believe I'd take my changes with the woods. I find it rather hard to believe that anyone rational would choose otherwise for themselves. How is it, then, that animals with any sense of self should be treated differently?
Oops. Misformatted the link for "and".
I think we should do an experiment. Release pets into the wild and see what happens.
Nature always finds a way.
I'm glad somebody brought that up. I'd much rather have an animal abuser registry than a sex offender registry for precisely this reason, though both of them are pretty bad ideas.
Animal abuse tends to be fairly narrowly defined to include the sorts of cruelty indicative of serious psychological problems on the part of the abuser. These folks have a significantly higher risk of harming people later in life according to numerous studies.
By contrast, there are teenagers on the sex offender registry for having sex with their 17-year-old girlfriends. The sex offender registries are sufficiently over-broad and diluted so as to make them nearly useless in practice. They stigmatize people who should not be stigmatized, and the result is that may people who otherwise would not commit a crime are forced into very limited lives that make them far more likely to commit crimes in the future.
That said, being a convicted criminal makes someone's life harder. People won't hire them, and they are marginalized by society. The result is predictable. They get desperate and do whatever it takes to survive, which usually involves committing another crime. The absolute last thing we should be doing is making it even harder for them to reestablish their lives, but that's precisely what these registries do. These registries are essentially like being on parole for life.
If a crime is committed and the person is believed to be likely to commit that crime again, they should not be released. If they are believed unlikely to commit that crime again, then there's no benefit to having them the registry. Either way, the registries are just a Band-Aid for a broken system of justice that is inept at judging the risk of recidivism. We need to fix the real problem, not patch around it with hack on top of hack that each create ten problems for every one problem that they solve.
The thing is, to the degree that the USB device doesn't require a special driver, that's because their hardware is conforming to the USB HID spec, which is a lot like conforming to the Bluetooth HID spec, just without the pairing/key exchange stuff.
It's true that the Bluetooth spec is a lot more complex because you have software control over the key exchange process on the user's machine (as opposed to presumably having to do some similar process once at the factory). Fortunately, that's all somebody else's problem (the silicon vendor). This makes it important to choose wisely when picking the Bluetooth silicon, but that's still a lot easier than designing equivalent parts from scratch.
I'm not a Bluetooth protocol specialist by any means, but IIRC, the device generates a key, and both ends have to store that key. The computer doesn't reject a device arbitrarily. Communication fails because the device's key no longer matches any key that the computer knows, and thus the computer cannot talk to the device at all. It seems unlikely that the computer would lose a key unless the stack implementation is just plain broken. After all, it has a hard drive to write the keys onto. It's much more likely that the device itself is losing the key or is deciding to generate a new key for some reason, probably either because of the pairing button getting pressed (intentionally, accidentally, due to insufficient case clearance near the button, etc.) or due to the batteries running down.
For example, I have one Bluetooth device that destroys its old key and generates a new one if you hit the pairing button (this is normal), and fails to restore it if you cancel pairing by power-cycling the device (this is annoying). I solved this little accident waiting to happen with a piece of tape and a penny on the bottom of the unit.... :-)
And that's a pretty serious problem. In my experience (which admittedly is mostly as a user, not an admin), most OSes aren't happy with high-latency wireless networks. With a fast, low-latency network with no packet loss, it can take a couple of seconds to do a DHCP request. With a slow, high-latency link with packet loss, I've seen it take a couple of *hours* to do a successful DHCP request. Sadly, such connections are easy to get when you have a few dozen people on an AP downloading porn^H^H^H^Hmovies^H^H^H^H^H^Hlegitimate software bits.
Something you might do to alleviate this is to use the 10 network for all your access points. Never reuse IPs and set your DHCP server to cache IP assignments and always ack when a host requests to extend its assignment. Oh, and set the lease time to a month or something. Doing this should reduce the number of DHCP packets that have to be sent. IIRC, for a re-request, you're down to one packet in each direction instead of (at least) two in each direction. Of course, if you can't get the response back within about two seconds, the client is likely to give up and fall back to a full-blown DHCPDISCOVER....
You should probably use a fast switch with a fast backbone between the APs and your core router/DHCP server to minimize latency between the AP and your DHCP server.
I would not use the same machine for the upstream router and the DHCP server. By keeping those separate, you are further reducing the wired portion of your latency because your DHCP discover/request packets aren't getting backed up behind outbound network traffic on the wire. Be sure to use a reasonably fast box for the DHCP server and a FAST box for your router/firewall/NAT box. Do not, under any circumstances, use the NAT built into any consumer router boxes.... The CPUs just aren't anywhere near fast enough.
Get several radios going, crank the gain down as much as is practical without losing bars of signal as seen from the devices, use directional antennas to dice up the space into as many distinct zones as possible, and organize the zones to maximize the distance between APs on the same channel. I'd probably put external antennas spaced periodically down each wall in alternation, forming a series of alternating cone-shaped zones. The exact distances depend on the spread angle of the antenna and the width of the room. Alternatively, you might consider hanging them from the ceiling pointing down, spaced in a grid formation.
If you can, try to make your APs give top priority to DHCP messages, thus minimizing the number of these packets that get dropped before they make it out (in either direction).
Oh, yes, and turn off 802.11b support if you can. Allowing 802.11b means that every packet sent at high speed requires additional crap before and after it so that the 802.11b radios don't choke. If that's not possible, set up a separate segregated network for legacy 802.11b clients and stick it on its own channel---probably one AP for the whole room.
Finally, if at all possible, make sure your DHCP server sends ACK using unicast where possible. AFAIK, every major OS should be able to handle this. IIRC, broadcast packets on 802.11 are particularly expensive. The more you can minimize them, the better off you are. While you're at it, crank up the multicast rate (basically, the minimum signal level that a client must maintain before the AP throws you out). This will force clients to associate with new stations more frequently, but should increase network performance and decrease latency under (particularly multicast/broadcast) load.
Oh, and one more thing. I'd like to echo the comments about not using home router gear. Get yourself Cisco APs. Most home routers just don't have the CPU to keep latency low enough when routing that much traffic, and many don't have sufficient control over power levels, external antenna jacks, etc.
You're grossly underestimating how hard it is to get the physical layer working with sufficient noise immunity. When designing a cheap device, you can't spend a lot of money on R&D. You have two choices:
If your hardware sucks and you can't reliably get a signal through the noise (which has been the case with almost every non-Bluetooth wireless device I've seen), you're pretty much screwed. By contrast, if your firmware sucks in the first rev, it's no big deal. You just flash the thing with new firmware. That's the advantage to using Bluetooth. The hardware layer is already completely designed and debugged for you, so you can focus on the protocol layer above it and get that right instead of having to do that *and* build your own (usually awful) hardware.
I view these things basically the same way as companies that write custom crypto algorithms. The results are almost invariably worse than if they used off-the-shelf technology underneath and focused on the upper layers instead.
Sounds like the mouse sucked, yes. That's certainly not normal. With good hardware, you have to explicitly hit a button to cause it to repair.
As for me, I won't buy wireless hardware that isn't Bluetooth. Bluetooth gear, in my experience, works reliably at 20-30 feet on average. Non-bluetooth gear gets jammed by random environmental noise and barely works at a foot or two from the receiver. I've seen this with many, many wireless keyboards and mice from many companies (including the major ones).
Proprietary communications technology SUCKS. A few bad devices notwithstanding, Bluetooth devices will always be more reliable than proprietary hardware because Bluetooth has hundreds of companies all working together to design the communication protocols and hardware instead of one company hacking something together on their own. When it comes to keyboards, mice, trackballs, etc., if it's not Bluetooth, as far as I'm concerned, it isn't really wireless.