Freigeisterhaus :: Thema anzeigen - Gnome Linux (Ubuntu)

bis

[^/[Drucken]\]
Gehe zu Seite Zurück 1, 2 :| |:
Freigeisterhaus -> DAU's Paradise

#31: Autor: Kramer,

Verfasst am: 06.02.2017, 01:35
—

fwo hat folgendes geschrieben:

Und jetzt mögen die besseren Windowskenner (ich habe keinen Ahnung von Windows) sagen ob ich irre: Ich schätze, dass das Problem, das Du gerade so hoch gehängt hast, auch unter Windows mit Umgebungsvariablen (Path und trallala) relativ elegant gelöst werden könnte.

Wie soll das funktionieren? Windows arbeitet (soweit ich weiss) auch intern mit Laufwerksbuchstaben, das Dateisystem ist so strukturiert. Wenn eine Datei auf der zweiten Festplatte liegt, dann muss ein Programm, das auf diese Datei zugreifen will, wissen, auf welchem Laufwerk sie liegt und welcher Laufwerksbuchstabe diesem Laufwerk zugeordnet ist.

Wenn man mit grösseren Projekten arbeitet, die auf Dateien in unterschiedlichen Verzeichnissen zurück greifen, kann das nach einem Einbau einer neuen Festplatte und dem Kopieren von Projektdateien bedeuten, dass man Stunden damit zubringt, die Dateien neu zuzuweisen. Ist mir schon mehrfach passiert. Da helfen auch keine Umgebungsvariablen, denn die können auch nicht voraus ahnen, wie die Umgebung sich verändert hat.

#32: Autor: DonMartin,

Verfasst am: 06.02.2017, 02:17
—

fwo hat folgendes geschrieben:

Aber damit sind wir nicht mehr bei Windows, sondern bei den schlecht geschriebenen Programmen, die die Möglichkeiten der Umgebungsvariablen nicht nutzen. Aber wer - ich hoffe nicht händisch, sondern in Mustern - nach Doppelpunkten sucht, sollte auch so eine Umstellung schaffen. Nur - und da hast Du auf der kaufmännischen Seite Recht: Da sind sehr viele Leute, die sich sträuben, selbst wenn die Lösung eigentlich bereits implementiert ist.

Es müssen nicht unbedingt schlecht geschriebene Programme sein, sondern einfach pragmatisch entwickelte, die berechtigterweise davon ausgehen, dass ein absoluter Windows-Pfadname mit einem Laufwerksbuchstaben anfängt. Das wäre selbst mit einer Umgebungsvariablen nicht anders, denn die müssen auch mit irgendwas enden, zB einem Doppelpunkt. Unter den Unixoiden fängt eine solche mit dem $ an und endet für gewöhnlich mit einem Schrägstrich. Damit gäbe es auch hier keine neutrale Spezifikation.
Umgebungsvariablen als Bestandteil von Dateinamen sind auch problematisch, wenn sie nicht von allen Komponenten des BS ausgewertet werden. Ob Windows das tut weiss ich nicht, unter Unixoiden bekommt man das umsonst nur in Shell-Umgebungen, der fopen() Aufruf der C-Bibliothek zB macht das mW nicht automatisch.
Besser dran sind hier so Exoten wie VMS oder das ehrwürdige AmigaOS, die haben sowas wie "logische Namen" (ebenfalls durch Doppelpunkt abgetrennt), welche stellvertretend für alles mögliche stehen können: Platten, Verzeichnisse, Geräte.
Logische Namen sind so tief im BS vergraben, dass alle Teile desselben was damit anfangen können.

#33: Autor: fwo, Wohnort: im Speckgürtel

Verfasst am: 06.02.2017, 02:24
—

Kramer hat folgendes geschrieben:

fwo hat folgendes geschrieben:

Ich sagte doch, dass ich kein Windows-Apologet bin.

