Archive for June 2014
The Samsung Z is set to hit Russia in the third quarter of the year. This phone is powered by the open source Tizen operating system. For those who didn’t know, Samsung has been quietly developing Tizen in the background for three years (Tizen already powers the Samsung Gear watches).
I firmly believe Samsung is testing the Tizen waters to see if the platform could be a viable alternative to Google’s Android OS. If any company could pull off such a feat… it would be Samsung. But beyond the implications Tizen has to Android (the most used platform worldwide), what does this mean for the near vaporware status Ubuntu Phone?
Plenty.
While the Ubuntu Phone is still struggling to gain any serious momentum — anywhere — Samsung has already set a date for its open-source device. The latest worthwhile news from the Ubuntu Phone camp was March 19, 2014, stating that “big smartphone brands [are] looking ‘seriously’ at Ubuntu Phone.” Prior to that, the big news was that Spanish-based BQ and China-based Meizu announced they were set to release Ubuntu Phone devices “sometime in 2014.”
2014 is officially half over.
That silence is fairly damning in a world that demands a constant deluge of updates — especially when a powerhouse such as Samsung announces they are set to release the first, mass-produced, open source, Linux-based smartphone. Samsung beat Canonical to the punch, and if the Samsung Z does well in Russia, it’ll be released to the rest of the world. Should that happen, the likelihood of the Ubuntu Phone having a chance, in an already saturated market, is unlikely.
Think about it this way. The IDC reports:
- Android powers nearly 80% of the world’s mobile devices
- iOS powers just over 15% of the world’s mobile devices
- Windows phone powers just over 3% of the world’s mobile devices
- BlackBerry powers just under 2% of the world’s mobile devices
There is a scant 1% left over for “Other.”
Because Samsung already has such a strong presence in the Android market, and because their devices are found everywhere, they could chip away (even slightly) at both the Android and “Other” markets. The Ubuntu Phone will most likely be relegated to the “Other” market. That’s not much to pull from. Those low numbers will make it a huge challenge for Canonical and the Ubuntu Phone. To make matters worse, the longer it takes for the Ubuntu Phone to make its way to market, the smaller that user base will be. That’s the crux of the issue — time. Canonical announced its intention to create a Ubuntu Phone some time ago. Since then, it’s been nothing but promises and a failed fundraiser for Ubuntu Edge.
The tragedy of this is that the Ubuntu Phone could well be one of the finest mobile devices to date. But because Samsung is going to likely beat Canonical to the punch, that brilliant piece of tech might flounder… simply because it couldn’t get into the fight soon enough. And now, with Samsung delivering their own open-source smartphone, the chances they would join in on the Ubuntu Phone fun are pretty much nil.
Don’t get me wrong, I would love to see the Ubuntu Phone released and enjoy a massive success. I would personally drop my current device, without hesitation, for an Ubuntu Phone — but I don’t see that happening any time soon. In fact, the likelihood that I could get my hands on a Tizen-based phone seems exponentially greater than the Ubuntu Phone.
Canonical needs to understand that timing is everything in this light-speed paced world in which we live. You cannot announce a product one year and deliver it the next. By the time you release, everyone has already moved on to the next great shiny thing. At the moment, that shiny thing might be the Samsung Z.
At least for Russia.
Will the Samsung Z have a chance in a market that’s choked by two major players (Android and iOS)? Or is it already doomed before it hits the market? And does Samsung’s release of the Tizen-based phone sound a death knell for the Ubuntu Phone? Share your thoughts in the discussion thread below.
 |
