Google en Red Hat patchen kritiek Linux-lek in glibc-bibliotheek

Het zal je misschien verbazen, maar onder Windows is de Visual C Runtime een applicatie-component. En als je de Borland C compiler gebruikt, dan is hun runtime evengoed een applicatie-component.

Windows zelf gebruikt een speciale build van de MSVC CRT, maar dat is een implementatie-detail van het OS. Applicaties gebruiken die CRT niet. Het gevolg is dat Microsoft die library gewoon kan renamen, zonder dat er iets breekt. Je moet onder Linux het niet wagen om glibc te renamen, dan kun je een reinstall doen.

Nee hoor, kijk maar op Debian waar ld-linux.so vandaan komt: "libc6" package, en dat is dus glibc - geen deel van het OS.

En het probleem met "statisch linken" is dat glibc zaken als "resolv.conf" door dynamisch laden oplost, zelfs als je kiest voor statisch linken.

[Reactie gewijzigd door MSalters op 17 februari 2016 15:28]

Normaal als je statisch linkt worden alleen de functies/subroutines die je echt gebruikt mee gelinkt. Dus alle applicaties die niet die client side dns resolver gebruiken krijgen die coding ook niet mee. dus:

1. de binary wordt niet heel veel groter.
2 heel veel applicaties doen niet zelf aan DNS resolving, en dat de impact wel meevalt.
Niettegenstaande dat moet de bug wel opgelost worden in apps/os die er wel gebruik van maken.

Als er iets is dat in mijn ogen Linux meer kwaad dan goed doet, is de enorme afhankelijkheid van de programma's met de libraries.

Op je Windows PC kan je gewoon zonder al te veel rommelen, updates van programma's installeren. Je hebt Office x, en je wilt de nieuwe Office z. Geen probleem.

Wil je een applicatie updaten in bijvoorbeeld Linux, is het vaak vechten tegen de bierkaai. Want veel distro's hun package managers zijn gelinkt met vaak enorm verouderde libraries / software.

Een leuk voorbeeld is probeer die zelfde Go is te installeren. Debian ( 8 ): 1.3. Mint: 1.2, ... We zijn intussen al aan de 1.6 RC versies op dit moment van schrijven.

Eenmaal dat je het pad ingaat van upgrades van programma's dat buiten je repo vallen, dan ga je een wereld binnen van incompatibility en andere problemen. En dan begint de hell voor iedere niet Tech-begaafde gebruiker. Ik heb geen enkel probleem dat de OS bestanden dynamisch gelinkt zijn maar ik heb een hekel hoe heel wat applicaties voor enorme problemen kunnen zorgen wanneer de OS achterloopt met hun libraries.

Je mag zeggen wat je wilt over Windows en hun manier van werken. Maar het werk. Je kan een Windows 7 draaien en iedere programma updaten zonder zorgen over de libraries hell dat je bijvoorbeeld hebt onder Linux bij updates.

Dat is ook het punt dat mij het meeste stoort onder Linux. Geen enkel distro heeft een goede oplossing voor het probleem. Ofwel lopen ze tot één tot twee jaar achter met hun software ( Debian ), ofwel zijn ze bleeding edge ( Arch ) waar je nooit met een modale niet Tech gebruiker aan de slag mee kunt.

Zo lang ze dat probleem niet kunnen oplossen bij Linux distro's, zal je nooit de "gewone" gebruiker overtuigen. En ik kan je verzekeren, dat het me al vaak vloeken en tieren opgeleverd heeft wanneer ik bepaalde versies van software nodig heb ( wegens verbeteringen of features ), of soms zelf het totaal ontbreken van die software op die distro's hun platform. En het werk dat je moet verzetten om dat te installeren ( van source compileren, tot backports, tot ... ). Waartegen een Windows gebruiker gewoon download en dan "install" drukt. Voila ...

Ps: Ik draai Linux Mint als men OS. Voor het geval dat sommige denken denkt dat ik een Windows gebruik ben, dat Linux wilt bekritiseren. Het moet eens gezegd worden dat men moet durven afstappen van die oude gedachten goed in de Linux wereld.

