# semantic-desktop: Widerstand zwecklos?

## sprittwicht

Hallo. Als ich damals zum ersten Mal KDE 4 installiert habe, habe ich semantic-desktop bewusst ausgeschaltet, weil ich dachte dass ich mir damit irgendeine Vista-ähnliche Indexierungsscheiße einfange.

Nun scheint man spätestens seit KDE 4.4 nicht mehr drum rumzukommen, sobald man die kdepim-Packages nutzt: https://forums.gentoo.org/viewtopic-t-833463.html

Also lese ich mal ein bisschen... http://nepomuk.kde.org/node/1

Zitat:

"The most interesting type of metadata is, however, the kind that cannot be extracted easily by an indexer and is not generated by the user manually. This includes for example the url of a file that is downloaded from the internet. Once saved on the local harddisk this information is lost. The same goes for the (rather popular) example of email attachments: Once an email attachment is saved to the local harddisk its connection to the email and with it the connection to the sender is lost."

Und das sind genau die Informationen, bei denen ich eher froh bin, dass die nicht irgendwo mitgeschleppt werden. Ich brauch sie nicht, ich will sie nicht, kurzum: ich habe keine Verwendung für semantic-desktop.

Meine Frage: Wenn ich das USE-Flag jetzt einschalte(n muss), läuft dann automatisch irgendein Indexierungsdienst im Hintergrund? Kann ich den manuell abschalten? Oder konfigurieren, was wann wo wie indexiert wird?

Wo werden die gesammelten Daten gespeichert?

Habe gerade bemerkt dass auch strigi bei mir schon installiert ist, mit clucene-"Backend"?

Kann mir jemand kurz erklären oder einen informativen Link geben, wie all diese Komponenten zusammenspielen, und wie ich rausfinden kann, ob und was bei mir indexiert wird?

Ich mag's nicht von unerwünschten Features überrollt zu werden. :-/

----------

## franzf

Advanced User Settings -> Desktop Search -> Enable Nepomuk Semantic Desktop ausmachen - fertig.

Wenns dir nur um die Dateiindizierung geht, kannst du da auch nur strigi deaktivieren.

----------

## musv

Und ich dachte schon, ich wär der einzige damit:

https://forums.gentoo.org/viewtopic-t-818147.html

https://forums.gentoo.org/viewtopic-t-831410.html

Also lautet das Geheimrezept wohl wieder:

Erst installieren, um den ganzen Müll dann in den Systemsettings wieder deaktivieren zu können.   :Confused: 

Musste ich bei kdewallet schon so machen. Ich finde dieses Prinzip nicht wirklich gut.

----------

## sprittwicht

 *musv wrote:*   

> Erst installieren, um den ganzen Müll dann in den Systemsettings wieder deaktivieren zu können.  

 

Die Energie der Gentoo-Entwickler in allen Ehren, die sie in die Split-Ebuilds für KDE gesteckt haben.

Aber irgendwie scheint das bei KDE einfach nicht zu funktionieren. Wenn man nicht alles so installiert wie die KDEler sich das ursprünglich gedacht hatten, knallt's früher oder später an allen Ecken und Enden.

Und ja, dieses bescheuerte KDE-Wallet ist bei mir auch so ein Hasskandidat, den ich nicht will, trotzdem installieren musste, ihm bei jeder Gelegenheit sage, dass ich irgendetwas Bestimmtes _nicht_ darin speichern möchte, und trotzdem poppt dieses Drecksteil ständig vor meiner Nase auf. "Wollen Sie nicht? Speichern hier? Sicher und toll, komm schon, mach schon..."

----------

## Klaus Meier

 *sprittwicht wrote:*   

>  *musv wrote:*   Erst installieren, um den ganzen Müll dann in den Systemsettings wieder deaktivieren zu können.   
> 
> Die Energie der Gentoo-Entwickler in allen Ehren, die sie in die Split-Ebuilds für KDE gesteckt haben.
> 
> Aber irgendwie scheint das bei KDE einfach nicht zu funktionieren. Wenn man nicht alles so installiert wie die KDEler sich das ursprünglich gedacht hatten, knallt's früher oder später an allen Ecken und Enden.
> ...

 

Du gehst auf die Konfiguration von kwallet und stellst da ein, dass du es nicht benutzen willst. Ein Klick und fertig. Man kann bei KDE so ziemlich alles so konfigurieren, wie man es gerne hätte. Einfach mal etwas in den Systemeinstellungen umschauen. Man kann es nicht vollständig über USE-Flags konfigurieren, was du wohl scheinbar erwartest.

----------

## musv

KDE-Wallet kannst du nach Installation von kde-base/kwallet in den Systemsettings deaktivieren. Dann fragt der nie wieder. 

Wie gesagt, komisches Prinzip, dass man Sachen erst "nicht mehr nutzen" braucht, nachdem man sie installiert hat.

----------

## Necoro

Zum Indizierungsdienst: Ich habe auf meinem Rechner "Tracker" im Einsatz (also wohl das Gnome-Pendant zu strigi, so ganz hab ich die Zusammenhänge noch nicht verstanden) -- und das läuft mit kaum wahrnehmbaren RAM-Verbrauch (werden wohl max. 20 MB sein ... hab den Rechner gerade net zur Hand) und ohne Indizierungsorgien (inotify sei dank). Also im Gegensatz zu der Windows-Indizierung überhaupt nicht wahrnehmbar.

Muss aber dazu sagen, dass ich das auch auf ein kleines Verzeichnis eingeschränkt habe, weil ich nicht mein komplettes /home indiziert haben brauch.

----------

## Josef.95

 *sprittwicht wrote:*   

> Kann mir jemand kurz erklären oder einen informativen Link geben, wie all diese Komponenten zusammenspielen, und wie ich rausfinden kann, ob und was bei mir indexiert wird?

  Eventuell helfen diese Infos ein wenig weiter?

http://www.pro-linux.de/news/1/15639/aaron-seigo-nepomuk-ist-mehr-als-datei-indizierung.html

http://aseigo.blogspot.com/2010/05/i-dont-need-no-stinking-nepomuk-right.html

----------

## firefly

 *musv wrote:*   

> KDE-Wallet kannst du nach Installation von kde-base/kwallet in den Systemsettings deaktivieren. Dann fragt der nie wieder. 
> 
> Wie gesagt, komisches Prinzip, dass man Sachen erst "nicht mehr nutzen" braucht, nachdem man sie installiert hat.

 

Das problem ist halt, wenn ein Programm kwallet Unterstützung hat und diese nicht beim übersetzen deaktiviert werden kann, dass dann die benötigten kwallet libs installiert sein müssen. Ansonsten läuft das Programm nicht. Da die libs neben dem eigentlichen kwallet dienst im kwallet paket enthalten sind, muss dann das kwallet paket  installiert sein.

----------

## Polynomial-C

Trotz PDEPEND in kde-base/kdelibs[semantik-desktop] stört es kde keineswegs, wenn man nepomuk nicht installiert hat. Ein beherztes 

```
mkdir /etc/portage/profile ; echo "kde-base/nepomuk-4.99" >> /etc/portage/profile/package.provided
```

sorgt dafür, daß nepomuk erst gar nicht mitinstalliert wird...

----------

## Klaus Meier

 *Necoro wrote:*   

> Zum Indizierungsdienst: Ich habe auf meinem Rechner "Tracker" im Einsatz (also wohl das Gnome-Pendant zu strigi, so ganz hab ich die Zusammenhänge noch nicht verstanden) -- und das läuft mit kaum wahrnehmbaren RAM-Verbrauch (werden wohl max. 20 MB sein ... hab den Rechner gerade net zur Hand) und ohne Indizierungsorgien (inotify sei dank). Also im Gegensatz zu der Windows-Indizierung überhaupt nicht wahrnehmbar.
> 
> Muss aber dazu sagen, dass ich das auch auf ein kleines Verzeichnis eingeschränkt habe, weil ich nicht mein komplettes /home indiziert haben brauch.

 

Ist bei KDE genauso. Verstehe auch nicht, warum da alle so eine Aufregung drum machen. Egal ob es an oder aus ist, ich merke absolut keinen Unterschied. Es gab so bis ca. März ein Speicherleck im kiothumbnailer, und der hat das System in die Knie gezwungen. Und 90% der Anwender haben einfach pauschal auf die Indizierung geschimpft.

----------

## franzf

 *Klaus Meier wrote:*   

> Es gab so bis ca. März ein Speicherleck im kiothumbnailer, und der hat das System in die Knie gezwungen. Und 90% der Anwender haben einfach pauschal auf die Indizierung geschimpft.

 

Äh, so ist das aber echt nicht gewesen! Hier hat die Indizierung definitiv meinen Speicher gefressen (sieht man ja in top, war hauptsächlich virtuoso, aber auch nepomukservices selber mit einigen Hundert MB...), und sicher bei einigen anderen auch, trotz Begrenzung in den Settings! Keine Ahnung was das war, es ist auf jeden Fall jetzt weg...

----------

## Klaus Meier

 *franzf wrote:*   

>  *Klaus Meier wrote:*   Es gab so bis ca. März ein Speicherleck im kiothumbnailer, und der hat das System in die Knie gezwungen. Und 90% der Anwender haben einfach pauschal auf die Indizierung geschimpft. 
> 
> Äh, so ist das aber echt nicht gewesen! Hier hat die Indizierung definitiv meinen Speicher gefressen (sieht man ja in top, war hauptsächlich virtuoso, aber auch nepomukservices selber mit einigen Hundert MB...), und sicher bei einigen anderen auch, trotz Begrenzung in den Settings! Keine Ahnung was das war, es ist auf jeden Fall jetzt weg...

 

Ok, egal, was da mal alles vor Monaten nicht funktioniert hat. Aber bei aktuell 4.4.4 kann ich bei mir keine Fehler mehr finden. Jedenfalls mit dem mplayer für die Thumbnails. Von daher kann ich es nicht nachvollziehen, dass sich so viele über die Desktopsuche aufregen.

