Linked by Thom Holwerda on Mon 9th Apr 2012 12:02 UTC
PDAs, Cellphones, Wireless RIM has announced it's going to remove the PlayBook's ability to sideload applications. The company claims it's to prevent the piracy problems in the "chaotic cesspool of Android Market". However, the company provided no evidence, studies, or whatever to back up their claims. Considering the state of RIM's business, I'd say the company has bigger fish to fry, but alas. At this point, I'm just hoping they don't do a BeOS, but open the QNX code before they go belly-up.
Order by: Score:
Question
by earksiinni on Mon 9th Apr 2012 12:44 UTC
earksiinni
Member since:
2009-03-27

One would think that QNX alone would be profitable enough to hold RIM over?

Reply Score: 4

RE: Question
by galvanash on Tue 10th Apr 2012 01:35 UTC in reply to "Question"
galvanash Member since:
2006-01-25

I'm assuming that was a joke, right...?

RIM only paid $200 million for QNX outright. I have never seen P&L for Hamon International breaking down revenue by product division, but I would be shocked if QNX generated even half of RIM's purchase price in annual income from licensing (otherwise RIM would have had to pay far more for it).

Update: Actually, I just found this: http://blog.vdcresearch.com/embedded_sw/2010/04/update-2-rim-to-acq.... It appears analysts put $200 million to be 5X QNX's revenue. If that was 100% profit, it would still be only $40 million a year... Not much. At all. RIM probably spends more than that on travel expenses...

RIM's annual revenue (as of 2011) is nearly $20 billion, with close to $3.5 billion in income. If RIM started licensing QNX now to 3rd parties and made back their purchase price in one year that would still be only 5% of their profits. And that is extremely optimistic - I really don't see much reason at all that they would be any more successful than Harmon International was at licensing it.

QNX is a great RTOS, and there is a market for it. But the traditional embedded market just doesn't have the volume it would take to make it make it worthwhile for RIM to bother. Either that make it work as their flagship OS or they will fail - licensing it is an act of desperation. The only exception might be getting a Samsung/LG/HTC or someone like that to license it (i.e. someone selling ALOT of high dollar hardware), but I just don't see that happening...

Im with everyone else - hopefully they can sell/open source QNX before the ship sinks.

Edited 2012-04-10 01:41 UTC

Reply Score: 3

RE[2]: Question
by earksiinni on Tue 10th Apr 2012 16:36 UTC in reply to "RE: Question"
earksiinni Member since:
2009-03-27

I had no idea. I just assumed that the RT embedded OS market was huge and that QNX was the dominant player getting the lion's share of the market. Thanks for the info!

Reply Score: 2

Alas
by fithisux on Mon 9th Apr 2012 12:50 UTC
fithisux
Member since:
2006-01-22

"open the QNX code before they go belly-up"

Reply Score: 4

Grammar Police Will Deal With This
by Al2001 on Mon 9th Apr 2012 13:02 UTC
Al2001
Member since:
2005-07-06

BEOS didn't open the QNX code.

Reply Score: 1

Athlander Member since:
2008-03-10

He means that BeOS didn't open the code for their OS, and that he hopes RIM don't do the same with QNX - that is, that RIM open sources the code for QNX before they, too, fall into oblivion. In other words, that RIM doesn't "do a BeOS" - that is, keep the code for no discernable reason.

Reply Score: 3

Bill Shooter of Bul Member since:
2006-07-14

Oh, there was a discernible reason for not opening BeOS source code when BeOS went under: They sold it to Palm. The BeOS stockholders probably appreciated some partial return of their assets, after they missed out on the mother load that would have been the apple acquisition. I can blame palm/Access for doing nothing with it since their purchase. They should open source it.

Reply Score: 4

Athlander Member since:
2008-03-10

I stand corrected - it seems Cobalt's multimedia and graphic framework was derived from BeOS, so I guess there was a reason not to open source it.

Reply Score: 2

earksiinni Member since:
2009-03-27

The problem is that right now it reads as if to "do a BeOS" involves opening up the source code, and Thom is hoping that they therefore don't open up the code. The "don't" is ambiguous and can be seen to be modifying "do" and "open".