Lina Deveikyte |
- In: Apple | Microsoft
- 6 Comments
For years Microsoft has been the de facto desktop operating system. Now Apple is using its mobile devices to steal market and mindshare.
Pundits have long expected Apple to integrate its desktop and mobile operating systems; however, recent announcements at Apple’s Worldwide Developers Conference (WWDC) show that the company is doing far more than borrowing user interface elements. After some tentative starts, Apple has embarked on a full-scale integration between the company’s phone and desktop devices. With new releases of the software powering each, your laptop will soon be answering phone calls, and your phone will share text messages with your desktop, allowing you to fire off a missive from your MacBook to a colleague’s Android smartphone using standard text messaging. While not totally unexpected, the depth of integration is fairly impressive, and doubly so since I couldn’t help wondering during the announcements: why hadn’t Microsoft done this?
A constantly unfinished puzzle
By nearly any metric, Microsoft was years ahead of Apple in the smartphone and tablet space. While Apple was restructuring a fractured business and “playing” with handheld devices in the form of the Newton, Microsoft had produced several generations of its own PDA, and eventually a full-fledged smartphone that was feature rich, but failed to build a compelling user interface around its advanced feature set. Over half a decade before the iPhone launched, a lifetime in mobile technology, Microsoft was introducing tablets, only to be wiped off the face of the map by the iPad. Microsoft’s most obvious advantage in the mobile space was its dominance of the desktop.
If anyone built a mobile device that integrated tightly with the desktop, it should have been Microsoft.
Technology versus usability
While Microsoft may have missed a historic opportunity, more recently the company has been touting its merging of significant portions of its mobile and desktop code. Even user interface elements have begun to cross-pollinate, with the “modern” user interface that first appeared in Windows Phone featuring prominently on desktops and tablets. However, this technical integration is indicative of Microsoft’s larger problem.
As a company, Microsoft’s Achilles’ heel has been an inability to fully integrate different elements of its computing empire, and to present a user experience tailored to the task at hand, not pounded into a contrived, pre-existing Windows metaphor. From the Start button and stylus on a mobile phone, to its most recent technical integration of its environments that completely lacks in end-user benefit, Microsoft is missing the boat on developing a holistic computing experience. Frankly, I don’t care if my desktop and smartphone are running completely incompatible code from totally different vendors, as long as they’ll share information and work seamlessly together.
The Switzerland of computing?
While Microsoft may have missed this opportunity for its own devices, it still represents a key player in the overall computing landscape, and the long-predicted “demise of Windows” is likely several years away, if it occurs at all. An integrated experience between Microsoft smartphones and Windows desktops won’t meet with much excitement, primarily due to the limited market penetration of Windows phones. What would be interesting, however, is if Microsoft were to use its desktop dominance to integrate tightly with devices from Apple, Google, and others.
Such integration might seem far-fetched, but Microsoft already does this to an extent, with its Exchange server happily sharing mail, contacts, and calendars between everything from phones and tablets to laptops and web apps. Microsoft also has decades of experience integrating diverse hardware, and producing operating systems that run well on millions of combinations of hardware is no small feat. Just as Apple’s original iPod hit its stride when the company made it available for PCs, Microsoft could accelerate its cloud services and desktop OS, and ultimately make a compelling case for Windows Phone by providing tight integration with several mobile vendors.
In the mid and long terms, “winning” the mobility wars is not going to be about who sells the most devices, especially as computing transitions away from single devices and into a multi-platform, multi-device world. Microsoft has a chance to regain lost ground by tightly integrating its desktop and cloud services with today’s devices, allowing it to define tomorrow’s computing experience.
 |
