HJB, in deiner News fehlt eine ganze wesentliche Information: Um was es überhaupt geht.
Wenn du schon Datenpakete schreibst, dann doch bitte wenigstens auch den englischen Begriff dazu, immerhin ist das die Debian Hauptsprache.
Auch wenns im Originaltext steht, die News sollte es schon auch enthalten:
-------- one important question lately has been "What should we do with large packages containing data", like game data, huge icon/wallpaper sets, some science data sets, etc. Naturally, this is a decision ftpmaster has to take, so here are our thoughts on it to facilitate discussion and see if we missed important points but we keep the right to have the last word how it gets done. --------
Mich überrascht hier etwas das scheinbar angedacht ist das dann wohl die Spieledebs die Datendebs nicht als Pflicht-Abhängigkeit nennen dürften. Das würde ja an sich keinen Sinn ergeben, läuft das Spiel ja ohne nicht. Allerdings habe ich den Originaltext nur überflogen um die News hier zu verstehen.
Auf den ersten Blick ist mir nicht ganz klar, was das bringen soll. Große Pakete werden also in ein anderes Archiv verschoben. Trotzdem muss ja auch dort für ausreichend Ressourcen gesorgt werden, dann heruntergeladen werden sie deshalb ja nicht automatisch seltener.
Kann jemand ein Beispiel nennen, welche Pakete >50MB in dieses Data-Archiv wandern würden? Handelt es sich womöglich um Pakete, die sehr lange konstant bleiben? Warum sollte dann weniger Traffic beim Spiegeln entstehen, die Spiegelserver arbeiten doch bestimmt inkrementell?
Wer einen Mirror betreibt und "main" spiegelt hat keine Möglichkeit Pakete aufgrund ihrer Größe wegzulassen. Gäbe es ein eigenes Repository für große Pakete könnte jeder Mirror für sich selbst entscheiden ob er auch noch "data" mirrorn will.
Resultat: Die großen Mirrors mit viel Ressourcen spiegeln beides, die kleineren nur "main". Meine Auffassung nach ist so etwas ohne die Aufteilung nicht möglich.
Okay, wie ich auch aus dem Beitrag von LH entnehme ich, es handelt sich um Dinge "like game data, huge icon/wallpaper sets, some science data sets".
Eine mögliche Erklärung wäre also durchaus, man will eine Art Zwei-Klassengesellschaft bei den Paketen etablieren. Wichtige Pakete aus "main" stehen auf allen Servern zur Verfügung, die durch den Wegfall der großen Brocken deutlich entlastet werden. Ungeliebter Kram wird eben nur noch auf wenigen, dann sehr stark ausgelasteten und folglich langsamen Servern, gespiegelt.
-> "Main" flutscht, Eye-Candy und Spielkram tröpfelt -> der Geek strahlt, der Dau weint.
Ich kenne die "üblichen" Paketgrößen ja nicht, aber vielleicht sollte man die Grenze für "große Pakete" eher bei 100 MiB legen. Das wäre doch noch eindeutiger. Ist der Wert zu niedrig, könnte er in naher Zukunft geändert werden müssen.
Eine Möglichkeit die nicht erwähnt wurde wären wohl Metapakete die bei der Installation dann einfach die Daten von einem separaten Server ziehen, so ähnlich wie das z.B. bei dem f-prot-installer Paket ist.
und nein, 'kleinhacken' bringt es nicht. Siehe wesnoth. Was hat man davon, daß man 'nur' 13 mb installieren braucht, wenn dan überhaupt nichts dabei ist? Installiert man das nötigste dazu ist man doch wieder bei 100mb und mehr ....
Es geht doch gar nicht darum, dass es weniger zu Downloadendes werden soll, sondern das man die Mirrors kleiner dimensionieren kann, wenn man die großen Datenpakete auslagert.
Ich denke nicht, dass diese Pakete angefasst werden. Sie enthalten die minimalen Daten, die man eben benötigt. Etwas anderes ist es mit Spielen oder Anwendungen, die mit verschiedenen Datenpaketen laufen können. Dann könnte ein minimales Paket in main stehen, optionale größere Daten in data. Ein Beispiel wäre flightgear. Das braucht ein Minimum von 200 MB, damit man starten kann. Dies wird wohl in main bleiben. Aber es gibt Gigabytes an Extradaten, das wäre ein Kandidat für data. Bisher gibt es diese nicht als Debian-Paket.
Ja. Ein weiteres Problem wäre übrigens die Versionsabhängigkeit erzeugter Binärpakete von ihren Sourcepaketen. So rutschen selbst bei einem Typofix in der Manpage eines Programms sämtliche dazugehörigen Binärpakete in einer neuen Version mit durch, selbst wenn sich an denen gar nichts geändert hat - natürlich dabei auch diese optionalen Datenpakete.
Ein weiteres Problem wäre übrigens die Versionsabhängigkeit erzeugter Binärpakete von ihren Sourcepaketen. So rutschen selbst bei einem Typofix in der Manpage eines Programms sämtliche dazugehörigen Binärpakete in einer neuen Version mit durch, selbst wenn sich an denen gar nichts geändert hat - natürlich dabei auch diese optionalen Datenpakete. Das stimmt so nicht. Bei deinem Beispiel Flightgear haben z.B. flightgear und fgfs-base jeweils ein eigenes Source-Archiv. Bei einem Typo in der Manpage muss nur flightgear, aber nicht fgfs-base angefasst werden.
Was sicherlich als "Motivation" dazu beiträgt Spiele schon heute teilweise in einzelne Pakete zu trennen.
Die Idee nur noch einen "kleinen" Mirror betreiben zu müssen, und die großen Pakete graußen zu lassen halte ich aber für mich schlecht. Immerhin dürfte es viele lokale Mirror in Firmen und größeren WGs geben bei denen nicht immer auch das dann "Data" benötigt würde, oder nicht oft genug um ein Spiegeln als lohnen erscheinen zu lassen.
Kommt halt drauf an. Wenn man was in wesnoth-music-1.4.0-1 "fixed", und die Abhängigkeit auch auf wesnoth-1.4.0-1 legt wird natürlich das Paket mit aktualisiert.
Aber unabhängig davon. Ich denke schon dass das was bringt. Bei wesnoth installier ich eigentlich nie das Musik-Paket (DL 75MB), weil ich trotz der guten Musik Quali lieber nen mp3 Player laufen habe. Auch die Kampagnen lade ich nicht nochmal runter, nachdem ich sie bei Wesnoth 0.9x mal durchgespielt habe oder nicht unbedingt spielen muss. (utbs 6MB, httt 6MB, trow 5,5MB etc etc..) Da kommt schon einiges zusammen. Installiert habe ich wesnoth + wesnoth-data = 40MB. Macht schon was aus....
Wesnoth ist ein schönes Beispiel dafür, daß $upstream doch bitte Code und Daten in mehrere Pakete aufsplitten und zusätzlich Delta-Dateien anbieten sollte. Archive/Isos ab mehreren hundert Megabyte könnten auch gerne - so die Lizenz es zuläßt - via P2P verteilt werden; und zwar möglichst distributionsübergreifend.
Wie wär's, wenn man alles so lässt wie bisher, ABER bei kleineren Updates (Version 10.5.2.1 -> 10.5.2.2) nicht immer wieder die ganzen 500 mb, sondern nur die 2 mb differenz als zusätzliches Paket anbieten würde? Dafür müsste man apt eventuell ein bisschen anpassen.
Ansonsten könnte man doch auch für "unwichtige" Pakete wie Spiele, die besonders groß sind, eine Art "apt-bittorrent-repos" anbieten. Mit den entsprechenden Checksummen auf den Hauptservern dürfte das keine so großes (sicherheits-)Problem sein, oder?
Und jetzt macht mich nicht zu sehr fertig, ich bin kein Experte, sondern nur Benutzer
Netter Ansatz, gefällt mir. Bin persönlich auch sehr dafür die Last von einzelnen Servern auf viele Nutzer zu verteilen. Ob BT der richtige Ansatz ist, ist vllt. zu diskutieren.
Und warum nutzt man nicht mehr Informationen über die Pakete selbst und lässt dann den jew. Admin entscheiden was er in seinen Repo zur Verfügung stellt? Der eine möchte eben keine Pakete über 50Mb, dem nächsten sind bereits 20 zu viel. Einfach eine DB drüber und jeder könnte selber über die verschiedensten Features entscheiden was er anbietet: "<60mb && non-free && !maintainer=sun"
Da lob ich mir OpenSuse mit seinen Delta-Paketen. Unter Debian führt z.B. jedes noch so kleine OpenOffice-Update sofort zu einem Riesendownload. Fast jedes Paket muß praktisch neu heruntergeladen werden. Genau das könnte man effizienter gestalten. Was Installationen anbelangt: Ich würde die meisten Spiele einfach weglassen, vor allem diejenigen aus dem contrib- und non-free-Zweig. Da auf einer jugendschutzgesetzkonformen Debian-CD oder -DVD Nexuiz oder Alien Arena ohnehin nichts verloren haben, könnte man diese Spiele auch gleich von den Debian-Servern verbannen und z.B. auf die Seite der Originalautoren verweisen. Torcs hingegen wäre für mich o.k. Wichtige Pakete wie z.B. OpenOffice gehören aber meiner persönlichen Meinung auf alle Fälle ins main-Repository.
"Da lob ich mir OpenSuse mit seinen Delta-Paketen." Das ist im Bereich Paketverwaltung aber auch so ziemlich das einzige was SuSE hier besser macht Ansonsten halte ich das Problem der Pakete nicht für elementar, sie müssen nur besser aufgeteilt werden für Updates.
"Ich würde die meisten Spiele einfach weglassen" Grundsätzlich hast du übrigens recht, sogar normale Spiele dürfen nicht ohne Jugendprüfung auf CDs, selbst wenn es ein Mensch-ärgere-dich-nicht ist. Das ist auch so ein Problem in DE...
Bezüglich OpenOffice sehe ich das auch so, allerdings sollte es dennoch wo immer möglich zerteilt werden. Wobei ich persönlich OOo heute nicht merh als groß empfinde. Vor Jahren habe ich dabei noch die Augen verdreht wenn mal wieder eine neue OOo Version erscheint bei den Paketgrößen, aber heute passt sie noch zusammen mit hundert anderen Programmen auf einen USB Stick
Ansonsten halte ich das Problem der Pakete nicht für elementar, sie müssen nur besser aufgeteilt werden für Updates. Eine bessere Aufteilung bringt nichts, wenn dann statt 1 Paket eben 100 Pakete aktualisiert werden müssen. Da müsste man schon Versionsunterschiede zwischen den Teilpaketen zulassen.
Warum sollten Versionunterschiede zwischen Teilpaketen nicht möglich sein? Soweit ich das aktuell sehe sind ja Abhängigkeiten in der Form " => x.xxx" jetzt schon möglich, nicht sicher bin ich mir ob " => x.xxx && <= y.yyy" auch geht. Wenn letzteres geht könnte man das ganze mit Unterversionnummern lösen.
Freilich bringt das nur dann auch etwas wenn der Bugfix nicht eh alle Pakete betrifft
Warum sollten Versionunterschiede zwischen Teilpaketen nicht möglich sein? Ich habe nicht behauptet, dass das technisch nicht möglich wäre.
Bei Debians openoffice.org-*-Paketen sind die Abhängigkeiten aber zum Beispiel mit "=" gekennzeichnet. Beispiel: openoffice.org-base (2.0.4.dfsg.2-7etch5) hängt von openoffice.org-core (= 2.0.4.dfsg.2-7etch5) ab. Da kannst du nicht einfach bloß openoffice.org-core aktualisieren.
Das es jetzt noch nicht sonderlich schlau gelöst ist: Keine Frage Aber Debian müsste eigentlich jetzt schon in der Lage sein das anders zu handhaben. Vielleicht ist es eher eine Frage des wollens als des könnens.
Schwachsinn, warum sollte man keine Pakte für Spiele anbieten? Ein extra Repo games würde ich ja noch einsehen, aber die überhaupt nicht anzubieten ist ja wohl völliger Blödsinn.
Man solle das mit bittorrent mal vorantreiben, ja. Wär ja nicht so, dass es das nicht geben würde. http://debtorrent.alioth.debian.org/
Inkrementelle updates zu realisieren wär natürlich auch eine tolle sache bei den Paketbeschreibungen hat man das ja schon geschafft. Wird aber denk ich nicht so einfach zu machen sein.
Es muß ja nicht für jede noch so kleine Library im main Differenzupdates geben. Da ist bestimmt auch der Verwaltungsaufwand viel zu groß für die über 20.000 Pakete. Aber wenn nur die großen Pakete von Spielekram, Debugging-Symbolen (libqt4-dbg z.B. hat immerhin über 90MB und wer installiert sowas außer vielleicht Entwickler) oder auch Pakete wie openclipart-png (Derzeit 144 MB) in ein neues 50MB+Repo kommen, dann kommen da doch bestimmt nicht so extrem viele Pakete zusammen, aber dafür halt etliche Gigabytes an Daten und das ganze gleich dreifach für die Debianvarianten Stable Testing und Sid. Und genau da bei, diesen riesigen Datenmengen, lohnt es sich doch ganz bestimmt mal wenigstens über Differenzupdates nachzudenken. Schließlich würden dadurch das nur nie Differenzen zu den Paket-Dateien heruntergeladen werden müssen nicht nur die Debian-Mirrors entlastet, auch die User hätten es dann viel einfacher. Hat ja nicht jeder DSL-6000 oder sowas in der Richtung. User bei denen noch nicht mal DSL-Light (384Kbits) geht, können bei so großen Paketen doch im Grunde nur die Version sperren, die mal von CD oder DVD installiert wurde, damit man nicht bei jedem Update erneut mit 100'ten MB's an Downloads genervt wird. (Auch 'ne Möglichkeit Debian Testing mit einer lahmen ISDN-Verbindung halbwegs aktuell zu halten.)
> (libqt4-dbg z.B. hat immerhin über 90MB und wer installiert sowas außer vielleicht Entwickler) Landet auf jedem der von mir installierten Systeme, allein schon wegen des besseren Backtrace im Krashmanager.
Man könnte auch einfach ein Script zum "Selberkompilieren" anbieten, welches a.) den Source, b.) die Voraussetzungen (GCC, etc) und c.) Abhängigkeiten (*.dev etc) automatisch runter lädt, kompiliert und ein fertiges *.deb-Paket erstellt. Das wäre dann eine Reduzierung von > 50 MB auf 20 - 30 Kb und somit eine max. Entlastung. Zu mindestens bei Spielen wäre das eine gute Möglichkeit.
"Zitat : was die Infrastruktur einschließlich der Spiegelserver stark belastet" Es geht doch hier um online...oder nutzt du einen Spiegelserver offline?
Nein, aber Du nennst ein Beispiel, dass man die Pakete durch Herunterladen mithilfe eines Skriptes (oder Pseudopaketes) erledigen kann. Nur wo lade ich das herunter, wenn ich das dazugehörige Programm samt Daten offline installieren will?
Ich verstehe dein Posting nicht wirklich, an welcher Stelle sparrst du dir dann die 49 MB die du angibst? Erfindest du die Bilder bei Spielen dann dazu?
Falls du mich meinst ? Der Source wird vom Anbieter runter geladen. GCC und Abhängigkeiten von den dedian servern. Das spart doch enorm. Scahu dir mal z.B OpenArena an.
Ich verstehe einfach den Zusammenhang zur News nicht, vor allem nicht warum es helfen würde den Quellcode zu verbreiten. Du musst immernoch die Spielepakete holen. Und ob du nun Sourcepakete verteilt und die Daten von Debian holst oder die Sourcepakete+Datenpakete macht keinen echten Unterschied. Zumal du heute schon von Debian Bequem den Sourcecode bekommen kannst und mit einem Kommando daraus ein Deb erstellen kannst.
So wich den Artikel verstanden habe, geht es doch darum die "Hauseigenen" Server zu entlasten. Mein Beispiel -OpenArena- beträgt 275 MB. OpenArena von der OA Homepage herunterzuladen , "Ausführbar" zu machen und zu installieren, ink nach /opt etc. verschieben sind ein paar Zeilen in der Konsole.
Für diejenigen die damit nicht vertraut sind, könnte man ein Script anbieten und somit die 275 MB auf den "Hausservern" einsparen.
Zur Zeit sieht es so aus : OA 703 KB, OA-data 271 MB, OA-Server 345 Kb. Das könnte man komplett einsparen.
Mir leuchtet nicht ein, wiso ein neues Repositorium mehr bringen soll als ein weiterer Mirror.
Ein Torrent/FTP Hybrid als data.debian.org würde wenigstens das Problem der fehlenden Resourcen entschärfen. Dies würde aber eine Erweiterung von apt um das Torrent-Protokoll erfordern.
Geht es um Speicherplatz? Der kostet relativ wenig und muss nur einmal angeschafft werden.
Geht es um Bandbreite? Hier sehe ich das Problem. Zur Zeit muss ein !komplettes! Packet (z.B. dataxyz-1) nach jeder Änderung heruntergeladen werden. Nehmen wir an, in dataxyz-1, sagen wir 500MB gross, ändert sich ein Byte. Schon wird die Version -2 von - sagen wir 100.000 - Nutzer heruntergeladen. Das macht eben 50.000 GByte! Da entstehen u.U. enorme Kosten. Ein vernünftiges Diff/Patch System für Packetänderungen sollte speziell bei den Packeten, die hauptsächlich Daten enthalten, die Bandbreite um einen großen Faktor vermindern (1.000, 10.000 oder noch mehr). Damit würde ein upgrade oder dist-upgrade für den durchschnittlichen DSL Besitzer außerdem noch wesentlich schneller vonstatten gehen.
Super. Ich bekomme nur Meldungen 'Debdelta is not present: ...'. Wahrscheinlich kommen die debdeltas mit einiger Verzögerung rein (Stunden oder Tage?). Kommt also irgendwie für mich nicht in Frage...
apt BitTorrent fähigkeiten zu verleihen wäre doch eine praktikable Lösung, die Archive liegen eh in /var/cache/apt/archives rum, da könnte man so auch die Server entlasten. Die Signatur der Pakete kann man ja weiterhin vom debian server beziehen.
Ich faende es gut zBsp Daten wie Icons, Wallpaper usw nur als Skripten bereitzustellen die dann anderswo alles runterladen. Auch bei Programmen halt nur die Dinge als .deb anzubieten die Debian spezifisch sind - also nur das was konkret Systemspezifisch kompiliert werden muss. Auf der DVD Stable Version waere alles was sowieso auf jedem *NIX gleich bleibt (.ogg, *.jpg, *.xpm, *.svg, Dokumentation) dann als .tar.gz verpackt. Da spart man 'ne Meeeeeeeenge.
Es hat wirklich Sinn in Zeiten von Energiemangel und aehnlichem mal daran zu denken, dass nicht jede Distro alles extra verpacken muss.
Und wer garantiert einem, dass an der entsprechenden Stelle in 5 Monaten oder 5 Jahren noch die Files liegen? Oder das dort nicht mitten in meiner stable-Laufzeit neue Daten rumliegen, die mit meinem Paket nicht mehr funktionieren? Es hat gute Gründe, warum man Pakete erstellt.
Das kann man ja machen, eben zur Herstellung von Debian-CDs und -DVDs. Die könnte man dann z.B. zum Verkauf anbieten, um das Debian-Projekt mehr zu unterstützen. Man muß das aber wirklich nicht alles auf die Server legen. Vielleicht pflegt Debian inzwischen wirklich zuviele Pakete. Ideal wären doch z.B. vier Installations-CDs (Gnome-, KDE-, XFce- und Server-CD ohne GUI), dazu eine sinnvolle Anzahl von Paketen auf den Servern zum "Nachladen", ohne Spiele und auch ohne Bücher und Sammlungen wie Openclipart.
Es liegt aber auch an den Benutzern. Wenn man mehrere Desktops oder Server aufsetzen möchte bzw. muß und die betreffenden Mega-Pakete schon einmal heruntergeladen hat, dann kann man die meisten davon nach der Basisinstallation doch in /var/cache/apt/archives hineinkopieren und so beim Weiterinstallieren oder Aktualisieren der Basisinstallation beträchtlich Bandbreite sparen. Und: Von wem werden denn die großen Spielepakete gezogen, wenn nicht fast ausschließlich von Privatnutzern?
> Vielleicht pflegt Debian inzwischen wirklich zuviele Pakete. Und dann möchtest Du noch zwei verschiedene Pakete (ein "Vollpaket" und ein "Downloadpaket") für die Daten einer bestimmten Anwendung?
1. Alle Debian-Pakete auf zig CDs und zig DVDs. Dieses Paket-Sammelsurium sollte man z.B. kaufen können, aber nicht zum Download anbieten. (nur meine persönliche Meinung)
2. Download-CDs (s.o.) und Download-Pakete auf den Debian-Servern, um die entsprechenden Desktop- bzw. Serverumgebungen vervollständigen zu können. Dazu zählen bestimmt nicht Spiele (ebenfalls nur meine persönliche Meinung).
3. Es gäbe dann also immer nur ein Debian-Paket, aber es würden sich nicht mehr alle auf den Debian-Servern befinden. Vielleicht sollte man auch darüber nachdenken, generell z.B. ohne Spiele zu veröffentlichen.
4. Denke vielleicht auch einmal an Marillats Debian-Multimedia-Repository: Das gibt es ja auch nicht auf den Debian-Servern. Ähnlich könnte man ein Debian-Games-Repository einrichten.
Der Haken: Auch Marillat (als Beispiel) hat ziemliche Kostenprobleme wegen des zu hohen Bandbreitenverbrauchs:
http://www.debian-multimedia.org/ "I think you have noticed the Google Ads. I need that to pay the huge amount of bandwidth." http://www.debian-multimedia.org/statistics.php
Ein solches Problem wird sich vielleicht über die stetig zunehmenden Kosten "lösen" lassen: Vielleicht gibt es dann irgendwann Marillats Repository nicht mehr. Ähnliche Probleme scheint es ja auch mit "originalen" Debian-Servern zu geben.
Erik: "Und wer garantiert einem, dass an der entsprechenden Stelle in 5 Monaten oder 5 Jahren noch die Files liegen? Oder das dort nicht mitten in meiner stable-Laufzeit neue Daten rumliegen, die mit meinem Paket nicht mehr funktionieren? Es hat gute Gründe, warum man Pakete erstellt."
Ups! Daran hatte ich nicht gedacht... Da haste Recht! Das waere in Hinsicht auf die verschiedenen Definitionen von "stabil" "obsolete" (BTW, was waere die deutsche Verison von obsolete?) der Distors ja unmoeglich... Man daenke nur mal an die Distros die XMMS rausgeschmissen haben!
"Ich wiederhole gern meine Frage von weiter oben: Wie will man damit eine sinnvolle Offline-Installation erzeugen?"
Na ja, vielleicht dadurch, dass man die .tar.gz wo z.Bsp. die Icons, Bilder, wasauchimmer sind auch auf die DVDs packt - Ich weiss, ist ein bisschen umstaendlich...
Eine andere Idee waeren z.Bsp. komplexe jigdo (oder wasauchimmer) Skripte zu basteln die dann eine komplette offline DVD (Blue Ray? ) Version basteln mit vielen Dingen die man auf nem offline Rechner mal nicht eben so runterladen kann.
Eine andere Idee waeren z.Bsp. komplexe jigdo (oder wasauchimmer) Skripte zu basteln die dann eine komplette offline DVD (Blue Ray?:) ) Version basteln mit vielen Dingen die man auf nem offline Rechner mal nicht eben so runterladen kann. Ich weiß halt nicht, ob das ein Problem löst, welches wirklich existent ist. Die architekturunabhängigen Datenpakete auslagern, Upgrades über Deltas... damit sollte man ein System haben, was sowohl auf Bandbreite als auch auf Serverplatz hinreichend optimiert wäre.
Debian hat eine gute Philosophie. Auch das keine Firma (primär) dahinter ist, ist gut (Support kostet ja was)
Aber - debian ist GRAUENHAFT.
- Der sklavische Hang zum FHS, der Zwang alles und jedes in +1000 Pakete zu zerteilen, unglaublich langsam (ratet mal wie Ubuntu populär werden konnte. Ja, weil Debian SAULANGSAM IST), der Zwang alles und jedes zu Tode zu patchen, die Entwickler davon aber nicht immer informieren und durch das Patchen manchmal Fehler reinbauen.
Ich habe damit kein Problem, ich verwende kein debian. Die community ist auch recht freundlich, das muss man zugute halten. Aber es muss einmal gesagt werden, das es bessere Alternativen zu den grossen und alten Distributionen gibt.
Das hat auch wesentliche Vorteile. Denke bitte einmal an die äußerst effizient ausgestalteten kde-core- und gnome-core-Pakete (ideal für ältere Rechner). Oder an die Nutzer, die mit k3b unter Gnome brennen wollen. Dank der "Zerteilung" entgehst Du der Installation vieler unnötiger KDE-Pakete und -Bibliotheken, so wie das z.B. unter OpenSuse der Fall ist. In dieser Hinsicht macht das Aufsplitten sehr viel Sinn.
Das stimmt nicht. Ein Debian mit KDE läuft per Default flotter als Ubuntu. Hat dafür halt auch kein Tracker, etc. aktiv ... aber es ist Unsinn dass Debian langsamer wäre, es ist bei gleicher Konfiguration etwa gleich schnell.
Komisch... als ich damals auf 'nem PII mit 64 MB RAM alles von SuSE ueber *buntu probierte (ich glaube Gentoo, Slack + Derivate und LFS waren die einzigen die nicht das Vergnuegen hatten) und dann auf Sarge umstieg war alles vieeeeeeeeeeel schneller. Eben weil Debian nicht versucht hat beim Start bluetooth zu laden und auf 'nem offline Rechner die Zeit zu synchronisieren. Ich glaube auch du hast keine Ahnung.
OK, Etch war ein bisschen Traege wegen dem Umstieg auf x.org, aber Lenny war dann wieder viel schneller.
Kommt darauf an was du unter schnell verstehst. Ja, es dauerte halt ca. 7s bis Firefox da war, oder um die 10s fuer Konqueror, aber das eigentliche arbeiten war damit fluessig. Aber damals nutzte ich progs wie Xnc, dillo, usw. Der Rechner ist jetzt noch bei meinen Eltern, hat Etch aber mit 256 MB RAM.
Aber ich wollte damit sagen, dass Debian da viel schneller war als *buntu oder die rpm distros, eben weil es nicht jeden Stuss laden wollte. Also ist der Komentar dass Debian langsam waere foellig unwahr!
Um was es überhaupt geht.
Wenn du schon Datenpakete schreibst, dann doch bitte wenigstens auch den englischen Begriff dazu, immerhin ist das die Debian Hauptsprache.
Auch wenns im Originaltext steht, die News sollte es schon auch enthalten:
--------
one important question lately has been "What should we do with large
packages containing data", like game data, huge icon/wallpaper sets,
some science data sets, etc. Naturally, this is a decision ftpmaster has
to take, so here are our thoughts on it to facilitate discussion and see
if we missed important points but we keep the right to have the last
word how it gets done.
--------
Mich überrascht hier etwas das scheinbar angedacht ist das dann wohl die Spieledebs die Datendebs nicht als Pflicht-Abhängigkeit nennen dürften. Das würde ja an sich keinen Sinn ergeben, läuft das Spiel ja ohne nicht.
Allerdings habe ich den Originaltext nur überflogen um die News hier zu verstehen.
Kann jemand ein Beispiel nennen, welche Pakete >50MB in dieses Data-Archiv wandern würden? Handelt es sich womöglich um Pakete, die sehr lange konstant bleiben? Warum sollte dann weniger Traffic beim Spiegeln entstehen, die Spiegelserver arbeiten doch bestimmt inkrementell?
Wer einen Mirror betreibt und "main" spiegelt hat keine Möglichkeit Pakete aufgrund ihrer Größe wegzulassen. Gäbe es ein eigenes Repository für große Pakete könnte jeder Mirror für sich selbst entscheiden ob er auch noch "data" mirrorn will.
Resultat: Die großen Mirrors mit viel Ressourcen spiegeln beides, die kleineren nur "main". Meine Auffassung nach ist so etwas ohne die Aufteilung nicht möglich.
some science data sets".
Eine mögliche Erklärung wäre also durchaus, man will eine Art Zwei-Klassengesellschaft bei den Paketen etablieren. Wichtige Pakete aus "main" stehen auf allen Servern zur Verfügung, die durch den Wegfall der großen Brocken deutlich entlastet werden. Ungeliebter Kram wird eben nur noch auf wenigen, dann sehr stark ausgelasteten und folglich langsamen Servern, gespiegelt.
-> "Main" flutscht, Eye-Candy und Spielkram tröpfelt -> der Geek strahlt, der Dau weint.
- Urban Terror (ca 700 MB)
- Alien Arena (ca. 700)
- Die kompletten Flight Gear Daten (4 GB)
lg
Erik
lg
Erik
vegastrike ~500mb
openoffice ~120mb
ut2004 demo ~275mb
quake4 ~274mb
nexuiz ~190mb
worldofpadman ~550mb
vmware ~100mb
qt-4.4.0 ~100mb
.
.
.
Ich wünsche debian viel Spaß.
und nein, 'kleinhacken' bringt es nicht. Siehe wesnoth. Was hat man davon, daß man 'nur' 13 mb installieren braucht, wenn dan überhaupt nichts dabei ist? Installiert man das nötigste dazu ist man doch wieder bei 100mb und mehr ....
lg
Erik
lg
Erik
Das stimmt so nicht.
Bei deinem Beispiel Flightgear haben z.B. flightgear und fgfs-base jeweils ein eigenes Source-Archiv. Bei einem Typo in der Manpage muss nur flightgear, aber nicht fgfs-base angefasst werden.
Die Idee nur noch einen "kleinen" Mirror betreiben zu müssen, und die großen Pakete graußen zu lassen halte ich aber für mich schlecht. Immerhin dürfte es viele lokale Mirror in Firmen und größeren WGs geben bei denen nicht immer auch das dann "Data" benötigt würde, oder nicht oft genug um ein Spiegeln als lohnen erscheinen zu lassen.
Doch. Bei mir ist es zum Beispiel bei Wesnoth der Fall.
lg
Erik
Aber unabhängig davon. Ich denke schon dass das was bringt. Bei wesnoth installier ich eigentlich nie das Musik-Paket (DL 75MB), weil ich trotz der guten Musik Quali lieber nen mp3 Player laufen habe. Auch die Kampagnen lade ich nicht nochmal runter, nachdem ich sie bei Wesnoth 0.9x mal durchgespielt habe oder nicht unbedingt spielen muss. (utbs 6MB, httt 6MB, trow 5,5MB etc etc..) Da kommt schon einiges zusammen.
Installiert habe ich wesnoth + wesnoth-data = 40MB. Macht schon was aus....
Ansonsten könnte man doch auch für "unwichtige" Pakete wie Spiele, die besonders groß sind, eine Art "apt-bittorrent-repos" anbieten. Mit den entsprechenden Checksummen auf den Hauptservern dürfte das keine so großes (sicherheits-)Problem sein, oder?
Und jetzt macht mich nicht zu sehr fertig, ich bin kein Experte, sondern nur Benutzer
Und warum nutzt man nicht mehr Informationen über die Pakete selbst und lässt dann den jew. Admin entscheiden was er in seinen Repo zur Verfügung stellt? Der eine möchte eben keine Pakete über 50Mb, dem nächsten sind bereits 20 zu viel. Einfach eine DB drüber und jeder könnte selber über die verschiedensten Features entscheiden was er anbietet: "<60mb && non-free && !maintainer=sun"
Unter Debian führt z.B. jedes noch so kleine OpenOffice-Update sofort zu einem Riesendownload. Fast jedes Paket muß praktisch neu heruntergeladen werden.
Genau das könnte man effizienter gestalten.
Was Installationen anbelangt:
Ich würde die meisten Spiele einfach weglassen, vor allem diejenigen aus dem contrib- und non-free-Zweig.
Da auf einer jugendschutzgesetzkonformen Debian-CD oder -DVD Nexuiz oder Alien Arena ohnehin nichts verloren haben, könnte man diese Spiele auch gleich von den Debian-Servern verbannen und z.B. auf die Seite der Originalautoren verweisen. Torcs hingegen wäre für mich o.k.
Wichtige Pakete wie z.B. OpenOffice gehören aber meiner persönlichen Meinung auf alle Fälle ins main-Repository.
Das ist im Bereich Paketverwaltung aber auch so ziemlich das einzige was SuSE hier besser macht
Ansonsten halte ich das Problem der Pakete nicht für elementar, sie müssen nur besser aufgeteilt werden für Updates.
"Ich würde die meisten Spiele einfach weglassen"
Grundsätzlich hast du übrigens recht, sogar normale Spiele dürfen nicht ohne Jugendprüfung auf CDs, selbst wenn es ein Mensch-ärgere-dich-nicht ist. Das ist auch so ein Problem in DE...
Bezüglich OpenOffice sehe ich das auch so, allerdings sollte es dennoch wo immer möglich zerteilt werden. Wobei ich persönlich OOo heute nicht merh als groß empfinde. Vor Jahren habe ich dabei noch die Augen verdreht wenn mal wieder eine neue OOo Version erscheint bei den Paketgrößen, aber heute passt sie noch zusammen mit hundert anderen Programmen auf einen USB Stick
Eine bessere Aufteilung bringt nichts, wenn dann statt 1 Paket eben 100 Pakete aktualisiert werden müssen. Da müsste man schon Versionsunterschiede zwischen den Teilpaketen zulassen.
Soweit ich das aktuell sehe sind ja Abhängigkeiten in der Form " => x.xxx" jetzt schon möglich, nicht sicher bin ich mir ob " => x.xxx && <= y.yyy" auch geht.
Wenn letzteres geht könnte man das ganze mit Unterversionnummern lösen.
Freilich bringt das nur dann auch etwas wenn der Bugfix nicht eh alle Pakete betrifft
Ich habe nicht behauptet, dass das technisch nicht möglich wäre.
Bei Debians openoffice.org-*-Paketen sind die Abhängigkeiten aber zum Beispiel mit "=" gekennzeichnet.
Beispiel: openoffice.org-base (2.0.4.dfsg.2-7etch5) hängt von openoffice.org-core (= 2.0.4.dfsg.2-7etch5) ab. Da kannst du nicht einfach bloß openoffice.org-core aktualisieren.
Aber Debian müsste eigentlich jetzt schon in der Lage sein das anders zu handhaben. Vielleicht ist es eher eine Frage des wollens als des könnens.
BitTorrent bietet das in vielen fällen frei haus.
http://debtorrent.alioth.debian.org/
Inkrementelle updates zu realisieren wär natürlich auch eine tolle sache bei den Paketbeschreibungen hat man das ja schon geschafft. Wird aber denk ich nicht so einfach zu machen sein.
Das fällt schon nicht so leicht, immerhin muss man dein Posting wie folgt zusammenfassen:
"Wie wär's, wenn man alles so lässt wie bisher, ABER alles ganz anders macht"? ;D
Es erscheint mir doch wesentlich leichter ein neues Repo für Große Pakete zu bauen als Differenzupdates und Bittorent zu integrieren
Schließlich würden dadurch das nur nie Differenzen zu den Paket-Dateien heruntergeladen werden müssen nicht nur die Debian-Mirrors entlastet, auch die User hätten es dann viel einfacher. Hat ja nicht jeder DSL-6000 oder sowas in der Richtung. User bei denen noch nicht mal DSL-Light (384Kbits) geht, können bei so großen Paketen doch im Grunde nur die Version sperren, die mal von CD oder DVD installiert wurde, damit man nicht bei jedem Update erneut mit 100'ten MB's an Downloads genervt wird. (Auch 'ne Möglichkeit Debian Testing mit einer lahmen ISDN-Verbindung halbwegs aktuell zu halten.)
Landet auf jedem der von mir installierten Systeme, allein schon wegen des besseren Backtrace im Krashmanager.
lg
Erik
lg
Erik
Es geht doch hier um online...oder nutzt du einen Spiegelserver offline?
lg
Erik
Der Source wird vom Anbieter runter geladen. GCC und Abhängigkeiten von den dedian servern.
Das spart doch enorm. Scahu dir mal z.B OpenArena an.
Du musst immernoch die Spielepakete holen. Und ob du nun Sourcepakete verteilt und die Daten von Debian holst oder die Sourcepakete+Datenpakete macht keinen echten Unterschied.
Zumal du heute schon von Debian Bequem den Sourcecode bekommen kannst und mit einem Kommando daraus ein Deb erstellen kannst.
Mein Beispiel -OpenArena- beträgt 275 MB.
OpenArena von der OA Homepage herunterzuladen , "Ausführbar" zu machen und zu installieren, ink nach /opt etc. verschieben sind ein paar Zeilen in der Konsole.
Für diejenigen die damit nicht vertraut sind, könnte man ein Script anbieten und somit die 275 MB auf den "Hausservern" einsparen.
Zur Zeit sieht es so aus : OA 703 KB, OA-data 271 MB, OA-Server 345 Kb.
Das könnte man komplett einsparen.
Mir leuchtet nicht ein, wiso ein neues Repositorium mehr bringen soll als ein weiterer Mirror.
Ein Torrent/FTP Hybrid als data.debian.org würde wenigstens das Problem der fehlenden Resourcen entschärfen. Dies würde aber eine Erweiterung von apt um das Torrent-Protokoll erfordern.
Geht es um Speicherplatz?
Der kostet relativ wenig und muss nur einmal angeschafft werden.
Geht es um Bandbreite?
Hier sehe ich das Problem.
Zur Zeit muss ein !komplettes! Packet (z.B. dataxyz-1) nach jeder Änderung heruntergeladen werden.
Nehmen wir an, in dataxyz-1, sagen wir 500MB gross, ändert sich ein Byte. Schon wird die Version -2 von -
sagen wir 100.000 - Nutzer heruntergeladen. Das macht eben 50.000 GByte! Da entstehen u.U. enorme Kosten.
Ein vernünftiges Diff/Patch System für Packetänderungen sollte speziell bei den Packeten, die hauptsächlich Daten enthalten,
die Bandbreite um einen großen Faktor vermindern (1.000, 10.000 oder noch mehr).
Damit würde ein upgrade oder dist-upgrade für den durchschnittlichen DSL Besitzer außerdem noch wesentlich schneller vonstatten gehen.
Habe ich etwas übersehen?
Schade nur, dass debdelta-upgrade nicht per default mit apt-get oder aptitude funktioniert bzw. dort funktionell implementiert ist.
Wahrscheinlich kommen die debdeltas mit einiger Verzögerung rein (Stunden oder Tage?).
Kommt also irgendwie für mich nicht in Frage...
Man solle das mit bittorrent mal vorantreiben, ja. Wär ja nicht so, dass es das nicht geben würde.
http://debtorrent.alioth.debian.org/
Gesendet von catdog2 am Di, 27. Mai um 13:57
Die gibts bereits: http://debtorrent.alioth.debian.org/
... erst lesen ... :/
Es hat wirklich Sinn in Zeiten von Energiemangel und aehnlichem mal daran zu denken, dass nicht jede Distro alles extra verpacken muss.
lg
Erik
Die könnte man dann z.B. zum Verkauf anbieten, um das Debian-Projekt mehr zu unterstützen.
Man muß das aber wirklich nicht alles auf die Server legen.
Vielleicht pflegt Debian inzwischen wirklich zuviele Pakete.
Ideal wären doch z.B. vier Installations-CDs (Gnome-, KDE-, XFce- und Server-CD ohne GUI), dazu eine sinnvolle Anzahl von Paketen auf den Servern zum "Nachladen", ohne Spiele und auch ohne Bücher und Sammlungen wie Openclipart.
Es liegt aber auch an den Benutzern.
Wenn man mehrere Desktops oder Server aufsetzen möchte bzw. muß und die betreffenden Mega-Pakete schon einmal heruntergeladen hat, dann kann man die meisten davon nach der Basisinstallation doch in /var/cache/apt/archives hineinkopieren und so beim Weiterinstallieren oder Aktualisieren der Basisinstallation beträchtlich Bandbreite sparen.
Und:
Von wem werden denn die großen Spielepakete gezogen, wenn nicht fast ausschließlich von Privatnutzern?
Und dann möchtest Du noch zwei verschiedene Pakete (ein "Vollpaket" und ein "Downloadpaket") für die Daten einer bestimmten Anwendung?
lg
Erik
1. Alle Debian-Pakete auf zig CDs und zig DVDs. Dieses Paket-Sammelsurium sollte man z.B. kaufen können, aber nicht zum Download anbieten.
(nur meine persönliche Meinung)
2. Download-CDs (s.o.) und Download-Pakete auf den Debian-Servern, um die entsprechenden Desktop- bzw. Serverumgebungen vervollständigen zu können. Dazu zählen bestimmt nicht Spiele (ebenfalls nur meine persönliche Meinung).
3. Es gäbe dann also immer nur ein Debian-Paket, aber es würden sich nicht mehr alle auf den Debian-Servern befinden.
Vielleicht sollte man auch darüber nachdenken, generell z.B. ohne Spiele zu veröffentlichen.
4. Denke vielleicht auch einmal an Marillats Debian-Multimedia-Repository: Das gibt es ja auch nicht auf den Debian-Servern. Ähnlich könnte man ein Debian-Games-Repository einrichten.
Der Haken:
Auch Marillat (als Beispiel) hat ziemliche Kostenprobleme wegen des zu hohen Bandbreitenverbrauchs:
http://www.debian-multimedia.org/
"I think you have noticed the Google Ads. I need that to pay the huge amount of bandwidth."
http://www.debian-multimedia.org/statistics.php
Ein solches Problem wird sich vielleicht über die stetig zunehmenden Kosten "lösen" lassen: Vielleicht gibt es dann irgendwann Marillats Repository nicht mehr.
Ähnliche Probleme scheint es ja auch mit "originalen" Debian-Servern zu geben.
lg
Erik
lg
Erik
Ups! Daran hatte ich nicht gedacht... Da haste Recht! Das waere in Hinsicht auf die verschiedenen Definitionen von "stabil" "obsolete" (BTW, was waere die deutsche Verison von obsolete?) der Distors ja unmoeglich...
Man daenke nur mal an die Distros die XMMS rausgeschmissen haben!
"Ich wiederhole gern meine Frage von weiter oben: Wie will man damit eine sinnvolle Offline-Installation erzeugen?"
Na ja, vielleicht dadurch, dass man die .tar.gz wo z.Bsp. die Icons, Bilder, wasauchimmer sind auch auf die DVDs packt - Ich weiss, ist ein bisschen umstaendlich...
Eine andere Idee waeren z.Bsp. komplexe jigdo (oder wasauchimmer) Skripte zu basteln die dann eine komplette offline DVD (Blue Ray?
) Version basteln mit vielen Dingen die man auf nem offline Rechner mal nicht eben so runterladen kann.
Ich weiß halt nicht, ob das ein Problem löst, welches wirklich existent ist. Die architekturunabhängigen Datenpakete auslagern, Upgrades über Deltas... damit sollte man ein System haben, was sowohl auf Bandbreite als auch auf Serverplatz hinreichend optimiert wäre.
lg
Erik
Auch das keine Firma (primär) dahinter ist, ist gut (Support kostet ja was)
Aber - debian ist GRAUENHAFT.
- Der sklavische Hang zum FHS, der Zwang alles und jedes in +1000 Pakete zu zerteilen,
unglaublich langsam (ratet mal wie Ubuntu populär werden konnte. Ja, weil Debian SAULANGSAM IST),
der Zwang alles und jedes zu Tode zu patchen, die Entwickler davon aber nicht immer informieren und
durch das Patchen manchmal Fehler reinbauen.
Ich habe damit kein Problem, ich verwende kein debian. Die community ist auch recht freundlich,
das muss man zugute halten. Aber es muss einmal gesagt werden, das es bessere Alternativen zu den
grossen und alten Distributionen gibt.
Denke bitte einmal an die äußerst effizient ausgestalteten kde-core- und gnome-core-Pakete (ideal für ältere Rechner).
Oder an die Nutzer, die mit k3b unter Gnome brennen wollen.
Dank der "Zerteilung" entgehst Du der Installation vieler unnötiger KDE-Pakete und -Bibliotheken, so wie das z.B. unter OpenSuse der Fall ist.
In dieser Hinsicht macht das Aufsplitten sehr viel Sinn.
...community ist auch recht freundlich...
Du hast doch keine Ahnung von Debian, und wolltest einfach nur etwas schreiben. Nicht wahr?
>Aber - debian ist GRAUENHAFT.
und ich finde Debian einfach genial!
-J
Komisch... als ich damals auf 'nem PII mit 64 MB RAM alles von SuSE ueber *buntu probierte (ich glaube Gentoo, Slack + Derivate und LFS waren die einzigen die nicht das Vergnuegen hatten) und dann auf Sarge umstieg war alles vieeeeeeeeeeel schneller. Eben weil Debian nicht versucht hat beim Start bluetooth zu laden und auf 'nem offline Rechner die Zeit zu synchronisieren. Ich glaube auch du hast keine Ahnung.
OK, Etch war ein bisschen Traege wegen dem Umstieg auf x.org, aber Lenny war dann wieder viel schneller.
Richtig schnell war dieses System wohl nur bis einschließlich Debian Woody.
bis Firefox da war, oder um die 10s fuer Konqueror, aber das eigentliche
arbeiten war damit fluessig. Aber damals nutzte ich progs wie Xnc, dillo, usw.
Der Rechner ist jetzt noch bei meinen Eltern, hat Etch aber mit 256 MB RAM.
Aber ich wollte damit sagen, dass Debian da viel schneller war als *buntu oder die
rpm distros, eben weil es nicht jeden Stuss laden wollte. Also ist der Komentar
dass Debian langsam waere foellig unwahr!