KDE werkt aan Android-runtime voor 'normale' Linuxdesktopsystemen

De KDE-gemeenschap heeft zondag tijdens de jaarlijkse Akademy-ontwikkelaarsbijeenkomst een Android-runtime aangekondigd voor reguliere Linux-systemen. Met de runtime moeten op termijn apps voor Googles mobiele besturingssysteem ook makkelijker op andere apparaten draaien.

De KDE-ontwikkelaars kondigden de runtime voor 'normale' Linux-systemen - Shashlik - zondag aan in het Spaanse A Coruña. Volgens één van de developers, de in Nijmegen woonachtige Sebastian Kügler, moet de runtime ervoor zorgen dat Android-apps eenvoudiger op Plasma Desktop en het recent geïntroduceerde Plasma Mobile draaien.

Volgens de KDE-ontwikkelaars zijn Linuxdistributies voor de desktop en Android onder de motorkap verschillend. Ze maken weliswaar gebruik van dezelfde kernel, maar de softwarelagen daarboven werken op een andere manier. Het gevolg daarvan is dat specifieke Android-software niet zo makkelijk te porten is naar andere Linux-systemen.

"Het idee is dat je de Shashlik-runtime installeert en dan allerlei voor Android geschreven apps op je computer of smartphone kunt draaien", zo laat Kügler desgevraagd aan Tweakers weten. De KDE-runtime werkt volgens hem anders dan die van concurrenten. "Shashlik is volledig vrije software - en dat is nieuw. De runtimes voor BlackBerry- en Jolla-smartphones zijn niet vrij, wat het bereik naar gebruikers toe beperkt."

Shashlik is nog volop in ontwikkeling. Volgens Kügler werken bepaalde zaken al, maar is de runtime nog niet gebruiksklaar. "We verwachten dat we de komende weken de eerste apps kunnen presenteren die op Shashlik draaien. Een groot probleem was de integratie van SurfaceFlinger met Wayland. De grafische stacks verschillen nogal, dus hier was een integratielaag voor nodig."

De ontwikkeling van Shashlik kan grote gevolgen hebben voor toekomstige apparaten die draaien op een Linuxkernel, waar tegenwoordig ook smartwatches en televisies onder vallen. De runtime leidt er in ieder geval toe dat er Android-apps naar het zaterdag gepresenteerde Plasma Phone OS, met de Plasma Mobile-gui, komen. Zo is het besturingssysteem niet alleen meer gestoeld op native apps, waarvoor veel mankracht nodig is. Kügler: "Dit lost het kip-ei-probleem op."

Reacties (37)

Weer iets wat redelijk nutteloos lijkt... want je kunt nu al op normale linux desktopsystemen gewoon APK's draaien (zonder emulatie dus). Het klopt dat ik niet weet hoe open het is, maar het is gewoon gratis en van Google. Zelfs als je niet de developer van de app bent kun je dat met een tool zoals deze doen:

https://github.com/vladikoff/chromeos-apk (ondanks de naam werkt dat gewoon op alles tegenwoordig) of https://play.google.com/s...pear.archonpackager&hl=en

en je kunt in de Chrome Webstore gewoon pure android apps vinden ook. En de chrome android runtime is gewoon door Google zelf gemaakt, het enige wat een tool zoals die doet is een apk wrappen in een Chrome App zodat het die runtime kan gebruiken. En performance wise is het zelfs bruikbaar op een ChromeOS laptopje (allemaal low-end machines en ik gebruikte het om Android versie van Skype te draaien voordat ze met de web versie uit kwamen)

Check deze reddit trouwens voor veel meer informatie: https://www.reddit.com/r/chromeapks en hier heb je een lijst van apk's die je nu kunt draaien: https://docs.google.com/s...XyrYiyo8/edit?pli=1#gid=0 (al heb ik sommige werkend gekregen die blijkbaar niet zouden werken~ maar goed, dat terzijde).

