57 replies to this topic

[Meega]

Het huidige licentie probleem is dat OpenPLi alles onder GPL vrijgeeft. De licentie van de meeste plugins is daarmee in strijd, omdat die allerlei extra beperkingen bevatten. Om op OpenPLi te mogen draaien, zouden de auteurs van de plugin de licentie ook naar GPL (of iets wat daarmee compatibel is) moeten omzetten.

precies, het is geen dreambox<->non-dreambox verhaal, maar gpl<->non-gpl.
Overigens voor discussie open, python is een script wat in een (gpl) interpretor draait.

Als een plugin een opzichzelf draaiend programmaatje binnen OpenPli is ,zoals bv Mytube mag het toch wel?
Of is de plugin als het ook gebruik maakt van de skin een samenvoeging in het systeem?

Van GNU.org

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? (#GPLAndPlugins)

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

[MiLo]

Alle plugins vallen in de "dynamically links" categorie. Ze worden bij Enigma in hetzelfde process geladen.

En da's de reden dat de meeste plugins geen "schone" GPL licentie hebben, maar altijd dat wazige tekstje over Dream hardware invoegen. Een GPL plugin zou niet op DMM software mogen draaien, zelfs niet toen DMM nog open-source was.

Da's ook de reden dat een origineel DMM image geen teletekst cache heeft: Ze draaien de TTX plugin (tuxtxt) in een apart proces om onder de GPL licentie van tuxtxt uit te komen. Aangezien PLi's licentie wel compatible is met GPL, kan tuxtxt gewoon geintegreerd worden en kun je ttx cachen.

Edited by MiLo, 3 April 2012 - 18:02.

[Meega]

Alle plugins vallen in de "dynamically links" categorie. Ze worden bij Enigma in hetzelfde process geladen.

Da's ook de reden dat een origineel DMM image geen teletekst cache heeft: Ze draaien de TTX plugin (tuxtxt) in een apart proces om onder de GPL licentie van tuxtxt uit te komen. Aangezien PLi's licentie wel compatible is met GPL, kan tuxtxt gewoon geintegreerd worden en kun je ttx cachen.

Oke helder bedankt

[Zuppelan]

Even een beetje theoretische gedachte hierover...

De architectuur van Enigma maakt het min of meer een besturingssysteem: Plugins als Mytube, Foreca, Apple Movietrailer e.d. zijn concept feitelijk gebruikersapplicaties. Die maken van diensten van Enigma gebruik... ofwel het idee applicatie versus besturingssysteem. In beginsel maken ze voor alle besturingssysteemdiensten van Enigma gebruik; ook het open en sluiten van een bestand gaat feitelijk via een Python-aanroep. Weliswaar worden deze diensten uitbesteed aan de Linux-kernel, maar voor een applicatie is de Linux-kernel niet zichtbaar. Het had net zo goed op bijv. FreeBSD kunnen draaien, een applicatie zou het verschil niet merken.

Welnu... gezien Enigma de facto het besturingssysteem is kunnen we ook de stand der wetenschap over besturingssystemen op Enigma gaan toepassen. Zo is de taak van een modern besturingssysteem om de applicaties in gescheiden processen te laten lopen. Dit gebeurt niet in Enigma. En de klassieke gevolgen treden op:
* De hierboven besproken GPL-licentiekwestie
* Eén applicatie kan heel Enigma doen crashen
* Pre-emptie wordt lastig. Er is in Enigma een soort coöperatieve multi-tasking d.m.v. event-driven programmeren dat bijv. de volumeafhandeling blijft werken in de meeste schermen, maar iedereen heeft vast wel eens gehad dat een plugin tien minuten lang tandwieltjes toont en je dan de ontvanger maar aan- en uitzet of via de PC inlogt en heel Enigma afschiet. Eigenlijk wil je de plugin kunnen "killen".

Er is ook niet echt een uitweg... Stel je wilt iets in een apart proces draaien, maar je hebt een tuner nodig. Alleen Enigma weet of het veilig is een bepaalde tuner op een frequentie af te stemmen, je wilt niet een tuner op een frequentie zetten als die bijvoorbeeld met een opname bezig is. Je moet wel "in" Enigma zitten om de tuner op een sjieke manier aan te vragen.

Dit is eigenlijk best wel een zwak punt van de Enigma-architectuur.

[pieterg]

De architectuur van Enigma maakt het min of meer een besturingssysteem

Absoluut mee oneens.
e2 is een applicatie. Vergelijk het met x bijvoorbeeld.

[Zuppelan]

Denk er nog maar eens over na want het is de waarheid..... mijn webbrowser zit niet in dezelfde procesruimte als X, heeft X niet nodig om een bestand te openen of netwerkverkeer te voeren e.d. en als mijn webbrowser hangt, kan ik hem gewoon afschieten. Er is pre-emptieve multitasking tussen mijn webbrowser tekstverwerker. Het verschil is dat X gewoon één van de diensten van het besturingssysteem is is die je kunt aanroepen (als in invoer of schermuitvoer wilt), terwijl Enigma alles overneemt en alle applicaties dwingt binnen zijn procesruimte te draaien.

Wel is X een vreemde eend in de bij versus de leer microkernel versus monolytische kernel. In de filosofie achter Linux is het dankzij zijn monolytische kernel veel efficiënter omdat als je bijvoorbeeld netwerkcommunicatie wilt alleen een kernelaanroepnodig is, en geen contextswitch naar een applicatie die de netwerkstack implementeert. Het is dan een beetje vreemd dat, zodra je schermuitvoer wilt (doorgaans vrij snelheidskritisch), juist in microkernel-stijl wel een contextswitch nodig is naar een applicatie die de schermuitvoer implementeert.

Edited by Zuppelan, 4 April 2012 - 07:55.

[littlesat]

Linux is het OS... Enigma2 is een applicatie (waar het UI in zit).... dit UI heeft mogelijkheden om het uit te breiden met plugins.
Windows-7 is het OS... Microsoft Word is een applicatie (waar het UI in zit). Dit UI heeft ook mogelijkheden het uit te breiden met addons of addins of hoe die dingen ook heten.

Enigma-2 is dus geen OS, Operating System alias Besturings systeem.

Edited by littlesat, 4 April 2012 - 07:59.

[Zuppelan]

Nee.... je draait erom heen. Het maakt me even niet uit hoe het in de huidige architectuur benoemd wordt. Ik kijk naar de concepten.

En in dat concept.. start ik via mijn afstandsbediening een applicatie (bijv. MyTube) op. En als die eeuwig tandwieltjes laat zien, kan ik die applicatie niet afschieten. Oorzaak: De architectuur van Enigma2, die applicaties dwingt plugins te zijn.

Edited by Zuppelan, 4 April 2012 - 08:01.

[littlesat]

Die afstandsbediening is een deel van het UI... via dit UI start je een plugin (MyTube)..... Die laat eeuwige tandwieltjes zien.... omdat er "iets" niet goed is in Enigma2 en/of de MyTube plugin...Daarmee is Enigma2 nog geen besturingssysteem???

[dAF2000]

Met de kennis die ik heb over GPL (en ik weet alleen maar de basis) gaat het niet om concepten of wat de gebruiker ervan ziet, maar puur om de technische term van OS en applicatie. Maar ik kan 't mis hebben. Een OS regelt dan bijvoorbeeld de interface met randapparatuur; Enigma doet dat niet. Bovendien draait er op een box behalve Enigma ook programma's als dhcp en telnet. Als Enigma al het OS zou zijn, hoe moeten we die dan plaatsen?

Een discussie die veel interessanter is, en Pieterg liet dat al weten, is in hoeverre Python een programma is. Python is namelijk een interpreter en een Python-programma daardoor strikt gezien een databestand.

[dAF2000]

Maar zelfs dan nog... als een plugin-schrijver z'n eigen koetjeboe-licentie (ik noem maar wat) verzint en zegt op welke hardware het wel en niet mag lopen, dan loop je daar al vast.

(maar we gaan nu off-topic)

[Zuppelan]

Die afstandsbediening is een deel van het UI... via dit UI start je een plugin (MyTube)..... Die laat eeuwige tandwieltjes zien.... omdat er "iets" niet goed is in Enigma2 en/of de MyTube plugin...Daarmee is Enigma2 nog geen besturingssysteem???

Misschien is de stelling besturingssysteem wat overdreven, maar snap je het punt?

Stel ik ben iemand die niets van Linux of Enigma afweet, maar prima met computers kan omgaan. Iemand presenteert mij enerzijds een PC met een KDE-desktop, en anderszijds een Enigma-ontvanger. Ik zie bij beiden een UI waarmee ik applicaties kan starten, bij de één met de muis, bij anders met de afstandsbediening, maar bij beide verschijnt een applicatie met een eigen GUI.

Bij de KDE-desktop heb ik de klassieke scheiding van processen, zodat ik applicaties met verschillende licenties kan draaien, heb ik pre-emptieve multi-tasking tussen de applicaties, en kan ik een applicatie afschieten, bij de Enigma-ontvanger kan dat niet. Daar moeten ze allemaal een GPL-licentie hebben, is er geen preëmptieve multitasking, en hangt één applicatie de hele boel op.

Even los van de vraag van de vraag of dit Enigma een besturingssysteem maakt, je ziet de analogie tussen beide platformen, en de verschillen (en gevolgen) wat betreft de scheiding van processen?

Laten we even terug gaan naar X, want dat is wel een mooie vergelijking.

Bij X zijn server, windowmanager, en applicaties allen gescheiden processen, die communiceren via interprocescommunciatie of zelfs TCP/IP. Men had ook voor een andere architectuur kunnen kiezen. Eentje waarbij de windowmanager een .so bestand was dat dynamisch geladen werd. En eentje waarbij webbrowsers en tekstverwerker ook een .so bestand waren dat door de X-server geladen wordt op het moment dat je hem opstart.

Technisch allemaal geen enkel probleem en het zou behoorlijk wat complexiteit schelen. Maar ik denk niet dat we dat zouden willen; de scheiding van processen is een groot goed en voor de robuustheid van het systeem essentieel.

[MiLo]

En in dat concept.. start ik via mijn afstandsbediening een applicatie (bijv. MyTube) op. En als die eeuwig tandwieltjes laat zien, kan ik die applicatie niet afschieten. Oorzaak: De architectuur van Enigma2, die applicaties dwingt plugins te zijn.

Oorzaak: Slecht programmeerwerk van de plugin auteur. Die had niet zo lui moeten zijn om een blocking call op de UI thread te doen.

Net als veel UI frameworks is er in Enigma2 een enkele thread die UI en events afhandelt. Op die thread hoor je geen "werk" te verrichten, maar hoor je de asyncrhone methods te gebruiken, en je kunt ook eenvoudig je calls deferren naar een andere thread en terug.

Als je "tandwieltjes" ziet, dan is dat een probleem van de programmeur(s) en niet van Enigma2 zelf. Die dwingt helemaal niets af.

[Zuppelan]

Nou ja... dat is gewoon de eeuwige discussie bij coöperatieve multitasking versus preëmptieve multitasking. Inderdaad is er bij coöperatieve multitasking niets aan de hand als alle applicaties zich netjes gedragen. Dus in een coöperatief systeem moet je in inderdaad geen grote hoeveelheden werk in een eventhandler verzetten, dat blokkeert de boel alleen maar. Wat dat betreft is er geen verschil tussen Windows 3.1 en Enigma2.

Op een bepaald moment kom je tot de conclusie dat het onmogelijk is om iedereen te dwingen software te schrijven die zich op dit punt perfect gedraagt. En dat je je gebruikers toch wilt beschermen tegen niet perfecte software. Dat is het moment dat je naar een preëmptief model overstapt.

Edited by Zuppelan, 4 April 2012 - 12:24.

[WanWizard]

Als dat impliceert dat je je hierbij kandidaat stelt om Enigma2 te herschrijven, ik denk niet dat er iemand zal zijn die je tegen houd.

[Meega]

@WanWizard

Kun je hier geen nieuw draadje van maken ?
Zeer interesant,tenminste als het draadje niet dood bloed.

Of met goedkeuren van dream1975 topicnaam iets aanpassen.

[MiLo]

Wat dat betreft is er geen verschil tussen Windows 3.1 en Enigma2.

En Windows NT, Windows XP, Windows Vista, Windows 7, Windows 8, QT, GTK, TCL/TK, en nog wel meer UI frameworks.

Een enkele UI thread is gewoon het efficientste. Anders spendeert die snel meer tijd aan mutexen locken dan aan echt werk verzetten. Vandaar dat vrijwel elk UI framework daarop terugvalt. Met het OS heeft dat niets te maken.

[Meega]

@Pieterg wat bedoel je nu met post 14 in het vps plugin draadje.

"But to me it would be fine if we declare that python plugins under creative commons license don't break the GPL license.
Nobody really knows, how interpreted code works with GPL."

Ik ben er ook wel voor om het allemaal duidelijk te krijgen.

Wat ik gister zat te lezen is dat als een stuk software eenmaal een licentie heeft je hem niet meer mag veranderen als die eenmaal is uitgegeven.
Ik weet niet hoe dat zit als er een update overheen gekomen is,dus als de software weer is aangepast alhoewel ik me kan voorstellen dat zolang de naam hetzelfde blijft de licentie dat ook zou moeten zijn.

[pieterg]

@Pieterg wat bedoel je nu met post 14 in het vps plugin draadje.

"But to me it would be fine if we declare that python plugins under creative commons license don't break the GPL license.
Nobody really knows, how interpreted code works with GPL."

Ik ben er ook wel voor om het allemaal duidelijk te krijgen.

Ik bedoel dat ik al dat licentie geneuzel meer dan zat ben, dus dat ik het prima vind om vanaf nu te veronderstellen dat creative commons python plugins prima samengaan met een GPL enigma2.

[Meega]

@Pieterg wat bedoel je nu met post 14 in het vps plugin draadje.

"But to me it would be fine if we declare that python plugins under creative commons license don't break the GPL license.
Nobody really knows, how interpreted code works with GPL."

Ik ben er ook wel voor om het allemaal duidelijk te krijgen.

Ik bedoel dat ik al dat licentie geneuzel meer dan zat ben, dus dat ik het prima vind om vanaf nu te veronderstellen dat creative commons python plugins prima samengaan met een GPL enigma2.

LOL helemaal eens!!!