• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Der "Was hast du heute gelernt?" Thread

das.chaos

Duracellhase 2.0
#76
Heute habe ich gelernt, dasz AF_CAN auf bald fuer FreeBSD funktionieren wird [wobei das Debugging etwas krittelig werden wird], aber es kompliziert ist einen CAN-Adapter mit SJA1000 Controller zu beschaffen, da mir der Loopback etwas zu "langweilig" ist.

@holgerw Reatltek rockt!!!1!!
 

das.chaos

Duracellhase 2.0
#78
Jo, krass. Danke [kannte ich noch nicht], aaaaber USB ist mir noch etwas "gewoehnungsbedurftig", da ich mich von der Komplexitaet von USB erschlagen fuehlte, als ich mich etwas mit USB beschaeftigte [was definitiv dem "Groessenwahn" etwas Einhalt gebot, dem ich beinahe verfallen bin oder waere, wobei ich mir noch nicht ganz sicher bin].

Mir schwebt fuer den Anfang etwas "leichteres", wie bspw. ein PCI-Adaper, vor dem geistigen Auge vor, weil das etwas "einfacher" zu portieren oder besser zu "verstehen" ist.

Vielleicht sollte ich noch etwas "aufraeumen" bevor ich mich an einem Controller "abarbeite", wobei MAC / LLC laut ISO 11898-1anscheinend kein Hexewerk ist [habe schon ISO 11898-1 grob "ueberflogen" und Inhalte mit Quellcode vom Adapter mit SJA1000 Controller verglichen oder wie man so eine "Netzwerkkarte" in der "CAN Welt" nennt].

Jetzt wird das etwas off-topic. *duck* :>
 
Zuletzt bearbeitet:

darktrym

Fahnenträger
#82
Seit Tagen rede ich in der Firma mir den Mundel fusselig dass MemoryMappedFiles schneller sind ist als gewöhnliche Memorystreams.
Ich bekomme dann solch Argumente wie aber "in der Implementation von Delphi wird auch nur am Stück eingelesen, wie soll das schneller sein'?!
Nun habe ich endlich mir die Zeit genommen mich durch die Windows Dokumentation zu wühlen und habe ein Vergleichstest gebaut und siehe da 45% schneller. Dazu durfte ich mich in Boyer-Moore-Algorithmus einlesen und den zurecht hacken um zeilenweise die Treffer anzuzeigen.
 

ralli

BSD Fanboy
#83
Vorübergehend zurück geworfen auf meinen fast 14 Jahre alten PC mit 2 GB RAM habe ich gelernt, wie unterschiedlich OS und Desktops sich verhalten bei gleicher Hardware Architektur, was die Resourcenauslastung und CPU Last betrifft. So belegt unter CentOS 7 Linux der aktuelle Mate Desktop nach dem Start lt. Systemmonitor nur 12 % RAM, bei Debian und FreeBSD viel mehr als das doppelte, so um die ca 32 %. Womit das erklärt werden könnte, kann ich nicht beurteilen. Das es graduelle Unterschiede gibt, ist mir schon klar, aber solche signifikanten Unterschiede dürften meineserachtens nicht sein. Bei aktueller Hardware spielt das natürlich alles keine Rolle. Fazit, Vergleiche bringen immer unterschiedliche Ergebnisse. Das einzuordnen, bedingt einen hohen Grad an technischer Kompetenz. Aber eine wirkliche realistische Antwort erwarte ich auch nicht.
 

Athaba

Libellenliebhaber
Mitarbeiter
#84
Habe gestern gelernt, dass das OpenBSD-Basissystem die perfekte Lösung ist wenn man jemanden im klassischen Stil statische Dateien auf einem Server hosten lassen will.

OpenSSH mit SFTP Chroot, OpenBSD httpd und acme-client sind schnell konfiguriert und eine perfekte Kombination.

Dazu noch das Learning, dass echt viele Leute mit Filezilla umgehen können, selbst wenn sie so gar keine Ahnung von irgendwas technischem haben. Das habe ich unterschätzt. Dürften doch die meisten Leute schon einmal für irgendwas verwendet haben.

Hintergrund: Mir ging es nicht darum unbedingt auf einem BSD aufzubauen oder gar selbst eine Lösung bereitzustellen, aber am Ende war es dann das einfachste, weil jemand HTML-Dateien, die von wo kamen online stellen wollte. Hatte zunächst nach klassischen Webhostern gesucht oder irgendsowas wie "CDN mit statischem Hosting", aber das war alles irgendwie kompliziert, komisch oder wenig Vertrauen erweckend. Vor allem kam das mit Unmengen an Zeug (MySQL, PHP, Email, etc.), das nicht gebraucht wurde. Einige Lösungen die auch preislich einigermaßen okay waren klangen danach, dass wenn das jetzt ein paar Aufrufe hätte gleich mal an irgendwelchen Limits wäre. Das wollte ich auch nicht riskieren.
 

