Porting hell voor bedrijven

Door Typnix op maandag 13 december 2010 14:46 - Reacties (10)
Categorie: -, Views: 4.121

Als je met recente versies van Unix zoals AIX en Solaris samen met OSS wilt werken dan valt het jou gelijk op dat de OSS pakketten die geschikt voor deze platformen vrijwel altijd te oud zijn. En ook alleen geschikt zijn voor oudere versies van het besturingssysteem die jij in beheer hebt. Noem als voorbeeld: MySQL5.0.x die dan alleen gecompileerd is voor Solaris 8 of een GNU GCC 4.2.4 die alleen geschikt is voor AIX 5.2.

Als voorstander van OSS laat ik mij niet door dit soort dingen afschrikken (mits ik het niet direct nodig heb) maar als ik onder werktijd een wat recentere versie zou willen hebben van een pakket, is dit dus wel slikken. Het dus niet zo vreemd dat er dus collega's zijn die ervoor kiezen om gelijkwaardige pakketten te nemen die ook nog door de fabrikant wordt ondersteund. Los van het feit wat voor nut betaalde ondersteuning heeft is het gewoon naar mijn inziens een gemiste kans.

Om maar als voorbeeld te nemen: als ik een recente versie wil van bijvoorbeeld Postfix met MySQL support voor Solaris 10 wil hebben dan moet ik het pakket eerst compileren voordat ik het kan gebruiken. Ik hoef de kenners niet te vertellen dat Postfix zich makkelijker laat compileren door GNU GCC. Het punt alleen is dat er geen recente versie aanwezig is voor Solaris 10. En er is wel een versie maar die is alleen geschikt voor Solaris 8. En die van Solaris 8 is niet geschikt voor Solaris 10. En omdat Sun in Solaris 10 de mappenstructuur heeft aangepast en nog meer van dat soort dingen, ben ik verplicht om te compileren.
En het compileren van GNU GCC is een langdurig werkje. Want GNU GCC heeft ook nog eens een forse lijst aan afhankelijkheden waarmee je rustig een A4tje kan vullen en die moeten eerst gecompileerd worden voordat je eindelijk aan GCC mag beginnen.

En dan hoef ik jullie niet te vertellen dat mocht ik dit onder werktijd doen dat dan mijn leidinggevende mij de wind van voren zou geven als ik het alleen maar zou denken.

En ongeacht of de duur van het compileren van GCC en zijn bijhorende afhankelijkheden lang of kort zal zijn, is de kans dat er een pakket zal zijn die niet wil compileren vanwege uitlopende redenen nog steeds aanwezig. Ik heb het dan over de regelrechte programmeerfouten tot aan echte systeemafhankelijke verschillen zijn die dan recht getrokken moeten worden voordat het pakket daadwerkelijk klaar is om zonder problemen te compileren aanwezig omdat het aantal mensen wat de kans heeft genomen om dit uit te zoeken aanzienlijk kleiner is dan de voor de platformen zoals Linux. Dit natuurlijk allemaal omdat vanwege de gesloten aard van Solaris en AIX.

En met dit alles maakt het gebruik van OSS op deze platformen in een bedrijfsomgeving een "no-go" situatie. Tenzij ik ervoor kies om dat ene pakket te nemen van Sun of van IBM.
En dan ben je er nog niet van af want het ene pakket laat zich wel compileren met die ene compiler en de andere weer niet met die andere. Dus dan wordt de keuze om een een kant -en klare oplossing op een ander platform zoals Microsoft Exchange, waarbij ik nergens over na hoeft te denken, wel heel groot en dat is erg jammer. Omdat daarmee de kans om opensourcesoftware goed te laten groeien in het bedrijfsleven veel kleiner is dan wanneer er situatie is waarbij er een aanzienlijke lijst aan voorgecompileerde pakketten zijn die je op een recente versie van een platform installeren.

En natuurlijk is het voor een project zoals libgmp ondoenlijk om dit te doen en dat zal dus ook niet gebeuren. Daarom pleit ik eigenlijk voor een platform die zich inzet voor het aanbieden van OSS op gesloten platformen op een gebruiksvriendelijke wijze om zo OSS beter in de markt te zetten. En het is ook voor het bedrijfsleven drempel minder om OSS niet te gebruiken. Er zijn particuliere initiatieven die dit ook doen alleen die zijn beperkt in hun mogelijkheden. Maar die lopen ook achter met hun versies en dat is uiteindelijk ook niet bevorderend. Het zelf oprichten van een dergelijk platform doe je ook niet even want daar heb je resources nodig zoals natuurlijk machines, ontwikkelaars en een goede organisatie.

