Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 99 reacties

Ubuntu-oprichter Mark Shuttleworth heeft aan de Debian-community voorgesteld om meer van zijn Ubuntu-ontwikkelaars voor Debian te laten werken. Shuttleworth hoopt zo de spanningen met de Debian-gemeenschap te verminderen.

Door het aanbieden van een aantal Ubuntu-ontwikkelaars die momenteel nog voor Canonical werken, zou de voor december voorgestelde code freeze van de Debian-distributie haalbaar moeten zijn, zo meent Shuttleworth. De miljonair stelt dat de ontwikkeling van zijn Ubuntu-distributie door de eventuele aderlating weliswaar minder snel zal verlopen, maar dat een betere samenwerking noodzakelijk is om alle Linux-distributies verder op weg te helpen. "Ik wil dat vrije software gaat winnen. Als de overwinning wordt behaald, dan zal deze niet afkomstig zijn van een enkel merk, zoals Debian, Ubuntu of Red Hat, hij zal behaald moeten worden op een gecoördineerde en gediversifieerde manier", zo betoogt Shuttleworth in een posting rondom de discussie over de code freeze.

De december-freeze, die mede door Ubuntu aan de Debian-gemeenschap werd voorgesteld, heeft veel verzet opgeroepen. Ubuntu en Shuttleworth werden door sommige Debian-ontwikkelaars zelfs beschuldigd van het misbruiken van Debian voor commercieel gewin. Inmiddels is het voorstel voor de december-freeze in de ijskast gezet. Het bestuur van het Debian Project heeft aangekondigd dat het volgende maand met een nieuw voorstel voor de tijdsplanning zal komen.

Shuttleworth staat niet alleen in zijn streven om de samenwerking tussen de diverse Linux-distributies te vergroten; er gaan steeds meer stemmen binnen de opensource-gemeenschap op om bijvoorbeeld in meerdere distributies dezelfde Linux-kernel te gebruiken, zodat er op een gecoördineerde manier bugs geplet kunnen worden. Ook zouden applicaties met minder aanpassingen op een groter aantal Linux-distro's kunnen draaien.

Moderatie-faq Wijzig weergave

Reacties (99)

Wat is de verhouding Debian/Ubuntu gebruikers ongeveer op het moment?
Hangt er vanaf, of je de verhouding mensen die Debian/Ubuntu gebruiken op Desktops, of op Servers...

Op Desktops heeft Ubuntu een massief voordeel. Op server is het dan weer andersom.

Ubuntu focust zich op de "leken" meer, terwijl Debian zich focused op stabiliteit, met als gevolg, dat beide hun eigen markt hebben.

Het grote probleem met Ubuntu is, dat hun releases soms te snel gebeuren, met te weinig getesten applicaties. Het gevolg is dat er sneller problemen durven voordoen ( ik spreek uit ervaring, zelf met Ubuntu Server ... ).

Je kan stellen dat:

Debian = Stable
Ubunty = Debian Testing + Meer gebruik vriendelijk wegens bepaalde "non free" drivers etc die standaard aanwezig zijn.

Nu, vele mensen zullen zeggen, Debian Testing is ook stabiel. Ja... Maar, er doen zich best nog wel leuke verrassingen voor, welke je deftig wat tijd kunnen kosten om op te lossen.

Persoonlijk ben ik ook niet van mening dat Ubuntu & Debian een gelijk release datum zouden krijgen. Want beide bedienen in feite verschillende markten.

Debian is altijd geweest, its done, when its done. Nadeel is dat de software etc durft achterlopen als je de stable gebruikt. Het voordeel is, het is uiterst stabiel...

Daartegen, als Debian & Ubuntu een gelijke release datum krijgen, zie ik problemen. Aangezien dat Debian & Ubuntu voor hun versie's verschillende ontwikkeling periodes gebruiken. Wat was Ubuntu weeral? 6 maand? En Debian, een jaar of meer...

Ik moet wel zeggen, dat de Debian developers wel een mogen ophouden met dat kinderachtig gedoe, zoals Firefox -> Iceweasle, Thunderbird -> Icedove etc. Want dat maakt het enkel maar lastiger voor nieuw mensen welke Debian willen gebruiken voor de eerste maal.
Technisch gezien synchroniseert Ubuntu met Debian unstable, niet met testing bron
Vandaar dat velen Ubuntu niet op een server willen draaien.

De Debian gemeenschap loopt -in tegenstelling tot Ubuntu- ook niet wild van nieuwe gebruikers.
Er heerst er ook dikwijls een soort van elite gevoel. Dit komt net door de opkomst van Ubuntu, ze willen zich daartegenover afzetten. Ook verstaanbaar: ze steken veel tijd in iets dat dan door een ander bijna letterlijk overgenomen wordt en ze zien die ander met de pluimen weglopen, terwijl het product van die ander, in hun mening, niet af is...

Als je de mening van de Debian gemeenschap wilt kennen, is het topic "Debian decides to adopt time-based release freezes" op het Debian forum behoorlijk interessant.
Debian probeert iedere 2 jaar een stable release te krijgen echter is dat geen vereiste. Tevens is ubuntu iedere release een import van debian unstable. Testing is reeds een stuk stabieler dan unstable.

Dat Firefox en Thunderbird een andere naam hebben komt omdat Mozilla niet toe staat dat Debian de pakketten patched door bv feature's of fixes te backporten naar oudere releases. Daarom gebruikt debian in feitte een fork. (Het is eigenlijk de mozilla release + eigen patches en een andere naam)
Dat Firefox en Thunderbird een andere naam hebben komt omdat Mozilla niet toe staat dat Debian de pakketten patched door bv feature's of fixes te backporten naar oudere releases. Daarom gebruikt debian in feitte een fork. (Het is eigenlijk de mozilla release + eigen patches en een andere naam)
Op zich heeft Mozilla er geen enkel probleem mee als men patches backport, als men dat maar wel in nauw overleg met Mozilla doet - vanwege het bewaken van de goede naam die men heeft.

Verder eist men ook dat, als men de naam Firefox gebruikt, men ook het Firefox-ikoon gebruikt. Dat wil de Debian community dan weer niet omdat het Fx-ikoon onder een trademark valt en dat niet compatible zou zijn met de Debian Free Software Guidelines...

Op zich heeft men bij Mozilla al voorzien in een manier om de boel te compileren naar een applicatie die geen gebruik maakt van de handelsmerken van Mozilla - maar dat werkte blijkbaar niet (goed genoeg) voor Debian (of men wilde de codenamen niet gebruiken die dan gebruikt worden, zoals bijvoorbeeld Shiretoko voor Fx 3.5).

Uiteindelijk is men dus een soort fork gaan maken, maar dan met hoofddoel de andere namen...

N.B. Ubuntu levert overigens gewoon de 'officiŽle' Firefox en Thunderbird mee, zij hebben dus wel een overeenkomst gesloten - compleet met de juiste naam en het bijbehorende icoon...

