Dueffel will FLOSS, Himbeerkuchen und Ordnung im Datenstall

[Bootdiskette]

joar, liegt halt (leider) nur rum.
Das Thinkpad Yoga 12 ist halt insgesamt wegen der besseren Auflösung mehr in Benutzung (hat aber halt nur 8 GB RAM … und kackt deshalb gerne mal ab wenn eine richtige IDE parallel zu einem Browser läuft )

Äußer Dich mal zu den weiteren Rip-Tipps ob hilfreich.

 

[drwilly]

Bei mir ists mit ZSH wie mit i3 oder ViM - teheoretisch überlegen. Praktisch sprechen bei mir 2 Dinge dagegen: Lernkurve ist meh und alle Systeme auf denen ich beruflich unterwegs bin haben halt Standard Debian Configs. Kein zsh, kein neovim, kein i3.

Vim mit Standard Konfig is doch OK?
Ansonsten ist fish die überlegene shell.

 

[Shihatsu]

Na, Vim find ich furchtbar in Standard. Aber krieg vielleicht bald Neovim, das wäre super.
So ziemlich jede shell ist besser als bash, aber es ist halt nicht bash.

 

[Bootdiskette]

@drwilly pls elaborieren. warum fish?

@shi was magst Du an der vim standard config nicht? Ich mein … klar, man kann sich ja seine eigene zusammentackern mit farbe und bunt, aber so die basisfunktionalität ist doch ok.

Es warten viele Silberlinge auf mich. In meiner Jugend hatte ich einfach alles zu mp3 gerippt und war glücklich. .RAW ziehe ich mir dieses Mal. Schliesslich wird man manchmal auch schlauer.

weil ich es grad nochmal gesehen habe … gibt es für dich einen bestimmten grund für RAW > FLAC? ich mein … das L steht für verlustfrei

 

[Shihatsu]

Naja, mein NeoVIM ist gewachsen und angepasst - allein so Dinge wie mein stacking fehlen halt komplett. Ich glaub standard VIM wäre gar nicht schlecht, aber glauben ist nicht wissen, und ich will nicht wissen

 

[drwilly]

@drwilly pls elaborieren. warum fish

Fish macht von Haus aus all das wovon zsh user ganz stolz berichten, dass sie das grade unter Zuhilfenahme von nur siebzehn Plugins zusammen-konfiguriert haben.
Syntax is auch besser, falls man doch mal einen for-loop in die Kommandozeile tippt.

 

[Bootdiskette]

@drwilly okay, das klingt tatsächlich sehr überzeugend. wenn mich eins beim arbeiten auf MacOS stört, dann, dass ich regelmäßig diese OhMyZsh-updates abnicken muss
@shi i see. ich glaube man will heute nach möglichkeit kein standard-vim mehr, weil es viele gute gründe für neovim gibt. nach dem tod von bram wird sich neovim womöglich bald auch als default ausbreiten.

 

[Shihatsu]

Wie isn das mit fish? bash kompatibel ja/nein?`afaik nein? das war für mich der kicker für zsh, aber ich darf halt net - und 2 shells lernen mag ich nicht.
ich bin ja quasi schon von apt vs pamac überfordert... srsly, nvida nvenc auf debian MY ASS

 

[drwilly]

@drwilly wenn mich eins beim arbeiten auf MacOS stört, dann, dass ich regelmäßig diese OhMyZsh-updates abnicken muss

Nix.
emerge fish && exec fish
Fertig.
In dem Zusammenhang muss ich auch feststellen, dass ich nen ziemlichen Hass auf diese Art von Software entwickelt habe, die super konfigurierbar ist, aber es seit den 70ern nicht schafft ihre defaults anzupassen. Neovim ist da, Vim kann auf die digitale Müllkippe. Stellt sich nämlich raus, dass nur ne handvoll masochisten Spaß an vimscript hatten. Überraschung.
Bash, zsh und Konsorten wird auch keiner vermissen. Fish hat glaube ich grade den größten mindshare, aber wie Shi sagt, nicht posix kompatibel, also braucht man bash noch für die ganzen Skripte.
oilshell.org könnte da das tun was neovim schon gelungen ist.
Hab auch gutes über Nushell gehört, hat mich persönlich aber nicht so angesprochen.

Wie isn das mit fish? bash kompatibel ja/nein?`afaik nein? das war für mich der kicker für zsh, aber ich darf halt net - und 2 shells lernen mag ich nicht.