In ieder geval, kan niet zeggen dat ik hier super enthousiast van word. Niet dat het niet nuttig is, maar had liever gezien dat KDE die energie in nieuwe dingen zou hebben geïnvesteerd. Dingen die nu nog niet kunnen. En voor Plasma mobile is het sowieso niet erg nuttig, want ze willen daar Ubuntu Touch, Android en native apps op draaien... je kunt vast voorspellen wat voor een UX dat gaat worden .

[Reactie gewijzigd door David Mulder op 26 juli 2015 19:15]

Een APK draait niet zomaar in linux. Daarvoor is Android te specifiek opgebouwd. Ga je via chrome (of chromeos) dan ben je nog altijd afhankelijk van Google. Het doel van dit project is net om een runtime te bouwen die NIET van Google komt en die dus door iedereen vrij bruikbaar is zonder ergens aan vast te hangen.

Deze runtime is in de eerste plaats ontwikkeld om samen te gaan met plasma-mobile, maar niets zal andere mensen tegen houden om dit te gebruiken op een desktop PC of om het mee te integreren in andere linux distributies.

Die lijst van apps die zouden moeten werken met ARCHon is trouwens enorm beperkt. Er staan 300 apps op waarvan men weet dat ze werken. Enig idee hoeveel apps er zijn voor Android?

En niet nuttig voor Plasma-mobile? Heb je de tekst goed gelezen? Op deze manier willen ze net het kip-ei probleem oplossen waar velen vandaag mee zitten. Kom je als nieuwe speler op de markt staat iedereen maar te roepen dat er geen apps zijn. Als deze runtime goed werkt dan krijgen alle nieuwe spelers in de toekomst als zij dat willen een eenvoudige manier om de grootste bibliotheek aan apps toe te voegen aan hun systeem.

En denk je dat alle apps blind zullen werken met deze runtime? Sowieso is het logisch dat op een desktop systeem mobiel specifieke functies niet werken. En gezien Google's runtime tenminste beperkte support kan bieden voor Google Play services zal Google's runtime sowieso meer apps supporten dan KDE's runtime. Daarnaast kun je gewoon iedere app dus uitproberen, die lijst is gewoon van wat mensen hebben uitgeprobeerd (vooral toen het in het begin nog met de hand moest worden gewrapped i.p.v. dat het een zaak van 'hier heb je een apk en klaar' was).

En trouwens, waar zou je praktisch aan vast hangen door Google's runtime te gebruiken? Dat je Chrome op je OS moet installeren? Ja, je sterft echt van die paar extra megabyte op je systeem als je het verder niet wilt gebruiken. Ik bedoel, laat duidelijk zijn dat ik liever ook zie dat ze het afsplitsen van Chrome en die runtime ook gewoon los release'en (al snap ik volledig dat dat nu niet zo is gegaan omdat het team wat hier aan werkte het deed vanuit het perspectief van ChromeOS) en Google kennende zou het me niks verbazen als ze dat ook nog zullen doen, maar het is een zware overdrijving om te stellen dat niet iedereen het vrij kan gebruiken. Het ergste wat ik kan bedenken is dat de runtime nu automatisch mee installeert als je een app vanuit de Chrome Webstore installeert die het nodig heeft, dus je zult akkoord moeten gaan met de ToS van de Chrome Webstore... Ik bedoel, zou dat een dienst zijn waar Google allemaal prive gegevens over je verzameld ofzo dan is dat nog één zaak, maar de Chrome webstore...? Je hebt niet eens een Google account nodig ofzo.

---