Het overlaten aan de fabrikanten zelf is ook niet verstandig want het ondersteunen van OSS is plassen in eigen vijver en dat doe je gewoon niet. IBM biedt wel zelf pakketten aan maar die zijn zo oud dat het eigenlijk niet meer verantwoordt is.

Ik denk dat ik daarom in de loop van de tijd een aantal artikelen zal schrijven over hoe je zelf een voorgecompileerd pakket kan bouwen en dan kijken wie het snelste en het beste voorgecompileerde pakket bouwen.

Tabee

Volgende: Beheerders en zo.. 02-'11 Beheerders en zo..
Volgende: Het sollicitatiegesprek. 12-'10 Het sollicitatiegesprek.

Reacties


Door Tweakers user i-chat, maandag 13 december 2010 15:20

euhhhh waar heb je het over???
Dus dan wordt de keuze om een een kant -en klare oplossing op een ander platform zoals Microsoft Exchange, waarbij ik nergens over na hoeft te denken, wel heel groot en dat is erg jammer. Omdat daarmee de kans om opensourcesoftware goed te laten groeien in het bedrijfsleven veel kleiner is dan wanneer er situatie is waarbij er een aanzienlijke lijst aan voorgecompileerde pakketten zijn die je op een recente versie van een platform installeren.
als je dan toch naar een 'andere' oplossing kijkt vraag ik me af waarom je niet gewoon een paar linux bakken in je netwerk hangt,

hoe moeilijk moet het zijn om paket x op een Rhell, een Sless of desnoods een Ubuntu server te laten draaien, terweil je gewoon de rest van je netwerk doet op dat ene vage os waar jij dagelijks mee werkt (nofi).

als iets werkelijk rampzalig is om te porten moet je gewoon 's overwegen om het dan dus maar niet te porten. en op een OS te draaien war het wel standaard ondersteuning heeft.

Door Tweakers user Typnix, maandag 13 december 2010 15:53

i-chat schreef op maandag 13 december 2010 @ 15:20:
euhhhh waar heb je het over???
[...]
als je dan toch naar een 'andere' oplossing kijkt vraag ik me af waarom je niet gewoon een paar linux bakken in je netwerk hangt,
Nee, want ook voor die Linux bakken die je dan op een aparte processor architectuur zoals SPARC en POWER moet draaien heb je nog steeds het probleem dat je moet porten. Het aantal software pakketten wat voor Linux voor IBM-POWER aanwezig is, kan je helemaal bedroevend noemen. En je hebt niet altijd de keuze om zomaar van een OS te stappen.
hoe moeilijk moet het zijn om paket x op een Rhell, een Sless of desnoods een Ubuntu server te laten draaien, terweil je gewoon de rest van je netwerk doet op dat ene vage os waar jij dagelijks mee werkt (nofi).
Non taken, maar die ene vage server waar ik mee werk wordt in het bedrijfsleven vaker gebruikt dan jij denkt. Denk maar aan iedere financiŽle-, zorg- en zelfs bepaalde administratieve instellingen, nutsbedrijven en natuurlijk de overheid. Die paar Linux servers0 waar jij het over hebt, die zullen ergens in een hoek zullen verdwijnen, zullen minder snel geÔmplementeerd worden dan een AIX bak of een HP-UX bak. Ja, Linux is groeiende maar als dominante partij is het een hele lange weg te gaan. En dan heb ik het niet eens over dat bedrijven de stap moeten wagen maar dat Linux kernel robuuster moet worden om mee te beginnen.
als iets werkelijk rampzalig is om te porten moet je gewoon 's overwegen om het dan dus maar niet te porten. en op een OS te draaien wat het wel standaard ondersteuning heeft.
Nogmaals, je hebt het niet altijd voor het kiezen.

Door Tweakers user RoadRunner84, maandag 13 december 2010 15:56

Uhm... ik volg je niet helemaal, waarom zou de OSS community zich moeten inspannen voor het beschikbaar maken van hun software op closed source systemen? Mocht er iemand behoefte aan hebben, laat die persoon/bedrijf dat dat op zich nemen.
Bovendien, is het niet aan Sun/Oracle om een portability onderzteuning te bieden als ze op het leuke idee komen de mappenstructuur overhoop te gooien? Immers is Solaris hier de oorzaak van de incompatibility.
Het gros van de OSS projecten target ofwel GNU/Linux, ofwel POSIX. In beide gevallen ligt het dus bij een afwijkend systeem om hiervoor ondersteuning te bieden.
Daar even los van,
En dan hoef ik jullie niet te vertellen dat mocht ik dit onder werktijd doen dat dan mijn leidinggevende mij de wind van voren zou geven als ik het alleen maar zou denken.
Waarom mag je van je werkgever niet tijd investeren in zaken die nodig zijn om zijn netwerk/servers te onderhouden, ook al zijn dat indirecte zaken (dependencies)?

