| Author |
Message |
|
|
Post subject: Re: RE: Eros timing?
 Posted: Oct 19, 2007 - 11:08 PM
|
|
Joined: Dec 02, 2006
Posts: 1707
Location: Germany / NRW
Status: Offline
|
|
|
Daddy-G wrote:
Aber wenn ich das richtig verstanden habe, muss der Nutzer im einzelnen paketweise entscheiden, was er aktualisiert und was nicht.
Eigentlich ja nicht. Da die grundsätzliche empfehlung ja lautet wenn man aktualisieren will immer ein *dist-upgrade* zu machen beziehen sich alle warnhinweise darauf: Ein d-u funktioniert derzeit nicht reibungslos weil xyz..., oder: ein d-u funktioniert nur, wenn xyz auf hold gesetzt wird.
Quote:
Das kann ganz aufwändig werden, zumindest zeitaufwändig.
Naja, niemand muß ständig aktualisieren. Und die warnhinweise vereinfachen dies: warte einfach bis es wieder geht odere folge den hinweisen.
Quote:
Daneben muss man berücksichtigen, dass hier nur das ausführlich diskutiert bzw. bewertet wird, was jeder hat, wie z.B. den x-server.
Hab auch schon kurzerhand das "unstable" auskommentiert,
... um was zu tun?
Quote:
als das Treiben bei den upgrade-warnings zu bunt wurde, ist ja eh von der her Formulierung für "Eingeweihte".
Schätze, zwischen den releases hat man dann halt das eine oder andere Paket ein bischen länger drauf.
ist doch kein problem
Quote:
Problematisch wird's wohl wenn ein neues Release kommt, sollte man dann wohl besser neuinstallieren, womit wieder bei "eros timing" wär. 
Möglicherweise missverstehe ich dich, aber für mich sieht das so aus als hättest du nicht verstanden, dass sid und vor allem sidux eine distri in kontinuierlicher weiterentwicklung ist und ein neu erscheinendes release keine neuinstallation auslösen will. Es ist ein snapshot zu einem günstigen zeitpunkt für neueinstiger in dieses rolling release. |
Last edited by michaa on Oct 19, 2007 - 11:12 PM; edited 1 time in total
|
| |
|
|
|
 |
