2009-07-20T17:21:29 sid burn

Quote

Datensicherheit im Programmdesign und Backups schließen sich nicht aus, sondern ergänzen sich. Ich mache ja auch Backups von Datenbanken, will aber trotzdem, dass die Datenbank ACID-Transaktionen kann.

Das was du ansprichst ACID-Transaktionen ist aber eine ganz andere Datensicherheit auf einen ganz anderen Level.
[...]

Es geht mir hier aber eben gerade nicht um die Ebene oder die Art und Weise, wie Datensicherheit geboten wird, sondern darum, dass beim Design darauf geachtet wird, dass sie auf vielen Ebenen vorhanden ist.

Quote

Und wenn wir schon bei Datenbanken sind. Datenbanken selber speichern ebenfalls in einem eigenen Binärformat, und die abstraktion hier ist ähnlich hoch, daher man kann es mit eigenen Dateisystem vergleichen.

Bei Datenbanken ergibt das allerdings einen gewissen Sinn, bei Versionskontrollsystemen nicht.

Man kann immer abwägen, ob ein bestimmtes Speicherformat mehr Vor- oder Nachteile bringt. Ein redundantes Textformat wäre bei einer Datenbank wohl kaum angebracht, bei einem Versionskontrollsystem für ein paar Byte Metainformationen allerdings schon.

Bei einem Versionskontrollsystem ist mir auch im Zweifelsfall die Robustheit etwas wichtiger als die Geschwindigkeit.

Quote

So bieten die Datenbanken ja auch in der Regel an direkt mit RAW Devices zu kommunizieren was sogar die Performance erhöht da diese auch Caching etc. selber implementieren.

Solche "Features", wenn sie denn überhaupt existieren (eigentlich fällt mir überhaupt nur Oracle ein, als Datenbank, die das macht), verwende ich auch nicht gerne.

Quote

Es kann hierbei sogar schädlich sein wenn man keine RAW Devices nutzt da sonst ein doppeltes Caching entsteht. Datenbank + Filesystem und dann z.B. ACID nicht mehr gewährleistet sein kann.
[...]

Dann ist meiner Meinung nach die Datenbank eben schlecht programmiert und ich benutze eine andere. Es gibt ja genügend gute Datenbanken, die die von Dir beschriebenen Probleme nicht haben ;-)

Quote

Ansonsten erhöht dir auch ACID nicht die Datensicherheit über die wir gesprochen haben. Gibt es ein defekt an den Binärdateien dann hast du ein problem.

Ordentlich implementierte Transaktionen erhöhen zumindest zeitweilig die Redundanz und senken damit auch die Wahrscheinlichkeit eines Datenverlustes bei einem Crash, der zu diesem Zeitpunkt auftritt.

Wenn die Binärdateien natürlich komplett im Eimer sind, hilft einem das in der Tat nicht weiter.

Quote

Aber deswegen wirst du mir bestimmt gleich sagen das du deswegen auch keine Datenbank nutzt sondern alles schön in performante CSV Dateien auslagerst. ;) :p

Wie gesagt: Es kommt auch auf eine Abwägung von verschiedenen Anforderungen an. Es mag durchaus Situationen geben, wo eine CSV-Datei, weil menschenlesbar, sinnvoller ist als eine binäre Datenbank. Wenn man dazu als Optimierung einen binären Index ablegt, muss das ganze nicht einmal weniger performant sein als eine Datenbank.

Quote

[...]
Aber ansonsten finde ich es nicht albern das du höhere Datensicherheit haben möchtest. Ein Versionierungssystem ist nur einfach keine Software die Datensicherheit bringt, sondern Source Code Verwaltet und Versioniert.

Etwas anderes habe ich ja auch nicht behauptet. Ich will nur, dass jede Software, die ich verwende, in gewissem Maße Rücksicht auf Datensicherheit nimmt. Dazu gehört eben, dass man nicht an völlig unsinnigen Stellen auf Kosten von Robustheit und Datensicherheit auf Geschwindigkeit optimiert.

Ferner frage ich mich auch, warum eine Software, die nur Quellcode verwalten und versionieren soll, einen Dateisystemtreiber enthalten sollte, welchen es ja bereits an anderer Stelle gibt. So etwas führt unnötig zusätzliche Fehlerquellen ein. Dann ist das ganze noch, auch im Sinne der Performanz, in C geschrieben, was wieder zusätzliche Fehlerquellen eröffnet und den Code unnötig komplexer macht, als wenn man statt eines Makroassemblers eine echte Programmiersprache mit Abstraktionsfähigkeiten verwendet hätte.

