Re: Andriod - coming on strong!

On Feb 3, 8:44 am, Flint <age...@xxxxxxxxxxxxx> wrote:
On 1/30/2011 10:45 AM, KDT wrote:

So as of *right now* Blackberry doesn't have a public 3rd party SDK
that allows native apps/
So what other SDK are they going to use *right now* with full access
to the API and Frame work for *RIM's* operating system.  An operating
system is more than just the kernel/

None.  So what?

So now it doesn't make any difference that third party developers
can't write native applications and are stuck with a glorified web
app?



*Every* OS is "highly extensible".

Untrue.

Hell, even ProDOS for the Apple //e was extensible....

Goal post move:  First, you said "Highly" extensible.  Then you down
shifted to just "extensible".

And now you're going to explain the technical difference that makes an
OS "extensible" versus "highly extensible"....




Second, ProDOS is not a true OS - it was a _disk_ operating system.


Number 1. It is silly to say that a "disk" operating system is not an
"operating system". Ever heard of sets and supersets?

ProDOS managed more than just "disks". It also managed input and
output. It overrode the Apple ROM hooks for input and output


iOS is based on the XNU kernel and
allows for kernel extensions

Architecturally impure, and contains a greater degree of
corruptibility to the point of trashing the whole OS, and less
efficient multitasking both from a theoretical standpoint and from a
UI experience.

Actually UI experience is more a function of whether the programmer
spawns long running processes in a separate thread from the UI thread
and whether the UI is assisted via the GPU, That's why you notice a
difference in the fluidity between an iOS device and Android devices.
In the "real world" (which you would know about if you actually
*programmed*), software engineers make all sorts of compromises based
on real world considerations..




If Apple doesn't "allow it", then neither does the OS.

So, if an OS doesn't allow a user to assign a process as "real time"
because of performance considerations, does that mean the OS doesn't
allow it? There are a lot of things that an OS is capable of that an
untrusted app is not allowed to do.


So how is it *ever* a good idea from a security stand point to allow
untrusted apps to run outside of a sandbox on a mobile platform?

Another strawman?  Tell me, how is iOS more secure than BBTOS?

If BBTOS will allow "untrusted" developers to write kernel extensions,
which it definitely won't. It will be less secure.



Do you really think all of those great features are going to be
exposed to developers via Adobe Air and WebWorks?

Another strawman.  Never said they would be by those SDKs

You have been posting about the QNX SDK from the beginning of this
thread -- which is completely irrelevant to the average developer.


Didn't say they were.  What I am saying is the underlying microkernel
allows for multiple processes that can share services to such a degree
that no other mobile OS I am aware of can because of the QNX
architecture.  Furthermore, it can do so because of the degree of
architectural 'purity' as you called it, or more accurately the
protected user space memory.  Neutrino even allows for multiple
concurrent OS layer services to float on the same microkernel, and is
also a truly _scalable_ OS allowing multiple microkernels running on
multiple cpu nodes to be interlinked into a networkable or distributed OS..


That's all cute and everything, but you still don't know *from first
hand experience*, how that relates to the PlayBook...



Oh, and before you go off on another boring rant dissing a product you
haven't seen yet,

As you've been bragging not only about a device that you haven't seen
yet. But from someone who has never programmed on a mobile
device.....


just be mindful of the fact that the PlayBook is
being targeted for truly mobile computing as was demo'd as an in-dash
auto device providing in vehicle networking.  I guess RIM won't be
using that QNX history/experience either, huh?

Exactly a demo You really think being able to network a device is
rocket science. You're easily impressed aren't you?



So how is a third party developer that wants to write the latest 3D
game on the Playbook going to do that with RIM supported tools --
*right now*?

Always in the here and now, aren't you.  You are such a dullard.

Yes, silly me for not making uninformed arguments based on
vaporware.

 Its
truly difficult to imagine you doing any programming on such a
'visionary' iPad by such a 'visionary' company called Apple.

I don't have to *envision* a great native SDK for the iPad, it exists
now.



Not necessarily.  QNX, it's OS architecture and current SDKs are very
relevant and usable even on a PlayBook since both were used to create
BBTOS.

And can I as a normal developer use it?


 QNX had most of BBTOS was already developed as BBTOS is more
of an 'off the shelf' built OS on an already established OS with tools
and a history of usage.  

The "OS" consists of the kernel as well as higher level functions
dealing with UI, chipsets (GPS, Cell ,media framework, etc) that did
not come from QNX -- especially the UI which is based on WebKit, which
came from another acquisitiion.

The hardware of a PlayBook (OMAP4430 - ARM
Cortex A9 + PowerVR SGX540) is supported already by existing QNX.
True, the higher frameworks have to be used via the currently
available SDKs, but I suspect you are intentionally muddling two
issues here:  Native code development & multitasking.


I did no such. This who thread has been about third party developers
being forced to write glorified web apps.

Since the microkernel design is such that it is scalable across
multiple cpu nodes (linking microkernels on each), or go the opposite
direction and hosting _multiple_ operating systems on the _same_
kernel, limited only by resource availability.  Considering a PlayBook
will have _4x_ the memory of an iPad (2X the memory iPad2 is rumored
to have), I think its fairly obvious that a PlayBook will be a bit
more 'open' than the iPad, and if not, at the very least it's PMT
scheme will provide a considerably more usable environment for
developers to target.

And in theory, the latest Android devices should be more fluid an
usable than a 1st gen iPhone. The devil is in the details.

As to the significance of a native coding SDK (or current lack
thereof), that is a debatable issue based largely on the requirements
and skill set of the developer I suppose.

