1) Your'e not at home/wheever the app is running. You're someplace else and wanr to run it remotely. Think home security applications, programming your DVR, etc).
2) You can't run it regularly because you don't have access to the computer it's running on. Maybe it's running in the cloud.
3) This is just another way of building highly interactive web pages. Beats the crap out of AJAX. Google could rewrite GMail as a linux app rather than using web technologies, and you'd not know the difference.
So the app is generating an HTML5 based web page that you serve to the remote browser? I'm not up-to speed on HTML5, so how does this handle the application "pushing" screen updates to the browser?
In general, yes, but anyone trivializing the risks of LSD is in fact a moron, especially when doing so in a forum like this full of young impressionable people who might take that as a factor in deciding to try it.
Yes, it sounds as if the bulk of Qt development will continue to be done at Nokia, but (other that having the Qt devs on their payroll) Nokia is now really in the same position as anyone else who chooses to continue to develop Qt under the LGPL... It seems they've sold the only piece that had any exclusivity to it - i.e. all that they really could sell having LGPL'd it.
Well, given that SCO failed to find any evidence to show to the court in 2005-2010, it seem a bit redundant for them to need to disclose that neither could they find any evidence in 2004!
A lot of people would argue.Net is a much better development environment than Qt. I can't understand why someone would willingly use C++ to develop user applications ( not systems dev ) in 2011. Even Android promotes Java for this.
Android doesn't promote Java because it's a better language than C++ for developing apps, but rather because of the benefits of using a virtual machine (just as,.NET targets the CLR VM). Anyways, I'd say that C# (since you're implicitly comparing.NET to C++) has as much in common with C++ as it does with Java.
If you think that.NET provides more productive libraries/etc to build graphical apps than Qt, then I can only assume you've never actually used Qt (esp. the components like QML & Qt Quick intended for modern animated phone-type applications).
Re:Another great Python 3.x series release
on
Python 3.2 Released
·
· Score: 1
So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.
It'd be nice if all library, language developers had super-human powers of future-prediction, but guess what... they don't. When designing a piece of software, there's only so far you can accurately predict potential future requirements and design to accommodate those. At some point your requirements change beyond the scope of what you were able to anticipate and you've got two choices:
1) Hack the new features in - thereby dooming the software to end-of-life ugliness and eventual replacement by something more suited to the now current requirements, OR
2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't. If you can't keep backwards compatibility while keeping the (refactored, reconsidered) design clean, then you're back at case 1 - a hack.
There do already exist anti-missile defences such as the phalanx gun (a radar guided gun that shoots 3-4000 15mm rounds per minute = 50+ rounds/sec), but this would certainly be a huge step up in defensive capability.
I don't know the latest benchmarks, but most programs arn't app. code bound anyway - they depend more on graphics, I/O (disk, network), external servers (web), etc.
Where pure CPU speed is an issue a language like C/C++ that was designed to map 1:1 to hardware always has a potential edge at least in allowing a human to cleverly code something, but optimizers are getting better all the time and a JIT compiler has the potential benefit of run-time information which a pre-compiled binary doesn't (not that a pre-compiled binary couldn't be instrumented by the compiler to gather run-time into to be feed back into the optimizer for the next compilation - I believe such compilers already exist).
Modern CPUs are also crazy fast, so for many apps, even if CPU is the limiting factor, the real-world difference is not important (who cares if your list gets sorted in 0.0001 or 0.0002 seconds)..
Having said all that, there will always be a few applications that are CPU bound, and where run-times are long enough that the difference in efficiency really does make a difference, and you're never going to see languages that trade efficiency for ease-of-use being widely used in those situations. Java is certainly such a language.
You're right - I forgot that WP7 apps are primarily.NET (they do have a native SDK too - but only available to special partners, not regular developers).
Some reasons Intel may prefer Android are:
1) It's Linux-based, like Meego which they are trying to push
2) Open source is strategically in Intel's interest since the more (CPU sucking) software is in more people's hands the better (just like Google promoting internet usage to sell more advertising)
I doubt there are too many places an ICBM travelling at Mach 1 can sustain even a 1/2" hole bored thru it without either somthing vital (fuel, wiring, electronics, warhead) being hit, or just simply losing control aerodynamically and breaking up a la Columbia (Space Shuttle) with a hole in the wing.
Who needs range when your "missile" is travelling at the speed of light?
Anyways, for a laser mounted on a Navy warship, say 10m above sea level, the horizon is over 10km away, so even an incoming sea skipping exocet missile coming in at 300 m/s is over 30 sec away.
The "20 feet of steel per second" number is similar to Slashdots car analogies - a way to make an otherwise difficult to understand number more human friendly. It's probably just the time it took to burn though, say, 1/4" of steel scaled up how much it could cut through in a second, if they could operate it continuously (which presumably they can't).
The goal of this thing certainly isn't cutting though many feet of steel - it's for shooting down missiles.
The article said it can burn thru 20 feet of steel per second, not 200 per the slashdot version.
Even the 20 feet is likely misleading since I doubt it can sustain that power output for more than a fraction of a second, and anyways if you really were borign thru multiple feet of steel then all your vaporized steel in the borehole you were creating would get in the way of the laser.
Still very impressive though. I'd love to see the face of the first crackpot dictator whose ICBMs are shot down by one of these.
WP7 only runs on ARM, so Intel doesn't have a lot to lose in saying Android would have been a better bet.
Android is also currently ARM only, but by basing it on the Dalvik VM, Google are at least ensuring that all existing (non-native) apps could run on future Android phones utilizing a different processor.
I don't think anyone in the market for a high end smart phone is going to be unaware what it's running and buy one by accident. More liikely current Nokia owners screwed by this about face and lack of upgrade path are going to look elsewhere next time. I don't think Nokia yet realize the amount of customer loyalty they've just lost. Any Nokia customer who wanted a Linux (Maemo) based phone will now have to switch to Android or even HP (Palm's WebOS).
Fragmentation is certainly an issue for Android, but this is more an issue for app developers who'd like to target a large unified market than it is for users. If you really want Android 2.x (or 3.0) so bad and can't get it on your current phone, are you really likely to switch to Microsoft out of spite, or just go buy yourself what you want (or just do nothing)?
I don't see Microsoft as guaranteeing major updates either.. Will your old MS phone run WP7? Will your WP7 phone run Windows 8 (already in beta, and targetting mobile devices)?
So, they sell support and training. Apparently (according to a Qt blog) there are 400,000 Qt developers, so a reasonable base to support. It's really quite an opportunity to be given Qt at it's current (advanced) state LGPL'd and be able to build a support business for that, without having to incurred the $millions it took to develop or the $150million or so it took Nokia to aquire!
With Qt you've got the best of both worlds, QtWebKit is totally integrated into Qt so you can use Qt to build apps that mix n match web and desktop technologies as you please.
Well, I can see why Nokia did this... as the smartphone market settles there are only going to be a vrey few major platform winners, so Nokia could either try to compete with Apple, Microsoft and Google for platform dominanceor join forces with one of them.
However, it's an extraordinarily risky move - they go from being the dominant phone manufacturer to being a kingmaker for Microsoft, while turning themselves into a WP7 commodity supplier. The only way to win in a commodity market is to be the lowest cost provider. Is that the market niche Nokia is after?
I think what they should have done instead was to continue their recent Qt-based SDK strategy, which makes the underlying OS irrelevant, and therefore serves to protect development investment. Qt mitigates any complaints about the Symbian SDK while providing an industry best SDK for Nokia (Meego-based) smartphones.
As an insurance policy against Meego failing, they could have (unannounced) pursued a Qt-on-Android "plan B", and/or (unnanounced) continued negotiations with Microsoft and held out for a better deal (Microsoft has more to gain from this than Nokia).
Nokia's timing in abandoning/rejecting Linux (Meego, Android) is also a bit premature given the wave of ARM-based Linux powered devices that are starting to appear.
Slashdot Mirror
Some reasons that come to mind:
1) Your'e not at home/wheever the app is running. You're someplace else and wanr to run it remotely. Think home security applications, programming your DVR, etc).
2) You can't run it regularly because you don't have access to the computer it's running on. Maybe it's running in the cloud.
3) This is just another way of building highly interactive web pages. Beats the crap out of AJAX. Google could rewrite GMail as a linux app rather than using web technologies, and you'd not know the difference.
So the app is generating an HTML5 based web page that you serve to the remote browser? I'm not up-to speed on HTML5, so how does this handle the application "pushing" screen updates to the browser?
In general, yes, but anyone trivializing the risks of LSD is in fact a moron, especially when doing so in a forum like this full of young impressionable people who might take that as a factor in deciding to try it.
... and since plain old water *IS* toxic to humans in large quantities, I guess one could conclude that LSD is safe and water isn't.
Of course you'd have to be a moron to conclude that, but in your case that condition seems to have already been met.
Yes, it sounds as if the bulk of Qt development will continue to be done at Nokia, but (other that having the Qt devs on their payroll) Nokia is now really in the same position as anyone else who chooses to continue to develop Qt under the LGPL... It seems they've sold the only piece that had any exclusivity to it - i.e. all that they really could sell having LGPL'd it.
Well, given that SCO failed to find any evidence to show to the court in 2005-2010, it seem a bit redundant for them to need to disclose that neither could they find any evidence in 2004!
Yep, and and Native Client (NaCl - salt) uses a browser plug-in interface called pepper. Tasty stuff!
A lot of people would argue .Net is a much better development environment than Qt. I can't understand why someone would willingly use C++ to develop user applications ( not systems dev ) in 2011. Even Android promotes Java for this.
Android doesn't promote Java because it's a better language than C++ for developing apps, but rather because of the benefits of using a virtual machine (just as ,.NET targets the CLR VM). Anyways, I'd say that C# (since you're implicitly comparing .NET to C++) has as much in common with C++ as it does with Java.
If you think that .NET provides more productive libraries/etc to build graphical apps than Qt, then I can only assume you've never actually used Qt (esp. the components like QML & Qt Quick intended for modern animated phone-type applications).
So consider Python 2.0 as a legacy language then, and Python 3.0 as a new one.
It'd be nice if all library, language developers had super-human powers of future-prediction, but guess what... they don't. When designing a piece of software, there's only so far you can accurately predict potential future requirements and design to accommodate those. At some point your requirements change beyond the scope of what you were able to anticipate and you've got two choices:
1) Hack the new features in - thereby dooming the software to end-of-life ugliness and eventual replacement by something more suited to the now current requirements, OR
2) Refactor/redesign to reflect the new requirements and as much of the future you can predict from this new position. Maybe you can do this while keeping backwards compatability, and maybe you can't. If you can't keep backwards compatibility while keeping the (refactored, reconsidered) design clean, then you're back at case 1 - a hack.
Huh? You seem to be thinking of an artillary scenario or somesuch, where a shot fired on target is as good as a hit.
What good does it do an enemy to fire a missile at you when you have the ability to shoot it down while it's as far as 10km away??!!
Never mid that, what does your defensive capability (laser) have to do with the your choice of offense?
Please engage brain before posting!
This video shows the phalanx doing it's thing ! :-)
http://www.youtube.com/watch?v=prNhzbqlZ4Q
There do already exist anti-missile defences such as the phalanx gun (a radar guided gun that shoots 3-4000 15mm rounds per minute = 50+ rounds/sec), but this would certainly be a huge step up in defensive capability.
http://www.google.com/search?hl=en&tbs=vid%3A1&q=phalanx+gun&aq=f&aqi=&aql=&oq=
I don't know the latest benchmarks, but most programs arn't app. code bound anyway - they depend more on graphics, I/O (disk, network), external servers (web), etc.
Where pure CPU speed is an issue a language like C/C++ that was designed to map 1:1 to hardware always has a potential edge at least in allowing a human to cleverly code something, but optimizers are getting better all the time and a JIT compiler has the potential benefit of run-time information which a pre-compiled binary doesn't (not that a pre-compiled binary couldn't be instrumented by the compiler to gather run-time into to be feed back into the optimizer for the next compilation - I believe such compilers already exist).
Modern CPUs are also crazy fast, so for many apps, even if CPU is the limiting factor, the real-world difference is not important (who cares if your list gets sorted in 0.0001 or 0.0002 seconds)..
Having said all that, there will always be a few applications that are CPU bound, and where run-times are long enough that the difference in efficiency really does make a difference, and you're never going to see languages that trade efficiency for ease-of-use being widely used in those situations. Java is certainly such a language.
You're right - I forgot that WP7 apps are primarily .NET (they do have a native SDK too - but only available to special partners, not regular developers).
Some reasons Intel may prefer Android are:
1) It's Linux-based, like Meego which they are trying to push
2) Open source is strategically in Intel's interest since the more (CPU sucking) software is in more people's hands the better (just like Google promoting internet usage to sell more advertising)
Lasers are unavoidable and impossible to counter - the best you can do is get more hull plating everywhere.
Yeah - either that or just shoot the frickin' shark.
I doubt there are too many places an ICBM travelling at Mach 1 can sustain even a 1/2" hole bored thru it without either somthing vital (fuel, wiring, electronics, warhead) being hit, or just simply losing control aerodynamically and breaking up a la Columbia (Space Shuttle) with a hole in the wing.
Who needs range when your "missile" is travelling at the speed of light?
Anyways, for a laser mounted on a Navy warship, say 10m above sea level, the horizon is over 10km away, so even an incoming sea skipping exocet missile coming in at 300 m/s is over 30 sec away.
http://en.wikipedia.org/wiki/Horizon
The "20 feet of steel per second" number is similar to Slashdots car analogies - a way to make an otherwise difficult to understand number more human friendly. It's probably just the time it took to burn though, say, 1/4" of steel scaled up how much it could cut through in a second, if they could operate it continuously (which presumably they can't).
The goal of this thing certainly isn't cutting though many feet of steel - it's for shooting down missiles.
The article said it can burn thru 20 feet of steel per second, not 200 per the slashdot version.
Even the 20 feet is likely misleading since I doubt it can sustain that power output for more than a fraction of a second, and anyways if you really were borign thru multiple feet of steel then all your vaporized steel in the borehole you were creating would get in the way of the laser.
Still very impressive though. I'd love to see the face of the first crackpot dictator whose ICBMs are shot down by one of these.
WP7 only runs on ARM, so Intel doesn't have a lot to lose in saying Android would have been a better bet.
Android is also currently ARM only, but by basing it on the Dalvik VM, Google are at least ensuring that all existing (non-native) apps could run on future Android phones utilizing a different processor.
I don't think anyone in the market for a high end smart phone is going to be unaware what it's running and buy one by accident. More liikely current Nokia owners screwed by this about face and lack of upgrade path are going to look elsewhere next time. I don't think Nokia yet realize the amount of customer loyalty they've just lost. Any Nokia customer who wanted a Linux (Maemo) based phone will now have to switch to Android or even HP (Palm's WebOS).
Fragmentation is certainly an issue for Android, but this is more an issue for app developers who'd like to target a large unified market than it is for users. If you really want Android 2.x (or 3.0) so bad and can't get it on your current phone, are you really likely to switch to Microsoft out of spite, or just go buy yourself what you want (or just do nothing)?
I don't see Microsoft as guaranteeing major updates either.. Will your old MS phone run WP7? Will your WP7 phone run Windows 8 (already in beta, and targetting mobile devices)?
This "multi-tasking" thing (did I say that right?) sounds freaking amazing!
I can't beleive they've also got a web browser running on a phone (on a PHONE!!!!). I almost crapped my pants!!!
God bless the USA!
So, they sell support and training. Apparently (according to a Qt blog) there are 400,000 Qt developers, so a reasonable base to support. It's really quite an opportunity to be given Qt at it's current (advanced) state LGPL'd and be able to build a support business for that, without having to incurred the $millions it took to develop or the $150million or so it took Nokia to aquire!
With Qt you've got the best of both worlds, QtWebKit is totally integrated into Qt so you can use Qt to build apps that mix n match web and desktop technologies as you please.
Well, I can see why Nokia did this... as the smartphone market settles there are only going to be a vrey few major platform winners, so Nokia could either try to compete with Apple, Microsoft and Google for platform dominanceor join forces with one of them.
However, it's an extraordinarily risky move - they go from being the dominant phone manufacturer to being a kingmaker for Microsoft, while turning themselves into a WP7 commodity supplier. The only way to win in a commodity market is to be the lowest cost provider. Is that the market niche Nokia is after?
I think what they should have done instead was to continue their recent Qt-based SDK strategy, which makes the underlying OS irrelevant, and therefore serves to protect development investment. Qt mitigates any complaints about the Symbian SDK while providing an industry best SDK for Nokia (Meego-based) smartphones.
As an insurance policy against Meego failing, they could have (unannounced) pursued a Qt-on-Android "plan B", and/or (unnanounced) continued negotiations with Microsoft and held out for a better deal (Microsoft has more to gain from this than Nokia).
Nokia's timing in abandoning/rejecting Linux (Meego, Android) is also a bit premature given the wave of ARM-based Linux powered devices that are starting to appear.