SolarCatcher

Well-Known Member
#86
Ich habe heute gelernt, dass unter FreeBSD 12 ein "pfctl -t pfbadhost -T replace -f /etc/pf-badhost.txt" fehl schlägt, wenn die Datei mehr als 2^15 IP-Adressen hat. Unter FreeBSD 11 war das kein Problem. Ein "-add" zeigte bei mir ebenfalls kein Problem - nur ein "-replace".

Lösung bringt das Hochsetzen der neuen sysctl net.pf.request_maxcount. Dabei ist zu beachten, dass ein "-replace" offenbar für jede IP Adresse den zweifachen Wert benötigt. In meinem Fall hat die Datei mit den Badhosts gut 50.000 Einträge. Daher reichte mir ein Wert von 2^16-1 in der /boot/loader.conf (bei o.g. sysctl handelt es sich um ein Tunable Value, das nur beim Booten gesetzt werden kann):
Code:
# Einfügen in /boot/loader.conf
net.pf.request_maxcount=131071
Wofür das ganze? Ich verfahre (ungefähr) nach diesem Howto, um täglich eine Liste bekannter Badhosts zu aktualisieren, die dann per PF vom Server weggehalten werden: https://www.geoghegan.ca/pfbadhost.html

Der Vollständigkeit halber, hier mein Bug-Report mit der Antwort von Kristof Provost.
 

pit234a

Well-Known Member
#87
was ich Sonntag gelernt habe:

wende dein erworbenes Wissen an und zwar bedächtig!

Oder anders gesagt: bau keinen Riesenmist mit der Hoffnung, es wird schon gut gehen, weil du so ein Gefühl hast, gerade eben dran zu sein mit "Glück haben".

Was hatte ich verbockt?

Ich wollte meinen ziemlich alten RaidZ1 größere Platten geben (nach einiger Überlegung entschied ich mich hierfür).
Die erste getauschte Platte war die älteste im Verbund mit fünf Platten, über 100.000h und aus purer Kuriosität noch im Pool. Beim Resilver gab es einen ersten Fehler, eine Datei wurde an gemeckert. Nicht weiter wichtig. Bei der Gelegenheit erinnerte ich mich dann aber daran, dass ich gar keinen aktuellen Backup hatte!!!
Natürlich hatte ich Backups der "wichtigen Dinge", aber es waren nun mal im Laufe der Zeit auch unwichtige Dinge, die aber nett zu haben sind, hinzugekommen. Als Beispiel: noch ungesehene Filme. Außerdem fiel mir gerade ein, dass ich den Fileserver nicht alleine nutze und auch die Backups der wichtigen Dinge veraltet sein können (nein, sicher veraltet sind), weil eben Leute aus meiner Familie Daten abgelegt haben könnten.
Jeder weiß, dass ohne Backup nichts geht.
Ich weiß nicht, wie oft ich das schon gepredigt habe.
Man kann natürlich mal Gottvertrauen beweisen und schlampig damit umgehen, aber nicht vor einem geplanten Umbau!!!
Auch ich weiß das, natürlich, eigentlich...

Schon genug Mist gebaut?
Weit gefehlt.
Mir schwante, dass ich nun doch einen Backup haben wollte, bevor ich weiter umbaute. Wie das zu machen ist, war meine nächste Sorge, denn ich hatte kein externes Medium mehr herumliegen, das ausreichend Speicherplatz gehabt hätte. Wegen des Resilverings mit einer defekten Datei (die auch schon ersetzt worden war), hatte ich nebenbei einen scrub angeworfen. Nach einem Plattentausch ja grundsätzlich keine dumme Idee. Doch die nächste Idee war dafür umso dümmer. Ich hatte nämlich eine interne HD mit ausreichend Kapazität frei und wollte die zunächst in ein externes Gehäuse friemeln und dann über Netzwerk und USB3 meinen Backup machen, als mir so in den Sinn kam, dass direkt im Fileserver ja noch ein SATA-Port frei ist und dass es viel schneller und auch einfacher ist, die Platte im Server provisorisch zu verkabeln und das Backup direkt über SATA zu fahren. Die Idee gefiel mir gut, ich schnappte ein SATA-Kabel und verlegte es, stöpselte es ins Motherboard, pulte ein Spannungskabel hervor und legte es zur Platte, schloss mein SATA-Kabel an der Platte an und betrachtete das Spannungskabel und dachte bei mir selbst: "och, da wird ja schon nichts passieren, wenn ich die Platte nun im laufenden Betrieb (bei laufendem Scrub!) einfach mal anschließe"...
Und ja, ihr könnt euch eure Kommentare auch an der Stelle sparen: ich kenne sie alle! Ich habe es schon hunderttausendmal mit Kopfschütteln und Unverständnis Anderen erklärt und nie verstanden, wie man denn sooo dooof sein kann.
Und dann schnappte der Stecker auf den Anschluss und alle Festplatten stellten ihre Aktivität spontan ein, das System war nicht mehr erreichbar, die ssh-Konsolen hingen, nichts mehr, nur drehende Lüfter.
Auch nach einem Neustart keinen Kontakt mehr zum System.
Scheiße.
Oder?