Aber Wikipedia sagt mir, dass Windows Umgebungsariablen und innerhalb dieser Pfadvariabeln kennt. Das heißt, dass in Command ein Prozessor für soetwas eingebaut ist. Und da Pfaddefinitionen in der Laufzeit festgelegt werden (bei Windows m.W. so wie es jetzt ist, nur durch einen Batch beim beim Booten, dann heißt das da Programm die prinzipiell auch nutzen können - ob Deine tun, das weiß ich nicht.

Das hier war die Aussage um die es mir ging:

DonMartin hat folgendes geschrieben:

luc hat folgendes geschrieben:

Das hoffe ich auf jeden Fall. C: konnte dann überall C: heißen und nicht xhppfflnuff oder etwas Ähnliches. zwinkern

Ob ein Geräte C: oder /dev/irgendwas heisst hat aber mit Textverarbeitung nichts zu tun, sondern gehört zum Eingemachten der jeweiligen Betriebssysteme.
Dass ein Teil der Autos nur mit Diesel fährt, ein anderer Teil nur mit Benzin, ist ja auch kein böswilliger Marketingtrick, sondern hat technische Gründe.

So tief im Eingemachten, wie DonMartin meint, ist das nicht, es ist aus Systemprogrammierersicht relativ wenig, was da zu machen ist und es sieht auch so aus, als sei da schon länger eine ganze Menge gemacht - es benutzen anscheinend nur sehr wenige, damit meine ich jetzt in erster Linie nicht User, sondern Programme.

#34: Autor: DonMartin,

Verfasst am: 06.02.2017, 02:59
—

fwo hat folgendes geschrieben:

Auch Umgebungsvariable unterliegen einer BS-spezifischen Syntax und müssen letztlich auf BS-übliche Pfadnamen heruntergebrochen werden.
Diese Unterschiede (zwischen Windoof und Unixoiden) waren luc schon zuviel, er hält das bloss für einen Marketing-Gag.
Was ziemlich ignorant ist, denn es hat technische und historische Ursachen, die vmtl älter sind als er.
Übrigens:
wenn Windowsvariablen tatsächlich nur beim booten festgelegt werden können, dann sind sie ziemlich unbrauchbar und es wäre verständlich, dass keiner sie nutzt.

#35: Autor: Kramer,

Verfasst am: 06.02.2017, 03:04
—

fwo hat folgendes geschrieben:

Aber Wikipedia sagt mir, dass Windows Umgebungsariablen und innerhalb dieser Pfadvariabeln kennt. Das heißt, dass in Command ein Prozessor für soetwas eingebaut ist. Und da Pfaddefinitionen in der Laufzeit festgelegt werden (bei Windows m.W. so wie es jetzt ist, nur durch einen Batch beim beim Booten, dann heißt das da Programm die prinzipiell auch nutzen können - ob Deine tun, das weiß ich nicht.

Nein, das Programm, das ich meine, tut das nicht. Es greift selber überhaupt nicht ins Betriebssystem ein und nutzt auch keine Variablen im Betriebssystem. Das ist aber so gewollt, denn das Programm kannst Du auf einem USB-Stick installieren und dann auf jedem Rechner benutzen.

Allerdings funktioniert das nur, wenn man das Programm portabel halten will. Bei einer Perfomance-optimierten Nutzung ist das nicht mehr möglich. Das ist aber kein Programmfehler, sondern ein Problem, das das Betriebssystem verursacht.

Das Programm, von dem ich rede, heisst Reaper, das ist eine DAW - eine Digital Audio Workstation. Mit dem Programm kannst Du Musik produzieren. Das Programm erlaubt es Dir, das Programm und alle Deine Projekte auf einem USB-Stick oder einer externen Festplatte zu speichern, oder eben die Möglichkeiten des Betriebssystems zu nutzen, um die Performance zu optimieren. Wenn Du letzteres nutzt, um z.B. die Audiodateien und die Daten für Samples auf verschiedenen Festplatten zu speichern (in meinem Fall zwei SSD-Festplatten) um möglichst viele Spuren ohne Aussetzer nutzen zu können, zerschiesst Dir jede neue Festplatte und jeder Rechnerumzug Deine Projekte.

Ich fände das Unix/Linux-Dateisystem da viel einfacher. Ich erstelle ein Verzeichnis /home/kramer/musik und nach einem Festplattenumbau oder einem Rechner-Umzug liegen die Dateien alle in den Unterordnern von /home/kramer/musik. Die können dennoch auf verschiedene Festplatten verteilt sein, denn welche Festplatte unter welchem Verzeichnis gemountet ist, kann ich ja selber bestimmen.

Ich nutze trotzdem Windows, Musik unter Linux zu produzieren ist mir immer noch zu experimentell. Aber die Art, mit Laufwerken und Dateien umzugehen, ist unter Linux viel besser gelöst.

#36: Autor: fwo, Wohnort: im Speckgürtel

Verfasst am: 06.02.2017, 07:52
—

Kramer hat folgendes geschrieben:

fwo hat folgendes geschrieben:

Wenn ich jetzt nicht gerade ganz dumm bin, tut Dein Programm es doch, nur nicht genügend - dass es auf einem USB-Stick installierbar ist, spricht dafür. Das Nutzen von Umgebungsvariablen, daszu gehört auch das Selbstdefinieren, ist übrigens kein Eingriff ins System, sondern es ist gerade eine Systemeigenschaft, die es Software ermöglicht, mit Geräten flexibler umzugehen.

Dass Windows da auch noch Leichen im Keller hat, streite ich auch nicht ab. Alles worauf ich hinaus will, ist dass das nichts derart Basales am Windowskonzept ist, das man nicht von einer version auf die nächste abstellen könnte. Das was dagegen spricht sind eher kaufmännische als Systemdesign-Gründe. Deren Geschichte fing dann halt damit an, dass MS beim System genauso wie bei den Anwendungen grundsätzlich versucht hat, neue Features nur deshalb herzustellen, um sie ausschließlich selbst bedienen zu können, d.h. Änderungen in Dateiformaten und Schnittstellen werden nicht nach außen kommuniziert um diesen Informationsvorsprung kaufmännisch nutzen zu können. Das hatte jetzt zur Folge, dass externe Windows-Software ganz viel enthält, was bei vernünftiger Planung eigentlich vom System geliefert werden müsste. (Ich brauche mir nur die Unterschiede in der Qualität der Anzeige unterschiedlicher PDF-Programme auf dem Bildschirm anzusehen, um das Kotzen zu bekommen - dass Windows bis heute noch nicht Entsprechendes zum Display-Postscript hat, ist einfach nur traurig.)

Das sind inzwischen halt so viele Programmierer / Firmen, die da ganz viel Eigenes anschleppen und nicht gewillt sind, diesen Vorteil aufzugeben, dass das inzwischen das zweite Problem von MS ist. Das erste ist immer noch, dass sie den Hals nicht vollkriegen können.

#37: Autor: Kramer,

Verfasst am: 07.02.2017, 01:47
—

fwo hat folgendes geschrieben:

Dass Windows da auch noch Leichen im Keller hat, streite ich auch nicht ab. Alles worauf ich hinaus will, ist dass das nichts derart Basales am Windowskonzept ist, das man nicht von einer version auf die nächste abstellen könnte.

Ich sehe gerade, dass es tatsächlich eine Möglichkeit unter Windows gibt, das Problem zu lösen:

https://de.wikipedia.org/wiki/Symbolische_Verkn%C3%BCpfung

Freigeisterhaus -> DAU's Paradise

output generated using printer-friendly topic mod. Alle Zeiten sind GMT + 1 Stunde

Gehe zu Seite Zurück 1, 2 :| |: Seite 2 von 2