(Would not have minded if they hadn't been binary about the switch, if they had simply added Intel models and not dropped the PowerPC processor. Would mind less if there were AMD models. Would mind much less now if I could get a usable development capable workstation running (Mac OS, I assume) on a 64 bit ARM processor.)
He replied that Google has become the new Microsoft.
Yeah, Google is going the way of all big companies. We know that.
Going big is going bad. WordPerfect fell into that trap, didn't they? I expected Google to go downhill.
He encouraged me to get an Android tablet anyway and start learning to build apps on it. He was right, and I did, and I have been digging into developing on/for it. It's definitely more of a mess than the iOS, but that's to be expected, too. Open source software is software developed by committee, and it may be the best way that committees can and should work, but the lack of focus shows through.
Found some sort-of bright spots, but the shine doesn't last.
Up front, before I go full-negative here, the Android device is a nice portable mailbox. Gmail is improving, and I really should try out some of the 3rd-party mail apps. It's also a very nice box for reading scriptures on the train. Google maps is really handy, although my portable router gets plugged up and kicked off the telephone network rather quickly. Not sure why.
But everything is so half-baked. Here are some of the frustrations I'm working against at the moment:
** Even the math/algebra/geometry app Geogebra has the UI hog-tied (in the Android version, because of lack of mouse and real keyboard, I assume). (Slightly unfortunate name, that. Would Algeobramathetry have been better? And there is a Japanese site.)
But I really wish they weren't deluded into thinking that everyone has all-day connection and that saving to their servers is somehow better than saving to the user's own disk drive.
** The text editor Jota has gone, how can I say this politely? connected. You get ads from Google when you run it, unless you pay for it. Seems reasonable, except that a text editor should never have any reason to connect to the network internally.
Externally, yes, it's nice to hook the file save/load dialogs into the system's networking functions. Not internally. Instead, by external connection that I have to initiate myself.
When I'm writing in my journal, some of that is so un-processed that I wouldn't even want myself to have access to it, if I could avoid that. And if the text editor is getting ads unless I pop for the low-low use fee, how do I know that it is not copying my keystrokes to the web even if I pay the low-low use fee?
Functionally, it's pretty nice, and getting better. But I can't trust it to use for the things I most need a text editor for.
And Jota is the best text editor I've been able to find so far.
And all the others do the same thing about ads.
** The file manager Astro has the same problem, too. It's a little funky about how you dig around in your file system because, I suppose, of the fake walls Google helps the vendor put up, making a show of protecting your data. But the real sin here is the connected "functionality". The "Free Astro Backup Account" and the "Rate Us".
Again, I can't trust it for what I need it most for.
** Raised my eyebrows just now when I updated the LDS Gospel Library and it asked for access to my profile.
Why should it need that? If it really does need something out of there, Google has done a poor job of normalizing the storage of my profile.
** Oh. Yeah. Google has done exactly that. That's one of the reasons my friend called them the new Microsoft. Cutting corners as a way to increase access to potentially profitable stuff.
(Hmm. Is there a way for an app to tell me that it is giving back access that the developers realize they don't need after all?)
** Basically, all the apps that fill in the functionality that the vendors have stripped out have the same problem. Trying to force the revenue stream. Succumbing to the temptation to over-reach in functionality.
There would be no problem if the developers for these apps offered external integration to for-pay backup space and such, say, a way to use the file access dialogs to save and load across the network.
But the functional integration is gratuitous, gets in the way of using the apps as tools, and breaks the agreement of trust.
Apps should do the minimum, and delegate the rest. That's the way they can be trusted.
Moving on to some of the more developer-oriented tools:
** The wireless keyboard loses connection and bounces. Really hard to get stable text entry with it on the train or anywhere else there is a lot of wireless traffic.
Bluetooth is such a ... . Well, I don't have nice things to say about bluetooth. You should not consider bluetooth a feature. Call it a blob of misfeatures.
** Gforth is nice.
Unfortunately, it tends to go pop every now and again. Sends you to the Android equivalent of a desktop, and when you go back, your session is gone.
The keyboard and non-ASCII characters seem to be some of the issues here. The pseudo-walls also cause problems, and not being run from a real shell causes more.
Actually, if I weren't busy with my own projects, gforth on Android is something I would be focusing on. It is definitely one of the brighter spots. Cool stuff here, and they need more of a user community.
** No-root Debian is nice, but you do need a hardware (USB) keyboard and mouse to do any serious work, and it goes pop every now and then like gforth does. Probably for similar reasons.
Trying to edit code in it on the train has not worked well for me. But I've been able to walk it through compiling code on the train, even with the software keyboard. Cool? Yeah.
bc and gforth run nicely enough.
A little bragging on myself, my 6800 assembler and my bif-c implementation of forth compile and run well enough on no-root debian. (Need to try compiling Joe Allen's exorsim on no-root debian sometime, or write my own 6800 simulator.)
Now this is not your free ticket to editing the system files. It's subject to the same pseudo-walls as all the apps that play "nicely" in the Playstore sandbox.
** terminal-ide is useful for understanding what's going on under the hood. It is subject to the sandbox rules like no-root debian, but the help functionality gives you a bit better view of what's happening on the tablet when you are working with the Google-provided hosted developer tools.
Working with an incomplete set of libraries, and without a true shell, is not exactly productive. I haven't been able to get the 6800 assembler to produce object code, nor have I been able to get the bif-c interpreter to give me a command prompt before segfaulting.
Not even thinking of trying to compile bc yet.
** Google's hosted developer tools are, well, developer level. Steep learning curve.
The biggest disappointment was trying to get admin-level access to my Acer tablet. I won't comment more on that until I buy a Nexus and try again, to make sure it wasn't just me.
The developer tools don't run well on openbsd. I don't want to use Linux any more after various things (such as /usr, and uefi) in the flap surrounding the systemd fiasco made it obvious that Linux is subject to social engineering. But I'll probably have to get a dedicated dev box with some sort of Linux running, if I decide to get serious about getting my own apps running on Android tablets.
Whether I do that before I buy a Mac and an iPad and start digging into iOS, I'm not sure.
Ask for help getting the android dev tools working on openbsd on the misc@ list,
and you'll get laughed at and accused of selling your soul.
Which is as it should be.
---------
I hear Android 5.0 brings back users.
You say, "WHat?"
User login. Where you have a user name that you choose and an associated password.
On Android, until Android 5.0, the idea was that everyone would not want the bother of managing users on a portable phone.
Stupid idea. If you want to lend your phone to a friend, you probably don't want to lend your friend your private phone book. And, for mixing business and personal use on the same phone, well, that's the data sink that feeds about half of the spam between PCs running Microsoft's OSses. Ticking time bomb.
And so much mistaken security effort induced by that one bad decision, trying to re-work the (correct) security model of *nix systems into an (incorrect) model that just ended up needing to be fixed. And all the phones that have been sold with the engineering error, and all the vendors who are unwilling to provide upgrades to Android 5 for their hardware.
Until I see for myself whether Android 5 has actually brought real user logins or just gone further down the road of trying to re-invent things that were done right to start with, just so managers could pretend they were being productive without really doing anything, I can't say whether things have actually been fixed.
---------
The GPL and all other true open-source licenses are legal implementations of something called an "agreement between gentlemen".
Simply put, there are rules to business. Treat each other nicely or drown in the cesspool of your own making. And when you are drowning, well, if it's your greed that is part of what is filling the cesspool, don't be surprised if everyone else is too busy trying to float in a mixture that is less dense than they are to help you.
(You do understand the real danger of cesspools? It's not the smell. It's that the human body, which floats somewhat well in clean water, sinks in a cesspool.)
The gentleman's agreement is that we play the games, but we don't go too far. When we see someone going too far, the agreement allows us to kick the recalcitrant in the seat of the pants to get his attention. If necessary, it allows us to kick the consistent offenders out of the game. Not just allow it, require it.
With open source licenses, the license helps us talk about figuring out what going too far means:
- Take, but give back.
- Don't build and sell stuff intended to be used once and thrown away.
- Support your customers.
- When you aren't able to support your customers, allow them to support themselves.
- Most of all, don't demand that your customers get approval for every little thing they want to do with the product they have been kind enough to buy from you.
Take. But give back.
That's how real value is generated. When we give back, if we give for real, we don't lose anything real, but the surrounding community gains more than we give.
That's the first law of economics.
Applied to free OSses like Android and Linux and the BSDs, if you are making money from them, support the developer communities with money, code, and especially infrastructure.
Publish your source code, including those no-they-aren't-really-your-crown-jewels drivers, of course.
Set up the infrastructure and support crew (cough, Darwin, Apple?) for open work on the software that makes your business model work.
Not just Apple, of course.
My first cell phone was a Docomo-branded Panasonic running a Limo/Tizen OS. Somewhere in the documentation was a link, and I found, somewhere on docomo's servers, a tarball that claimed to contain the source code that was their "compliance" to the GPL. I never was able to unpack that tarball in any meaningful way before that phone died.
That's not compliance. Bare minimum compliance would have been a link to a page that would
- tell a competent end-user how to find the community and join it,
- tell a competent end-user what kind of system was necessary to get at the source code,
- describe how the competent end-user could set himself up with a system to do at least some useful custom work on the phone without eating more than half a month's pay check
- in addition to a tarball (but better an open source tree) that could be opened by standard tools.
My new phone is a Docomo-branded Sharp built phone. (I plan to give it to my daughter shortly.) It has problems, and I could solve some of those problems with shell access. I haven't bothered looking for the compliance tarball for it, probably will not bother.
When I talk about such things at the Docomo service centers, if the service rep knows what I'm talking about, there's a look in her eyes that should be reserved for when she sees a terrorist.
If the wireless phone network is that vulnerable, I'm not the problem, the phone company itself is.
What is the difference between Limo/Tizen and Android?
Google did a better job of telling interested developers how to get started.
That's about it.
But there's still something missing.
When I got this Acer brand Android tablet, it was still at Android 3.2 or so. Acer provided an update to Android 4. That is, they provided a binary update.
I found some source code on Acer's site, but I am not optimistic about being able to use it. None of the mainstream Linux distributions or *BSD OS communities have it in their repositories, because it is really hard to integrate the code into their trees and workflows. And it's hard to get the hardware, and hard to get the hardware set up to reliably test the OS that results.
If they are going to be able to use this source code, they need more help from Acer and Google. This is where things shift from the taking phase to the giving phase.
They need Google and Acer to assign an engineer to help them get the code integrated into their source tree. And they need test hardware.
NO WAY!!!!!!! you say. No company is going to waste valuable engineering time on supporting non-product!
This is where you shift from taking to giving, Google. All the billions you have in the black, surely you could give up maybe ten thousand of dollars worth of engineering time. And a pair of each of the current model Nexus tablets to the Fedora, Debian, and Ubuntu communities, and to the FreeBSD, netBSD, and openBSD communities wouldn't even begin to hit your bottom line.
That would provide enough to provide a way to keep these tablets useable even after the maker quits providing Android updates. It would also help the makers figure out how to set up user support communities for Android on their products, which is where it comes back around to strengthen your bottom line.
That's what is missing in Android. Just because Apple is being a pig is no excuse.