Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Open source … een déjà vu

Open source software, veel van de lezers gebruiken het al in meer of mindere mate. Misschien niet altijd bewust, maar het zit al op zoveel plaatsen verweven dat we er haast niet meer om heen kunnen. Het is echter ook zo dat de meesten niet echt de sources gebruiken, maar reeds gebouwde producten, gebaseerd op open source code. Op het moment dat je met de broncode aan de slag gaat kun je voor een paar leuke uitdagingen komen te staan.

Onlangs kreeg ik de vraag om eens te kijken of ik één van de open source pakketten die we gebruiken ook zelf gebouwd kon krijgen, dit in verband met lange-termijn onderhoudsverplichtingen (tot nu toe was er een reeds gebouwde versie in gebruik). Zo gezegd, zo gedaan … dacht ik.

Het downloaden van de source code was uiteraard het begin, en met behulp van internet was al snel gevonden hoe je zou moeten kunnen bouwen. Dit begon met het downloaden van een drietal ondersteunende producten. Na het nodige gestoei om systeemvariabelen en paden goed te zetten lukte het zowaar om te bouwen. Uiteraard volgde daarop een test om te kijken of een en ander nog werkte, die al snel faalde op missende header files in het gebouwde product. Een zoektocht op internet leverde na verloop van tijd op dat er blijkbaar een regeltje ontbrak in de instructie die ik gevonden had.

Om een lang verhaal niet nog langer te maken: na zeven additionele tools/libraries geïnstalleerd te hebben was ik eindelijk in staat de binaries te reproduceren. Alhoewel...  bij de gedownloade binaries stond nergens vermeld welke versies van de additionele tools/libraries gebruikt zijn bij het bouwen van die ene versie, dus of ik nu echt hetzelfde heb gereproduceerd is nog maar de vraag.

Voor het vervolgproject is al aangegeven dat men naar een nieuwere versie van betreffend open source product wil. Tijdens het zoeken naar de instructies voor de huidige versie bleek dat het bouwen van de nieuwe versie wezenlijk verschilt van de bestaande. Ik zie de bui dus al weer hangen.

De oudere jongeren onder ons, die eind jaren negentig al met Linux werkten, herkennen wellicht veel van dit verhaal. Destijds moest je ook, om één pakket aan de praat te krijgen, talloze andere pakketten downloaden en zelf configureren en bouwen. De hele exercitie leverde me dan ook een groot déjà-vu gevoel op. Nu, zo'n vijftien jaar later is Linux veel volwassener geworden, en neemt het package management systeem je nagenoeg al het werk uit handen.

Hopelijk krijgen we op termijn voor het zelf bouwen van open source iets vergelijkbaars.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5597009). © Jaarbeurs IT Media.
6,8

 

Reacties

Dat is er al lang.
Bijv. Maven of Gradle.

Volgens mij hangt het sterk af van de soort applikatie. Wanneer je met GCC werkt kom je onvermijdelijk terecht in dit soort versie vraagstukken.

Bij zoiets als Perl is dat al aanmerkelijk minder. Toegegeven, ik ben geen C-ontwikkelaar, hoeft ook niet vanwege het pakketmanagement dat programma's praktisch gebruiksklaar levert en de updates nalevert.

Wat ik in deze markt zie, is dat er reklame gemaakt wordt met "open source" voor produkten waar dan voor het onderhoud betaalt wordt. Daar is niets mee mis maar vaak probeert men zijn markt dan toch te beschermen door gebrek aan dokumentatie of ingebouwde onnodige komplexiteit.

Het nadeel van open source is nu eenmaal dat je alleen aan de service kunt verdienen en niet aan het produkt. Dat is zakelijk een moeilijke afweging omdat je verdienmodel anders is/wordt en dus een ander soort konkurrentie voortbrengt de kunst is daaruit voordeel te halen.

Juist dit punt is lastig bij de selektie van open source software, kies je het verkeerde dan klapt zo'n projekt in zichzelf in elkaar.

@Peter: voor bepaalde open source producten zal je uitspraak vast en zeker gelden, maar als het zo eenvoudig was voor alles dan had ik het artikel niet geschreven

@Jan: ik weet niet of het opzet is (de marktbescherming), interessante gedachtengang. Wat ik wel merk is dat het ook heel erg afhangt van het platform. Vooral op het moment dat je cross platform gaat werken wordt het soms behoorlijk tricky en complex (bijv. iets wat oorspronkelijk op linux ontwikkeld is proberen te bouwen met visual studio)

