thomas_niphba schriebWieso musste eigentlich unbedingt die 20 Jahre alte Tradition von /bin, /sbin und /usr/sbin mit filesystem-2013.05 per gewalt aufgelöst werden????
Es existiert zwar eine Anleitung um das Update durchzuführen, aber dieses funktioniert bei Systemen die spätestens vor 3 Monaten aktualisiert wurden.
Hat ausser mir eigentlich schon mal jemand versucht ein System zu updaten, dass zuletzt im September 2012 aktualisiert wurde.
Kurzer Hinweis: Das ist völlig unmöglich!!! Beim Versuch die hunderten Zirkelbezüge zwischen den Paketen aufzulösen landet man früher oder später bei einem zerstörten System. Ich danke vielmals, dass ich jetzt alles neu installieren kann.
Ich bin prinzipiell nicht gegen Weiterentwicklungen. Aber wieso dieser Aufwand für eine kleine Schönheitskorrektur? Warum dürfen keine Datein mehr in /bin, /sbin und /usr/sbin verbleiben. Ohne diese harte Bedingung währe der Updateprozess erfolgreich gewesen. Dann hätte ich eben manuelle Nacharbeit gehabt und fertig.
Da nützt keinen Weinen und Meckern. Du bist selber Schuld, wenn du dein System nicht regelmäßig* aktuell hälst. Lies mal die News von heute bis September 2012 und du wirst sehen, dass das nicht an der neuesten Aktuallisierung liegt.


*regelmäßig = ein bis zwei Mal die Woche.
thomas_niphba schriebHat ausser mir eigentlich schon mal jemand versucht ein System zu updaten, dass zuletzt im September 2012 aktualisiert wurde.
Außer dir wird hier keiner ein System haben, dass er so lange nicht geupdatet hat.
thomas_niphba schriebIch bin prinzipiell nicht gegen Weiterentwicklungen.
Und warum updatest du dann nur ien mal im Jahr?
Der Vorteil eines permanent aktualisierten Systems mit stets aktueller Software wird halt mit dem Preis erkauft, dass man auch regelmäßig aktualisieren muss. Da ist nichts Ungewöhnliches dabei und genauso wird es von der Arch-Community auch nach Außen gebracht.

Wenn du ein System willst, dass über einen gewissen Zeitraum auch ggf. Monate später die Aktualisierung noch einwandfrei funktioniert, bist du bei Linux-Distros mit Releasezyklen (Ubuntu, CentOS...) besser aufgehoben, bekommst dann aber natürlich auf einen Schlag sämtliche Upgradeprobleme, wenn du von einem Release zum Nächsten wandern musst.

Wenn du ein System willst, in dem tiefgreifende Änderungen nur zwischen Releases vorkommen (Ubuntu, CentOS...) aber trotzdem die ein oder andere Software aktuell haben willst, bleibt dir nur der Weg, sie entweder über ein Dritt-Repository einzubinden (wenn du Glück hast und jemand sowas bereitgestellt hat) oder zur Not manuell zu kompilieren; bei beiden Möglichkeiten musst du aber für die Aktualisierung der jew. Software selbst ein Auge drauf werfen.

Sorry, so hart es sich anhört: RollingRelease ist nicht dafür gemacht, fast ein dreiviertel Jahr lang nicht mit Updates versorgt zu werden, wie du es offensichtlich getan hast...
Wobei selbst solche Updates bei weitem nicht unmöglich sind, wenn man sich zu helfen weiss.
Mein Netbook wurde zwischen August 2011 und Juni 2012 ebenfalls nicht aktualisiert. Kam erst eine große Reise und danach das große Vergessen. Ich erinnere mich, dass auch damals eine größere Aktualisierung anstand des filesystems anstand UND pacman 4 drauf wollte. Glaube es war nocht etwas dazu aber ich find die entsprechende News gerade nicht - war zumidnest ähnlich wie die derzeitgen Updates. Die beiden Updates kamen sich arg ins Gehege. War aber alles lösbar.

Aber die Vorredner haben natürlich recht:
Rolling Release hat nunmal die Einschränkung, dass oft und auch tiefgehend aktualisiert wird. Und je länger man wartet, desto größer sind die Chancen, dass da etwas schiefgehen kann. Das ist kein Fehler der Distribution, sondern einfach eine Tatsache.

