ZFX + Developia

Fortsetzung der Antivirenscheiße: https://twitter.com/ericlaw/status/1176478751825301505

Mit diesem Goldstück:



Verbrennt die ganze scheiß Branche!

Deinen zweiten Link mit dem Goldstück kann ich leider erst sehen wenn ich den Quelltext anzeige. Scheint dass mein Adblocker da was wegfiltert ^^

Hmm … ist auf Twitter gehostet. Firefox hatte das anfangs als „Tracker“ blockiert, beim zweiten Besuch nicht mehr. Mit Chrome geht’s die ganze Zeit.

Wie clever von Firefox, einen Ad-Blocker direkt in den Browser zu verlagern.

Bin inzwischen auf Vivaldi unterwegs. Das passt zum Link :D

Ich mag ansich ja wirklich den ISO 8601 Standard für Zeitangaben - aber das 'T' zwischen Datum und Uhrzeit stört mich dann doch. Es gibt ja schon extra den 'extended' Modus mit schickeren Trennzeichen (statt 20190927T185242 dann 2019-09-27T18:52:42), aber was ich wirklich so viel netter finde wäre das T durch ein anderes Zeichen zu ersetzen. Beispielsweise so 2019-09-27_18:52:42. Die einzige Ausnahme die der Standard diesbezüglich zulassen zu scheint, ist das T per 'mutual agreement' einfach wegzulassen (2019-09-27 18:52:42). Allerdings kommt es mir so vor, dass man auf dem Level eines mutual agreements ansich überhaupt keine Standards mehr braucht. Die wurden ja schließlich gerade dafür geschaffen, dass man sich nicht ständig absprechen muss.

Alles kein Beinbruch, aber dennoch ein kleines *seufz*.

Mal ganz ehrlich: Was ändert es anstatt eines 'T' ein '_' zu verwenden?

Mit dem 'T' (und ohne Trennzeichen) ist es halt ne reine Textwand, die ich sehr mühsam zu lesen finde. Ich bin da ganz auf Jonathans Seite.

Usability ist eben ein sehr schwieriges Kapitel ^^

Diesbezüglich finde ich IBAN den größten Fuckup. Warum haben die nicht verdammte Email-Adressen (oder sowas in der Art) genommen...

Ich weiß nicht, ob ich überhaupt das Datum/die Zeit im ISO 8601-Format meinem Anwender präsentieren möchte. Ich sehe das eher als Vorteil bei maschineller Verarbeitung. Aber wahrscheinlich ist das alles persönliche Präferenz.

Thoran hat geschrieben: ↑30.09.2019, 14:35 Ich weiß nicht, ob ich überhaupt das Datum/die Zeit im ISO 8601-Format meinem Anwender präsentieren möchte. Ich sehe das eher als Vorteil bei maschineller Verarbeitung. Aber wahrscheinlich ist das alles persönliche Präferenz.

Würde ich nicht machen. Der ISO-Standard ist hervorragend, um Datumsangaben korrekt abzuspeichern (timezone, uhrzeit, datum, ...). Aber zum Anzeigen sollte man natürlich immer die System Locale oder das vom User eingestellte verwenden (sprich: "Montag, den 30. September 2019, 15 Uhr 30" statt "20190930T153000+02:00")

Ich benutze das Format (oder ein ähnliches, laut Wikipedia scheint die Variante mit den Minussen auch legal) wenn ich in Fließtexten präzise Zeitangaben übermitteln muss. Also gerade da wo ich nicht davon ausgehen kann, dass die Gegenseite das selbe locale verwenden würde, was in einem Fließtext sowieso nicht gescheit anpassbar wäre und schon gar nicht annehme, dass die Gegenseite weiß wann bei mir die Sommerzeit endet.

Die Minusse wirken übrigens wahre Wunder bei der Lesbarkeit. Das T stört dann gar nicht mehr.