----------

## toralf

Und ich lerne kwallet langsam schätzen - insbesondere, wenn man sehr viele ssh und/oder email accounts zu verwalten hat.

----------

## Josef.95

 *toralf wrote:*   

> Und ich lerne kwallet langsam schätzen - insbesondere, wenn man sehr viele ssh und/oder email accounts zu verwalten hat.

 

++

dem kann ich nur zustimmen!

ist ne sehr feine Sache!

Und wer es nicht nutzen möchte der kann es ja, wie schon erwähnt, auch komplett deaktivieren.

Ein wenig Info

http://de.wikipedia.org/wiki/KWallet

.....................................................................................................................................................................

/edit:

Noch kurz was zu meiner Meinung und Erfahrung zum eigentlichen Topic

semantic-desktop: Widerstand zwecklos?

Ich hab mich auch lange Zeit gesträubt "semantic-desktop" zuzulassen und Teile davon zu nutzen.

Bei vielen Paketen gibt es ja die USE-flag "semantic-desktop" daher sollte man meinen die Unterstützung sei Optional, und das stimmt auch soweit.

Es kommt aber auf drauf an welches Paket es als Abhängigkeit fordert,

einer der häufigsten Kandidaten ist wohl kmail da ihn viele Leute nutzen,

weitere sind hier zb 

```
 $ euse -I semantic-desktop

global use flags (searching: semantic-desktop)

************************************************************

[- c  ] semantic-desktop - Cross-KDE support for semantic search and information retrieval

Installed packages matching this USE flag: 

kde-base/dolphin-4.4.4

kde-base/gwenview-4.4.4-r1

kde-base/kdebase-runtime-meta-4.4.4

kde-base/kdelibs-4.4.4

kde-base/kdepimlibs-4.4.4

kde-base/kdeplasma-addons-4.4.4

kde-base/kget-4.4.4

kde-base/plasma-workspace-4.4.4

kde-base/pykde4-4.4.4

media-gfx/digikam-1.2.0-r1

media-sound/amarok-2.3.1-r1

media-video/kdenlive-0.7.7.1

local use flags (searching: semantic-desktop)

************************************************************

!!! -e, --exact-name is now default.

!!! Use globbing to simulate the old behavior.

[- c  ] semantic-desktop (kde-base/pykde4):

Enables Nepomuk and Soprano python language bindings
```

Sprich, möchte man kmail nutzen, oder in einer der anderen genanten Beispiel Pakete Dienste von "semantic-desktop" nutzen,

ja, dann ist Widerstand wohl zwecklos....  :Wink: 

----------

## mv

Ja, kmail ohne semantic-desktop is nich, denn soweit ich weiß werden die Mails (oder zumindest ist das geplant) ausschließlich in strigi o.ä. gespeichert (die genaue Architektur kenne ich nicht und will ich auch nicht kennen). Bisher kommt man noch drumrum, indem man qmail statt kmail benutzt. Jedoch haben die kde-Entwickler gerade angedroht, dass sie auch diese letzte Möglichkeit einer vernünftigen Nutzung für Rechner mit beschränktem Plattenplatz oder sicherheitsbewusstere User bewusst kappen wollen. Wie bei Microsoft wird das Ganze ohne vernünftiges Sicherheitskonzept gestrickt, und man glaubt, das dann im Nachhinein durch ein paar "Sicherheitsfunktionen" nachklappen zu können. Damit ist für mich zumindest klar, dass KDE voll in die falsche Richtung abfährt. Da Gnome ohne das *kit-Geraffel (und damit acl und attr - unabhängig, ob das Sicherheitskonzept des Rechners das vorsieht - und übrigens auch den ganzen docbook-bloat für die Kompilation) nicht zu haben ist, werde ich die von mir betreuten Rechner wohl demnächst wieder auf fvwm umstellen.

----------

## franzf

 *mv wrote:*   

> denn soweit ich weiß werden die Mails (oder zumindest ist das geplant) ausschließlich in strigi o.ä. gespeichert (die genaue Architektur kenne ich nicht und will ich auch nicht kennen).

 

strigi ist nur zum Dateien indizieren da, das speichert selber gar nix. KMail wird mit 4.5(.1, wohl eher) komplett auf akonadi umgestellt. AFAIK ist akonadi selber nur dazu da, zentral PIM-Daten zu speichern und zu verwalten. Neopomuk wiederum kümmert sich ums taggen. Z.B. hier stehen ein paar Sachen, was jetzt kdepim mit nepomuk anfangen will.

Dein verlinkter Thread ist ja auch schon etwas älter, die Probleme hatte ich auch, sind aber mittlerweile behoben (extremste Speicher/CPU-Vergewaltigung).

Wo siehst du die extremen Sicherheitsprobleme? (Vor allem wenn du die Architektur gar net kennst  :Razz: )

Und, naja, wenn es dir nur um den Plattenplatz geht hoffe ich du hast noch nie andere Plasma-themes probiert. Das hat mir mal meine Platte übelst fragmentiert  :Razz:  (Schau mal gaaaaanz vorsichtig nach /var/tmp/kdecache-<user>/kpc/)

----------

## mv

 *franzf wrote:*   

> Dein verlinkter Thread ist ja auch schon etwas älter

 

Das betreffende Posting ist nagelneu (von gestern).

 *Quote:*   

> Wo siehst du die extremen Sicherheitsprobleme? (Vor allem wenn du die Architektur gar net kennst )

 

Unix hat eine einigermaßen gute Rechtetrennung. Die wird durch Indizierung de facto ausgehebelt. Wie da dann irgendwie wieder etwas draufgesetzt wird, ist dann letztlich egal, weil das einfach prinzipiell komplexer und damit fehleranfälliger als die Unix-eigene Rechtetrennung ist. Und die Erfahrung zeigt: Sicherheit muss im Ansatz berücksichtig werden; das kann man nicht im Nachhinein "draufschrauben".

 *Quote:*   

> Und, naja, wenn es dir nur um den Plattenplatz geht hoffe ich du hast noch nie andere Plasma-themes probiert.

 

Ganz bestimmt nicht, und auch für die Wallpapers habe ich gleich ein Dummy-Ebuild gemacht. So ein kleiner älterer Laptop hat halt nun mal max. 10 GB Platte, wobei da noch kräftig User-Daten mit drauf sollen. Da ist halt schon für die Installation von Nepomuk (mit den ganzen Datenbank-Abhängigkeiten, die man alle nicht braucht, wenn man nicht indizieren will) kein Platz mehr.

----------

## musv

Wie ich hier schon paar Mal erwähnt hab, nutze ich als Desktop-Manager e16.  

In der Linuxwelt kann man sich halt nunmal die meisten Applikationen entweder aus der GTK- oder aus der KDE-Welt raussuchen. Mir persönlich gefallen die KDE-Anwendungen häufig besser. Das Schöne daran ist, dass man trotz Abhängigkeiten zu Qt, Kdelibs und gtk+ trotzdem eine einigermaßen gleich aussehende Oberfläche hinbekommt. 

Aber:

Ich will den KDE-Desktop nicht, da mir mein e16 besser gefällt. Ich will Semantic-Desktop nicht, ich brauch keine Dateiindizierung. Locate für Dateinamen und mein Wiki für alle möglichen "Erkenntnisaufzeichnungen" reichen mir. KWallet kam bei mir nur in Kopete zum Vorschein. Und für eine einzige Applikation brauch ich das nicht. Das angesprochene KMail hab ich auch nicht. Bin seit vielen Jahren an Claws-Mail gewöhnt.

Von daher empfinde ich diese Entwicklung als nicht gerade sehr schön. Schlimmer noch bei KDE4 ist, dass ich noch diverse KDE3-Anwendungen nutzen muss, weil ich die KDE4-Versionen nicht für brauchbar halte. Da wären:

- K3b findet keine Laufwerke, da ich HAL nicht nutze und auch nicht installieren werde.

- Amarok - dazu muss man nicht wirklich viel sagen.

- Quanta fehlt in der Portierung noch ganz. Der Tipp, dafür KDevelop zu nutzen, war für mich nicht ganz nachvollziehbar.

Tja, der Weg von KDE4 ist wohl noch lang, damit ich wieder zufrieden damit leben kann.

----------

## franzf

 *mv wrote:*   

>  *franzf wrote:*   Dein verlinkter Thread ist ja auch schon etwas älter 
> 
> Das betreffende Posting ist nagelneu (von gestern).

 

Das neueste Posting ja, alle übrigen sind alt.

Ich bezog mich dabei auf die "alten" Probleme, die erwähnt wurden -  die sollten mittlerweile behoben sein.

 *Quote:*   

>  *Quote:*   Wo siehst du die extremen Sicherheitsprobleme? (Vor allem wenn du die Architektur gar net kennst ) 
> 
> Unix hat eine einigermaßen gute Rechtetrennung. Die wird durch Indizierung de facto ausgehebelt. Wie da dann irgendwie wieder etwas draufgesetzt wird, ist dann letztlich egal, weil das einfach prinzipiell komplexer und damit fehleranfälliger als die Unix-eigene Rechtetrennung ist. Und die Erfahrung zeigt: Sicherheit muss im Ansatz berücksichtig werden; das kann man nicht im Nachhinein "draufschrauben".

 

Ich seh das Problem immer noch nicht so wirklich. akonadi/nepomuk laufen in ihren eigenen Prozessen, jesweils mit den Rechten des jeweiligen Users. Die Datenbank ist auch ein User-eigener Prozess, das läuft nicht über einen globalen DB-Server-Prozess. Die Metadaten liegen im Verzeichnis des Benutzers, sind also durch Dateisystemrechte geschützt.

Dein letzter Satz bezieht sich wohl auf das hier:

 *Quote:*   

> you can share tags and semantic data, it's a research project which is ongoing - 'just' need to solve the privacy issues

 