Kristina Kozlova |
What to expect with Android 4.4.3
Posted on: June 9, 2014
For many Android owners, the 4.4.3 update has yet to hit (though it is slowly rolling out — when you will receive the update will depend upon your carrier and device). Although the new feature list isn’t epic in length, what it brings to the table will have a lot of users happy… quite happy, actually. This is especially so for users who frequently snap photos with their device and/or record audio.
Aesthetics get little in the way of an upgrade. There is a slight tweak to the Dialer app, but that’s the only change to the UI you’ll readily notice.
The short list of major changes looks something like this:
- A tweaked Dialer app with a colored Action bar (this is the UI change)
- Contact app (sometimes called People) uses placeholder images, similar to those used by Gmail
- Fixed hissing sound while recording videos (Nexus 5) is fixed
- Fix for LTE connection dropping bug
- Wi-Fi improvements
- Microphone and earphone related changes
There are also a lot of other under-the-hood camera, Bluetooth, and other system-related bug fixes.
The cameras (especially those on Motorola devices) will see numerous improvements. Exposure consistency and flash coloring are dramatically improved. A big change for photo enthusiasts is better low-light handling for the front camera.
Speaking of Motorola devices, Moto X and Moto G owners will find a new app called Motorola Alert. This app will send out periodic messages to select contacts.
Probably the biggest upside to this update is the improvements to security, overall stability, and power profile features. One major update is an optimization to ZRAM support. This allows idle background apps to store data in a compressed RAM partition to free up RAM for applications. There’s also a low-RAM API that improves performance on devices with as little as 512 MB of RAM (by using more aggressive memory management). Finally, an experimental Java runtime (called ART) improves application performance over the current Dalvik runtime.
On the downside, at least for Nexus 5 owners, the mm-qcamera-daemon bug (this is a bug that caused the camera to quickly drain the device battery) has not been fixed. The update also does not fix the LED Notification for missed calls (which has been plaguing many devices for some time now).
Android 4.4.3 is primarily a continuation of bug fixing for KitKat. However, don’t let the lack of UI changes fool you… the 4.4.3 update will go a long way to improve the performance and stability of your device. So, when can you expect the rollout to your device?
- GPE versions of the HTC One M7, Galaxy S4, HTC One M8, and the Sony Z Ultra should already have the update
- Sprint users with Nexus 5 devices should be seeing the update soon
- All other devices should see the update in the coming weeks
As with any Android update, predicting when a device will receive the new software is like predicting the weather — it’s hit and miss (and most often wrong). Every supported device should have the update available in the coming weeks. I can tell you that, as of this writing, Verizon HTC and Motorola devices, as well as AT&T Motorola devices, do not have the update available.
Have you received your 4.4.3 update? If so, has your Android device performance and reliability improved? What would you like to see in upcoming Android updates? Share your ideas in the discussion thread below.
|
Lina Deveikyte |
- In: .NET | IT Start Up | IT Trends | Microsoft
- 4 Comments
Over the years dynamic languages such as Python and Ruby have become cherished by startups. As for .Net it is more rarely heard to be used by startups. That’s interesting indeed, because this platform is definitely bigger than most of the popular ones.
So I wonder why a platform as widely adopted and supported as .NET isn’t more visible in startup culture. Let’s try figuring out the main arguments in favor and against making .Net a startup technical choice.
1. Community culture
Some people say the main reason is the culture of the .NET community itself, not anything specific to the platform. Being centered mostly around the needs of enterprise market .NET developers’ concerns are often regarding supporting legacy systems, building enterprise architectures, large systems for supporting business processes. This implies solving problems which are not so relevant for startups at least at their initial point.
As for members of the startup community, they fuss over different issues – concurrency, experience design, supporting multiple clients and browsers, etc.
As a result the startup community and the .NET community don’t overlap as much as they do for other technologies. That’s why startup founders don’t get much exposure to .Net and don’t think of it as an applicable tool for their purposes. The same way many .Net developers who want to work for hot startups don’t have as many opportunities to do so unless they abandon the platform for a more startup-friendly one or start a company themselves.
So platform doesn’t always dictate its use – that’s people who make the choice. Enterprise and startups aren’t mutually exclusive – they’re just different stages in the evolution of software, and there’s no reason why the startup community shouldn’t look at .NET as an attractive starting point for a new business.
2. Startup tech compatibility
A startup is a risky venture with no guarantee of success. So tech startups seek advantages in order to succeed. Hence startups take what big enterprises consider risky bets on technology. This objective can be achieved by using technology that is popular in startup environment.
Many features of .NET, facilitating the productivity of big companies, are not always useful to startups. There is too much choice of implementation methods. If anything, web startups are looking to have this choice taken away – their technology choices come from the subset that is built for the web.
Also it is said that innovation is quicker with other ecosystems which have a bigger set of libraries and tools. As for .Net there are a few open source projects however most of them are pretty much an implementation of concepts that have already been implemented for a while in the Java world, for example.
3. Open source vs proprietary
Although many startups don’t mind paying for tools and services, most of them still pick things based on cost. For a long time the “enterprise” level tools, services, databases, etc were hardly affordable by startups. That’s why startups adopt so much open source.
It’s also hard to justify the use of proprietary software from a business perspective. If you want to be acquired it is wise to develop your product using an open stack rather than Microsoft’s.
However luckily for many startups Microsoft saw a huge value in giving their stuff away to startups and startups have benefited greatly. Microsoft has been running their Bizspark program for several years, which eliminates most of the startup costs normally associated with employing a .NET framework. To get into the BizSpark program you just need to get checked by BizSpark team if your startup is eligible (developing a real product). Then you’ll get free licenses to basically every product they make, including SQL Server, and a free MSDN gold subscription, for 3 years. They figure 3 years is long enough for you to get going so after that they want you to pay for new licenses. The great part is that they let you keep the licenses you’re already using. So Microsoft has basically taken the cost factor completely out of the equation for new startups.
4. Velocity vs performance
Some people say that it’s all about the velocity. If you agree with an assumption that a startup goal is to find a niche vs build a product, then the goal of a startup is to learn about the market, customers, and product needs as quickly as possible. Python, Js, Ruby, etc allow you to iterate quickly without a lot of infrastructure and boilerplate. However a company that has already has a market has a little different goal, for them the objective is to build a stable product that they can maintain.
Some people say that .Net is not suitable for quick changes. This is a pretty outdated view of C# these days, it’s actually fairly easy to write extremely terse code with. As an added bonus refactoring is so incredibly easy compared to JS, Ruby, Python, etc. that it’s ideal for rapidly switching directions in code as you can refactor so fearlessly without being slowed down by massive amounts of tests. Unfortunately what’s bad about .Net is the tooling and the supporting ecosystem.
Python is much better suited to quick prototypes that can be fleshed out into a reasonably reliable product without too many headaches. The key difference comes when you have to change features mid-stream. The lack of strict typing and interfaces means you can add, change, and remove features much quicker than C# for example. On top of that, you just write fewer actual lines of code to get the same thing done, although sometimes readability can suffer if you get too concise. There is a price to be paid with Python and Ruby though and performance is the biggest one.
5. Team and project size
The team and project size always matters. So when the solution is being built with a small team, then it is easier to use something like Python. Obviously the goal is to be fast to develop in and have a bunch of libraries to be used. On the other hand when building something with a big team, you feel like using something like C#. In this case it keeps it safe to develop in and easy to catch mistakes. Any optional documentation provided by a developer is incomplete. On the contrary the quality level of the available .Net documentation is outstanding.
However if the company is starting as very small at the initial point, it hopefully grows and builds up quite a sizeable codebase by some point. Python, JS & Ruby are fine for small programs but anything more than that and they become their own enemies because the programs they make are quite brittle.
6. Scalability
The common opinion is that .Net scales well.So, if your startup does make it, you’ll probably have a much easier time scaling the .Net stack than you would with say Ruby or PHP.
Conclusion: it’s all about stereotyping
Eventually, I found different opinions on my question of .Net being not so popular with startups such as “platform lock-in,” “no open standards,” “licensing costs.” Sure, these are issues preventing many developers from adopting .NET in the startup space, but not enough to bar all of them from using it. Most of the arguments are just stereotypes that can be dispelled under closer examination.
All languages have strengths and weaknesses. For a startup, you need to do due-diligence and research what the right language to use for your idea will be because recoding in a different language can get costly.
So do you use .Net in your startup projects? Please share your feedback and experiences with us.
 |
Aliona Kavalevich |
