And if anyone actually was curious, the PlayBook Native SDK actually does run on Linux, and a lot of the F/OSS they've been porting to it is posted on Github.
Because those APIs are the reason people use Windows in the first place.
Just look at any market where Microsoft doesn't have a "legacy platform advantage," and see just how much more competition they face. In some of those markets, they may even have a trivial presence.
Except when changes in economies of scale make the hobbyist-friendly stuff far more expensive and difficult to obtain than we're currently used to. Oh, and also far less accessible to the high school kid with techno-illiterate parents who only understand the appliance-like equipment. (A state many of us have all been in, at some point in our lives.)
Its not just a matter of what you can get. Its also a matter of what the market allows you to actually afford.
And as your codebase grows, I strongly recommend taking breaks to read books on design patterns, clean code, unit testing, etc. Without learning the various architectural techniques out there, any codebase will devolve into spaghetti the moment you try to implement any mildly interesting features. However, you won't see the obvious need for those techniques until your project reaches that point.
Except if you look at a local map, "The West Bank" doesn't really exist as a marked-off territory. That seems to be a creation of US/western maps. First, the area is locally called "Judea and Samaria." Second, the highway system runs right through it as though it were just another part of the country.
Except the modern office suite software has made Ctrl-V useless and annoying, copying styles that have nothing to do with your paste target and often messing it up in the process. So instead you have to either click through menus or find a far more awkward key combo to "paste without formatting."
Re:It'll never make it through FDA trials
on
Cancer Cured By HIV
·
· Score: 1
This is actually something I've often wondered about, more about the ACA than big pharma. We have all these big "societies" that have grown up around major medical conditions. And any sufficiently large organization tends to want to perpetuate. If the thing they stand for is suddenly a solved problem, what motive do they have to continue to exist?
(That being said, given that cancer is really a whole family of related conditions, I doubt its something that can be "cured" in one fell swoop anyways.)
But seriously, if the "tried and true" methods aren't making more than minor incremental progress, what's so bad about trying radial new high-risk/high-payoff things? For the DoD, we have a whole agency (DARPA) dedicated to funding just that.
And as someone who often posts to Facebook/Twitter from places other than a desktop web browser (often Twitter first, with an FB app to pick it up), I find this a completely worthless solution. However, I have yet to hear of another option.
That's also a big problem, because sometimes there is a common language. But the lowest-common denominator version of the language and API is extremely primitive. For example, Android, BlackBerry, and "those other J2ME-supporting phones" (not sure what you call them) can all be developed for in Java. Except...
- J2ME is based off Java 1.3 (I think), with an extremely primitive API - BlackBerry is J2ME-derived, but compensates by adding a lot of useful classes to its API (that obviously don't work on normal J2ME) - Android is J2SE-derived, but is really completely its own API
So BlackBerry's J2ME "compatibility" deludes people into thinking they can just write a single J2ME app that works on both, or share a lot of code. In reality, any apps written this way tend to be quirky and barely usable, since core J2ME is so limited.
And one might think you could share your business logic amongst all 3, since they're all technically Java. Well, doing that would require carrying along your own abstraction layer for pretty much anything beyond a tiny subset of java.lang.* and java.util.*, and being very limited in your use of language features.
This is one interesting thing about mobile development. Each platform pretty much dictates a programming language of choice. If its a language you don't mind working in, then its not a problem. But that's not always the case. Personally, I seem to know a lot of sysadmin-types who tend to be stuck-up jackasses about their own little personal language hatreds or preferences, and these opinions tend to be formed completely in a vacuum from target platforms. (Of course, since you can develop in pretty much any language on a PC, and especially so in *nix, this attitude becomes quite permissible.)
Of course this "language independence" works in the non-mobile world because the OS and/or GUI libraries expose their APIs primarily through C, which is then wrapped in higher-level APIs for any other programming language of choice. You also have a bit less of a "single vendor must provide all" approach in the non-mobile world, since individual developers are often leveraging a whole ecosystem of libraries maintained external to the OS. (Mobile developers seem to have a far lower willingness to expend time and effort doing anything that can't be done with out-of-the-box OS libraries/tools.)
And with the PlayBook, RIM went to the extreme of this. Made the tools so high-level that no one (except the developers who write things we install Firefox plugins to block) will want to use. However, that's just step 1. Step 2 is going to be releasing a full native SDK that will allow people to actually write real code in C/C++ (or obviously port any libraries we want on top of that). Step 3 will be compatibility layers for existing mobile Java flavors (BB and Android). Of course the PlayBook uses a QNX-based OS, which can safely and security run all of this stuff.
On the phones, I think the reason they never did this was because the OS really didn't have a good way of supporting it. It was designed before iOS or Android existed, and really does seem to function like one big JVM. (Any strange quirks it may have can really be explained when you think in these terms.) Sure, they've pushed it far beyond its initially intended capabilities, but its gone about as far as it can reasonably go. I just hope they survive the platform transition once their tablet OS gains a mature enough software stack to become their phone OS.
And the current trend in computing devices is one from where the normal consumer device could be tinkered with, to where the normal consumer device is forbidden from being tinkered with. Its only a matter of time before you'll need a special "development system" to do any tinkering at all. Of course there are many in our age group who may not see this as a problem, because *they* would get such a system, and *normal* people don't need one anyways.
And you know how likely it is for a middle-schooler to actually have access to such a system? Especially when the parents aren't tinkerers themselves? Practically zip!
Or the casual use of "SQL Server" for "Microsoft SQL Server". (Not to be confused with all the other database products that might handle SQL, and have the phrase "SQL Server" in their full product name.)
I've heard that the so-called "black programs" are actually far more likely to be on-time and within-budget, due to not having to deal with all the same sorts of red tape:-)
People often forget where that $800 hammer comes from:-)
- You need to have a DARPA program to fund research into advanced nail insertion technology (ANIT). - Then you have some FFRDC do an involved trade study that concludes that a hammer is preferably to the DARPA-developed ANIT project. - A program executive office (PEO) now hosts an industry day presentation on the US Army's Tactical Hammer Needs to the tool-making industries - The PEO now publishes a Request For Information (RFI) to solicit information from industry on steel hardening and handle-forming capabilities that could be used for the hammers. - Finally a Request for Proposal (RFP) is published, along with a detailed performance spec, requirements list, and statement of work. There is a limited number of hammers desired, with options for buying more later. They also have to conform to various Military standards that no tool you'd buy at Home Depot would ever have to confirm to. Also, they do need to be made in the US in a facility that holds the proper security clearances. - The PEO finally selects one of the submitted proposals, awarding the contract. - One of the loosing contractors decides to file a formal protest, and drags the process out longer. Eventually a settlement is made, and the selected prime contractor takes them on as a subcontractor for handle-to-head integration. - After several rounds of requirements engineering, systems engineering, and product R&D, along with approvals at preliminary and critical design reviews (PDR/CDR), the government gives the go-ahead to enter Low-Rate Initial Production (LRIP). - Testing eventually finds issues in the initial batch. Some design changes are made, costs are passed along, and eventually the hammer enters full-rate production (FRP). - Following training and deployment, the MK42 Tactical Nail Insertion Device (code-name "Hammer") is deployed into the field. - Meanwhile, nails are getting tougher, and follow-on program for the MK49 Objective Nail Banger is announced.
The core of the PlayBook's OS isn't bad at all. It actually works really well and feels quite solid. The problem is that the software stack layered on top of it is mostly incomplete at this stage. That stuff all takes time to build from scratch, and they didn't take the approach of throwing a boatload of money to a team hiding behind locked doors for a few years to do it.
Well, we do have the photos taken by the Apollo astronauts. Those were taken using color film on a Hasselblad, which is technically a medium-format SLR, and the quality is pretty darn amazing.
Slashdot Mirror
This is the original article that the linked articles are attempting to paraphrase:
Israel vows to hit back after credit cards hacked
While it doesn't add too much information, it might have slightly better wording.
And if anyone actually was curious, the PlayBook Native SDK actually does run on Linux, and a lot of the F/OSS they've been porting to it is posted on Github.
http://blackberry.github.com/
And anyone who's stumbled across old DEC hardware knows that the round mouse long pre-dated the iMac.
Because those APIs are the reason people use Windows in the first place.
Just look at any market where Microsoft doesn't have a "legacy platform advantage," and see just how much more competition they face. In some of those markets, they may even have a trivial presence.
So, about the time that the enterprise world finally upgrades from Windows XP? :-)
Except when changes in economies of scale make the hobbyist-friendly stuff far more expensive and difficult to obtain than we're currently used to. Oh, and also far less accessible to the high school kid with techno-illiterate parents who only understand the appliance-like equipment. (A state many of us have all been in, at some point in our lives.)
Its not just a matter of what you can get. Its also a matter of what the market allows you to actually afford.
And as your codebase grows, I strongly recommend taking breaks to read books on design patterns, clean code, unit testing, etc. Without learning the various architectural techniques out there, any codebase will devolve into spaghetti the moment you try to implement any mildly interesting features. However, you won't see the obvious need for those techniques until your project reaches that point.
Qt is very cleanly written and well commented where it matters. Most F/OSS code tends to have no comments of any sort, for some reason.
Except if you look at a local map, "The West Bank" doesn't really exist as a marked-off territory. That seems to be a creation of US/western maps. First, the area is locally called "Judea and Samaria." Second, the highway system runs right through it as though it were just another part of the country.
Actually, this one only seems to work in Firefox and vim. Haven't seen anything else support it.
Except the modern office suite software has made Ctrl-V useless and annoying, copying styles that have nothing to do with your paste target and often messing it up in the process. So instead you have to either click through menus or find a far more awkward key combo to "paste without formatting."
This is actually something I've often wondered about, more about the ACA than big pharma. We have all these big "societies" that have grown up around major medical conditions. And any sufficiently large organization tends to want to perpetuate. If the thing they stand for is suddenly a solved problem, what motive do they have to continue to exist?
(That being said, given that cancer is really a whole family of related conditions, I doubt its something that can be "cured" in one fell swoop anyways.)
But seriously, if the "tried and true" methods aren't making more than minor incremental progress, what's so bad about trying radial new high-risk/high-payoff things? For the DoD, we have a whole agency (DARPA) dedicated to funding just that.
And as someone who often posts to Facebook/Twitter from places other than a desktop web browser (often Twitter first, with an FB app to pick it up), I find this a completely worthless solution. However, I have yet to hear of another option.
And have exemptions for the types of calls that make up the majority of your junk call volume anyways.
That's also a big problem, because sometimes there is a common language. But the lowest-common denominator version of the language and API is extremely primitive. For example, Android, BlackBerry, and "those other J2ME-supporting phones" (not sure what you call them) can all be developed for in Java. Except...
- J2ME is based off Java 1.3 (I think), with an extremely primitive API
- BlackBerry is J2ME-derived, but compensates by adding a lot of useful classes to its API (that obviously don't work on normal J2ME)
- Android is J2SE-derived, but is really completely its own API
So BlackBerry's J2ME "compatibility" deludes people into thinking they can just write a single J2ME app that works on both, or share a lot of code. In reality, any apps written this way tend to be quirky and barely usable, since core J2ME is so limited.
And one might think you could share your business logic amongst all 3, since they're all technically Java. Well, doing that would require carrying along your own abstraction layer for pretty much anything beyond a tiny subset of java.lang.* and java.util.*, and being very limited in your use of language features.
This is one interesting thing about mobile development. Each platform pretty much dictates a programming language of choice. If its a language you don't mind working in, then its not a problem. But that's not always the case. Personally, I seem to know a lot of sysadmin-types who tend to be stuck-up jackasses about their own little personal language hatreds or preferences, and these opinions tend to be formed completely in a vacuum from target platforms. (Of course, since you can develop in pretty much any language on a PC, and especially so in *nix, this attitude becomes quite permissible.)
Of course this "language independence" works in the non-mobile world because the OS and/or GUI libraries expose their APIs primarily through C, which is then wrapped in higher-level APIs for any other programming language of choice. You also have a bit less of a "single vendor must provide all" approach in the non-mobile world, since individual developers are often leveraging a whole ecosystem of libraries maintained external to the OS. (Mobile developers seem to have a far lower willingness to expend time and effort doing anything that can't be done with out-of-the-box OS libraries/tools.)
And with the PlayBook, RIM went to the extreme of this. Made the tools so high-level that no one (except the developers who write things we install Firefox plugins to block) will want to use. However, that's just step 1. Step 2 is going to be releasing a full native SDK that will allow people to actually write real code in C/C++ (or obviously port any libraries we want on top of that). Step 3 will be compatibility layers for existing mobile Java flavors (BB and Android). Of course the PlayBook uses a QNX-based OS, which can safely and security run all of this stuff.
On the phones, I think the reason they never did this was because the OS really didn't have a good way of supporting it. It was designed before iOS or Android existed, and really does seem to function like one big JVM. (Any strange quirks it may have can really be explained when you think in these terms.) Sure, they've pushed it far beyond its initially intended capabilities, but its gone about as far as it can reasonably go. I just hope they survive the platform transition once their tablet OS gains a mature enough software stack to become their phone OS.
And the current trend in computing devices is one from where the normal consumer device could be tinkered with, to where the normal consumer device is forbidden from being tinkered with. Its only a matter of time before you'll need a special "development system" to do any tinkering at all. Of course there are many in our age group who may not see this as a problem, because *they* would get such a system, and *normal* people don't need one anyways.
And you know how likely it is for a middle-schooler to actually have access to such a system? Especially when the parents aren't tinkerers themselves? Practically zip!
Think about it.
Or the casual use of "SQL Server" for "Microsoft SQL Server". (Not to be confused with all the other database products that might handle SQL, and have the phrase "SQL Server" in their full product name.)
I've heard that the so-called "black programs" are actually far more likely to be on-time and within-budget, due to not having to deal with all the same sorts of red tape :-)
People often forget where that $800 hammer comes from :-)
- You need to have a DARPA program to fund research into advanced nail insertion technology (ANIT).
- Then you have some FFRDC do an involved trade study that concludes that a hammer is preferably to the DARPA-developed ANIT project.
- A program executive office (PEO) now hosts an industry day presentation on the US Army's Tactical Hammer Needs to the tool-making industries
- The PEO now publishes a Request For Information (RFI) to solicit information from industry on steel hardening and handle-forming capabilities that could be used for the hammers.
- Finally a Request for Proposal (RFP) is published, along with a detailed performance spec, requirements list, and statement of work. There is a limited number of hammers desired, with options for buying more later. They also have to conform to various Military standards that no tool you'd buy at Home Depot would ever have to confirm to. Also, they do need to be made in the US in a facility that holds the proper security clearances.
- The PEO finally selects one of the submitted proposals, awarding the contract.
- One of the loosing contractors decides to file a formal protest, and drags the process out longer. Eventually a settlement is made, and the selected prime contractor takes them on as a subcontractor for handle-to-head integration.
- After several rounds of requirements engineering, systems engineering, and product R&D, along with approvals at preliminary and critical design reviews (PDR/CDR), the government gives the go-ahead to enter Low-Rate Initial Production (LRIP).
- Testing eventually finds issues in the initial batch. Some design changes are made, costs are passed along, and eventually the hammer enters full-rate production (FRP).
- Following training and deployment, the MK42 Tactical Nail Insertion Device (code-name "Hammer") is deployed into the field.
- Meanwhile, nails are getting tougher, and follow-on program for the MK49 Objective Nail Banger is announced.
I could go on forever :-)
Why does that look more like a BSD license than the LGPL?
The core of the PlayBook's OS isn't bad at all. It actually works really well and feels quite solid. The problem is that the software stack layered on top of it is mostly incomplete at this stage. That stuff all takes time to build from scratch, and they didn't take the approach of throwing a boatload of money to a team hiding behind locked doors for a few years to do it.
Um, they fixed the browser in OS 6. It doesn't suck anymore.
Well, we do have the photos taken by the Apollo astronauts. Those were taken using color film on a Hasselblad, which is technically a medium-format SLR, and the quality is pretty darn amazing.