EDIT:
Wobei ich aber mir heut keine halbe Stunde Arbeit für sowas mehr machen würde. Wenn mein System so arg alt ist wirds einfach fix neu aufgesetzt. Mit einer Sicherung von etc (und home natürlich) dauert das wirklich nicht lange und man erspart sich viel Aufwand...
Meine privaten Systeme aktualisiere ich ja auch mehrmals pro Woche. Bei meinen eigenen Systemen im Büro ist das auch nicht anders. Es gibt aber auch Leute die die Vorteile einer schlanken anpassbaren Distribution nicht nur für den privaten Gebrauch zum Selbstzweck und als Hobby nutzen wollen. Ich setze ArchLinux als ThinClients auf ca. 80 PC's im Unternehmen ein. Und bevor jemand mit Bemerkungen über Images kommt: Natürlich deploye ich diese Systeme per Image. Aber dass mache ich auch nur höchsten einmal im Jahr. Zusäzlich gibt es auch 3 besondere ThickClients mit ArchLinux die natürlich speziell angepasste Einzelinstallationen sind. Und genau diese darf ich jetzt neu installieren.

Das filesystem-Update ist bisher die tiefgreifenste Änderung die ich in 2 Jahren ArchLinux erlebe.
Es zwingt dich ja auch keiner, Arch nur als Hobby einzusetzen. Genau so, wie dich keiner zwingt, deine Images nur einmal im Jahr zu aktualisieren. Wie oft du die verteilst ist doch auch Wurst. Hauptsache du aktualisierst das Image öfter. Einmal im Monat pacman laufen zu lassen sollte ja jetzt keine haarige Sache sein. Wobei ich bei einem einjährigen Zyklus das System - wie schon gesagt - eher komplett neu aufsetzen würde.
Wie gesagt, Arch ist Rolling. Dass da auch tiefgreifende Änderungen durchgeführt werden, MUSS dir einfach klar sein. nd dass das nicht auf deinen Arbeitsrythmus passt ist nicht die Schuld der Entwickler.
Hab eben mal auf die Schnelle gesucht, aber nichts gefunden, weiß hier zufällig jemand, wo ich das Image von vor 3-4 Monaten runterladen kann?
thomas_niphba schriebIch setze ArchLinux als ThinClients auf ca. 80 PC's im Unternehmen ein. Und bevor jemand mit Bemerkungen über Images kommt: Natürlich deploye ich diese Systeme per Image. Aber dass mache ich auch nur höchsten einmal im Jahr.
Und nun „beschuldigst“ du Arch für deine Fehler?
@Lycanthropist: Vielen Dank! "Leider" zieht die LiveCD ja das aktuelle Arch aus dem Netz. Wollte eigentlich ein 4 Monate altes Arch auf aktuellen Stand bringen :/
Dirk schriebAußer dir wird hier keiner ein System haben, dass er so lange nicht geupdatet hat.
Oh, oh, Dirk, fangen bei dir etwa schon Verdrängungseffekte an? (Nicht, dass ich sowas gutheißen möchte, die Quittung hat hier ja jemand bekommen.)