Ich benutze es manchmal ohne Zeitzonenangabe wenn ich in der selben Zeitzone bin wie die Gegenseite und bin damit streng genommen anscheinend nicht konform. Der Standard würde zu UTC defaulten, nicht zur lokalen Zeitzone. In dem Fall lasse ich das T eher weg und bisher wurde das immer verstanden.

Mir scheint es offensichtlich, und Wikipedia bestätigt das auch mindestens teilweise, dass das Format menschenlesbar gemeint ist, und ich denke mein Anwendungsfall ist valide. Ich bin nicht üüberzeugt dass es das beste Format ist wenn Menschenlesbarkeit keine Rolle spielt und man für den Menschen sowieso konvertiert.

xq hat geschrieben: ↑30.09.2019, 14:56

Thoran hat geschrieben: ↑30.09.2019, 14:35 Ich weiß nicht, ob ich überhaupt das Datum/die Zeit im ISO 8601-Format meinem Anwender präsentieren möchte. Ich sehe das eher als Vorteil bei maschineller Verarbeitung. Aber wahrscheinlich ist das alles persönliche Präferenz.

Würde ich nicht machen. Der ISO-Standard ist hervorragend, um Datumsangaben korrekt abzuspeichern (timezone, uhrzeit, datum, ...). Aber zum Anzeigen sollte man natürlich immer die System Locale oder das vom User eingestellte verwenden (sprich: "Montag, den 30. September 2019, 15 Uhr 30" statt "20190930T153000+02:00")

In meinem konkreten Anwendungsfall ging es darum, Timestamps in JSON-Dateien abzuspeichern. Das ist ein bisschen ein Mischfall, es sollte halt leicht einzulesen sein, aber ich gucke halt auch ab und zu die Datei im Texteditor an um zu gucken was ich da eigentlich vor mir habe.
Letztendlich habe ich mich für die Variante mit dem T entschieden, um standardkonform zu sein. Wobei das viel eher prinzipieller Natur ist, ich erwarte nicht, dass die Dateien außer mir nochmal jemand einliest und werde wenn ich die Zeit mal nicht als String sondern echte Zeit brauche vermutlich eh einen regex oder eine dieser eingebauten Parsefunktionen verwenden, so dass das Format ohnehin wieder total beliebig ist.

git for Windows zerstört alle line feeds als wär’s 1993 (via core.autocrlf).

Sei’s drum, von den paar hundert Parser-Testdateien habe ich ja zum Glück noch ein Backup außerhalb von git gespeichert.

Viel erschreckender ist aber, dass die Mehrheit der User das überhaupt nicht negativ sieht, dass ein Versionierungssystem die Dateien beim pull/push verändert, denn das sei ja total praktisch. Äh, WTF?!

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_code_core_autocrlf_code hat geschrieben:This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Und die offensichtliche Lösung für dieses annoying fact ist, dass git das halt direkt selber tut!

core.whitespace
Git comes preset to detect and fix some whitespace issues. It can look for six primary whitespace issues — three are enabled by default and can be turned off, and three are disabled by default but can be activated.

The three that are turned on by default are blank-at-eol, which looks for spaces at the end of a line; blank-at-eof, which notices blank lines at the end of a file; and space-before-tab, which looks for spaces before tabs at the beginning of a line.

WIEBITTE?! Das sind exakt einige meiner Whitespace-Testdaten! Die wurden auch kaputt„korrigiert“?! I CAN’T EVEN

Das ist übrigens haargenau der Untergang-der-Zivilisations-Talk von Jonathan Blow. You can’t just XXX. You can’t just push files. Du musst dir erst bewusst sein, dass es da vier standardmäßig eingeschaltete Einstellungen gibt, die die Dateien beim Push verändern. Aber nur, wenn es Textdateien sind! Als nächstes darfst du also erforschen, woran git Textdateien erkennt und das in deinem Kopf nachspielen. Statt wirklich zu programmieren. Das, wobei uns git helfen sollte.

