We have the same thing here in the US, but good luck getting a new SSN if it gets compromised.

What bugs me is I've been refusing to give out my SS# to any operation that didn't have a federal mandate to get it for decades - since at LEAST the '80s.

Then I aged into eligibility for medicare - and other health insurers insist that, since I'm eligible, they'll only pay the difference between my coverage with them and what Medicare pays (which is most of the bill), even if I don't collect from Medicare. Not collecting from Medicare would be a financial disaster.

But Medicare's I.D. is the social security number with a single letter appended to it. Every clerk at every doctor's office, clinic, hospital, pharmacy, etc. that I interact with gets my SS#. Ever such operation's database has my SS#. I went to Costco for a flu shot, so now Costco has my SS#. Every store's database is a chance for a cracker to collect it. Every clerk is a chance for some crook to tempt them and buy it.

There was recently an article wringing its hands over the discovery that people over 65 have a higher incidence of identity theft. Well DUH!

The solution would be fore Medicare to assign a separate medicare number for making claims and otherwise interacting with them - something randomly picked (not algorithmically generated from the SS#, which would return to the current case as soon as the algorithm leaked), and only paired with the SS# (if at all) in a database in the relevant government department.

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.

your DVR?

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?

I boycott all Sony products (especially Playstations) as a matter of principle. I was starting to consider forgiving them for the rootkit, but then they removed OtherOS. Sony is dead to me.

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.

Try me.

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.

Which still sounds odd to me. I'm running Gentoo on my main desktop (Mint on my laptop) and have never installed systemd. I've decided to stick with OpenRC. GIMP works fine here and I do have dbus installed.

It seems this dbus dependency is not an unsolvable problem.

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.