Tool maakt Linux-applicaties makkelijk uitwisselbaar

Een student van de Stanford-universiteit in het Amerikaanse Palo Alto heeft een tool ontwikkeld waarmee Linux-applicaties makkelijker tussen meerdere pc's kunnen worden uitgewisseld, zonder dat een gebruiker in dependency hell terecht komt.

Door de verscheidenheid aan Linux-distributies, kernelversies en versies van softwarebibliotheken, is het allerminst vanzelfsprekend dat een voor Linux ontwikkelde applicatie op een pc direct werkt. Een applicatie kan op meerdere andere programma's leunen, die op hun beurt weer andere softwarepakketten vereisen. Dit fenomeen, ook wel dependency hell genoemd, kan grotendeels worden omzeild door een pakketbeheerder te gebruiken, zoals apt of rpm, die automatisch de vereiste applicaties opzoekt.

Toch kan het voorkomen dat een pakket niet kan worden geïnstalleerd of niet werkt, doordat een bepaalde library of versie van een library niet aanwezig is in de gebruikte software-repositories. Om dit probleem op te lossen, heeft Stanford-student Philip Guo een tool ontwikkeld waarmee de benodigde software en vereiste bibliotheken samen met een applicatie worden ingepakt, waardoor software kan worden uitgevoerd op andere systemen die zonder deze omweg niet compatibel zouden zijn. Bij het uitvoeren creëert CDE een sandbox met benodigde bibliotheken en executables.

Overigens werkt de tool, met de naam CDE, niet in alle gevallen: pc's moeten dezelfde architectuur gebruiken, bijvoorbeeld x86. Bovendien moeten beide computers een kernel uit dezelfde branch gebruiken: een applicatie die is 'ingepakt' op 2.6, werkt niet onder 2.4; andersom kan dat in bepaalde gevallen wel. Guo benadrukt dat zijn tool niet als concurrentie voor pakketbeheerders is bedoeld; het zou slechts een simpele manier zijn om code op een ander systeem te kunnen uitvoeren.

Volgens Guo kan CDE van pas komen bij het delen van programma's met collega's of het uitproberen van andermans software, zonder dat er root-privileges vereist zijn of dat er software hoeft te worden geïnstalleerd. Ook kunnen meerdere versies van een programma op hetzelfde systeem worden getest, zonder dat er conflicten tussen softwarebibliotheken ontstaan.

Reacties (104)

[j0bro]

Het lijkt wel op de Windows Installer, waarbij je de zoveelste instantie van een DLL meekrijgt. Dit kost allemaal schijfruimte voor de installer, onnodig veel tijd met installeren en een mogelijk risico op conflicterende libraries omdat er meerdere keren dezelfde library op één systeem geïnstalleerd wordt.

Het idee van de dependencies onder de meeste Linux-distro's is juist dat er zoveel mogelijk shared code in libraries geleverd wordt. Wat is er moeilijk aan 'apt-get install <package>', enter? Goed, als je van source gaat compileren, zul je de libs er zelf bij moeten zoeken, maar ook hiervoor bieden de meeste package-managers uitkomst: 'apt-get depends <package>' uit mijn hoofd bij de Debian-derivaten zoals Ubuntu, en voilà, je hebt alle libs die nodig zijn voor compilatie.

Edit: typo's

[Reactie gewijzigd door j0bro op 22 juli 2024 19:47]

[bassekeNL]

Dat er meerdere versies van een library op een computer staan is niet zo'n probleem, zolang ze niet door elkaar gehaald worden door andere programma's. Met dit soort technieken komen er echter ook meerdere exemplaren van dezelfde lib op een computer te staan.

Oudere libraries kunnen problemen geven als ze voor veiligheidslekken zorgen. Zodra je niet meer kunt controleren welke libs gebruikt zijn door de geïnstalleerde programma's loop je dus extra risico.

[cibrhusk]

Mee eens, normaal gesproken om bijv te oude programma's niet in de weg te zitten:
mylib.so wordt geupdate en mylib.so.1 wordt neergezet, mylib.so wordt vervolgens gelinkt naar mylib.so.1 wanneer deze compatible blijven. In gevallen waar ze niet compatible zijn worden er wel twee versies gehouden (dus geen gelink).
Als je recente applicaties gebruikt zal de oude lib al snel in onbruik raken en met een apt-get autoremove (debian based) wel weer verdwijnen. Het is ondertussen zowieso al niet meer verstandig te noemen om veel buiten de apts and yums om te gaan, en dan datgene dat je niet via die weg doet in /opt te gooien, voor je overzicht.

(overigens is het niet apt vs rpm, maar apt vs yum of dpkg vs rpm - maar goed)

Al met al speelt dit probleem vaak als je een erg nieuwe applicatie op een oude linux distro wilt zetten. Zo moet ik soms voor het oude fedora 8 pakketten neerzetten die echt niet meer willen. Er worden in static distro's veelal geen nieuwere versies introduceert dus van yum krijg je het niet, zelf updaten met source code wil wel, maar is al snel een dep-hel. Dan kun je eventueel proberen op een nieuwe fedora en vervolgens compilen met libraries static meegenomen, resultaat proberen op oude fedora. Al snel een puinzooi.
Het probleem is natuurlijk dat die oude fedora 8 gewoon allang niet meer had mogen draaien en geüpdate had moeten worden. Daar zijn wel meer redenen voor.

Al met al kom ik de dependency hell overigens nauwelijks nog tegen nu ik vooral met apt werk. Voor al die keren dat ik het wel tegen kom weet ik al dat die machine eigenlijk niet meer veilig zo'n oude distro kan gebruiken (meestal al geen updates meer).

Evengoed is het een welkom project.

[Reactie gewijzigd door cibrhusk op 22 juli 2024 19:47]

[Relief2009]

Ach ja met zulke codes om zaken goed geïnstalleerd te krijgen wordt Linux zeker populair onder de niet-techneuten.

Is er dan echt geen enkele OS onder Linux die qua installatie en gebruik net zo goed werkt als Windows? Ik heb het niet over wat Tweakers makkelijk vinden, ik heb het over wat de gemiddelde Jantje makkelijk vindt.