Klar - wenn man Tags, also die Metadaten, mit anderen Nutzern teilen kann, kann es zu Problemen kommen. Man muss aber eben die Metadaten nicht teilen. Und wer es tut ist wohl auch gut in den sozialen Netzen (facebook etc) unterwegs, und jeder da draußen kennt mehr Einzelheiten über das private Leben als die eigenen Eltern...

Und dass das Teilen noch ein "research project" ist, heißt doch dass es selbst in den Wurzeln noch nicht endgültig ist, man muss also nicht nur einen Security-Aufsatz für ein fertiges System erfinden.

----------

## mv

 *franzf wrote:*   

> Och seh das Problem immer noch nicht so wirklich. akonadi/nepomuk laufen in ihren eigenen Prozessen, jesweils mit den Rechten des jeweiligen Users. Die Datenbank ist auch ein User-eigener Prozess, das läuft nicht über einen globalen DB-Server-Prozess.

 

Wie bitte? Soll das heißen, auf einem Rechner mit 50 Usern wird 50 mal z.B. /usr/share/man, /usr/share/info, /usr/share/doc indiziert und in des Users eigener Datenbank gespeichert? Dann gibt es tatsächlich weniger Rechteprobleme, dafür aber viel mehr Platzverschwendung, als ich erwartet hatte.

 *Quote:*   

> Klar - wenn man Tags, also die Metadaten, mit anderen Nutzern teilen kann, kann es zu Problemen kommen. Man muss aber eben die Metadaten nicht teilen.

 

Bei allem, was man problemlos selbst lesen kann, muss man davon ausgehen, dass es durch Bugs möglich ist, dass sie auch ein anderer liest. Man braucht nur mit einem Browser mit einer pasenden Lücke unterwegs zu sein... deswegen sind gute Rechner so konfiguriert, dass der Browser oder andere Dinge, die auf das Netz zugreifen, unter einem geeigneten anderen Benutzer geöffnet werden. Schlimm genug, dass man dazu in KDE bereits jetzt diesem Browers vollen Zugriff auf das X geben muss; wenn aber z.B. mit dem Browser geholte Email oder andere Daten beim Benutzer landen soll, reicht das nicht aus, sondern der Browser braucht vollen Zugriff auf des Users KDE: Einfach die Files nach Herunterladen verschieben und mit entsprechenden Rechten versehen, geht ja nicht problemlos bei einer komplexen Datenbankstruktur.

----------

## Klaus Meier

Bei der Suche von KDE wird dein Homeverzeichnis durchsucht. Mehr nicht als Voreinstellung. Was man aber anpassen kann. Also werden auf einem Rechner mit 50 Usern 50 mal deren private Daten indiziert und dies abgespeichert. Nicht die von dir angegebenen /usr/share/irgendwas.

----------

## firefly

 *mv wrote:*   

>  *franzf wrote:*   Och seh das Problem immer noch nicht so wirklich. akonadi/nepomuk laufen in ihren eigenen Prozessen, jesweils mit den Rechten des jeweiligen Users. Die Datenbank ist auch ein User-eigener Prozess, das läuft nicht über einen globalen DB-Server-Prozess. 
> 
> Wie bitte? Soll das heißen, auf einem Rechner mit 50 Usern wird 50 mal z.B. /usr/share/man, /usr/share/info, /usr/share/doc indiziert und in des Users eigener Datenbank gespeichert? Dann gibt es tatsächlich weniger Rechteprobleme, dafür aber viel mehr Platzverschwendung, als ich erwartet hatte.

 

Falsch. Zu mindestens in der Standard Einstellung, wird von strigi nur das home Verzeichnes des Benutzers indiziert. Und nicht die komplette Festplatte.

----------

## mv

 *firefly wrote:*   

> Falsch. Zu mindestens in der Standard Einstellung, wird von strigi nur das home Verzeichnes des Benutzers indiziert. Und nicht die komplette Festplatte.

 

Das überrascht mich jetzt sehr, denn ich dachte, einer der Hauptpunkte von Nepomuk wäre, dass man - neben seinen eigenen Dokumenten - eben auch leicht Zugriff auf die Systemdokumente und -hilfen hätte. Gerade bei Alt-F2 o.ä. ist dann ja Nepomuk ziemlich witzlos, oder nicht?

----------

## firefly

 *mv wrote:*   

>  *firefly wrote:*   Falsch. Zu mindestens in der Standard Einstellung, wird von strigi nur das home Verzeichnes des Benutzers indiziert. Und nicht die komplette Festplatte. 
> 
> Das überrascht mich jetzt sehr, denn ich dachte, einer der Hauptpunkte von Nepomuk wäre, dass man - neben seinen eigenen Dokumenten - eben auch leicht Zugriff auf die Systemdokumente und -hilfen hätte. Gerade bei Alt-F2 o.ä. ist dann ja Nepomuk ziemlich witzlos, oder nicht?

 

Ich glaube du  und auch anderer verwechseln dar was. Nepomuk hat gar nichts mit der Dateiindizierung zu tun. Nepomuk ist nur ein Framework um metadaten zu speicher und zu verwalten.

Die Indizierung von Dateien ist strigi zuständig.

Krunner (über Alt+F2 erreichbar) verwendet auch nepomuk (wenn das nepomuk krunner plugin aktiviert ist) um nach Dateien zu suchen. Wenn aber strigi nicht aktiv ist, kannst du mit nepomuk nur nach Dateien suchen, für welche durch anderer Mechanismen metadaten in nepumuk eingetragen worden sind. Z.b. über das Erstellen und Verändern von Tags über dolphin.

----------

## mv

 *firefly wrote:*   

>  *mv wrote:*   Das überrascht mich jetzt sehr, denn ich dachte, einer der Hauptpunkte von Nepomuk wäre, dass man - neben seinen eigenen Dokumenten - eben auch leicht Zugriff auf die Systemdokumente und -hilfen hätte. Gerade bei Alt-F2 o.ä. ist dann ja Nepomuk ziemlich witzlos, oder nicht? 
> 
> Ich glaube du  und auch anderer verwechseln dar was. Nepomuk hat gar nichts mit der Dateiindizierung zu tun. Nepomuk ist nur ein Framework um metadaten zu speicher und zu verwalten.
> 
> Die Indizierung von Dateien ist strigi zuständig.
> ...

 

Das meinte ich mit "ziemlich witzlos": Da strigi laut firefly und Klaus Meier per Default nur Homedateien des Benutzers indiziert, nutzt nepomuk bei Alt+F2 per Default gar nichts - mal abgesehen von Daten, die der Benutzer händisch zu Systemdateien angibt, was aber wohl praktisch kein Benutzer machen wird.

----------

## firefly

 *mv wrote:*   

>  *firefly wrote:*    *mv wrote:*   Das überrascht mich jetzt sehr, denn ich dachte, einer der Hauptpunkte von Nepomuk wäre, dass man - neben seinen eigenen Dokumenten - eben auch leicht Zugriff auf die Systemdokumente und -hilfen hätte. Gerade bei Alt-F2 o.ä. ist dann ja Nepomuk ziemlich witzlos, oder nicht? 
> 
> Ich glaube du  und auch anderer verwechseln dar was. Nepomuk hat gar nichts mit der Dateiindizierung zu tun. Nepomuk ist nur ein Framework um metadaten zu speicher und zu verwalten.
> 
> Die Indizierung von Dateien ist strigi zuständig.
> ...

 

Sag das nicht, dass das kein Benutzer praktisch machen würde. Es gebt bestimmt genüg Benutzer die z.b. Ihre Musik/Video-Sammlung mit zusätzlichen Metadaten (z.b. Rating) versehen, welche vom Dateiformat nicht unterstützt wird. Aber momentan stimmt das, dass das nepomuk plugin von krunner nicht viel bringt. Aber wenn mehr Programme nepomuk verwenden, desto mehr infos können dann auch von krunner abgerufen werden um Benutzeranfragen zu beantworten.

----------

## mv

 *firefly wrote:*   

>  *mv wrote:*   mal abgesehen von Daten, die der Benutzer händisch zu Systemdateien angibt, was aber wohl praktisch kein Benutzer machen wird. 
> 
> Sag das nicht, dass das kein Benutzer praktisch machen würde. Es gebt bestimmt genüg Benutzer die z.b. Ihre Musik/Video-Sammlung mit zusätzlichen Metadaten (z.b. Rating) versehen, welche vom Dateiformat nicht unterstützt wird.

 

Eine Musik/Video-Sammlung hat nun aber mit Systemdateien, die mit F2 gestartet werden, wenig zu tun. Ich denke nicht, dass so großer Bedarf besteht, dass jemand die installierten Programme für sich selbst kommentiert (zumindest nicht im Regelfall). Deswegen hat es mich ja so überrascht, als ich eben lernte, dass da nicht per Default die Beschreibungen/manpages/infopages usw. in Nepomuk übernommen werden.

----------

## firefly

 *mv wrote:*   

>  *firefly wrote:*    *mv wrote:*   mal abgesehen von Daten, die der Benutzer händisch zu Systemdateien angibt, was aber wohl praktisch kein Benutzer machen wird. 
> 
> Sag das nicht, dass das kein Benutzer praktisch machen würde. Es gebt bestimmt genüg Benutzer die z.b. Ihre Musik/Video-Sammlung mit zusätzlichen Metadaten (z.b. Rating) versehen, welche vom Dateiformat nicht unterstützt wird. 
> 
> Eine Musik/Video-Sammlung hat nun aber mit Systemdateien, die mit F2 gestartet werden, wenig zu tun. Ich denke nicht, dass so großer Bedarf besteht, dass jemand die installierten Programme für sich selbst kommentiert (zumindest nicht im Regelfall). Deswegen hat es mich ja so überrascht, als ich eben lernte, dass da nicht per Default die Beschreibungen/manpages/infopages usw. in Nepomuk übernommen werden.

 

Jetzt musst du mir erklären was du mit systemdateien meinst. Denn dein satz mit dem ausführen hört sich nach programmen an. Und diese lassen sich über krunner auch ohne nepomuk starten.