[Reactie gewijzigd door Little Penguin op 8 augustus 2009 20:46]

Dat wil de Debian community dan weer niet omdat het Fx-ikoon onder een trademark valt en dat niet compatible zou zijn met de Debian Free Software Guidelines...
En dit is meteen de reden waarom ik Debian lekker links laat liggen. Als je als organisatie er liever voor kiest om een voor de gebruiker bekend icoon en naam te vervangen door een ander omdat er toevallig een naam/beeldmerk niet compatible is met hun guidelines en daarvoor dan ook echt ontwikkeltijd vrij te maken dan kan je dat niet serieus meer nemen. Alle succesvolle organisaties zijn enigszins beschermd, al was het alleen maar om te voorkomen dat anderen hun naam kunnen misbruiken. (Spyware onder de Firefox naam uitbrengen oid.)
Misschien moet je wat meer onderzoek doen, want het probleem ligt bij Mozilla zoals andere partijen ook hebben ondervonden. Daar valt Sun Microsystems ook onder. Novell daar in tegen kiest ervoor om gewoon de laatste versie van Mozilla te packagen en te hopen dat er niks breekt.

En het is jammer dat Mozilla deze strijd over de rug van de gebruiker uitvecht en alleen vanwege het geld wat ze ervoor krijgen. Andere partijen die dit truukje probeerde kregen een aardige douw de verkeerde kant op. IPF, Qmail, XFree86 en Pine zijn hier aardige voorbeelden van.

Je moet misschien ook eens uitzoeken wat die guidelines eigenlijk betekenen voor jouw als eindgebruiker en/of bedrijf. Het kan verstandig zijn om een platform te kiezen welke proactief potentiele legal issues opspoort en verhelpt. Bedenk ook dat Debian op veel meer plekken wordt gebruikt dan alleen desktops en servers en als hint geef ik je de embedded cq appliance wereld.
De Guidelines van Debian zorgen ervoor dat het bijna onmogelijk is om de continuÔteit van Debian te ondermijnen. De code van Firefox is vrij, maar naam en logo niet, dat zijn handelsmerken.

Debian zorgt ervoor dat ze geen gebruik maken van andermans trademarks. Je kunt prima een overeenkomst sluiten zoals Ubuntu dat gedaan heeft, echter mocht dan de andere partij die overeenkomst beŽindigen, maak je opeens wel inbreuk op hun handelsmerk. je moet dan moet je van de ene op de andere dag omschakelen of andere gekke sprongen maken. Nu is het zo dat niemand op zinvolle manier de organisatie van Debian kan aanklagen, de release van een Debian versie gerechtelijk kan tegenhouden of gebruikers mag verhinderen Debian te gebruiken. Daarom zijn de guidelines van Debian ook zo streng.

[Reactie gewijzigd door BeosBeing op 9 augustus 2009 13:26]

Ubuntu is gebaseerd op debian, dus iedere ubuntu gebruiker is een debian gebruiker.
Daarbij gebruiken vele mensen de verschillende distro's voor verschillende doeleinden. Zo gebruik ik Ubuntu als desktop en draaien al mijn servers op Debian (en ik gok velen met mij).
shuttleworth probeert al een tijdje mee te liften op het werk van anderen. Het synchroon releasen van distributies is zijn stokpaardje.

het is namelijk zo dat ubuntu zo goed als geen werk aan de kernel doet, terwijl red hat daar heel veel mensen op heeft zitten. red hat heeft een zeer succesvolle enterprise business, net als suse. ubuntu niet: zij verdienen niks met ubuntu server en de markt perceptie is ook dat ubuntu best leuk is als desktop maar zeker niet als server.

het synchroon releasen betekent dat hij heel makkelijk in de enterprise business kan instappen. laten we zeggen dat hij niet heel erg populair is met deze visie in de linux (kernel) community. het is niet alleen maar nemen, je moet ook geven. dat is iig wat de meesten denken
die anderen kunnen weer net zo makkelijk meeliften op ubuntu.

en aangezien ubuntu als desktop heel populair is voegen ze blijkbaar toch genoeg waarde toe om een groot verschil te maken.

ze geven mss geen grote kernel ontwikkelingen terug, maar wel een heleboel andere dingen, die voor een heleboel distributies nuttig kunnen zijn.

ik zie het probleem niet.
ubuntu is "populair" als desktop, maar speelt nog steeds geen enkele rol op dat vlak (tov Windows en OSX), Red Hat of Suse server daarentegen heeft wel degelijk een rol van betekenis tov Windows server, en daar is dus ook geld te verdienen
als Shuttleworth nu wil meeliften om zo in de servermarkt te komen, kan ik begrijpen dat niet iedereen dat zo leuk lijkt
Dus de dingen die je doet tellen alleen mee als het in het straatje van anderen past? Een erg zwak argument als je het mij vraagt. Ik als leek zie Shuttleworth als de enige die de "Desktop Linux" bekend heeft gemaakt bij een veel groter publiek door er 1 geheel van te maken. Dit zou voor het algehele succes van Lunix ( ook op de server ) wel eens veel belangrijker kunnen zijn dan al het andere; hoe meer desktops op Linux draaien hoe meer Enterprise Linux servers er gevraagd gaan worden.
Ik ga er van uit dat in de linuxwereld (waar samenwerken en opensource en verbondenheid alles is, volgens devs toch), de spelers ook rekening houden met elkaar zodat ze samenwerken en elkaar niet gaan tegen werken. Dat zou de evolutie van Linux t.o.v. de markt verstoren, gok ik.
Ik denk dat Ubuntu Linux naar een hoger plan helpt op de desktop, vraag me niet hoe of waarom.. maar Ubuntu is wat veel mensen 't eerste gebruiken als ze besluiten om met Linux te spelen. Ik denk dat er zonder Ubuntu een stuk minder linux clients geweest zouden zijn.
Ik denk dat Ubuntu Linux naar een hoger plan helpt op de desktop, vraag me niet hoe of waarom..
Dat is omdat Ubuntu makkelijk en compleet installeert. Ubuntu zet in op gebruiksvriendelijkheid en niet zozeer op tweakbaarheid of volledige controle. Je kan wel alles naar eigen wens installen, maar je kan ook gewoon next next next klikken en eindigen met een werkbare omgeving.

Ik denk dat shuttleworth gelijk heeft. Een tikje meer uniformiteit maakt het makkelijker om Linux nog makkelijker te maken. Tevens is het dan voor nV of AMD makkelijker om drivers voor het platform te maken waarvoor je niet de console in hoeft. Console werk schrikt het grote publiek af en imho moet je nog steeds altijd de console in bij welke linux dan ook.
Tevens is het dan voor nV of AMD makkelijker om drivers voor het platform te maken waarvoor je niet de console in hoeft.
Waarbij dan ook weer geldt dan de driver blijkbaar proprietair & closed source is, want anders hadden de mensen van de op de Linux-kernel gebaseerde distributie wel een aanpassing kunnen doen zodat'ie gelijk bij de installatie al actief gemaakt kon worden - of via de GUI actief gemaakt kan worden.