And you have evidence that BB will allow native apps -- *right now*
based on what exactly?


 Your example of a 3D game
app strikes me as a bit of a stretch to me since the platform as whole
is not an ideal gaming platform (on any tablet device for that
matter),

Tell that to EA and the other companies that are making millions of
dollars on games for iOS devices.....



so I tend to consider this rather moot.  Personally, I tend
to feel the PMT implementation is more important because of the need
to provide a smooth and pleasant 'entire web' UI experience, and right
now(and forseeable future) this requires *flash*.

Have you actually tried to use a flash based app designed for the PC
with a touch screen device that lacks a keyboard and a mouse?

 Personally, I tend
to think BBTOS's Webworks/WebKit implementation along with flash and
Java implementation represents a very balanced and real-world
trade-off which makes more sense than compromising the architectural
purity of the underlying OS components/microkernel.

So I'm sure end users will care about "architectural purity" more than
being able to actually run great apps...


 The comparative
demos of PlayBook and iPad multitasking certainly seem to bear this out.

Exactly,,,,demos.




Yes I am, based on the user-hidden parts/QNX roots of BBTOS _alone_.
Just because they don't see those, doesn't mean they won't see/derive
the benefits of this in the UI experience.  If anything, its more of
what they _won't_ see or have to put up with that will be the highest
praise of it.

And Android has "hidden roots" of Linux but the fluidity of the UI is
horrible because of Google's implementation.


And you seem to be confused with what QNX *can* do and what RIM's
implementation is going to allow to be done with their
implementation....

I'm not confused about either.  I'm just saying whether RIM *supports*
it or not, or via jailbreaking, the platform as a whole is a more
suitable/usable device because of it's QNX roots - period.

Is this simple enough for you?

And you think basing a business model on selling apps to users with
"jailbroken" devices makes sense?



You mean like saying that supporting native apps and even Java apps is
"coming soon"?  I never stated that RIM would never allow native
apps.  But *right now* the only supported way to write apps for the
Playbook is via WebWorks, AIR, and Flash.

OK, native app coding isn't quite possible at just this time.  The
significance of this _is_....?

You really don't think not being able to write real apps is not a
negative?


If the developers didn't have access to it, then the capaability
_didn't exist_ for them, period.  

You mean like writing native apps on the BlackBerry......

Just as you jumped all over my
pointing out QNX capability as being irrelevant because of your
coloring book & crayons perception of available SDKs, the same logic
applies to your statement.  You can't have it both ways.


iOS 4 is available *now*. I'm not whimsically posting about some
capability that may be available in the future.....



No it isn't. You seem to be making the mistaken assumption that RIM
just took the QNX source code lock stock and barrel and recompiled it
without changing any of the higher level frameworks and programs will
just magically work on the Playbook.

I never said such, but that statement on your part definitely shows
your lack of understanding of the fundamental differences between the
QNX architectural base of BBTOS and Apple's iOS, nor hacve you even
perused the architectural overview.

Right, so that's why you post links to the QNX SDK when we are
discussing the Playbook? As if you think someone can just download
the QNX SDK and start developing apps for the Playbook. Let me know
how that works out for you.....



Never said they are not coming -- unlike you, I actually went to the
developer's website.  They are not available *now*.

Again, what is the implied significance of this, then?

It's more significant to look at the SDK's from BB's website than
posting a link to a QNX SDK.

.

Relevant Pages

  • Re: Andriod - coming on strong!
    ... So now it doesn't make any difference that third party developers ... downloaded 10 Billion+ iOS apps. ... QNX provides a tight integration between message passing and CPU scheduling, and is one of the key efficacy of QNX message passing. ... BBTOS is said to ...
    (comp.sys.mac.advocacy)
  • Re: Andriod - coming on strong!
    ... 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. ... developers to write apps that aren't hosted on the CLR. ... multitasking as it is NOTand IS limited compared to most PMT. ...
    (comp.sys.mac.advocacy)
  • Re: Andriod - coming on strong!
    ... So now it doesn't make any difference that third party developers ... downloaded 10 Billion+ iOS apps. ... difference in the fluidity between an iOS device and Android devices. ... Agreed, but there is a point in the QNX OS environment, an 'untrusted ...
    (comp.sys.mac.advocacy)
  • Re: Andriod - coming on strong!
    ... that developers will be limited to just these two SDK platforms. ... What I am saying is the underlying microkernel allows for multiple processes that can share services to such a degree that no other mobile OS I am aware of can because of the QNX architecture. ... Oh, and before you go off on another boring rant dissing a product you haven't seen yet, just be mindful of the fact that the PlayBook is being targeted for truly mobile computing as was demo'd as an in-dash auto device providing in vehicle networking. ... is documented how an average developer can write OpenGL based apps? ...
    (comp.sys.mac.advocacy)
  • Re: Andriod - coming on strong!
    ... So what other SDK are they going to use *right now* with full access ... I've never argued that this isn't a limiting factor in BBTOS, but you haven't provided any useful insight as to how this is a devastating limitation, or how this is more important than initial prioritization of a fully usable web experience, and tools aimed towards that end first. ... It would be a pointless and wasted effort on someone who hasn't even read the architectural overview of the QNX, or fails to understand it's benefits, or even the fundamental difference between a microkernel based OS and a monolithic OS, and is practiced at feigning ignorance and putting words into others' mouth. ... Agreed, but there is a point in the QNX OS environment, an 'untrusted app' doesn't always equate with _all_ 3rd party apps, and user processes can appear as OS services and vice versa. ...
    (comp.sys.mac.advocacy)