Door Tweakers user i-chat, maandag 13 december 2010 17:05

waar ik op doelde was om als het porten naar dat os zo'n probleem is om dan maar ofwel een heel distro port te zoeken en volgens mij zijn die er voor de meeste architecturen wel, dan heb je in ierder geval GNU linux zodat je DAAR alvast geen zorgen meer om hoeft te maken.

als je werkelijk de keuze maakt om voor een 'open source omgeving te gaan omdat die gewoonweg beter zijn dan alternatieven die je hebt, dan denk ik dat, ofwel het draaien van een virtualisatie laag (met daarin een paar linux services), of gewoon een paar standaard servers. helemaal niet zo'n probleem mogen zijn de development tijd in uren is in de meest gevallen al snel hoger dan het kostenplaatje van een paar x86 servers of een goed uitgewerkte virtualisatie slag.

hoe dan ook problemen zijn er op te lossen, en dat begint in jouw geval schat ik zo bij het 'je manager overtuigen van de noodzaak van het gene dat je wilt' en daarbij dus tijd en/of budget vrijmaken om dingen structureel op te lossen.

[Reactie gewijzigd op maandag 13 december 2010 17:07]


Door Tweakers user Typnix, maandag 13 december 2010 17:34

RoadRunner84 schreef op maandag 13 december 2010 @ 15:56:
Uhm... ik volg je niet helemaal, waarom zou de OSS community zich moeten inspannen voor het beschikbaar maken van hun software op closed source systemen? Mocht er iemand behoefte aan hebben, laat die persoon/bedrijf dat dat op zich nemen.
Ja en nee. Bedrijven gebruiken OSS software niet omdat ze het vertikken om software te gebruiken waarvan er een reŽle kans bestaat dat zij eerst erin moeten investeren voordat zij het Łberhaupt kunnen gebruiken. En ja, er zijn bedrijven die het wel doen maar dat zijn er niet zodanig veel dat er het ook daadwerkelijk ook nog eens een verschil maakt. Daarnaast is het ook zo dat er opensource projecten zijn die zacht gezegd niet zo snel zijn met het implementeren van fixes. En ja, natuurlijk moet je voor voorzichtig zijn maar niet vijf versies.

En er zijn beheerders die zeggen van: "Als ik het moet compileren dan gebruik ik het maar niet want stel dat ik een bug tegenkom, wat dan?"

Omdat Solaris jarenlang gratis downloadbaar en bruikbaar is geweest(alleen in zijn support niet) tot aan Solaris 10 en dus ook voor gewone consumenten mogelijk is geweest om de x86 versie van Solaris te gebruiken zouden bepaalde bugs al eerder naar voren kunnen komen.
Bovendien, is het niet aan Sun/Oracle om een portability onderzteuning te bieden als ze op het leuke idee komen de mappenstructuur overhoop te gooien? Immers is Solaris hier de oorzaak van de incompatibility.
Het gros van de OSS projecten target ofwel GNU/Linux, ofwel POSIX. In beide gevallen ligt het dus bij een afwijkend systeem om hiervoor ondersteuning te bieden.
Daar even los van,
Nee, dat is niet aan Sun om achterwaartse ondersteuning te geven voor softwarepakketten van derden want waarom zouden zij dat doen? Sun brengt dan op dat moment software uit die alleen maar geschikt is voor de versie waarvoor het gemaakt is.
En dus moeten de OSS projecten zelf voor zorgen dat hun software er wel op werkt.
Waarom mag je van je werkgever niet tijd investeren in zaken die nodig zijn om zijn netwerk/servers te onderhouden, ook al zijn dat indirecte zaken (dependencies)?
Omdat het compileren voor andere architecturen dan x86 en x86_64 wat minder vlekkeloos gaat. En nogmaals omdat de kans dat je een bug tegenkomt redelijk groot is maakt dit juist dure aangelegenheid. Want die bug moet opgelost worden en dat oplossen kost tijd. En als je het niet kan oplossen kost het meer tijd en tijd kost gewoon geld.

Door Tweakers user Typnix, maandag 13 december 2010 18:27

