[Dev] SDL support on Tizen
jini at zeus.net.au
Mon May 30 11:05:46 GMT 2016
On 30/05/2016 5:26 PM, Carsten Haitzler (The Rasterman) wrote:
>> Having the worlds most popular programming language running on Tizen makes a
>> lot of sense too (It's the language of Android). Tiobe index:
>> Java 21%
>> C 13.2%
>> C++ 6.7%
>> Swift 1.6%
>> Objective-C 1.6%
> I would happen to agree. Though you missed Python, C#, PHP. :) I think PHP is
> inappropriate for Tizen EXCEPT perhaps for making remote UI's that serve HTML5.
> Swift I just am not sure about and is too new. C, C++ and Java have been
> long-standing top-languages for the last 2 decades for just about as long as
> I've seen popularity comparison charts. Even if C were not popular, it's the
> lowest level "lingua franca" that just about every runtime, vm, language etc.
> relies on (be it just to build on or as the basic ABI), so it's a good base.
> Then offer API's in higher level languages so you can include as many
> programmers as possible. Personally me and Java have had... not so great
> interactions, but I'll definitely say that it's one of the long-standing
> popular languages out there.
> Objective-C seems to be rapidly on the way out thanks to swift and other forces.
> C# I'm just neutral on. I hear good things, but otherwise have no opinion other
> than it having been traditionally not accepted among open source circles for
> various reasons (some of them good).
> JS I'm neutral on too - but of my preferred languages for "dynamic quick and
> dirty development" It'd be in my top 2. Lua would be right up there just due to
> size and speed.
> Python is just incredibly popular especially among learners who are still
> getting started.
On that subject, I hear good things about F#, but haven't looked into it
>> Java and C are the only languages with market share in double digits, these
>> two together have more than one third of total developer market share.
>> The increase in Java last year alone (+4%) was almost twice the total for
>> Increasing available apps is more likely to occur if you double the number of
>> developers who can write programs for your platform.
> I would agree, though we need to do much more than that. We need to have a
> "WOW" factor for Tizen, and frankly... we have never had it. Something that
> makes people (developers, users, someone) go "WOW ... that's amazing. I WANT
> THAT". I can go on all day about things that would have the WOW factor...
> things i know by studying of market (developers at least) would make them go
> WOW and turn up, but this is not the time or thread for that. :)
Samsung's talking a lot about IoT, for some years I've contributed to a
project called Apache River, which was originally Sun Microsystems Jini,
one of the first IoT systems out there, it was ahead of it's time,
however it never really went mainstream, it's had some significant big
name deployments, what limited it?
What was good about Jini:
* Dynamic discovery
* Software as Services
* Service Registrar
What wasn't soo good:
* Security was implemented later and was compromised by the need to
maintain backward compatibility.
* The JVM changed, runtime namespace was wider than compile time
namespace, due to ClassLoaders.
* Network cards and OS's were often configured so that multicast
discovery needed some additional work to set up.
* IPv4 networking required configuration.
What stopped it:
* IPv4 NAT
* Firewalls blocking multicast
What I take from it, is dynamic network discovery enables things to be
discovered and work without requiring configuration.
* Auto configuration
* Global address space.
* No NAT.
The internet has become a publish subscriber model, a server on the
internet can only contact clients that have first contacted it. NAT has
resulted in the loss of the openness of the internet, or the abilities
of peer to peer networks to discover each other dynamically, except on
Today we rely on DNS and lookup names, to popular social networking or
cloud applications, placing our data in the hands of large corporations.
The other problem is walled gardens and locked down platforms, where we
place trust in a corporation to audit and check compliance, with little
in the way of transparency.
With IPv6 multicast and autoconfiguration, combined with dynamic
discovery opens the gate to placing the power back in the hands of the
owners of hardware, however as you mention below there remain security
issues and compatiblity issues with OS platforms.
Java almost got the sandbox right, but insecure deserialization has been
a fly in the ointment, but then there are also problems with
constraining resources, so DOS is quite easy for untrusted code, which
really means don't trust unknown code or input.
Perl taint mode was quite an innovation, ensuring the developer always
parsed and validated input.
>> The jvm and libs can be stripped down using compact profiles and jvms can
>> share class files to reduce start up time The jvm is 2x faster than Android,
>> although I believe startup can be slower for Java.
> TBH I think we need to stand back and re-think how we deal with the OS + apps.
> As time goes on, more and more apps bundle libraries, runtimes etc. into the
> apps. this just duplicates and creates a mess. Apps bloat out horribly in size.
> I think we should split things into 3 groups
> 1. Core OS.
> 2. Runtimes/middleware
> 3. Apps
> Runtimes would include the Tizen Web App Runtime. They would include Java if
> there. Each runtime would be versioned with a new install per version. Apps
> simply indicate which runtime and which version they want. Runtimes would be
> installed as package dependencies automatically (and uninstalled when zero apps
> reference them after removal).
> This would allow runtimes to be updated rapidly where the core os can only be
> slowly updated. It would allow new communities to turn up and support specific
> runtimes themselves. Enough people want Python - sure. add it to the runtime
> "store" and support it. This would by design de-duplicate all the installs
> inside every app. It'd keep memory footprint low as mmap()ing the same file for
> the same code, since it's shared, uses only one piece of memory rather than 2 or
> 3 or 4 apps shipping copies of the same code buried in their shipped-with-app
> runtimes using many peices multiplying the footprint and I/O needed to load
> the data into RAM. It'd keep Tizen efficient AND flexible.
> The only thing to really argue is how much should be in the runtimes. Can it
> include shared libraries? how will these override system ones (launcher can
> just set LD_LIBRARY_PATH for an app...). And security. Now apps depend on these
> middleware code blobs... how to ensure they are not compromised. Personally I'd
> take the view that any runtime or middleware MSUT be shipped as source. No
> binaries. It has to be auditable and compiled/packages by trusted servers, not
> the submitters. But that's a long discussion.
You're right this is a complex security / compatibilty problem.
I quite liked how Debian's apt packaging system resolved dependencies,
I also liked how Solaris Zones allowed you to isolate applications, so
you could make the OS and libraries read only, even if the root account
was compromised an attacker would be disappointed. I liked Solaris a
lot, at least until Oracle closed it, then I lost interest. There's an
interesting small project called DilOS, that combined the Illumos kernel
(Solaris) with GNU runtime and libraries and apt packaging.
Let's not forget static analysis and LLVM's intermediate representation.
A packaging system that uses an intermediate representation, static
analysis for validation (similar to Java bytecode verification) and JIT
runtime hotspot compiler and architecture independance.
But these are probably fantasies, IT history has shown many times it's
not the best that wins, it's usually one that can establish critical
market share and maintain it.
So if there was an open platform that used an IR package format, static
analysis for validation, automatic configuration and discovery and
searching of services provided by surrounding devices, with encryption
and autogeneration of identify certificates for users and devices, so
they could do things they cannot do now, on an open platform, without
walled gardens or loss of personal data, except to trusted peers without
a middle man, then people may consider...
More information about the Dev