Well, I stand by the fact that the ones you refer to didn't work in the MH370 case and a new generation of doppler science on Inmarsat data was required instead to reach an accepted location of the crash as being a more likely indicator that ELTs of that kind are not deployed on the MH370 airframe rather than a very good reason for passenger/crew families to sue Boeing and/or Honeywell. I never said such devices don't exist, the answer to your question "Isn't there supposed to be several salt-water activated beacons that are automatically released upon a crash?" is no. Quoting wikipedia for example:
"Most general aviation aircraft in the U.S. are required to carry an ELT, depending upon the type or location of operation, while scheduled flights by scheduled air carriers are not. However, in commercial aircraft, a cockpit voice recorder or flight data recorder must contain an Underwater locator beacon."
As far as I know from two respected broadcast news sources' stories (quoting government search organizations among sources) that automatic water activated ultrasound locators were being sought with urgency in the days following the MH370 crash due to their limited power life but that the problem was it was not worth searching other than in the region of the locator due to the low output power of the locator. A functioning floating VHF/UHF or even HF ELT would have been located with precision by satellite within no more than hours of the crash with half the world's ham radio operators contributing references from ground as well. It would not have been at the location of the crash when discovered if it was floating and would not have stayed where it was when located anyway. An underwater RF transmitter of the same type at the depth of ocean floor in this case would not have moved but would not be receivable other than in a small region around the crash, which is the reason ultrasonic ones are used underwater and why submarine external communications systems are not HF, VHF or UHF. I'm listening to a BBC World Service story right now where they are saying the new "rough" crash site is the size of Portugal and there's no knowledge of whether the "ultrasound" locator being sought is on a flat surface or down a sea-floor canyon.
I also heard a magazine style story using the Air France 447 crash as a frequent example and quoting US government aviation safety sources describing an intended design goal of ultrasound locators and the recorders themselves being to not leave the scene of the crash and that anything of interest leaving that location would be sought after based on best available knowledge of forces capable of moving them (tides for example). The reverse being intended if the debris is found away from the crash site. A floating radio ELT could not serve the same purpose and any on-board that did float could not be expected to go in the same direction as all survivors anyway so would have a lower than 100% effectiveness anyway. The only news discussion I've heard of ELT type locators is of the form where the reporter makes scathing comments about how outdated the system being sought is and how we must be able to do better with satellites and GPS for example and the interviewee points out that's not the problem, deploying such systems on all the world's existing civil aircraft makes it prohibitive to be considered an official safety system. In that case, I assume the Honeywell ELT system used by Boeing, for example, is a commercial locator that no airlines are required to deploy but can choose to buy.
The answer to your question was "no" with regard to MH370 and you've done nothing to show otherwise and quoted no sources of your own in response to several of mine. There were no RF ELT's on-board or required to be on-board MH370 and they would only be partially effective anyway. It contains one or two ultrasonic locators designed to have stayed at the crash site with the flight recorders and they cannot be discovered outside of a limited distance from them hence the need to know the crash site.
Somewhere there was a comment about being addicted to food. As in, you can't be. Well, yes, you can, in the pure dependence meaning of the term, too. If you don't eat food you suffer extreme withdrawal symptoms. Death can be a final symptom. And you can be addicted to foods in the common language meaning of addiction. Mmmm, I love mint chocolate chip ice cream. I have a strong urge to eat it...
In which case water is even more addictive than even food (the mean number of person-days water is taken is bound to be higher than the mean number of person-days food is taken). Better still, food is not only addictive, it is the most overdosed on substance in the world with food pusher's selling as much as multiple daily overdoses to anyone who can afford a fix.
But most manufacturers don't WANT to provide sources to their drivers
As someone who works on linux bug fixing for, among others, the hardware partners of a linux distro vendor I sense that changing day by day. Some never will publish but as a result those they compete with will generally have a lower per-developer cost of development leading to a higher rate of bug fixes alone for the vendors who do publish. Not publishing made sense when the PC was the only platform that mattered but I'm impressed by the number of x86/x86-64 build bugs I see for things being called point of sale systems. They are probably PC based but they are built in a way that means they'll never run Windows and there will be more of them in the end so the hardware with published source is probably a better choice for those manufacturers. I'm sure one of Intel's plans is to support them as hard as it can afford to. Those that follow the lead will probably do quite well. It's ironic that standardization of hardware was intended to make things cheap to mass-produce then we have mass-produced standard hardware interfaces that make incorporating a large variety of unique devices relatively easy and the cheapness comes from mass-produced software where standard libraries make the effort to handle each unique device very low cost and with just one third party developer interested in contributing to the final effort part of the cost for the hardware vendor is off-loaded. They only have to maintain control over what's accepted as code intended for their hardware.