Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: mercury, Schalentier


 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 160 161 162 163 [164] letzte »
erste ungelesene Seite | letzter Beitrag 
MartiniMoe

AUP MartiniMoe 02.02.2019
Ich nerde egtl auch hauptberuflich mit Linux rum, aber verstehe hier auch nur 1% peinlich/erstaunt Breites Grinsen
09.09.2020 22:54:24 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
 
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?
10.09.2020 10:29:11 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
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]
10.09.2020 10:57:45 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Zitat von Farbkuh

Mal aus Neugier: ihr macht das vorwiegend hauptberuflich oder? Also nerden meine ich peinlich/erstaunt



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]
10.09.2020 11:37:31 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
a1ex

a1ex_small2
peinlich/erstaunt
13.09.2020 14:26:40 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Ach, komm. Gib nach und schreibe
13.09.2020 20:47:58 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
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]
14.09.2020 22:30:01 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

Deutscher BF
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]
14.09.2020 23:30:35 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
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.
15.09.2020 0:21:06 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
FreeHawk*

AUP FreeHawk* 31.10.2010
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?
15.09.2020 23:27:52 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
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"...
15.09.2020 23:50:14 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
FreeHawk*

AUP FreeHawk* 31.10.2010
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.
16.09.2020 0:31:03 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
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.
16.09.2020 7:14:28 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
SwissBushIndian

AUP SwissBushIndian 07.11.2011
Azure Insights
16.09.2020 7:26:11 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GH@NDI

ghandi2
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]
16.09.2020 8:21:58 Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 160 161 162 163 [164] letzte »

mods.de - Forum » Linux » 

Hop to:  

Thread-Tags:
gnu  linux 
| tech | impressum