In den NachrichtenNerdkrams
GitHub: Auf zum Atom?

Worauf hat die Welt denn bei­na­he so drin­gend gewar­tet wie auf einen ein­ge­bil­de­ten Berg? Richtig: Auf Atom.

Atom - ich mei­ne aus­nahms­wei­se nicht die Energiequelle - ist ein von GitHub, einem gro­ßen Anbieter für frem­den Quellcode aller Art, ent­wickel­ter Texteditor, der bei­na­he aus­sieht wie das recht belieb­te Sublime Text und auch ähn­lich funk­tio­nie­ren soll, aller­dings kosten­los und quell­of­fen ange­bo­ten wird. (Einen ähn­li­chen Versuch, aller­dings mit gerin­ge­rer media­ler Aufmerksamkeit, star­te­te vor einer Weile Adobe mit Brackets.)

„Kostenlos“ ist ja eines der Lieblingswörter von Mitmensch Internetnutzer in sei­ner Gratiswolke. Qualität gern, aber lie­ber was geschenkt. Folgerichtig wird TextMate, eines der Vorbilder von Sublime Text, in der Version 2.0 eben­falls - bezeich­nen­der­wei­se auf GitHub - gra­tis zur Verfügung gestellt.

Ein gro­ßes Manko von TextMate ist, dass es aus­schließ­lich für Mac-OS-X-Systeme ent­wickelt wird:; eben­so wie der Atom-Editor übri­gens. Trotzdem sind blog­gen­de Entwickler (oder Gelegenheitsskripter) begei­stert und freu­en sich, dass sie jetzt einen Editor, der auch nicht mehr kann als sei­ne Vorbilder, nicht mehr müh­sam erbet­teln müssen:

Bisher muss­te man um einen Beta-Key bet­teln, wenn man sich die neu­ste Entwicklung aus dem Hause Github anschau­en wollte.

Auch bei heise.de ist man beeindruckt:

Der auf Googles Chromium basie­ren­de und Node.js als Backend nut­zen­de JavaScript-Editor soll die besten Eigenschaften ande­rer Texteditoren kom­bi­nie­ren. Die Entwickler zogen hier den Komfort von Sublime und TextMate sowie die Flexibilität und Erweiterbarkeit von Emacs und Vim her­an, die sich aber alle­samt nur mit spe­zi­el­len Skriptsprachen anpas­sen lie­ßen und nicht all­zu intui­tiv seien.

Nun, an einer Erneuerung von Vim wird ja eben­so gear­bei­tet wie an Emacs-Versionen, die das Skripten ein­fa­cher machen soll­ten, etwa mit einem Wechsel der Skriptsprache von Emacs Lisp zu Scheme. Ein Editor, der die Vorteile der bekann­ten Editoren mit­ein­an­der ver­bin­det, ohne einen ihrer Nachteile zu über­neh­men, klingt zwar zumin­dest in der Theorie inter­es­sant, aber dafür müss­te er sich erst ein­mal posi­tiv von ande­ren Editoren abheben.

Womit aber will Atom das schaffen?

Die Website sagt zum Beispiel:

Our goal is a deeply exten­si­ble system that blurs the distinc­tion bet­ween „user“ and „deve­lo­per“.

Der Editor soll also von jedem Benutzer ein­fach und kom­plett frei skript­bar sein. Das sind Vim, Emacs und der­glei­chen zwar auch, aber sie benut­zen nicht so schö­ne Werbephrasen dafür.

Atom comes loa­ded with the fea­tures you’­ve come to expect from a modern text editor.

Atom bringt also alle Funktionen mit, die Editoren wie Notepad++ auch mit­brin­gen. Das ist wirk­lich sehr prak­tisch, aber auch nicht innovativ.

Wo blei­ben nun die Innovationen? Na, wei­ter oben:

Atom is a desk­top app­li­ca­ti­on based on web technologies.

Tatsächlich: Atom basiert auf Chromium. Auf einem Webbrowser. Ein Texteditor, der auf einem Webbrowser basiert. Ein ein­fa­ches Werkzeug, das auf einer kom­ple­xen, schwe­ren Plattform steht. Ein Texteditor, der Facebook kann. Atome hat­te ich mir ja immer als etwas sehr Kleines vor­ge­stellt, aber ich habe noch nie ein Atom gese­hen. Vielleicht lag ich da falsch.

Aber die Entwickler haben sich auch etwas dabei gedacht, denn so kön­nen sie statt sta­ti­schen, platt­form­ab­hän­gi­gen Codes in ihrem Texteditor, der nur unter Mac OS X läuft, platt­form­un­ab­hän­gi­ge Pakete ent­wickeln, die die Leistungsfähigkeit des Editors enorm erhö­hen. Zum Beispiel Metrics. Metrics ist ein wohl stan­dard­mä­ßig akti­ves Paket, das essen­zi­el­le Editorfunktionen ent­hält: Es sen­det Benutzerdaten zwecks Auswertung an Google Analytics (pro­vo­kant gesagt also wahr­schein­lich an die NSA).

