|
|
|
|
|
|
|
| | B0rG*
An nem schweineteuren Ultrawide funktioniert der Audio-Ausgang bestimmt auch besser! | |
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von KingGinord am 18.02.2021 11:14]
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Ich habe ja einfach einen USB DAC. Bitte, habe gerne geholfen, und grüsse die Mama von Statixx.
| |
Irgendwie hast du damit tatsächlich vielleicht ein bisschen geholfen. Bin bisher nicht auf die Idee gekommen, obwohl son Teil eh schon am Headset hängt  Grüße hiermit auch statixx Mom.
|
|
|
|
|
|
|
|
|
|
|
|
Richt ich aus, sie freut sich sicher!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
An nem schweineteuren Ultrawide funktioniert der Audio-Ausgang bestimmt auch besser!
| |
Selbstverständlich!
| | Zitat von MartiniMoe
| | Zitat von SwissBushIndian
Ich habe ja einfach einen USB DAC. Bitte, habe gerne geholfen, und grüsse die Mama von Statixx.
| |
Irgendwie hast du damit tatsächlich vielleicht ein bisschen geholfen. Bin bisher nicht auf die Idee gekommen, obwohl son Teil eh schon am Headset hängt Grüße hiermit auch statixx Mom.
| |
Unerwartete Wendung
|
|
|
|
|
|
|
|
|
|
HÄTT ICH BLOSS DEN GRÖSSEREN GENOMMEN! 
Äh, ne. Geiles Ding. Jede Menge Platz, weniger Kabel auf dem Schreibtisch, Wechsel zwischen Laptop und Desktop funktioniert super, Bild sieht auf den ersten Blick auch spitze aus. Und das Beste: Endlich vernünftige Auflösung vom Laptop aus! Würd ich wieder kaufen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von statixx am 19.02.2021 15:23]
|
|
|
|
|
|
|
|
|
|
Kein tilieren, keine competition.
|
|
|
|
|
|
|
|
|
|
|
|
Genehmigt. Ist die Kabelverwaltung von Fatty so abgenommen worden?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 19.02.2021 16:13]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Kein tilieren, keine competition.
| |
War da, tat es. Mir reicht tatsächlich das schmalspurtiling von KDE ziemlich gut, für Terminals nehm ich bei bedarf noch tmux/byobu dazu. Mal sehen ob das mit dem breiten display so bleibt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
| | Zitat von Oli
Kein tilieren, keine competition.
| |
War da, tat es. Mir reicht tatsächlich das schmalspurtiling von KDE ziemlich gut, für Terminals nehm ich bei bedarf noch tmux/byobu dazu. Mal sehen ob das mit dem breiten display so bleibt.
| |
Jetzt muss nur noch Stadia UWQHD unterstützen. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von DeineOmi am 19.02.2021 16:47]
|
|
|
|
|
|
|
|
|
Sagtmal, was für dunkle Magie passiert eigentlich wenn eine TLS1.3 Session abläuft?
Hatten hier ewig das Issue, dass wir ein nginx-ingress reverse proxy haben der ssl passthrough auf ein anderen nginx macht der dann schlussendlich das ssl terminiert. Der letzte macht dann auch den ssl session Voodoo.
Jetzt haben einige User das Problem gehabt, dass sie nach 10 Minuten http polling für genau 2 requests ein "Jo, diggi, ssl cert passt nicht"-Fehler bekommen haben.
Lag dann daran, dass der reverse proxy den sni nicht erkannt hat, und entsprechend mit seinem cert versucht hat zu terminieren, wat halt nicht passt.
Stellt sich raus, die Dudes die das affected, sind nur diejenigen die TLS1.3 nutzen, und der ganze shit tritt nicht mehr auf, wenn man ssl session cache/tokens komplett deaktiviert.
Code vom ingress sagt generell: "Ich lese erstmal die ersten max 4096 bytes die kommen, und checke dann ob ich ein SNI dadrin finde, und leite dann entsprechend weiter"
Passiert da irgendein magischer ninja Handshake um die Session zu renewen und die Clienten schicken da dann nicht (in den ersten 4096 bytes) den SNI mit? Wtf is dis shit Oo
|
|
|
|
|
|
|
|
|
|
|
mal nachgeschaut was die clients so als SNI schicken?
da scheint sich was geändert zu haben?
|
|
|
|
|
|
|
|
|
|
|
|
Uh, interesting, ich jags mal durchn wireshark.
|
|
|
|
|
|
|
|
|
|
|
Hallo zusammen,
Ich hab da mal ne Frage.
Ich hab nen Datensatz (Inhalt ist erstmal egal) mit herrlich unschönen Namen für die Messungen:
| |
| Code: |
[1] "Participant" "Activity" "tBodyAcc.mean...X" "tBodyAcc.mean...Y"
[5] "tBodyAcc.mean...Z" "tGravityAcc.mean...X" "tGravityAcc.mean...Y" "tGravityAcc.mean...Z"
[9] "tBodyAccJerk.mean...X" "tBodyAccJerk.mean...Y"
|
|
Nach ein bisschen aufräumen sieht es so aus:
| |
| Code: |
[1] "Participant" "Activity" "TimeBodyAcceleration.Mean.X"
[4] "TimeBodyAcceleration.Mean.Y" "TimeBodyAcceleration.Mean.Z" "TimeGravityAcceleration.Mean.X"
[7] "TimeGravityAcceleration.Mean.Y" "TimeGravityAcceleration.Mean.Z" "TimeBodyAccelerationJerk.Mean.X"
[10] "TimeBodyAccelerationJerk.Mean.Y"
|
|
Gefällt mir auch noch nicht wirklich. Ist zwar lesbarer aber nicht so hübsch.
Wie würdet ihr da rangehen?
Acid
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von AcidPils am 21.02.2021 17:10]
|
|
|
|
|
|
|
|
|
Hat von euch jemand mit Kubernetes zu tun?
Ich möchte mich da gern für zukünftige Projekte einarbeiten. Habt ihr Tipps zu Tutorials, Resourcen, Büchern oder vielleicht sogar brauchbaren Schulungen? Darf auch ruhig kosten, wenn es empfehlenswert ist. Die offiziellen Tutorials auf kubernetes.io sind bekannt und hab ich durch.
Ich möchte gerne zukünftig Projekte in dem Bereich machen, habe aber aktuell keinen konkreten Anwendungsfall. Habt ihr einen Tipp oder ne Idee, wie ich da zunächst vorgehen könnte um trotzdem irgendwas einigermaßen sinnvolles über mehrere Nodes und Pods laufen zu lassen zum lernen? 
Generell fehlt mir gerade ein bisschen die Idee, wie ich das lernen kann ohne konkretes Kundenprojekt und ich möchte aber kein konkretes Kundenprojekt durchführen, ohne es einigermaßen gelernt zu haben vorher... Weitere Hetzner Kiste anmieten und das ganze private Cloudgeraffel mit Kubernetes hosten? 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von MartiniMoe
Hat von euch jemand mit Kubernetes zu tun? | |
nö.
aber man kann ja nie zuwenig ahnung haben um nicht doch ein paar gut gemteinte tipps dazulassen 
soviel mal als disclaimer.
soweit ich das bisher gesehen hab kann man z.b. mit "k8s, the hard way" https://github.com/kelseyhightower/kubernetes-the-hard-way ganz gut mal lernen wie das ding aufgebaut ist.
ansonsten zum direkt loslegen und spielen eignen sich vielleicht auch direkt mal k3s.io und microk8s.io
das wars aber schon für mich.
|
|
|
|
|
|
|
|
|
|
|
Hab ein Jahr k8s consultant gespielt und Schulungen gegeben, darf das original material nicht raushauen, hab aber ne "light version" von der k8s for devs schulung in form von slides + nem github repo was ich dir sonst morgen mal rauskramen kann.
Für den Schulungsshizzle meistens GKE genutzt, wenn du aber Interesse hast nicht nur den "dev" sondern auch infra/ops Part von k8s zu übernehmen, würde ich stark empfehlen einfach mal 2, 3 billige Kisten zu mieten und das ganze einfach mal aufzusetzen und dann einfach mal n büsschen Software von der Stange drauf laufen zu lassen und auch eigenen Stuff mal in ein helm chart zu gießen und drauf laufen zu lassen.
Da stolperst du dann relativ schnell in die ganzen Detailprobleme.
Allerdings fair warning: Storage & Loadbalancing sind etwas pain wenn du nicht auf nem cloudprovider läufst. Storage würd ich openebs empfehlen, lb würd ich erstmal außen vor lassen und deine svcs per NodePort exportieren.
Ansonsten prinzipiell ist die offizielle k8s doku schon gar nicht mal so kacke um halbwegs ins Thema zu kommen.
|
|
|
|
|
|
|
|
|
|
|
Geil, danke euch! Da sind schon mal viele wertvolle Informationen für mich dabei.
Was wäre denn überhaupt der "dev" part von k8s außer die eigene Software in ein helm chart zu gießen und dann zu deployen und exposen? Ich dachte schon an den ops part 
// Wenn du die light sachen morgen rauskramen könntest wäre ich dir dankbar
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von MartiniMoe am 21.02.2021 19:38]
|
|
|
|
|
|
|
|
|
Joar, das ist grob auch die dev Sicht.
"In ein Helm Chart zu gießen" ist halt schon simpel ausgedrückt
Weils halt nicht mehr nur das klassische "ich hacke einen service, schreib ein Dockerfile und der DB Guy kümmert sich um die DB und der Ops Guy kümmert sich um Server & Configs und der BI Studi macht das Dashboard" ist, sondern der ganze Stuff schön abstrahiert wird und in der Verantwortung der Devs liegt - zumindest idealerweise.
Ist halt einmal das grobe understanding von der Architektur, wofür so die einzelnen (standard) Resourcen gut sind, und noch so die kubectl/helm basics um mal n portforward zu legen oder abzuchecken warum der Service eigentlich gerade crasht.
Je nach dem was dann noch für operatoren auf dem Cluster laufen haste da dann auch noch viele CRDs.
Bei uns definieren die Jungs und Mädels ihre gesamte Infrastruktur in den Charts.
Ingresse, Storage, Datenbanken, Cronjobs, Monitoring, Dashboards, Alerts, u name it.
Für den Ops Part hab ich leider keine slides die ich rausgeben kann :/
Wenn du konkrete Fragen hast kann ich dir da aber gern versuchen weiterzuhelfen.
Prinzipiell variiert der Ops Part ziemlich abhängig von Fully Managed(e.g. GKE/EKS/..)/Cloud Provider VMs/onprem.
Bei den großen Providern kriegste das meiste halt von der Stange, etcd ist schon HA, storage wird dir von ebs und co abgenommen, backups ebenso, logging & monitoring haste teilweise auch direkt onboard Lösungen und wenn du full cloud maniac gehst nimmste auch die cloud Datenbanken und Co.
Heißt effektiv biste da als Ops guy maximal Berechtigungen am einrichten, n büsschen configs zusammen kleben und hier und da mal irgendein fancy operator am installieren. Und halt händchenhalten für die Devs.
On prem sieht die Chose dann wieder etwas anders aus, denn der ganze k8s stuff besteht aus wesentlich mehr Abstraktionen als Implementationen, heißt hier darfste dich dann erstmal an den ganzen Komponenten austoben.
Also, wenn du die Basis Konzepte schon drauf hast, würd ich dir einfach mal empfehlen n paar billo Kisten bei Hetzner zu schießen und dir einfach mal ein Cluster mit mehreren Nodes aufzusetzen und so den standard Kram einzurichten.
CNI & CSI Plugins aufsetzen, ingress controller, efk, prometheus stack, backups, etc.
Und dann einfach mal irgendne stupide Gästebuch App mit ner HA Datenbank oder so deployen und feststellen, dass die logs scheiße aussehen, dein Logging 10 Minuten hinterher hängt da auf HDDs unendlich viel contention ist, etc.
Anschließend mal lustig auf irgendwelchen Kisten die stöpsel ziehen, checken ob der HA stuff wirklich tut, und ggf mal ne Runde Disaster Recovery nachspielen, kriegste wirklich dein Cluster ohne Probleme aus nem Backup restored?
Anschließend vielleicht nochmal n büsschen in den ganzen RBAC shizzle und in den Security Shizzle einlesen und den stuff nachspielen und falls du n richtig krasser Typ bist, mal for the lulz ein k8s controller mit eigenen CRDs hacken.
und dann haste da eigentlich auch schon ein tieferes Wissen als 90% der Branche.
|
|
|
|
|
|
|
|
|
|
|
Puh. Was ist anstrengender, kubernetes oder JavaScript front-end Entwicklung?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 21.02.2021 21:52]
|
|
|
|
|
|
|
|
|
javascript frontened! ohne das andere jemals gemacht zu haben.
aber das npm ökosystem ist die traurigste hölle die mir in den letzten 20 jahren untergekommen ist.
z.b. werd ich _nie_ wieder ne library nehmen um jsonrpc calls zu machen. nur noch dieses fucken einfache protokoll einfach direkt selber implementieren.
von dem grundsätzlichen fuckup der dort stattfindet reden wir.
|
|
|
|
|
|
|
|
|
|
|
den _einzigen_ vorteil den ich da bei den dingern seh ist dass promises, die schon ewig vorhanden sind nahtlos mit async/await verwendet werden können, das haste bei z.b. python nicht und dass npm, trotz der horrorstories von einfach _allem_, z.b. sowas simples wie ne package-lock.json das kryptographisch mit hashes externe dependencies absichert. d.h. wenn du die einmal gecheckt hast kannste dir sicher sein dass das auch in zukufnt passt, trotz externer quelle. bei pip such ich die möglichkeit immer noch ohne mich zu verrenken (soll irgendwie gehen, weiss jemand wie?)
nichts desto trotz haste bei javascript eh direkt wieder verloren, ein "hello-world" in angular implementitiert hat das letzte mal als ich nachgezählt hab 913(!) externe dependencies reingezogen. 913(!), ich muss es nochmal schreiben.
ich glaub das hab ich bei meinem fettesten python projekt noch nicht einmal in die größenordnung geschafft...
e: jaja, in reactive js nimmt man eh keine promises mehr sondern macht alles mit observables, aber das ist ja der gleiche wein in anderen schläuchen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [KdM]MrDeath am 21.02.2021 22:05]
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Puh. Was ist anstrengender, kubernetes oder JavaScript front-end Entwicklung?
| |
Seien wir ehrlich verteilte, fehlertolerante Systeme die 30 Jahre IT Entwicklung abstrahieren wolllen sind nicht unbedingt trivial, aber wesentlich weniger pain als 2021 versuchen zu wollen ne Webseite mit JS zu bauen...
Außerdem bietet das eine Feld idR entsprechende Goldbarren um sich die Tränen aus dem Gesicht zu wischen
/e: bei pip gabs auch iwie .lock files, kann aber auch sein dass das durch nochmal ein separates tool kommt.
/e2: ah nevermind, das kam von pipenv
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von FreeHawk* am 21.02.2021 22:12]
|
|
|
|
|
|
|
|
|
Aber dann mit wireshark irgendwelche issues debuggen, die wegen nginx hinter nginx auftreten.
Goldbarren sind natürlich ein gutes Argument.
|
|
|
|
|
|
|
|
|
|
|
Fair Point
Ist halt übelstes Gaffa um da ein Kunden happy zu machen, SaaS in der Versicherungsbranche ist purer Hass.
Da haste dann so java enterprise https Clienten die einfach noch aus den 90ern sind und keine elliptic curves können, denkste dir gut, machste halt RSA mit safen algos, und killst damit kompatiblität zu 20% der Endkunden Devices die entweder sicheres ecdsa können oder nur unsichere kaputte RSA Algos.
Und der erste nginx mag keine hybriden Certs, insofern musste man da etwas kreativer werden
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
nichts desto trotz haste bei javascript eh direkt wieder verloren, ein "hello-world" in angular implementitiert hat das letzte mal als ich nachgezählt hab 913(!) externe dependencies reingezogen. 913(!), ich muss es nochmal schreiben.
| |
Ich muss momentan auch was mit JS machen, und hab die Gelegenheit genutzt, um mich endlich mal mit Rails 6 + Webpacker + Stimulus.js auseinanderzusetzen.
Mit Stimulus.js ist es tatsächlich das erste mal seit langer Zeit so, dass ich was mit JS machen muss und nicht nur am Weinen bin. Stimulus.js selbst ist relativ schmal (zieht selbst nur 3 deps, mit webpack sind's dann 62 – aber das zählt natürlich nicht wirklich; wenn man 'n frisches Rails aufsetzt mit stimulus hat man muntere 705 JS dependencies + 76 gems) bzw. bietet ein schmales "Konzept": man hat Controller, spezifische data-attributes für zur DOM-Verbindung und die ganzen onload/ready-events schon übernommen – und sonst erstmal nicht viel mehr.
Ändert überhaupt nichts an der Grundaussage zu npm, pip/pypi, rubygems & Co., aber ich wollte unbedingt mal mitteilen, dass ich Stimulus.js überraschend angenehm finde
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
den _einzigen_ vorteil den ich da bei den dingern seh ist dass promises, die schon ewig vorhanden sind nahtlos mit async/await verwendet werden können, das haste bei z.b. python nicht und dass npm, trotz der horrorstories von einfach _allem_, z.b. sowas simples wie ne package-lock.json das kryptographisch mit hashes externe dependencies absichert. d.h. wenn du die einmal gecheckt hast kannste dir sicher sein dass das auch in zukufnt passt, trotz externer quelle. bei pip such ich die möglichkeit immer noch ohne mich zu verrenken (soll irgendwie gehen, weiss jemand wie?)
| |
Du willst Poetry verwenden. Ist pip-kompatibel. Beschdes Tool das es im Python-Universum in der letzten Zeit so gegeben hat.
|
|
|
|
|
|
|
|
|
|
|
danke für den hinweis, kommt direkt mal auf die liste.
aber das ist halt so ein abzug. ich erwarte dass sowas heutzutage minimalster standard ist.
pip muss das können.
ja pipenv hab ich auch schon benutzt, aber der author reitet ja sowas von drauf rum dass das nur zur entwicklung gedacht ist. auch wenn die meisten seiner benutzer es eben nicht dafür benutzen.
|
|
|
|
|
|
|
|
|
|
|
|
Kennt jemand einen selfhosted Chat, wo ich ohne account im Browser auf domain.com/raumname gehen kann, dann kann man dort chatten und wenn alle raus sind wird alles reseted? Also Chaträume im Browser die wie Jitsi Räume funktionieren, aber halt Text only
|
|
|
|
|
|
|
|
|
|
|
|
[[ jedes websocket Tutorial ]]
|
|
|
|
|
|
|
|
|
|
|
Hab tatsächlich schon überlegt das 'schnell' selbst zusammen zu hacken... aber so wichtig ist es mir dann auch nicht.
https://github.com/hack-chat/main sieht recht brauchbar aus
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
