Seite 199 von 254
Re: Jammer-Thread
Verfasst: 15.12.2019, 22:22
von Krishty
Oh wow, das ist ja echt die Kirsche auf dem Scheißhaufen.
Die
Photos-App, die genutzt wird, um Bilder anzuzeigen, rendert alle Bilder verschwommen. Ich habe gestochen scharfe PNGs, aber sobald ich sie anzeige, sind sie Matsch.
Auf die Ursache wäre ich NIE gekommen:
https://www.reddit.com/r/Windows10/comments/ajms87/microsoft_photos_app_shows_sharp_images_as_blurry/ hat geschrieben:It has to do with the relationship between the width/height of the Photos window and the width/height of the image.
Photos tries to center the image in the window/canvas, but with no consideration to keeping the image aligned to the pixel grid. So if the width or height of the image are not both an even number of pixels or both an odd number of pixels, the image is not aligned to the grid when centered and displays as blurry.
WHAT THE ACTUAL FUCK?! Das Problem, zu dem jeder Möchtegern-2D-Spieleprogrammierer auf ZFX seit 1999 einen Thread eröffnet hat? DAS HABEN SIE NICHT GELÖST GEKRIEGT?!
An dieser Stelle könnte man berechtigterweise fragen, ob Windows 10 so heißt, weil es von Zehnjährigen programmiert wurde. Aber gehen wir doch einen Schritt zurück.
Phtotos ist eine App. Als solche baut sie nicht mehr auf Win32s GDI auf, sondern auf UWP. UWPs Grundgedanke ist, eine App einmal zu schreiben und auf jedem Smartphone/Computer/Tablet ausführen zu können.
Darum arbeitet UWP nicht mit Koordinatensystemen in Pixeln, sondern in logischen Einheiten. Ausführliche Beschreibung:
https://docs.microsoft.com/de-de/window ... d-ui-intro
… und weil es nicht in Pixeln arbeitet, lag es den Entwicklern offensichtlich auch fern, irgendwas pixelgenau ausrichten zu können. Das Ganze ist also by-design. Eine App, die Pixel auf den Bildschirm blitten soll, schafft das by-design nicht pixelgenau. Das muss man sich auf der Zunge zergehen lassen.
Durch ein paar Registry-Schlüssel kann man sich die Windows 7-Fotogallerie wiederherstellen:
https://www.howtogeek.com/225844/how-to ... indows-10/
Die hat natürlich auch ihre Tücken (kein Light/Dark Theme; keine Filterung beim Zoom), aber immerhin besser als der App-Scheiß.
Re: Jammer-Thread
Verfasst: 16.12.2019, 09:29
von Chromanoid
Apropos, das Bildbetrachten regt mich schon seit einiger Zeit in Windows auf. Genau aus solchen Gründen. Die Photos-App verliert auch ständig den Zeiger auf die Sicht im Explorer, so dass man nicht mehr mit den Pfeiltasten durch die Dateiliste navigieren kann. Der alte Viewer ist da besser, sieht aber hässlich aus und verkraftet, wenn ich das richtig im Kopf habe, nicht richtig mit unterschiedlichen DPI-Zahlen bei mehreren Bildschirmen.
Gibt es einen schlanken Viewer, der das zuverlässig kann?
Re: Jammer-Thread
Verfasst: 16.12.2019, 12:24
von mrz
Nutze seit jeher IrfanView, vorallem wegen dem Thumbnail View.
Re: Jammer-Thread
Verfasst: 17.12.2019, 12:17
von Thoran
Kämpfe seit einigen Tagen mit der Partikeleffekt-basierten Explosion meiner Gegner in meinem Top-Down-Shooter in Unreal 4. Auf dem PC alles gut, auf dem Mobile Preview mit Featureset ES31 alles gut. Nur auf meinem Handy vom März dieses Jahres, leider keine Explosionen. DIe Hardwarediversität in Android ist schon nervig. :-|
Re: Jammer-Thread
Verfasst: 17.12.2019, 14:06
von DerAlbi
Neuer PC und damit endlich der Umstieg auf Linux. Mint als Einsteiger-Distro.
Der Anfang ist sehr holprig. Man gewöhnt sich aber relativ schnell. Die Lernkurve ist steil, aber man muss auch viel lernen.
Ich habe leider große Probleme mit dem Hardware-Support. Mein optischer Sound-Ausgang z.B. geht überhaupt nicht und das Audio-system von Linux ist irgendwie generell FUBAR.
Meine Grafikkarte (RX 5700XT) wird (zur Zeit) nur von unterentwickelten Opensource-Treibern von AMD untersützt. In meinem 3-Monitor-System ist der mittlere ein 144Hz-Monitor mit AMD-FreeSync. Hängt man den an die AMD-GraKa passiert was? Genau. Die DP1.2 Übertragung ist im Eimer und der Bildschirm bekommt vertikale Streifen. Geschieht auch, wenn man auf DP1.1 downgraded, oder den Monitor über HDMI anschließt. Auf screenshots sind die Pixelfehler nicht da. JA, die AMD-Software, die auf einen AMD-Prozessor läuft, um eine AMD-Grafikkarte anzusteuern, der mit einem AMD-FreeSync-Monitor verbunden ist, geht nicht.
Irgendwie ist man auch auf Linux vor dem Corporate-Bullshit nicht sicher. Linux hat nur eine kleine Nutzerbasis, also bekommt es keine Liebe von den Firmen.
Ansonsten bin ich zufrieden. Compilieren ist bei mir Faktor 3x schneller und die Eclipse IDE ist das erste mal nicht deprimierend verkorkst langsam und träge. Linux ist definitiv für Entwickler besser; jetzt weiß ich, woher diese Meinungen stammen. Ich weiß aber auch angesichts der Probleme, warum Leute meinen, dass man für Linux eher entwickler sein muss... da soll sich viel getan haben.. aber das ist nicht meine Erfahrung.
Re: Jammer-Thread
Verfasst: 17.12.2019, 14:39
von Chromanoid
Der Hauptgrund für die bessere Performance unter Linux ist übrigens meinen Erkenntnissen nach ntfs unter Windows... falls du mal Langeweile hast würde mich interessieren ob davon was hilft:
http://www.ntfs.com/ntfs_optimization.htm
Re: Jammer-Thread
Verfasst: 17.12.2019, 15:13
von Matthias Gubisch
Die Beschreibung von DerAlbi ist doch genau der Grund warum sich Linux so schwer tut mit der Verbreitung.
Wenn meine Hardware erstmal nicht tut und ich schon mal "Expertenwissen" brauch um das ganze vielleicht zum Laufen zu bekommen dann hat der Druchschnittsanwender doch schon keine Lust mehr. Vor allem weils dann oft bei der SW weitergeht dass man sich um hunderte abhaengigkeiten kuemmern muss damit die Anwendung auf der eigenen Distro laeuft wenn man nicht 0815 Standard config verwenden kann/will.
Ich selbst bin da auch ned besser, Windows hat viele Macken, aber gewisse Dinge um die ich mich nicht kuemmern will (wie zum Beispiel anstaendige Treiber fuer Grafikkarten) funktionieren da halt einfach und man hat den Kopf dann frei fuer die eigentlichen Projekte.
Das OS soll mich in meiner Arbeit unterstuetzen und nicht mir Arbeit machen und da sehe ich aktuell deutlich den Vorteil bei Windows..
Re: Jammer-Thread
Verfasst: 18.12.2019, 11:26
von Krishty
Chromanoid hat geschrieben: ↑17.12.2019, 14:39
Der Hauptgrund für die bessere Performance unter Linux ist übrigens meinen Erkenntnissen nach ntfs unter Windows... falls du mal Langeweile hast würde mich interessieren ob davon was hilft:
http://www.ntfs.com/ntfs_optimization.htm
Nö, das ist von vorne bis hinten veraltet:
- Das mit der Fragmentierung wurde schon zu Vista-Zeiten verbessert.
- Dass der MFT fragmentiert, ist seltene Ausnahme. Das habe ich im Jahrzehnt erst ein paar Dutzend Mal gesehen, und dann war der MFT auch nur in zwei oder *erschreck* DREI Teile fragmentiert.
- Die Fragmentierung der Paging File ist Quark, denn die wird vom System angelegt. Dafür müsste die Platte schon richtig voll sein.
- Access Updates wurden mit Vista abgeschafft.
- 8.3 Names wurden mit 10 abgeschafft (zumindest bei einem Teil der Kunden).
Da wir nun wissen, was es
nicht ist, können wir ja schauen,
was es sein könnte:
Albi hat geschrieben:Compilieren ist bei mir Faktor 3x schneller
Krishty hat geschrieben:Der Defender wird ständig wider meines Willens wieder eingeschaltet. Damit sinkt die Leistung bei git pull um mindestens die Hälfte; bei 7-Zip um zwei Dritten (57 statt 21 Minuten!)
Zufall?
Ein weiterer Grund, warum Linux beim Kompilieren schneller ist, dürfte die schnellere Erzeugung von Prozessen sein. Ein Compiler wird schließlich pro Quelldatei einmal aufgerufen und dann wieder beendet.
Da fallen einem zwar als erstes Microsofts Komfort- und Spionageaspekte ein:
- Vor dem Start jeder Anwendung wird auf Kompatibilitätseinstellungen geprüft
- und auf bestimmte Lokalisierung
- Shims alter Windows-Versionen werden angewandt
- Eine Liste aller gestarteten Programme wird an Microsoft gesendet
aber des Pudels Kern ist das komplett unterschiedliche Prozessmodell:
- fork()/exec() in Linux, mit Hardware-Unterstützung da der Großteil über virtuellen Speicher geregelt ist
- ein blanker neuer Prozess in Windows, der erstmal aufwändig mit Adressraum und Kernelmodulen befüllt werden muss.
Aber Linux hat eben auch einen risen Nachteil bei der Programmierung: Den Debugger.
gdb ist der größte Haufen Scheiße, den ich zwischen Entwicklungs-Tools gesehen habe. Ich könnte den ganzen Tag lang aufzählen, was
nicht funktioniert: Das Setzen von Haltepunkten, das Endlosschleifen auslöst; das Anspringen optimierter Zeilen, das schlicht Glückssache ist; das Setzen von Speicher-Haltepunkten, die mal funktionieren und dann wieder nicht – und wenn nicht, dann weiß man nicht, ob der Wert nicht geändert wurde oder gdb wieder Durchfall hat. Dazu die Abstürze, die Hänger (die dann die IDE direkt mitreißen – egal, ob Eclipse oder Qt Creator) und die Linux-Philosophie, alles als Text aus dem Debuggerprozess zur IDE zu pipen (was die Anzeigerate auf ein paar tausend Elemente pro Sekunde limitiert – also Einzelschritt unbrauchbar macht, sobald ein großes Array im Scope ist).
Wenn ich unter Linux was debuggen soll, mache ich mittlerweile lieber wieder
printf() oder versuche, das Problem unter Windows zu reproduzieren – alles viel schneller als
gdb zu bemühen.
Re: Jammer-Thread
Verfasst: 18.12.2019, 14:14
von Chromanoid
@Krishty Danke für den Hinweis. Ich muss wohl doch noch mal einen Test der Build-Performance "wirklich ganz ohne Virenscanner" anberaumen... Bei meinem Arbeitgeber kann man den Unterschied nämlich sehr schön sehen, da der gleiche Java-Gradle-Build unter Linux und Windows auf Build-Servern ausgeführt werden kann. Das mit den Prozessen sollte da keine Auswirkung haben. Ich war bisher immer davon ausgegangen, dass es an NTFS liegt, da ein Verpacken der class-Files in JAR-Archive immer einen signifikanten Performance-Gewinn unter Windows gebracht hat, unter Linux nicht... Aber das kann natürlich an einem "on access" Virenscanner liegen, allerdings wurde mir beim letzten Test versichert, dass nichts dergleichen aktiviert ist...
Re: Jammer-Thread
Verfasst: 24.12.2019, 22:59
von Krishty
Chromanoid hat geschrieben: ↑18.12.2019, 14:14@Krishty Danke für den Hinweis. Ich muss wohl doch noch mal einen Test der Build-Performance "wirklich ganz ohne Virenscanner" anberaumen... Bei meinem Arbeitgeber kann man den Unterschied nämlich sehr schön sehen, da der gleiche Java-Gradle-Build unter Linux und Windows auf Build-Servern ausgeführt werden kann. Das mit den Prozessen sollte da keine Auswirkung haben. Ich war bisher immer davon ausgegangen, dass es an NTFS liegt, da ein Verpacken der class-Files in JAR-Archive immer einen signifikanten Performance-Gewinn unter Windows gebracht hat, unter Linux nicht... Aber das kann natürlich an einem "on access" Virenscanner liegen, allerdings wurde mir beim letzten Test versichert, dass nichts dergleichen aktiviert ist...
Formatier doch mal mit FAT32 statt NTFS. Der Build müsste ja noch immer gehen, sofern du nicht strikt auf Rechtevergabe angewiesen bist, und du müsstest den NTFS-Overhead als Differenz messen können.
————
Habe ich recht verstanden, dass
make Leerzeichen in Dateinamen nur „unter sehr großer Anstrengung“ unterstützt? In welchem Jahr lebt Linux eigentlich, 1993?
Re: Jammer-Thread
Verfasst: 25.12.2019, 09:52
von xq
Krishty hat geschrieben:Habe ich recht verstanden, dass make Leerzeichen in Dateinamen nur „unter sehr großer Anstrengung“ unterstützt? In welchem Jahr lebt Linux eigentlich, 1993?
Wenn es für dich zu "großer Anstrengung" gehört, entweder das Leerzeichen zu escapen: Dann ja.
Ansonsten schau mal hier:
Re: Jammer-Thread
Verfasst: 25.12.2019, 10:37
von Krishty
xq hat geschrieben: ↑25.12.2019, 09:52Wenn es für dich zu "großer Anstrengung" gehört, entweder das Leerzeichen zu escapen: Dann ja.
Weil ich out-of-source kompiliere, das Zielverzeichnis also wo anders liegt, ist es eine Variable. Jetzt darf ich innerhalb deren Wertes escapen, geil!
Wenn es denn überhaupt funktioniert. Microsofts Make schluckt das schonmal nicht.
Re: Jammer-Thread
Verfasst: 27.12.2019, 20:45
von Jonathan
Windows kann ja nur 15 ShellIconOverlayIdentifiers, aber die meisten Tools wie tortoiseGit oder alles was irgendwie mit Cloud zu tun haben belegen in der Regel mindestens ein halbes dutzend davon - so dass man effektiv höchstens 2 Tools mit funktionierenden Icons haben kann. Weil die Priorität nach der alphabetischen Sortierung geht, gibt es einen Kampf wer mehr Sonderzeichen an den Anfang setzen kann um in der Liste ganz vorne zu stehen.
Meine TortoiseGit Icons die alle mit zwei Leerzeichen anfangen wurden gerade von dem neuen Seafile-Update besiegt - die mit einer Kombination aus 3 Leerzeichen, Anfürungszeichen sowie Punkt in die Schlacht ziehen. Was für egoistische Würstchen programmieren eigentlich diese Installer denen scheißegal ist ob der Rest des Systems danach noch funktioniert, hauptsache die eigenen Icons werden angezeigt? Alles nur damit die Supportanfragen an jemand anderen gehen oder wie? Und wer denkt sich einen so saudummen Präfix aus? Wenn man schon 5 Zeichen verwendet, wieso ist man dann nicht wenigstens effizient und benutzt immer das beste (-> am weitesten vorne stehende)? Das ist doch alles ein großer Quatsch...
Und warum schaffen es die, uhm, Menschen von Microsoft immer neue Telemetriescheiße zu implementieren, aber elementare und vollkommen absurde Einschränkungen werden über Dekaden nicht gepatcht? Und was habe ich überhaupt der Welt schlimmes angetan, dass sich scheinbar alle gegen mich verbündet haben und mich mit ihren mutwillig schlechten Lösungen dazu zwingen meine wertvolle Arbeitszeit in sinnlose Internetrants zu verschwenden?
Die Alternative wäre ja, sich ein kleines Tool zu schreiben, mit denen man derlei Wildwüchse bequem neu sortieren kann. Aber das dauert wieder zwei Stunden und irgendwie bin ich immer zu faul dafür und mache es dann doch wieder per Hand (so alle 1-2 Monate einmal, und das seit Jahren...). Nerv.
(Dabei fällt mir gerade ein, dass man genau das als Installer-Plugin vertreiben könnte. Das wäre dann nämlich die eigentlich korrekte Lösung: Darauf hinweisen, dass es ein Problem gibt dass Microsoft sich weigert zu patchen und dann dem Benutzer die Möglichkeit geben selbst zu entscheiden welche Icons welcher aktuell installierten Programme er sehen möchte.)
Re: Jammer-Thread
Verfasst: 28.12.2019, 13:16
von joggel
@Jonathan
Ich habe es gelesen. Verstanden. Und reflektiert.
Und ich kam zu der Erkenntnis, dass es mir ebenfalls Schmerzen bereitet...
Ich fühle mit dir :'(
Re: Jammer-Thread
Verfasst: 28.12.2019, 17:13
von Krishty
Einer der besten Rants hier … als ich auf Old New Thing zum ersten Mal von den 15 Overlay-Icons las, dachte ich zuerst, es wäre ein Scherz …
Re: Jammer-Thread
Verfasst: 29.12.2019, 11:23
von LaBerg
Das gehört zur selben Sorte Einschränkungen wie die 255 Zeichen bei der Pfadlänge. Die führen insbesondere bei Fileservern regelmäßig zu Schimpftriaden, weil man dank Laufwerksmapping problemlos längere Pfade erzeugen kann. Auf dem Server selbst, kann man dann aber mit dem Explorer nicht mehr in die Pfade navigieren und Backupsoftware hat damit auch so seine liebe Not...
Man kann zwar Möglichkeiten aktivieren, um auf solche Pfade mit spezieller Syntax im Explorer zu zugreifen, aber standardmäßig geht das nicht. Mal davon abgesehen, dass es die Standardklassen z.B. in .NET auch nicht mit den langen Pfaden umgehen können. Und wenn es die Standardfunktionen nicht hergeben, kann es in der Regel Software von anderen Anbietern auch nicht.
Re: Jammer-Thread
Verfasst: 29.12.2019, 11:39
von Tiles
Re: Jammer-Thread
Verfasst: 29.12.2019, 12:03
von LaBerg
Na das wäre ja mal was, wenn es ab Win10 Kernel eine vernünftige Lösung gibt. Das wäre dann bei den Serversystemen ab Server 2016... Leider waren das meiste, wo geflucht wurde 2008 Server, die zwecks Supportende migriert werden mussten....
Wie gesagt das tolle ist, man kann die langen Pfade ja schon immer anlegen, aber man kann dann lokal nicht mehr darauf zugreifen.
Wenn man einen Pfad hat:
\\SERVER\SHARE\Mein\toller\ganz\langer\Pfad\ und sich den beispielweise als Z:\ verbindet, kann man ab dort wieder die 260 Zeichen Pfladlänge anlegen nur lokal auf dem Server kommt man in das Verzeichnis nicht mehr rein.
Re: Jammer-Thread
Verfasst: 30.12.2019, 09:49
von Tiles
Ich habe den schnellsten Computer ever. Aber das Right Click Menü auf ein Item in der Taskleiste ist langsamer und träger als auf meinem ersten PC von 1997. Danke Microsoft.
Re: Jammer-Thread
Verfasst: 30.12.2019, 13:06
von scheichs
https://plundervolt.com/
Intel hat bereits BIOS-Microcode für die Hersteller bereitgestellt, welches Undervolting verhindert. Ich habe ein Dell XPS 15. Ohne Undervolting ist das Gerät sustained nur eingeschränkt nutzbar (ist eine 1050TI drin). Ich habe mal System-Updates im Dell Manager deaktiviert. Hoffentlich hilft's. Vllt gibt's hier noch den ein oder anderen mit Intel-Notebook, der seinen Prozessor auch undervolted betreibt.
Re: Jammer-Thread
Verfasst: 04.01.2020, 10:06
von Jonathan
Ich wollte gerade VS2019 deinstallieren wurde aber gezwungen erst ein 80 MB Update für den Installer zu installieren, bevor ich das Produkt, dass ich mit dem Installer installiert hatte deinstallieren konnte. In was für einer Welt leben wir eigentlich??
Re: Jammer-Thread
Verfasst: 09.01.2020, 13:11
von Tiles
Meine alte Drupal 7 Seite fliegt auseinander. Ich fange schon an Module abzuschalten weil sie nicht mehr mit der neuesten PHP Version funktionieren oder anderweitig streiken. Und mit jedem Update fällt die Seite ein wenig mehr auseinander. Also muss ich eine neue Seite bauen. Das Problem: Wordpress hat alle anderen CMS platt gemacht. Auch Drupal. Version 8 wäre ein Downgrade und ist eh ein komplett neues CMS. Die haben noch nicht mal eine wirklich funktionierende Upgrade Lösung. Drupal ist EOL. Und selber von Null auf bauen, mit Community und CMS Features? Nee, so alt werde ich nicht mehr.
Also fluche ich mich gerade durch eine Wordpress Installation. Mal ein paar Schmankerl: Drupal 7 Ladegrösse der Seite: 70 Kb. Wordpress Ladegrösse der Seite 1 Mb. Ohne Bilder versteht sich. Und ich habe noch nicht mal viele Plugins an. Und natürlich auch schon alles gecached. Das Ding ist inzwischen Bloat Pur. Und das in Wordpress gehardcodete Gravatar ist auch so ein nettes Wordpress Geschenk. Absolut nicht DSGVO konform, und ohne Holzhammer nicht zu erlegen -.-
Re: Jammer-Thread
Verfasst: 09.01.2020, 15:51
von Thoran
Also ich betreibe meine Seite mit Joomla, das auch noch Updates erhält. Vielleicht ein Blick wert, wenn Du Wordpress nicht magst
Re: Jammer-Thread
Verfasst: 09.01.2020, 17:52
von Tiles
Ja, danke für den Tip. Alles schon durchprobiert, inklusive Typo3, Contao und auch so Exoten wie OctoberCMS oder ein auf Communities spezialisiertes CMS das sich die Wurzeln mit Wordpress teilt. Selbst den PHP Framework Laravel habe ich mir schon angesehen. Aber wie gesagt selber bauen, dafür werde ich einfach nicht mehr alt genug.
Eine blanke statische Seite kann man ja zur Not auch über pures HTML und ein wenig PHP lösen. Oder über einen der Page Builder ohne Programmierkenntnisse. Aber ich brauche eine Communitylösung. Forum, PM, Freundschaften, Bilderverwaltungen, Avatar und so weiter. Und da wirds mit den anderen Lösungen sehr schwierig. Drupal war für mich seinerzeit die optimale Lösung. Damit ging sehr viel. Nur haben sie das mit Drupal 8 kaputtrepariert. Es gibt kein brauchbares Forum mehr, und die Anzahl der Module ist insgesamt stark geschrumpft. Du merkst dass die Leute da immer weniger motiviert sind. Und Drupal 7 fällt wie gesagt auseinander. Zu alt. Wordpress ist zwar bloatet, aber du findest halt echt für jeden Mist ein Plugin. Und damit bekomme ich die Seite so hin wie ich sie brauche. Nur gefallen tuts mir halt trotzdem nicht :D
Re: Jammer-Thread
Verfasst: 09.01.2020, 22:01
von Chromanoid
https://redaxo.org/ mal getestet? Ah vergiss, das Community-Zeug scheint immer noch nicht fertig zu sein.
Re: Jammer-Thread
Verfasst: 10.01.2020, 08:17
von Tiles
Ah, das kannte ich noch nicht, aber ich hab sie gefühlt echt alle durch :D
Das Problem mit den Exoten ist halt, wenn dir auch nur ein Baustein fehlt dann wars das meist. Bei Wordpress hast du für den gleichen Zweck dutzende Plugins die du durchtesten kannst. Das Ökosystem ist echt gigantisch inzwischen.
Re: Jammer-Thread
Verfasst: 12.01.2020, 01:07
von Krishty
Visual Studio kann bei git keine Submodules. Es kann sie einmalig abholen, aber Änderungen werden nicht verarbeitet, weder upstream noch downstream.
Ja, äh … wofür ist es dann überhaupt zu gebrauchen?! Ich dachte, die meisten Projekte hätte irgendwo eine Abhängigkeit?
https://devblogs.microsoft.com/devops/new-git-features-in-vs2017-update-5/ hat geschrieben:Visual Studio now treats Git submodules and Git worktrees like normal repos. Just add them to your list of Local Repositories on the Team Explorer Connect page and get coding! Please note that you still cannot do anything that requires multi-repo support (such as viewing files in a parent repo and a submodule at the same time). If you would like multi-repo support, please
vote on UserVoice.
Der Link ist tot.
Nachtrag: Ach guck:
Vor zwei Wochen geschrieben. Dann kann es ja nur noch fünf Jahre dauern!
Re: Jammer-Thread
Verfasst: 15.01.2020, 21:24
von Krishty
Krishty hat geschrieben: ↑05.10.2019, 13:48git for Windows zerstört alle line feeds als wär’s 1993 (via
core.autocrlf).
Heutiges Opfer ist … Media Player Classic.
https://github.com/clsid2/mpc-hc/commit ... 571f2e4a49
Aber damit das hier nicht
nur Jammern ist: Ich war enttäuscht, dass git es nicht hinkriegt, meine Dateien in einen Unterordner zu schieben, sondern jedes
git mv als
git remove, git add auffasst. Dann habe ich mir Linus’ Rant durchgelesen, dass das beabsichtigt ist, um Änderungen besser verfolgen zu können:
https://web.archive.org/web/20160304045 ... ol.git/217
… und das ergibt tatsächlich Sinn.
Re: Jammer-Thread
Verfasst: 16.01.2020, 11:30
von Tiles
CSS! :'3
Re: Jammer-Thread
Verfasst: 16.01.2020, 21:40
von Krishty
PowerShell.
Ich habe einen Haufen alter Batch-Skripte, und wollte den Windows-10-Umstieg mit einem PowerShell-Umstieg kombinieren, weil auch Visual Studio langsam in Richtung PowerShell umsteigt. Aber …
Fucking Bullshit. Das Drecksteil braucht auf meinem nagelneuen Rechner an die fünf Sekunden zum Starten; warm sind es noch zwei. Das bedeutet: 192,000,000,000 Rechenzyklen – für sowas würde mein erster PC 20 Sekunden brauchen.
Zum Öffnen einer leeren Konsole. Dann läuft das Teil mit 40 MiB Working Set
bevor ich auch nur die erste Taste gedrückt habe. Weil natürlich das halbe .NET-Framework drin hängt (und das erklärt auch die Startzeit). Und dabei hat’s
andere wohl noch schlimmer getroffen.
CMD startet in 0 Sekunden bei unter 7 MiB Arbeitssatz.
Wer hat den Leuten eigentlich ins Hirn geschissen?! Wie bescheuert kann man sein, sowas zu entwickeln und es dann auch noch jedem aufzuzwingen, indem man es voreinstellt?! Ist das versteckte Kamera?!
Alle feuern und auf ReactOS umsteigen.