|
from a thread in which the die hards argue with the realists about whether blackberry needs a new ceo / can possibly succeed in pivoting to a software business (lol) / etcmarkmall posted:There are many reasons why it might have failed. My point is that it had no chance of not failing. No consumer electronics product can ever succeed if people do not know that it is for sale and what it does differently. also have the comeback JeepBB posted:You seem to exist in a fantasy world. The UK isn't Oz either - there are few wizards and I've certainly never seen anyone I would describe as a Munchkin. Most of us are of average height.
|
#
¿
Jul 5, 2016 02:55
|
|
|
|
| # ¿ May 10, 2024 04:10 |
|
|
Notorious b.s.d. posted:you could, if apple let you. which they will not. userspace isn't completely the same: uikit (ios ui framework) is not the same api as cocoa (osx ui framework). they are (very) close relatives, to the point that people can share big chunks of source code between ios and osx versions of an app, but not "just hit recompile" identical twins that said, lol @ fishmech's entire angle. if you go look up stebe's presentation announcing the iphone (it should be on youtube somewhere) i'm p. sure he basically called it os x on a phone, because they hadn't invented the ios name to describe it yet. also it is now known history that there were two factions inside apple which competed for the right to create the os for ipad/iphone: the ipod guys, who wanted to enhance the super lightweight ipod "os", and the mac system software guys, who thought it should be possible to pare down osx to run on a device with limited memory. the osx faction won because (a) they came up with convincing existence proof and (b) starting from something feature rich and throwing away what you don't need / can't afford to have (yet) gives a better development path than starting over from scratch iirc this choice was p. much why tony fadell ended up leaving apple and founding nest. after they chose osx there was no chance his ipod division was ever going to do anything but slowly lose influence inside apple
|
|
#
¿
Dec 12, 2016 01:39
|
|
|
fishmech posted:steve jobs also described magic fruit diets as a way to treat cancer successfully, and html5 on an EDGE connection as a good thing to use instead of native applications, i don't trust steve jobs to describe things. https://www.youtube.com/watch?v=9hUIxyE2Ns8&t=502s lol turns out jobs was even more explicit about it than i remembered. not that you need the word of jobs to know that actually, osx and ios are deeply related you're just like trump, fishmech: no matter how obviously wrong the thing you said is, you think the worst thing in the world is to admit you were wrong, so you never do, and you get more angry about it the more wrong you're proven to be
|
|
#
¿
Dec 12, 2016 05:23
|
|
|
The Management posted:qnx is a decent os when your number one criteria is "doesn't crash" and number two is "kind of unixy". my car runs it with a Linux user land in the entertainment system. it was not a bad choice for a phone OS. the problem was in no way the kernel and base OS frameworks, it was the junk on top of that written by blackberry and also that they were way late to market and their hardware sucked. yeah wasn't blackberry os "classic" basically their hellfucked pager os that grew up to become a really bad smartphone os? I remember articles about how they realized that improving bbyos wasn't going anywhere, they couldn't hire any talent good enough to take on cleaning the augean stables because those people would not want that job, and really they just couldn't attract good talent period. so they bought qnx and it was the right move but they should have made it years earlier and by then they were so far behind iphone and android it was doomed to be too little too late
|
|
#
¿
Jan 17, 2017 21:38
|
|
|
Subjunctive posted:at the time, wasn't Linux too non-real-time enough to do their low power radio trickery? I remember arguing about that with my mom of all people if you make your radio code an in-kernel driver, lock all the ram (or just don't have a swap device, which is likely in this context), and tweak the scheduler a bit (or use one of the existing realtime linux projects which have already done that), there's no reaosn why linux wouldn't work. most of the time, hard realtime systems only need a tiny bit of driver-ish code to actually be given hard realtime guarantees, and the rest of the system can deal with unpredictable delays, and everyone's happy because this is comparatively little work to get right poo poo doesn't get real (time) until you decide "hey my entire gui stack needs to be hard realtime because it's the control panel for a nuclear power plant and we need to know that without fail every indicator on the virtual instrumentation panel updates in lockstep with the display refresh and also every operator button press during that interval has been fully processed and properly responded to"
|
|
#
¿
Jan 18, 2017 10:28
|
|