Re: Andriod - coming on strong!

On 1/30/2011 8:51 PM, KDT wrote:
On Jan 30, 7:25 pm, Flint<age...@xxxxxxxxxxxxx> wrote:
1. Where on QNX's website can you find documentation on accessing
RIM's specific framework additions and modifications?

Why are you stuck on "RIM's specific framework additions and

Because you can't program a the BlackBerry Playbook without access to
the frameworks that BB added to QNX. This isn't rocket science.

Apparently you seem to think Blackberry Playbook is a locked down at it's kernel as an iPad is.

2. Where on RIM's website do you find any evidence that developers
will be allowed to write applications that are based on it.

Applications _NOT_ based on BBTOS?


We are talking about writing applications for the BlackBerry Playbook
aren't we?

Yes, but you started this whole debate centered on a lack of _native app_ development tools (primarily because of games) as being impossible because of the currently SDK availability. I simply pointed out documented proof that QNX does have tools enabling developers to move outside of the BBTOS framework, and that the core of the OS is designed such that this could be done. You then goal post shifted to imply this won't ever happen, or even be possible.
Again, you were provided source to show it is indeed possible. Furthermore, you accuse me of not reading things, looking things up, yet the only link you've provided is the BBTOS page which obviously I would have had to have read already.

You are a very temporal minded and myopic individual. If it doesn't exist *here* and *now*, its simply not valid in your mind, and your world stops in a static bubble. You obviously haven't talked to any BBTOS developers yourself.

Uh, show me another tablet OS that *does*?

iOS and even Android with the NDK. Windows 7 doesn't allow normal
developers to write apps that aren't hosted on the CLR.

We weren't talking about Win7 in this discussion.

You said which tablet allows native applications -- both Android and

Yet somehow you seem to have special inside knowlege/proof that BBTOS

Silly me for actually looking at the SDKs on BB's website and reading
where they said that a native and Java SDK is coming soon but not
available *now*.

How do you as a normal non-blessed developer develop a native program
for the Playbook? Where do I find this information on BB's website?

You seem to think an XCode-type of developer environment is absolutely necessary at/or before launch, or it will fail.

I have to take Dan Dodge's word for it when he says at :

"For applications that require access to the native OS environment, developers can develop and port C/C++ applications and also take advantage of the QNX® Momentics® Tool Suite, which is based on the Eclipse standard. The BlackBerry Tablet OS provides built-in interfaces to integrate the rich graphical application environment with underlying native code."

You do realize that iOS and Android have pre-emptive multitasking.

Android's is a bit better since it only does so in critical situations
(low resources/memory).

Android only does "pre-emptive multitasking in low resource
situations"? What in the heck are you talking about? Why would
multitasking be limited to "low resource situations"?


I need a "cite" to show where "multitasking" has anything to do with
resource management in low memory situations? PMT only deals with
task scheduling.

I needed to finish my 'cite'. It was an unfinished thought I overlooked and didn't finish. Furthermore, I got ahead of my train of thought. Rather than write one line, easy to digest answers only to have you regurgitate them:

Then why does the iPad's iOS multitasking suck compared to the

Right, because you've actually used the Playbook and studied the SDK
to make a comparison....

No, but I have used QNX RTOS

Got it, so you've never actually programmed on any mobile platform.
So do you think someone who has "used" Linux is automatically an
expert in programming Android?

Why is Apple beefing up iOS mutltitasking? iOS
'preemptive multitasking' preempts ALL apps outside of Apple's core

Now I get it. You really don't know what "preemptive multitasking"

No, my point is the way Apple implements P/MT/MT in iOS is NOT true
multitasking as it is NOT<global> and IS limited compared to most PMT.

Apple implements multitasking via PMT. iOS is limited because of
resource constraints -- 512MB of RAM on the newest iPhone and Touch
and 256MB of RAM on the 3GS and iPad with no swap (you really don't
want to swap to SSD) Also, Apple chose to limit multitasking in iOS 4
to conserve battery life -- one of the biggest complaints aboout
Android. The *operating system* allows full PMT. Apple's
implementation limits it because of Apple's chosen priorities.

Granted, it is Apple's choice of priorities. Personally, I prefer the Android way of doing things even if it does suck up more battery.
I suspect I'll like BBTOS/QNX way even more so, but I suppose we'll see.

That's why you said that Android only does it in case of low
resources. You think pre-emptive multitasking refers to Android's and
iOS's forcing apps to quit when memory is low!

That is _part_ of it....

Which relates to resource management -- not multitaskiing. Have you
ever written a program in your life?

.... but not *all* of it. Resource management is part of Apple's PMT scheme. I didn't say it was it's entire PMT scheme. The problem here seems to be that you are still equating kernel task scheduling as PMT in it's entirety. I T I S N O T. Task scheduling is _part_ of a PMT scheme, not the other way around. Android has more of an unrestricted PMT implementation, but rather than get into detail of the mechanics, I'll simply let you read up on it:

That has *nothing* to
do with PMT. PMT is the ability for multiple programs to run at one
Since iOS 4 came out -- six months ago for the iPhone/Touch and 3
months ago for the iPad. 3rd party apps are allowed to run in the
background. There are some limitations imposed because of resource
constrainst -- memory, battery, etc.

And entirely logical.

1. Any program is allowed to play audio in the background and hook
into the audio controls UI.
2. VoIP apps
3. Location notifications -- any program can be registered to be
notified when the location changes and perform some type of process.
4. Task completion.

and a few others I can't think of.

... and this is going in the right direction as a granular refinement
of PMT, but get back to me when Jobs allows for a task manager of
sorts, with user specified task prioritization/reprioritization, and
doesn't compromise the efficacy of a microkernel

Do you really think that the average user wants to use a task manager
and deal with assigning priorities to different processes?

Perhaps not implemented like Windows Task Manager, no. But I would prefer to see every app *required* to provide the user an easily accessible task priority setting (at the very least), and the ability to dynamically reprioritize a currently running process.

Once again, you're showing your ignorance. In a CMT environment, the
OS doesn't control when an app has to release the CPU, the app
controls it. In the case of Macs pre OS X, it was via the
WaitNextEvent call. With iOS, the operating system controls when an
app get's CPU time.

I'm well aware of the differences between CMT, PMT, RRP,

In that case, why did you bring up CMT in regards to iOS? iOS has
*never* let the program decide when to give up the CPU.

Because iOS (as I've observed it running on an IPhone) feels just as clunky to me as an early 'classic Mac' OS.

Furthermore, you're really showing that you have no clue on how iOS
worked even pre-4.0. iOS completely purged a 3rd party app from
memory before OS 4 --- which has nothing to do with PMT versus CMT,.

That is correct - it has>nothing< to do with PMT vs CMT. Of course,
I was referring to the lack of a global PMT, not just housekeeping
chores implemented at a higher OS level.

So why bring up CMT at all?

See above

And you're still confused. "True multitasking", is PMT when Nothing more
nothing less.

>>>>> WRONG<<<<<

You are the one who is confused. You seem to think PMT is an OS level
only function - it is not. Even in AmigaOS, _users_ had control over
PMT at a very high level via the AmigaDOS 'ChangeTaskPri' command.
While the OS _can_ decide when an app gets allocated resource time,
PMT does not dictate, nor imposes arbitrary limits on who/what does
the 'preempting' in PMT. You are confusing kernel level task
scheduling with PMT. "True" multitasking is a scheme that is both
_global_ and _dynamic_, and to some degree, allows the user control.

So, is an OS not "true" multitasking when the user doesn't have
permission to change priorities? Words Mean Things. You can't
arbitrarily decide what terms mean that have a well define definition.

No, a PMT scheme doesn't _have_ to have user capable prioritization. It _is_ a more complete, rounded out scheme if it provides users with it however.

And that has nothing to do with whether the OS is responsible for CPU
scheduling -- which differentiates PMT versus CMT.

It has _everything_ to do with it. The 'OS'(as a whole) should NOT be
responsible for CPU scheduling - _only the kernel_. The OS (and even
at the UI to some degree) outside of the kernel can have a
deterministic effect on _task prioritization_, but it is (and should
be) only the kernel that actually handles thread execution/task

You can make up any definition you want to -- but you claimed that iOS
was akin to CMT.

"akin" is not exactly the "same" as.

Sure there is a such thing as architectural purity. But in the real
world, sometimes architectural purity needs to be broken. But then
again, you would know that if you were a programmer.

Back in the 8-bit era. We *knew* that self modifying code was bad,
but we also knew thel number of clock cycles we saved by doing things
the "wrong" way. Just like I'm sure the developers of XNU knew the
benefits of pure microkernal but took real world considerations into

Or coding hardware timer based loops that only later broke the software when run on newer faster cpu, or banging directly on hardware, siezing exclusive control of it when it supposed to be a sytem shared resource ...

Preemptive multitasking forces applications to share the CPU whether
they want to or not, but the _user_ can still be/should be allowed
deterministic input. (Only Steve Jobs seems to think users should not
be allowed this, and only recently even allowed programmers more
control of this.)

No, Apple knew that for a consumer focused device -- especially a
phone, that *nothing* should interfere with the primary purpose of the
device. The average user doesn't want to manage their phone like they
want a computer

So your saying Apple builds devices for average "masses are asses" users?

OTOH, QNX is/has always been preemptive, as BBTOS is. Now, whether or
not PMT is ideally user manaeagable for all smartphone users, that is
another discussion entirely (I tend to favor Job's view on that one),
but on a>tablet<, as a more functional computing device, it SHOULD be
PMT all the way, with a complete/full implementation allowing user
deterministic input.

You mean the "more functional tablet" that won't even have a mail/
calendar client without being tethered to a BlackBerry phone?


Or the
one that only has two SDKs available at launch that only supports AIR,
Flash, and WebWorks? The industry tried to market a tablet with a
full OS before the iPad. How did that work out.

I fail to see your point between only two SDKs at launch and a full OS. And where was this monolithic 'industry'

Have you seen in *any* of their demos where they will allow *users*
that kind of fine grained control?

No, but there has been discussion of it onother forums.

My guess is that even BBTOS won't allow this (at first anyway), but
the underlying OS, all the way down to the microkernel *does* allow
for it, and in a more clean implementation because of the separation
of kernel functionality and higher OS framework.

The higher level frameworks are the graphics, sound, frameworks, etc.
They are not built into the XNU kernel

a) Still haven't shown in the documentation where the SDK gives you
access to RIM's modifications/additions.

I never said the current SDKs do... *ever* That's _your_ worn out
drum, not mine.

Then why post links about the QNX SDK when those aren't relevant to
the average developer working outside of RIM?

Because BBTOS is based on the OS that currently _does_ have the developmental tools and are currently available to write processes, servers, apps or even an entire OS that can run concurrently on or with BBTOS. You've offered nothing to prove contrary, only conjecture that one has to be 'blessed' by RIM in order to get into the BB app store. Did it ever occur to you that RIM themselves may be hedging their bet on their investment by allowing other development efforts on their hardware? Gee, thats a novel concept, ain't it? Like that has never been done before...

Oh, and the "average programmer" is a dodge on your part to be dismissive of what I've repeatedly shown proof of being able to do on a Playbook. You seem to equate currently "unsupported", with "banned", "forbidden", or "impossible". That is a negative assertion which is unprovable. It also assumes/implies a static developmental environment for PlayBook based on your dismissive attitude.

That aside however, you seem to think that RIM's
"modifications/additions" are of RIM's design, and not QNX's. This
could not be more wrong. _Every_ indication seems to point to a
plug-n-play approach to RIM's development of the PlayBook (choice of
hardware, OS, aquisition of OS supplier, and their aquisition of the
original Android UI designer, The Astonishing Tribe).

