4 ms·
Is that a problem? I mean you're using a Google OS. At this point they are selling you a service, not a program. I have no idea what is in one version vs an
by metalliqaz 9y ago
Is that a problem? I mean you're using a Google OS. At this point they are selling you a service, not a program. I have no idea what is in one version vs another, and I don't really care as long as the service keeps working.
Now, I do still care of being in control of my own hardware, but I do so on my server. I don't know of a cell phone that delivers what I want without being sold as a service rather than a standalone product. Best I can do is back up all my data to my own box and keep buying new phones when the batteries die.
- cryptoz 9y agoThis was a major major major problem for me. Those silent Android updates are buggy in huge ways. One of them turned off the barometer until phone restart, throwing my startup into a panic as our core product (live barometer data from millions of contributing phones) went slowly dark for some mysterious unknown and scary reason. The data took weeks to return and that gap is lost forever.
- ddalex 9y agoDo you have public data sets? Some live view? I'm interested to see live barometer data across a vast number of sensors.
- cryptoz 9y agoWe used to, the company is no longer active. It was really neat data. It was open source code, but it's now a few years out of date, and would maybe be a good idea to rewrite, modernize and bring a big barometer network back online. On the individual scale, the sensor data was noisy, but in a dense environment with lots of sensors, the noise is identifiable and filterable to get solid pressure trends (actual pressure values is considerably harder).
- vanderZwan 9y ago> I have no idea what is in one version vs another, and I don't really care as long as the service keeps working. They insist on updating to newer versions of the Play Store on very old hardware that doesn't actually have the hardware power to run it.
- ocdtrekkie 9y agoGoogle Play Services meets all the definitions of malware. The fact that it is built to spy on you and transmit personal information about you to a third party, can't be removed, and does things like update itself despite your explicit instruction for it not to.
- jacquesm 9y agoYes, it is a problem: no updates means NO UPDATES, it does not mean all updates except for those that ignore the setting. The OS is supposed to enforce such things.
- ryandrake 9y agoExactly. People are forgetting the word "command". In the old days, users would command computers to do things, and the computers did those things. If I say rm -rf documents, I expect the documents directory to be removed. I'm not suggesting that the computer could do it, or asking the computer to do it. I'm issuing a command. And I expect it to be carried out completely. Delete it all. I don't expect the OS to keep around some dot-files that it really really likes, or to hit me up for confirmation, or to silently ignore me because the OS vendor can make more money by doing so. It's a huge problem if I tell a computer to do something and it doesn't do it, it does it half way, or it usually does it but sometimes doesn't. We engineers need to have a Hippocratic Oath that starts with: 1. Never put the company's need over the user's intent.
- jacquesm 9y agoInteresting. I have a blog post in draft called 'Do as I say', it echoes quite a few of the sentiments in your comment.
- ryandrake 9y agoMaybe I'm just crabby but I even resent having to ask my computer via its software if it could please, pretty please, shut down. As if I need its permission. Back in the day, you threw the power switch and it was off. And, yes, I understand disk caches and why we have a graceful shutdown process. What irks me is that the computer might be in the middle of doing something despite my not having told it to be doing anything.
- jacquesm 9y agoAnything a little larger (say a 4381) 'back in the day' also needed to be asked politely to be switched off, even PDP-11's running UNIX wouldn't take kindly to an unscheduled drop in input juice. fsck or the local equivalent would be your lot. I'm actually quite happy with the shutdown speed of modern hardware running Linux, it's typically under a second or so but I can see how it might get to you that you can't just throw the switch. It might be interesting to do this on purpose a bunch of times to see what the end result is, I built a car computer once that was arranged purposefully so that losing power at any time did not make it lose stuff but that was quite a tricky setup with a supercap and a bunch of 'early warning' logic to let the computer know that powerdown was imminent. It did work but I was never quite sure how much leeway there was.