Moin, * David Haller [02-12-07 22:40]:

On Sat, 07 Dec 2002, Michael Gebhart wrote:

...

ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,

Mit MS-SQL? *muhahaha*

...

Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend. Verzeichnisse verwirren Anfänger immer wieder. Wenn man so einfach alle Dateien sortiert und strukturiert, je nach Art der Abfrage aufgelistet bekommen würde, hätten die wenigstens Probleme einen PC zu bedienen.

Und wie soll es dann ablaufen, wenn du Dateien abspeicherst? Willst du alles einfach auf den Desktop knallen? Oder halt "irgendwo hin"? Womoeglich im Internet-Cache der regelmaessig geloescht wird? Na denn viel Spass!

Klar kommt das 'irgendwo hin', genauso wie das jetzt 'irgendwo hin' gespeichert wird. Wenn man klug ist, macht man heute noch ein paat Angaben wie den Verzeichnisnamen, etwas entsprechendes kann man aber sogar besser bei einem DBFS angeben. (Womit wir wieder halbwegs bei erweiterten Attributen wären.)

Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...

Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?

Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.

Irgendwas ist ja immer.

...

Was haltet ihr von dem neuen Dateisystem, oder der Idee prinzipiell? Wäre so etwas nicht etwas revolutionäres, was sich auch Linux zu eigen machen könnte?

Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.

Es wird unter Garantie auch ein Dateisystemfrontend geben, sonst könnte man ja alle alten Anwendungen in die Tonne schmeißen.

Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben"). Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;)

CPU&-Register: die Person (mit Kurzzeitgedaechnis) L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller

Na, so oft gehe ich nicht in den Keller. Da würde ich eher die Caches weglassen, die sind eh nur technisches Detail. CPU&-Register: die Person (mit Kurzzeitgedaechnis) RAM: Schreibtischoberflaeche/-unterlage Festplatte: Regale/Aktenschraenke im Arbeitszimmer

Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann.

Oder wie beliebige Kriterien, die man dem DBFS mitgeben kann. Thorsten -- If people could put rainbows in zoos, they'd do it. - Hobbes

Moin, * David Haller [02-12-10 00:28]:

On Mon, 09 Dec 2002, Thorsten Haude wrote:

...

...

Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...

Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?

man M$SQL? (kann das eigentlich transactions?)

Ich kann mir nicht vorstellen, daß MS-SQL so schlecht ist wie sein Ruf in dieser Liste.

Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...

Von RDBMS war die Rede, nicht von MySQL.

Ohne ein _zuverlaessiges_ mind. _taegliches_ Backup kannst du statt der DB (naja, fast) auch gleich /dev/null verwenden. Und du willst mir doch nicht weis machen, dass das $JOE_RANDOM_LUSER kaufen und (richtig!) verwenden wuerde, oder?

Stell Dir vor, die Speicherung der Daten könnte man tatsächlich ändern, wenn RDBMS und JFS zusammen entwickelt werden, um eine gemeinsame Aufgabe zu erfüllen.

...

...

Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.

Es wird unter Garantie auch ein Dateisystemfrontend geben, sonst könnte man ja alle alten Anwendungen in die Tonne schmeißen.

Jaja. So ein gutes wie das "Suchen" Dingens von Win9x...

Unter Windows, ja. Unter Unix würde es weiterhin find und grep geben. Thorsten -- He who passively accepts evil is as much involved in it as he who helps to perpetrate it. He who accepts evil without protesting against it is really cooperating with it. - Martin Luther King

Thorsten Haude schrieb am 10.12.2002 um 10:13:18 +0100: Hallo Thorsten,

* David Haller [02-12-10 00:28]:

...

On Mon, 09 Dec 2002, Thorsten Haude wrote:

...

...

Und hast du schonmal an die Sicherheit (erstmal nur i.S.v. Datensicherheit / -konsistenz) gedacht? Fuer mich hoert sich das eher nach Alptraum[1] an...

Huh? Seit wann sind RDBMS dafür bekannt, mit Daten besonders schlampig umzugehen?

man M$SQL? (kann das eigentlich transactions?)

ja.

Ich kann mir nicht vorstellen, daß MS-SQL so schlecht ist wie sein Ruf in dieser Liste.

ist er auch nicht. Aber dies ist eine Linuxliste. Da darf Software von MS nicht gut sein, bzw. ist Software von MS prinzipiel schlecht. Auch wenn genau das Gegenteil der Fall ist :-)

...

Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...

Von RDBMS war die Rede, nicht von MySQL.

da gilt wohl das selbe wie oben geschrieben. Da redet jemand über MS-Software, also ist das schlecht. Und darüber gibt es auch garnichts zu diskutieren :-)

...

Ohne ein _zuverlaessiges_ mind. _taegliches_ Backup kannst du statt der DB (naja, fast) auch gleich /dev/null verwenden. Und du willst mir doch nicht weis machen, dass das $JOE_RANDOM_LUSER kaufen und (richtig!) verwenden wuerde, oder?

Seine Daten ohne Backup irgendeinem Dateisystem anzuvertrauen ist immer mit einer Tendenz zu /dev/null zu sehen. Backups gehören halt dazu, egal was oder wer meine Daten bereithält. Oder glaubst Du etwa irgendeine Versicherung (oder was auch immer) hält aus Datenrettungsgründen seine Daten nur auf einer Platte die ext3 formatiert ist? Weil man die ja mit einem Editor nach einem Absturz bearbeiten kann :-)

Stell Dir vor, die Speicherung der Daten könnte man tatsächlich ändern, wenn RDBMS und JFS zusammen entwickelt werden, um eine gemeinsame Aufgabe zu erfüllen.

wenn ich mit einer vernünftigen DB arbeite, ist das Journalling doch quasi schon dabei.

...

...

...

Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.

warum? Meinst Du nur weil es Dinge schon gibt, darf es keinen neuen, vieleicht besseren Ansatz geben? Wenn es danach geht, würden wir heute alle noch auf Bäumen sitzen und Bananen fressen. Oder darf das bessere nur nicht von MS kommen? Mich hätte mal interessiert was passiert wäre, wenn in der Ausgangsmail nicht MS, sondern SuSE o. Redhat o. Debian o. ... gestanden hätte. Dann währe das mit Sicherheit eine verdammt coole Sache gewesen. Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de

Moin, * David Haller [2002-12-11 20:22]:

On Wed, 11 Dec 2002, Michael Schulz wrote:

...

Thorsten Haude schrieb am 10.12.2002 um 10:13:18 +0100:

...

* David Haller [02-12-10 00:28]:

...

Und hast du schonmal aus den (binaer) Daten einer DB (z.B. mysql) ein .tex wiederhergestellt? Schau doch einfach (via /dev/hdXY im hexeditor!) mal in dein /var/lib/mysql und finde dort eine bestimmte Mail/ein .tex o.ae... Und dann sabotiere mal einen zufaelligen Sektor der HD auf der die DB (-datei) liegt... Viel Spass auch...

Von RDBMS war die Rede, nicht von MySQL.

Nimm eine beliebige RDBMS, mir egal. Ueberschreib der mal einen "passenden" Sektor in den Daten und schau wie das Teil dann noch laeuft...

Du glaubst, man würde dieses Konzept realisieren, indem man $RDBMS installiert, einen FS-Wrapper darumpackt und es dabei belässt? Thorsten -- The only thing necessary for the triumph of evil is for the good men to do nothing. - Edmund Burke

Moin, * Bernd Brodesser [02-12-09 09:14]:

* David Haller schrieb am 07.Dez.2002:

...

On Sat, 07 Dec 2002, Michael Gebhart wrote:

...

ich wollte mal folgendes Thema ansprechen: WinFS, das neue Dateisystem, welches in Microsoft Windows Longhorn zu finden sein soll. Um bei immer größeren Festplatten, mit immer mehr Dateien weiterhin Ordnung zu behalten und Dateien schnell finden zu können arbeitet eine SQL Datenbank im Hintergrund,

Mit MS-SQL? *muhahaha*

Sicherlich kein MS-SQL und auch kein MySQL.

Sicherlich wird es MS-SQL sein, was denn sonst?

Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.

