|
|
|
|
|
|
|
Ich nerde egtl auch hauptberuflich mit Linux rum, aber verstehe hier auch nur 1%  
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Apropos Basics, die nicht funktionieren, macOS ist wohl das einzige Betriebssystem, dass Farbmanagement auf eine nicht völlig dämliche Weise macht, weil in macOS Quartz, also der Compositor, das macht. Und man halt einfach seine Surfaces mit dem entsprechenden Farbraum taggt und das gesamte GUI mit drei fucking Zeilen Code funktionierendes Farbmanagement hat. Komisch wie nah die macOS API an rats' naive Vorstellung von vor ein paar Wochen ist, dass man doch eigentlich nur seinen Framebuffer/Surface mit nem Colorspace taggen müsste und dann kann das System ez pz für eine korrekte Darstellung sorgen.
| |
Sind damit denn noch unterschiedliche rendering intents möglich?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | Zitat von hoschi
Ich bin mir nicht sicher bezüglich des Triple Bufferung. Triple Buffering glättet die Darstellung und verhindert Tearing, mit dem Nebeneffekt der höhere spürbaren Latenz (schwammiges Gefühl in Shootern). Der Hintergrund ist aber wohl, dass sie die Firmware oder Treiber mit Triple Buffering - bei Bedarf - in ein höheren Leistungsmodus bringen wollen (wohl mit IDLE, PRESENTING_MAX und PRESENTING gemeint) und eine flüssige Darstellung zu garantieren. Das dürfte eine der vielen kleinen Optimierungen sein, die spezielle angepasste Treiber unter Windows mitbringen.
| |
Ne
| |
Interpretiere ich es richtig, dass dein "Ne" sich auf das schwammige Gefühl in Shootern bezieht? Weil Triple Buffering nicht der unglücklichen bzw. falschen Implementierung aus Fall 3 entsprechen und kein schwammiges Gefühl verursachen sollte:
Fall 3:
+------------------------------------->-------------------------------------+
| Flips mit VSync |
| |
| +-----------+ +----------+ +-----------+ |
| | | | | | | |
+----+ Front | <-----------+ | | <-----------+ | Back | <-+
| | | | | |
+-----------+ +----------+ +-----------+
Ich habe mir Triple Buffering immer so vorgestellt, wie von Dir im Fall 2 beschrieben. So etwas habe ich immer als Triple Buffering erwartet, wenn ich in CS oder Quake den passenden Haken gesetzt habe:
+------------+
| |
| Renderer |
| |
+------+-----+
|
+--------v-------+
| |
| |
+-----------+ +-----v-----+ +-----v----+
| | | | | |
| Front | | Back | | Back |
| | | | | |
+-----+-----+ +-----------+ +----------+
^
| + +
| | |
| | Frischester Back|
| | Buffer wird zum |
| | VSync geflippt |
| | |
+--------------------------+<----------------+
Wenn ich deine Erklärung richtig verstanden habe und meine Erfahrung mit den Spielen dazu nehme, habe ich aber immer nur Fall 2.
Jetzt zu GNOME:
Sie haben wir wohl als Grundlage nur Fall 3 als Triple Buffering mit höheren Latenzen. Jetzt kommt die extra Arbeit von den Mutter Entwicklern dazu um sich Fall 2 wengistens anzunähern?
|
|
[Dieser Beitrag wurde 7 mal editiert; zum letzten Mal von hoschi am 10.09.2020 11:46]
|
|
|
|
|
|
|
|
|
| | Zitat von Farbkuh
Mal aus Neugier: ihr macht das vorwiegend hauptberuflich oder? Also nerden meine ich
| |
Schon, ja. Beruflich wäre ich am liebsten meist beim Umflippen von Bits mit Stift und Papier, die Praxis weicht mit hoher Schwankgsbreite ab.
Hier berührt sich dann Freizeit und Beruf.
|
|
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 13.09.2020 20:48]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ach, komm. Gib nach und schreibe 
|
|
|
|
|
|
|
|
|
|
|
flasks langer weg zu async/await support uff. die tun sich damit echt schwerer als ich gedacht hätte.
seh ich da was nicht oder ist flask technologisch wirklich so weit hinten dran? das ganze ding ist wenn man nur einen thread hat blocking, und wenn man parallele requests will braucht man mehrere threads. willkommen im letzten jahrzent.
es sagt zwar jemand dass es auch ohne ginge aber labert direkt was von race conditions.
seh ich da nen dritten weg (den von flask) nicht?
e: kurzum: was nimmt man heutzutage als nettes serverseitiges framework in python so? aiohttp sonst nichts?
tornado hab ich vor langer zeit geliebet, aber das ist ja auch pre async/await zeit.
wird wohl auf connexion mit aiohttp rauslaufen?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 14.09.2020 22:32]
|
|
|
|
|
|
|
|
|
Es gibt gleich zwei "Flask-but-async"-Projekte: https://github.com/vibora-io/vibora und https://gitlab.com/pgjones/quart
Keine Empfehlung, nie benutzt, ist nur gerade als erstes aus der Suche gefallen.
Aber fwiw, ich hatte nie das Gefühl, dass modulare Webapps sonderlich toll funktionieren (sei es Django Apps oder Flask Blueprints). Und mit dem Hang zu Microservices kann man die Dinge, die man sonst als gegenseitig abhängige Apps o.ä. schreiben würde, ja eifnach als gegeinander abhängige Microservices schreiben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 14.09.2020 23:32]
|
|
|
|
|
|
|
|
|
ja.
für "grössere" dinge geh ich auch gerne direkt auf serverseitig api, client dann js/typescript usw (in form von bootstrapVue/angular/react, letzeres aber noch nie benutzt).
das ist aber automatisch auch direkt wieder aufwand und ich würd mal gern wieder was leichteres ausprobieren, sprich die "alte" variante von serverseitiges rendering und dann wird direkt html ausgeliefert. einfach weils mir grade nach wesentlich weniger aufwand für ne simple aufgabe ausschaut. nen /api endpoint kann man ja immer noch einbauen, kost ja nicht viel wenns intern richtig strukturiert ist.
|
|
|
|
|
|
|
|
|
|
|
Was nutzt ihr so für Stacks für Application Logs?
Auch nach mehreren Jahren werde ich nicht mit ELK/EFK warm.
Gefällt mir so null. Frisst unendlich viel ram und ist so semi stabil.
Und dazu noch mega unhandlich.
Es reicht dass irgendeine App mal ein timestamp statt dem exakt definierten Timestring loggt und Kibana macht kein Schritt mehr bis man manuell irgendwelche fucking Queries gegen die elastische Lucy abfeuert um das schema zu reparieren weil mimimi type mismatcht.
Dann fixte die Kacke, schauste dir in Kibana logs an, versuchst n Flow zu rekonstruieren drückst 3 mal Load Moar und dann ist der button ausgegraut und du musst die query anpassen um weitere Daten angezeigt zu bekommen (maximum kannste natürlich hochschrauben... halt analog zum mem in der Kiste).
Structlogging + voll indexierte Logs sollten eigentlich richtig geil sein, aber in der Handhabe sind n paar grep calls immernoch einfacherer und genauer :/
Scheint iwie keine große Alternative zur Lucy zu geben die halbwegs supported ist und für mehr als embedding in ne bestehende App gedacht ist, oder kennt ihr da was?
|
|
|
|
|
|
|
|
|
|
|
lehn ich mich mal aus dem fenster, kann gut sein dass du sagst "kenn ihc, das ist doch das gleiche/teil vom ELK stack". wat is mit graylog?
sah auf den ersten blick ganz nett aus, muss aber sagen solche fehler wie du sie beschreibst auch noch nicht gehabt, was denke ich eher am mangelnden breiten einsatz liegt.
ist übrigens mal wieder ein sehr gutes beispiel: "your database may not care about schemas, your application does"...
|
|
|
|
|
|
|
|
|
|
|
Graylog noch nicht im produktiven Einsatz gehabt, falls du da Geschichten vom Krieg hast - immer her damit! 
Sieht auf dem ersten Blick ziemlich aufjedenfall ziemlich ähnlich aus.
|
|
|
|
|
|
|
|
|
|
|
Die Frage ist, ob deine probleme eher kibana zuzuschreiben sind und elastic eigentlich doch ganz ok ist.
Interessiert mich, das Thema, sag mal bescheid was du noch so ausprobierst.
|
|
|
|
|
|
|
|
|
|
|
Azure Insights 
|
|
|
|
|
|
|
|
|
|
|
Wir haben schon länger einen Graylog im Einsatz. Allerdings ist das Projekt bisher noch in der DevPhase, also eher so ~2000 HTTP-Requests pro Tag die wir loggen.
An sich funktioniert Graylog gut, sofern du unproblematisch im GELF-Format loggen kannst. Was mich fürchterlich an Graylog nervt, ist die fehlende "drill down" Möglichkeit. Ich würde gerne z.B. auf das "CorrelationID" Feld klicken und in einem neuen Tab alle ergebnisse für diesen Filter sehen. Tatsächlich hängt Graylog beim Klick auf das Feld dann diese Bedingung nur an die evtl. schon vorhandene an. Das ist dann bei so Szenarios wie: "Zeig mir mal alle 500 StatusCodes und jetzt schauen wir uns diesen ganzen Request an" ziemlich nervig im Graylog.
Was ich mir die letzten Tage angschaut habe, war Seq. Eigentlich also lokale Container-Lösung um logs aus verschiedenen Containern während der Entwicklung zu sammeln. Muss aber sagen, dass es mir rein von der Oberfläche deutlich besser gefallen hat als Graylog. Graylog ist doch irgendwie ewas altbacken. Ich habe aber keine Ahnung wie gut Seq langfristig skaliert.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von GH@NDI am 16.09.2020 8:24]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
oh, nice.
|
|
|
|
|
|
|
|
|
|
|
Hach, AV.  Mit dem EICAR-Teststring hat mein Opa ja schon im IRC gedrollt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Scherzfrage
|
|
Woran erkennt man, dass man kurz vor oder nach dem Release ist?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Leider falsch. Nächster (Versuch).
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 24.09.2020 12:08]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Woran erkennt man, dass man kurz vor oder nach dem Release ist?
| |
"push it directly to master!"
|
|
|
|
|
|
|
|
|
|
|
|
Ich löse auf. Jede Commit Message enthält das Wort 'revert'
|
|
|
|
|
|
|
|
|
|
|
uhh da haben wir auch so spezialisten.
ganz gut sind die leute die "ein feature" über mehrere komponenten verteilen und das dann nur an ein paar stellen davon deaktivieren.
|
|
|
|
|
|
|
|
|
|
|
Die DTAG hatte wohl gerade einen kleinen Schluckauf:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 62.155.243.7 icmp_seq=1 Destination Net Unreachable
getaddrinfo(whois.ripe.net): Temporary failure in name resolution
(Mein DNS geht über die Root-Server)
62.155.243.7 ist wohl ein Router im DTAG-Netz:
inetnum: 62.155.128.0 - 62.155.247.255
netname: DTAG-DIAL10
Jetzt geht es anscheinend über einen anderen Router (einer ausm DTAG-DIAL13-Netz).
Hab da ja überhaupt keine Ahnung von, finde aber die "War-Stories" von Internetausfällen immer sehr faszinierend...
|
|
|
|
|
|
|
|
|
|
|
|
seitdem ich bei der Deutschen Glasfaser bin, bin ich nachträglich sehr beeindruckt von der Zuverlässigkeit des DTAG-Netzes. Deutsche Glasfaser fällt gern mal für nen halben Tag komplett aus, mehrmals im Jahr. Und dann nicht ein Ort, oder irgendein Routing nach Kasachstan, sondern einfach mal das ganze Münsterland + Niederrhein, einmal alles für jeden weg.
|
|
|
|
|
|
|
|
|
|
|
|
Rechtfertigen sie sich denn irgendwie für ihre kaputte Infrastruktur oder ist das halt so?
|
|
|
|
|
|
|
|
|
|
|
|
es tut ihnen immer sehr leid.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
