LSB 4.0 poogt Linux opnieuw standaarden op te leggen

De nieuwste versie van de LSB, die eind dit jaar gepland staat, moet programmeurs helpen hun software distributie-onafhankelijk te maken. De organisatie achter de standaard stelt de benodigde tools voor certificatie ter beschikking.

De Linux Standards Base, onderdeel van de Linux Foundation, de organisatie die Linux tracht te promoten door onder meer standaarden vast te stellen, heeft de release van versie 4.0 van zijn standaarden-definitie voor november 2008 gepland. De standaard moet ontwikkelaars van Linux-software houvast bieden bij het schrijven voor verschillende distributies: middels een gestandaardiseerde verzameling libraries en api's zouden programma's op elke Linux-distributie met LSB-certificering moeten functioneren. De vierde versie van LSB zou vooral een belangrijke bijdrage aan de certificering moeten leveren: de tests om te controleren of software LSB-conform is, laten tot op heden te wensen over.

Volgens de leider van het LSB-project, Jim Zemlin, moet LSB 4.0 een belangrijk keerpunt betekenen: Zemlin zou 50 programmeurs achttien maanden lang aan het werk hebben gezet om de certificeringssoftware voor LSB 4.0 te schrijven. De testsoftware moet controleren of een nieuw stuk software aan de standaarden voldoet en onder meer van de juiste libraries gebruik maakt. In theorie zou gecertificeerde software derhalve op alle gecertificeerde distributies moeten functioneren, aangezien LSB dicteert dat een vaste verzameling software, libraries en api's in een Linux-variant aanwezig is. In combinatie met het Linux Developer Network, eveneens een project van de Linux Foundation en bedoeld om het makkelijker te maken voor programmeurs om Linux-applicaties te schrijven, zou het distributie-onafhankelijk programmeren voor Linux met LSB 4.0 een grote vlucht moeten nemen.

Uiteraard is de certificering niet verplicht, zo stelt Zimlin, maar hij verwacht dat het gemak dat de testsoftware van LSB 4.0 met zich meebrengt tot een grotere bereidheid om voor meerdere distributies te programmeren zal leiden. Wel bevestigt hij dat programma's voor elke distributie nog getest dienen te worden op compatibiliteit. Onder meer Novell, Sun, Red Hat en Canonical zijn bij de Linux Foundation aangesloten; de grote distributie Debian ontbreekt echter.

Reacties (94)

[Mars Warrior]

Is dit nu weer niet iets dat men binnen Linux al 20 jaar probeert (standaardiseren), terwijl nu juist die verschillen door sommige personen als de kracht van Linux wordt gezien??

De tijd zal het leren, maar als Debian al niet meedoet, tja. Een uniforme Linux zal wel een utopie blijven ben ik bang

[GENETX]

Goed punt. Standaardisatie is gewoon nodig als Linux verder wil groeien. Juist bovenstaand punt is de reden dat ik maar weer terug ben gestapt op Windows. Naast een stabiel OS is eenheid bijna net zo belangrijk om het voor de eindgebruiker makkelijk te maken.

[BastiaanN]