Nachtrag: Oh, das war ja fucking großartig. Die meisten Testfälle für Whitespace waren kaputt. Außerdem viele für Zeilenenden. Viele Dateien, deren Größen genau auf Pages abgestimmt waren. Außerdem alle Tabellen für MSI, die Tabs als Trennzeichen für Tabellen nutzen. Und die Vorlagen für RTF-Dateien.

Also: Wenn man seine Dateien in ein git-Repository verlegt, muss man entweder vorher die Dokumentation nach allen „hilfreichen“ Voreinstellungen abgrasen oder darf einplanen, alles von Build-Skripten und Tests über Setup ab Null neu zu testen. Scheißdreck

Jap, autocrlf ist die Seuche. Das ist auch die erste Option, die ich beim git-Installieren sofort ändere. Ich glaube sogar, dass es standardmäßig an ist und, noch schlimmer, im Hilfetext steht "wenn du dir unsicher bist, lass es einfach an, dann funktioniert alles automatisch richtig.

Das es drei unterschiedliche Standards für Newlines gibt ist nicht gut. Aber seien wir mal ehrlich, jeder vernünftige Texteditor kann damit problemlos umgehen. Und wenn dein Texteditor Zeilenenden automatisch konvertiert und deshalb Ärger macht, muss man eben einen anderen verwenden. Ich meine, git macht ja auch nicht aus Tabs vier Leerzeichen oder andersherum - und das ist auch gut so. Und überhaupt widerspricht das doch dieser ganzen tollen Linux-Philosophie "Ein Tool für eine Aufgabe". Es ist irgendwie wirklich aus jeder Perspektive unbegreiflich, wie man so ein Feature nur implementieren und zum Standard machen konnte. Hach...

Na das Problem ist doch viel mehr dass es die Versionsgeschichte zerstört wenn immer von \r\n zu \n hin und her gewechselt wird zwischen Linux und Windows commits.

Das es unterschiedliche Zeilenumbrüche gibt ist zwar wirklich nervig, aber die Versionskontrolle kann das Problem auch nicht einfach ignorieren wie ihr vorgeschlagt, außer man hat ein Windows bzw. Linux-only Projekt.

Ich wurde auch schon davon getroffen mit Testdateien für UTF-8 / UTF-16 Konvertierung, aber die Problemlösung die betroffenen Dateien als Binärdateien in einer .gitattribute-Datei zu listen finde ich eigentlich ganz okay.

Diffst Du nie? Das stirbt nämlich bei einer als "binär" getaggten Datei.

Spiele Programmierer hat geschrieben: ↑06.10.2019, 17:01Das es unterschiedliche Zeilenumbrüche gibt ist zwar wirklich nervig, aber die Versionskontrolle kann das Problem auch nicht einfach ignorieren wie ihr vorgeschlagt, außer man hat ein Windows bzw. Linux-only Projekt.

Äh, doch?! Wenn ich eine LF-Datei unter Windows öffne und was reinschreibe, übernimmt der neue Text auch LF statt CR+LF. Ist mit Notepad++ so, mit Visual Studio, und seit neuestem wohl auch mit Notepad ohne ++. Und wenn nicht, macht mich das Diff ziemlich schnell drauf aufmerksam.

Jonathan hat geschrieben:Ich meine, git macht ja auch nicht aus Tabs vier Leerzeichen oder andersherum - und das ist auch gut so.

Naja fast ;)

[…] turned on by default are […] and space-before-tab, which looks for spaces before tabs at the beginning of a line.

Schrompf hat geschrieben: ↑06.10.2019, 17:24 Diffst Du nie? Das stirbt nämlich bei einer als "binär" getaggten Datei.

Nicht in dieser Datei, ne.
Oder habt ihr wirklich so viele Textdateien bei denen es auf die Art des Zeilenumbruch ankommt?

