1) You linked to a ?prestigious award? from almost 7 years ago.
2) I don?t care how power friendly QNX is (which has yet to be seen since you won?t list any current handheld devices using QNX), if you have a poor UI, drivers and apps having an efficient kernel isn?t going to work.
3) So far, you are the only one speaking out the side of your mouth. Wu made stated the PlayBook tablet has poor battery life, he then inferred that the reason was QNX. His latter doesn?t have to be correct for the former to be true. They all have to be well managed for power usage or the product may be as big of a dud as the Palm Pre.
4) You can say that it has good power management, but compared to what? Are you saying it?s better than Android or Darwin? Are you saying it?s better than other OSes from 7 years ago? Big fraking deal.
5) The PlayBook is only half done? If it comes out in May that means they only started working on it 6 months ago?. You really think it?s a sound argument to suggest that the PlayBook has been touted by RiM and raised up by their CEOs as the bestest thing in the whole wide world when it?s only ?half done?? Really?!
While I don't agree with a lot of what samab has to say, I admit I trust him much farther than I trust Wu on technical matters.
PlayBook appears to be going down hard. QNX is obviously involved in that even though it is probably not the root cause. The root problem is probably more along the line of trying to do too much too fast and not being able to get everything done right and on time. Given RIM didn't really have any time to waste in the first place, I think they just hastened their demise by over-promising what they should have set up to deliver in 2012. Or really what they should have started on in Feb 2007 for a 2010 delivery.
(1) Safety RTOS moves at a much slower pace industry-wise than the general operating system. The space shuttle is still running on a computer built in the 1970's.
No, it's not. All the shuttles were retrofit with 1980's era computers in the mid-90s when NASA did the glass panel flight deck upgrades.
Quote:
Logitech remotes are pretty recent, so as the military radio and so as the harman/becker personal navigation devices. Much more recent that the big cisco router which was launched in 2004.
(2) Sure if you have a poor UI, device drivers and apps then that is going to negate much of the advantage. But it is the same AIR UI that powers car dashboards --- and they only have something like a 200MHz CPU. Device drivers and much of apps shown are done by QNX, the same people who won the power management award.
Given the applications you cite, and the thresholds auto manufacturers consider as power savings, I wouldn't try to use them as major rallying points for handhelds and recent tablet computers. Pushing a couple dozen preprogrammed textures and automotive rate moving map device doesn't need much CPU horsepower.
Quote:
(3) Sure, Shaw could be right that the current beta Playbook has poor battery life. But what to do with that fact is what is important. Shaw thinks that RIM needs months and months of tinkering with QNX because QNX is supposedly built for the big routers and not for battery life. Well, QNX is embedded in handheld military software defined radios where poor battery life could kill your own soldiers.
I agree Wu is full of it technically. But even though he gets the specifics wrong, I think he's right that the PlayBook will need months and months to get power management right given the state of the "Beta hardware". Even a blind squirrel finds a nut once in awhile.
Quote:
(4) Compare to what? QNX won the award at the Embedded World Conference. It is not like the BeOS fans who thinks that their OS is godlike --- but it was only godlike because they were comparing it with Windows 95.
OK fine. But that's not helping RIM right now. Is it. This actually places the PlayBook team in a worse position given the current beta has the confirmed by RIM problems it does.
Quote:
(5) Speed to market --- that's what having a completely certified POSIX operating system is all about. Back 10 years ago, Sony announced their BeOS-based evilla internet appliance --- took 18 months to launch. Later on, 3Com hired some 3rd party QNX consultant to design the Audrey --- took 6 months to launch, sold them for a few months and then discontinued the Audrey before Sony finished their evilla design.
So does discontinuing something make it a good example? Or was that because they rushed it and made a turd that nobody wanted? Speed to market is only meaningful when you deliver a properly designed well engineered product. The old saw "fast and broke is still just broke" applies liberally here.
Well, to be fair, having a tablet that can't run apps other than a web-browser would be a redefinition of what a tablet can do -- kind of like having a car that can only drive in reverse would be a redefinition of what a car can do.
Yep. Now we have to see if the target audience agrees with the nature of the redefinition as a good and useful change. Or if they like that 'old' way and stick with it
It is worth noting that Wu's source on this are even more sketchy and tabloid than his Apple sources. Frankly I can't help wondering if he is down talking the Playbook to encourage sales and pull the price down. Regardless, it doesn't appear he has held or used one and real world use is what will give us the best read on this device.
Nor is it a black science that only Apple understands.
And just what does that have to do with the cost of a slice of bread?
And you think only Apple is capable of doing this?
Besides much of that design effort is not taken care of buy the SoC design process and the package on package construction of the processors going into these machines.
You blew it right there. The implication that things are going wild on the Playbook is joke and you have no basis for stating such.
Flash is a problem but that should surprise absolutely no body.
Sure Flash isn't a big help with respect to long term performance but it gets product to market and people here mis the importance of doing this. Playbooks long term success will be built around the coming SDK just as the SDK lead to an explosion of apps on the iPhone which then had an additive impact on iPhone sales.
You see what bothers me here is that Apple shoved iPhone out the door with just web app support when it first debuted. After a good long while we eventually got the SDK. Why when RIM is about to do the same thing, it gets no respect is beyond me. Sure they could fail, but they need to try. Especially if you are a die hard Apple iPad owner as it means pressure on Apple to upgrade.
Well, when an iPad gets at least twice as much battery life than all comparable competitors, that tells me that Apple is doing something that the competitors are not. Right?
Threads *are* going wild on the PlayBook when a flashed based video player is designed to play multiple video streams with only one stream being visible. That is capital offense on a tablet device and will cause users to deplete their batteries in minutes. The best software engineers at Apple and Microsoft agree that this should not be done this way for various reasons.
HP tried to rush a tablet out of the door with a Flash UI and failed but at least they recognized that it was not worth shipping. For RIM to cut corners with Flash/AIR and rush to market is a mistake. I think that they should have gone with Palm or MEGO.
I've held way too many of those "handheld" radios. The batteries are IMMENSE! (compared to anything in the consume mobile space) And you have to carry extras for just in case.
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
Quote:
I'll give QNX props for energy management. Embedded operating systems that can be used for remote sensors do not suck power for their own benefit. (The radios tend to ignore that in my estimation.) Shawn Wu is talking out his arse when he says what QNX is and isn't designed to do. I can believe the basic facts on PlayBook battery life he reports, but have to completely filter out anything he says when it comes to technical explanations.
They aren't even facts. It really is just crap running out of his mouth.
Quote:
Also @Dick, in the QNX context "application" means "device" rather than software "app".
What I'll call BS with on RIM though is that an embedded OS that does do remote sensor in other applications is suddenly not implementing power management in beta hardware? WTF, are they going to ship an Alpha implementation?
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
Quote:
To make that comment at all is incredibly telling. Power management isn't just something you slap on after the fact. It's inherent in both the hardware components and the software drivers.
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
In any event why would you be focused on power management when so much else needs to be done.
Quote:
If power management isn't implemented yet it either means they are going to be shipping VERY new drivers, or different hardware than they are developing and testing on now. I highly doubt both of those last two possibilities.
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
Quote:
That leaves me with one nasty little suspicion that a senior manager of engineers has pulled a good old "Debug Code"-class excuse out his little arse and the non-technical half of the dual core CEOs ate it up. Fully.
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
...
In any event why would you be focused on power management when so much else needs to be done.
...
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
I agree with the above bits!
What bothers me is that this PlayBook "product announcement" is all over the place...
What is it:
-- a proof of concept prototype?
-- a pre alpha?
-- a pre beta?
Most observers will admit that a lot needs to be done before the PlayBook is an actual product.
Let's assume that RIM has the talent and manpower to do all this concurrently -- when can we reasonably expect a working, shipping product?
We have a similar scenario that we can use as a comparison -- the Apple iPhone gen 1.
OK, Here is the timeline for the iPhone 1 Announce / Release
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
I was talking about a 3lb 7oz mil-specbattery with a 12oz "protective case" for transport. If you want to continue to take things out of context and look foolish doing it be my guest.
Quote:
They aren't even facts. It really is just crap running out of his mouth.
Quote:
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
Well if this was alpha hardware you would have a point, but it's not. It is beta hardware (see last para) and power management isn't a trivial feature to add at the end of development. RIM can "tweak" to their hearts content over time. But getting basic functionality of at least a days use out of a modern mobile device isn't follow on tweaking, it's core functionality that requires rigorous QA and long term testing. If it's not fully implemented and ready for optimization in the beta, it's not a beta and ready for unfettered public consumption outside the engineering enclave.
Quote:
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
OK, I agree there, but it's relatively unrelated to RIMs current problem of promising the world and finding out they cannot deliver the requisite power over the desired duration. This is everyones problem and it is solved with hard work over time, not by magic in a few short weeks. the interrelated tradeoffs and interactions with both on and off SoC components takes time to learn and optimize. You can accelerate a derivative product, but not a first design unless you are willing to bet the success of the entire product on a losing formula. It is possible to win the bet, but not a likely possibility.
As for RIM having no control over the SoC, that only works on one level, the decision of what is on the SoC. After that RIM is in complete control of how familiar they are with it and who they hire and/or contract to work with that hardware. If you want to go to market faster you need appropriate talent and management compared to how long it might take the in-house group to get up to speed before they can make solid progress. That's all still part of the hardware side of the equation.
Quote:
In any event why would you be focused on power management when so much else needs to be done.
Because a product that dies in less than 6 hours will be deemed a failure on a major feature. A beta that dies in that timeframe is going to give a major hurdle to the long term buying plans precisely because the beta is the showpiece to make a CIO want to buy something. The CIO will overlook little stuff, but short battery cycles will make them take a wait and see on the final rather than make huge pre-orders.
RIM shipped an alpha and called it a beta, now they are trying takes-backsies on the beta. That mistake alone may be enough to prevent the PlayBook from ever being successful. and the company will have to work even harder to ensure that mistake doesn't tarnish the rest of the company enough to seal a slow death spiral.
Quote:
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
Duh. Now lets get back into context rather than get willfully opportunistic and incorrectly pedantic shall we? I used new quite clearly as newly introduced to the PlayBook after the beta, not as in new to market.
Quote:
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
What part of "nasty little suspicion" tipped you off there? Yes, it was explicitly obvious it was guesswork and opinion.
As for every single feature, you are creating a false context. I never said that anywhere, ever. I have and continue to contend that power usage isn't a trivial fluff feature that can be added after the fact with little risk. Power usage is core functionality, period. And beta hardware and software had better be core functionality complete or else. Sure beta means things are still in a late post integration debugging phase, that's precisely what beta means.
RIMs use of the term pre-beta is a late to the game attempt to cover up the faux pas. You don't ever pass around alpha prototypes to expected end-use customers for their own use and business process testing. Ever. RIM admits in the press release that PlayBook units are in the wild outside their walls. Either they are betas which aren't up to snuff, or RIM is even dumber an engineering outfit than I ever imagined by letting alpha hardware out into the wild.
RIMs use of the term pre-beta is a late to the game attempt to cover up the faux pas. You don't ever pass around alpha prototypes to expected end-use customers for their own use and business process testing. Ever. RIM admits in the press release that PlayBook units are in the wild outside their walls. Either they are betas which aren't up to snuff, or RIM is even dumber an engineering outfit than I ever imagined by letting alpha hardware out into the wild.
Yeah, what does alpha or beta mean anymore?
Then what is pre-alpha or pre-beta?
Is there a post-alpha or a post-beta?
Which comes first pre-beta or post-alpha?
Is there any checklist of things that must be completed to qualify a product to have attained any of these stages of completion?
Can we build a timeline that shows how a product progresses through these stages of development.
Back in the 1950s they developed a planning discipline called PERT * (Program Evaluation and Review Technique) to plan and manage complex projects.
* PERT was later supplanted with enhanced techniques like POP (Piss On PERT).
PERT used a diagramming concept to layout milestones (like project start, alpha, beta, project completion) and the tasks (dependencies) that needed to be accomplished to reach those milestones.
Each task definition showed the estimated time and manpower required to perform the task.
The longest (duration) path of sequential tasks to reach a milestone defines the time required to attain that milestone.
If a project is behind schedule, it is easy to determine where the delays are, the resources needed (if available) to bring the task back on schedule, or the length of time the following milestones (including project completion) will be delayed.
PERT diagramming is a simple, but iterative process -- as the project progresses you learn things, continually revise the diagram, and the project schedule.
There are computer programs that evaluate the tasks and dependencies, apply calendar time, and calculate when the project (and milestones) will be completed.
For example:
The circled numbers represent milestones, e.g,:
10 - start of project
30 - alpha complete
40 - beta complete
50 - product Release
for a simple project
The arrows, Red Uppercase Letters (or starting and ending milestone nodes)) indicate tasks that must be completed, e.g.:
A (10-30) - Perform Alpha Development
D (30-40) - Perform Beta Development
F (40-50) - Manufacture Product
E (30-50) - Prepare Documentation
B (10-20) - Prepare Announcement and Promotional Material including co-muzzles
C (20-50) - Announce Product
We see a estimated time duration for each task, Gray Lowercase letters.
By calculating the duration to traverse each path through the diagram, we can calculate the longest paths (the critical paths) to project completion. This also identifies those tasks that cannot be delayed without delaying the project -- as well as tasks that can be performed concurrently.
Obviously this is an overly simplistic PERT or CPM (Critical Path Method) chart -- but it's a start.
We can take a general task like A (10-30) - Perform Alpha Development and break it into many smaller tasks: define requirements, determine development costs, prepare cost benefit analysis, determine personnel requirements, etc.
If necessary or beneficial (it usually is) we can prepare a PERT/CPM chart for these smaller tasks that comprise the general task -- showing critical and concurrent tasks.
Everything we do to refine the diagram makes it more accurate and more representative of the project to be accomplished.
All this information can entered into a computer which will calculate dependencies, identify critical paths/tasks, etc.
As tasks are completed, the chart and computer model are updated and, based on the accuracy of prediction of completed tasks (planned vs actual time) a "degree of confidence" can be calculated for reaching each remaining milestone.
In the early 1970s I worked for IBM in Software Development for the Distribution Industries in Des Plaines, IL. We were waiting to get approval on a project to begin Beta development (writing the code, in our project). After weeks of frustration trying to get the various high(er)-level approvals, the Department Manager gave me a challenge:
Assume we want to develop a program with:
-- 1 line of code
-- 1 page of documentation
and, it's already done!
How long will it take to get it through the approval process.
After about 2 weeks on the phone, I had gathered enough information to create a PERT chart and entered the information into an APL PERT program...
It would take 12 months to get through the approval process -- for example, it had to go through Pricing and Forecasting (a two week process) two separate times -- and each process had to be scheduled at least 1 week in advance.
So, then, the Department Manager asked me to see what could be done to expedite the process, e.g. things like only one pass through Pricing and Forecasting.
Another two weeks, or so, and I had a revised chart and a revised estimate.
Expediting the project added 1 week to the process -- it took 3 weeks to schedule executive (Armonk) approval to bypass the 2-week Pricing and Forecasting process...
This led to the following:
In business, to do nothing, takes 12 months!
-The Des Plaines Doctrine-
Expediting, takes a little longer!
-The Armonk Axiom-
OK.
I suspect that CPM scheduling and the like have been supplanted, over the years with more accurate project/program management and review techniques.
I suspect QNX (RIM?) needs to participate in something like the above to fulfill its contract to provide software for the moon rover and other Mil-Spec projects.
It is kind of sad, really, that the management at RIM, apparently, can't use available techniques to successfully define, manage and execute a "relatively" simple project of building a tablet -- this ain't exactly moon rover science!
However, it speaks volumes about RIM.
To be fair, things can't always be scheduled accurately -- or sometimes the stars won't align to make things happen as we wish.
I can remember a press invitation for an announcement meeting in Cupertino.
Once everyone was in place, Steve gave out some performance statistics and then made 2 product announcements:
-- the iPod HiFi
-- a leather case for the iPod
Obviously, they had planned to announce other products -- but they weren't ready...
Those two guys founded the company, so I guess they have equal authority.
I don't doubt that but what's important is: do they both have the same philosophy on the best way to run a company or do they spend most of their time compromising with each other. IMHO, any company has to have a strong, inspirational leader (singular) .... Balsillie does not "inspire me in the least.
Man, imagine if 3 months from now they delayed it another six months and in nine months they cancelled it. Sounds very much like Larrabee at the moment.
Adobe is the wrong wingman on this mission. Way wrong.
Dick, I think you may have just given RIM the product planning tools they have been needing for years - and I doubt you got paid for it...
I'm really surprised that the investment community doesn't see through RIM's bs. Not that I think they'll go out of business tomorrow, because there are plenty of companies completely satisfied with them as they are today (but this too won't last forever), but even making proclamations like they are suggests to me that they (as a company or as directors of the company) are not even following some standard business protocols.
I don't even get the sense that they're cocky about what they're doing because they indeed have something different and potentially better than what's on the market. They can't back up their promises and proclamations with real examples - because they don't have anything real to show.
The proof is in how they execute over the next year or so, but I really get the impression that RIM is one trick pony that sort of lucked into their dominate position and have no idea how to run a business when faced with competitive pressures.
They hit on their server side mobile business email solution at a time when there was nothing to compete, did a good job of building hardware to support that and in building and refining business friendly features while becoming the entrenched incumbent in that space, but as time goes on they seem less and less like a mobile powerhouse and more and more like a bright kid who invented a clever thing which sold really well but who is hopelessly in over his head when it comes to what to do next.
If Apple hadn't made the iPhone they probably could have gone on like that for quite a while, doing incremental improvements on the cash cow without feeling any real pressure to step outside their comfort zone. But now they're forced to make public statements about the roadmap, and it becomes immediately evident that these people don't have any business running a business. It's genuinely shocking, IMO.
Here is a DF snippet linking to an article about why Android’s UI performs so poorly. Is Adobe AIR HW accelerated over QNX or will it also suffer from a similar fate?
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
They aren't even facts. It really is just crap running out of his mouth.
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
In any event why would you be focused on power management when so much else needs to be done.
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
People have been doing robust power management with Neutrino for years.
That kind of just reinforces the fact that if RIM is having power issues, they are in big trouble and it is self inflicted.
RIM is shooting for 8 hours of battery life --- 80% of iPad's battery life. The Playbook (5300mAh) also has 80% of the battery capacity of the iPad (about 6600mAh).
RIM is shooting for 8 hours of battery life --- 80% of iPad's battery life. The Playbook (5300mAh) also has 80% of the battery capacity of the iPad (about 6600mAh).
1) Shooting for. Not confirmed. Not guaranteed. Just crossed finger and wishful thinking.
2) Do you really think their statement was a medium average of some maximum under ideal conditions scenario? I bet 6 hours of video will be hard to get, compared to the 11.5 hours Pogue got from the iPad.
3) 80% of the battery capacity with ½ the display size where the majority of the power is used on the iPad, with less pixels to push to the display, and a newer, more power efficient CPU. Anything else from the FUD factory?
Comments
1) You linked to a ?prestigious award? from almost 7 years ago.
2) I don?t care how power friendly QNX is (which has yet to be seen since you won?t list any current handheld devices using QNX), if you have a poor UI, drivers and apps having an efficient kernel isn?t going to work.
3) So far, you are the only one speaking out the side of your mouth. Wu made stated the PlayBook tablet has poor battery life, he then inferred that the reason was QNX. His latter doesn?t have to be correct for the former to be true. They all have to be well managed for power usage or the product may be as big of a dud as the Palm Pre.
4) You can say that it has good power management, but compared to what? Are you saying it?s better than Android or Darwin? Are you saying it?s better than other OSes from 7 years ago? Big fraking deal.
5) The PlayBook is only half done? If it comes out in May that means they only started working on it 6 months ago?. You really think it?s a sound argument to suggest that the PlayBook has been touted by RiM and raised up by their CEOs as the bestest thing in the whole wide world when it?s only ?half done?? Really?!
While I don't agree with a lot of what samab has to say, I admit I trust him much farther than I trust Wu on technical matters.
PlayBook appears to be going down hard. QNX is obviously involved in that even though it is probably not the root cause. The root problem is probably more along the line of trying to do too much too fast and not being able to get everything done right and on time. Given RIM didn't really have any time to waste in the first place, I think they just hastened their demise by over-promising what they should have set up to deliver in 2012. Or really what they should have started on in Feb 2007 for a 2010 delivery.
(1) Safety RTOS moves at a much slower pace industry-wise than the general operating system. The space shuttle is still running on a computer built in the 1970's.
No, it's not. All the shuttles were retrofit with 1980's era computers in the mid-90s when NASA did the glass panel flight deck upgrades.
Logitech remotes are pretty recent, so as the military radio and so as the harman/becker personal navigation devices. Much more recent that the big cisco router which was launched in 2004.
(2) Sure if you have a poor UI, device drivers and apps then that is going to negate much of the advantage. But it is the same AIR UI that powers car dashboards --- and they only have something like a 200MHz CPU. Device drivers and much of apps shown are done by QNX, the same people who won the power management award.
Given the applications you cite, and the thresholds auto manufacturers consider as power savings, I wouldn't try to use them as major rallying points for handhelds and recent tablet computers. Pushing a couple dozen preprogrammed textures and automotive rate moving map device doesn't need much CPU horsepower.
(3) Sure, Shaw could be right that the current beta Playbook has poor battery life. But what to do with that fact is what is important. Shaw thinks that RIM needs months and months of tinkering with QNX because QNX is supposedly built for the big routers and not for battery life. Well, QNX is embedded in handheld military software defined radios where poor battery life could kill your own soldiers.
I agree Wu is full of it technically. But even though he gets the specifics wrong, I think he's right that the PlayBook will need months and months to get power management right given the state of the "Beta hardware". Even a blind squirrel finds a nut once in awhile.
(4) Compare to what? QNX won the award at the Embedded World Conference. It is not like the BeOS fans who thinks that their OS is godlike --- but it was only godlike because they were comparing it with Windows 95.
OK fine. But that's not helping RIM right now. Is it. This actually places the PlayBook team in a worse position given the current beta has the confirmed by RIM problems it does.
(5) Speed to market --- that's what having a completely certified POSIX operating system is all about. Back 10 years ago, Sony announced their BeOS-based evilla internet appliance --- took 18 months to launch. Later on, 3Com hired some 3rd party QNX consultant to design the Audrey --- took 6 months to launch, sold them for a few months and then discontinued the Audrey before Sony finished their evilla design.
So does discontinuing something make it a good example? Or was that because they rushed it and made a turd that nobody wanted? Speed to market is only meaningful when you deliver a properly designed well engineered product. The old saw "fast and broke is still just broke" applies liberally here.
Well, to be fair, having a tablet that can't run apps other than a web-browser would be a redefinition of what a tablet can do -- kind of like having a car that can only drive in reverse would be a redefinition of what a car can do.
Yep. Now we have to see if the target audience agrees with the nature of the redefinition as a good and useful change. Or if they like that 'old' way and stick with it
It is worth noting that Wu's source on this are even more sketchy and tabloid than his Apple sources. Frankly I can't help wondering if he is down talking the Playbook to encourage sales and pull the price down. Regardless, it doesn't appear he has held or used one and real world use is what will give us the best read on this device.
Nor is it a black science that only Apple understands.
And just what does that have to do with the cost of a slice of bread?
And you think only Apple is capable of doing this?
Besides much of that design effort is not taken care of buy the SoC design process and the package on package construction of the processors going into these machines.
You blew it right there. The implication that things are going wild on the Playbook is joke and you have no basis for stating such.
Flash is a problem but that should surprise absolutely no body.
Sure Flash isn't a big help with respect to long term performance but it gets product to market and people here mis the importance of doing this. Playbooks long term success will be built around the coming SDK just as the SDK lead to an explosion of apps on the iPhone which then had an additive impact on iPhone sales.
You see what bothers me here is that Apple shoved iPhone out the door with just web app support when it first debuted. After a good long while we eventually got the SDK. Why when RIM is about to do the same thing, it gets no respect is beyond me. Sure they could fail, but they need to try. Especially if you are a die hard Apple iPad owner as it means pressure on Apple to upgrade.
Well, when an iPad gets at least twice as much battery life than all comparable competitors, that tells me that Apple is doing something that the competitors are not. Right?
Threads *are* going wild on the PlayBook when a flashed based video player is designed to play multiple video streams with only one stream being visible. That is capital offense on a tablet device and will cause users to deplete their batteries in minutes. The best software engineers at Apple and Microsoft agree that this should not be done this way for various reasons.
HP tried to rush a tablet out of the door with a Flash UI and failed but at least they recognized that it was not worth shipping. For RIM to cut corners with Flash/AIR and rush to market is a mistake. I think that they should have gone with Palm or MEGO.
Time will tell.
I've held way too many of those "handheld" radios. The batteries are IMMENSE! (compared to anything in the consume mobile space) And you have to carry extras for just in case.
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
I'll give QNX props for energy management. Embedded operating systems that can be used for remote sensors do not suck power for their own benefit. (The radios tend to ignore that in my estimation.) Shawn Wu is talking out his arse when he says what QNX is and isn't designed to do. I can believe the basic facts on PlayBook battery life he reports, but have to completely filter out anything he says when it comes to technical explanations.
They aren't even facts. It really is just crap running out of his mouth.
Also @Dick, in the QNX context "application" means "device" rather than software "app".
What I'll call BS with on RIM though is that an embedded OS that does do remote sensor in other applications is suddenly not implementing power management in beta hardware? WTF, are they going to ship an Alpha implementation?
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
To make that comment at all is incredibly telling. Power management isn't just something you slap on after the fact. It's inherent in both the hardware components and the software drivers.
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
In any event why would you be focused on power management when so much else needs to be done.
If power management isn't implemented yet it either means they are going to be shipping VERY new drivers, or different hardware than they are developing and testing on now. I highly doubt both of those last two possibilities.
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
That leaves me with one nasty little suspicion that a senior manager of engineers has pulled a good old "Debug Code"-class excuse out his little arse and the non-technical half of the dual core CEOs ate it up. Fully.
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
...
In any event why would you be focused on power management when so much else needs to be done.
...
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
I agree with the above bits!
What bothers me is that this PlayBook "product announcement" is all over the place...
What is it:
-- a proof of concept prototype?
-- a pre alpha?
-- a pre beta?
Most observers will admit that a lot needs to be done before the PlayBook is an actual product.
Let's assume that RIM has the talent and manpower to do all this concurrently -- when can we reasonably expect a working, shipping product?
We have a similar scenario that we can use as a comparison -- the Apple iPhone gen 1.
OK, Here is the timeline for the iPhone 1 Announce / Release
Jan 2007 ............................... Jul 2007
|___________________|___________________|_________ __________|___________________|
iPhone Product Announce.................iPhone Product Avaiability
Live demos of major features ...........delivered
Announced price.........................delivered
Announced reseller......................delivered
Announced product availability..........delivered
Announced major product specs...........delivered
Announced battery performance...........delivered
Now. Here's the timeline for the PlayBook Announce / Release ?
Sep 2010............Jan 2011.............Apr 2011.............Jul 2011
|___________________|___________________|_________ __________|___________________|
PlayBook Product Announce.................................................. .....
.............Live demos of some features.........................................
......................Announce price?............................................
..............................Announce product availability?.....................
......................................Announce reseller?.........................
Announced major product specs............................................. ......
..............................................Announce battery performance?......
They have shown us a few (minimal) demos, given us some incomplete specs...
...and a whole lotta' "we're right on track" and "we're way advanced" and "we're competitive" gumbeating...
What they haven't told us is:
- When will it be available
- Who wil be selling it
- How much will it cost
- How long will the battery last
With all due respect, it has been 3 months since you announced (?) this product (?).Don't you know the answers to these questions?
Is this a real product -- or just a wishlist?
What have you done to your reputation vis a vis customers, developers, shareholders and the investment community?
What have you done to done to the morale of RIM employees -- both those working on QNX/PlayBook, and those working on legacy products?
Is that anyway to run a company? To run anything?
.
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
I was talking about a 3lb 7oz mil-specbattery with a 12oz "protective case" for transport. If you want to continue to take things out of context and look foolish doing it be my guest.
They aren't even facts. It really is just crap running out of his mouth.
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
Well if this was alpha hardware you would have a point, but it's not. It is beta hardware (see last para) and power management isn't a trivial feature to add at the end of development. RIM can "tweak" to their hearts content over time. But getting basic functionality of at least a days use out of a modern mobile device isn't follow on tweaking, it's core functionality that requires rigorous QA and long term testing. If it's not fully implemented and ready for optimization in the beta, it's not a beta and ready for unfettered public consumption outside the engineering enclave.
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
OK, I agree there, but it's relatively unrelated to RIMs current problem of promising the world and finding out they cannot deliver the requisite power over the desired duration. This is everyones problem and it is solved with hard work over time, not by magic in a few short weeks. the interrelated tradeoffs and interactions with both on and off SoC components takes time to learn and optimize. You can accelerate a derivative product, but not a first design unless you are willing to bet the success of the entire product on a losing formula. It is possible to win the bet, but not a likely possibility.
As for RIM having no control over the SoC, that only works on one level, the decision of what is on the SoC. After that RIM is in complete control of how familiar they are with it and who they hire and/or contract to work with that hardware. If you want to go to market faster you need appropriate talent and management compared to how long it might take the in-house group to get up to speed before they can make solid progress. That's all still part of the hardware side of the equation.
In any event why would you be focused on power management when so much else needs to be done.
Because a product that dies in less than 6 hours will be deemed a failure on a major feature. A beta that dies in that timeframe is going to give a major hurdle to the long term buying plans precisely because the beta is the showpiece to make a CIO want to buy something. The CIO will overlook little stuff, but short battery cycles will make them take a wait and see on the final rather than make huge pre-orders.
RIM shipped an alpha and called it a beta, now they are trying takes-backsies on the beta. That mistake alone may be enough to prevent the PlayBook from ever being successful. and the company will have to work even harder to ensure that mistake doesn't tarnish the rest of the company enough to seal a slow death spiral.
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
Duh. Now lets get back into context rather than get willfully opportunistic and incorrectly pedantic shall we? I used new quite clearly as newly introduced to the PlayBook after the beta, not as in new to market.
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
What part of "nasty little suspicion" tipped you off there? Yes, it was explicitly obvious it was guesswork and opinion.
As for every single feature, you are creating a false context. I never said that anywhere, ever. I have and continue to contend that power usage isn't a trivial fluff feature that can be added after the fact with little risk. Power usage is core functionality, period. And beta hardware and software had better be core functionality complete or else. Sure beta means things are still in a late post integration debugging phase, that's precisely what beta means.
RIMs use of the term pre-beta is a late to the game attempt to cover up the faux pas. You don't ever pass around alpha prototypes to expected end-use customers for their own use and business process testing. Ever. RIM admits in the press release that PlayBook units are in the wild outside their walls. Either they are betas which aren't up to snuff, or RIM is even dumber an engineering outfit than I ever imagined by letting alpha hardware out into the wild.
RIMs use of the term pre-beta is a late to the game attempt to cover up the faux pas. You don't ever pass around alpha prototypes to expected end-use customers for their own use and business process testing. Ever. RIM admits in the press release that PlayBook units are in the wild outside their walls. Either they are betas which aren't up to snuff, or RIM is even dumber an engineering outfit than I ever imagined by letting alpha hardware out into the wild.
Yeah, what does alpha or beta mean anymore?
Then what is pre-alpha or pre-beta?
Is there a post-alpha or a post-beta?
Which comes first pre-beta or post-alpha?
Is there any checklist of things that must be completed to qualify a product to have attained any of these stages of completion?
Can we build a timeline that shows how a product progresses through these stages of development.
Back in the 1950s they developed a planning discipline called PERT * (Program Evaluation and Review Technique) to plan and manage complex projects.
http://en.wikipedia.org/wiki/Program...view_Technique
* PERT was later supplanted with enhanced techniques like POP (Piss On PERT).
PERT used a diagramming concept to layout milestones (like project start, alpha, beta, project completion) and the tasks (dependencies) that needed to be accomplished to reach those milestones.
Each task definition showed the estimated time and manpower required to perform the task.
The longest (duration) path of sequential tasks to reach a milestone defines the time required to attain that milestone.
If a project is behind schedule, it is easy to determine where the delays are, the resources needed (if available) to bring the task back on schedule, or the length of time the following milestones (including project completion) will be delayed.
PERT diagramming is a simple, but iterative process -- as the project progresses you learn things, continually revise the diagram, and the project schedule.
There are computer programs that evaluate the tasks and dependencies, apply calendar time, and calculate when the project (and milestones) will be completed.
For example:
The circled numbers represent milestones, e.g,:
10 - start of project
30 - alpha complete
40 - beta complete
50 - product Release
for a simple project
The arrows, Red Uppercase Letters (or starting and ending milestone nodes)) indicate tasks that must be completed, e.g.:
A (10-30) - Perform Alpha Development
D (30-40) - Perform Beta Development
F (40-50) - Manufacture Product
E (30-50) - Prepare Documentation
B (10-20) - Prepare Announcement and Promotional Material including co-muzzles
C (20-50) - Announce Product
We see a estimated time duration for each task, Gray Lowercase letters.
By calculating the duration to traverse each path through the diagram, we can calculate the longest paths (the critical paths) to project completion. This also identifies those tasks that cannot be delayed without delaying the project -- as well as tasks that can be performed concurrently.
Obviously this is an overly simplistic PERT or CPM (Critical Path Method) chart -- but it's a start.
We can take a general task like A (10-30) - Perform Alpha Development and break it into many smaller tasks: define requirements, determine development costs, prepare cost benefit analysis, determine personnel requirements, etc.
If necessary or beneficial (it usually is) we can prepare a PERT/CPM chart for these smaller tasks that comprise the general task -- showing critical and concurrent tasks.
Everything we do to refine the diagram makes it more accurate and more representative of the project to be accomplished.
All this information can entered into a computer which will calculate dependencies, identify critical paths/tasks, etc.
As tasks are completed, the chart and computer model are updated and, based on the accuracy of prediction of completed tasks (planned vs actual time) a "degree of confidence" can be calculated for reaching each remaining milestone.
In the early 1970s I worked for IBM in Software Development for the Distribution Industries in Des Plaines, IL. We were waiting to get approval on a project to begin Beta development (writing the code, in our project). After weeks of frustration trying to get the various high(er)-level approvals, the Department Manager gave me a challenge:
Assume we want to develop a program with:
-- 1 line of code
-- 1 page of documentation
and, it's already done!
How long will it take to get it through the approval process.
After about 2 weeks on the phone, I had gathered enough information to create a PERT chart and entered the information into an APL PERT program...
It would take 12 months to get through the approval process -- for example, it had to go through Pricing and Forecasting (a two week process) two separate times -- and each process had to be scheduled at least 1 week in advance.
So, then, the Department Manager asked me to see what could be done to expedite the process, e.g. things like only one pass through Pricing and Forecasting.
Another two weeks, or so, and I had a revised chart and a revised estimate.
Expediting the project added 1 week to the process -- it took 3 weeks to schedule executive (Armonk) approval to bypass the 2-week Pricing and Forecasting process...
This led to the following:
In business, to do nothing, takes 12 months!
-The Des Plaines Doctrine-
Expediting, takes a little longer!
-The Armonk Axiom-
OK.
I suspect that CPM scheduling and the like have been supplanted, over the years with more accurate project/program management and review techniques.
I suspect QNX (RIM?) needs to participate in something like the above to fulfill its contract to provide software for the moon rover and other Mil-Spec projects.
It is kind of sad, really, that the management at RIM, apparently, can't use available techniques to successfully define, manage and execute a "relatively" simple project of building a tablet -- this ain't exactly moon rover science!
However, it speaks volumes about RIM.
To be fair, things can't always be scheduled accurately -- or sometimes the stars won't align to make things happen as we wish.
I can remember a press invitation for an announcement meeting in Cupertino.
Once everyone was in place, Steve gave out some performance statistics and then made 2 product announcements:
-- the iPod HiFi
-- a leather case for the iPod
Obviously, they had planned to announce other products -- but they weren't ready...
...At least Steve had the sense to say nothing!
Those two guys founded the company, so I guess they have equal authority.
I don't doubt that but what's important is: do they both have the same philosophy on the best way to run a company or do they spend most of their time compromising with each other. IMHO, any company has to have a strong, inspirational leader (singular) .... Balsillie does not "inspire me in the least.
^^ Deserves some sort of award.
Why mock Venezuala ? The USA is not exactly a glowing beacon these days is it?
Torture in an annexed country, murder of innocents in others. An economy in ruins.
Maybe fix your problems before mocking others.
Is that anyway to run a company? To run anything?
Man, imagine if 3 months from now they delayed it another six months and in nine months they cancelled it. Sounds very much like Larrabee at the moment.
Adobe is the wrong wingman on this mission. Way wrong.
I'm really surprised that the investment community doesn't see through RIM's bs. Not that I think they'll go out of business tomorrow, because there are plenty of companies completely satisfied with them as they are today (but this too won't last forever), but even making proclamations like they are suggests to me that they (as a company or as directors of the company) are not even following some standard business protocols.
I don't even get the sense that they're cocky about what they're doing because they indeed have something different and potentially better than what's on the market. They can't back up their promises and proclamations with real examples - because they don't have anything real to show.
John
They hit on their server side mobile business email solution at a time when there was nothing to compete, did a good job of building hardware to support that and in building and refining business friendly features while becoming the entrenched incumbent in that space, but as time goes on they seem less and less like a mobile powerhouse and more and more like a bright kid who invented a clever thing which sold really well but who is hopelessly in over his head when it comes to what to do next.
If Apple hadn't made the iPhone they probably could have gone on like that for quite a while, doing incremental improvements on the cash cow without feeling any real pressure to step outside their comfort zone. But now they're forced to make public statements about the roadmap, and it becomes immediately evident that these people don't have any business running a business. It's genuinely shocking, IMO.
http://digitaldaily.allthingsd.com/2...-battery-life/
And people don't carry extra batteries for their iPhones? This is interesting because my iPhone went dead yesterday and it would have been nice to have one of those spare batteries. What was the problem; trying to use the built in maps app!!! On a 3G it just drains the battery like crazy.
They aren't even facts. It really is just crap running out of his mouth.
Actually why would they implement power management on what is really Alpha hardware? Think about it they need to get the base system down pat. Beyond that do you really think power management was static with iOS. There are examples all over the net where it gets better than worst and then better again. I would like wise expect RIM to continually tweak power management as the device evolves.
As I said before manufactures like RIM have little control these days over hardware. These days most companies are working with SoC folded into package on package assemblies. Apple is about the only example I can even think of these days trying to roll their own. Even then it appears that Apple is closely tied to Samsung.
In any event why would you be focused on power management when so much else needs to be done.
By definition they will be shipping new hardware and drivers. I'm not sure what your point is. New is a relative term here though because they are likely building on existing QNX software.
That is pure guess work. In any event I just don't support your point of view that alpha/beta hardware needs to have every single feature implemented to be useful
People have been doing robust power management with Neutrino for years.
http://www.qnx.com/developers/articl...cle_296_2.html
People have been doing robust power management with Neutrino for years.
http://www.qnx.com/developers/articl...cle_296_2.html
That kind of just reinforces the fact that if RIM is having power issues, they are in big trouble and it is self inflicted.
That kind of just reinforces the fact that if RIM is having power issues, they are in big trouble and it is self inflicted.
RIM is shooting for 8 hours of battery life --- 80% of iPad's battery life. The Playbook (5300mAh) also has 80% of the battery capacity of the iPad (about 6600mAh).
RIM is shooting for 8 hours of battery life --- 80% of iPad's battery life. The Playbook (5300mAh) also has 80% of the battery capacity of the iPad (about 6600mAh).
1) Shooting for. Not confirmed. Not guaranteed. Just crossed finger and wishful thinking.
2) Do you really think their statement was a medium average of some maximum under ideal conditions scenario? I bet 6 hours of video will be hard to get, compared to the 11.5 hours Pogue got from the iPad.
3) 80% of the battery capacity with ½ the display size where the majority of the power is used on the iPad, with less pixels to push to the display, and a newer, more power efficient CPU. Anything else from the FUD factory?