Bekijk GoLang ... wat is juist door heel wat mensen aangezien als een main feature. Just, het feit dat ze statisch linken van de bestanden. Maakt het het bestand groter. Ja ... maakt het grotere bestand iets uit op éénder welke normale PC / Server: Geen klein beetje. Enkel op micro pc setups ( zoals de Pi, of routers enz ).

Je ziet juist meer & meer in die opkomende programmer talen dat de features omvatten: Het statisch linken van libraries. Het maakt het leven voor het distributie van je applicatie gewoon zo veel makkelijker wanneer je niet constant moet checken welke libraries zijn er op x distro.

Het nadeel is dat het de security updaten van de libraries/programma's verschuift naar de ontwikkelaar. Nu is er één core library een bug en je hebt miljoenen toestellen dat kwetsbaar zijn. Waartegen moesten applicaties hun eigen versie draaien ( zoals de pre 2.8 ), geen probleem. Een deftige sandboxed applicatie zou perfect oude informatie of mixed dll's mogen draaien.

Waarom zijn systemen zoals Docker / enz ook meer en meer populair. Omdat je gewoon de libraries hell verplaatst naar de containers, waardoor je gewoon zaken kan draaien zonder je zorgen te moeten maken dat die applicatie je systeem onstabiel maakt.

Sorry als ik het zeg, maar dynamische gelinkte bestanden zijn iets dat enkel tot de core OS zou mogen behoren en de rest zou in een sandboxed omgeving moeten draaien met hun eigen libraries! Dan pas kan je het gebruik gemak verhogen van de eind gebruiker.

Zal niet toevallig zijn dat je nu meer en meer nieuwe programmatie talen met statisch linken werken, en oplossingen zoals docker enz begint te zien. Dat men zelf bij de grote distro's zit te experimenteren met distro's dat puur met sandboxed applicaties werken a la docker. Juist omdat het heel wat zaken makkelijker maakt en toelaat om mensen voor de laatste versies van software te draaien zonder dat het gans je core OS onderuit kan halen.

Zoals ik zei, zo lang dat men dit niet verbeterd zal Linux voor de gewone eindgebruikers gewoon nooit de oplossingen worden ( Zelf met Steam ).

Ja, ik ga heel wat kritiek krijgen van die hard Linux gebruikers, van hoeveel oplossingen er wel zijn. Maar dat is niet het punt. Het punt is dat men gewoon achterloopt in de gewone gebruiker ervaring tegenover andere OS'en zoals Windows. En dat dit niet komt wegens technische onmogelijkheden maar eerder doordat men niet durft weg stappen van bepaalde gedachten ( zoals statisch linken = bad bad bad ). En zo lang een groot bedrijf niet doordruk zoals docker / sandbox voor graphic applicaties waardoor de druk wegvalt van het dynamisch linken...

Dat een technische persoon oplossingen kan vinden en hup even de command line opzoekt is geen oplossing.

Dat gaat ook alleen maar op wanneer applicaties allemaal dezelfde versie van die dynamische lib gebruiken.
Zodra ze dat niet doen mag die systeembeheerder voor elke applicatie gaan uitzoeken welke versie lib er gebruikt wordt en zonodig patchen.

Ik ben van de statische school; applicaties moeten zo weinig mogelijk afhankelijkheden hebben, dus ook net in dynamische libs. Dan kan je ze makkelijker sandboxen en de/re/installeren, heb je midnder afhankelijkheden in je ontwikkelpad en is het voor de gebruiker ook makkelijker te begrijpen.

Ruimtegebruik is geen argument. Diskruimte stijgt harder dan lib size. Wil je dan toch minder dan pas je maar een filesysteem met deduplicatie toe.

Wat bedoel je te zeggen? De C++ std::string is veel abstracter, en heeft veel lagere performance. Ga je code maar eens herschrijven van het gebruik van iostreams naar cstdio (std::cout -> printf, std::string -> char *) en de performance wordt significant hoger, koste van wat usability en wat safety checks. Ook is de compile-time veel lager (door het overslaan van de enorme C++ STL), en de resulterende binary wordt ook kleiner.

Voor desktop-applicaties maakt dat geen fluit uit (en dan kan je net zo goed Python gebruiken om maar eens wat te noemen), maar voor low-level systemen als kernels en systeembibliotheken maakt dat een enorm verschil.