----------

## mv

 *firefly wrote:*   

> Jetzt musst du mir erklären was du mit systemdateien meinst. Denn dein satz mit dem ausführen hört sich nach programmen an. Und diese lassen sich über krunner auch ohne nepomuk starten.

 

Dass das ohne nepomuk geht, weiß ich (so betreibe ich ja KDE). Genau das war ja meine erstaunte Feststellung: Dass nepomuk für krunner absolut nichts bringt. Wenn, dann läge der Nutzen doch darin, dass ein unbedarfter User vielleicht mit Nepomuk ein Programm findet, das das tut, was er mit Nepomuk suchen will. Wenn die zugehörigen Daten aber per Default gar nicht in der Datenbank stehen...

----------

## franzf

 *mv wrote:*   

> Dass das ohne nepomuk geht, weiß ich (so betreibe ich ja KDE). Genau das war ja meine erstaunte Feststellung: Dass nepomuk für krunner absolut nichts bringt. Wenn, dann läge der Nutzen doch darin, dass ein unbedarfter User vielleicht mit Nepomuk ein Programm findet, das das tut, was er mit Nepomuk suchen will. Wenn die zugehörigen Daten aber per Default gar nicht in der Datenbank stehen...

 

KRunner macht mittlerweile deutlich mehr als nur Programme zu finden und zu starten. Sonst wären ja die ganzen Runner total witzlos.

Was der Nepomuk-Runner bringt: Er findet Dateien des Benutzers über einen Tag (AFAIK kann man auch komplexere Suchanfragen ala SQL stellen), und kann diese bei Bedarf mit dem passenden Programm öffnen. Und was Hilfedateien (aka manpages) angeht: krunner kannn natürlich auch kio und öffnet bei "man:/cdrdao" die manpage zu cdrdao.

Das was du aber indirekt vorschlägst hört sich auch sehr interessant an und wäre durchaus einen Vorschlag wert: eine Assoziation manpage<->Programm, so dass eine Suche nach "kopieren" cp vorschlägt. Allerdings denke ich, dass eine direkte Suche via google nach einer bestimmten Tätigkeit wie "linux console copy files" besser ist, da ein via krunner gefundenes "cp" den User eher vor das Problem stellt "und wie weiter?", "Warum passiert bei "Enter" nix?", usw. Aber ob deshalb gleich alle manpages indiziert werden müssen - ich finde das wäre zu viel des Guten.

----------

## firefly

Wenn für ein Programm auch ein desktop file exisitiert und dieses sich auch in den suchpfaden für desktop files befindet, dann kann krunner auch über die Beschreibung, welche im desktop file enthalten ist, ein program finden. Sprich wenn du z.b browser im krunner angibst zeigt dir dieser alle programme an, in dessen desktop files unter beschreibung das wort browser enthalten ist.

Und das ganze funktioniert komplett ohne nepomuk.

----------

## Hilefoks

 *mv wrote:*   

> Das meinte ich mit "ziemlich witzlos": Da strigi laut firefly und Klaus Meier per Default nur Homedateien des Benutzers indiziert, nutzt nepomuk bei Alt+F2 per Default gar nichts - mal abgesehen von Daten, die der Benutzer händisch zu Systemdateien angibt, was aber wohl praktisch kein Benutzer machen wird.

 

Sorry - fast jede deiner Aussagen zu Nepomuk und Co. sind falsch.

Nepomuk bekommt seine Daten nicht nur von Strigi. Das ist eigentlich sogar der langweiligere Weg. Nepomuk kann seine Daten ebenso von Plasma, KMail, Amarok, Konversation, Dolphin, Konqueror, Kopete, PSI, Digikam, Firefox oder sonst einem Programm bekommen. Und zwar nicht nur jene die der Benutzer aktiv einpflegt, sondern insbesondere eben auch die, die automatisch gewonnen werden können. 

Letzten Endes speichert Nepomuk oft sogar genau das, was vorher auch schon gespeichert wurde. KMail musste schon immer die Information speichern, welche Mail zu welchem Anhang gehört. Und irgendwo musste KMail auch immer schon speichern welche Mail welches Flag (z.B. "Als wichtig makiert") erhält. Und auch Amarok speichert schon lange welches Lied wann gehört wurde. 

In der Vergangenheit hat jede Anwendung das speichern und verknüpfen solcher Informationen für sich gelöst, in der Zukunft wird jede KDE Anwendung dafür Nepomuk verwenden.

----------

## musv

 *Hilefoks wrote:*   

> Nepomuk bekommt seine Daten nicht nur von Strigi. Das ist eigentlich sogar der langweiligere Weg. Nepomuk kann seine Daten ebenso von Plasma, KMail, Amarok, Konversation, Dolphin, Konqueror, Kopete, PSI, Digikam, Firefox oder sonst einem Programm bekommen. Und zwar nicht nur jene die der Benutzer aktiv einpflegt, sondern insbesondere eben auch die, die automatisch gewonnen werden können. 
> 
> Letzten Endes speichert Nepomuk oft sogar genau das, was vorher auch schon gespeichert wurde. KMail musste schon immer die Information speichern, welche Mail zu welchem Anhang gehört. Und irgendwo musste KMail auch immer schon speichern welche Mail welches Flag (z.B. "Als wichtig makiert") erhält. Und auch Amarok speichert schon lange welches Lied wann gehört wurde. 
> 
> In der Vergangenheit hat jede Anwendung das speichern und verknüpfen solcher Informationen für sich gelöst, in der Zukunft wird jede KDE Anwendung dafür Nepomuk verwenden.

 

Also ist Nepomuk ein kleiner Schäuble, der alles wissen will? Dient das Teil dann nur für die Anwendungen zum Speichern eigener Angaben, oder ist das wie bei dbus, dass dann auch andere Anwendungen auf die Daten zugreifen können? Wielange werden die Metadaten gespeichert? Kann sich Nepomuk analog zur Windows-Registry zumüllen?

Wär klasse, wenn jemand mal für DAUs (mich) verständlich zusammenfassen kann, was nun die einzelnen von vielen eher argwöhnisch betrachteten Komponenten eigentlich machen:

- läuft als Daemon / Client

- Speicherverbrauch + CPU-Last

- Nutzen für welche Anwendungen

 Insbesondere denke ich da an:

- Nepomuk

- Strigi

- Semantic Desktop

----------

## Hilefoks

Der Vergleich mit Schäuble zeigt das eine gewisse Angst vorherrscht, das Nepomuk und Co. die Privatsphäre der Anwender bedroht. Diese Angst ist aber unbegründet. Wie bereits erwähnt, speichert Nepomuk insbesondere die Daten, die ohnehin bekannt sind und auch sonst irgendwo abgelegt werden müssten. Nepomuk vereinheitlicht lediglich den Zugriff auf diese Daten. Diese Daten waren also zuvor auch schon vorhanden, eben nur an anderer Stelle und zum Teil nicht so schön zugänglich/aufbereitet. Das letzteres bisher nicht der Fall war, verbessert aber keinesfalls den Schutz der Privatsphäre, sondern erschwert lediglich die "sinnvolle" Nutzung dieser Daten.

Nepomuk (wie auch Akonadi) sind prinzipiell Weiterentwicklungen von Bibliotheken, die es zum Teil bereits in KDE 1 gab (z.B. kab). Und es sind eben nur Bibliotheken. Und als solches extrahieren sie häufig verwendete Funktionalitäten, verallgemeinern diese und stellen sie allen Anwendungen zur Verfügung.

 *musv wrote:*   

> Dient das Teil dann nur für die Anwendungen zum Speichern eigener Angaben, oder ist das wie bei dbus, dass dann auch andere Anwendungen auf die Daten zugreifen können?

 

Ja, es dient Anwendungen eigene Daten zu speichern und ja, es dient eben auch dazu anderen Anwendungen Zugriff auf diese Daten zu ermöglichen.

 *musv wrote:*   

> Wielange werden die Metadaten gespeichert?

 

Metadaten sind i.A. keine zusätzlich erzeugten Daten, sondern meistens Daten die sowieso vorhanden und oft auch zwingend erforderlich sind. Beispiel: KMail weiß welcher Dateianhang zu welcher Email gehört. Diese Information muss KMail wissen. Leider geht diese Information nahezu verloren, wenn diese Datei weiterverarbeitet wird. Aber wieder: das sie verloren geht ist kein Gewinn für den Schutz der Privatsphäre, sondern nur ein Verlust für den sinnvollen Einsatz dieser Information. Warum? Weil ich als "evil -privatsphären Verletzer" diese Information ganz einfach gewinnen kann. Gibt es eine Datei "Lebenslauf.pdf" und will ich wissen an wenn diese wohl geschickt wurde, muss ich nur in deinen Postausgang schauen. Wurde sie zwischenzeitlich umbenannt, reicht ein Vergleich der MD5-Summen. 

Wann welche Metadaten gelöscht werden (können) hängt also auch stark von der Anwendung ab, die diese Daten erzeugt hat.

 *musv wrote:*   

> Kann sich Nepomuk analog zur Windows-Registry zumüllen?

 

Ja, das könnte passieren - kann ich mir zumindest vorstellen. Allerdings wären sowohl die Effekte als auch die Change dieses Problem technisch zu lösen eine ganz andere. Die Windows-Registry kann nur sehr schwer automatisch aufgeräumt werden. Beim Datenbestand von Nepomuk dürfte dies viel leichter und ungefährlicher sein. Außerdem werden auch die Programmierer sich solche Fragen gestellt haben und aus den Fehlern der Vergangenheit lernen.

 *musv wrote:*   

> läuft als Daemon / Client

 

Nepomuk und Akonadi werden gestartet so bald eine Anwendung sie benötigen, oder alternativ beim Start von KDE selbst. Um Ressourcen zu sparen beenden sie sich nach Gebrauch nicht (gleich) wieder, sondern laufen im Hintergrund weiter.

 *musv wrote:*   