Op zich is er op korte termijn weinig tegen zo'n oplossing in te brengen, op langere termijn in een open source oplossing - bij voorkeur een die onderdeel is van de kernel - een veel betere oplossing. Als de driver een onderdeel is van de kernel, dan heb je veel meer kans dat'ie blijft werken dan wanneer het een binaire driver is die dus stopt met werken als men een API (al dan niet noodgedwongen) gaat wijzigen.
imho moet je nog steeds altijd de console in bij welke linux dan ook.
Nou, volgens mij zijn er voldoende recentie distributies waar dat dus niet het geval is, maar goed je gebruikt er ook de afkorting 'IMHO' bij - het is dus jouw mening :)
Heel Wikipedia Draait op ubuntu 8.04.... omdat het blijkbaar makkelijker was als Red Hat en Fedora, en gratis.


nieuws: Servers Wikipedia migreren naar Ubuntu
Heel Wikipedia Draait op ubuntu 8.04.... omdat het blijkbaar makkelijker was als Red Hat en Fedora, en gratis.
Nou nee, de hoofdreden is dat men op Ubuntu gemakkelijker betaalde support kon krijgen. Red Hat levert namelijk alleen support op RHEL en niet op Fedora.

Fedora is ook gewoon gratis, maar ja als je daar geen support op kunt krijgen - als je dat nodig hebt, dan houdt 't snel op.

Voor de beheerders maakt het betrekkelijk weinig uit welke Linux-variant er draait. Hoewel de beheerders die vooral Windows-geŲrienteerd zijn wel zou hun eigen voorkeuren (kunnen) hebben - denk bijvoorbeeld aaan het feit dat die dus bij voorkeur via de GUI gaan werken e.d.
Voor mijn werk beheer ik enkele RHEL servers, ik thuis gebruik Ubuntu server en desktop. Ik geef toch de voorkeur aan deb (samen apt/itude natuurlijk) over rpm (met yum).

Ik vind het ook niet nodig dat package management gelijk getrokken moet worden.
Ieder z'n keuze, is zowat het idee van Linux.

[Reactie gewijzigd door GoBieN-Be op 9 augustus 2009 00:47]

Dat wil ik absoluut aannemen. Het is geen altruÔst, het is een zakenman. Met zakelijke motieven, ondermijn je misschien weer het opensource concept.
Daarom moet je niet meer dan 50% zakelijke motieven laten leiden.
Wat raaskal jij nu weer dan ?

Marktplaats draaide altijd Debian maar is ook overgestapt op Ubuntu afgelopen jaren.

Ze draaiden eerst RHEL toen CentOS, toen Debian en nu Ubuntu

Dus jij zegt dat dergelijke bedrijven niet enterprise zijn ?? :?
het enige wat ik hieruit lees is dat marktplaats niet wil betalen voor support en nogal wispelturig is in zijn platformkeuze.

mijn punt is dat hij makkelijk wil instappen in de enterprise markt zonder er werk voor te doen. ubuntu heeft tot nu toe ook nog op geen enkele manier (significant) teruggegeven aan de community. het wordt overigens wel beter nu bv. launchpad (eindelijk) open source is.

de echte enterprise markt (wall street, GROTE bedrijven, legers, overheden): daar is waar het geld zit. en daar is NIET waar ubuntu zit. daar vind je RHEL en SUSE.
daar wil ubuntu ook tussen komen.
duidelijker? :-)
Jij kunt dat lezen, maar er was vroeger ooit eens gekozen voor RHEL, nu is dat niet het beste, ook niet qua support dus was CentOS een beter alternatief in dat geval.

Aangezien er nogal wat Debian mensen bij Stone-IT zaten/zitten was dat voor de hand liggend aangezien Ubuntu nog niet het was en ook geen server versie had.

Momenteel werkt Ubuntu voor servers vaak lekkerder dan Debian ivm nieuwe packages die echt wel goed werken.

Dus wat je leest is mij best, maar zolang je niet na wil denken over een reden kun je beter ook niet reageren lijkt me.

Ubuntu moet daar niet tussen willen komen eigenlijk. Overheden zijn zeikerds op IT budget, bedrijven als Ebay en Marktplaats niet... die zien toch wel geld binnen komen.

Tevens is het zo dat je bepaalde support kwijt raakt uit je community als je er tussen komt... mensen willen niet gratis iets vertellen als ze weten dat er aan verdiend kan worden.
het enige wat ik hieruit lees is dat marktplaats niet wil betalen voor support en nogal wispelturig is in zijn platformkeuze.
Dat kun je niet zomaar stellen: http://www.ubuntu.com/support/paid
Canonical (shuttleworth zijn bedrijf) biedt wel degelijk betaalde support aan voor bedrijven scholen, eznv...

edit: ik zal eerst doorlezen de volgende keer ;)

[Reactie gewijzigd door GoBieN-Be op 9 augustus 2009 00:44]

Het enige wat ik hieruit lees is dat Marktplaats niet gerund wordt door pointy-haired-bosses. Ik ken RHEL en Debian vrij aardig en er is geen duidelijke feature waarom RHEL wel in de enterprise zou horen en Debian niet, behalve inderdaad kosten. RHEL kost altijd geldt (licenties e.d.) debian alleen voor support (en dan niet eens van Debian zelf). Aangezien RHEL duurder is moet het wel beter zijn. Dus banken en verzekeraars kiezen RHEL....
Ik heb de mailinglist even gelezen en zie eigenlijk alleen maar developers van Debian aan het woord tegen Shuttleworth. Het enige wat ik mis zijn de meningen van de gebruikers maar die menen dat ze nog niet het respect hebben verdient om daar te posten. Waar de Debian developers wel gelijk in hebben is dat Ubuntu de packages van Debian jat. Waar ook weer goeie dingen uit ontstaan.
Maar de patches die Ubuntu doet op unstable daar doet Debian niks mee voor Debian zijn dat gewoon pure hacks. En daar gaat het mis volgens mij, dit is ook een goede bijdrage. Ubuntu is voor gebruikers dus gebruiksvriendelijk met hacks, Debian is voor de programmeurs dus technische goed en dus ook goed voor mensen die het willen gebruiken in een stabiele omgeving.
Bij gebruikers moet er een afweging gemaakt worden tussen technisch goed en bruikbaar.
En wanneer moet een hack gebruikt worden en wanneer een technisch goede oplossing ?
Dat hangt af van hoeveel afhankelijkheden de code heeft.
Nu kun je wel denken puur alleen op hacks kun je niet verder werken daarom zou ik kiezen voor iets zoals Intel het doet met zijn Tick Tock principe.
Wat mijn persoonlijke afweging zou zijn is dat de half jaar release-cycle van Ubuntu blijft maar elk jaar worden de hacks op geschoond en elke twee jaar komt een LTS versie samen met een Debian release. Zo krijgt Ubuntu ook kwalitatief beter LTS releases.
Maar ja ik ben maar een gebruiker dus wie geeft mij het recht om hier over te praten respect heb ik namelijk nog niet verdient doordat ik nog geen bijdrage heb gedaan aan de code alleen wat wat bugreports.
Waar de Debian developers wel gelijk in hebben is dat Ubuntu de packages van Debian jat.
Maar is dat erg? Ubuntu is niet de eerste commerciŽle partij die gebruik maakt van het werk dat door de Debian-gemeenschap gedaan wordt. Dat men nu bereid is om ook 'iets' terug te doen, dan is eigenlijk alleen maar een pluspunt.