Du leidest vergeblich

 

[Shihatsu]

Bedankt, aber: QQ

 

[Bootdiskette]

In dem Zusammenhang muss ich auch feststellen, dass ich nen ziemlichen Hass auf diese Art von Software entwickelt habe, die super konfigurierbar ist, aber es seit den 70ern nicht schafft ihre defaults anzupassen.

Ist halt wie üblich: Entwickler macht den Kram für sich selbst … hat auch noch einen Job und keine Kapazität bzw. andere Prioritäten bzw. ist halt kein UI/UX-Experte … und schwups hat man genau dieses Bild. Ich habe da Verständnis, aber geil finde ich es obvsly auch nicht.

Neovim ist da, Vim kann auf die digitale Müllkippe. Stellt sich nämlich raus, dass nur ne handvoll masochisten Spaß an vimscript hatten. Überraschung.

Jetzt klingst Du aber ein bisschen aggro. Fast so als ob Du traumatische Erlebnisse mit vimscript gehabt hättest.

Bash, zsh und Konsorten wird auch keiner vermissen. Fish hat glaube ich grade den größten mindshare, aber wie Shi sagt, nicht posix kompatibel, also braucht man bash noch für die ganzen Skripte.
oilshell.org könnte da das tun was neovim schon gelungen ist.
Hab auch gutes über Nushell gehört, hat mich persönlich aber nicht so angesprochen.

Hm hm. Seit es systemd gibt ist ja die Relevanz von (Bash-)Shellskripten im laufenden System doch zum Glück sehr deutlich gesunken. Und mit korrektem Shebang macht einem das ja auch keine Probleme solange man bash installiert hat.

 

[drwilly]

Jetzt klingst Du aber ein bisschen aggro. Fast so als ob Du traumatische Erlebnisse mit vimscript gehabt hättest.

Nee, tatsächlich nicht. Aber seit ich das bemerkt habe fällt mir das an vielen Stellen auf: Vim und emacs, aber auch viele Programmiersprachen wie common lisp, SQL oder eben bash.
Was da an Aufwand betrieben wird, nur damit man ein paar Zeilen code nicht angepasst werden müssen. Junge junge. Aber ja, was das angeht bin ich ein bisschen "aggro".

Edit: Ich denke das liegt auch daran, dass die jeweiligen Programme unheimlich viel richtig machen. Vim hat einfach das beste Texteditor-Konzept. Eine Shell zu haben ist an sich schon Klasse. Aber das manche Sachen da so eine Trägheit entwickeln... Das fällt eigentlich immer auf, wenn dann so eine Wachablösung stattfindet. Nur warum arbeitet man da nicht gleich dran? Meist scheitert es ja nicht an technischer Umsetzung sondern wirklich am Willen. Und das ärgert mich halt.

 

[Bootdiskette]

Das verstehe ich gut. Allerdings glaube ich nicht, dass es am Willen mangelt, sondern eher am disruptiven Charakter solcher Änderungen, welche häufig dann Kompatibilitäten zerstören und viel Folgearbeit bedeuten. Je häufiger man das gemacht hat, desto eher arrangiert man sich mit einem halbwegs funktionierenden System mit "Eigenheiten".

Deswegen kann man mE noch so sehr über Pöttering, systemd und pulseaudio abkotzen (oder auch wayland, wenn auch nicht Pöttering aber trotzdem wieder Red Hat): Was er (und Red Hat) mit diesen Änderungen angestoßen hat sind genau diese dicken Bretter zum Beseitigen von riesigen Haufen Legacy-Infrastruktur. Das kann man kaum hoch genug einschätzen.