[Nickname55]

Is er dan echt geen enkele OS onder Linux die qua installatie en gebruik net zo goed werkt als Windows? Ik heb het niet over wat Tweakers makkelijk vinden, ik heb het over wat de gemiddelde Jantje makkelijk vindt.

Als je gewoon een distro als bijv. Ubuntu of Fedora neemt en je gebruikt gewoon apps uit de eigen repo's is er helemaal niks aan de hand, werkt alles als een tierelier en kan je gewoon grafisch in de pakket beheerder klik klik doen wat je maar wilt hebben. Alles werkt gewoon zonder moeilijk gedoe, Jantje kan dat zeker, sterker nog, het is nog makkelijker dan bij Windows. Het word pas een probleem als Jantje een app op internet vind en die wilt installeren.

[actionInvoke]

Ik denk dat je Jantje bij het woord Repo al kwijt was.

[thegve]

Daarom noemen ze het ook een pakketbron in de Nederlandse versie . Maar ook daar hoef je je helemaal niet druk over te maken. De eerste keer dat je hem start, krijg je de vraag "wil je ook gesloten software gebruiken, naast open source?". Dat is dan nog wel een min-of-meer ingewikkelde vraag, maar daar ontkom je niet altijd aan, maar als je dan op OK klikt, zet hij de juiste repo open.
Wat 'wij' als tweakers hier meestal aan commando's posten ben je als gebruiker op zich niet nodig. Ik werk echter van mijn 40 werkuren ongeveer 30 achter de CLI (waarvan 8 omdat ik met servers zonder GUI werk, en 22 omdat ik CLI uberhaubt fijner/productiever vind werken), en dan is het niet zo vreemd dat je een voorkeur voor commando's hebt.

[Antipater]

Tegen Jantje moet je App Store zeggen en dan naar de Ubuntu Software Center verwijzen.

[tehsojiro]

aangezien de computer van Jantje vol zit met virussen en andere malware doordat hij overal maar op "ja" klikt is dat maar beter ook.

[d3vlin]

Naast de command line interface mogelijkheden om pakketjes te installeren zijn er voor vrijwel alle distributies ook talloze varianten met een GUI, bijvoorbeeld (bijvoorbeeld Synaptic). Die werken vrijwel altijd op basis van het principe 'zoek een pakketje uit de lijst, klik er op en het programma wordt inclusief de benodigde libraries en andere dependencies geinstalleerd'. Veel makkelijker krijg je het niet volgens mij.

Ik hoop niet dat je met 'makkelijk' doelt op: "Klik, Klik, Next, Next, Next, Finish, (hey waar komen al die toolbars vandaan?)" .

[Reactie gewijzigd door d3vlin op 22 juli 2024 19:47]

[Lye]

Het overgrote deel aan programma's dat je installeert op linux gaat meestal via een of andere package manager (de programma's die "de gemiddelde Jantje" gebruikt in ieder geval). Installatie via package manager is stukken simpeler dan op Windows; je drukt op install en verder hoef je niks te doen, geen installatiepath kiezen geen nutteloze next knopjes.
Het werkt dus al net zo goed, als het niet beter is.

[dgompie]

En wat VEEL belangrijker is, je kunt meerdere programma's "tegelijkertijd" installeren en de-installeren.

Met nieuwe laptops met Windows, ben ik al gauw een paar uur bezig om alle nutteloze programma's te verwijderen (trial versie selecteren, uninstall, wachten, nog langer wachten, volgende toolbar selecteren, uninstalleren, wachten, wachten, wachten).

[HansvDr]

Tipje: pcdecrapifier

Removes unwanted preinstalled software from Windows XP and Vista machines. Free for personal use, commercial version includes automation capability.

http://www.pcdecrapifier.com/

[thechronic]

Haha fijn om te horen dat er nog niks veranderd is in de Windowswereld.

[bouwfraude]

Ubuntu, het werkt zelfs makkelijker dan Windows.

Een update center voor alle programma's, drivers etc.
Over het algemeen is deze al klaar met installeren terwijl windows nog aan het zoeken is.

En als Jantje een app vindt dan staat het 9 van de 10 keer al in het software centre.
Het restant heeft wel een installer voor ubuntu.

[Reactie gewijzigd door bouwfraude op 22 juli 2024 19:47]

[_JGC_]

Nog nooit zelf geprobeerd dus. Er zijn zat GUI-tools om pakketjes te installeren, en in tegenstelling tot dat gekke Windows waarbij je vervolgens "Windows Update", "Java Update", "Flash Update", "Installshield Update" en "Adobe Update" krijgt die stuk voor stuk alleen de eerstvolgende versie downloaden ipv alleen de laatste versie die je wilt hebben, zorgen die GUI-tools of packagemanagers wel dat je in een keer de software krijgt die je wilt.
Voor de wat populairdere distributies leveren softwaremakers ook gewoon kant-en-klare pakketjes die je met een klik kunt installeren met de meegeleverde packagemanager. Voorbeeld daarvan is Opera, die gewoon voor Debian, Ubuntu, Redhat, etc pakketjes aanbiedt op de downloadsite. Het kiezen van het juiste pakket is niet moeilijker dan kiezen voor een 32 of 64bit versie van Windows waar je tegenwoordig mee zit.

[Blokker_1999]

Is er dan echt geen enkele OS onder Linux die qua installatie en gebruik net zo goed werkt als Windows? Ik heb het niet over wat Tweakers makkelijk vinden, ik heb het over wat de gemiddelde Jantje makkelijk vindt.

Werkt windows dan goed? Ik dacht het niet. Over het algemeen is linux een stuk gebruiksvriendelijker. Zowat alle software die je nodig hebt zit normaalgezien in de repository van je distributie. Je hebt een centraal software beheer waar je de pakketten uitzoekt en installeert. Alle pakketten worden ook mooi samen up to date gehouden, je moet nooit zelf op zoek gaan naar updates.

Het word pas een probleem vanaf dat je software wenst te installeren die niet in je repo voorkomt. En daar komt men nu dus met deze oplossing dewelke hetzelfde doet als onder windows al 20 jaar gedaan word.

[A Noniem]

