While the specific details of the deal are being worked out, here’s a quick summary of what we are working towards:
• Nokia will adopt Windows Phone as its primary smartphone strategy, innovating on top of the platform in areas such as imaging, where Nokia is a market leader.
• Nokia will help drive and define the future of Windows Phone. Nokia will contribute its expertise on hardware design, language support, and help bring Windows Phone to a larger range of price points, market segments and geographies.
• Nokia and Microsoft will closely collaborate on development, joint marketing initiatives and a shared development roadmap to align on the future evolution of mobile products.
• Bing will power Nokia’s search services across Nokia devices and services, giving customers access to Bing’s next generation search capabilities. Microsoft adCenter will provide search advertising services on Nokia’s line of devices and services.
• Nokia Maps will be a core part of Microsoft’s mapping services. For example, Maps would be integrated with Microsoft’s Bing search engine and adCenter advertising platform to form a unique local search and advertising experience.
• Nokia’s extensive operator billing agreements will make it easier for consumers to purchase Nokia Windows Phone services in countries where credit-card use is low.
• Microsoft development tools will be used to create applications to run on Nokia Windows Phones, allowing developers to easily leverage the ecosystem’s global reach.
• Microsoft will continue to invest in the development of Windows Phone and cloud services so customers can do more with their phone, across their work and personal lives.
• Nokia’s content and application store will be integrated with Microsoft Marketplace for a more compelling consumer experience.
announcement surprised almost everyone in the mobile industry. It was
hard to predict, but is not too hard to rationalize. It may be argued
that there are two reasons for Nokia's acquisition and open source
as a royalty-free, open source licensed OS, Android was too hard to
resist for any OEM. Nokia's acquisition of Symbian is essentially the
answer to Android, resonating the same core principles, which are
open source licensing for pooling costs of maintaining a commoditizing OS
majority ownership by a single player
Motorola was bleeding heavily in a financial sense, and so it would
have been keen to sell out its UIQ shares, which Sony Ericsson could
not assume the burden of, as UIQ was a long way from being profitable.
With UIQ out, S60 was the only Symbian-based alternative for Sony
Ericsson, and a strategic choice in keeping Google from becoming the
"Android-inside" of the mobile industry.
Communication is a big subject so I have decided to start with this.
Too much is a bad thing Rule #1: Users understand their workflow better than I do Rule #2: When a user tells me something, even in passing, they will expect me to remember it. Rule #3: User communication must be documented Rule #4: Users rarely take responsibility for follow-up Rule #5: People are sensitive to how others treat their importance Postmortem
Apple iPhone Link Pro : 480x320 Pixel Cool UI, But is it useful ? (Need hand on experience) Con : No Keyboard for SMS/Email No 3G for fast and easy browser experience No USB Port No Memory Card Extention No TVOut Too big to carry around. Too expansive. 8G-4G=4G NandFlash << 30USD Unknow : No Standby battery usage time
No Java VM Specification. No Detail Camera/Lens Specificaiton. True Mac OS X ? How about QuickTime Player ?
The basic idea of a MoSoSo is to overlay a location and time
element to the idea of digital networking. So it enables you to find
people in your vicinity and at that time for social, sexual/dating or
business networking. It's worth noting that the time variable is often
overlooked in analysis of MoSoSo dynamics.
1 Never use meaningful file or procedure names such as
IsValidSerialNum (duh.) If you do use functions for
checking purposes, place at least some required code
that your program really needs, in such a function.
When the cracker disables the function, the program
will produce incorrect results.
2 Don't warn the user right after a violation is made.
Wait later, maybe until the next day or two (crackers hate that).
3 Use checksums in DLL's and in the EXE. Have them check each other.
Not perfect but it just makes it harder to crack.
4 Pause a second or two after a password entry to make brute
force cracking unfeasible. Simple to do, but rarely done.
5 Self-heal your software. You know, error correction like modems
and hard drives use. The technology has been around for years,
and no one uses it on their software? The best thing about this
is that if the cracker used a decompiler, they may be looking at
a listing that is no longer valid.
6 Patch your own software. Change your code to call different
validation routines each time. Beat us at our own game.
7 Store serial numbers in unlikely places, like as a property
of a database field.
8 Store serial numbers in several places
9 Don't rely on the system date. Get the date of several files,
like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and compare them to
the system date. Require that the time be greater than the last
A Don't use literal strings that tell the user that their time is
expired. These are the first things to look for. Build strings
dynamically or use encryption.
B Flood the cracker with bogus calls and hard-coded strings. Decoys
C Don't use a validation function. Every time you validate the user,
write your validation code inline with the current process. That
just makes more cracking for the cracker.
D When using hard-coded keys or passwords, make them look like program
code or function calls (i.e., "73AF" or "GetWindowText"). This
actually works very well and confuses some decompilers.
E Finally, never reveal your best protection secrets :-)