Again, these pesky facts are getting in your way. Both WebWorks and
AIR are based on Web technologies therefore right now, third party
apps wil use an HTML based rendering engine. They both use Webkit,
which was acquired from a *separate* company -- Torch Mobile.

While this is speculation on my part, it is based on informed
speculation: BBTOS will also likely run Android apps.

b) Haven't shown on BB's website whether they are officiially
supporting anything besides WebWorks, AIR, and Flash *right now*.

I never said they were 'officially; supporting anything anything
besides WebWorks, AIR, and Flash *right now*. This is, always has
been, and apparently always will be your mantra or assumption of a
static/closed nature of Playbook SDKs.

Then why bring up the QNX SDK when it has no relevance to what third
party developers can do now?

Because I think the developers of BBTOS probably know and understand the capabilities of it being built on their own OS with a 30+ year history/track record, at least better than you do.

The fact that the I A> provided links above to well developed _QNX_
platform tools targeting the chosen hardware of the PlayBook, B> QNX
tools targeting the PlayBook have the broadest/widest support of
development host environments (hence more likely to garner support
from a broader number of developers), C> QNX itself remains an
autonomous operation that is still supporting/selling it's OS and
SDKs, D> has developed RIMs Blackberry Tablet OS for them, D> and the
currently available SDKs ...

And the QNX SDK's have *nothing* to do with user level programs where
the UI is not based on QNX but are based on the WebKit rendering

Goal post move: You're original comment had to do with native app development being impossible at this time. I simply pointed out this was false (which it is) as the very tools used to develop BBTOS UI already exist, have existed for 30+ years,

Have you actually *ever* written a program for any mobile device?
Have you actually even read the documentation for either iOS, Android,
or RIM?

I opt to question the questioner, so now it's my turn...<<ugh>>
<<grunt>> (damn! This goal post moving is HARD!)

Who is moving the goal post? You repeatedly post about QNX

Because QNX is relevant since BBTOS is based on it.

when we
are discussing user level programing on BB.

Noooooooooooooo...*you* are the one insisting on just what is and isn't possible or allowed on a PlayBook (OK, you didn't say "allowed", you said "blessed"). You have have offered absolutely _zilch_ for proof. I, OTOH, have have provided several sources to prove it is possible, and historical precedence for such a possibility.

You have shown no
understanding of why QNX has little relevance on what the typical
third party developer would be using when developing and app based on
BB's implementation.

I never claimed what a "typical 3rd party developer" would or wouldn't do on BBTOS implementation, nor did I limit development to just "typical" 3rd party developers writing apps only. I only posited what would be _ABLE_ to done. You are the one making all the assertions that QNX Neutrino based BBTOS won't work with apps created with the very tools used to create BBTOS itself. This is absurd on it's face, and is a negative assertion which is unprovable,

Or if you turn it around, and make it a POSITIVE ASSERTION, and state that doing so will require RIM's 'blessing', the burden falls on *you* to prove otherwise.

I'm still waiting for this 'proof'...or perhaps you are saying RIM's PlayBook is a totally unhackable piece of hardware, and RIM has done what Apple could not (stop hacking/reverse engineering the hardware specs).