Ubuntu, dat software center is 10x handiger voor het instaleren van programma's dan alles los van sites downloaden zoals je bij windows moet doen. Dat het dan maar 1 gigantisch setup.exe bestand, zal handig zijn voor de meeste mensen, maar je moet nog wel steeds alles los opzoeken. Bij Ubuntu heb je dat in het software center allemaal bij elkaar.

De gemiddelde tweaker zoals ik zal echter meestal gewoon synaptic gebruiken, of zit uberhaupt niet op ubuntu en zit in arch lekker te kutten in de command line met pacman

[Verwijderd]

gemiddelde jan kan denk ik zelfs wel met ubuntu omgaan. maar ik vraag me af of die wel weet hoe ze uberhaupt een besturingssysteem kunnen booten

[triflip]

dat weet ie perfect, power knop induwen en wachten, voila, besturingssysteem geboot.

[Niemand_Anders]

Maar daar zit eigenlijk ook onder Windows een probleem. Omdat het installeren van programma's zou eenvoudig installeren de Windows gebruikers alles wat los en vast zit. Uninstallers zijn vaak zeer slecht geschreven en laten een hoop troep staan en als gevolg dat na verloop van tijd je systeem nog amper vooruit komt.

De meeste mensen hoeven alleen maar te weten hoe ze hun installatie up-to-date houden. En dat is en blijft het gemakkelijkst als je alleen programma's en libraries gebruikt welke worden aangeboden door je package manager.

[Superstoned]

Vrijwel elke linux is makkelijker met het installeren van apps dan windows.

Je hoeft niet op internet te zoeken naar een app, het uit te pakken, op je desktop of waar je het hebt gezet op te zoeken, te starten, een paar vage vragen te beantwoorden etc - en dat voor elk progamma en elke nieuwe versie weer.

Nee, onder linux ga je naar software beheer, je zoekt op wat je wilt hebben ("webbrowser", of "firefox"), zet een vinkje voor wat je wilt en herhaal dit voor alles wat je wilt installeren. Dan klik op "uitvoeren" en klaar, linux download en installeert alles automatisch. Geen vragen, geen zelf uit pakken of opzoeken en weer opruimen.

Kortom, linux gebruikt al meer dan 10 jaar een appstore model - veel makkelijker dan wat win of mac hebben.

[Zer0]

Wat is er moeilijk aan 'apt-get install <package>', enter?

Dat werkt niet op veel linux distributies, die kennen apt namelijk niet. Daarnaast werkt installeren via een packetmanager alleen goed voor software die in die repo beschikbaar is. Ga je software buiten de repo's om installeren dan loop je regelmatig tegen de dependency hell aan.

[hostname]

Dat werkt niet op veel linux distributies, die kennen apt namelijk niet.

Dan moet je apt-get vervangen door yum, zypper of pacman, maar het principe blijft hetzelfde.

Daarnaast werkt installeren via een packetmanager alleen goed voor software die in die repo beschikbaar is. Ga je software buiten de repo's om installeren dan loop je regelmatig tegen de dependency hell aan.

Ubuntu heeft al 30.000+ packages en dat zal bij de andere grote distro's echt niet anders zijn. En als het niet in de standaard repos zit kan je vaak via bijv. getdeb.net het wel vinden. Ik ben nog nooit software tegengekomen die niet in de repos zit.

Theoretisch zou dat ook niet zo moeilijk mogen zijn trouwens: van bijna alle libraries zijn meerdere versies parallel te installeren. In het ergste geval moet je ook alle libraries zelf compileren.

[Reactie gewijzigd door hostname op 22 juli 2024 19:47]

[elmuerte]

Zo vaak installeer ik geen GNU/Linux software dat niet in de package repository zit. Maar als ik dat doe kom ik echt geen dependecy hell tegen.
Sure, soms moet ik dependencies installeren, maar versie conflicten ben ik nog niet tegen gekomen bij een normale build/install.
Dependency hell komt je bijna alleen tegen als je een package wilt installeren dat gemaakt is voor X op een systeem Y (waarbij Y een stukje ouder is dan X). Je hebt bijvoorbeeld hetzelfde probleem als je in Windows een programma wilt installeren dat Windows Vista niet herkent als een compatible Windows versie.
Maar zo'n beetje alle GNU/Linux software die ik geinstaleerd heb kwam met een redelijk simpele installer en werkte daarna gewoon.
Loli Setup (http://icculus.org/loki_setup/) maakt fijne installers voor proprietry Linux software.

Voor een propretry software maker is het redelijk simpel:
1) maak een package voor de huidige stabiel en meest gangbare GNU/Linux distributies (beetje afhankelijk aan je target audience).
2) voor de rest maakt je een installer voor een statically linked library (in (1) gebruik je shared libraries).

[Reactie gewijzigd door elmuerte op 22 juli 2024 19:47]

[actionInvoke]

"Wat is er moeilijk aan 'apt-get install <package>', enter? "

Jij denkt als een techneut, niet als een mens. Het bovenstaande is een mooi voorbeeld waarom linux nooit een systeem zoals windows zal verslaan. Het is niet zozeer het systeem zelf (dat een goed systeem is) maar de mensen die er mee werken/het ontwikkelen.

[thegve]

Laat ik het vertalen hoe een niet-techneut dit zou moeten doen:
Wat is er moeilijk aan Systeem->Beheer->Synaptic Pakketbeheer->Tekstverwerking->OpenOffice->Toepassen

[Verwijderd]

Dat gaat tegenwoordig nog makkelijker met de nieuwe ubuntu 'app store'

[Neko Koneko]

Klopt: Applications > Ubuntu Software Center > rechtsbovenin naam programma intikken > Installeren > Klaar

Ik vind het echt geweldig dat Ubuntu een software center meelevert, gewoon omdat ik het installeren van applicaties onder Linux voorheen een hel vond (idd vanwege al die dependencies). Ik vind .deb ook veel fijner werken dan .rpm, dat laatste heeft voor mij eigenlijk nooit goed uitgepakt in het verleden. Misschien is het tegenwoordig beter maar ik ben zeer tevreden met Ubuntu. Als het de wlan kaart in mijn andere laptop zou ondersteunen zou ik geen eens meer Windows gebruiken hier