Krishty hat geschrieben: ↑06.10.2019, 18:30Äh, doch?! Wenn ich eine LF-Datei unter Windows öffne und was reinschreibe, übernimmt der neue Text auch LF statt CR+LF. Ist mit Notepad++ so, mit Visual Studio, und seit neuestem wohl auch mit Notepad ohne ++. Und wenn nicht, macht mich das Diff ziemlich schnell drauf aufmerksam.

In Notepad++ und Visual Studio scheint das bei mir jetzt auch zu funktionieren. Allerdings gibt es halt schon mehr Editoren & Tools als die beiden.

Ich kann mich aber auch andersrum erinnern, dass ich für meinen Linux Port mit den Zeilenenden in VS gekämpft habe. Es gab ständig diese "The line endings in the file are not consistent" Warnungen in Visual Studio, wenn die Datei auf Linux geändert wurde. Ich weiß leider nicht mehr welchen Editor ich da verwendet habe, aber eigentlich ist mir die meiste Zeit (außer in dieser einen Testdatei) völlig scheiß egal welche Zeilenumbrüche da drin sind. Durch fixen dieser Warnung wurde dann die svn Geschichte dann mit nutzlosen Commits verseucht.

Ich meine, natürlich kann man jetzt argumentieren, dass ein vernünftiges diff Tool auch whitespaces ignorieren kann. tortoise-git diff hat dafür beispielsweise Knöpfe um das schnell ein- oder auszuschalten. Ist echt nützlich.

Letztendlich ist es natürlich eine irgendwie philosophische Frage, was die Aufgaben eine Versionsverwaltungstools sein sollten. Aber für mich klingt es einfach doch ziemlich sinnvoll, dass Dateien binäridentisch sind. Das git auch in der Codeeinrückung rumfummelt ist mir noch nie aufgefallen (scheint so, als würde es standardmäßig nur warnen). Ich meine, es klingt prinzipiell schon nützlich und ich sollte mir definitiv mal anschauen, was man noch alles nettes mit git-hooks machen kann, aber sowas sollte man halt dazuschalten wenn man es benutzen will. Ich erkenne git keine Autorität an, mir einen Style-Guide vorzuschreiben.

Ich habe mich da auch schon sehr über das gleiche "Feature" in Perforce gefreut:

Wenn ich Source-Dateien mit CRLF Line Ending innerhalb einer zip-Datei vom Windows auf den OS X Rechner transferiere und dort in Xcode öffne und Xcode entsprechend auf CRLF Lineendings konfiguriere, funktioniert das super ohne irgendwelche Konvertierungen, auch wenn ich auf beiden Systemen ein und auschecke - solange es sich um ein SVN-Repository handelt.

Aber was passiert, wenn ich auf dem OS X Recher in ein Perforce Repository einchecken will?
Performace sieht, das die Dateien von einem OS X Client kommen und geht ganz selbstverständlich davon aus, dass sie dann auch LF Line Endings haben müssen und versucht diese automatisch in CR LF zu konvertieren, OHNE vorher zu prüfen, ob womöglich nicht schon CR LF vorliegt -> Als Ergebnis hat es in jeder Datei nach jeder Zeile eine Leerzeile eingefügt.

Eine automatische Line-Ending Konvertierung hat echt in einem Versionierungssystem nichts zu suchen.



@Jonathan:
Bei den Leerzeichen geht es, so wie ich das verstehe, nicht darum, dass Git bei Einrückungen Tabs durch Leerzeichen ersetzt oder umgekehrt, sodern darum, dass es Leerzeichen entfernt, die unmittelbar vor einem Tab-Character auftauchen.
Von expliziten Whitespace-Testdateien wie bei Krishty mal abgesehen, sollte diese Kombi in der Form in freier Wildbahn wohl sehr sehr selten vorkommen. Es ist also nicht unbedingt überraschend, dass du da noch nicht drüber gestolpert bis.

Ich scheitere hier grade an einem Diff. Bin mir aber nicht sicher ob das jetzt an dem Whitespace scheitert. Aber ratet mal was angemeckert wird ...

<stdin>:108: trailing whitespace.