i-chat schreef op maandag 13 december 2010 @ 17:05:
waar ik op doelde was om als het porten naar dat os zo'n probleem is om dan maar ofwel een heel distro port te zoeken en volgens mij zijn die er voor de meeste architecturen wel, dan heb je in ierder geval GNU linux zodat je DAAR alvast geen zorgen meer om hoeft te maken.
Laat ik het anders vertellen.. Het draaien van Linux op andere architecturen die anders zijn dan x86 is gewoonweg bagger omdat het allemaal net niet werkt.
OSS wordt tot nu toe alleen maar gelinkt met Linux op x86 terwijl OSS veel meer is dan een onderdeel is van een kernel. OSS hoort helemaal niet te beperken tot Linux maar ook beschikbaar te zijn voor andere platformen ook en daar ging het ook ooit allemaal om.
als je werkelijk de keuze maakt om voor een 'open source omgeving te gaan omdat die gewoonweg beter zijn dan alternatieven die je hebt, dan denk ik dat, ofwel het draaien van een virtualisatie laag (met daarin een paar linux services), of gewoon een paar standaard servers. helemaal niet zo'n probleem mogen zijn de development tijd in uren is in de meest gevallen al snel hoger dan het kostenplaatje van een paar x86 servers of een goed uitgewerkte virtualisatie slag.
Virtualisatie laag is een leuke tussen oplossing maar dan verplaats je het probleem dat
OSS hoort niet alleen op Linux op x86 te werken maar ook op andere architecturen en platformen.
hoe dan ook problemen zijn er op te lossen, en dat begint in jouw geval schat ik zo bij het 'je manager overtuigen van de noodzaak van het gene dat je wilt' en daarbij dus tijd en/of budget vrijmaken om dingen structureel op te lossen.
Ik hoef niet om de tafel met mijn manager gelukkig maar het is wel een probleem waarbij ook steeds meer van de gemeenschap zelf wordt gezegd dat dit ook verbeterd moet worden.

Door Tweakers user i-chat, maandag 13 december 2010 22:17

[...]

Virtualisatie laag is een leuke tussen oplossing maar dan verplaats je het probleem dat
OSS hoort niet alleen op Linux op x86 te werken maar ook op andere architecturen en platformen.


[...]

Ik hoef niet om de tafel met mijn manager gelukkig maar het is wel een probleem waarbij ook steeds meer van de gemeenschap zelf wordt gezegd dat dit ook verbeterd moet worden.
ik denk JUIST dat het een nuttige manier is, OSS software is natuurlijk vrij makkelijk te draaien op elke arch, je hoeft hef immers alleen maar hercompilen ..

dat dit in de practijk vaak niet werkt omdat er een vaak bedrijf zo nodig afwijkend wil zijn,
je zegt zelf dat het niet sun/oracle's taak is om te zorgen voor een basis copatibiliteit maar zelfs MS denkt daar heel anders over.

dat virtualisatie een tussen oplossing is ben ik met je eens, het zou beter zijn als er mensen waren die cygwin (of moet het sygAIX noemen) zouden porten een soort wLine ??

anderzijds staat het jullie bedrijf natuurlijk ook vrij om een SourceForge accountje aan te maken en de make scripts en eventuele patches vrij te geven ... kans is dat deze na verloop van tijd ook door andere worden gedebugged en/of door de officiele dev worgen overgenomen naar de mainline ... want DAT is natuurlijk OOK oss (zelf code aanleveren)..

Door Tweakers user terje7601, dinsdag 14 december 2010 12:16

Ik ben zeker geen kenner, maar wat is er mis met deze:
MySql
Postfix
gcc
?

Door Tweakers user Typnix, dinsdag 14 december 2010 13:23

terje7601 schreef op dinsdag 14 december 2010 @ 12:16:
Ik ben zeker geen kenner, maar wat is er mis met deze:
MySql
Postfix
gcc
?
MySQL en Postfix: touchť.

GCC: De schrijver van de blog schrijft hier ten eerste over een versie voor x86(32 bit) dus niet eens SPARC64 en het is oude versie. GCC zit nu op versie 4.5.1 en de schrijver heeft het hier over versie 4.2.4. En de schrijver heeft het ook geprobeerd met 4.4.x maar dat lukt niet omdat GCC niet kan bepalen hoe het zit met de endianess.
Over 4.5.1 x86_64 kan ik persoonlijk zeggen dat die ook nog niet kan werken omdat in libgmp een bug zit die te maken heeft met de macroprocessor.

Moet je nagaan dat hebben we het niet eens over de SPARC64 versie gehad, waar het eigenlijk allemaal omgaat :X