|
|
|
Post subject: Re: RE: Eros timing?
Posted: Oct 19, 2007 - 11:11 PM
|
|
Joined: Nov 30, 2006
Posts: 3481
Location: Budapest
Status: Offline
|
|
Daddy-G,
da ist gar nichts problematisch, testing sources dazu und dann eventuell noch security/testing nach Debian-Anleitung. Unstable nicht auskommentieren wegen des sidux-Repositorys bzw. der sidux-Kernel, die ja gegen sid kompiliert sind.
apt-get update && apt-get dist-upgrade -t testing
Nur: es wird sich hier niemand finden, der das unterstützen kann, da ich niemanden kenne, der sidux so fährt, aber theoretisch müsste es so gehen können.
Was den Dist-Upgrade auf ein aktuelles Sid anbelangt, da gibt es in der Regel überhaupt keine Probleme, da muss nichts neu installiert werden. Habe grade Anfang September einen Dist-Upgrade an einer Maschine gemacht, die zwei Monate nicht gelaufen ist. Die müsste noch älter als testing gewesen sein.
Wenn ein Sid-Snapshot grade fehlerfrei ist, kann man ihn ja auch lassen und nur sicherheitsrelevante Pakete upgraden und erst beim nächsten Kernel-Upgrade ein volles dist-upgrade fahren. Das habe ich schon öfter so gehalten und war nie ein Problem.
Wie gesagt: Möglichkeiten gibt es viele, jeder kann dies wirklich halten, wie er will, da es ja keine dist-upgrade-Pflicht gibt Und ich selber halte es immer wieder unterschiedlich, je nach Lust und Laune bzw. nach Qualität des augenblicklichen Sid-Snapshots oder ob ich neue Features wirklich brauche. Sicherheitsupdates spiele ich in der Regel sofort ein.
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Eros timing?
Posted: Oct 20, 2007 - 08:34 AM
|
|
Joined: Dec 02, 2006
Posts: 415
Location: Germany/NRW
Status: Offline
|
|
Will there be a new status report about the current developments of sidux in the near future?
Wird es in naher Zukunft einen Status Report geben zu den aktuellen Entwicklungen rund um sidux? |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Eros timing?
Posted: Oct 20, 2007 - 08:44 AM
|
|
Team Member
Joined: Nov 24, 2006
Posts: 2010
Location: w3
Status: Offline
|
|
|
hubi wrote:
Daddy-G,
da ist gar nichts problematisch, testing sources dazu und dann eventuell noch security/testing nach Debian-Anleitung. Unstable nicht auskommentieren wegen des sidux-Repositorys bzw. der sidux-Kernel, die ja gegen sid kompiliert sind.
apt-get update && apt-get dist-upgrade -t testing
Nur: es wird sich hier niemand finden, der das unterstützen kann, da ich niemanden kenne, der sidux so fährt, aber theoretisch müsste es so gehen können. ...
Während dist-upgrades in Debian fast immer sehr sauber ablaufen (ich hatte kürzlich sogar ein old-stable auf stable und von dort auf sid hochgebracht, ohne wesentliche manuelle Eingriffe), ist ein "dist-downgrade" in der beschriebenen Form immer problematisch:
1) man geht bewusst zusätzliche Sicherheitsrisikien ein weil man bereits gefixte Lücken wieder aufreisst;
2) etliche Pakete sind gegen Sid kompiliert und funktionieren dann nicht mehr;
3) es wird nirgendwo Support dafür geben;
4) Namensänderungen, strukturelle Unterschiede und komplexe Abhängigkeiten machen garantiert Probleme.
Ein solches Downgrade führt also zu einem unsicheren, instabilen und oft sogar unbrauchbaren System. Das gilt übrigens auch für gedankenloses Pinning und Holding auf einzelne Paketversionen aus testing, wie ich es hier hin und wieder als Lösugsvorschlag für Bugs in einzelnen Paketen lese. Auch das sollte nur in ganz seltenen Einzelfällen unter Anleitung eines kundigen Helfers hier geschehen, und niemals als Standardlösung für Probleme verwendet werden.
Um es nochmals deutlich zu sagen: Testing ist keine brauchbare Debian-Version, und ist wesentlich unsicherer als Sid oder Stable. Testing dient ausschliesslich zum Testen und als Sammelpool für die jeweils kommende Stable Version.
Macht es Euch doch nicht so kompliziert. Die Lösung ist doch ganz einfach und wird hier vom sidux Team ja als Kernkompetenz angeboten: Benutze die aktuelle sidux Release zur Einstiegsinstallation und mache alle 2-3 Wochen ein dist-upgrade nachdem Du sicherheitshalber unsere aktuellen News gelesen hast. Sollte dort eine Warnung stehen, warte ein paar Tage damit. Ein derartig gepflegtes System ist immer topaktuell, hochsicher und bombenstabil. Solche Pflege nimmt monatlich nicht mehr als 20 Minuten in Anspruch - einfacher können wir es Dir wirklich nicht mehr machen. Und für Lesefaule gibt es sogar noch smxi.
Greetings,
Chris |
_________________
64bit stuff for sidux
development is life - code.zikula.org
an operating system must operate - sidux.com
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Oct 20, 2007 - 03:29 PM
|
|
Joined: Dec 03, 2006
Posts: 131
|
|
Hi
danke für die Antworten zu .o.g. Schreiben. Das Prinzipielle ist ja durchaus bekannt, es sind da halt einige unklare Punkte auf die man immer wieder stößt.
Was für den erfahrenen Linuxer bzw. Profi eine rein technische Frage ist, ist für den Normalanwender manchmal auch eine psychologische. Gerade wenn es um Xorg-Probleme u.a. in sid geht.
Im Frühjahr 2006 wurde man ziemlich abrupt aus der "Kanotix-Idylle" gerissen als - wie einer schrieb - bei sid und Xorg u.a. die "Kacke am Dampfen war". Vorher gings mit Kanotix-nur aufwärts. Wenn es 2004/2005 wegen SID mal gewackelt haben sollte, dann hat's unsereiner gar nicht mitgekriegt. Man hat beiläufig und beifällig registriert, dass Kanotix immer aktuell ist, aber sid, sarge, etch waren böhmische Dörfer vor allem wenn man nicht von debian sondern via Knoppix zu Kanotix kam.
Nun ja Schnee von gestern, aber es stellt sich schon die Frage inwieweit sidux da jetzt besser aufgestellt ist, upgrade-warnings gabs damals auch schon und trotzdem ging einiges schief. Man merkt, dass das hier jetzt vom Team her cooler gehandelt wird, aber da sind so einige Punkte z.B:
Quote:
Macht es Euch doch nicht so kompliziert. Die Lösung ist doch ganz einfach und wird hier vom sidux Team ja als Kernkompetenz angeboten: Benutze die aktuelle sidux Release zur Einstiegsinstallation und mache alle 2-3 Wochen ein dist-upgrade nachdem Du sicherheitshalber unsere aktuellen News gelesen hast. Sollte dort eine Warnung stehen, warte ein paar Tage damit.
Schön, aber geht das so pauschal...? Es ist doch so, dass die meisten zusätzliche Anwendungen installieren und jeder eine andere Paketzusammenstellung hat. Das sidux team überwacht ja wohl nicht das ganze sid-Repo, sondern was sidux default mitbringt.
Somit stellt sich ggfs. dann schon die Frage des einzelfallbezogenen supports beim dist-upgrade.
btw. zu lenny: Es ist schon klar dass sidux-testing auf Dauerzustand nicht funktionieren kann, und auch nicht. zwangsläufig "sid-trouble" vermeidet. Dass es zwischendurch als sanftes downgrading mal geht, hab ich ja gemerkt. Wenn man bei "sidux-lenny" die sidux-repos drin läßt, gibts irgendwann Ärger da sid-abhängig, kommentiert man sie aus, hat man ein lenny-testing mit schnell alterndem sidux, das irgendwann älter als lenny ist. Deshalb hab ich geschrieben man kann nur von release zu release auf testing gehen.
Denke mal wer die Lenny-Entwicklung verfolgen will, sollte nicht sidux als Basis nehmen sondern es vielleicht von debian direkt holen. Stellt sich nur die Frage, ob man zusätzlich was von sidux übernehmen kann, Graka-Treiber-scripte oder so
Abschließend kann ich sagen, dass der frühere Sid-Ärger imerhin dazu geführt hat, dass man doch ein bischen vertrauter mit Linux-Distries wird und versch. testet, und nicht auf windoof ausweichen muss, wenn die eine Distri mal wackelt. |
_________________
Kanotix-Thorhammer-2.6.27-10
sidux_2008-3
Debian-Lenny-2.6.26-1
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Oct 20, 2007 - 03:43 PM
|
|
Team Member
Joined: Nov 24, 2006
Posts: 2010
Location: w3
Status: Offline
|
|
|
Daddy-G wrote:
Nun ja Schnee von gestern, aber es stellt sich schon die Frage inwieweit sidux da jetzt besser aufgestellt ist, upgrade-warnings gabs damals auch schon und trotzdem ging einiges schief. Man merkt, dass das hier jetzt vom Team her cooler gehandelt wird, aber da sind so einige Punkte z.B:
Quote:
Macht es Euch doch nicht so kompliziert. Die Lösung ist doch ganz einfach und wird hier vom sidux Team ja als Kernkompetenz angeboten: Benutze die aktuelle sidux Release zur Einstiegsinstallation und mache alle 2-3 Wochen ein dist-upgrade nachdem Du sicherheitshalber unsere aktuellen News gelesen hast. Sollte dort eine Warnung stehen, warte ein paar Tage damit.
Schön, aber geht das so pauschal...? Es ist doch so, dass die meisten zusätzliche Anwendungen installieren und jeder eine andere Paketzusammenstellung hat. Das sidux team überwacht ja wohl nicht das ganze sid-Repo, sondern was sidux default mitbringt.
Somit stellt sich ggfs. dann schon die Frage des einzelfallbezogenen supports beim dist-upgrade.
Ja, das geht so pauschal - der Großteil der sidux-User tut genau das. Selbstverständlich können wir nicht das gesamte Sid Repo täglich durchtesten, aber wir testen eine Menge, und aufmerksame User kommen jeden Tag mit Bug Reports, die wir sofort in Lösungen und Aktivität umsetzen. Den Mainstream decken wir damit täglich ab, einige Spezialgebiete (wie z.b. Webserver, wissenschaftlich orientierte Programme, etc.) auch. Wir arbeiten daran diesen Bereich auszubauen, und suchen dazu auch immer laufend hilfsbereite Tester. Wer einen sidux KDE Desktop mit gängigen Applikationen verwendet, ist bei uns auf jeden Fall gut aufgehoben.
Daddy-G wrote:
btw. zu lenny: Es ist schon klar dass sidux-testing auf Dauerzustand nicht funktionieren kann, und auch nicht. zwangsläufig "sid-trouble" vermeidet. Dass es zwischendurch als sanftes downgrading mal geht, hab ich ja gemerkt. Wenn man bei "sidux-lenny" die sidux-repos drin läßt, gibts irgendwann Ärger da sid-abhängig, kommentiert man sie aus, hat man ein lenny-testing mit schnell alterndem sidux, das irgendwann älter als lenny ist. Deshalb hab ich geschrieben man kann nur von release zu release auf testing gehen.
Denke mal wer die Lenny-Entwicklung verfolgen will, sollte nicht sidux als Basis nehmen sondern es vielleicht von debian direkt holen. Stellt sich nur die Frage, ob man zusätzlich was von sidux übernehmen kann, Graka-Treiber-scripte oder so
Testing ist IMMER Trouble, egal woher und wie. Darum ging es mir ganz besonders in meinen obigen Bemerkungen. Da ist Stable mit Backports noch besser, und dafür gibt es ja auch gute Anbieter .
Daddy-G wrote:
Abschließend kann ich sagen, dass der frühere Sid-Ärger imerhin dazu geführt hat, dass man doch ein bischen vertrauter mit Linux-Distries wird und versch. testet, und nicht auf windoof ausweichen muss, wenn die eine Distri mal wackelt.
Greetings,
Chris |
_________________
64bit stuff for sidux
development is life - code.zikula.org
an operating system must operate - sidux.com
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Oct 20, 2007 - 03:55 PM
|
|
Joined: Apr 07, 2007
Posts: 387
Location: Italia
Status: Offline
|
|
| anyway, which improvements will Eros eventually sport? |
_________________
-----------------------------
SI VIS PACEM, PARA BELLVM
-----------------------------
AC MILAN CaMpIoNe d'EuRoPa 2oo7!!!!
AC MILAN WoRLd ChAmPiOn 2oo7!!!!
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Oct 20, 2007 - 08:36 PM
|
|
Joined: Nov 30, 2006
Posts: 204
Location: Buxton, UK
Status: Offline
|
|
| Just a little tip: If a thread starts in the English Forum, typed in English, a good idea would be to keep the thread in English. I was following this thread with interest until it switched to German, at which point I was basically lost. |
_________________
"Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines."
Bertrand Russell.
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Oct 20, 2007 - 08:43 PM
|
|
Joined: Nov 30, 2006
Posts: 3481
Location: Budapest
Status: Offline
|
|
100% agreed.
When I replied I did not even realise I am in the English forum, because I have just the not yet read threads open.
I'll be more careful in the future to watch if the language was hijacked
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 04:52 AM
|
|
Joined: Sep 10, 2007
Posts: 25
Location: Schleswig-Holstein
Status: Offline
|
|
|
x-un-i wrote:
Wofür?? Die Packet von "testing" habe wir schon alle gehabt also.. bringen gar nichts neues
Das scheint so nicht richtig zu sein. Lesen auf debian.org bringt mir folgende Erkentnisse:
Quote:
5.6 Was enthält das testing-Verzeichnis?
Pakete landen im testing-Verzeichnis, nachdem sie zu einem gewissen Grad in unstable getestet wurden.
Diese Pakete müssen identisch für alle Architekturen vorliegen auf denen sie gebaut wurden. Es darf auch keine Abhängigkeiten geben, welche sie uninstallierbar machen würden. Des Weiteren müssen sie weniger veröffentlichungskritische Fehler aufweisen als die aktuelle Version in testing. Auf diese Art erhofft man, dass »testing« immer nahe daran ist ein Release-Kandidat zu werden.
Weitere Informationen über den Status von »Testing« und über die einzelnen Pakete sind unter http://www.debian.org/devel/testing verfügbar.
und weiter:
Quote:
Die Testing-Distribution ist eine automatisch generierte Distribution. Sie wird aus der Unstable-Distribution von einem Satz aus Skripten generiert, die versuchen Pakete hinüber zu bewegen, die ausreichend wahrscheinlich keine veröffentlichungs-kritischen Fehler enthalten. Sie machen es auf eine Art, die sicherstellt, dass die Abhängigkeiten von anderen Paketen in Testing immer aufgelöst werden können.
und weiter zum Thema Sicherheit:
Quote:
F: Wie wird die Sicherheit für Unstable gehandhabt?
A: Die kurze Antwort ist: gar nicht. Unstable ist starken Änderungen unterworfen und das Sicherheits-Team hat nicht die Mittel, die benötigt würden, um diese entsprechend zu unterstützen. Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben.
F: Wie wird die Sicherheit für Testing gehandhabt?
A: Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben. Allerdings gibt es eine begrenzte Sicherheitsunterstützung für Testing: Das Debian Testing-Security-Team behandelt freigegebene (d.h. öffentlich bekannt gemachte) Probleme für Testing. Es stellt sicher, dass die korrigierten Pakete Testing auf dem normalen Weg erreichen oder, falls das zu lange dauert, sie über die normale http://security.debian.org-Infrastruktur erledigt werden. Um diese zu benutzen, muss die folgende Zeile in /etc/apt/sources.list enthalten sein:
deb http://security.debian.org testing/updates main
Führen Sie dann apt-get update && apt-get upgrade wie gewohnt aus.
Beachten Sie, dass dies nicht garantiert, dass alle bekannten Sicherheitsfehler in Testing behoben sind! Einige aktualisierte Pakete könnten auf den Übergang nach Testing warten, und einige Fehler könnten nicht öffentlich und somit auch dem Testing-Sicherheits-Team nicht bekannt sein. Weitere Informationen über die Sicherheits-Infrastruktur für Testing kann unter http://secure-testing-master.debian.net/ gefunden werden.
und jetzt kommt der Satz, der einen dann völlig verwirrt:
Quote:
F: Wie bekommt Testing Sicherheitsaktualisierungen?
A: Sicherheitsaktualisierungen gelangen über Unstable in die Testing-Distribution. Normalerweise werden sie mit einer hohen Priorität hochgeladen, wodurch sich die Quarantäne auf zwei Tage reduziert. Nach dieser Zeit gelangen die Pakete automatisch nach Testing, wenn sie für alle Architekturen gebaut worden sind und ihre Abhängigkeiten in Testing erfüllt werden können.
Ist es das, was Slam schon geraume Zeit versucht, einigen ( ich schließ mich da nich aus) klar zu machen?
Ich versteh nix mehr 
Also bleiben wir bei sidux Sid und smxi und alles okay?
rolo |
|
|
| |
|
|
|
|
|
|
|
Post subject: Re: RE: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 05:56 AM
|
|
Joined: Dec 19, 2006
Posts: 1030
Status: Offline
|
|
|
d2kx wrote:
Will there be a new status report about the current developments of sidux in the near future?
A quick update from my little sidux bubble, here are changes I've been involved with:
* totally new Xorg configuration program. The old crap derived from knoppix/kanotix is gone, and new scripts have been written and integrated into the fll-live-initscripts framework. This has been done in an effort to adapt with RandR 1.2 capable drivers that are starting to appear. It also has the most potential for end user bug reports...
* dissolved scanpartitions/rebuildfstab into the fll-live-initscripts framework in the form of a single perl program
* initial backend for an "install-to-USB-stick" installer has been done. It is a "frugal" type installation; it is actually just a live-cd/fromiso setup done on external media. It has the potential to save all modifications back to the external media and transparently merge those changes back on next boot, but still tries hard to remain hardware agnostic. x-un-i and hjt did most of this work.
There have been very minimal changes to the way sidux is built. Thats about it from me, for now
Kel. |
|
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 06:49 AM
|
|
Joined: Dec 02, 2006
Posts: 396
Status: Offline
|
|
| Thanks Kelmo- nice to hear whats going on |
_________________
Linux user 403389 and Herbaholic Trichopath
AMD Athlon 64 X2 4200+ / 2GB dual chan ddr2 800/ gigabyte ga-m61sme-s2
Acer Aspire One (sidux-Ourea)
sidux -64 Gaia
Hackintosh Leopard
Win Xp (virtualbox)
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 07:38 AM
|
|
Joined: Nov 30, 2006
Posts: 3481
Location: Budapest
Status: Offline
|
|
kelmo,
thank you so much for your info. For me there are really two hotties:
- using Notebooks at my "home cinema" for beamers new X.org development is really welcome
- easy USB-stick installation is very cool
Thank you,
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 07:48 AM
|
|
Joined: Nov 30, 2006
Posts: 3481
Location: Budapest
Status: Offline
|
|
rolo,
sticking with Sid and in case of problems a fallback to testing or http://snapshot.debian.net/ plus hold is the way I go for almost two years without any serious troubles.
testing is for the development of the next stable Debian, and they are kicking out quite a lot of packages all the time to keep it buildable. And for those who like to be on the safe side, I think new Kanotix and new Mepis really might be an alternative working extensively with backporting. Not my way, but I really appreciate their efforts.
Sorry for writing in English, but seeker is right, let's go back to the language of the thread.
hubi |
_________________
Bonitas stultitiaque sodales sunt.
|
| |
|
|
|
|
|
|
|
Post subject: RE: Re: RE: Re: RE: Eros timing?
Posted: Oct 21, 2007 - 08:17 AM
|
|
Team Member
Joined: Nov 24, 2006
Posts: 2010
Location: w3
Status: Offline
|
|
Yes, sorry for the language swift - I did not realize the topic was English initially.
@rolo: Yes, that's part of what I try to explain since ever. Testing is not intended to be run as a distribution, everything getting into testing get's there in an automated way by scripts pushing the packages. Nobody takes care for consistency in Testing, as nobody does for security. What you read at the main Debian site about security packages for Testing was a humble plan, but never seriously actually happened. Testing get's serious attention only shortly before the next Stable release, and only in this time it might become usable for some weeks.
Please understand that some stuff written at the Debian web site is outdated, or explains planned activity - even if you have the impression they are talking about something already done. Please also understand that the people concetrating on the next stable Debian are not interested very much in Sid, they mostly understand it as a interim welcome pool for new packages. If they do not actually run sidux themselves (some do), they would not know what we are doing here, and why.
What you have found out about the flow of security related fixes is correct: All security fixes from upstream hit Sid first, then drop into Testing and might be used by the Security Team afterwards to create security patches for Stable.
Greetings,
Chris
Greetings,
Chris |
_________________
64bit stuff for sidux
development is life - code.zikula.org
an operating system must operate - sidux.com
|
| |
|
|
|
|
|
|
|