Man kann jedenfalls mit SQL eine Menge Sachen machen, die mit einem nackten Dateisystem mühsamer wären. Allerdings geht es hier vermutlich auch eher um das RDBMS als um das Frontend. Thorsten -- Getting a thrill out of some stupid quote is a sign of idiocy. - turmeric

Moin, * Bernd Brodesser [02-12-09 12:20]:

Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?

Irgendwie schon, die Datenbankengine heißt Jet.

Natürlich geht es um das RDBMS und das sollte doch professionell sein, die höchsten Anforderungen erfüllen. Es hat doch keinen Sinn, wenn man für höhere Ansprüche ein weiteres DBMS auf der Platte bräuchte.

Ich glaube, wir haben hier ein Mißverständnis. Ich spreche hier von Windows, Du offensichtlich nicht. Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt. Thorsten -- The liberty of a democracy is not safe if the people tolerate the growth of private power to the point where it becomes stronger than the democratic state itself. That in its essence is fascism - ownership of government by an individual, by a group or any controlling private power. - Franklin D. Roosevelt

Moin, * Bernd Brodesser [02-12-09 17:15]:

* Thorsten Haude schrieb am 09.Dez.2002:

...

Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.

Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben.

Deine Ansprüche sind hoch. Ich nehme an, Du setzt auch daheim auf mehrfach redundante SANs, load-balancing Cluster und die entsprechende Überwachungssoftware?

MySQL ist ja gut und schön, wenn man damit irgendwelche Killefitzsachen verwalten möchte, aber wenn es auf Datenkonsistenz auch unter erschwerten Bedingungen ankommt, kann man es vergessen.

Das habe ich auch nicht erwähnt.

PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax.

Man wird kaum mit SQL auf seine Daten zugreifen, ich verstehe auch nicht, wie Du auf diese Idee kommst. Auch für SQL-basierte Datenbanken gibt es graphische Frontends, für diesen Zweck wird man sich nochmal mehr Gedanken machen müssen.

ACK = ACKnowledge = Zustimmung

Ich versteh's immer noch nicht. Bei TCP bedeutet ACK nur, daß eine Nachricht angekommen ist. Thorsten -- The existing IP companies have nothing to offer in the new world, and no hope of adopting. Therefore they must fight to the death to maintain the old one. - crucini

Moin, * Bernd Brodesser [02-12-09 20:28]:

* Thorsten Haude schrieb am 09.Dez.2002:

...

* Bernd Brodesser [02-12-09 17:15]:

...

* Thorsten Haude schrieb am 09.Dez.2002:

...

...

Für welchen Zweck? Entweder ich nehme ein DBMS, daß ruhigen Gewissens auch meine Bank auf ihren Host laufen läßt, um mein Geld zu verwalten, oder ich lasse es ganz bleiben.

...

Deine Ansprüche sind hoch. Ich nehme an, Du setzt auch daheim auf mehrfach redundante SANs, load-balancing Cluster und die entsprechende Überwachungssoftware?

Es geht nicht um meine Ansprüche. Es geht um das Dateisystem. Es soll doch wohl universell einsetzbar sein, oder etwa nicht?

Nicht zwingend, die Ansprüche sind eben verschieden. SANs sind letztlich auch universell einsetzbar.

Wenn es universell einsetzbar sein soll, dann muß es auch die Bank auf ihren Host einsetzen können.

Keine Bank würde ihre Daten einem nackten ext3 anvertrauen, und das ist auch gut so.

...

...

PostgreSQL kenne ich nicht, weiß auch nicht, welche Ansprüche es erfüllt. Aber wie gesagt, imho ist SQL sowieso total daneben. Nicht wegen der Funktionalität, sondern wegen der Syntax. Wenn schon alles neu gemacht wird, dann bitte eine Datenbanksprache mit vernünftiger Syntax.

Man wird kaum mit SQL auf seine Daten zugreifen, ich verstehe auch nicht, wie Du auf diese Idee kommst. Auch für SQL-basierte Datenbanken gibt es graphische Frontends, für diesen Zweck wird man sich nochmal mehr Gedanken machen müssen.

Es geht nicht um Frontend, sondern um die Art und Weise, wie der Kernel an seine Daten kommt. Das will auch programmiert sein. Da ist eine vernünftige Syntax auch ganz gut.

Auch das muß nicht mit SQL passieren. Es gibt immer noch Datanbanken, die ohne auskommen (allerdings fällt mir gerade nur eine ein), und zB. Postgres unterstützt das erst, seit es PostgreSQL heißt. Übrigens wirst Du keine Sprache finden, an der niemand etwas auszusetzen hat. Thorsten -- If I have seen further, it is by standing on the shoulders of giants. - Sir Isaac Newton

Moin, * Jan Trippler [02-12-09 21:09]:

On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:

...

* Bernd Brodesser [02-12-09 12:20]:

...

Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?

Irgendwie schon, die Datenbankengine heißt Jet.

Ähem - Jet ist AFAIK die Engine von MS-Access, MS-SQL-Server ist schon ein *richtiges* DBMS (und seitdem es row-level-locking kann, auch für OLTP = *Online Transaction Processing* zu gebrauchen).

Ach. Na, ich habe gehört, daß Jet eben die Basis für beides ist.

Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen.

Wann habe ich das denn versucht?

...

Für Linux gibt es PostgreSQL, das ist wohl das beste System, das es zur Zeit für diesen Zweck gibt.

Für welchen Zweck? Wie sieht es denn mit Interbase, DB/2, Oracle, Adabas, Sap-DB aus?

Das habe ich vergessen, ich meinte natürlich Freie Systeme.

Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn?

Das überlasse ich lieber Leuten, die schlauer sind als ich, wie Du etwa. Thorsten -- If people could put rainbows in zoos, they'd do it. - Hobbes

Moin, * Jan Trippler [02-12-09 23:30]:

On Mon, 09 Dez 2002 at 23:03 (+0100), Thorsten Haude wrote:

...

* Jan Trippler [02-12-09 21:09]:

...

Kannst Du da mal eine kleine Analyse zu geben? Wieveile von diesen DBMS kennst Du denn?

Das überlasse ich lieber Leuten, die schlauer sind als ich, wie Du etwa.

Wir sind heute wieder lustig, ne?

Ich habe nur keinen Bock auf Leute, die sich mit falschen Behauptungen in eine Diskussion einmischen, deren Charakter die vollständig falsch einschätzen. Thorsten -- Auch Hunger ist Krieg. - Willy Brandt

On Die, 10 Dez 2002 at 03:11 (+0100), Bernd Brodesser wrote:

* Jan Trippler schrieb am 09.Dez.2002:

...

On Mon, 09 Dez 2002 at 13:40 (+0100), Thorsten Haude wrote:

...

* Bernd Brodesser [02-12-09 12:20]:

...

...

...

Ich muß gestehen, daß ich MS-SQL nicht kenne, ist das ein reines Frontend?

[...]

...

Nehmt es mir nicht übel, aber irgendwie habe ich den Eindruck, dass Ihr beide nicht so richtig wisst, worüber Ihr da schreibt. Den MS-SQL-Server jedenfalls könnt Ihr offensichtlich nicht einschätzen.

Habe ich irgendwie klar und deutlich geschrieben.

MS-SQL hört sich aber nicht so an, als erfülle es die höchsten Ansprüche, die man an einer DB stellen kann.

Das muss ich mal einem Kunden erzählen: *Produkt xyz hört sich nicht so an, als ob es auf Ihre Anforderungen passt*. Jan

Am Montag, 9. Dezember 2002 10:59 schrieb Thorsten Haude:

Sicherlich wird es MS-SQL sein, was denn sonst?

Ich fänds viel cooler, wenn MS ne Oracle-DB für die Verwaltung der Dateien im nächsten Windows nehmen würde ;-) Aber ich denke der primäre Grund für eine solche Umstellung bei MS dürfte Paladium sein, immerhin wird es reichlich kompliziert das ganze Rechtezeugs zu verwalten, wenn die Daten im Filesystem einfach so rumligen. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

Hallo Matthias, Matthias Houdek schrieb

gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,

Na? Was ist denn nun eine FAT? ;-) Eine FAT ist definitiv keine Datenbank! Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ). Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....

