Die Sidux-Community im Interview

**Ghandy** · 22. 11. 2009, 22:40

Eigentlich versuchen die Entwickler von Sidux das Unmögliche möglich machen. So möchte man aus dem experimentellen Entwicklungszweig von Debian eine regelmäßig erscheinende und gleichzeitig stabile Linux-Distribution zaubern. Was also ist Sidux? Debian heiss und scharf!

zur News

**suppaman2** · 22. 11. 2009, 23:48

Interessantes Interview

**Molnitza** · 23. 11. 2009, 02:37

Wenn ich das lese weiss ich nicht, warum ich z.Z. einen Debian Server mit Sid Repo betreibe. Nur als Desktop OS wär Sidux für mich nicht grad die beste Wahl. Ich mag mein Gnome

**braindad** · 23. 11. 2009, 11:53

Zitat von Molnitza

Wenn ich das lese weiss ich nicht, warum ich z.Z. einen Debian Server mit Sid Repo betreibe. Nur als Desktop OS wär Sidux für mich nicht grad die beste Wahl. Ich mag mein Gnome

Vom Sidux-Konzept bin ich auch jedesmal wieder aufs neue begeistert, wenn ich darüber lese. Da ich aber nunmal "leider" auch Gnome bevorzuge und mit aktuellen KDE-Versionen nicht viel anfangen kann, bleibt mir das System bislang auch versperrt. Wäre echt schön, wenn Gnome wenigstens rudimentär von Sidux supportet würde. Vielleicht wird Gnome 3 ja hinsichtlich der Pflege einfacher, damit Sidux das maintainen kann. Wobei da dann auch wieder die Frage für mich ist, ob Gnome 3 auf Grund des neuen Bedienkonzepts weiterhin mein Favorit bleiben wird. Die Zeit wird's zeigen

**suppaman2** · 23. 11. 2009, 17:13

Es gibt auch eine bleeding edge und rolling release Distribution abseits von Debian bzw. Sidux, die unter Anderem Gnome unterstützt

**a_d_s** · 25. 11. 2009, 19:53

An der Stelle frage ich mich, warum immer mehr Leute eigene Distributionen starten. Wäre es nicht (zumindest teilweise) sinnvoll, die Arbeit in die Verbesserung der bestehenden Distributionen zu stecken?

**suppaman2** · 25. 11. 2009, 20:00

Zitat von a_d_s

An der Stelle frage ich mich, warum immer mehr Leute eigene Distributionen starten. Wäre es nicht (zumindest teilweise) sinnvoll, die Arbeit in die Verbesserung der bestehenden Distributionen zu stecken?

Wenn eine neue Distribution veröffentlicht wird, dann hat das in der Regel Gründe. Zum Beispiel eben ein neues Konzept, um beim Beispiel Archlinux zu bleiben: Eigener Paketmanager mit User Repositories, anderes Init-System, andere Philosophie (der User kontrolliert sein System komplett selbst - Ubuntu sieht das z.B. anders) und so weiter.

Dazu kommt, dass man bei einer eigenen Distribution praktisch selbst der Maintainer ist und sich nicht anderen unterordnen muss.

**a_d_s** · 25. 11. 2009, 20:18

Also der "ich bin mein eigener Chef"-Gedanke ist aber genau das Gegenteil von dem, was man mit Open Source eigentlich erreichen will.

**suppaman2** · 25. 11. 2009, 20:27

Warum? Es ist doch so, dass es auch bei den OSS Projekten klare Rangordnungen gibt - nicht jeder hat Schreibrechte auf den GIT/SVN/CVS-Servern um ein Beispiel zu nennen. Wem das Projekt nicht passt, der kann es ja selbst forken und es dann verbessern, einen größeren Schwerpunkt auf seine eigenen Kriterien setzen und so weiter.

Wenn du jetzt einen Patch geschrieben hast für ein Projekt, bei dem du nicht der Maintainer bist, kann es ja durchaus sein, dass dieser nicht akzeptiert wird. Also einen oder mehrere Chefs gibt es da schon.

**a_d_s** · 28. 11. 2009, 00:10

Es ist doch aber eher so, dass wegen jedem zweiten abgelehnten Patch dann ein Projekt geforkt wird. Das fördert nicht gerade das Vorankommen von Open Source im Allgemeinen sondern verteilt recht effektiv die vorhandenen Kräfte.

**suppaman2** · 28. 11. 2009, 13:08

Hättest du denn eine bessere Lösung bei einem nicht akzeptierten Patch?

- Der Patchersteller hat Arbeit investiert um den Patch zu erstellen und würde diesen folglich auch gerne benutzen

- Der/Die Maintainer lehnen diesen Patch aus welchen Gründen auch immer ab

- Der Patchersteller erstellt nun einen Fork, der seinen Patch enthält => beide Parteien sind zufrieden

Aber das ist wie gesagt nicht der einzige Grund, warum man einen Fork erstellen würde. Die größte Motivation wird wohl sein, dass man andere Schwerpunkte legen will, die sich mit den ursprünglichen schlecht oder nicht vereinbaren lassen.

**a_d_s** · 28. 11. 2009, 16:21

Wie wäre es mit vorher reden? Jedes Projekt hat eine oder mehrere Mailinglisten und bevor ich einen Patch schreibe kann ich fragen, ob die neue/geänderte Funktionalität erwünscht wird.

Wenn ich gleich mit der Tür ins Haus falle, ist klar, dass da etwas nicht funktionieren kann. Einerseits entspricht der Patch vielleicht nicht dem, was sich das Projekt wünscht, aber andererseits hat der Autor schon Arbeit investiert und will die natürlich gewürdigt sehen - ggf. in Form eines Forks. Hätte man statt dessen vorher darüber gesprochen, welche Features gewünscht sind und wie die implementiert werden, hätte es unter Umständen weniger Stress gegeben.