"Crap" is relative. While I've complained a lot about the old Froyo-based phone I eventually ditched, you only have to look at what passes for "apps" on a non-smartphone to see what a step up even a crap Android phone is over that.
The game has changed a bit. Pick a cheaper Lumia or an Asha touch phone (to talk about ostensible non-smartphones). Most cheap Android phones are crap compared to that.
Really? Just like Surface doomed the prospects of Asus, Samsung, and the few other manufacturers who have announced Windows RT tablets?
You armchair business analysts seem to assume that there is no OEM differentiation in the Windows world. I can't see why. Lumia 920 is a very impressive device, and it's selling as of today, while the MS phone is only an industrial rumor.
Of course, everybody knows they are paedophile hangouts. OK, Myspace has a chance to get overlooked, since nobody cares about it anymore.
Facing recent waves of protest, some Russian officials have shared a shocking revelation: much of the "inciting" commentary was published on servers hosted in the U.S.! They are live relics, looking at our world and trying to reconnect it with their bygone era.
Agreed, my young friend, though the Berlin Wall was built by East Germany which was a Soviet puppet state. A better pun would be the Tinfoil Curtain, to harken back to the Iron Curtain of old. Even then, people were able to listen to shortwave stations from the West, despite jamming. The current attempt is bound to failure, it will cause inconvenience at worst and breed more dissent.
There is no way to connect to the appstore and forbid Microsoft from wiping my phone or finding my location because these levers are controlled by a web site hosted by Microsoft not by levers in the device itself.
You mean, if somebody steals my phone and it's not locked, they should be able to prevent me from wiping my data and going after them?
I can't even use the GPS without it leaking data over my data plan that I pay for to croudsource their a tower/wifi skyhook type system.
I suggest you look into Google ToS for their location-enabled applications. They played this game with Google Maps waaay back in Symbian times. But otherwise yeah, it looks like you can't opt out. So enjoy your quick assisted GPS fixes, that's what you get in return for sending data about the tower IDs your device sees.
I can't use wifi without it sending NLA type crap to MS servers I have no way of turning off.
That's news to me, is there anything on the net describing this "feature"?
If you don't need WP8-specific functionality you can target WP7.5 and your app will work on both.
Yeah, that's what I understood. I don't know why would people feel blocked if they already have things working for WP7.5.
Of course, this limits you from using any of the new stuff like native code and DirectX support. If you want that, you're looking at a rewrite, but that shouldn't be a surprise.
Even then you get to keep the UI written in C# and XAML, and bridge with the native stuff should you need any.
Supportig iOS and Android is economical since they already have market share. Risking a third will only kill your profitability.
This means it will be taken over by your competitor who now has a chance to claim the Windows Phone users uncontested. Their number is relatively small, but it's growing, and the growth is expected to accelerate now that the fully competitive OS version is finally released.
I totally agree with your point, since all the prototyping we did for our Windows Phone 8 project was in Visual Studio 2010, targeting Windows Phone 7.5, on Win7 machines. None of that is actually useful right now. Surprise, surprise.
Weren't you supposed to be able to run your WP 7.5 applications on Windows Phone 8 practically unchanged?
Seriously? From the debacle that is the product just released at $work, with huge rounds of all-levels-of-management congratulations for getting the product out the door, I'd say that nothing matters other than the date. Not functionality, not quality, not employee retention (12-16 hour days, 7 days a week, for 3 months?). Nothing other than that date. It was going to be delivered come hell or high water.
This, precisely, brought Nokia to where it is now. Failure to acknowledge quality slips early and take action to fix the dysfunctional development culture that caused them. Any company that allows it will destroy itself in the long run.
You see, practically minded people have figured long ago that having no memory left to allocate means you're already screwed [...]
Not at all! It depends on the system, but there's often plenty of stuff you can do in a server environment.
Remember that anything you do in this situation cannot allocate any new memory at all. So God forbid you hit a logging statement on your way to freeing memory after a bad_alloc. It's not guaranteed that you can safely close files, database connections, and so on — something that exception unwind paths will be eager to do.
So if you want to reach OOM-safety, you still have to test every occasion in which it may happen. And it's not even a static list derived from simple code analysis.
Writing your code for exception safety to begin with (and it's honestly not hard) allows you to increase the robustness of the system without touching intermediate code. That alone has saved my bacon more than once.
Yes, exceptions are very useful... in managed environments that are designed to support them. Too bad in C++ they are basically feature creep that, among the other creepy features, stretched the language to the point where it can't be used to do anything in a simple way. You got to wrap everything in "smart pointers", of which until recently there was no standard variety, so everybody now uses their own flavor, not compatible with the others. The Boost/C++11 smart pointers are not designed to be passed around in function signatures: they are made to be convenient for type-casting, so they interact with the overcomplicated overload resolution rules in sometimes counter-intuitive ways (and produce kilobyte-long mangled symbol names for the benefit of your dynamic linker). So you have to leave your preferred smart pointer bubble at an API boundary, where an overlooked exception may bite you again, or you end up making a lot of deep copies just to work around the broken language design.
So, you substitute "this code does not lose data because it's well-tested" with "this code will never lose data because of our silver bullet: exceptions!" Guess what, you still have to test your code, and each throw site constitutes a separate error-handling path or a few, that all need to be tested. There is a problem, though: exception unwind paths are not easily mapped back to the code, so they may go overlooked in coverage tools and such.
Re bad_alloc: do you run database servers in an OS that lacks virtual memory allocation? It's about the only case where run-of-the-mill allocations can fail. On a typically configured Linux server, for example, unless you try to allocate huge buffers, the oom killer will get your process before you start seeing any bad_alloc's thrown. You see, practically minded people have figured long ago that having no memory left to allocate means you're already screwed; so they tend to find other solutions than guarding every allocation, wasting your time and code size on error handling paths that can hardly be properly exercised and tested. It should be more preemptive, too. On a server, low memory means you either have a memory leak, or your server is poorly specced/configured for the workload. Just restart it, shutting down services gracefully. On mobile devices, they gracefully suspend background apps and services when memory runs low. std::bad_alloc is irrelevant in most modern software development.
If you don't know why that line of code contains a bug, then you're a Qt programmer, not a C++ programmer. Though your tag line suggests that you do indeed know why it contains a bug, and you're still a Qt programmer.
I'm also a practical C++ programmer. I don't give a shit about bad_alloc or "exception safety" because they simply provide no value in the systems I work with. Software where that does matter, if it's even written in C++ to begin with, would have to redesign, rewrite, or harden most of the useful libraries available out there (I'm not talking about Boost, I mean libraries that actually implement some useful functionality). And you are in a world of pain if you try to bridge C code with code that takes C++ exceptions seriously.
And you are right about programming in Qt: you've got to take all that "efficient C++" schooling out to the backyard. Same is true about programming Mozilla, Chromium, GCC, or pretty much any popular open project or programming environment based on C++.
Qt's templates are designed to be lightweight and they are backed with a stable binary API. There are some exceptions, but most of Qt template classes are thin wrappers around library calls that implement the heavy lifting, rather than emitting everything in the compilation unit where the template is used.
Code generation in Qt is actually very different from how C++ templates work: the moc runtime support code is emitted in strictly one place per each class. The meta-object data provide features that C++ was never designed to do: runtime type introspection that works, down to class members and their signatures.
Ironically, using template metaprogramming shit actually hampers effective use of dynamic linkage. When using it in libraries, you have to painstakingly maintain a separation between internally used templates and library APIs that should not expose template classes not designed for such use, like proper thin templates are. Templates, for purposes of an ABI, are clouds of lexical tokens producing weakly linked instantiations that litter multiple binaries and are subject to constant change. So you end up doing things like bridging your templated types with opaque accessors used in the public API. And then some noob goes and leaks a list iterator into the public function signatures, thus exposing an implementation detail, and other noobs start using it from other modules, so your library is broken.
For example, a coding convention that bans complicated C++ meta-template programming techniques, helps to extract the maximum from recent grads, by making sure they don't have to read 'Modern C++ Design' cover to cover 7 times before making their first commit (and that also applies to R&D folks who have PHd's in maths/physics, yet would struggle to write their own linked list template).
That's a good reason alone, but really, banning meta-template shit like Boost and STL helps to extract greater efficiency across the board. Your ABIs can stay manageable, your binaries do not get more bloat than what you put there on purpose. Choose a good base library such as Qt, it will save you more time in the long run.
Sorry, I prefer to hide behind a degree of anonymity here on Slashdot. I appreciate your work back then, and the work of other good folks. If only they were in charge...
Nokia Maps on Windows Phone 7 need online access to (not hitherto cached) map data. AIUI, applications in WP7 cannot share data between themselves, so it's only Nokia Drive that gets to have offline maps. Managing two sets of identical offline maps on one device was probably deemed too wasteful, so they made this compromise.
Proper offline maps, shared between Maps and Drive, are reportedly implemented on WP8.
Then take all of the lovely WinMo devices that Nokia developed, and put the OS from the N9 on some and Belle FP1 on others. Sort out Skype so video chat finally works. Finally, clean out all of the trash from the Nokia Store and get, by paying them directly if necessary, developers to build out the basics (e.g., a proper chat client integrated into the messaging app, GMail sync as a default setup option).
You mean like, they should redo all the work that Microsoft is currently doing for them, and do it for their own money? Just because you don't like Microsoft? Belle... Yeah, that will move millions of devices.
I love how your only statement of fact is a Google search of images, some of them doctored for fun, and this gets modded up. I'll spare comments about coherence of your writing...
Lots of MS fanboys like to say competition is good when rooting for Windows Phone 7/8. But I doubt they would actually agree competition is good in general. What about competition in the Desktop OS space? Would those MS fanboys applaud if Windows dropped to 50% market share because competition is good? Nope.
I would love to see GNOME 3 taking a comparable share. (Ducks.)
Slashdot Mirror
"Crap" is relative. While I've complained a lot about the old Froyo-based phone I eventually ditched, you only have to look at what passes for "apps" on a non-smartphone to see what a step up even a crap Android phone is over that.
The game has changed a bit. Pick a cheaper Lumia or an Asha touch phone (to talk about ostensible non-smartphones). Most cheap Android phones are crap compared to that.
I believe a forked, mainline-incompatible Linux kernel runs on 75% of Smartphones :)
FTFY
Really? Just like Surface doomed the prospects of Asus, Samsung, and the few other manufacturers who have announced Windows RT tablets?
You armchair business analysts seem to assume that there is no OEM differentiation in the Windows world. I can't see why. Lumia 920 is a very impressive device, and it's selling as of today, while the MS phone is only an industrial rumor.
Having a US hosting provider or the protections of the 1st amendment didn't protect the director of “Innocence of Muslims".
I'd say, publishing a wacky hateful movie did not give him a license to violate the terms of his parole.
Of course, everybody knows they are paedophile hangouts. OK, Myspace has a chance to get overlooked, since nobody cares about it anymore.
Facing recent waves of protest, some Russian officials have shared a shocking revelation: much of the "inciting" commentary was published on servers hosted in the U.S.! They are live relics, looking at our world and trying to reconnect it with their bygone era.
Agreed, my young friend, though the Berlin Wall was built by East Germany which was a Soviet puppet state.
A better pun would be the Tinfoil Curtain, to harken back to the Iron Curtain of old.
Even then, people were able to listen to shortwave stations from the West, despite jamming. The current attempt is bound to failure, it will cause inconvenience at worst and breed more dissent.
There is no way to connect to the appstore and forbid Microsoft from wiping my phone or finding my location because these levers are controlled by a web site hosted by Microsoft not by levers in the device itself.
You mean, if somebody steals my phone and it's not locked, they should be able to prevent me from wiping my data and going after them?
I can't even use the GPS without it leaking data over my data plan that I pay for to croudsource their a tower/wifi skyhook type system.
I suggest you look into Google ToS for their location-enabled applications. They played this game with Google Maps waaay back in Symbian times. But otherwise yeah, it looks like you can't opt out. So enjoy your quick assisted GPS fixes, that's what you get in return for sending data about the tower IDs your device sees.
I can't use wifi without it sending NLA type crap to MS servers I have no way of turning off.
That's news to me, is there anything on the net describing this "feature"?
If you don't need WP8-specific functionality you can target WP7.5 and your app will work on both.
Yeah, that's what I understood. I don't know why would people feel blocked if they already have things working for WP7.5.
Of course, this limits you from using any of the new stuff like native code and DirectX support. If you want that, you're looking at a rewrite, but that shouldn't be a surprise.
Even then you get to keep the UI written in C# and XAML, and bridge with the native stuff should you need any.
Supportig iOS and Android is economical since they already have market share. Risking a third will only kill your profitability.
This means it will be taken over by your competitor who now has a chance to claim the Windows Phone users uncontested. Their number is relatively small, but it's growing, and the growth is expected to accelerate now that the fully competitive OS version is finally released.
I totally agree with your point, since all the prototyping we did for our Windows Phone 8 project was in Visual Studio 2010, targeting Windows Phone 7.5, on Win7 machines. None of that is actually useful right now. Surprise, surprise.
Weren't you supposed to be able to run your WP 7.5 applications on Windows Phone 8 practically unchanged?
Seriously? From the debacle that is the product just released at $work, with huge rounds of all-levels-of-management congratulations for getting the product out the door, I'd say that nothing matters other than the date. Not functionality, not quality, not employee retention (12-16 hour days, 7 days a week, for 3 months?). Nothing other than that date. It was going to be delivered come hell or high water.
This, precisely, brought Nokia to where it is now. Failure to acknowledge quality slips early and take action to fix the dysfunctional development culture that caused them. Any company that allows it will destroy itself in the long run.
Not at all! It depends on the system, but there's often plenty of stuff you can do in a server environment.
Remember that anything you do in this situation cannot allocate any new memory at all. So God forbid you hit a logging statement on your way to freeing memory after a bad_alloc. It's not guaranteed that you can safely close files, database connections, and so on — something that exception unwind paths will be eager to do.
So if you want to reach OOM-safety, you still have to test every occasion in which it may happen. And it's not even a static list derived from simple code analysis.
Writing your code for exception safety to begin with (and it's honestly not hard) allows you to increase the robustness of the system without touching intermediate code. That alone has saved my bacon more than once.
Yes, exceptions are very useful... in managed environments that are designed to support them. Too bad in C++ they are basically feature creep that, among the other creepy features, stretched the language to the point where it can't be used to do anything in a simple way. You got to wrap everything in "smart pointers", of which until recently there was no standard variety, so everybody now uses their own flavor, not compatible with the others. The Boost/C++11 smart pointers are not designed to be passed around in function signatures: they are made to be convenient for type-casting, so they interact with the overcomplicated overload resolution rules in sometimes counter-intuitive ways (and produce kilobyte-long mangled symbol names for the benefit of your dynamic linker). So you have to leave your preferred smart pointer bubble at an API boundary, where an overlooked exception may bite you again, or you end up making a lot of deep copies just to work around the broken language design.
So, you substitute "this code does not lose data because it's well-tested" with "this code will never lose data because of our silver bullet: exceptions!" Guess what, you still have to test your code, and each throw site constitutes a separate error-handling path or a few, that all need to be tested. There is a problem, though: exception unwind paths are not easily mapped back to the code, so they may go overlooked in coverage tools and such.
Re bad_alloc: do you run database servers in an OS that lacks virtual memory allocation? It's about the only case where run-of-the-mill allocations can fail. On a typically configured Linux server, for example, unless you try to allocate huge buffers, the oom killer will get your process before you start seeing any bad_alloc's thrown. You see, practically minded people have figured long ago that having no memory left to allocate means you're already screwed; so they tend to find other solutions than guarding every allocation, wasting your time and code size on error handling paths that can hardly be properly exercised and tested. It should be more preemptive, too. On a server, low memory means you either have a memory leak, or your server is poorly specced/configured for the workload. Just restart it, shutting down services gracefully. On mobile devices, they gracefully suspend background apps and services when memory runs low. std::bad_alloc is irrelevant in most modern software development.
How many times have you seen this?
QSomething* something = new QSomething();
If you don't know why that line of code contains a bug, then you're a Qt programmer, not a C++ programmer. Though your tag line suggests that you do indeed know why it contains a bug, and you're still a Qt programmer.
I'm also a practical C++ programmer. I don't give a shit about bad_alloc or "exception safety" because they simply provide no value in the systems I work with. Software where that does matter, if it's even written in C++ to begin with, would have to redesign, rewrite, or harden most of the useful libraries available out there (I'm not talking about Boost, I mean libraries that actually implement some useful functionality). And you are in a world of pain if you try to bridge C code with code that takes C++ exceptions seriously.
And you are right about programming in Qt: you've got to take all that "efficient C++" schooling out to the backyard. Same is true about programming Mozilla, Chromium, GCC, or pretty much any popular open project or programming environment based on C++.
Qt's templates are designed to be lightweight and they are backed with a stable binary API. There are some exceptions, but most of Qt template classes are thin wrappers around library calls that implement the heavy lifting, rather than emitting everything in the compilation unit where the template is used.
Code generation in Qt is actually very different from how C++ templates work: the moc runtime support code is emitted in strictly one place per each class. The meta-object data provide features that C++ was never designed to do: runtime type introspection that works, down to class members and their signatures.
Ironically, using template metaprogramming shit actually hampers effective use of dynamic linkage. When using it in libraries, you have to painstakingly maintain a separation between internally used templates and library APIs that should not expose template classes not designed for such use, like proper thin templates are. Templates, for purposes of an ABI, are clouds of lexical tokens producing weakly linked instantiations that litter multiple binaries and are subject to constant change. So you end up doing things like bridging your templated types with opaque accessors used in the public API. And then some noob goes and leaks a list iterator into the public function signatures, thus exposing an implementation detail, and other noobs start using it from other modules, so your library is broken.
For example, a coding convention that bans complicated C++ meta-template programming techniques, helps to extract the maximum from recent grads, by making sure they don't have to read 'Modern C++ Design' cover to cover 7 times before making their first commit (and that also applies to R&D folks who have PHd's in maths/physics, yet would struggle to write their own linked list template).
That's a good reason alone, but really, banning meta-template shit like Boost and STL helps to extract greater efficiency across the board. Your ABIs can stay manageable, your binaries do not get more bloat than what you put there on purpose. Choose a good base library such as Qt, it will save you more time in the long run.
Sorry, I prefer to hide behind a degree of anonymity here on Slashdot.
I appreciate your work back then, and the work of other good folks. If only they were in charge...
Dude, fatphil and I worked on it, so we know how fucked up it was, from the inside. Stop repeating Ahonen's bullshit.
Whoa there. Do you have any sources to back all that up?
Nokia Maps on Windows Phone 7 need online access to (not hitherto cached) map data.
AIUI, applications in WP7 cannot share data between themselves, so it's only Nokia Drive that gets to have offline maps. Managing two sets of identical offline maps on one device was probably deemed too wasteful, so they made this compromise.
Proper offline maps, shared between Maps and Drive, are reportedly implemented on WP8.
Then take all of the lovely WinMo devices that Nokia developed, and put the OS from the N9 on some and Belle FP1 on others. Sort out Skype so video chat finally works. Finally, clean out all of the trash from the Nokia Store and get, by paying them directly if necessary, developers to build out the basics (e.g., a proper chat client integrated into the messaging app, GMail sync as a default setup option).
You mean like, they should redo all the work that Microsoft is currently doing for them, and do it for their own money? Just because you don't like Microsoft?
Belle... Yeah, that will move millions of devices.
I love how your only statement of fact is a Google search of images, some of them doctored for fun, and this gets modded up.
I'll spare comments about coherence of your writing...
Lots of MS fanboys like to say competition is good when rooting for Windows Phone 7/8. But I doubt they would actually agree competition is good in general. What about competition in the Desktop OS space? Would those MS fanboys applaud if Windows dropped to 50% market share because competition is good? Nope.
I would love to see GNOME 3 taking a comparable share.
(Ducks.)