Sorry, aber der Kommentar ist so angestaubt wie unangebracht.
Jede Aktion als eigenes Programm... warum nicht gleich Browser aufspalten. Eine externe Lesezeichenverwaltung, Cahceverwaltung, Multimediaanzeige, eine HMTL Anzeige, eine optionale CSS Anzeige, Passwörter über ein eigenes Tool und das Ganze nur auf der Shell... die grafische Oberfläche dazu natürlich als weiteres Programm.
Also, das habe ich mir auch schon lange gewünscht ... geht weiter mit allen anderen Daten wie Adressen, Kalender, ToDo etc.
DAS wäre doch mal ein echtes Alleinstellungsmerkmal und Nutzergefühl bei open-source/Linux Desktops wenn alle Programmierer das in Ihren Programmen einbauen würden.
Import/Export von sowas, am besten noch mit csv Dateien, ist **gähn** langweilig und sollte echt nicht mehr nötig sein.
Wenn ich so darüber nachdenke: Eigene Lesezeichenverwaltungen gibt es für fast alle Browser als Plugin oder externe Programme. Schließlich ist nichts perfekt.
Nennt sich uzbl Aber selbst der Hauptentwickler hat inzwischen eingesehen, dass diese Herangehensweise relativ kompliziert und ineffizient ist. Trotzdem, geiler Browser!
"Sorry, aber der Kommentar ist so angestaubt wie unangebracht."
Warum angestaubt, das ist ein bewährtes Prinzip. Und es ist sehr angebracht, da exakt zum Thema passend.
"Jede Aktion als eigenes Programm..."
Du hast sicher den Unterschied von einem daemon und einem Browser erkannt ... nachdem du deinen Text geschrieben hast...
Abgesehen davon gibt es durchaus solche Trennungen die du verspottest, wenn natürlich nicht unbedingt nach der reinen Unixlehre (ein Browser ist nunmal auch kein daemon...) Eigene Wallets Programme für Passwörter sind Alltag, die HTML Engine ist oft aus anderen Projekten (z.B. Webkit, oder unter Windows die IE Engine, dort sogar als eigene Lib Teil des Systems), Multimedianazeige war lange kein Teil von Browsern sondern via Plugin realisiert (und auch jetzt sind es eher externe Libs die gleich genutzt werden), Browser für die Shell gibts natürlich auch Der IE hatte sogar (bis zum IE9 der bald kommt) Javascript in komplett eigenen Prozessen, die nicht zum Browser gehörten. Keine Programme im eigentlichen Sinne, aber es gab gewisse Trennungen.
Und die GUI IST ein weiteres Programm. Nennt sich X. Darauf läuft ein Fenstermanager, je nach Anwendung ein eigenes GUI Toolkit. Gerne auch über Rechnergrenzen hinweg.
Warum nutzt du eigentlich ein Unixartiges System, wenn dir das Grundprinzip nichts bedeutet?
Was Du beschreibst hat überhaupt nichts mit UNIX zu tun, sondern damit, dass die Aufteilung eines großen Systems in überschaubare Teile die einzige bekannte Möglichkeit ist, solche Systeme zu entwickeln. Das wird unter Windows und Mac OS genauso praktiziert wie unter UNIX.
UNIX-spezifisch ist die Art und Weise, wie Programme zusammenarbeiten: ein Programm schreibt auf die Standardausgabe, liest von der Standardeingabe, und man kann Programme über Pipes und Shell-Umleitungen miteinander verknüpfen. Dies ist mit der berühmten UNIX-Philosophie gemeint, und die Begrenzungen dieses Konzepts sind offensichtlich: es gibt kein Standardkonzept, um strukturierte Daten (Objekte, Maps, Listen usw.) auszutauschen, Kommunikation ist wegen der Pipes nur in eine Richtung möglich und nicht zuletzt ist es Nutzern schwer zu vermitteln. Deswegen wird dieses Konzept als "angestaubt" bezeichnet, weil es eben einfach angestaubt ist.
Was systemd angeht: Ich kann nicht erkennen, dass dieses Programm zu viel täte. Im Gegenteil, es kümmert sich um genau eine Sache: das Starten und Beenden von Diensten.
"Was Du beschreibst hat überhaupt nichts mit UNIX zu tun, sondern damit, dass die Aufteilung eines großen Systems in überschaubare Teile die einzige bekannte Möglichkeit ist, solche Systeme zu entwickeln. Das wird unter Windows und Mac OS genauso praktiziert wie unter UNIX."
Ich habe auch nicht das Browserbeispiel gebracht, sondern er. Ich habe nur nahelegen wollen, das auch dort sehr wohl ein Prinzip der einzelnen Komponenten existiert. Wobei eigene Lesezeichenprogramme, getrennte Passwortrwallets und co. durchaus dem Unixprinzip entsprechen. Einzelne Anwendungen, die untereinander Kommunizieren, und eine Aufgabe erfüllen.
"ein Programm schreibt auf die Standardausgabe, liest von der Standardeingabe, und man kann Programme über Pipes und Shell-Umleitungen miteinander verknüpfen."
Das ist richtig, aber so streng auf GUI Anwendungen garnicht anwendbar, da diese anders arbeiten. Einzelne Anwendungen, die über GUI-passende arten Kommunizieren, können dem Prinzip dennoch entsprechend. Das hat aber nichts mehr mit systemd zu tun, aber war ja wie gesagt auch nicht mein Beispiel. Siehe mein Text.
"Ich kann nicht erkennen, dass dieses Programm zu viel täte. Im Gegenteil, es kümmert sich um genau eine Sache: das Starten und Beenden von Diensten."
Lies dir nochmal genau durch was es noch so alles tut. Leider ist das was du sagst nicht wirklich der Umfang von systemd, es bringt praktisch alles an Funktionen mit, die man in einem eventbassierten System überhaupt integrieren kann, anstatt nur deren Mittler zu sein.
Ein Beispiel für einen Minimaldienst wäre cron, das ding hier aber ist praktisch ein 2. Kernel in sich.
Die Inflation von Features ist aber kaum überraschend, das war bei Pulseaudio auch so. Einige nützliche Grundfunktionen, die wirklich sinnvoll waren, wurden um hunderte mittel bis unwichtige Funktionen erweitert, bis am Ende für längere Zeit eine instabile Masse vor dem User wartete. Ich habe wenig Hoffnung was dieses Projekt angeht, sage ich ganz ehrlich. Featuritis war noch nie der Weg zum Erfolg, schon garnicht im Unixbereich.
"Sorry, aber der Kommentar ist so angestaubt wie unangebracht.
Jede Aktion als eigenes Programm... warum nicht gleich Browser aufspalten. Eine externe Lesezeichenverwaltung, Cahceverwaltung, Multimediaanzeige, eine HMTL Anzeige, eine optionale CSS Anzeige, Passwörter über ein eigenes Tool und das Ganze nur auf der Shell... die grafische Oberfläche dazu natürlich als weiteres Programm."
Toll, alle Funktionalitaet in ein Programm, oder wie? So ein Schmarrn. Was rauskommt sieht man z.B. beim Adobe reader.
Sorry, aber der Kommentar ist so angestaubt wie unangebracht.
Jede Aktion als eigenes Programm... warum nicht gleich Browser aufspalten. Eine externe Lesezeichenverwaltung, Cahceverwaltung, Multimediaanzeige, eine HMTL Anzeige, eine optionale CSS Anzeige, Passwörter über ein eigenes Tool und das Ganze nur auf der Shell... die grafische Oberfläche dazu natürlich als weiteres Programm.
[...] Eine externe Lesezeichenverwaltung, [...]
Also, das habe ich mir auch schon lange gewünscht ... geht weiter mit allen anderen Daten wie Adressen, Kalender, ToDo etc.
DAS wäre doch mal ein echtes Alleinstellungsmerkmal und Nutzergefühl bei open-source/Linux Desktops wenn alle Programmierer das in Ihren Programmen einbauen würden.
Import/Export von sowas, am besten noch mit csv Dateien, ist **gähn** langweilig und sollte echt nicht mehr nötig sein.
Wenn ich so darüber nachdenke: Eigene Lesezeichenverwaltungen gibt es für fast alle Browser als Plugin oder externe Programme. Schließlich ist nichts perfekt.
Nennt sich uzbl
Aber selbst der Hauptentwickler hat inzwischen eingesehen, dass diese Herangehensweise relativ kompliziert und ineffizient ist. Trotzdem, geiler Browser!
"Sorry, aber der Kommentar ist so angestaubt wie unangebracht."
Warum angestaubt, das ist ein bewährtes Prinzip. Und es ist sehr angebracht, da exakt zum Thema passend.
"Jede Aktion als eigenes Programm..."
Du hast sicher den Unterschied von einem daemon und einem Browser erkannt ... nachdem du deinen Text geschrieben hast...
Abgesehen davon gibt es durchaus solche Trennungen die du verspottest, wenn natürlich nicht unbedingt nach der reinen Unixlehre (ein Browser ist nunmal auch kein daemon...)
Eigene Wallets Programme für Passwörter sind Alltag, die HTML Engine ist oft aus anderen Projekten (z.B. Webkit, oder unter Windows die IE Engine, dort sogar als eigene Lib Teil des Systems), Multimedianazeige war lange kein Teil von Browsern sondern via Plugin realisiert (und auch jetzt sind es eher externe Libs die gleich genutzt werden), Browser für die Shell gibts natürlich auch
Der IE hatte sogar (bis zum IE9 der bald kommt) Javascript in komplett eigenen Prozessen, die nicht zum Browser gehörten.
Keine Programme im eigentlichen Sinne, aber es gab gewisse Trennungen.
Und die GUI IST ein weiteres Programm. Nennt sich X. Darauf läuft ein Fenstermanager, je nach Anwendung ein eigenes GUI Toolkit. Gerne auch über Rechnergrenzen hinweg.
Warum nutzt du eigentlich ein Unixartiges System, wenn dir das Grundprinzip nichts bedeutet?
Was Du beschreibst hat überhaupt nichts mit UNIX zu tun, sondern damit, dass die Aufteilung eines großen Systems in überschaubare Teile die einzige bekannte Möglichkeit ist, solche Systeme zu entwickeln. Das wird unter Windows und Mac OS genauso praktiziert wie unter UNIX.
UNIX-spezifisch ist die Art und Weise, wie Programme zusammenarbeiten: ein Programm schreibt auf die Standardausgabe, liest von der Standardeingabe, und man kann Programme über Pipes und Shell-Umleitungen miteinander verknüpfen. Dies ist mit der berühmten UNIX-Philosophie gemeint, und die Begrenzungen dieses Konzepts sind offensichtlich: es gibt kein Standardkonzept, um strukturierte Daten (Objekte, Maps, Listen usw.) auszutauschen, Kommunikation ist wegen der Pipes nur in eine Richtung möglich und nicht zuletzt ist es Nutzern schwer zu vermitteln. Deswegen wird dieses Konzept als "angestaubt" bezeichnet, weil es eben einfach angestaubt ist.
Was systemd angeht: Ich kann nicht erkennen, dass dieses Programm zu viel täte. Im Gegenteil, es kümmert sich um genau eine Sache: das Starten und Beenden von Diensten.
"Was Du beschreibst hat überhaupt nichts mit UNIX zu tun, sondern damit, dass die Aufteilung eines großen Systems in überschaubare Teile die einzige bekannte Möglichkeit ist, solche Systeme zu entwickeln. Das wird unter Windows und Mac OS genauso praktiziert wie unter UNIX."
Ich habe auch nicht das Browserbeispiel gebracht, sondern er. Ich habe nur nahelegen wollen, das auch dort sehr wohl ein Prinzip der einzelnen Komponenten existiert. Wobei eigene Lesezeichenprogramme, getrennte Passwortrwallets und co. durchaus dem Unixprinzip entsprechen. Einzelne Anwendungen, die untereinander Kommunizieren, und eine Aufgabe erfüllen.
"ein Programm schreibt auf die Standardausgabe, liest von der Standardeingabe, und man kann Programme über Pipes und Shell-Umleitungen miteinander verknüpfen."
Das ist richtig, aber so streng auf GUI Anwendungen garnicht anwendbar, da diese anders arbeiten. Einzelne Anwendungen, die über GUI-passende arten Kommunizieren, können dem Prinzip dennoch entsprechend. Das hat aber nichts mehr mit systemd zu tun, aber war ja wie gesagt auch nicht mein Beispiel. Siehe mein Text.
"Ich kann nicht erkennen, dass dieses Programm zu viel täte. Im Gegenteil, es kümmert sich um genau eine Sache: das Starten und Beenden von Diensten."
Lies dir nochmal genau durch was es noch so alles tut. Leider ist das was du sagst nicht wirklich der Umfang von systemd, es bringt praktisch alles an Funktionen mit, die man in einem eventbassierten System überhaupt integrieren kann, anstatt nur deren Mittler zu sein.
Ein Beispiel für einen Minimaldienst wäre cron, das ding hier aber ist praktisch ein 2. Kernel in sich.
Die Inflation von Features ist aber kaum überraschend, das war bei Pulseaudio auch so. Einige nützliche Grundfunktionen, die wirklich sinnvoll waren, wurden um hunderte mittel bis unwichtige Funktionen erweitert, bis am Ende für längere Zeit eine instabile Masse vor dem User wartete.
Ich habe wenig Hoffnung was dieses Projekt angeht, sage ich ganz ehrlich. Featuritis war noch nie der Weg zum Erfolg, schon garnicht im Unixbereich.
Weil das nunmal schon immer so gehandhabt wurde im Unix Bereich.
"Sorry, aber der Kommentar ist so angestaubt wie unangebracht.
Jede Aktion als eigenes Programm... warum nicht gleich Browser aufspalten. Eine externe Lesezeichenverwaltung, Cahceverwaltung, Multimediaanzeige, eine HMTL Anzeige, eine optionale CSS Anzeige, Passwörter über ein eigenes Tool und das Ganze nur auf der Shell... die grafische Oberfläche dazu natürlich als weiteres Programm."
Toll, alle Funktionalitaet in ein Programm, oder wie? So ein Schmarrn. Was rauskommt sieht man z.B. beim Adobe reader.