Quote

Datensicherheit ist sicherlich ein gutes Thema. Ich finde es aber ein Trugschluß wenn man meint das man ein Versionierungssystem nutzt und man hat dann bereits Datensicherheit.

Auch hier legst Du mir wieder Dinge in den Mund, die ich nie gesagt habe...

Quote

Wahrscheinlich habe ich höhere Anforderung an Datensicherheit als du, das ich ein Versionierungssystem nicht in der Kategorie "Datensicherheit" einstufe. ;)

Mir drängt sich eher das Gefühl auf, dass Du absichtlich nicht verstehen willst, wovon ich rede ;-)

Quote

Quote

Zur Geschwindigkeit habe ich gar nichts gesagt [...]

Naja du hast von "effizenz" gesprochen. Was meintest du den dadrunter?

In diesem Falle Platzeffizienz, was meiner Meinung nach deutlich aus dem Kontext zu erkennen war.

Quote

[...]
Einen haufen kleine Dateien zu öffnen ist für ein betriebssystem auffendiger als eine einzelne Datei zu öffnen. Das liegt in der Natur des ganzen.

Das mag vielleicht bei einigen aktuellen Betriebssystemen so sein, allerdings sehe ich keinen Grund, warum das prinzipiell immer so sein sollte.

Im Gegenteil kann ich mir zum Beispiel gut vorstellen, dass das Öffnen und Auslesen von mehreren kleinen Dateien aus einer großen komplexen Verzeichnisstruktur, viel schneller geht als das Öffnen und Herumsuchen in einer einzigen großen komprimierten Datei. Jedenfalls sofern das Dateisystem die Verzeichniseinträge nicht selten dämlich ablegt und erst recht, wenn der ausgewählte Satz kleiner Dateien im Gegensatz zu der einzelnen Großen vielleicht in einen Cache passt. Und genau diese Situation dürfte man bei einem Versionskontrollsystem öfter vorfinden.

Quote

[...]
Was natürlich eine gute Designentscheidung ist, wenn andere Versionierungssysteme zwei unterschiedliche sachen "Reposiory" und "Branches" als das "gleiche" ansieht. ;)

Ja, das Vereinheitlichen von Konzepten um eine neue mächtigere Abstraktionsebene zu schaffen ist tendenziell meistens eine gute Idee.

Quote

[...]
Letztendlich wenn man möchte findet man immer etwas das man aussetzen kann. Mir gefällt die Font nicht. Die Schriftart ist nicht toll. Bei Mercurial nummerieren sich mit Dezimalen zahlen durch, woanders mit römischen zahlen... ;)
[...]

Richtig, deswegen sagte ich ja auch schoneinmal, dass das alles Geschmackssache ist. Unterschiedlichen Leuten sind einfach auch unterschiedliche Dinge wichtig -- wer zum Beispiel schlecht sieht, für den mag eine ungünstig gewählte Schriftart tatsächlich ein Ausschlusskriterium sein ;-)

Quote

[...]
Naja wie gesagt welcher Datenwald? Es gibt zwei Kategorien, einmal HIGH-LEVEL Kommandos und einmal LOW-LEVEL Kommandos. Suchst du ein HIGH-LEVEL Kommando scrollst du zu den HIGH-LEVEL Kommandos und gehst du Alphabetisch Sortierte liste durch.
[...]

Da haben wir eigentlich wieder das gleiche Problem -- eine große Datei versus mehrere kleine: Natürlich sind beide Konzepte im Endeffekt äquivalent, aber die Komplexität des Datenzugriffs verlagert sich an unterschiedliche Stellen. Im Fall mit mehreren Manpages übergebe ich einen Auswahlschlüssel aus meinem Kopf an den Rechner und das Dateisystem erledigt die Vorsortierung, so dass meinem Kopf dann nur die relevanten Informationen zugeführt werden, im anderen Fall bekomme ich den gesamten Datenbestand vorgesetzt und muss im Kopf die Informationen ausblenden, die ich gerade nicht benötige. Da ich als Programmierer von Natur aus faul bin, will ich lieber die stumpfsinnige Maskierung der Information dem Rechner überlassen.

Dass das einzelne große Dokument strukturiert ist, damit die Auswahl der Informationen leichter vonstatten gehen kann, ändert nichts an der Tatsache, dass die Auswahl einfach im falschen Verarbeitungsschritt erfolgt. Aber da das bei Git anscheinend so gewünscht ist und es Menschen gibt, denen das liegt, will ich nichts gesagt haben -- ich selbst muss es ja zum Glück nicht benutzen ;-)