Alleen is het wel belangrijk dat er dan goed samengewerkt wordt en men vanuit Canonical ook bereid is om het volgens de Debian-regels te doen.
Maar de patches die Ubuntu doet op unstable daar doet Debian niks mee voor Debian zijn dat gewoon pure hacks. En daar gaat het mis volgens mij, dit is ook een goede bijdrage. Ubuntu is voor gebruikers dus gebruiksvriendelijk met hacks, Debian is voor de programmeurs dus technische goed en dus ook goed voor mensen die het willen gebruiken in een stabiele omgeving.
De vraag is of het ook nodig is dat men een hack toepast - als het inderdaad pure hacks zijn om iets werkend te krijgen. Een Quick 'n Dirty Fix dus. Dan kan ik het me levendig voorstellen dat de Debian-mensen dit soort zaken lekker negeren.

Op middel-lange termijn moet je namelijk niet aan een QD-Solution willen blijven zitten, dus als je een fix maakt doe het dan gelijk goed. Als men vanuit Ubuntu dus de extra tijd neemt om wel een goede fix te maken, dan is de kans groot dat men bij Debian de patches wel op prijs gaat stellen...
Wat mijn persoonlijke afweging zou zijn is dat de half jaar release-cycle van Ubuntu blijft maar elk jaar worden de hacks op geschoond en elke twee jaar komt een LTS versie samen met een Debian release. Zo krijgt Ubuntu ook kwalitatief beter LTS releases.
Doet men dit eigenlijk niet al zo, ik neem niet aan dat men blijft zitten met eigen patches als er al patches upstream beschikbaar zijn voor de nieuwe versie van Linux en de userland toepassingen...
Maar ja ik ben maar een gebruiker dus wie geeft mij het recht om hier over te praten respect heb ik namelijk nog niet verdient doordat ik nog geen bijdrage heb gedaan aan de code alleen wat wat bugreports.
Er zijn ook QA-mensen nodig, dus ik zie niet in waarom je niet mee zou mogen praten hoor.

* Little Penguin is overigens ook slechts een normale developer en dus geen Linux hacker oid...
Maar is dat erg? Ubuntu is niet de eerste commerciŽle partij die gebruik maakt van het werk dat door de Debian-gemeenschap gedaan wordt.
Storm Linux 2000, Corel Linux, Xandros Desktop, Lindows/Linspire gingen Ubuntu al voor. De eerste ging failliet, de tweede flopte en werd verkocht aan de derde die werd verkocht aan de vierde. Vooral de eerste twee hebben ook nog nauwelijks de kans gekregen om Łberhaupt iets terug te doen, als bedrijf moesten ze eerst winst maken.
Het is Xandros die Linspire opgekocht heeft, niet omgekeerd:
http://xandros.com/news/p...os_acquires_linspire.html
Waar de Debian developers wel gelijk in hebben is dat Ubuntu de packages van Debian jat.
Dan moet je je code niet als open source aanbieden :)
Niet als GPL bedoel je natuurlijk. Er zit een wezenlijk verschil tussen 'een source aanbieden' en 'een source aanbieden onder GPL/BSD'.

Je kunt namelijk iemand de mogelijkheid geven om de broncode te bekijken en vervolgens zeggen dat diegene de broncode niet mag veranderen.
De haat voor bedrijven is kennelijk erg groot bij de debian community als je sommige reacties hier en de replies leest op de mail van Shuttleword.
In plaats van het een eer te vinden dat je werk gebruikt wordt door anderen en weer vrij word weggegeven (wat imho volgens mij de gnu gedachte is..) Wordt er nogal al achterdochtig en met een hoog alluhoudje gehalte gereageerd. Zelfs als iemand aanbied ergens extra werk voor te doen is men niet tevreden.
De meeste reacties lijken op afgunst. De andere partij heeft iets te winnen en dus doen we het niet. Er wordt niet strategisch nagedacht over wat er mogelijk is maar erg strak vast gehouden aan de 'leer'. Wellicht is dit het fundamentele verschil. Ubuntu is een 'bedrijf' en debian een 'geloof'.
Het gaat hem imho niet om de haat, maar om de achterliggende motieven. Debian is zover gekomen door te werken zoals ze doen. Nu wil een ander bedrijf ineens dat Debian zijn werkwijze aanpast zodat het voor Canonical eenvoudiger en goedkoper word. Als Debian in december een freeze doet en de community die freeze zelfs maar gedeeltelijk naar een stabiel platform tilt dan heeft Canonical ineens veel tijd en dus geld uitgespaard voor zijn volgende versie.
Het punt is dat het voor Debian ook eenvoudiger zou moeten worden...win-win, alle neuzen in dezelfde richting, samenwerken i.p.v. tegenwerken,... Ach, er zijn overal wel mensen die alleen maar kunnen klagen; c'est la vie. :-)
WŠt moet er voor Debian eenvoudiger worden? De Debian community heeft bepaalde keuzes gemaakt en houdt zich vast aan de gemaakte keuzes omdat ze zijn gebaseerd op idealen. Wie het daar niet mee eens is moet maar zelf een distributie maken. De community wil samenwerken met mensen die er hetzelfde over denken, niet met mensen die andere doeleinden hebben.
Die ideaalen zijn goed en daar moeten ze ook vooral mee doorgaan, maar laten we eerlijk wezen Ubuntu is meer voor de desktop en Debian is meer voor stabielere omgevingen zoals servers. Ubuntu maakt het de gebruiker makkelijk om non-free software (met een melding dat het non free is) met een muisklik te installeren terwijl Debian alles doet om non-free software buiten de deur te houden (wat ook een goede zaak is). Ze bijten elkaar daar dus niet. Het voordeel wat Debian echter heeft door de massa aan Ubuntu gebruikers is dat een gedeelte van hun packages al grootschalig getest wordt. Mark Shuttleworth wil nu dus graag meer samenwerken met Debian. En omdat Ubuntu probeert om Linux commercieel succesvol te maken staan er direct tig personen klaar die vinden dat Mark het alleen voor het geld doet, terwijl elke idioot weet dat de ontwikkeling van een Linux distributie mankracht kost en dat terwijl Ubuntu nog altijd gratis is. Uiteindelijk probeert elke distributie op de een of andere mannier er beter van te worden (hetzij financieel hetzij kwa marktaandeel). Het samenwerken hoeft dus helemaal niet te betekenen dat Debian de gemaakte keuzes moet wijzigen...

