Background Diskussionen über eine neues aptosid.de Release. Namen:
- aptode als ein Arbeitstitel
- AptosidDE ist zu schräg
- "de" kommt aus Deutschland und beginnt wie Debian
- aptode hört sich langsamer und einfacher an als aptosid
Die Langsamkeit ist, was wir anstreben: Debian sid soll attraktiver und einfacher werden für Debian Einsteiger!
Deswegen machen wir einfach ein neues Release, was zwischen den Stühlen sid und testing Bestand haben wird.
Wir machen ein Repository, was hauptsächlich aus Metapaketen besteht, die die normalen Debian sid Pakete holen, die von einigen von uns als Frontrunner (Man kann auch sagen Frontschweine) ein paar Tage lang getestet sind.
Dieses "aptode" Release Repo muss von Geniessern unseres "easy" Debian sid mit erhöhter Priorität konfiguriert werden. Wenn wir zB die slh kernel mit unseren Metapaketen anbieten, werden Aptode Geniesser nicht jeden Tag einen neuen Kernel per DU upgraden müssen, weil wir ihn sowieso 4,5 Tage testen. Käme in dieser Zeit ein neuer slh Kernel würden wir wiederum diesen testen und das Kernel upgrade verzögerte sich. Im Endeffekt hätten Aptode Geniesser viel weniger DU Upgrade Orgien zu erleiden. Und sie würden nie ein udev Paket erleben, dass ihren Pc unbootbar macht.
Die Diskussionen in den aptosid.de Foren werden kaum mehr im Teil "Upgrade Warnungen" stattfinden.
[Edit] Titel ergänzt
[Edit] Einleitung geändert hinsichtlich der allgemeiner gewordenen Diskussion
Nur kurz, weil spät ;)
mir geisterte der name "DebSid" im Kopf rum.
Quote from: "reddark"Nur kurz, weil spät ;)
mir geisterte der name "DebSid" im Kopf rum.
"Sideb" würde das ganze noch um einen Buchstaben kürzen. :wink: Wäre auch sid und deb mit drin.
Wir würden vielleicht neben einem Metapaket
sideb-kernel-slh auch
sideb-kernel-bfs und
sideb-kernel-rtbrummer
haben wollen? Ich bin kein Artworker eher ein Autworker, zu den ästhetischen Fragen äußere ich mich nicht, was nicht heißt, dass ich sie unwichtig einschätze.
Äh, wobei Namensäthetik:
sideb-kernel
debsid-kernel
aptode-kernel
da finde ich aptode nicht das schlechteste, wenn man es englisch ausspricht!
Na zu rtbrummer kann ich nur sagen: natürlich möchte ich das. :D
@ralul: nenn den thread doch einfach "Namensfindung" sonst wird das noch so viel ;)
@reddark, nee - mein Hauptanliegen ist die Diskussion, wie wir ein Einsteiger freundlicheres Debian sid bauen können! Das mit dem Namen läuft jetzt natürlich nebenher, weil ich davon angefangen habe ...
ok ;)
aba war dafür nich devils thread gedacht ;)
Quote from: "ralul"da finde ich aptode nicht das schlechteste, wenn man es englisch ausspricht!
Das stimmt. Ich persönlich fände sideb insofern nicht schlecht da es deb und sid mit beinhaltet und auch ne Distanz zu aptosid wäre.
Quote from: "reddark"war dafür nich devils thread gedacht ;)
Dort habe ich meinen Plan für ein "easy" Debian sid auch zuerst angesprochen. In dem Gefecht über proprietär ging es unter. Die Frage von Proprietärer Software wird tendenziell eher unwichtiger werden ...
Hallo,
der Bezug zu Debian muss ja nicht im Namen eingebaut werden. Viele Derivate haben vom Namen her gar keinen erkennbaren Bezug zur jeweiligen Herkunftsdistribution.
Meine Vorschläge
Rolling-Linux
App-to-Date
Viele Grüße,
Holger
Quote from: "ralul"Deswegen machen wir einfach ein neues Release, was zwischen den Stühlen sid und testing Bestand haben wird.
Warum nicht Debian in ihren CUT Bemühungen unterstützen. Ob du nun sid als Basis nimmst und zurück hälst oder testing als Basis und vorziehst macht nicht so den Unterschied. Vor allem hat man alle sid Nutzer als Tester, deren Zahl sehr viel größer sein wird als auch jede noch so große Zahl an aptode/debsid/sideb-Testern. 30.000 Pakete wird man kaum "alleine" testen können...
Und fürs Protokoll: Ein Repo zwischen testing und unstable zu schalten wie auch Mint das gerade eben mit ihrer Debian-Version versucht geht nur wenn man unstable entsprechend spiegelt. Mit ein paar Metapaketen (Depends: foo (= bar)) oder Pinning ist da nichts zu reißen - das geht schneller in die Hose als du unstable sagen kannst...
Zum restlichen Thema möchte ich mein Lieblingswort anbringen: "Eierlegende Wollmilchsau"
Wer non-free nicht zur Not von Hand an die sources.list drankleistern kann hat in unstable nichts verloren - Punkt aus. Das ist nicht weil man so ein elitärer Club sein möchte, sondern einfach weils dem Nutzer keinen Spaß machen wird. Da gibts immer mal was was nicht funktioniert und wo man basteln darf -- wenn der Nutzer sowas aber haßt dann wirds ihm nicht gefallen...
Wie wärs also mal wenn man (realistisch) die "Target-Audiance" definiert und sich dann umsieht, was es schon gibt. Den Distros zwischen unstable und testing gibts genug - und z.B. mit Ubuntu wirds wohl keiner aufnehmen wollen...
Da ich nur Betrachter des Ganzen bin und somit emotional nicht tief drinne hänge, dann kann ich nur empfehlen, erst mal ein Produkt zu erstellen, bevor es "verkauft" wird. Es wirkt sonst irgendwie ...ähmmm...komisch (und das ist noch höchst freundlich ausgedrückt).
andersrum wird ein schuh draus:
erst mal ein schlüssiges konzept, dann ist das produkt nicht so schwer.
wenn man dann nicht bis zum schlüssigen konzept kommt, kann man immer ohne probleme das projekt beerdigen.
greetz
devil
Devil, ich spreche nicht vom Konzept, sondern von der vorzeitigen Suche nach einem Namen für noch nichts vorhandenes.
wie ich im eigentlichen thread schon sagte: alles hat aussenwirkung, auch solche threads. das sollte man immer im hinterkopf haben.
greetz
devil
Ich denke, man sollte einen Namen wählen, der eingänglicher ist. Alle Kombinationen aus apt, sid und deb klingen - unverändert - irgendwie holprig.
Hallo,
den schlechtesten Vorschlag finde ich sideb:
Etwas anders ausgesprochen wird daraus Sie DEPP!
Spontan evtl. getsid.
Grüße
hschn
Quote from: "DonKult"
Wie wärs also mal wenn man (realistisch) die "Target-Audiance" definiert und sich dann umsieht, was es schon gibt. Den Distros zwischen unstable und testing gibts genug - und z.B. mit Ubuntu wirds wohl keiner aufnehmen wollen...
+1
Ich finde auch, wir sollten erstmal eine Zielgruppe für das Vorhaben definieren und anschließend nach einem Namen dafür suchen. Der Name spielt meines Erachtens im Vorfeld nicht so eine große Rolle. Wenn wir wissen, wer die Distro evtl. nutzen wird, können wir uns Gedanken über deren Ausrichtung machen (siehe anderer Threat bzgl. non-free). Schließlich müssen wir ja wissen, warum ein Nutzer gerade diese Distribution installieren soll. Da ist der Name erstmal Nebensache. Aber:
QuoteAlle Kombinationen aus apt, sid und deb klingen - unverändert - irgendwie holprig.
selbst die beste Distri würde mich mit einem komischen Namen erstmal abschrecken :wink:
Grüße
Quote from: "antitainer"selbst die beste Distri würde mich mit einem komischen Namen erstmal abschrecken :wink:
Analog zu einem verhunzten Artwork, ja.
Ansonsten stimme ich Dir zu, die Frage nach dem Namen sollte am Ende geklärt werden.
Ich finde die Idee mit den Prio Repos und Meta-Paketen wirklich gut, da sie d-u Probleme gewaltig einschränken kann und tägliche Orgien verhindert. Hier kann man den Schwerpunkt auf einige wenige Themen setzen damit die Arbeit nicht überhand nimmt. Dazu noch ein schickes debsid-Image alle halbe Jahre und fertsch isses.
Ich habe diesen Thread aufgemacht um ein Alleinstellungsmerkmal zu diskutieren, was im devil Thread durch die proprietär,script Diskussion zu kurz kam.
Ich will mich nur engagieren, wenn wir etwas machen, was man interessierten Einsteigern auch empfehlen kann. Sprich, es sollte nicht für jeden bei jedem DU die Gefahr bestehen ein unbootbares System zu bekommen, ausser für die "Frontschweine" (siehe oben). Das ist das Alleinstellungsmerkmal, auch ganz im Sinne von devil von mir gedacht: Ganz nah an Debian sid! Man braucht nur ein paar Meta Pakete zu löschen um wieder voll auf sid zu sein.
Wenn Bedarf nach Abgrenzung zu aptosid vorhanden ist, sollten wir uns einfach wieder sidux nennen. Das würde auf aptosid.com wohl am Meisten provozieren.
Ich habe kein Provo Bedürfnis, eher eine adelig herablassende Haltung, die entgegengesetzt korrespondiert zu slh's Meinung über Benutzer. Ich könnte mir eine anfängliche Existenz als "aptode" Ergänzung zu aptosid vorstellen, die dann wachsen und wichtiger werden kann ganz natürlich im Laufe der Zeit.
Quote
Wenn Bedarf nach Abgrenzung zu aptosid vorhanden ist, sollten wir uns einfach wieder sidux nennen. Das würde auf aptosid.com wohl am Meisten provozieren.
das ist legal nicht möglich (markenname)
Quote
Sprich, es sollte nicht für jeden bei jedem DU die Gefahr bestehen ein unbootbares System zu bekommen,
kannst du mal bitte ein expose über die machbarkeit schreiben, damit man das diskutieren kann? (ausserhalb es forums, evtl. blog oder wiki)
greetz
devil
Quote from: "antitainer"Quote from: "DonKult"
Wie wärs also mal wenn man (realistisch) die "Target-Audiance" definiert und sich dann umsieht, was es schon gibt. Den Distros zwischen unstable und testing gibts genug - und z.B. mit Ubuntu wirds wohl keiner aufnehmen wollen...
+1
Ich finde auch, wir sollten erstmal eine Zielgruppe für das Vorhaben definieren
Zielgruppe bist Du und Deine Freunde, denen Du Deine Distro nahe bringen willst. Mit "Du" ist der geneigte Leser hier gemeint. Mit Ubuntu Fanboys und Mint Kiddies wird es nichts zu tun haben.
@devil,
wir sind mit meinem Vorschlang nicht genau in der Mitte zwischen sid und testing, wie viele andere Distros, sondern nur 4,5 Tage nach Debian sid. Wir sind ein "slow" Debian sid.
Wenn das genau dem Debian CUT Projekt entspricht (ich hatte es anders verstanden), wäre ich froh und stolz, wenn wir einfach eine neue Benutzer Gruppe, ein unterstützender Club für Debian CUT darstellen, der eigenes Artwork hat.
Quote from: "ralul"Mit Ubuntu Fanboys und Mint Kiddies wird es nichts zu tun haben.
Auf solche Herabwürdigungen könnte man in Zukunft ggf. verzichten.
Quote from: "ralul"wir sind mit meinem Vorschlang nicht genau in der Mitte zwischen sid und testing, wie viele andere Distros, sondern nur 4,5 Tage nach Debian sid. Wir sind ein "slow" Debian sid.
Das wird mit der hiesigen Manpower nicht umsetzbar sein. Es sei denn, man verzögert um 4,5 Tage, macht in dieser Zeit aber sonst nichts. Das ginge allenfalls für einige wenige systemimmanente Programme, aber welche Seiteneffekte das hat, müsste man auch noch sehr genau untersuchen.
Ein abgesichertes Repository zwischen sid und testing einzuführen, wo nur Pakete einfließen, die gut getestet sind und sicher installierbar sind, halte ich, ehrlich gesagt, für unrealistisch. Ist einfach zu aufwändig.
Man sollte sich IMHO eher überlegen, wie man den Benutzer auf Client-Seite besser schützen kann. Eine Vorgehensweise, die ich praktiziere: Man hat mindestens zwei Systempartitionen. Eine ist eine Fallback-Installation. Die Fallback-Installation aktualisiere ich nur, wenn die Hauptinstallation nach upgrade ein paar Tage lang gut lief. Damit habe ich quasi eine Rolling Installation und eine etwas besser abgehangene Stepping-Distribution.
So etwas müsste man dem Endbenutzer automatisch an den Mann bringen. Es werden zwei Systempartitionen eingerichtet. Die eine kann er regelmäßig upgraden. Die andere nur, wenn er sich sicher ist, dass alles läuft, als Kopie (rsync) der ersten. Theoretisch könnte man auch von 2 auf mehrere Stufen gehen, um noch mehr Sicherheit zu bekommen.
Das Ganze könnte man dann "Dublex" nennen oder "Fallbax".
Quote from: "devil"QuoteSprich, es sollte nicht für jeden bei jedem DU die Gefahr bestehen ein unbootbares System zu bekommen,
kannst du mal bitte ein expose über die machbarkeit schreiben, damit man das diskutieren kann?
Ich mache einen Thread im Kernel Hacking auf:
techn Machbarkeit von aptode-sideb - Bitte nicht stören
Diese Diskussion kommt zu früh. Devil hat recht, Außenwirklung.
Wir sollten sowas intern diskutieren (siehe mein Posting in Devils thread, S.7)
Generell: Da wir alle nicht mehr 18 sind, sollten wir uns einen Namen geben, der nicht suggeriert, dass wir 16 seien ;-)
Ich schlage vor, den Geekfaktor so gering wie möglich zu halten!
ralul,
bitte nicht im forum.
lanzi, danke fürs bremsen :)
greetz
devil
Quote from: "arwa"Man sollte sich IMHO eher überlegen, wie man den Benutzer auf Client-Seite besser schützen kann. Eine Vorgehensweise, die ich praktiziere: Man hat mindestens zwei Systempartitionen. Eine ist eine Fallback-Installation. Die Fallback-Installation aktualisiere ich nur, wenn die Hauptinstallation nach upgrade ein paar Tage lang gut lief. Damit habe ich quasi eine Rolling Installation und eine etwas besser abgehangene Stepping-Distribution.
Das ist ja jetzt nicht wirklich eine Distroeigenheit, sondern etwas was man bei jeder tun kann. Soll Leute geben, die vor einem Debian stable upgrade eine Vollkopie ziehen und so wechseln könnten im Notfall... (man nennt das bisweilen auch Backup ;))
Wird im Grund aber alles recht obsolete sobald btrfs sich auf die Reihe bekommt und man es als Dateisystem gutengewissens empfehlen kann:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-update-manager-btrfs
Eine Distroeigenheit wäre es dann, wenn es die Distri automatisch so vorgibt. Natürlich kann sich der User, der es kann, selber schützen. Wenn man ihm aber Distroseitig dabei unter die Arme greifen kann, wäre das nicht uninteressant.
Anderes Beispiel: Ähnlich wie ein apt-listbugs sollte ein Check in das dist-upgrade eingeklingt werden, dass bekannte Warnungen automatisch ausgibt. Natürlich kann man auch ins Forum schauen. Wenn das aber automatisch auf den Screen gebeamt wird, wäre das komfortabler und sicherer.
btrfs: Scheint ja interessant zu werden.
Ein Wrapper für apt-get zu schreiben, ist sicher nicht das Problem. Problematisch wirds schon eher, woher man diese Warnungen dann nimmt. Aus einem Forum? Was, wenn da ein Paket angekreidet wird, dass gar nicht schädlich ist. Sollen nur Warnungen ausgegeben werden, die vom "Team" approved sind? Was dann in diesem Fall, wenn das Team nicht schnell genug ist?
Ich meine, dass diese Diskussion schon zu sidux-Zeiten mal aktuell war und selbst dort aufgrund von Personalmangel und Organisationsschwierigkeiten verworfen wurde.
Und auch vor Klärung dieser Fragestellung sollte man sich einig sein: Wen will man erreichen? Soll eine eine einsteigerfreundliche Distro werden oder beabsichtigt man ein Derivat, bei dem sich die Leute weitestgehend selbst vor selbsteingeladenen Unfällen via apt-get schützen können? Wenn man die erstere Zielgruppe bedienen möchte, ist sid meiner Meinung nach die falsche Grundlage oder verkompliziert das ganze zumindestens unnötig.
Genau meine Meinung Steve. Sid bleibt immer Sid und kann man auch nicht so absichern, daß Einsteiger ohne Plan damit zurecht kommen.
100%ig wasserdicht wird man es nicht bekommen. Aber über jeden Hinweis zu bekannten Problemen sollte man doch als Distupgrader froh sein. Schließlich wird auch empfohlen, ins Forum zu gucken, bevor man upgradet, obwohl das auch keine Sicherheit bringt, aber immerhin häufig gute Warnungen.
War aber auch nur eine Idee. Die Liste sollte moderiert sein. Häufig findet sich von einem Moderator im Forum eine Sticky-Meldung, dass man vielleicht besser momentan nicht upgraden solle. Solche Hinweise meine ich.
Das Einklinken in den apt-get Mechanismus scheint mir per Hook zu gehen: /etc/apt/apt.conf.d/
Quote from: "DonKult"Wird im Grund aber alles recht obsolete sobald btrfs sich auf die Reihe bekommt und man es als Dateisystem gutengewissens empfehlen kann:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-update-manager-btrfs
Dieses btrfs Feature wird, wenn es denn bald den Benutzern einfach zugänglich ist, den Rollin'Releases einen extra Schub geben!
Die Frage ist wirklich, ob meine Idee für ein "easy" Debian sid nicht in einem halben Jahr schon obsolet sein können?
Quote from: "towo"Sid bleibt immer Sid und kann man auch nicht so absichern, daß Einsteiger ohne Plan damit zurecht kommen.
Ich meine doch:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1186
Jedenfalls in viel größerem Maß als bisher verwirklicht. Das Schöne daran ist, das dies sogar Aufwand auf allen Seiten erspart: Wenn die Leute, die hier mit viel Liebe und Geduld immer dieselben Leiden heilen, nur die Hälfte der dafür nötigen Zeit in das Projekt "easy" Debian sid stecken!
Bitte hier die Meinung, dort im Thread die technischen Aspekte!