> Speicherverbrauch + CPU-Last

 

Alle haben einen gewissen Speicherverbrauch und erzeugen natürlich CPU-Last. Allerdings ist dieser nach einer Initialisierungsphase recht unerheblich und, und das darf man auch nicht vergessen, dafür entfällt einiges bei den Anwendungen selbst. Zudem verteilen Nepomuk und Co. die anfallende Arbeit erheblich besser auf freie Ressourcen (z.B. verschiedene Prozessoren) und auf Idle-Phasen als es die Anwendungen selber könnten. Würden Nepomuk & Co. nur das ersetzen, was es vorher schon gab, dürfte der Ressourcenverbrauch sogar sinken.

 *musv wrote:*   

> Nutzen für welche Anwendungen

 

Nepomuk wird viele Anwendungen durchziehen. KMail, KAddressbook, KOrganizer, ... also alle PIM Anwendungen. Aber auch Browser, Dateimanager, Audioplayer, Videoplayer und viele mehr. Letztlich sogar alle KDE-Anwendungen, denn es wird sich z.B. auch im Dateiauswahldialog bemerkbar machen.

Um mal ein anderes Beispiel zu bemühen: 

Der Videoplayer Dragon-Player speichert die Position eines laufenden Videos wenn er geschlossen wird. Amarok macht das gleiche für Musik. Eine nette Funktion wie ich finde. In Zukunft könnte ich allerdings auch alle Videos wiederfinden, die ich einmal angefangen, aber nie zu ende geschaut habe. Ebenso wie alle nicht zu ende gehörten Podcasts aus Amarok. Und zwar nicht nur mittels der jeweiligen Anwendung, sondern z.B. auch mittels Dolphin.

 *musv wrote:*   

> Nepomuk, Strigi und der Semantic Desktop

 

Strigi ist ein weiteres Puzzlestück. Strigi ist lediglich ein Programm zur Indizierung von Informationen. Es ist damit vergleichbar mit den bekannteren Beagle oder Tracker. Es erstellt also einen durchsuchbaren Index von eher statischen Informationen zu den durchsuchten Dateien.

Nepomuk und Strigi sind zunächst unabhängig voneinander einsetzbar. Und Strigi kann auch gegen Tracker oder Beagle ausgetauscht werden. Nepomuk kann aber natürlich von den von diesen Desktopsuchen extrahieren Informationen profitieren.

Zu Nepomuk habe ich nun viel gesagt, aber immer noch nicht genug. Bisher nicht erwähnt und nur in den Beispielen angeklungen ist das eigentlich Neue an Nepomuk - Nepomuk gibt den Informationen eine für den Computer verwertbare Bedeutung. Das Ziel ist ein semantischer Desktop. 

Warum ist ein Anwender prinzipiell in der Lage die Frage zu beantworten, welcher befreundeten Person er zuletzt einen Dateianhang von mehr als 2 MB geschickt hat, der Computer aber nicht? Sofern der Anwender sich nicht einfach erinnert, haben beide ja die gleichen Daten zur Verfügung. Der Computer kann den vorhandenen Daten aber eben einfach keine Bedeutung beimessen. Und dies soll das Nepomuk Projekt ändern.

Siehe auch:

http://de.wikipedia.org/wiki/NEPOMUK_(Framework)

http://de.wikipedia.org/wiki/Semantisches_Netz

http://de.wikipedia.org/wiki/Semantisches_Web

http://de.wikipedia.org/wiki/Semantischer_Desktop

http://de.wikipedia.org/wiki/Metadaten

http://de.wikipedia.org/wiki/Strigi

http://de.wikipedia.org/wiki/Beagle_(Software)

http://de.wikipedia.org/wiki/Meta_Tracker

P.S: Nepomuk und Co. können heute noch nicht ihr Potential zeigen. In den letzten ~2 Jahren mussten zunächst die grundlegenden Frameworks geschaffen und etabliert werden. Ein typisches Henne-Ei Problem wie schon zu KDE 4.0 Zeiten. Kein Entwickler portiert seine Anwendung auf ein Framework das es noch nicht in die Mainstream-Distributionen geschafft hat.

Inzwischen sind diese Frameworks aber etabliert und so fangen Anwendungsentwickler (mich eingeschlossen) an, ihre Anwendungen zu portieren. Bis die grossen Anwendungen allerdings portiert wurden, werden nochmal 1-2 Jahre ins Land ziehen. Und erst wenn genügend Anwendungen portiert wurden, werden Nepomuk und Co. ihr Potential zeigen können.

----------

## mv

 *Hilefoks wrote:*   

> Der Vergleich mit Schäuble zeigt das eine gewisse Angst vorherrscht, das Nepomuk und Co. die Privatsphäre der Anwender bedroht. Diese Angst ist aber unbegründet.

 

Dein weiteres Posting demonstriert das genaue Gegenteil.

 *Quote:*   

> Wie bereits erwähnt, speichert Nepomuk insbesondere die Daten, die ohnehin bekannt sind und auch sonst irgendwo abgelegt werden müssten.

 

Dies ist nur ein Teil der Daten. Der andere Teil ist der, von dem Du vielleicht gar nicht willst, dass sie gespeichert werden: Mit welchem Tool von welcher URL Du bestimmte Daten geholt hast, beispielsweise.

 *Quote:*   

> Nepomuk vereinheitlicht lediglich den Zugriff auf diese Daten. Diese Daten waren also zuvor auch schon vorhanden, eben nur an anderer Stelle und zum Teil nicht so schön zugänglich/aufbereitet.

 

Jetzt sind sie zwar für KDE-Programme aufbereitet, für andere Programme und den User aber praktisch nicht mehr zugänglich und mit (Standard-)Skripten u.ä. praktisch nicht mehr editierbar. Der Übergang ist Vergleichbar mit dem Übergang von ASCII-Konfigurationsdateien eines Unix-Systems auf die Registry eines Windows-System: Fans von Letzterem bejubeln, dass alles "einheitlich" sei, aber jeder, der Erfahrung mit Unix hat, weiß die klare und übersichtliche ASCII-Konfiguration zu schätzen, die man bei Bedarf gescriptet ändern oder (in gezielten Teilen) auf andere Rechner kopieren kann. Klar, vieles davon geht theoretisch mit der Windows-Registry auch (export von Teilen als ASCII, dann bearbeiten, dann wieder zurücklesen oder auf andere Rechner kopieren). Aber will das wirklich jemand? Und nicht nur mit der Registry sondern mit allen seinen Daten?

 *Quote:*   

> Beispiel: KMail weiß welcher Dateianhang zu welcher Email gehört. Diese Information muss KMail wissen. Leider geht diese Information nahezu verloren, wenn diese Datei weiterverarbeitet wird. Aber wieder: das sie verloren geht ist kein Gewinn für den Schutz der Privatsphäre, sondern nur ein Verlust für den sinnvollen Einsatz dieser Information. Warum? Weil ich als "evil -privatsphären Verletzer" diese Information ganz einfach gewinnen kann.

 

Ach ja? Wenn Du eine Datei siehst, kannst Du ganz einfach erkennen, dass diese Datei mir von x als Anhang zur Mail y geschickt wurde? Und Du denkst, die ungefragte Speicherung solcher Informationen hat nichts mit Verletzung der Privatsphäre zu tun?

 *Quote:*   

> Gibt es eine Datei "Lebenslauf.pdf" und will ich wissen an wenn diese wohl geschickt wurde, muss ich nur in deinen Postausgang schauen.

 

Das klappt nur, solange Anhänge im Postausgang gespeichert werden und die Mail noch nicht vom Postausgang gelöscht wurde. Was man ja gerade bei empfindlicheren Daten garantiert nie machen würde...

 *Quote:*   

> Der Videoplayer Dragon-Player speichert die Position eines laufenden Videos wenn er geschlossen wird. Amarok macht das gleiche für Musik. Eine nette Funktion wie ich finde.  In Zukunft könnte ich allerdings auch alle Videos wiederfinden, die ich einmal angefangen, aber nie zu ende geschaut habe. Ebenso wie alle nicht zu ende gehörten Podcasts aus Amarok. Und zwar nicht nur mittels der jeweiligen Anwendung, sondern z.B. auch mittels Dolphin.

 

Auch so ein Beispiel, das so überhaupt nichts mit Verletzung der Privatsphäre zu tun hat, wenn jemand einsehen kann, wann ich welche Musik/Video gehört und wo unterbrochen habe... Marktforschungsfirmen werden begeistert sein. Tatsächlich ist das eine Datenschutz-GAU!

Edit: Zitatautor korrigiert.Last edited by mv on Mon Jun 28, 2010 5:18 pm; edited 1 time in total

----------

## Finswimmer

 *mv wrote:*   

> 
> 
> Auch so ein Beispiel, das so überhaupt nichts mit Verletzung der Privatsphäre zu tun hat, wenn jemand einsehen kann, wann ich welche Musik/Video gehört und wo unterbrochen habe... Marktforschungsfirmen werden begeistert sein. Tatsächlich ist das eine Datenschutz-GAU!

 

Nur als Randbemerkung:

Es geht um deine eigenen Dateien, da alles Userbezogen läuft.

Natürlich kann die Marktforschungsfirmen an deinen Rechner gehen (sofern er ungeschützt ist) und sich diese Daten dann anschauen.

Aber das kann man auch ohne Nepomuk und Co.

Ich verstehe die Panikmache in Bezug auf Datensicherheit bei Dir nicht, denn ein anderer User/Person/Institution sieht die nur dann, wenn du sie bewusst frei gibst. Wo ist da der Unterschied zu jetzt?

Tobi

----------

## franzf

 *Finswimmer wrote:*   

> Ich verstehe die Panikmache in Bezug auf Datensicherheit bei Dir nicht, denn ein anderer User/Person/Institution sieht die nur dann, wenn du sie bewusst frei gibst. Wo ist da der Unterschied zu jetzt?

 