Dit is een interessant artikel, maar de beschreven problemen zijn niet representatief voor alle open source software. Zoals Peter al aangeeft maakt veel OSS gebruik van Maven, Gradle, of iets vergelijkbaars.
Helaas zal dit artikel door sommige mensen gebruikt worden om te roepen dat alle OSS rotzooi is.

Commerciele software heeft de beschreven problemen niet, want die kan je niet zelf bouwen. Maar als je die wilt uitbreiden of aanpassen loop je tegen dezelfde soort problemen aan. Ga maar eens een extensie voor Sharepoint (of Alfresco, maar dat is OSS) maken. Of een SAP implementatie, wat Jacob Spoelstra vandaag vergelijkt met 'slow TV'.

Even het één en ander op een rijtje:
De "open source" software is wel degelijk eens gemaakt, en de maker(s) had(den) inzicht in hoe het product gemaakt is.
Goede software maken is zeer moeilijk en niet iedereen kan dat.
De IT arbeidsmarkt is behoorlijk verziekt met mensen die niet deskundig en vakbekwaam zijn; die op de verkeerde plek zitten.

Ik vrees dat er een nieuwe lichting is die niet meer in staat is om het oude niveau te halen.

@Steven: iets een keertje maken is één, iets reproduceerbaar herhalen en goed documenteren is iets anders.
Ik ben het met je eens dat de schoolverlaters meer moeite hebben dit te reproduceren. De instructie die ik gemaakt had wilde ik laten checken door een schoolverlater die momenteel hier rondloopt, en die ging behoorlijk de mist in door
a) slecht lezen
b) gewoon op "next" of "ok" klikken zonder te lezen wat er nu stond
c) geen idee hebbend wat hij nu aan het doen was

Wat ik in de loop der jaren vaak gezien heb is dat iets op de PC van een ontwikkelaar of open-source-thuiswerker bouwt, maar op het moment dat de code geporteerd wordt naar een andere PC de problemen van het reproduceerbaar bouwen beginnen. De ontwikkelaar heeft bepaalde libraries ooit geïnstalleerd gehad, welke nu gebruikt worden, maar weet niet meer waarvandaan en welke versie. Op zijn PC staan wat aliasses en andere settings die op het andere systeem niet staan en ga zo maar door. Je moet dan in een woud van variabelen in installaties gaan zoeken naar de 10 verschillen.


@Nico: waar sommigen nog wel eens de mist mee ingaan op dit gebied is dat men source code management goed in place heeft, maar vergeet dat je ook de omgeving moet managen wil je iets kunnen reproduceren. Bij bedrijven die de kost verdienen met sw producten is hier wellicht wat meer aandacht voor dan bij een open source gemeenschap.

PaVaKe, zoals altijd weer leuke opinie van jou hand.

Ik gebruik steeds meer codenvy.com dat lost het probleem op dat iedere computer anders is ingericht...

Wat betreft aanpassen van open source... als je de master / origin van de source niet kan aanpassen met je verbeteringen, wees dan inderdaad bewust welk pad je inslaat. Ik ben veel geforkte open source tegen gekomen en die paden lopen vrijwel altijd dood of zijn zeer duur om te onderhouden, als er voldoende markt is, pak dan de essentie van iets wat doet wat je wilt en maak het volledig eigen, dus je eigen (open) source.

Niets is zo frustrerend om je conformeren aan een architectuur die net even anders opgezet is dan voor jouw probleem en onderhoud is een drama.

Dus of zelf goed maken of adopteren en eventueel de source verbeteren....

@Paveke
[quote]Wat ik in de loop der jaren vaak gezien heb is dat iets op de PC van een ontwikkelaar of open-source-thuiswerker bouwt, maar op het moment dat de code geporteerd wordt naar een andere PC de problemen van het reproduceerbaar bouwen beginnen. De ontwikkelaar heeft bepaalde libraries ooit geïnstalleerd gehad, welke nu gebruikt worden, maar weet niet meer waarvandaan en welke versie. Op zijn PC staan wat aliasses en andere settings die op het andere systeem niet staan en ga zo maar door. Je moet dan in een woud van variabelen in installaties gaan zoeken naar de 10 verschillen. [/quote]

Dit probleem is volgens mij niet uniek voor open-source, maar een probleem voor alle omgevingen waar software gemaakt wordt. Daarom zie je ook steeds meer (open en closed source) integration en build omgevingen opkomen.