Als Warnung wäre das super nützlich. Aber als Fehler … nein danke …

Okay. Habs gecheckt und ist ne Warnung. Das scheitert an was anderem. Trotzdem kurios ^^

Ich habe mir bei Steam nur 9200 Spiele in der Entdeckungsliste angesehen und schon bekomme ich fast nur noch coming soon Spiele vorgestellt.
Warum kann man scheinbar die Liste nicht zurücksetzen ? Jammer...

"Musste" mich bei LinkedIn anmelden um mit jemandem Kontak aufzunehmen.
Alleine im Bereich "Datenschutz" muss man über 20 Switches (sind glaubs an die 30) umstellen
damit die nicht eifach alles rausgeben und weiterverwenden (was sie so oder so machen schätze ich mal)
und damit public mich niemand einfach so sieht. Dann noch mehr als 10 Switches im Bereich "Werbung".
Reicht nicht. Ich bekommen immer noch Mails von denen. Habe den Bereich "Kommunikation" ganz übersehen.
Und heute wieder ein Mail erhalten dass ich noch meine Mail bestätigen soll. Ist auch erst die 3.
Ist ja nicht so dass bereits beim Registrierungsprozess ein PIN an die Mail gesendet wurde
ohne diesen man die Registrierung gar nicht abschliessen konnte.
WTF. Hoffe dass ich den Account bald wieder löschen kann. Fühle mich als hät ich mich mit etwas infiziert.

Ich krieg’s einfach nicht hin mit git und den Zeilenenden.

Jetzt bleiben die Dateien beim Pull und Push wie sie sind – keine Konvertierung mehr. Das ist gut.

Aber die Diffs sind Schrott. Irgendwie wird ausschließlich mit einer Version gedifft, die CR+LF als Zeilenende benutzt. Und damit ist eben JEDE Zeile geändert und ich sehe nur einen riesigen roten Block und danach einen riesigen grünen.

Wenn ich dann pushe und mir das Diff des Pushes ansehe, ist wieder alles richtig – beides hat das gleiche Zeilenende. Aber wenn ich *vor* dem push diffe (egal ob staged oder nicht), nutzt die Repo-Version angeblich immer CR+LF und dann ist halt alles Schrott.

Tage, die mich git bisher gekostet hat: 4
Tage, die ich gegenüber einem nackten Verzeichnis gespart habe: 0

Nun google ich mal die exakte technische Bedeutung von Remote Repository, Local Repository, Staging Area und Working Directory sowie die Implikationen ihrer Wechselwirkung auf Zeilenenden. Denn offensichtlich sind das technische Konzepte, mit denen man bis ins Detail vertraut sein muss, wenn man einem Projekt eine Datei hinzufügen möchte.

Joah. Parallel solltest du dir halt auch echt einen diff-Viewer installieren, der Newline-Changes ignorieren kann (ich benutze tortoise-git). Dadurch wird aus "ich kann unmöglich weiter arbeiten, bis dieses Problem gelöst ist" ein "meh, wäre nett, wenn das in den nächsten paar Monaten mal gefixt werden könnte".

Wenn man in die USA Reisen möchte und einen die verschärften Sicherheitsbestimmungen nerven, kann man sich gegen Gebühr für das Global Entry Programm anmelden. Gegen eine weitere Gebühr (85$) kann man sich dann für TSA-Pre Check registrieren und darf fortan seinen Gürtel in der Hose und seinen Laptop in der Tasche lassen. Und sogar Flüssigkeiten mitnehmen. Kannst du dir nicht ausdenken. #Capitalism.

Battletech. War im Humblebundle. Ladezeiten von mehreren Minuten für ein Level. Auch bei neustart des Levels (was eigentlich gar keine Ladezeiten haben dürfte). Mag sein, dass RAM langsam ein bisschen schmal wird hier, aber das Spiel hat gar keinen Grund mehr als 8GB RAM zu verbrauchen. Es ist offensichtlich einfach bescheiden programmiert.