Ich denke es geht ihm um die Speicherung der Zusammenhänge von temporären Aktionen. Wenn ich irgendwem eine Datei maile, was nicht jeder wissen soll, und dann unbemerkt im Nepomuk-Index dies protokolliert wird (am besten noch mit aus der Datei indizierten Tags), ist dies im günstigsten Falle nervig.

Die Lösung liegt in der Nepomuk Query Language, mit der du (wie bei SQL) Datensätze abfragen und manipurlieren kannst. Wenn man einen so hohen Sicherheitswunsch artikuliert, hat man sich intensiv mit dem System auseinander gesetzt und versteht abstraktere Mechanismen, ist also sicher in der Lage ein Script zu schreiben, welches einem die ungeliebten Informationen löscht. Das ganze als Cronjob und man ist auf der sicheren Seite. Und ja, es wäre schön wenn es eine Option gäbe mit der man dieses Sicherheitslevel per Default einstellen könnte. Aber damit rechne ich nicht, weil die große Basis dies nicht benötigt.

----------

## mv

 *franzf wrote:*   

> Wenn ich irgendwem eine Datei maile, was nicht jeder wissen soll, und dann unbemerkt im Nepomuk-Index dies protokolliert wird (am besten noch mit aus der Datei indizierten Tags), ist dies im günstigsten Falle nervig.

 

Hier glücklicherweise nur nervig, weil ich mir denken kann, dass Nepomuk diese Daten speichert, und sie dann gezielt wieder entfernen könnte. Hier ist die Nichtbenutzung von KDE lediglich bequemer.

Der "Master-Plan" von KDE ist ja aber viel schlimmer, nämlich dass alle möglichen Daten und Zusammenhänge in Nepomuk erfasst werden sollen, an die zwar vielleicht der Autor einer Spezialanwendung denkt, nicht aber unbedingt der Anwender (das Speichern der Abbruchstelle eines Songs war vielleicht für den einen oder anderen Anwender solch ein Beispiel). Das ist doch der absolute Albtraum: Der Computer sammelt Daten über Dich, und Du weißt nicht einmal genau, welche. Dann wird alles in irgendeiner binären Datenbank kodiert, was in der Praxis bedeutet, dass der Benutzer eigentlich auch keine Möglichkeit hast, zu verstehen, was da genau wie gespeichert wird, wenn er sich nicht mit allen Programmen genau befasst.

Zumindest für mich ist ein heftiger Grund, Windows nicht zu benutzen genau dieses Phänomen, dass im Hintergrund etwas passiert, und man (zumindest nicht ohne großen Aufwand) nicht verstehen kann, was das ist. Gerade das wird jetzt hier als sensationelle Verbesserung der Computertechnik gefeiert! Das mag verstehen wer will, ich werde mir Nepomuk auf keinen Fall installieren, und jeder, der auch nur Grundkenntnisse in Datenschutz besitzt, wird sich hoffentlich genauso verhalten. Glücklicherweise gibt es derzeit noch Autoren von Anwenderprogrammen, die gesunden Menschenverstand besitzen und nicht den Computer Daten über sich selbst sammeln lassen wollen.

 *Hilefoks wrote:*   

> Warum ist ein Anwender prinzipiell in der Lage die Frage zu beantworten, welcher befreundeten Person er zuletzt einen Dateianhang von mehr als 2 MB geschickt hat, der Computer aber nicht?

 

Das Beispiel passt hier gerade nicht genau, denn ein kleines grep beantwortet die Frage natürlich. Wenn es aber um komplexere Zusammenhänge, insbesondere im Zusammenhang mit Mails oder Files geht, die ich vielleicht bewusst gelöscht habe, bin ich sehr froh, dass der Computer nur genau die Fragen beantworten kann, deren Informationen ich ganz bewusst gespeichert habe. Ich zumindest will nicht, dass mein Computer (oder jemand, der irgendwie auf ihn Zugriff bekommen sollte) mehr über mich herausfinden kann, als das von mir bewusst Gespeicherte.

----------

## manuels

Ich könnt mir denken, dass es früher oder später ein Programm gibt, das die in Nepomuk erfassten Informationen kategorisiert auflistet und selektiv löschen kann.

Einen "Private"-Modus für Nepomuk ähnlich zu dem des Firefox' wäre ebenfalls denkbar.

Überhaupt kann man Nepomuk mit der History-Durchsuchenden Adressbar des FF vergleichen. Diese will ich nicht mehr missen.

----------

## mv

 *manuels wrote:*   

> Ich könnt mir denken, dass es früher oder später ein Programm gibt, das die in Nepomuk erfassten Informationen kategorisiert auflistet und selektiv löschen kann.

 

Nur dass Dir das wenig bringt, wenn die meiste Information kaum zu durchschauen ist. Spätestens wenn Du irgendetwas unverständliches gelöscht hast und danach siehst, dass Du die Anhänge Deiner gespeicherten Mails nicht mehr öffnen kannst, weil Du den Zusammenhang mit der zugehörigen Mail selbst aus der Datenbank gelöscht hast, wirst Du da händisches Eingreifen bleiben lassen. Die Analogie mit der Windows-Registry ist schon nicht schlecht, nur dass die Nepomuk-Datenbank über kurz oder lang viel umfangreicher und daher noch deutlich unübersichtlicher sein wird.

 *Quote:*   

> Überhaupt kann man Nepomuk mit der History-Durchsuchenden Adressbar des FF vergleichen. Diese will ich nicht mehr missen.

 

Nicht alles was hinkt, ist ein Vergleich. Du kannst Nepomuk eher mit der gesamten lokalen Datenbank des Firefox vergleichen. Also History und Reihenfolge aller aufgerufenen Seiten. Zusätzlich versehen mit Informationen, über die Du nicht genau Bescheid weißt, wenn Du Dir nicht den Firefox-Sourcecode genau ansiehst. Möglicherweise Daten, nach welcher Google-Anfrage oder welchem Werbebanner Du welche Seite nach welcher Zeit ausgewählt hast, oder was auch immer dann die Firefox-Programmierer oder die Leute, die sie dafür bezahlen für interessant halten. Nur dass sich bei Firefox selbst im schlimmsten Fall alles nur um Dein Surf-Verhalten dreht.

----------

## franzf

 *mv wrote:*   

> Spätestens wenn Du irgendetwas unverständliches gelöscht hast und danach siehst, dass Du die Anhänge Deiner gespeicherten Mails nicht mehr öffnen kannst, weil Du den Zusammenhang mit der zugehörigen Mail selbst aus der Datenbank gelöscht hast, wirst Du da händisches Eingreifen bleiben lassen.

 

akonadi setzt sich nicht über existierende Standards wie mbox/maildir/... hinweg. Wenn eine Mail mit Anhang vom Server auf die lokale Platte geholt wird, bleiben auch die Anhänge dabei. Wenn du aber jetzt hergehst, und den Anhang separat speicherst, kann sich nepomuk einschalten und einen Zusammenhang zwischen der lokalen Kopie und der Mail herstellen. Ein riesiges Sicherheitsproblem sehe ich da nicht, denn die Mail samt Anhang lag ja schon vorher auf der Platte.

Zum Rest: Man kann kein pauschales Urteil abgeben, solange man nicht weiß, was denn alles im Index landet. Auch bei deinen bisherigen Programmen weißt du nicht, was da sonst noch abspeichert wird, solange du nicht den Sourcecode anschaust. Und solche Information ist immer abgreifbar, egal ob das jetzt gemeinsam in einer DB oder separat im DATADIR des jeweiligen Programms ist.

Nepomuk ist eine neue, interessante Technololgie, die sich natürlich auch erst durchsetzen muss. Wenn du es nicht nutzen willst, nutze es nicht, gibt genügend Alternativen (an Programmen ohne Nepomuk). Ansonsten macht es einfach wenig Sinn, eine Sache schlecht zu reden, nur weil man es nicht kennt. Ist doch das selbe mit den Vuvuzelas bei der WM, die in Afrika einfach zum Fußballgeschehen dazu gehören. So wie die Alphörner zu den Alpen, oder das Didgeridoo zum Aborigine.

----------

## manuels

 *mv wrote:*   

> Die Analogie mit der Windows-Registry ist schon nicht schlecht, nur dass die Nepomuk-Datenbank über kurz oder lang viel umfangreicher und daher noch deutlich unübersichtlicher sein wird.

 Die Analogie zur Registry ist, wie franzf schon sagte, nicht angebracht: Nepomuk ist kein Speicherort für Daten. Es ist nur ein "Ort" in dem Metadaten _zusätzlich_ und nur zur Verarbeitung durch das Nepomuk-Framework gespeichert werden.

"Alles bleibt weiter an seinem Platz."

----------

## musv

manuels und mv: 

Danke für die Erklärungen und die Pros und Kontras. 

Jetzt bin ich etwas schlauer aber noch genauso dumm wie vorher. 

Fakt ist:

Ich versuche mein System so ressourcenschonend wie möglich zu bauen. Deswegen benutze ich auch Gentoo. Jeder Daemon, der sich irgendwo installieren will, wird erstmal kritisch hinterfragt. Aus diesem Grund hab ich z.B.:

PAM

Zeroconf

Pulseaudio

HAL

nicht installiert.

Mag sein, dass die Einstellung etwas übertrieben ist und effektiv auch wenig bringt. Aber ich hätte gern das auf meinem Rechner laufen, was ich will und sonst nichts. 

Die Sache mit den Ontologien / Semantic Web ist mir durchaus ein Begriff. War Teil meiner Diplomarbeit. Nur sehe ich noch nicht wirklich darin die Anwendung, was das mit den Daten auf meinem Rechner anstellen soll. Das Ziel läuft immer darauf hinaus, dass ich irgendwelches Wissen und  irgendwelche Daten auf meinem Rechner besser wiederfinden kann. Daran gefällt mir nicht, dass ich das eigentlich gar nicht brauch. Ich weiß, wo welche Daten liegen. Schon die Google-Desktopsearch fand ich im Gegensatz zu vielen Leuten nicht wirklich reizvoll. 

