Not so much the cost of the sensor/programming/configuration, but the reliability of it would be an issue. Assembly lines have to function within very tight schedules from beginning to end of the line, there isn't a lot of room for pauses. Every false alarm (and there would be a lot) would shut down the device, causing a backup and very likely shutting down the line until it is reset. It makes a lot more sense to just have exclusion zones clearly marked and keep people the hell out of them. That simple low-tech solution has worked for 150 years, there really isn't any reason to yet to spend a lot of resources on solutions that won't work as well and will cause new and unpredictable problems.
Every death is tragic
Horseshit. Ronald Reagan's and Pol Pot's deaths were cause for celebration, and I certainly did (Hitler and Stalin were before my time). It's just too bad that Pol Pot's wasn't more painful and drawn out.
In the 1970s GM automated a portion of the assembly line parts warehouse, and at least two workers were killed because they got in the way of equipment. One was pretty much reduced to hamburger by a trolley passing over his corpse repeatedly.
Property value going up is only a good thing if you intend to sell. Otherwise it raises your taxes for little to no benefit to you. Unless you're the type who likes to boast about how much their house is worth, I suppose.
Just a bit of historical trivia, the reason the Soviets were microwaving the embassy was because they could eavesdrop on conversations in the room (to a certain extent) by Doppler readings of the vibrations of the single-pane windows.
Not necessarily. I used to hear the hum of florescent light ballasts, which pretty much no one else I worked with could. A squealing fan belt or worn brake pads were physically painful to be near. As I've lost hearing over the years (hereditary factors) those particular annoyances have gone away, but on the down side I can't hear crickets any more or the wind in the trees.
Something tells me that you're too dumb to know how to create a user account, AC. There are plenty of devices that require you to change the password the first time you log into them, there is absolutely no reason NOT to do that except for laziness.
It's not a Linux problem as such, but it is an OS programmer problem because they **allow** default passwords to survive first use without requiring that they be changed.
The simple fact that you can leave the device with a default password encompasses several levels of stupidity. 1) Programmers who do not require password to be changed, 2) Manufacturers who will install that firmware, 3) Customers who leave it that way. Level 3 shouldn't even be possible except for stupidity and laziness in Level 1 and 2.
Mosquito larvae are an important part of the ecosystem of non-circulating water deposits, eating bacteria and protozoa and providing food for dragonfly nymphs and other predators. There is no real replacement for them, and you can't have larvae without adults.
So are apples and cherries. For that matter wheat, cows and potatoes are as well.
I think you'll find that most embedded hardware has your "broken" IP implementation. Probably partly because it's more work to set it up correctly, but also because there are a lot of times where installers in the field or repair people in the shop have no way of knowing what the IP address of this stuff is supposed to be and need to be able to get at it. Devices that I have personally worked with would include a plethora of security cameras, Seimens I/O panels, Lantronix and Mercury TCP/IP to serial I/O converters, AMAG security hardware, two kinds of infant abduction systems, intercoms, and emergency alert systems. Some (most?) SCADA hardware is set up that way as well, I've been told. I suppose the reason why this isn't really considered a security issue is that you need physical access to the device to make it work.
Works, I've done it several dozen times. You're communicating at the physical layer. The exception would be if some absolute moron of a programmer hard coded an IP address for the source in the application.
Because the device isn't identified by its IP address at the physical level, but by the MAC address. Your NIC will first do a MAC broadcast to see if the target is on the same network segment. If you use a hub it will be forwarded to all the other ports and the other NIC will answer, if you're on a switch it **should** forward the packet, but sometimes they'll be flaky and ignore a MAC broadcast.
"for example 172.16.16.20" Example.
The arp command will work with any valid IP address, not just 172.x. I assume that the IP address is not hard coded into the app.