IRC Logs for #zfx


2021-08-17

05:50:19 Schrompf joined the channel
06:21:36 Schrompf: Schon wieder gleich am frühen Morgen Party mit Heizelement
06:21:45 Schrompf: Lasst mich doch erstmal zum Kaffee :-/
07:42:24 joeydee joined the channel
07:42:29 Schrompf: yo!
07:42:31 joeydee: moin
07:42:37 Schrompf: ätsch eher
07:42:48 joeydee: yo, ey!
07:43:02 Schrompf: ey, yo!
07:43:11 joeydee: alda, dei mudda!
07:43:39 Schrompf: du hasch kein respeggt in dei homezone!
07:44:13 joeydee: ey, willscht du mich produziern oder was?
07:45:30 xq: moin moin
07:45:51 xq: Kinners, benehmt euch
07:48:49 joeydee: der kleine Schrompf und der kleine Joey möchten aus dem Kinderparadies abgeholt werden.
07:49:26 xq: Schrompf: ich hab mir gestern übrigens Death Trash gekauft und bisher noch keine Minute bereuut
07:50:48 Schrompf: das ding mit dem raben in der totenwelt?
07:51:23 xq: nein, das Projekt von https://twitter.com/talecrafter
07:51:36 xq: http://www.deathtrash.com/
07:51:37 xq: das hier
07:51:52 Schrompf: ahja
07:52:03 Schrompf: wasndas? RPG? oder Point&Click?
07:52:20 xq: mhhh
07:52:31 xq: Action-Adventure/RPG
07:53:12 xq: du hast Stats/Skills
07:53:37 xq: hast ne offene Welt, die Story leitet dich aber relativ linear durch diese
07:54:05 xq: Man quatscht viel, kloppt sich aber auch viel
07:56:41 Schrompf: ah ok, thx
07:56:59 xq: sehr sehr spaßig und absurd
07:58:07 xq: gibt sogar eine Demo :O
08:35:18 IceMichael: moin
08:35:24 joeydee: moin
08:35:38 IceMichael: na, was gibt's Neues an der Kreativfront?
08:35:41 Schrompf: moin
08:35:58 Schrompf: noch nicht, hab den umbau erst angefangen
08:36:07 Schrompf: und auf arbeit brennt die hütte
08:36:09 IceMichael: was baust um?
08:36:11 IceMichael: oh, wieso das?
08:36:36 Schrompf: das wurmspiel. das kriegt jetzt ne display-world, die alle entities aus der game-world spiegelt.
08:36:48 joeydee: auch nix Neues an meiner Kreativfront
08:37:16 Schrompf: damit kann ich nämlich die display-entities länger leben lassen als die game-entities, um sie z.b. auszublenden oder beim futtern zum wurm-maul zu bewegen, obwohl sie gameplay-wirksam schon lange weg sind
08:39:26 Schrompf: und auf arbeit: gestern lief ein salt-run (remote mass server admin tool), während gerade ein neues engine-image auf alle server ausgespielt wurde. dadurch war auf manchen maschinen der upload unvollständig und das programm crashte immer wieder bei dem versuch, es zu laden
08:39:32 Schrompf: doof für die kunden, doof für uns
08:39:50 Schrompf: und der nachhall davon sind halt jede menge absicherungen, notfallmaßnahmen und neue tickets
08:40:35 IceMichael: Schrompf, oh, klingt nice. Klingt aber auch nach einem komplett neuen Layer, das etwas Overhead verursacht und bei dem ich hier normalerweise "Buhhh"-Rufe aus diesem Channel hören würde :)
08:41:12 Schrompf: nö, man muss schon taktisch abwägen, wofür man layer einzieht
08:41:23 IceMichael: ja, aber der erste Ruf ist immer dagegen hier
08:41:36 Schrompf: und der display-layer ist ja auch ECSt, der allokiert nicht und kann große mengen entities gleich verarbeiten
08:41:48 Schrompf: ja, den ersten ruf würde ich auch immer dagegen setzen
08:42:00 Schrompf: aber das heißt ja nicht, dass der letzte ruf auch dagegen sit
08:42:04 Schrompf: brauchst halt gute gründe
08:42:19 IceMichael: hehe ok :) na ja, ich seh ein paar Standardfälle, wo recht schnell klar ist, dass Layers schlau sind
08:42:25 Schrompf: und "da fühlt sich das klassendesign sauberer an" ist für mich halt kein grund :-)
08:42:30 IceMichael: neeee
08:42:41 IceMichael: allein weil "sauberer" was schon ein buzzword ist
08:42:46 IceMichael: full ack
08:42:49 Schrompf: jau, hochgradig subjektiv
08:42:52 IceMichael: oder agree? egal
08:43:06 IceMichael: und kacke @ Kunden, das sind immer super Fälle
08:43:22 Schrompf: jau, da ist panikgetriebenes sprinten über gänge angesagt
08:43:33 Schrompf: auch wenn's gar nix nützt, so verlangt es die Tradition
08:45:22 IceMichael: ja, wir hatten letztens auch nen supergau
08:45:27 IceMichael: int32 vollgelaufen
08:45:36 IceMichael: DB konnte es sogar, aber unsere Protokolle, die teilweise bytebasiert sind, halt nicht
08:46:19 IceMichael: google protobuf und so... kann man nicht mal schnell ändern. Ist halt schnell und kompakt zur Übertragung, aber dafür beschissen anzupassen, bin also nicht so sicher, wie schlau die Entscheidung dafür war
08:46:57 IceMichael: na ja, normalerweise sollte int32 nicht vollaufen und es gab auch große Lücken, jetzt wurde viel einfach in die Lücken reingesetet
08:47:45 Schrompf: Protobuf kann man ja nun gerade schnell ändern
08:47:48 Schrompf: seltsam?
08:48:22 Schrompf: wir hatten ein handgeklöppeltes Binär-Protokoll, das solche Änderungen viel weniger flexibel weggesteckt hätte, und haben es durch Protobuf ersetzt
08:48:43 Schrompf: und haben nun das problem, dass das Marshalling in Go (und nur in Go) spektakulär langsam ist
08:49:02 Schrompf: wir reden hier von Faktor 50 gegenüber der C++-Version mit Arena-Allokator
08:49:32 Schrompf: und das macht uns gerade an allen möglichen Interfaces Ärger, weil sich Nachrichten aufstauen und Timeouts reissen
08:50:21 Schrompf: "ein bissl langsamer" würde ich ja akzeptieren, aber Go hat doch als Managed-Sprache bereits den vorteil eines arena-allocs eingebaut
08:50:31 Schrompf: die müssten da doch durchblastern wie nüscht gutes
08:50:38 Schrompf: tun sie aber nicht.
08:50:40 Schrompf: grmpf
08:55:22 IceMichael: Schrompf, ach scheiße... also haben die es einfach schlecht gebaut?
08:55:45 Schrompf: Weiß nicht
08:56:02 IceMichael: hm, ich frag mich gerade auch, wieso wir GPB nicht schnell ändern können
08:56:05 Schrompf: es gibt ne alternative implementierung "GoGoProtobuf" die "fünfmal schneller" sein soll
08:56:18 IceMichael: also nur 6 mal langsamer
08:56:25 Schrompf: :-)
08:56:48 IceMichael: ja und selbst bauen ist da wohl auch zu hart
08:56:49 Schrompf: aber die encoded ein paar builtin types anders als die orginale protobuf-implementierung. darunter z.b. den timestamp, den jetzt unsere c++-engine nicht merh lesen kann
08:56:51 Schrompf: fuck eh
08:57:03 IceMichael: puh... ja, das ist ätzend
08:57:10 Schrompf: aber echt ma
08:57:34 Schrompf: unser erster reflex war natürlich sofort: na dann machen wir das marshallen halt in c++, so wie wir alles in c++ machen, was in go zu langsam ist
08:58:00 Schrompf: aber dann musst du halt c++-objekte ins Go marshallen, und es kann gut sein, dass das dann genauso lahm ist wie das ur-protobuf :-)
08:58:37 Schrompf: vielleicht nehmen wir die C-Impl, die generiert doch nur einen strauß C-Strukturen, die man einfach so in Go lesen kann?
08:59:06 Schrompf: nee, wahrscheinlich haben die auch nen "software-abstraktion"-käfer gebissen und generieren lieber viele hundert accessor-funktionen
09:01:23 IceMichael: ja, hätte auch gedacht, dass das marshalling vermutlich das bottleneck ist
09:03:20 IceMichael: und die dickere bulkoperation, die in go ist, in c++ verschieben ist auch ätzend
09:11:13 Schrompf: ja, unsere Goler sind sehr skeptisch, wenn irgendwas in C gemacht werden soll, selbst wenn sie es selbst nicht machen müssen.
09:11:51 Schrompf: die gründe, die sie angeben, klingen für mich sehr nach ausreden, aber das allgemeine unwohlsein ist schwer wegzudiskutieren
09:13:51 IceMichael: es ist ja klar, so was ist immer "unschön". Klare Verantwortlichkeiten mit nem Layer pro Sprache usw.
09:14:01 IceMichael: und hier wird basierend auf Performance eben dann doch wieder was geshiftet
09:14:06 IceMichael: und die haben keine Kontrolle
09:25:14 IceMichael: na ja, ihr seid nicht soo groß, ne? Weil nachher ist was kaputt und wenn die die Verantwortung haben, kriegen die aufn Deckel :) aber klingt ja eher so, als würden bei euch eh immer alle dann rumsprinten ohnd groß Schuldzuweisung
09:30:43 Schrompf: ja, so möchte das ja auch sein, oder?
09:33:22 IceMichael: keine Frage, aber spätestens ab Konzernlevel wird das Sündenbock-Pattern leider gewählt
09:33:35 IceMichael: wenn ein Chef kacke baut, sucht er sich nen Sündenbock, der es vermeintlich vermurkst hat
09:33:41 IceMichael: das Schlimme ist: es klappt leider gut
09:34:13 Schrompf: blaming hat aber noch nie einen bug gefixt?
09:34:24 IceMichael: nö, das ist unabhängig
09:34:36 IceMichael: aber wenn es Leute mit Befugnissen in der Firma gibt, die von "Schuld" viel halten, suchen die danach
09:34:41 Schrompf: ahso, das läuft concurrent
09:34:43 IceMichael: völlig unnötiger Schritt
09:34:53 IceMichael: ja, oder schlimmstenfalls sequentiell
09:35:42 IceMichael: https://dilbert.com/strip/2012-05-31
09:37:04 IceMichael: aber egal, ihr seid da glücklicherweise nicht. Wir auch (noch) nicht, aber so was kommt leider gern mal mit Wachstum, wo Leistungen von managern schwerer zu beurteilen sind und der größte Blender den Zuschlag kriegt
09:39:40 xq: "hauptsache, der manager ist nicht schuld"
09:40:08 Schrompf: man muss halt echt ne große firma sein, um sie dieses maß an ego-befriedigung ohne payload leisten zu können
09:40:33 IceMichael: es ist auch die Branche. Wenn die Markteintrittsbarrieren irrational hoch sind, geht's den Oligopolen zu gut
09:40:51 IceMichael: die besten Beispiele sind Pharmazie, Telekommunikation, Versicherungen, Banken
09:41:34 IceMichael: meine Frau hat zB untersucht (ist u.a. ihr Job), ob die ein paar Medizintechnik-Produkte anbieten könnten, weil die maßlos überteuert sind
09:41:47 IceMichael: wieso sind sie das? Nicht wegen Technik oder Arbeit, sondern wegen Zertifizierungen
09:41:58 IceMichael: und die haben einfach nur komplett sinnlos aufgeblasene Preise
09:42:28 IceMichael: und schon müssen Pflegeheime oder Krankenhäuser horrende Preise zahlen... das Geld wäre zB in Pfleger wesentlich besser investiert, aber an der Schraube dreht halt keiner :)
09:42:57 IceMichael: sorry, ich werd wieder zu politisch hier
09:44:37 IceMichael: sooo, wie motiviere ich mich jetzt zu coden, viel wichtigere Frage
09:50:51 Schrompf: die frage wäre denn, wie man an so ner schraube drehen will
09:51:14 Schrompf: du kannst ja schlecht die firmen zu fiktiven preisen verpflichten. das erlaubt die marktwirtschaft nicht
09:51:23 Schrompf: man müsste denen halt staatliche konkurrenz machen
09:51:43 Schrompf: und da kommste schnell ins interop-loch: die wenigsten anwendungen sind freistehend, alles muss mit allem reden können
09:52:13 Schrompf: und bei krankenhäusern läuft das schnell auf SAP raus, was ja wohl das paradebeispiel für einen Moloch ist, der vom reinen Vendor Lockin lebt
09:52:48 IceMichael: Schrompf, ich bin jetzt bei den Zertifizierungen nicht so tief drin. Aber ja, Konkurrenz ist die Frage: warum kann das nicht jeder machen? Vermutlich, weil der Staat dazu sagen muss "darfste machen"
09:53:23 IceMichael: und jetzt kann es zB einfach Lobbyarbeit sein, warum die Politik aus fadenscheinigen Gründen nicht wem anders den Zuschlag gibt (nur ein Beispiel). Weil bei den Preisen werden sich schon viele überlegt haben, da mitzumachen
09:53:31 Schrompf: nö, ich vermute wie geschrieben eher die interop. die ist im gegensatz zu zertifikaten funktionsrelevant
09:54:23 IceMichael: die Technik ist aber nicht interop oder fortschrittlich. Anne hat zB mal Patientenwaagen angeschaut
09:54:38 IceMichael: die nutzen einfach einen sehr alten Stand der Technik und die werden manuell vom Personal über ein LED ausgelesen
09:55:11 IceMichael: also LED-Display (oder nicht mal das)
09:55:31 IceMichael: oder meinst du jetzt irgendwie interop auf Zertifizierungslevel?
09:56:32 IceMichael: jedenfalls hat sie da mit diversen Ingenieuren gesprochen und es wäre wirklich einfach ein in jeder Hinsicht besseres Produkt zum 1/10 des Preises herzustellen. Nur eben die Zertifizierung ist der teure Scheiß
10:39:09 Schrompf: oh noeyz!
10:39:17 Schrompf: oh, schon ne weile her
10:39:38 Schrompf: merkt man eigentlich, dass ich mich gerade von codegen-debugging drücke?
10:46:19 IceMichael: kaum
18:05:03 Magister joined the channel
18:05:46 Essex20 joined the channel
18:06:05 Essex20: moin
18:10:25 Essex20: uuuund tschüss....
20:09:07 IceMichael: danke für den Beitrag Essex20