Sofern Nepomuk ein KDE-Äquivalent zu dbus darstellen sollte, versteh ich nicht, warum dann nicht gleich dbus verwendet wird.

----------

## firefly

 *musv wrote:*   

> Sofern Nepomuk ein KDE-Äquivalent zu dbus darstellen sollte, versteh ich nicht, warum dann nicht gleich dbus verwendet wird.

 

Das hat du falsch verstanden nepomuk ist kein äquivalent zu dbus. Sondern nepomuk verwendet für die Kommunikation dbus.

Sprich eine Applikation, welche nepomuk verwenden möchte, kann dies über dbus tun.

----------

## Necoro

Ich möchte mich hier einmal mvs Standpunkt anschliessen: Die Verbindung von Daten ist ein Datenschutzproblem -- denn nun können fremde Personen Zusammenhänge erkennen, die sie evtl. nicht sehen sollten (zb wäre es Ihnen vorher nicht möglich gewesen, herauszufinden, dass die Person in IMG_20601.jpg der Paul ist, mit dem ich letztes Jahr in Pisa war). Es ist Fremden dann ja auch nicht nur möglich Daten zu lesen -- sondern eben auch zu suchen ('ich weiss was du letzten Sommer getan hast'). Nicht umsonst laufen Datenschützer immer Sturm, sobald die Regierung mal wieder dabei ist vorhandene (!) Datenbestände miteinander in Verbindung zu setzen.

Und selbst unter der utopischen Annahme, dass niemand an den eigenen Rechner kann um Nachrichten auszulesen. Früher oder später kommt doch sicherlich auch jemand auf die Idee, sowas zentral zu speichern. In Kombination mit Katastrophen wie avahi/zeroconf, die dann auch mal 'automatisch' und 'vorsorglich' Verbindungen zu irgendwelchen im Netz vorhandenen Servern aufnehmen, wird das alles sehr unschön.

----------

## mv

 *franzf wrote:*   

> Zum Rest: Man kann kein pauschales Urteil abgeben, solange man nicht weiß, was denn alles im Index landet.

 

Und das genau ist das Problem (dass man das nicht weiß, ohne sich für jedes einzelne Programm darüber zu informieren).

 *Quote:*   

> Auch bei deinen bisherigen Programmen weißt du nicht, was da sonst noch abspeichert wird, solange du nicht den Sourcecode anschaust.

 

Ja, aber vernünftige Programme tun dies in ~/.programm, was man ggf. leicht entsorgen kann (übrigens ist das einer der Gründe, weshalb ich docbook-* vermeide: Das ganze sgml/xml&co-Geraffel, das ständig in /etc globale Listen verwaltet...)

 *Quote:*   

> Und solche Information ist immer abgreifbar, egal ob das jetzt gemeinsam in einer DB oder separat im DATADIR des jeweiligen Programms ist.

 

Im DATADIR hat man die Information von genau einem Programm, meist in menschenlesbarer Form. In Nepomuk stehen Daten aus vielen Programmen und Aktionen, und ein Verständnis wäre nur noch mit enormem Zeitaufwand möglich.

 *Quote:*   

> Nepomuk ist eine neue, interessante Technololgie, die sich natürlich auch erst durchsetzen muss. Wenn du es nicht nutzen willst, nutze es nicht, gibt genügend Alternativen (an Programmen ohne Nepomuk).

 

Ja, glücklicherweise derzeit noch. Wenn ich aber KDE ohne Nepomuk bald nicht mehr benutzen kann, ist das halt ein enormer technologischer Rückschritt. Das hatte ich schon bei amarok erlebt, dass ich das entsorgen musste, weil die Macher der Meinung waren, dass man ohne eine riesige Datenbank keine Musik spielen kann, dann kam kmail an die Reihe, und nun scheint auch noch der ganze Rest von KDE zu folgen. Diese "Entwicklung" nach hinten ist wirklich traurig.

 *Quote:*   

> Ansonsten macht es einfach wenig Sinn, eine Sache schlecht zu reden, nur weil man es nicht kennt.

 

Aber es macht sehr viel Sinn vor einer Sache zu warnen, deren Gefahr man kennt. Dazu muss man nicht wissen, was jetzt im Moment welche Programme in KDE mit Nepomuk anstellen. Deswegen ist auch die Diskussion, ob die Daten im Moment durch Strigi, pim, den Filemanager oder den Browser kommen, nur ein Strohmann (und erst recht die stellschweigende Unterstellung, man könne Nepomuk nicht beurteilen, wenn man sich über diese Details nicht informiert habe). Wie ja jeder weiß, soll dies ja nur ein kleiner Beginn sein. Wenn der Plan aufgehen sollte, wird über kurz oder lang niemand mehr einen Überblick haben, was genau von wo in Nepomuk gespeichert wird, und genau das ist das Problem.Last edited by mv on Tue Jun 29, 2010 10:52 pm; edited 1 time in total

----------

## Necoro

Problematisch ist auch, dass einige Entwickler die Datenschutz-Bedenken nicht haben ... oder zwar schon sehen, aber explizit ignorieren, weil in ihren Augen "Datenschutz" veraltet ist und so etwas auf dem Altar der Bequemlichkeit und des technischen Fortschritts geopfert werden kann.

----------

## mv

 *Necoro wrote:*   

> Problematisch ist auch, dass einige Entwickler die Datenschutz-Bedenken nicht haben ... oder zwar schon sehen, aber explizit ignorieren, weil in ihren Augen "Datenschutz" veraltet ist und so etwas auf dem Altar der Bequemlichkeit und des technischen Fortschritts geopfert werden kann.

 

Beifall-klatsch. Die naive Ausrede, im Nachhinein Sicherheit "draufsetzen" zu wollen, anstatt zuerst ein Sicherheitskonzept aufzustellen, dem dann alles untergeordnet werden muss, hat mir diese Attitüde sehr schön gezeigt. (Wer das technisch nicht versteht, sollte mal versuchen, Unix auf einem FAT-Dateisystem zu installieren und dann wichtige Daten von root zu verbergen...)

----------

## UTgamer

Leider mit 2 Wochen Verspätung, ich schließe mich voll und ganz mv, musv und Necoro an.

 *mv wrote:*   

>  *franzf wrote:*   Wenn ich irgendwem eine Datei maile, was nicht jeder wissen soll, und dann unbemerkt im Nepomuk-Index dies protokolliert wird (am besten noch mit aus der Datei indizierten Tags), ist dies im günstigsten Falle nervig. 
> 
> Hier glücklicherweise nur nervig, weil ich mir denken kann, dass Nepomuk diese Daten speichert, und sie dann gezielt wieder entfernen könnte. Hier ist die Nichtbenutzung von KDE lediglich bequemer.
> 
> Der "Master-Plan" von KDE ist ja aber viel schlimmer, nämlich dass alle möglichen Daten und Zusammenhänge in Nepomuk erfasst werden sollen, an die zwar vielleicht der Autor einer Spezialanwendung denkt, nicht aber unbedingt der Anwender (das Speichern der Abbruchstelle eines Songs war vielleicht für den einen oder anderen Anwender solch ein Beispiel). Das ist doch der absolute Albtraum: Der Computer sammelt Daten über Dich, und Du weißt nicht einmal genau, welche. Dann wird alles in irgendeiner binären Datenbank kodiert, was in der Praxis bedeutet, dass der Benutzer eigentlich auch keine Möglichkeit hast, zu verstehen, was da genau wie gespeichert wird, wenn er sich nicht mit allen Programmen genau befasst.
> ...

 100% Zustimmung.

Bereits als KDE in Version 3.6 anfing Zeroconf oder Avahi zu nutzen habe ich gestreickt, meinen Unmut losgeworden und 3.5 als letzte Version genutzt, jetzt nur mehr ausschließlich Flußbox mit dem Dateimanager = Worker // E-Mail = Thunderbird (bei claws fehlt mir HTML) // Seamonkey als Browser // Photobetrachter = Geeqie/GQview // Audio = Audacious // Video = VLC/Xine // Texteditor = nedit und als bequemen Taskmanger den xfce4-taskmanager. 

Von KDE nutze ich auschließlich nur noch K3b, Kpat und Kolourpaint, alles andere ist für mich gestorben.

 *musv wrote:*   

> manuels und mv: 
> 
> Danke für die Erklärungen und die Pros und Kontras. 
> 
> Jetzt bin ich etwas schlauer aber noch genauso dumm wie vorher. 
> ...

 100% Zustimmung.

Aus diesem Grund hab ich z.B.:

PAM

Zeroconf

Pulseaudio auch nicht installiert.

 *Necoro wrote:*   

> Ich möchte mich hier einmal mvs Standpunkt anschliessen: Die Verbindung von Daten ist ein Datenschutzproblem -- denn nun können fremde Personen Zusammenhänge erkennen, die sie evtl. nicht sehen sollten (zb wäre es Ihnen vorher nicht möglich gewesen, herauszufinden, dass die Person in IMG_20601.jpg der Paul ist, mit dem ich letztes Jahr in Pisa war). Es ist Fremden dann ja auch nicht nur möglich Daten zu lesen -- sondern eben auch zu suchen ('ich weiss was du letzten Sommer getan hast'). Nicht umsonst laufen Datenschützer immer Sturm, sobald die Regierung mal wieder dabei ist vorhandene (!) Datenbestände miteinander in Verbindung zu setzen.
> 
> Und selbst unter der utopischen Annahme, dass niemand an den eigenen Rechner kann um Nachrichten auszulesen. Früher oder später kommt doch sicherlich auch jemand auf die Idee, sowas zentral zu speichern. In Kombination mit Katastrophen wie avahi/zeroconf, die dann auch mal 'automatisch' und 'vorsorglich' Verbindungen zu irgendwelchen im Netz vorhandenen Servern aufnehmen, wird das alles sehr unschön.

 100% Zustimmung. 

