Hi An einen PC mit Win 10 pro melde ich mich ohne Paßwort an. Auf diesen PC möchte ich per RDP zugreifen (RDP ist aktiviert). Ich bekomme aber immer eine seltsame Fehlermeldung. Ich vermute den Grund darin, daß der PC kein Paßwort hat. Wenn dem so ist: Wie/wo kann ich dem PC ein Paßwort verpassen? Oder wie/wo kann ich einen neuen User mit Paßwort anlegen?
RDP ohne Passwort ist aus Sicherheitsgründen gesperrt. Kommandozeile als Admin öffnen und folgenden Befehl eingeben:
1 | net user Benutzername Passwort /add |
Peter N. schrieb: > Wie/wo kann ich dem PC ein Paßwort verpassen? Normalerweise setzt/ändert man sein PW, in dem man Strg/Alt/Entf drückt und dort "Kennwort ändern" auswählt.... Peter N. schrieb: > Oder wie/wo kann ich einen neuen User mit Paßwort anlegen? In dem du in die Benutzerverwaltung gehst. Startmenü aufklappen, "Weitere Benutzer" buchstabenweise eintippen bis die "Andere Benutzer anlegen..." auftaucht.
Peter N. schrieb: > Ich bekomme aber immer eine seltsame Fehlermeldung. Einfach unter Behinderteneinstell... äh... Barrierefreiheit den Text größer einstellen, dann kannst du die Meldung lesen und hier posten.
Mario M. schrieb: > Kommandozeile als > Admin öffnen und folgenden Befehl eingeben: net user Benutzername > Passwort /add Habe ich durchgeführt, es gab auch eine Rückmeldung mit irgendwas erfolgreich. Jetzt bootet der PC zum Sperrbildschirm, fragt nach einem PW, aber ich komme einfach durch Drücken von Return oder Klicken auf den Sperrbildschirm auf den Desktop... Bei RDP klappt die Anmeldung natürlich nicht. Falls es irgendwie damit zu tun haben sollte: Der User ist der, den das (vorinstallierte) Windows hatte. Diesen habe ich über die Systemsteuerung umbenannt.
Peter N. schrieb: > Bei RDP klappt die Anmeldung natürlich nicht. Der neue Benutzer muss durch Aufnahme in die Gruppe Remotedesktopbenutzer für RDP freigeschaltet werden.
1 | net localgroup "Remotedesktopbenutzer" "Benutzername" /add |
Verstehe ich irgendwie nicht. Für einen anderen PC habe ich bei RDB einfach Computername, User und PW eingegeben und es lief...
Wenn der Standard-Benutzer ein Passwort hat, läuft es nach Aktivierung des Remote-Desktops einfach so.
Peter N. schrieb: > Verstehe ich irgendwie nicht. > Für einen anderen PC habe ich bei RDB einfach Computername, User und PW > eingegeben und es lief... Google verrät an 999 Stellen: Wenn ein Passwort auf dem Remote-Computer geändert bzw. neu eingerichtet worden ist, muss es dort lokal mindestens einmal genutzt werden, damit es dort in den Cache gelangt. Erst dann kann man es aus der Ferne nutzen. (Eine durchaus sinnvolle Schutzmaßnahme.)
Rolf schrieb: > Wenn ein Passwort auf dem Remote-Computer geändert bzw. neu eingerichtet > worden ist, muss es dort lokal mindestens einmal genutzt werden, damit > es dort in den Cache gelangt. Und wie wird das PW "genutzt"? Wie ich schon schrieb, komme ich durch einen Klick oder Returndruck auf den Sperrbildschirm direkt auf die Win-Oberfläche!
Auf der Windows-Oberfläche ins Startmenü gehen, dort "Bentzer wechseln"(*). Den neuen Benutzer auswählen und dich einmal anmelden. Dabei wird eine Warnung aufpoppen (anderer Benutzer aktiv, ...). Akzeptieren und Anmeldung fortsetzen. Dann bist du neben dem Hauptbenutzer auch unter dem "neuen" Benutzer angemeldet. Wenn die Anmeldung dur h ist, kannst du dich gleich wieder anmelden. Dann kommt der Anmeldenbildschirm wieder, aber diesmal mit einer Auswahl von zwei Benutzern: dem Standard Benutzer und dem Neuen. Hier einfach den Standardbenutzer auswählen und Return drücken. Und alles ist wie gewohnt. Jetzt geht auch die Remote-Anmeldung. PS: Ich sitze gerade nicht vor dem PC. Daher kann ich die exakten Begriffe nicht prüfen. Aber sinngemäß stimmt das schon so, wie oben beschrieben.
:
Bearbeitet durch User
Beitrag #8011533 wurde vom Autor gelöscht.
Tja, die Nachteile und Quirks von RDP, einer der größten: Der RDP-Benutzer ist immer jemand anders, will sagen: da meldet sich jemand mit seinem eigenen Bildschirm und eigener Tastatur an, den ich als Benutzer an der Maschine selbst weder sehen noch beeinflussen kann. Mit VNC oder Teamviewer dagegen ist man der der davorsitzt, nur eben woanders. Wesentlich einfacher und übersichtlicher. War RDP tatsächlich gezielt gewollt, oder ging es nur um "das ist eingebaut, das kostet nix"?
Nix mit vorher lokal anmelden und Cache. Lokales Konto anlegen und Benutzer in die Remotedesktopbenutzer-Gruppe aufnehmen. Dann kann man sich sofort remote anmelden. Einziges Problem: Windows Professional lässt nur einen Benutzer gleichzeitig zu. Ein noch lokal angemeldeter Benutzer wird nach 30 Sekunden abgemeldet.
Mario M. schrieb: > Windows Professional > lässt nur einen Benutzer gleichzeitig zu. Ein noch lokal angemeldeter > Benutzer wird nach 30 Sekunden abgemeldet. Ja, via RDP kann nur "einer gleichzeitig" rein. Der lokale bleibt aber m.W. aktiv? Oder wurde das irgendwann in Win11 geändert? Ich habs früher™ mal irgendwann getestet, da ging es stundenlang parallel. Nur das beide User nichts voneinander wissen.
Peter N. schrieb: > Und wie wird das PW "genutzt"? > > Wie ich schon schrieb, komme ich durch einen Klick oder Returndruck auf > den Sperrbildschirm direkt auf die Win-Oberfläche! Nutzen tut man ein PW, indem man sich damit anmeldet. Wenn du ohne PW oder andere Legitimation auf den Desktop gelangst, hast du dich nicht als ein Nutzer angemeldet, an den du ein Passwort vergeben hast. Vielleicht hast du auch die Rechner verwechselt. Jeder Rechner hat eine eigene Nutzerdatenbank mit eigenen Passwörtern. Auf dem fernzusteuernden PC muss ein Nutzer mit Passwort angelegt sein, und auf dem fernsteuernden Rechner musst du diese beiden eingeben (nicht anlegen).
Peter N. schrieb: > Ich bekomme aber immer eine seltsame Fehlermeldung. Und nach mehr als neuneinhalb Jahren und über 3200 Beiträgen hier im Forum kommst Du nicht auf die Idee, diese Fehlermeldung zu zitieren? Wow.
Jens M. schrieb: > Ja, via RDP kann nur "einer gleichzeitig" rein. Der lokale bleibt aber > m.W. aktiv? > Oder wurde das irgendwann in Win11 geändert? Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr. Wenn man sich per RDP einloggt, wird der lokale User ausgeloggt, bzw. wenn es derselbe User ist, wird die vorhandene Session durch den RDP-Client übernommen.
Hmmm schrieb: > Wenn man sich per RDP einloggt, wird der lokale User ausgeloggt, bzw. > wenn es derselbe User ist, wird die vorhandene Session durch den > RDP-Client übernommen. Richtig, das ist schon seit XP Zeiten so.
Jens M. schrieb: > War RDP tatsächlich gezielt gewollt Wer schon IT kannte, als die noch EDV hieß, für den ist das, was RDP macht, eine völlig normale Sache. Die Client-Server-Struktur des Großrechner-Bereichs: ein zentraler Rechner hoher Leistung (der "Server"), an den etliche Terminals (die "Clients") mit wenig oder ganz ohne eigene Intelligenz angeschlossen sind. Die Nutzer an diesen dummen Terminals nutzen jeder für sich Anwendungsprogramme, die komplett auf dem Server laufen. Der Server hat in der Regel gar keinen Bildschirm und keine Tastatur; für Wartungsarbeiten loggt sich der Admin an einem der Terminals ein. Nach genau demselben Prinzip funktioniert RDP: Man sitzt an einem Terminal und nutzt Anwendungsprogramme, die auf einem entfernten PC laufen. Nur aus praktischen/finanziellen Gründen ist das Terminal ein normaler PC (mit dem man auch anderes tun kann) und kein Terminal ohne Intelligenz, das man ja für nichts anderes gebrauchen könnte. Man sieht auf dem Monitor ein Bild, das so aussieht, als wäre es das Desktop-Bild des Windows auf dem Server-PC. Das ist es aber gar nicht, weil das gar nicht existiert (der Server hat keinen Monitor oder zeigt dort keinen Desktop an), das wird nur simuliert. Deswegen gibt es da eigentlich gar keinen zweiten Nutzer, der am Server sitzt und mit dem der erste Nutzer kommunizieren könnte. Was VNC, Teamviewer u. Ä. machen, ist etwas völlig anderes: Da geht es darum, dass zwei Nutzer miteinander kommunizieren, und nicht darum, die Leistung eines entfernten Servers zu nutzen. Eine völlig andere Aufgabenstellung/Zielsetzung.
Rolf schrieb: > Wer schon IT kannte, als die noch EDV hieß, für den ist das, was RDP > macht, eine völlig normale Sache. Richtig, aber häufig im privaten Bereich eigentlich nicht das was man will. Chromebooks oder Thinclients sind da ja nicht so verbreitet. Rolf schrieb: > Was VNC, Teamviewer u. Ä. machen, ist etwas völlig anderes: Eben genau das war meine Frage: will man tatsächlich einen normalen PC als Server nutzen und einen zweiten Arbeitsplatz da per RDP realisieren, oder will man "ich kann da gerade nicht sitzen, will aber das machen was ich sonst da mache". Im privaten/nicht-kommerziellen Umfeld ist das zu 90% letzteres.
Jens M. schrieb: > Tja, die Nachteile und Quirks von RDP, einer der größten: Der > RDP-Benutzer ist immer jemand anders Nö, nö. Es ist schon derselbe Benutzer. Nur eben eine andere Session. > Mit VNC oder Teamviewer dagegen ist man der der davorsitzt, nur eben > woanders. Auch das kann RDP. Nennt sich dann nicht "remote desktop" sondern "remote help". Und das können (im Unterschied zu remote desktop) auch die kastrierten Home-Versionen von Windows. Allerdings hat MS die Prozedur zur Kontaktaufnahme so kompliziert gestaltet, dass die Sache dadurch nahezu unbenutzbar ist. Deswegen wurde und wird dies auch so gut wie nie in der Praxis benutzt. > War RDP tatsächlich gezielt gewollt Ja, nomen est omen. Es ging darum, einem den eigenen(!) Desktop auch aus der Ferne bereit zu stellen. Und wenn man in der Ferne ist, kann man unmöglich auch gleichzeitig lokal sein. Also wird eine eventuell noch laufende lokale Session suspendiert, wenn die Anmeldung zu einer remote Session erfolgt. Allerdings hat das im Kern natürlich pekuniäre Gründe. Der eigentliche Grund ist, dass die Client-Versionen von Windows grundsätzlich nur eine aktive Session erlauben. Die Server-Versionen hingegen erlauben immerhin zwei. Mehr geht nur mit dem (extrem teuren) Terminal-Server, den MS aus naheliegenden Gründen natürlich sehr gern verkaufen würde.
Jens M. schrieb: > Eben genau das war meine Frage: will man tatsächlich einen normalen PC > als Server nutzen und einen zweiten Arbeitsplatz da per RDP realisieren, > oder will man "ich kann da gerade nicht sitzen, will aber das machen was > ich sonst da mache". Ja und? Das geht hervorragend mit RDP. Meldet man sich mit dem gleichen Benutzerkonto an, wie das, was vorher lokal am Rechner angemeldet war, übernimmt man diese Sitzung. Und wenn der Rechner, von dem man sich via RDP anmeldet, einen höher auflösenden Monitor hat, dann kann man diese Auflösung auch nutzen -- selbst wenn am fernzusteuernden Monitor nur 'ne olle VGA-Gurke mit 640x480 hängt. Das geht auch mit mehreren Monitoren. Und wenn man dann wieder direkt vor dem Rechner sitzt, kann man die RDP-Sitzung übernehmen - einfach lokal anmelden, fertig. In dieser Beziehung ist RDP ganz erheblich besser als VNC, Teamviewer und Co., denn die können nur mit der lokal vorgegebenen Monitorauflösung arbeiten. Im übrigen kann RDP auch verwendet werden, um einem lokal angemeldeten Benutzer "über die Schulter" zu schauen (was für eine Supportfall relevant ist), das geht mit der Kommandozeilenoption "shadow". Will man auch steuernd eingreifen, brauchts /control.
Harald K. schrieb: > Ja und? Das geht hervorragend mit RDP. Meldet man sich mit dem gleichen > Benutzerkonto an, wie das, was vorher lokal am Rechner angemeldet war, > übernimmt man diese Sitzung. Stimmt, das hatte ich in meinem Posting falsch dargestellt. Die eigene Session kann man übernehmen (das ist sogar das Standardverhalten). Was ich schrieb, betrifft also nur die Sessions anderer Benutzer. Die werden suspendiert.
Hmmm schrieb: > Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr. In der ersten Version von XP, also die ohne Servicepack, war es tatsächlich noch möglich. Hat mich damals sehr gewundert, denn diese Funktionalität verkaufte MS teuer mit dem Terminalserver (jetzt Remote Desktop Host). Wie auch immer, der "Fehler" wurde in Redmond schnelle bemerkt und mit dem Servicepack 1 behoben. @Topic Der Zugriff über das Netzwerk ohne Kennwort ist per Default gesperrt. Kann man über Gruppenrichtlinien ändern: gpedit.msc ausführen (lokale Gruppenrichtlinien) Richtlinien für lokaler Computer Windows-Einstellungen Lokale Richtlinien Sicherheitsoptionen "Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken" -> auf Deaktiviert setzen Dann klappt auch die RDP-Anmeldung ohne Kennwort.
Ein T. schrieb: > kommst Du nicht auf die Idee, diese Fehlermeldung zu zitieren? Meinst du, wenn ich das abends zuhaus probiere, kann ich mich dann morgens auf Arbeit noch an den Wortlaut der Meldung erinnern? Was ist denn das Spezielle am ersten/einzigen Win-User? Ich habe den Computernamen irgendwo in den Systemeinstellungen (Taskleiste links Rechtsklick) geändert. Irgendwo dort habe ich auch den Usernamen geändert (finde die Stelle aber gerade nicht mehr...). Der Username wurde aber nicht vollständig geändert, irgendwo spukte immer noch der ursprünglicher Username rum. Unter "Computerverwaltung/lokale Benutzer/Benutzer/" stand bei "Vollständiger Name" der neue Name, bei "Name" noch der ursprüngliche. Als ich bei "Name" den neuen Usernamen eingetragen hatte, war Ruhe. PW setzen hat auch erst damit funktioniert: Jens M. schrieb: > Normalerweise setzt/ändert man sein PW, in dem man Strg/Alt/Entf drückt > und dort "Kennwort ändern" auswählt.... Jetzt funktioniert RDP endlich.
Peter N. schrieb: > Was ist denn das Spezielle am ersten/einzigen Win-User? Nichts. Da gibts nichts spezielles. Alle User sind gleich, nur manche User sind gleicher.
Der "Erste" User ist automatisch ein Admin, mehr nicht. Bei so einer Umbenennungsaktion wird im Normalfall der Profilordner nicht umbenannt. D.h. "Berta" wird als Berta angezeigt, das Profil liegt aber (in der Regel) unter "C:\Users\Adam". Das kann verwirrend sein, auch für diverse Software, denn diese Namensungleichheit gilt auch in der Registry und an anderen Stellen. Besser isses da, einen neuen Benutzer anzulegen und den alten nach dem Übertragen der Daten zu löschen.
Icke ®. schrieb: > Hmmm schrieb: >> Ich glaube, 1x lokal + 1x RDP geht schon seit Windows XP nicht mehr. > > In der ersten Version von XP, also die ohne Servicepack, war es > tatsächlich noch möglich. Hat mich damals sehr gewundert, denn diese > Funktionalität verkaufte MS teuer mit dem Terminalserver (jetzt Remote > Desktop Host). Wie auch immer, der "Fehler" wurde in Redmond schnelle > bemerkt und mit dem Servicepack 1 behoben. > Bei Windows-Server 2003 konnte man den Terminal-Server einfach installieren, den zugehörigen Lizenz-Server für User-Lizenzen (nicht für Devices) konfigurieren und nicht aktivieren, schon hat der Lizenz-Server immer beliebig viele temporäre User-Lizenzen für den Terminal-Server bei jeder User-Anmeldung neu vergeben, ohne dass man überhaupt für eine User-Lizenz bezahlt und installiert hat. Hab keine Ahnung, ob und wann Microsoft den Bug behoben hat.
Icke schrieb: > Der Zugriff über das Netzwerk ohne Kennwort ist per Default gesperrt. > Kann man über Gruppenrichtlinien ändern: > > gpedit.msc ausführen (lokale Gruppenrichtlinien) Halte ich für eine idiotische Idee, Scheunentor offen und direkt daneben stehen ein paar Kerzen und Streichhölzer. Peter N. schrieb: >> kommst Du nicht auf die Idee, diese Fehlermeldung zu zitieren? > Meinst du, wenn ich das abends zuhaus probiere, kann ich mich dann > morgens auf Arbeit noch an den Wortlaut der Meldung erinnern? Was kannst Du überhaupt, quer durchs Forum erscheinst Du mir als Chaot. "wenn ich das abends zuhaus probiere", könnte ich Screenshots direkt ins Forum posten, Du nicht? Sandra schrieb: > Bei Windows-Server 2003 konnte man den Terminal-Server einfach > installieren, den zugehörigen Lizenz-Server für User-Lizenzen (nicht für > Devices) konfigurieren und nicht aktivieren, schon hat der Lizenz-Server > immer beliebig viele temporäre User-Lizenzen für den Terminal-Server bei > jeder User-Anmeldung neu vergeben, Die Lizenz tut hier absolut nichts zur Sache. Im Gegensatz zum 'normalen' Windows kann man auf dem Server mehrere Remoteverbindungen parallel aufmachen. Wenn man die nicht beendet, belegen die Speicher und sind auch nach Neustart weiterhin aktiv.
Manfred P. schrieb: > Halte ich für eine idiotische Idee, Scheunentor offen und direkt daneben > stehen ein paar Kerzen und Streichhölzer. Im Heimnetzwerk vertretbar, sonst natürlich nicht. > Im Gegensatz zum > 'normalen' Windows kann man auf dem Server mehrere Remoteverbindungen > parallel aufmachen. Wenn man die nicht beendet, belegen die Speicher Ja. Aber wo genau ist das Problem? Eine getrennte RDP-Sitzung bleibt auch unter Desktop-Windows weiterhin im Speicher. > und sind auch nach Neustart weiterhin aktiv. Nein.
:
Bearbeitet durch User
Manfred P. schrieb: > Wenn man die nicht beendet, belegen die Speicher und > sind auch nach Neustart weiterhin aktiv. Wenn "Neustart" nicht Neustart des Servers, sondern nur Neuanmeldung mit RDP-Client meint ... Im übrigen kann man einstellen, daß inaktive RDP-Sitzungen nach einiger Zeit automatisch abgemeldet werden, um genau das Ressourcenproblem zu lösen.
Harald K. schrieb: > Im übrigen kann man einstellen, daß inaktive RDP-Sitzungen nach einiger > Zeit automatisch abgemeldet werden, um genau das Ressourcenproblem zu > lösen. Ersetze "kann" durch "muß". Anders lassen sich renitente User nicht disziplinieren.
Icke ®. schrieb: > Sandra schrieb: >> Hab keine Ahnung, ob und wann Microsoft den Bug behoben hat. > > Bis dato nicht. Gut zu wissen.😉😀
Peter N. schrieb: > Oder wie/wo kann ich einen neuen User mit Paßwort anlegen? Das konnte man doch bisher immer schon bei der Anmeldung machen. Oder nicht? Ich gehe jetzt mal die KI fragen, warum das mit dem Custom-Gruppen-Erstellen in Baldurs Gate 2 in Windows - aber nicht in Linux funktioniert. Darüberhinaus wäre es ja schon schön, wenn Windows endlich mal Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere Leute an einem Rechner sitzen können. Das wäre sicher auch noch gut für den Muli-Monitor-Betrieb. Linux kann ja Multiseat, - Windows dagegen hat Linux intus kann aber nicht.. - hehe, irgendwie fehlt auf beiden Systemen dies und das, was x hat und y nicht oder umgekehrt was y hat und x nicht -> ein Teufelskreis!
Rbx schrieb: > wenn Windows endlich mal > Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere > Leute an einem Rechner Haben sie doch. Musst nur dafür zahlen. Remote Desktop Services (RDS), dazu einen Licensing Server, und genug CALs. Hat MS zwar m.W. abgekündigt (Die Leute sollen doch endlich in die Cloud), aber kannst du noch kaufen/nutzen. Rbx schrieb: > Ich gehe jetzt mal die KI fragen, warum das mit dem > Custom-Gruppen-Erstellen in Baldurs Gate 2... Mein Tipp (Nach den Erfahrungen mit deinen Skyrim-Problemen): Du hast wieder irgendwelche Sabotage-DLLs in deinen Overrides. Aber lass die KI mal machen.
Εrnst B. schrieb: > Rbx schrieb: >> wenn Windows endlich mal >> Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere >> Leute an einem Rechner > > Haben sie doch. Musst nur dafür zahlen. Und das schon seit Windows 2000. Die Funktionalität ist in den Serverversionen enthalten, bezahlt wird deren Nutzung per Gerät oder User.
Oder auch kostenfrei, wenn Microsoft den Bug des Lizenz-Servers nicht beheben will.
Icke ®. schrieb: > Εrnst B. schrieb: >> Rbx schrieb: >>> wenn Windows endlich mal >>> Großrechner/Terminal-Funktionen einbauen könnte, damit eben mehrere >>> Leute an einem Rechner Wenn M$ und die Softwarefirmen sich an die damals verbindlichen Richtlinien, was Antwortzeiten und UI-Design halten würden... ☺ Am Grossrechner gab es keine Sanduhr. > Und das schon seit Windows 2000. Die Funktionalität ist in den > Serverversionen enthalten, bezahlt wird deren Nutzung per Gerät oder > User. W2000 Workstation fehlt der Terminalserver/RDP-Dienst. Weswegen ich dann den Advanced Server installiert habe. Der mag aber auch nur 2 Verbindungen, was mir bei dem aber auch reicht. Die perfekte Lösung ist das aber auch nicht. Gibt es doch Software, die eine Installation auf dem Server glatt ablehnt.
:
Bearbeitet durch User
Cartman E. schrieb: > Wenn M$ und die Softwarefirmen sich an die damals /verbindlichen/ > Richtlinien, was Antwortzeiten und UI-Design halten würden... ☺ > Am Grossrechner gab es keine Sanduhr. Hmm... Was gab es statt dessen, wenn z.B. die Anfrage an eine umfangreiche Datenbank mehrere Sekunden oder gar Minuten gedauert hat? Gar kein Feedback? Irgendwie nicht sehr benutzerfreundlich... Aber genau das ist ja wohl, was so Unix-typisch ist, oder?
Ob S. schrieb: > Hmm... Was gab es statt dessen, wenn z.B. die Anfrage an eine > umfangreiche Datenbank mehrere Sekunden oder gar Minuten gedauert hat? Wenn eine Antwortzeit von z.B. 3 s, für eine Abfrage nicht eingehalten wurde, war das schlicht ein Fehler, und berechtigte zur Reklamation. Was dann passierte, stand in den Vertragsdokumemten. Das es nun aus sachlichen Gründen, auch mal länger dauern konnte, wird es mindensten eine Reaktion gegeben haben, die eine weitere Abschätznung des verbleibenden Zeitbedarfs enthalten haben dürfte. Das war aber die absolute Ausnahme. > Gar kein Feedback? Irgendwie nicht sehr benutzerfreundlich... Im Gegenteil. Garantierte Antwortzeiten sind ausgesprocehn angenehm. > Aber genau das ist ja wohl, was so Unix-typisch ist, oder? Wenn man UNIX® zum erstenmal unter den Fingern hatte, kam es einem schon wie ein Grossrechner vor. Die Philosophie der Behandlung von Nutzertransaktionen, orientiert sich aber nicht am klassischen Grossrechner. Am Textterminal gab es dann maximal einen Texthinweis oder einen Spinner [\|/-]. UMIX und garantierte Antwortzeiten? Auch eher nicht. Also nein.
Cartman E. schrieb: > Wenn eine Antwortzeit von z.B. 3 s, für eine Abfrage nicht > eingehalten wurde, war das schlicht ein Fehler, und berechtigte > zur Reklamation. Was dann passierte, stand in den Vertragsdokumemten. Wow. Umfangreiche Datenbanken und komplexe Abfragen darauf können sehr leicht mal die 3-Sekunden-Grenze reißen. Beispiel: Die gemeinsame DNA-Datenbank der US-Polizeibehörden. So eine Anfrage konnte schon in den frühen 90ern Tage dauern. Und kann es trotz vielfach schnellerer Hardware auch heute noch. Weil sich halt sowohl die Komplexität der möglichen Abfragen als auch der Datenbestand zwischenzeitlich massiv erhöht haben. Grund zur Reklamation? Nö. Ist einfach so und läßt sich im Rahmen der formalen Logik auch nicht ändern. Auch nicht mit Unix oder irgendeinem anderen OS. Und ja: In den Clients (sind Windows-basiert) gibt es keine Sanduhr. Statt dessen halt ein Hinweis, dass die Frage bearbeitet und die Antwort irgendwann mal eingehen wird. Das ist ja auch SO VIEL besser als eine Sanduhr...
Mit gut (oder schlecht) gewählten Beispielen, kann man Alles oder Nichts beweisen. Entscheidend: "Das war aber die absolute Ausnahme." Ich hatte selbst Ende der 80er Jahre mit Datenbanken und UNIX zu tun, und die Datenbanksoftware war, wenn man das auf die Leistungsfähigkeit damaliger Hardware herunterechnet, ausgesprochen performant. 16 bit CPU, 4 MHz Takt, und ca. 50 kB/s Lesegeschwindigkeit der Platte. Eine Und-verknüpfte Suchanfrage, förderte die Treffer aus einer Tabelle mit ca. 100000 Einträgen in unter einer Sekunde zu Tage. Einschliesslich der Daten aus referenzierten weiteren Tabellen. Unique Keys, und binäre Bäume waren wohl das Hilfsmittel. Ein Adobereader braucht heute für eine Volltextsuche ca. 1 s für eine Seite. Möglicherweise geringfügig schneller. ☺ So ein Dreck wäre vom Benutzer damals nicht akzeptiert worden... Es kann auch kein grundsätzliches Problem sein. Andere Hersteller sind da 2-3 dezimale Grössenordnungen schneller als das Adobezeug.
Cartman E. schrieb: > und ca. 50 kB/s Lesegeschwindigkeit der Platte. Was soll das für eine Platte gewesen sein? Das ist Diskettengeschwindigkeit. MFM-Festplatten haben das zehnfache, RLL-Festplatten das fünfzehnfache geliefert. (Sofern der Festplattencontroller in der Lage war, eine komplette Spur in einem Rutsch zu lesen, sonst brauchte der einen sogenannten "Interleave", was die Lesegeschwindigkeit halbierte oder drittelte, aber nur 50 kB/sec war auch Ende der 80er unterirdisch langsam.
Es war wohl eine Seagate ST251 verbaut. Deren Datenblatt verrät eine Datenrate von "0.625 MB/S". Das "Drumherum" der Platte war aber vermutlich mit Z80 und dessen Peripherie realisiert, und die Daten über Z80-PIOs zur (16 bit-)CPU geschleust. Ich könnte im Schaltplan nachsehen, hege aber kein Interesse. Die 50 kB/s habe ich auch nicht gemessen, sondern stammen aus u.U. unzuverlässigen Informationsquellen. Die Grössenordnung wird aber stimmen. Ein XT-Nachbau, 2 Tische in meinem Arbeitszimmerchen weiter, war unter MS-DOS mit dem selben Plattetyp unterwegs, und bei der Verarbeitung eher noch langsamer. Dafür konnte man mit M$-C 5.1 recht komfortabel debuggen. Beim UNIX-System hatte ich immerhin das Privileg, es "aussuchen" zu dürfen. Allerdings gab es keine praktikablen Alternativen. Der Preis für das System lag damals, bei ca. einer viertel Million. Und die Antwortzeiten waren ja auch nicht schlecht. ☺
Cartman E. schrieb: > Es war wohl eine Seagate ST251 verbaut. Deren Datenblatt verrät > eine Datenrate von "0.625 MB/S". 5 MBit/sec Bruttodatenrate. Wenn auf die übliche Art und Weise mit 512-Byte-Sektoren formatiert, dann gab es davon 17 pro Spur und die Platte drehte sich mit 60 Umdrehungen pro Sekunde. Die Nettodatenrate lag daher bei 17 x 512 x 60 Byte pro Sekunde, also 510 kiB/sec. > Das "Drumherum" der Platte war aber vermutlich mit Z80 und dessen > Peripherie realisiert, und die Daten über Z80-PIOs zur (16 bit-) > CPU geschleust. Gut, mit unpassenden Controllerschaltungen kann man beliebig viel Performance ausbremsen. Ich hatte zur gleichen Zeit mal mit 68k-Systemen zu tun, bei denen ein ungeschickt programmierter SCSI-Controller in Kombination mit einem ebenfalls ungünstigen MFM-SCSI-Adapter (irgendwas von Omti) die Datenrate auch auf erbärmliche Werte ausbremste, der MFM-SCSI-Adapter konnte natürlich nicht ohne "Interleave" arbeiten, und der ungeschickte Treiber des 53c80 regelte irgendwo unter 100 kByte/sec auch schon ab. An einem AT aber, wie er Ende der 80er durchaus üblich war, wären diese Datenraten sehr ungewöhnlich gewesen, daher meine Nachfrage. Der Ur-MFM-Controller des AT (WD1003) konnte auch nur im Interleave betreiben werden, was üblicherweise die Datenrate halbierte oder drittelte. Der auch schon Ende der 80er verfügbare WD1006 war da der Durchbruch, der hatte statt 2 kiB RAM als Puffer großzügige 8 kiB RAM, was genügte, um auf "Interlave" verzichten zu können, so daß tatsächlich 510 kiB/sec Nettodatenrate möglich waren. Richtig schick war dann die RLL-Variante davon (WD1006-SR2), die erlaubte, wenn man sich über die Spezifikation der Festplatten hinwegsetzte, anderthalbfache Kapazität und anderthalbfache Geschwindigkeit (26 Sektoren pro Spur, also resultierende Nettodatenrate von 780 kiB/sec). Ich hab' irgendwo noch im Schrank eine ST125 liegen, die jahrelang problemlos mit genau so einem Controller als ST138R betrieben wurde ... Und heute findet man einen Internetzugang langsam, der derartige Datenraten liefert. Wie sich die Zeiten ändern ...
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.