{
"version": "https://jsonfeed.org/version/1.1",
"user_comment": "This feed allows you to read the posts from this site in any feed reader that supports the JSON Feed format. To add this feed to your reader, copy the following URL -- https://tuxproject.de/blog/2014/05/github-auf-zum-atom/feed/json/ -- and add it your reader.",
"home_page_url": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/",
"feed_url": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/feed/json/",
"language": "de",
"title": "Comments on: GitHub: Auf zum Atom?",
"description": "Relevanz auf Halbmast.",
"icon": "https://tuxproject.de/blog/wp-content/uploads/2017/05/cropped-penrose.png",
"items": [
{
"id": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75787",
"url": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75787",
"content_html": "Als Antwort auf simonszu.\n\nNat\u00fcrlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also k\u00f6nnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.
\n\nNehmen wir mal die beiden Editoren (aktuelle \"finale\" Versionen) ohne Extraplugins.\n\nBloat von Emacs: Ein Psychotherapeutenskript. Hui.\nBloat von Atom: Chromium, das allein \u00fcber 100 MiB des Downloads ausmachen d\u00fcrfte.\n\nM\u00f6chtest du das in LoC haben oder gen\u00fcgt es dir auch so?\n\nmacht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett.
\n\nWie gesagt: Dann nutz' doch Eclipse, das kann auch alles, hat keinen Webbrowser, braucht ewig zum Laden und frisst RAM wie bl\u00f6de, aber sind ja nicht mehr die 80er, man muss ja mit der Zeit gehen.\n\nAuf deinem Screenshot war klar ein OS mit GUI zu sehen, vermutlich ein Windows. Wieviel Speicher verbraucht das denn so, wenn es gestartet und eingeloggt ist, aber sonst keinerlei Dienste im Hintergrund laufen?
\n\nVariiert. (Irgendwelche Dienste laufen ja immer.)\n\nEmacs l\u00e4uft \u00fcbrigens auch ohne GUI (die ersten Versionen hatten gar keines, dein Vergleich ist also gar keiner). Und Atom so?\n\nAtom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verf\u00fcgbaren Hauptspeichers ben\u00f6tigt.
\n\nJedenfalls die von dir selbst kompilierte Version - das kann stark variieren. Und: RAM-Gr\u00f6\u00dfe w\u00e4chst exponenziell, Menge an Editorfunktionen aber nicht. \u00dcberdenk' die Aussage. ;) (Und: GB? Nicht eher MB?)\n\nAber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB gro\u00df ins Gewicht fallen w\u00fcrde.
\n\n\"Wir haben mehr RAM, also belegen wir den auch, obwohl wir auch mit weniger RAM mehr Funktionen haben k\u00f6nnten! Weil wir ein neues Jahrtausend haben!\"\n\nIrgendwo fehlt mir da die Kausalit\u00e4t.\n\nAber wenn man sich mal die Dependencies eines emacs anguckt\u2026 libc6, libncurses, libpng, libtextbuf, libpango, die zlib\u2026
\n\nDas sind deutlich weniger \"Dependencies\" als der Chromium-Quatsch allein besitzt, der in Atom drin ist. \u00dcbrigens ist zum Beispiel die libpng optional - hast du sie nicht, gehen halt keine Inline-PNGs. (Ich w\u00fcrde das nur im Twittering-Mode \u00fcberhaupt bemerken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abh\u00e4ngigkeit fehlt? Nein, lass' mich raten ... streiken, richtig?\n\nDie Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit.
\n\nncurses in einem CLI-Editor: Sinnvoll.\nWebkit in einem Editor: Wof\u00fcr, zum heiligen Henker?!\n\n\u00c4pfel. Birnen. Wie immer.\n\nDas h\u00e4tte man ja auch besser l\u00f6sen k\u00f6nnen, mit ner nativen Anzeigeengine
\n\nH\u00e4tte sich super auf die Portabilit\u00e4t ausgewirkt. Bemerkt man gerade bei Atom.\n\nzu dem Spywarevorwurf..ja klar, ist aber deaktivierbar
\n\n\"Da hat zwar wer reingekackt, aber wenn man nach dem Reintreten alles sauber wischt, merkt man es gar nicht mehr.\"\n\nSuper!",
"content_text": "Als Antwort auf simonszu.\n\nNat\u00fcrlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also k\u00f6nnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.\n\nNehmen wir mal die beiden Editoren (aktuelle \"finale\" Versionen) ohne Extraplugins.\n\nBloat von Emacs: Ein Psychotherapeutenskript. Hui.\nBloat von Atom: Chromium, das allein \u00fcber 100 MiB des Downloads ausmachen d\u00fcrfte.\n\nM\u00f6chtest du das in LoC haben oder gen\u00fcgt es dir auch so?\n\nmacht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett.\n\nWie gesagt: Dann nutz' doch Eclipse, das kann auch alles, hat keinen Webbrowser, braucht ewig zum Laden und frisst RAM wie bl\u00f6de, aber sind ja nicht mehr die 80er, man muss ja mit der Zeit gehen.\n\nAuf deinem Screenshot war klar ein OS mit GUI zu sehen, vermutlich ein Windows. Wieviel Speicher verbraucht das denn so, wenn es gestartet und eingeloggt ist, aber sonst keinerlei Dienste im Hintergrund laufen?\n\nVariiert. (Irgendwelche Dienste laufen ja immer.)\n\nEmacs l\u00e4uft \u00fcbrigens auch ohne GUI (die ersten Versionen hatten gar keines, dein Vergleich ist also gar keiner). Und Atom so?\n\nAtom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verf\u00fcgbaren Hauptspeichers ben\u00f6tigt. \n\nJedenfalls die von dir selbst kompilierte Version - das kann stark variieren. Und: RAM-Gr\u00f6\u00dfe w\u00e4chst exponenziell, Menge an Editorfunktionen aber nicht. \u00dcberdenk' die Aussage. ;) (Und: GB? Nicht eher MB?)\n\nAber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB gro\u00df ins Gewicht fallen w\u00fcrde. \n\n\"Wir haben mehr RAM, also belegen wir den auch, obwohl wir auch mit weniger RAM mehr Funktionen haben k\u00f6nnten! Weil wir ein neues Jahrtausend haben!\"\n\nIrgendwo fehlt mir da die Kausalit\u00e4t.\n\nAber wenn man sich mal die Dependencies eines emacs anguckt\u2026 libc6, libncurses, libpng, libtextbuf, libpango, die zlib\u2026\n\nDas sind deutlich weniger \"Dependencies\" als der Chromium-Quatsch allein besitzt, der in Atom drin ist. \u00dcbrigens ist zum Beispiel die libpng optional - hast du sie nicht, gehen halt keine Inline-PNGs. (Ich w\u00fcrde das nur im Twittering-Mode \u00fcberhaupt bemerken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abh\u00e4ngigkeit fehlt? Nein, lass' mich raten ... streiken, richtig?\n\nDie Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. \n\nncurses in einem CLI-Editor: Sinnvoll.\nWebkit in einem Editor: Wof\u00fcr, zum heiligen Henker?!\n\n\u00c4pfel. Birnen. Wie immer.\n\nDas h\u00e4tte man ja auch besser l\u00f6sen k\u00f6nnen, mit ner nativen Anzeigeengine\n\nH\u00e4tte sich super auf die Portabilit\u00e4t ausgewirkt. Bemerkt man gerade bei Atom.\n\nzu dem Spywarevorwurf..ja klar, ist aber deaktivierbar\n\n\"Da hat zwar wer reingekackt, aber wenn man nach dem Reintreten alles sauber wischt, merkt man es gar nicht mehr.\"\n\nSuper!",
"date_published": "2014-05-08T22:08:46+02:00",
"authors": [
{
"name": "tux0r",
"url": "http://tuxproject.de",
"avatar": "data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB2aWV3Qm94PSIwIDAgNTAgNTAiPgoJPHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iMSIvPgoJPHRleHQKCQlmaWxsPSIjZmZmIgoJCWZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIgoJCWZvbnQtc2l6ZT0iMjYiCgkJZm9udC13ZWlnaHQ9IjUwMCIKCQlkb21pbmFudC1iYXNlbGluZT0ibWlkZGxlIgoJCXRleHQtYW5jaG9yPSJtaWRkbGUiCgkJeD0iNTAlIgoJCXk9IjU1JSIKCT4KCQlUCgk8L3RleHQ+Cjwvc3ZnPg=="
}
],
"author": {
"name": "tux0r",
"url": "http://tuxproject.de",
"avatar": "data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB2aWV3Qm94PSIwIDAgNTAgNTAiPgoJPHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iMSIvPgoJPHRleHQKCQlmaWxsPSIjZmZmIgoJCWZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIgoJCWZvbnQtc2l6ZT0iMjYiCgkJZm9udC13ZWlnaHQ9IjUwMCIKCQlkb21pbmFudC1iYXNlbGluZT0ibWlkZGxlIgoJCXRleHQtYW5jaG9yPSJtaWRkbGUiCgkJeD0iNTAlIgoJCXk9IjU1JSIKCT4KCQlUCgk8L3RleHQ+Cjwvc3ZnPg=="
}
},
{
"id": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75786",
"url": "https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75786",
"content_html": "Um also die Diskussion von Twitter fortzuf\u00fchren. Ich beziehe mich mal f\u00fcr die Definition von Bloatware auf die Wikipedia. \r\n\"Als Bloatware (engl. to bloat \u201eaufbl\u00e4hen\u201c), selten als Bl\u00e4hware oder Fatware[1], wird Software bezeichnet, die mit Funktionen \u00fcberladen ist bzw. die Anwendungen sehr unterschiedlicher Arbeitsfelder ohne gemeinsamen Nutzen b\u00fcndelt (siehe: eierlegende Wollmilchsau).\"\r\nNat\u00fcrlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also k\u00f6nnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.\r\n\r\nUnd zur Tatsache, dass du Bloat mit Speicherverbrauch gleichsetzt, nun: Atom verbraucht 30MB Speicher, ja. Aber in Anbetracht der Tatsache, dass du heutzutage kaum noch Computer mehr mit weniger als 4GB Speicher kaufen kannst, alleine weil das Betriebssystem so rumbloated, macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett. \r\nAuf deinem Screenshot war klar ein OS mit GUI zu sehen, vermutlich ein Windows. Wieviel Speicher verbraucht das denn so, wenn es gestartet und eingeloggt ist, aber sonst keinerlei Dienste im Hintergrund laufen? Mit Sicherheit mehr als 1% des Hauptspeichers, und dennoch nutzt du es, ohne dich selbst des Bloatings anzuklagen.\r\n\r\nDie Wurzeln von GNU emacs reichen bis 1984 zur\u00fcck, die Wurzeln von emacs als Macrosammlung bis 1976. Ich geh jetzt mal davon aus, dass die Punkte in den Zahlenangaben Dezimalpunkte sind, denn sonst h\u00e4ttest du den eleganten Speicherverbrauch von 50MB, und w\u00fcrdest dich selbst disqualifizieren. Nun, also eine Auslastung von 50kB. Legen wir dem Entwicklerteam von emacs mal einen guten Programmierstil zugegen, und behaupten, dass sich das Programm in den letzten 30 Jahren nicht signifikant aufgebl\u00e4ht hat (wie du schon sagtest, keine Bloatware). Ich geh mal davon aus, dass emacs in den 80er Jahren also mal so grob 45kB Hauptspeicher belegt hat. \r\n\r\nNun gehen wir mal, aus Gr\u00fcnden der Fairness, davon aus, dass ein hypothetischer User im Jahre '84 emacs auf seinem PC ausf\u00fchren wollte, und nicht auf irgendeinem Mainframe. In den 80er Jahren lag die typische Arbeitsspeichergr\u00f6\u00dfe irgendwo zwischen 64kB in einem C64 und 512kB in einem Amiga 500. Das hie\u00dfe: emacs hat kurz nach seinem initialen Release irgendwas zwischen 11 und 70% des damaly \u00fcblichen Sets an Hauptspeicher verbraucht. Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verf\u00fcgbaren Hauptspeichers ben\u00f6tigt. \r\n\r\nUnd du willst mir ernsthaft erz\u00e4hlen, Atom w\u00fcrde bloaten? Setze die Relationen, und \u00fcberdenk die Aussage.\r\n\r\nJa, nat\u00fcrlich, wir haben nicht mehr die 80er Jahre, also f\u00e4llt der Speicherverbrauch von 50kB nicht mehr so stark ins Gewicht. Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB gro\u00df ins Gewicht fallen w\u00fcrde. \r\n\r\nUnd dein anderes Argument, man m\u00fcsse eine komplette Browserumgebung laden, um ein Textfile editieren zu k\u00f6nnen, stimmt zwar, aber l\u00e4sst sich auch in Relationen setzen. Aber wenn man sich mal die Dependencies eines emacs anguckt... libc6, libncurses, libpng, libtextbuf, libpango, die zlib...man muss einmal die kompletten Libraries laden, um nur mal eben ein Textfile editieren zu k\u00f6nnen. Das h\u00e4tte man aber auch eleganter und weniger bloatend l\u00f6sen k\u00f6nnen, oder? Once again, check die Relationen. Die Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. Das h\u00e4tte man ja auch besser l\u00f6sen k\u00f6nnen, mit ner nativen Anzeigeengine, oder damals einfach alles statisch linken, oder kurzerhand selbst reinhacken k\u00f6nnen.\r\n\r\nZu deiner Mac-OS-Only-Argumentationen gibt es mittlerweile mehrere Builds f\u00fcr alle Systeme, auf denen Node l\u00e4uft, also d\u00fcrfte das auch widerlegbar sein, und zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar, und es soll ja Leute geben, deren Menge mit der Menge der Leute, die \u00fcber GA besorgt sind, relativ konjunkt ist, die einfach den Zugriff auf die Google-Analytics-Server in ihrer /etc/hosts (oder woauchimmer das betriebssystemspezifisch definiert wird) unterbunden haben, bzw den DNS-Record umgebogen haben, sodass ich mir \u00fcber das Problem ehrlich gesagt noch gar keine Gedanken gemacht habe.\r\n\r\nAber ich m\u00f6chte hier auch keinen Flame- oder Editor-War starten. Es m\u00f6ge jeder genau die Software nutzen, mit der er gl\u00fccklich wird. Wieso auch nicht?\r\n\r\nUnd \u00fcbrigens: Ich mag Wurst.",
"content_text": "Um also die Diskussion von Twitter fortzuf\u00fchren. Ich beziehe mich mal f\u00fcr die Definition von Bloatware auf die Wikipedia. \r\n\"Als Bloatware (engl. to bloat \u201eaufbl\u00e4hen\u201c), selten als Bl\u00e4hware oder Fatware[1], wird Software bezeichnet, die mit Funktionen \u00fcberladen ist bzw. die Anwendungen sehr unterschiedlicher Arbeitsfelder ohne gemeinsamen Nutzen b\u00fcndelt (siehe: eierlegende Wollmilchsau).\"\r\nNat\u00fcrlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also k\u00f6nnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.\r\n\r\nUnd zur Tatsache, dass du Bloat mit Speicherverbrauch gleichsetzt, nun: Atom verbraucht 30MB Speicher, ja. Aber in Anbetracht der Tatsache, dass du heutzutage kaum noch Computer mehr mit weniger als 4GB Speicher kaufen kannst, alleine weil das Betriebssystem so rumbloated, macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett. \r\nAuf deinem Screenshot war klar ein OS mit GUI zu sehen, vermutlich ein Windows. Wieviel Speicher verbraucht das denn so, wenn es gestartet und eingeloggt ist, aber sonst keinerlei Dienste im Hintergrund laufen? Mit Sicherheit mehr als 1% des Hauptspeichers, und dennoch nutzt du es, ohne dich selbst des Bloatings anzuklagen.\r\n\r\nDie Wurzeln von GNU emacs reichen bis 1984 zur\u00fcck, die Wurzeln von emacs als Macrosammlung bis 1976. Ich geh jetzt mal davon aus, dass die Punkte in den Zahlenangaben Dezimalpunkte sind, denn sonst h\u00e4ttest du den eleganten Speicherverbrauch von 50MB, und w\u00fcrdest dich selbst disqualifizieren. Nun, also eine Auslastung von 50kB. Legen wir dem Entwicklerteam von emacs mal einen guten Programmierstil zugegen, und behaupten, dass sich das Programm in den letzten 30 Jahren nicht signifikant aufgebl\u00e4ht hat (wie du schon sagtest, keine Bloatware). Ich geh mal davon aus, dass emacs in den 80er Jahren also mal so grob 45kB Hauptspeicher belegt hat. \r\n\r\nNun gehen wir mal, aus Gr\u00fcnden der Fairness, davon aus, dass ein hypothetischer User im Jahre '84 emacs auf seinem PC ausf\u00fchren wollte, und nicht auf irgendeinem Mainframe. In den 80er Jahren lag die typische Arbeitsspeichergr\u00f6\u00dfe irgendwo zwischen 64kB in einem C64 und 512kB in einem Amiga 500. Das hie\u00dfe: emacs hat kurz nach seinem initialen Release irgendwas zwischen 11 und 70% des damaly \u00fcblichen Sets an Hauptspeicher verbraucht. Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verf\u00fcgbaren Hauptspeichers ben\u00f6tigt. \r\n\r\nUnd du willst mir ernsthaft erz\u00e4hlen, Atom w\u00fcrde bloaten? Setze die Relationen, und \u00fcberdenk die Aussage.\r\n\r\nJa, nat\u00fcrlich, wir haben nicht mehr die 80er Jahre, also f\u00e4llt der Speicherverbrauch von 50kB nicht mehr so stark ins Gewicht. Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB gro\u00df ins Gewicht fallen w\u00fcrde. \r\n\r\nUnd dein anderes Argument, man m\u00fcsse eine komplette Browserumgebung laden, um ein Textfile editieren zu k\u00f6nnen, stimmt zwar, aber l\u00e4sst sich auch in Relationen setzen. Aber wenn man sich mal die Dependencies eines emacs anguckt... libc6, libncurses, libpng, libtextbuf, libpango, die zlib...man muss einmal die kompletten Libraries laden, um nur mal eben ein Textfile editieren zu k\u00f6nnen. Das h\u00e4tte man aber auch eleganter und weniger bloatend l\u00f6sen k\u00f6nnen, oder? Once again, check die Relationen. Die Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. Das h\u00e4tte man ja auch besser l\u00f6sen k\u00f6nnen, mit ner nativen Anzeigeengine, oder damals einfach alles statisch linken, oder kurzerhand selbst reinhacken k\u00f6nnen.\r\n\r\nZu deiner Mac-OS-Only-Argumentationen gibt es mittlerweile mehrere Builds f\u00fcr alle Systeme, auf denen Node l\u00e4uft, also d\u00fcrfte das auch widerlegbar sein, und zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar, und es soll ja Leute geben, deren Menge mit der Menge der Leute, die \u00fcber GA besorgt sind, relativ konjunkt ist, die einfach den Zugriff auf die Google-Analytics-Server in ihrer /etc/hosts (oder woauchimmer das betriebssystemspezifisch definiert wird) unterbunden haben, bzw den DNS-Record umgebogen haben, sodass ich mir \u00fcber das Problem ehrlich gesagt noch gar keine Gedanken gemacht habe.\r\n\r\nAber ich m\u00f6chte hier auch keinen Flame- oder Editor-War starten. Es m\u00f6ge jeder genau die Software nutzen, mit der er gl\u00fccklich wird. Wieso auch nicht?\r\n\r\nUnd \u00fcbrigens: Ich mag Wurst.",
"date_published": "2014-05-08T21:51:41+02:00",
"authors": [
{
"name": "simonszu",
"url": "",
"avatar": "data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB2aWV3Qm94PSIwIDAgNTAgNTAiPgoJPHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iMSIvPgoJPHRleHQKCQlmaWxsPSIjZmZmIgoJCWZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIgoJCWZvbnQtc2l6ZT0iMjYiCgkJZm9udC13ZWlnaHQ9IjUwMCIKCQlkb21pbmFudC1iYXNlbGluZT0ibWlkZGxlIgoJCXRleHQtYW5jaG9yPSJtaWRkbGUiCgkJeD0iNTAlIgoJCXk9IjU1JSIKCT4KCQlTCgk8L3RleHQ+Cjwvc3ZnPg=="
}
],
"author": {
"name": "simonszu",
"url": "",
"avatar": "data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB2ZXJzaW9uPSIxLjEiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgd2lkdGg9IjUwIiBoZWlnaHQ9IjUwIiB2aWV3Qm94PSIwIDAgNTAgNTAiPgoJPHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iMSIvPgoJPHRleHQKCQlmaWxsPSIjZmZmIgoJCWZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIgoJCWZvbnQtc2l6ZT0iMjYiCgkJZm9udC13ZWlnaHQ9IjUwMCIKCQlkb21pbmFudC1iYXNlbGluZT0ibWlkZGxlIgoJCXRleHQtYW5jaG9yPSJtaWRkbGUiCgkJeD0iNTAlIgoJCXk9IjU1JSIKCT4KCQlTCgk8L3RleHQ+Cjwvc3ZnPg=="
}
}
]
}