[Erik]

Heb je ndiswrapper al eens geprobeerd? Daarmee kun je windowsdrivers voor wifi gebruiken in linux. Het werkt niet altijd 100%, maar vaak gaat het best goed!

[Quipeace]

Het wordt dan ook pas een echte hell als de lib, of zoals ook al in het artikel wordt vermeld, een specefieke versie van een lib niet te vinden is via apt of een soortgelijke manager.

[Strike_2]

Sterker nog:
Windows 7 bewaart een kopie van de specifieke libraries die door een pakket worden gebruikt.
Per applicatie worden er hardlinks aangemaakt naar de specifieke 'fysieke' libraries.

Hierdoor kan Windows per applicatie een patch terughouden, als deze de applicatie kapot maakt.

Er staan meer details op: http://www.winvistaclub.com/f16.html

[daft_dutch]

>Het lijkt wel op de Windows Installer.
Dat is het dus 100% niet, Het is een package met een volledige Linux omgeving toegewijd aan die ene executable. voor een 100% foolproof oplossing. Dat geen enkel installatie script vereist.

De Linux distros hebben zelf hun distro package manager en zijn ver voorbij de Dependency hell. Met symlinking en globale afspraken in het Linux common core project dat samenwerkt met de grote distros voor Future/MultiDistro/Backward compatibiliteit.

Neemt nog niet weg dat CDE alle dependecies mee neemt dat veel verder gaat dan de scoop van bijna alle distros waardoor Het een zeer sterke tool is.

Linux Installers zijn bashscripts met een embedded gz/tar bestand.

[Verwijderd]

Wanneer houd men eens op met werkelijk alles in externe libs/dll te verpakken i.p.v. de benodigde libs gewoon met de eigen code mee te linken. Dat is veel stabieler, beter testbaar en kan ook nog eens snellere code opleveren door betere optimalisatie mogelijkheden zoals inlining. Vaak wordt toch maar een klein deel van een lib gebruikt.

Voor abstracte interfaces zoals video drivers e.d. is het begrijpbaar omdat deze apart vernieuwd moeten kunnen worden, maar verder is het gebruik van dll/libs vooral inefficiënt, fout gevoelig en onnodig complex.

[humbug]

De belangrijkste reden is dat shared libs minder ruimte op de harddisk en in het geheugen innemen. Ook is het praktischer om standaard componenten te gebruiken ipv elke keer precies de functies eruit te snijden die je wilt gebruiken. Het is dus juist simpeler en minder foutgevoelig en zorgt dat het beschikbare geheugen efficient benut wordt waardoor het ook nog eens sneller is.

Dus eigenlijk leidt jou idee precies tot datgene wat je niet wilt.

[Verwijderd]

Je redenatie gaat mank !

Een shared lib die maar gedeeltelijk gebruikt wordt kan ook MEER ruimte in het geheugen gebruiken, zelfs als er meerde programma's gebruik van maken (er wordt immers per page ingelezen, ook als je maar 150 bytes aan code gebruikt). Dit komt omdat een compiler/linker slechts die stukjes code uit een lib opnemen die nodig zijn voor je programma. Verder heb je snelheidsvoordeel omdat de locality van je code beter is en eventuele executie paden (hele if blocken) uit de lib code weggesneden kunnen worden indien op compile time zichtbaar is dat deze nooit gebruikt gaat worden door je applicatie. En vergeet ook niet dat die libs zelf ook weer gebruik maken van standaard C lib code e.d. net als je eigen programma, dus die dubbel op memory footprint ben je grotendeels kwijt zodra je het als 1 programma linkt.

En sta ook een stil bij het feit dat een library in source vorm net zo standaard is als in gecompileerde vorm, maar wel flexibeler voor de compiler om mee te werken. Je hoeft echt niet stukjes code te gaan kopiëren e.d. om er gebruik van de te maken en zelf te gaan zitten vissen wat mee moet en wat niet. Dat doet de linker voor je!

Volgens hou redenatie zou function inlining voor veel gebruikte functies ook negatief zijn voor de prestaties van een applicatie en dat terwijl dit vaak de grootste performance boost geeft. Zelfs als het resultaat is dat er meer code in het geheugen komt te staan.

Nog iets om bij stil te staan is dat een processor niet zozeer belast wordt door hoeveelheid code en data, maar vooral door de voorspelbaarheid van de executie paden en memory accesses. Vandaar die zeer heftige branch prediction en prefetching tegenwoordig. Dus als jou gebruik van een stuk shared code anders is dan dat van een ander programma, dan laat je de processor vaker mis gokken, en dat KOST weer prestaties.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:47]

[cibrhusk]

Zoals ik er naar kijk:

Linux bevat libraries die veelvuldig door vele programma's worden aangeroepen. Deze nemen maar 1x geheugen in en zijn in jouw verhaal ook echt een stuk efficiënter voor de cpu. In jouw geval nemen meerdere applicaties met stukjes uit libraries vaak meerdere malen geheugen in voor dezelfde functies. Erg inefficient en voor de processor zijn executie paden ook niet bepaald voorspelbaar. Je verhaal gaat dus alleen op voor libraries die minder gebruikt worden. De waarheid ligt in het midden.

De praktijk is overigens dat een gemiddelde linux distro na boot nog geen 400MB geheugen gebruikt en met software techniek anno 2010 nog steeds goed draait op hardware techniek anno 1995 (helemaal als je het houd bij CLI). Dus die praktijk meegenomen vermoed ik dat de waarheid uiteindelijk meer aan de kant van humbug staat dan bij jouw, ondanks je kennis...

//
Overigens is het volgens mij zo dat ook bij shared libraries nooit de hele librarie in het geheugen zit, maar alleen de delen die veelvuldig of zojuist zijn aangeroepen. Dus als ik het niet mis heb gaat daar merendeel van je redenatie al mank.
Vermoed wel dat Windows hier totaal anders mee omgaat dan Linux of andere Unix-achtige

[Reactie gewijzigd door cibrhusk op 22 juli 2024 19:47]

[A Noniem]

