On 30/05/2016 5:26 PM, Carsten Haitzler (The Rasterman) wrote:
<SNIP>
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%
JavaScript 2.3%
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
much myself.
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
JavaScript.
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.
IPv6:
* Multicast
* 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
local networks.
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.
<SNIP>
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...
Cheers,
Peter.
<SNIP>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