Mijn ideaal 'software model' bestaat nog altijd uit een vrije basis met daarboven een betaalde laag voor extra functionaliteit. Eclipse is gratis, voor MyEclipse moet je betalen. OpenOffice is gratis, voor StarOffice moet je betalen.
De community wil niet samenwerken met mensen die geld willen verdienen met Linux? ( Wat dat is uiteindelijk het doel van Shuttleworth natuurlijk ) Ook niet als dat betekent dat het voor de community ook makkelijker wordt om geld te verdienen aan Linux?

Heeft de community moeite met het feit dat iemand anders geld verdient met hun werk oid? Als dat zo is gaat het hele OSS concept niet werken.
Ik denk ook meer dat het de keuze om niet 10x hetzelfde te doen.

Nu denk dat er dit bedoeld wordt: er is bijvoorbeeld een fout gevonden in de kernel die wordt gepatched bijv.: ( ik weet niet hoe dit zit, maar ik denk dat het zo gebeurt)

een 1 moet een 0 zijn ergens:

dan gaat eerst iemand van Red Hat dat veranderen, dan iemand van ubuntu, dan iemand van debian en dan van Suse. Dan heb je dus 4 programeurs die hetzelfde veranderen terwijl 1 iemand het had kunnen doen voor alle 4!

En tuurlijk gebruikt debian een iets andere kernel als ubuntu en Fedora maar waarom niet stappen maken. Bijv.: Debian gebruikt kernels die ontwikkeld zijn tot stap 2 en ubuntu die al tot stap 5 ontwikkeld zijn?!

Maar dan kunnen ontwikkelaars van ubuntu voor de volgende release van debian al wat bugs verhelpen en kunnen ontwikkelaars bij de huidige release van ubuntu al mogelijk patches uitbrengen.

Uiteindelijk is dit een win win situatie! En heb je meer vooruitgang omdat je programmeurs overhoud en met zijn allen samenwerkt. En ik denk ook dat dit 1 van de manieren is om de desktop markt werkelijk te veroveren.

Wat betreft die pakketten .rpm schijnt een paar voordelen boven .deb te hebben welke weet ik niet maar dat heb ik eens gehoord en zolang het nog niet hetzelfde is zet ik het gewoon vrolijk om als het moet van .rpm naar .deb
Als Debian door de samenwerking hun volgende release eerder kunnen uitbrengen, is dat een voordeel(tje) voor Debian. Als daarmee de volgende releases regelmatiger kunnen uitkomen, is het voordeel wat groter. Debian wordt dan voor velen een betere keus.

Als men de releases steeds synchroon kan laten lopen met die van Ubuntu, is daar het grote voordeel voor Canonical en Ubuntu. Dat hoeft geen bezwaar te zijn voor Debian, als men bij Debian maar aan hun principes vast blijft houden.

@Cheetah:
De Debian community heeft bepaalde keuzes gemaakt en houdt zich vast aan de gemaakte keuzes omdat ze zijn gebaseerd op idealen.
Zo is het, en daar moet men zich bij Debian aan vasthouden. Is samenwerking mogelijk binnen die principes, en is het voordeel niet vrijwel uitsluitend voor Canonical/Ubuntu, dan zou men er goed aan doen om er op in te gaan.

Moet men idealen opgeven, waaronder, "it's done when it's done" (maar vooral de andere), dan moet men er bij Debian vanaf zien, want dan is het op langere termijn voor Debian schadelijk.
Inderdaad, en het zou wel eens een hele grote showstopper kunnen zijn om Linux bij "het grote publiek" te laten slagen.
Er zijn nog steeds massa's elitairen in de Linux community hoor. Eens ze die rotte appels eruit krijgen, kunnen ze beginnen denken aan concurrentie op grote schaal met de bijhorende concessies die zullen moeten gebeuren.
Veel van het werk van die rotte appels is of gratis of zeer goedkoop ... concessies gaan alleen maar komen in ruil voor heel veel geld (ik denk niet dat de hoeveelheid geld die Canonical kan leveren in de buurt komt). IMO meer dan de klanten willen betalen, dus dan moeten ze maar genoegen nemen met de rotte appels ... of niet, moeten ze helemaal zelf weten.

[Reactie gewijzigd door Pinkys Brain op 9 augustus 2009 04:16]

Het is net in Ubuntu waar ze het al aandurven om een groter profiel aan te nemen maar daardoor mensen tegen zich te krijgen. Het integreren van gesloten software in de distributie om mensen een goeie ervaring te geven als ze het opstarten ipv frustratie.
Ik weet het niet zo zeker. Als Shuttleworth de toon gaat zetten door betaalde krachten in te zetten voor het organisatorische werk, dan is het einde zoek. Dan open je een verdeel en heersmentaliteit die schadelijker is voor debian of elke andere distributie.
Gebeurt in de open source volgens mij best wel vaak dat betaalde ontwikkelaars uitgeleend worden. Niks bijzonders hieraan.
Inderdaad. Bovendien heb je altijd nog de source en patches (diffs) die je kan overnemen. Dat is het mooie aan open source, als iemand een probleem opgelost heeft kan elke dev daar gebruik van maken en betere versies maken/suggereren.
echter is het voorstel om ontwikkelaars in te zetten, dus niet voor organisatorisch werk. Geen verdeel-en-heers dus maar hij zoekt m.i. echt de samenwerking.
Ik juich de komende freeze van Debian van harte toe. Lenny is mooi spul, maar een nieuwe stable release met laten we zeggen GNOME 2.28 en Linux kernel 2.6.31 lijkt mij opzich he-le-maal niet verkeerd!

De software die nu in Lenny zit is stable, maar functioneel is het naar mijn mening niet helemaal. (Weinig hardware support, vooral voor WiFi en brak geluid bijvoorbeeld)

Daarom vind ik dat de Debian community niet moeilijk moet doen. Ik wist trouwens niet eens dat de Linux distro's elkaar zo in de haren vlogen, is het bashen van Windows niet genoeg ofzo :?

[Reactie gewijzigd door AquaL1te op 8 augustus 2009 20:38]

Debian werkt al jaren zo met zijn stable release. Het heeft van Debian ťťn van de belanrijkste distros gemaakt op de servermarkt. Je kan de stabiliteit die ze nu bieden niet behouden wanneer je continue pakketen loopt bij te werken naar nieuwe versies. Wil je meer up2date zijn, kies dan een andere distributie. Das net het leuke aan linux, voor elk wat wils.
Ja ik weet wat het verschil maakt tussen Debian en Ubuntu :')

