Re: Time-Machine auf NAS-Freigabe
Dominik Schlütter
> Wenn ich das richtig verstehe, unterst�tzt Time-Machine von Haus aus ja
> nur externe USB/Firewire-Festplatten, welche dann direkt mit einem
> HFS-Dateisystem formatiert und angesprochen werden.
Nein, man kann TimeMachine auch via AFP nutzen. Dazu hat Apple ein paar
Erweiterungen implementiert - und dann ist auf dem Zielsystem auch nicht
mehr so wichtig, welches Dateisystem benutzt wird. Da wird dann notfalls
halt in ein entsprechendes Sparse-Image gesichert.
> Mit etwas Googlen findet man dann allerdings Anleitungen, die beschreiben
> wie man eine wachsende HFS-Image-Datei auf einen NAS legen kann um dann
> dieses Image als Ziel f�r die Backups zu verwenden.
Naja, man braucht auch noch einen passenden AFP-Server und f�r ein
Restore von der Installations-DVD auch noch ein paar
"Dienst-Ank�ndigungen" via Bonjour, damit der TM-Server gefunden wird.
> Allerdings scheint Apple hier beim Snow-Leopard wieder irgendwas
> ge�ndert zu haben; jedenfalls funktioniert das (zumindest bei mir)
> nicht.
Soso.
> Kann das jemand best�tigen? Oder hat jemand einen Tipp wie man
> die Schnee-Katze doch noch �berreden kann, ihr Daten in einen
> HFS-Container auf einer NAS-Freigabe zu legen?
Vielleicht kannst du mal kurz schildern, was genau du gemacht hast -
also welcher Serverdienst dazu auf dem NAS (was f�r ein Ger�t?) l�uft
und wie du das eingebunden hast bzw. ansprichst. Prinzipiell geh�rt das
IMHO auch eher nach <news:de.comp.sys.mac.lokale-netze>, deshalb x-post
und f'up dorthin.
Gru�,
Dominik.
Joern Bredereck
Am 26.12.09 13:23, schrieb Dominik Schl�tter:
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Wenn ich das richtig verstehe, unterst�tzt Time-Machine von Haus aus ja
>> nur externe USB/Firewire-Festplatten, welche dann direkt mit einem
>> HFS-Dateisystem formatiert und angesprochen werden.
>
> Nein, man kann TimeMachine auch via AFP nutzen.
yep, das ist richtig. Bei AFP kann man sich den Umweg �ber einen
HFS-Container sparen, weil AFP direkt die HFS-spezifischen
Dateisystem-Attribute unterst�tzt. Bei Samba geht das leider nicht direkt.
> Dazu hat Apple ein paar
> Erweiterungen implementiert - und dann ist auf dem Zielsystem auch nicht
> mehr so wichtig, welches Dateisystem benutzt wird. Da wird dann notfalls
> halt in ein entsprechendes Sparse-Image gesichert.
Ja. Und �ber diesen Sparse-Image-Klimmzug kann man das Image eben auch
�ber Samba mounten, denn f�r den simplen File I/O-Zugriff auf diese eine
Image-Datei tut's Samba allemal. Alle relevanten HFS-Meta-Informationen
liegen dann innerhalb des Image und Samba bzw. das Dateisystem auf dem
Server spielen �berhaupt keine Rolle. Eine Beschr�nkung hat man dann
h�chstens noch in Form der maximalen Dateigr�sse, die das Image-File
haben darf.
>> Mit etwas Googlen findet man dann allerdings Anleitungen, die beschreiben
>> wie man eine wachsende HFS-Image-Datei auf einen NAS legen kann um dann
>> dieses Image als Ziel f�r die Backups zu verwenden.
>
> Naja, man braucht auch noch einen passenden AFP-Server
Nein, den sollte man eigentlich nicht brauchen, denn alles HFS-relevante
findet innerhalb des Containers/Image-Files statt. Da tut's dann auch
eine Samba-Share um in diese eine Image-Datei zu schreiben und daraus zu
lesen.
> und f�r ein
> Restore von der Installations-DVD auch noch ein paar
> "Dienst-Ank�ndigungen" via Bonjour, damit der TM-Server gefunden wird.
das wird per Samba wahrscheinlich nicht gehen. Es sei denn man k�nnte
schon w�hrend der Installation auf einen Samba-Server zugreife und ein
dort gefundenes Image-File als Volume mounten. Aber damit k�nnte ich zur
Not leben. Wenn wirklich mal ein Desaster-Recovery notwendig w�re,
k�nnte ich immernoch den Inhalt des Image auf eine externe HFS-Platte
umkopieren.
Mir isses allerdings zu aufw�ndig permanent eine externe Platte (oder
gar so eine overprizete Time-Capsule) an mein MacBook anzuschliessen. Da
sichere ich lieber per WLAN auf's NAS ohne jedes mal externe Platten an-
und abst�pseln zu m�ssen.
>> Allerdings scheint Apple hier beim Snow-Leopard wieder irgendwas
>> ge�ndert zu haben; jedenfalls funktioniert das (zumindest bei mir)
>> nicht.
>
> Soso.
naja, das w�re zumindest eine Erkl�rung, warum's bei mir nicht geht.
Alle Anleitungen die ich gefunden habe, haben sich auf �ltere
Mac-OS-Versionen bezogen.
>> Kann das jemand best�tigen? Oder hat jemand einen Tipp wie man
>> die Schnee-Katze doch noch �berreden kann, ihr Daten in einen
>> HFS-Container auf einer NAS-Freigabe zu legen?
>
> Vielleicht kannst du mal kurz schildern, was genau du gemacht hast -
http://www.meetinx.de/tutorial-time-machine-auf-nas-netzwerk-laufwerk/
http://www.administrator.de/Datensicherung_mit_Time_Machine_auf_normalem_Standard_NAS.html
> also welcher Serverdienst dazu auf dem NAS (was f�r ein Ger�t?) l�uft
> und wie du das eingebunden hast bzw. ansprichst.
Was f�r ein Ger�te d�rfte keine Rolle spielen... ist eine simple
SMB-Freigabe von meinem Digital-Receiver (Dreambox 8000).
Das Anlegen und Mounten des Containers funktioniert. Ich kann problemlos
in das gemountete HFS-Volume schreiben.
Nur Time-Machine bietet mir dieses Volume leider nicht zum sichern an.
Gru�,
J�rn
Dominik Schlütter
> yep, das ist richtig. Bei AFP kann man sich den Umweg �ber einen
> HFS-Container sparen, weil AFP direkt die HFS-spezifischen
> Dateisystem-Attribute unterst�tzt.
AFP kennt einige zus�tzliche Methoden, um Mac-typische Metadaten korrekt
�bers Netz zu transportieren. Nur muss das dann am Zielsystem auch
irgendwie im Dateisystem umgesetzt werden - deswegen braucht man bei
Netatalk z.B. die CNID-Backends. Und selbst damit hat man noch nicht
zwingend alle Features implementiert, so dass man weiterhin auf
Sparse-Images angewiesen ist.
> Ja. Und �ber diesen Sparse-Image-Klimmzug kann man das Image eben auch
> �ber Samba mounten, denn f�r den simplen File I/O-Zugriff auf diese eine
> Image-Datei tut's Samba allemal.
Es ist ja durchaus etwas mehr als ein "simpler File I/O-Zugriff", der da
passiert. Die zus�tzlichen Features f�r AFP sorgen beispielsweise daf�r,
dass eine Best�tigung auch erst dann signalisiert ist, wenn die Daten
auch auf der Platte gelandet sind (und nicht, wenn sie irgendwo
quittiert und in einen Cache verschoben wurden).
> Alle relevanten HFS-Meta-Informationen liegen dann innerhalb des Image und
> Samba bzw. das Dateisystem auf dem Server spielen �berhaupt keine Rolle.
Nein, das ist leider nicht so. Es gibt ja auch Anforderungen, die nicht
die Speicherung sondern z.B. den Transport betreffen.
> Nein, den sollte man eigentlich nicht brauchen, denn alles HFS-relevante
> findet innerhalb des Containers/Image-Files statt. Da tut's dann auch
> eine Samba-Share um in diese eine Image-Datei zu schreiben und daraus zu
> lesen.
Wie du ja selbst festgestellt hast, ist dem eben nicht so :-P.
> Mir isses allerdings zu aufw�ndig permanent eine externe Platte (oder
> gar so eine overprizete Time-Capsule) an mein MacBook anzuschliessen. Da
> sichere ich lieber per WLAN auf's NAS ohne jedes mal externe Platten an-
> und abst�pseln zu m�ssen.
Gut, das ist ja auch nicht das Problem. Nur gibt es eben einige
Anforderungen, die da an eine Netzwerkplatte (bzw. die Serversoftware
dort gestellt werden). Das Umlegen eines Schalters mit 'defaults write
com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1' reicht da
nicht wirklich aus.
> Was f�r ein Ger�te d�rfte keine Rolle spielen... ist eine simple
> SMB-Freigabe von meinem Digital-Receiver (Dreambox 8000).
Es legt halt zumeist fest, was da f�r ein Serverdienst l�uft (oder
laufen kann - auf meiner LinkStation tut es ein aktuelles Netatalk 2.0.5
und mit der entsprechenden Avahi-Konfiguration wird das in der
Zeitmaschine angeboten). Auch in den von dir verlinkten Anleitungen wird
doch schon auf das Problem hingewiesen, dass das nicht klappt und fr�her
oder sp�ter das Sparsebundle volll�uft. Das Problem ist ja nicht neu,
<http://discussions.apple.com/thread.jspa?messageID=5918065>
thematisiert das ebenfalls.
Selbst wenn du es hinbekommst, dass TM ohne Fehlermeldung sichert, wirst
du nicht viel Freude an deinem Backup haben. Und wenn nicht sicher ist,
ob das Backup wirklich nutzbar ist, bleibt IMHO die Frage, weshalb man
sich das Ganze dann �berhaupt antut ... .
Gru�,
Dominik.
Joern Bredereck
Am 26.12.09 17:10, schrieb Dominik Schl�tter:
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> yep, das ist richtig. Bei AFP kann man sich den Umweg �ber einen
>> HFS-Container sparen, weil AFP direkt die HFS-spezifischen
>> Dateisystem-Attribute unterst�tzt.
>
> AFP kennt einige zus�tzliche Methoden, um Mac-typische Metadaten korrekt
> �bers Netz zu transportieren. Nur muss das dann am Zielsystem auch
> irgendwie im Dateisystem umgesetzt werden - deswegen braucht man bei
> Netatalk z.B. die CNID-Backends. Und selbst damit hat man noch nicht
> zwingend alle Features implementiert, so dass man weiterhin auf
> Sparse-Images angewiesen ist.
richtig, so hatte ich das auch verstanden.
>> Ja. Und �ber diesen Sparse-Image-Klimmzug kann man das Image eben auch
>> �ber Samba mounten, denn f�r den simplen File I/O-Zugriff auf diese eine
>> Image-Datei tut's Samba allemal.
>
> Es ist ja durchaus etwas mehr als ein "simpler File I/O-Zugriff", der da
> passiert. Die zus�tzlichen Features f�r AFP sorgen beispielsweise daf�r,
> dass eine Best�tigung auch erst dann signalisiert ist, wenn die Daten
> auch auf der Platte gelandet sind (und nicht, wenn sie irgendwo
> quittiert und in einen Cache verschoben wurden).
naja, das ist je nach verwendeter Festplatte bzw. je nach
Festplatten-Controller �brigens auch sehr relativ. Sobald du am
Sata-Controller den Write-Cache anschaltest (oder den defaultm�ssig
angeschalteten Write-Cache nicht aussschaltest), meldet der Controller
immer zur�ck, die Daten seien geschrieben, obwohl sie in Wirklichkeit
noch irgendwo im RAM des Controllers rumgammeln. Ich gebe dir allerdings
recht, dass man w�hrend eines Backups eigentlich keinen Write-Cache
haben will. Allerdings ist es mitnichten damit getan AFP zu benutzen und
sich dann "sicher" zu f�hlen. Da sind noch ein paar andere Layer beteiligt.
Aber um zum Thema zur�ckzukommen: Ich k�nnte grunds�tzlich mit so einem
Cache leben. Die Gefahr, dass inkonsistente Daten geschrieben werden,
sollte durch entsprechende Hash-Verifies eigentlich �berschaubar
bleiben. Und wenn's doch mal passiert, sollte es zumindest nicht
unbemerkt passieren. Im schlimmsten Fall bekommt man dann von
Time-Machine ne Fehlermeldung und weiss, dass sein Image kaputt ist. Mir
gehts hier ja nicht darum vollautomatisch Daten in einem HA-Datacenter
zu sichern, sodern wir sprechen von meinem MacBook. :-)
>> Alle relevanten HFS-Meta-Informationen liegen dann innerhalb des Image und
>> Samba bzw. das Dateisystem auf dem Server spielen �berhaupt keine Rolle.
>
> Nein, das ist leider nicht so. Es gibt ja auch Anforderungen, die nicht
> die Speicherung sondern z.B. den Transport betreffen.
Mal Butter bei die Fische: Welche Anforderungen werden von Samba nicht
erf�llt?
>> Nein, den sollte man eigentlich nicht brauchen, denn alles HFS-relevante
>> findet innerhalb des Containers/Image-Files statt. Da tut's dann auch
>> eine Samba-Share um in diese eine Image-Datei zu schreiben und daraus zu
>> lesen.
>
> Wie du ja selbst festgestellt hast, ist dem eben nicht so :-P.
inzwischen l�ufts. Scheint ein Bug in der Namensaufl�sung von
SnowLeopard zu sein. Wenn man die Share �ber die IP-Adresse anstelle des
NetBios-Namens mounted, dann scheint es zu funktionieren (Backup ist
gerade erst gestartet... ob's wirklich geklappt hat sehe ich erst wenn's
fertig ist).
>> Mir isses allerdings zu aufw�ndig permanent eine externe Platte (oder
>> gar so eine overprizete Time-Capsule) an mein MacBook anzuschliessen. Da
>> sichere ich lieber per WLAN auf's NAS ohne jedes mal externe Platten an-
>> und abst�pseln zu m�ssen.
>
> Gut, das ist ja auch nicht das Problem. Nur gibt es eben einige
> Anforderungen, die da an eine Netzwerkplatte (bzw. die Serversoftware
> dort gestellt werden). Das Umlegen eines Schalters mit 'defaults write
> com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1' reicht da
> nicht wirklich aus.
wenn du recht hast, w�re das ehrlichgesagt ein ziemliches Armutszeugnis
f�r MacOS. Andere Hersteller schaffen es, Backup-L�sungen zu
implementieren, die mit einer simplen Samba-Share auskommen und keine
h�heren Anforderungen stellen.
Man k�nnte jetzt unterstellen, dass Apple einfach seine Zeitkapseln
verkaufen m�chte.... aber ich schweife vom eigentlichen Thema ab.
>> Was f�r ein Ger�te d�rfte keine Rolle spielen... ist eine simple
>> SMB-Freigabe von meinem Digital-Receiver (Dreambox 8000).
>
> Es legt halt zumeist fest, was da f�r ein Serverdienst l�uft (oder
> laufen kann - auf meiner LinkStation tut es ein aktuelles Netatalk 2.0.5
> und mit der entsprechenden Avahi-Konfiguration wird das in der
> Zeitmaschine angeboten).
Wahrscheinlich k�nnte ich mit einem Cross-Compiler bewaffnet auch einen
AFP-Server f�r die Dreambox bauen, aber f�r die Arbeitszeit, die ich da
reinstecken m�sste, k�nnte ich mir auch einen dedizierten FreeBSD-Server
mit AFP hinstellen. :-)
> Auch in den von dir verlinkten Anleitungen wird
> doch schon auf das Problem hingewiesen, dass das nicht klappt und fr�her
> oder sp�ter das Sparsebundle volll�uft. Das Problem ist ja nicht neu,
> <http://discussions.apple.com/thread.jspa?messageID=5918065>
> thematisiert das ebenfalls.
Ich werd das jetzt mal testen und dann entscheiden, ob's ein (f�r meine
Anforderungen) praktikabler Weg ist.
Gru�,
J�rn
Thomas Kaiser
> Bei AFP kann man sich den Umweg über einen HFS-Container sparen, weil
> AFP direkt die HFS-spezifischen Dateisystem-Attribute unterstützt.
Und was soll das bringen, wenn der Server das dann nicht passend
speichern kann? Time Machine durchs Netz --> Sparse Bundle. Auch bei
AFP. Daß AFP besser geeignet ist, liegt einfach daran, daß Apple AFP
paar Erweiterungen spendiert hat, mit der der Client weiß bzw.
sicherstellen kann, daß die zu sichernden Daten auch wirklich
geschrieben wurden (im Sinn von: Sicher auf Platte und nicht in
irgendwelchen Caches). Grad bei Backup halte ich so eine Sicherstellung
nicht für unnötigen Luxus sondern Grundbedingung.
>> Dazu hat Apple ein paar Erweiterungen implementiert - und dann ist
>> auf dem Zielsystem auch nicht mehr so wichtig, welches Dateisystem
>> benutzt wird. Da wird dann notfalls halt in ein entsprechendes
>> Sparse-Image gesichert.
Notfalls?
> Ja. Und über diesen Sparse-Image-Klimmzug kann man das Image eben auch
> über Samba mounten, denn für den simplen File I/O-Zugriff auf diese
> eine Image-Datei tut's Samba allemal. Alle relevanten HFS-Meta-
> Informationen liegen dann innerhalb des Image und Samba bzw. das
> Dateisystem auf dem Server spielen überhaupt keine Rolle. Eine
> Beschränkung hat man dann höchstens noch in Form der maximalen
> Dateigrösse, die das Image-File haben darf.
Tja, drum wird ja ein Sparse Bundle und kein Sparse Image genutzt. Und
AFP hat trotzdem noch weitere Vorteile, speziell wenn man auch einen
simplen bzw. problemlose Restore im Hinterkopf hat.
>>> Mit etwas Googlen findet man dann allerdings Anleitungen, die
>>> beschreiben wie man eine wachsende HFS-Image-Datei auf einen NAS
>>> legen kann um dann dieses Image als Ziel für die Backups zu
>>> verwenden.
>>
>> Naja, man braucht auch noch einen passenden AFP-Server
>
> Nein, den sollte man eigentlich nicht brauchen
Doch, doch.
>> und für ein Restore von der Installations-DVD auch noch ein paar
>> "Dienst-Ankündigungen" via Bonjour, damit der TM-Server gefunden
>> wird.
>
> das wird per Samba wahrscheinlich nicht gehen.
Genau.
> Wenn wirklich mal ein Desaster-Recovery notwendig wäre, könnte ich
> immernoch den Inhalt des Image auf eine externe HFS-Platte umkopieren.
Ah, der Trend zum Zweit-Mac ist unverkennbar. Oder wie willst Du im Fall
des Falles dann das Image mounten und auf eine HFS+ Platte bügeln?
> Nur Time-Machine bietet mir dieses Volume leider nicht zum sichern an.
Und das ist auch gut so. Außer Du betreibst Backup eh nur zum Spaß und
kannst auch drauf verzichten.
Gruss,
Thomas
Thomas Kaiser
> wenn du recht hast, wäre das ehrlichgesagt ein ziemliches
> Armutszeugnis für MacOS.
Dir sollte klar sein, daß Deine Art und Weise, für Dich Neues und noch
nicht wirklich Verstandenes als Quatsch oder sonstwas zu diffamieren,
Dich von einigen Antworten bzw. Antwortgebern in Zukunft abschneiden
dürfte?
Und nicht falsch verstehen: Apple macht garantiert nicht alles richtig.
Und Apple-Fanboys, die andauernd das Gegenteil behaupten (und meist gar
keine Ahnung haben... aber das gehört ja wohl auch zusammen) sind mir
ein ziemliches Greuel. Aber Deine Attitüde -- alles doof, was Du (noch)
nicht kapierst -- nervt beinahe noch mehr.
Gut' Nacht,
Thomas
Joern Bredereck
> Joern Bredereck schrieb in <news:hh5k6d$60s$1...@hathi.bw-networx.net>
>> wenn du recht hast, wäre das ehrlichgesagt ein ziemliches
>> Armutszeugnis für MacOS.
>
> Dir sollte klar sein, daß Deine Art und Weise, für Dich Neues und noch
> nicht wirklich Verstandenes als Quatsch oder sonstwas zu diffamieren,
> Dich von einigen Antworten bzw. Antwortgebern in Zukunft abschneiden
> dürfte?
Mit Diffamieren hat diese Feststellung nichts zu tun. Ich finde es
wirklich arm, wenn Apple es nicht schafft, eine Backup-Lösung zu
entwickeln, die mit einer simplen Samba-Freigabe klarkommt. Das schaffen
zig andere Hersteller auch. Das lässt für mich nur zwei Rückschlüsse zu:
a) Apple kann es wirklich nicht (das WÄRE ein Armutszeugnis - man
beachte den Konjunktiv)
b) Apple will es nicht, weil das nicht ins Marketing-Konzept (Stichwort:
Verkauf von Zeitkapseln) passt.
Ich halte b) für wahrscheinlicher. Und wir können gerne darüber
diskutieren, falls du anderer Meinung bist. Aber mir einfach nur zu
unterstellen, ich würde "diffamieren", ohne dich inhaltlich damit
auseinanderzusetzen halte ich für ein bisschen "billig".
> Und nicht falsch verstehen: Apple macht garantiert nicht alles richtig.
> Und Apple-Fanboys, die andauernd das Gegenteil behaupten (und meist gar
> keine Ahnung haben... aber das gehört ja wohl auch zusammen) sind mir
> ein ziemliches Greuel.
Also dieser Alibi-Disclaimer macht deine typische Fanboy-Reaktion leider
auch nicht objektiver. Wenn du Argumente hast, die meine These
widerlegen, dann lass uns darüber sachlich diskutieren.
Wenn du hingegen einfach nur deinen Unmut darüber zum Ausdruck bringen
willst, dass es tatsächlich jemand wagt Apple zu kritisieren, dann frage
ich mich, warum du genau das tust, was du in deinem "Disclaimer" als
nervend definierst.
Also lass uns bitte mal von dieser Meta-Diskussion herunterkommen und
nenn mir doch mal einen guten Grund, warum es von Apple keine
Backup-Lösung gibt, die in eine simple CIFS-Share sichern kann. Jedem
billigen Wühltisch-NAS liegt eine entsprechende Windows-Software bei,
die diesen Job macht. Selbstverständlich ist da teilweise auch schrott
dabei, aber mir sind zumindest einige Lösungen bekannt die bei uns und
unseren Kunden seit Jahren problemlos funktionieren und regelmässig ihre
Alltagstauglichkeit (in Form von teilweisen oder Komplett-Restores)
unter Beweis stellen.
Gruß,
Jörn
Dominik Schlütter
> Mit Diffamieren hat diese Feststellung nichts zu tun. Ich finde es
> wirklich arm, wenn Apple es nicht schafft, eine Backup-L�sung zu
> entwickeln, die mit einer simplen Samba-Freigabe klarkommt.
Das sei dir unbenommen - aber du solltest vielleicht auch mal schauen,
was Apple da anbietet. Das ist n�mlich eine wirklich einfach zu
bedienende Backupl�sung, die zum einen mit Hardlinks jeweils
"Komplettimages" liefert, zum anderen aber (und das ist IMHO der
wirklich interessante Ansatz) �ber das reine Sichern von Einzeldateien
hinausgeht und den Applikationen die M�glichkeit gibt, einzelne Objekte
zu versionieren.
Wenn ich also im Adressbuch schauen m�chte, wie eine Visitenkarte vor
zwei Wochen aussah, dann mus sich nicht wissen, wo das Adressbuch seine
Daten speichert und dann in der Datei herumw�hlen um den einen Datensatz
zu finden und irgendwie in die aktuelle Version hineinzufummeln.
Stattdessen kann ich mir einfach eine Visitenkarte heraussuchen und mit
der Zeitmaschine die Versionen der Vergangenheit anschauen (und bei
Bedarf zur�ckholen). Das alles mit einer Benutzeroberfl�che, die zwar
durchaus noch ein wenig Politur vertragen k�nnte, die ansonsten aber
auch einem DAU eine anschauliche Herangehensweise erm�glicht.
Um es jedem - wirklich jedem - einfach zu machen, ein aktuelles Backup
zu nutzen, kann man einfach eine Platte anstecken und benutzen. Oder man
nimmt einen passen konfigurierten Server (ja, Apple verkauft dazu z.B.
die Time Capsule).
Man kann jetzt nat�rlich sagen "oh, das ist mir alles zu einfach, ich
m�chte aber meinen Server xy benutzen". Wenn man dann das Basteln
anf�ngt, ist der naheliegende Ansatz, Apples Spezifikationen m�glichst
genau umzusetzen und z.B. die dort angebotenen Server zu kopieren. Das
geht inzwischen z.B. mit Netatalk und Avahi - wenn man das einrichtet,
klappt das �hnlich gut wie mit der Apfel-Hardware.
Du m�chtest dagegen, dass sich Apples Software so verh�lt, dass sie zu
deinen vorhandenen (offensichtlich weniger geeigneten) Servern passt.
Dazu wirst du bei Apple aber wenig Unterst�tzung finden, denn die haben
ja schon ein funktionierendes Konzept mitsamt passender Hardware. Du
m�sstest also die TM-Software von Apple erweitern, was mangels Quellen
ein ziemlich ausssichtsloses Unterfangen ist.
Oder noch mal in aller K�rze: Apple ist es ziemlich egal, dass du das
Ganze auf einem abgespeckten CIFS-Server betreiben m�chtest. Die haben
schliessslich bereits eine funktionierende, einfache L�sung f�r das
Backup-Problem entwickelt.
> Aber mir einfach nur zu unterstellen, ich w�rde "diffamieren", ohne dich
> inhaltlich damit auseinanderzusetzen halte ich f�r ein bisschen "billig".
Sorry, aber du machst nicht den Eindruck, als h�ttest du dich mit den
zugrundeliegenden Konzepten vertraut gemacht. Stattdessen kommt von dir
vor allem, dass irgendwas angeblich nicht ginge, obwohl es das sollte
und �berhaupt sei das ja alles eine Selbstverst�ndlichkeit. Dem ist
nicht so.
> Wenn du hingegen einfach nur deinen Unmut dar�ber zum Ausdruck bringen
> willst, dass es tats�chlich jemand wagt Apple zu kritisieren, dann frage
> ich mich, warum du genau das tust, was du in deinem "Disclaimer" als
> nervend definierst.
Du kritisierst Dinge, deren Sinn du anscheinend nicht verstanden hast.
Das passiert halt im Usenet - nur solltest du die Chance nutzen und dich
ein wenig zum Thema schlau machen. Das hilft. Wirklich.
> Also lass uns bitte mal von dieser Meta-Diskussion herunterkommen und nenn
> mir doch mal einen guten Grund, warum es von Apple keine Backup-L�sung
> gibt, die in eine simple CIFS-Share sichern kann.
Naja, gibts doch:
| [alBook:~] dominik$ which rsync
| /usr/bin/rsync
Damit kannst du Kram nach Herzenslust durch die Gegend sichern. Auch auf
via CIFS angebundene Laufwerke. Wenn du fertige L�sungen suchst, hat
Apple ebenfalls was anzubieten - das erfordert dann halt einen
entsprechenden Server (und nein, der muss nicht von Apple kommen).
Gru�,
Dominik.
Dominik Schlütter
>>> [ ... in Sparse-Image sichern]
>
> Notfalls?
Ich muss sagen, dass ich da wenig Erfahrung habe. Ich dachte immer, wenn
man z.B. einen Mac als Zielserver benutzt, dann landet das direkt im
Dateisystem - aber dem ist dann wohl nicht so. Ich habe es �bers Netz
bislang nur mit Netatalk und einer Linuxkiste probiert, und da l�uft es
eh' auf eine Sparse-Image/Bundle hinaus ... .
Gru�,
Dominik.
Ralph Böhme
> Thomas Kaiser <Thomas...@phg-online.de> schrieb:
>>>> [ ... in Sparse-Image sichern]
>>
>> Notfalls?
> Ich muss sagen, dass ich da wenig Erfahrung habe. Ich dachte immer, wenn
> man z.B. einen Mac als Zielserver benutzt, dann landet das direkt im
> Dateisystem - ...
Nope.
> ...aber dem ist dann wohl nicht so.
Genau. Auch mit OS X Server nicht.
> Ich habe es übers Netz
> bislang nur mit Netatalk und einer Linuxkiste probiert, und da läuft es
> eh' auf eine Sparse-Image/Bundle hinaus ... .
Tut es also immer.
Gruß Ralph
--
s/-nsp// for mail
Ralph Böhme
> Am 26.12.09 13:23, schrieb Dominik Schlütter:
>> Joern Bredereck <jo...@bredereck.net> schrieb:
>>
>>> Wenn ich das richtig verstehe, unterstützt Time-Machine von Haus aus ja
>>> nur externe USB/Firewire-Festplatten, welche dann direkt mit einem
>>> HFS-Dateisystem formatiert und angesprochen werden.
>>
>> Nein, man kann TimeMachine auch via AFP nutzen.
>
> HFS-Container sparen, weil AFP direkt die HFS-spezifischen
Apple _könnte_ sich den Umweg sparen, sie tun es aber nicht. Daher wie
nebenan geschrieben wird per AFP immer in ein Image gesichert.
>> Dazu hat Apple ein paar
>> Erweiterungen implementiert - und dann ist auf dem Zielsystem auch nicht
>> mehr so wichtig, welches Dateisystem benutzt wird. Da wird dann notfalls
>> halt in ein entsprechendes Sparse-Image gesichert.
>
> Ja. Und über diesen Sparse-Image-Klimmzug kann man das Image eben auch
> über Samba mounten, denn für den simplen File I/O-Zugriff auf diese eine
> Image-Datei tut's Samba allemal. Alle relevanten HFS-Meta-Informationen
> liegen dann innerhalb des Image und Samba bzw. das Dateisystem auf dem
> Server spielen überhaupt keine Rolle. Eine Beschränkung hat man dann
> höchstens noch in Form der maximalen Dateigrösse, die das Image-File
> haben darf.
>>> Mit etwas Googlen findet man dann allerdings Anleitungen, die beschreiben
>>> wie man eine wachsende HFS-Image-Datei auf einen NAS legen kann um dann
>>> dieses Image als Ziel für die Backups zu verwenden.
>>
>> Naja, man braucht auch noch einen passenden AFP-Server
>
> Nein, den sollte man eigentlich nicht brauchen, denn alles HFS-relevante
> findet innerhalb des Containers/Image-Files statt. Da tut's dann auch
> eine Samba-Share um in diese eine Image-Datei zu schreiben und daraus zu
> lesen.
Prinzipiell schon aber:
- x CIFS Implementationen, davon Samba als Beispiel:
- y Samba Versionen
- z Samba Optionen
Das macht dann halt den Unterschied zwischen supported, not-supported
und funktioniert, und not-supported und funktioniert nicht.
Es gibt eine eigene Spezifikation [1] für TMoverAFP die ansatzweise
aufzuzeigen vermag, was hier alles zu berücksichtigen ist.
>> also welcher Serverdienst dazu auf dem NAS (was für ein Gerät?) läuft
>> und wie du das eingebunden hast bzw. ansprichst.
>
> Was für ein Geräte dürfte keine Rolle spielen... ist eine simple
> SMB-Freigabe von meinem Digital-Receiver (Dreambox 8000).
> Das Anlegen und Mounten des Containers funktioniert. Ich kann problemlos
> in das gemountete HFS-Volume schreiben.
> Nur Time-Machine bietet mir dieses Volume leider nicht zum sichern an.
U.U. falsche bzw. veraltete Google Fundstellen genutzt. Mit 10.6 wird
afair im Image die MAC des Clients anders gespeichert.
-Ralph
--
s/-nsp// for mail
Joern Bredereck
Am 27.12.09 02:16, schrieb Dominik Schl�tter:
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Mit Diffamieren hat diese Feststellung nichts zu tun. Ich finde es
>> wirklich arm, wenn Apple es nicht schafft, eine Backup-L�sung zu
>> entwickeln, die mit einer simplen Samba-Freigabe klarkommt.
>
> Das sei dir unbenommen - aber du solltest vielleicht auch mal schauen,
> was Apple da anbietet. Das ist n�mlich eine wirklich einfach zu
> bedienende Backupl�sung, die zum einen mit Hardlinks jeweils
> "Komplettimages" liefert, zum anderen aber (und das ist IMHO der
> wirklich interessante Ansatz) �ber das reine Sichern von Einzeldateien
> hinausgeht und den Applikationen die M�glichkeit gibt, einzelne Objekte
> zu versionieren.
ich sehe ehrlich gesagt den Zusammenhang zwischen den von dir genannten
Features und der Unm�glichkeit der Verwendung einer CIFS-Share nicht.
Die von dir genannten Features haben mit dem Protokoll, welches zur
�bertragung der gesicherten Daten genutzt wird, nicht das geringste zu tun.
Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
andere Backup-Software auch bereitstellt? Ich kann mir das nicht
vorstellen und muss daher zu dem Schluss kommen, dass man dieses Feature
mit Absicht nicht einbaut, um den Verkauf von proprit�ren
Storage-L�sungen voranzutreiben.
Und sorry, aber es kommt dann schon ein bi�chen "fanboyisch" r�ber, wenn
jemand diese simple Marketing-Strategie zu ungunsten der Anwender auch
noch verteidigt und als etwas tolles darstellt.
> Um es jedem - wirklich jedem - einfach zu machen, ein aktuelles Backup
> zu nutzen, kann man einfach eine Platte anstecken und benutzen. Oder man
> nimmt einen passen konfigurierten Server (ja, Apple verkauft dazu z.B.
> die Time Capsule).
>
> Man kann jetzt nat�rlich sagen "oh, das ist mir alles zu einfach, ich
> m�chte aber meinen Server xy benutzen".
Wir reden hier nicht von einem esoterischen Filesharing-Protokoll "xy",
sondern von CIFS/SMB. Dem wohl unbestritten am weitesten verbreiteten
Filesharing-Protokoll �berhaupt.
Ich kann mich �brigens noch an die Diskussion in der Apple-Community
erinnern, als mit MacOS-X pl�tzlich CIFS-Support ins MacOS einzug
gehalten hat. Einige Fanboy-Hardliner haben darin den Niedergang des
apple'schen Abendlandes gesehen und haben CIFS als Windows-Teufelszeug
bezeichnet. Inzwischen lachen die meisten von uns dar�ber und k�nnen
sich ein MacOS ohne CIFS nicht mehr vorstellen. Und vielleicht werden
wir in ein paar Jahren auch dar�ber lachen, dass Apple tats�chlich
versucht hat CIFS bei seiner Backup-L�sung k�nstlich auszusperren.
Wenn ich ein Backup-Konzept entwerfe und dabei das Protokoll, dass
praktisch als kleinster gemeinsamer Nenner von jedem
Netzwerk-Storage-Device angeboten wird aussen vor lasse, dann muss ich
mir schon die Frage stellen lassen, warum ich sowas tue.
Technische Gr�nde k�nnen wir ausschliessen, denn anderen Herstellern
gen�gt CIFS als Transportprotokoll f�r die Backups. Bleiben also nur
noch Gr�nde im Bereich der Produktpolitik bzw. des Marketings.
> Wenn man dann das Basteln
> anf�ngt, ist der naheliegende Ansatz, Apples Spezifikationen m�glichst
> genau umzusetzen und z.B. die dort angebotenen Server zu kopieren. Das
> geht inzwischen z.B. mit Netatalk und Avahi - wenn man das einrichtet,
> klappt das �hnlich gut wie mit der Apfel-Hardware.
Unbestritten. Ich k�nnte mir jetzt nat�rlich ne kleine FreeBSD-Box mit
dem aktuellen Netatalk-Daemon und Avahi hinstellen. Aber warum einfach,
wenn's auch umst�ndlich geht...
> Du m�chtest dagegen, dass sich Apples Software so verh�lt, dass sie zu
> deinen vorhandenen (offensichtlich weniger geeigneten) Servern passt.
Reality-Check: Schau dir bitte mal an, wieviele Storage-Devices
angeboten werden, die lediglich CIFS "drin haben" und dann schau dir an,
wieviele Ger�te AFP/Avahi anbieten. AFP/Avahi ist eine absolute
Nischenl�sung, w�hrend der Rest der Welt CIFS spricht.
> Dazu wirst du bei Apple aber wenig Unterst�tzung finden, denn die haben
> ja schon ein funktionierendes Konzept mitsamt passender Hardware.
klar, wenn man mit proprit�ren L�sungen mehr Geld verdienen kann, ist
das eine nachvollziehbare Motivation. Was mich nur viel mehr wundert ist
die Tatsache, dass es anscheinend Leute gibt, die es auch noch toll
finden, zum Kauf diese proprit�ren L�sungen gen�tigt zu werden.
> Oder noch mal in aller K�rze: Apple ist es ziemlich egal, dass du das
> Ganze auf einem abgespeckten CIFS-Server betreiben m�chtest. Die haben
> schliessslich bereits eine funktionierende, einfache L�sung f�r das
> Backup-Problem entwickelt.
klar, ist nachvollziehbar. Aber jetzt nimm doch bite mal die
Fanboy-Brille ab und nenn mir einen Grund, warum du und ich das auch
noch toll finden sollten. W�re es nicht sch�ner, Apple w�rde die bereits
bestehenden Devices/Protokolle in seine Backup-L�sung integrieren,
anstatt diese aus rein finanziellen Gr�nden aussen vor zu lassen?
>> Aber mir einfach nur zu unterstellen, ich w�rde "diffamieren", ohne dich
>> inhaltlich damit auseinanderzusetzen halte ich f�r ein bisschen "billig".
>
> Sorry, aber du machst nicht den Eindruck, als h�ttest du dich mit den
> zugrundeliegenden Konzepten vertraut gemacht.
Also meine ersten AFP und Apple-Talk-Server habe im Jahr 2000
aufgesetzt. Wie Avahi/Bonjour funktioniert ist mir ebenfalls bekannt.
Und auch sonst kann ich von mir behaupten, mich beruflich mit
Netzwerkprotokollen und Backup-L�sungen zu besch�ftigen. Vielleicht habe
ich gerade deswegen auch ein etwas umfassenderes Bild von dem, was
technich m�glich w�re, wenn Apple nur wollte.
Nochmal: Wir sprechen hier nicht von einer technisch bedingten
Einschr�nkung, sondern von einer politisch gewollten.
> Stattdessen kommt von dir
> vor allem, dass irgendwas angeblich nicht ginge, obwohl es das sollte
> und �berhaupt sei das ja alles eine Selbstverst�ndlichkeit. Dem ist
> nicht so.
Nun ja, wenn man jahrelang t�glich mit Backup-L�sungen zu tun hat, die
technisch einwandfrei mit CIFS klarkommen, dann erwartet man irgendwie,
dass auch ein Hersteller wie Apple eine L�sung daf�r anbieten w�rde. Um
so entt�uschter ist man dann, wenn man feststellen muss, dass Apple hier
eine andere Agenda hat und lieber seine proprit�ren L�sungen verkaufen
m�chte.
>> Wenn du hingegen einfach nur deinen Unmut dar�ber zum Ausdruck bringen
>> willst, dass es tats�chlich jemand wagt Apple zu kritisieren, dann frage
>> ich mich, warum du genau das tust, was du in deinem "Disclaimer" als
>> nervend definierst.
>
> Du kritisierst Dinge, deren Sinn du anscheinend nicht verstanden hast.
> Das passiert halt im Usenet - nur solltest du die Chance nutzen und dich
> ein wenig zum Thema schlau machen. Das hilft. Wirklich.
Dann mach mich doch bitte mal schlau und erkl�re mir, warum Apple es
nicht schafft CIFS in Time-Machine zu supporten. Dass es technisch geht,
zeigen andere Hersteller.
>> Also lass uns bitte mal von dieser Meta-Diskussion herunterkommen und nenn
>> mir doch mal einen guten Grund, warum es von Apple keine Backup-L�sung
>> gibt, die in eine simple CIFS-Share sichern kann.
>
> Naja, gibts doch:
>
> | [alBook:~] dominik$ which rsync
> | /usr/bin/rsync
>
> Damit kannst du Kram nach Herzenslust durch die Gegend sichern.
Ich habe nach einer Backup-L�sung von Apple gefragt. Rsync ist ja nun
nicht wirklich von Apple.
> Wenn du fertige L�sungen suchst, hat
> Apple ebenfalls was anzubieten - das erfordert dann halt einen
> entsprechenden Server (und nein, der muss nicht von Apple kommen).
Dass er nicht von Apple kommen muss, l�st das Problem nicht wirklich.
Man wird gen�tigt, eine exotische L�sung nachzubauen, wo seit Jahren
etablierte und bew�hrte L�sungen vorhanden sind. Au�erdem kannst du
sicher sein, dass Apple die FreeBSD-basierten AFP-L�sungen auch ein Dorn
im Auge sind. Und es w�rde mich wundern, falls man im Falle eines
Problems mit diesen L�sungen von Apple irgendwelchen Support bekommen w�rde.
Gru�,
J�rn
Dominik Schlütter
> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
> in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
> andere Backup-Software auch bereitstellt?
Du stellst die Frage IMHO falsch. Apple hat schliesslich schon ein
"hauseigenes" Dateisystem, und es hat auch ein entsprechendes
Netzwerkprotokoll. F�r das neue Backupsystem baut man sich in Cupertino
dementsprechend eine L�sung, die auf diese bew�hrten Techniken aufsetzt
und diese weiterentwickelt (f�r TM gab es ja sowohl �nderungen an HFS+
als auch am AFP). Ob man da noch weitere L�sungen entwickeln k�nnte,
interessiert da erst mal nicht - genausowenig, was "praktisch jede
andere Backup-Software" bereitstellt.
> Ich kann mir das nicht vorstellen und muss daher zu dem Schluss kommen,
> dass man dieses Feature mit Absicht nicht einbaut, um den Verkauf von
> proprit�ren Storage-L�sungen voranzutreiben.
Es gibt Dokumentation dazu und es gibt alternative L�sungen. Deiner
Meinung nach w�re Apple also gescheitert, weil sie ihre propriet�re
L�sung nicht wie angeblich geplant als einzige ausnutzen k�nnen. Auf dem
Level "Apple ist b�se, weil sie mir nicht geben, was ich m�chte" ist
eine Diskussion IMHO wenig sinnvoll.
> Und sorry, aber es kommt dann schon ein bi�chen "fanboyisch" r�ber, wenn
> jemand diese simple Marketing-Strategie zu ungunsten der Anwender auch
> noch verteidigt und als etwas tolles darstellt.
TM via passendem AFP-Server funktioniert, mit CIFS dagegen geht es in
der Regel nicht. Das haben einige hier zu erkl�ren versucht.
Ich glaube, niemand hat die These vertreten, dass es besonders gut oder
w�nschenswert ist, dass nur ein Netzwerkprotokoll unterst�tzt wird. Du
hast dich dagegen immer beschwert, dass das, was du m�chtest, nicht
geht. Wenn jetzt das Aufzeigen funktionierender Alternativen einen zum
"Fanboy" macht - na gut. Dann sind wir wohl doch alle nur Fanboys hier.
> Wir reden hier nicht von einem esoterischen Filesharing-Protokoll "xy",
> sondern von CIFS/SMB. Dem wohl unbestritten am weitesten verbreiteten
> Filesharing-Protokoll �berhaupt.
Ja. Und wir reden von Macs, auf denen CIFS schon immmer h�chstens
halbherzig unterst�tzt wurde. Schau dir einfach mal ein paar Threads zum
Thema hier an - dass CIFS am Mac ein �rgernis ist, kommt schliesslich
mit sch�ner Regelm��igkeit aufs Tapet.
> Ich kann mich �brigens noch an die Diskussion in der Apple-Community
> erinnern, als mit MacOS-X pl�tzlich CIFS-Support ins MacOS einzug
> gehalten hat. Einige Fanboy-Hardliner haben darin den Niedergang des
> apple'schen Abendlandes gesehen und haben CIFS als Windows-Teufelszeug
> bezeichnet.
Nun - ich wei� nicht, wo du diese Diskussion mitbekommen hast, hier war
es wohl nicht. Hier wurden eigentlich h�chstens Dateinamensendungen,
Intel-CPUs oder ganz allgemein Mac OS X als "das Ende", "das B�se" etc.
angesehen :-P.
> Wenn ich ein Backup-Konzept entwerfe und dabei das Protokoll, dass
> praktisch als kleinster gemeinsamer Nenner von jedem
> Netzwerk-Storage-Device angeboten wird aussen vor lasse, dann muss ich
> mir schon die Frage stellen lassen, warum ich sowas tue.
Nochmal: deine Fragestellung ist falsch. Apple wollte nicht hingehen und
eine Backupl�sung entwerfen, die auf m�glichst vielen Ger�ten im
Netzwerk funktioniert. Der Ansatz dort war ein anderer, er basierte auf
minimaler Konfiguration, m�glichst hoher Abstraktion des
Sicherungsprozesses - oder kurz: darauf, dass Leute ohne Ahnung von
Computern ohne Aufwand dazu zu bringen, Backups zu machen. Dazu hat man
sich hingesetzt und eine L�sung �berlegt.
Das ist nat�rlich auch nicht "die endg�ltige L�sung". Wenn es dir eher
darum geht, Dateien �bers Netz zu sichern, dann gibt es ja auch immer
noch andere Backup-Applikationen, die auch am Mac laufen. Da ist dann
vielleicht CIFS auch nicht problematisch (oder zumindest nicht
problematischer als sonst am Mac).
> Technische Gr�nde k�nnen wir ausschliessen, denn anderen Herstellern
> gen�gt CIFS als Transportprotokoll f�r die Backups. Bleiben also nur
> noch Gr�nde im Bereich der Produktpolitik bzw. des Marketings.
Wer ist denn "wir", die da die technischen Gr�nde ausschlie�en k�nnen?
Oder bezeichnet das einfach alle "nicht-Fanboys" - also alle, die dir
nicht widersprechen?
> Reality-Check: Schau dir bitte mal an, wieviele Storage-Devices
> angeboten werden, die lediglich CIFS "drin haben" und dann schau dir an,
> wieviele Ger�te AFP/Avahi anbieten.
Reality-Check: Schau dir bitte mal an, was Apple mit TM (z.B. laut ihrer
Eigendarstellung) bezwecken will und an wen sich das richtet. Das Ziel
war nicht, auf m�glichst vielen NAS zu laufen.
> Was mich nur viel mehr wundert ist die Tatsache, dass es anscheinend Leute
> gibt, die es auch noch toll finden, zum Kauf diese proprit�ren L�sungen
> gen�tigt zu werden.
Ich wei� nicht, wo du diese Leute getroffen hast. Aber du scheinst eine
Erl�uterung des Status Quo mit einer Rechtfertigung zu verwechseln. Aber
ich wiederhole mich.
> Aber jetzt nimm doch bite mal die Fanboy-Brille ab und nenn mir einen
> Grund, warum du und ich das auch noch toll finden sollten.
Nochmal: Niemand verlangt von dir, dass du das toll finden sollst.
Stattdessen will man dir hier erkl�ren, was es mit der "normativen Kraft
des Faktischen" auf sich hat. Wenn du ein TM-Backup �bers Netz machen
willst, dann kommst du mit CIFS halt nicht weit. Egal, ob du das toll
findest oder nicht.
Gru�,
Dominik.
Michael Lestinsky
> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
> in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
> andere Backup-Software auch bereitstellt?
Dann nutze diese andere Backup-Software doch einfach, anstatt hier
herumzumaulen! Niemand zwingt dich Time Machine f�r Remote-Backup
einzusetzen.
Bye,
Michael
Joern Bredereck
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
>> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
>> in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
>> andere Backup-Software auch bereitstellt?
>
> Du stellst die Frage IMHO falsch.
nun, versuch doch bitte erstmal die Frage zu beantworten. Glaubst du
wirklich Apple w�rde es nicht mit CIFS hinbekommen, wenn Sie es nur wollten?
> Apple hat schliesslich schon ein
> "hauseigenes" Dateisystem, und es hat auch ein entsprechendes
> Netzwerkprotokoll. F�r das neue Backupsystem baut man sich in Cupertino
> dementsprechend eine L�sung, die auf diese bew�hrten Techniken aufsetzt
> und diese weiterentwickelt (f�r TM gab es ja sowohl �nderungen an HFS+
> als auch am AFP). Ob man da noch weitere L�sungen entwickeln k�nnte,
> interessiert da erst mal nicht - genausowenig, was "praktisch jede
> andere Backup-Software" bereitstellt.
Naja, die Frage ist doch ganz simpel: Unterst�tze ich etablierte
Techniken und Standards, oder erfinde ich das Rad neu und verkaufe dann
mein Rad+ und stelle als Alibi noch die Specs f�r Rad+ zur Verf�gung.
>> Ich kann mir das nicht vorstellen und muss daher zu dem Schluss kommen,
>> dass man dieses Feature mit Absicht nicht einbaut, um den Verkauf von
>> proprit�ren Storage-L�sungen voranzutreiben.
>
> Es gibt Dokumentation dazu und es gibt alternative L�sungen. Deiner
> Meinung nach w�re Apple also gescheitert, weil sie ihre propriet�re
> L�sung nicht wie angeblich geplant als einzige ausnutzen k�nnen.
Nunja, zwischen "scheitern" und "100%ig erfolgreich" sein, gibts ja noch
die eine oder andere Abstufung. Wenn Apple auch nur eine einzige
Time-Capsule mehr verkauft, weil das vorhandene CIFS-Nas nicht zu
gebrauchen ist, dann war das Kalk�l schon erfolgreich.
Dass ver�ffentlichen von Specs ist �brigens immer wieder ein
gerngenommener Alibi-Stunt: Seht her, wir sind gar nicht b�se, denn wir
erlauben ja auch anderen Herstellern unser neu erfundenes Rad+ zu bauen.
Dass es kundenfreundlicher w�re, wenn Rad+ zu Rad1.0 r�ckw�rtskompatibel
w�re, wird bei dieser Gelegenheit dann gerne verschwiegen.
> Auf dem
> Level "Apple ist b�se, weil sie mir nicht geben, was ich m�chte" ist
> eine Diskussion IMHO wenig sinnvoll.
aha, also ist Kritik an Apples Strategie mal wieder nicht erw�nscht.
>> Und sorry, aber es kommt dann schon ein bi�chen "fanboyisch" r�ber, wenn
>> jemand diese simple Marketing-Strategie zu ungunsten der Anwender auch
>> noch verteidigt und als etwas tolles darstellt.
>
> TM via passendem AFP-Server funktioniert, mit CIFS dagegen geht es in
> der Regel nicht. Das haben einige hier zu erkl�ren versucht.
Richtig. Und ich bin jetzt schon einen Schritt weiter und versuche zu
hinterfragen warum dem so ist. Und vor allem w�rde mich interessieren,
was Leute wie dich dazu bewegt diese Situation gutzuheissen oder zu
verteidigen.
> Ich glaube, niemand hat die These vertreten, dass es besonders gut oder
> w�nschenswert ist, dass nur ein Netzwerkprotokoll unterst�tzt wird. Du
> hast dich dagegen immer beschwert, dass das, was du m�chtest, nicht
> geht. Wenn jetzt das Aufzeigen funktionierender Alternativen einen zum
> "Fanboy" macht - na gut. Dann sind wir wohl doch alle nur Fanboys hier.
Nicht das Aufzeigen macht dich zum Fanboy, sondern die Art und Weise,
wie du diese offensichtlich k�nstlich auferlegte Beschr�nkung auf AFP
auch noch gutheisst.
>> Wir reden hier nicht von einem esoterischen Filesharing-Protokoll "xy",
>> sondern von CIFS/SMB. Dem wohl unbestritten am weitesten verbreiteten
>> Filesharing-Protokoll �berhaupt.
>
> Ja. Und wir reden von Macs, auf denen CIFS schon immmer h�chstens
> halbherzig unterst�tzt wurde. Schau dir einfach mal ein paar Threads zum
> Thema hier an - dass CIFS am Mac ein �rgernis ist, kommt schliesslich
> mit sch�ner Regelm��igkeit aufs Tapet.
oha, und ich dachte, die Apple-Community h�tte endlich begriffen, dass
Interoperabelit�t doch nicht so ganz unwichtig ist. Aber anscheinend
gibt es immernoch Leute, die an der "guten alten Zeit", in der bei Apple
ALLES proprit�r war, festhalten m�chten.
Ich k�nnte jetzt �brigens auch ganz lapidar antworte: auf anderen
Plattformen funktoniert CIFS/SMB realtiv schmerzfrei. Wenn's unter MacOS
Probleme gibt, sollte man sich vielleicht mal die dortige
Implementierung genauer anschauen. Mir sind allerdings auch auf dem Mac
mit CIFS noch keine Probleme untergekommen, von daher kann ich deine
Andeutungen so auch nicht nachvollziehen.
>> Ich kann mich �brigens noch an die Diskussion in der Apple-Community
>> erinnern, als mit MacOS-X pl�tzlich CIFS-Support ins MacOS einzug
>> gehalten hat. Einige Fanboy-Hardliner haben darin den Niedergang des
>> apple'schen Abendlandes gesehen und haben CIFS als Windows-Teufelszeug
>> bezeichnet.
>
> Nun - ich wei� nicht, wo du diese Diskussion mitbekommen hast, hier war
> es wohl nicht. Hier wurden eigentlich h�chstens Dateinamensendungen,
> Intel-CPUs oder ganz allgemein Mac OS X als "das Ende", "das B�se" etc.
> angesehen :-P.
:-) Wie ich sehe, verstehst du worauf ich anspielen wollte.
>> Wenn ich ein Backup-Konzept entwerfe und dabei das Protokoll, dass
>> praktisch als kleinster gemeinsamer Nenner von jedem
>> Netzwerk-Storage-Device angeboten wird aussen vor lasse, dann muss ich
>> mir schon die Frage stellen lassen, warum ich sowas tue.
>
> Nochmal: deine Fragestellung ist falsch. Apple wollte nicht hingehen und
> eine Backupl�sung entwerfen, die auf m�glichst vielen Ger�ten im
> Netzwerk funktioniert.
ja, so siehts aus. Und da m�sste doch die Frage gestattet sein, WARUM
das so ist?
> Der Ansatz dort war ein anderer, er basierte auf
> minimaler Konfiguration, m�glichst hoher Abstraktion des
> Sicherungsprozesses - oder kurz: darauf, dass Leute ohne Ahnung von
> Computern ohne Aufwand dazu zu bringen, Backups zu machen. Dazu hat man
> sich hingesetzt und eine L�sung �berlegt.
Das eine schliesst das andere nicht aus. Man k�nnte die jetzige L�sung
inkl. AFP/Bonjour durchaus beibehalten und um eine abgespeckte
CIFS-Variante ERG�NZEN. Will Apple aber nicht. Wo k�men wir denn da hin,
wenn die �berteuerte Time-Capsule kein Alleinstellungsmerkmal gegen�ber
99% der anderen NAS-L�sungen h�tte.
> Das ist nat�rlich auch nicht "die endg�ltige L�sung". Wenn es dir eher
> darum geht, Dateien �bers Netz zu sichern, dann gibt es ja auch immer
> noch andere Backup-Applikationen, die auch am Mac laufen. Da ist dann
> vielleicht CIFS auch nicht problematisch (oder zumindest nicht
> problematischer als sonst am Mac).
ich werde mir jetzt erstmal Time-Machine �ber iSCSI anschauen. Das
sollte ja dann hoffentlich problemlos funktionieren, weil die Schichten
hierbei noch weiter abstrahiert sind. Aus Sicht von Time-Machine wird
dann auf ne lokale SCSI-Platte gesichert.
>> Technische Gr�nde k�nnen wir ausschliessen, denn anderen Herstellern
>> gen�gt CIFS als Transportprotokoll f�r die Backups. Bleiben also nur
>> noch Gr�nde im Bereich der Produktpolitik bzw. des Marketings.
>
> Wer ist denn "wir", die da die technischen Gr�nde ausschlie�en k�nnen?
ich h�tte auch "man" schreiben k�nnen.
> Oder bezeichnet das einfach alle "nicht-Fanboys" - also alle, die dir
> nicht widersprechen?
ich w�re dir dankbar, wenn wir uns diesen infantilen Exkurs sparen
k�nnen, danke.
>> Reality-Check: Schau dir bitte mal an, wieviele Storage-Devices
>> angeboten werden, die lediglich CIFS "drin haben" und dann schau dir an,
>> wieviele Ger�te AFP/Avahi anbieten.
>
> Reality-Check: Schau dir bitte mal an, was Apple mit TM (z.B. laut ihrer
> Eigendarstellung) bezwecken will und an wen sich das richtet. Das Ziel
> war nicht, auf m�glichst vielen NAS zu laufen.
Bitte nenn mir eine schl�ssige Begr�ndung warum das eine das andere
ausschliessen sollte. Man k�nnte durchaus beide Optionen anbieten:
One-Klick-Backup/Restore �ber AFP/Bonjour f�r weniger Technik-afine
Anwender mit dickerem Geldbeutel und eine manuelle L�sung f�r Leute, die
mit dem manuellen Anlegen einer Sparse-Datei auf einem CIFS-Share nicht
�berfordert sind und im Gegenzug ihr bestehendes Equipment nicht
wegschmeissen m�ssen.
Wenn Apple das wollte, w�re es m�glich. Sie wollen nur nicht. Und das
kann man jetzt entweder sch�nreden, oder man kann es kritisieren. Du
tust das erstere, ich tue das letztere.
>> Was mich nur viel mehr wundert ist die Tatsache, dass es anscheinend Leute
>> gibt, die es auch noch toll finden, zum Kauf diese proprit�ren L�sungen
>> gen�tigt zu werden.
>
> Ich wei� nicht, wo du diese Leute getroffen hast. Aber du scheinst eine
> Erl�uterung des Status Quo mit einer Rechtfertigung zu verwechseln. Aber
> ich wiederhole mich.
Dann mal Butter bei die Fische: Findest du es gut, dass Apple die
CIFS-Option wegl�sst, obwohl es technisch durchaus m�glich w�re?
>> Aber jetzt nimm doch bite mal die Fanboy-Brille ab und nenn mir einen
>> Grund, warum du und ich das auch noch toll finden sollten.
>
> Nochmal: Niemand verlangt von dir, dass du das toll finden sollst.
Gut. Dann gestatte mir bitte aber auch, dies zu kritisieren ohne dich in
deiner Ehre als (anscheinend �berzeugter) Apple-User angegriffen zu
f�hlen. Oder ist Kritik hier grunds�tzlich unerw�nscht?
Gru�,
J�rn
Joern Bredereck
>> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
>> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
>> in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
>> andere Backup-Software auch bereitstellt?
>
> Dann nutze diese andere Backup-Software doch einfach, anstatt hier
> herumzumaulen! Niemand zwingt dich Time Machine f�r Remote-Backup
> einzusetzen.
Du hast "hier ist keine Kritik an Apple-Produkten erw�nscht" etwas
seltsam formuliert. Da habe ich aber schon Fanboys erlebt, die sich
etwas mehr M�he gegeben haben.
Michael Lestinsky
Deine Argumentationslinie ist d�mlich.
Niemand hier behauptet, die Applel�sung sei perfekt und �ber alle Kritik
erhaben. Aber wenn dein Pflichtenheft von der Applel�sung eben nicht
erf�llt wird, w�re der rationale Ansatz, die Anforderung "muss von Apple
sein" fallen zu lassen, und sich nach Alternativen umzuschauen.
Viel Spass noch.
Michael
Joern Bredereck
>> seltsam formuliert. Da habe ich aber schon Fanboys erlebt, die sich
>> etwas mehr M�he gegeben haben.
>
> Deine Argumentationslinie ist d�mlich.
und an deinen Umgangsformen k�nntest du mal arbeiten, aber das ist ein
anderes Thema.
> Niemand hier behauptet, die Applel�sung sei perfekt und �ber alle Kritik
> erhaben.
Sch�n. Dann lass uns doch bitte sachlich und ohne ideologische
Vorbehalte �ber diese Flaws diskutieren. Was spricht dagegen? Wenn die
Apple-Community so krittikf�hig ist, wie du sie hier darstellst, dann
sollte das doch gar kein Problem sein.
André Igler
> Am 27.12.09 13:12, schrieb Michael Lestinsky:
>
>>> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
>>> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
>>> andere Backup-Software auch bereitstellt?
>>
>> Dann nutze diese andere Backup-Software doch einfach, anstatt hier
>> einzusetzen.
>
> Du hast "hier ist keine Kritik an Apple-Produkten erwünscht" etwas
> seltsam formuliert. Da habe ich aber schon Fanboys erlebt, die sich
Heast, jetzt reicht's aber. Du postest absolut Schwachsinn.
Auf z.B. Pkw umgelegt beschwerst Du Dich gerade darüber, dass auf Deinen
Volkswagen Glof die Kupplung vom Mazda nicht "out of the box" passt. Es
gibt zwar sogar einen Adapterkit für die Mazdakupplung von VW, aber der
passt Dir nicht, weil Du kannst ihn nur bei VW kaufen.
In einer anderen NG hätten Sie Dich schon längst hinausgeflämmt.
Überlege Dir mal, was Du da postest. *kopfschüttel* Leute gibts.
addio
--
pm <mein vorname> bei <mein nachname> punkt at
http://weblog.igler.at www.albinschwarz.com
Michael Lestinsky
> Am 27.12.09 13:59, schrieb Michael Lestinsky:
>> * Joern Bredereck<jo...@bredereck.net>:
>>
>>> Du hast "hier ist keine Kritik an Apple-Produkten erw�nscht" etwas
>>> seltsam formuliert. Da habe ich aber schon Fanboys erlebt, die sich
>>> etwas mehr M�he gegeben haben.
>>
>> Deine Argumentationslinie ist d�mlich.
>
> und an deinen Umgangsformen k�nntest du mal arbeiten, aber das ist ein
> anderes Thema.
Ach, jeden, der dir widerspricht als religi�sen Fanboy zu diffamieren ist
ein besserer Umgangston?
Bye,
Michael
Joern Bredereck
> * Joern Bredereck <jo...@bredereck.net>:
>
>>> Deine Argumentationslinie ist d�mlich.
>>
>> und an deinen Umgangsformen k�nntest du mal arbeiten, aber das ist ein
>> anderes Thema.
>
> Ach, jeden, der dir widerspricht als religi�sen Fanboy zu diffamieren ist
> ein besserer Umgangston?
warum f�hlst du dich angesprochen? Wo habe ich geschrieben, Du seist ein
Fanboy?
Joern Bredereck
> Am 27.12.09 13:43, schrieb Joern Bredereck:
>> Am 27.12.09 13:12, schrieb Michael Lestinsky:
>>
> Volkswagen Glof die Kupplung vom Mazda nicht "out of the box" passt.
Nein, keineswegs. Übertragen auf PKWs beschwere ich mich darüber dass
ich mein neues "Apple-Mobil" nicht an normalen Tankstellen betankt
werden kann, sondern dass ich zu überteuerten Apple-Tankstellen fahren
muss, um dort zu tanken, weil Apple dafür gesorgt hat, dass die
regulären Tankrüssel nicht passen.
Und dann bekomme ich noch zu hören: Wäre doch gar kein Problem,
schliesslich hat Apple ja die neuen Tankrüssel spezifiziert und es
würden anderen Tankstellenbetreibern ja freistehen auch Apple-Tankrüssel
bereitzustellen.
> In einer anderen NG hätten Sie Dich schon längst hinausgeflämmt.
jaja... ich verbeuge mich in Dehmut ob dieser unbeschreiblichen Toleranz
und Kritifähigkeit. *g*
Ralph Böhme
> Am 27.12.09 14:13, schrieb André Igler:
>> Am 27.12.09 13:43, schrieb Joern Bredereck:
>>> Am 27.12.09 13:12, schrieb Michael Lestinsky:
>>>
>> Auf z.B. Pkw umgelegt beschwerst Du Dich gerade darüber, dass auf Deinen
>> Volkswagen Glof die Kupplung vom Mazda nicht "out of the box" passt.
>
> Nein, keineswegs. Übertragen auf PKWs beschwere ich mich darüber dass
> ich mein neues "Apple-Mobil" nicht an normalen Tankstellen betankt
> werden kann, sondern dass ich zu überteuerten Apple-Tankstellen fahren
> muss, um dort zu tanken, weil Apple dafür gesorgt hat, dass die
> regulären Tankrüssel nicht passen.
Nope. Eigentlich beschwerst du dich darüber dass du beim Googeln
falsch abgebogen bist, da du nicht auf Details achtest und das unter
einem Schwall Admin-Geblubber verbirgst. Und diejenigen die dir die
Details erklären könnten vergraulst du hier, das es ein Vergnügen ist.
Hausaufgabe:
Was sind CNIDs?
Welche Dateizugriffssemantiken werden durch CNIDs ermöglicht?
Wie werden die per CIFS emuliert?
Hat das direkt was mit TM zu tun?
Sind die Semantiken vom CIFS und AFP am Mac gleich?
-Ralph
--
s/-nsp// for mail
Joern Bredereck
> Nope. Eigentlich beschwerst du dich darüber dass du beim Googeln
> falsch abgebogen bist, da du nicht auf Details achtest und das unter
> einem Schwall Admin-Geblubber verbirgst.
willst du das mal näher erläutern? Wo bin ich falsch abgebogen? Die
Howto's die unter 10.5 funktioniert zu haben scheinen, funktionieren
augenscheinlich unter 10.6 nicht mehr.
Nachdem ich anfangs davon ausging, dass ein Workaround über CIFs
durchaus möglich wäre, habe ich mich inzwischen damit abgefunden dass
Apple alles unternommen hat, um CIFS für die Time-Machine-Sicherung
praktisch unmöglich zu machen.
> Und diejenigen die dir die
> Details erklären könnten vergraulst du hier, das es ein Vergnügen ist.
Ach, die meisten Leute die mir geantwortet haben, hatten sich doch nur
angegriffen gefühlt, weil es jemand wagt IHR System zu kritisieren. Als
jemand der schon in den 80ern die Ataris versus Amiga-System-Kriege
miterlebt hat, weiss ich ziemlich genau, was ich von solchem ideologisch
motivierten Geschwätz zu halten habe. Wer es nicht schafft, vorbehaltlos
und ohne ideologische Hintergründe über technische Zusammenhänge zu
diskutieren, der kann mir wirklich gestohlen bleiben. Sollte ich solche
Leute verprellt haben, werde ich damit leben müssen.
> Hausaufgabe:
> Was sind CNIDs?
das dürften die ACLs unter AFP sein. Mir ist nur nicht klar, worauf du
hinauswillst.
> Welche Dateizugriffssemantiken werden durch CNIDs ermöglicht?
> Wie werden die per CIFS emuliert?
Wenn man wollte wäre das durch einen Container abbildbar. Man müsste
lediglich die Layer sauber abstrahieren und diesen Container als
stinknormales Block-Device verwenden.
Unter den gängigen Unices kann man sich jede beliebige Datei über
"losetup" zu einem Loopback-Device mounten und dann dieses
Loopback-Device als Blockdevice ansprechen. Aus Sicht der Anwendungen
handelt es sich um eine stinknormale Festplatte bzw. eine
Festplatten-Partition. Wo diese Image-Datei lieg, ist dabei vollkommen
irrelevant. Sämtliche Logik des Filesystem/Anwendungs-Layers findet
dabei innerhalb des Containers statt. Auf dem Layer unten drunten sorgen
simple File I/O-Funktionen lediglich für die notwendigen
Lowlevel-Lese-Schreib-Zugriffe. Und dabei ist es vollkommen egal, über
welches Protokoll diese Zugriffe stattfinden. CIFS eignet sich hier als
simples I/O-Filesharing-Protokoll allemal. CIFs muss genauso HFS-unaware
sein, wie mein SATA-Festplatten-Controller HFS-unaware ist. Das ist ein
komplett anderer Layer der sich sauber abstrahieren lässt - WENN man
denn nur will. Wenn man natürlich seiner Anwendung sagt: Schreib bitte
nur in Volumes, die zuvor per Bonjour als TM-worthy announced werden,
dann klappt das natürlich nicht. Und genau das scheint Apple leider zu
machen.
Ich habe übrigens eben versucht eine Image-Datei auf einer externen
USB-Platte zu erstellen und dann dieses Image als Volume zu mounten. Das
hat auch funktioniert, aber TM bietet mir dieses Volume natürlich wieder
nicht als gültiges Backup-Volume an.
Kannst du mir erklären, was dagegen sprechen würde, in dieses Volume zu
sichern? Es handelt sich hier aus Anwendungs-Sicht um ein vollwertiges
HFS-Volume. Welche Einschränkungen würden TM nun daran hindern in dieses
Volume seine Backups zu schreiben?
> Hat das direkt was mit TM zu tun?
Mir stellt es sich momentan so dar, dass TM absichtlich derartige
Volumes aussperrt, damit ja niemand auf die Idee kommt, etwas anderes
als einen AFP-Server oder eine Time-Capsule zu verwenden.
> Sind die Semantiken vom CIFS und AFP am Mac gleich?
müssen Sie nicht sein. Denn TM müsste nicht direkt in eine CIFS-Share
schreiben, sondern könnte problemlos in ein lokales HFS-Volume
schreiben. Dieses HFS-Volume würde alle benötigten Features
bereitstellen. Über den Schreibzugriff in den per CIFS bereitgestellten
Container hat sich einzig und allein der Kernel (bzw. die
SMB-Userland-Tools) zu kümmern. TM müsste mit diesem Layer überhaupt
nicht in Berührung kommen.
Ich bin jetzt mal gespannt, ob es klappt, wenn man die Layer per iSCSI
abstrahiert. Bei Google habe ich Blog-Einträge von Leuten gefunden, die
das hinbekommen haben.
Gruß,
Jörn
Ralph Böhme
> Am 27.12.09 15:33, schrieb Ralph Böhme:
>> Nope. Eigentlich beschwerst du dich darüber dass du beim Googeln
>> falsch abgebogen bist, da du nicht auf Details achtest und das unter
>> einem Schwall Admin-Geblubber verbirgst.
>
> willst du das mal näher erläutern? Wo bin ich falsch abgebogen? Die
> Howto's die unter 10.5 funktioniert zu haben scheinen, funktionieren
> augenscheinlich unter 10.6 nicht mehr.
Klar. Weil afaik mit 10.6 einfach die MAC-Adresse des Clients anders
untergebracht werden will. Wie ich bereits schrieb. Und das gilt für
sowohl AFP als auf CIFS. Vertmutlich arbeitest du dich halt an den
veralteten Howtos ab.
> Nachdem ich anfangs davon ausging, dass ein Workaround über CIFs
> durchaus möglich wäre, habe ich mich inzwischen damit abgefunden dass
> Apple alles unternommen hat, um CIFS für die Time-Machine-Sicherung
> praktisch unmöglich zu machen.
Und unter anderem dieser Schluss ist mindestens voreilig, wenn nicht
falsch. Von dieser Problematik ist afair AFP genauso betroffen. Und das..
>> Und diejenigen die dir die
>> Details erklären könnten vergraulst du hier, das es ein Vergnügen ist.
>
> ... Ach, die meisten Leute die mir geantwortet haben, hatten sich doch
> nur angegriffen gefühlt, weil es jemand wagt IHR System zu kritisieren.
...haben dir einige Leute versucht zu verknusen. So habe ist jedefalls
mein Eindruck des Threads. Unter anderem hast du hier jemanden falsch
verstanden der mit sehr großen Wahrscheinlichkeit schon mehr Netz-
traces von sowohl AFP als auch CIFS analysiert hat als du.
> Als
> jemand der schon in den 80ern die Ataris versus Amiga-System-Kriege
> miterlebt hat, weiss ich ziemlich genau, was ich von solchem ideologisch
> motivierten Geschwätz zu halten habe. Wer es nicht schafft, vorbehaltlos
> und ohne ideologische Hintergründe über technische Zusammenhänge zu
> diskutieren, der kann mir wirklich gestohlen bleiben. Sollte ich solche
> Leute verprellt haben, werde ich damit leben müssen.
Mein Eindruck des Threads ist ein anderer. Hier wurde versucht deinen
voreiligen und falschen Schlüsse zu hinterfragen und korrigieren.
Worauf du in den flame-war Modus geweschselt bist.
>> Hausaufgabe:
>> Was sind CNIDs?
>
> das dürften die ACLs unter AFP sein.
Nein. Ein bischen mehr Mühe hättest du dir schon geben könne, so
machts keinen Spaß.
Aber zugegeben, der war etwas gemein, CNIDs ist wohl Netatalk-Lingo.
Steht für "catalog node id" und besagt in etwa, dass Dateien und Ordner
im Dateisystem eine konstante, eindeutige, indizierbare Nummer haben.
Hervorzuheben ist dabei u.a., dass dies Zugriffssemantiken ermöglicht
bei der nicht mit Pfaden gearbeitet wird, sondern implizit einfach mit
dieser CNID (keine Ahnung welches die aktuelle OS X API dafür ist,
FSRef? Alias Manager?).
Gescheite AFP Server bzw. das AFP Protokoll unterstützen diese
Semantiken, CIFS nicht -- ist in der Spezifikation gar nicht vorgesehen.
Apple berücksichtigt das entsprechend und gibt in Applikationen die
APIs nutzen die auf bestimmten Volumes nicht funken die entsprechenden
Fehlercodes aus.
Und damit sind wir da worauf ...
> Mir ist nur nicht klar, worauf du hinauswillst.
...ich hinauswill: es gibt prinzipielle sematische Unterschiede
zwischen CIFS am Mac und AFP am Mac. Und solange Apple nicht die
entsprechenden APIs rausschmeißt (oder Programme sie nicht mehr
nutzen -- was aktuell leider der Trend ist) bleibt es dabei.
Das Ganze hat mit TM erstmal nur soviel zu tun, als dass es dich
dafür sensibilisieren soll, das die Dinge komplexer sind als du
sie darstellst.
>> Welche Dateizugriffssemantiken werden durch CNIDs ermöglicht?
Den hatten wir nun schon.
>> Wie werden die per CIFS emuliert?
>
> Wenn man wollte wäre das durch einen Container abbildbar. Man müsste
> lediglich die Layer sauber abstrahieren und diesen Container als
> stinknormales Block-Device verwenden.
Gute Idee. Und an welcher Stelle ist das in den CIFS Specs
beschrieben?
> Unter den gängigen Unices kann man sich jede beliebige Datei über
> "losetup" zu einem Loopback-Device mounten und dann dieses
> Loopback-Device als Blockdevice ansprechen. Aus Sicht der Anwendungen
> handelt es sich um eine stinknormale Festplatte bzw. eine
> Festplatten-Partition. Wo diese Image-Datei lieg, ist dabei vollkommen
> irrelevant. Sämtliche Logik des Filesystem/Anwendungs-Layers findet
> dabei innerhalb des Containers statt. Auf dem Layer unten drunten sorgen
> simple File I/O-Funktionen lediglich für die notwendigen
> Lowlevel-Lese-Schreib-Zugriffe. Und dabei ist es vollkommen egal, über
> welches Protokoll diese Zugriffe stattfinden. CIFS eignet sich hier als
> simples I/O-Filesharing-Protokoll allemal. CIFs muss genauso HFS-unaware
> sein, wie mein SATA-Festplatten-Controller HFS-unaware ist. Das ist ein
> komplett anderer Layer der sich sauber abstrahieren lässt - WENN man
> denn nur will. Wenn man natürlich seiner Anwendung sagt: Schreib bitte
> nur in Volumes, die zuvor per Bonjour als TM-worthy announced werden,
> dann klappt das natürlich nicht. Und genau das scheint Apple leider zu
> machen.
Soweit das meiste ganz richtig. Die Schlussfolgerung wieder Quatsch.
Nochmal: es gab/gibt ganz ähnliche Probleme mit 10.6 und TM Sicherung
per AFP auf NAS Schraddel. Der Grund ist wie beschrieben wohl einer
wie oben angemerkt.
> Ich habe übrigens eben versucht eine Image-Datei auf einer externen
> USB-Platte zu erstellen und dann dieses Image als Volume zu mounten. Das
> hat auch funktioniert, aber TM bietet mir dieses Volume natürlich wieder
> nicht als gültiges Backup-Volume an.
>
> Kannst du mir erklären, was dagegen sprechen würde, in dieses Volume zu
> sichern?
Hast du unter anderem diesen "defaults write show-unsupported-network-
volumes" Kram gemacht? Etc. Ich tippe einfach drauf dass du veraltete
Howtos umsetzt.
> Es handelt sich hier aus Anwendungs-Sicht um ein vollwertiges
> HFS-Volume. Welche Einschränkungen würden TM nun daran hindern in dieses
> Volume seine Backups zu schreiben?
Wohl nicht das richtige IM Volume.
>> Hat das direkt was mit TM zu tun?
>
> Mir stellt es sich momentan so dar, dass TM absichtlich derartige
> Volumes aussperrt, damit ja niemand auf die Idee kommt, etwas anderes
> als einen AFP-Server oder eine Time-Capsule zu verwenden.
Schlicht falsch. Punkt.
>> Sind die Semantiken vom CIFS und AFP am Mac gleich?
> müssen Sie nicht sein. Denn TM müsste nicht direkt in eine CIFS-Share
> schreiben, sondern könnte problemlos in ein lokales HFS-Volume
> schreiben. Dieses HFS-Volume würde alle benötigten Features
> bereitstellen. Über den Schreibzugriff in den per CIFS bereitgestellten
> Container hat sich einzig und allein der Kernel (bzw. die
> SMB-Userland-Tools) zu kümmern. TM müsste mit diesem Layer überhaupt
> nicht in Berührung kommen.
Siehe oben: OS X hat halt Funktionalitäten und Semantiken die u.a.
Linux und CIFS in der Form nicht kennt: CNIDs. Und daher ist deine
Aussage nicht falsch, sondern einfach am Thema vorbei.
> Ich bin jetzt mal gespannt, ob es klappt, wenn man die Layer per iSCSI
> abstrahiert. Bei Google habe ich Blog-Einträge von Leuten gefunden, die
> das hinbekommen haben.
Klar funktioniert das. Denn das IST ein anderer Layer.
Thomas Kaiser
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Nachdem ich anfangs davon ausging, dass ein Workaround über CIFs
>> durchaus möglich wäre, habe ich mich inzwischen damit abgefunden dass
>> Apple alles unternommen hat, um CIFS für die Time-Machine-Sicherung
>> praktisch unmöglich zu machen.
>
> Und unter anderem dieser Schluss ist mindestens voreilig, wenn nicht
> falsch.
Vielleicht solltest Du ihn nochmal auf die Apple-Specs stubsen, die Du
bereits in diesem Thread gepostet hast?
Locking, AFP Reconnects und inzwischen Replay Cache als für Apple
offensichtlich notwendige Voraussetzungen, um ihre Implementierung von
TM sinnvoll und ausreichend performant übers Netzwerk fahren zu können.
Einfach um sicherzustellen, daß ein Backup übers Netzwerk genauso
deppensicher und auch von wenig technikaffinen Menschen _beherrschbar_
ist, wie ein lokales. Was gibt's davon in sicher funktionierend auf
beliebigen SMB-/CIFS-Servern? Genau: Exakt gar nichts. Und das hat
nichts mit HFS+ Semantiken _innerhalb_ des TM-Sparsebundles zu tun,
sondern damit, die einzelnen Streifen des SparseBundles auch sicher
schreiben zu können, Speicherplatz wieder freigeben zu können, etc.
Schließlich denkt Apple bei Backup nicht nur an Backup sondern an das
einzig Spannende bei Backup: Einen ebenso deppensicher hinzubekommenden
Restore. Da braucht's halt ein paar Grundvoraussetzungen wie bspw.
Bonjour Annoncierung und ein _verläßliches_ Protokoll, das die
notwendigen Features auch bereitstellt. Mich wundert's nicht, daß Apple
hier auf AFP setzt, das ja extra für TM entsprechende Erweiterungen
spendiert bekommen hat.
Man kann an Apple ja viel kritisieren (und das machen ja witzigerweise
all die "Fanboys" hier, die dem OP überhaupt geantwortet haben in seinen
bisher eröffneten Threads, von den klassischen "Apple ist geil und Steve
mein Gott"-Schwaflern hat er ja noch gar nichts gelesen, weil er das
Archiv der Gruppe offensichtlich auch noch kein einziges mal konsultiert
hat)
Aber daß solche technischen Entscheidungen wie die bzgl. TM via Netzwerk
nur von Profitsucht motiviert sein sollen, glaub ich dann doch nicht.
Andererseits war die Vorgabe seitens Produktmanagement ganz sicherlich
schon: "Macht das Ganze für unsere Zielgruppe, also den sprichwörtlichen
DAU, maximal simpel beherrschbar". Und dem folgt die Umsetzung: Klare
Vorgaben und eben kein Wischiwaschi-Support für ein Netzwerk-Protokoll,
das in vielen Implementierungen auf unvollständigem Reverse Engineering
beruht.
Und die negative Publicity, wenn all die technik-affinen Bastelwastel
dann die Foren und Blogs damit füllen, daß selbstredend nicht sie selbst
sondern Apple schuld sei, daß TM nicht mit ihrer mehr oder weniger
kaputten SMB-/NFS- oder iSCSI-Implementierung sauber zurechtkommt
(wohlgemerkt hinsichtlich SMB noch dazu bei einem Protokoll, das
außerhalb -- böse Zungen behaupten ja auch innerhalb -- Microsofts im
Wesentlichen durch Reverse Engineering, Orientierung an der "Referenz-
Implementierung" und tausenden Fixes von Fixes besteht), braucht Apple
wohl auch nicht unbedingt. Wobei mir das wiederum wurscht ist, was Apple
braucht und was nicht :-)
>>> Und diejenigen die dir die Details erklären könnten vergraulst du
>>> hier, das es ein Vergnügen ist.
>>
>> ... Ach, die meisten Leute die mir geantwortet haben, hatten sich
>> doch nur angegriffen gefühlt, weil es jemand wagt IHR System zu
>> kritisieren.
Also bei mir bist Du primär deshalb ins Killfile geschlittert, weil es
relativ aussichtslos erscheint, Dir neue _technische_ Zusammenhänge
näherzubringen. Das mag in ein paar Monaten anders sein, wenn Du Dich
auf gewisse Konzepte am Mac einlassen _willst_ und nicht hinter allem,
was Du aktuell (noch) nicht verstehst, Boshaftigkeit/Unfähigkeit seitens
Apple vermutest.
Daß bei Dir alles gleich auf 'ne persönliche Ebene rutscht, hat ja
einerseits was Amüsantes (bin von Dir ja erst zum Gelegenheits-
Terminal-User ernannt worden und jetzt auch noch zum Apple-Fanboy :-),
ist aber andererseits ebenfalls ein Grund, Diskussionen mit Dir zu
meiden (zumindest für mich, weil's bei mir auch zu schnell auf die
persönliche Ebene rutscht. Killfile --> Selbstschutz. Spart zudem auch
noch Zeit und Nerven :-)
>> Ich bin jetzt mal gespannt, ob es klappt, wenn man die Layer per
>> iSCSI abstrahiert. Bei Google habe ich Blog-Einträge von Leuten
>> gefunden, die das hinbekommen haben.
>
> Klar funktioniert das. Denn das IST ein anderer Layer.
Und das ist nur für Leute interessant, die Backup um des Backups willen
machen aber den Restore-Fall, speziell Desaster Recovery, für unnötigen
Luxus halten. Für Hobbyisten und Bastelwastel ganz OK -- wenn man das
Backup aber als Backup brauchen sollte, also um des Restores willen
macht, dann keine gute Idee.
Aber selbstverständlich ist auch das wieder reine Boshaftigkeit seitens
der Blutsauger aus Cupertino, daß dem OP dann, wenn ihm die Kitze
abratzt und er mit der Installations-DVD booten und von TM-Sicherung
wiederherstellen will, feststellen muß, daß Apple weder einen
generischen noch den von ihm bisher verwendeten iSCSI-Client mit auf die
DVD gepackt haben, mit dem er dann an sein Blockdevice (AKA HFS+ auf
anderem Abstraktionslayer) rankommt. :-)
Eigentlich ist es auch hier total einfach: Apples Zielgruppe ist eine
andere: Die wollen sich nicht Stunden um die Ohren schlagen, um ein
Backup auf einem Wald-und-Wiesen-NAS eingerichtet zu bekommen, die
wollen, daß das Ding im Bedarfsfall _einfach so_ funktioniert (was
allerdings auch gegen die Time Capsule spricht) und die wollen sich erst
recht nicht im Restore- bzw. Desaster Recovery Fall mit dem Aufsetzen
einer funktionierenden TCP/IP-Konfiguration und Eingabe irgendwelcher
IQNs herumschlagen. Die wollen, daß das aus dem Stand heraus ohne
Konfiguration und Technik-Sch*** geht.
Und das liefert ihnen Apple auch. In Form der bisherigen Time Capsules
natürlich in katastrophaler Form. Aber mei, das kennzeichnet auch den
typischen Apple-Anwender. Der kauft's trotzdem ;-)
Gruss,
Thomas
Ralph Böhme
> .... BIG snip ...
> ..
> Ralph Böhme schrieb in <news:hh82lp$ens$1...@news.albasani.net>
>> Joern Bredereck <jo...@bredereck.net> schrieb:
>>> Ich bin jetzt mal gespannt, ob es klappt, wenn man die Layer per
>>> iSCSI abstrahiert. Bei Google habe ich Blog-Einträge von Leuten
>>> gefunden, die das hinbekommen haben.
>>
>> Klar funktioniert das. Denn das IST ein anderer Layer.
> ...
> Aber selbstverständlich ist auch das wieder reine Boshaftigkeit seitens
> der Blutsauger aus Cupertino, daß dem OP dann, wenn ihm die Kitze
> abratzt und er mit der Installations-DVD booten und von TM-Sicherung
> wiederherstellen will, feststellen muß, daß Apple weder einen
> generischen noch den von ihm bisher verwendeten iSCSI-Client mit auf die
> DVD gepackt haben, mit dem er dann an sein Blockdevice (AKA HFS+ auf
> anderem Abstraktionslayer) rankommt. :-)
:-)))
Gruß Ralph
PS:
Mist, ich dachte ich hätte den Engelsgeduld-Award sicher -- und dann
du wieder! ;)
--
s/-nsp// for mail
Matthias Arndt
> Mist, ich dachte ich h�tte den Engelsgeduld-Award sicher -- und dann
> du wieder! ;)
Ralph, you made my day!
Matthias
... DAU-gleich mit TM :o)
--
There are 10 kinds of people in the world: those who understand binary,
and those who don't.
Joern Bredereck
Am 27.12.09 17:40, schrieb Ralph Böhme:
> ...haben dir einige Leute versucht zu verknusen. So habe ist jedefalls
> mein Eindruck des Threads. Unter anderem hast du hier jemanden falsch
> verstanden der mit sehr großen Wahrscheinlichkeit schon mehr Netz-
> traces von sowohl AFP als auch CIFS analysiert hat als du.
Bei AFP magst du recht haben, bei CIFS wäre ich mir da nicht so sicher.
>> Als
>> jemand der schon in den 80ern die Ataris versus Amiga-System-Kriege
>> miterlebt hat, weiss ich ziemlich genau, was ich von solchem ideologisch
>> motivierten Geschwätz zu halten habe. Wer es nicht schafft, vorbehaltlos
>> und ohne ideologische Hintergründe über technische Zusammenhänge zu
>> diskutieren, der kann mir wirklich gestohlen bleiben. Sollte ich solche
>> Leute verprellt haben, werde ich damit leben müssen.
>
> Mein Eindruck des Threads ist ein anderer. Hier wurde versucht deinen
> voreiligen und falschen Schlüsse zu hinterfragen und korrigieren.
> Worauf du in den flame-war Modus geweschselt bist.
Flame-War-Modus? Nur weil sich hier einige Leute auf den Schlips
getreten fühlen, weil man Apples Produkte kritisiert hat das nichts mit
Flame-War zu tun.
> Aber zugegeben, der war etwas gemein, CNIDs ist wohl Netatalk-Lingo.
> Steht für "catalog node id" und besagt in etwa, dass Dateien und Ordner
> im Dateisystem eine konstante, eindeutige, indizierbare Nummer haben.
> Hervorzuheben ist dabei u.a., dass dies Zugriffssemantiken ermöglicht
> bei der nicht mit Pfaden gearbeitet wird, sondern implizit einfach mit
> dieser CNID (keine Ahnung welches die aktuelle OS X API dafür ist,
> FSRef? Alias Manager?).
>
> Gescheite AFP Server bzw. das AFP Protokoll unterstützen diese
> Semantiken, CIFS nicht -- ist in der Spezifikation gar nicht vorgesehen.
Du scheinst nachwievor nicht verstanden zu haben, dass diese alle auf
einem völlig anderen Layer stattfinden kann. Auf dem Blockdevice-Layer
gibt es keine Filesystem-spezfifischen Semantiken.
> Und damit sind wir da worauf ...
>> Mir ist nur nicht klar, worauf du hinauswillst.
>
> ...ich hinauswill: es gibt prinzipielle sematische Unterschiede
> zwischen CIFS am Mac und AFP am Mac. Und solange Apple nicht die
> entsprechenden APIs rausschmeißt (oder Programme sie nicht mehr
> nutzen -- was aktuell leider der Trend ist) bleibt es dabei.
Das ist auch nicht weiter tragisch, denn es ist CIFS genauso egal,
welche Mechnismen _innerhalb_ des HFS-Containers Anwendung finden.
Genauso wie es dem SATA-Protokoll vollkommen Schnuppe ist, ob da ein
HFS, NTFS oder FAT32 huckepack von und zur Festplatte transportiert wird.
Nochmal: Was ich vorschlage wäre ein 100%ig abstrahierter HFS-Container,
der in einem virtuellem Blockdevice (aka Image-Datei-Container)
untergebracht ist. Ob dieses Blockdevice anschliessend über SATA, IDE,
SCSI, USB oder CIFS transportiert wird, spielt nicht die geringste Rolle.
>> Wenn man wollte wäre das durch einen Container abbildbar. Man müsste
>> lediglich die Layer sauber abstrahieren und diesen Container als
>> stinknormales Block-Device verwenden.
>
> Gute Idee. Und an welcher Stelle ist das in den CIFS Specs
> beschrieben?
Anscheinend reden wir immernoch aneinander vorbei. Anders kann ich mir
diesen Einwand deinerseits nicht erklären.
Ich werde mal versuchen, dir das anhand eines praktichen Bespiels unter
Linux zu zeigen. Mir ist klar, dass Linux != MacOS ist, aber das
grundsätzlich Prinzip ist das selbe und ich bin sicher, dass sich diese
Demonstration auch unter MacOS/Darwin nachbauen liesse:
Schritt 1: Ich mounte mir eine CIFS-Share (//192.168.200.98/jb) nach
/var/srv/share:
root@mondenkind:~# mount -t cifs -o username=jb //192.168.200.98/jb
/var/srv/share
Password:
root@mondenkind:~# mount | grep srv/share
//192.168.200.98/jb on /var/srv/share type cifs (rw,mand)
Schritt 2: Ich erstelle in dieser Share z.B. ein 1 MB grosses Image:
root@mondenkind:~# dd if=/dev/zero of=/var/srv/share/container.img
bs=1024 count=1000
1000+0 records in
1000+0 records out
1024000 bytes (1.0 MB) copied, 16.5985 s, 61.7 kB/s
Schritt 3: Ich mache diese Image-Datei über ein Loopback-Device zu einem
Block-Device:
root@mondenkind:~# losetup /dev/loop0 /var/srv/share/container.img
root@mondenkind:~# losetup -a
/dev/loop0: [0012]:25460627 (/var/srv/share/container.img)
Anchliessend habe ich unter /dev/loop0 eine vollwertiges Blockdevice,
dass ich wie eine stinknormale Festplatte ansprechen kannst. Ich könnte
das Ding z.b. mit fdisk partitionieren:
root@mondenkind:~# fdisk -l /dev/loop0
Disk /dev/loop0: 1 MB, 1024000 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Disk /dev/loop0 doesn't contain a valid partition table
In diesem Beispiel reichts aber aus, dass komplette Blockdevice
unpartitioniert zu formatieren:
root@mondenkind:~# mkfs.ext3 /dev/loop0
mke2fs 1.40.8 (13-Mar-2008)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
128 inodes, 1000 blocks
50 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=1048576
1 block group
8192 blocks per group, 8192 fragments per group
128 inodes per group
Writing inode tables: done
Filesystem too small for a journal
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
Hierbei wird jetzt ein vollwertiges ext3-Dateisystem in den Container
geschrieben. Hier spasseshalber mal ein Filesystem-Check:
root@mondenkind:~# e2fsck -y -f /dev/loop0
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop0: 11/128 files (9.1% non-contiguous), 38/1000 blocks
Im nächsten Schritt kannst ich das formatierte Blockdevice mounten und
ganz normal Dateien dort erstellen:
root@mondenkind:~# mount /dev/loop0 /var/srv/ext3-mountpoint/
root@mondenkind:~# mount | grep srv/
//192.168.200.98/jb on /var/srv/share type cifs (rw,mand)
/dev/loop0 on /var/srv/ext3-mountpoint type ext2 (rw)
Und selbstverständlich stehen jetzt auch alle ext3-spezifischen
Attribute/Features zur Verfügung:
root@mondenkind:~# echo "Test" > /var/srv/ext3-mountpoint/test.txt
root@mondenkind:~# lsattr /var/srv/ext3-mountpoint/test.txt
------------------ /var/srv/ext3-mountpoint/test.txt
root@mondenkind:~# chattr +S /var/srv/ext3-mountpoint/test.txt
root@mondenkind:~# lsattr /var/srv/ext3-mountpoint/test.txt
--S--------------- /var/srv/ext3-mountpoint/test.txt
Und du kannst mir glauben, dass diese Dateisystem-Attribute nirgends in
CIFS spefiziert sind oder von CIFS supported werden. Aber genau das ist
ja mein Punkt: CIFS muss das alles überhaupt nicht supporten. CIFS muss
lediglich dafür sorgen, dass mein Rechner "mondenkind" in die
Container-Datei "container.img" auf dem entfernten CIFS-Host
(192.168.200.98) lesen/schreiben kann.
ALLES andere findet einen Layer oberhalb statt und muss von CIFS nicht
supported werden. Von daher sind deine Einwände bezüglich "CNID" oder
der Semantik vollkommen irrelevant, denn all das findet (genau wie die
ext3-Attribute in meinem Beispiel) einen (genauergesagt sogar zwei)
Layer höher im Filesystem statt.
Übrigens: In meinem Beispiel habe ich mir eine CIFS-Share von einem
Server gemountet, der fast 400 Kilometer entfernt in einem Nürnberger RZ
steht. D.h. unterhalb von CIFS waren auch noch ein paar VPN-Layer im
Einsatz, die von dem ext3-Dateisystem genausowenig wissen/supporten
müssen wie CIFS.
Und was unter Linux mit ext3 geht, sollte auf dem MAC mit HFS(+) doch
auch funktionieren. Und dann dürfte TM doch kein Problem haben, in
dieses HFS-Dateisystem so zu schreiben, als wenn es sich um ein lokal
gemountetes HFS handeln würde.
>> Ich habe übrigens eben versucht eine Image-Datei auf einer externen
>> USB-Platte zu erstellen und dann dieses Image als Volume zu mounten. Das
>> hat auch funktioniert, aber TM bietet mir dieses Volume natürlich wieder
>> nicht als gültiges Backup-Volume an.
>>
>> Kannst du mir erklären, was dagegen sprechen würde, in dieses Volume zu
>> sichern?
>
> Hast du unter anderem diesen "defaults write show-unsupported-network-
> volumes" Kram gemacht?
ja, habe ich. Paradoxerweise wird mir eine CIFS-Share als mögliches
Backup-Volume angeboten, während das von der FAT32-Partion auf der
externen USB-Platte gemountete HFS-Volume nicht angeboten wird.
Hast du eine Idee, warum nicht? Eigentlich sollte es doch jetzt möglich
sein, in dieses HFS-Volume zu sichern, oder?
> Etc. Ich tippe einfach drauf dass du veraltete
> Howtos umsetzt.
Wozu brauche ich da eine Howto.... ich erstelle im
Festplatten-Dienstprogramm eine Image-Datei für ein HFS-Volume und nach
einem Doppelklick auf diese Image habe ich ein neues HFS-Volume im
Finder. Auf dieses Volume kann ich absolut problemlos schreiben und
davon lesen. Nur TM weigert sich beharrlich in dieses Volume zu sichern.
>> Es handelt sich hier aus Anwendungs-Sicht um ein vollwertiges
>> HFS-Volume. Welche Einschränkungen würden TM nun daran hindern in dieses
>> Volume seine Backups zu schreiben?
>
> Wohl nicht das richtige IM Volume.
IM Volume?
>>> Hat das direkt was mit TM zu tun?
>>
>> Mir stellt es sich momentan so dar, dass TM absichtlich derartige
>> Volumes aussperrt, damit ja niemand auf die Idee kommt, etwas anderes
>> als einen AFP-Server oder eine Time-Capsule zu verwenden.
>
> Schlicht falsch. Punkt.
Naja, hast du denn noch eine zielführende Idee, was ich machen müsste um
ein Volume zu erstllen, dass ich mit TM verwenden kann?
>>> Sind die Semantiken vom CIFS und AFP am Mac gleich?
>
>> müssen Sie nicht sein. Denn TM müsste nicht direkt in eine CIFS-Share
>> schreiben, sondern könnte problemlos in ein lokales HFS-Volume
>> schreiben. Dieses HFS-Volume würde alle benötigten Features
>> bereitstellen. Über den Schreibzugriff in den per CIFS bereitgestellten
>> Container hat sich einzig und allein der Kernel (bzw. die
>> SMB-Userland-Tools) zu kümmern. TM müsste mit diesem Layer überhaupt
>> nicht in Berührung kommen.
>
> Siehe oben: OS X hat halt Funktionalitäten und Semantiken die u.a.
> Linux und CIFS in der Form nicht kennt: CNIDs. Und daher ist deine
> Aussage nicht falsch, sondern einfach am Thema vorbei.
Ich hoffe, dass du nach meinem obigen praktischen Beispiel erkennen
konntest, dass ich hierbei eine 100%ig Abstrahierung der Layer
durchführen möchte. Deine ständigen Einwände bezüglich Semantiken und
CNIDs zeigen mir, dass du augenscheinlich noch immer nicht verstanden
hast, dass es bei einer vollständigen Abstrahierung der Layer vollkommen
egal ist, ob das darunterliegende Protokoll nun SATA, (i)SCSI, NFS, CIFS
oder AFP heisst. All diese Protokolle haben in meinem Ansatz nur die
Aufgabe simple I/O-Zugriffe auf ein Blockdevice zu ermöglichen und
müssen daher nicht Aware für irgendwelche Dateisystem-Spezifika sein.
>> Ich bin jetzt mal gespannt, ob es klappt, wenn man die Layer per iSCSI
>> abstrahiert. Bei Google habe ich Blog-Einträge von Leuten gefunden, die
>> das hinbekommen haben.
>
> Klar funktioniert das. Denn das IST ein anderer Layer.
Nein. Wenn ich einen vollständig abstrahierten Blockdevice-Container
über CIFS anspreche, dann ist das exakt der selbe logische Layer wie iSCSI.
Ob ich nun
a) Filesystem-over-Blockdevice-over-SATA
b) Filesystem-over-Blockdevice-over-iSCSI-over-SATA
c) Filesystem-over-Blockdevice-over-CIFS-over-Filesystem-over-SATA
mache, kommt am Ende immer auf's selbe heraus (naja, die Performance und
der Protokoll-Overhead variieren natürlich). Ich habe einen 100%ig
abstrahieren Blockdevice-Layer in welchem sich ein 100%ig valides
Filesystem befindet. Lediglich die Layer unterhalb des Blockdevices
unterscheiden sich. Und genauso wie es TM egal sein müsste, ob das
betreffende Blockdevice auf einer SCSI, SATA, oder IDE-Platte liegt, so
sollte es ihm auch egal sein, ob ein CIFs darunter liegt.
Defacto dürfte es aber so sein, dass sich TM schlicht und einfach am
fehlenden Bonjour-Announcement stört. Und das wiederum bedeutet, dass
Apple schlichtweg solche Lösungen nicht ermöglichen WILL, obwohl das
Bonjour-Announcement einzig und allein dazu dient, um zu erkennen, ob
eine propritäre Zeitkapsel dran hängt, oder nicht. Das Backup an sich
liesse sich technisch sehr wohl über einen
Blockdevice-over-CIFS-Container durchführen. Apple will's nur einfach
nicht. :-(
Gruß,
Jörn
Goetz Hoffart
> Nur weil sich hier einige Leute auf den Schlips getreten f�hlen, weil man
> Apples Produkte kritisiert hat das nichts mit Flame-War zu tun.
Es haben schon Neulinge hier vor dir Apple kritisiert und es lief nicht
so. Und ein Gutteil der Diskutanten hier kritisiert Apple beinahe
t�glich und manchmal nicht zu sparsam.
Auch wenn es offensichtlich schwerf�llt es zu glauben: hier ist nicht
die Apple-Fanboy-Gruppe.
Gr��e
G�tz
--
http://www.knubbelmac.de/
Joern Bredereck
ich k�me auch nicht auf die Idee, das in dieser Form zu verallgemeinern.
Aber einige Antworten, die ich bekommen habe, rochen schon sehr
"defensive". Vor allem solche Totschalgargumente wie "dann benutz doch
was anderes" finde ich immer sehr zielf�hrend, denn es geht mir ja darum
erstmal abzukl�ren, was mit der mitgelieferten Software m�glich ist, und
was nicht. Und warum dann einige Leute gleich ausflippen, wenn man das
Fehlen bestimmter Features hinterfragt, finde ich schon sehr am�sant.
Man bekommt dann die Werbetexte der Apple-PR-Abteilung um die Ohren
gehauen und merkt, dass es den betreffenden gar nicht darum geht, �ber
das konkrete Problem zu diskutieren, sondern dass sie blos klarmachen
wollen dass Apple �ber jeden Zweifel erhaben ist, und wer damit Probleme
hat, sollte keine Apple-Produkte benutzen.
Ich habe in den letzten 25 Jahren schon so ziemlich mit allem
gearbeitet, was irgendwie Bits und Bytes verarbeitet (13 Jahre davon
beruflich) und in dieser Zeit einige "Systemkriege" miterlebt. Von daher
bilde ich mir ein, jemanden der willens und in der Lage ist, sachlich
�ber die Technik zu diskutieren von jemanden, der nur extrem �berheblich
sein System "verteidigen" will, zu unterscheiden.
Im Zuge dieser �berheblichkeit, die dabei einige Leute an den Tage
legen, werden dann auch noch schlichte Unwahrheiten oder Vorurteile
verbreitet. So musste ich vorgestern lernen, dass Copy'n'Paste zwischen
generischen MacOS-Anwendungen und X11-Applikationen (in diesem Fall
Eterm) nicht m�glich sei. Und das von jemanden, der sich augenscheinlich
als Shell-Guru sieht, und sich auf den Schlips getreten f�hlte, weil ich
sagte, dass Terminal.app zumindest f�r Gelegenheits-Shell-User
vollkommen ausreichend ist. Das scheint ihn als Terminal.app-User schwer
getroffen zu haben, immerhin hat mich daraufhin ins Killfile genommen.
Solch eine Reaktion kann man einfach nur als "infantil" bezeichnen; so
als wenn sich die Leute �ber die Anwendungen definieren w�rden, die sie
benutzen.
Hey Leute: Das sind einfach nur Hilfsmittel, die euch bei eurer
t�glichen Arbeit unterst�tzen sollen. Wer sich pers�nlich angegriffen
f�hlt, weil man seine Lieblings-Anwendung kritisiert, der solte sich
wirklich mal fragen ob mit seinem Werte- und Priorit�ts-Empfinden noch
alles in Ordnung ist. Entspannt euch einfach mal ein bi�chen und legt
mal eure Scheuklappen ab.
Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
schweigende Mehrheit sich zusammen mit mir �ber solche beleidigten
Leberw�rste am�siert und einfach nichts dazu sagt.
Ich werde in der Zukunft (schon aus Zeitmangel) versuchen auf solche
"religi�sen" Exkurse nicht mehr einzugehen. Wer sachlich �ber technische
Dinge mit mir diskutieren will, kann das gerne machen. Wer den ersten
Anflug von �berheblichkeit oder Ideologie aufkommen l�sst, wird in
Zukunft links liegen gelassen.
Dietmar Plaßmann
> Ich habe in den letzten 25 Jahren schon so ziemlich mit allem
> gearbeitet, was irgendwie Bits und Bytes verarbeitet (13 Jahre davon
> beruflich) und in dieser Zeit einige "Systemkriege" miterlebt.
Sch�n. Hier dagegen treiben sich nur Unwissende herum.
> �ber die Technik zu diskutieren von jemanden, der nur extrem �berheblich
> sein System "verteidigen" will, zu unterscheiden.
Hier verteidigt doch keiner was. Man versucht nur dir klar zu machen,
das das was du willst nicht geht und von uns kann einer was dagegen
machen. Hier m�sste Apple t�tig werden, beschwer dich bei denen.
> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
> schweigende Mehrheit sich zusammen mit mir �ber solche beleidigten
> Leberw�rste am�siert und einfach nichts dazu sagt.
Die schweigende Mehrheit ist ehr �ber deine Postings am�siert, denn
wahrscheinlich hat die schweigende Mehrheit das alles schon durch, was
du hier bem�ngelst.
Nur sind wir Apple-User, da f�ngt keiner an zu frickeln um es irgendwie
hinzubekommen. Nachricht an Apple, "baut das ein" und vielleicht kommt
es wenn es gen�gend Leute haben wollen. Die Version 1.0 sollte man aber
tunlichst nicht einsetzen.
Dominik Schlütter
> ich k�me auch nicht auf die Idee, das in dieser Form zu verallgemeinern.
Und doch hast du es immer wieder getan. Ich denke, das nervt hier einige
Leute am meisten.
> Aber einige Antworten, die ich bekommen habe, rochen schon sehr
> "defensive". Vor allem solche Totschalgargumente wie "dann benutz doch
> was anderes" finde ich immer sehr zielf�hrend, denn es geht mir ja darum
> erstmal abzukl�ren, was mit der mitgelieferten Software m�glich ist, und
> was nicht.
Nochmal: Du hattest ein Problem mit einer bestimmten Aufgabenstellung.
Daraufhin wurde dir erkl�rt, wie man selbiges l�sen kann - das gefiel
dir aber nicht, weil du es gerne anderes machen wolltest. Und an diesem
Punkt wird es dann �rgerlich, denn jetzt machst du die Leute f�r dein
Probelm verantwortlich, die dir erkl�rt haben, dass das so nicht geht.
Dir geht es ab da dann auch nicht mehr darum, dein Problem zu l�sen,
sondern irgendwie Schuld zuweisen zu k�nnen. Da machen die meisten hier
nicht mehr mit.
Du m�chtest hier diskutieren, warum Apple etwas nicht so implementiert,
wie du es gerne h�ttest - was soll dabei herauskommen? Inwiefern hilft
es dir, wenn wir uns jetzt alle zusammensetzen und �berlegen, wie man
das Verhalten von Apples Time Machine umschreiben m�sste, damit es auch
mit deinem vorhandenen NAS auf Anhieb funktioniert? Geht es dir darum,
dich getr�stet zu f�hlen, wenn wir jetzt alle schreiben, dass Apple beim
Verhalten von TM �bers Netz weiter nachbessern muss? Ich denke, diesen
Satz k�nnten alle hier unterschreiben - aber dadurch l�uft es bei dir
nicht besser.
Es w�rde dagegen wirklich besser, wenn du dich auf die Hinweise
einlassen k�nntest, die dir hier gegeben wurden. So aber hinterl�sst du
den Eindruck, dass dir dein urspr�ngliches Problem eher egal ist und das
die L�sungshinweise der Regulars hier von vornherein umsonst waren.
> Und warum dann einige Leute gleich ausflippen, wenn man das Fehlen
> bestimmter Features hinterfragt, finde ich schon sehr am�sant.
Niemand ist ausgeflippt. Stattdessen hast du hier immer den Eindruck
hinterlassen, du w�rdest die Mac-User insgesamt nicht wirklich f�r voll
nehmen, weil du ja viel mehr Ahnung (und Erfahrung und offene
Shell-Fenster) hast.
> Man bekommt dann die Werbetexte der Apple-PR-Abteilung um die Ohren
> gehauen [...]
Das musst du mit einer anderen Diskussion verwechseln, hier kam das
nicht vor. Du solltest vielleicht mal deine Vorurteile ein wenig
�berdenken.
> Von daher bilde ich mir ein, jemanden der willens und in der Lage ist,
> sachlich �ber die Technik zu diskutieren von jemanden, der nur extrem
> �berheblich sein System "verteidigen" will, zu unterscheiden.
Nun ja, besser Einbildung als gar keine Bildung ... :-P. Aber mal im
Ernst: du bist neu hier und die Leute hier k�nnen einander dagegen schon
ein wenig einsch�tzen, was Know-How und F�higkeiten angeht. Und
(vielleicht mit Ausnahme von mir) hast du es hier mit Leuten zu tun, die
viel Ahnung von den Innereien von Mac OS X haben und die dar�berhinaus
regelm��ig zumeist auch beruflich mit entsprechenden Probleml�sungen zu
tun haben. Aus irgendeinem Grund versuchst du aber, denen die Schuld an
den von Apple gelieferten Funktionen zu geben, die dir nicht ausreichen.
Vielleicht solltest du dich mit deinen Beschwerden eher an Apple richten
als an die Leute, die dir erkl�ren, wie du deine Aufgabenstellung l�sen
kannst.
> Wer sich pers�nlich angegriffen f�hlt, weil man seine Lieblings-Anwendung
> kritisiert, der solte sich wirklich mal fragen ob mit seinem Werte- und
> Priorit�ts-Empfinden noch alles in Ordnung ist. Entspannt euch einfach mal
> ein bi�chen und legt mal eure Scheuklappen ab.
Vielleicht solltest du dir das mal zu Herzen nehmen und dir die
Diskussion noch mal anschauen. Und dir dann �berlegen, wem du hier die
Schuldzuweisungen um die Ohren haust.
> Ich werde in der Zukunft (schon aus Zeitmangel) versuchen auf solche
> "religi�sen" Exkurse nicht mehr einzugehen. Wer sachlich �ber technische
> Dinge mit mir diskutieren will, kann das gerne machen. Wer den ersten
> Anflug von �berheblichkeit oder Ideologie aufkommen l�sst, wird in
> Zukunft links liegen gelassen.
Das w�re sch�n. Du solltest aber vielleicht noch ein wenig an deinem
�berheblichkeits- und Ideologie-Detektor arbeiten, sonst k�nnte es f�r
dich hier schnell recht einsam werden.
Gru�,
Dominik.
Joern Bredereck
> Joern Bredereck wrote:
>
>> Ich habe in den letzten 25 Jahren schon so ziemlich mit allem
>> gearbeitet, was irgendwie Bits und Bytes verarbeitet (13 Jahre davon
>> beruflich) und in dieser Zeit einige "Systemkriege" miterlebt.
>
> Sch�n. Hier dagegen treiben sich nur Unwissende herum.
findest du? Ich kanns nicht beurteilen, ich habe diese Newsgroup erst
vor ein paar Tagen subscribed.
>> �ber die Technik zu diskutieren von jemanden, der nur extrem �berheblich
>> sein System "verteidigen" will, zu unterscheiden.
>
> Hier verteidigt doch keiner was. Man versucht nur dir klar zu machen,
> das das was du willst nicht geht und von uns kann einer was dagegen
> machen. Hier m�sste Apple t�tig werden, beschwer dich bei denen.
In dieser Absolutheit stimmt das nicht ganz. Auch hier sollte man nicht
verallgemeinern, sondern es etwas differenzieter betrachten: Zum einen
habe ich Howtos von Apple-Usern gefunden, die es unter fr�heren
MacOS-Versionen hinbekommen haben. Es bestand also begr�ndete Hoffnung,
dass es auch einen Workaround f�r SL gibt.
In einem anderen Teilthread ging es um die Frage, ob die Mechnismen, die
ich vorgeschlaen habe, �berhaupt funktionieren K�NNEN. Ralf B�hme hat
z.B. immer wieder behauptet, es w�re schlichtweg technisch nicht m�glich
die komplexen HFS-Spezifika �ber CIFS abzubilden. Augenscheinlich haben
wir hier aneinander vorbeigeredet. Daher habe ich mir gestern die M�he
gemacht ihm anhand eines praktischen Beispiels zu zeigen, wie es
funktionieren kann. Dass Apple von diesen technischen M�glichkeiten
keinen Gebrauch macht, steht wieder auf einem anderen Blatt. Aber wenn
jemand behauptet, es ginge technisch nicht, dann muss es mir doch
gestattet sein, dies sachlich und auf technischer Ebene zu widerlegen,
ohne dass mir dies als "N�rglerei" ausgelegt wird.
In diesem Zusammenhang m�chte ich Ralf �brigens auch mal lobend
erw�hnen. Im Gegensatz zu einigen anderen, ist er nie pers�nlich
geworden und hat versucht sich auf einer sachlich/technischen Ebene mit
mir auseinanderzusetzen. Davon k�nnten sich einige andere in dieser
Newsgroup mal eine Scheibe abschneiden.
>> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
>> schweigende Mehrheit sich zusammen mit mir �ber solche beleidigten
>> Leberw�rste am�siert und einfach nichts dazu sagt.
>
> Die schweigende Mehrheit ist ehr �ber deine Postings am�siert, denn
> wahrscheinlich hat die schweigende Mehrheit das alles schon durch, was
> du hier bem�ngelst.
naja, das werden wir woh nie herausfinden, denn die schweigende Mehrheit
schweigt dazu.
> Nur sind wir Apple-User, da f�ngt keiner an zu frickeln um es irgendwie
> hinzubekommen.
Ach, dann seit "ihr" (wer ist ihr?) also alle gleich? Ich dachte immer
ich habe es hier mit Individuen zu tun, die jeder f�r sich selbst
denken, argumentieren und handeln.
Ohne dir jetzt zu nahe treten zu wollen, aber glaubst du nicht, dass du
den anderen Apple-Usern Unrecht tust, wenn du sie als gleichgeschaltete
Konsumenten darstellst? Auch wenn du es nicht so gemeint haben magst,
aber so kommt es leider r�ber.
Ich glaube jedenfalls nicht daran, dass man alle Apple-User in eine Topf
schmeissen kann. Desweiteren bin ich �berzeugt davon, dass es auch unter
Apple-Usern Leute gibt, die sich �ber die technischen Hintergr�nde
Gedanken machen und den einen oder anderen Workaround f�r
Unzul�nglichkeiten der Default-Installation umsetzen.
> Nachricht an Apple, "baut das ein" und vielleicht kommt
> es wenn es gen�gend Leute haben wollen.
Wenn das mal konsequent zu ende denkt, dann k�nnte man sich diese
Newsgroup eigentlich sparen und bei jedem Problem lieber direkt Apple
anmailen, anstatt das Problem mit anderen Apple-Usern zu diskutieren.
Sorry, aber da kann ich dir nicht zustimmen.
> Die Version 1.0 sollte man aber tunlichst nicht einsetzen.
Darf man dann wenistens �ber die Bugs in der 1.0 in dieser Newsgroup
diskutieren, oder lautet die �berhebliche Antwort dann wieder: Schreib
einen Bugreport an Apple und h�r mit der N�rglerei auf?
Joern Bredereck
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> ich k�me auch nicht auf die Idee, das in dieser Form zu verallgemeinern.
>
> Und doch hast du es immer wieder getan. Ich denke, das nervt hier einige
> Leute am meisten.
Ich habe nicht verallgemeinert, sondern micht auf konkrete �usserung
bezogen.
> Und an diesem
> Punkt wird es dann �rgerlich, denn jetzt machst du die Leute f�r dein
> Probelm verantwortlich, die dir erkl�rt haben, dass das so nicht geht.
Nein, da verwechselst du was. Ich habe niemanden f�r etwas
verantwortlich gemacht. Ich habe in einem Teilthread die technische
Machbarkeit diskutiert und in einem anderen Teilthread war ich
�berrascht, dass jemand diese offensichtliche Einschr�nkung zu begr�ssen
scheint.
> Du m�chtest hier diskutieren, warum Apple etwas nicht so implementiert,
> wie du es gerne h�ttest - was soll dabei herauskommen? Inwiefern hilft
> es dir, wenn wir uns jetzt alle zusammensetzen und �berlegen, wie man
> das Verhalten von Apples Time Machine umschreiben m�sste, damit es auch
> mit deinem vorhandenen NAS auf Anhieb funktioniert?
Gegenfrage: Was spricht dagegen, wenn sich Anwender dar�ber austauschen,
was technisch m�glich w�re? Wenn dich der Thread nicht interessiert,
verstehe ich nicht, warum du ihn gelesen hast. Aber ich finde es etwas
vermessen wenn du den Leuten zur Auflage machen willst, dass ihre
Diskussionen die Welt ver�ndern m�ssten.
Mir ist klar, dass hier wohl keine Apple-Mitarbeiter mitlesen, die sich
vernalasst sehen, die ge�usserte Kritik als Kunden-Feedback
weiterzuleiten. Zumindest halte ich das f�r sehr unwahrscheinlich.
Aber vielleicht hat ja jemand eine z�ndende Idee, wie man die
diskutierten Nachteile beseitigen oder ausgleichen k�nnte. In 15 Jahren
UseNet habe ich solche F�lle schon sehr oft erlebt.
Irgendjemand hat mal gesagt ein Problem ist halb gel�st, wenn es
formuliert ist. Also warum nicht dar�ber diskutieren?
> Geht es dir darum,
> dich getr�stet zu f�hlen, wenn wir jetzt alle schreiben, dass Apple beim
> Verhalten von TM �bers Netz weiter nachbessern muss? Ich denke, diesen
> Satz k�nnten alle hier unterschreiben - aber dadurch l�uft es bei dir
> nicht besser.
Naja, �u�erungen wie...
"Schau dir bitte mal an, was Apple mit TM (z.B. laut ihrer
Eigendarstellung) bezwecken will und an wen sich das richtet. Das Ziel
war nicht, auf m�glichst vielen NAS zu laufen."
...klingen nicht gerade so, als wenn du der Meinung w�rst, dass Apple da
nachbessern muss. Es klang eher danach, das Verhalten von Apple zu
rechtfertigen.
>> Und warum dann einige Leute gleich ausflippen, wenn man das Fehlen
>> bestimmter Features hinterfragt, finde ich schon sehr am�sant.
>
> Niemand ist ausgeflippt. Stattdessen hast du hier immer den Eindruck
> hinterlassen, du w�rdest die Mac-User insgesamt nicht wirklich f�r voll
> nehmen, weil du ja viel mehr Ahnung (und Erfahrung und offene
> Shell-Fenster) hast.
Also erstens fiele es mir nicht im Traum ein, alle Mac-User �ber einen
Kamm zu scheren. Soetwas wie "DIE Mac-User" gibt es in meinem Denken
�berhaupt nicht. Von daher kann ich deine Kritik nicht so recht
nachvollziehen.
Und zweitens war wohl eher das Gegenteil der Fall: Als Mac-Neuling wurde
mir an mehrern Stellen technisches Unverm�gen unterstellt. Ich wurde
mehr als einmal von "oben herab" als Noob dargestellt, obwohl meine
allgemeinen IT- und Netzwerk-Kenntnisse schon aufgrund meines
beruflichen Backgrounds den Status des Noob-Neulings �bersteigen
d�rften. Dass ich wenig Erfahrung mit MacOS-spezifischen Eigenheiten
habe, steht allerdings ausser Frage. Vielleicht erlaubt mir diese
Ausgangs-Situation aber auch, etwas "unvoreingenommener" an die Sache
heranzugehen und Dinge zu hinterfragen, die viele Mac-User als
selbstverst�ndlich hinnehmen.
Ich kann schon nachvollziehen, dass es Mac-User gibt, f�r die es ganz
selbstverst�ndlich ist, dass eine Apple-Backup-L�sung eben nur mit
Apple-Hardware richtig funktioniert.
Aber Leute, die vom C64 �ber Atari, Amiga, Linux, Solaris/HP-UX/NetBSD
bis hin zu allen Windows-Versionen schon alles l�ngere Zeit in Benutzung
hatten haben vielleicht einen etwas anderen Blick auf solche Dinge.
Das soll nicht heissen, dass ich Mac-User, die bislang noch nichts
anderes als einen Mac verwendet haben, nicht "f�r voll" nehmen w�rde. Es
soll nur aufzeigen, dass es Leute gibt, die einen etwas anderen
Background haben und f�r die es daher vielleicht _nicht_
selbstverst�ndlich ist, dass man f�r ein Backup nur die Hardware eines
bestimmten Herstellers verwenden kann.
Zumal wir hier �ber Techniken und Protokolle sprechen, die eigentlich
mit dem Macintosh �berhaupt nichts zu tun haben. �ber Protokolle wie
CIFS und dessen technische M�glichkeiten ben�tige ich keine "Belehrung";
auch wenn ich Mac-Neuling bin. Von daher fand ich die etwas �berhebliche
Art, wie man mir hier erkl�ren wollte, meine Problemstellung w�re mit
CIFS technisch nicht machbar schon etwas fehl am Platze.
> (vielleicht mit Ausnahme von mir) hast du es hier mit Leuten zu tun, die
> viel Ahnung von den Innereien von Mac OS X haben und die dar�berhinaus
> regelm��ig zumeist auch beruflich mit entsprechenden Probleml�sungen zu
> tun haben. Aus irgendeinem Grund versuchst du aber, denen die Schuld an
> den von Apple gelieferten Funktionen zu geben, die dir nicht ausreichen.
nochmal: nein, das habe ich nie getan, und das k�me mir auch nicht in
den Sinn. Warum sollte ich einen Mac-User f�r die Produkte des
Herstellers verantwortlich machen? Das w�re absurd.
> Vielleicht solltest du dich mit deinen Beschwerden eher an Apple richten
> als an die Leute, die dir erkl�ren, wie du deine Aufgabenstellung l�sen
> kannst.
Ich denke du bringst hier 2 Sachen durcheinander: Wenn ich �ffentlich
Kritik �ussere, dann "beschwere" ich mich nicht. Und schon gar nicht bei
den Leuten, mit denen ich �ffentlich dar�ber diskutiere. Ich gebe
Beobachtungen, Meinungen und Vorschl�ge von mir und diskturiere gerne
mit anderen dar�ber. Nicht mehr und nicht weniger.
W�rde ich Time-Machine f�r einen Kunden evaluieren h�tte ich schon
l�ngst einen entsprechenden Support-Case (bzw. eine Feature-Anfrage) bei
Apple bzw. dem zust�ndigen Distributor/Supporter aufgemacht. Da ich aber
bislang nicht vorhabe Apple-Hardware zu verkaufen oder gar bei meinen
Kunden Apple-Produkte in meiner Beratung zu ber�cksichtigen, ist das
absolut kein Thema f�r mich.
Gru�,
J�rn
Dominik Schlütter
> Du scheinst nachwievor nicht verstanden zu haben, dass diese alle auf
> einem v�llig anderen Layer stattfinden kann. Auf dem Blockdevice-Layer
> gibt es keine Filesystem-spezfifischen Semantiken.
Und du scheinst nicht verstanden zu haben, dass Apple f�r TM beim
Zugriff auf Netzwerkressourcen andere Anforderungen stellt als beim
lokalen Zugriff - das Stichwort "locking" fiel ja beispielsweise schon
mehrfach. F�r AFP wurde das Protokoll entsprechend aufgebohrt, f�r
andere Dienste geht das nicht so leicht.
> Das ist auch nicht weiter tragisch, denn es ist CIFS genauso egal,
> welche Mechnismen _innerhalb_ des HFS-Containers Anwendung finden.
Ja. Apple ist das aber halt nicht egal.
> [... Besipiel eines �bers Netz gemounteten disk images gesnippt ...]
>
> Und du kannst mir glauben, dass diese Dateisystem-Attribute nirgends in
> CIFS spefiziert sind oder von CIFS supported werden. Aber genau das ist
> ja mein Punkt: CIFS muss das alles �berhaupt nicht supporten. CIFS muss
> lediglich daf�r sorgen, dass mein Rechner "mondenkind" in die
> Container-Datei "container.img" auf dem entfernten CIFS-Host
> (192.168.200.98) lesen/schreiben kann.
Hast du dir die verlinkte Dokumentation zu den AFP-Erweiterungen, die TM
gerne h�tte, �berhaupt angeschaut? Auch dort ist es egal, welches
Dateisystem auf dem Server genutzt wird - dennoch gibt es die
Erweiterungen um mit dem "locking" und "lock-stealing" klarzukommen.
> Wozu brauche ich da eine Howto.... ich erstelle im
Du hast doch selbst geschrieben, dass du welche genutzt hast.
> Ich hoffe, dass du nach meinem obigen praktischen Beispiel erkennen
> konntest, dass ich hierbei eine 100%ig Abstrahierung der Layer
> durchf�hren m�chte.
Ja, *du* m�chtest das. Apple nicht. Die m�chten netzwerkweit Verf�gbares
gesondert behandeln. Wenn du meinst, das sei dir egal - dann sieh halt
zu, dass deine gew�nschten Ziel-Volumes f�r das System z.B. als
USB-Laufwerke erscheinen. Es gibt da entsprechende propriet�re
NDAS-L�sungen, bei denen sollte TimeMachine dann auch �bers Netz
funktionieren. Nat�rlich handelt man sich damit dann ein paar andere
Probleme ein ... .
> Deine st�ndigen Einw�nde bez�glich Semantiken und
> CNIDs zeigen mir, dass du augenscheinlich noch immer nicht verstanden
> hast, dass es bei einer vollst�ndigen Abstrahierung der Layer vollkommen
> egal ist, ob das darunterliegende Protokoll nun SATA, (i)SCSI, NFS, CIFS
> oder AFP heisst.
Eben - *bei* einer vollst�ndigen Abstraktion. Die ist seitens Apple halt
nicht gew�nscht.
> Nein. Wenn ich einen vollst�ndig abstrahierten Blockdevice-Container
> �ber CIFS anspreche, dann ist das exakt der selbe logische Layer wie iSCSI.
F�r das System ist es aber immer noch erkennbar, ob dein Disk Image auf
einem lokalen Laufwerk oder einer Netzwerkfreigabe liegt. Wenn du das so
verbiegst, dass das System das nicht mehr wei� - dann kann auch TM was
damit anfangen. Und nat�rlich hast du weiterhin die von Thomas schon
angesprochenen Probleme beim Restore.
> Defacto d�rfte es aber so sein, dass sich TM schlicht und einfach am
> fehlenden Bonjour-Announcement st�rt.
F�r lokale Platten braucht es kein Bonjour. Und das willst du doch, eine
aus Sicht von TM lokale Platte. Denn f�r alles, was �bers Netzwerk geht,
will Apples Implementation ja ein paar zus�tzliche Sicherheiten (z.B.
was das locking angeht, s.o.) ... .
Gru�,
Dominik.
Dominik Schlütter
> Naja, �u�erungen wie...
>
> "Schau dir bitte mal an, was Apple mit TM (z.B. laut ihrer
> Eigendarstellung) bezwecken will und an wen sich das richtet. Das Ziel
> war nicht, auf m�glichst vielen NAS zu laufen."
>
> ...klingen nicht gerade so, als wenn du der Meinung w�rst, dass Apple da
> nachbessern muss. Es klang eher danach, das Verhalten von Apple zu
> rechtfertigen.
Du hast gefragt, warum Apple das wohl so implementiert hat, wie sie es
haben. Ich habe darauf reagiert, in dem ich dir die Frage nach dem
"warum" beantwortet habe und auf Apples eigene Aussagen dazu verwiesen.
Jetzt klingt es bei dir schon wieder so, als h�tte ich mir die Aussagen
Apples zu eigen gemacht oder w�rde irgendwas verteidigen - dem ist
offensichtlich nicht so, lies doch einfach mal was da steht.
Du fragst nach dem "warum", aber mit dem was der Hersteller selbst dazu
sagt, bist du auch nicht zufrieden. Bei dir muss da anscheinend immer
noch eine kleine Verschw�rungstheorie dazukommen, Erkl�rungen von Apple
z.B. zum erweiterten locking sind da stets nur ein Vorwand, um m�glichst
viele propriet�re Ger�te zu verkaufen. Es bleibt dir nat�rlich
unbenommen, das so zu sehen (schliesslich wissen wir alle ja auch nix
genaueres �ber die Interna bei Apple). Nur behauptest du letzten Endes,
dass alle, die nicht an deine Theorien glauben, "Apple Fanboys" seien,
die sich durch deine investigativen Fragen in die Enge gedr�ngt s�hen.
> Vielleicht erlaubt mir diese Ausgangs-Situation aber auch, etwas
> "unvoreingenommener" an die Sache heranzugehen und Dinge zu hinterfragen,
> die viele Mac-User als selbstverst�ndlich hinnehmen.
Vielleicht. Vielleicht aber auch nicht - denn alle, die dir hier
geantwortet haben, kennen (und benutzen) auch andere Systeme und haben
ebenfalls durchaus Ahnung, was "generelle" Computerthemen angeht,
insbesondere was Netzwerke und Netzwerktechnik angeht.
> Aber Leute, die vom C64 �ber Atari, Amiga, Linux, Solaris/HP-UX/NetBSD
> bis hin zu allen Windows-Versionen schon alles l�ngere Zeit in Benutzung
> hatten haben vielleicht einen etwas anderen Blick auf solche Dinge.
Mit solchen Leuten redest du hier. Schon die ganze Zeit. Und du hast
Irix vergessen (und statt C64 hatte man nat�rlich einen Apple II) :-P.
> Warum sollte ich einen Mac-User f�r die Produkte des Herstellers
> verantwortlich machen? Das w�re absurd.
Gut. Dann kannst du ja auch auch davon ausgehen, dass deine Fragen
niemanden hier in die Defensive treiben. Und dass niemand dir hier
beantworten kann, warum Apple irgendwas in der Art und Weise
implementiert, wie sie es nun mal tun.
Gru�,
Dominik.
André Igler
> Und (vielleicht mit Ausnahme von mir)
und kenn mich dann meistens ebenfalls nudel aus.
> hast du es hier mit Leuten zu tun, die viel Ahnung von den Innereien
> von Mac OS X haben und die darüberhinaus regelmäßig zumeist auch
> beruflich mit entsprechenden Problemlösungen zu tun haben.
Das allerdings. Zu meinem Glück, hier hat man mich ein paar mal
wensentlich geholfen. :P
Gerald Eíscher
> Joern Bredereck wrote:
>
>> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
>> Leberwï¿œrste amï¿œsiert und einfach nichts dazu sagt.
>
> Die schweigende Mehrheit ist ehr ï¿œber deine Postings amï¿œsiert, denn
Als Teil der schweigenden Mehrheit melde ich mich. Ja, ich amï¿œsiere mich
kï¿œstlich ï¿œber Joern. Langsam kriege ich Lust, nach langer Zeit wieder
einmal ein Merkbefreiungsformular hervorzukramen.
--
Gerald
Thomas Kaiser
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Du scheinst nachwievor nicht verstanden zu haben, dass diese alle auf
>> Layer gibt es keine Filesystem-spezfifischen Semantiken.
>
> Und du scheinst nicht verstanden zu haben, dass Apple für TM beim
> Zugriff auf Netzwerkressourcen andere Anforderungen stellt als beim
> lokalen Zugriff
Das haben ihm jetzt schon drei Leute zu erklären versucht. Er wird das
wohl erst kapieren, was für blöde Idee das ist, ein riesiges Image (wie
es für Time Machine üblich ist) übers Netz zu mounten, wenn mal Probleme
mit der Netzwerkverbindung auftreten, bspw. Kabel aus Versehen
ausstecken (bei Airport reicht ja schon weniger), Rechner in den Schlaf
schicken (Ruhezustand), während ein Backup läuft, etc.
In all den Fällen stehen die Chancen sensationell gut, daß das Image
anschließend im Ar*** ist. Apple setzt nicht umsonst auf Sparse Bundles
und ein Netzwerk-Protokoll, das genau mit solchen Situationen umgehen
kann (und genau zu diesem Zweck Erweiterungen spendiert bekam). Es geht
eben nicht darum, daß die Dateisystemsemantiken _innerhalb_ des Images
transparent sind sondern es geht nur darum, das _externe_ Handling des
Images robust, schnell und sicher zu implementieren.
Ruhezustand und Netzwerkverbindungsabbrüche werden von AFP-only-Features
wie Reconnect und Replay Cache abgefangen, das fragile Handling der
Sparse-"Bänder" durch entsprechende Locking-Semantiken sichergestellt
(gerade in der Situation des Image-Optimierens -- hdiutil compact -- um
auch den extern vom SparseBundle belegten Speicherplatz wieder frei zu
bekommen bzw. an den intern im Image verbrauchten Platz anzupassen).
Das sind die _technischen_ Design-Entscheidungen, die Apple dazu bewogen
haben, mit 10.5 SparseBundles einzuführen. Dito neue, zu 10.5-Zeiten
undokumentierte (aber auf filesys...@lists.apple.com seitens Apple-
Engineering erläuterte) AFP-Features, die seit AFP 3.3 (parallel zu
10.6) aber Teil der offiziellen Specs sind. Und die mehr als deutlich
machen, daß man das eben nicht mit beliebigen Netzwerk-Protokollen (dito
via iSCSI) umsetzen _will_, wenn man gewisse Anforderungen an ein Backup
stellt.
Ich weiß nicht, wie oft ihm das jetzt schon unter die Nase gerieben
wurde. Aber sicherlich werdet Ihr jetzt mit ihm Diskussionen darüber
führen, daß Apple ja gar nicht auf Images setzen müsse, wenn das so
kompliziert und gefährlich und nur mit Apple-Proprietärem möglich sei.
Dann werdet Ihr ihn an das ebenfalls mit 10.5 neue HFS+-Feature
directory-based Hardlinks erinnern und in Folge diskutieren, daß auch
das nur eine Gemeinheit seitens Apple sei, um wiederum den Verkauf
eigener Geräte anzukurbeln... und so weiter und so fort...
Gruss,
Thomas, weiterhin noch viel Spaß wünschend und jetzt auch noch nach
Threads filternd...
Gerald Eíscher
>
> Das ist auch nicht weiter tragisch, denn es ist CIFS genauso egal,
> welche Mechnismen _innerhalb_ des HFS-Containers Anwendung finden.
> Genauso wie es dem SATA-Protokoll vollkommen Schnuppe ist, ob da ein
> HFS, NTFS oder FAT32 huckepack von und zur Festplatte transportiert wird.
>
> der in einem virtuellem Blockdevice (aka Image-Datei-Container)
> SCSI, USB oder CIFS transportiert wird, spielt nicht die geringste Rolle.
Dann sichere doch auf ein Samba-Share, wenn du unbedingt mï¿œchtest. Ja,
das scheint zu funktionieren, es wurde vor rund zwei Jahren hier
diskutiert, und ich habe es ausprobiert. In meinem Fall ist allerdings
zwar ein sparse bundle erstellt worden, aber nach ein paar 100 MB die
Sicherung abgebrochen. Das kann auch an der alten Samba-Version des
Servers gelegen haben, ich habe es nicht weiter verfolgt.
Falls dann dein Restore einmal nicht funktionieren sollte, dann
beschwere dich bitte beim Salzamt.
Meinst du ernsthaft, Apple hat Lust, sich die schlechte Nachrede
anzutun, weil Leute auf irgendwelche Windoof-Kisten oder selbst
zusammengebastelte Samba-Server sichern, ï¿œber deren Software Apple keine
Kontrolle hat und dann die Wiederherstellung daneben geht?
--
Gerald
Goetz Hoffart
> > Aber Leute, die vom C64 �ber Atari, Amiga, Linux, Solaris/HP-UX/NetBSD
> > bis hin zu allen Windows-Versionen schon alles l�ngere Zeit in Benutzung
> > hatten haben vielleicht einen etwas anderen Blick auf solche Dinge.
>
> Mit solchen Leuten redest du hier. Schon die ganze Zeit. Und du hast
> Irix vergessen (und statt C64 hatte man nat�rlich einen Apple II) :-P.
Acorn!
Goetz Hoffart
> dass jemand diese offensichtliche Einschr�nkung zu begr�ssen scheint.
�Begr��en� und �verstehen/nachvollziehen/akzeptieren� sind zwei Paar
Schuhe. Es gibt halt immer Gr�nde f�r oder gegen etwas. Linux kriegt
seine ABIs seit Jahren nicht stabil, Windows sucht sein WinFS und
Software von Apple ist erstmal nur gegen eigene Specs getestet. Was
irgendwie, f�llt mir grade auf, auch nicht arg viel anders ist, als das
dauernd wechselnde ABI von Linux - beide wollen nur mit sich selbst.-)
Jochem Huhmann
> Ich glaube jedenfalls nicht daran, dass man alle Apple-User in eine Topf
> schmeissen kann. Desweiteren bin ich überzeugt davon, dass es auch unter
> Apple-Usern Leute gibt, die sich über die technischen Hintergründe
> Gedanken machen und den einen oder anderen Workaround für
> Unzulänglichkeiten der Default-Installation umsetzen.
Wobei man aber auch einfach mal feststellen muß, dass solche
Unzulänglichkeiten in aller Regel fehlende Features sind, die deshalb
fehlen, weil sie halt nur unzulänglich zu implementieren wären. Bei
Linux spielt sowas überhaupt keine Rolle, da ist halt der Anwender oder
Admin dafür verantwortlich, die Möglichkeiten und Grenzen zu verstehen
und wenn er sich in den Fuß schießen will, kriegt er noch eine
doppelläufige Schrotflinte dazu gereicht. Geladen und entsichert.
> Darf man dann wenistens über die Bugs in der 1.0 in dieser Newsgroup
> diskutieren, oder lautet die überhebliche Antwort dann wieder: Schreib
> einen Bugreport an Apple und hör mit der Nörglerei auf?
Hier wird verdammt viel diskutiert, genörgelt und kritisiert und
natürlich darf man das, aber Du hast es irgendwie fertig gebracht, ein
paar Leute gegen Dich aufzubringen, nachdem Du hier reingeplatzt bist.
Nimm's nicht persönlich, das geht vorbei.
Dass es sehr schön wäre, wenn man TM möglichst flexibel und sicher
über's Netz einsetzen könnte, steht außer Frage. Dass aber gerade bei
Backups "geht vielleicht" irgendwie gar nicht geht, steht aber auch
außer Frage.
Jochem
--
"A designer knows he has arrived at perfection not when there is no
longer anything to add, but when there is no longer anything to take away."
- Antoine de Saint-Exupery
Hans Juergen Meisen
> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
> schweigende Mehrheit sich zusammen mit mir �ber solche beleidigten
> Leberw�rste am�siert und einfach nichts dazu sagt.
Dann werde ich mich als Teil der schweigenden Mehrheit mal outen. Denn
ich glaube, Du gehst von falschen Voraussetzungen aus.
Ich geh�re seit einiger Zeit (aus Zeitmangel, nicht aus Desinteresse)
zum eher konsumierenden Teil der Gruppe.
Da ich in meinem "Nebenjob" aber zwischen den Tagen frei habe und mich
nur noch um den selbst�ndigen Teil meiner Erwerbst�tigkeit (oder die
Reste davon) k�mmern muss , habe ich jetzt etwas Zeit ....
Vielleicht gehst Du bei Deiner Bewertung der Antworten von falschen
Voraussetzungen aus:
a) Die "Fanboy"-Quote ist relativ gering
b) Terminologie aus dem Heise-Forum ist hier nicht der normale
Umgangston
c) haben hier einige Leute durchaus (auch berufliche) Erfahrungen mit
anderen Betriebssystemen, einige verdienen sogar ihr Geld damit.
d) es gibt hier noch andere, die die Atari-Amiga Kriege kennen und
hinter sich gelassen haben...
Hier kommen nat�rlich auch nicht selten "Neue" mit der Frage/Aussage:
"Ich habe das bisher immer so gemacht. Ich m�chte, dass das am Mac
genauso funktioniert, wie unter meinem bisherigen $OS!"
Dann bekommst Du nat�rlich auch Antworten wie: "... geht hier halt
nicht, geht hier anders." oder "Wenn Du was anderes brauchbares hast,
dann nimm doch das!". Ist vielleicht "nicht zielf�hrend", w�rden die
meisten hier aber genau so machen.
Du hast hier in de.comp.sys.mac.* zwei Threads begonnen. Ich beginne mal
mit dem in *misc - gute Terminal-Emulation? (auch wenn es eigentlich
nicht hier hin geh�rt). Ich fasse es nur zusammen, mit meinen Gedanken
dazu....
Du beginnst mit der Frage nach einer besseren Einbindung von Aterm oder
anderen guten Terminalemulation, weil Terminal.app f�r Dich nicht
ausreicht, dazu bekommst Antworten und auch die Frage, was Dir
eigentlich fehlt.
In Message-ID: <hgvuq4$ekb$1...@hathi.bw-networx.net> kommt dann die
Anforderungsliste:
---- snip -----
> - stufenlos einstellbare Transparenz
> - Hintergrund-Grafiken
> - verschiedene Zeichens�tze
> - Unterst�tzung f�r verschiedene Encodings (ISO-8859-x, UTF-8)
> - speicherbare Themes
> - fensterlose Darstellung
---- snap ----
Meine Gedanken dazu: Da spielt einer im Terminal und bunt muss es auch
noch sein!
Bei mir muss ein Terminal lesbar sein, auch wenn Logfiles durchtickern.
Aber das tun sie bei mir nur, wen ich es konkret ben�tige. Mit
Hintergrundfarben, Bildchen, Transparenzen kann ich nix anfangen.....
Geht aber, haben Dir auch einige geantwortet, aber es reichte f�r Dich
nie aus.
Meine Gedanken dazu: Spielkind .....
Erst in Message-ID: <hha33c$44j$1...@hathi.bw-networx.net> kommt die
Aufl�sung (4 Tage sp�ter):
> Bei mir laufen i.d.R. immer Mail (Pine), News (tin), IRC (irssi), ICQ
> (CenterICQ) und bei Bedarf auch eine ganze Reihe anderer interaktiver
> Anwendungen in diversen Terminals. Zumindest Tin scheint in Terminal.app
> schlicht und einfach nicht nutzbar zu sein, da die Hintergrundfarben
> nicht korrekt angezeigt werden.
Wenn Du das Terminal so nutzt... aber deswegen sind andere keine
"Gelegenheitsterminal-User", sondern nutzen den Mac halt anders und
haben ihre Arbeitsweisen in den letzten 20 Jahren an ver�nderte Technik
angepasst. Sorry, nichts f�r ungut. Es bleibt jedem selbst �berlassen,
wie er am liebsten arbeitet. Aber die konkreten Anforderungen, h�ttest
DU gut fr�her formulieren k�nnen. Du h�ttest den anderen damit zeit
erspart.
Hier in *lokale.netze hast in "Time-Machine auf NAS-FReigabe" recht
ausf�hrliche und fundierte Antworten bekommen. Insbesondere weshalb
deine "Frickelei" gerade bei einem sensiblen Thema wie Backup und
Restore keine gute Idee ist. Thomas hat sich den "Engelsgeduld-Award"
wahrlich verdient.
Aber alle technischen Einw�nde weist Du zur�ck, es liegt an Apples
Marktpolitik....
Ich versuche es mal weniger technisch, eher marktpolitisch:
Weshalb sollte Apple NAS-Systeme unterst�tzen, die keine AFP-Freigaben
anbieten?
Nur die weil die meisten mit SMB/CIFS und andere das auch k�nnen ....
Worauf basieren die Freigaben in den NAS Systemen mit SMB/CIFS? SAMBA?
Oder hat Microsoft den Herstellen die nicht ver�ffentlichte Doku �ber
den Tisch geschoben? Willst Du allen Ernstes ein Backup auf einem nicht
ver�ffentlichten Protokoll aufbauen?
Alles das und noch mehr hat man Dir bereits geantwortet, drum spare ich
mir den Rest hier.
Aber dennoch hast Du recht, es ist Apples Politik und die ist mir sehr
sympatisch. Bestimmte Dinge machen Sie einfach nicht.
Vielleicht geht es um Time-Capsules (ich habe so'n Ding nicht und mir
kommt auch keine in's Haus/B�ro), vielleicht aber auch nicht.
Apple bem�ht sich ein m�glichst idiotensicheres und zuverl�ssiges System
zu bringen. "Bem�ht sich" kennen wir aus Arbeitszeugnissen, aber ok, sie
bem�hen sich wenigstens.
Vor einiger Zeit gab es hier mal eine Anfrage eines Windows-Users, der
sich beschwerte, das man im Finder Dateien zwar mit "kopieren" und
"einsetzen" verschieben k�nne, aber dann zur�ck m�sste, um das Original
zu l�schen, Windows k�nne das doch auch.
Warum Apple sowas nicht einbaut erschlie�t sich wahrscheinlich erst,
wenn zwischen "Ausschneiden" und "Einsetzen" der Explorer abgeschmiert
ist.
Noch l�nger zur�ck, gab es mal einen Poster, der Apple den fehlenden
Knopf am Diskettenlaufwerk vorwarf mit der Aussage "Apple traut seinen
Benutzern nicht mal zu, die Disketten selbst auszuwerfen".
Die Antwort aus der Gruppe war: "Doch Apple traut es ihnen zu, deshalb
haben sie es unterbunden."
Also, geh einfach davon aus, dass die Leute hier in der Regel wissen,
wor�ber sie reden, nicht mit allem einverstanden sind und manchmal
seltsame Antworten geben.
Hans J�rgen
Heinz Bastenhorst
> Als Teil der schweigenden Mehrheit melde ich mich. Ja, ich am�siere mich
> k�stlich �ber Joern. Langsam kriege ich Lust, nach langer Zeit wieder
> einmal ein Merkbefreiungsformular hervorzukramen.
Vorsicht damit hast du dich bestimmt als Fanboy geoutet :-).
Ich bekomme langsam eher den Eindruck das der gute Joern ein Troll ist,
der �ber die Weihnachtsfeiertage einfach zuviel Zeit hat.
Auf jeden Fall ist sein Diskussionsstil so unertr�glich, dass er wohl
nicht nur bei mir jetzt gem�tlich seinen Platz im Killfile findet.
Gru�
h1
Joern Bredereck
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Du scheinst nachwievor nicht verstanden zu haben, dass diese alle auf
>> einem v�llig anderen Layer stattfinden kann. Auf dem Blockdevice-Layer
>> gibt es keine Filesystem-spezfifischen Semantiken.
>
> Und du scheinst nicht verstanden zu haben, dass Apple f�r TM beim
> Zugriff auf Netzwerkressourcen andere Anforderungen stellt als beim
> lokalen Zugriff - das Stichwort "locking" fiel ja beispielsweise schon
> mehrfach. F�r AFP wurde das Protokoll entsprechend aufgebohrt, f�r
> andere Dienste geht das nicht so leicht.
Ja, das habe ich auch nie bestritten. Das was technisch m�glich w�re und
das was Apple in seiner Time-Machine implementiert sind eben zwei
verschiedene Sachen. Mir ging es nur darum die Behauptung zu widerlegen,
es w�re technisch nicht m�glich.
> Hast du dir die verlinkte Dokumentation zu den AFP-Erweiterungen, die TM
> gerne h�tte, �berhaupt angeschaut? Auch dort ist es egal, welches
> Dateisystem auf dem Server genutzt wird - dennoch gibt es die
> Erweiterungen um mit dem "locking" und "lock-stealing" klarzukommen.
ja, ich habe sie gelesen. Locking ist beim Mounten eines Blockdevices
allerdings �berhaupt kein Thema. Das Blockdevie-Image kann sowieso immer
nur von einem Client gleichzeit gemountet werden. Mit dieser
Einschr�nkung k�nnte man aber wohl gut leben. Oder wieviele Backups von
wievielen Maschinen willst der typische User zur selben Zeit in den
selben Container machen?
>> Wozu brauche ich da eine Howto.... ich erstelle im
>
> Du hast doch selbst geschrieben, dass du welche genutzt hast.
F�r die NAS-Freigabe, ja. Diesmal ging es mir um einen Container auf
einer USB-Platte.
>> Ich hoffe, dass du nach meinem obigen praktischen Beispiel erkennen
>> konntest, dass ich hierbei eine 100%ig Abstrahierung der Layer
>> durchf�hren m�chte.
>
> Ja, *du* m�chtest das. Apple nicht. Die m�chten netzwerkweit Verf�gbares
> gesondert behandeln. Wenn du meinst, das sei dir egal - dann sieh halt
> zu, dass deine gew�nschten Ziel-Volumes f�r das System z.B. als
> USB-Laufwerke erscheinen. Es gibt da entsprechende propriet�re
> NDAS-L�sungen, bei denen sollte TimeMachine dann auch �bers Netz
> funktionieren. Nat�rlich handelt man sich damit dann ein paar andere
> Probleme ein ... .
Siehe oben: Ich glaube wir reden hier wirklich aneinander vorbei. F�r
mich ist der Thread wie folgt verlaufen:
1. Ich habe eine Howto f�r Mac OS 10.5 ausprobiert und festgestellt,
dass es unter 10.6 nicht geht. Dieses Problem habe ich hier geschildert.
2. Im Anschluss wollten mir einige Leute erkl�ren dass es
a) von Apple nicht gewollte ist
b) technisch gar nicht m�glich w�re.
Meine Meinung zu a) habe ich gepostet - wohl wissend, dass sich daran
nichts �ndern wird. Das hat einige Leute anscheinend gest�rt, weil ich
es gewagt habe, Apples Produktpolitik in Frage zu stellen.
Bez�glich b) habe ich versucht diese These, es sei technisch nicht
m�glich, argumentativ und gestern durch ein praktisches Beispiel zu
widerlegen.
Und inzwischen hat sich ein Meta-Diskussion darum gebildet, ob es denn
�berhaupt sinnvoll ist, Apple zu kritisieren und ob mir das als
Mac-Neuling �berhaupt zustehen w�rde.
>> Deine st�ndigen Einw�nde bez�glich Semantiken und
>> CNIDs zeigen mir, dass du augenscheinlich noch immer nicht verstanden
>> hast, dass es bei einer vollst�ndigen Abstrahierung der Layer vollkommen
>> egal ist, ob das darunterliegende Protokoll nun SATA, (i)SCSI, NFS, CIFS
>> oder AFP heisst.
>
> Eben - *bei* einer vollst�ndigen Abstraktion. Die ist seitens Apple halt
> nicht gew�nscht.
... aber technisch machbar. Und das war mein Punkt. Der Unterschied ist
dir klar?
>> Nein. Wenn ich einen vollst�ndig abstrahierten Blockdevice-Container
>> �ber CIFS anspreche, dann ist das exakt der selbe logische Layer wie iSCSI.
>
> F�r das System ist es aber immer noch erkennbar, ob dein Disk Image auf
> einem lokalen Laufwerk oder einer Netzwerkfreigabe liegt. Wenn du das so
> verbiegst, dass das System das nicht mehr wei� - dann kann auch TM was
> damit anfangen. Und nat�rlich hast du weiterhin die von Thomas schon
> angesprochenen Probleme beim Restore.
TM k�nnte schon etwas damit anfangen. TM will es nur nicht, weil die
Apple-Entwickler es nicht wollen. Ich vermute, dass TM ein entsprechende
Bonjour-Announcement erwartet oder dass ein HFS-Container-Image noch
zus�tzlich irgendwie geflagged wird.
>> Defacto d�rfte es aber so sein, dass sich TM schlicht und einfach am
>> fehlenden Bonjour-Announcement st�rt.
>
> F�r lokale Platten braucht es kein Bonjour. Und das willst du doch, eine
> aus Sicht von TM lokale Platte.
richtig. Und du k�nntest recht haben, dass es nicht nur an dem
Bonjour-Announcement liegt. Letztlich ist mir aber auch egal, welchen
Mechnismus Apple nutzt, um dieses UNERW�NSCHTE Feature nicht zu
erm�glichen.
Mich hat an dieser ganzen Diskussion immer nur gest�rt, dass ich
herablassend als Noob angesehen wurde, weil ich behauptet habe, dass es
technisch durchaus m�glich w�re, WENN MAN (=APPLE) NUR WOLLTE.
> Denn f�r alles, was �bers Netzwerk geht,
> will Apples Implementation ja ein paar zus�tzliche Sicherheiten (z.B.
> was das locking angeht, s.o.) ... .
ja, Apple will das... und bei eine direkten Ablage auf einem CIFS-Share
macht das auch durchaus Sinn. Das Locking bei SMB/CIFS ist in der Tat
eine Katastrophe. Aber wenn ich sicherstelle, dass die Image-Datei
exklusiv genutzt wird (das kann man z.B. durch das simple anlegen einer
versteckten Semaphore-Datei machen), dann kann ich das Locking einen
Layer h�her im HFS-Dateisystem stattfinden lassen und habe somit
�berhaupt keine Locking-Probleme mehr (bzw. die selben, die ich lokal
auch h�tte).
Gerald Eíscher
> Gerald Eï¿œscher <Spa...@fahr-zur-Hoelle.org> wrote:
>
>> Als Teil der schweigenden Mehrheit melde ich mich. Ja, ich amï¿œsiere mich
>> einmal ein Merkbefreiungsformular hervorzukramen.
>
> Vorsicht damit hast du dich bestimmt als Fanboy geoutet :-).
Ich ganz bestimmt, der OS X ganz nï¿œchtern als ein BSD-artiges Unix mit
einer hypscher Oberflï¿œche mit einigen Unzulï¿œnglichkeiten, die IBM schon
vor >15 Jahren besser konnte, sieht und nun ganz bestimmt von den
ï¿œchten[tm] Fanboys (Wo sind eigentlich die Fangirls?) geprï¿œgelt wird ;-)
> Ich bekomme langsam eher den Eindruck das der gute Joern ein Troll ist,
> der ï¿œber die Weihnachtsfeiertage einfach zuviel Zeit hat.
Ich halte ihn eher fï¿œr einen notorischen Besserwisser.
--
Gerald
Joern Bredereck
> Am 28.12.2009 12:57 Uhr schrieb Dietmar Plaï¿œmann:
>> Joern Bredereck wrote:
>>
>>> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
>>> schweigende Mehrheit sich zusammen mit mir ï¿œber solche beleidigten
>>> Leberwï¿œrste amï¿œsiert und einfach nichts dazu sagt.
>>
>> Die schweigende Mehrheit ist ehr ï¿œber deine Postings amï¿œsiert, denn
>> wahrscheinlich hat die schweigende Mehrheit das alles schon durch, was
>> du hier bemï¿œngelst.
>
> Als Teil der schweigenden Mehrheit melde ich mich.
Das widerspricht sich irgendwie. Findest du nicht? :-)
> Ja, ich amï¿œsiere mich
> kï¿œstlich ï¿œber Joern. Langsam kriege ich Lust, nach langer Zeit wieder
> einmal ein Merkbefreiungsformular hervorzukramen.
hast du auch Argumente oder ist das ein simples Hit'n'Run-Bashing?
Joern Bredereck
> Joern Bredereck <jo...@bredereck.net> wrote:
> a) Die "Fanboy"-Quote ist relativ gering
Sch�n. Denn eine unvoreingenommen Herangehensweise halte ich f�r eine
Grundvoraussetzung.
> b) Terminologie aus dem Heise-Forum ist hier nicht der normale
> Umgangston
auch das begr�sse ich.
> c) haben hier einige Leute durchaus (auch berufliche) Erfahrungen mit
> anderen Betriebssystemen, einige verdienen sogar ihr Geld damit.
das wiederum hatte ich nie anders angenommen. Vielleicht sollten diese
Leute aber auch mal zur Kenntnis nehmen, dass auch ein Mac-Einsteiger
nicht zwangsl�ufig ein Noob ist, den man von oben herab "belehren" muss.
Eine Diskussion auf Augenh�he halte ich f�r selbstverst�ndlich. Und nur,
weil sich jemand seit vielen Jahren (wom�glich auch beruflich) mit Macs
besch�ftigt, hat er nicht das Recht einen Mac-Einsteiger von oben herab
anzusprechen.
> d) es gibt hier noch andere, die die Atari-Amiga Kriege kennen und
> hinter sich gelassen haben...
auch das h�tte ich so angenommen. Ich wollte nur herausstellen, dass
mein MacBook Pro nicht mein erster Computer ist, daher hatte ich das
erw�hnt.
> Hier kommen nat�rlich auch nicht selten "Neue" mit der Frage/Aussage:
> "Ich habe das bisher immer so gemacht. Ich m�chte, dass das am Mac
> genauso funktioniert, wie unter meinem bisherigen $OS!"
das muss man differenziert betrachten. Wenn es problemlos m�glich ist,
gewohnte Workflows am Mac beizubehalten spricht zun�chst einmal nichts
dagegen. F�r mich ist der Computer nicht Selbstzweck, sondern ein
Werkzeug f�r die t�gliche Arbeit. Ich habe weder Zeit noch Lust zum
reinen Selbstzweck neue Workflows auszuprobieren. Wenn es erforderlich
ist, bin ich hingegen auch offen f�r neues. Ich w�rde behaupten, dass
ich in den letzten 5 Tagen eine ziemlich steile MacOS-Lernkurve
bew�ltigt habe. Und wisst ihr was: Das meiste davon hat wirklich Spa�
gemacht und ich erkenne viele Vorteile gegen�ber dem was mir meine
bisherigen Arbeitsumgebungen erm�glicht haben. Es w�re daher absurd, mir
zu unterstellen, dass ich nicht offen f�r neues w�re oder auf teufel
komm raus, meinen bisherigen Gnome-Desktop nachbauen wolle. Von daher
finde ich solche Kommentare wie "installier dir doch wieder ein Linux
auf deinem Mac" sehr unpassend und infantil.
> Du beginnst mit der Frage nach einer besseren Einbindung von Aterm oder
> anderen guten Terminalemulation, weil Terminal.app f�r Dich nicht
> ausreicht, dazu bekommst Antworten und auch die Frage, was Dir
> eigentlich fehlt.
>
> In Message-ID: <hgvuq4$ekb$1...@hathi.bw-networx.net> kommt dann die
> Anforderungsliste:
>
> ---- snip -----
>
>> - stufenlos einstellbare Transparenz
>> - Hintergrund-Grafiken
>> - verschiedene Zeichens�tze
>> - Unterst�tzung f�r verschiedene Encodings (ISO-8859-x, UTF-8)
>> - speicherbare Themes
>> - fensterlose Darstellung
>
>
> ---- snap ----
>
> Meine Gedanken dazu: Da spielt einer im Terminal und bunt muss es auch
> noch sein!
Farben k�nnen durchaus dabei helfen Informationen schneller zu
verarbeiten. Farbiges Syntax-Highlighting oder farbige
Directory-Listings k�nnen helfen, seine Arbeit schneller zu erledigen,
weil es zur �bersichtlichkeit beitr�gt.
> Bei mir muss ein Terminal lesbar sein, auch wenn Logfiles durchtickern.
> Aber das tun sie bei mir nur, wen ich es konkret ben�tige. Mit
> Hintergrundfarben, Bildchen, Transparenzen kann ich nix anfangen.....
Hintergrundfarben helfen dabei die verschiedenen Terminals
auseinanderzuhalten und schneller wiederzufinden. Viele Admins verwenden
f�r Root-Shells z.B. ein rotes Terminal, um vor den Root-Rechten zu warnen.
Transparenz hilft dabei den �berblick zu bewahren. Gerade auf einem
Notebook, wo mir nur eine begrenzte Display-Gr�sse zur Verf�gung steht,
muss man mit dem Platz haushalten. Das geht ab einem gewissen Grad nur
noch dadurch, dass man Terminals transparent �bereinanderlegt.
> Geht aber, haben Dir auch einige geantwortet, aber es reichte f�r Dich
> nie aus.
nein, reicht leider auch nicht aus. Die Zielsetzung der Eterm-Entwickler
ist einfach eine andere, als die der Apple-Entwickler. Ich verstehe aber
auch gar nicht, warum ich mich jetzt schon wieder daf�r rechtfertigen
muss, dass mir der Eterm-Approach besser gef�llt als der
Terminal.app-Approach.
Erkl�r mir doch mal, wo f�r die Diskutanten in diesem Thread die
Motivation lag, mich von Terminal.app zu �berzeugen (um das Wort
"missionieren" nicht zu verwenden). Ist es so schwer zu akzeptieren,
dass andere User andere Anforderungen haben, f�r die andere Werkzeuge
besser geeignet sind?
> Erst in Message-ID: <hha33c$44j$1...@hathi.bw-networx.net> kommt die
> Aufl�sung (4 Tage sp�ter):
>
>> Bei mir laufen i.d.R. immer Mail (Pine), News (tin), IRC (irssi), ICQ
>> (CenterICQ) und bei Bedarf auch eine ganze Reihe anderer interaktiver
>> Anwendungen in diversen Terminals. Zumindest Tin scheint in Terminal.app
>> schlicht und einfach nicht nutzbar zu sein, da die Hintergrundfarben
>> nicht korrekt angezeigt werden.
>
> Wenn Du das Terminal so nutzt... aber deswegen sind andere keine
> "Gelegenheitsterminal-User",
kommt darauf an, wie man Gelegenheitsuser definiert. Und vor allem
sollte man sich fragen, ob an diese Bezeichnung unbedingt als abwertend
interepretieren muss. So war sie n�mlich keineswegs gemeint. Ich
verstehe sowieso nicht, warum eine sachliche Diskussion �ber ein
Werkzeug pl�tzlich auf eine pers�nliche Diskussion �ber deren Anwender
rutschen musste. Ich hatte eigentlich kein Interesse daran, die Anwender
in irgendeiner Forum zu bewerten oder �berhaupt nur dar�ber zu
diskutieren. Mit Gelegenheitsuser wollte ich lediglich andeuten, dass es
verschiedene Terminal-L�sungen f�r verschiedene Anwendungsf�lle gibt und
dass es daher keinen Sinn macht mich zu Terminal.app "bekehren" zu
wollen. F�r mich ist und bleibt Eterm das richtige Werkzeug und ob, wie
oft und wie andere user andere Terminal-Emulationen verwenden ist mir
dabei eigentlich ziemlich egal.
> sondern nutzen den Mac halt anders und
> haben ihre Arbeitsweisen in den letzten 20 Jahren an ver�nderte Technik
> angepasst.
Nunja, das hat mit ver�nderter Technik nicht viel zu tun. Eher mit
ver�nderten Anforderungen und Workflows. Aber wenn ich aus diesem Thread
eines gelernt habe, dann dass es jetzt wohl keine gute Idee w�re, �ber
das F�r und Wieder von Terminal-basierten Anwendungen kontra
GUI-Anwendunge zu diskutieren. Nach meinen bisherigen Erfahrungen w�rden
sich dabei wieder einige Leute aus irgendwelchen mir unerfindlichen
Gr�nden angegriffen f�hlen, oder sie w�rden sich veranlasst sehen, mich
auf den "Pfad der Tugend" zu bekehren. Daher lassen wir das besser.
> Sorry, nichts f�r ungut. Es bleibt jedem selbst �berlassen,
> wie er am liebsten arbeitet.
Full-Ack.
> Aber die konkreten Anforderungen, h�ttest
> DU gut fr�her formulieren k�nnen. Du h�ttest den anderen damit zeit
> erspart.
ich ging implizit davon aus, dass die Leser dieses Threads wissen, dass
jemand der 10 Stunden am Tag auf der Kommondozeile verbringt, etwas mehr
tut als am laufenden Band Config-Dateien zu editieren. F�r letzteres
h�tte mir Terminal.app selbstverst�ndlich gereicht.
> Hier in *lokale.netze hast in "Time-Machine auf NAS-FReigabe" recht
> ausf�hrliche und fundierte Antworten bekommen. Insbesondere weshalb
> deine "Frickelei" gerade bei einem sensiblen Thema wie Backup und
> Restore keine gute Idee ist. Thomas hat sich den "Engelsgeduld-Award"
> wahrlich verdient.
Findest du? Also wenn du schon Namen nennen must, dann ist mir Ralf
B�hme besonders positiv aufgefallen. Thomas spielt doch momentan die
beleidigte Leberwurst, weil er den Gelegenheitsterminal-User (sei es aus
�bersteigertem Ego oder weil er sich bei sowas grunds�tzlich
angesprochen f�hlt) auf sich selbst bezogen hat. Dass ich mit dieser
Formulierung gar nicht ihn gemeint habe, wird er jetzt nicht mehr
wahrnehmen k�nnen, da er mich nach eigenem Bekunden im Killfile hat.
Ehrlichgesagt kann ich zum jetzigen Zeitpunkt den Nachteil, der mir
angeblich daraus entstehen soll, noch nicht so recht nachvollziehen. Im
Gegensatz zu den Ausf�hrungen von Ralf haben mich seine �u�erungen nicht
wirklich weiter gebracht, da er mehr damit besch�ftigt war, mich
entweder als Noob zu diffamieren oder sich dar�ber auszuheulen, dass ich
ihm gegen�ber nicht den anscheinend angebrachten Respekt gezollt habe.
Zu guter Letzt hat er sich bei mir komplett als "Fachmann"
diskreditiert, als er behauptet hat, mit Eterm liesse sich kein
Copy'n'Paste zu generischen Mac-Anwendugen (d.h. Non-X11-Anwendungen)
machen.
Aber hey: Das sind nur meine ersten Eindr�cke von ihm. Vielleicht ist er
ja ein charakterlich einwandfreier Kerl, mit extrem viel Ahnung, der
einfach nur ein paar schlechte Tage hatte. Von daher Schwamm dr�ber...
ich bin bestimmt nicht nachtragend.
> Ich versuche es mal weniger technisch, eher marktpolitisch:
>
> Weshalb sollte Apple NAS-Systeme unterst�tzen, die keine AFP-Freigaben
> anbieten?
>
> Nur die weil die meisten mit SMB/CIFS und andere das auch k�nnen ....
>
> Worauf basieren die Freigaben in den NAS Systemen mit SMB/CIFS? SAMBA?
>
> Oder hat Microsoft den Herstellen die nicht ver�ffentlichte Doku �ber
> den Tisch geschoben? Willst Du allen Ernstes ein Backup auf einem nicht
> ver�ffentlichten Protokoll aufbauen?
Naja, das ist dann wohl der Unterschied zwischen Theorie und Praxis. In
der Theorie ist CIFS b�se, weil es unterspezfiziert ist und Apple keinen
Einfluss auf die Implementierungen hat. In der Praxis funktioniert CIFS
"in the wild" hervorragend; �brigens auch um damit Backups zu speichern.
Und das bleibt nicht irgendwelchen "Fricklern" vorbehalten, sondern wird
von namhaften Herstellern so propagiert und in der Praxis auch so
betrieben. Dass es bessere L�sungen gibt, ist unbestritten. Aber die
hier propagierte Meinung, CIFS sei f�r Backups unbrauchbar ist
schlichtweg Geschwafel von Leuten, denen anscheinend der t�gliche
Praxis-Bezug zu solchen L�sungen fehlt.
Wir (ein mittelst�ndisches Systemhaus) sichern bei einer gr�sseren
zweistelligen Anzahl von Kunden auch (d.h. nicht ausschliesslich) auf
Linux-basierte Storage-Systeme. In vielen F�llen kommt iSCSI zum
Einsatz, aber am weitesten verbreitet sind immernoch die CIFS-basierten
L�sungen. Als Software kommt f�r Windows-Server i.d.R. "Drive Snapshot"
von Tom Ehlert zum Einsatz. Diese Software erstellt auf
NTFS-Dateisystemen Image-Container-Dateien, die sich absolut problemlos
per CIFS auf entfernte Storage-Server speichern lassen. Die Integrit�t
der Daten wird schon w�hrend des Schreibens st�ndig gepr�ft und
anschliessend nochmal sowohl gegen die Echtdaten als auch gegen eine
Hash-Datei der Echtdaten zum Zeitpunkt des Snapshots gepr�ft. Die
Container lassen sich �brigens auch direkt aus CIFS-Shares direkt
mounten um z.B. einzelne Dateien wieder herzustellen. �hnlich wie
Time-Machine kann Drive-Snapshot inkrementell sichern.
Alles in allem ist das eine sehr st�rungsarme und stabile L�sung. Wenn
St�rungen auftreten, bleiben diese nicht unbemerkt. Und die meisten
St�rungen, die wir im t�glichen Einsatz haben, sind keineswegs
CIFS-spezifisch, sondern haben ihre Ursache fast immer in
Hardware-Problemen.
Wenn man sieht, wie es eine 1-Mann-Bude wie Tom Ehlert schafft, eine
Backup-Software zu schreiben, die s�mtlich hier genannten
CIFS-Fallstricke zu nehmen weiss und unterm Strich eine zuverl�ssige und
stabile Backup-L�sung darstellt, dann kommen einem eben Zweifel, wenn
jemand behauptet, CIFS sei grunds�tzlich ungeeignet und es w�re f�r
Apple absolut technisch unm�glich eine solche L�sunge auf den Markt zu
bringen.
Da k�nnen die CIFS-Gegener noch so oft auf die zweifelsfrei vorhandenen
Probleme/Nachteile von CIFS verweisen. Es �ndert nichts daran, dass es
Hersteller gibt, die in der Lage sind, L�sungen zu entwickeln, die trotz
der bekannten Widrigkeiten zuverl�ssig und stabil funktionieren. Und es
tut mir leid, aber an solchen L�sungen muss sich Apple dann eben auch
messen lassen und es muss m�glich sein, im Rahmen eines Threads im
UseNet dar�ber zu diskutieren, ohne gleich als Noob und
Apple-Spec-Ignorant hingestellt zu werden.
> Alles das und noch mehr hat man Dir bereits geantwortet, drum spare ich
> mir den Rest hier.
D.h. du wirfst mir jetzt konkret vor, dass ich diese Antworten nicht
einfach unkommentiert zu Kenntnis nehmen, sondern es wage die
technischen Hintergr�nde zu hinterfragen? Oder wie darf ich dich verstehen?
> Aber dennoch hast Du recht, es ist Apples Politik und die ist mir sehr
> sympatisch. Bestimmte Dinge machen Sie einfach nicht.
Das ist doch endlich mal eine Ansage. Endlich mal jemand, der nicht
versucht die Entscheidungen von Apple mit irgendwelchen teilweise
haahneb�chenen technischen Begr�ndungen zu rechtfertigen. Ich bin
sicher, dass Leute wie Thomas weniger versierte Leute mit ihren
professionell aussehenden Rants �ber CIFS beeindrucken k�nnen. Aber mir
sind Leute wie du wirklich lieber, dir einfach sagen wie es ist.
> Apple bem�ht sich ein m�glichst idiotensicheres und zuverl�ssiges System
> zu bringen. "Bem�ht sich" kennen wir aus Arbeitszeugnissen, aber ok, sie
> bem�hen sich wenigstens.
In Puncto Usablity habe ich da wenig zu kritisieren. Was die
Zuverl�ssigkeit angeht, habe ich bislang keine Erfahrungswerte. Aber
wenns so zuverl�ssig wie Tom Ehlerts Drive-Snapshot laufen w�rde, dann
w�rde mir das schon reichen.
> Vor einiger Zeit gab es hier mal eine Anfrage eines Windows-Users, der
> sich beschwerte, das man im Finder Dateien zwar mit "kopieren" und
> "einsetzen" verschieben k�nne, aber dann zur�ck m�sste, um das Original
> zu l�schen, Windows k�nne das doch auch.
> Warum Apple sowas nicht einbaut erschlie�t sich wahrscheinlich erst,
> wenn zwischen "Ausschneiden" und "Einsetzen" der Explorer abgeschmiert
> ist.
Was soll denn in diesem Fall deiner Meinung nach passieren? Die Datei im
Quell-Ordner wird erst gel�scht nachdem die Datei im Ziel-Ordner
erfolgreich geschrieben wurde. Verloren gehen kann daher nichts, falls
du darauf hinauswolltest.
Gru�,
J�rn
Joern Bredereck
F'up2 ignoriert, weil....
Am 28.12.09 18:07, schrieb Daniel Krebs:
> Joern Bredereck <jo...@bredereck.net> wrote:
>> Ich werde in der Zukunft (schon aus Zeitmangel) versuchen auf solche
>> "religi�sen" Exkurse nicht mehr einzugehen. Wer sachlich �ber technische
>> Dinge mit mir diskutieren will, kann das gerne machen. Wer den ersten
>> Anflug von �berheblichkeit oder Ideologie aufkommen l�sst, wird in
>> Zukunft links liegen gelassen.
>
> B�rp._
.... ich wie gesagt kein Interesse an Rechnerkriegen oder ideologisch
gepr�gten Diskussionen habe.
Wenn du mit deinem B�uerchen fertig bist, musst du in
z-netz.alt.rechnerkrieg leider alleine spielen gehen.
Radulph Kader
1jbdugn.1qk8gjx19wwuv0N%schl...@gmx.net:
> Joern Bredereck <jo...@bredereck.net> schrieb:
>
>> Lass mich andersrum fragen: Glaubst du wirklich, dass ein Weltkonzern
>> wie Apple, der sich die besten Software-Entwickler leisten kann, nicht
>> in der Lage w�re, eine simple Funktion anzubieten, die praktisch jede
>> andere Backup-Software auch bereitstellt?
[snip]
> Nochmal: Niemand verlangt von dir, dass du das toll finden sollst.
> Stattdessen will man dir hier erkl�ren, was es mit der "normativen Kraft
> des Faktischen" auf sich hat. Wenn du ein TM-Backup �bers Netz machen
> willst, dann kommst du mit CIFS halt nicht weit. Egal, ob du das toll
> findest oder nicht.
>
Gott habt ihr eine Geduld.
Ich wei� jetzt jedenfalls, worauf ich beim NAS-Kauf zu achten habe. Danke.
Gru�
Radulph
Hans Juergen Meisen
> Am 28.12.09 17:34, schrieb Hans Juergen Meisen:
> .... Und nur, weil sich jemand seit vielen Jahren (wom�glich auch
> beruflich) mit Macs besch�ftigt, hat er nicht das Recht einen
> Mac-Einsteiger von oben herab anzusprechen.
>
Ich hatte nicht den Eindruck, dass jemand von "oben herab" geantwortet
hat. Du hast Hinweise bzgl. Terminal.app, dem Einbinden von Aterm
mittels Script und anderer Arbeitsweisen bekommen. Thomas hat sogar
geschrieben, dass er sich Aterm installiert und ausprobiert, aber den
Vorteil nicht sehen konnte. Die Leute hier machen keinen Apple-Support,
sondern sind ebenfalls an Alternativen interessiert, auch wenn Sie von
"Neuen" kommen. Hier geht es um Austausch, nicht um Dienstleistung.
Auf die Ebene von "langj�hriger Terminaluser" und
"Gelegenheits-Terminal-User" wurde die Diskussion von Dir gebracht.
> F�r mich ist der Computer nicht Selbstzweck, sondern ein Werkzeug f�r die
> t�gliche Arbeit. Ich habe weder Zeit noch Lust zum reinen Selbstzweck neue
> Workflows auszuprobieren.
Das sehen wohl die meisten hier so. Deshalb geht es um Austausch (s.o.)
und nicht um die Verteidung Apple'scher Marketingstrategien.
> Farben k�nnen durchaus dabei helfen Informationen schneller zu
> verarbeiten. Farbiges Syntax-Highlighting oder farbige
> Directory-Listings k�nnen helfen, seine Arbeit schneller zu erledigen,
> weil es zur �bersichtlichkeit beitr�gt.
Nat�rlich. Jeder der im Editor HTML-, C-, Objective-C oder sonstiges
bearbeitet wird Dir das best�tigen...
> > Bei mir muss ein Terminal lesbar sein, auch wenn Logfiles durchtickern.
> > Aber das tun sie bei mir nur, wen ich es konkret ben�tige. Mit
> > Hintergrundfarben, Bildchen, Transparenzen kann ich nix anfangen.....
> ... Transparenz hilft dabei den �berblick zu bewahren. Gerade auf einem
> Notebook, wo mir nur eine begrenzte Display-Gr�sse zur Verf�gung steht,
> muss man mit dem Platz haushalten. Das geht ab einem gewissen Grad nur
> noch dadurch, dass man Terminals transparent �bereinanderlegt.
Ich da l�ngst an die Grenzen meiner Multitaskingf�higkeiten gestossen
und mehrere Terminals �bereinander w�rden mich durch Unlesbarkeit irre
machen.
> Ich verstehe aber auch gar nicht, warum ich mich jetzt schon wieder daf�r
> rechtfertigen muss, dass mir der Eterm-Approach besser gef�llt als der
> Terminal.app-Approach.
Musst Du nicht. Du hast eine andere Arbeitsweise, andere hier aber auch.
> > Erst in Message-ID: <hha33c$44j$1...@hathi.bw-networx.net> kommt die
> > Aufl�sung (4 Tage sp�ter):
> >
> >> Bei mir laufen i.d.R. immer Mail (Pine), News (tin), IRC (irssi), ICQ
> >> (CenterICQ) und bei Bedarf auch eine ganze Reihe anderer interaktiver
> >> Anwendungen in diversen Terminals. Zumindest Tin scheint in Terminal.app
> >> schlicht und einfach nicht nutzbar zu sein, da die Hintergrundfarben
> >> nicht korrekt angezeigt werden.
> >
> > Wenn Du das Terminal so nutzt... aber deswegen sind andere keine
> > "Gelegenheitsterminal-User",
>
> kommt darauf an, wie man Gelegenheitsuser definiert. Und vor allem ...
Mir ging es hier weniger um den Begriff Gelegenheitsuser, als um den
Hinweis, dass deine Anforderungen erst viel sp�ter deutlich wurden.
Anf�nglich entstand der Eindruck, Du wolltest etwas mehr Farbe im
Terminal und Terminal.app k�nne das nicht. Die Diskussion w�re dann
vielleicht anders verlaufen.
> ich ging implizit davon aus, dass die Leser dieses Threads wissen, dass
> jemand der 10 Stunden am Tag auf der Kommondozeile verbringt, etwas mehr
> tut als am laufenden Band Config-Dateien zu editieren. F�r letzteres
> h�tte mir Terminal.app selbstverst�ndlich gereicht.
Naja, ist vielleicht die andere Arbeitsweise.
> > Hier in *lokale.netze hast in "Time-Machine auf NAS-FReigabe" recht
> > ausf�hrliche und fundierte Antworten bekommen. Insbesondere weshalb
> > deine "Frickelei" gerade bei einem sensiblen Thema wie Backup und
> > Restore keine gute Idee ist. Thomas hat sich den "Engelsgeduld-Award"
> > wahrlich verdient.
>
> Findest du? Also wenn du schon Namen nennen must, dann ist mir Ralf
> B�hme besonders positiv aufgefallen.
Ralf sicher auch und noch einige andere.
> Thomas spielt doch momentan die beleidigte Leberwurst, ....
Komm mal davon wieder runter ...
> weil er den Gelegenheitsterminal-User (sei es aus �bersteigertem Ego [...]
> [...]da er mehr damit besch�ftigt war, mich entweder als Noob zu
> diffamieren oder sich dar�ber auszuheulen, dass ich ihm gegen�ber nicht
> den anscheinend angebrachten Respekt gezollt habe.
und davon erst recht...
Schau mal ins Archiv der Gruppe.
> > Oder hat Microsoft den Herstellen die nicht ver�ffentlichte Doku �ber
> > den Tisch geschoben? Willst Du allen Ernstes ein Backup auf einem nicht
> > ver�ffentlichten Protokoll aufbauen?
> Naja, das ist dann wohl der Unterschied zwischen Theorie und Praxis. In
> der Theorie ist CIFS b�se, weil es unterspezfiziert ist und Apple keinen
> Einfluss auf die Implementierungen hat.
In der Theorie ist alles b�se, was nicht �ffentlich und spezifiziert
ist. Sp�testens dann, wenn es um um Kompatibilit�t und Sicherheit geht.
Mit ist auch ODF lieber als .doc oder .pages, auch wenn es von namhaften
Herstellern empfohlen wird.
Aber eigentlich wollte ich mich aus der technischen Diskussion
raushalten. Ich besch�ftige mich seit einigen Jahren wieder mit ganz
anderen Dingen und bin deshalb nicht mehr "auf dem Laufenden".
> In der Praxis funktioniert CIFS "in the wild" hervorragend; �brigens
> auch um damit Backups zu speichern. Und das bleibt nicht irgendwelchen
> "Fricklern" vorbehalten, sondern wird von namhaften Herstellern so
> propagiert und in der Praxis auch so betrieben.
Das streitet auch keiner ab. Die Frage ist nur f�r welche Systeme das
geeignet ist und wie weit die Kompatibilit�t geht.
In Zeiten vor MacOSX wurden beim Mac Dateien in Ressource- und DataFork
gespeichert. Eine Mac-Datei auf dem FTP Server oder auf FAT gespeichert
war nicht mehr zu gebrauchen, es sei denn, sie wurde vorher als
macbinary umkodiert. Die Dateisysteme gaben das aufgrund ihrer
Speizifikation nicht her.
Ok, es wird unter MacOSX anders gel�st, aber es gibt heute noch durchaus
Firmen, die mit klassischen Systemen arbeiten oder im Archiv haben und
stinkig werden, wenn ihre QuarkXpress- oder Photoshopdateien nicht mehr
brauchbar sind. Das sollte man bedenken, z. B. Thomas weiss das ....
> Aber die hier propagierte Meinung, CIFS sei f�r Backups unbrauchbar ist
> schlichtweg Geschwafel von Leuten, denen anscheinend der t�gliche
> Praxis-Bezug zu solchen L�sungen fehlt.
>
> Wir (ein mittelst�ndisches Systemhaus) ....
Kennst Du ein mittleres Systemhaus, dass seinem Kunden empfiehlt bei
zwei piepsenden Platten am RAID den NT-Server und das RAID neu zu
starten? Das zudem dem Kunden erkl�rt, er brauche kein Backup, er habe
ein RAID....
Ich schon.
Dumm wenn der betreffende Kunde den Umschlagsentwurf des neuen Bandes
eines auflagenstarken Jugendromans (ich sag nicht welcher) nicht
p�nktlich liefern kann und wegem der nicht geringen Konventionalstrafe
kurz vor der Insolvenz steht und die Haftpflicht des Systemhauses nicht
zahlen will....
Das ist Praxis.
> Wenn man sieht, wie es eine 1-Mann-Bude wie Tom Ehlert schafft, eine
> Backup-Software zu schreiben, die s�mtlich hier genannten
> CIFS-Fallstricke zu nehmen weiss ...
Yep, aber kann die Software auch �ber AFP auf HFS+?
> Da k�nnen die CIFS-Gegener noch so oft auf die zweifelsfrei vorhandenen
> Probleme/Nachteile von CIFS verweisen. Es �ndert nichts daran, dass es
> Hersteller gibt, die in der Lage sind, L�sungen zu entwickeln, die trotz
> der bekannten Widrigkeiten zuverl�ssig und stabil funktionieren.
Das tut Apple mit Timemachine.
> Und es tut mir leid, aber an solchen L�sungen muss sich Apple dann eben
> auch messen lassen und es muss m�glich sein, im Rahmen eines Threads im
> UseNet dar�ber zu diskutieren, ohne gleich als Noob und
> Apple-Spec-Ignorant hingestellt zu werden.
Nun, Apple hat eigene Spezifikationen, die man nicht ignorieren sollte.
Aber wirft Du nicht einiges durcheinander?
Apple hat mit TimeMachine eine DAU-sichere Backupl�sung geliefert und
nicht die eierlegende Wollmilchsau. Um Dateien in gr��eren Netzwerken
auf entsprechende Devices zu sichern gibt es andere Software, die dann
Archiware oder MediaManager oder sonstwie heisst.
Ich habe mal vor einigen Jahren in der Uni Seminare zum Thema
Iso9000/9001 belegt. Dort ging es um die Qualit�t von Produkten als die
Eigeschaft der Produkte, die definiert werden. Also die Kaffeemaschine
die 8 oder 12 Tassen herstellt. Die 12 Tassen Maschine ist nicht besser
oder schlechter, sie hat andere Eigenschaften. Meine Kaffemaschine macht
nur eine Tasse, daf�r werden die Bohnen frisch gemhlen. Mich jetzt zu
beschweren, dass sie keine 12 Tassen macht ...
> > Aber dennoch hast Du recht, es ist Apples Politik und die ist mir sehr
> > sympatisch. Bestimmte Dinge machen Sie einfach nicht.
>
> Das ist doch endlich mal eine Ansage. Endlich mal jemand, der nicht
> versucht die Entscheidungen von Apple mit irgendwelchen teilweise
> haahneb�chenen technischen Begr�ndungen zu rechtfertigen.
Na so hahneb�chen sind die Begr�ndungen nicht und es ist nat�rlich
Produktpolitik.
> > Warum Apple sowas nicht einbaut erschlie�t sich wahrscheinlich erst,
> > wenn zwischen "Ausschneiden" und "Einsetzen" der Explorer abgeschmiert
> > ist.
>
> Was soll denn in diesem Fall deiner Meinung nach passieren? Die Datei im
> Quell-Ordner wird erst gel�scht nachdem die Datei im Ziel-Ordner
> erfolgreich geschrieben wurde. Verloren gehen kann daher nichts, falls
> du darauf hinauswolltest.
Ich schrieb ja, dass das Beispiel schon �lter ist. Vieleicht ist es
zwischenzeitlich ge�ndert. Es war mal anders.
Worauf ich eigentlich hinaus wollte, ist aber eher, dass nicht alles,
was technisch irgendwie machbar ist, auch sinnvoll ist.
Gru�
Hans J�rgen
Ingo Lembcke
>Als Teil der schweigenden Mehrheit melde ich mich. Ja, ich am�siere mich
>k�stlich �ber Joern. Langsam kriege ich Lust, nach langer Zeit wieder
>einmal ein Merkbefreiungsformular hervorzukramen.
Ich habe ihn bis Mitte Januar ins Killfile gepackt. Danach sehe ich mir das wieder an.
Mfg,
Ingo Lembcke
Ingo Lembcke
Ich biete hier noch ein IBM OS/2 Warp 4.52 noch fast t�glich im Einsatz, VM und Selbstbau-PC (ca. 11-12 Jahre alt).
Ausserdem nat�rlich getestet damals BeOS und QNX.
Guten Rutsch (Wetter wird ja nicht so doll werden zum Jahreswechsel)!
Achja, und Apple hat sich in Frankfurt von der B�rse nehmen lassen, am 22.12.2009.
Keine Ahnung, was das soll, da sie lt. Mitteilung noch im Freiverkehr gehandelt werden, also brauchen sich die Aktion�re keine Sorgen zu machen.
Na dann.
Mfg,
Ingo Lembcke
--
> Yesterday is history. Tomorrow is a mystery. And today? Today is a gift.
> That's why we call it 'The Present'.
Gerald Eíscher
> Am 28.12.09 16:04, schrieb Gerald Eï¿œscher:
>> Am 28.12.2009 12:57 Uhr schrieb Dietmar Plaï¿œmann:
>>> Joern Bredereck wrote:
>>>
>>>> Aber wahrscheinlich ist es auch in dieser Newsgroup so, dass die
>>>> schweigende Mehrheit sich zusammen mit mir ï¿œber solche beleidigten
>>>> Leberwï¿œrste amï¿œsiert und einfach nichts dazu sagt.
>>>
>>> Die schweigende Mehrheit ist ehr ï¿œber deine Postings amï¿œsiert, denn
>>> wahrscheinlich hat die schweigende Mehrheit das alles schon durch, was
>>> du hier bemï¿œngelst.
>>
>> Als Teil der schweigenden Mehrheit melde ich mich.
>
> Das widerspricht sich irgendwie. Findest du nicht? :-)
Nun gehï¿œre ich zur sich ï¿œuï¿œernden Minderheit.
>> Ja, ich amï¿œsiere mich
>> kï¿œstlich ï¿œber Joern. Langsam kriege ich Lust, nach langer Zeit wieder
>> einmal ein Merkbefreiungsformular hervorzukramen.
>
> hast du auch Argumente
Selbstverstï¿œndlich. Dir wurde mehrmals u.A. in
<slrnhjf739.htu...@phg-online.de> lang und breit erklï¿œrt,
weshalb ein Backup ï¿œber CIFS keine gute Idee ist und du faselst
unverdrossen weiter von "Apple Fanboys". Ein derartiges Verhalten
rechtfertigt durchaus eine Merkbefreiung.
--
Gerald
Maurice Bonnet
> Transparenz hilft dabei den �berblick zu bewahren. Gerade auf einem
> Notebook, wo mir nur eine begrenzte Display-Gr�sse zur Verf�gung steht,
> muss man mit dem Platz haushalten. Das geht ab einem gewissen Grad nur
> noch dadurch, dass man Terminals transparent �bereinanderlegt.
F�r dich k�nnte dann evtl. Spaces interessant sein (Systemeinstellungen).
> Erkl�r mir doch mal, wo f�r die Diskutanten in diesem Thread die
> Motivation lag, mich von Terminal.app zu �berzeugen (um das Wort
> "missionieren" nicht zu verwenden).
Das hat niemand versucht. Bis auf einen Punkt (Hintergrundgrafiken)
konnte Terminal deinen Anforderungskatalog erf�llen. Niemand konnte
nachvollziehen (und dein Link auf die Screenshots hat nur Kopfsch�ttel
ausgel�st), warum f�r dich Hintergrundgrafiken so wichtig sind. Wenn es
f�r dich ein must-have-feature ist, gut, ist es f�r andere nicht.
Maurice, dem auch langsam die Geduld ausgeht.
Apple k�nnte, will aber nicht und deshalb kann jetzt Joern nicht, der
gerne m�chte. Mal sehen, wer da nachgibt ...
Michael Lestinsky
> Niemand konnte
> nachvollziehen (und dein Link auf die Screenshots hat nur Kopfsch�ttel
> ausgel�st), warum f�r dich Hintergrundgrafiken so wichtig sind.
Vielleicht kommt da ja ein Foto vom zum jeweiligen Terminal geh�rigen
Remote-Rechner rein, damit er nicht ausversehen die falsche Kiste herunter-
f�hrt? ;-)
Bye,
Michael
Otto Adam
> Das hat niemand versucht. Bis auf einen Punkt (Hintergrundgrafiken)
> konnte Terminal deinen Anforderungskatalog erfï¿œllen.
iTerm kann das.
Hat das irgendeinen Mangel, warum das noch nicht besprochen wurde, oder
habe ich da was uebersehen (habe nicht die ganze Diskussion im Detail
verfolgt)?
mfg
otto
André Igler
> habe ich da was uebersehen
ad*scnr*dio
Gerald Eíscher
> * Maurice Bonnet <mbon...@web.de>:
>
>> Niemand konnte
>> ausgelï¿œst), warum fï¿œr dich Hintergrundgrafiken so wichtig sind.
>
> Vielleicht kommt da ja ein Foto vom zum jeweiligen Terminal gehï¿œrigen
> Remote-Rechner rein, damit er nicht ausversehen die falsche Kiste herunter-
ï¿œh, das wï¿œre gar keine so blï¿œde Idee. Habe mich eben erst gewundert,
warum ich nicht ins Verzeichnis /etc/netatalk/ wechseln kann...
--
Gerald
Otto Adam
> Am 30.12.09 19:15, schrieb Otto Adam:
>> habe ich da was uebersehen
> Ja. Der Faden ist lï¿œngst woanders. :)
Dann habe ich das mit dem iTerm wohl uebersehen.
Der kann aber wirklich Hintergrundbildchen. ;-)
mfg
otto
Gerhard Urban
[skip]
> Dass es kundenfreundlicher w�re, wenn Rad+ zu Rad1.0 r�ckw�rtskompatibel
> w�re, wird bei dieser Gelegenheit dann gerne verschwiegen.
Au, Ja! Das waere dann genau dasselbe wie unter Windows (Kompatibilitaet
von DOS 1.0 bis jetzt)!
Ist das wirklich besser, alte Zoepfe ueber Jahrzehnte beizubehalten?
Mein ja nur
Alles Gute im Neuen Jahr
Gerhard
Gerald Eíscher
> Joern Bredereck schrieb:
> [skip]
>> wï¿œre, wird bei dieser Gelegenheit dann gerne verschwiegen.
>
> Au, Ja! Das waere dann genau dasselbe wie unter Windows (Kompatibilitaet
> von DOS 1.0 bis jetzt)!
DOS 1.0 lï¿œuft mangels Unterstï¿œtzung von 3 1/2"-Disketten nicht auf
aktueller PC-Hardware.
Abgesehen davon, hat die Nicht-Unterstï¿œtzung von CIFS durch TimeMachine
nichts mit verweigerter Rï¿œckwï¿œrtskompabiliï¿œt zu tun, das wurde in diesem
Fred eh lï¿œngst durchgekaut.
> Ist das wirklich besser, alte Zoepfe ueber Jahrzehnte beizubehalten?
Der Zopf namens BIOS dï¿œrfte bald abgeschnitten werden, bald darauf wird
wohl auch der Keyboard-Kontroller fliegen. Apple hat bei seiner
PC-Hardware den Anfang gemacht.
--
Gerald
quic...@gmail.com
nur weil man selbst etwas nicht gut durchdenkt, muß es doch nicht
schlecht sein.
es geht doch nicht nur um "unterstützen" sonder auch um "supporten".
apple hat selbst TC und os x server, auf dem man TM verwenden kann und
dazu 100.000 verschiedene externe platten mit min. 4 unterstützen
schnittstellen.
und wenn das auch noch nicht reicht, kann man sich auch noch ein NAS
kaufen.
die meisten unterstützen TM backups. mein buffalo macht das perfekt.
qnap und synology können das AFAIK auch. aber das ist sicher
rauszufinden, welche das noch können.
ganz den riesengroßen müll muß man sich ja nicht gerade kaufen.
bei TM kann man nicht viel "rumdrehen" und das ist IMHO gut so.
das beste DAU backup, das ich kenne.
ich bin damit zufrieden :-)
my2cent
mike