Drafts/Tizen Dev

From Tizen Wiki
Jump to: navigation, search

Tizen Developer Friendliness

This is a draft document to collect proposals and development direction points with the goal of making Tizen friendlier to develop for or with.


Preface

Tizen is a Linux and Open Source platform to build devices with from small IoT devices all the way through Wearables, Mobiles, TVs, and more. In order to accomplish this it needs to provide a few basic aspects. It needs to be able to actually power such devices and build products. It needs to be friendly to the developers building such products. It needs to be friendly to 3rd party developers to improve and extend via applications. It needs to also be user friendly to the consumers who will ultimately use and buy such devices.

This document aims to address the continuum from Tizen being easy to USE to develop devices through to it being easy to develop FOR for 3rd party applications. This here is all about making Tizen nice to use, develop for and to use as a developer.

Please be aware that this document is not a final polished work, but is a place to collect experiences, ideas, problems and solutions. It's a working document to ensure ideas and experiences are not lost, but collected, refined and then ultimately acted upon.


Areas to Improve

Developer Devices

Either actual developer devices should be available for sale or existing devices should be able to convert to developer devices with a firmware change or special settings. Developers have enough to fight without also having unfriendly devices treating them as if they don't know anything and need protection from themselves.

SMACK

SMACK is all fine and well for containering untrusted applications you randomly download and install, but it gets in the way of developers. What we need is some kind of "super user" smack label that effectively turns off all smack checking, so it basically acts as sudo for the user. We likely want a "developer shell" of some sort that is run using this SMACK label. When you log in remotely (SDB etc.) the developer shell should be running under this label by default once developer debug options are turned on. Ultimately developer devices should offer for example a terminal emulator app that by default is run using this SMACK label too. The point is that developers should be able to debug and do their work without interference from SMACK, but untrusted software should be still sandboxed.

Root

Developers should have root access. Developers devices should offer an option that enables sudo access (sets a root password and/or a user password).

SSH + USBNet

SDB is a very poor shell on the best of days. Devices should bring back USB network gadget support and SSHD listening on all interfaces (so you can access your device via USB, Wifi or any other network interfaces). This should be enabled once Developer options are enabled. Any shell spawned by SSHD after a user login should run with the "SMACK super user" label just like SDB. Long-term we should actually migrate everything to SSH as it is encrypted, secure, has full authentication that is extremely solid, network tunneling and forwarding features, filesystem support via things like SSHFS and provides a sane terminal to work in.

Complete UNIX File Tools

Tizen has a very simplistic file utils set. It's even missing ping in some of the Tizen 3 images. Tizen should have a complete UNIX base toolset as well as all the networking commands (ifconfig, ip, iwconfig, etc.). Someone with a basic Debian, Arch, Gentoo, Fedora etc. install should not feel like they are missing anything in Tizen.

Extended Tools

Some extended tools like vim, htop, bash etc. should be installed by default just to give Tizen a decent core toolset without needing to install any extra packages. The small amount of space needed for such things is well worth the utility value.

System Package Extension

Tizen by default should come with a package manager that is able to fetch packages from on-line repositories as well as do system updates via such repositories and packages. Call it "apt" or "dfn" or "pacman" or "zypper" ... Tizen needs it. Any developer should be able to extend Tizen with more packages from 1 or more repositories with some very simply command-line tools. OS upgrades via the packager manager should not break. This should be tested and work

Decent Package Repositories

There should be a core well managed Tizen package repository which guarantees stability and security of packages. It should provide a wide range of common every-day tools for debugging and system maintenance and building. This package set would be managed by a restricted set of people. In addition to such a core high quality package set, additional community and individual package repositories should be provided and supported. These will have differing levels of quality, but enable much more value by providing yet more software to extend Tizen with. To make this easy to manage, tools should be provided to create such personal repositories or to upload packages to shared repositories like this. In addition tools to manage a database of available repositories and metadata should exist allowing people to easily discover and add repositories they need or want for their work.

Tizen Based Development

It should be possible to actually develop, debug AND run apps on Tizen itself. That means all the necessary tools for doing this should exist in the above repositories and should work. Eating your own dog food is essential to building a great platform.

Tizen Community Store

There should be a Community store that does not deal with money, but does offer an easier path to distribution for apps without very strict rules and guidelines. This should be considered as also providing a test-bed for application developers to share apps before they are really "ready" for the mass market. It should distribute TPKs just like the commercial app store does, but just with fewer rules and barriers.

Certificates

Developer devices should drop the need for certificates and signatures to massively drop the pain of dealing with such barriers for developers. This is nothing but a time-sink for developers. Regular consumers should still be protected.

Development Languages

Tizen ultimately should support many popular languages for development (not just C/C++ but also C#, Python, Javascript (Node.JS style), Lua, Rust, etc. etc.). This does not mean the SDK must support them perfectly from the beginning, but at least the raw tools and runtime should be there from the command-line up and over time the SDK and IDE tools can appear.

Rapid / Rolling Release

Reality is that it takes far too long to upgrade Tizen and/or get upgrades onto Devices. As a start at least, Tizen itself should have a rapid and/or rolling release model where the OS upgrades rapidly with new features at least for Developer devices. New unstable features should be showcased here, with feedback being rolled into a final features available to developers to deploy to all Tizen devices once the catch up.

API Transparency

There is a magic whitelist of API symbols and libraries they are allowed to be used from. This should be a public document clearly and widely publicized so people know what will and will not be accepted. This whitelist should also be far more generous allowing far more access to the Linux ecosystem of libraries and tools available, rather than being so restrictive ans it just creates work for developers.

Linux Re-centering

Tizen has tried to be too special. It isn't really "GNU/Linux" (a.k.a Linux) (though it's closest). It's not Android. It's not iOS. It's not Windows. It's time to re-center around Linux as it's what Tizen is closest to and can get the most value from. This means having less special stuff in Tizen. DeviceD likely should go and be replaced by SystemD, with various other controls moving off to their logical locations (most like backlight controls, rotation etc. should move into the compositor). Manifest files should continue to be supported, but supporting XDG/freedesktop standards for desktop files and extending such files with more fields needed for Tizen apps as well. Special libraries that only run on Tizen like Appcore should not be necessary for writing a Tizen app.