Zo snel je met meer dan 1 ontwikkelaar zit te werken aan dezelfde codebase is het sowieso verstandig om een dedicated build machine te maken. Tegenwoordig een stuk makkelijker met de eenvoudige tools om b.v. een VM in te richten.

Story of my live....

Soms ben ik dat ook wel een beetje zat hoor,dan neem je de elende van ongewenste nieuwigheden gnome3, systemd ect maar voor lief, je wil ook verder.

Feit is dat je dit probleem met commerciele closed source software ook hebt, al eens geprobeerd Quartus 10.1 op een 64bit Linux systeem werkend te krijgen ? Je heb die versie nodig als je iets met Cyclone-I FPGA's wil doen...

@PaVaKe
waarom zou je een ontwikkel-omgeving van Linux naar Windows porteren?
Een virtuele Linux is toch geen groot probleem meer, of wil je de tools behouden die je gewend was, dan is die keuze wellicht niet de beste.
Crossplatform vindt je hoofdzakelijk bij java-applikaties en webapplikaties. Crossover van codeweavers
(https://www.codeweavers.com/) om Windows-software op linux te draaien heeft ook zo zijn beperkingen maar kan evt. je probleem oplossen.

@Henri
Dat forks vaak doodlopen klopt, maar ook projekten die aan 1 ontwikkelaar hangen dragen een risiko, namelijk dat die er mee stopt. Overigens wanneer je een projekt ombouwt voor je eigen gebruik, stel het dan ook weer ter beschikking, dat hoort bij FOSS.

@Benno: voor een gecontroleerde omgeving zoals een kantoor is dat makkelijker te realiseren dan voor een open source community waar de ontwikkelaars thuis zitten te werken.

In mijn dagelijkse omgeving hebben de ontwikkelaars gedefinieerde installaties, en zijn de bouw- en testmachines op dezelfde manier ingericht. Hiermee voorkomen we veel problemen, maar het kan nog altijd voorkomen dat een ontwikkelaar lokaal iets anders heeft gezet waardoor het op de bouwomgeving alsnog misgaat. In dat geval zijn de afspraken heel helder: de bouwomgeving is leidend.

@Jan: voornamelijk omdat we in de afdeling waar ik werk alles op windows doen. Ik zou het misschien ook wel aan de praat krijgen in een (al dan niet virtuele) linux omgeving, maar iemand moet die omgeving ook nog kunnen managen\gebruiken als ik er niet ben.
Vanwege lange onderhoudsverplichtingen is het streven zo min mogelijk uitzonderingen op de standaard te hebben.

Ya pa, the goodold dependency en reproduce hell.
yum/yast over rpm, apt over dpkg voor linux binaries ?
freebsdports en wellicht gentoo voor bsd/linux sources ?
Misschien moeten we Cloud fluisteraar Henri volgen, opensource kan steeds vaker ook van de plank. hahaha, Henri volgen. Wat zeggik nu ? Vooruit dan maar. Mooi weer en bijna weekend. wtf.


@pa va ke;

zijn er spec files of source rpms beschikbaar? dan kun je yum gebruiken om aan al je build dependancies te voldoen. Voor oeloeboentoe en afgeleiden kun je apt-get gebruiken om de source package binnen te halen en de build te doen en alle dependancies op te lossen. Dat is vaak een makkelijker startpunt om daarna zelf een package te maken met de nieuwere versie van de software en te maintainen.

Het artikel lijkt mij te gaan over ontwikkelaars die niet bij blijven met de ontwikkelingen en daardoor in het verleden blijven hangen.

Ga anders maar eens een .net 2.0 applicatie porten naar .net 4.x en je komt soortgelijk 'gedoe' tegen met afhankelijke libraries. En zul je e.a. aan moeten passen ivm veranderde api's.

Dat er nog meer geautomatiseerd kan worden in deze tak van de ontwikkelsoftware staat als een paal boven water. Maar blijkbaar is op dat vlak de innovatie niet zo noodzakelijk om de mensen zich goed kunnen redden met wat ze hebben.

Felix, RedHat (of een derivaat ervan) is op zich een prima keuze voor de enterprise markt.
Maar first of all, het is niet de enige keuze en ook niet speciaal de keuze voor developers.
Ik denk dat is het voorbeeld van Pascal (van Kempen that is) het wel handig zou zijn als de documentatie (if any) zou verwijzen naar de vanila versies van de mee te linken libs.
Maar al te vaak roepen developers dat ze geen gepatchte versies ondersteunen (Ubuntu, Debian, RedHat, SuSe allemaal halen ze die ongein uit)
Overigens Pascal, een opmerking van je valt me tegen.
Je onderbouwing voor het porten naar Windows zie ik in essentie als onvermogen om gekwalificeerde colega's te vinden (op zich weer een bekend probleem)
Als dat werkelijk het probleem zat kun je beter alles in Java en DotNet bouwen en elke vorm van inovatie diep in een lade duwen.

Overigens dank voor je interesante opinie en de reacties hierop.

@spec: volgens mij heb je wat gemist in de reacties. Het gaat hier om een poging iets te bouwen op een windows omgeving, dus rpm en spec files gaan met niet helpen zover mijn kennis reikt

@Peter: ja en nee. Er zit een groot verschil in applicaties die je zelf ontwikkeld hebt, waar de kennis van in huis is en welke goed gedocumenteerd is of een brok software waarbij je afhankelijk bent van een community.
Overigens een gewaagde uitspraak over ontwikkelaars die je doet. De mensen waar ik mee werk zijn van een iets ander kaliber dan de uurtje-factuurtje codekloppers van bijv. een cap-gemini, neem dat maar van me aan.

@Pascal: er zijn natuurlijk meerdere wegen die naar Rome leiden hoe dit probleem te tackelen. Een linux omgeving opzetten en bijbehorende kennis inhuren/eigen maken is er één van. Ik heb in één van mijn vorige banen in een een hybride omgeving (linux/unix/windows) gewerkt, en ook dat brengt de nodige uitdagingen met zich mee als het gaat om portabiliteit / compatibiliteit. It's all about choices.


Ik herken de problematiek zeker. Kennelijk val ik onder de oudere jongeren met een leeftijd van 40.

Zeker als je een halfdood pakket probeert te gebruiken, dat grotendeels op een bepaalde revisie is blijven steken, loop je tegen dit soort problematiek.

Probleem is de 'wildgroei'. Was het vroeger FunctieXY(ArgumentA, ArgumentB) dan is het nu bijvoorbeeld FunctieXY(ArgumentA,ArgumentB,ArgumentC). Tijdens het compileren gaat dat natuurlijk helemaal mis en moet je terug gaan werken met de libraries totdat je dezelfde compileerbare functies weer hebt. Andere oplossing zou zijn uitzoeken wat ArgumentC doet en het overal in de broncode vervangen.

Aan het eind van je exercitie heb je wel het pakket draaiende gekregen, Pavake.. Bij closed sourced van een overleden leverancier kan je gewoon niets meer doen.

@pa va ke

yep, maar ook bij het nogmaals lezen van je eigen stukje, was mij dat ook niet geheel meteen duidelijk ;).

