Ist mir am Notebook zu unergonomisch, vor allem, wenn man keine feste Unterlage hat.
Welche relevanten nich-Gnome/nicht-KDE-Programme gibt es denn heute noch? Außerdem wir wohl auch eine mehrzahl von denen wohl alle freedesktop.org-kompatiblen Mechanismen unterstützen.
/ralph
-- http://www.flickr.com/photos/sooperkuh/
Weil man damit z.B. nicht "Text" überschreibt, wenn man "text" ins gleiche Verzeichnis reinkopiert?
/ralph
-- http://www.flickr.com/photos/sooperkuh/
Ich vermute mal, du hast hier ein "nicht" vergessen. Trotzdem sehe ich deinen Punkt nicht.
Wenn ich unter Windows ein File "FOO" anlege und danach "foo", lügt mir das blöde Betrübssystem vor, daß es schon ein "foo" habe. Kaputt. Wenn ich dann ls^H^Hdir sage, bekomme ich evtl. sogar "Foo" zu sehen. Eine Systematik konnte ich noch nicht erkennen. Manchmal pfuscht Windows an Groß/Kleinschreibung rum, manchmal nicht.
Und es nützt überhaupt nichts, wenn *eins* der von Windoze unter- stützten Filesysteme das richtig kann, wenn es die anderen und der halbe Überbau dann wieder nicht können.
"Ich will case-sensitive Filenamen" ist eine Ideologie, zu der ich uneingeschränkt stehe.
XL
In article , "Ralph A. Schmid, dk5ras" writes: |> |> Mich für meinen Teil nervt es, auf der Kommandozeile dann mühsam |> Scheiß der Art "vi SuperWichtigesConfigFileDerGanzArgTollenApp" |> eingeben zu müssen.
Stimmt. Aber diese Groß-/Kleinschreibseuche kommt in erster Linie aus der Windows-Welt, wo man weiterhin einen sehr seltsamen Fetisch für den Underscore hegt...
Und wer ein Config-File wie oben benennt, der entstammt ohnehin nicht der reinen Lehre ;)
Rainer
In article , Ralph Aichinger writes: |> |> Welche relevanten nich-Gnome/nicht-KDE-Programme gibt es denn heute |> noch?
Genügend. Nur weil Du sie nicht kennst, heißt es nicht, daß sie nicht existieren.
Rainer
Welchen Grund gibt es denn bitte sehr, Filenamen *nicht* case sensitive zu machen? Mir ist bewußt, daß es mal Regeln a'la "8.3, erlaubt sind Großbuchstaben, Ziffern und Unterstrich" gab. Das war so vor 30 Jahren. Zum Glück hat sich zumindest ein Teil der IT seitdem weiterentwickelt.
Und was hat das jetzt damit zu tun? Ist es nicht unerheblich, ob du "vi SuperWichtigesConfigFileDerGanzArgTollenApp" oder "vi superwichtigesconfigfilederganzargtollenapp" eintippst? Und würde das nicht sowieso "vi Sup" werden?
XL
1) Weil es logisch ist, es ist schliesslich nicht das gleiche. 2) Weil es die simpelste und schnellste Methode ist den Name einfach ungesehen zu uebernehmen. 3) Weil nicht jede Sprache lateinische Buchstaben verwendet, d.h. der betreffende Treiber ist nicht sprachunabhaengig. 4) Weil es seit Jahrzehnten Systeme gibt die case sensitive sind und ich alle Dateien sehen moechte wenn ich sie von dort auf mein System kopiere (ohne vorheriges Umbenennen). 5) Weil das OS machen soll was ich sage und nicht was es denkt das ich meine. 6) Weil es C auch so macht und K&R bekanntlich immer Recht haben ;-)
Das wuerde ja auch nur ein Windows-User komplett eintippen. Mit einer Shell wie z.B. der auf jedem Linux vorhandenen Bash reich vermutlich "vi Su".
Einige Leute arbeiten ja an der Einfuehrung des grossen Scharf-S, mal sehen ob dann beim deutschen Windows 8 wirklich "Fußball.jpg" und "FU?BALL.JPG" die gleiche Datei sind. Wenn nein, waere es ja schliesslich inkonsistent.
Micha
"Axel Schwenke" schrieb im Newsbeitrag news: snipped-for-privacy@xl.homelinux.org...
Sicher nicht.
Natuerlich nicht. Ideologisch vernagelt eben.
Es sagt, dass foo schon vergeben ist. Das ermoeglichst es dir, deinem Arbeitskollegen zu sagen, gibt mir mal die Datei Foo, und der nicht bloed antwortet: FOO haben wir nicht. Wie dir z.B. durch Grossbuchstaben am Satzanfang gelaeufig sein sollte, ist Gross/Klein nur eine andere Form desselben Buchstabens. Nur dumme Betriebssysteme wissen das nicht, weil sie Buchstabenzeichencodes ohne Beruecksichtung des semantischen Inhalts stumpfsinnig numerisch vergleichen.
Vielleicht sogar in Arial oder Courier, Kapitaelchen, so what ?
Ein vollstaendig gross gespeicherter Name wird vom GUI in 'Erster Buchstabe gross, rest klein' gewandelt, alle anderen werden so dargestellt, wie sie gespeichert wurden. Das hat ein GUI-Programmiere wegen besserer Lesbarkeit so entschieden. Er hat Recht, was die Lesbarkeit anlangt, und er hat Recht, das die Bedeutungslosigkeit von Gross- Kleinschreibung anlangt.
Ausser CVS im Eclipse haben eigentlich keines der von mir verwendeten Programme ein Problem mit dem richtigen Umgang mit Dateinamen.
Du hast es schon gesagt. Du bist eben ein Ideologe. Du sagst 'falsch' zu Dingen, die Geschmack sind. Und bei denen es viele Gruende gibt, es anders zu sehen.
-- Manfred Winterhoff
Ralph Aichinger schrieb:
...
Ctrl-C ist nicht in der Shell definiert, sondern in dem /dev/tty, an dem die Shell hängt. Und in der typischen Unix-üblichen ideologischen Verblendung hat man auch diese Funktion konfigurierbar gemacht ;-)
Man klicke Datei->Einstellungen->Device->tty->Steuerzeich..... Quatsch, "stty intr ^E" (Ctrl-V Ctrl-E) und schwupps, ist ^E die Unterbrechung.
Will man aber nicht, weil man dann mit ^E nicht mehr an das Ende der Eingabe springen kann.
Falk, mittlere-Maustasten-Nutzer.
Ack, beim reinen Lesen ist vmtl. auch ein Vorteil messbar.
Es aber schwierig das beim Schreiben so zu handhaben, dass man davon einen Vorteil hat. Das Hauptproblem dabei duerfte das Journal des Dateisystems sein. Damit das Journal seinen Job erfuellt, muss jede Transaktion darauf zugreifen und es muss eine bestimmte Zugriffsreihenfolge eingehalten werden. Um das zu erreichen verwendet man heute Write-Barriers. Mit den gaengigen billigen ATA-Platten kann man die Reihenfolge im Cache aber nicht kontrollieren. Kopiert man mehr Dateien wird also oefter ins Journal geschrieben und wegen mehr Barriers der Cache oefter "geflusht" (was seine Effektivitaet gegenueber Einzelaktionen mindert).
Micha
"Michael Baeuerle" schrieb im Newsbeitrag news: snipped-for-privacy@micha.freeshell.org...
Dass eine schlechte Implementiertung z.B. eines Journals ein Bremser sein kann, ist unbetritten, aber selbst bei FAT (kein Journal, nicht transaktional) bremst sich Windows selber aus.
Eine korrekte Implementation eines transaktionalen Dateisystems betrachtet den Kopiervorgang als ganzes als Transaktion. Es laufen 2 Kopiervorgaenge, wahlweise inklusive Journaleintraegen, die beide in optimierter Reihenfolge durchgefuehrt werden koennen (d.h. neben den aktuellen Dateisystemstand kann der neue Dateisystemstand auf die Platte geschrieben werden), und erst an ihrem jeweiligen Ende festgeschrieben werden muessen, d.h. nur ein Zugriff committed (urgs) die Transaktion, egal wie gross die Kopieraktion vorher war, mithin O(1) und kein Grund, warum etwas langsamer werden sollte.
...funktioniert eine vernuenftige Implementation eines Dateisystems auch mit Journal, auch mit Transaktionen, problemlos.
So macht es eine schlechte Implementation. Es gibt bei drag&drop eines Dateibaums keinen Grund, den kuenstlich in mehrere Transaktionen aufzusplitten.
-- 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.
MaWin schrieb:
...
Was bitte ist "drag&drop eines Dateibaums"? Drag and Drop kenne ich von GUI-Anwendungen, Dateien gibt es auf Betriebssystemebene.
Oder meintest Du rekursives Kopien ganzer Directorystrukturen?
Falk
Außerdem gilt das nur, wenn man das tty im "cooked" mode betreibt. Die überwiegende Mehrzahl heutiger Programme benutzt den "raw" modus und kann damit auch CTRL+C selber fangen.
XL
"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...
Ich meine das, was vorher in diesem Thread als Aufgabe gestellt wurde, denn es ist wissenschaftlicher Unfug, mittendrin die Aufgabenstellung zu veraendern, damit die eigenen Ergebnisse besser passen, so wie du es vielleicht tun willst.
Aber zu deiner Beruhigung: Das rekursive kopieren eines Dateibaums ist die exakt gleiche Operation, nur durch eine andere Benutzerinteraktion ausgeloest. Beides ist EINE Operation und damit EINE Transaktion. Ein Betriebssystem, welches daras mehrere Transaktionen macht (und ggf. mittendrin abbricht und damit nur einen Teil 'committed'), behandelt die Operation FALSCH.
-- Manfred Winterhoff
Ist das wirklich die Mehrzahl? Ich hab' eher den Eindruck, dass üblicherweise da einfach SIGINT abgefangen wird. Sonst könnte man die meisten Programme ja auch nicht mit Strg-Z (SIGTSTP) anhalten.
An Programmen, die Tasten selbst auswerten, fallen mir ad-hoc jetzt nur GNU screen und der Midnight Commander ein. Ok, und vielleicht noch nano.
Gruß Henning
Und das ist eine Lüge. "foo" != "FOO"
Dir ist wirklich kein besseres Beispiel eingefallen? Falls das aus dem Leben gegriffen sein sollte:
Ahh ja.
Die Gefangenen fliegen. Die gefangenen Fliegen.
ist jeweils klar
die gefangenen fliegen
ist nicht entscheidbar. Ich wüßte jetzt nicht, welchen Vorteil ich von einem Betrübssystem hätte, das alle 3 Varianten als identisch ansieht.
Abgesehen davon ist ein Dateisystem ein Dateisystem und keine KI mit der ich mich unterhalten will. Wenn ich sage "mach ein neues File mit Namen foo" dann soll es das tun und mir nicht mit "ich habe aber schon FOO und halte dich für zu blöd, FOO und foo auseinander zu halten" kommen.
Und genau das geht mir an Windoze so auf den Sack. Laufend glaubt es, besser als ich zu wissen, was ich eigentlich will. Intelligente Software wäre vermutlich toll. Aber Software, die Intelligenz nur simuliert und dabei regelmäßig vollkommen daneben liegt, ist Müll.
Auf der selben Wellenlänge liegt auch Excel. Wenn ich "1.1.9" in ein Feld tippe, macht es ungefragt den 1. Januar 2009 daraus. Das ist schlicht kaputt. Solange ich nicht sage, daß das ein Datums-Feld ist, soll es meine Eingaben gefälligst als Strings behandeln.
Du hast immer noch keinen Grund gebracht. Und über deinen Geschmack möchte ich nun wirklich nicht streiten.
Man könnte natürlich auch fragen, warum Windoze denn mir *seinen* Geschmack aufdrängen will. Eben mußte ich spontan an Douglas Adams` Nutrimatic® denken: "Greif zu und genieße!". Wahrscheinlich hat der Mann (bekennender Apple-Fan) da seine Windows-Traumata aufgearbeitet.
XL
"Geh und steck' Deinen Kopf in ein Schwein"
SCNR Henning
Am Fri, 29 May 2009 10:19:05 +0200 schrieb MaWin:
Hi!
Stimmt schon. Man könnte. Aber will man das auch? Man könnte alle freien Sektoren aus der FAT im Cache lesen, alle Daten in einer Wurst in die freien Sektoren schreiben und dann in einer Wurst die FAT updaten. Ist geschwindigkeitstechnisch sicher optimal. Allerdings ist das auch die unsicherste Art irgendwas auf die Platte zu schreiben.
Vor allem warten dann die Applikationen ewiglich bis sie vom BS die Meldung bekommen, daß die Daten nun doch endlich zwischen all den anderen den Weg auf die Platte gefunden haben und auch ordnungsgemäß in der FAT eingetragen wurden.
Nö, danke. Ich bin schon recht zufrieden damit wie NT das handhabt. Wems zu langsam ist, der soll sich einfach ein SCSI RAID zulegen und gut is.
Grüße, Thorsten
"Thorsten Oesterlein" schrieb im Newsbeitrag news: snipped-for-privacy@40tude.net...
Sicher. Wenn du das erste mal ein paar hundert Gigabytes umkopiert hast, weisst du, dass man will.
Kann man, muss man nicht.
Koennte man, wenn man auf diese Art eine Kopie anlegt. Ich persoenlich haette lieber ein 'locken' der Datensektoren gegen ueberschreiben, dann muss man sie zum Kopieren nicht mehr kopieren, sondern nur noch doppelt referenzieren, aber gehen wir mal von einem Umkopieren auf einen anderen Datentraeger aus: Ja, man wird.
Ja. Wenn man die Sektoren auch noch in ihrer physikalischen Reihenfolge schreibt.
Nur wenn man wie du nicht zu Ende denkt. Natuerlich schreibt man die neue FAT (falls wir im Beispiel beim FAT Dateisystem bleiben) ebenfalls in ungenutzte neue Sektoren.
Nur ganz zum Abschluss der Transaktion 'Commit' aendert man den Verweis auf die FAT.
Nur wenn man transaktionale Systeme gar nicht verstanden hat. Natuerlich arbeiten alle Applikationen ungebremst weiter, sie sehen entweder die Platte vor der Kopieraktion, oder die Platte anch der Kopieraktion, aber nie ein Platte inmitten einer halben Kopieraktion.
Damit wird's kaum schneller, es ist Windows, was bremst, die PLatten sind
10 bis 100 mal schneller als das, was ankommt.-- Manfred Winterhoff
"Die meisten nutzen raw" ist wohl richtig, weil alles was readline oder (n)curses benutzt darunter fällt. Kann aber gut sein, daß die Sonder- locken für CTRL+C und CTRL+Z noch eine Ebene tiefer liegen. Und zumindest SIGINT ist ja trivial abzufangen.
Hier gibts ne nette Zusammenfassung:
XL
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.