Das tun ande­re Editoren tat­säch­lich meist nicht. Man kann das Paket zwar deak­ti­vie­ren - dafür aber muss es erst ein­mal aktiv gewe­sen sein. Das also sind alle Funktionen, die ich von einem moder­nen Texteditor erwar­te. Ob er wohl auch Texte edi­tie­ren kann? Die Website schweigt sich aus.

Der Editor des 21. Jahrhunderts, fast so groß wie OpenBSD. Ich fand das letz­te Jahrhundert irgend­wie besser.

Senfecke:

  1. Um also die Diskussion von Twitter fort­zu­füh­ren. Ich bezie­he mich mal für die Definition von Bloatware auf die Wikipedia.
    „Als Bloatware (engl. to bloat „auf­blä­hen“), sel­ten als Blähware oder Fatware[1], wird Software bezeich­net, die mit Funktionen über­la­den ist bzw. die Anwendungen sehr unter­schied­li­cher Arbeitsfelder ohne gemein­sa­men Nutzen bün­delt (sie­he: eier­le­gen­de Wollmilchsau).“
    Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weni­ger zu steu­ern. Also könn­te man nun das Bloating bei­den Editoren vor­wer­fen, oder keinem.

    Und zur Tatsache, dass du Bloat mit Speicherverbrauch gleich­setzt, nun: Atom ver­braucht 30MB Speicher, ja. Aber in Anbetracht der Tatsache, dass du heut­zu­ta­ge kaum noch Computer mehr mit weni­ger als 4GB Speicher kau­fen kannst, allei­ne weil das Betriebssystem so rum­bloa­ted, macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nut­zen den Braten jetzt auch nicht mehr fett.
    Auf dei­nem Screenshot war klar ein OS mit GUI zu sehen, ver­mut­lich ein Windows. Wieviel Speicher ver­braucht das denn so, wenn es gestar­tet und ein­ge­loggt ist, aber sonst kei­ner­lei Dienste im Hintergrund lau­fen? Mit Sicherheit mehr als 1% des Hauptspeichers, und den­noch nutzt du es, ohne dich selbst des Bloatings anzuklagen.

    Die Wurzeln von GNU emacs rei­chen 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ät­test du den ele­gan­ten Speicherverbrauch von 50MB, und wür­dest dich selbst dis­qua­li­fi­zie­ren. Nun, also eine Auslastung von 50kB. Legen wir dem Entwicklerteam von emacs mal einen guten Programmierstil zuge­gen, und behaup­ten, dass sich das Programm in den letz­ten 30 Jahren nicht signi­fi­kant auf­ge­bläht hat (wie du schon sag­test, kei­ne 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 hypo­the­ti­scher User im Jahre ’84 emacs auf sei­nem PC aus­füh­ren woll­te, und nicht auf irgend­ei­nem Mainframe. In den 80er Jahren lag die typi­sche Arbeitsspeichergröße irgend­wo zwi­schen 64kB in einem C64 und 512kB in einem Amiga 500. Das hie­ße: emacs hat kurz nach sei­nem initia­len Release irgend­was zwi­schen 11 und 70% des dama­ly übli­chen Sets an Hauptspeicher ver­braucht. Atom hat kurz nach sei­nem initia­len Release irgend­was zwi­schen 1% (4GB RAM) und 0,25% (16GB RAM) des ver­füg­ba­ren Hauptspeichers benötigt. 

    Und du willst mir ernst­haft erzäh­len, Atom wür­de bloa­ten? Setze die Relationen, und über­denk die Aussage.

    Ja, natür­lich, 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 fal­len würde. 

    Und dein ande­res Argument, man müs­se eine kom­plet­te Browserumgebung laden, um ein Textfile edi­tie­ren zu kön­nen, stimmt zwar, aber lässt sich auch in Relationen set­zen. Aber wenn man sich mal die Dependencies eines emacs anguckt… libc6, libn­cur­ses, libpng, lib­text­buf, lib­pan­go, die zlib…man muss ein­mal die kom­plet­ten Libraries laden, um nur mal eben ein Textfile edi­tie­ren zu kön­nen. Das hät­te man aber auch ele­gan­ter und weni­ger bloa­tend lösen kön­nen, oder? Once again, check die Relationen. Die Libraries von emacs zu laden war einst bestimmt auch genau so #auf­schrei-Induzierend wie heu­te das Webkit. Das hät­te man ja auch bes­ser lösen kön­nen, mit ner nati­ven Anzeigeengine, oder damals ein­fach alles sta­tisch lin­ken, oder kur­zer­hand selbst rein­hacken können.

    Zu dei­ner Mac-OS-Only-Argumentationen gibt es mitt­ler­wei­le meh­re­re Builds für alle Systeme, auf denen Node läuft, also dürf­te das auch wider­leg­bar sein, und zu dem Spywarevorwurf..ja klar, ist aber deak­ti­vier­bar, und es soll ja Leute geben, deren Menge mit der Menge der Leute, die über GA besorgt sind, rela­tiv kon­junkt ist, die ein­fach den Zugriff auf die Google-Analytics-Server in ihrer /etc/hosts (oder woau­chim­mer das betriebs­sy­stem­spe­zi­fisch defi­niert wird) unter­bun­den haben, bzw den DNS-Record umge­bo­gen haben, sodass ich mir über das Problem ehr­lich gesagt noch gar kei­ne Gedanken gemacht habe.

    Aber ich möch­te hier auch kei­nen Flame- oder Editor-War star­ten. Es möge jeder genau die Software nut­zen, mit der er glück­lich wird. Wieso auch nicht?

    Und übri­gens: Ich mag Wurst.

    • Natürlich haben emacs und Atom ein Plugin-System, um das mehr oder weni­ger zu steu­ern. Also könn­te man nun das Bloating bei­den Editoren vor­wer­fen, oder keinem.

      Nehmen wir mal die bei­den Editoren (aktu­el­le „fina­le“ Versionen) ohne Extraplugins.

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

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

      macht die Tatsache, dass ein Editor es wagen kann, 1% des Gesamtspeichers zu nut­zen den Braten jetzt auch nicht mehr fett.

      Wie gesagt: Dann nutz‘ doch Eclipse, das kann auch alles, hat kei­nen 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.

      Auf dei­nem Screenshot war klar ein OS mit GUI zu sehen, ver­mut­lich ein Windows. Wieviel Speicher ver­braucht das denn so, wenn es gestar­tet und ein­ge­loggt ist, aber sonst kei­ner­lei Dienste im Hintergrund laufen?

      Variiert. (Irgendwelche Dienste lau­fen ja immer.)

      Emacs läuft übri­gens auch ohne GUI (die ersten Versionen hat­ten gar kei­nes, dein Vergleich ist also gar kei­ner). Und Atom so?

      Atom hat kurz nach sei­nem initia­len Release irgend­was zwi­schen 1% (4GB RAM) und 0,25% (16GB RAM) des ver­füg­ba­ren Hauptspeichers benötigt. 

      Jedenfalls die von dir selbst kom­pi­lier­te Version - das kann stark vari­ie­ren. Und: RAM-Größe wächst expo­nen­zi­ell, Menge an Editorfunktionen aber nicht. Überdenk‘ die Aussage. ;) (Und: GB? Nicht eher MB?)

      Aber wir haben auch nicht mehr den Beginn der 2000er Jahre, wo ein Speicherverbrauch von 30MB groß ins Gewicht fal­len würde. 

      „Wir haben mehr RAM, also bele­gen wir den auch, obwohl wir auch mit weni­ger RAM mehr Funktionen haben könn­ten! Weil wir ein neu­es Jahrtausend haben!“

      Irgendwo fehlt mir da die Kausalität.

      Aber wenn man sich mal die Dependencies eines emacs anguckt… libc6, libn­cur­ses, libpng, lib­text­buf, lib­pan­go, die zlib…

      Das sind deut­lich weni­ger „Dependencies“ als der Chromium-Quatsch allein besitzt, der in Atom drin ist. Übrigens ist zum Beispiel die libpng optio­nal - hast du sie nicht, gehen halt kei­ne Inline-PNGs. (Ich wür­de das nur im Twittering-Mode über­haupt bemer­ken; oder sind das JPEGs? Dann gar nicht.) Was macht Chromium, wenn ihm eine Abhängigkeit fehlt? Nein, lass‘ mich raten … strei­ken, richtig?

      Die Libraries von emacs zu laden war einst bestimmt auch genau so #auf­schrei-Induzierend wie heu­te das Webkit. 

      ncur­ses in einem CLI-Editor: Sinnvoll.
      Webkit in einem Editor: Wofür, zum hei­li­gen Henker?!

      Äpfel. Birnen. Wie immer.

      Das hät­te man ja auch bes­ser lösen kön­nen, mit ner nati­ven Anzeigeengine

      Hätte sich super auf die Portabilität aus­ge­wirkt. Bemerkt man gera­de bei Atom.

      zu dem Spywarevorwurf..ja klar, ist aber deaktivierbar

      „Da hat zwar wer rein­ge­kackt, aber wenn man nach dem Reintreten alles sau­ber wischt, merkt man es gar nicht mehr.“

      Super!

Comments are closed.

https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_smilenew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_biggrin2.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_sadnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_eek.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_shocked.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_confusednew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_coolnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_lol.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_madnew.gif  https://tuxproject.de/blog/wp-content/plugins/wp-monalisa/icons/smiley_emoticons_aufsmaul.gif 
mehr...
 

Erlaubte Tags:
<strong> <em> <pre> <code> <a href="" title=""> <img src="" title="" alt=""> <blockquote> <q> <b> <i> <del> <span style=""> <strike>

Datenschutzhinweis: Ihre IP-Adresse wird nicht gespeichert. Details finden Sie hier.