Mijn Ubuntu instalatie gebruikt op dit moment bij opstarten ~420mb, omdat ik het vol heb gegooid met allerlei shit (dropbox, dock, compiz effects). Ik heb de laatste tijd heel wat linuxjes geïnstaleerd en de kale instalaties namen bij opstarten iets meer dan 100mb ram in beslag bij het opstarten (kde gebruikt denk ik wel iets meer, maar lxde/gnome/xfce ontloopt elkaar niet gigantisch).

[Reactie gewijzigd door A Noniem op 22 juli 2024 19:47]

[Verwijderd]

Ik gaf al aan dat er van paging gebruik wordt gemaakt, dus het zijn altijd blokken van 4KiB of een veelvoud daarvan (afhankelijk van het OS). Het maakt eigenlijk niet eens echt uit of er veel applicaties gebruik van een lib/dll maken, tenzij die lib/dll echt groot is. Tegenwoordig past wat betreft actieve code "vrijwel" alles in de cache. Ik geloof niet dat het sharen van veelgebruikte functies hier nu een prestatiewinst op gaat leveren. Zoals ik al aangaf, is het belangrijkste de voorspelbaarheid en het niet executeren van voor het hoofdprogramma irrelevante code zoals if constructies die altijd waar of onwaar zijn wanneer aangeroepen vanuit applicatie X. Want als de processor een verkeerde gok maakt, dan wordt de pipeline flushed en moet een hele reeks van instructies opnieuw uitgevoerd worden. En met 70+ instructies (met memory fetch dependancies) in flight, is dat een heel dure grap!

Bovendien is paging ook op applicaties van toepassing. Een linker optimaliseert hiervoor door elkaar aanroepende functies zoveel mogelijk te groeperen. Dus gebruik je een deel van de applicatie niet, dan hoeft dit ook niet in het geheugen te komen.

Een ander bijkomend voordeel van inlining (als je de lib source mee compileerd) is dat het andere optimalisaties mogelijk maakt die het aantal uit te voeren instructies drastisch kan reduceren (vandaar ook zoveel snelheidswinst). Ook zaken als loop unrolling worden mogelijk, waarbij het aantal branches sterk afneemt.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:47]

[cibrhusk]

Na enig onderzoek zie ik dat u gelijk hebt wat betreft performance van de applicaties. Ook geeft het meer stabiliteit, althans een grotere kans op stabiliteit omdat het vooral afhangt van de library of deze in shared vorm instabiliteit veroorzaakt.

Er zijn wel maren:
Libraries die veelvuldig gebruikt worden staan allemaal al in het geheugen wat wel meer snelheid geeft, maar niet in alle opzichten. Een applicatie kan sneller opstarten omdat zijn executables kleiner zijn en de rest idealiter al in het geheugen zit. Een applicatie draait langzamer omdat het afhankelijk is van derden, hoeveel langzamer hangt af van de dynamic linker in kwestie en de library zelf (de gnu dynamic linker is een stuk efficienter dan de microsoft tegenhanger).
Al met al werkt een gnu gebasseerd systeem bijna volledig volgens shared library principe wat ten goede gevolgen heeft voor de overall performance - dit soort systemen gebruiken minder geheugen, hoeven nooit of zelden te swappen en hoeven ook zelden iets van de harddisk te laden dat niet al in het geheugen zit. Zodoende kun je het systeem zwaarder belasten en gaat multitasking volgens mij ook efficienter

De grootste maar zit hem in updates & beveiliging, er komen veelvuldig security problemen of bugs aan het licht in libraries, in static geval moet ik al die applicaties controlleren op de versie van de library die ze mee gecompileerd hebben en deze allemaal bijwerken. Dat is veelal ondoenlijk en soms zelfs onmogelijk.
Bij een shared library kan je de library bijwerken en is dat afdoende voor alle programma's dit het gebruiken. U noemt dat verderop een singlepoint of failure, maar het is maar hoe je er naar kijkt want qua security trek je volgens mij toch aan het korste eind als je alle applicaties moet nagaan - of moet vertrouwen dat een ander dat voor u doet. We moeten er natuurlijk niet lichtzinnig mee omspringen bij een library update, maar gelukkig is op het moment dat jij hem aangeboden krijgt deze al door verschillende partijen gecontrollleerd en voorzien van hashes en gpg certicaten. Als sys admin behoev ik dus niet al het werk te doen. Nog steeds lijkt het ideaal voor een cracker om zich op libraries te richten, maar in de praktijk blijkt dat te ingewikkeld en kiezen deze er eerder voor om executables te proberen te vervangen middels gaten in het huidige systeem.
Al met al moet ik toegeven dat er in de wereld van gnu wel heel strak gewerkt moet worden bij ontwikkeling van libraries om de boel niet op zijn gat te helpen, maar volgens mij is dit nu juist ook weer een voordeel gebleken doordat iedereen gedwongen wordt pietje precies te werken.

Ik zal al met al wel in mijn hoofd meenemen wat u hebt uitgelegd over performance en voor een enkele applicaties er mogelijk nu wel gebruik van maken. Dank dus voor u uiteenzetting, want ik begrijp nu wel dat een applicatie zelf er niet beter van wordt.

[scsirob]

Dat zou prima werken als er niet zoveel versie verschillen tussen DLL's en libraries waren. Inmiddels installeert bijna iedere Windows applicatie 'zijn' DLL's in de lokale directory om er maar zeker van te zijn dat er niet een andere, incompatible, versie op het systeem staat. Daarmee is het concept van DLL's achterhaald.

Als je voor elke app een grote monolitische executable zou bouwen dan worden alleen die routines meegelinkt die ook echt gebruikt worden. Ik vraag me sterk af of dat zoveel ongunstiger uitvalt. En zoals TheCodeForce al zei, het wordt er in ieder geval stukken stabieler van.

[Joost]

Beetje lastig beveiligingsupdates verspreiden wel, als iedereen ze op eigen houtje meelevert

[hostname]

Omdat dat het updaten veel lastiger maakt. Als 100 apps een library meelinken die een veiligheidslek bevatten is dat veel moeilijker te updaten dan een library updaten.

[Verwijderd]