Was soll daran also so wahnsinnig neu sein?

Die Anforderungen an professionelle Serversysteme. Beispiel: Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht. Andere Möglichkeit: Dein Kollege hat versehentlich etwas gelöscht, was besser drin geblieben wäre. Gratulation. Du ersetzt aus Deiner Kopie den fehlenden Teil. Jetzt hat aber Dein Kollege die Karteileiche. Und stell Dir jetzt noch vor, alle drei Versionen geistern in der Firma umher! Da hilft die Datenbank. Du und Dein Kollege braucht dann keine Kopie mehr, das Filesystem "erinnert" sich an die Vorgängerversionen einer einzigen Datei. Noch drei Jahre später kommt Dein Chef und fragt Dich nach einem Dokument mit einem bestimmten Inhalt, weiß aber nicht mehr, daß dies Dein Umsatzbericht war. Und jetzt? Würdest Du jetzt eine Volltextsuche über das Unternehmensnetz starten, brauchte dies nicht nur gewaltige Rechenleistung, es kämen auch auf einmal mehrere (redundante) Dokumente aus verschiedenen Quellen zu Tage (einige haben spätere Berichte teilweise auch noch bei Dir abgeschrieben), die Du nur noch durch lesen qualifizieren kannst. Bei einem Datenbank-Filesystem hättest Du in kürzester Zeit zwar auch alle verschiedenen Ausführungen, aber Du wüstest auch, welches die endgültigen Versionen der Dokumente sind. Der Aufwand das richtige Dokument zu finden ist dann wahrscheinlich um Klassen niedriger. Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel. so long... Achim

Hallo Bernd, Bernd Brodesser schrieb:

Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?

völlig korrekt. Es ist eine simple verkettete Liste aus der Urknallphase der Computertechnik, also nicht einmal Steinzeit ;-) . so long ... Achim

* Adalbert Michelic schrieb am 10.Dez.2002:

* On Tue, 10 Dec 2002 at 18:09 +0100, Achim Luft wrote:

...

Bernd Brodesser schrieb:

...

Du schreibst, wo der erste Speicherpunkt auf der Festplatte liegt. Der nächste Speicherpunkt steht am Ende des ersten Blocks. Ist das

Nein, steht er nicht. Die FAT ist (wie schon der Name sagt) eine Tabelle, die am Anfang der Platte steht, in der je Block die Nummer des Folgeblocks vermerkt ist, oder alternativ ein reservierter Wert, der angibt, daß der File mit diesem Block endet oder der Block defekt/resreviert/$whatever ist.

Aufgrund der Brisanz der enthaltenen Daten wurde FAT meist in zweifacher Ausfertigung abgelegt. Auf die FAT(s) folgte dann das root-Verzeichnis, und dann die eigentlichen Datenblöcke.

...

...

richtig? Wenn dem so ist, dann ist FAT maximal daneben. Das hieße, wenn man irgendwo auf eine große Datei zugreifen will, dann muß man sich immer wieder durchhangeln?

Durchhangeln, ja. Aber wie sollte man sonst unbekannte Mengen von Daten speichern, ohne sich wo durchhangeln zu müssen? ext2 ist in dem Punkt sicher nicht viel besser - um genauer zu sein, um ein Stück aufwendiger.

Moment, moment. Wenn ich mit dem Systemaufruf lseek den Zeiger einer Datei auf eine beliebige, aber feste Position verlege, dann wird zuerst nachgerechnet, im wievielten Block sich die Position befindet. Dann wird in der I-Node nachgesehen, wo sich dieser Block befindet. Dafür sind dann evtl. (bei dreifach indirekte Blöcke) noch drei Zugriffe auf indirekt-Blöcke notwendig. Dann hat man aber den Block und dann wird der Block im Hauptspeicher gelesen und auf der entsprechenden Position gesetzt. So bei ext-Dateisysteme. Wenn ich das mit FAT richtig verstanden habe, muß zuerst der erste Block gelesen werden, dann der zweite usw. bis zum, sagen wir mal fünftausendsechshundertdreiundzwanzigsten. Wenn dem so ist, finde ich das nicht optimal.

...

völlig korrekt. Es ist eine simple verkettete Liste aus der Urknallphase der Computertechnik, also nicht einmal Steinzeit ;-) .

Und trotzdem sind verkettete Listen immer noch verdammt aktuell.

Kommt darauf an, wo. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9

Am Montag, 9. Dezember 2002 23:36 schrieb Achim Luft:

Hallo Matthias,

Matthias Houdek schrieb

...

gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,

Na? Was ist denn nun eine FAT? ;-)

Eine FAT ist definitiv keine Datenbank!

Gut, jetzt wäre zu definieren, was eine Datenbank ist *g*.

Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ).

Oups. Naja, ich hab mich damit seit CP/M-Zeiten nicht mehr bewusst auseinandergesetzt, weil ich es nicht mehr brauchte. Damals wurden dort noch alle Sektoren, in denen die Datei liegt, dort eingetragen (iirc). Aber du hast Recht, wäre sonst wohl auch etwas unhandlich so.

Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....

Muss das eine Datenbank können? Ist das Voraussetzung, um von einer Datenbank reden zu können? Eine Datenbank muss Entitäten mit dazugehörigen Eigenschaften strukturiert aufnehmen können. Das kann eine FAT.

...

Was soll daran also so wahnsinnig neu sein?

Die Anforderungen an professionelle Serversysteme.

Wenn denen damit gerecht würde. Das ist aber noch _die_ Frage ;-)

Beispiel:

Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht.

Na, ob das die M$-Datei-Datenbank kann?

Andere Möglichkeit: Dein Kollege hat versehentlich etwas gelöscht, was besser drin geblieben wäre. Gratulation. Du ersetzt aus Deiner Kopie den fehlenden Teil. Jetzt hat aber Dein Kollege die Karteileiche. Und stell Dir jetzt noch vor, alle drei Versionen geistern in der Firma umher!

Da hilft die Datenbank. Du und Dein Kollege braucht dann keine Kopie mehr, das Filesystem "erinnert" sich an die Vorgängerversionen einer einzigen Datei. Noch drei Jahre später kommt Dein Chef und fragt Dich nach einem Dokument mit einem bestimmten Inhalt, weiß aber nicht mehr, daß dies Dein Umsatzbericht war. Und jetzt? Würdest Du jetzt eine Volltextsuche über das Unternehmensnetz starten, brauchte dies nicht nur gewaltige Rechenleistung, es kämen auch auf einmal mehrere (redundante) Dokumente aus verschiedenen Quellen zu Tage (einige haben spätere Berichte teilweise auch noch bei Dir abgeschrieben), die Du nur noch durch lesen qualifizieren kannst. Bei einem Datenbank-Filesystem hättest Du in kürzester Zeit zwar auch alle verschiedenen Ausführungen, aber Du wüstest auch, welches die endgültigen Versionen der Dokumente sind. Der Aufwand das richtige Dokument zu finden ist dann wahrscheinlich um Klassen niedriger.

Richtig. Wäre schön, wenn das so wäre. Aber es soll doch vom Microsoft kommen ...?

Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel.

Systeme, vorhandene Dateien nach anderen Kriterien als (ausschließlich) ihrem Dateinamen (incl. Pfad) zu klassivizieren, gibt es viele. Ich kenne sowas schon aus den 80ern. Und wenn Microsoft so etwas in das Betriebssystem integriert, wird es sicher so ein Zusatzsystem sein, dass dann so mit systemeigenen DLLs wechselseitig verzahnt wird, dass eines ohne das andere einfach nicht mehr laufen wird (vgl. Internet Explorer)*g* -- Gruß MaxX, Quotenossi und Plenker(er) 8-)

Am Montag, 9. Dezember 2002 23:36 schrieb Achim Luft:

Hallo Matthias,

Matthias Houdek schrieb

...

gegeben haben. Was ist denn z.B. eine FAT? Letztendlich doch eine Datenbank,

Na? Was ist denn nun eine FAT? ;-)