Wat mijn punt is, is dat het helemaal niet verkeerd zou zijn om nu weer een stable release uit te brengen met wat meer functionele software. Dan heb je veel meer aan die stabiliteit ;)

Want ik vind Lenny op een erg ongelukkig moment uitgebracht, als ze iets langer de freeze hadden uitgesteld dan had die release veel verder ontwikkelde desktop functies gehad. Misschien dat ze dat nu met deze nieuwe freeze beter gaan doen, zoals ik al zei met een GNOME 2.28 en een Linux 2.6.31 kernel komen ze veel verder. En dat spul gaat ook veel langer mee dan GNOME 2.22 met de 2.6.26 kernel.
Je ziet het simpelweg verkeerd. Als je nieuwe features wilt gebruiken moet je Debian Unstable of Debian Testing gebruiken. Voor een goed getest systeem heb je de stabel release. Die wordt dan ook veelvuldig gebruikt op servers. En de kernel en gnome zijn niet eens zo interessant voor dat soort systemen. Als de netwerkkaarten en raid controllers maar ondersteund worden, komt het meestal goed. Debian stable is nu eenmaal niet bleeding edge.

Hetzelfde geldt overigens voor CentOS en Fedora.
Klinkt goed, vooral dat gedeelte van een kernel zou een goede vooruitgang kunnen zijn (in mijn ogen)
Eťn kernel zou goed zijn maar is niet echt de bedoeling aangezien je nu juist kan selecteren wat je wilt hebben en lekker klein houden.
Ja, maar aan de andere kant heb je dan duizend verschillende versies van hetzelfde product die allemaal tegelijkertijd onderhouden moeten worden. Als ze dat centraal houden en recht trekken gaat het veel vlotter. En de Linux kernel is niet echt iets waar vaak in Linux distro's op beknibbeld wordt qua omvang of iets dergelijks.
Wat is het achterliggende nut van de diverse packages? Men gebruikt .deb, .rpm, .tgz en weet ik wat meer. Waarom wordt dit niet gelijkgetrokken? Ik kan me voorstellen dat er in zaken als filesystem van de gebruiker een behoefte is aan keuze, maar het zal mij toch niet interesseren via welke packages de software op mijn systeem komt.?

edit: dank voor de opheldering. Uiteindelijk kun je geloof ik het beste bij distributie-specifieke packages blijven. Maakt het ook niet uit welke methode gebruikt wordt.

[Reactie gewijzigd door snirpsnirp op 8 augustus 2009 22:40]

De .tgz is gewoon een tarball en bevat verder geen enkele vorm van depenency management - het is gewoon een gecomprimeerde vorm van de source (die je dan dus ook zelf nog moet compileren en waar je dus ook de meeste vrijheid hebt qua instellingen en processor-optimalisatie). Er zijn ook tarballs die alleen een binairy+simpel install-script bevatten, maar die zijn echt in de minderheid.

De .deb package zijn door de Debian-gemeenschap verzonnen en worden gebruikt door alle distributies die van Debian afgeleid zijn. Hier is er wel sprake van dependency checking en zoekt de package-manager dus zelf uit wat er bij nodig is, en geeft aan welke pakketten je nog moet installeren. In combinatie met een extra download-tool, zoals apt-get, kan dat zelfs geheel transparant geregeld worden, waarbij apt-get alle downloads voor je regeld.

Bij .rpm package staat RPM voor 'RPM Package Manager', maar origineel stond het voor 'Red Hat Package Manager'. Evenals bij .deb is er hier ook sprake van een dependency check en hoef je dat dus ook niet zelf te controleren. In combinatie met bijvoorbeeld yum is het mogelijk om de paketten van een centrale server van het internet te halen.
RPM is overgenomen door veel andere Linux-distributies, zoals o.a. SuSE en Mandriva.

Je kunt eigenlijk wel stellen dat, als een Linux-distributie een package manager gebruikt het al heel snel de RPM-variant is, behalve wanneer de distro (gebaseerd is op) Debian in dat geval wordt er de DEB-variant gebruikt.

Edit: DEB en RPM bevatten vaak alleen de binaire variant en zijn dus wel CPU afhankelijk...

[Reactie gewijzigd door Little Penguin op 8 augustus 2009 22:23]

De .tgz is gewoon een tarball en bevat verder geen enkele vorm van depenency management
Niet helemaal waar, onder FreeBSD waren de packages .tgz (nu .tbz omdat ze bzip2 zijn gaan gebruiken). Een tarball zoals jij die beschrijft heet meestal gewoon .tar.gz.
Er zijn ook source packages zowel van het .deb als van het .rpm package type.

.tgz = .tar.gz en bevat normaliter geen dependency check, maar uiteraard kan het wel.
Bij .deb en .rpm is de depencency check vereist.

Debian .deb packages zijn in principe compatible met Ubuntu (afgeleid van Debian) en omgekeerd zou dat ook zo moeten zijn.

