Siduction Forum
Siduction Forum => Scripting & Kernelhacking => Topic started by: ralul on 2011/07/24, 12:54:45
-
Bitte hier nicht mit reinen Gut,schlecht-find Meinungen stören!
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?
1. Es sollte einen DU Modus für Einsteiger oder Benutzer, die nicht tief technisch interessiert sind, geben, der ein bootbares System weiterhin garantiert.
2. Dieser Benutzerkreis kann es verkraften Paketversionen, die veraltet sind, auch eine Woche länger zu fahren. Sie benutzen jedoch kein Debian stable oder testing, weil sie eine Verspätung aktueller Software von 5-20 Monaten nicht akzeptieren.
3. Wenn wir die zB die ubuntu "unattended Upgrades" Technik verwenden um eigene Hooks einzubauen, die ungefähr wöchentliche Updates garantieren könnten, hätte unsere Distro genau das, was viele suchen (Alleinstellungsmerkmal).
4. Metapakete können ins Leere zielen, sprich Installationen und Upgrades eine zeitlang nicht möglich sein, weil wir "Frontschweine" noch keine sauberen Versionen vorgefunden haben. Dies ist für einen Benutzerkreis im Modus "easy" aber eine zeitlang akzeptabel und entspricht vollkommen den jetzigen "Upgrade Warnings" momentan das System nicht anzufassen. Durch den Einsatz von Metapaketen braucht dieser Benutzerkreis aber das Forum "Upgrade Warnings" nicht zu lesen. Der "easy" Benutzerkreis merkt nach einer Woche nur, dass immer noch keine Pakete aktualisiert wurden (Wenn derjenige sich dafür interessierend in die "About" Infos schaut).
5. Die Schwierigkeit, der Drawback:
In einer Phase, in der DUs ausgelassen werden, harmoniert die installierte Systembasis des Benutzers nicht mehr mit den Debian sid Repos. Dies wird besonders in solchen Phasen vorkommen, in denen Debian sid strukturell stark vorbereitet wird für das nächste Release, was man bei openSUSE Milestones nennt (dies war jetzt gerade passiert mit Debian). Dadurch kann es vorkommen, dass der Benutzer neue Software eine Zeitlang nicht erfolgreich installieren kann. Wir könnten für solche Phasen erklärende Meldungen vorhalten, die erscheinen.
6. Der 5. "Drawback" Punkt ist verhinderbar durch eigene gefixte Pakete. Dies ist also auch eine Frage der Entwicklung unseres Engagements und Könnens.
-
Die Lösung des DU Problems sehe ich als essentiell. Die Herausgabe einer Live Distibution mit eigener Artwork ohne diesen Punkt anzugehen, wäre für mich ohne tieferen Sinn.
Alle anderen Punkte sind schon jetzt sehr schnell verwirklichbar:
- für Artwork gibt es bei uns Könner
- Proprietär Hilfen wurden hier auch schon angeboten (towo, agaida)
- eine eigene Live CD haben auch schon einige von uns zusammengestellt.
- Kernel wurde schon gebacken (towo, agaida, ich mit bfs, brummer rt)
-
Zum Aufwand für uns "Frontschweine" (agaidas Bezeichnung):
- Wir könnten mit etwas Script-hacking Aufwand eine Server Funktion basteln, die unsere eigenen privaten Booterfolge mit neuen Software Versionen sammelt.
- Wenn eine festgelegte Anzahl von Reboots einer festgelegten Anzahl von uns "Frontschweinen" stattgefunden hat, kann automatisch ein aktualisiertes Metapaket erstellt und freigegeben werden. Wenn von uns nicht einer händisch auf dem Server "stop" gesagt hat ...
Zum Sinn eines neuen Release Namens mit erhöhter Priorität:
- Ein "aptode" oder "sideb" in der Herkunftsanzeige von Paketen (unter aptitude ist dies konfigurierbar) erhöht die Transparenz unseres Tuns und des Unterschieds zu reinem Debian sid
- aptosid.com benennt seine Pakete mit "aptosid" im Versionsstring
- Grundsätzlich wäre die vorgeschlagene Technik DUs über Metapakete zu steuern auch ohne erhöhte Prioritätssetzungen (apt/preferences) und damit auch ohne einen zusätzlichen "aptode" Release Namen möglich.
Warum sollte man apt Steuerungstechniken, die alles transparenter machen können, nicht einsetzen? DonKult ist hier gefragt, ob es Nachteile eines solchen Vorgehens geben mag.
-
irgendwas davon technisch bei dir schon umgesetzt?
greetz
devil
-
Ich bin kein Debian Paketier Spezialist, ich sehe mich eher beim Kernel patchen. Meine Erfahrungen mit Paketabhängigkeiten in aufsteigender Schwierigkeit:
- Debian Release Wechsel sid zu testing und zurück (geht manchmal)
- Ubuntu Wechsel kubuntu-xubuntu per Metapaketen
- openSUSE Release Wechsel (zypper)
- Ubuntu Release Wechsel (aptitude)
- Gentoo mit nicht offiziellem gcc-4.6 erfordert eigenes Repo
-
Warum sollte man apt Steuerungstechniken, die alles transparenter machen können, nicht einsetzen? DonKult ist hier gefragt, ob es Nachteile eines solchen Vorgehens geben mag.
Eigentlich muss ja jeder selber erstmal auf die Nase fallen und eigentlich hab ich das ja sogar schon im alten Thread erwähnt, aber weil mein Name da steht und sonst noch wer auf die Idee kommt ich hätte damit was zutun, bitte:
Wie soll das den aussehen:
Metapaket easy-upgrade Depends: udev ( = x.y-z), kernel ( = x.y-z), …
oder wie? Wenn dem so ist, ist das schon Käse: Die einfachste Lösung wenn dann udev x.y-z+b1 rauskommt ist dann nämlich für den Paketmanager das Metapaket easy-upgrade zu entfernen und udev zu upgraden. Macht auch am meisten Sinn…
Ich spiele gerade mit einem n810 herum, bei dem genau diese technik für Distroupgrades verwendet wurde. ARGH!! Kann ich da nur sagen, das hagt hinten und vorne und da liegt das Repo unter vollständiger Kontrolle von Nokia… nicht wie unstable mit einem nie enden wollendem Fluss an neuen Versionen (mit neuen Bugs und Fixes, möglichst mehr letzteres als ersteres).
Unattended Upgrades ist für unstable auch eine eher schwer vorstellbare Idee… Vor allem wenn du nur bestimmte Pakete so upgraden willst. Ich kann nur immer mein Lieblings-Squeeze Beispiel nennen: udev upgrade erfordert upgrade auf KDE4. Ein Nutzer freut sich sicher wenn das KDE3 auf KDE4 Upgrade plötzlich nach einem Reboot vollzogen ist ohne das er vorher was davon wusste. Das kann man weniger drastisch auf jede größere Veränderung ausweiten. Xorg -> hal -> udev -> Xorg Konfiguration von Tastaturen und Co z.B. … oder auch nur iceweasel 8 -> 9 (vor allem weil für den ja auch ein iceweasel restart zwingend nötig ist).
Und schlussendlich: Nur weil die Kiste bootet heißt noch lange nicht, dass deine Nutzer vor dem gröbsten beschützt sind. Vor allem weil auch nicht jeder Nutzer das selbe braucht um zu booten. Man nehme nur verschlüsselt vs. unverschlüsselte Partition. Raid vs kein, LVM vs kein, ……………
(daher wird die Erstellung von diesen ominösen Metapaketen auch nochmal so lustig, Nokia untersützt mit n810 nur ein genau definiertes Target-Device, wie ist das hier?)
Wenns einsteigerfreundlich sein soll, dann sollte WLan noch funktionieren (viel Spaß beim auftreiben aller Hardware zum testen), der Browser natürlich auch (alle bitte, gibt ja Auswahl, da müssen die größten schon drin sein) und was macht man eigentlich wenn meinetwegen AMD mal Wochenlang aus der Linux-Treiberentwicklung für ihre Grafikkarten aussteigt - Kernel einfrieren und beten oder AMD-User im Regen stehen lassen. (AMD ist jetzt extrem, genausogut kann man irgendwas anderes nehmen: z.B. ein schwer zu findenden Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?(geschieht gerade mit APT auf sparc, hatten wir aber auch schon auf amd64 und allen anderen Architekturen… Man kann niemals jede Plattform mit allen Konfigurationen testen)
So, und mit der Abhandlung bin ich raus. Gern kann man mir spezifische Fragen stellen, ich werde das sicher beiläufig beobachten und eventuell mal meinen Senf abgeben wenns (nicht) passt, aber entgeltfreier Unternehmensberater für ein "not-yet-defined" werde ich sicher nicht, ich hab für den Job schon bei Debian "unterschrieben".
(und weil ralul mal gefragt hast: DD bin ich nicht - hab mich bisher nicht beworben - Titel ändern ja an der Arbeit nix)
-
@DonKult, die konkrete kleine Frage war eigentlich nur:
Sind konkrete Nachteile zu erwarten, wenn man ein apt Paketsystem dauerhaft mit zwei verschiedenen Releases fährt in unterschiedlichen Prioritäten?
Ich habe genau dies schon gemacht, wechselnd mit testing versus sid und keine nachteiligen Auswirkungen gespürt. Mit openSUSE und seinen spezial obs-Buildverzeichnissen sind verschiedene Prioritäten mein täglich Brot.
Deine verschiedenen Äusserungen zu meinem Plan animieren mich zu Konkretisierungen:
Metapaket easy-upgrade Depends: udev ( = x.y-z), kernel ( = x.y-z), …
oder wie? Wenn dem so ist, ist das schon Käse: Die einfachste Lösung wenn dann udev x.y-z+b1 rauskommt ist dann nämlich für den Paketmanager das Metapaket easy-upgrade zu entfernen und udev zu upgraden. Macht auch am meisten Sinn…
Das Metapaket ist ja gewollt, manuell (aptitude) und vom priorisierten "aptode-sideb" Release. Das udev Paket ist nicht gewollt, sondern nur automatisiert durch das Metapaket per Abhängigkeit reingezogen: Was ist das für ein Paketmanagement, dass mir ein nicht gewolltes udev auf Kosten des gewollten und höher priorisierten Metapaketes upgraded?
Kann doch nicht sein, ist das Dein apt?
Ich spiele gerade mit einem n810 herum, bei dem genau diese technik für Distroupgrades verwendet wurde. ARGH!! Kann ich da nur sagen, das hagt hinten und vorne und da liegt das Repo unter vollständiger Kontrolle von Nokia
Genau, Genießer unseres "easy" Debian sid stehen vollkommen unter der _Kontrolle_ des "aptode-sideb" Release Teams. Außer sie deinstallieren unsere Metapakete.
Unattended Upgrades ist für unstable auch eine eher schwer vorstellbare Idee… Vor allem wenn du nur bestimmte Pakete so upgraden willst.
Die bestimmten Pakete des Release Teams sollen automatisch upgegraded werden und alle sonstigen Pakete des Nutzers, wenn sich mit "apt-get dist-upgrade --simulate" kein Fehlerlevel ergibt. Bei einem Errorlevel wird der Nutzer benachrichtigt werden müssen, dass das Release Team Mist gebaut hat und nun manuell eingegriffen werden muss. Dann ist im Supportforum eine Aufgabe vorhanden!
Ich kann nur immer mein Lieblings-Squeeze Beispiel nennen: udev upgrade erfordert upgrade auf KDE4. Ein Nutzer freut sich sicher wenn das KDE3 auf KDE4 Upgrade plötzlich nach einem Reboot vollzogen ist ohne das er vorher was davon wusste.
Man kann im Supportforum solch wichtige Änderungen vorher ankündigen. Vielleicht finden wir eine Technik, die automatische dist-upgrades vorübergehend ausstellen kann:
Ein dummy Paket, was als Flag missbraucht werden kann:
Dummy-1.gruen
Dummy-2.rot
Und schlussendlich: Nur weil die Kiste bootet heißt noch lange nicht, dass deine Nutzer vor dem gröbsten beschützt sind. Vor allem weil auch nicht jeder Nutzer das selbe braucht um zu booten. Man nehme nur verschlüsselt vs. unverschlüsselte Partition. Raid vs kein, LVM vs kein, ……………
LVM Nutzer sind keine Einsteiger oder sonstwie "easy" Debian sid Kandidaten. Im Gegenteil ist LVM für mich ein Tag für ein richtiges "Frontschwein" im Release Team.
Wenns einsteigerfreundlich sein soll, dann sollte WLan noch funktionieren
So etwas muss weiterhin wie bisher "manuell" im Forum supportet werden.
AMD mal Wochenlang aus der Linux-Treiberentwicklung für ihre Grafikkarten aussteigt - Kernel einfrieren und beten
Kernel einfrieren und beten, dass nouveau und gallium bald perfekt sind. Es gibt schon erstaunliche aber seltene Teilergebnisse auf openbenchmarking.org
Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?
Ich möchte nur amd64 unterstützen! Der wichtigste Grund neben Faulheit ist, dass genau i386 von Debian Entwicklern immer seltener getestet wird. Durch das Multiarch, was Du mir so schön erklärt hattest, können 32bit Aufgaben bald perfekt gelöst werden. Für uralte Computer ist das aktuelle Debian sowieso nicht mehr geeignet. Die werden mit Puppy bestückt.
PS: Irgendwie komisch. Ich komme mir vor, als ob ich DonKult erklären müsste, wieviel sich mit seinem apt Paketsystem erreichen lässt.
-
Ich möchte nur amd64 unterstützen!
:evil: :evil: :evil:
x86 x86 x86 x86 x86 x86 x86 x86 x86 x86
-
Sind konkrete Nachteile zu erwarten, wenn man ein apt Paketsystem dauerhaft mit zwei verschiedenen Releases fährt in unterschiedlichen Prioritäten?
Macht natürlich keine Sorgen -- viele haben die wildesten Mixe aus testing/unstable/experimental, aber ganz brav stable und stable-backports ist der selbe Fall -- allerdings muss man es dafür auch konfigurieren. UND auch wenn man mehrere Quellen hat: Eine Quelle ist die Hauptquelle, wenn man Pakete aus einer anderen haben will muss für gewöhnlich Handangelegt werden: apt-get install foo/barrelease
Das passt dir natürlich nicht ins Gehege, weil man sich dann z.B. auf testing als Hauptquelle festlegt, aber nicht "mit Metapaketen" aus unstable andere Sachen automatisch "hochziehen" kann. Genausowenig wie man Hauptquelle unstable nehmen kann und "Metapakete" aus der selben (naja, eigentlich aus einer ganz anderen Quelle) dann die Installation von anderen Versionen verhindern.
Mehrere Quellen machen von einem Automatismus her gesehen nur dann Sinn, wenn in der Hauptquelle das Paket selbst nicht vorhanden ist.
Was ist das für ein Paketmanagement, dass mir ein nicht gewolltes udev auf Kosten des gewollten und höher priorisierten Metapaketes upgraded?
Ein vollkommen normales, weil dein Metapaket quasi überhaupt keine reverse Dependendencies hat während von udev Gott und die Welt abhängt. Da ist die einzig logische Entscheidung das "veraltete" Metapaket zu entfernen statt den globalen Fortschritt mit udev aufzuhalten… Man macht schließlich ein dist-upgrade… Eine Depends = x.y-z (ja mit Debian-revision z, was in Debian sehr unüblich ist - aber für deine Zwecke unabdingbar wäre) ist sehr schnell veraltet, ich kann mir kaum vorstellen, dass du ein Grundsystem (mal davon abgesehen, dass man das mal definieren müsste) zusammenstellen kannst und dieses Metapaket erstellen kannst was dann auch nur die Hälfte des Jahres überhaupt installierbar wäre……
Schon alleine weil nicht jede deiner "sicheren" Versionen testing erreichen werden - verschwinden also mit dem erscheinen einer neuen Version direkt.
Und schlussendlich: Nur weil die Kiste bootet heißt noch lange nicht, dass deine Nutzer vor dem gröbsten beschützt sind. Vor allem weil auch nicht jeder Nutzer das selbe braucht um zu booten. Man nehme nur verschlüsselt vs. unverschlüsselte Partition. Raid vs kein, LVM vs kein, ……………
LVM Nutzer sind keine Einsteiger oder sonstwie "easy" Debian sid Kandidaten. Im Gegenteil ist LVM für mich ein Tag für ein richtiges "Frontschwein" im Release Team.
Wie kommst du auf die Idee? Die Festplatte verschlüssen kann heute jeder, viele Installer bieten dazu eine mehr oder minder einfach Option an. Dafür muss man kein Experte sein. Das machen selbst Leute auf Windows, warum muss ich als Umsteiger direkt in die Expertenschiene wechseln? Und für Raids und LVM sicher auch nicht, man wird ja auch nicht zum Experte von Debian dadurch. Die ganze Hardwareschiene der Argumentation hast du ja freundlichst ignoriert: Die kommt ja noch oben darauf…
Bug auf i386 der auf amd64 (und allen anderen Archs) nicht Auftitt?
Ich möchte nur amd64 unterstützen!
Ne, so wie du dich anhörst möchtest du nur die Architekturen: raluls-laptop und raluls-desktoppc untersützten. Dann könnte(!) das sogar klappen, meine Behauptung ist nur, dass das nicht hoch skaliert auf komplett "amd64" (mal von abgesehen, dass das die Beschränkung zu diesem Zeitpunkt auch ein wenig Käse ist, aber egal).
PS: Irgendwie komisch. Ich komme mir vor, als ob ich DonKult erklären müsste, wieviel sich mit seinem apt Paketsystem erreichen lässt.
P.S. Es ist nicht "mir", damit fangen wir mal gar nicht erst an.
Doch bevor man mir Lehrstunden über das Paketmanagementsystem erteilt, sollte man besser genau wissen was man tut, sonst kommt nämlich jemand und stellt unangenehme Fragen und erbittet eine Implementierung - den am Ende ist die Realisierung das entscheidende Kriterium, nicht irgendein neunmalkluger APT-Bastler, den der kann sich irren, die Realität irrt sich aber nie.
-
Ich möchte nur amd64 unterstützen!
:evil: :evil: :evil:
x86 x86 x86 x86 x86 x86 x86 x86 x86 x86
1. das ist meine erste Vormeinung
2. amd64 Beschränkung wäre nur für die Target Audience Debian sid Einsteiger und "easy" Genießer.
Jedenfalls werde ich mit amd64 anfangen
Wenn x86 "Frontschweine" dazu kommen, könnten wir da auch noch landen ...
-
Guten Morgen,
ich weiß nicht, ob ich jetzt zu pessimistisch bin, oder einfach nur Realist, aber ...
Die Lösung des DU Problems sehe ich als essentiell.
das dist-upgrade-Problem wird sich innerhalb von Debian sid nicht lösen lassen. Debian sid ist nunmal ein sich schnell bewegendes Ziel ("heavy moving target"), das sich nicht nur in Art der Pakete, sondern jeweils auch in Architektur, Branch und Alter. Dabei ist es schlussendlich so vielfältig, dass unter Beibehaltung von apt kein Mechanismus dieser Welt die dafür notwendigen Vorgänge in Stein meißeln könnte.
"easy" und "Debian sid" passen nicht zusammen, das kann nicht funktionieren. Wenn es hoch kommt, kann man einige wenige systemimmanente Programme kurzfristig vorm Upgrade bewahren. Das wars dann aber auch schon.
ralul, Deine Umsetzungsvorschläge können meines Erachtens nur zwei Effekte haben:
a) es funktioniert nicht, oder
b) es ist am Ende kein Debian sid mehr.
Ein solches Setup wäre einfach viel zu steif, um auf die Vielzahl der Installationen passend reagieren zu können. Genauso, wie die des Nächstens diskutierte Lösung, (halb-)automatisierte Rollbacks des Systems vor einem fehlerhaften DU zu machen.
Ich kürze das nochmal ab:
Entweder, man nimmt die Eigenheiten von apt unter Debian sid in Kauf, oder sid ist die falsche Ausgangsbasis, bzw. Debian die grundsätzlich falsche Distribution für ein solches Vorhaben.
-
+1
Das hört sich für mich "ungebildeten" nach einer menge Arbeit und potentiellen Fehlerquellen an. Man sollte doch eigentlich versuchen User zum mitdenken zu erziehen.
debian/sid ist eben unstable, ich benutze seit Jahren nichts anderes und hatte nicht ein mal ein Problem.
Ich finde jeder der sid nutzt sollte lesen können und auch mal ein paar std warten können wenn das halbe System deinstalliert werden sollte. Man kann versuchen Hilfestellungen zu geben sollte aber nicht versuchen ein System zu schaffen das einem das denken abnimmt.
-
Ich merke schon, auch an der Frage von devil, ich muss es erstmal selbst mindestens beispielhaft implementieren, um Anhänger für die Idee zu finden. Wie es immer bei openSource ist, dass man nur interessieren kann, wenn man konkret etwas vorweist, und nicht nur drüber redet - DoKratie.
Eine Quelle ist die Hauptquelle, wenn man Pakete aus einer anderen haben will muss für gewöhnlich Handangelegt werden: apt-get install foo/barrelease
Das passt dir natürlich nicht ins Gehege, weil man sich dann z.B. auf testing als Hauptquelle festlegt, aber nicht "mit Metapaketen" aus unstable andere Sachen automatisch "hochziehen" kann.
Ich bezieh mich nicht auf testing, aber vom Prinzip dachte ich es sollte so funktionieren:
/etc/apt/sources.list deb http://ftp.de.debian.org/debian/ unstable main contrib non-free
deb http://ftp.aptode.org/debian/ aptode main fix easyetc/apt/preferencesPackage: *
Pin: release a=unstable
Pin-Priority: 501
Package: *
Pin: release a=aptode
Pin-Priority: 502Die Metapakete für "easy" Debian Benutzer werden aus dem Verzeichnis easy gezogen, und sind durch die erhöhte Priorität (502) geschützt? Ginge mein Plan besser mit beiden Prioritäten über tausend?
Was ist das für ein Paketmanagement...
Ein vollkommen normales, weil dein Metapaket quasi überhaupt keine reverse Dependendencies hat während von udev Gott und die Welt abhängt. Da ist die einzig logische Entscheidung das "veraltete" Metapaket zu entfernen statt den globalen Fortschritt mit udev aufzuhalten…
Dazu will ich die erhöhte Priorität des aptode-sideb Releases benutzen, reicht nicht?
So kenne ich es von openSUSE und Gentoo.
ich kann mir kaum vorstellen, dass du ein Grundsystem (mal davon abgesehen, dass man das mal definieren müsste) zusammenstellen kannst und dieses Metapaket erstellen kannst was dann auch nur die Hälfte des Jahres überhaupt installierbar wäre……
Ja, die durchgehende Installierbarkeit wäre ein Argument die Pakete selbst zu hosten, nicht nur Metapakete. Allerdings geht es bei meinem Projekt nicht um Installierbarkeit, sondern um die nachfolgende "easy" Pflege. Ich kann mir einen Button vorstellen zur Umstellung eines Systems nach der eigentlichen Installation:
"easy" einrichten.
Ne, so wie du dich anhörst möchtest du nur die Architekturen: raluls-laptop und raluls-desktoppc untersützten.
Sehr beschränkt anfangen gehört zum Plan.
-
schön wäre z.b. wen der Installer für /home eine eigene Partition anlegen würde, bzw. eine bestehende /home Partition einbinden könnte. Damit wäre ein upgrade über eine neu Installation machbar, also upgrade nur wenn eine neue CD erscheint, das wäre dann die 85%ige Sicherheit (Abteilung sorglos)
Die Arbeit für das (sorglos) Team wäre dabei sicherzustellen, das bestimmte configs, die nicht mehr funktionieren oder obsolent sind, auf die neuen Anforderungen transferiert werden, oder eben gelöscht.
Ich denke das ist eher machbar als (sorglos) zu jeder Zeit zu gewährleisten.
-
@Steve,
@Se7en11
eure Beiträge sind Meinungsäußerung. Ihr wiederholt das allgemein übliche Urteil über Debian sid, dass es nicht geht. Dieses Urteil kenne ich, also hier:
Bitte nicht stören
-
:)
-
schön wäre z.b. wen der Installer für /home eine eigene Partition anlegen würde
...
Ich denke das ist eher machbar als (sorglos) zu jeder Zeit zu gewährleisten.
So sehe ich es auch. Auf das von DonKult vorgebrachte LVM Argument gehe ich aus folgenden Gründen nicht ein:
- Btrfs wird sehr bald LVM vollkommen erledigen.
- /home als extra Partition reicht zur Verschlüsselung aus, weil es mit Hilfe von /run und seinen tmpfs Möglichkeiten genügend Schutz gibt runtime Daten zu verbergen.
Spezialisten mit besonderen LVM und Raid Ambitionen sind keine "easy" Debian sid Kandidaten.
-
installer der /home verschlüsselt fällt mir da noch auf Anhieb ein ... falls das nicht als Störung angesehen wird.
Ich weiß auch das das kein 100 % Schutz ist aber wäre trotzdem etwas wo Interesse bestehen könnte. Ubuntu macht das automatisch.
-
Hallo Ralph,
@Steve,
@Se7en11
eure Beiträge sind Meinungsäußerung. Ihr wiederholt das allgemein übliche Urteil über Debian sid, dass es nicht geht. Dieses Urteil kenne ich, also hier:
Bitte nicht stören
Das heißt also in Anlehnung an die Signatur von @se7en11:
Die Tatsachen stehen fest, bitte stört mich nicht mit Euren Meinungen ;-)
Mal ernsthaft gesagt bin ich ja immer noch dafür zu haben, das Werkzeug YaST an ein Debianderivat anzupassen. Bitte nicht schlagen, aber ich finde, YaST ist richtig gut geworden.
Falls das nicht hier zum Beitrag technische Machbarkeit passt, dann sagt es mir, ich verschiebe meinen Kommentar dann nach Freie Rede.
Viele Grüße,
Holger
-
Hier wollte ich _nur_ mein Projekt "easy" Debian sid auf technische Machbarkeit von problemlosen DUs hin diskutieren.
Die Diskussion über eine neue Distro hatte angefangen:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1136
Es werden Namen diskutiert:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1185
-
Hier wollte ich _nur_ mein Projekt "easy" Debian sid auf technische Machbarkeit von problemlosen DUs hin diskutieren.
Die Diskussion über eine neue Distro hatte angefangen:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1136
Es werden Namen diskutiert:
http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=1185
Hallo Ralph,
wenn Du hier nur Fragen zu anwendefreundlicher Aktualisierung diskutieren möchtest, dann passt der YaST Beitrag nicht. Ich werde ihn später wo anders unterbringen.
Viele Grüße,
Holger
-
Hi,
ist es nicht möglich für "easy" Debian sid ein eigenes upgrade Skript zu basteln, das erstmal eine Liste von auf "hold" zu setzende Pakete holt, diese Pakete auf "hold" setzt und danach erst das apt-get dist-upgrade ausführt? Diese Liste müsste dann quasi von den "Frontschweinen" gepflegt werden.
cu
-
Ich merke schon, auch an der Frage von devil, ich muss es erstmal selbst mindestens beispielhaft implementieren, um Anhänger für die Idee zu finden. Wie es immer bei openSource ist, dass man nur interessieren kann, wenn man konkret etwas vorweist, und nicht nur drüber redet - DoKratie.
Tue das, dann siehst du nämlich, dass das…
Ich bezieh mich nicht auf testing, aber vom Prinzip dachte ich es sollte so funktionieren:
/etc/apt/sources.list deb http://ftp.de.debian.org/debian/ unstable main contrib non-free
deb http://ftp.aptode.org/debian/ aptode main fix easyetc/apt/preferencesPackage: *
Pin: release a=unstable
Pin-Priority: 501
Package: *
Pin: release a=aptode
Pin-Priority: 502Die Metapakete für "easy" Debian Benutzer werden aus dem Verzeichnis easy gezogen, und sind durch die erhöhte Priorität (502) geschützt? Ginge mein Plan besser mit beiden Prioritäten über tausend?
… nicht funktioniert selbst wenn du sie auf eine Millarde hochsetzt. Die Priority bestimmt nur welche Version zur Installation/Upgrade verwendet wird. Nicht ob ein Paket installiert wird (mit teilweiser Ausnahme vom negativen Pin) und beschützen vor dem entfernen tut das schon gar nicht.
@Nex: So ein Script gibt es schon. Es nennt sich smxi und untersützt sicherlich auch bald eMails (Zawinski's Law: "Every program attempts to expand until it can read mail."). Abgesehen vom Endpunkt für so ein Script ist das Problem daran ganz klar die reine Vorspiegelung von Sicherheit durch einen Blackliste - und wäre damit das umgekehrte von ralul der eine Whiteliste vorschlägt - da niemand eine solche Liste maintainen kann ohne das nicht ab und an jemand über die Klippe springt. Genau wie hier jetzt auch mit den Upgrade-Warnungen: Erst muss wer auf die Nase fallen bevor man von dem Fehler weiß.
Stell dir einen Spamfilter vor: Mit einer Blackliste wirst du immer wieder mal Spam bekommen bis du den jeweiligen Absender eingetragen und so blockiert hast. Mit einer Whiteliste wirst du erst Mails bekommen wenn du den Absender eingetragen hast. Beides skaliert kein Stück in einem Archive von mehr als 30.000 Paketen das ständig von anderen mit neuen Versionen gefüttert wird, die sich überhaupt nicht um deine Listen scheren… Willst du also abundan kaputte Pakete weil noch nicht eingetragen oder aber keine (installierbaren) Pakete weil sie nicht freigeschaltet sind - "pick your poison".
@holgerw: Ohne näheres darüber zu wissen: http://yast4debian.alioth.debian.org/
-
Idee - So ein Expose schreibt man z.B. auf einer Wiki-Seite - da kann dann auf der zugehörigen Diskussionsseite ein Austausch geführt werden. Hat den Vorteil, dass man erledigte Dinge auch einfach mal "erledigen" kann und der Entwurf an sich sauber bleibt. Wenn es dann wirklich richtig Bedarf an einer Diskussion über einzelne Punkte gibt, passen die auch wieder in ein Forum.
Ist aber nur so ein Gedanke.
-
@agaida, die Idee nur Metapakete zu nehmen wird von unserem Fachmann verneint. Wir müssen also wenn dann doch ein halbes Repo kopieren.
Bisher dachte ich in meiner Vorannahme, dass Debian das perfekte Paketsystem hat. Jetzt merke ich, dass Gentoo viel besser ist: Allerdings so gut, dass es schon eine richtige Mühe sein kann für einen Gentoo~unstable Benutzer die ganzen "blockings" zu lösen, die durch Abhängigkeiten auf Pakete von "world" / gewollte Pakete entstehen. Da ich rot markierte Blockings auch von Debians aptitude kenne, dachte ich, ich könnte diesen Mechanismus mittels Metapaketen benutzen.
Mich wundert es schon, dass es keine symptomatischen Errorlevel für ein
apt-get dist-upgrade --simulate
geben soll, wenn Abhängigkeiten nicht erfüllt werden.
-
Ohne jetzt groß alles gelesen zuhaben .. den yast-gedanken von holgerw finde ich auch nicht schlecht. Hab ja damals mit suse (hmm,vergessen 5 oder6) angefangen und fand yast nie doof. Nur das das ganze system zu sehr aufgebläht wurde .. hat mich irgendwann zu redhat, dann ubuntu und seid chaos hierher geführt. Wenn es da möglichkeiten gibt, sollte mensch zumindest mal drüber nachdenken .... <--- meine meinung ;)
edit: in der nachlese .... falscher thread .. hab grad burzeltag --- sehts mir nach (nich ganz nüchtern) ;)
-
@Nex: So ein Script gibt es schon. Es nennt sich smxi und untersützt sicherlich auch bald eMails (Zawinski's Law: "Every program attempts to expand until it can read mail."). Abgesehen vom Endpunkt für so ein Script ist das Problem daran ganz klar die reine Vorspiegelung von Sicherheit durch einen Blackliste - und wäre damit das umgekehrte von ralul der eine Whiteliste vorschlägt - da niemand eine solche Liste maintainen kann ohne das nicht ab und an jemand über die Klippe springt. Genau wie hier jetzt auch mit den Upgrade-Warnungen: Erst muss wer auf die Nase fallen bevor man von dem Fehler weiß.
Das Skript kenne ich sogar, habe es eine Zeitlang unter Sidux, bevor es geächtet wurde, genutzt. Aber war/ist es nicht so, dass dieses Skript von nur einer einzigen Person verwaltet wird? Das wäre hier ja anders, da es mehr als ein "Frontschwein" gibt. Zudem kann man smxi ja für alles mögliche inklusive Kaffeekochen benutzen, was es natürlich aufbläht und auch anfällig für Fehler macht. So, wie ich es mir vorstelle (ohne wirklich Ahnung der Machbarkeit zu haben), gäbe es wirklich nur die Blacklist. Und eigentlich denke ich, könnte das auch funktionieren, denn wenn man sich die Threads im "Upgrade Warnings" anschaut, posten zu einem sehr großen Teil immer die gleichen Leute von wirklich gravierenden Fehlern.
cu
-
Hallo David,
@holgerw: Ohne näheres darüber zu wissen: http://yast4debian.alioth.debian.org/
danke für den Hinweis, die Ernüchterung, die auf der Seite zu finden ist, lautet:
IRC: last meeting on 20050424 on #debian-desktop
Das Interesse ist wohl mittlerweile nicht mehr vorhanden, schade.
Viele Grüße,
Holger
-
Das Skript kenne ich sogar, habe es eine Zeitlang unter Sidux, bevor es geächtet wurde, genutzt. Aber war/ist es nicht so, dass dieses Skript von nur einer einzigen Person verwaltet wird? Das wäre hier ja anders, da es mehr als ein "Frontschwein" gibt. Zudem kann man smxi ja für alles mögliche inklusive Kaffeekochen benutzen, was es natürlich aufbläht und auch anfällig für Fehler macht. So, wie ich es mir vorstelle (ohne wirklich Ahnung der Machbarkeit zu haben), gäbe es wirklich nur die Blacklist. Und eigentlich denke ich, könnte das auch funktionieren, denn wenn man sich die Threads im "Upgrade Warnings" anschaut, posten zu einem sehr großen Teil immer die gleichen Leute von wirklich gravierenden Fehlern.
cu
Hallo,
die Schwierigkeit von smxi liegt in der großen Dynamik beim Zweig Debian Sid, bei Testing ist es vielleicht gar nicht so schlecht.
Stell Dir vor, an einem Tag sind zahlreiche Paketbetreuer seher motiviert beim Bauen und Hochladen nach Sid, und dann bedenke, dass die Hauptserver von Debian vier mal pro Tag synchronisiert werden. Und dann noch, dass die Nutzer hier unterschiedliche Repositorien-Server in ihrer sources.list drin stehen haben, die unterschiedlich rasch mit neuen Paketen versorgt werden.
Da können auch 100 Leute an einem smxi arbeiten, der Schuss ginge häufig nach hinten los.
Wir können es doch schon hier beobachten. @Devil postet zum Beispiel eine Upgrade-Warnung, gibt dann zwei Tage später Entwarnung, während andere Nutzer aufgrund anderer Repo-Server noch von dem gleichen Fehler berichten.
Viele Grüße,
Holger