Eine FAT ist definitiv keine Datenbank! Es ist eine schlichte (und ziemlich dumme) Liste, bei der zu jedem Dateinamen der Erste Speicherpunkt auf der Festplatte liegt. Mehr nicht. Die ist nicht einmal auf normalem Wege intern sortierbar (Seit Windows weiß das aber keiner mehr ;-) ).

Keine Verknüpfungen mit anderen Dateien (das kann auch nicht einmal NTFS), Keine redundanzfreie Sammlung von Daten aus unterschiedlichen Quellen, Keine Indizierung der Inhalte....

...

Was soll daran also so wahnsinnig neu sein?

Die Anforderungen an professionelle Serversysteme.

Sorry, da kann ich Dir nicht so recht folgen ...

Beispiel:

Du erstellt einen Bericht über die Umsätze Deines Unternehmens und trägt die Werte Deiner Niederlassung ein. Sodann leitest Du die Datei weiter. Dein Kollege in hält die Datei nicht für vollständig und erweitert diese. ZACK! er hat vergessen der Datei einen neuen Namen zu geben, Deine Version ist verschütt. Oder? Hast Du eine Kopie auf Deinem Rechner? Ja, hast Du. Jetzt gibt es zwei Möglichkeiten: Dein Kollege hat alles richtig gemacht, die neue Datei ist O.K. Dann hast Du wieder eine Karteileiche auf Deinem Rechner, die Du wahrscheinlich in zwei Monaten vergessen hast und desshalb vorsichtshalber nicht löscht, weil Dir gerade nicht einfällt, was drin steht.

Dazu kann man einer/der Datei eine _aussagekräftigen_ Namen geben ... wir sind hier nicht mehr bei DOS!!!

[ .... ]

Soweit zum Funktionsumfang eines EDM/PDM Systems. Diese Funktionalität

Den hast Du ziemlich gut beschrieben, da (nur da) gehört sowas auch hin!!! Es ist aber _kein_ FileSystem!!!

auf Betriebssystemebene herunterzubringen ist IMHO nur eine logische (und sehr umsatzträchtige) Entwicklung. Und M$ hatte immer schon ein Gespür dafür, wie man anderen das Wasser abgräbt. Zudem gibt es schon seit Win3.11 die Möglichkeit einer Datei Zusatzinformationen zu geben. Warscheinlich hat sie kaum jemand genutzt, jetzt wird dies zum Schlüssel.

Echt toll, nur was sollen z.B. meine Webserver damit ??? Solche Systeme leben insbes. davon, daß die Daten entspr. indiziert werden, erklär das mal dem DAU! - Der bekommt es doch heute schon nicht richtig hin seinen (digitalen) Urlaubsfotos richtige (Datei-)Namen zu geben. Alles was das kostet sind Unheimlich Rechenpower und Speicher ... 1. DBMS sind nur relativ schnell, wenn die relevanten Daten/Indizes im RAM liegen. 2. Vergleich mal: a) cat ~/ich/Brief-an-Oma.txt b) SELECT * FROM "Dokumente" where "Text" ~* 'Hallo Oma'; 3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ... Das bringt endlich die Möglichkeiten, auf die Intel und Co. so lange gewartet haben. Jetzt können Sie jedem "Normal-DAU" schlüssig erklären, das er (mindestens) einen P7 mit 12,8 GHz, 4 TByte RAM und eine 12,7 PByte HD (RAID) braucht. Die größere Herausforderung ist herauszufiltern, was nach /dev/null verschoben wird, als immer mehr sinnlosen Müll zu archivieren. Mal ehrlich, alles dorthin, wo es hingehört! Frohes Fest und Tschö Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Mirko Richter | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+

Am Dienstag, 10. Dezember 2002 08:56 schrieb Bernd Brodesser:

* Mirko Richter schrieb am 10.Dez.2002:

...

3. Ausfallsicherheit, wenn die Platte eine Macke hat oder der Strom weg ist, macht das einem normalen (guten) FS relativ wenig Probleme. Eine DB hat da wesentlich mehr Probleme ... happy backuping ...

was? Nein, eine vernünftige DB hat keine Probleme, wenn der Strom ausfällt. Sowas ist doch Aufgabe einer DB, auch unter schwierigen Bedingungen Konsistent zu sein.

Ja das ist so schon richtig, nur wenn der Datenbank der Boden unter den Füßen weggerissen wird, dann hat man mehr Probleme als bei einem normalen FS. Ich hab's schon mal durchgemacht, ist so ca. 2 Jahre her. Das war ne InterBase, da gab es einen Stromausfall, die UPS ist hochgegangen ;) , dadurch wurde div. Plattenfehler verursacht. So ziemlich alle Dateien ließen sich wieder herstellen, nur die Datenbank ließ sich nicht mehr zum Leben erwecken. Alle Versuche scheiterten. Also Backups einspielen, hat bloß 10 Stunden gedauert .... Im Highendbereich macht sowas ja nichts, da werden genügend Maßnahmen getroffen, damit das nicht passiert. - Redundante Sromversorgung - redundante Platten etc. Diesen Aufwand kann/will Otto Normalo einfach nicht betreiben, wo es auf wirkliche Verfügbarkeit ankommt ist auch das Geld dafür da. Was ich meinte, war die Relation zw. DBMS und Normalrechner, weil hier der eine oder andere von diesem System so schwärmten. Bei einer DB kommt es schnell mal zum Supergau - sprich alles wech - wenn kleine Fehler am Speichermedium auftreten. Bei einem normalen FS ist das wesentlich unproblematischer, egal ob ext2 oder FAT ... . Ich mußte schon genügend Daten von Platten retten - hat auch praktisch immer geklappt ;). Es gab genügend Fälle, wo z.B. die Partitionstabelle hin war und damit praktich die ganze Platte Leer oder ein(ige) Sektor(en) der Platte überschrieben worden sind - ob nun durch Dummheit oder z.B. Virus - betrifft dies im allgemeinen nur einzelne Files, wenn das bei einer DB passiert, hast Du größere Probleme. Eine DB2 oder Oracle zum Speichern von Lieschen Müllers Briefchen an Oma ? Für einen 08/15 Arbeitsplatz-PC ist das der blanke OVERKILL! Ich sag immer: "Alles dort, wo es Sinn macht!" MfG Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Mirko Richter | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: m.richter@ngi.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+

Hallo, On Mon, 09 Dec 2002, Manfred Tremmel wrote:

Am Montag, 9. Dezember 2002 10:59 schrieb Thorsten Haude:

...

Sicherlich wird es MS-SQL sein, was denn sonst?

Ich fänds viel cooler, wenn MS ne Oracle-DB für die Verwaltung der Dateien im nächsten Windows nehmen würde ;-) Aber ich denke der primäre Grund für eine solche Umstellung bei MS dürfte Paladium sein, immerhin wird es reichlich kompliziert das ganze Rechtezeugs zu verwalten, wenn die Daten im Filesystem einfach so rumligen.

Ack. *seufz* -dnh -- [Java sei nicht das Gelbe vom Ei] Es ist auch nicht das Weiße vom Ei. Eher das grün-bräunliche eines verschimmelten Gammel-Eis. Java ist die gelbliche Ab- lagerung an Pissoirs. Java ist der Schimmelpilz der IT-Branche. Mag sein, daß es eine Funktion erfüllt, aber sie ist noch nicht gefunden worden. -- fefe

On Mon, 09 Dez 2002 at 09:14 (+0100), Bernd Brodesser wrote: [...]

Abgesehen davon ist SQL eine *kotzwürg* Sprache. Mir hat noch keiner erklären können, warum die Syntax für ein UPDATE so total anders ist als die Syntax für ein INSERT. Und warum z.B AND einmal, wie bei vielen anderen Sprachen, als logisches und, und zum anderen als Aufzähltrenner, wo andere Sprachen ein Komma nehmen, verwendet wird.