Het feit dat je een lib kan updaten, zonder dat de bovenliggende applicatie mee is getest is net zo goed een beveiligingslek vanjewelste. Als ik malware zou maken, dan zou il smullen van libs , in 1 keer alle applicaties tegelijk infecteren.

Single point of failure is BAD BAD BAD!

En wie is er verantwoordelijk als er iets niet blijkt te werken?

[killercow]

Ja, t werkt inderdaad voor geen meter.

Alle linux apps zijn zo lek als een mandje en de windows apps hebben inderdaad een prachtig gecentraliseerd update systeem zonder tientallen los meegeleverde taskbar update tools.

Man, ga je eerst eens inlezen in de werking van een en ander voordat je het evangelie gaat verkondigen.

[chronoz]

Vorige keer moest ik tcllib source rpm van FC14 opnieuw builden en installeren, omdat er geen 8.5 rpm was voor 8.4. Het gebruiken van FC14 rpm's is überhaupt niet mogelijk op CentOS 5, omdat FC14 rpm's veel nieuwe libraries meestal gebruiken. Hiervoor had ik het script dus niet kunnen gebruiken.

Dit zou overigens wel handig geweest kunnen zijn, want ik moest een eggdrop (Google Translate bot) verplaatsen van Ubuntu naar CentOS en ben er niet uitgekomen na 3 uur werk en knutselen met libraries. Het simpele TCL-script blijft errors geven.

Ik ga direct http://stanford.edu/~pgbovine/cde.html lezen en het opnieuw proberen

[Reactie gewijzigd door chronoz op 22 juli 2024 19:47]

[kozue]

Vorige keer moest ik tcllib source rpm van FC14 opnieuw builden en installeren, omdat er geen 8.5 rpm was voor 8.4.

En wat was er dan mis met 8.4 dan je zo nodig 8.5 perse moest hebben? Package managers zijn niet bedoelt om versie-geile nerds van het meest spiksplinternieuwe te voorzien, maar om een stabiele software respository te creeren met pakketten die blijven werken zolang je niet van distro upgrade.

Het gebruiken van FC14 rpm's is überhaupt niet mogelijk op CentOS 5

Gek he? Debian debs werken ook niet op CentOS. FC14 rpm's werken ook niet op OS X. Dat FC en CentOS nou toevallig allebei Redhat is, zegt niet dat het meteen hetzelfde is.

Dit zou overigens wel handig geweest kunnen zijn, want ik moest een eggdrop (Google Translate bot) verplaatsen van Ubuntu naar CentOS en ben er niet uitgekomen na 3 uur werk en knutselen met libraries. Het simpele TCL-script blijft errors geven.

Dit klinkt niet als iets wat jouw probleem op gaat lossen. Dit klinkt meer als een tool wat de package manager probeert te omzeilen door alle dependencies per pakket mee te leveren, iets wat juist totaal niet aan te raden is vanuit een security oogpunt, omdat je dan alle libraries van alle programma's apart moet patchen als er lekken worden gevonden. Shared libraries zijn beter te managen en gebruiken ook minder geheugen.
Dit "handige tooltje" is volgens mij juist weer de tijd terugdraaien naar 10 jaar geleden, en ik hoop dan ook dat iedereen het lekker links laat liggen, voordat ik straks "cde" pakketten tegen ga komen die mijn systeem vol proppen met nutteloze dubbele libraries.

[Verwijderd]

...iets wat juist totaal niet aan te raden is vanuit een security oogpunt, omdat je dan alle libraries van alle programma's apart moet patchen als er lekken worden gevonden. Shared libraries zijn beter te managen en gebruiken ook minder geheugen...
...Ik hoop dan ook dat iedereen het lekker links laat liggen, voordat ik straks "cde" pakketten tegen ga komen die mijn systeem vol proppen met nutteloze dubbele libraries.

hear hear!

[BeosBeing]

Voor de mainstream programma's lijkt me dit ook absoluut niet de juiste weg, wel lijkt het me in sommige gevallen een zinvol alternatief, bv
- om twee versies van dezelfde applicatie naast elkaar te kunnen gebruiken, bv een firefox 3.6.x en een 4.x beta.
- om oude applicaties te kunnen blijven gebruiken die afhankelijk zijn van oude libraries die in nieuwe distro's niet meer beschikbaar zijn. (Security hoeft niet zo'n issue te zijn omdat deze libs dan enkel deze app ter beschikking staan (en omgekeerd). Daarbij creërt de CDE zijn eigen sandbox waar de app niet buiten kan, en die van buitenaf (andere apps) ook niet zomaar te benaderen iis.
- om in oude distro's toch nieuwe apps te kunnen gebruiken, die afhankelijk zijn van nieuwe libraries die in de oude distro nog niet zijn opgenomen. Dit zal vooral spelen bij bleeding-edge software op bv LTS-distro's. Stabiele omgeving met daarop de nieuwste software.
Echter, zoals gezegd, moet het niet de mainstream methode worden. Een goede packagemanager lijkt mij daarvoor een betere optie. Die moet echter voor de beginnende gebruiker niet te detaïstisch zijn (ala synaptic, prima tool voor gevorderden, en voor wie weet wat hij zoekt maar teveel bomen om de bosjes te zien, of aptitude/apt-get) en ook niet te simplistisch zijn (ala 'Add-Remove programs in Ubuntu 10.04 waar je bij een pakket niet eens meer kunt lezen waar het voor dient.), niet voor de gevorderde maar ook niet voor de beginner. Zoals in Ubuntu 8.04 lijkt mij nog het beste evenwicht.

[Strike_2]

Je kunt applicaties aan specifieke 'bevroren' libraries koppelen d.m.v. de LD_LIBRARY_PATH variabele.
Ik heb mensen ook een chroot zin gebruiken om applicaties te 'bevriezen.

In beide gevallen kun je de libraries van een programma 'bevriezen', maar je bent dan zelf verantwoordelijk voor het patchen van deze libraries.

[harrydg]

om dan nog maar te zwijgen van het geheugen. Iedere lichtjes verschillende library moet OPNIEUW in het geheugen geladen worden... byebye efficientie en performantie!

het begint hier serieus op java te gelijken... ieder programma zijn eigen jre!!!

[Joost]

Vorige keer moest ik tcllib source rpm van FC14 opnieuw builden en installeren, omdat er geen 8.5 rpm was voor 8.4. Het gebruiken van FC14 rpm's is überhaupt niet mogelijk op CentOS 5, omdat FC14 rpm's veel nieuwe libraries meestal gebruiken. Hiervoor had ik het script dus niet kunnen gebruiken.

Hiervoor is CDE juist bedoeld

[rob12424]

Je schijnt hem ook met oudere versies te kunnen ¨faken¨ alleen resulteert dit meestal in een onstabiel systeem. Aangezien je dan tegen het programma zegt pak de oude versie want dat is de goede versie!

Voor de rest leuk dat hij dit gedaan heeft maar dit kan toch allang? ik meen hier in het verleden al eens gebruik van te hebben gemaakt toen een pc geen internet verbinding had?

[Eonfge]

Handig, weer een extra wapen tegen de (Red Hat) Dependency hell!

Nu nog zorgen dat dit over het bittorrent protocol werkt. Momenteel werkt Linux met grote servers voor hun updates en distributie van programma's. Het zal een uitkomst zijn als de servers alleen voor de beveiliging en certificatie worden gebruikt, terwijl de echte programma's via torrents gaan. Het zal server kosten verlagen en zal sneller werken, ook is het praktischer op het gebied van wetgeving.

[humbug]

Ik snap even niet wat dit met bittorrent te maken heeft. Het gaat om wat je verspreidt, niet hoe je het verspreidt....

[Verwijderd]

helemaal niets Dit is een tool om applicaties samen met hun dependencies in één te packagen zodat je het tussen diverse distributies uit kan wisselen terwijl dat normaliter met shared libraries niet kan. Bittorrent is een distributie protocol, en heeft dus helemaal niets met ced te maken Dat is netzoiets als dat er een manier is ontwikkeld om iedere auto-motor uit te wisselen met elke andere auto, ook al passen ze normaal gesproken niet. En dan zeggen "maar nu nog zorgen dat dit voor de snelweg werkt"...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:47]