Jetzt würde mich aber interessieren was Du an SQL hatest … ich mein, da gibt es in jedem Dialekt so diverse Kinks, aber insgesamt hat sich SQL für sein Alter doch extrem gut gehalten?

 

[drwilly]

Das verstehe ich gut. Allerdings glaube ich nicht, dass es am Willen mangelt, sondern eher am disruptiven Charakter solcher Änderungen, welche häufig dann Kompatibilitäten zerstören und viel Folgearbeit bedeuten.

Ja das Argument hört man in dem Zusammenhang immer. Halte ich aber für Schwachsinn: Guck dir an mit welcher Geschwindigkeit solche Plugin-Ökosysteme aus dem Boden sprießen, zB bei vscode. Oder oben genannt neovim. Oder systemd-units.
Wenn du die Leute überzeugst, geht das immer sehr schnell.
Folgearbeit, ja... "Ich habe 1982 ein Programm geschrieben und das kompiliert immer noch ohne Änderungen!" - ja Horst, das ist ja toll, dass dein EBCDIC Encoder immer noch geht, aber wen interessierts? Guck doch mal deinen PC durch und sag mir welche der Programme ihr letztes release vor 2020 hatten. Programme werden gepflegt solange sie nützlich sind; alles andere ist das Äquivalent zu einem liebevoll gepflegten Oldtimer in der Garage.
Ich habe mehrere größere repos von Python 2 auf 3 portiert und das war für meine Begriffe der GAU was sowas angeht. Sowas sollte man regelmäßig besser nicht machen. Aber wenn man die Migration ein bisschen besser gestaltet spricht für mich nichts dagegen alle 10(?) Jahre inkompatible Änderungen einzuführen. Oder man nachts gleich wie zB Rust mit den editions, wo inkompatible Sprachänderungen einfach gar nicht zum Problem werden.

Deswegen kann man mE noch so sehr über Pöttering, systemd und pulseaudio abkotzen (oder auch wayland, wenn auch nicht Pöttering aber trotzdem wieder Red Hat): Was er (und Red Hat) mit diesen Änderungen angestoßen hat sind genau diese dicken Bretter zum Beseitigen von riesigen Haufen Legacy-Infrastruktur. Das kann man kaum hoch genug einschätzen.

Pulseaudio ist tot, Pipewire ist die Zukunft.
Aber ja, den ganzen shellskripten weint da auch keiner wirklich nach.

Jetzt würde mich aber interessieren was Du an SQL hatest … ich mein, da gibt es in jedem Dialekt so diverse Kinks, aber insgesamt hat sich SQL für sein Alter doch extrem gut gehalten?

Gut dass du fragst, ich habe da eine kurze Präsentation vorb...
Nee, quatsch, aber ich würde sagen in dem Artikel werden einige Probleme ganz anschaulich erklärt:

Against SQL

www.scattered-thoughts.net

Aber selbst wenn du nicht so tief einsteigen willst, gibt es schon an der Oberfläche reichlich Kleinigkeiten:
Warum gibt es so kram wie natural join, join using (XYZ), aber für nen ganz normalen pkey<->fkey join musst du wirklich die Bedingung ausformulieren? Warum kann SQL keine Trailing Commas? Wieso sind die Fehlermeldungen eigentlich immer so nutzlos? Gibt es irgendeine sinnvolle und konsistente Einrückung für SQL??
Dass sich SQL gut gehalten hat sehe ich übrigens nicht so. SQL wird kontinuierlich weiterentwickelt; der neueste standard is von 2019; die wollen das so!

 

