|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
| | Zitat von hoschi
Was empfehlt ihr den als Werkzeug für eine Statuswebsite? Also nicht "Monitoring" sondern "Status"?
https://cachethq.io/
Braucht eben PHP 
| |
HTML5? 
| |
Ja. Weil faul sein und so 
Und der passende Webserver nicht so ganz auf Patchlevel ist
Es beruhigt mich etwas, der Aktionsmus von Google stoert mich und Nachdenken vor dem Handlen faende ich gut. Alle paar Wochen ein Abenteuer mit ihren Neuerungen und OpenSSL muss ich nicht haben. Hoffentlich haben sie an die anderen typischen Ausnahmen gedacht, wie selbstsignierte Zertifikate oder localhost. Google sollte sich auf rueckwaertskompatible Neuerung beschraenken oder einen Vorschlag machen, wie man das Zertifikatssystem komplett ersetzt.
Mich stoert es, das Google Chrome kontrolliert und an OpenSSl beteiligt ist und den Support fuer CommonName aus Chrome entfernt hat, aber bei OpenSSL nichts angepasst hat. OpenSSL fragt weiterhin den CommonName ab und kann nur mit einer umgebauten openssl.conf ueberhaupt noch gueltige Zertifikate mit AlternateNames erzeugen. Fuer Admins wahrscheinlich normal, aber ich will einfach nur ein fertiges Zertifikat ohne (gefaehrliches?) Konfigurationsvoodoo. Damit einhergehend ist beinahe jede Anleitung fuer selbstsignierte Zertifikate - was Chrome angeht - falsch.
// edit
Bei gnome-terminal hat sich jemand grosse Muehe gegeben und neben Spanisch und Katalanisch, auch noch valenzianisches Katalanisch eingebaut. Der Patch fuer das letzte hat mich jetzt wieder zusaetzlich Arbeit gekostet, weil jemand die halbe PO-File umgebaut hat.
|
|
[Dieser Beitrag wurde 11 mal editiert; zum letzten Mal von hoschi am 31.10.2017 16:00]
|
|
|
|
|
|
|
|
Gelernt
|
| |
| Code: |
626.664412] Bluetooth: hci0: BCM: chip id 63
[ 626.665499] Bluetooth: hci0: BCM: features 0x07
[ 626.682450] Bluetooth: hci0: BCM20702A
[ 626.683369] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000
[ 626.683394] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e6.hcd failed with error -2
[ 626.683397] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21e6.hcd not found
|
|
Funktioniert doch 
Erklaerung: Hat wohl eine Firmware eingebacken in einem One-Time-Programmable-Speichermodul. Wenn man stattdessen die externe Firmware laed, koennte auch HSP, HFP oder auch A2DP funktionieren. Mal vorsichtig probieren, gibt es leider nur in Windowstreibern zum herunterladen. Lustiger Weise enthaelt gleich ein Konvertierungswerkzeug mit hex2hcd. Broadcom hat natuerlich nicht die Firmware in linux-firmware aufnehmen lassen, Lizenz erlaubt keine Weiterverbreitung. Im Jahr 2017 
Da stellt sich Broadcom bei den WLAN-Chips einerseits nicht so schlau an, andererseits doch schlauer.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 31.10.2017 18:55]
|
|
|
|
|
|
|
|
|
UEFI und SecureBoot waren von Anfang an Fehler, die Management-Engine steigert den Umfang nochmal. Coreboot klingt wie eine moegliche Loesung, das haengt von der Codequalitaet und wohl auch von der Hardware darunter ab. Linux als Firmware finde ich dagegen auch gruselig, weil das ein riesiger Ballast ist. Warum wird hier wieder versucht ein softwarepolitisches Problem mit Mitteln gegen ein technisches Problems (Quellcode) zu loesen? Ich meine, was soll ernsthaft getan werden - das Problem aus der Welt schaffen oder verzweifelt rumfrickeln?!
Google hat ja selbst die politische Loesung bei den Chromebooks gewaehlt, auch wenn diese mit der Userlandsoftware von Google unbrauchbar gemacht werden. Google koennte sich ja mal den damaligen Bedenken von Canonical und RedHat zu SecureBoot anschliessen und das ganze (UEFI, SecureBoot und ME) zur EU-Kommission tragen. Das braucht ewig, aber die freuen sich da immer so goldig, wenn sie - endlich - etwas getan haben. Bezueglich des Servermarktes hat Google allein wahrscheinlich schon so viel Gewicht, dass AMD deren Wuensche umgehend umsetzen wuerde und Prozessoren (also auch Chipsaetze) und Mainboards nur mit Coreboot liefern wuerde.
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von hoschi am 31.10.2017 21:48]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VBA nur Bronze ist etwas überraschend. Perl irgendwie auch. Bei Delphi ist das glaub ich so ein "ist das immer noch nicht tot?"-Problem.
|
|
|
|
|
|
|
|
|
|
|
Sehr schön auch das Bild hier:
Backend developer hassen frontend mehr als frontend developer backend hassen. 
|
|
|
|
|
|
|
|
|
|
|
Kein Wunder
|
|
|
|
|
|
|
|
|
|
|
Warum hassen Linuxleute die Windowsleute, aber umgekehrt nicht?
Weil die Windowsleute Linux immer ignorieren 
PS: C++ ist immer noch beliebter als Java und Bash macht Programmiere glücklich 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 02.11.2017 17:16]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Warum hassen Linuxleute die Windowsleute, aber umgekehrt nicht?
Weil die Windowsleute Linux immer ignorieren
| |
wir sind einfach gechillter. Wir müssen ja ständig auf Windows Update warten, da wird man automatisch zum buddhistischen Mönch (oder stirbt am Schlaganfall).
Was mich freut ist der Hass auf Webforms, das kann nicht schnell genug an die Wand gestellt werden.
Edit: Hello Bhudda, whoever you are!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GarlandGreene am 02.11.2017 17:23]
|
|
|
|
|
|
|
|
|
75% des Perl-Hasses kommen eh nur von kläglich gescheiterten Versuchen die Regex zu benutzen :P
|
|
|
|
|
|
|
|
|
|
|
Dafür freut sich der Linuxanwender auf Updates
Meine Kollegin hat glatt eine spezifische Windows-API in unser Programm eingebaut, ohne #ifdef. Eiskalt Linux ignoriert
Ignorieren tut weh, sehr. Besonders dann wenn der Hardwarehersteller, Spielehersteller und Anwendungshersteller dich immer ignorieren und Eiskalt ZUNIXKOMPATIBEL sind.
|
|
|
|
|
|
|
|
|
|
|
|
Meinten Sie: z/UNIX kompatibel?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Dafür freut sich der Linuxanwender auf Updates
| |
ich muss ja gestehen, daß ich bei Windows eigentlich nie Sorgen vor Updates habe. Aber wenn ich mal ne ältere Linux-Kiste, die längere Zeit keine Updates bekommen hat, aktualisieren muss, mach ich vorher 4 Backups und 10 Snapshots. Und ein paar mal hab ich die auch schon gebraucht.
|
|
|
|
|
|
|
|
|
|
|
Dito, Windows Updates (also normale Updates) laufen entweder durch oder schlagen irgendwie fehl, aber alles funktioniert weiterhin, sodass einen letzteres nicht groß interessieren braucht. Probiert er später automatisch wieder, klappt meistens. Hab noch nie ein Windows oder Daten an ein Update verloren... zumindest nicht, dass ich wüsste.
e: Abseits von Desktops hatte ich da mal diesen Windows Server (2008R2), der rund fünf Jahre wartungsfrei durchgelaufen ist, da habe ich vielleicht zwei oder dreimal geschaut, ob alle Updates drauf waren... brauchte sonst nix machen. Lief einfach.
.
Lenovo plant Mehrheitsübernahme der PC-Sparte von Fujitsu
Demnächst: Lenovo plant Übernahme der PC-Sparte von Dell
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 02.11.2017 17:51]
|
|
|
|
|
|
|
|
|
|
Aha. Dachte ich mir doch, dass da was im Busch ist als wir als neuen Ausrüstungspartner plötzlich Lenovo hatten.
|
|
|
|
|
|
|
|
|
|
|
Aufteilung der IT-Welt wie folgt:
Lenovo, Samsung, Huawei und der unbedeutende Rest.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Dito, Windows Updates (also normale Updates) laufen entweder durch oder schlagen irgendwie fehl, aber alles funktioniert weiterhin, sodass einen letzteres nicht groß interessieren braucht. Probiert er später automatisch wieder, klappt meistens. Hab noch nie ein Windows oder Daten an ein Update verloren... zumindest nicht, dass ich wüsste.
| |
benutze windows seit 12 jahren nichtmehr, hab deshalb da keine erfahrungswerte, aber bei heise&co liest man doch mehrmals im jahr irgendwas von "bluescreens" nach updates? auch hat ein kollege das problem schonmal gehabt...?
|
|
|
|
|
|
|
|
|
|
|
|
Das häufigste Problem mit Windows-Updates ist "mistiger Virenscanner X hält plötzlich $essentielleSystemkomponente für einen Virus und löscht sie" in meiner Wahrnehmung. Danach kommt dann das gelegentliche "bei Mondstellung 44.71° überm Horizont und mit Version 14.5.7 Build 2138 von Treiber Y und wenn KB2378821 vor und nicht nach KB21381293 installiert wurde oder KB23712313 manuell installiert wurde, führt KB2131233 (zurückgezogen) zu einem BSOD unter Bedingung Foxtrott Alpha".
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
benutze windows seit 12 jahren nichtmehr, hab deshalb da keine erfahrungswerte, aber bei heise&co liest man doch mehrmals im jahr irgendwas von "bluescreens" nach updates? auch hat ein kollege das problem schonmal gehabt...?
| |
Probleme gibts hin und wieder mal, aber bisher war das nur Zeug von dem ich gelesen hab, nichts davon hab ich selber erlebt. Bei uns im Büro ist natürlich die Regel, daß WSUS-Updates erst mal auf ne kleine Gruppe Rechner ausgerollt werden, bevor der Rest sie bekommt. Aber auch zuhause hab ich nie Probleme mit Updates gehabt, nur mit der Installation derselben (wuauserv braucht teilweise Stunden, um die Updates zu ermitteln und zu installieren, allerdings eher auf älteren ungepatchten Kisten).
Windows 10 Upgrades können manchmal Ärger machen. Wir hatten letztens einige baugleiche Optiplex-Systeme, die aufgrund eines Audio-Treibers nach dem Upgrade unbenutzbar wurden, aber selbst das hab ich dann im abgesicherten Modus repariert bekommen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GarlandGreene am 03.11.2017 13:42]
|
|
|
|
|
|
|
|
|
in aller regel sind das treiberprobleme, die zu den bluescreens führen.
da hab ich inzwischen allerdings auch kein verständnis mehr führ, wenn die hersteller der hardware es nicht gebacken bekommen nach knapp 6 monaten, in denen microsoft da ne beta bereitstellt, saubere kompatible treiber zu liefern.
den letzten bluescreen den ich hier gesehen hatte war auf grund von nem abgrundtief miserablen intel treiber. nachdem ich den eliminiert hatte, lief das system stabil.
das was ich da microsoft allerdings empfehlen würde ist, dass gleiche system für alle treiber zu implementieren, was sie für grafikkartentreiber gebaut haben. da kann dir der treiber, selbst die kernel komponente, explodieren und der kernel resettet die hardware und lädt den treiber neu. das führt zu nem kurzen freeze des bildes und dann kannst du weiterarbeiten, als wenn nichts gewesen ist.
wenn das da wäre, dann könnten die updates das versuchen mit den treibern von den herstellern und wenn die dann x mal auf die fresse fliegen, dann wird entweder der treiber nicht mehr geladen oder aber nen kompatibilitätstreiber verwendet, bis der hersteller sich dazu bewegt den kram zu fixen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Das häufigste Problem mit Windows-Updates ist "mistiger Virenscanner X hält plötzlich $essentielleSystemkomponente für einen Virus und löscht sie" in meiner Wahrnehmung. Danach kommt dann das gelegentliche "bei Mondstellung 44.71° überm Horizont und mit Version 14.5.7 Build 2138 von Treiber Y und wenn KB2378821 vor und nicht nach KB21381293 installiert wurde oder KB23712313 manuell installiert wurde, führt KB2131233 (zurückgezogen) zu einem BSOD unter Bedingung Foxtrott Alpha".
| |
Ebenso meine Erfahrung und Dank unserer Admins hält "McAffe" folgendes für Viren:
- Den GNU-Linker und die Executables daraus
- Alles was Executabledateien überschreibt (also jeden Installer...)
- MSYS2-Updates
- Die Hälfte allen Javascripts und CSS-Codes im Internet...
Mir ist in den letzten Jahren auch noch nicht Archlinux bei einem Update zerbrochen. Grobe Fehler, höchstes bei der Installation durch mich.
Ich würde mich aber auch nicht trauen, das Ubuntu 12.04 hier noch irgendwo hin zu aktualisieren, genauso wie das SLES aus 2009. Das wäre auch so schlau, wie von XP über Vista, 7, 8 auf Windows 10 zu aktualisieren.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 03.11.2017 15:28]
|
|
|
|
|
|
|
|
|
aus der kategorie "warum sollte ich keine alte hardware versuchen zu nutzen":
| |
| Code: |
Nov 3 23:12:49 oxy kernel: [ 11.040764] e1000 0000:05:04.0 enp5s4f0: Detected Tx Unit Hang
Nov 3 23:12:49 oxy kernel: [ 11.040764] Tx Queue <0>
Nov 3 23:12:49 oxy kernel: [ 11.040764] TDH <0>
Nov 3 23:12:49 oxy kernel: [ 11.040764] TDT <1>
Nov 3 23:12:49 oxy kernel: [ 11.040764] next_to_use <1>
Nov 3 23:12:49 oxy kernel: [ 11.040764] next_to_clean <0>
Nov 3 23:12:49 oxy kernel: [ 11.040764] buffer_info[next_to_clean]
Nov 3 23:12:49 oxy kernel: [ 11.040764] time_stamp <fffb8f8d>
Nov 3 23:12:49 oxy kernel: [ 11.040764] next_to_watch <0>
Nov 3 23:12:49 oxy kernel: [ 11.040764] jiffies <fffb9740>
Nov 3 23:12:49 oxy kernel: [ 11.040764] next_to_watch.status <0>
Nov 3 23:12:51 oxy kernel: [ 13.088403] e1000 0000:05:04.0 enp5s4f0: Detected Tx Unit Hang
Nov 3 23:12:51 oxy kernel: [ 13.088403] Tx Queue <0>
Nov 3 23:12:51 oxy kernel: [ 13.088403] TDH <0>
Nov 3 23:12:51 oxy kernel: [ 13.088403] TDT <1>
Nov 3 23:12:51 oxy kernel: [ 13.088403] next_to_use <1>
Nov 3 23:12:51 oxy kernel: [ 13.088403] next_to_clean <0>
Nov 3 23:12:51 oxy kernel: [ 13.088403] buffer_info[next_to_clean]
Nov 3 23:12:51 oxy kernel: [ 13.088403] time_stamp <fffb8f8d>
Nov 3 23:12:51 oxy kernel: [ 13.088403] next_to_watch <0>
Nov 3 23:12:51 oxy kernel: [ 13.088403] jiffies <fffb9f40>
Nov 3 23:12:51 oxy kernel: [ 13.088403] next_to_watch.status <0>
Nov 3 23:12:53 oxy kernel: [ 14.816015] NETDEV WATCHDOG: enp5s4f0 (e1000): transmit queue 0 timed out
Nov 3 23:12:53 oxy kernel: [ 14.816912] ------------[ cut here ]------------
Nov 3 23:12:53 oxy kernel: [ 14.817775] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x1f4/0x200
Nov 3 23:12:53 oxy kernel: [ 14.818672] Modules linked in: nls_ascii nls_cp437 qla2xxx nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc bonding ip_tables x_tables
Nov 3 23:12:53 oxy kernel: [ 14.820535] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.9-oxy #1
Nov 3 23:12:53 oxy kernel: [ 14.821483] Hardware name: Dark Matter Solutions OXY Storage System/S3210SH, BIOS S3200X38.86B.00.00.0052.112920101508 11/29/2010
Nov 3 23:12:53 oxy kernel: [ 14.823458] task: ffffffffa460e480 task.stack: ffffffffa4600000
Nov 3 23:12:53 oxy kernel: [ 14.824473] RIP: 0010:dev_watchdog+0x1f4/0x200
Nov 3 23:12:53 oxy kernel: [ 14.825478] RSP: 0018:ffff958e1fc03e98 EFLAGS: 00010282
Nov 3 23:12:53 oxy kernel: [ 14.826479] RAX: 000000000000003d RBX: 0000000000000000 RCX: 0000000000000000
Nov 3 23:12:53 oxy kernel: [ 14.827517] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 0000000000000300
Nov 3 23:12:53 oxy kernel: [ 14.828557] RBP: ffff958e162ce000 R08: 0000000000000000 R09: 00000000000003d6
Nov 3 23:12:53 oxy kernel: [ 14.829609] R10: 0000000000000293 R11: ffff958e13c607a0 R12: 0000000000000001
Nov 3 23:12:53 oxy kernel: [ 14.830676] R13: 0000000000000000 R14: ffff958e162ce000 R15: 0000000000000000
Nov 3 23:12:53 oxy kernel: [ 14.831744] FS: 0000000000000000(0000) GS:ffff958e1fc00000(0000) knlGS:0000000000000000
Nov 3 23:12:53 oxy kernel: [ 14.832828] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 3 23:12:53 oxy kernel: [ 14.833917] CR2: 00007f06dae06ab4 CR3: 0000000208ee5000 CR4: 00000000000006f0
Nov 3 23:12:53 oxy kernel: [ 14.835034] Call Trace:
Nov 3 23:12:53 oxy kernel: [ 14.836146] <IRQ>
Nov 3 23:12:53 oxy kernel: [ 14.837247] ? qdisc_rcu_free+0x40/0x40
Nov 3 23:12:53 oxy kernel: [ 14.838354] ? call_timer_fn+0x2e/0x120
Nov 3 23:12:53 oxy kernel: [ 14.839454] ? run_timer_softirq+0x1c7/0x400
Nov 3 23:12:53 oxy kernel: [ 14.840558] ? tick_sched_handle+0x23/0x60
Nov 3 23:12:53 oxy kernel: [ 14.841658] ? tick_sched_timer+0x34/0x70
Nov 3 23:12:53 oxy kernel: [ 14.842751] ? __do_softirq+0xff/0x287
Nov 3 23:12:53 oxy kernel: [ 14.843831] ? irq_exit+0xa8/0xb0
Nov 3 23:12:53 oxy kernel: [ 14.844899] ? smp_apic_timer_interrupt+0x39/0x50
Nov 3 23:12:53 oxy kernel: [ 14.845963] ? apic_timer_interrupt+0x7f/0x90
Nov 3 23:12:53 oxy kernel: [ 14.847026] </IRQ>
Nov 3 23:12:53 oxy kernel: [ 14.848088] ? mwait_idle+0x60/0x160
Nov 3 23:12:53 oxy kernel: [ 14.849144] ? do_idle+0x177/0x1a0
Nov 3 23:12:53 oxy kernel: [ 14.850184] ? cpu_startup_entry+0x6f/0x80
Nov 3 23:12:53 oxy kernel: [ 14.851220] ? start_kernel+0x408/0x428
Nov 3 23:12:53 oxy kernel: [ 14.852253] ? secondary_startup_64+0x9f/0x9f
Nov 3 23:12:53 oxy kernel: [ 14.853292] Code: 63 8d 60 04 00 00 eb 96 48 89 ef c6 05 43 16 a4 00 01 e8 50 a0 fc ff 89 d9 48 89 ee 48 c7 c7 60 ce 3d a4 48 89 c2 e8 07 d6 7f ff <0f> ff eb c3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 c7 47 08
Nov 3 23:12:53 oxy kernel: [ 14.855500] ---[ end trace eb86c21da6b94e26 ]---
Nov 3 23:12:53 oxy kernel: [ 14.856643] e1000 0000:05:04.0 enp5s4f0: Reset adapter
Nov 3 23:12:59 oxy kernel: [ 21.024270] e1000 0000:05:04.0 enp5s4f0: Detected Tx Unit Hang
Nov 3 23:12:59 oxy kernel: [ 21.024270] Tx Queue <0>
Nov 3 23:12:59 oxy kernel: [ 21.024270] TDH <0>
Nov 3 23:12:59 oxy kernel: [ 21.024270] TDT <1>
Nov 3 23:12:59 oxy kernel: [ 21.024270] next_to_use <1>
Nov 3 23:12:59 oxy kernel: [ 21.024270] next_to_clean <0>
Nov 3 23:12:59 oxy kernel: [ 21.024270] buffer_info[next_to_clean]
Nov 3 23:12:59 oxy kernel: [ 21.024270] time_stamp <fffbb760>
Nov 3 23:12:59 oxy kernel: [ 21.024270] next_to_watch <0>
Nov 3 23:12:59 oxy kernel: [ 21.024270] jiffies <fffbbe40>
Nov 3 23:12:59 oxy kernel: [ 21.024270] next_to_watch.status <0>
Nov 3 23:13:01 oxy kernel: [ 23.072219] e1000 0000:05:04.0 enp5s4f0: Detected Tx Unit Hang
...
|
|
die lustigen "Tx Unit Hang" messages werden dann für ca. 1-5 minuten produziert, irgendwann resettet sich der chip dann und dann hat man für nen paar minuten ruhe, danach fliegt einem die zweite chip function um die ohren mit dem exakt gleichen fehler.
das scheint, soweit ich das recherchieren konnte, ausschliesslich in der kombination zwischen der Intel Pro/1000 MT (82546EB) und dem Intel 6702PXH (PCIe -> PCI-X bridge) in kombination mit einer hand voll chipsätzen wie z.b. dem Intel 3210 MCH aufzutreten.
die mailingliste zu dem e1000 treiber war da ernüchternd hilfreich. das was ich weiss ist, dass genau dieser fehler nur auf intel platformen auftritt und es einen separaten anderen alignment fehler gibt, der auf nicht intel platformen auftritt. praktischerweise gibt es zu dem 80546EB scheinbar keine spec updates mehr um möglicherweise mal zu sehen, ob die da ne information zu haben. ok, ist hardware von anno 2003, aber man bekommt ja auch immer noch die spec updates zum 80486DX2 und co.
angenehm in dem zusammenhang ist auch, dass jegliche empfohlenen workarounds, die ich zu dem oder ähnlichen problemen finden konnte einfach gar nichts bringen, die verzögern das auftreten einfach nur.
das aller tollste daran ist aber, dass das scheinbar nen bug auf dem board (Intel S3210SHLX) auslöst, welcher dann zu nem kompletten system freeze führt, also nix crash dump oder ähnlichem, das system steht einfach. interessanterweise inklusive dem on-board BMC, der eigentlich komplett separat laufen sollte und das eigentliche system via watchdog resetten sollte, wenn es denn hängt. da bleibt dann nur der weg zum stecker bzw. netzteil, da auch die ATX schalter am gehäuse nicht mehr funktionieren.
man lernt also daraus, dass intel hardware durchaus ein wenig sehr buggy sein kann, auch gut 15 resp. 10 jahre nach erscheinen.
was mich dabei allerdings am meisten interessieren würde ist, warum der BMC da mit abraucht? die einzige erklärung die ich dafür hätte wäre, dass das normale OS die shared NIC (nicht die betroffene) resettet und in einen undefinierten zustand versetzt, was die BMC verbindung zerlegt. gleichzeitig müsste dann der BMC auf den kontrollleitungen zum eigentlichen system immer noch sehen, dass alles okay ist und deshalb der watchdog den reset nicht zündet.
das wiederum wirft bei mir die frage auf, sollte der watchdog nicht eigentlich von der software auf dem kasten alle x sekunden resettet werden damit der nicht auslöst?
btw. kauft euch bzw. betreibt nicht solche hardware!
/e
ich hab mir übrigens mal noch den nachfolger, der nachfolgenden chip revision der Pro/1000 aka die Pro/1000 GT bestellt. die sollte morgen hier ankommen und ich bin mal gespannt, ob das da auch auftritt, weil laut mailing listen archiv und dem tatsächlich noch existierenden spec update sind dort keine solchen fehler bekannt.
hab ich schonmal erwähnt, warum ich kein fisi werden wollte, obwohl mir alle dazu geraten haben, weil ich doch so gut dabei bin...?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 03.11.2017 22:38]
|
|
|
|
|
|
|
|
|
Alte Hardware unter Linux fand ich eigentlich immer sehr geil.
Kumpel hatte irgendwann eine alte Soundkarte mit 19" Panel und wollte die im Proberaum für Aufnahmen nutzen.
Offiziell gab es dafür Treiber für WinXP. Ich habe ne Stunde versucht das ans laufen zu kriegen, aber der Treiber schmierte ständig ab. Dann hab ich Linux probiert. Sämtliche Kanäle liefen auf Anhieb. Wir waren echt schwer begeistert.
|
|
|
|
|
|
|
|
|
|
|
Aureal 3D Vortex 2.0
Gibt nur Betatreiber für Win2K, die notdürftig unter WinXP laufen. In Quake3 und CS1.6 hat man damit A3D in Stereo, es ist soooo viel besser als EAX von Creative (welche Aureal aufgekauft haben). Die Treiber sind stabil, schon seit gefühlt immer im Linuxkernel.
Ich müsste mal probieren, ob ich A3D in CS1.6 unter Linux einschalten kann.
A3D ~ Sonar
Linux ist wie ein Weinkeller, nur wirklich gute Rotweine kommen rein und werden noch besser mit der Zeit. Siehe OpenGL-Support für die HD3000 (Intel SandyBridge), jetzt OpenGL 3.3 (MacOS 3.2, Windows 3.1), hat halt ewig gebraucht.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 04.11.2017 18:22]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Linux ist wie ein Weinkeller, nur wirklich gute Rotweine kommen rein und werden noch besser mit der Zeit.
| |
Wow
|
|
|
|
|
|
|
|
|
|
|
|
Linux ist wie ein Dreier mit zwei Pornodarstellerinnen. Hört sich großartig an, aber irgendwie ist man ganz schnell komplett überfordert.
|
|
|
|
|
|
|
|
|
|
|
Ist halt nichts für Anfänger.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Muss ich wohl doch mal Windows installieren
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
