Actually, I was just going to warn you that you forgot to redact your name. Then when I read that you'd already noticed it, I got curious about that used oil analysis. Seriously, what's the deal with the diesel oil and/or canola in your Corolla?
We now also know you drive an '00 Corolla and live in Walnut Creek, CA. By the way, why do you use diesel oil in your gasoline engine? I put the same stuff in my TDI...
Wait -- and why is the oil analysis guy talking about canola?!
It's not like 10 years ago it was enjoyable either to use a dumb terminal, and quite frankly I doubt it's improved (I think they were SUN dumb terminals connected to something I can't remember). These days you're still going to compete over resources over a extremely high latency link (relative to computer performance). Not to mention the increased use of graphical elements in the UI.
It's worse... these days we're making our dumb terminals using AJAX.
Why don't you expect that you can re-write the code on the dozen micro-controllers in your car
I do, and I have (or more precisely, I paid somebody else to do it for me). In my case, the guy had to remove the ECU and de-solder the memory in order to flash it; on newer models it can be done thorugh the ODB II port -- I consider that to be an improvement.
Incidentally, you can get a lot more horsepower out of most turbodiesels that way.
On other cars from the same manufacturer, some people re-flash their window control module so they can roll down their windows using their keyless entry. My car had that feature already enabled, so I didn't need to mess with it.
or your refrigerator
My refrigerator is old and dumb. But if it weren't, I would indeed expect to be able to hack it.
What about your cable box?
When I had cable (against my will -- only because the cable company charged less for internet + TV than they did for internet by itself that year) I used an HDHomeRun with a CableCard.
I use an HTPC specifically because I can program it!
your DVD player?
It's a drive in the afore-mentioned HTPC.
How about that PS3 your kids play?
Your ethical criteria is arbitrarily created to castigate Apple for doing the same thing that hundreds of other manufacturers have done over the last 100 years.
Nope. I apply the same standard to everything else I buy.
I'm genuinely worried acceptable new products will cease being made (which is, of course, the reason for my rule in the first place).
You probably own a few dozen processors which are similarly handicapped by the manufacturer to function as an appliance.
Exported by what? For all you know, I might be trying to look for the damn things using strings on the raw block device!
Yes, new packages will need to support both for a while, but this is a tiny fraction of the work to create and maintain a new service. It is a very small price to pay in order to get some breathing room and a graceful transition period.
See, the problem here is that your whole concept of the issue is mistaken. You're talking about supporting both "for a while" during a "graceful transition period" when the issue is that people don't ever want to switch. Not now, not after a "transition period," not 1000 years from now -- never. The issue is that lots of people see SystemD as fundamentally wrong, bad, incorrect, doubleplusungood, and anathema to the "Unix nature." A "graceful transition period" will not and can not fix that!
The browser would have to trigger the script somehow, the script would have to read the contents of the browser, etc. etc.
No, you'd just write a shell script to listen for the "network joined" event (or maybe the "captive portal found" event -- Android has the ability to detect captive portals; I assume iOS does too) then construct (a priori, from looking at the captive portal's source code yourself) an appropriate HTTP POST command and pipe it to a tool like curl or wget to send it.
You can probably find a scriptable browser in the App store
Not if it uses an HTML rendering engine other than Webkit!
I'm shocked you can't understand why this isn't a priority for Apple.
Oh, I understand, all right: I understand that scripting was preexisting functionality (from iOS's UNIX heritage) that Apple made a conscious, deliberate effort to remove. I understand that they did so specifically in order to give themselves more control at the expense of the user. The issue is not that I don't understand; the issue is that I fundamentally and vehemently disagree.
Including things like their version of Androids Intents (that they call "extensions")....notifications pane from iOS (stolen from Android, natch)...
Right, so you're upset that Apple is using plugins, extensions, and notifications because all of those things were invented by Android developers. Sure.
You seem to have "accidentally" forgotten to quote the objectionable part:
However, since they come from iOS, they ["extensions"] only work with apps that are sold through the App Store.
Anything that "only works with... the App Store" (except maybe for updating the OS itself and first-party applications) is a problem, because it's a step towards locking out anything that circumvents the App Store.
Further, I suspect you are somewhat forgetting that this is really a phone, an appliance, and not really a computer, even though it has one inside of it - just like a microwave.
On the contrary, I am explicitly rejecting the notion that it's "not really a computer!"
Can you write scripts like that on anything? A script that "knows" the state of another app? ( a real question, not a troll. )It sounds like you want something similar to Applescript, which allows you to write a script which actually launches whatever apps, invokes the methods exposed by the app via the script library, and then does something else, no?
Yes, Applescript (or even Automator) is pretty much the minimum of what I'm asking for (preferably including shell script Actions). Being able to write something that compiles to a native executable would be even better, but Automator would be the minimum.
If so, I think the reason Apple excludes such a thing is twofold: one, sandboxing and security is difficult with such a beast, and two,
.0001% of their customer base wants such a thing. Heck, it's almost dead on the Mac. It would be pretty awesome, though!
I don't particularly care "why" Apple chose to rip out that functionality; I think it is wrong of them to have done so. Divorcing owning a computer from being able to program it is dangerous because it enables a "Right to Read" scenario.
For many people (especially in developing countries) a "smartphone" is the closest thing to a computer they'll ever have for the foreseeable future. I do not want an entire generation of people growing up thinking it's "okay" for some corporation to tell them what they are "allowed" to do with their own damn property!
There's IFTTT and all sorts of apps that'll automate based on geofencing.
Okay, great. Now what if I want to automate based on something other than "geofencing?" What if I want to do it based on receiving a text message? Or when I turn the device in a particular orientation? Or based on the ambient light level? Or based on some arbitrary event generated by an arbitrary third-party app? Anything flexible enough to handle all those cases turns into a scripting environment.
But having a script trigger when a captive portal comes up would mean the script would have to know what's going on in the browser thread when the capture portal detection runs
Indeed it would, which is why it would be impossible for Apple to code a solution. Instead, the only way to solve the problem is for the user himself to write a script to handle the particular captive portal he cares about, which is exactly why scripting is required.
That depends: if the microwave is the kind with only a mechanical dial timer, then no. If it's the kind with a number pad interface and presets, then I expect to be able to program presets. If it can read email (I'm not even joking -- see "Messages Sending Function"), then I expect to be able to program it like a general-purpose computer.
So, you're wanting to build and compile code on your phone? Or an iPad mini? If so, you're just nuts.
Why not? I was able to compile QBasic code on a 286; surely a smartphone should be at least as capable. The only important thing my 286 had that an iPhone does not is a physical keyboard, and Bluetooth (or a drag-and-drop graphical development environment, like Apple's own Automator) solves that problem.
More to the point, I'm not sure where you're getting this whole "build and compile" idea -- I wouldn't be planning to develop some huge application on the phone (although I see no need to restrict someone from doing so); I just want to be able to write scripts to glue stuff together. Stuff like "when my GPS says I'm at location X and app A is in state Y, tell app B to do action Z." Is that too much to ask? I don't think so.
As for the "ethics", you're just flat making that issue up for the rest of the world.
The purpose of a computer -- as opposed to some other tool -- is that it has the flexibility (by being programmed) to do many different things, including things conceived of by nobody but the user. A computer that can't be programmed is fundamentally not fit for purpose. Apple is selling devices that they have intentionally broken.
The necessary foundation to make scripting work would break process and application isolation.
BS. OS X applications prove this isn't true. The point is not to be able to twiddle with an application's state arbitrarily; the point is for the application to expose a scripting API.
I've yet looked at my phone and went, "Gee, I wish I could just do this with curl instead of safari."
You've never looked at your phone and went, "Gee, I wish I could script the damn captive portal to this Wi-Fi hotspot so I wouldn't have to log in manually anymore?" Or, "Gee, I wish I could make my phone automatically do X upon condition Y" (where X might be "set the ringer to vibrate" and Y might be "when I arrive at work")?
Of course, those are simple examples, which Apple programmers could conceivably think of and write an ad-hoc solution for. But Apple's never going to write a solution for anything sufficiently unusual or personal; scripting is the only thing flexible enough to accomplish that.
Problem is of course that everyone already has the mobile phone number. This would require getting everyone to change it. Which is hard enough if ever your mobile phone number has to change. Given that your existing mobile phone number will still exist, good luck trying to get everyone to call this other number instead.
Well, what you do is port your existing number to Google Voice and get a new number for your cellular service. Admittedly, it's most convenient to do this concurrently with when you'd be changing plans anyway.
Also, who would really want a command line on their *phone*?
I was using "command line" as a proxy for "scripting." An iOS version of Automator might be good enough*, but of course even Automator would include a call-a-shell-script Action, so it amounts to the same thing.
If you can't understand why scripting is important, then you don't understand what computers are to begin with (and an iPhone is a computer; it just happens to have a modem, microphone and speaker too).
(* On a Mac, Automator scripts are more cumbersome to use for ad-hoc things than the command line, but maybe in the absence of a physical keyboard the situation would be reversed.)