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.)

Let me get this straight: after already having spent money to buy the iDevice itself, a user is required not only to spend more money to buy a Mac, but to then spend even more money on top of that (not to mention, the hassle) to replace the OS? So that even in the best-case scenario, a user with a $250 iPad Mini has to spend an additional $520 (for a Mac Mini + OS X Server) just to be free of the goddamn App Store?

Forgive me if I remain unconvinced.

And of course, let's not forget the fact that all of this is beside the point since providing a computer without the ability for it to be programmed is fundamentally unethical to begin with!

From the summary:

OS X is finally a full-fledged peer to iOS; all aspects of sibling rivalry have been banished."

Excuse me, but the only way for OS X to become a "peer" to iOS would be for iOS to become a whole lot better (e.g. to gain better multitasking and multiuser support, the ability to freely install software without a walled garden, a command line, etc.) or for OS X to become a whole lot worse!

In other words, Google Voice requires you to have a separate telephone number, that's not your mobile phone number. Depending on what services they want, people have to contact you on the two separate numbers. (Google Voice has limitation on SMS, international calling etc.)

No, Google Voice requires you to have a Google Voice number [full stop]. It doesn't matter whether you have a mobile phone number or not. Even if you do have a mobile phone number, nobody ever has to know it or call it, because they can reach your cellphone anyway (either by you setting up Google Voice to transparently forward to your mobile phone number, or by using a [VoIP] data connection with Hangouts). If you continue telling people to call your "real" cellphone number after signing up for Google Voice, you are proverbially Doing it Wrong.

You could cancel your cellular service entirely and use your phone with Google Voice over wi-fi, or get a plan where you only care about the data part and the "voice" minutes are irrelevant. For example, my T-Mobile plan costs $30 and has 5GB of 4G data (which is equivalent to about 4000 minutes of VoIP) and a measly 100 actual-voice minutes. But that's okay, because I use exactly 0 voice minutes because all my calls are routed over Google Voice. Since I don't come anywhere close to using all 5GB each month, I could probably even switch to a provider like Ting, select a data-only plan, and pay even less.

And by the way, Google Voice does in fact have SMS and international calling (the latter has some non-zero per-minute cost, though). I don't know how you imagined it didn't.

Hello, Mr. Strawman. Are you going to start singing "If I Only Had a Brain" now?

(BMW should have theirs out by then)

They're apparently out now; I saw one on the road this morning.