[ ] Du hast SQL verstanden. Sorry, aber das ist doch hanebüchener Unsinn, was Du da schreibst! Ein Update soll Feldwerte (also einzelne Spalten) eines oder mehrerer durch eine Bedingung definierter Sätze aktualisieren - ein Insert fügt immer einen kompletten neuen Satz hinzu. SQL arbeitet prinzipiell ergebnismengenorientiert - mit Ausnahme des Insert. Deshalb weicht eben die Insert-Syntax vom Select und Update ab. AND dient genau wie in jeder anderen Sprache auch zum Verknüpfen von Bedingungen (bei SQL eben immer dann, wenn vorher ein WHERE stand) - OR wird übrigens haargenau so behandelt. Immer dann, wenn mehrere Spalten nacheinander aufgezählt werden (Select oder update), dann steht da ein Komma. SQL ist im Gegensatz zu prozeduralen oder objektorientierten Programmiersprachen einfach zu lesen, weil sich die Syntax an die natürliche Sprache anlehnt: select spalte1, spalte2 from tabelle where spalte_x > 100 and spalte_y <> 'Nikolaus'; update tabelle set spalte1 = 'A', spalte2 = 1 where spalte_y like 'Niko%' or spalte_z = '2002-12-24'; insert into tabelle values ('x', 'y', 2); SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima. Wenn ich mir vorstelle, komplexe betriebswirtschaftliche Sachverhalte statt in SQL z. B. in C oder Perl oder PHP mit deren originärem Wortschatz abfragen zu müssen, dann wird mir schlecht. DBMS verbergen die physikalischen Grundlagen der Datenhaltung vor dem Frontend - SQL verbirgt die Art und Weise, wie DBMS die angeforderten Daten beschaffen, vor dem Anwender. [...]

Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.

Doch, wenn es richtig gemacht wird, dann ist es das. Dann muss man nämlich nicht mehr wissen, unter welchem Namen und nach welchen Ordnungskriterien man z. B. ein Angebot für ein neues Archiv vor einem halben Jahr abgelegt hat (Chronologisch? nach Kunden? nach Produkt? nach Preis? nach irgendeinem anderen Kriterium?) und was noch viel interessanter ist - Man kann das lokale Dateisystem ähnlich wie eine gute Suchmaschine verwenden: Das war doch mal was mit Archiv und Angebot - zeige mir mal, was da so auf der Pladde liegt! Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen. Jan

On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:

* Jan Trippler schrieb am 09.Dez.2002: [...]

...

Deshalb weicht eben die Insert-Syntax vom Select und Update ab.

Es weicht aber weit mehr ab, als es müßte.

Hä? Den Satz musst Du mir mal erklären. Nach welchen Kriterien definierst du *als es müsste*? Die Syntax ist so, dass man sie sich sehr leicht merken kann, weil sie wieder an die der natürlichen Sprache angelehnt ist.

...

AND dient genau wie in jeder anderen Sprache auch zum Verknüpfen von Bedingungen (bei SQL eben immer dann, wenn vorher ein WHERE stand) - OR wird übrigens haargenau so behandelt. Immer dann, wenn mehrere Spalten nacheinander aufgezählt werden (Select oder update), dann steht da ein Komma.

Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf.

BETWEEN 15 AND 23

Was ist denn daran auszusetzen? Du sagst doch auch: Zwischen 1 _und_ 6 - und genauso ist die Syntax in SQL.

...

SQL ist im Gegensatz zu prozeduralen oder objektorientierten Programmiersprachen einfach zu lesen, weil sich die Syntax an die natürliche Sprache anlehnt:

Und genau das ist es. Natürliche Sprachen sind nicht logisch. Mag ja leichter zu lesen sein, aber nicht leichter zu schreiben.

Das ist Deine Meinung. Ich behaupte, dass sie viel leichter zu schreiben ist als jede Programmiersprache, weil die Syntax der des gesprochenen Satzes entspricht. Das entspricht im Übrigen auch meinen Beobachtungen bei Kunden.

...

select spalte1, spalte2 from tabelle where spalte_x > 100 and spalte_y <> 'Nikolaus'; update tabelle set spalte1 = 'A', spalte2 = 1 where spalte_y like 'Niko%' or spalte_z = '2002-12-24'; insert into tabelle values ('x', 'y', 2);

Was soll das into? Kann nach einem insert auch was anderes kommen?

Es soll die Les- und Schreibbarkeit verbessern. Natürlich kannst du auch *ins tabelle (x, y, z)* schreiben, nur dann ist eben die Erfassbarkeit nicht mehr so klar (obwohl Du gleich das Gegenteil behaupten wirst).

Bei einem update werden Spalten und Werte direkt zugeordnet, bei einem insert werden zuerst die Spaltennamen aufgezählt, dann die dazugehörige Werte.

Nur dann, wenn nicht alle Spalten mit Werten versorgt werden oder die Reihenfolge eine andere ist als in der Tabelle. Wie ich schon mal geschrieben habe: Ein Update soll einzelne Spalten einer durch Suchkriterien definierten Menge an Sätzen aktualisieren, der insert fügt einen kompletten neuen Satz ein (was anderes macht ja auch keinen Sinn). Warum soll also der Insert genauso aussehen wie der Update? Das wäre genauso, als wenn Du verlangen würdest, dass in C der fgets genauso aussieht wie der fread - sie machen doch auch ungefähr das Gleiche! Der delete wäre ja dann noch viel schlimmer - er hat überhaupt keine Spalten mehr, auweia: delete from tabelle where spaltex = 'Ostern'. Es macht hier einfach keinen Sinn, Spalten anzugeben, weil immer ein ganzer Satz gelöscht wird.

...

SQL (=Structured Query Language) ist mit dem Ziel designed worden, das _Wie_ vor dem Anwender der Sprache zu verbergen - er soll nur noch definieren müssen, _Was_ er als Ergebnis haben will - und das schafft diese Sprache prima.

Nein, ich muß mich an eine enge Syntax halten. In einer natürlichen Sprache bin ich viel freier. Wenn ich mich schon an eine enge Syntax halten muß, dann habe ich viel lieber was logisch aufgebautes, auch wenn es von der natürlich gesprochene Sprache abweicht.

1. Was hat die Einhaltung einer Syntax mit der Struktur von SQL zu tun? SQL ist nach wie vor eine formalisierte Sprache, das habe ich aber auch nicht bestritten. 2. Was an SQL ist unlogisch? 3. Meinst Du nicht, dass jemand, der _nicht_ programmieren kann, mit einer an natürliche Sprachen angelehnten Syntax viel schneller zurecht kommt als mit einer mehr oder weniger kryptischen Symbolik einer Programmiersprache?

Ich kann mir vorstellen, daß es für jemand, der nicht Englisch als Muttersprach hat, und auch keine Sprache, die dem Englischen sehr ähnlich ist, was das Deutsch nun mal ist, seine Probleme hat.

Aha, und der hat es dann mit setuid(), getpwnam() usw. ja so viel einfacher, ja? [...]

Das ist richtig, und das ist ja auch der Vorteil der DB. Aber man muß z.B erst mal die DB­Sprache lernen. Wie etwas sortiert abgelegt wurde, interessiert ja nur insofern, wie schnell eine Suche sein wird. Allerdings wenn ich nach einen bestimmten Inhalt suche, wird es sicherlich auch länger dauern, oder ich muß eine Indexdatei über den Inhalt anlegen. [2] Hmmm.

Seit wann musst Du z. B. bei Google eine DB-Sprache lernen oder einen Index anlegen? Du musst (solange zumindest, bis Computer die unscharfen Formulierungen der natürlichen Sprache einschätzen können) _immer_ ein gewisses Maß an Verabredungen (z. B. für die Formulierung von Suchanfragen) kennen. Und da ist die Schwelle für SQL deutlich niedriger als z. B. C (oder Perl ;-)

...

Ob da nun ein relationales DMBS oder ein objektorientiertes DBMS oder ein ausgewachsenes Dokumentenmanagement- und Retrievalsystem im Hintergrund werkelt, ist erstmal nebensächlich. Fakt ist, dass die Schnittstelle zwischen Mensch und Dateisystem intuitiver zu bedienen sein wird. Da sind auch ausgeklügelte find-grep-sed-awk-Mechanismen bald am Ende, weil sie nur syntaktische Zusammenhänge herstellen können, keine semantischen.

Verstehe ich jetzt nicht.

Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).

Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C.

Das ist aber doch kein Widerspruch zur Aussage, dass sie leichter zu erfassen ist.