Trouwens, ik moet wel eerlijk zijn in dat ik zo negatief ben over dit project primair omdat ik geen nut zie in het Plasma Mobile project (zowel omdat ze van alles door elkaar mixen en dat wat uiteindelijk het belangrijkste is: de UX, niet de eerste plaats geven als omdat er al tal van andere projecten zijn die het wel doen) en deze runtime praktisch alleen nut heeft in de context van het Plasma Mobile project. Zou KDE ofzo super groot zijn geweest dan zou het nog een ander verhaal zijn geweest mogelijk~ maar goed, ik wou dus vooral alleen aangeven dat als je denkt dat Plasma Mobile wel een groot succes word dan zul je ook anders tegen dit project aankijken (al zouden ze dan nog steeds op z'n minst alleen dit soort applicaties moeten ondersteunen (en iets als een NDK)... en dan hadden ze beter een android fork kunnen maken... ach ja, ik snap de logica niet...).

[Reactie gewijzigd door David Mulder op 27 juli 2015 00:20]

Plasma is net gebouwd zodat een UI zeer eenvoudig in elkaar te steken is. Neen de layout is niet hun eerste prioriteit, KDE heeft altijd als eerste prioriteit de onderliggende technologie gehad, en dan pas de rest. Door de onderliggende technologie zo flexibel te maken heb je enkel nog een usability expert nodig om je UI samen te stellen. Hierdoor wordt het grootste probleem met Open Source software ook verkleint: het is niet de (nerd) programmeur die de UI bepaalt, het is de designer die het bepaalt. Daarmee dat de getoond UI (die inderdaad erbarmelijk was) echt maar als proof of concept gezien moet worden, men kan hieruit echt niet afleiden hoe het er gaat uitzien.

Veel projecten tegenwoordig worden eerst behandeld als: het moet werken en er goed uitzien, en dan pas wordt gezocht naar de technologie die er voor nodig is. KDE neemt de omgekeerde weg, eerst een goede basis leggen zodat het design eenvoudig wordt.

OT: als een Klein bedrijfje als Jolla zo een runtime kan ontwikkelen ben ik er zeker van dat Shashlik (wat een naam:-|) van de grond komt. Moest het project het zeer goed doen hoop ik eigenlijk dat Jolla gaat meehelpen omdat hun runtime dan geen unique selling point meer is.

En nu springen ze ineens mee op de mobile bandwagon. Terwijl KDE nog heel veel polish nodig heeft .

PS: Shashlik is in Belgie een frituurbrochette

Als je wil weten hoeveel effort het kost om de mobile bandwagon te ondersteunen en hoeveel voordelen dit oplevert voor de desktop dan zou je het anders bezien. Martin Grasslin heeft er op zijn blog een mooi artikel over geschreven. Kwin op wayland zou nog niet zo ver staan zonder deze mobile bandwagon. Het mooie aan KDE is net dat dit mobiel gedeelte amper development effort vraagt die niet op andere plaatsen gebruikt kan worden.

Kwin op wayland zou nog niet zo ver staan zonder deze mobile bandwagon.

Om eerlijk te zijn kan ook Wayland me op dit moment gestolen worden. Wat KDE voornamelijk nodig heeft in mijn opinie is Q&A. En dat een voormalige Xorg developer (als we het over dezelfde persoon hebben) daar anders over denkt is ook wel compleet normaal. Maar als KDE gebruiker, vind ik de hele KDE 4.x serie een misser: Er ontstaan regelmatig fouten in de plasma-desktop-appletsrc of plasma-desktoprc files waardoor de desktop niet naar behoren werkt. Widgets zijn een ramp en er treden dikwijls grafische fouten op (calendar - zal wel xorg zijn zekerst). Het cmake build systeem is ongewoon en moeilijk, ... Nu veel van deze problemen plaagde ook de KDE 3.x serie, maar dat maakt het juist zo erg.

[Reactie gewijzigd door goarilla op 28 juli 2015 14:32]

Het gros van de apps werkt niet met deze converter... Apk's draaien dus niet zomaar onder chrome(windows en linux versies)
De aangekondigde software zou wel eens serieuze bommen kunnen leggen onder sommige bedrijfsstructuren...
Stel bv eens voor dat Apple dit op z'n toestellen zet...

Het convert niks, alles wat het doet is het in een chrome app wrapper stoppen die Chrome verteld om de android runtime te gebruiken. Google heeft besloten om die runtime primair te ontwikkelen zodat android apps op ChromeOS kunnen werken, dus dat is simpelweg het formaat waarin je het distribueert. Applicaties die een runtime nodig hebben hebben altijd een soort van wrapper. Soms is dat simpelweg een blok aan computercode die zeg maar tegen de computer zegt '1. zoek runtime 2. execute runtime met als input alles wat na dit punt komt' of andere keren is dat ietsje complexer maar hetzelfde idee (zoals met Google's android runtime) of is het geabstraheerd naar OS niveau en je verteld de computer dus 'ieder bestand wat van het type `.xxx` is moet je via dit en dit runtime draaien'. Converten of emuleren zijn twee COMPLEET andere technieken.

Ok, ik heb me wat verkeerd uitgedrukt...

Ik doelde dan ook vooral op het draaien van apk's onder Windows en linux (dus niet Chrome OS maar de browser plugin die de apk parset en laat draaien... Die interfacet dan op zijn beurt met het gast-OS; bv wifi speedtest gebruikt gewoon je wlan om je wifi netwerk te testen op snelheid /stabiliteit net zoals je het met je smartphone test met die zo (icm de companion software die je op een pc zet)).

Ja, maar dat is het geval waar je een runtime ook gebruikt, dus zelfs op Android. De onderliggende kernel (en de rest) blijft gewoon los staan van de Android runtime. Het verschil zit hem in de implementaties van de relevante functies alleen.

In de repo (http://github.com/shashlik/shashlik) viel me meteen op dat gebruik van Dalvik word gemaakt. Ook is te zien dat ze er al zeker een jaar mee bezig zijn. Mijn eerste gedachte was meteen, waarom niet ART? ART is er al sinds Android 4.4. Nu beginnen ze al meteen met een achterstand.

Mijn tweede gedachte was, hoe ga je al die Google dingen afvangen / vervangen? Heel veel apps maken er gebruik van. Bijvoorbeeld ruim 70% van de top 100 apps maakt gebruik van Google Cloud Messaging. Zonder de Google api's werken veel apps niet. Sommige dingen als locatie zijn simpel te vervangen, maar dingen als Google sing in en games api's zijn volgens mij bijvoorbeeld veel moeilijker te vervangen. Nog niet gesproken over in app aankopen gesproken.

Mooi project, maar ik zie nog wel enkele haken en ogen.

Het plan is om Lollipop over te slaan en Shashlik zodra dit mogelijk is op Android M te gaan baseren.

Er zijn ongetwijfeld haken en ogen, maar wat voor mij belangrijk is is dat we dingen als whatsapp e.d. kunnen ondersteunen. De meeste mensen gebruiken twee, drie apps zonder die ze niet kunnen leven, de rest is redelijk makkelijk te vervangen. Zonder ondersteuning voor die apps (die weer voor iedereen anders zijn) zit je feitelijk vast aan Android of iOS, en kun je naar je privacy fluiten. Met Shashlik kunnen we een groot deel van deze mensen blij maken.

De meeste mensen gebruiken twee, drie apps zonder die ze niet kunnen leven, de rest is redelijk makkelijk te vervangen. Zonder ondersteuning voor die apps (die weer voor iedereen anders zijn) zit je feitelijk vast aan Android of iOS, en kun je naar je privacy fluiten. Met Shashlik kunnen we een groot deel van deze mensen blij maken.

Als verstokt KDE-gebruiker kijk ik hier enorm naar uit, zeker dus in combinatie met Plasma Phone OS. Wat ik me afvraag is hoe er met de benodigde permissies van allerlei Android apps kan worden omgegaan. M.a.w., krijg je daar als gebruiker directe invloed en controle op? Kun je die permissies wellicht zelfs tot op het detailniveau beheren als bij XPrivacy kan?

Weet ik helaas niet, maar ik zou zeggen hou planetkde.org in de gaten, en Dan's weblog.

Het klinkt allemaal heel goed! Maar een soort push-dienst à la GCM zou het wel helemaal compleet maken. Of een manier om gemakkelijk een push-dienst van een derde partij te gebruikt, een soort van modulair. Hetzelfde geldt voor een locatiedienst (locatie op basis van Wifi en cell-torens). Dat zijn eigenlijk de enige dingen van Google die veel applicaties niet gemakkelijk zouden kunnen aanpassen/vervangen als ze van Android naar Shashlik zouden willen porteren. Er zijn er wel wat derde partijen die die dingen doen, zoals de locatiedienst van Mozilla, maar ik weet niet hoe bruikbaar die allemaal zijn...

WhatsApp ondersteunen is wel aardig, maar we vergeten volgens mij dat het een single-device app is. Dan werkt het dus niet meer op je telefoon. Als je al een Android hebt, kun je je telefoon aan je desktop/laptop koppelen met web.whatsapp

Google is tevens bezig om ART goed werkend te maken op ChromeOS, om daarvan nog een platform te maken voor Android applicaties. Maar dan Desktop Applicaties. Eigenlijk een concurrent van C# op de nieuwe Windows Runtime in Windows 8/8.1/10.

https://www.youtube.com/watch?v=bbHKBMeBEjQ
https://youtu.be/Q8EwC48Xfjc?t=234

Open source of niet vind ik persoonlijk niet zo belangrijk. Het gaat om de mogelijkheden van de runtime.

De runtime van BlackBerry is erg goed, echter de crux zit hem in door Google formeel goedgekeurde aanwezigheid van de Google Play Store en Google Play Services en nog wat cruciale Google apps. Zonder deze is de runtime een "lame duck". Via de community zijn de Google apps nu wel aan de gang te krijgen in de BlackBerry android runtime, maar Google zal daar zeer onwaarschijnlijk formeel goedkeuring aan geven en zonder dat sta je met welke runtime dan ook toch met redelijk lege handen als je dit voorbij de hobby-fase wilt brengen.

[Reactie gewijzigd door HardeNiezer op 26 juli 2015 19:08]

Wie op BlackBerry de apps wil kunnen downloaden uit de Google Play store kan dat gewoon doen via de playstore cliënt SNAP van redlightlove.

Als je dan google Maps download, draait die ook prima en zonder problemen. Enige wat je mist als je niet de closed source api's installeert is bijv. de integratie van maps in bijv. de zoekfunctie van de AH app. (die draait ondanks afhankelijkheid van closed source api's van een adverteerder voor de rest ook prima)

Ik zie de stap van KDE wel als een mooie, om juist te zorgen de 'dependancy' van closed source api's van veel apk's te stoppen. Nu geeft een app nog aan dat bijv. Een kaartje met bepaalde coördinaten perce via bijv. Google maps geopend moeten worden. Ontwikkelaars kunnen ook niet iets anders kiezen.

Met wat KDE maakt, kan ik mij zo voorstellen, dat ze een framewerk/api maken voor dat zelfde kaartje, maar waarin je dan in de toekomst een keuze kan maken voor kaartmateriaal naar keuze (bijv open maps, sygic etc). op die manier kunnen apps, android en linux distributies veel meer 'open-source' blijven, dan tot wat ze nu gemaakt worden.

Beter is het gebruik, ook bevestigd door mensen die eerst SNAP gebruikten, om de Cobalt app te gebruiken, via
http://forums.crackberry....post-instructions-985344/
Daardoor heb je de Play store zelf op je BB werken en hoef je ook niks te sideloaden zonder dat je ingebouwde BB beveiliging uit moet zetten om SNAP te kunnen installeren.

Het blijft een houtje touwtje oplossing, die de gemiddelde gebruiker afschrikt.
Gelukkig is tegenwoordig wel héél makkelijk de Amazon App store te installeren (wordt ook al standaard meegeleverd bij BB OS 10.3).
Helaas willen niet alle Android ontwikkelaars hun app ook uitgegeven via de Amazon App store, vooral Nederlandse ontwikkelaars!!!!
Ze snappen niet waarom, denken dat het meer moeite kost (wat echt niet zo is) en..... snappen niet waarom uitbrengen bij een concurrent voor hun in hun voordeel kan zijn.

[Reactie gewijzigd door William_H op 26 juli 2015 20:22]

Let op, het is niet altijd van niet willen... Kleinere uitgevers hebben veel vaker een niet mogen aan hun been dmv contractuele overeenkomsten waarin bv staat dat ze het niet op een tweede locatie gratis mogen distribueren voor dezelfde markt (bv Europa)..

Geef dat dan aan. Want dat vind ik dan wel een goed argument. Maar dan komen ze met een leuter argument aan.

als ze een exclusiviteitscontract afsluiten valt er niet veel meer aan te geven vrees ik.
Het is juist als ze toch op een andere plek de software gratis gaan aanbieden dat er iets zal worden aangegeven omdat ze hun contract verbreken.
In de videogames industrie komt dit soort contracten ook enorm vaak voor.
Denk maar aan de vele CoD games die telkens eerst op de x360 verschenen en pas een tijd later op de ps3...

Wanneer we de basics hebben draaien, is het plan om inderdaad voor diepere systeemintegratie te zorgen, een brug voor notificaties, vervangende API's voor veelgebruikte dingen is inderdaad het plan. Het zal niet allemaal op dag 1 perfekt zijn, maar dat is't bij een open ontwikkelingsproces nooit.

Voor mij persoonlijk en heel veel anderen is het buitengewoon belangrijk om dit onder Vrije licenties beschikbaar te hebben, dat geldt natuurlijk niet voor iedereen, maar ik ken heel veel gebruikers die hier echt op zitten te wachten. Het is niet geheel triviaal, dus ik ben blij dat we de mankracht hebben om dit van de grond te krijgen. Uiteindelijk wordt hier niemand door beperkt of geschaadt, er zijn alleen extra mogelijkheden die worden aangeboden.

Mooi, goed bezig KDE.

Ik hoop ook dat ze in tegenstelling tot BlackBerry en Jolla en windows hun android time volledig open source weten te houden, daarnaast dat die net zo goed werkt, en dat ze hem beschikbaar kunnen stellen voor iedereen.

Edit:

De ontwikkeling van Shashlik kan grote gevolgen hebben voor toekomstige apparaten die draaien op een Linuxkernel, waar tegenwoordig ook smartwatches en televisies onder vallen. De runtime leidt er in ieder geval toe dat er Android-apps naar het zaterdag gepresenteerde Plasma Phone OS, met de Plasma Mobile-gui, komen. Zo is het besturingssysteem niet alleen meer gestoeld op native apps, waarvoor veel mankracht nodig is. Kügler: "Dit lost het kip-ei-probleem op."

Ik denk dat ze hiermee de koe bij de hoorns vatten.
Een volledig nieuw platform uit de grond stampen, terwijl dat alleen moet draaien op je eigen 'native' apps is gewoon vrijwel onmogelijk.

Gebruikers verwachten apps, apps verwachten gebruikers. Het zou mooi worden als APK's een standaard worden voor cross-platform apps. Een krachtige sterke linux partij die APK's ook op een volledige open source wijze ondersteund. Zorgt er ook voor dat meer developers misschien kiezen om open-source Apps te ontwikkelen in plaats van apps die afhankelijk worden gemaakt van closed source api's.

Android is ooit begonnen als een open source project, met ook die doelstelling en heeft daardoor initieel veel enthousiasme gewekt bij allerlei ontwikkelaars. Helaas hebben met de verloop van tijd commerciële belangen gezorgd voor een steeds grotere rol van closed source code.

Wellicht, en het is een beetje hoopdenken, kan KDE hiermee het schip keren.

[Reactie gewijzigd door Anoniem: 601896 op 26 juli 2015 19:13]

KDE is altijd al een FOSS project geweest en ook dit nieuwe project verschilt daar niet van. De code is vandaag al tie zien op github ( https://github.com/shashlik/shashlik ). En hoewel ik er nu niet direct een licentie zie bijstaan, neem ik aan dat dit project ook gewoon zal voldoen aan het licentiebeleid van KDE ( https://techbase.kde.org/Policies/Licensing_Policy )

GPL, even een willekeurige source file erbij gepakt, https://github.com/shashl...controller/Controller.cpp.

Mocht dit echt goed gaan werken dan stap ik meteen over naar Plasma Mobile. Je hebt dan namelijk best of both worlds: Een écht Linux OS (zonder dat Google overal bij meekijkt) maar wel een hele grote appbase. En ja, ik weet dat Sailfish en BBOS dit ook hebben maar die OSen zijn nog steeds niet volledig open source.

Ook veel dank aan Kügler dat hij alles zo goed uitlegt en mededeelt

Graag gedaan.

Ik wou ook even zeggen, bedankt voor je werk en lekkere naam Shashlik.

Ik hoop niet dat Shashlik teveel gepaard gaat met KDE. Ik wil niet allemaal KDE libraries op mijn PC hebben, puur vanwege alleen Android compatibiliteit. Overigens is het wat langer geleden dat ik het deed, en ik ben niet echt op de hoogte van KDE, maar ik heb wel eens applicaties die gemaakt waren voor KDE geïnstalleerd en ik meen me te herinneren dat ik er een hoop nodeloze onzin bij kreeg. Maar goed, als dat toch het geval is zullen andere DE bouwers vanzelf wel een fork bouwen. Krijg je applicaties met namen als GTKashlik of Shashlik-qt.

[Reactie gewijzigd door Amanoo op 26 juli 2015 21:21]

Of je krijgt die pakketten omdat de code zo opgesplitst is, dat wil zeggen dat men dit meestal op packaging niveau oplost, in plaats van maar meteen te forken. Forken gaat gepaard met hoge kosten en is echt een laatste maatregel die meestal fundamentelere problemen dan wat dependencies hebben, vaak niet-technisch maar sociaal zelfs.

Daarnaast is de footprint van de KDE libraries tegenwoordig zeer beperkt. Met de komst van Frameworks 5 zijn dependencies opgeruimd en alles fijnmazig opgesplitst.

[Reactie gewijzigd door sebas op 26 juli 2015 21:32]

Ik denk dat je ook de Jolla developers wel meekrijgt om mee te helpen. Wat hier niet gezegd wordt en dat vindt ik wel kwalijk is dat zij wel alien dalvik in licentie moesten nemen omdat er geen alternatief was. (en hnet is een start up dus hebben het al niet breed) Grote kans dat als dit goed werkt. Ze dit gaan gebruiken inplaats van de licentie. Overigens Google zal hier niet blij mee zijn. Op mijn Jolla werkt de playstore enz. ook niet of met een hele erge workaround. Nu is Jolla niet groot genoeg om dit op te lossen de KDE ook niet maar de linux gemeenschap in zijn geheel wel. Gnome zit al op mobiels in de vorm van MER. Al gaan er wel geruchten dat er ook mensen van Gnome meer willen.

"Android-runtime voor 'normale' Linuxdesktopsystemen" doet me denken aan ... WINE en Mono. En die hobbelden altijd achter Windows en .NET aan omdat Microsft niet meewerkte. Dus als Google niet meewerkt ...

Samba werd pas echt een (compatibliteits)success toen de EU Microsoft opdroeg om alle SMB-specs openbaar te maken aan Samba

[Reactie gewijzigd door surfert op 27 juli 2015 00:54]

Ik zal dat feature niet gebruiken, ook al ben ik een KDE-gebruiker, Google weet al te veel (idem voor de concullega's).

Had meer verwacht van een KDE gebruiker. Als je een applicatie schrijft en een APK bouwt. En deze draait op KDE met de ART/Dalvik Runtime. Zit er totaal geen Google tussen.
Dat had je zelf ook wel kunnen bedenken. Google krijgt dan niks te zien.