Yo dawg, I heard you like CVS so I put your pharmacy's dyslexic tabular data in version control.

...or something like that.

Oh come on, TFS isn't bad enough to be flamebait!

Now, VSS, on the other hand...

It's very specific, in many sections, that the neutrality rules apply only to "lawful content".

Right, net neutrality requires you not to discriminate against lawful content. If it is silent on the issue of unlawful content, that would mean you have the option of discriminating against it. It does not mean you're somehow "required" to discriminate against it. You're conflating net neutrality's actual requirement with its inverse.

So... how do you distinguish between what is "lawful" or not?

You assume everything is lawful and don't discriminate against anything. Easy-peasy. Half the point of being a "common carrier" is that you're not liable for the unlawful content you transmit (specifically in recognition of the fact that figuring out what would be lawful or not is a pain in the ass).

Now, either you knew this or you should have known it before posting; yet you misrepresented it anyway. Therefore: STFU, troll!

I think you missed my point: the universe of possibilities for voting "against Republicans" encompasses more than just Democrats.

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.

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.