AVR Tx Rx direkt koppeln

Es gab mit UNIX und VMS durchaus schon fertig entwickelte und vor allem gut durchdachte Systeme auf die man hätte aufbauen können. Nur war das aus unternehmenspolitischen Gründen bei Microsoft nicht erwünscht. Die Eigenschaften von Windows egal welcher Generation sind bis ins Detail so, dass von zwei möglichen Lösungen immer die jeweils andere gewählt wird. Das reicht vom leidigen "\" statt "/" in Pfadnamen bis hin zur Rechtevergabe und Links, die keine sind.

Wenn nicht durch den kommerziellen Erfolg von DOS und den ersten Windows- Versionen so viel Geld im Unternehmen gewesen wäre, hätte man sich die vielen Rad-Neuerfindungen nicht leisten können.

------

Reply to
Kai-Martin Knaak
Loading thread data ...

Windows NT ist ja auch nur ein neu aufgelegtes VMS: einfach mal alle Buchstaben eins weiterzählen: WNT :-)

Es gibt aber auch einige Dinge, die Microsoft richtig gemacht hat, z.B. die Zwischenablage. Unter KDE oder Gnome muß man immer rätseln, welche Tastenkombination man drücken muß, oder man wundert sich, warum per Maus markiertes nur per mittleren Mausbutton einfügbar ist, aber per Ctrl-C wiederum nicht. Oder warum man den Drucker, Kamera, Scanner usw. nicht einfach einstecken kann und das läuft dann, wie unter Windows zumeist.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

"Kai-Martin Knaak" schrieb im Newsbeitrag news:gvmc5r$hi6$ snipped-for-privacy@gwaiyur.mb-net.net...

DOS aka MS-DOS entstand aus QDOS welches CP/M aehnlich war und ein CP/M fuer 8088 werden sollte, und jenes CP/M baute 1974 auf TOPS-10 von DEC auf, und damit waeren wir bei UNIX und VMS, ebenfalls Betriebssysteme die auf DEC Computern liefen.

CP/M haette 1974 also auch auf Unix basieren koennen, schliesslich gab es das da schon, es war aber viel zu aufwaendig fuer 8 bit Systeme. TOPS-10 war die naeher liegende Basis von der PDP-8/PDP-10.

Microsoft erweiterte dann QDOS in MS-DOS 1.1 auf dem 8088 IBM-PC mit Unix-aehnlichen Dateifunktionen, die sie von Xenix uebernehmen konnten. Dieses galt auch damals noch als zu schwerfaellig fuer die kleinen Computer.

Mit Win32 wurde dann vieles von DEC VMS uebernommen, schliesslich holte Microsoft den VMS Enwickler Dave Cutler als Chefentwickler.

Dessen Enscheidungen sind bis heute die Plage, ich halte die Entscheidungen von Dave Cutler so wie sie gemacht wurden allesamt fuer Fehlentscheidungen, das beginnt bei der Inkompatibilitaet 16/32 bit, der I/O-Blockade, der Prozessverwaltung, und ist ganz einfach an einem PC auszuprobieren: Kopiere einen riesigen Dateibaum per drag & drop, und kopiere direkt danach einen weiteren riesigen Dateibaum. Macht man das gleichzeitig, ist es in der Summe langsamer, als wenn man es sequentiell macht. Das ist so ziemlich das Gegenteil dessen, wie sich ein Betriebssystem verhalten sollte.

Die Links sind uebel, man erinnere sich noch an OS/2 ? Kommt halt davon, wenn man kein inode-Dateisystem hat. Dann kann man auch nicht kaschieren.

Nein, der \ statt / hat andere Gruende, CP/M verwendete bereits den / als Optionszeichen. Allerdings konnte man unter dem "armem" MS-DOS das noch umstellen, mit SWITCHAR wurde - das Optionszeichen und / der Pfadtrenner.

Hat man im "reichen" Microsoft unter Win32 alles wegrationalisiert.

--
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.
Reply to
MaWin

Am Thu, 28 May 2009 15:55:39 +0000 (UTC) schrieb Kai-Martin Knaak:

Wozu hätten sie das ändern sollen? Nachdem NT eine Weiterentwicklung von Windows werden sollte und wurde, und auch 16Bit Windows den "\" verwendete, ist es nur logisch das so zu behalten. In 16Bit Windows wiwderum war der "\" sowieso vorgegeben, weil es auf DOS aufsetzte und DOS nunmal den "\" verwendet.

Die Rechtevergabe wiederum orientierte sich am LAN-Manager den Microsoft zuvor - basierend auf OS/2 1.3 - am Markt hatte und der wunderbarst funktionierte.

Es waren eben keine Neuerfindungen sondern Lösungen die man schon vorher eingesetzt hatte.

Grüße, Thorsten

Reply to
Thorsten Oesterlein

Am Wed, 27 May 2009 18:29:36 +0200 schrieb Frank Buss:

Hallo!

Ähm, der NT-Kernel ist völlig unabhängig von Windows 95 und Nachfolgern entwickelt worden. Und zwar noch vor Windows 95. Windows NT 3.1 kam 1993 auf den Markt und wurde entwickelt, nachdem sich MS und IBM bei der Entwicklung eines Betriebssystems - nämlich OS/2 - zerstritten haben.

Und sie hätten vermutlich auch gewusst wie man das macht. Immerhin hatten sie mit OS2 1.3 auch schon ein leistungsfähiges Betriebssystem am Markt. Allerdings ohne grafische Oberfläche.

Grüße, Thorsten

Reply to
Thorsten Oesterlein

UNIX ist (zumindest aus heutiger Sicht) auch alles andere als perfekt. Für damalige Anforderungen war es aber tatsächlich sehr gut durchdacht.

Das stimmt doch garnicht. Der WindowsNT-Kernel ist, genau betrachtet, überaus unixoid. Und bis Windows2000 hatte er dementsprechend auch viele Beschränkungen der geklauten UNIX-Konzepte. Einige wichtige, z.B. das damals schon eindeutig an seine Grenzen stößende primitive User-Group-World-Rechtesystem, welches UNIX in seiner Evolution bis heute massiv behindert, wurden allerdings gleich von Anfang an durch was intelligenteres ersetzt. ACLs. Zusätzlich brauchte sich Microsoft in der Folge nicht groß um Kompatibilität zu scheren und war deshalb in der Lage, das Konzept recht schnell entsprechend moderner Anforderungen weiter zu entwickeln. Von NT4 auf W2K war ein echter Quantensprung. Plug&Play. Die "echten" UNIXes haben sich da mit der heiligen Kompatibilität selber die Evolution schwer gemacht. Natürlich gibt es da inzwischen auch Plug&Play, es gibt ACLs und es gibt directory services, aber das paßt alles nicht richtig zusammen wie aus einem Guß, es bedarf immer wieder viel fehlerträchtiger Frickelei, den ganzen Kram zu etwas Lauffähigem und Bedienbarem zusammenzusetzen. Man braucht sich z.B. nur den Wahnwitz Samba mit LDAP-Backend anschauen. Das ist doch krank, in der Komplexität nur mit Mühe noch sicher beherrschbar.

Das ist ja wohl eine Sache, die völlig Wurscht ist. Jedes Zeichen ist prinzipiell gleichberechtigt, es spielt als aus theoretischer Sicht keinerlei Rolle, ob ich nun \ oder / oder . oder sonstwas als Hierachietrenner benutze. Nur Vollidioten ohne jede systemtheoretischen Kenntnisse benutzen solche Nebensächlichkeiten ernsthaft als Argument. Mit derselben Idiotie könnte man gegen unterschiedliche Trennzeichen in den Zeit- und Datumsformaten von Locales wettern.

Hier ist Windows eindeutig im Vorteil. ACLs sind mächtig. Genau deswegen werden sie auch auf die unterschiedlichsten Arten immer wieder an Unix-Systeme und Anwendungen drangestrickt...

