WhatsApp doesn't use libsignal, and Android is already pretty Rusty and deployed more than WhatsApp around the world (not just smartphone. Tons of "embedded" use cases also run on custom Android)
It doesn't make sense for that device alone, but the vendor probably supplies all the different equipment in the gym. Using a tablet simplifies their supply chain, deployment, debugging/repair, app update process and simply supports more features. There are probably some connectivity features on the device, for example. When you look at all of that together, it's hard to argue it's wasting money.
It's like complaining about Electron apps. For sure I love small native apps like everyone else. But, if Electron enables a company to ship cross-platform apps and iterate faster, who am I to say no?
(I happen to have seen some of those tablets in diagnostic mode and poked around a bit. These things are much more complicated than you think.)
Once you price in the cost of integration, plastics, ROHS, CE and other regulatory/certifications, the extra cost of an Android tablet which already has a lot of that starts to make sense.
If you also add in the extra ease of things like device management across fleets etc, it becomes a no-brainer for the manufacturer.
The major problem with sticking an Android tablet on to exercise equipment is the difference in life spans. Android tablets are generally going to last you 4-5 years. Weight equipment should be able to last decades. There is some simple & cheap hardware that can last decades, but it is legitimately harder to program.
Even worse was an article some months back about Android tablets hooked to heating & cooling systems expected to last 20 years. There's no way those things are making it at scale.
Weight training equipment lasts decades all the time. It's just big piles of metal, it's not hard to get right.
What actually prompted the engineering-CYA "should" is if the Android tablet is controlling some sort of robotic system for selecting weight sizes, that that system might have an expected life span on par with a tablet, being a physical thing moving around some pins or something in a potentially hostile user environment. That'll break long before anything else would.
If you are the sort of person who needs a reference for "weight equipment lasts a long time", feel free. Whatever guilt and shame you think I should be feeling over such a claim, believe me, I don't. I'm more in the "feeling pity for you" department here; I've been around enough to know what kind of person types messages like this.
Well, doesn't look like to me, and a plain ESP32 with a touch screen would do the job for displaying a weight bar with plus, minus and reset count buttons.
And then you get to a cardio unit where you want a completely different set of features and have to start over. Going lean on hardware only makes sense when you push out a very high number of units, when you have to deal with battery constraints or when you just have a lot of intertia, the combination of existing codebase and developer filter skillset.
Except all the machines have the same feature set I mentioned.
Agree that wanting to hire cheap developers is why they did it that way, the current interface is so laggy that I would bet it is Web based, on top of running Android for nothing.
That's not a problem of the platform, but is a problem of the developers.
The extra cost of an Android capable tablet (maybe $200 especially wholesale) is a minimal hardware cost considering the overall price of the equipment is in the thousands.
But finding good embedded developers is a very difficult problem to solve, much easier to find Android app developers and then you get the Android eco-system for free like device management, OTA updates etc.
Put all the sensors and controls on a USB bus and you need one or two actual embedded developers to deal with the drivers and the rest of the developers can build the UI that people see.
In the case of a gym, the person buying the equipment is the customer, not you.
They want features that will make you "sticky" to the gym, plus save costs on training you on how to use the equipment.
Cardio units have neither a "weight bar" nor a repetition counter, but they have a whole universe of possible features in the realm of scripted sequences, reactions to HRM signals and even just "making time pass" features. With unbounded gimmickyness, the sky is the limit.
Personally, I'm a bit of an aficionado of close to the metal sports electronics. When I stare at gym screens I immediately notice updates that are supposed to come in once a second to get randomly delayed by what must be hundreds of millis. But I can totally see why they went that route. It's a market where feature quantity is big as a success metric and using a maintenance-friendly platform is even bigger. Wether Android actually checks that box might be debatable, but a bad embedded implementation could easily be worse, no doubt about that.
In the old days, those screens would have randomly dropped into some Windows desktop failing to operate in some kiosk mode fantasy.
And then you start selling in a country which demands accessibility for your equipment. Good luck getting a 20+ language human-sounding TTS system on your ESP32.
If they are not programming then they could have more time to produce food themselves without using machines relying on energy (traditional vs industrial agriculture).
Given this (including the linked writeup on the mintlify RCE), after the React RCE, if think it should be pretty obvious that
1. content security policies should always be used to prevent such scripts (here they would prevent execution of scripts from the SVG)
2. The JavaScript ecosystem should be making ` --disallow-code-generation-from-strings` a default recommendation when running NodeJS on the server.
Vercel (and other nodejs as a service providers) should warn customers that don't use CSP and `--disallow-code-generation-from-strings` that their settings should be improved.
If you use a lot of Arc<Mutex<Box<T>>> you you probably just learn to use Rust properly and just use Arc<Mutex<T>> instead because it pretty much never makes sense to have a Box inside an Arc...
I say that as someone that thinks Rust's learning curve is the main reason it rarely makes economic sense to use it.
It's a french project funded in part by the french government and the only current instances are for french contributors. They actually make it pretty easy to contribute... for the people that will contribute in France.
There are currently only 2 panoramax instances. One from IGN (french "National Geographic Institute) and one from the french OSM charter.
This is obvious by looking at the coverage the world. France it where the majority of the coverage is. The coverage of most cities is actually pretty impressive for a young project.
While the UI and coverage is not necessarily on par with street view, it's still pretty usable in France.
Secondly Panoramax is first built for OSM contributors/mappers, not for end users. The blog reflects this in the tldr: "If you are interested in contributing"
