<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet href="https://tuxproject.de/blog/wp-content/plugins/pretty-rss-feeds/xslt/pretty-feed.xsl" type="text/xsl" media="screen" ?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:series="https://publishpress.com/"
	
	>
<channel>
	<title>
	Kommentare zu: GitHub: Auf zum Atom?	</title>
	<atom:link href="https://tuxproject.de/blog/2014/05/github-auf-zum-atom/feed/" rel="self" type="application/rss+xml" />
	<link>https://tuxproject.de/blog/2014/05/github-auf-zum-atom/</link>
	<description>Relevanz auf Halbmast.</description>
	<lastBuildDate>Thu, 08 May 2014 20:08:46 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		Von: tux0r		</title>
		<link>https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75787</link>

		<dc:creator><![CDATA[tux0r]]></dc:creator>
		<pubDate>Thu, 08 May 2014 20:08:46 +0000</pubDate>
		<guid isPermaLink="false">http://tuxproject.de/blog/?p=9495#comment-75787</guid>

					<description><![CDATA[Als Antwort auf &lt;a href=&quot;https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75786&quot;&gt;simonszu&lt;/a&gt;.

&lt;blockquote&gt;Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also könnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.&lt;/blockquote&gt;

Nehmen wir mal die beiden Editoren (aktuelle &quot;finale&quot; Versionen) ohne Extraplugins.

Bloat von Emacs: Ein Psychotherapeutenskript. Hui.
Bloat von Atom: Chromium, das allein über 100 MiB des Downloads ausmachen dürfte.

Möchtest du das in LoC haben oder genügt es dir auch so?

&lt;blockquote&gt;macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett.&lt;/blockquote&gt;

Wie gesagt: Dann nutz&#039; doch Eclipse, das kann auch alles, hat keinen Webbrowser, braucht ewig zum Laden und frisst RAM wie blöde, aber sind ja nicht mehr die 80er, man muss ja mit der Zeit gehen.

&lt;blockquote&gt;Auf 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?&lt;/blockquote&gt;

Variiert. (Irgendwelche Dienste laufen ja immer.)

Emacs läuft übrigens auch ohne GUI (die ersten Versionen hatten gar keines, dein Vergleich ist also gar keiner). Und Atom so?

&lt;blockquote&gt;Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verfügbaren Hauptspeichers benötigt. &lt;/blockquote&gt;

Jedenfalls die von dir selbst kompilierte Version - das kann stark variieren. Und: RAM-Größe wächst exponenziell, Menge an Editorfunktionen aber nicht. Überdenk&#039; die Aussage. ;) (Und: GB? Nicht eher MB?)

&lt;blockquote&gt;Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB groß ins Gewicht fallen würde. &lt;/blockquote&gt;

&quot;Wir haben mehr RAM, also belegen wir den auch, obwohl wir auch mit weniger RAM mehr Funktionen haben könnten! Weil wir ein neues Jahrtausend haben!&quot;

Irgendwo fehlt mir da die Kausalität.

&lt;blockquote&gt;Aber wenn man sich mal die Dependencies eines emacs anguckt… libc6, libncurses, libpng, libtextbuf, libpango, die zlib…&lt;/blockquote&gt;

Das sind deutlich weniger &quot;Dependencies&quot; als der Chromium-Quatsch allein besitzt, der in Atom drin ist. Übrigens ist zum Beispiel die libpng optional - hast du sie nicht, gehen halt keine Inline-PNGs. (Ich würde das nur im Twittering-Mode überhaupt bemerken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abhängigkeit fehlt? Nein, lass&#039; mich raten ... streiken, richtig?

&lt;blockquote&gt;Die Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. &lt;/blockquote&gt;

ncurses in einem CLI-Editor: Sinnvoll.
Webkit in einem Editor: Wofür, zum heiligen Henker?!

Äpfel. Birnen. Wie immer.

&lt;blockquote&gt;Das hätte man ja auch besser lösen können, mit ner nativen Anzeigeengine&lt;/blockquote&gt;

Hätte sich super auf die Portabilität ausgewirkt. Bemerkt man gerade bei Atom.

&lt;blockquote&gt;zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar&lt;/blockquote&gt;

&quot;Da hat zwar wer reingekackt, aber wenn man nach dem Reintreten alles sauber wischt, merkt man es gar nicht mehr.&quot;

Super!]]></description>
			<content:encoded><![CDATA[<p>Als Antwort auf <a href="https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75786" data-wpel-link="internal">simonszu</a>.</p>
<blockquote><p>Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also könnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.</p></blockquote>
<p>Nehmen wir mal die beiden Editoren (aktuelle „finale“ Versionen) ohne Extraplugins.</p>
<p>Bloat von Emacs: Ein Psychotherapeutenskript. Hui.<br>
Bloat von Atom: Chromium, das allein über 100 MiB des Downloads ausmachen dürfte.</p>
<p>Möchtest du das in LoC haben oder genügt es dir auch so?</p>
<blockquote><p>macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nutzen den Braten jetzt auch nicht mehr fett.</p></blockquote>
<p>Wie gesagt: Dann nutz‘ doch Eclipse, das kann auch alles, hat keinen Webbrowser, braucht ewig zum Laden und frisst RAM wie blöde, aber sind ja nicht mehr die 80er, man muss ja mit der Zeit gehen.</p>
<blockquote><p>Auf 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?</p></blockquote>
<p>Variiert. (Irgendwelche Dienste laufen ja immer.)</p>
<p>Emacs läuft übrigens auch ohne GUI (die ersten Versionen hatten gar keines, dein Vergleich ist also gar keiner). Und Atom so?</p>
<blockquote><p>Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verfügbaren Hauptspeichers benötigt. </p></blockquote>
<p>Jedenfalls die von dir selbst kompilierte Version – das kann stark variieren. Und: RAM-Größe wächst exponenziell, Menge an Editorfunktionen aber nicht. Überdenk‘ die Aussage.  <img src="https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_wink2.gif" alt=";)" width="18" height="18" class="wpml_ico">  (Und: GB? Nicht eher MB?)</p>
<blockquote><p>Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB groß ins Gewicht fallen würde. </p></blockquote>
<p>„Wir haben mehr RAM, also belegen wir den auch, obwohl wir auch mit weniger RAM mehr Funktionen haben könnten! Weil wir ein neues Jahrtausend haben!“</p>
<p>Irgendwo fehlt mir da die Kausalität.</p>
<blockquote><p>Aber wenn man sich mal die Dependencies eines emacs anguckt… libc6, libncurses, libpng, libtextbuf, libpango, die zlib…</p></blockquote>
<p>Das sind deutlich weniger „Dependencies“ als der Chromium-Quatsch allein besitzt, der in Atom drin ist. Übrigens ist zum Beispiel die libpng optional – hast du sie nicht, gehen halt keine Inline-PNGs. (Ich würde das nur im Twittering-Mode überhaupt bemerken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abhängigkeit fehlt? Nein, lass‘ mich raten … streiken, richtig?</p>
<blockquote><p>Die Libraries von emacs zu laden war einst bestimmt auch genau so #aufschrei-Induzierend wie heute das Webkit. </p></blockquote>
<p>ncurses in einem CLI-Editor: Sinnvoll.<br>
Webkit in einem Editor: Wofür, zum heiligen Henker?!</p>
<p>Äpfel. Birnen. Wie immer.</p>
<blockquote><p>Das hätte man ja auch besser lösen können, mit ner nativen Anzeigeengine</p></blockquote>
<p>Hätte sich super auf die Portabilität ausgewirkt. Bemerkt man gerade bei Atom.</p>
<blockquote><p>zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar</p></blockquote>
<p>„Da hat zwar wer reingekackt, aber wenn man nach dem Reintreten alles sauber wischt, merkt man es gar nicht mehr.“</p>
<p>Super!</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Von: simonszu		</title>
		<link>https://tuxproject.de/blog/2014/05/github-auf-zum-atom/#comment-75786</link>

		<dc:creator><![CDATA[simonszu]]></dc:creator>
		<pubDate>Thu, 08 May 2014 19:51:41 +0000</pubDate>
		<guid isPermaLink="false">http://tuxproject.de/blog/?p=9495#comment-75786</guid>

					<description><![CDATA[Um also die Diskussion von Twitter fortzuführen. Ich beziehe mich mal für die Definition von Bloatware auf die Wikipedia. 
&quot;Als Bloatware (engl. to bloat „aufblähen“), selten als Blähware oder Fatware[1], wird Software bezeichnet, die mit Funktionen überladen ist bzw. die Anwendungen sehr unterschiedlicher Arbeitsfelder ohne gemeinsamen Nutzen bündelt (siehe: eierlegende Wollmilchsau).&quot;
Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also könnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.

Und 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. 
Auf 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.

Die Wurzeln von GNU emacs reichen bis 1984 zurück, 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ättest du den eleganten Speicherverbrauch von 50MB, und würdest 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äht 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. 

Nun gehen wir mal, aus Gründen der Fairness, davon aus, dass ein hypothetischer User im Jahre &#039;84 emacs auf seinem PC ausführen wollte, und nicht auf irgendeinem Mainframe. In den 80er Jahren lag die typische Arbeitsspeichergröße irgendwo zwischen 64kB in einem C64 und 512kB in einem Amiga 500. Das hieße: emacs hat kurz nach seinem initialen Release irgendwas zwischen 11 und 70% des damaly üblichen Sets an Hauptspeicher verbraucht. Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verfügbaren Hauptspeichers benötigt. 

Und du willst mir ernsthaft erzählen, Atom würde bloaten? Setze die Relationen, und überdenk die Aussage.

Ja, natürlich, wir haben nicht mehr die 80er Jahre, also fällt 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ß ins Gewicht fallen würde. 

Und dein anderes Argument, man müsse eine komplette Browserumgebung laden, um ein Textfile editieren zu können, stimmt zwar, aber lässt 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önnen. Das hätte man aber auch eleganter und weniger bloatend lösen können, 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ätte man ja auch besser lösen können, mit ner nativen Anzeigeengine, oder damals einfach alles statisch linken, oder kurzerhand selbst reinhacken können.

Zu deiner Mac-OS-Only-Argumentationen gibt es mittlerweile mehrere Builds für alle Systeme, auf denen Node läuft, also dürfte 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 über 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 über das Problem ehrlich gesagt noch gar keine Gedanken gemacht habe.

Aber ich möchte hier auch keinen Flame- oder Editor-War starten. Es möge jeder genau die Software nutzen, mit der er glücklich wird. Wieso auch nicht?

Und übrigens: Ich mag Wurst.]]></description>
			<content:encoded><![CDATA[<p>Um also die Diskussion von Twitter fortzuführen. Ich beziehe mich mal für die Definition von Bloatware auf die Wikipedia.<br>
„Als Bloatware (engl. to bloat „aufblähen“), selten als Blähware oder Fatware[1], wird Software bezeichnet, die mit Funktionen überladen ist bzw. die Anwendungen sehr unterschiedlicher Arbeitsfelder ohne gemeinsamen Nutzen bündelt (siehe: eierlegende Wollmilchsau).“<br>
Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weniger zu steuern. Also könnte man nun das Bloating beiden Editoren vorwerfen, oder keinem.</p>
<p>Und 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.<br>
Auf 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.</p>
<p>Die Wurzeln von GNU emacs reichen bis 1984 zurück, 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ättest du den eleganten Speicherverbrauch von 50MB, und würdest 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äht 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. </p>
<p>Nun gehen wir mal, aus Gründen der Fairness, davon aus, dass ein hypothetischer User im Jahre ’84 emacs auf seinem PC ausführen wollte, und nicht auf irgendeinem Mainframe. In den 80er Jahren lag die typische Arbeitsspeichergröße irgendwo zwischen 64kB in einem C64 und 512kB in einem Amiga 500. Das hieße: emacs hat kurz nach seinem initialen Release irgendwas zwischen 11 und 70% des damaly üblichen Sets an Hauptspeicher verbraucht. Atom hat kurz nach seinem initialen Release irgendwas zwischen 1% (4GB RAM) und 0,25% (16GB RAM) des verfügbaren Hauptspeichers benötigt. </p>
<p>Und du willst mir ernsthaft erzählen, Atom würde bloaten? Setze die Relationen, und überdenk die Aussage.</p>
<p>Ja, natürlich, wir haben nicht mehr die 80er Jahre, also fällt 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ß ins Gewicht fallen würde. </p>
<p>Und dein anderes Argument, man müsse eine komplette Browserumgebung laden, um ein Textfile editieren zu können, stimmt zwar, aber lässt 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önnen. Das hätte man aber auch eleganter und weniger bloatend lösen können, 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ätte man ja auch besser lösen können, mit ner nativen Anzeigeengine, oder damals einfach alles statisch linken, oder kurzerhand selbst reinhacken können.</p>
<p>Zu deiner Mac-OS-Only-Argumentationen gibt es mittlerweile mehrere Builds für alle Systeme, auf denen Node läuft, also dürfte 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 über 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 über das Problem ehrlich gesagt noch gar keine Gedanken gemacht habe.</p>
<p>Aber ich möchte hier auch keinen Flame- oder Editor-War starten. Es möge jeder genau die Software nutzen, mit der er glücklich wird. Wieso auch nicht?</p>
<p>Und übrigens: Ich mag Wurst.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