NT beherrscht Hardlinks genauso wie symbolische Links. Und zusätzlich noch die Dinger auf Applikationsebene, die eigentlich normale Dateien sind. Das sind auch Links. Nur eben auf Anwendungsebene. Sie leisten prinzipiell dasselbe wie symbolische Links, bieten aber zusätzliche Features. Bei unter Unixioden üblichen GUI-Frontends finden sich übrigens praktisch überall ähnliche Konzepte wie diese .lnk-Dateien von Windows...

Reply to
Heiko Nocon

Am Thu, 28 May 2009 18:45:40 +0200 schrieb MaWin:

Hi!

Is halt eine Gradwanderung und ich wüsste auch nicht wie ich das entwickeln würde. Man könnte das schneller machen indem man die Dateizugriffe anders steuert und immer eine Datei fertig schreibt bevor die nächste geschrieben wird. Dadurch erspart man sich das neupositionieren des Kopfes. Dafür wartet die Applikation dann ewig bis sie mal darf. Ist auch nicht der Weisheit letzter Schluß.

Grüße, Thorsten

Reply to
Thorsten Oesterlein

Gegenteil

Das Zauberwort heißt "I/O-Scheduler". OK, verschiedene Workload erfordert auch mal verschiedene Scheduler-Strategien. Aber z.B. Linux ist da nicht so. Nicht nur bringt es verschiedene I/O-Scheduler von Haus aus mit (CFQ, DEADLINE, NOOP) - man kann die sogar pro Blockdevice zur Laufzeit ändern. Ganz ohne Registry-Gewurschtel :)

Aber gut. Was Filesysteme und das I/O-Subsystem angeht, war mir Windoze schon immer sehr suspekt.

XL

Reply to
Axel Schwenke

Was genau vermißt du? Und inwiefern ist das intrinsisch für UNIX?

Welches UNIX hat keine ACLs? Seit etlichen Jahren?

Ein schöner Euphemismus für "was scheren uns Standards"

Du möchtest eventuell das Wort "Quantensprung" nachschlagen. Hint: ein Quant ist nicht groß. Eher klein.

I beg to differ. Wenn man bei UNIX die gleiche "alles aus einer Hand" Strategie fährt, die man bei Windoze gezwungenermaßen fahren muß - dann paßt auch alles nahtlos zusammen (Kunststück, wenn es doch aus einer Hand kommt).

Samba ist in erster Linie deswegen krank, weil es einen so kranken Protokoll-Mischmasch implementieren muß. Wenn Microsoft sich z.B. mit LDAP zufrieden gegeben hätte und nicht mit Active Directory eine subtil abweichende Implementierung gemacht hätte, wäre das Leben der Samba- Leute um einiges einfacher. Offensichtlich wollte Microsoft genau das verhindern.

Dann laß mich ein weiteres Argument in den Ring werfen: Case Sensitivity von Filenamen. Obwohl zumindest NTFS es mittlerweile richtig könnte, ist der Default immer noch "kaputt".

Ähm. Nein.

Ja. Aber du wirst die Phantasielosigkeit der KDE-Leute wohl kaum UNIX anlasten wollen. Und abgesehen davon: egal ob man KDE benutzt oder nicht: auf einem UNIX hat man *immer* auch Hard- und Softlinks.

XL

Reply to
Axel Schwenke

Zumindest das NTFS-Dateisystem bietet es an und wenn man einmal einen Hardlink oder symbolischen Link hat, dann erscheint der auch problemlos im Datei Explorer. Blöderweise bietet das Betriebssystem von Haus aus keine Möglichkeit, sowas anzulegen, dazu muß man erst weitere Software installieren:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Am Fri, 29 May 2009 01:52:23 +0200 schrieb Axel Schwenke:

Hallo!

Das Zauberwort heißt "junction". Leider bringt NT aber von Haus kein Tool mit um diese Hardlinks zu erstellen. Man muß externe Software bemühen. Funktioniert aber einwandfrei.

Liebe Grüße, Thorsten

Reply to
Thorsten Oesterlein

Am Fri, 29 May 2009 01:35:17 +0200 schrieb Axel Schwenke:

Hallo!

