ob das ausgerechnet mit diesem problem zusammenhängt, kann ich nicht sagen (was martin beschreibt, führt normalerweise zu einem segfault) aber das problem scheint eigentlich nur bei einer einzigen distribution aufzutreten und es tritt dermaßen häufig auf, daß man davon ausgehen muß, daß, um es vereinfacht auszudrücken, "install" mit "cp" ersetzt wurde, was alles aus dem tritt bringen wird, das auf in den speicher geblendeten festplatteninhalt (im zweifel noch nicht verwendeten code des binaries oder verlinkter libs) zugreift, welcher dann "heimlich" vom installer ausgetauscht wurde.
ob das in diesem fall greift, kann ich nicht sagen, aber nichtsdetotrotz sollte dieses anscheinend distrospezifische verhalten des updaters angepaßt werden und ansonstem wäre ubuntunutzern ganz generell zu raten, updates nur aus runlevel 1, resp. offline (also aus einer parallelinstallation) durchzuführen.
oder man passt das Programm dementsprechend an, so dass es selbst bei "cp" nicht mehr zu solchen Fehlern kommt. Denn:
1. will ich als User nicht wissen, warum etwas nicht funktioniert - ich will schlicht und einfach dass es funktioniert.
2. wenn ich ein Teil konstruiere und es fällt aus, weil es von links nach rechts gebogen wird, statt von rechts nach links - dann muss ich es umkonstruieren, so dass es in allen use-cases hält und funktioniert. Genau so "einfach" stelle ich mir das auch mit KDEPIM und Akonadi/ Nepomuk vor. Es gibt ja schließlich noch andere Datenbanken (Amarok z.B.), die auch nicht von einem Update kaputtgehen = Beweis, dass es auch ohne kaputtgehen geht.
Das "Programm" wäre dann wahlweise das Dateisystem (copy-on-write, ZFS oder btrfs haben das Problem entsprechend nicht mehr) oder evtl. noch der kernel.
Die Anwendung (*jede*) ist völlig Schutzlos wenn unqualifiziert ihr Speicher manipuliert wird (auch sehr beliebt dafür: "bleachbit" -whitelist gesteuertes inodeüberschreiben - ja sicher...) Allenfalls könnte man den Speicher hashen und den hash laufend abgleichen.
Ich will jetzt mal nicht lange diskutieren, ob derartiger overhead noch angemessen wäre...
"Install" und die Mechanismen dahinter existieren schlicht nicht umsonst.
Darüberhinaus und wie deutlich gesagt: ich weiß nicht, was da bei akonadi kaputtgeht (benutze ich nicht) und ob das durch dieses spezielle updateverhalten verursacht wird.
Nur, dieses von Martin angeschnittene spezielle updateverhalten scheint es zu geben und die Schuld für die natürlichen Konsequenzen dessen (es crasht iA. spätestens wenn eine dlopen lib ausgetauscht wird) sind ganz sicher weder bei linux, noch libc oder gar den Anwendungen zu suchen. Die fehlerhafte Komponente wäre (im Fall dieses anscheinenden Verhaltens) dann hier klar der Installer.
ob das ausgerechnet mit diesem problem zusammenhängt, kann ich nicht sagen (was martin beschreibt, führt normalerweise zu einem segfault) aber das problem scheint eigentlich nur bei einer einzigen distribution aufzutreten und es tritt dermaßen häufig auf, daß man davon ausgehen muß, daß, um es vereinfacht auszudrücken, "install" mit "cp" ersetzt wurde, was alles aus dem tritt bringen wird, das auf in den speicher geblendeten festplatteninhalt (im zweifel noch nicht verwendeten code des binaries oder verlinkter libs) zugreift, welcher dann "heimlich" vom installer ausgetauscht wurde.
ob das in diesem fall greift, kann ich nicht sagen, aber nichtsdetotrotz sollte dieses anscheinend distrospezifische verhalten des updaters angepaßt werden und ansonstem wäre ubuntunutzern ganz generell zu raten, updates nur aus runlevel 1, resp. offline (also aus einer parallelinstallation) durchzuführen.
oder man passt das Programm dementsprechend an, so dass es selbst bei "cp" nicht mehr zu solchen Fehlern kommt.
Denn:
1. will ich als User nicht wissen, warum etwas nicht funktioniert - ich will schlicht und einfach dass es funktioniert.
2. wenn ich ein Teil konstruiere und es fällt aus, weil es von links nach rechts gebogen wird, statt von rechts nach links - dann muss ich es umkonstruieren, so dass es in allen use-cases hält und funktioniert. Genau so "einfach" stelle ich mir das auch mit KDEPIM und Akonadi/ Nepomuk vor. Es gibt ja schließlich noch andere Datenbanken (Amarok z.B.), die auch nicht von einem Update kaputtgehen = Beweis, dass es auch ohne kaputtgehen geht.
Das "Programm" wäre dann wahlweise das Dateisystem (copy-on-write, ZFS oder btrfs haben das Problem entsprechend nicht mehr) oder evtl. noch der kernel.
Die Anwendung (*jede*) ist völlig Schutzlos wenn unqualifiziert ihr Speicher manipuliert wird (auch sehr beliebt dafür: "bleachbit" -whitelist gesteuertes inodeüberschreiben - ja sicher...)
Allenfalls könnte man den Speicher hashen und den hash laufend abgleichen.
Ich will jetzt mal nicht lange diskutieren, ob derartiger overhead noch angemessen wäre...
"Install" und die Mechanismen dahinter existieren schlicht nicht umsonst.
Darüberhinaus und wie deutlich gesagt:
ich weiß nicht, was da bei akonadi kaputtgeht (benutze ich nicht) und ob das durch dieses spezielle updateverhalten verursacht wird.
Nur, dieses von Martin angeschnittene spezielle updateverhalten scheint es zu geben und die Schuld für die natürlichen Konsequenzen dessen (es crasht iA. spätestens wenn eine dlopen lib ausgetauscht wird) sind ganz sicher weder bei linux, noch libc oder gar den Anwendungen zu suchen.
Die fehlerhafte Komponente wäre (im Fall dieses anscheinenden Verhaltens) dann hier klar der Installer.
Ist nicht oder schwer möglich, je nach Anwendung..