A more clear version would be: "At this point, I'm just hoping that they don't do a BeOS and that they open the QNX code before going belly-up." (Changed the end because three "they"'s would be too much.)

Reply Score: 4

QNX to FSF = HURD
by miker on Mon 9th Apr 2012 13:33 UTC
miker
Member since:
2009-07-08

QNX is the only successful microkernal POSIX operating system. I have thought for awhile, that donating QNX to the FSF is the only way Hurd will ever become a reality.

Reply Score: 3

RE: QNX to FSF = HURD
by CapEnt on Mon 9th Apr 2012 14:29 UTC in reply to "QNX to FSF = HURD"
CapEnt Member since:
2005-12-18

I think otherwise: it's the fastest way to bury Hurd into oblivion, since QNX will swallow his few active developers if open sourced.

Reply Score: 3

RE[2]: QNX to FSF = HURD
by demetrioussharpe on Mon 9th Apr 2012 20:30 UTC in reply to "RE: QNX to FSF = HURD"
demetrioussharpe Member since:
2009-01-09

I think otherwise: it's the fastest way to bury Hurd into oblivion, since QNX will swallow his few active developers if open sourced.


Either that, or bury QNX in the developmental hell that's HURD development. Injecting a working system into a broken system doesn't always yield good results. More than likely, the HURD developers would try to make QNX match the HURD philosophy, ruining QNX in the process.

Reply Score: 1

RE: QNX to FSF = HURD
by Bill Shooter of Bul on Mon 9th Apr 2012 14:29 UTC in reply to "QNX to FSF = HURD"
Bill Shooter of Bul Member since:
2006-07-14

The problem with HURD is not the lack of a viable microkernel, its with HURD's complex design and ambitious goals combined with lack of developer resources.

In retrospect, they probably should have in the name of freedom, just done a FOSS unix-like clone. Its pretty clear the FOSS market chose that in GNU/Linux, rather than trying to realize the HURD.

Reply Score: 2

RE[2]: QNX to FSF = HURD
by demetrioussharpe on Mon 9th Apr 2012 20:32 UTC in reply to "RE: QNX to FSF = HURD"
demetrioussharpe Member since:
2009-01-09

The problem with HURD is not the lack of a viable microkernel, its with HURD's complex design and ambitious goals combined with lack of developer resources.

In retrospect, they probably should have in the name of freedom, just done a FOSS unix-like clone. Its pretty clear the FOSS market chose that in GNU/Linux, rather than trying to realize the HURD.


Right! At this stage of the game, HURD's the poster child for vaperware.

Reply Score: 1

RE[3]: QNX to FSF = HURD
by Bill Shooter of Bul on Mon 9th Apr 2012 22:34 UTC in reply to "RE[2]: QNX to FSF = HURD"
Bill Shooter of Bul Member since:
2006-07-14

No, the development is in the open. Its been worked on, and you can track the progress and even test it on virtual machines. Not what I would call vaporware.

http://www.gnu.org/software/hurd/

Reply Score: 2

RE: QNX to FSF = HURD
by Thom_Holwerda on Mon 9th Apr 2012 14:39 UTC in reply to "QNX to FSF = HURD"
Thom_Holwerda Member since:
2005-06-29

QNX is the only successful microkernal POSIX operating system. I have thought for awhile, that donating QNX to the FSF is the only way Hurd will ever become a reality.


I highly doubt QNX can be made FSF-compliant open source. It's chock-full of patented and proprietary technology (i.e. drivers).

Reply Score: 2

RE[2]: QNX to FSF = HURD
by fithisux on Tue 10th Apr 2012 08:28 UTC in reply to "RE: QNX to FSF = HURD"
fithisux Member since:
2006-01-22

Yes but special drivers could be removed. Moreover Hurd could work with Darwin Mach version and enhance it. The bonus : IOKIt.

Reply Score: 2

Comment by grantpalin
by grantpalin on Mon 9th Apr 2012 21:24 UTC
grantpalin
Member since:
2011-02-11

As a Playbook user since last summer, I both appreciate this news and worry about the aftereffects.

It's no secret that the AppWorld selection has not been on par with other platforms, though it has steadily improved since the initial release last year - more apps, better apps, useful apps. I don't need half a million apps, I just need the ones I can use day-to-day. I don't use Skype or Netflix, so their absence does not bother me.

That said, I can appreciate what the side-loading ability has done to bolster the app options. I've used the ability to sideload apps that are freely available, yet are not in AppWorld. The loss of this ability will severely curtail the app options.

I do see the rationale behind this move, in reducing use of pirated apps (I've seen numerous requests in the CrackBerry forums for help in converting paid Android apps), and to provide some solace to would-be developers concerned about app piracy.

The possible upside of this move is that app developers may feel better about developing for the Playbook with piracy out of the picture. On the other hand, if developers simply weren't interested before, the perspective may not change after.

Time will reveal the result of this move. It could be good, or it could be bad. Makes me even more interested in working on an app or two for the Playbook.

Reply Score: 1

RE: Comment by grantpalin
by Alfman on Mon 9th Apr 2012 22:17 UTC in reply to "Comment by grantpalin"
Alfman Member since:
2011-01-28

grantpalin,

"The possible upside of this move is that app developers may feel better about developing for the Playbook with piracy out of the picture. On the other hand, if developers simply weren't interested before, the perspective may not change after."

You're comment covered two possibilities but ignored another: some developers are put off by monopolized app distribution channels. I thought the possibility should be mentioned since it covers most open source guys and some proprietary ones who'd rather market and distribute themselves.


Anyways, I personally feel DRM is mostly evil and hurts legitimate users more than anyone else by curtailing fair use rights, etc. Never the less, as misguided as I find DRM to be on both technical and moral fronts, I do understand the motivation of executives to buy into it. However if RIM's intention was just to offer better copy protection, it should just offer it's DRM API's to all developers regardless of sideloading.

Edit: I'm assuming RIM has DRM at all, but I suppose it might not have any DRM to offer developers? I don't know, but time and time again the solution is to improve sandboxing rather than to disable sideloading.

Edited 2012-04-09 22:26 UTC

Reply Score: 2

It was a dumb move
by twitterfire on Tue 10th Apr 2012 08:46 UTC
twitterfire
Member since:
2008-09-11

It was a big fail for RIM and a big win for the guys selling QNX.

With 200 millions USD one can probably hire developers to write at least 20 operating systems, QNX-like. Probably they payed that nice amount of cash because they were in a hurry and they wanted it overnight.

Probably they wanted something proprietary, non GPL, so they can keep their source close. But they could have used FreeBSD or NetBSD instead.

If I were RIM shareholder I'd fire the CEO in a second.

Reply Score: 2