[1] Aber mich nur noch teilweise erinnert habe. So häufig ist BETWEEN ja nicht.

[2] Bzw. das System für mich macht. Es bliebe ein dicker Overhead.

Bernd

-- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

On Die, 10 Dez 2002 at 16:55 (+0100), Bernd Brodesser wrote:

* Jan Trippler schrieb am 10.Dez.2002:

...

On Die, 10 Dez 2002 at 03:56 (+0100), Bernd Brodesser wrote:

...

* Jan Trippler schrieb am 09.Dez.2002:

...

...

Stimmt schon. Was ich meinte [1] ist das AND bei BETWEEN. Da rollen sich bei mir die Zähennägel auf.

BETWEEN 15 AND 23

...

Was ist denn daran auszusetzen? Du sagst doch auch: Zwischen 1 _und_ 6 - und genauso ist die Syntax in SQL.

Ja, genau das sagt man, und da ist die deutsche Sprache genauso unlogisch wie die englische. Dieses und hat nichts mit dem logischen und zu tun. Ich glaube nicht, daß dies in jeder Sprache der Welt so ist. Ein Sprecher einer Sprache, die zwichen dieses und und dem logischen und unterscheidet, hat sicherlich schwirigkeiten dies zu verstehen. Mehr als irgend einen englischen Begriff, den man immer übersetzen kann.

Also weisst Du ... - Was soll das jetzt mit einer hypothetischen Sprache, bei der ein *Zwischen a und b* mit einem anderen *und* als bei einem logischen *und* geschrieben wird? Das ist doch Fantasterei! Wenn ein armer Suaheli jetzt grossen Stress dabei kriegt, SQL zu lernen, dann ist mir das völlig egal. Im Englischen ist das das gleiche AND (und an diese Sprache ist nunmal SQL angelehnt), im Deutschen ist es das gleiche UND und in SQL ist es ebenfalls das gleiche AND - das reicht mir. BTW: Das *und* bei dem *zwischen a und b* ist im Prinzip ein logisches, denn BETWEEEN ist einfach eine andere Bezeichnung für: größer gleich a _und_ kleiner gleich b. Tatsächlich kannst Du das BETWEEN in SQL dadurch ersetzen, dann brauchst Du Dich nicht mehr darüber zu ärgern. Ich verstehe Dich nicht, Deine Argumente sind für mich nicht logisch.

Eine Katze hat einen Schwanz mehr als keine Katze. Keine Katze hat zwei Schwänze, also hat eine Katze drei Schwänze.

Hört sich logisch an, ist aber offensichtlich vollkommener Blödsinn. Das liegt daran, daß das Wort "keine" in zwei völlig verschiedene Bedeutungen benutzt wird.

Dass die menschliche Sprache voller Mehrdeutigkeiten ist, das wissen wir. Na und? Java z. B. ist doch genauso mehrdeutig: System.out.println (4 + "2"); ergibt 42 System.out.println (4 + 2); ergibt 6 Sprachelemente ändern ihre Bereutung in Abhängigkeit vom Kontext - egal ob in Deutsch, Englisch, SQL, Java ... [insert / update]

Mir ist es schon öfters untergekommen, daß der User einen Datensatz eingibt. Wenn ein Schlüsselbegriff schon existiert, wird ein UPDATE gemacht, sonst ein INSERT.

In dieser begnadeten Pro*C Schnittstelle von Oracle, in der SQL-Befehle per Präcompiler in C eingebettet wird, hatt man dann ständig mit unterschiedlichen Synatx zu kämpfen.

Ich habe es ein paar Mails vorher schon mal geschrieben: SQL ist eine auf Ergebnis_mengen_ basierende Sprache. Der Update, der genau einen Satz angreift ist nur ein klitzekleiner Spezialfall der Anwendung des Befehls. Nicht umsonst wird bei Updates und Deletes die Anzahl der betroffenen Sätze (affected rows) zurückgeliefert. Der Fall, dass bei Eingabe eines existierenden Schlüssels in einer Maske automatisch ein Update gemacht wird, ist wieder ein Spezialfall. Normalerweise sollte dann zumindest eine Warnung / Sicherheitsabfrage erfolgen, weil es oft gar nicht gewünscht ist, existierende Sätze einfach zu überschreiben. Ich verstehe auch hier wieder nicht, worüber Du Dich eigentlich aufregst. [...]

Wer verwendet den heute noch SQL? Doch wohl nur noch Programmierer, oder etwa nicht. Alle anderen sind mit Eingabemasken und GUIs besser bedient.

Nö, eben nicht. Ich habe einige Admins / DV-Verantwortliche erlebt, die für ihre monatlichen Statistiken SQL einsetzten (weil GUIs eben immer nur einen Teil der Fähigkeiten von SQL zur Verfügung stellen). [...]

Ich habe doch in der Fußnote geschrieben, daß man den Index nicht selber anlegen muß, aber das System müßte es machen. Es entsteht ein gigantischer Overhead.

Ja, wie auch bei der locate-DB oder bei einem Thesaurus - immer wenn ich auf Daten zugreifen will, ohne den gesamten Datenbestand sequentiell durchforsten zu müssen, fällt ein solcher Overhead an. Das ist normal und gewollt. Ein Index dient der Performance-Steigerung und beinhaltet deshalb eine bestimmte Sicht auf einen Teil der indexierten Daten. [...]

...

Lass einen grep z. B. auf den Begriff *high water mark* los - er wird nicht wissen, ob Du was über Hochwasserstände oder über Transaktionspuffer von RDBMS erfahren möchtest. Eine DB, die in der Lage ist, semantische Zusammenhänge herzustellen (ähnlich wie eine gute Spracherkennung), kann den Suchbegriff in einen Kontext einordnen, grep kann das nicht (nur in Verbindung mit anderen Funktionen, über die sich aber der Anfragende klar sein muss).

Äh? Inwieweit macht ein WHERE Column_x LIKE "%high water mark%" irgendwas anderes? Das sucht doch auch, genau wie ein grep nur nach einer Zeichenfolge, ohne den Inhalt zu verstehen.

Wir haben uns doch hier über das *intelligente* Dateisystem aus dem Ausgangsposting unterhalten - oder? Es geht mir hier nicht um relationale DBMS und die Fähigkeiten von SQL. Wir erwarten doch nicht ernsthaft, dass der Benutzer eines solchen Dateisystems seine Daten per SQL sucht, oder?

...

...

Mag ja sein, daß sich die Syntax von SQL lockerer anhört, ist sie aber nicht. Sie muß genauso strikt eingehalten werden, wie die von C.

Das ist aber doch kein Widerspruch zur Aussage, dass sie leichter zu erfassen ist.

Das ist Geschmackssache.

Für mich: EOT - es bringt nichts. Jan

Hallo, On Tue, 10 Dec 2002, Bernd Brodesser wrote:

Ja, schon klar. Bei locate handelt es sich aber nur um Dateinamen. Da ist kein großer Overhead da. Wenn aber ein Index, über den kompletten Inhalt der Dateien existieren soll, dann ist der Overhead doch sicherlich gigantisch.

Muss nichtmal der Inhalt sein... Allein Indices ueber Pfad + saemtliche Attribute (wie von ls+lsattr angezeigt) duerften eine DB auf das x-fache der locatedb aufblaehen. Nimmt man dann noch ein paar Dateiformatspezifische Metadaten dazu, dann waechst die DB sehr schnell. Man schaue sich einfach z.B. mal die von gtktalog angelegte DB zu _einer_ CD, oder die RPM-DBs. Letztere haben bei mir z.B. z.Z. 97MB fuer 1085 Pakete... Und 'rpm -q' ist nicht allzu performant... Sowas als FS??? Nein, wie schon "upthread" geschrieben, danke, darauf kann ich verzichten... -dnh -- Die Bezeichnung Newbie ist also, wie schon soviele vor mir äußerten, keine Beleidigung sondern einfach eine Zustandsbeschreibung für einen bestimmten Wissensbereich. -- Jens Ott in suse-linux

* David Haller schrieb am 10.Dez.2002:

Das ist uebrigens eins der Dinge, die ich an Perl mag -- einen expliziten Konkatenationsoperator ('.'), der ungleich dem Sequenz- (',') und ungleich dem Additionsoperator ('+') ist.

oh ja, laß uns über perl sprechen. ;) perl ist was feines, hat leider nur einen Nachteil: Es erlaubt zuviel. Mal ganz ehrlich, würdest Du gerne an einem in perl geschriebenen Kernel arbeiten? Laß mal die Tatsache weg, daß es nicht sonderlich sinnig ist, einen Kernel in einer Skriptsprache zu schreiben. Ich meine schlicht die Tatsache, wenn eine Millionen Zeilen Quelltext von hunderte verschiedene Leute geschrieben werden. Ich glaube, bei perl blickt da denn keiner mehr durch. Mit perl kann man bösartigen Code schreiben. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

Hallo David, * David Haller schrieb am 11.Dez.2002:

On Wed, 11 Dec 2002, Bernd Brodesser wrote:

...

oh ja, laß uns über perl sprechen. ;) perl ist was feines, hat leider nur einen Nachteil: Es erlaubt zuviel.

Finde ich nicht.

...

Mal ganz ehrlich, würdest Du gerne an einem in perl geschriebenen Kernel arbeiten?

Nein.

...

meine schlicht die Tatsache, wenn eine Millionen Zeilen Quelltext von hunderte verschiedene Leute geschrieben werden.

Und was ist mit dem Kernel? Schonmal "MAINTAINERS" angeschaut? Und mal ein wc -l ueber die Kernelquellen gemacht? Perl ist wesentlich kleiner. Und bei den Modulen die man verwenden will kann man ja vorher reinschauen.

Reden wir aneinander vorbei? Was ich meine, wenn Du etwas an einem Perlskript ändern müßtest, das nicht Du geschrieben hast, sondern ein anderer. Dieses Skript vielleicht noch auf andere Skripte zugreift, die noch andere geschrieben haben. Um eine tiefgreifende Änderung vorzunehmen, mußt Du Dir diese Skripte alle anschauen und auf evtl. Bugs kontrollieren. Und das ganze vielleicht auch noch unter Zeitdruck. Jeder hat einen anderen Stil zu programmieren. Bei perl ist es viel schwieriger durchzusteigen, als etwa bei C.

...

Ich glaube, bei perl blickt da denn keiner mehr durch. Mit perl kann man bösartigen Code schreiben.

Das geht mit C und anderem auch.

Ja, es geht auch mit C, wenn man genug bösen Willen hat. Und es gibt auch Fallstricke bei C. Aber bei perl hat man das, auch ohne bösen Willen, viel schneller. Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4

* Am Don, 12 Dez 2002 schrieb Thorsten Haude:

Moin,

* Bernd Brodesser [2002-12-12 05:44]:

...

Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.

Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.

Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen

Moin, * Christoph Maurer [2002-12-12 10:03]:

* Am Don, 12 Dez 2002 schrieb Thorsten Haude:

...

* Bernd Brodesser [2002-12-12 05:44]:

...

Zum Beispiel wenn das if *nach* dem Befehl kommt, so kann das ganz schön verwirrend sein.

Stimmt; das kann aber auch sehr schick sein, weil es der menschlichen Sprache näher ist.

Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.

Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die; Thorsten -- Das Briefgeheimnis sowie das Post- und Fernmeldegeheimnis sind unverletzlich. - Grundgesetz, Artikel 10, Abs. 1

Moin, * Bernd Brodesser [2002-12-12 10:29]:

* Thorsten Haude schrieb am 12.Dez.2002:

...

* Christoph Maurer [2002-12-12 10:03]:

...

Womit wir wieder bei der SQL-Diskussion wären. Hilft es einer Programmiersprache, wenn sie nahe an der menschlichen Sprache ist, ich denke nicht. Programmiersprachen sollten sich an logischen Grundsätzen orientieren und die menschliche Sprache ist nun mal nicht besonders logisch.

Ich sehe nicht, wo das schaden könnte. Man kann mit typischen Perlismen schon sehr gut lesbare Dinge schreiben, zB.: open $file or die;

Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden.

Mit scheint, Du lehnst die Sprache grundsätzlich ab, weil sie in bestimmten Situationen nicht ideal ist. C taugt also nichts, weil man damit keine Skripte schreiben kann. Thorsten -- A: Top posters Q: What's the most annoying thing about email these days?

Moin, * Christoph Maurer [2002-12-12 11:10]:

Du liest Bernds Mails nicht:

Stimmt, ich habe nicht bemerkt, daß Ihr getauscht habt. Thorsten -- When the government fears the people, it is liberty. When the people fear the government, it is tyranny. - Thomas Paine

* Thorsten Haude schrieb am 12.Dez.2002:

* Bernd Brodesser [2002-12-12 10:29]:

...

Ja, man *kann* Wenn Du aber ein Projekt hast, an dem hundert Leute schreiben, da muß man auch durchblicken, was die anderen so schreiben. Zumindest bei vielen. Und da kann es ganz schön eng werden.

Mit scheint, Du lehnst die Sprache grundsätzlich ab, weil sie in bestimmten Situationen nicht ideal ist. C taugt also nichts, weil man damit keine Skripte schreiben kann.

Blödsinn! Ich mag perl und schreibe viel in perl. Nun gut, gegen David habe ich sicherlich keine Chance. ;) perl hat auch enorme Vorteile. So z.B die regular expressions, die vor perl, und teilweise noch heute, sehr unter verschiedener Definition, verschiedener tools leiden. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

Hallo, On Mon, 09 Dec 2002, Bernd Brodesser wrote:

* David Haller schrieb am 07.Dez.2002:

...

On Sat, 07 Dec 2002, Michael Gebhart wrote: ["WinFS" in ner SQL-DB?] Mit MS-SQL? *muhahaha*

Sicherlich kein MS-SQL

[ ] Du kennst M$. Natuerlich damit. Oder Access. *wuerg*

und auch kein MySQL.

Ok.

Wenn Datenbank, dann was vernünftiges. Oracle oder DB2 oder so. Aber da fängt das Problem schon an. Wenn man es Professionell einsetzt, als damit Geld machen will, dann will Oracle und wahrscheinlich auch IBM, für ihre Datenbank sehr, sehr viel Geld.

[ ] Du kennst M$.

...

...

Wenn es so ablaufen würde und es keine Verzeichnisse oder Laufwerke im Sinne von C: D: geben würde, wäre das meiner Meinung nach ein großer Fortschritt auch die Benutzerfreundlichkeit betreffend.

Bei UNIX gibt es schon seit ewigen Zeiten keine Laufwerkbuchstaben. Das ist nun wirklich nichts Neues.

Eben. Nur kann M$ das nun als tolle Innovation verkaufen...

Ich kann mir schon ein Datenbankbasiertes Dateisystem vorstellen. Aber das wird, für den Anfänger mit Sicherheit nicht einfacher, als ein hirachisches.

Ack. Auch in einer DB muessen die Daten irgendwie strukturiert abgelegt werden, und eben dabei, der Strukturiertheit liegt "das Problem"...

...

Achso, den Festplattenherstellern duerfte das natuerlich gefallen, endlich eine Anwendung, die die neuen Kapazitaeten auslastet. 100 MB Daten, 500 MB Metadaten *rotfl*.

Nun ja, sehr viele Dateien verbraten mehr I-Node, als tatsächliche Daten. Ich weiß auch nicht, warum ein Datenbankorientiertes System soviel Overhead produzieren sollte.

Indizes! Ansonsten waere ne DB aehnlich schnell wie ein find auf ext2. Und damit das ganze "DBFS" sinnvoll ist, muessten mehr Metainformationen als z.B. bei ext2 oder FAT/NTFS abgelegt werden, und diese wuerden natuerlich (mit den Indizes darauf) mehr Platz verbrauchen.

...

Bitte nicht. Danke. Mir reichen die vorhandenen Mittel wie locate, find etc. Noch mehr overhead will und brauche ich nicht.

locate brauche ich nur sehr selten. Da kann man ja nur nach den Namen suchen, nicht aber nach Datum, Größe, oder was auch immer. find kann das, braucht aber ewig, besonders wenn nach Inhalt gesucht wird. ;)