[parats']

Das Problem bei SQL ist, dass es historisch gewachsen ist und aus einer Zeit kommt, die komplett andere Anforderungen hatte. Man konnte halt immer nur mit den Anforderungen dran bauen, musste den Kern aber behalten.
Nach heutigem Wissen würde man so einige Sachen sicher anders machen, aber bei der Menge an Legacy Code ist das eben schwierig und durch die große Verbreitung im Backend auf verschiedenen tech stacks hast du eine große Variationen an SQL wie bspw. TSQL, DSQL, PLSQL, SOQL etc. pp..
Getrieben vor allem durch unterschiedliche Grundkonzepte der populären RDBMs, die sich im wesentlichen auch kaum bewegt haben.

 

[Bootdiskette]

@drwilly ajo, da sind wir letztlich doch in vielem einer meinung. ich wollte ja schon irgendwie darauf hinaus, dass inkompatibilitäten eben sand im getriebe sind, den man managen muss, damit er so einen prozess zu neuerem nicht killt.
mit pulseaudio meinte ich nur, dass es den prozess angestoßen hat. pipewire kommt ja auch von redhat und wäre ohne pulseaudio wohl nicht passiert oder zumindest längst nicht so leicht zu einem erfolg geworden.

thx für den link … ich denke auch da sind wir uns an sich einig, haben den kram aber unterschiedlich ausgedrückt.
was ich an SQL mag ist das an sich sehr simple deklarative. was ich daran nicht mag sind viele der sachen die da genannt werden, aber für mich überwiegt da aktuell, dass es doch sehr zuverlässig funktioniert.

@parats' was meinst du mit "grundkonzepte"? sowas wie CoW usw. und vielleicht die unter-der-haube-unterschiede zwischen bspw. MariaDB und Postgres?
Ohne der krasse DB experte zu sein glaube ich, dass es da auch echt schwer ist große innovationen voran zu bringen, weil gerade DB entwicklung so extrem eng auf algorithmische effizienz mapped, dass da vermutlich der mögliche fortschritt einfach echt schwer zu realisieren ist ohne große fortschritte in algorithmen oder CPU-architektur. verstehst du wie/was ich meine?

 

[parats']

Ich meine damit, dass je nach Hersteller bestimmte Schwerpunkte und Vor/Nachteile existieren und ich in den vergangenen 20 Jahren (also meine aktive Zeit) nicht das Gefühl hatte, dass die Hersteller ihre Schwächen schwächen, sondern ihre Stärken stärken. Ich würde sagen, dass sich die "alten" Hersteller vor allem nach den Anforderungen ihrer Kunden entwickelt haben. Man hat also bspw um OLTP verschieden Punkte wie Konsistenz oder Parallelität entwickelt, die aber immer nur ein weiterer Vorbau der kompletten Architektur sind. Da kann ich mir schon vorstellen, dass die Ressourcen für "andere" Dinge einfach nicht da waren, weil es keiner auf der Business-Seite anfragt hat.

So richtig bewusst ist mir das vor ca. 10 Jahren in einem PoC mit Microsoft geworden.
Wir haben damals das Produkt PDW* (später APS) evaluiert und im wesentlichen ist es ein normaler SQL Server ohne klassisches OLTP oder RDBMs Funktionalität. Man hat ein eigenes Sprachderivat namens DSQL implementiert, dass genau wie TSQL war, aber ein paar Funktionen verloren hat.
Will sagen: die Kunden fordern und die Anbieter liefern. Aber die extra Meile wird nie bezahlt und deswegen flanscht man dran.
Im Kern bin ich bei dir und kann die Punkte aus dem Link von @drwilly nachvollziehen.

*Ich weiß nicht, ob es die Hintergründe zum Produkt PDW so publik gibt, aber der Grund warum Microsoft das Ding entwickelt hat, war ein reiner Business demand. Damals kam Bet and Win auf Microsoft zu mit der Forderung "wir wollen einen SQL Server aber 10x schneller". Microsoft gründete das interne Projekt x10 und hat die normale SQL Server Engine als Plattform genommen und alles rausgeworfen was "langsam" ist. Es gibt keine PKs, FKs, Constraints, Datenmodelle, auto increments etc. Pp.. Es gibt Tabellen +Verteilungsschema und eine Handvoll Datentypen. Thats it. Alle Funktionalitäten für die Datenintegrität, Sicherheit etc. Pp. wurden in den ersten Versionen entfernt. Der Kunde war glücklich, Microsoft konnte seine Produktpalette erweitern und mittlerweile heißt das Ding Azure Synapse und weißt du was? Die können jetzt sogar Spark, weil es die Kunden wollten. Aber natürlich auch nur drangeflanscht mit semi Integration.

P.s. wir weichen sehr vom Thema ab, von daher sollten wir das an der Stelle wohl lassen.

 

[Bootdiskette]

Wir haben ein paar Use Cases mit Azure Synapse, das wurde nur genommen weil es zum Zeitpunkt des Bedarfs das schnellstverfügbare war. Alle hassen es (inkl. mir). Wir migrieren in Richtung Databricks und alle so **hype**.

Spoiler

Dat PDW-Beschreibung mit dem Plottwist

Ich hab da grad ein Projekt übernommen … da würdet ihr auch am Boden liegen. Das soll zum Jahresende live gehen. Eigentlich relativ simpler Usecase (zumindest in der MVP-Variante). Aber durch Inkompetenz und mangelnde Orga bzw. Mangel an klaren Zuständigkeiten ein dampfender Haufen Scheiße.
Ich hab mir zu Beginn das Hauptrepo gezogen und angefangen zu lesen … und war mir nach ein paar Stunden nicht sicher ob das jetzt ein Scherz oder ein Test sein sollte. Selten so einen unprofessionellen Haufen Scheiße gesehen
Mein Chef war natürlich not amused als ich ihm gesagt hab was Sache ist, und hat darauf bestanden, dass das Projekt auf einem guten Weg ist. Jetzt habe ich ihn endlich dazu bekommen, dass wir ein Codereview mit unabhängigen (internen) Entwicklern machen, damit er mir geglaubt. Ergebnisbesprechung ist kommende Woche, die Vorbesprechung mit den Reviewern war "Wie hast Du ohne laut zu schreien an solchem Code arbeiten können?", "lol wtf die codebase", "*das* soll live gehen?", "ich hoffe ich muss nie mit ****** ******* (alter projektleiter) arbeiten, das ist ja eine zumutung!"
Ich freue mich sehr über die Bestätigung und warte gespannt auf das Gesicht meines Chefs

 

[parats']

Wir haben ein paar Use Cases mit Azure Synapse, das wurde nur genommen weil es zum Zeitpunkt des Bedarfs das schnellstverfügbare war. Alle hassen es (inkl. mir). Wir migrieren in Richtung Databricks und alle so **hype**.

Wir mussten von der APS zur Synapse migrieren, weil die Wartungsverlängerung für das OnPrem System jährlich 6stellig war.
Wenn ich das richtig vorhersehe, dann dürfte aber auch Synapse nur ein Durchlaufposten sein und Fabric das vorläufige Endszenario.
Das Ganze Buzz wording um den one lake (aka delta lake) lässt mich aber hoffen. Technisch ist es im Kern sehr ähnlich, wenn man den auto scaler wegnimmt und anerkennt, das parquet nichts anderes als ein clustered columnstore index ist.
Technisch bin ich mit der Synapse in der Tat zufrieden. Das knappe Petabyte lässt sich noch ganz praktisch bewirtschaften und die Kosten halten sich in Grenzen.
Ob ich mir allerdings nochmal eine Migration antue weiß ich nicht, gab genug graue Haare.

Mein Chef war natürlich not amused als ich ihm gesagt hab was Sache ist, und hat darauf bestanden, dass das Projekt auf einem guten Weg ist. Jetzt habe ich ihn endlich dazu bekommen, dass wir ein Codereview mit unabhängigen (internen) Entwicklern machen, damit er mir geglaubt. Ergebnisbesprechung ist kommende Woche, die Vorbesprechung mit den Reviewern war "Wie hast Du ohne laut zu schreien an solchem Code arbeiten können?", "lol wtf die codebase", "*das* soll live gehen?", "ich hoffe ich muss nie mit ****** ******* (alter projektleiter) arbeiten, das ist ja eine zumutung!"
Ich freue mich sehr über die Bestätigung und warte gespannt auf das Gesicht meines Chefs

Immerhin habt ihr Code Reviewer. Ich kenne ne Reihe von Firmen die für sowas "keine Zeit" haben.