------- Original Message -------
Sender : huanhuan zhu<[email protected]> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics
Date : Jun 03, 2016 11:54 (GMT+08:00)
Title : Re: ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))
------- Original Message -------
Sender : huanhuan zhu<[email protected]> Senior Engineer/SRC-Nanjing-Advanced 2 Lab/Samsung Electronics
Date : Jun 03, 2016 11:41 (GMT+08:00)
Title : Re: Dev Digest, Vol 33, Issue 19
Hi All
This is Zhu huanhuan who worked NDK project in TV before.
Let me give my personal opinion,
A. Why we need NDK ?
It is not used for application development directly, it is used for game engine porting their module over Tizen.
So we do not need to care about UI/FW or language, 3rd developers do not care.
B. Why NDK need SDL ?
1. Not exactly, we can also refer Android to supply Surface and EGL init & OpenGLES call directly ( I think it is also good)
C. Analysis SDL.
1. SDL similar as windows application, application side hold main-loop itself.
SDL does not care how to integrate platform's appframework who is incharge of lifecycle management.
For example all application in windows need a X button and close itself. TaskManager just do kill one process works.
main() is the entrance of application directly.
2. Android / Tizen which has internal glib's g_main_loop to handle the main-loop.
The AppManager want to handle to launch and terminate works by OS directly and front-ground/back-ground case.
So application need register render callback based main-loop and app manager is handled in OnXXX callback.
For android case, it use one thread to handle lifecycle and render.
For EFL case, it is same but it has a problem of integrate EGL inside.(which is a issue I will talk latter)
For Dali case, it divides two thread for lifecycle and render , which I think is a waster of performance.
So SDL has issue now in Tizen.
1. How to integrate to AppFW if main-loop conflict exist.
Let's see how android do for SDL, it create similar structure as dali, event thread(main thread) for applifecycle and inputs, render thread for SDL to handle SDL main-loop. So two thread is needed ( Somehow a waste) One is for Ecore, another is for SDL main
Is there other solution ?
Yes, we can refer Android NDK case directly, but issue exist that evasGL is conflict pure EGL
that we can not use EFL window, so it will be look like that:
Ecore+ EcoreX/EcoreWayland window create
Get surface and pass to user,
User do EGL init and call OpenGLES api directly
Handle inputs from XInput or Wayland inputs.
BR
Zhu huanhuan
------- Original Message -------
Sender : [email protected]<[email protected]>
Date : May 30, 2016 20:00 (GMT+08:00)
Title : Dev Digest, Vol 33, Issue 19
Send Dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.tizen.org/listinfo/dev
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dev digest..."
Today's Topics:
1. Re: ??SDL?support?on?Tizen (Carsten Haitzler (The Rasterman))
2. Re: ??SDL?support?on?Tizen (Peter)
----------------------------------------------------------------------
Message: 1
Date: Mon, 30 May 2016 16:26:37 +0900
From: Carsten Haitzler (The Rasterman)
To: Peter
Cc: "[email protected]"
Subject: Re: [Dev] ??SDL?support?on?Tizen
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On Mon, 30 May 2016 16:41:41 +1000 (AEST) Peter
> ?
> Thanks Carsten,
>
> Yes java jni code generation. ?Thanks for the references this helps a lot.
:) On the same page then.
> It's a shame Eolian use doesn't extend to Tizen api's, perhaps Samsung may
> reconsider??
I have suggested it many times. Evenm if all it was was a simple eo wrapper
on top of existing native API's, then we'd get "binding auto generation" for
free. The more languages eolian supports, tyhen the more languages come "fore
free". (someone has to run the generator to generate bindings - EFL runs it
just as part of "make", tizen native API's could do whatever they wanted as
long as it is run).
> Samsung: Automation trumps manual editing every time, the parser and
Absolutely. That is the premise behind doing auto-generation. We have done
manual bindings many times for EFL. The Python bindings are still manually
maintained and they are always behind the C API and lacking features. It's
manual effort. It's boring work. It's painful. It's error-prone.
Auto-generation takes longer to get right (we've been working on this for a
while to get it right and to get it to fit multiple targets), but in the long
run it saves much more time. Slow to start, fast to finish. The big plus is
indeed "no maintenance". If the generator has a bug, it gets fixed there once
for all languages and API's, so at worst the maintenance is this.
> generators will end up being thoroughly tested in the long run, significantly
> reducing bugs and saving many wasted development hours that could be spent on
> more important work. ?
Yup. Bingo.
> 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.
> 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. :)
> It would make it a lot easier for developers to create native ports of
> Android apps, provided the presentation and application layers are cleanly
> separated.
Agreed.
> Most recent UI's can be defined using xml, including Android, JavaFX and
> Apache Pivot, among many others, which does make me wonder if generators can
> be written to transform these into enlightenment ui components for simple
> applications, the parsers already exist and are open? ?Far superior to
> android emulation.
Possibly.
> 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.
> JOGL supports both Jvm and Android platforms for 3D cross platform
> compatibility.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
> ?
> ??Include original message
> ---- Original message ----
> From: Carsten Haitzler
> Sent: 30/05/2016 10:58:08 am
> To: Peter
> Cc: [email protected]
> Subject: Re: [Dev] ??SDL?support?on?Tizen
>
> On?Sun,?29?May?2016?14:08:57?+1000?Peter?
>
> >?Thanks?Carsten,
> >?
> >?Where's?the?best?place?to?start?looking?to?learn?about?Eolian???I've?
> >?done?an?initial?web?search?which?turned?up?some?presentations.
> >?
> >?Is?Eolian?specific?to?Enlightenment,?or?are?there?plans?for?Samsung?to?
> >?use?it?for?other?Tizen?api's?as?well?
>
> eolian?is?specific?to?efl?indeed.?we?wrote?it?specifically?for?the?object?model
> we?created?and?for?the?purpose?of?making?bindings?directly?from?source.
> consider?this?like?gobject?but?with?a?very?different?take?on?how?to?do?a
> generic?object?model?in?c.?eo?(the?object?model)?and?elian?were?built?from?the
> get-go?to:
>
> 1.?be?able?to?back?our?existing?code?and?so?it?requires?specific?and?special
> solutions
> 2.?to?be?able?to?act?as?a?"language?neutral"?IDL?system?to?define?APIs?that
> appear?in?C?but?also?then?map?directly?to?other?languages?-?be?they?statically
> typed?or?dynamically?typed,?explicitly?memory?managed?or?GC'd?like?C+
> +,?JS,?Lua so?far.
> 3.?save?us?work?in?C?by?writing?and?maintaining?boilerplate?C?code?for?us.
>
> this?is?old?and?eo?syntax?has?changed?since?but?it?gives?a?bit?of?a?general
> intro:
>
> https://phab.enlightenment.org/phame/post/view/75/yet_another_c_object_model_-_but_better/
>
> we?don't?have?the?eo_do()?construct?anymore,?but?eo_add()?can?do?the?same?by
> calling?methods?to?setup?up?an?object?at?construction?time,?so?objects?have
> finalizers?to?call?after?these?setup?methods?are?called.?it's?meant?to?be?a?way
> to?optimize?objects?by?deferring?as?much?work?f?object?creation?as?possible
> until?the?finalize?when?we?know?the?initial?state.
>
> if?you?find?all?the?*.eo?files?in?efl?you'll?see?how?it?works?soon?enough:
>
> ??git?clone?https://git.enlightenment.org/core/efl.git
> ??cd?efl
> ??find?.?-name?'*.eo'?-print
>
> those?eo?files.?from?those?eo?files?C?core/boilerplate?is?generated,?and?then
> the?actual?implementation?code?is?filled?in.?from?those?eo?files?also?the?c++
> *.hh?files?that?are?the?bindings?are?generated?as?well?as?the?lua?files?(we
> targetted?luajit?making?use?of?ffi?to?bind),?and?if?you?--enable?it,?the?js
> bindings?(c++?v8/node.js?code).
>
> for?java?i?assume?you'd?want?to?generate?possibly?java?code?that?uses?jni?to
> call?the?original?c.?someone?has?to?write?the?eolian_java?generator,?but?there
> is?a?libeolian?that?does?all?the?.eo?file?parsing?and?manages?an?in-memory?db
> of?everything?to?make?it?easy.
>
> no?-?the?rest?of?tizen?doesn't?use?this.?to?date?there?has?been?no?interest.
> they?seem?to?prefer?to?do?things?by?hand.
>
> >?The?JOGL?library?uses?Gluegen?to?generate?it's?java?bindings.??JOGL?has?
> >?a?number?of?different?back?ends,?I?haven't?quite?got?my?head?around?how?
> >?to?create?a?back?end?based?on?enlightenment?yet,?it?did?seem?like?a?
> >?difficult?task.??I?looked?at?some?of?the?gl?application?examples?for?
> >?Tizen?developers?in?Samsung's?sample?programs,?but?decided?to?focus?on?
> >?creating?java?bindings?for?the?Tizen?api's?first.
>
> hmm?ok?-?so?it's?generated.?the?evas_gl?stuff?is?plain?c?functions?just?as
> function?pointers?in?a?struct.?the?eo/eolian?stuff?doesn't?cover?it.?doe?to?its
> nature?it'd?have?to?be?manually?bound.
>
> >?I'm?glad?Enlightenment?isn't?written?in?C++.
>
> at?least?there?are?a?few?of?you.?:)
>
> >?Regards,
> >?
> >?Peter.
> >?
> >?On?28/05/2016?11:01?AM,?Carsten?Haitzler?(The?Rasterman)?wrote:
> >?>?On?Sat,?28?May?2016?10:20:53?+1000?(AEST)?Peter
> >?>
> >?>>?I?started?writing?java?bindings?for?Tizen?(on?github).??I?was?impressed?by
> >?>>?the?object?orientated?nature?of?Enlightenment?and?how?easy?it?is?to?hand
> >?>>?craft?java?bindings?for,?following?the?inheritance?hierarchy.??Tools?that
> >?>>?generate?bindings?don't?do?so?well.
> >?>?orly??everyone?keeps?going?"efl?is?not?oo!?make?it?oo!?(rewrite?in?c++?is
> >?>?what?they?mean)".?i?keep?saying?oo?is?a?concept?independent?of?language.
> >?>?efl?does?do?things?relatively?oo-ish.?it?could?be?improved?(and?thats?what
> >?>?all?the?eo?infra?is?for?-?now?it?looks?REALLY?oo?with?a?single?function?for
> >?>?del/unref?of?every?single?object?and?direct?strict
> >?>?inheritance/milti-inheritance?and?more).
> >?>
> >?>?fyi?-?eolian?should?actually?make?it?far?easier?to?generate?bindings.?we
> >?>?already?auto?generate?bindings?for?lua,?js?and?c++?directly?from?the
> >?>?original?.eo?files?for?efl?api.?the?.eo?files?are?written?at?a?high?level
> >?>?abstraction?and?eolian?generates/maintains?the?c?boilerplate?and?there?are
> >?>?various?binding?generators?per?one?of?the?above?languages.?writing?a
> >?>?generator?for?java?shouldn't?be?too?hard?considering?all?of?the?other
> >?>?languages?we?are?already?handling.?this?means?the?core?of?efl?remains?c?and
> >?>?there?is?a?core?c?api?with?the?bindings?sitting?directly?1:1?on?top?of?this
> >?>?handling?reference?counting?and?more.?considering?the?constraints?of?things
> >?>?like?js?and?lua?i?think?java?should?be?easy.?once?you?have?a?generator?then
> >?>?maintenance?is?over.?it's?not?just?re-running?it?to?pull?out?more?api's
> >?>?into?java?whenever?the?libraries?update?and?add?classes?and?methods.?we
> >?>?already?run?the?js,?lua?and?c+
> >?>?+?generators?every?time?efl?builds?as?part?of?the?efl?makefiles.
> >?>
> >?>>?JOGL?and?JOAL?bindings?already?exist,?but?I?can't?get?access?to?a?native
> >?>>?window?on?which?to?draw.
> >?>?as?below?-?you?will?have?to?re-bind?and?make?jogl?etc.?compatible?api?on
> >?>?top?of?elm_glview?etc.?it?wouldn't?be?hard?at?all.
> >?>
> >?>>?What?I'd?like?is?a?standard?way?to?get?a?window?(full?screen)?on?which?to
> >?>>?draw?using?opengles.???Events?can?be?used?to?gracefully?get?out?of?the?way,
> >?>>?suspend?etc.??I?need?some?kind?of?compatibility?layer?between?JoGL?and
> >?>>?enlightenment?to?make?it?work.
> >?>?technically?with?is?possible,?but?it?looks?more?like:
> >?>
> >?>?create?window?(elm_win),?put?elm_glview?in?win,?show?it,?show?win.?done.?now
> >?>?your?window?is?filled?with?a?glview.?there?are?associated?properties?of?the
> >?>?glview.
> >?>
> >?>?it's?actually?FAR?LESS?code?than?using?egl/glx+native?xlib?or?wayland?for
> >?>?example?(as?i've?been?doing?this?stuff?for?a?long?time...?to?do?this?RIGHT
> >?>?takes?a?fair?bit?of?code?like?getting?visual?and?colormap?right?in?x11).
> >?>?far?far?less.
> >?>
> >?>?the?glview?can?allow?you?to?use?gles2/3?or?1.1?api?on?it?(there?is?a
> >?>?complete?gles?set?of?api's?in?the?evas_gl?api?struct).?did?you?look?at?the
> >?>?glview?examples?in?elementary_test??if?you?enable?direct?rendering?fyi?...
> >?>?you?get?zero?overhead?support?-?no?extra?copies.?the?api?funcs?are?almost
> >?>?all?just?direct?pass?down?except?a?few?like?scissor?stuff?etc.?-?there?is
> >?>?even?a?helper?header?that?removed?the?need?for?glapi->func()?and?allows
> >?>?just?the?old?func
> >()?via?macros?assuming?a?local?var?for?the?api?struct?etc. >
> >?>?but?either?way?for?some?java?bindings?this?should?do?the?work.
> >?>
> >?>>?A?headless?jvm?works,?2d?and?widgets?will,?but?3D?I?haven't?figured?out.
> >?>>
> >?>>?Regards,
> >?>>
> >?>>?Peter.
> >?>>
> >?>>?Sent?from?my?Samsung?device.
> >?>>???
> >?>>????Include?original?message
> >?>>
> >?
>
>
> --?
> Carsten?Haitzler?(The?Rasterman)?
>
>
--
Carsten Haitzler (The Rasterman)
------------------------------
Message: 2
Date: Mon, 30 May 2016 21:05:46 +1000
From: Peter
To: "Carsten Haitzler (The Rasterman)"
Cc: "[email protected]"
Subject: Re: [Dev] ??SDL?support?on?Tizen
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
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%
>> _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.
>
>> 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.
------------------------------
Subject: Digest Footer
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
------------------------------
End of Dev Digest, Vol 33, Issue 19
***********************************
|
|
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