[BeosBeing]

Nu nog zorgen dat er een efficiënte methode is om die motoren op vrachtauto's te laden zodat ze via de snelweg door het land te versprijden zijn.

[Blokker_1999]

Over het algemeen is er geen dependency hell, zolang een app voorkomt in een repo van je distributie zal je nooit tegen echte problemen aanlopen. En het grote voordeel van een repo blijft dat alle software altijd mooi met elkaar word geupdate .

[thegve]

Ik zou persoonlijk best wat willen betalen voor een goede mirror, zie ik als een betere oplossing. Niks zo snel als een lijn die gewoon direct opbouwd en full speed download.

[_JGC_]

Met mirrors over de hele wereld zie ik dat probleem niet zo. Zelfs Archlinux heeft een handjevol Nederlandse en Duitse mirrors waar je met de volle snelheid van kunt downloaden.

[kozue]

Ik zie geen reden om het anders te doen dan nu. Ik download al met m'n volledige snelheid. Ubuntu heeft overal mirrors staan...

[Verwijderd]

Niks zo snel als een lijn die gewoon direct opbouwd en full speed download.

Ik weet niet wat het probleem is, want als ik updates draai haal ik ze met 5MB per seconde binnen.... en alles staat in de repo wat ik zoek.

[thegve]

Downloads lopen nu ook prima, maar het gaat om een 'andere' p2p oplossing. Daar heb ik niet zo'n zin in/behoefte aan. Feitelijk ben ik het dus gewoon met jullie eens, maar mochten de sponsoren dit niet meer 'aankunnen', dan wil ik er ook wel voor betalen.

[CAPSLOCK2000]

bestaat, ik ken twee projectjes die dit doen:
debtorrent en apt-torrent
(linkjes mag je zelf googelen)

[g4wx3]

Weer een bewijs.. In linux land bestaat echt al zoveel, dat je het niet meer kan verzinnen, je moet het alleen nog weten te vinden.

[Yakotb]

Never change a winning team...

[Rob Coops]

Dus eigenlijk niets anders and Goole'sAndroid oplossing, alles in een archive en dus geen gezeur met libraries dependencies en andere typische redenen waarom Linux voor een huis tuin en keuken computer zo hopeloos is.

Dat je niet tussen kernels kan wisselen lijkt me logisch net als dat een Windows 95 applicatie lang niet op altijd een Windows 2000 systeem werkt etc. Ook kan je natuurlijk als je iets inpakt dat voor een ERM chip is ge compileerd dit niet op een x86 chip draaien, al weer erg logisch.

Het ljikt er op dat er eindelijk binnen de Linux community mensen op aan het staan zijn die inzien dat dependencies lang niet altijd zalig makend zijn. Natuurlijk is het goed dat je bestaande code en oplossingen gebruikt maar het moet wel redelijk blijven als je in een situatie terecht komt waar je 12 lagen aan dependency hebt voor je het eigenlijke programmatje kan draaien dan is er toch echt iets ernstig mis gegaan.
Deze oplossing is erg handig maar het zal wel zorgen voor een grotere footprint van de applicaties ook al is dat tegenwoordig over het algemeen niet meer zo'n probleem. Zeker niet op huis tuin en keuken systemen.

[Terracotta]

Alles wat je zelf maakt in een archive, alle functionaliteiten die google aanbiedt en waar je gebruik van wil maken zijn al geïnstalleerd in...shared libraries...

Autopackage heeft dit tien jaar geleden al proberen aan te pakken, het heeft de linux wereld super vooruit geholpen op de desktop. [/sarcasm]

De meeste OS-en gaan meer richting shared library systemen dan vroeger:
apple's app store
webos app store
android market place
windows phone 7
meego (met qt-api, al zijn de hildon libraries ook installeerbaar)
symbian (met qt-api)

Om voor die os-en te ontwikkelen kan je gebruik maken van bepaalde api's... as in je kan shared libraries gebruiken. De manier van distribueren van packages is zelfs gelijkaardig aan de repository systemen in moderne linux distro's.

Daarbij toont opera aan dat het echt wel doenbaar is om voor verschillende systemen packages te voorzien.