Hetzelfde geldt ook voor GCC voor POWER. 4.2.4 compileert wel maar recentere versies weer niet omdat in Libmpfr een bug zit die ervoor zorgt dat deze ook niet kan gecompileerd kan worden.

Beide gevallen heb ik in privťtijd mogen ondervinden, trouwens.

Door Tweakers user Typnix, dinsdag 14 december 2010 14:13

i-chat schreef op maandag 13 december 2010 @ 22:17:
ik denk JUIST dat het een nuttige manier is, OSS software is natuurlijk vrij makkelijk te draaien op elke arch, je hoeft hef immers alleen maar hercompilen ..
Als dat zo was dan was het porten niet zo'n probleem geweest maar het tegendeel is waar. Je hebt te maken met verschillende cpu architecturen die allemaal flink afwijken op het gebied van bijvoorbeeld omgaan met bytecode en broncode in het algemeen als je multiplatform werkt. Je hebt niet alleen maar te maken met het OS maar ook met het systeem waarop je het compileert. Dat is het nadeel van multiplatform ontwikkelen.
En dan heb ik het niet eens gehad over de verschillen tussen compilers die een applicatie kunnen maken of breken.
dat dit in de practijk vaak niet werkt omdat er een vaak bedrijf zo nodig afwijkend wil zijn,
je zegt zelf dat het niet sun/oracle's taak is om te zorgen voor een basis copatibiliteit maar zelfs MS denkt daar heel anders over.
Waarom zou het de verantwoordelijkheid moeten zijn van Sun of IBM en zelfs Microsoft om bijvoorbeeld ervoor te zorgen dat een vage library die door een nog grotere applicatie wordt gebruikt dat die ook op hun systemen werkt, terwijl ze eigen oplossingen hebben die velen malen makkelijker zijn in gebruik met ook nog eens support?

Ik zie het nog niet gebeuren dat Microsoft bijjvoorbeeld developers neerzetten op het Wine project laat staan specificaties geven over hoe Windows in zijn werk gaat met applicaties om maar een zijstraat te noemen.

Achterwaartse compatibiliteit kan je alleen geven als het algemeen plaatje uiteindelijk weinig veranderd is. Als het alleen maar een paar linkjes waren een kernel emulator dan valt het nog mee. Dit veranderd even als er wordt verschoven en applicaties verdwijnen en andere ervoor in de plaats komen met als gevolg dat applicaties van derden aangepast moeten worden naar de nieuwe situaties of je moet zeggen als maker dat je een dubbele omgeving hebt: een nieuwe situatie en een oude. Maar dan zie je de bomen door het bos ook niet meer.
dat virtualisatie een tussen oplossing is ben ik met je eens, het zou beter zijn als er mensen waren die cygwin (of moet het sygAIX noemen) zouden porten een soort wLine ??
Dat is niet mogelijk omdat mocht je alle reguliere AIX, HP-UX en Solaris applicaties weghalen die impact zou kunnen hebben op het systeem, dat de kans heel groot is dat je met een zodanig reduceert pakket overhoud dat er practisch niets meer mee kan doen.
Ook is het verschil qua performance is niet te vergelijken van een x86 met een POWER of een SPARC processor. Het mooiste zou zijn als het mogelijk is om bijvoorbeeld met Qemu een POWER processor te kunnen emuleren maar dat gaat niet omdat het ontwerp van de x86 het niet toelaat en de ontwikkeling in het algemeen tergend langzaam is.
anderzijds staat het jullie bedrijf natuurlijk ook vrij om een SourceForge accountje aan te maken en de make scripts en eventuele patches vrij te geven ... kans is dat deze na verloop van tijd ook door andere worden gedebugged en/of door de officiele dev worgen overgenomen naar de mainline ... want DAT is natuurlijk OOK oss (zelf code aanleveren)..
Daar ben ik het wel mee eens dat bedrijven meer mogen meedoen als het hier om gaat.
En dat gebeurd ook wel maar je ziet ook dat er genoeg bedrijven zijn die zijn eigen versies erop nahouden die zodanig afwijken van de originele broncode.
Voor mijzelf ben ik helaas beperkt dat ik het porten alleen in mijn vrije tijd mag doen.
Vind het overigens niet erg want dit het soort werk wat ik alleen thuis kan doen vanwege de rust en de mogelijkheden. Ik zit er persoonlijk niet erg op te wachten dat er over mijn schouder wordt meegekeken of ik het allemaal al klaar heb.

Reageren is niet meer mogelijk