To be fair (ish) QNX on the Playbook isn't really ready for prime time yet. It's better to wait until they've got those bugs ironed out before they risk their phone platform on it.
Now, why QNX on the Playbook is so bad, that's another question altogether. Maybe RIM thinks Apple has a patent on well designed UIs and APIs, and aren't risking a patent battle.
For me it's merely a price discussion: I can get a WiFi only version for $499, and never pay anything more again. Or I can buy a WiFi/3G version, for $529, and spend $30-50/month every month for two years until the contract expires. Total price differential of $750-1230 to have internet access in the few places that don't offer free wifi these days? I think I'll take the WiFi only version, thanks.
Oh, I can understand the idea perfectly... It'll take me a few hours after work on Tuesday, and $1000 of hardware to put this together, or I can spend 4 hours in a meeting with IT to explain my requirements, give them a few thousand dollars in exploratory budget, and two weeks later they'll come back to me with a spec for something similar to what I asked for, then I can give them a few thousand more dollars in implementation budget, and a month or two later they'll stand up a system that does about 90% of what I asked for.
As an IT person, I understand the desire to have everything locked down and under IT control, but at the same time, we stab ourself in the eye when we retaliate for this kind of behavior. Instead, regard this as a working prototype, and push for this functionality to be adopted and subsumed into IT.
Ah, the old IT conundrum: If I ask IT to do it, it'll take several months and tens of thousands of dollars in budget to implement. If I hack it together myself, it'll take a few hours, and a $1000 investment in hardware. But then comes maintenance, and repair, and so forth and so on.
In the end, you're going to need to hand over control of the system to IT, whether that means having them build a new box for you that does the same as the one you built, or handing them over root control of the system you built, if they're familiar with the components of the BSD/LDAP/CalDAV beast you've hacked together. Basically what you've built for them is a Proof of Concept system, or a Prototype, which they'll need to take over eventually, because you're not going to in the business long term of supporting this tool.
Sure... That's what some of the Flash->HTML5 converters are doing (though they're going through the intermediary of AS3 bytecode). The thing is that the Flex class library directly inherits from the Flash class library, so re-implementing on another platform would require a ground-up reimplementation of the entire windowing library on any existing stack (Java,.Net, etc...) So it's not really feasible to "port" Flex to another language/platform (though SIlverlight is a reasonable knockoff on the.Net stack).
Flex is just a set of Libraries and an XML syntax for ActionScript bytecode. In other words, Flex is built on top of Flash, so it can't really outlive Flash.
Note that you can get started developing for iOS at no cost with a single download.
Really? When I looked into starting iOS Development, it looked like it would cost me at least $799 to pick up the development environment, since it only came pre-packaged with custom hardware and an operating system. Although, at least their $799 package works with my existing monitor and keyboard.
One has to sympathize with RIM's internal software engineers if that is the same tool they have to work with to develop their own apps. This is not an indication that RIM wants to turn developers away, but an indication that their software development process is not very efficient. The complicated process is not only a turn-off for external developers, but also their internal ones. The question is, is this the best process they could come up with, or is it that good ideas or designs in the company have problem becoming realized?
Honestly, the dev tools for the Flash/AIR platform are pretty solid, but the RIM SDKs are pretty horribly architected. It's loosely based on the Adobe Flex APIs, but it ignores all of the conventions set up in the Flex APIs, and isn't even internally consistent with itself. Half of the reason for using a Flash-based API is to have the built in smooth transitions (Fade, slide, etc..), but for whatever reason, the QNX components don't work with the built in transitions. You can build an app without QNX components, sure, but it'll run way slower, and doesn't blend in with the QNX UI.
And let's even look at the QNX "standard UI". Oh wait, there isn't one. The only example of an application that we have to loosely try to base our UI around is the web browser that TFA mentions. Of course, none of the standard UI metaphors that the browser uses are built in to the API? The "tab drawer" that happens when you swipe down? It's fully custom constructed, you'd have to write the whole thing yourself from primitive UI Rectangles and hand-built transitions and event handlers if you wanted to have a similar thing in your app. Take a look at Android or iOS, where tabs, accordions, toast notifications, and view-stacks are built in metaphors in the UI. I don't know when it's going to all be fixed, but it's in serious need of massive repair.
Sure, The $20/submission fee keeps out fart apps, but the thing is that it's not $20/app. If I submit Application A and one of my users finds a bug, I obviously need to submit an update... That UPDATE costs another $20. What if you add a feature? Another $20. So basically, the model that the Blackberry App World model encourages is for you to submit bugfixes only when they're absolutely critical, and to avoid adding new features.
I don't think the article was expounding on Unix "Manliness" and uptime metrics... It mostly just highlighted the mistake that a lot of junior admins make (Both Windows and Unix) that it doesn't matter if you understand why the problem is happening, just mashing the power button until it goes away is the best rout forward.
Rather than presenting technical reasons why you shouldn't reboot, It's actually probably better to ask for technical reasons why you *should* reboot. Rebooting a server to try and fix a problem is just one step above "percussive maintenance" in the hierarchy of problem solving.
Now, I will actually suggest one additional reason to reboot a Unix Server not mentioned in the article, and that is installing a new service that's intended to be included in the boot up sequence. However, that suggestion is just a Quality Assurance measure: Make sure that the service powers up as it's supposed to, in case some unexpected downtime does happen, and ensure that the service comes back up as expected. Otherwise, Hardware and Kernel upgrades should be the only reason for a reboot.
Yes, but they're first gen tech. The first gen is always too expensive, because it covers the R&D costs. Look at Blu-Ray Players circa 2005, which cost $400+ for the cheap ones. Fast forward 5 years, and we've got Blu-Ray players available at grocery stores for $100 a pop. Ultimately, people are paying for the "Ooh Shiny" factor now, but in a few years we'll see the price drop, and you'll be able to pick up a capacitive touch screen 7 inch tablet with 1024x600 resolution and an LTE modem for $150 bucks.
But see, that's where the anti-competitive laws come into play: Apple is directly leveraging their dominance in the Tablet OS market to harm their competitor in the e-Book market. As I understand monopoly laws, they're not allowed to do things like that. It's like if Microsoft charged all Office Suite manufacturer's 30% of the sale price of their suite in order to run under Windows, or if Hyundai charged a 30% surcharge to companies who were shipping Honda cars using the ships that Hyundai built.
So I know this gets called a lot, but I think this seems like an area where the FTC could potentially get involved... Apple is leveraging their dominance in the mobile computing market to force competitors in the e-book market to raise their prices. This might be in violation of existing anti-trust laws.
This would actually be one of the places where a Patent is perfectly appropriate. Patent the technology, and publish the paper describing the equipment. I understand that the practice is pretty common in corporate-style labs.
There's certainly theory behind it... Two atoms (generally hydrogen) combine into a heavier element, and in the process some minute portion of their mass is converted directly into energy. We've even accomplished that part in limited circumstances (i.e. Hydrogen Bombs). The fiendishly tricky part is balancing the inputs and the outputs to the reaction to keep it going while keeping the whole thing cool enough that the reaction doesn't go out of control (i.e. "Cold Fusion")
Maybe.... It depends on what the efficiency of the process is, and whether it's more efficient than current power-generation reactions. And, as you said, whether there are hazardous by-products.
Slashdot Mirror
Shipping is the only feature that is an absolute must have for any application. The rest is just chrome.
To be fair (ish) QNX on the Playbook isn't really ready for prime time yet. It's better to wait until they've got those bugs ironed out before they risk their phone platform on it.
Now, why QNX on the Playbook is so bad, that's another question altogether. Maybe RIM thinks Apple has a patent on well designed UIs and APIs, and aren't risking a patent battle.
This is english... all our words are a foreign language.
For me it's merely a price discussion: I can get a WiFi only version for $499, and never pay anything more again. Or I can buy a WiFi/3G version, for $529, and spend $30-50/month every month for two years until the contract expires. Total price differential of $750-1230 to have internet access in the few places that don't offer free wifi these days? I think I'll take the WiFi only version, thanks.
Oh, I can understand the idea perfectly... It'll take me a few hours after work on Tuesday, and $1000 of hardware to put this together, or I can spend 4 hours in a meeting with IT to explain my requirements, give them a few thousand dollars in exploratory budget, and two weeks later they'll come back to me with a spec for something similar to what I asked for, then I can give them a few thousand more dollars in implementation budget, and a month or two later they'll stand up a system that does about 90% of what I asked for.
As an IT person, I understand the desire to have everything locked down and under IT control, but at the same time, we stab ourself in the eye when we retaliate for this kind of behavior. Instead, regard this as a working prototype, and push for this functionality to be adopted and subsumed into IT.
Ah, the old IT conundrum: If I ask IT to do it, it'll take several months and tens of thousands of dollars in budget to implement. If I hack it together myself, it'll take a few hours, and a $1000 investment in hardware. But then comes maintenance, and repair, and so forth and so on.
In the end, you're going to need to hand over control of the system to IT, whether that means having them build a new box for you that does the same as the one you built, or handing them over root control of the system you built, if they're familiar with the components of the BSD/LDAP/CalDAV beast you've hacked together. Basically what you've built for them is a Proof of Concept system, or a Prototype, which they'll need to take over eventually, because you're not going to in the business long term of supporting this tool.
You've apparently never seen the Aussie film "Undead"...
Ah, you're right, I was thinking GTK+ and Qt being skinned to look nearly equivalent.
Still though, the differences are almost entirely cosmetic. Why bother fighting about it?
*sigh* who cares? Most distros toss skins on top of them that make them indistinguishable anyhow.
A fictional character from Ayn Rand's novel "Atlas Shrugged"?
Sure... That's what some of the Flash->HTML5 converters are doing (though they're going through the intermediary of AS3 bytecode). The thing is that the Flex class library directly inherits from the Flash class library, so re-implementing on another platform would require a ground-up reimplementation of the entire windowing library on any existing stack (Java, .Net, etc...) So it's not really feasible to "port" Flex to another language/platform (though SIlverlight is a reasonable knockoff on the .Net stack).
Flex is just a set of Libraries and an XML syntax for ActionScript bytecode. In other words, Flex is built on top of Flash, so it can't really outlive Flash.
Note that you can get started developing for iOS at no cost with a single download.
Really? When I looked into starting iOS Development, it looked like it would cost me at least $799 to pick up the development environment, since it only came pre-packaged with custom hardware and an operating system. Although, at least their $799 package works with my existing monitor and keyboard.
One has to sympathize with RIM's internal software engineers if that is the same tool they have to work with to develop their own apps. This is not an indication that RIM wants to turn developers away, but an indication that their software development process is not very efficient. The complicated process is not only a turn-off for external developers, but also their internal ones. The question is, is this the best process they could come up with, or is it that good ideas or designs in the company have problem becoming realized?
Honestly, the dev tools for the Flash/AIR platform are pretty solid, but the RIM SDKs are pretty horribly architected. It's loosely based on the Adobe Flex APIs, but it ignores all of the conventions set up in the Flex APIs, and isn't even internally consistent with itself. Half of the reason for using a Flash-based API is to have the built in smooth transitions (Fade, slide, etc..), but for whatever reason, the QNX components don't work with the built in transitions. You can build an app without QNX components, sure, but it'll run way slower, and doesn't blend in with the QNX UI.
And let's even look at the QNX "standard UI". Oh wait, there isn't one. The only example of an application that we have to loosely try to base our UI around is the web browser that TFA mentions. Of course, none of the standard UI metaphors that the browser uses are built in to the API? The "tab drawer" that happens when you swipe down? It's fully custom constructed, you'd have to write the whole thing yourself from primitive UI Rectangles and hand-built transitions and event handlers if you wanted to have a similar thing in your app. Take a look at Android or iOS, where tabs, accordions, toast notifications, and view-stacks are built in metaphors in the UI. I don't know when it's going to all be fixed, but it's in serious need of massive repair.
Sure, The $20/submission fee keeps out fart apps, but the thing is that it's not $20/app. If I submit Application A and one of my users finds a bug, I obviously need to submit an update... That UPDATE costs another $20. What if you add a feature? Another $20. So basically, the model that the Blackberry App World model encourages is for you to submit bugfixes only when they're absolutely critical, and to avoid adding new features.
I don't think the article was expounding on Unix "Manliness" and uptime metrics... It mostly just highlighted the mistake that a lot of junior admins make (Both Windows and Unix) that it doesn't matter if you understand why the problem is happening, just mashing the power button until it goes away is the best rout forward.
Rather than presenting technical reasons why you shouldn't reboot, It's actually probably better to ask for technical reasons why you *should* reboot. Rebooting a server to try and fix a problem is just one step above "percussive maintenance" in the hierarchy of problem solving.
Now, I will actually suggest one additional reason to reboot a Unix Server not mentioned in the article, and that is installing a new service that's intended to be included in the boot up sequence. However, that suggestion is just a Quality Assurance measure: Make sure that the service powers up as it's supposed to, in case some unexpected downtime does happen, and ensure that the service comes back up as expected. Otherwise, Hardware and Kernel upgrades should be the only reason for a reboot.
Why reboot? Why not just kill off the process, clear the temp files, and restart the process?
Yes, but they're first gen tech. The first gen is always too expensive, because it covers the R&D costs. Look at Blu-Ray Players circa 2005, which cost $400+ for the cheap ones. Fast forward 5 years, and we've got Blu-Ray players available at grocery stores for $100 a pop. Ultimately, people are paying for the "Ooh Shiny" factor now, but in a few years we'll see the price drop, and you'll be able to pick up a capacitive touch screen 7 inch tablet with 1024x600 resolution and an LTE modem for $150 bucks.
If he's not talking about iOS, is he just talking about the cool skin that Apple's marketing group put on top of BSD then?
But see, that's where the anti-competitive laws come into play: Apple is directly leveraging their dominance in the Tablet OS market to harm their competitor in the e-Book market. As I understand monopoly laws, they're not allowed to do things like that. It's like if Microsoft charged all Office Suite manufacturer's 30% of the sale price of their suite in order to run under Windows, or if Hyundai charged a 30% surcharge to companies who were shipping Honda cars using the ships that Hyundai built.
I know that's the policy on the new Amazon Android Store
So I know this gets called a lot, but I think this seems like an area where the FTC could potentially get involved... Apple is leveraging their dominance in the mobile computing market to force competitors in the e-book market to raise their prices. This might be in violation of existing anti-trust laws.
This would actually be one of the places where a Patent is perfectly appropriate. Patent the technology, and publish the paper describing the equipment. I understand that the practice is pretty common in corporate-style labs.
There's certainly theory behind it... Two atoms (generally hydrogen) combine into a heavier element, and in the process some minute portion of their mass is converted directly into energy. We've even accomplished that part in limited circumstances (i.e. Hydrogen Bombs). The fiendishly tricky part is balancing the inputs and the outputs to the reaction to keep it going while keeping the whole thing cool enough that the reaction doesn't go out of control (i.e. "Cold Fusion")
Maybe.... It depends on what the efficiency of the process is, and whether it's more efficient than current power-generation reactions. And, as you said, whether there are hazardous by-products.