[thegve]

Daarbij toont opera aan dat het echt wel doenbaar is om voor verschillende systemen packages te voorzien.

In de praktijk stelt RPM/DEB ook niet zo gek veel voor wat dat betreft. Je maakt 1 package (RPM bijvoorbeeld), port die vrij eenvoudig naar DEB formaat, en het onderhoud is dan zo nu en dan een dependency toevoegen of verwijderen. Testen is uiteraard nog het meeste werk.

[CAPSLOCK2000]

Dus eigenlijk niets anders and Goole'sAndroid oplossing, alles in een archive en dus geen gezeur met libraries dependencies en andere typische redenen waarom Linux voor een huis tuin en keuken computer zo hopeloos is.

Windows applicaties doen het toch op exact dezelfde manier? Alles wat niet in Windows zit gewoon meeleveren in je installer? Ik ben het met je eens dat het geen goede oplossing is. maar een nadeel ten opzichte van windows is het dus ook niet.

Het ljikt er op dat er eindelijk binnen de Linux community mensen op aan het staan zijn die inzien dat dependencies lang niet altijd zalig makend zijn. Natuurlijk is het goed dat je bestaande code en oplossingen gebruikt maar het moet wel redelijk blijven als je in een situatie terecht komt waar je 12 lagen aan dependency hebt voor je het eigenlijke programmatje kan draaien dan is er toch echt iets ernstig mis gegaan.
Deze oplossing is erg handig maar het zal wel zorgen voor een grotere footprint van de applicaties ook al is dat tegenwoordig over het algemeen niet meer zo'n probleem. Zeker niet op huis tuin en keuken systemen.

Nogmaals, waarin verschilt dit van wat onder Windows of MacOS gebeurt?

Er zit ook een erg groot nadeel aan het embedden van al je dependencies. Als er een bug gevonden wordt kan je die niet in 1 keer fixen voor heel je systeem, maar zal je iedere applicatie die de bug meelevert moeten repareren.

[durian]

Ik vind dit een beetje een oplossing voor een niet bestaand probleem. Het is over het algemeen geen probleem om verschillende versies van de libraries naast elkaar te hebben, en je software tegen de juiste te linken.

Als je een server beheert dan komt daar altijd software uit de officiele repositories op via aptitude/RPM/whatever, dan speelt het probleem sowieso niet.

Voor desktop computers kan je of je officiele repositories gebruiken, of van source compileren, en dat gaat ook altijd.

En kernelversies die een rol spelen?

Zeker, het komt sporadisch voor dat het wat moeite kost om een bepaald programma aan de praat te krijgen, maar om het over dependency hell te gaan hebben is schromelijk overdreven.

[Joost]

Heb je de preview van Spotify geprobeerd te installeren op Ubuntu 10.10? Die werkt dus niet out-of-the-box, omdat een bug in de code niet samenwerkt met de versie van Qt die 10.10 gebruikt. Nu kun je zelf op zoek gaan naar de vereiste, oudere versie (als je al weet dat het aan Qt ligt), die je niet vanuit de repository van 10.10 kunt installeren. Met CDE had Spotify dit zelf kunnen voorkomen.

Tot zover 'niet-bestaand probleem'.

[Reactie gewijzigd door Joost op 22 juli 2024 19:47]

[Terracotta]

Als je previews kan/wil installeren... kan je ook wel vinden waar het aan ligt. Is dat trouwens niet het doel van previews? zorgen dat de uiteindelijke release WEL werkt/compatible is met andere systemen?

[Verwijderd]

Spotify had ook QT statisch kunnen linken, waren ze ook van het gezeur afgeweest. Veel commerciële software doet dit.

Dit leidt wel tot grotere executables, waardoor het niet praktisch is als elke applicatie dit doet. Vandaar dat er meestal dynamisch gelinkt wordt, zeker als je een repository van een distributie gebruikt die ervoor zorgt dat de boel gesynchroniseerd blijft.

[willyb]

Zag ik nu /etc/passwd meegekopieerd worden?

[Blokker_1999]

waarschijnlijk een dummy versie voor in de chroot.

[Punica-]

Opzich aan de ene kant een goed initiatief, maar 10 jaar te laat. De dependency hell zoals vroeger bestaat eigenlijk niet meer als je van packet managers gebruik maakt en zelf niet gaat klooien met packages.

En pakketten die je buiten de standaard package manager moet installeren zoals bijv Opera zijn al zo opgebouwd dat ze het universeel doen.

Aan de andere kant vind ik dit een slecht initiatief, omdat het developers kan verleiden om maar de makkelijke vieze gehackte manier te kiezen ipv zich aan de standaard libs te houden. Tevens zal het een aanslag op je HD space worden (al lijkt mij dat anno 2010 geen echt probleem meer) net als op Windows, simpele programma'tjes die tientallen dan niet 100n' MB's groot zijn.

[Blokker_1999]

dependency hell bestaat nog wel, maar door het feit dat distos hun repo zo groot is kom je het niet vaak meer tegen. Het is pas als je software wenst te gebruiken die niet in een repo zit dat je in de hel terechtkomt.

[Verwijderd]

Met de gemiddelde console applicatie zal het nog wel te doen zijn maar met een redelijke X applicatie heb je het al snel over vele megabytes aan libraries die je moet overzetten. En als het dan ook nog aan shared stuff hangt is het helemaal diep zoeken van wat nodig is en wat niet. Maar er zijn veel nuttige toepassingen voor CDE te bedenken. Met name voor mensen die wat willen ontwikkelen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 19:47]

[Superstoned]

Ik ben een beetje verrast over dit verhaal - ik zie weinig vernieuwends. Het lijkt een boel op 'klik', wat echt al 6-7-8 jaar aan de weg timmert en precies hetzelfde bied. En ook even on-populair is, precies om wat jij zegt: je krijgt enorme hoeveelheden bibliotheken want de gemiddelde grafische app heeft zo 30-40 mb aan dependencies, makkelijk oplopend tot 100 (gaan we ook X bijleveren? Fonts? themes? icoontjes? bij ELKE app?)

[jorkro]

Voor C/C++-applicaties werkt de -static parameter hier ook prima voor.