Gepubliceerd: Maandag 10 augustus 2009
Ubuntu haalt de banden aan met Debian, de Linux-distributie waar het op is gebaseerd. Canonical staat eigen ontwikkelaars af om het Debian-project een nieuwe impuls te geven.
Toon volledig artikel
Geen reacties? Ik lees altijd "waarom wordt er nooit iets over Linux gepost, maar zoveel over MS". Dan hebben we eindelijk een topic, en blijft het stil. Kennelijk is de interesse dus toch niet zo groot..
Het is niet echt nieuwswaardig. Dat er wat frustraties bestaan tussen Debian en Ubuntu weten we nu wel. De grootste ruzie leeft tussen de fanboys, en niet bij de direct betrokkenen.
Er zijn overigens al een hoop Ubuntu developers die ook aan Debian werken. Veel van hun werkten al aan Debian voordat Ubuntu bestond, en die blijven dat doen, niet alleen omdat ze het leuk vinden, maar omdat het in het voordeel van Ubuntu is.
Ubuntu probeert niet al te veel af te wijken van Debian. Alles wat ze veranderen zullen ze zelf moeten ondersteunen. Als ze de veranderingen rechstreeks in Debian opnemen dan helpt de Debian community met het onderhoud.
Ik zelf zie niet zo veel in gemeenschappelijke freezes. Hoewel er zeker voordelen aan zitten lijkt het mij veel te moeilijk om de boel synchroon te houden.
Als het een keer toevallig zo uitkomt zou je wat extra moeite kunnen doen om de boel te synchroniseren, maar op de lange termijn is het niet vol te houden. In de tijd dat Debian nodig heeft om van freeze tot release te komen doet Ubuntu twee releases.
Ook wordt het gebrek aan overleg met ontwikkelaars zelf gelaakt.
Iemand hier een mening over?
Ik moet bekennen dat ik Debian niet echt volg, dus voor mijn komt dit nieuws als een donderslag bij heldere hemel. Wanneer is dit voorgesteld? Of is het gewoon eenzijdig besloten?
In het laatste geval kan ik me enigszins voorstellen dat de ontwikkelaar lichtelijk gepikeerd zijn.
Ik denk dat dit positief voor Debian zou kunnen uitpakken omdat de release cycli nu vrij groot zijn. Kortere cycli, kunnen bijdragen aan een grotere bekendheid. Aan de andere kant kan het ook haastwerk opleveren om een cyclus te halen, met meer bugs tot gevolg.
Ps. Zo goed Seven? ;)
Ik denk dat het verschil tussen Debian en Ubuntu vooral zit in de toepassing.
Zoals ik me Debian herinner (sinds Sarge), was deze meer voor server doeleinde geschikt en niet zo zeer voor op de Desktop. Omdat de basis van Debian zo clean is, heeft Ubuntu gekozen voor Debian, ook vanwege haar package manager. Ubuntu moest wel veel sleutelen om bijv. Beryl op de desktop te brengen, hier loopt Debian dus achter.
Ik denk dat Shuttleworth graag ziet dan beide distro's helemaal synchroon lopen, en dan moet veel ontwikkeld worden.
Al met al een goede zaak, maar kan me voorstellen dat dit met wrijving gepaard gaat.
Ik denk dat het verschil tussen Debian en Ubuntu vooral zit in de toepassing.
Ik denk dat het verschil eerder zit in clue van de gebruiker. De debian gebruiker weet doorgaans goed wat hij doet, en wil daarom een zo transparant mogelijk systeem dat werkt zoals hij dat wil.
De ubuntu gebruiker wil doorgaans dat "het werkt". Daarin is ubuntu wel heel erg goed.
Wanneer is dit voorgesteld? Of is het gewoon eenzijdig besloten?
Dit is besproken/besloten tijdens de jaarlijkse Debconf conferentie.
Fragment uit de debian-annouce mailing van 29 juli:
The new freeze policy was proposed and agreed during the Debian Project's yearly conference, DebConf, which is currently taking place in Caceres, Spain. The idea was well received among the attending project members.
Een vlottere release-cycle, maakt het invoeren van de "...-and-a-half" tussenversies (om nieuwere hardware te ondersteunen) overbodig. Maar het moet niet ten kosten gaan van Debian's speerpunt: stabiliteit
Een releasebeleid "wanneer het af is", klinkt wel sympathiek maar het heeft vooral nadelen. Zo is Firefox zoals het in Debian Stable zit niet "stabiel" maar stomweg verouderd, en dat geldt voor veel meer software. Er zijn genoeg voorbeelden van projecten die ook niet commercieel zijn, maar waar een timed release-schema uitstekend werkt. OpenBSD is er daar bijvoorbeeld een van, en Theo de Raadt is echt niet iemand die zich ook maar *iets* aantrekt van commercie.
Debian zou er goed aan doen om ook voortaan timed releases te doen en het zou praktisch en handig zijn wanneer die regelmatig overlappen met Ubuntu. De realiteit is immers dat Ubuntu intussen meer mainstream is dan Debian. Op elkaar afgestemde release-cycli zouden onderlinge kruisbestuiving flink kunnen bevorderen, nog afgezien van de vraag of er een commercieel belang gediend wordt.
Gelijktijdig releasen is nooit aan de orde geweest, onder andere omdat Debian net zo veel tijd neemt als nodig is. Alleen het moment waarop de ontwikkeling bevroren wordt om naar een release toe te werken wordt gesynchroniseerd, of dat was de bedoeling.
Gelijktijdig is ook helemaal niet handig, maar "regelmatig overlappen" was misschien niet de handigste formulering daarvoor. Wat wel handig is: gelijktijdig samen een release dichttikken zodat er van beide zijden bugfixes komen. Als een dergelijke samenloop alleen voorkomt voor de Ubuntu LTS-releases is dat ook prima.
Het spanningsveld tussen Debian & Ubuntu bestaat al wat langer. Maar het is vaak een eenzijdige spanning want Debian heeft nou eenmaal andere normen en waarden dan veel andere distributies zoals Ubuntu. Dat is niet zozeer goed of slecht, maar gewoon zoals het is.
Ik denk dan ook dat de reactie van Canonical inderdaad is ingegeven door het inzicht dat het voor iedere distributie van belang is dat onderling meer zaken met elkaar worden afgestemd. Dat ontwikkelt een stuk sneller en draagt bij aan een solidere basis van betrokken distributies.
En als dat zo is dan is het ook verstandig om zelf 'boter bij de vis' te voegen en te starten met het leveren van bijdragen aan Debian.
Inmiddels weten we wel dat er honderden distributies zijn om uit te kiezen. Maar de som der delen zou een heel stuk hoger kunnen liggen als onderling meer samenwerking zou ontstaan.
Het komt toch regelmatig voor dat de implementatie van vernieuwende technologie van de een leidt tot aanpassingen bij de ander. Dat kan en moet slimmer worden aangepakt.
Ik weet niet veel over de kwestie maar volgens mij zit het probleem bij de commerciele drivers (bijv. NVIDA). toelichting: kernelversie->driverversie (deb pakketje)
... kon het bericht niet veranderen door NoScript denk ik.
Dat ligt eerder aan de briljante wijze waarop Webwereld cached denk ik. Of je NoScript aan of uit hebt staan maakt niet veel uit. Voor je een gewijzigd bericht probeert te wijzigen moet je een minuut of wat wachten.
Wat je verder met je opmerking bedoelt volg ik niet helemaal. Ik kan me niet voorstellen dat Debian uitgeleverd wordt met de binary blob van Nvidia. Dus wat heeft dit met kortere release cycli te maken?
De "Binary blob" moet natuurlijk wel goed communiceren met de kernel. Hiervoor waren (ben niet meer zo thuis op de "Desktop kant" van Debian dus verbeter me als ik onzin vertel) in het verleden ook wijzigingen in de kernel benodigd. En aangezien de kernel in Debian over het algemeen achter loopt kun je daar zeker wel conflicten krijgen als je een nieuwere driver wil gebruiken.
Nu weet ik niet uit mijn hoofd op welke Release Ubuntu leunt kwa release (Stable/Testing/Unstable) en de Testing en Unstable sneller met kernel patches zijn dan Stable kan het zijn dat mijn bovenste stukje geen/weinig impact heeft op de proprietary code die niet in de release van Debian kunnen
Op zich valt het wel mee. De NVIDIA-driver heeft een stukje broncode voor een kernelmodule. Deze module wordt op maat gecompileerd voor de draaiende kernel (heb je wel headers voor nodig). Vervolgens verloopt de communicatie tussen kernel en binary blob via deze module. Werkt redelijk stabiel, al is het natuurlijk verre van optimaal en een veiligheidsrisico.
Canonical staat eigen ontwikkelaars af om het Debian-project een nieuwe impuls te geven.
Heeft Debian een impuls nodig? Of wil Canonical gewoon een leuk gebaar maken? Uiteindelijk komt ontwikkelwerk voor Debian ten goede aan Ubuntu dus komt het op mij over als een broekzak-vestzak constructie.
Wat er verder zij met vaste release cycles is niet van belang. Het onderwerp komt zo nu en dan ter sprake maar verdwijnt ook steeds weer. Binnen Debian zijn ze er achter dat het geen zin heeft om vele jaren door te modderen aan een stable release maar een strakke deadline voor een freeze heeft ook geen zin omdat er eenvoudigweg teveel software is die op teveel platformen moet werken. Daarbij komt dat Debian toch vrij regelmatig released, ook al wordt geen enkele deadline gehaald.
Voor Canonical maakt dat al helemaal niet uit. Ubuntu wordt goed op tijd uitgebracht, ongeacht de toestand van Debian. Voor zover ik weet is Ubuntu gebaseerd op sid, de unstable repository van Debian. En die rolt rustig door, hooguit wat minder hard als er een freeze is voor stable/testing.
Volgens mij is het echte nieuws dat Canonical wil proberen om "alle" oss een gezamenlijke development cycle te geven. En daarbij Debian als eerste uitnodigt om mee te doen. Ik denk dat het een erg mooi streven is.
Het doel is niet ervoor te zorgen dat alle distributies op hetzelfde moment hun release plannen maar dat de softwareontwikkelaars mee doen.
Toen Hardy gelanceerd werd hebben ze er nog snel firefox 3.0 ingestopt terwijl ie eigenlijk nog vrij buggy was en zat er een OpenOffie.org versie (2.4) in die al veroudert was omdat versie 3.0 eraan zat te komen. zoiets zorgt voor onstabiele systemen en ontevreden gebruikers.
Wanneer er meer distributies hun releasecyclus duidelijk plannen zal het voor de softwareontwikkelaars een aanmoediging zijn om dat voor hun software ook zo te doen. De releasecyclus van Ubuntu is trouwens gebasseerd op die van GNOME :)
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