De kracht is inderdaad dat er altijd wel een distro is die iets heeft wat jou ligt. Geen enkele distro is hetzelfde. Vervelender is bijvoorbeeld dat de verschillende base distro's nu voor dezelfde doeleinden allemaal andere commando's hebben. (er zijn natuurlijk ook wel commando's die wel op elke distro aanwezig zijn zoals ls,top etc.)

apt-get, yast2 en yum doen allemaal hetzelfde. Zelfs ik als doorgewinterde tweaker vind dit nog vervelend. Maar je ziet nu dat alle linux distro's sterk bezig zijn met het user friendly maken van dingen zoals bijv. de installatie.

Hoe dan ook, die standaarden mogen er van mij komen! als iedereen zich aan die standaarden houdt, wordt het straks de kracht van linux dat je alles alsnog kan aanpassen, maar dat het op elke distro functioneerd

[Reactie gewijzigd door BastiaanN op 23 juli 2024 00:21]

[graey]

apt-get, yast2 en yum doen ongeveer hetzelfde, en los daarvan is het ook nog zo dat ze verschillend presteren (ik spreek nu alleen voor x86 en x86-64, daar heb ik genoeg ervaring mee). Op een middenmoot-computer (of beter) kun je best met yast/yum leven, en je zal je er misschien niet eens echt aan ergeren, maar als je daarna een willekeurige debian-based distro probeert merk je dat apt een stuk sneller loopt. Tel daarbij de overhead op van een GUI om het wat makkelijker te maken, en het is echt een aanzienlijk verschil. Nou is het een stuk versnelt in de laatste release van openSuse, maar het is nog steeds aanwezig.

[phobosdeimos]

Debian kan niet volledig meedoen omdat LSB probeert RPM op te dringen, terwijl Debian dpkg gebruikt, een formaat dat samen met apt veel verder staat dan rpm.

[Verwijderd]

Doet de LSB dat nog steeds met LSB 4.0? Ze zijn al een tijdje bezig met PackageAPI, waarmee het precieze formaat onbelangrijk wordt, als PackageAPI maar ondersteund wordt. Die Package API wordt dan aangeroepen door installers van 3rd party vendors, en zorgt ervoor dat de programma's van die vendors goed integreren in het packaging (en dependency) systeem van de distributie.

Voor closed source programma's betekent dat dat ze gewoon 1 package kunnen maken voor heel Linux, en dat dependencies overal goed worden afgehandeld.

Voor open source programma's betekent dat dat ze hun releases op hun site ook gewoon als 1 package kunnen releasen, en dat packagers van de verschillende distributies alsnog hun eigen package voor in de repositories kunnen maken.

[Umbrah]

Ook zoiets van de open source community, wat een gebrek is op heel linux land: "mijn product is beter dan het jouwe!". Als je op je werk het niet met iets eens bent, doe je vaak ook toch een concessie? Ik denk dat het beter is voor heel Linux, als debian toch maar toegeeft en gaat samenwerken om RPM beter te maken.

[CAPSLOCK2000]

Het zou niet veel uitmaken. Technisch gezien zijn RPM en DEB vrijwel identiek, alle ook maar enigzins interessante features hebben ze allebei.
Het probleem is dat een Debian systeem heel anders is opgebouwd dan (bijvoorbeeld) een Fedora systeem. Packages hebben andere namen, files staan op andere plekken en procedures zijn anders.
Dat is onafhankelijk van het pakket formaat, andere RPM distributies (bv SUSE) hebben precies hetzelfde probleem.

Debian lost dit op door de LSB onderdelen in een aparte directory te zetten. RPM kun je zo ook gewoon onder Debian gebruiken. Je kan het weliswaar niet gebruiken voor de Debian pakketten zelf, maar wel voor LSB pakketten, en daar ging het om.

[lvh]

rpm's en deb's (de packageformaten) zijn inderdaad grotendeels identiek, maar dpkg en rpm (in dit geval rpm als package manager, niet als formaat) en de daaropgebouwde apt en yum zijn geenszins te vergelijken.

[arbraxas]

Het is de kracht en tevens de zwakte van linux.
Al die verschillende distributies met hun eigen specifieke kenmerken en sterke punten.
Aan de andere kant is t daardoor ook niet weggelegd voor "noobs" als desktop.
Als je hardware/software niet out of the box werkt zit je toch wel met een probleem dat door die mensen niet zomaar is op te lossen.
Maar er zijn nu zoveel verschillende distro`s met hun eigen aanpak dat dit al gedoemd is te mislukken voor dat ze ermee begonnen waren.

[zenlord]

Hoeveel noobs ken jij die windows zelf installeren, misschien (aangezien je over OOBE spreekt)? Laat een noob achter een voorgeïnstalleerde pc plaatsnemen, en die persoon zal even gemakkelijk surfen onder windows, linux of OSX (of BSD of...).

Tjonge, jonge. Straffe uitspraak om mee af te sluiten.

[flowerp]

Is dit nu weer niet iets dat men binnen Linux al 20 jaar probeert (standaardiseren), terwijl nu juist die verschillen door sommige personen als de kracht van Linux wordt gezien??

Ja en nee. Er zijn 2 soorten standaarden: die van de look & feel en die van de APIs en omgeving voor je code.

Vergelijk het met browsers. Een web pagina moet elke browser correct kunnen weergeven, maar niet elke browser hoeft de back button op exact dezelfde plek te hebben staan en ook hoeft deze er niet exact het zelfde uit te zien. Daarnaast zijn er enkele features die je browser kan bieden, zonder dat dat beïnvloed hoe de web page er uit ziet.

Zo is het ook met Linux. De hoop is om tot een oplossing te komen waarmee ik zeg maar applicatie A kan schrijven, waarbij deze direct kan worden opgenomen als software voor Debian en Red Hat. Nu nog moeten de mensen van beiden distributies de code dikwijls patchen, omdat er gewoon verschillen zijn.

[Verwijderd]

De belangrijkste aanpassingen zitten toch in de software zelf. Er zijn tig build systems. Laat ze eerst eens allemaal gebruik gaan maken van automake, autoconf en libtool.

Het op maat installeren van packages is dan ook een stuk eenvoudiger. Zeker als je naar de build tools voor .deb en .rpm packages kijkt.

[totaalgeenhard]

Debian grote distributie ?

Qua naamsbekendheid maar niet qua installed base.

[Blokker_1999]

Debian vormt de basis van enorm veel distributies. Als Debian zou voldoen aan de LSB dan zullen vele distributies bijna automatisch volgen.

Daarnaast is Debian misschien minder bekend/geliefd bij thuisgebruikers (hoewel het de distro is die ik zelf gebruik) maar is het wel vrij populair op servers.

[Verwijderd]

Debian ondersteunt ook de meeste CPU architecturen dus is het jammer dat ze niet mee doen. Maar het is ook wel begrijpelijk dat niet alle distro's meedoen want het sterke van Linux is juist dat je er niet mee aan banden ligt qua inhoud, zeker m.b.t. de window manager. Daarnaast ondersteunt, Debra&Ian ook een veelvoud aan verschillende apparaten die weer verschillende user interfaces nodig hebben.

Wel goed om te zien dat ze wat meer standaarden invoeren bij linux (als is er natuurlijk al zoiets als POSIX ).

Ik vind dat dan ook een zeeeer groot voordeel van MS WINDOWS, namelijk de PE, Portable executable, die op iedere 32 bit WindowsBak draait (al heeft natuurlijk ook vele nadelen waar Linux van profiteert). Je hoeft een programma onder Windows maar 1 maal te compileren en het werkt gewoon overal (tenzij een dll-etje ontbreekt). Dat vind ik dan ook echt een heel vervelend nadeel van Linux, dat je eerst tig libraries moet downloaden etc. voordat je eindelijk PacMan kunt spelen.

Het is dus afwegen: Wil ik flexibiliteit of ga ik voor compatibiliteit.

Ik juich de OpenSource communitie toe maar ik vind Linux nog niet helemaal gebruiksklaar voor de massa, ook niet Ubuntu.

[deadinspace]

Ik vind dat dan ook een zeeeer groot voordeel van MS WINDOWS, namelijk de PE, Portable executable, die op iedere 32 bit WindowsBak draait

PE is Windows' executable format. Op Unices is het ELF (Executable and Linkable Format) executable format gebruikelijk. PE en ELF vervullen beide hetzelfde doel (de file opdelen in bepaalde secties, dynamisch linken mogelijk maken, etc) en zijn grotendeels gelijkwaardig aan elkaar. Lees voor meer informatie dit maar eens.

Je hoeft een programma onder Windows maar 1 maal te compileren en het werkt gewoon overal (tenzij een dll-etje ontbreekt).

Je hoeft een programma onder GNU/Linux ook maar 1 maal te compilen, en het werkt dan ook overal, tenzij er een library ontbreekt

Dat vind ik dan ook echt een heel vervelend nadeel van Linux, dat je eerst tig libraries moet downloaden etc. voordat je eindelijk PacMan kunt spelen.

En dat heeft dus niks met PE vs ELF te maken. Het heeft te maken met het feit dat bij het bouwen van een Windows applicatie alle gebruikte libraries met de applicatie mee worden geleverd, en bij GNU/Linux niet.

Op Windows betekent dat dat iedere applicatie zijn eigen verzameling libraries in de system32 directory installeert. Dat wordt vervelend als twee programma's dezelfde library meezeulen, want die kunnen met elkaar conflicteren; het later geinstalleerde programma zal de library van het eerder geinstalleerde programma overschrijven, wat het eerder geinstalleerde programma knap vervelend kan vinden. Dat is wat bekend stond als de "DLL hell".

Tegenwoordig is het onder Windows gebruikelijker voor iedere applicatie om zijn eigen libraries op een eigen locatie te installeren, in plaats van op een gemeenschappelijke plaats. Daarmee voorkom je de DLL hell, maar het gaat nogal voorbij aan het idee van shared libraries. Als een library gebruikt wordt door vijf programma's op je systeem, dan heb je dus ook vijf losse kopiëen van die library.

Dat betekent dat als je de vijf applicaties die die library gebruiken start, er ook vijf kopiëen van diezelfde library in je geheugen geladen worden. Ook als er een securityfix voor die library uitkomt, dan zal van ieder van die vijf programma's een update moeten komen met de gefixte library. Een goed voorbeeld hiervan is de zlib vulnerability van 2005.

Onder GNU/Linux is het dus juist niet gebruikelijk om elk progamma zijn eigen libs te laten meezeulen. In plaats daarvan wordt een benodigde library op een gezamelijke plaats geinstalleerd, zodat elk programma dat die library nodig heeft het kan gebruiken. In bovenstaand zlib-vulnerability probleem hoefde de zlib library maar één keer geupdate te worden, waarna alle programma's die dynamisch van zlib gebruik maakten alleen maar herstart hoefden te worden.

Een nadeel hiervan (en dat is waar jij het over hebt) is natuurlijk dat bij de installatie van een programma ook bepaalde libraries geinstalleerd moeten worden. Maar om dat makkelijk te maken en te automatiseren bestaan package management systemen. Een package geeft simpelweg aan welke libraries het nodig heeft om te functioneren (de zogenaamde dependancies), en die kunnen dan automatisch geinstalleerd worden als je het applicatie package installeert.

[Katsunami]

En als je nu 5 programma's gebruikt die allemaal verschilende versies van een bepaalde library nodig hebben? Die kun je dan niet op een gezamelijke plaats opslaan en dan heb je een Library Hell

Ik vind het persoonlijk geen probleem als een bepaalde DLL 5x op mijn systeem staat en indien nodig 5x geladen wordt. Vroeger was dat wel een probleem; de schijfruimte en het geheugen waren veel beperkter. In de tijd waarin een 500GB schijf net over de 50 euro kost, en 4-8GB al te halen is voor 60-120 euro, geldt dat echter veel minder.

Hoewel software steeds groter en groter wordt, groeit de hardware nog veel sneller.

Het punt dat je maakt betreffende het updaten van een library blijft natuurlijk bestaan. Ik zou het een voordeel vinden als er een soort "Windows repository" zou komen dat gekoppeld is aan Windows Update; een plek waar elke fabrikant (gratis) een account kan aanmaken waarin hij de updates voor zijn programma zet. Het programma zou zichzelf kunnen aanmelden bij Windows Update. Windows Update kan dan updates downloaden en installeren voor elk programma dat je op je computer hebt staan.

Uiteraard moet elke fabrikant een update uitbrengen om zijn specifieke versie van de DLL-met-bug bij te werken, maar een gebruiker zou hier niets van merken

[Reactie gewijzigd door Katsunami op 23 juli 2024 00:21]

[deadinspace]

En als je nu 5 programma's gebruikt die allemaal verschilende versies van een bepaalde library nodig hebben? Die kun je dan niet op een gezamelijke plaats opslaan en dan heb je een Library Hell

Dan heb je vijf verschillende versies van die libraries die gezellig naast elkaar op de gezamelijke plaats leven.

Libraries zijn onder Unices namelijk voorzien van versies, en daarom kun je prima verschillende versies naast elkaar hebben. De conventie is om de 'hogere' getallen in versienummers gelijk te houden zolang de library compatible blijft met voorgaande versies (bijvoorbeeld door alleen bugfixes of performance-verbeteringen door te voeren). Bij incompatible veranderingen worden de 'major' versienummers wel opgehoogd, zodat het duidelijk is dat het om een incompatible wijziging gaat.

Als voorbeeld, op mijn Desktopsysteem (Debian Unstable) staan twee versies van libdns, namelijk versies 22.1.0 en 32.2.2:

% ls -l /usr/lib/libdns.*
lrwxrwxrwx /usr/lib/libdns.so.22 -> libdns.so.22.1.0
-rw-r--r-- 1 /usr/lib/libdns.so.22.1.0
lrwxrwxrwx /usr/lib/libdns.so.32 -> libdns.so.32.2.2
-rw-r--r-- 1 /usr/lib/libdns.so.32.2.2

Alle 22-versies zijn onderling compatible, en alle 32-versies onderling ook, maar 22-versies zijn niet compatible met 32-versies. Een programma gebruikt vervolgens òf een 22-versie òf een 32-versie van libdns (of nog een andere versie, maar de programma's op mijn systeem nemen genoegen met 22 of 32).

Omdat het binnen een major versie niet uitmaakt welke versie een programma exact gebruikt, zijn programma's gelinkt aan bijvoorbeeld /usr/lib/libdns.so.32 en niet aan /usr/lib/libdns.so.32.2.2. Een programma roept dus /usr/lib/libdns.so.32 aan, maar dit is een symlink naar libdns.so.32.2.2, en zo krijgt het programma de daadwerkelijk geïnstalleerde versie voorgeschoteld.

Zo gebruiken bijvoorbeeld een hoop DNS-gerelateerde libraries en utils op mijn systeem (waaronder nslookup) libdns 32:

% ldd /usr/bin/nslookup | grep libdns
libdns.so.32 => /usr/lib/libdns.so.32 (0xb7db5000)
%

Van libdns 22 maken slechts nog twee andere libraries gebruik (zoals libbind9):

% ldd /usr/lib/libbind9.so.0 | grep libdns
libdns.so.22 => /usr/lib/libdns.so.22 (0xb7e22000)
%

Op deze manier zijn precies zoveel versies op het systeem geinstalleerd als voor compatibility nodig is, en niet meer.

Ik vind het persoonlijk geen probleem als een bepaalde DLL 5x op mijn systeem staat en indien nodig 5x geladen wordt. Vroeger was dat wel een probleem; de schijfruimte en het geheugen waren veel beperkter. In de tijd waarin een 500GB schijf net over de 50 euro kost, en 4-8GB al te halen is voor 60-120 euro, geldt dat echter veel minder.

En die mentaliteit is een van de redenen dat veel dingen nog steeds traag zijn, ondanks de fenomenaal toegenomen snelheid van hardware. Het is resource verspilling door slordigheid, niet meer en niet minder.

Bovendien heeft niet iedereen zin of geld om ieder jaar een nieuwe computer te halen (de gemiddelde thuisPC heeft vaak 512 of 1024MB!), en bij telefoons, PDA's en embedded systemen komt het nog veel nauwer.

[Verwijderd]

Nee, het probleem dat er een bepaalde versie nodig is is er tot nog toe maar weinig ontstaan.

Libraries zeulen vaak een aantal achterhaalde, 'deprecated' methodes met zich mee om tegemoet te komen aan software die op het gebruik van die methodes gebaseerd is. Met nieuwere versies worden deze methodes vaak omgeschreven naar een eenvoudige functie om de aanroep te vertalen naar een nieuwe, betere methode.

Wanneer er echter een te grote verandering zal plaatsvinden en een bepaalde methode echt geschrapt moet worden, gebeurt dit in principe altijd met een major version upgrade. Zo kan je rustig gecko1.8 en gecko1.9 (de rendering engines van resp. firefox 2 en 3) naast elkaar installeren, omdat 'gecko1.8' een andere library is dan 'gecko1.9'.
In principe kunnen alle programma's die gebouwd zijn voor gecko1.8 build 42 probleemloos overweg met gecko1.8 build 1337 (even wat getallen uit de grote duim gezogen) Andersom is dat natuurlijk niet vanzelfsprekend, omdat er functionaliteit kan zijn toegevoegd.

[_Thanatos_]

Je hebt helemaal gelijk over de Windows PE's, op 1 detail na: processor-architecturen
Een x64- of IA64-executable zal echt niet werken op x86.

Dat is weliswaar met .NET opgelost, maar Java lost dat op Linux evengoed op...

[Reactie gewijzigd door _Thanatos_ op 23 juli 2024 00:21]

[tweakerbee]

Bij .NET krijg je dan veel problemen als er toch nog stiekem wat native DLLs aageroepen worden. Je app lijkt prima te werken (op je x86 bak/OS) maar als je hem in 64-bits mode draait klaagt hij opeens over BadImageException. Expliciet compileren voor x86 lost dit probleem op, maar dan heb je dus geen 64-bits software meer.

(Hm... wel lekker offtopic bij een *Linux* artikel.)

[graey]

offtopic:
Gedeeltelijk, Thanatos' reactie was er ontopic. En .net is niet alleen voor linux he

[IStealYourGun]

Maar servers hebben vaak maar een beperkte functie. Ik denk eerlijk gezegd dat LSB dan ook minder belangrijk is voor servers. Maar aan de andere kant geef ik je wel gelijk dat het een enorme boost zou geven voor verschillende andere distributies.

[Verwijderd]

Debian is een beetje meer dan Debian Linux. Hun softwarecollectie is enorm en juist die is belangrijk voor de communitie en het zou dus veel schelen als die software aan de standaard voldeed.

Recent las ik nog dat de codebase die Debian in beheer tegen de 10 miljard dollar zou kosten om te ontwikkelen. Tegen de 275 miljoen regels code meen ik me te herinneren.

[Umbrah]

zat distro's die er op gebaseerd zijn.

Maar opzicht heeft het wel iets, wat meer standaard en uniformiteit binnen Linux. Het is gewoon NIET aantrekkelijk voor de thuisgebruiker. En (helaas) mede doordat er duizend-en-een verschillende distributies zijn die allemaal wat verschillen, en hoe leuk en aardig Gnome/KDE ook zijn, de verschillen zijn te groot, en je kunt lang niet alles vanuit de GUI. Anno 2008 schrikken command prompts af. "sudo apt install shit hoofdletter vergeten" is niet gebruikersvriendelijk. En het gezeur dat veel distro's geven als je een closed source programma probeert te installeren (wat is er mis met installshield? Standaardiseer dat eens voor Linux), gezeur wat irritanter is dan welke vorm van UAC dan ook.

Totdat het gebruikersvriendelijk wordt OOK voor de leek, zal Linux nooit het succes van bijvoorbeeld Firefox (duidelijke pagina, simpele installer, en kopieert instellingen, en het programma is fisherprice-achtig simpel, ook qua plugins) kunnen evenaren, en zal het een nerd/server/gelimiteerde terminal OS blijven (zoals op die netbooks, het is linux based, maar je kunt er niet zo veel mee als met een volwaardige distro of windows). Ik vind het natuurlijk een geweldig OS voor op een (web/db) server, maar zal het niet zo snel op m'n picasa-gekke foto-bewerkende (cardreader gewoon berijkbaar vanuit "my computer"), foto bestellende vader zijn PC installeren.

Ik gun Linux ook op de "gewone" gebruiker zijn PC het succes van bijvoorbeeld Firefox, maar er moet binnen de community heel wat veranderen en gestandaardiseert worden.

[sleezball]

Klopt wel grotendeels wat je zegt. Maar net als bij Windows (95/98/NT/XP/Vista) heeft ook Microsoft er een commandprompt ingebouwd dus is het verschil met Windows niet zo heel groot.

Het probleem is juist dat men (het gros van de computergebruikers) nooit heeft geleerd om ook maar de meest basis commando's te leren gebruiken. Sterker nog, het lijkt wel of zelfs wordt aangeraden bij de commandprompt zo ver mogelijk vandaan te blijven, dan kan je immers ook niks verprutsen. Maar dat kan met Windows zonder de commandpromp dus nog steeds, dat gaat onder eender welke Linux distro toch een stuk lastiger, je systeem om zeep helpen.

Dat brengt me meteen bij het volgende punt. Verreweg de meeste gebruikers die ik ken doen niet veel meer dan een emailtje versturen, een keertje surfen op internet, een briefje tiepen en een potje patience. De OOBE van bijvoorbeeld Ubuntu of Fedora is voor die doelgroep meer dan uitstekend en heeft intuitief een betere indeling dan welke Windows dan ook. Het werkt helder en stabiel, bij een probleem wordt het programma afgesloten ipv. een BSOD of een spontane vastloper/reboot.

Daar komt nog eens bij dat de 'leek' het nogal eens wil proberen een programma te installeren, klik klik klik en voltooien, en de 'leek' voelt zich een geweldenaar op zijn computer. De Linux (Ubuntu) variant heeft het simpeler bekeken, met Add/Remove of de Synaptic Package Manager installeer je in een handomdraai het programma wat je hebben wil op de enige juiste wijze, je kunt gewoon bijna niets verkeerd doen. De update feature werkt fantastisch, niet net als onder Windows ieder programma apart updaten, één simpel progje bekijkt bij opstarten óf er updates zijn en met één druk op de knop wordt je hele systeem geupdate.

Nu ben ik niet speciaal een Windows óf Linux fanboy, ik gebruik beide. Ik bekijk het deze keer echter vanaf de zienswijze van de 'leek' en/of de eenvoudig computergebruiker en kom zo tot de conclusie dat voor enkel het basisgebruik van een PC de Linux varianten net wat beter zijn ingedeeld en stabieler draaien dan welke Windows dan ook. (hoeft men het niet persee mee eens te zijn, dit is mijn ervaring) Het werkt simpel en wijst voor het grootste gedeelte zelf de weg. Net als onder Windows is het even de weg leren kennen maar het is inmiddels wel bewezen dat men het onder Linux net wat sneller doorheeft door het intuitieve karakter van diverse distro's.

[flowerp]

Ik bekijk het deze keer echter vanaf de zienswijze van de 'leek' en/of de eenvoudig computergebruiker en kom zo tot de conclusie dat voor enkel het basisgebruik van een PC de Linux varianten net wat beter zijn ingedeeld en stabieler draaien dan welke Windows dan ook.

Daar ben ik het helemaal mee eens en ik verkondig dit dan ook al wat langer. -JUIST- voor de leek is Linux enorm geschikt.

Het is juist het middenveld die problemen heeft met Linux. Dat zijn de mensen die 'Windows all kennen'. Vaak is dan niet Linux zelf het probleem (soms wel), maar het feit dat iets "niet is zoals in Windows". Het midden veld denkt vaak in 2 termen: "zoals Windows = goed", "niet zoals Windows = slecht".

Een programma opstarten door een icoontje dubbel clicken op de desktop in Linux vinden ze dus goed, want dat is zoals in Windows. Ook een venster slepen is goed, want ook dat is zoals in Windows. Een virtuele desktop of apt-get is automatisch slecht. Niet omdat het opzich slecht is, maar puur omdat het niet is zoals Windows.

De echt geavanceerde IT'er, ook al is deze 100% Windows gebruiker geweest zal dan weer minder moeite hebben met het concept Linux. Tuurlijk, voor deze gebruiker zal de overstap ook zwaar zijn, want hij of zij weet exact welke setting waar staat in Windows en wat deze doet. Echter, bij het upgraden van een major Windows versie moet de expert ook weer dingen overnieuw leren, dus Linux wordt dan alleen als een wat grotere uitdaging gezien.

[TDeK]

"Het midden veld denkt vaak in 2 termen: "zoals Windows = goed", "niet zoals Windows = slecht"."

Windows heeft nu eenmaal een gigantische userbase waardoor veruit de meeste mensen bekend zijn met de 'Windows' manier van werken. We kunnen het onszelf onnodig gecompliceerd gaan maken, of we kunnen dit gewoon als standaardisering zien en hiermee verdergaan. Er zijn vele apparaten, software en andere zaken gesneuveld, puur omdat de maker vond dat hij het beter wist qua bediening of gebruiksgemak. De gebruiker wil _alles_ in een GUI doen ala Vista of OSX, anders is het gewoon oude troep.

De nieuwe versie van Ubuntu heeft dit al vrij goed door, ik was blij verast met het aanzicht van alleen al de desktop. Daarbij kun je nu ook binnen no-time o.a. codecs installeren. Je krijgt een mooie melding dat de nu komende codec closed-source of wellicht illegaal is, maar na een druk op de knop werkt het gewoon. En daar gaat het om: het boeit me niet hoe, als het maar werkt. En zo denken veel eindgebruikers er ook over.

[Havelock]

Kijk dan kan je nog beter linux mint gebruiken www.linuxmint.com

Daar zitten alle codecs al in en geen geklik meer enige wat je niet ziet is dat dat close-source dingen installeert want die zijn al voor geinstalleert(codecs).

Zo zijn er nog meer dingen anders maar voor de grote lijnen zijn er veel overeenkomsten.
Want linux mint is namelijk voor 98% van ubuntu afgeleid alles wat je dan op ubutnu kan moet dan ook linux mint kunnen.

Probeer het zelf maar eens zal het zien de kracht van linux is.

Zins ik linux mint heb geprobeerd wil ik niks anders meer ook al heb ik nog andere linux distro's geprobeerd.

Wat kan linuxen toch heerlijk zijn.

[Umbrah]

Je hebt een aantal misvattingen:

Klopt wel grotendeels wat je zegt. Maar net als bij Windows (95/98/NT/XP/Vista) heeft ook Microsoft er een commandprompt ingebouwd dus is het verschil met Windows niet zo heel groot.

Klopt, windows heeft een command prompt, sterker nog: het heeft er zelfs 2. Een soort dos-emulator die we kennen als "cmd", en de zgn. Recovery console. Die laatste is een "echte" command prompt, maar zelfs die is (in vista) eigenlijk niet meer nodig. Voor meer referenties, ga maar eens spelen met de repair functie van de vista setup.

Hoewel Linux de laatste tijd en zeker met de "personal" distro's zoals ubuntu enorme stappen vooruit is gegaan GUI-gewijs, ontkom je, als je een tikkie een complexere taak dan normaal wilt doen, niet aan die command prompt. Ga maar eens de helpfiles van ubuntu na.

In deze tijd dat consumer electronics en PC technologie steeds meer versmelten, kan dat dus ook niet meer. Een command prompt is het meest ongebruikers vriendelijke wat er bestaat, tab completion of niet. Het hoeft gewoon niet meer anno 2008. Beetje het "wii" syndroom. De PC is al lang geen hobbykamer/zolder product meer. Hij staat in de woonkamer bij iedereen.

Dat brengt me meteen bij het volgende punt. Verreweg de meeste gebruikers die ik ken doen niet veel meer dan een emailtje versturen, een keertje surfen op internet, een briefje tiepen en een potje patience. De OOBE van bijvoorbeeld Ubuntu of Fedora is voor die doelgroep meer dan uitstekend en heeft intuitief een betere indeling dan welke Windows dan ook. Het werkt helder en stabiel, bij een probleem wordt het programma afgesloten ipv. een BSOD of een spontane vastloper/reboot.

Weet niet wat voor mensen jij kent, maar dat potje patience is ondertussen geupgrade naar "de sims" en andere soortgelijke "feel good" spellen, keek laatst op m'n ouders hun PC, en zag tot m'n schrik dat vista ontspanning 113 items erin had staan, waarvan 99 Zylom Games. En dat is goed, toch?

Ondertussen staat er ook ~80gb aan muziek op, gekocht, geript en gecatagoriseerd door mijn vader, die gek is op z'n muziek verzameling beheren en z'n LP's en Audio CD's te bewaren/compilaties branden. Tevens heeft z'n filmpje eindelijk plaats gemaakt voor een digitale camera, en hij bestelt printjes van z'n foto's op internet, maakt albums via de TNT post fotoservice, en meer van dat soort dingen. De man is 54, en over het algemeen kan ik veilig zeggen: Als HIJ het doet, dan is de tijd van "briefje tikken en patience" permanent voorbij.

Tevens volstaat windows add/remove volwaardig, en "msi" packages zijn niet zoveel anders meer dan RPM's. Vroeger had je een punt gehad, maar software beheer in windows is zéker niet slecht. En windows update reboot óók pas nadat alle updates zijn geinstalleerd, of helemaal niet. Kan ook sinds vista SP1.

Aan je comment over BSOD's te horen als één programma crashed, heb je geen windows meer gebruikt sinds 95, het enige wat windows écht kan laten rebooten is een fout van een high level driver, zoals een videokaart. Geluidskaart kan crashen zonder problemen, houd het gewoon op. Heeft creative me in de begindagen vaak zat duidelijk gemaakt. En nVidia ook.

Hoewel dit natuurlijk erg windows, en dan vooral vista, fanboy-achtig klinkt (ze zouden echt eens wat linux "gurus" achter vista moeten zetten en het ECHT uit laten proberen, een paar hebben goede kritiek, maar als ik het zo hoor hebben de meesten het niet gebruikt, zeg niet dat dat bij jou zo is), ben ik dat zeker niet. Sterker nog: op MacOS X systemen na heb ik thuis alles draaien, hoewel ik laatst mijn BSD server maar voorzien heb van Edge, hoewel ik twijfel nu ze niet samenwerken met LSB, om een non-debian distro te gaan installeren.

[Terracotta]

Wil je geen command prompt voor je instellingen? kies opensuse of novell linux desktop... yast2 is your thing, echt er zijn zoveel distros met elk hun voorkeur, debian kiest voor command prompt, al kan je ook daar meer en meer grafisch doen. Het probleem blijft closed source programmas en de directe ondersteuning van recente hardware, de rest is meer dan goed genoeg en doet zeker niet onder voor windows, vind windows persoonlijk zelfs slechter.

[Miglow]

Mijn vader is 59 en die doet dat echt niet. Hij tikt en print een briefje, leest z'n email, doet z'n bankzaken via internet, google't wat hier en daar en um, m'n moeder van 62 doet tripeaks.

[ATS]

Een commandprompt is helemaal niet gebruikersonvriendelijk. Het ligt er alleen nogal aan wat je wil doen. Voor bepaalde taken is het oneindig veel handiger dan een point en click interface.

The command prompt is not user unfriendly. It is just picky about who it's friends are.

[flowerp]

En het gezeur dat veel distro's geven als je een closed source programma probeert te installeren (wat is er mis met installshield? Standaardiseer dat eens voor Linux), gezeur wat irritanter is dan welke vorm van UAC dan ook.

Het ligt iets gecompliceerder dan dat. Het punt is niet dat er een installer ontbreekt, maar dat de sourcecode de 'native' taal is van Linux. Iets lagers kent Linux simpelweg niet. D.w.z. je kunt Linux geen binaries geven, omdat er geen binary compatibiliteit bestaat in Linux. In zekere zin is de status van een binary onder Linux min of meer een tijdelijk bij product van de source code; nodig om te source code daar werkelijk te draaien.

Vergelijk dit met b.v. een JVM. Deze voer je primair bytecode. Nu zou je theoretisch gezien de tijdelijke hot compiled x86 code (als je de JVM op een x86 draait) vanuit de JVM cache kunnen pakken en deze weer aan een andere JVM kunnen geven. Aangezien dit een intern formaat zal zijn, zal dit alleen werken als die andere JVM -exact- identiek is (zelfde vendor, zelfde versie, exact zelfde platform, etc).

Een tikkeltje kort door de bocht is Linux dus een hele high level VM die applicaties in source code vorm uitvoert. Elke compilatie op die source is eigenlijk intern voor jouw specifieke systeem. Daarom kun je dus ook (eigenlijk) geen binaries publiceren voor Linux. Door uit te gaan van bepaalde versies (met name distributie, kernel, gcc, libs) -kan- het wel eens werken onder Linux, maar het werkt vaker niet dan wel.

Dit veranderen haalt de hele architectuur van Linux onderuit. Het is van de grond af aan opgebouwd om source code te draaien en binaries bestaan eigenlijk niet binnen deze architectuur.

Een tussenoplossing zou kunnen zijn wat Apple heeft gedaan: bedenk een universal binary formaat, waarin je binaries opneemt voor de +-32 meest populaire combinaties.

Natuurlijk helpt dit niet zodra jij upgrade naar een kernel die nog niet bestond toen de binary gemaakt werd. Dat zou dan weer opgelost kunnen worden door een meer transparantere vorm van iets als User Mode Linux. Zorg dat je bijvoorbeeld 128 ofzo van de meest recente linux versies hebt installed in UML vorm. Als je een binary probeert te draaien zou Linux deze kunnen herkennen en automatisch door 1 van je 128 installs laten uitvoeren. Als elke binary dan ook nog eens 32 afzonderlijke binaries bevat, dan heb je zo'n 4096 mogelijkheden om je binary uit te voeren. Dit klinkt belachelijk groot, maar gezien alle mogelijke Linux combinaties is het nog niet eens zo gek.

[Cyphax]

D.w.z. je kunt Linux geen binaries geven, omdat er geen binary compatibiliteit bestaat in Linux

Ik denk dat je in de war bent met iets anders. Die binary compatibiliteit tussen Linux-systemen is er wel hoor. De binaries hebben een standaardformaat, meestal Elf, eventueel nog a.out (support zit in de kernel - Linux zelf) maar het probleem ligt bij de dependencies. Die dependencies zijn libraries die gebruikt worden door die software, je hebt geen garantie dat die dependencies ook geinstalleerd zijn. In Windows zag je dat ook weleens terug, als je bijv. de VB6 runtimes ofzo mist. Microsoft maakt zelf de libraries die mensen gebruiken, dus heeft elke Windowsinstallatie die libraries wel aan boord.

Een ander probleem kan zijn de lokatie van software. En dat probleem probeert men o.a. op te vangen met LSB.

Dan heb je ook nog de verschillende packageformaten die niet compatible zijn. Debian heeft een eigen formaat (.deb), Gentoo heeft een eigen formaat, Slackware heeft een eigen formaat en dan heb je ook nog de RPM's van Red Hat. Nu wordt .deb het meest gebruikt, mede door het succes van Ubuntu. Voordeel is dat bijna iedereen hun software aanlevert in onder andere .deb. Als je dus Ubuntu draait kun je vrijwel alle software wel installeren zonder bang te hoeven zijn dat je moet gaan compilen van source. Wat mij betreft is er ook niet echt een groot probleem.

[Reactie gewijzigd door Cyphax op 23 juli 2024 00:21]

[flowerp]

Ik denk dat je in de war bent met iets anders. Die binary compatibiliteit tussen Linux-systemen is er wel hoor. De binaries hebben een standaardformaat, meestal Elf,

Dat valt wel mee hoor. Zo in de war ben ik niet, hooguit slechts een beetje Elf is meer een package formaat, dat zegt niets over op welke plek bepaalde symbols gevonden kunnen worden. Een ABI, zoals andere platformen dat wel hebben kent Linux dan ook niet.

Dit gaat een HEEL flink stuk verder dan externe 3rd party libs. Als ik gewoon in C een programma compile met een simpele main functie en een als statement slechts een eenvoudige printf, dan is het resultaat van deze binary in zekere zin slechts lokaal geldig op mijn systeem.

printf zit gewoon standaard in de C library, die elk Linux systeem heeft. printf gaat ook helemaal niet meer veranderen en heeft dat de afgelopen tig jaar ook niet gedaan. TOCH kan ik deze binary niet op een usb stick zetten en op een willekeurig ander Linux systeem draaien...

Binary compatibiliteit is -echt- wat anders dan de beschikbaarheid van bepaalde 3rd party libraries...

[deadinspace]

Elf is meer een package formaat, dat zegt niets over op welke plek bepaalde symbols gevonden kunnen worden. Een ABI, zoals andere platformen dat wel hebben kent Linux dan ook niet.

Toch wel. Op het laagste niveau bestaat die ABI uit ELF, waarin een executable vastlegt welke libraries hij nodig heeft, en welke symbols hij daaruit wil gebruiken.

Een laagje hoger heb je de ABI van individuele libraries, bestaande uit o.a. de gebruikelijke C calling convention (argumenten op de stack), de argumenten die een functie accepteren, en de layout van bepaalde datastructuren (zoals struct stat, om maar eens wat te noemen).

De ABI's van inviduele libs zijn versioned, zodat gedetecteerd kan worden welke versie een library verwacht, en daar op ingesprongen kan worden. Ik heb hier de ls van een Red Hat 6.2 systeem (uitgebracht in april 2000), en als ik de versies van de gebruikte symbols opvraag zie ik het volgende:

% readelf -V ls

Version symbols section '.gnu.version' contains 84 entries:
Addr: 0000000008048c20 Offset: 0x000c20 Link: 4 (.dynsym)
000: 0 (*local*) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
004: 2 (GLIBC_2.0) 1 (*global*) 1 (*global*) 2 (GLIBC_2.0)
008: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
00c: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
010: 2 (GLIBC_2.0) 3 (GLIBC_2.1) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
014: 1 (*global*) 1 (*global*) 2 (GLIBC_2.0) 1 (*global*)
018: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
01c: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
020: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
024: 3 (GLIBC_2.1) 2 (GLIBC_2.0) 1 (*global*) 2 (GLIBC_2.0)
028: 0 (*local*) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
02c: 2 (GLIBC_2.0) 1 (*global*) 2 (GLIBC_2.0) 3 (GLIBC_2.1)
030: 3 (GLIBC_2.1) 2 (GLIBC_2.0) 3 (GLIBC_2.1) 2 (GLIBC_2.0)
034: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
038: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
03c: 1 (*global*) 2 (GLIBC_2.0) 1 (*global*) 2 (GLIBC_2.0)
040: 1 (*global*) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
044: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
048: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
04c: 1 (*global*) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
050: 0 (*local*) 2 (GLIBC_2.0) 0 (*local*) 2 (GLIBC_2.0)

Version needs section '.gnu.version_r' contains 1 entries:
Addr: 0x0000000008048cc8 Offset: 0x000cc8 Link to section: 5 (.dynstr)
000000: Version: 1 File: libc.so.6 Cnt: 2
0x0010: Name: GLIBC_2.1 Flags: none Version: 3
0x0020: Name: GLIBC_2.0 Flags: none Version: 2

De glibc symbols zijn dus hoofdzakelijk van ABI versie 2.0, en sommigen van 2.1. Nu de ls op mijn Debian Unstable systeem (zeer recent):

% readelf -V /bin/ls

Version symbols section '.gnu.version' contains 103 entries:
Addr: 0000000008048fc4 Offset: 0x000fc4 Link: 5 (.dynsym)
000: 0 (*local*) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
004: 2 (GLIBC_2.0) 3 (GLIBC_2.2) 2 (GLIBC_2.0) 4 (GLIBC_2.1.3)
008: 2 (GLIBC_2.0) 5 (GLIBC_2.1) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
00c: 2 (GLIBC_2.0) 0 (*local*) 0 (*local*) 2 (GLIBC_2.0)
010: 3 (GLIBC_2.2) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
014: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 0 (*local*)
018: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 5 (GLIBC_2.1) 2 (GLIBC_2.0)
01c: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
020: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 6 (GLIBC_2.3) 3 (GLIBC_2.2)
024: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
028: 5 (GLIBC_2.1) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
02c: 6 (GLIBC_2.3) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 5 (GLIBC_2.1)
030: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
034: 3 (GLIBC_2.2) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
038: 7 (ACL_1.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
03c: 2 (GLIBC_2.0) 5 (GLIBC_2.1) 8 (GLIBC_2.2) 0 (*local*)
040: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
044: 3 (GLIBC_2.2) 0 (*local*) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
048: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
04c: 6 (GLIBC_2.3) 3 (GLIBC_2.2) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
050: 3 (GLIBC_2.2) 9 (GLIBC_2.2.3) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
054: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0)
058: 2 (GLIBC_2.0) 2 (GLIBC_2.0) 2 (GLIBC_2.0) 1 (*global*)
05c: 2 (GLIBC_2.0) 1 (*global*) 1 (*global*) 2 (GLIBC_2.0)
060: 2 (GLIBC_2.0) 1 (*global*) 2 (GLIBC_2.0) 1 (*global*)
064: 1 (*global*) 2 (GLIBC_2.0) 2 (GLIBC_2.0)

Version needs section '.gnu.version_r' contains 3 entries:
Addr: 0x0000000008049094 Offset: 0x001094 Link to section: 6 (.dynstr)
000000: Version: 1 File: librt.so.1 Cnt: 1
0x0010: Name: GLIBC_2.2 Flags: none Version: 8
0x0020: Version: 1 File: libacl.so.1 Cnt: 1
0x0030: Name: ACL_1.0 Flags: none Version: 7
0x0040: Version: 1 File: libc.so.6 Cnt: 6
0x0050: Name: GLIBC_2.2.3 Flags: none Version: 9
0x0060: Name: GLIBC_2.3 Flags: none Version: 6
0x0070: Name: GLIBC_2.1 Flags: none Version: 5
0x0080: Name: GLIBC_2.1.3 Flags: none Version: 4
0x0090: Name: GLIBC_2.2 Flags: none Version: 3
0x00a0: Name: GLIBC_2.0 Flags: none Version: 2

En daar zien we wat nieuwere symbol versies, tot aan 2.3. De hoofdmoot is nog steeds 2.0 trouwens, dus blijkbaar is er voor de meeste symbols niet veel veranderd.

Er zijn trouwens wel eens ABI compatibility issues geweest, daar niet van. Maar de situatie is toch een heel stuk anders dan jij hem omschrijft.

Dit gaat een HEEL flink stuk verder dan externe 3rd party libs. Als ik gewoon in C een programma compile met een simpele main functie en een als statement slechts een eenvoudige printf, dan is het resultaat van deze binary in zekere zin slechts lokaal geldig op mijn systeem.

printf zit gewoon standaard in de C library, die elk Linux systeem heeft. printf gaat ook helemaal niet meer veranderen en heeft dat de afgelopen tig jaar ook niet gedaan. TOCH kan ik deze binary niet op een usb stick zetten en op een willekeurig ander Linux systeem draaien...

Ik compile jouw simpele printf programmatje op een Red Hat 6.2 (april 2000) machine:

% cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)
% cat hello.c
#include <stdio.h>

int main( int argc, char **argv )
{
printf( "Hello, world!\n" );
}
% gcc -o hello hello.c
% md5sum hello
dfbf66120686bbf9e8e30093f7a3eb24 hello
%

En run hem op mijn Debian Unstable machine (juli 2008):

% cat /etc/debian_version
lenny/sid
% md5sum hello
dfbf66120686bbf9e8e30093f7a3eb24 hello
% ./hello
Hello, world!
%

En hee, dat werkt! Wat ingewikkelders, de ls van de Red Hat machine op de Debian Unstable machine werkt ook:

% cat /etc/debian_version
lenny/sid
% ./ls --version | grep Copyright
Copyright (C) 1999 Free Software Foundation, Inc.
% ./ls -F
Desktop/ bin/ documents/ fotos/ hello* ls* music/ projects/ video/
%

De compatibility de andere kant op (progs van de Debian Unstable machine draaien op de Red Hat 6.2 machine) is een stuk beroerder trouwens. Maargoed, dat is overkomelijk.

Nou heb ik me hier beperkt tot twee vrij eenvoudige programma's die alleen een beetje glibc gebruiken (en de glibc lui zijn vrij streng op ABI compatibility), dus bij complexere programma's ligt het wat ingewikkelder dan hier. Maar de situatie is toch echt minder dramatisch dan jij het omschrijft.

[Reactie gewijzigd door deadinspace op 23 juli 2024 00:21]

[flowerp]

Maar de situatie is toch echt minder dramatisch dan jij het omschrijft.

Hmmm, ok, I stand corrected Bedankt voor het uitgebreide voorbeeld.

Zoals gezegd, ik heb al een tijdje niet meer op Linux ontwikkeld voor Linux zelf, maar de problemen waar ik eerder tegen aanliep waren er wel toen wel degelijk. Ik werkte op een lab in een shared omgeving via een X-terminal. Gecompileerde programma's stonden in mijn home. Als ik dan soms de volgende dag weer verder ging had men wel eens het system geüpdate (kernel, gcc, etc). Meer dan eens kon ik dan de boel overnieuw compileren omdat er dingen niet meer werkte. Ook enkele van m'n (commandline) apps die ik maakte en via een grid liet lopen waar diverse nodes verschillende Linux versies draaide wilde niet lopen.

Maar goed, ik was zeker niet een expert Linux developer, dus wellicht dat ik zelf wat fout deed...

[Verwijderd]

Nou heb ik me hier beperkt tot twee vrij eenvoudige programma's die alleen een beetje glibc gebruiken (en de glibc lui zijn vrij streng op ABI compatibility), dus bij complexere programma's ligt het wat ingewikkelder dan hier.

In de praktijk is toch wel rottig hoor. Ik probeer b.v. vaak die VMWare console te installeren (dus niet heel VMWare, maar alleen de client om naar een VMWare server te connecten). Deze wordt als een binaire ding geleverd, maar wat een hel om die aan de praat te krijgen elke keer. Firefox heeft het goed voor elkaar, maar kan mozilla misschien even haar gebruikte techniek aan VMWare uit leggen dan?

[Verwijderd]

Dan vraag ik me toch af hoe Firefox's Linux binaries gewoon te downloaden en te gebruiken zijn op elk Linux systeem.

[flowerp]

Dat is een zeer knap stukje engineering werk van de mozilla organisatie ja, maar zeker niet iets wat je out of the box voor elkaar krijgt.

De huidige binary van firefox werkt op de huidige populaire systemen maar voor zover ik weet kan een enkele kernel upgrade dit potentieel alweer te niet doen. Ik moet zeggen dat ik wellicht mijn kennis weer wat moet updaten (ik ontwikkel al een tijdje geen Linux software meer), maar nog niet eens zo lang terug was dit echt wel een zeer concreet probleem. Misschien is het nu wel beter, hoewel ik een grote juich aankondiging hierover dan zeker wel ergens had moeten oppikken.

2 willekeurige links:

http://www.pixelbeat.org/...binary_compatibility.html

en

http://ask.slashdot.org/a...11/24/2230256&threshold=1

quotes:

There is no official Kernel ABI (Application Binary Interface)

en:

For larger library interface changes, a new version of the library will be used, which presents a major problem for binary compatibility as an application can only be linked to one particular version of a library.

en:

Now, binary compatibility on Linux is a total pain in the butt. Incompatibilities in glibc 2.2 vs 2.3, pthreads vs nptl, gcc C++ ABI is broken on every other gcc release, thread local storage, just to name a few hurdles

Dit is ongeveer ook mijn ervaring van slechts enkele jaren geleden. Maar zoals gezegd, -misschien- is het tegenwoordig beter...

[graey]

Ik weet het niet zeker hoor, maar het beperkte aantal programma's dat ik in Linux compileer is gewoon bruikbaar, ook na een kernel-upgrade, alleen kernel modules niet, maar dat is niet meer dan logisch...
Als ik bijvoorbeeld een keer vanaf de debian-site een bepaald pakket download hoef ik ook alleen maar te kijken of hij wel voor mijn processorarchitectuur is, kernelversie maakt alleen uit bij dingen die echt iets 'met de kernel doen'. Sterker nog, sommige pakketten die ik heb kan ik alleen vinden voor Ubuntu 6.10. Installeer ik dezelfde pakketten in 7.10 (8.04 heb ik nog niet geprobeerd), dan werken ze gewoon. En ja, ik weet zeker dat dat binary-pakketten zijn.

[lvh]

Zegt de term "static binary" jou ook maar iets, flowerp?

[flowerp]

Zegt de term "static binary" jou ook maar iets, flowerp?

Zegt de term "resource waste" jou ook maar iets, racoontje?[/quote]

[AlBundy]

Wat een verschrikkelijke onzin kraam je uit! Het is absoluut geen knap stukje vakwerk om iets te coden wat op elk Linux-systeem draait.
Als je zorgt dat je standaard-libraries gebruikt, of ervoor zorgt dat je de benodigde libraries als dependencies opgeeft, draait het onder elk systeem.

Ik heb nog nooit meegemaakt dat een nieuwe kernel programma's onbruikbaar heeft gemaakt. Het enige wat na een kernel-update niet meer werkt, zijn je eigen custom-compiled kernel modules, zoals de nvidia of ati-driver voor je videokaart. Maar dat is een kwestie van de installer opnieuw draaien en dan wordt de module weer gelinkt.

Als je een distro gebruikt met een goede package manager, heb je hier ook zeker geen omkijken naar. Een distro met apt en dpkg installeert netjes wat je nodig hebt aan libraries.

En natuurlijk zijn er altijd utizonderingen voor exotische hardware/software, maar ik heb in de tien jaar dat ik met GNU/Linux heb gewerkt (resp. met Debian, Gentoo en Ubuntu), op tig verschillende systemen nog nooit problemen gehad betreffende binary compatibility.

[Verwijderd]

Wat een verschrikkelijke onzin kraam je uit! Het is absoluut geen knap stukje vakwerk om iets te coden wat op elk Linux-systeem draait.

Doe me een lol en ga dan zelf bij VMWare, Adobe of Google werken. Als het echt zo makkelijk is, waarom worden alle applicaties van tenminste die bedrijven dan niet als een makkelijke overal te draaien binary aangeboden?

[YaPP]

Dan vraag ik me toch af hoe Firefox's Linux binaries gewoon te downloaden en te gebruiken zijn op elk Linux systeem.

Dat kun je bereiken door op een oud Linux systeem de boel te compileren. Slackware 10.0 is hier bijvoorbeeld erg geschikt hiervoor, mede omdat er weinig tot geen patches (=wijzigingen aan de ABI) worden toegevoegd door de Slackware ontwikkelaars.

In glibc zitten van iedere functie meerdere versies. Standaard probeert de compiler je binary te linken tegen de laatste symbolen, waardoor de binary dus niet werkt op oudere systemen. Er zijn allerlei trucks voor om dit te voorkomen, maar het makkelijkst is een oude distributie gebruiken.

Een tweede mogelijkheid is statisch-linken, of alle library's zelf meeleveren in een map.

[Reactie gewijzigd door YaPP op 23 juli 2024 00:21]

[MadEgg]

Inderdaad, wat voor compiler gebruik jij? Dat gaat dus echt wel werken. De enige manier waarop je misschien incompatibiliteit kan creeren is door specifiek op jouw systeem toegespitste compiler flags te gebruiken, maar zolang je dit een beetje algemeen houdt zal het overal draaien.

[marcieking]

Heb je ooit ubuntu geinstalleerd? Als je een baviaan leert een muis te gebruiken kan hij ook Ubuntu installeren... Daarnaast kunnen de mensen die geen Ubuntu kunnen installeren ook geen Windows installeren, dus dat is eigenlijk een vreemd bezwaar.

[Reactie gewijzigd door marcieking op 23 juli 2024 00:21]

[Umbrah]

Ja, ik heb ooit ubuntu geinstalleerd. Natuurlijk heb ik dat, kun je haast wel stellen. Het partitioneren met een al bestaand besturingssysteem was opzich wat "vaag", vager dan de partitionering in vista (/dev/HD0 wtf? Windows gebruikt device/controller naam). Daarnaast besloot hij "uit zichzelf" om me nog een 2e keer te vragen om te partitioneren.

En dan nu het leukste: Voor sommige van mijn hardware was er geen open source AMD64 driver, ondanks dat er vermeld werd op de ubuntu pagina dat de versies identiek zijn. Erger nog: ik miste een aantal belangrijke dingen in ubuntu, basis dingen zoals een GUI om de bootmanager mee te beheren (wil windows standaard, niet ubuntu!), een "device manager", die zit wél in de 32 bit versie, maar in de 64 bit versie stond hij er niet standaard in en moest hij gedownload worden, wat me weer terugbrengt bij het probleem dat alle 3 m'n netwerkkaarten niet een open source 64 bit driver hadden, wat er voor zorgde dat ik héél veel gekloot met het mounten van m'n windows partitie mocht uitspoken om de closed source driver handmatig te installeren.

Ja, een aap zou ubuntu op een kale PC kunnen installeren en gebruiken, mits hij de 32 bit versie pakt, en out-of-the-box hardware heeft. En dan moet diezelfde aap héél wat meer geklooi uitvoeren om er daadwerkelijk comfortabel mee te werken, want niet alles zit standaard in ubuntu. Blijkbaar zijn die ubuntu vogels een tikkie angstig wat betreft closed source. Closed source is niet noodzakelijk slecht, en open source is niet noodzakelijk goed/gebruikers vriendelijk. Dat is ook iets wat in "houding" moet veranderen in de open source community. Blijf bij mijn punt dat eigenlijk alleen Mozilla het een béétje door heeft. Nu zouden ze wat TV reclame mogen maken en deals met OEMs sluiten.

[zenlord]

Je snapt het niet. Gebruiksvriendelijkheid heeft niets te maken met de installatie van een OS. Eens linux is geïnstalleerd, durf ik het iedereen voorschotelen om er dagelijks mee te werken. Zo heb ik mijn moeder en grootvader laten overschakelen voor het gewone huis-, tuin- en keukenwerk (vooral mail en surf dus), heb ik mijn twee pc-analfabete kantoorgenoten op debian linux laten overstappen en heb ik onlangs een nonkel zover gekregen om Ubuntu te gaan gebruiken, aangezien XP telkens bleef crashen, hoe vaak ik het ook herinstalleerde.

Elk van die mensen gebruikt het naar volle tevredenheid.

Mijn advies aan jou: zoek iemand om je te begeleiden tijdens de installatie en/of probeer verschillende distro's uit om te zien welke je aanstaan (probeer bvb zeker eens Arch linux - zeer spartaans, maar o zo eenvoudig en supersnel). En gebruik dan eens linux voor je dagdagelijkse taken. Wist je trouwens dat er een native-linux versie bestond van picasa en dat F-spot nagenoeg dezelfde functionaliteit biedt als picasa?

Let op: het maakt mij persoonlijk geen bal uit of je dit advies nu aanvaardt of niet. Maar ik vind jouw getuigenis hier niet kloppen. Je hebt duidelijk tijd geïnvesteerd in het leren kennen van de windows-installatie, en nu wil je dat linux op zich hetzelfde zou doen als windows. Dat is een foute ingesteldheid - als je wil overstappen op linux, moet je aanvaarden dat je met iets fundamenteel verschillends gaat werken, en dus dat je praktisch van 0 moet herbeginnen. Ik kan je verzekeren dat dat best moeilijk is, maar ik heb er nog geen seconde spijt van gehad.

Na een kleine twee jaar windows-vrij te zijn heb ik gisteren voor het eerst zelf een groot probleem op twee linux-kantoorpc's kunnen identificeren en oplossen, zonder enige tussenkomst van onze support of zelfs nog maar van google... Onder windows kon ik dit gevoel zeer regelmatig ervaren - nu begin ik het gevoel te krijgen dat linux geleidelijk aan zijn grenzen voor mij begint te ontsluiten. Neem de tijd.

[Reactie gewijzigd door zenlord op 23 juli 2024 00:21]

[Verwijderd]

In je eerste post gaat het over je picasa-vader en nu begin je ineens over 3 netwerkkaarten, een bootloader en amd64 (voor mijn hardware zijn ook niet allemaal 64-bit drivers onder windows trouwens), niet echt fair.

[Umbrah]

Ik heb een picasa vader met zijn eigen machine, wat, voor je info: een alles-on-board machine is met een Core2 Duo stijl CPU met 2gig geheugen.

Mijn eigen machine is iets complexer; gebaseert op een Asus P5E moederbord, waar 2 NIC's op zitten, en ik heb er een PCI-E WiFi kaartje bij ingestoken (gebaseert op een broadcom chippie).

Antwoord aan zenlord; Natuurlijk is het me gelukt, zoals ik al eerder zei: Ik zit in de (unieke?) positie dat ik een aardige professionele ervaring heb, maar ook een stuk klanten ondersteuning in verschillende richtingen kan doen. Tevens doe ik voor het bedrijfskundige gedeelte van mijn opleiding af en toe een markt onderzoek, en volg ik "de ontwikkeling". Het success van nintendo's "touch" generatie spelcomputers verbaaste mij eigenlijk dus ook niets.

[Miglow]

Ach ja, krijg je kritiek of commentaar op het ene bijgehaalde punt, haal je gewoon het volgende aan. Laten we in een discussie over Linux eens lekker beginnen over een nintendo spelcomputer. Feit is dat wanneer je hardware had gekozen die native ondersteund word in Ubuntu, je geen enkel probleem had gehad. Voor iemand die wat van pc's weet, ben je er namelijk vrij makkelijk vanuit gegaan dat het wel zou werken. Ik denk dat je volgende keer makkelijker even kunt checken welke hardware compatible is en out-of-the-box ondersteund word voor je iets koopt.

Mijn Asus M3A-78EMH HDMI bijvoorbeeld werd van de geluidskaart tot de netwerkkaart en ATI-onboard grafische chip 100% ondersteund. Sterker nog: Ubuntu gaf me de keus tussen closed-source en open source drivers om 3D te ondersteunen. Heb ik Windows nog nooit zien doen bijvoorbeeld, erop wijzen dat de standaard driver vervangen kan worden omdat er een betere variant voor is.

[Katsunami]

Feit is dat wanneer je hardware had gekozen die native ondersteund word in Ubuntu, je geen enkel probleem had gehad.

Dat is nu juist het probleem Soms wil iemand een bepaald stuk hardware gebruiken vanwege bepaalde functies; als het dan niet wordt ondersteund, dan "heb je pech". Soms MOET je een bepaald stuk hardware gebruiken omdat er eenvoudigweg geen alternatief is. Dan vervalt Linux als OS. Dat zou natuurlijk ook andersom zijn als je een stuk hardware of software hebt waar geen Windows-variant van bestaat.

Hardware blijft, IMHO, het meest heikele punt. Zelfs mijn meer-standaard-is-niet-mogelijk-notebook krijg ik niet 100% aan de praat. (Wel voor 80%, en vrij gemakkelijk ook nog, maar de laatste 20% kost me 1000% extra tijd die ik niet heb om hieraan te besteden.)

Zolang mensen niet gewoon naar de winkel kunnen gaan, een willekeurig stuk hardware kunnen kopen en een CD-tje in hun Linux-PC kunnen kiepen om het te installeren, gaat het niet goed komen met de Linuxdesktop voor de massa. Zodra ik gewoon bij de fabrikanten drivers kan downloaden (of een bijgeleverde CD kan gebruiken) om wel stuk hardware dan ook te installeren, ben ik de eerste die fulltime overstapt. Linux moet medewerking krijgen van de grote hardwarefabrikanten in de computerwereld om te slagen. DAT is de reden waarom MS zo groot is geworden.

(Al was het maar om iets anders te gaan gebruiken na 15 jaar probleemloos Windows-gebruik. Maar ja, ik zit dan ook al sinds 1996 op de Windows NT-kernel, en draaide daarvoor, tussen 1994-1996 OS/2 3.0 met daaronder Win/OS2 voor Windowsprogramma's, en tussen 1990-1994 gebruikte ik DOS en Windows 3.0. Mijn enige "uitstap" naar Win98 was op mijn Pentium 2 350, vanaf half 1999 tot begin 2000, om mijn USB-scanner te ondersteunen.)

[Reactie gewijzigd door Katsunami op 23 juli 2024 00:21]

[graey]

Yup, het aloude verhaal van dat Linux als OS onderuit gaat omdat de hardwaremakers (wiens eigenlijke plicht het is om fatsoenlijke drivers te leveren voor meer dan 1 OS) geen drivers leveren. En vaak wordt het dan ook nog aan de distromakers/kernelschrijvers verweten...
En dat hele gedoe is ook precies de reden dat je min of meer probleemloos Windows kan gebruiken (zolang je geen exotische hardware gebruikt met rare drivers of oud spul, want dat kan tegenwoordig ook steeds minder in Windows), want daar wordt bij 90% van alle hardware drivers geleverd voor Windows.

[triflip]

wat voor NICs heb jij dan? mijn onboard nic werd gewoon gezien en zelfs mijn USR usbsticky werd gezien en connecte meteen naar het eerste beste onbeveiligde netwerk.

en ja dat was ubuntu 64bits

[Wim-Bart]

Ja, maar Ubuntu krijg ik niet geïnstalleerd op mijn Laptop met een standaard CD/DVD. En ook al niet met mijn PC.

Met Vista en XP is dat anders, gewoon ff een USB stickie of Floppy of ander medium met een boot drivertje. Maar onder Linux moet je een aangepaste kernel hebben waarin opeens speciale modules meegelinked moeten zijn (gaap wat een werk weer).

Maar uiteindelijk wel gelukt om Umbutu te installeren dus ook maar ff mijn HP laptoppie onder de hand genomen. Fuck shit en nog meer ellende, weer een andere CD maken om te installeren.

Kortom, Windows Vista en XP in hooguit 3 kwartier, Linux halve dag....

[ronny]

Voor vista kan ik nog een beetje met je mee gaan maar voor XP zeker niet.
XP in 3 kwartier installeren? Dacht het niet.
XP kent vrijwel geen enkele driver dus voor veel SATA moet je al een DISKETTE hebben om te kunnen installeren.
Vervolgens moet je in de stapels CD gaan zoeken naar een driver voor het netwerk omdat je anders een update's kan installeren vervolgens allerlei website afstruinen naar drivers. Welke geluidchip zit er ookal weer in. En net voor het uitkomen van SP3 was je al bijna een dag bezig om alle update's binnen te halen en tussen door te rebooten voor het een of ander.
Maw XP installeren en volledig gebruiks klaar lukt niet in 45 min tenzij je van te voren een nLite CD hebt gemaakt met alle updates en drivers. Maar dat is geen verdienste van Windows.
Ik ben vanaf 96 al bezig met Linux maar heb nog niet anders mee gemaakt als CD er in en gaan en direct draaien. Soms een kleine randapparaat dat niet werkt maar dat kan je Linux niet kwalijk nemen.

[Wim-Bart]

XP is wel dergelijk in 3 kwartier te installeren. En dat zonder slipstream CD. Dat je daarna nog servicepacks op moet zetten neem ik even niet mee, maar tja, bij bijvoorbeeld SuSe is ie daar ook 4 uur mee bezig.

Maar een nLite Slipstream CD van XP werkt helemaal lekker, vooral als je daar al alle mogelijke drivers op hebt staan, maar dat is niet eerlijk. Overigens op mijn Core Duo laptop duurt installatie ongeveer 40 minuten, inclusief SP3 en de Dell Software en drivers.

[Kwastie]

Technisch gezien is Ubuntu/Kubuntu/Xubuntu ook allemaal debian. En volgens mij vormen ze samen een heel groot aandeel van de Linux markt.

[Verwijderd]

Toch staat Canonical wel in het rijtje van aangesloten partijen, dus daarmee zijn de { , K, X}ubuntu-distributies binnen, zou je zeggen.

[dmantione]

Ja zo kan ik het ook: Mandriva/Centos/Scientific Linux is zeker ook allemaal Red Hat? En SuSE is Slackware?

[Reactie gewijzigd door dmantione op 23 juli 2024 00:21]

[deadinspace]

Debian grote distributie ?

Qua naamsbekendheid maar niet qua installed base.

Heb je daar een bron voor?

Naar mijn idee is de installed base van Debian juist behoorlijk groot. Het is zeer populair als serverplatform (niet zonder reden overigens).

Van de mensen die ik ken gebruiken verreweg de meesten Debian. Ook als je regelmatig op het Tweakers.net forum komt, dan zie je duidelijk dat Debian heel veel gebruikt wordt onder de forumbezoekers.

[Verwijderd]

zorgt dit er ook voor dat kde programma's beter op gnome gaan draaien en omgekeerd? dit mis ik nog wel...

[graey]

Dit kan al, zolang je dan maar de goede libraries installeert binnen gnome. Het zal niet zo zijn dat dit ervoor zorgt dat KDE applicaties in Gnome opeens GTK gebruiken. Wat je moet voorstellen is dat dit ervoor zorgt dat er een standaard is voor hoe gecompileerde bestanden in Linux eruit zien, waar ze in het systeem geplaatst worden en hoe ze geinstalleerd worden.
Dus niet zozeer dat applicaties library X aanroepen in plaats van library Y omdat de gebruiker voor Y heeft gekozen in plaats van X, maar wel dat de applicatie maar 1 keer hoeft te worden 'ingepakt' in een installatiebestand dat werkt op verschillende Linux-distributies (waaronder dus Ubuntu van Canonical en (open)SuSE van Novell).

[YaPP]

zorgt dit er ook voor dat kde programma's beter op gnome gaan draaien en omgekeerd?

Waar doel je specifiek op? wat wil je "beter" zien?

De LSB zegt grofweg gezegt iets over de bestanden/libraries die op het systeem aanwezig moeten zijn, en hoe die inhoudelijk zijn gestructureerd.

Er zijn andere projecten binnen de LinuxFoundation / FreeDesktop om bijvoorbeeld:
* RPC protocollen om communicatie applicaties gelijk te trekken, denk bijvoorbeeld aan:
- notificaties van een applicatie naar de desktop sturen ("nieuwe mail", "hardware aangesloten", ..)
- toegang tot een centrale password-manager / wallet.
- uitwisseling van "now playing" track informatie.
- aan het systeem te vragen een library te installeren (PackageKit).
* op dezelfde wijze een smb:// of sftp:// share aan te spreken.
* de file manager mime type instellingen gelijk te trekken.
* altijd het file open dialoog venster tonen van de huidige desktop.
* de printer instellingen te delen
v etc...

Voor ieder systeem onderdeel zal uiteindelijk een standaard komen.

[Reactie gewijzigd door YaPP op 23 juli 2024 00:21]

[blorf]

Ik draai AmaroK op xfce4. Daarvoor moeten gewoon de dependencies van AmaroK geinstalleerd worden, inclusief kdelibs. Op een andere manier werkt dat toch niet, of heb ik het mis?

[Zubzub]

Neen, gnome gebruikt de gtk grafische library die, ik geloof, op c is gebasseerd. kde gebruikt de qt grafische library en die is c++ . Daarnaast heb je ook nog de opkomende java (hoewel veel minder populair, zeker in de linux wereld) die de in de jdk ingebouwd swing/awt grafische interface gebruikt.

Er bestaan wel manieren om de uiterlijken van qt applicaties en gtk applicaties (en ook swing/awt iirc) op elkaar af te stemmen (=gelijk te maken).

Verder bestaat er ook de, zoals hierboven vermeld, inter client communications convention (http://en.wikipedia.org/w...cation_Conventions_Manual). Dit is een standaard systeem om grafische applicaties via de X grafische server informatie naar elkaar door te zenden. Voorlopig is dit echter beperkt tot applicatie icoontje, applicatie naam, copy/paste ed.

[Reactie gewijzigd door Zubzub op 23 juli 2024 00:21]

[SirBlade]

[sarcarsme-mode]
En ik maar denken dat de opensource community zo dol was op standaarden. Blijkbaar niet dus, anders was dit niet nodig. Laat ze eerst eens hun eigen zaken op orde krijgen voordat ze gaan klagen over het gebrek aan standaarden bij derden.
[/sarcarsme-mode]

[brompot758]

Er zijn standaarden en er zijn standaarden.

Standaarden voor bestandsformaten zorgen ervoor dat je documenten en andere bestanden uit kunt wisselen, ook als iemand anders een ander OS gebruikt. Dat wordt in de OS wereld vrij goed nageleefd.

Standaarden voor protocollen zorgen ervoor dat computers met elkaar kunnen praten. Als iedereen zijn web verkeer op zijn eigen manier deed i.p.v. http dan was Internet nooit zo groot geworden. Dat vult men in de OS comunity vrij goed in.

Programmeer standaarden (waar staan config files e.d.) is nog niet altijd consistent in Linux. Met een configure script worden de meeste verschillen wel weggepoetst, maar daarmee ben je source compatible, niet binary compatible. En Binary compatibility is wat LSB nastreeft.

Overigens is LSB puur iets voor Linux en de Linux comunity is iets anders dan de open source community. Al maakt de eerste wel deel uit van de tweede.

De open source community streeft naar standaarden, en is daar m.i. veel verder in dan veel anderen. Dat wil natuurlijk niet zeggen dat het standaarden Nirvana reeds bereikt is. LSB is een stap in de goede richting vind ik.

[MBV]

"The nice thing about standards is that there are so many of them to choose from." (A.S. Tanenbaum)

Linux werkt (bijna) helemaal volgens standaarden. KDE is een standaard, Gnome is een standaard, en iedereen die voor KDE of Gnome wil programmeren hoeft 'alleen maar' de API te lezen. Maar een machine zonder KDE libraries zal geen KDE programma kunnen draaien, en vice versa. Ook voor drivers zijn er heel veel standaarden: ik geloof dat je om een driver te schrijven vaak uit 3 API's kan kiezen.

De grap is nu dat hier een overkoepelende standaard moet komen die ervoor zorgt dat een programma altijd werkt, ondanks concurrerende standaarden.

[Reactie gewijzigd door MBV op 23 juli 2024 00:21]

[mie9iel]

Dat heb je verkeerd gedacht. Ze zijn dol op OPEN standaarden (vs gesloten standaarden natuurlijk).

[Pietervs]

[sarcasme-mode]
standaard flame van Windows fanboy?
[/sarcasme-mode]

[Reactie gewijzigd door Pietervs op 23 juli 2024 00:21]

[joho]

Binary compatible moet juist niet het doel zijn. Je kunt de laatste tijd zien dat er veel meer ontwikkelingen onstaan als je gemengde platforms mogelijk maakt.
Ultra-light laptops, desnoods zonder PCI bus. Chinese (MIPS-kloon) CPU's.
Handheld telefoons op ARM architectuur, of Texas Instruments DSP's.
Meer vrijheid in hardware laat nieuwe producten ontstaan, meer vernieuwing, en goedkoper.
Dus het liefst geen binaire compatibiliteit nastreven, maar een goed gedefinieerd open source platform.

[flowerp]

Dus het liefst geen binaire compatibiliteit nastreven, maar een goed gedefinieerd open source platform

Of een binaire compatibiliteit van een intermediate language natuurlijk. Zowel de JVM (tegenwoordig GPL) als de CLI (via Mono) zijn dan mogelijkheden. Omdat de JVM voor als nog voornamelijk met Java wordt geassocieerd (hoewel dat strikt gezien niet een 1:1 relatie is), heeft Mono wat betere kansen. Los van enige compatibiliteit met .NET en/of Windows zou Mono mits goed uitgevoerd veel meer kunnen betekenen voor Linux.

[Dreamvoid]

Maar het heeft een Microsoft oorsprong, en dus lopen er maar weinig Linux devs voor warm. Waarom ben je anders voor Linux gaan ontwikkelen?

Verder is zo'n intermediate VM in de praktijk helemaal niet zo universeel. Ik kan tenminste geen mobiele Java apps gebruiken op mijn desktop, en mijn Java desktop apps doen het ook niet op mijn mobieltje. Als je dan toch voor elk platform weer een aparte app moet schrijven ben je weer terug bij af, kan je net zo goed native gaan.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 00:21]

[flowerp]

Verder is zo'n intermediate VM in de praktijk helemaal niet zo universeel. Ik kan tenminste geen mobiele Java apps gebruiken op mijn desktop,

Je snapt niet helemaal wat ik bedoel denk ik. De VM maakt niet dat je op magische wijze opeens diverse soorten Java programma's kan draaien. De VM is alleen een abstractie van je CPU, niets meer en niets minder. Dat heeft dan niets met een Java platform (als in library/api) te maken.

Met zo'n VM blijf je gewoon Qt of GTK+ apps schrijven, en die apps gaan gewoon op zoek naar /etc/weetikveelwatvoorconfigfile. Het enige wat verschilt is dat je niet naar x86 compiled of naar PPC of naar Mips, maar naar intermediate assembly. Voorderest blijft het gewone Linux code. Native compilen zou dan natuurlijk gewoon een optie moeten blijven, waardoor de intermediate code feitelijk gewoon 1 van de velen compile targets wordt en niet -de- compile target.

[graey]

Zo is het theoretisch ook mogelijk om naar een 'intermediate binary' te compileren, waardoor de gebruiker het programma direct kan gebruiken, terwijl op de computer van de gebruiker in de achtergrond de 'intermediate binary' direct weer wordt gecompileerd/vertaalt naar een native binary. De volgende keer dat het programma dan wordt gestart is er een snelheidswinst behaald. Nou moet het natuurlijk niet te gortig worden, ik zou dit bijvoorbeeld niet willen wanneer mijn laptop niet aan netstroom hangt, en sommige applicaties zullen hier gewoon te groot voor zijn. Maar het is wel een mooie tussenstap om eenvoudig aan meerdere mensen native binaries te leveren zonder de broncode te hoeven prijsgeven en/of zelf laten compileren.

[reinouts]

Omdat de JVM voor als nog voornamelijk met Java wordt geassocieerd (hoewel dat strikt gezien niet een 1:1 relatie is), heeft Mono wat betere kansen.

Is er iets mis met Java dan?

[Verwijderd]

Ik denk dat er niets mis is met de JVM, maar dat er nog een barriere zit in de hoofden van veel programmeurs. De meesten denken nog JVM = Java en komen er niet op om de JVM alleen als VM voor een Linux applicatie te gaan gebruiken die b.v. in C++ geschreven is (even aangenomen dat er al een C++ compiler is voor de JVM).

[Kalief]

Lees ik het goed dat alleen ontwikkelaars hier baat bij hebben?

[Verwijderd]

Lijkt me niet, door meer standaarden gebruiken is de kans groter dat applicaties ed zonder problemen onder elke distributie die die standaarden volgt kan draaien

[zenlord]

Dat is wat de ontwikkelaars van een distro doen: de packages compileren voor hun gebruikers op een manier dat dat bepaalde programma werkt zoals het hoort in de door hen ontwikkelde distro (zoals debian, suse, slackware etc), of naast de broncode van het programma de instructies schrijven voor het probleemloos compileren en installeren van die broncode (zoals Gentoo of Arch).

Naar mijn mening zal dit dus weinig bijbrengen bij de gewone gebruiker.

[zenlord]

Ik dacht dat ook begrepen te hebben uit het artikel. Voor de modale eindgebruiker maakt het bitter weinig uit of er nu gekozen wordt voor gamin of fam bvb, maar als slechts 1 van beide packages voldoet aan de LSB 4.0-standaard, dan zij het zo.

Misschien wel positief nieuws dat er aan zo'n certifiëring gedacht wordt, maar het mag de keuze van de gebruiker wel niet beperken. Als ik om welke reden dan ook gamin zou verkiezen voor fam (bvb betere samenwerking met pcmanfm 0.5), maar gamin draagt niet de voorkeur weg van LSB, dan kan mij dat niets schelen.

[Verwijderd]

ik bedoel dat het ook kan intergreren...

[blorf]

Geen idee. Hij heeft een ikoon op de desktop en als ie gestart is komt er een ikoontje in mijn taakbalk. En als ik wil kan ik met rightclick een mp3tje openen met Amarok.
Ik zou niet weten wat er nog meer moet gebeuren.
Het enige wat is me nog kan voorstellen is dat KDE er misschien een mooie install wizard achtig iets bij doet.

[graey]

Ik weet niet welke distro je gebruikt, maar in elke grote distro kan je (ongeacht of je KDE of Gnome gebruikt) bijvoorbeeld AmaroK gewoon installeren via het pakketbeheer. Sommige distro's zullen dan aangeven dat er meer libraries geinstalleerd moeten worden, dat moet je dan accepteren (je krijgt dan niet een volledige KDE-installatie, maar slechts de onderdelen die AmaroK nodig heeft, maar daar zie je verder niks van terug, alleen een beetje meer gebruikte schijfruimte), sommige distro's geven geen melding en doen dit automatisch erbij. Daarna komt AmaroK gewoon netjes in het menu van Gnome/XFCE/watdanook.

[10011]

nfi ->
Gelukkig zijn er ook nog genoeg mensen die een draak als AmaroK niet willen en gewoon netjes xmms draaien.
Maargoed hier spreekt dan ook een Slackware xfce gebruiker.


Zou Pat ooit PAM implementeren als dat het enigste is dat hem en LSB scheiden?

[blorf]

Haha, het is wel een zwaar ding die AmaroK ja maar ik vond die internetradio lijst wel handig. Als het echt snel moet doe ik Orpheus console based.
Hier Freebsd trouwens dus met die linux standaarden heb ik niet zo veel te maken denk ik. Het is wel handig voor de compat-linux packages als er een algemene richtlijn komt. Ze plukken nu het een en ander door elkaar weg bij Suse en Fedora onder andere.

[Metro2002]

Zou eens tijd worden dat er fatsoenlijke standaarden voor linux komen ja. Niet alleen qua programmeren maar zeker ook qua hoe een linux systeem opgebouwd is / wordt. Als je in distributie X de config files blind weet te vinden kan het zomaar zijn dat die in distributie X ineens totaal niet meer bestaat of in een andere plaats staat opgeslagen of gewoon ineens samengevoegd is in een ander bestand.

Tevens zou het fijn zijn als er 1 standaard kwam voor het installeren van packages en zou het prettig zijn als er ALTIJD een binary aangeboden wordt ipv alleen maar de sourcecode (die moet natuurlijk wel beschikbaar blijven voor als je een afwijkend platform hebt of eraan wilt programmeren). Een programma compileren is nou eenmaal niet gebruiksvriendelijk. Zeker niet als je eerst nog tig programma's nodig hebt die het compileren mogelijk maken (en nee die worden ZEKER niet altijd std meegeinstalleerd).

Linux is een schitterend systeem maar zolang het zo gefragmenteerd blijft als nu zal het nooit echt een groot marktaandeel veroveren ben ik bang.

[blorf]

Het probleem is dat iedereen weer net iets andere ideeen heeft over de ideale linux distro.
Daarom is linux dus niet compleet als standaard beschreven maar wel zover mogelijk door- ontwikkeld zodat het klaar is om een standaardpakket samen te stellen, en daar heb je helaas meestal ook de source voor nodig omdat er altijd wel wat versieconflicten enzo zijn. De hele handel is constant in ontwikkeling dus er klopt wel eens iets even niet.
Het mooiste vind ik een systeem dat zichzelf volledig kan recompilen en installeren naar een andere bestemming. Dus constant alles vastleggen wanneer je configuratiebestanden aanpast.

Trouwens, als je een bug ontdekt in je binary-only systeem kun je mooi met een hex-editor gaan zitten rommelen maar ver kom je niet. Dan maar hopen dat je de goeie source files nog kunt vinden op internet.

[Metro2002]

Je kunt in elk geval met elkaar afspreken hoe de standaard opbouw van het systeem werkt lijkt me. Waar je de config file stalt, waar je de shared libraries stalt, welk programma er standaard gebruikt wordt voor het compilen van programma's, hoe de opstartprocedure standaard verloopt (BSD style bv) etc.

Dat kun je natuurlijk wel doen en dan behoud je alsnog de mogelijkheden om bv een ander compileerprog te gebruiken of een andere desktopomgeving maar een beetje meer eenheid in de opbouw van het systeem zou helemaal geen kwaad kunnen.