Nutzt aber nix. Einander konkurenzierende Dateizugriffe bremsen nunmal aus. Du kannst das durch Intelligenz etwas optimieren, aber ganz verhindern kannst du es nicht.

Grüße, Thorsten

Reply to
Thorsten Oesterlein

Darum geht es bei der Metapher nicht. Ein Quantensprung ist eine diskontinuierliche, nicht stetige, "revolutionäre" statt graduell evolutionäre Änderung.

/ralph

--
http://www.flickr.com/photos/sooperkuh/
Reply to
Ralph Aichinger

Kopieren per Auswahl/Paste per mittlerer Maustaste war zuerst da, das macht X selbst, deshalb funktioniert es auch unter allen WMs. Irgendwann kamen dann KDE und Gnome und brachten als Zugeständnis an Windows-Umsteiger ein eigenes, erweitertes Clipboard mit den "bekannten" Tastenkombinationen mit. Dieses wird nur "lose" mit dem X-Mechanismus synchronisiert.

Wenn man das weiß, ist das Verhalten gar nicht mehr so rätselhaft. Ich käme beispielsweise auch nie auf die Idee, zu erwarten, dass ich Text, den ich im vim mit 'd' oder im nano mit Strg-K ausgeschnitten habe, mit Strg-V in kate wieder einfügen könnte. Das sind halt eigene, anwendungsspezifische Zwischenablagen.

Windows ist da ziemlich monotheistisch, "Du sollst keine anderen Zwischenablagen haben neben mir".

Gruß Henning

Reply to
Henning Paul

"Thorsten Oesterlein" schrieb im Newsbeitrag news: snipped-for-privacy@40tude.net...

Im Gegenteil, aus dem Menge an I/O-Anforderungen des einen Jobs und der Menge der I/O-Anforderungen des anderen Jobs kann man eine optimalere Abarbeitung waehlen - oder sollte man zumindest koennen als ordentlich geschriebenens Betriebssystem - als wenn man jeden Job zeitlich nacheinandern alleine betrachtet.

Es ist sachlich falsch, diese als konkurrierende Dateizugriffe zu betrachten. Sie ergaenzen sich.

--
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.
Reply to
MaWin

"Axel Schwenke" schrieb im Newsbeitrag news: snipped-for-privacy@xl.homelinux.org...

Wenn man sich ideologisch absolut verrannt hat, weiss man, welche Implementation kaputt ist.

Es ist nur peinlich, deine Ideologielastigkeit zu sehen.

--
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.
Reply to
MaWin

MaWin schrieb:

Absolut richtig ;-)

Falk, case-sensitive Dateinamen mit 255 Zeichen Länge seit >15 Jahren nutzend.

Reply to
Falk Willberg

Warum sollte man es denn wollen, daß "text" und "Text" unterschiedlich behandelt werden? Welche handfesten, praktischen Gründe gibt es? "Weil es möglich wäre" zählt für mich da nicht.

Mich für meinen Teil nervt es, auf der Kommandozeile dann mühsam Scheiß der Art "vi SuperWichtigesConfigFileDerGanzArgTollenApp" eingeben zu müssen.

-ras

--

Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Reply to
Ralph A. Schmid, dk5ras

De facto könnte man auch den Mittlere-Maustaste-Mechanismus entfernen, und man hätte ziemlich genau das Verhalten von Windows. Ja, auf den meisten Notebooks mit zwei Tasten unter dem Touchpad ist es eh de facto so.

Das einzige Gnome-Programm, bei dem das Ctrl-C,Ctrl-V bei mir nicht funktioniert, ist das Terminal, und auch da nur deswegen, weil Ctrl-C in der Shell traditionell die Unterbrechung ist, und man diese Tastenkombination sinnvollerweise nicht überdecken will.

/ralph

--
http://www.flickr.com/photos/sooperkuh/
Reply to
Ralph Aichinger

Da drückt man beide gleichzeitig. Auch da bevorzuge ich den Markieren/Mittlere Maustaste-Mechanismus.

Und was, wenn Du mal ein nicht-Gnome/nicht-KDE-Programm laufen hast?

Gruß Henning

Reply to
Henning Paul

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.