@Smon
Da könntest du höchstens das letzte Imagerelease nehmen, dass noch nicht pures netinstall ist, diese Umstellung ist aber, glaube ich, schon länger als 4 Monate her (Oktober 2012 war's schon rein netinstall, wenn ich das richtig nachgesehen habe. 4 Monate ist damit wohl nicht drin.

Back2Topic:

Ein Arch installiere ich nur, wenn ich regelmäßig Wartungszugriff auf den Rechner habe und auch genug Zeit, alle Installationen angemessen zu pflegen. Für ein großflächiges Deployen ist Arch imho weder geeignet noch konzipiert, Updates werden hier halt von Hand eingepflegt. Das ist Teil des Konzeptes.


Desweiteren: Die Aufteilung von /bin, /sbin und /usr kommt daher, dass man Unixe früher teilweise auf 5 Datenträger verteilen musste, weswegen alle binarys, die nicht boot-relevant sind, nach /usr kamen, was auf eine andere Platte kam, die später eingebunden wurde. Das ist heute aber schlicht nicht mehr der Fall. Ich weiß gar nicht, ob man überhaupt noch Permanentdatenträger (außer eeproms vielleicht) bekommt, auf denen man ein Unixoid nicht komplett installieren kann. Insofern macht diese Aufteilung in drei Ordner schlicht keinen Sinn mehr, alles nach /usr/bin zu packen, erleichtert allerdings den Wartungsaufwand ganz massiv, weil eben Binarys, wenn, dort liegen. Die Aufteilung von /bin und /sbin, die eigentlich sogar eine Aufteilung in /bin, /sbin und /lib war, hat man halt im gleichen Atemzug zu bin und lib kondensiert, sodass Paketbauer und Software ganz klar weiß, wo binarys zu suchen sind.

Ist also nur das konsequente Rückgängigmachen einer damals(TM) aus der Not geborenen Trennung und imho auch sinnvoll so. Irgenwann muss man es aber nun mal machen. Fedora macht es genauso (nur lassen die es nach und nach reintröpfeln anstatt die Sache gleich vernünftig abzufrühstücken, wie die Arch-Devs es getan haben).

Alternativ war das der Wink der Devs an gewisse Leute, ihr System mal häufiger zu updaten. 😛

[Edit:]
@thomas_niphba
By the way: Wie sieht das denn dann das Sicherheitskonzept aus, wenn diese Rechner nur einmal im Jahr ein Update kriegen?
Ovion schrieb[…] anstatt die Sache gleich vernünftig abzufrühstücken, wie die Arch-Devs es getan haben).
Vernünftig … und mit ’nem halben Dutzend Symlinks.
Dirk schriebVernünftig … und mit ’nem halben Dutzend Symlinks.
Schöner wär's natürlich gewesen, die Symlinks gleich wegzulassen, aber dann riskierst du halt massives Breakage externer Software, die für irgendwelche Aufrufe noch von der alten Struktur ausgeht. Und mir ist ein Symlink lieber als wenn die Arch-Packager jetzt anfangen, dafür in den Paketen rumzupatchen, von eigenen Paketen ganz zu schweigen.
Aber jetzt ist das immerhin über die Bühne und braucht so einen Move nicht in einigen Wochen nochmal.

@Pierre
Gibt's eigentlich Pläne, besagte Symlinks irgendwann mal wieder rauszunehmen?
Wenn ihr meint, dass es sich lohnen würde unter anderem in allen Bash-Skripten das #!/bin/bash anzupassen. 😉
Diese Symlinks werden ganz sicher nicht so schnell verschwinden.
Richtig, es gibt keine Pläne diese Symlinks zu entfernen.
fs4000 schriebWenn ihr meint, dass es sich lohnen würde unter anderem in allen Bash-Skripten das #!/bin/bash anzupassen. 😉
Genau das meinte ich mit Package-Breakage. Und wo wir beim Thema sind: Was ist von Dev-Seite für die Zukunft eigentlich die korrekte Bash-Shebang-Linie unter Arch? #!/bin/bash oder #!/usr/bin/bash? Auf der arch-dev-public wurde das noch nicht thematisiert (oder ich hab's übersehen), für ersteres spricht (evtl.) Kompatiblität mit anderen Unixen/Linuxen, die technische Realität impliziert imho allerdings eher /usr/bin/bash, da dies der eigentlich korrekte Pfad ist. Was sagt die Chefetage?
Smon schrieb@Lycanthropist: Vielen Dank! "Leider" zieht die LiveCD ja das aktuelle Arch aus dem Netz. Wollte eigentlich ein 4 Monate altes Arch auf aktuellen Stand bringen :/
Achso. 😉

Wenn man nach VirtualBox/VMware/etc. Images sucht findet man das ein oder andere:

http://stacklet.com/downloads/images/list/Arch
http://virtualboxes.org/images/archlinux/
http://virtual-machine.org/vmware-image-archlinux-release-2010-05-download

Vielleicht geht ja der ein oder andere Download davon noch. 🙂
@fs4000
Stimmt, das gab es, ich erinnere mich tatsächlich. Ok, hab's zwar nicht überlesen, aber vergessen, was effektiv keinen großen Unterschied macht. Danke für die Erinnerung!

Edit: Adressierung zur Lesbarkeit hinzugefügt.