Bij .rpm is dat al moeilijker omdat Suse niet is gebaseerd op Red Hat, en op sommige cruciale punten behoorlijk afwijkt. Compatibiliteit tussen Fedora en Red Hat Enterprise gaat mischien nog wel, en indien ze inmiddels niet teveel afwijken lukt dat ook nog wel met andere Red-Hat afgeleiden (zoals Mandriva dat ooit was (toen het nog Mandrake heette).

Daar komt nog bijnwat Iatka hieronder schrijft, de meeste commerciŽle en dus closed source packages vind je bij Red Hat afgeleiden.

[Reactie gewijzigd door BeosBeing op 9 augustus 2009 12:55]

Historisch gegroeid en het zal je wel degelijk uit moeten maken: .tgz heeft geen dependencies... Die andere die je noemt (rpm en deb) lijken verdacht veel op elkaar (op papier dan) en is het voornamelijk een verschil in 'wat kent de developer in kwestie'. Beide packaging formaten maken het mogelijk om er een ongelofelijke zooi van te maken, maar in de praktijk is dit voornamelijk voorbehouden aan RPM omdat men RPMs probeert te maken die op Fedora, RedHat Enterprise en SuSe moeten werken. .debs vind je voornamelijk op Debian en Ubuntu en voor Debian geldt eigenlijk dat je vrijwel altijd je package uit de eigen repo kunt halen met als voordeel dat het package ook echt goed werkt op Debian en niet probeert voor iedereen alles te zijn.
Oh ja: persoonlijk geef ik zwaar de voorkeur aan .deb vooral nu ik de afgelopen weken heb geprobeert om een vendor RPM om te bouwen, dit is niet zo makkelijk omdat de tools uitgaan dat je de source hebt, en die heb je dus niet als het een vendor package is..
Wat is het achterliggende nut van de diverse packages? Men gebruikt .deb, .rpm, .tgz en weet ik wat meer. Waarom wordt dit niet gelijkgetrokken?
Because there's more then one way to do it TM

Redhat heeft dingen in z'n rpm spec zitten die ze bij Debian niet boeiend vinden, en mist dingen die ze nodig hebben.

Daarnaast delen beide distro's zaken op filesystem anders in, dus waar komen binaries, waar komen configfiles, etc, etc. Je zou het gelijk kunnen trekken, maar dan zouden Debian en Red Hat het eens moeten worden, en dat zie ik zo snel niet gebeuren. Het zijn echt gewoon concurenten en conculega's van elkaar.
Buiten het feit dat die verschillende packageformaten eigenlijk min of meer afgestemd zijn op een bepaalde distributie: lichte verschillen in bestandslocaties en lichte verschillen in de naam van sommige packages; zijn er wel projecten die alles dichter bijeen proberen te brengen, of toch te doen lijken alsof dat zo is. Het is niet helemaal wat je wilt bereiken, maar het heeft er wel de meeste voordelen van: zo moet je maar 1 systeem leren en kan je op elke distributie in ieder geval de standaardinstallaties doen, hoewel het misschien nog nodig is om voor moeilijkere dingen naar de specifieke tools te kijken.

PackageKit bv. streeft ernaar om bovenop alle bestaande systemen (dpkg, rpm, ...) een eigen schil te leggen die gemeenschappelijk is; zodat het voor een gebruiker niet meer uitmaakt of hij RPMs of DEBs gebruikt omdat het op elke distributie met een gelijke interface benaderd kan worden.

Langs de andere kant zijn er ook projecten die voor specifieke package managers dienen: apt4rpm bv. doet wat het zegt: het voorziet een interface zoals apt-get voor dpkg is, maar dan voor rpm (waar je eerder yum zou gebruiken).

En zoals hierboven al staat: ook bestaat er alien die kan converteren tussen DEB en RPM, die dan hopelijk werken of anders manueel natuurlijk wat bijgesleuteld kunnen worden.

[Reactie gewijzigd door ILUsion op 9 augustus 2009 19:07]

Je kan met allien wel pakketten omzetten van .deb naar .rpm en van .rpm naar .deb alleen is dit niet altijd stabiel en werkt het ook niet altijd, maar soms is het wel het proberen waard!
Voorbeeld? Wat heeft Fedora in de kernel wat Ubuntu niet heeft? Of andersom? En zou dat een reden kunnen zijn om juist voor een bepaalde distro te kiezen? Als je verstand hebt van de kernel, als je dus weet wat je wel en wat je niet in de kernel wilt hebben, dan kun je wellicht ook gewoon je eigen kernel maken en dan maakt de distro helemaal niet uit.
Vaak is het zo dat de diverse bouwers van een distributie die op de Linux-kernel gebaseerd is, eigen patches toevoegen om bijvoorbeeld eerder een bug te pletten - omdat deze in de mainstream kernel nog niet geplet is bijvoorbeeld. Ook wil men wel eens eigen werk in de kernel stoppen. En soms heeft men een feature die (nog) niet in de mainstream kernel zit, maar die men toch graag (al eerder) aan wil bieden, zoals bijvoorbeeld een patch voor de Xen hypervisor.

Natuurlijk kun je, als je verstand hebt van de kernel en hoe die werkt, zelf een kernel compileren om deze te gaan gebruiken - maar hoeveel mensen kunnen dat? Dat is dus gering, en de meeste systeembeheerders kunnen dat al helemaal niet - die zijn vaak slechts getraind om productieproblemen te vinden en als het even kan op te lossen.

Overigens zou het een heel erg goede zaak zijn als er 100% uniformiteit komt, maar dat is wat lastig af te dwingen met open source software. Het enige dat je nog zou kunnen doen is een soort van Linux-certification, eventueel als onderdeel van de LSB. Zodat je als gebruiker gewoon weet of het wel of nu juist niet zal gaan werken, met name als je closed source software bovenop een op de Linux kernel gebaseerde besturingssysteem gaat gebruiken...
Overigens zou het een heel erg goede zaak zijn als er 100% uniformiteit komt, maar dat is wat lastig af te dwingen met open source software. Het enige dat je nog zou kunnen doen is een soort van Linux-certification, eventueel als onderdeel van de LSB. Zodat je als gebruiker gewoon weet of het wel of nu juist niet zal gaan werken, met name als je closed source software bovenop een op de Linux kernel gebaseerde besturingssysteem gaat gebruiken...
LSB als basis betekent effectief: RedHat als basis (RPM is verplicht in LSB). Ook is 100% uniformiteit wellicht niet zo handig: je bent gevoeliger voor aanvallen en een Linux die alles voor iedereen wil zijn zal al snel Windows-achtig worden en dus nooit helemaal lekker voor iedereen bruikbaar.
Volgens mijn is het gelijktrekken van de packaging al een hele stap voorwaarts, maar dit is bijna een heilige oorlog uitroepen tussen deb en rpm gebruikers.
Zolang de gebruikers dezelfde package manage tools zou kunnen gebruiken zal het ze een worst wezen in wat voor formaat de package zelf aangelevert wordt.
Afgezien van dat het je gevoeliger bent voor aanvallen, heeft iedere distro zijn visie als het gaat om stabiliteit en compatibiliteit. Om bijvoorbeeld Slackware te nemen die heel lang de boot heeft afgehouden om over te gaan naar een 2.6 kernel en Ubuntu die redelijk de nieuwste versie Linuxkernel implementeert.
LSB is in principe een goede zaak, maar door o.a. RPM verplicht te stellen, gaat het een stap te ver. Er moet keuze blijven, keuze tussen RPM, DEB of iets anders, mits dit aan dependency checks doet, en wie wil moet daar ook vanaf kunnen wijken (bijvoorbeeld tar.gz gebruiken en zelf de checks doen).

Volgens velen is DEB ook beter als RPM, dus als je al een onderdeel verplicht stelt, dan moet je zeker de beste gebruiken.
Een distributie als Fedora gaat steeds voor het laatste nieuwe. Zij offeren stabiliteit op voor vooruitgang. Debian gaat dan weer puur voor die stabiliteit en de rest komt op de tweede plaats. Dat zijn 2 doelen die niet te verenigen zijn.
Wel slim bedacht, je gratis systeem gebruiken als speelplaats voor de technologieen en in de enterprise variant beproefde technologie aanleveren. Waarschijnlijk doe je er dan wel goed aan om je webserver niet op de laatste versie van Fedora te draaien.
Nog beter om heel geen Fedora te gebruiken voor webserver.
Ik zou het liever anders willen zeggen: geen Fedora gebruiken op productie-machines. Fedora is vergelijkbaar met Debian Testing, CentOS is vergelijkbaar met Debian Stable.
En CentOS is weer de gehercompileerde open variant van RHEL.

Tsja.
Fedora is beter met XEN dan Debian. Dat de Debian kernel nu de fedora patches heeft, duurde erg lang..
waarschijnlijk omdat de fedora patches er erg lang over deden om in mainstream te komen ( patches moeten vaak opgeschoont / verbeterd worden voor dat gebeurt).

Als je voor Debian kiest, kies je boven alles voor stabiliteit, Fedora is meer de development tuin van Red Hat.
Op https://wiki.ubuntu.com/KernelTeam/UbuntuDelta/Karmic vind je een lijst met de verschillen tussen de Ubuntu "karmic" 2.6.31-kernel en de standaard 2.6.31-kernel. Die patches zijn ook beschikbaar in git.

Ik vermoed dat Fedora ook een gelijkaardige, maar lichtjes verschillende, kernel heeft. Een Fedora-gebruiker kan je misschien uitleggen waar je hun "delta" t.o.v. de vanilla kernel kan vinden.
Je kan de kernel altijd nog zelf compileren als de grote een probleem is.
true de linux kernel is modulair, en als de BASIS voor alle belangrijke spelers nagenoeg synchroon loopt, betekend dat ook dat er aan juist DIE tak meer gefixt en ontwikkeld wordt,
en dat ze sneller en effectiever minor versies kunnen droppen...

of en welke drivers modules en patches verder worden toegevoegt is dan aan de Distrobouwer, - maar voor de patches is het ongetwijfeld ook makkelijker op steeds met de distro's mee te groeien,

sterker nog ik denk dat als er wat spelers synchroon,, gaan lopen het ook makkelijker wordt om sneller kernel upgrades uit te rollen,
Ik gebruik Debian unstable dus release cycles zijn voor mij niet van belang, ongelukkige developers des te meer.
Wat jij gebruikt maakt niet uit, wat de massa gebruikt is van belang.
Installeer jij dan maar weer windows..

En Ubuntu praat waarschijnlijk over een gedeelde kernel met Debian/Fedora/CentOS/Mandrive gewoon wat van de andere grote jongens
Ik werk voor nu voor meer dan 15 jaar als Linux Engineer voor banken, verzekeraars en andere grote organisaties.

Dus even een opmerking over OS keuze.

De keuze wordt bepaalt op basis van support, support vanuit de leverancier van het OS, support vanuit de leverancier van de applicatie die er op gaat draaien en support vanuit de hardware leverancier waar het OS op geÔnstalleerd word (Server/San).

Debian wordt niet ondersteund en voor Ubuntu is vaak nog geen ondersteuning. Dit betekend niet dat het niet werkt. Maar voor een grote organisatie is het geen optie.

RHEL word voor 7 jaar ondersteund. (waarvan 4 jaar driver updates voor de standaard kernel).

http://www.redhat.com/security/updates/errata/

Het zelfde geld voor SLES.

http://support.novell.com/lifecycle/

En Ubuntu. (5 jaar)

Maar waar het allemaal om draait is hardware en software support. Zoals HP servers [url]http://h18006.www1.hp.com/products/servers/linux/options-matrix-all.html

Of IBM

http://www-03.ibm.com/ser...ompat/us/nos/matrix.shtml

Zie dat er geen Debian of Ubuntu op vermeld wordt. Ubuntu is overigens wel mogelijk. Debian niet omdat er geen "Professionele" organisatie achter zit.

Dus dan zul je met een partner moeten werken.

Even een herhaling, niet ondersteund betekend niet.. niet werkend. Alleen als ik een probleem heb kan ik niet naar IBM of HP gaan want die ondersteunen het niet.

Ik denk niet dat er maar een kernel configuratie zal komen. Waarom niet..

1) Elke Linux distributie heeft zijn eigen filosofie/doelgroep en de kernels zijn daar een reflectie van.
2) Bugs worden al geplet en terug gevoert naar de vanila kernel. Het zijn de optimalisaties die verschillen.