Diese semantische Datenbank wird eines Tages schon ihren Weg nach draußen finden. In einem deutschen Forum wurde mein Seamonkey letzte Woche heftig auf GTK-Lücken abgeklappert, gut das ich noch eine ältere gtk-Config hatte (wegen nicht installiertem Gnome) und die Browserausgabe immer in einem Shellfenster ausgegeben wird (der Angriff wäre auf einem Ubuntu/Debian sicher durch gegangen). Ist zwar leicht störend ein weiteres Shellfenster rumfliegen zu haben dient aber unheimlich der Sicherheit meiner Daten.

Schönen Gruß

----------

## Terrere

Ich bin Windows/KDE frei

hehe, ja mei, Spass muss sei.

KDE hat mir damals das Einleben in Linux sehr erleichtert, war so mit Suse 7.

Nicht das ich jetzt ein Crack wär,

finde aber nun mittlerweile meine Daten auch ohne Konqi.

D-Bus, Hal, QT, Consolekit, andere "Sinnvolle Progs" wurden schon genannt.

In Linux gibts Hass-Tools wie Sand am Meer.

P.s. Natürlich gibts auch ne Schattenseite, wen man Gentoo nur mit lausigen

447 Packeten fährt; es gibt NICHT täglich was zum emerge -avutDN world

 :Smile: 

----------

## musv

Der nächste blöde Paukenschlag bei KDE. Ich hab's noch nicht weiter getestet, warum und was, aber:

Digikam will Fortran haben

Jetzt fragt man sich: Warum benötigt eine Applikation basierende auf KDE4 auf einmal Fortran? Ich mein, die Programmiersprache ist von 1957 und sollte eigentlich nur noch in irgendwelchen Dinosaurierindustrieapplikationen vorkommen, die aus irgendwelchen Gründen noch nicht refactored wurden. 

Bisher ist der Stand so, dass ich viele KDE-Apps eigentlich noch mag. Mal sehen, wenn ich dem ein Ende setz. Eventuell ist's auch nur ein fälschlich eingebautes Use-Flag. Werd das beim nächsten größeren Update (4.5?) mal testen.

----------

## Klaus Meier

Bei mir lässt sich KDE4 nur installieren, wenn ich im gcc Fortran aktiviere. Irgendwas braucht das, keine Ahnung was.

----------

## Finswimmer

Das scheint aber ein Gentoo Problem zu sein:

 *Quote:*   

> # gcc[fortran] is required since we cannot otherwise link to the lapack library
> 
> #   (the fun of unbundling)
> 
> DEPEND="${CDEPEND}
> ...

 

----------

## Finswimmer

 *Klaus Meier wrote:*   

> Bei mir lässt sich KDE4 nur installieren, wenn ich im gcc Fortran aktiviere. Irgendwas braucht das, keine Ahnung was.

 

Das liegt dann auch an Digikam.

Im gesamten Portage hängen nur Digikam und open64 von gcc[fortrane] ab.

Tobi

----------

## mv

 *musv wrote:*   

> Digikam will Fortran haben

 

Das hingegen finde ich eine verständliche Forderung von digicam: lapack ist die Standard-Mathematik-Bibliothek, und die ist halt nun mal in fortran geschrieben. Dass eine Bildverarbeitung auf eine bestehende Mathematik-Bibilothek zugreift statt das Rad selbst neu zu erfinden, ist vernünftig.

----------

## mv

 *Finswimmer wrote:*   

> Im gesamten Portage hängen nur Digikam und open64 von gcc[fortrane] ab.

 

Ja nun: lapack kann außer mit gcc[fortran] experimentell auch noch mit Intels Fortran-Compiler compiliert werden. De facto hat man hier aber eine (nicht in DEPEND genannte sondern nur zur Compile-Zeit überprüfte) Abhängigkeit von gcc[fortran].

----------

## musv

 *mv wrote:*   

>  *musv wrote:*   Digikam will Fortran haben 
> 
> Das hingegen finde ich eine verständliche Forderung von digicam: lapack ist die Standard-Mathematik-Bibliothek, und die ist halt nun mal in fortran geschrieben. Dass eine Bildverarbeitung auf eine bestehende Mathematik-Bibilothek zugreift statt das Rad selbst neu zu erfinden, ist vernünftig.

 

Gut akzeptiert. Warum ist die Bibliothek aber jetzt noch in Fortran geschrieben. Hätte man die nicht irgendwann mal in den letzten Jahrzehnten portieren können?

Die Edith hat grad Lapack++ gefunden. Sieht doch auf den ersten Blick vielversprechend aus.

----------

## mv

 *musv wrote:*   

> Gut akzeptiert. Warum ist die Bibliothek aber jetzt noch in Fortran geschrieben. Hätte man die nicht irgendwann mal in den letzten Jahrzehnten portieren können?

 

Leider ist bis heute Fortran die Sprache der Mathematik-Software: Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. In C++ kann man das zwar als Klassen "emulieren", aber es ist halt nicht der Standard (und die Implementation langsamer, da naturgemäß in C++ selbst geschrieben). Gerade auf Großrechnern mit extremer Rechenleistung gibt es oft extrem gute Fortran-Compiler, die noch ein Fizzelchen effizienter sind - und bei numerischen Problemen kommt es darauf oft an, weil für das Anmieten eines solchen Rechners für einen Tag dann viel Geld bezahlt wird, und am Ende des Tages sollte ein riesiges numerisches Problem dann auch gelöst sein.

Da auf solchen Rechnern dann eben der lapack/blas-Standard existiert (und dort meist hochoptimiert von einer Spezialfirma implementiert wurde), wird der dann halt auch auf kleineren Rechnern benutzt. Den Standard zu ändern, dürfte also schwierig sein.

Edit: Soweit ich weiß, ist lapack++ i.W. eine wrapper-Bibliothek: Sie macht es bequem, lapack/blas von C++ aus zu nutzen. Die Bibliothek selbst greift dabei aber auf den Origial fortran-Code zurück (wobei ich jetzt nicht weiß, ob der vollständig oder nur teilweise von einem fortran-to-c-compiler zuvor "bearbeitet" wurde); ich vermute, die Chancen sind gut, dass man für die Compilation von lapack++ daher ebenfalls gcc[fortran] benötigt.

----------

## musv

ok danke, wieder was gelernt.

----------

## manuels

 *mv wrote:*   

> Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache.

 

Sorry, jetzt wirds ein bisschen offtopic:

C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen.

Meiner Erfahrung wird Fortran in den Naturwissenschaften genutzt, da die Profs zu faul sind/keinen Grund sehen eine neue Programmiersprache zu lernen.

Als sie studiert haben, gab es Fortran. Und dabei sind sie geblieben.

----------

## Yamakuzure

manuels, Fortran wird immer noch weiterentwickelt. Aktuell ist nicht F77, sondern F08 (Fortran 2008).

Ein ganz interessanter Bericht, _warum_ Fortran nicht nur immer noch benutzt, sondern auch weiterentwickelt wird:

http://www.mid-day.com/lifestyle/2009/apr/170409-FORTRAN-programming-language-52nd-year-IT-Adda-Bangalore-C-language-code.htm

----------

## mv

 *manuels wrote:*   

>  *mv wrote:*   Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. 
> 
> Sorry, jetzt wirds ein bisschen offtopic:
> 
> C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen.

 

Das schrieb ich ja, aber beides gibt es in C++ nur indirekt über zusätzliche Klassen, nicht als Teil der "nativen" Sprache. Daher ist beides langsamer. (Dabei spielt es keine Rolle, ob es die "complex"-Klasse per Standard in jedem C++-Compiler zu geben hat: Es bleibt trotzdem eine zusätzliche Klasse und ist kein nativer Datentyp wie int,float,double. Für Rechnen mit beliebigen Genauigkeiten, Intervallarithmetik, o.ä. gibt es m.W. in C++ gar keinen Standard, sondern nur verschiedene unabhängige Bibliotheken. Wenn man dann mehreres kombinieren will, sieht es erst recht mau aus).

----------

## Treborius

 *mv wrote:*   

>  *manuels wrote:*    *mv wrote:*   Dort sind beispielsweise komplexe Zahlen und Rechnen mit hohen Genauigkeiten Bestandteil der Sprache. 
> 
> Sorry, jetzt wirds ein bisschen offtopic:
> 
> C++ bietet die selbe Genauigkeit und ebenfalls komplexe Zahlen. 
> ...

 

klinkt mich mal offtopic ein :

wenn du eine Klasse "complex" als POD schreibst (was in C++ ohne weiteres möglich ist) gibt es meiner meinung nach absolut keinen

geschwindigkeitsunterschied zwischen fortran und C++

ist doch egal ob Klasse oder nativ, für ne Addition von 2 complexen Zahlen muss der Prozessor genau die selben 2 ADDs machen,

ob nun fortran oder C++

----------

## mv

 *Treborius wrote:*   

> ist doch egal ob Klasse oder nativ, für ne Addition von 2 complexen Zahlen muss der Prozessor genau die selben 2 ADDs machen,
> 
> ob nun fortran oder C++

 

Für eine Operation, ja. Für Formeln (etwa x=a+b*c) muss aber beispielsweise der Compiler haufenweise temporäre Objekte erzeugen, die - wenn man mit Rechenregeln für komplexe Zahlen vertraut ist - durch Kommutativität der Addition oder Verwerfen vermieden werden können. Solche Annahmen kann ein Compiler aber bei Klassen im allgemeinen nicht machen. Abgesehen davon, dass ein guter Compiler anhand der Formellänge u.ä. entscheiden kann, ob er die Zahlen nun im Format (Real,Imag) abspeichert, oder ob sich des Erzeugen und Merken eines Zwischenergebnisses z.B. in Polarkoordineten für spezielle Multiplikationen oder Potenzierungen lohnt. Für die built-in-Typen nennen sich solche Optimierungen beim gcc CFLAGS=-ffast-math

----------

