|
|
|
|
|
|
|
|
|
|
|
|
|
Jo, hab ich auch grad versucht. Läuft. Das war ja easy 
Erst mal drauf daddeln. Man kann da ja schon ziemlich viel einstellen. Danke!
|
|
|
|
|
|
|
|
|
|
|
|
Auch den Besten läuft mal die Platte voll.
|
|
|
|
|
|
|
|
|
|
|
Wenn ich meine PCIe 4x SFP Netzerkkarte via billiger PCIe x1 -> x16 Risercard an den PCIe x1 Slot des Boards klemme, schmiert mir alle paar Stunden die TRUENas Kiste ab und schickt mir ne Mail mit "unscheduled reboot".
Interessant. 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist gut zu wissen. Obwohl mich die originären X, T und P-Serien interessieren. In den letzten zehn Jahren hat sich sehr viel verbessert, manche Dinge stören mich immer noch oder wieder.
Ich habe mir das Ende vom zugehörigen Thread im Lenovoforum angesehen. Erstmal als Referenz die vollständige Liste aller System von Lenovo mit Zertifizierung für Linux. Da sind die günstigen L-Modelle nicht dabei, die ultramobile X-Serie mit AMD schon. Es gibt auch eigene Zertifizierungen von Red Hat und Ubuntu, wobei ich der von Ubuntu weniger Bedeutung beimesse. ACPI und die DSDT (Beschreibungstabelle) sind ein Standard. Eigentlich sollte eine Zertifizierung nicht notwendig sein, wenn das System IBM-kompatibel und die weiteren Standards (hier die DSDT) ordentlich umgesetzt sind. Meines Wissens nach, orientiert sich Linux an dem was die Firmware untestützt und meldet ein möglichst kompatibles System, meistens ein Windows und seltener Linux.
Wenn man jetzt den letzten Aussagen im Thread folgt, messen die Igenieure der Linuxunterstützung für das L-Modell keine sonderliche Bedeutung zu. Weil? Ist ja nicht zertifiziert für Linux. Der Vorwurf steht im Raum, dass hier die Einträge schlichtweg ausgenullt wurden. Schwierig zu werten.
Das kann ein Argument für zertifizierte Modelle von Lenovo sein oder ein Argument gegen Lenovo generell. Meine persönliche Auffassung ist, dass man als Minderheit keinen Anspruch auf eine Sonderbehandlung (Extrawurst) hat, aber auf eine ordentliche und gleichgestellte Behandlung. Falls das nicht der Fall ist, darf man sich als Minderheit beschweren und wehren. Das ist unabhängig von Linux. Fragt sich nur, ist das schlechte Linuxunterstützung oder schlechte Unterstützung für die L-Serie? Ich tendiere mehr zu letzterem.
// edit
Ich will niemand seine L-Serie madig machen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 22.06.2021 13:10]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Huch, pipewire war mir neu, das kann ja die pulse und jack api - und damit beide Soundserver ersetzen. (solange man jack nicht für Firewire Geräte braucht).
Einsatz bisher unspektakulär
|
|
|
|
|
|
|
|
|
|
|
Pipewire nutze ich seit ca. 2 Monaten.
Ganz selten hat es mal Schluckauf (Hall oder Steam-Beta wollte nimmer), aber im Großen und Ganzen läuft es sehr stabil.
Aber mal eine Frage an die Gnome Nutzer: Wenn ich mich abmelde, dann wird immer "disable-user-extensions" gesetzt und ich muss das via dconf-editor wieder aktivieren.
Bin ich damit alleine?
|
|
|
|
|
|
|
|
|
|
|
Ich habe auch keine Problem mit Pipewire, wünsche mir aber mehr Codecs für Bluetooth. Tut auch mit Steam und CS 1.6 
@GandalfDerPinke:
Bei mir nicht. Ich nutze nur eine Extension (Frippery - Uhr nach rechts oben). Der beste Weg ist wohl Bisecting, Hälfte der Extensions aus und schauen ob es nicht mehr passiert?
|
|
|
|
|
|
|
|
|
|
Boar wie arg es nervt Daten von POSIX/Linux auf Windows/NTFS zu schieben.
Mimimi dein Ordnername darf nicht mit nem Punkt enden
Mimimi da ist ein Leerzeichen hinten dran das darfst du nicht
Mimimi da ist ein Fragezeichen
Mimimi da ist nen Doppelpunkt
Mimimi
MI MI MI
Und leider fehlt Dolphin die Intelligenz zu merken, dass EINVAL bei open/mkdir heißen könnte, dass das Dateisystem da was nicht mag und es daher keine "Ja entfern die Mimimi-Zeichen halt beim Kopieren"-Option gibt.
e: Tarpipe fängt schonmal das Gröbste: tar xf - ... --transform='s/[? *"\\<>]/ /g'
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 30.06.2021 20:09]
|
|
|
|
|
|
|
|
|
Falls mal jemand anderes zufällig auch mal in der Lage sein sollte, über ein separates, schwächliches Gerät (cubietruck), auf dem mpd läuft, um Musik abzuspielen, und gelegentlich aber auch mal was spontan vom Rechner über Lautsprecher abspielen möchte, ohne Kabel umzustecken / zu verlegen / weitere Geräte anzuschaffen, und vielleicht sogar zusätzlich zur Musik was abspielen möchte (z.B. parallel was von mynoise.net laufen lassen)…:
Theoretisch kann pulseaudio über RTP direkt streamen und am anderen Ende empfangen. Das habe ich aber nur in grottiger Qualität hinbekommen, egal mit welchen Settings. Umwege über VLC sind auch an allen Ecken und enden fehlgeschlagen.
Da ich da jetzt länger für gebraucht hätte, als eigentlich angemessen, schreibe ich das hier jetzt mal auf – hilft vielleicht irgendwem, und im Zweifel irgendwann mir selbst wieder, wenn ich danach suche 
Lösung: Pulseaudio => Sink => RTP zu 127.0.0.1 => ffmpeg => transcoden zu mp3 => RTP => remote host (ffmpeg-SDP-file mitgeben) => ffmpeg => pulseaudio.
pulseaudio-rtc wird benötigt. Dann auf dem "Host"-Rechner:
| |
| Code: |
# /etc/pulse/default.pa
load-module module-null-sink sink_name=rtp sink_properties="device.description='RTP'"
load-module module-rtp-send source=rtp.monitor destination_ip=127.0.0.1 port=46998 loop=1
|
|
(pulseaudio neustarten)
| |
| Code: |
ffmpeg \
-i rtp://127.0.0.1:46998 \
-c:a libmp3lame \
-vn \
-f rtp \
-sdp_file whatever.sdp \
"rtp://[ziel-IP]:5004"
|
|
.sdp-Datei auf den Ziel-Rechner schieben.
Dort:
| |
| Code: |
ffplay \
-protocol_whitelist file,rtp,udp \
-nodisp \
-i whatever.sdp
|
|
Von nun an wird alles, was in den RTP-pulseaudio-Sink reinkommt, in angemessener Qualität durch die Gegend gestreamt \o/
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von FuSL am 30.06.2021 20:09]
|
|
|
|
|
|
|
|
|
neovim 0.5.0 ist da, ich installiere es gleich mal - hoffentlich funktioniert alles
// edit
LSP, nvim-lspconfig (CLANGD) und nvim-compe funktionieren 
Ich verabschiede OmniCppComplete in den Ruhestand.
Server ausgefallen, Supermaerke in Schweden geschlossen. Wieso sind Menschen so technikglaeubig? Ich kann mir zwei Gruende ausmalen, es sah billig und bequem aus? Dass die Kassen autark arbeiten ist Grundvoraussetzung. Irgendwas geht nicht und man bucht weiter, Abends schaut man sich die Liste der verkauften Ware an und schickt ein Fax Brieftaube los. Wir wissen ja, dass es Ausfaelle geben wird - nur noch nicht wie oft. Ironischer Weise sind selten Ausfaelle noch schlimmer, weil man sich dann sicher fuehlt. Software wird in der Beziehung zunehmend schlechter, abhaengig von (wenigen) Servern. Ich denke immer mehr so, dass die autarken Clients fuer den Betrieb da sind und die Server zur Synchronisierung. Dann habe ich ein resilientes System, bequeme Nutzung und aktuelle Daten und kann ruhiger Schlafen. Zugegeben - ich habe keinen ruhigen Schlaf, weil es hier nicht so ist 
Fefe hat bei mir schon laenger nicht mehr getroffen, aber dass mit dem Bargeld ist ein sensibler Punkt bei mir. Ist das wirklich so schlimm in Schweden? In der Sparkasse hatten wir (damals) eine Kontokladde* und das habe ich mehrmals verwenden duerfen. Nachdem die Kassenanwendung durch eine Website ersetzt worden ist, war die Kontokladde noch wichtiger. Die Kassenanwendung hat ohne Netz die Kontostaende auch nicht pruefen koennen, aber die Buchungen hinterher wenigstens selbst synchronisiert.
* Excel mit Kugelschreiber
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 04.07.2021 22:43]
|
|
|
|
|
|
|
|
|
Die autarke Funktionsfähigkeit eines automatischen Kassentresors war zu meiner Zeit der Softwareteil mit der höchsten Bugdichte.
Der Teil hat auch zu gerne Doppelbuchungen verursacht. Leider kann ich nicht bewerten, ob die Architektur einfach nur ungeeignet war für einen Mischbetrieb (On- Offline) oder aufgrund der VdS Anforderungen. Da war ich gerade erst fertig mit der Ausbildung.
|
|
|
|
|
|
|
|
|
|
|
Wir haben für einige groooße Retailer als Kunden.
Ich kann euch sagen: Sodom und Gomorra!
Die ganzen Waagen und Kassen sind alles PCs mit Netzwerk. Kaum Updates. Schlechte Wartung. Und für nix ist Geld da.
Ist aber auch ein undankbares Umfeld. Der durchschnittliche Supermarkt hat halt keinen IT-Admin. Mittlerweile laufen da aber soviele IP-Gebundene Systeme.
Z.B. die sog. Durchbedienung an der Fleischtheke: Damit du an Waage 1 dein Hackfleisch wiegen kannst und an Waage 3 den Käse dazu buchst um dann an Waage 4 zu bezahlen. Alles Netzwerkbasiert. Jetzt erklär mal der Fleischereifachverkäuferin was zu tun ist, wenn es einen IP-Konflikt gibt.
Bei vielen Märkten ist ja jetzt noch die Fleischtheke im Kassensystem am Checkout integriert für Plausibilitätsprüfungen (damit leute nicht die Barcode tauschen. Oder damit man mitbekommt: "Heute sind 4kg Spareribs "verkauft" worden, aber nie an der Kasse angekommen).
Dazu kommen dann immer mehr digitale Aufsteller die irgendwelchen kruscht anzeigen/abspielen.
Stundenaktuelle Preisupdates, auf ein Sortiment mit hundertausenden von Produkten mit einer 1.5mbit DSL-Leitung irgendwo im nirgendwo. 
Und jeder der Anbieter auf dem Markt hat natürlich eine eigene, selbstgestrickte magische Lösung. Irgendwann in den 90er entwickelt, mit viel JAVA und XML. Und dann soll Frau Maier an der Kasse einen "mergekonflikt" für Snickers lösen.
Achja, ich sagte ja, sodom und gomorra!
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 05.07.2021 10:32]
|
|
|
|
|
|
|
|
|
|
Ist es nicht meist so, dass es günstiger ist, die IT etwas schleifen zu lassen und die Ausfälle einzukalkulieren anstatt alles mit genügend Leuten auf einem guten Stand zu halten?
|
|
|
|
|
|
|
|
|
|
|
Im Kern ist das dass, was der deutsche Mittelstand so tut: Lieber ne Versicherung gegen den Ausfall abschlißen, als den Ausfall verhindern.
Aber mit den zunehmend handgestrickten Ransomware angriffen auf Companies könnte sich da die Betrachtung verschieben.
Oder zumindest die Versicherung könnte irgendwann sagen: Was? DAS willst du versichern? gtfo!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DeineOmi
Die autarke Funktionsfähigkeit eines automatischen Kassentresors war zu meiner Zeit der Softwareteil mit der höchsten Bugdichte.
Der Teil hat auch zu gerne Doppelbuchungen verursacht. Leider kann ich nicht bewerten, ob die Architektur einfach nur ungeeignet war für einen Mischbetrieb (On- Offline) oder aufgrund der VdS Anforderungen. Da war ich gerade erst fertig mit der Ausbildung.
| |
Hier automatischer Kassentresor mit Java-Applet, als Anwender. Das Ding könnte einen Hassthread im Alleingang füllen. Autark war da aber nichts.
| | Zitat von GH@NDI
Aber mit den zunehmend handgestrickten Ransomware angriffen auf Companies könnte sich da die Betrachtung verschieben.
| |
Ich erwarte ähnliches. Ich erhoffe ähnliches? Falls das für ein Streben hin zu Stabilität führt und nicht zu Gerichtsprozessen.
Wenn Software skaliert (hohe Kunst), lohnt sich jede Verbesserung um so mehr, je häufiger die Software im Einsatz ist. Je kleiner der Softwareeinsatz ist, um so eher kommt man mit einem Problem zu Recht. Der kleine Dorfladen kann einen Quittungsblock von Soennecken verwenden, bei Aldi dürfte ein Problem mit dem internen Filialfunk schon nerven? Und bei Industrieanlagen (BASF) oder Buchungssystemen (Lufthansa) ist es noch kritischer.
Das mit dem Skalieren und verteilten Systemen interessiert mich, sehe und lerne ich hier nicht 
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 05.07.2021 16:06]
|
|
|
|
|
|
|
|
Warum wird man Computer auf einmal langsam?
|
| |
| Code: |
...
[12832.570056] teams[15509]: segfault at 7f34df7fe9d0 ip 00007f34f9ab08a2 sp 00007fff7a73aac0 error 4 in libpthread-2.31.so[7f34f9aad000+10000]
...
[20533.537520] Out of memory: Killed process 17861 (_Postman) total-vm:8825960kB, anon-rss:3263400kB, file-rss:0kB, shmem-rss:3876kB, UID:1000 pgtables:8628kB oom_score_adj:0
...
|
|
Der Zentralrat der Linuxanwender ist empört.
|
|
|
|
|
|
|
|
|
|
|
Irgendwie verstehe ich lm_sensors noch nicht so ganz.
Ich will meine NVME Sensoren rauswerfen, aber das will einfach nicht.
Ich leg ne *.conf in /etc/sensors.d/ an und schreibe folgendes rein:
| |
| Code: |
chip "nvme-pci-*"
ignore "Composite"
ignore "Sensor 1"
ignore "Sensor 2"
ignore "Sensor 5" |
|
Das frisst er aber nicht und ich habe keine Ahnung warum. Auch ist mir nicht ganz klar wo sensors-detect seine Ergebnisse reinschreibt.
|
|
|
|
|
|
|
|
|
|
|
Ich brauche ein Programm von dem ich hoffte, es niemals brauchen zu müssen. Ich hab hier ein XSD-Schema für ein absurd großes XML-Dokument und ich möchte es mir halbwegs übersichtlich visuell darstellen lassen. Eigentlich würde ich mir auch gerne Beispieldokumente generieren lassen, aber das wäre ein Premium-Feature.
"xsd diagram" kann das XSD nicht laden und QXmlEdit ist unübersichtlich und bringt mir nix
Gibt es da ne gute Alternative? Von mir aus auch für Geld, so lange es auf Linux läuft. Bezahlt ja eh der Arbeitgeber.
|
|
|
|
|
|
|
|
|
|
|
Vielleicht weiß jemand bei der Konkurrenz eine Software für dich?
Mal eine Frage:
Seit einem Systemupgrade haben wir das Problem, dass der Tomcat-Server nicht mehr hochfährt, wenn jemand ein Filehandle auf catalina.out offen hat hat. Zum Beispiel less oder tail -f. Woran kann das liegen? Ich habe schon nachgeschaut, es ist definitiv kein Windows
|
|
|
|
|
|
|
|
|
|
|
Die Altova-Produkte sind für alles, was mit XML zu tun hat ziemlich nice.
Sind aber meines Wissens alles nur Windows kompatible Programme.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DeineOmi
Die Altova-Produkte sind für alles, was mit XML zu tun hat ziemlich nice.
Sind aber meines Wissens alles nur Windows kompatible Programme.
| |
Dann werd ich mal die Testversion von XMLSpy unter Wine probieren. Vielleicht tut das ja.
Ansich sieht das Programm schon mal sehr geil aus.
|
|
|
|
|
|
|
|
|
|
|
Args, vielleicht hat hier wer ne Idee:
Hab 3 Racks in unterschiedlichen DCs/ISPs mit jeweils einer Linux Kiste als firewall drin, zu 99% identisch.
Alle 0.5 - 2 Tage stellen wir partielle Netzwerk Outages für 10 - 20 Minuten fest.
Konnten das bisher auf 2 der 3 Kisten feststellen. Diese 2 erhalten den großteil des Netzwerk Traffics (~ halbes gbit/s jeweils).
Die Outage lässt sich per (normalem) ping oder mtr nicht feststellen.
DBs und co verrecken aber natürlich.
Wir konnten das ganze synthetisch nur reproduzieren, in dem wir ein ping mit einer großen Paketsize abfeuern aka ping -s 1500 1.1.1.1 (ohne dont fragment flag).
Hier taucht dann während der Outages ein massiver loss auf, außerhalb der outages alles ez und tut.
Wir stellen auch fest, dass das monitoring was auf der FW läuft und die internen Kisten hinter der FW health-check-pollt timeouts reported.
Heißt alle interfaces sind von der Outage betroffen, nicht nur das public interface.
Haben Probleme beim ISP auch nochmal explizit ausgeschlossen, ein raspi der direkt am upstream hängt hat diese Outages nicht.
Heute dann noch zufällig im genau richtigen Moment ein tcpdump am laufen gehabt und gesehen, dass da während mein ping command sagt dass Pakete verloren gehen, im tcpdump die Pakete alle schön angezeigt werden, in sowie out.
Heißt der Traffic kommt tatsächlich an der Kiste an, wird aber vom Kernel verworfen und nicht ins userland weitergeleitet.
Erste Idee, irgendne fancy iptables rule dreht frei, hab überall logging hinzugefügt und deaktiviert was nicht zwingend notwendig ist, aber nix nada, keine unserer rules droppen das.
/proc/net/softnet_stat reported nix an Fehlern.
Conntrack loggt nix, /proc/sys/net/netfilter/nf_conntrack_count ist auch noch weit unter dem max.
GRO ist bereits disabled (die e1000 fw ist wohl buggy... yay...)
Load mäßig langweilt sich die Kiste auch, definitiv nicht an der Grenze.
Kernellog reported auch nix, kein flapping NIC oder sonst irgendwas
No comprende. Ich check nicht, wieso die Pakete da gedroppt werden.
Jemand ne Idee wie man das weiter debuggen kann? Oder was das ggf sein kann?
|
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von FreeHawk* am 09.07.2021 1:01]
|
|
|
|
|
|
|
|
|
|
Laufen evtl Buffer voll? Man kann die Größen per sysctl einstellen, evtl sind da zu niedrige Werte gesetzt. Kann morgen mal schauen, an welchen du konkret drehen könntest. Hab sowas auch schon Mal gejagt, allerdings auf embedded Geräten mit wenig ram.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Schau dir mal folgendes an:
vm.min_free_kbytes
net.core.rmem_max
net.core.wmem_max
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
net.ipv4.ucp_rmem
net.ipv4.ucp_wmem
Wir hatten auf einem unserer Geräte ebenfalls recht zufällig wirkende Paketdrops bei ~600MBit Ethernet-Traffic, das haben wir in den Griff bekommen, indem wir die Werte dort recht großzügig hochgeschraubt haben. Rauszufinden, welche Werte für welchen Anwenungsfall ideal sind, ist scheinbar ein beliebtes Hobby bei Netzadmins. Vielleicht drehst du einfach mal mit dem Holzhammer um Faktor 10 (oder so) hoch und schaust, ob's überhaupt was nützt.
|
|
|
|
|
|
|
|
|
|
|
Merci, die hatten wir schon.
Ham jetzt nach und nach alles mögliche an flags angepasst...
Turns out: tc macht default mäßig magie und droppt pakete wenn spikes und spikes > txqueuelength vom interface...
Dann gibts nochmal ein max_backlog sysctl der ebenso dafür sorgen kann...
und ipfrag_thresh sowie max_dist die wohl auch gern dazu führen, wenn Mars und Venus in der richtigen Konstellation stehen dass fragmentierter Traffic gedroppt wird, because why not.
Was ein ekliger scheiß hey. Kann man schon mal n paar Tage lang debuggen bis man den richtigen, magischen parameter findet.... brrrr
|
|
|
|
|
|
|
|
|
|
|
Die neuen ThinkPads sind nicht wirklich verfügbar.
Bei Lenovo Deutschland sind es "Notebooks" und da bekommt man nur ein X13 Gen2 mit Intel und lächerlichen 8 GB Hauptspeicher, keine Modifikationen möglich. Keine AMD-Modelle. In Amerika sind es "Laptops" und man darf zumindest zwischen verschiedenen X13 Gen2 mit Intel auswählen, höchstens aber 16 GB Hauptspeicher. Als AMD-Modelle gibt es ein altes X13 Gen1 oder sogar ein X395.
Marktstart für die Intel Tigerlake war April und für AMD 5xxx im Mai. Meno
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
