Ich weiss ja nicht wie Du das machst. Hier laeuft seit 6 Stunden XP volle Kamelle, eine SPICE Sim nach der anderen, 6 weitere Programme auf, Firefox mit 15 Tabs in denen ich dauernd ruehre, es ist >30C in der Huette, der PC Luefter blaest volles Rohr warme Luft raus -> Kein Plop oder Pling. Nicht einer. Dito mit dem Netbook daneben und dem Laptop auf dem Labortisch.
-- Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
[...]
Da ist nicht Windows dran Schuld. Nur die Gier der Handler und die ekelhafte Dummheit der Käufer.
Michael Baeuerle schrieb:
:) :===)
Gratulation! Sie haben soeben 17 Waschmaschinen gekauft!
Guido
Wie ist das bei Windows, ist da eigentlich ? äquivalent A äquivalent ??
/ralph
-- http://www.flickr.com/photos/sooperkuh/
Wieso das? Welches auch nur halbwegs verbreitete UNIX-Filesystem unterstützt keine ACLs? Ich muß ehrlich gestehen, daß ich nie auf die Idee kommen würde, selber ein Samba als "drop in" Ersatz für den zentralen Windoze-Server in einer Windoze-Client-Landschaft aufzusetzen. Windoze soll sterben, da leiste ich doch keine lebensverlängernden Maßnahmen! ;)
Macht Samba diesen Permission-Kram tatsächlich selber, oberhalb des Filesystem-Levels? Wenn ja, will ich nichts gesagt haben...
Ist halt blöd, wenn man gerne "foo" und "FOO" unterscheiden wöllte. Oder wenn CVS seine Metadaten gerne unter CVS/* finden wöllte, statt Cvs/*. Aber hey - man kann sicher auch damit leben, Files nur mit Großbuchstaben im 8.3 Schema zu bezeichnen. Hat einige Jahre prima funktioniert. Mir fällt nur ums verrecken kein Grund ein, warum das erstrebenswert sein sollte.
Ja. C lebt. Pascal ist tot.
OK, das liegt nicht an der case-sensitivity. Eher daran, daß Standard- Pascal eine Totgeburt war und sein lebensfähiger Bruder Turbo-Pascal ausschließlich auf (historischen) Windoze-Architekturen läuft. Von "Runtime Error 205" auf zu schnellen Maschinen schweigen wir besser...
Wenn das Äquivalent von "ln" standardmäßig fe lt, dann würde ich nicht von "beherrschen" von Links sprechen. Und "Junctions" sind auch wieder Sonderlocken. UNIX macht Hardlinks nur für Files, für Directories gehen nur Softlinks. Die Probleme mit "Löschen einer Junction" lösen sich für UNIX damit in ein Logikwölkchen auf.
(ja, ich hab NTFS Junction mal nachgeschlagen und abgefeiert als ich lesen durfte "löschen sie bloß keine Junction mit dem Explorer, weil sie dann auch alle Files darunter löschen. Verschieben in den Papierkorb ist noch ein bisschen subtiler kaputt; da sind die Files im anderen Zweig der Junction dann noch eine Weile da bevor sie verschwinden." Kann man sich gar nicht ausdenken, sowas.)
Über die Möglichkeit endloser Rekursionen in NTFS denke ich jetzt mal lieber nicht nach. Habe ich analog aber mit multiplen Mounts einer Partition einmal als C: und einmal als D:\C und andererseits D: als C:\D schon gesehen. Es ist nur für Außenstehende spaßig, wenn die Suche nach "foo" nicht terminiert weil Windoze endlos C:\D\C\D\C\... absucht. Linux kann mit mount --bind zwar etwas ähnliches, macht aber keine Loops.Es gibt keine UNIX-Filesysteme, die weder Hard- noch Softlinks unterstützen. Dito gibt es keine UNIX-Installationen, die nicht "ln" mitbringen. *Das* ist der Unterschied.
Wenn "Installation zusätzlicher Software" zählt, dann kann Windoze wirklich alles. Notfalls installiert man halt Linux ;)
XL
Am Fri, 29 May 2009 14:14:33 -0700 schrieb Joerg:
Hallo!
Das ist bei XP aber nicht die Standardeinstellung.
Standardmässig nervt NT einfach. Egal ob es nun das Sicherheitscenter ist, die Updates, die Desktop.inis, Autostart bei CDs ...
Um XP so hinzubiegen, daß es so tut wie man will muß schon bissl was tun (und wissen WIE man es tut)
Liebe Grüße, Thorsten
Am Fri, 29 May 2009 21:06:35 +0200 schrieb MaWin:
Genau. Und weil der das entscheidet und nicht die Applikation, kann die Aplikation maximal raten wann ihre Daten geschrieben werden und im schlimmen Fall - aus Sicht der Applikation - dauert es länger die Daten zu schreiben als ohne Scheduler. Und bis nach dem Commit ( über das die App so und so keine Controlle hat ) ist nicht mal sicher, daß die Daten wirklich auf der Platte sind.
Sollte das commit aus welchen Grund auch immer Fehlschlagen, dann hast du so und so die A....karte. Dann kannst ein Rollback machen und aus Maus. Deine Daten sind weg und die App weiß das nicht mal.
Wenn du daraus einen Geschwindigkeitsvorteil ableiten willst, dann musst du die Anfrage serialisieren.
Ausser du verwendest eine der sehr seltenen Platten mit 2 Schreib/Leseköpfen.
Grüße, Thorsten
Am Sat, 30 May 2009 07:50:55 +0200 schrieb Thorsten Oesterlein:
Das scheint mir generell eine geschickte Vorgehensweise.
Lutz
-- Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin auch für Nagios - Nachricht per e-mail,SMS und SNMP:
Am Fri, 29 May 2009 21:09:42 +0200 schrieb MaWin:
Hallo!
Nein. Den Netzstecker kannst du erst nach einem Commit ziehen ohne daß etwas passiert.
Ich habe nie bestritten, daß es schneller geht. Nur geht das auf Kosten der Sicherheit.
Grüße, Thorsten
"Thorsten Oesterlein" schrieb im Newsbeitrag news:1a1ckfcg9l8qx$.14oi1niiw9kab$. snipped-for-privacy@40tude.net...
Wenn du das als Betriebssystemprogrammierer alles so schlecht loesen wuerdest, ja, dann waere das so. Sei versichert, es geht besser.
Leider hab wir - siehe Farnell Thread - nur noch so einfaeltige Informatiker.
-- Manfred Winterhoff
MaWin schrieb:
tiker.
Leider haben wir, siehe die Heimelektronik, seit 30 Jahren nur noch so=20 einf=E4ltige Elektroniker.
Boahr, als ob Informatiker nicht anderes als als Webdorks sind X( ...
Der Typ nervt ...
Bei allen Mängeln in Windows ist das Bashing in diesem Fall einfach nur Quatsch. Diese Einstellung ist lediglich die Vorgabe, vollständig konfigurierbar, und z.B. bei mir selbstverständlich abgestellt.
Wer natürlich zu faul ist, selbst etwas anzupassen, der sollte nicht unbedingt erwarten, daß alle Einstellungen genau seinen Vorlieben entsprechen und muß, wie viele Windowsanwender, eben das fressen, was ihm vorgesetzt wird.
Es war früher *das* Kaufargument für Mac's, daß man nix wissen müsse, aber gleich produktiv arbeiten könne .
Grüße, H.
Ein kompletter fsck ist nicht notwendig, richtig. Aber das Transaktionslog muss geprueft werden und ggf. muessen unvollstaendige Transaktionen wiederholt werden. Also das, was ein journaling FS leistet (wobei die meisten nur die Metadaten absichern und mir nur eines bekannt ist, welches optional[0] auch die Daten absichert).
ACK - und ganz besonders bei Laptops wo ein *piep*piep*Akku_leer* doch gelegentlich mal passiert ;-)
Man liest sich, Alex. [0] Gegen einen entsprechenden Preis - der Durchsatz sinkt dementsprechend.
-- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison
Unwahrscheinlich, die aktuellen disk scheduler sind ziemlich clever. Gutes disk scheduling ist naemlich auch nicht trivial. Dem geneigten Leser sei der entsprechende Quelltext zur Lektuere empfohlen.
Falsch. Auf brauchbaren Systemen existieren Syscalls wie fsync(2) und fdatasync(2), mit denen die Anwendung das Schreiben der Daten auf Disk erzwingen kann. Die Syscalls kehren erst zurueck, wenn das Disksystem meldet, dass die Daten erfolgreich geschrieben wurden. Wenn die Platte natuerlich luegt (gab es mal eine Weile bei IDE-Disks, war toll fuer Benchmarks aber katastrophal fuer Datenbanken), hat man Pech.
Bei Hardwarefehlern/-ausfaellen ist man so oder so angeschmiert, da kann das Betriebssystem nichts fuer. Man kann sowas in gewissen Grenzen durch redundate Systeme abfangen. Man kann es sogar praktisch komplett abfangen[0], aber den Aufwand will keiner bezahlen ;-)
Oder das Journal liegt gar nicht auf Disk sondern auf batteriegestuetztem RAM. Ja, gab und IIRC gibt es noch.
Man liest sich, Alex.
[0] Spontante Komplettzerstoerung der Anlage durch z.B. Feuer oder so mal ausgenommen. Aber selbst das kann abgefangen werden, es kostet nur entsprechend.-- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison
"Alexander Schreiber" schrieb im Newsbeitrag news: snipped-for-privacy@mordor.angband.thangorodrim.de...
Nicht zwingend. Es haengt von der Implementierung ab. Es gibt bessere. Journaling != Transaktional
Unvollstaendige Transaktionen koennen (vom Dateisystempruefprogramm) gar nicht wiederholt werden, weil sie eben unvollstaendig sind. Sie sind nie committed, also nie passiert. Waere es anders, waere es kein transaktionales Dateisystem. Sie muessten von der Applikation wiederholt werden. Was normalerweise bedeutet: Der Benutzer darf nochmal ran. Better save than sorry.
-- Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net homepage: http://www.geocities.com/mwinterhoff/ de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/ Read 'Art of Electronics' Horowitz/Hill before you ask. Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Am Sat, 30 May 2009 13:43:58 +0200 schrieb Heinz Schmitz:
Bei Design kann das sein ;-)
Lutz
-- Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
Schlechtes Argument. Dann wird beim nächsten Mal Text mit Text überschrieben. Und dann?
-ras
-- Ralph A. Schmid http://www.dk5ras.de/ http://www.db0fue.de/ http://www.bclog.de/
Ja, das sind halt die workarounds, weil es "ohne" noch unbrauchbarer wäre. Es gibt aber Fälle, wo es diese Helferlein nicht gibt. Dann darf man den Mist tatsächlich abtippen...
-ras
-- Ralph A. Schmid http://www.dk5ras.de/ http://www.db0fue.de/ http://www.bclog.de/
Dann nimmt man 'vi *' und schon passt das... Faelle wo das alles nicht geht muss man wirklich mit der Lupe suchen. In dem Falle tipp ich das dann eben. Schon sehr lange nicht mehr vorgekommen.
Gerrit
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.