Man kann da gar nicht sagen oder denken: Pech gehabt.
Das ist kein Pech, das ist Dummheit! Nein, dass ist Dummheit in beliebiger Potenz.

Nehmt das alle zum Anlass, nicht selbst dumm zu sein UND wider besseres Wissen zu handeln!

Ich möchte die Geschichte noch ein wenig weiter erzählen.
Der Fileserver ist ein altes FreeBSD, das niemals upgedatet wurde. Das ZFS darauf eines der ersten in FreeBSD benutzten. Ich sollte den vielleicht neu machen, bin aber zu faul. Jedenfalls gab es damals Probleme mit root on ZFS und ich entschied mich, auch aus anderen Gründen, das System auf einem Stick mit UFS zu betreiben. Von diesem Stick halte ich eine Kopie im Fileserver parat, für den Fall der Fälle. Den hatte ich nun ja. Also, Neustart mit alternativem Stick und ein Blick auf den zpool zeigte: drei Platten faulty, pool faulty, alles im Eimer, alles Hin.
Das war Sonntag.
Heute früh betrachtete ich mir den Bootvorgang mit dem ersten Stick (ich musste dazu eine GraKa einbauen) und sah, dass er ein defektes Dateisystem hatte. Stick in den PC, fsck, neuer Start vom Stick, Blick auf den Pool: ein neuer Scrub beginnt und der Pool ist nur ein wenig Degraded.

Inzwischen ist der Scrub durch und mein Pool meldet sich heil wieder.
Ich fasse nichts an! Derzeit läuft ein Backup, auf ein neu gekauftes, externes Medium. Lass es laufen, so lange es dauert!

Vielleicht ist das gerade so nochmal gut gegangen. Vielleicht werde ich weiteres Lehrgeld bezahlen müssen.
Glück gehört zum Leben, aber man kann sich nicht darauf verlassen und sollte es einfach nicht in Anspruch nehmen.

Wenn das nochmal gut geht und man daraus eine Lehre ziehen will: trust in ZFS

Allerdings gibt es vielleicht auch eine rein technische Lehre, denn offenbar schreibt ein Scrub nicht nur etwas auf die benutzten Datenplatten, sondern auch ins System (bei mir einen USB-Stick). Deshalb kann man nicht "in laufendem Betrieb" innerhalb eines Scrubs das System wechseln. Zumindest nicht so einfach, wie ich das machte.

Und noch was nebenbei, was dieser Aktion aber nicht bedurft hätte: mein nächster Pool hat >= zwei Platten Redundanz. Alles Andere ist Pfusch. Es wird ein Raidz2 werden, wenn irgendwie möglich.
 

Vril

Well-Known Member
#90
ich habe heute gelernt, dass der Inhalt eines int Arrays Elements in C, von dem man ziemlich sicher ist,
dass der Wert entweder 0 oder 70000 betragen muss - man aber immer wieder 18801652560 zu sehen bekommt,
keineswegs ein Fehler in Form einer Adresse o.ä. sein muss - sondern total korrrekt ist, wenn man bedenkt dass der Wert
von einer Mototorola BIG_ENDIAN Maschine kommt und hier in der LITTLE_ENDIAN Welt natürlich byte-vertauscht
interpretiert wird.

Klar, dafür haben kluge Köpfe <byteswap.h> erdacht ... aber bis ich da 'mal drauf gekommen bin?! -- OMG!
 

serie300

Well-Known Member
#91
Little <-> Big Endian <-> Mixed <->...
Menschenlesbare ASCII "Header" Files, die den Datensatz beschreiben (vorgeschlagen z.B. auch in der ISO 21289) und dann ein simpel aufgebauter Binary Datensatz, werden leider viel zu selten genutzt. Dann könnte man ja Datensätze selber auswerten, anstatt irgendeine proprietäre Meßgeräte SW zu verwenden. Die andere Fraktion ist die "Ich werte es in Excel aus" Fraktion; wenn's einer wollte, habe ich auch einen ASCII Export von 20GB Integer Matrizen zukommen lassen...

Für Fehlereinbautest bei ARM Prozessoren - einfach mal dezent den Prozessor im Startup im Endian Format umstellen...
 
Gefällt mir: Vril

TCM

Well-Known Member
#92
bridge(4) kann VLAN-Tags und Spanning Tree weiterleiten und ist damit transparenter als ein Monitoring-Port am Switch, wenn das zu analysierende Gerät tatsächlich mit irgendwem reden soll.