Wat wel zou kunnen is dat alle Distributies besluiten om naast hun eigen


Nu terug naar de oorspronkelijke topic.

Ik ben blij dat er een Debian is, alhoewel ik zelf het meeste OpenSUSE en SLES/RHEL gebruik.

Maar ik denk dat Conical zich gewoon met hun eigen ontwikkeling moet bemoeien en wat meer tijd moet besteden aan officieel support van de IBM/HP/Oracle/SAP wereld te krijgen.

Debian zal altijd hun eigen wereld supporten.. Free and Open Source.. En ik kan daar mee leven. Maar ik denk dat het niet in het belang van Ubuntu is. Ik zou er niet verbaast over zijn als over een aantal jaren Ubuntu min of meer wegdrijft van Debian omdat de ontwikkelingen daar te traag gaan.

We zullen wel zien ;-)
Mag je eens uitleggen waarom je bij HP support kan krijgen voor Debian. Ze shippen elke 6 seconde een Linux-server naar een klant toe. Ze zijn na Sun en Intel de grootste contributeur aan de FOSS-wereld.

Het probleem met Debian is hetzelfde als met RHEL en SLES. De ISV-support is slecht tot niet. En als je kijkt hoe ISVs nu support leveren op platformen zoals AIX, Solaris en Windows zal dat de komende jaren ook niet gaan verbeteren.
Moet je hierin niet twee dingen heel duidelijk scheiden?

Aan de ene kant de desktop en de concurrentie met Apple en MS. Duidelijkheid voor de gewone gebruiker cq. overstapper, standaardisatie qua pakketbeheer, samenwerking tussen de distro's hetgeen een goede indruk kan geven op windows en apple gebruikers...

Aan de andere kant de corporate/server kant van Linux, met op de maat toegesneden oplossingen. Hierin zal de kernel met al zijn flexibiliteit vooral divers moeten blijven en de versch. distro's hun eigen gang moeten blijven gaan...

Imho, als debian en ubuntu desktopper, lijken ze sterk op elkaar in het gebruik. Het zou mooi zijn als beider developers de neuzen 1 kant op laten wijzen...wordt maar sterker, en doe wat water bij de wijn!
uiteindelijk gaat het erom om meer marktaandeel te krijgen en daarin heeft Shuttleworth zich imo al bewezen.
ik denk dat je je vergist, voor shuttleworth gaat het uiteindelijk om meer geld verdienen, voor de Debian community gaat het over het nastreven van een ideaal, namelijk een functioneel, stabiel, opensource (GPL achtig) besturingssysteem, zonder concessies.
Mochten de distro's hierdoor dichter bij elkaar komen zou dat wellicht een goeie zaak zijn, vooral voor nieuwe gebruikers die nu vaak tussen al die distro's door het bos de bomen niet meer zien en daardoor ietwat geÔntimideerd zijn en er uiteindelijk gewoonweg niet meer aan beginnen en daarom bij Microsoft blijven.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True