ken je mingw? http://www.mingw.org/ verder deel ik wel de menig van anderen; je bent met symptoom bestrijding bezig door zo iets op windows te willen doen waar het OS dus niet de meest logische keuze voor is omdat de tools op dat OS haaks op een unix filosofie staan.

Zelf heb ik me regelmatig vervloekt om een eenvoudige portable c++ code die op elk POSIX systeem dat er was (en DOS met borland destijds) zonder problemen compileerde en slechts een make file van 10 regels nodig had in de MS visual c++ IDE te krijgen. Mijn god hoeveel buttons en dialogen je door moest en extra .dlls toevoegen voordat er een .exe kwam. Toen ik eenmaal ook het knopje gevonden had wat de IDE onder de kap dan als commando uitvoerde, heb ik daar maar heel snel een .bat van gemaakt en nooit meer naar die IDE specifieke gekeken. Anderen zullen wel anders vinden.



@spec \ @pascal: de keuzes die gemaakt zijn, zijn voor een buitenstaander wellicht niet altijd logisch, maar in een streng gereguleerde omgeving waarin ik werk gelden soms andere criteria dan de meest logische.

Dit heeft alles te maken met het moeten valideren van ontwikkelomgevingen etc. alvorens wij producten op de markt mogen zetten. Overstappen naar andere compilers (mingw) of OSsen (Linux) heeft daardoor nogal wat voeten in aarde.

(het moeten installeren van allerlei "hulp-tools" om iets te kunnen bouwen is soms onontkoombaar, maar brengt dus soms ook het nodig extra werk met zich mee)

Computable Expert
Pa  Va Ke

Pa Va Ke
Configuration Management / Product Lifecycle Management, -. Expert van Computable voor de topics Development, Beheer en Zorg.
Hele profiel

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×