Ein locate <extension> | grep ... | xargs grep -H ... ist i.d.R. deutlich schneller als ein analoges find ... { -exec , | xargs } grep -H ... Natuerlich bedingt das, dass z.B. Extensionen vergeben werden, oder "passende" Verzeichnisse (-bestandteile) verwendet werden. Lege ich z.B. alle Quelltexte in Verzeichnissen ab, in denen irgendwo ein '/src/' vorkommt, so ist ein 'locate /src/ | ...' wesentlich schneller als ein 'find / ...'. Passend mit grep auf Dateinamen und/oder -inhalte kombiniert... Und selbst wenn man aus der locate-Ausgabe noch die Verzeichnisnamen extrahiert (man dirname), und diese dann noch nach nem '| sort -u' noch an find verfuettert... Die Frage ist, wie man die Tools optimal kombiniert, nicht welches man davon (exklusiv) verwendet ;) Mein System, mit (ohne das vergammelte Win 0.95) z.Z. gut 84 GB ist eigentlich ein grosses Chaos, da ueber Jahre hinweg gewachsen (von IIRC mal 2 GB) und immer wieder auf neue HDs umgezogen, mit Doubletten/Backups, mit aus Platzmangel "kurzfristig" auf ne andere Partition/HD ausgelagertem Kram usw. usw... Und dennoch finde ich mit einem locate ... | egrep '\.(foo|bar)' i.d.R. das gesuchte innerhalb von Sekunden, da ich gewisse "Konventionen"/"Kriterien" immer einhalte. Und genau danach kann ich suchen. Z.B. locate foo | grep '/tex-archive/' Das findet mir nur Kram von CTAN ;) Oder: locate foo | grep '^/win[c-f]/' findet mir nur was auf meinen Win-Partitionen...

...

Achso: Was "Anfaenger" verwirrt sind schlicht unpassende Analogien, wenn "man" versucht ihnen das zu erklaeren. Je nach "Hintergrund" der Person sind eben unterschiedliche Analogien angebracht. Schwieriger wird's erst bei der Unix-spezifischen Variante "alles ist eine Datei" (also insbesondere auch Verzeichnisse, Devices (wie Festplatten!) usw. aber das kann man "rausschieben").

Was ist denn daran schwierig? Ist doch viel einfacher als alles andere.

Ja, "eigentlich" schon... Aber mach $DAU dann man den (subtilen) Unterschied zwischen "regular file", "directory", "char device", "block device", "fifo", "socket" usw. klar... Ne, da ist mir (erstmal) die Trennung "Datei", "Verzeichnis" und "anderes" lieber...

Klar, daß eine Festplatte eine Datei ist, muß man vielleicht schon mal schlucken.

Eben. ;)

Aber Grundsätzlich, wenn einem sowas als nicht einfach erscheint, dann kann ich mir das nur durch verbildung durch andere OS erklären.

Ack. Aber: $DAU kapiert auch dort nicht so recht was denn nun Dateien und Verzeichnisse sind. Fuer $DAU ist eine Datei z.B. das, was er in Word sieht. Nicht die Datei auf der HD, nein, das, was Word _anzeigt_! Ganz zu schweigen davon, wenn MacOS und die "Resource Forks" mit ins Spiel kommen *eg*

...

Ansonsten kann man sich meist wunderbar mit der "Buero"-Analogie behelfen und Verzeichnisse sind einfach Aktenordner und -schraenke ;)

CPU&-Register: die Person (mit Kurzzeitgedaechnis)

Ich darf doch schwer bitten. Wenn ich morgens aufwache, brauche ich nicht erst Aktenordner durchzulesen. Ich kann mich auch so erinnern.

*lol* Denk dir einfach ein 'dump(regs, archive)' vor, und ein 'restore(archive, regs)' nach dem schlafen ;) Und zwischendrin ein "mix(regs, archive, /dev/random)" ;) Und ja, das mit dem Gedaechnis ist eine eher bloede Analogie. Der Rest passt besser.

...

L1-Cache: Schreibtischoberflaeche/-unterlage L2-Cache: Ablagefaecher auf dem Schreibtisch RAM: Regale/Aktenschraenke im Arbeitszimmer Festplatte: Archiv im Keller Tapes etc: Backup-Archiv in $FILIALE / $BANK o.ae.

Und "Verzeichnisse" sind also schlicht ein "Ordnungsmittel" wie Hefter/Ordner/Schraenke, in die man "Akten" (-blaetter) einsortieren kann.

Ganz generell, Linux ist nicht nur für Anfänger geschrieben. Ganz im Gegenteil.

Ack. Allerdings: Linux hat (fuer mich) den angenehmen Nebeneffekt, dass man sehr viel ueber Rechner lernen kann... Allein sich mal dmesg in aller Ruhe reinzuziehen... (mit Doku, und evtl. auch mal einen Blick in die Kernelsourcen)... Da lernt man viel davon, was der Rechner denn eigentlich so macht, wenn er ein OS bootet... "Oh, hallo ersma... ick schein zu laufen... Denn wolle mer ma kucken, wat hier so los is... also erstmal isset gut, wenn icke ne CPU finden taet. Denn auf irgendwat schein ick jo ausjefuehrt zu wern, nae? Und denn, was hammwer denn noch so allet? Ah, eine HD? Jut. Denn kucken wer ma, wat da so allet druff is... (usw. ;) ... ah, unn wat zum Krachmachen hamwer oooch?..." -dnh -- Perl is a mess. But that's okay, because the problem space is also a mess. -- Larry Wall

Hallo, On Tue, 10 Dec 2002, Bernd Brodesser wrote:

* David Haller schrieb am 10.Dez.2002: [..] Viel häufiger suche ich nach Dateien, die ich gestern geändert habe, weiß aber leider total nicht mehr, wo ich suchen soll.

Naja, ich hab nur eine handvoll Verzeichnisse, in denen ich arbeite, darin liegen naturgemaess nicht allzuviele Dateien, und dann kann man mit find schnell die Dateien finden.

Was bei mir wirklich häufiger vorkommt, daß ich irgendwas mit yast installieren, yast meint, dann müsse man aber auch noch dies und das installieren, ich sage OK. Später stelle ich fest, daß es doch nicht das ist, was ich brauche und wieder deinstalliere. Das eigentliche Paket, daß ich installiert habe, weiß ich noch, aber die Dinger, die yast mir vorgeschlagen hat - no Chance.

Doch. man rpm und rpm --querytags (und das RPM-Book). rpm -qa --queryformat \ "%{installtime} %{installtime:date} %{name}\n" | sort -n Ein cut -d' ' -f2- falls man die "Epoch"-Zeitangabe weghaben will und/oder ein 'tail -20' kann man ggfs. auch anhaengen... [..]

...

Fuer $DAU ist eine Datei z.B. das, was er in Word sieht. Nicht die Datei auf der HD, nein, das, was Word _anzeigt_!

Bei vi oder auch emacs, stimmt es ja auch weitgehend überein. ;)

*hehe* Aber auch da ist die Datei nicht die Editoranzeige. Besonders auffaellig ist das beim xemacs, der aktuelle Aenderungen in einer _anderen_ Datei speichert... Und erst beim abspeichern landen die Aenderungen in der urspruenglichen Datei ;) -dnh -- How the boss came up with this brilliant idea is so fscking far beyond my logic, that in order to see it clearly, I would have to drain 50% of the blood from my body, and ingest LSD laced with PCP and turpentine. -- Stephen Edwards

Thorsten Haude [8 Dez 2002 14:03:53 +0100]:

Was mir als Umsteiger von OS/2 zB. immer noch fehlt, sind erweiterte Attribute.

Die du in Linux höchstwahrscheinlich nie finden wirst, da sie zu nichts anderem kompatibel sind. Über NFS könnten solche EAs nie übertragen werden und Tools wie tar, cpio und alle Dateipacker wie gzip, bzip2 etc. müssten wie seinerzeit für OS/2 speziell angepasst werden. EAs waren eine nette Idee, aber sie sind auch komplett inkompatibel zum Rest der Welt. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de