Wird das zukünftige Programmiersystem für die neueren alten S7 - und die alten neueren S7 (TIA Portal bis vsl. V13)
Das klingt so schrecklich nach "auf Arbeit", denn privat braucht man eher keine SPS …
Das nächste mal am besten über die Product Server Methode aus einer 25H2 ISO. Clean und easy, hab damit schon zig Rechner problemlos auf 11 25h2 bekommen.
Wenn der Rechner nicht für Windows 11 taugt, weil etwa kein TPM 2.0 vorhanden ist, bekommt man das mit der Product Server Methode vielleicht installiert, aber es ist nur was "zum mal angucken", jedoch nicht produktiv nutzbar, weil Microsoft das System dann mit einem Update ins Nirvana schießt.
Dachte schon, das Brett ist tot. Nach dem Einschalten drehten die Lüfter an, kein Bild, kein Piep, nix. CMOS-Reset inkl. CMOS-Stütze raus bringt nix. Auf dem Brett steckt ein FX 8350.
Den AMD FX 8350 auf ein AsRock 970M gesteckt, startet. Im BIOS u.a. Core C6 mode auf enabled gesetzt, und Brett scheint ebenfalls tot. Nach dem Einschalten drehten die Lüfter an, kein Bild, kein Piep, nix. CMOS-Reset inkl. CMOS-Stütze raus bringt nix.
Dann mal einen Phenom II X4 925 auf das AsRock 970 Pro3 R2.0 gesteckt, der von Core C6 mode nix weiß. Nochmal 'n CMOS-Reset und danach startet das Brett wieder normal. Also wieder den FX 8350 drauf, und alles wie vorher eingestellt außer Core C6 mode, der auf disabled bleibt, Brett startet normal.
Und das AsRock 970M? Das wurde mit der gleichen Prozedur wieder ins Leben zurück geholt, nur das am Ende nur ein FX 6350 drauf kam.
als Soundkarte ne ALS4000. Die sagt mir garnichts.
Die Avance Logic Inc. ALS4000 ist 'ne schlichte PCI-Soundkarte (line-out, line-in, mic-in, MIDI/Game-Port), die auch vom Linux-Kernel ≥ 2.6.0 unterstützt wird.
wurde natürlich schon wieder überall gestreut. Mal sehen, wielange meine Fahrradreifen das mitmachen.
Streugut killt Fahrräder! 
Für die Reifen ist vor allem Splitt ein Problem. Wenn sich so ein Matterhorn mit der Spitze voran in den Mantel einarbeitet, führt das fast immer zu einem Platten.
Für die Metallteile sind die salzbasierten Streumittel ein Problem. Die führen zu Chlorid-induzierter Spannungsrisskorrosion. Unvermittelt reißende Speichen sind ein Beispiel dafür.
Ohne diesen sinnlosen Winter hätten wir diesen ganzen Ärger nicht.
Gut, dass du ein Komma in dem Satz hast...
Hatte überlegt es zu setzen, denn Scheiße wird ja bekanntlich in der Maßeinheit "Zentimeter Schneehöhe" gemessen.
Es schneit, Scheiße!!!
Der Klapprechner könnte vermutlich einen deutlichen Leistungsschub erfahren, wenn Du die SATA-HDD durch eine SATA-SSD ersetzt. Auf die kommen dann die Windows-Installation(en), und auf die 32 GB mSATA-SSD ein Linux. Bei 8 GiB RAM braucht man in den meisten Fällen kein swap.
Zuerst musst Du mal klären, ob eine mSATA-SSD verbaut ist. Das BIOS müsste die anzeigen. Andernfalls bleiben nur der mechanische Weg oder mal 'n Live-Linux starten. Beim Live-Linux dürfte ein dmesg | grep -i ata auf der Console Klarheit bringen.
Wenn das eine mSATA-SSD mit geringer Speicherkapazität ist, dürfte die als Cache für das Betriebssystem bestimmt sein. Ich kenne so etwas vom Lenovo Thinkpad E540, in dem im Lieferzustand damals eine 1 TB SATA-HDD mit einer 16 GB mSATA-SSD kombiniert war, um Windows 8 irgendwie zu beschleunigen.
Ob Windows Vista mSATA-SSDs aus der Tüte erkennt, weiß ich nicht. Du brauchst aber sicherlich einen Treiber für das Caching auf die SSD, wenn Windows Vista das nicht aus der Tüte anbietet.
Habe ich getan - leider kommt nun in der Geräteübersicht folgende Information:
Das ist erwartbar, weil der brother installer alles nach /opt schmeißt. Schau mal, ob Du in CUPS das Verzeichnis zu der Datei auf opt/brother/Printers/mfcj4340dw/cupswrapper umstellen kannst. Wenn das nicht geht, lege einen Link /usr/lib/cups/filter/brother_lpdwrapper_mfcj4340dw an, der auf /opt/brother/Printers/mfcj4340dw/cupswrapper/brother_lpdwrapper_mfcj4340dw zielt. Wenn CUPS dann immer noch wegen der fehlenden Datei nörgeld, kopier den Inhalt von /opt/brother/Printers/mfcj4340dw/cupswrapper nach /usr/lib/cups/filter.
GDI-Drucker aka E-Schrott sind voll die Moppelkotze, weil man für die Treiberei auf Gedeih und Verderb dem Druckerhersteller ausgeliefert ist.
Der Betrieb über WLAN mit statischer IPv4-Adresse könnte die Installation über CUPS vereinfachen, weil dann als Device URI einfach lpd://*.*.*.*/lp mit *.*.*.* = IPv4-Adresse anzugeben ist. WPA3 kann der Drucker nicht. Das Risiko musst Du selbst einschätzen. 
Der Betrieb über einen "einfachen" Printserver (hier: FRITZ!Box) löst keine Probleme mit fehlenden oder rumzickenden Treibern. Diese Printserver dienen lediglich dazu, einen Drucker, der nur über USB oder Parallelport angeschlossen werden kann, im Netzwerk (LAN, WLAN) verfügbar zu machen.
Habe mal mfcj4340dwpdrv-3.5.0-1.i386.rpm runter geladen und ausgepackt. Es ist das übliche Filtertreiber-Gerümpel¹, mit dem Brother die Nutzer penetriert. Immerhin ist in dem Paket eine Version für x86_64 enthalten.
Versuch mal eine Installation über CUPS mittels PPD file. Dazu fütterst Du CUPS mit der Datei brother_mfcj4340dw_printer_en.ppd, die unter /opt/brother/Printers/mfcj4340dw/cupswrapper zu finden ist.
Spricht der Drucker eine Standardsprache, also PCL $_any_version oder PostScript?
¹Für den hier genutzten Brother MFC-9142CDN gibt es das Filtertreiber-Gerümpel nur für ia32. Das erfordert auf x86_64 eine multilib-Umgebung. Weil mir das einzurichten mittlerweile zu blöd geworden ist und auch damit der Drucker nicht richtig lief, wurden schlicht zwei Treiber Generic PCL6 grayscale und Generic PCL6 color installiert. Damit druckt der Drucker so, wie er soll.
Welche "websichere Zeichenkette" verwendet denn so ein USB-Anschluss?
CUPS hat mir noch nie eine nicht websichere Zeichenkette in die Device URI gekloppt. Daher kommt die Vermutung ("sollten […] nicht"), dass Leerzeichen und runde Klammern in der Device URI keine so gute Idee sind. Allerdings waren das alles Drucker an Ethernet oder Parallelport. Wenn das Brother Driver Install Tool meint, dass eine Zeichenkette mit Leerzeichen und runden Klammern in der Device URI funktioniert, probier es aus, also:
lpd://Brother%20MFC-J434DW%20(USB)/lp
ipp:// könnte das Problem sein.
Leerzeichen, also %20, sollten in der Device URI auch nicht verwendet werden, Sonderzeichen dito.
Versuch als Device URI lpd://*/lp, wobei * dann eine websichere Zeichenkette ist.
Falls nicht schon probiert:
TPM2.0+SecureBoot war schon aktiv
SecureBoot muss doch gar nicht aktiv sein, sondern nur im UEFI als Option vorhanden sein. Dazu muss CSM = disabled gesetzt sein. Mit SecureBoot = enabled übergibt man die Kontrolle über den Rechner in Software an Microsoft …
bin auch schon neugierig, ob mal vermehrt 6th/7ths Rechner auftauchen.
Da sollte auch 'n Rudel Sockel-AM3+ unterwegs sein …
Das ATX-Netzteil FSP235-60GTW ist komplett tot, entweder Transportschaden oder altersbedingt einfach "switch to death".
Viel schlimemr ist aber, dass auf dem Lucky Star 5MVP3 drei Blähkos (1× 1000 µF / 10 V & 2× 1000 µF / 6,3 V) versammelt sind. Was fällt denen ein sich sinnlosest aufzublähen anstatt einfach zu funktionieren! Baugleiche 1000 µF / 10 V & 1000 µF / 6,3 V sind 'n paar mehr auf 'm Brett. Da ist zu befürchten, dass die still und friedlich vor sich hin getrocknet sind oder im eingelöteten Zustand unsichtbar unten durch die Gummidichtung abgeblasen haben. Das wäre jedenfalls ein möglicher Grund dafür, dass auf dem Brett 512 MiB = 2× 256 MiB SDRAM PC-133 CL3 double-sided stabil laufen, 768 MiB = 3× 256 MiB SDRAM PC-133 CL3 double-sided hingegen nimmer. Also nochmal Elkos odern und löten …
Hört sich hart nach Netzteil an. Tauschen gegen neues Netzteil! Zweiter Verdächtiger wäre 'n Speicherriegel. Und da wir es hier in 'nem anderen Thread gerade hatten: Hat die CMOS-Stütze noch VBat ≥ 3,0 V? Falls nein, tauschen!
Alle drei genannten Fehler können zu nicht reproduzierbarem Fehlverhalten des Systems führen.
passend zum Reformationstag:
