wo bleibt der Multiuser Support, sprich Speicherung der Settings in den jeweiligen Ordnern der Benutzerprofile wie es andere populäre Tools wie VLC media player oder Azureus tun ?

Wofür sollte das gut sein? Vernünftige Einstellungen sind nicht vom User, sondern vom Rechner und der Internetanbindung abhängig.

Nur weil andere etwas anderes machen ist es nicht automatisch besser.

Im Gegenteil: so hat man alles was zum Muli gehört schön kompakt zusammen, was sowohl die Installation (entpacken -> läuft), als auch ein Backup erleichtert.

Als einer der ersten Gründe wäre dazu zu sagen, das nicht jeder User das gleiche freigibt und downloadet (Stichwort Privacy) !!!...

Wie alle modernen Programme und Systeme (z.b Linux) sollte auch eMule zwischen dem "bin" Standort mit den geimeinsamen Executables und anderen benötigten Dateien und "home" Standort mit den Settings und z.b den Downloads und Partfiles unterscheiden. Ich nenne das vollwärtige und Multiuserfreundliche Systemintegration.

Was schadet es ausser ein paar Kilobytes pro User ?

Ich würde mal gerne (vernünftige) Argumente dagegen hören ....

PS: Könnte mal jemand anfangen, eMule mit QT !!! speziell für KDE zu portieren ...

bei jedem benutzerwechsel emule neu starten? na denn

Schlauer uni-line Nutzer?

Moment mal, was möchtest du gleich?
Einen Client der alle deine Files übernehmen kann, oder ein neues Betriebssystem?

Schnelle Benutzerumschaltung in Xp und Mule läuft als temporär abgemeldeter User weiter (und läuft und läuft) ... -----> siehe Taskmanager

Nochwas ?

witzbold, wie soll das laufen wenn jeder andere sachen läd und shared

Jetzt klär mich doch einfach mal auf und sag wo da der Vorteil deiner Meinung nach liegen mag...

irgendwie bin Ich überrascht ... sehr sogar über diese ersten Reaktionen ... hmm , habt ihr überhaupt Multiusererfahrungen oder Kenntnisse im Bereich IT-Management ? Also nochmal im Klartext :

Beispiel Layout für meinen User n1ghtmare:

C:\Programme\eMule\

(emule.exe, lang ordner und dessen inhalt, webserver ordner und dessen inhalt, helpfiles , changelogs ,licences , uninstaller , Linkcreator.exe und last but not least die readme)

der config ordner mit gesamtem Inhalt (könnte ja jetzt auch eMule heissen)

liegt in C:\Profile\n1ghtmare\Anwendungsdaten ... ( C:\Profile enspricht auf Standard Xp Systemen "Dokumente und Einstellungen" ) damit es den config pfad "C:\Profile\n1ghtmare\Anwendungsdaten\eMule" ergibt

letztlich die temp und completed ordner sollten in den config ordner als (selbsverständlich nur) voreinstellung erstellt bzw. übernommen werden. (liegen bei mir eh woanders ...

Es geht einfach nur darum, Emule in ein Multiuser-OS zu integrieren, den schliesslich Userprofil Ordner die speicherorte von Benutzereinstellungen und nicht Ordner der Programme (Stichwort Dateiberechtigungen ) und per user verschiedene temp und completed ordner zu ermöglichen ...

Bei Single User Systemen ändert sich im Prinzip beim Handling nix ...

Man kann das doch ganz einfach regeln: Nehmen wir mal an eMule wird in einer WG mit vier Leuten benutzt. Es wird also ein PC aufgestellt auf dem nur eMule läuft. Alle vier Leute greifen via Webinterface auf eMule zu. Die Transfers sind in vier Kategorien unterteilt, für jeden Bewohner eine. Wird ein Download fertiggestellt, so wird er in das Verzeichnis des entsprechenden Bewohners kopiert (Bei den Kategorien kann man für jede Kategorie ein eigenes "Incoming"-Verzeichnis wählen).
Das einzige was man jetzt noch braucht ist ein wenig Vertrauen untereinander.

Viel Spaß damit, ich glaube kaum dass das mal jemand machen wird. aMule nutzt bereits wxWidgets anstatt MFC und ist so plattformunabhängig, vielleicht schaust du dir das mal an. (amule.org)

Ja - und weil ich darüberhinaus auch den Muli kenne halte ich den Vorschlag für unsinnig. eMule ist von seiner Natur her kein Multi-User Programm. Es macht keinen Sinn auf einem Rechner 4 Mulis mit unterschiedlichen Configs und jeweils anderen Files im Download nacheinander zu staten und 4 Mulis parallel auf einem Rechner zu starten ist ebenso sinnfrei.

Was du (möglicherweise) willst, ist ein Programmkern für den Download, der ggf. als Dienst auch im Hintergrund läuft und dazu ein multiusertaugliches GUI.

Dass man dazu den Muli komplett von grundauf neu stricken müsste sollte dir als IT-Profi klar sein und damit kennst auch die Wahrscheinlichkeit für eine derartige Umsetzung.

Das was du machen willst ist ganz einfach zu realisieren:

Du erstellst einfach anstatt den Ordnern (config zum Beispiel im eMule Verzeichniss) eine Verknüpfung, die auf einen ähnlichen Pfad wie diesem verweißt:
%userprofile%\Anwendungsdaten\eMule\config

Fertig! Da jeder Benutzer einen eigenen Profil-Pfad besitzt kommen sich die Dateien nicht in die Quäre. Auserdem lässt sich das System ohne große Eingriffe auch mit weiteren Benutzern einfach skalieren.


Und überhaupt, warum soll eMule portiert werden? Es läuft doch schon längst, mittels Wine, unter Linux (auch auf schnelleren Desktops als dem lahmen KDE).

So dumm ist die Idee garnicht. Ein Problem dabei ist auch, daß je nach Benutzerrechten nicht jeder User Schreibzugriff auf C:\Programme hat. Ich habe vor einer Weile eMule für jemanden auf einem Rechner installiert, auf dem nur ich Administratorrechte habe. Derjenige, der an dem Rechner normalerweise arbeitet, ist dagegen nur normaler Benutzer.

Die Incoming und Temp Ordner habe ich zwar in seinen "Eigene Dateien" Ordner gepackt, aber ganz vergessen, daß eMule ja auch ins Programmverzeichnis bzw. das config Unterverzeichnis schreibt. Entsprechend ist eMule natürlich ständig auf die Nase gefallen, weil es keinen Schreibzugriff auf die Dateien dort hatte. Zumindest bis ich die entsprechenden Berechtigungen manuell vergeben habe.

Bei einem Rechner mit mehreren Nicht-Administrator Konten ist es extrem lästig, wenn man für jedes Programm, das meint aus der Reihe tanzen zu müssen die Schreibberechtigungen im Programmverzeichnis manuell setzen muß. Irgednwann hat man dann gar keinen Überblick mehr, wer denn wo genau schreiben darf. Ist ja auch ein Sicherheitsfeature, daß normale Benutzer eben nicht überall nach Lust und Laune Schreibzugriff haben.

Die meisten neueren Programme (z.B. OpenOffice, Firefox, Thunderbird, Gimp...) halten sich auch dran und packen benutzerspezifische Sachen und Konfigurationsdateien in die Benutzerverzeichnisse.

Unter Linux funktioniert das ja auch schon lange und hat sich bewährt. Daher verstehe ich nicht, wieso es viele Entwickler nicht zu schätzen wissen, daß seit 2K/XP entsprechende Berechtigungen und Richtlinien auch für die breite Masse der Windows-Nutzer existieren (NT vorher wurde ja eher in Firmen eingesetzt). So mancher Entwickler ist anscheinend noch in der Win 95/98 Zeit hängen geblieben, wo jeder User alles durfte. z.B. erscheint manchmal heute noch neue, für den Alltagsgebrauch und Endanwender bestimmte Software, die nur mit den Administratorrechten läuft.

Ich hoffe mal, daß Microsoft wie angekündigt in Vista den richtigen Gebrauch und die Vergabe von Benutzerrechten forcieren wird. Wenn dann plötzlich nicht mehr 99% der Windows User mit Administratorrechten unterwegs sind, gibt das für einige Entwickler ein böses Erwachen.

ich lasse mein Muli auch als eingeschränkter Benutzer laufen,

einfach emule programmordner (und unterordner) rechte geben und ende is

[bei xp alles kein thema]

Dann mache das mal bei einem Rechner, mit 3-4 eingeschränkten Benutzerkonten auf dem 10-20 Programme laufen, die nicht die Benutzerverzeichnisse zum Speichern von Einstellungen nutzen.

Wenn sich nach einem Update die Verzeichnisstruktur ändert, darf man die Berechtigungen neu setzten. Jedesmal wenn ein Benutzer Programmeinstellungen ändert, oder gar auf die Idee kommt eigenmächtig eine andere/neue Version eines Programms zu installieren, sind auch die anderen Benutzer betroffen...

Mit der Zeit wird das recht nervig.

Vorschlag bleibt bestehen! Und man muss den Mule NICHT von Grund auf neu stricken, hab Modifikationen im Source in 3h hinbekommen, hat aber noch nen "Schönheitsfehler" bei anderen Sprachen ausser Deutsch.

Seine Unsinnigkeit auch!

Da du aber nicht auf Argumente eingehen magst, sondern schlicht auf deinem Standpunkt bestehst bin ich raus, denn diskutieren geht anders.

hol dir doch aMule, der speichert sogar ausserdem die prefs so wie dus willst (in ~/.aMule ) - is halt gtk und nicht qt, aber das ist ja wohl nicht weiter schlimm...

Bring einen Mod raus, dazu sind diese da.
Ich finde deinen Vorschlag allerdings auch gut. Klar ist es nicht sinnvoll 4 eMules nebeneinander laufen zu haben, dennoch gehören die Einstellungen bei Windows NT nicht in das Programmverzeichnis. Als eingeschränkter Benutzer ohne Schreibrechte ist es so wie es gegenwärtig ist nur unnötig kompliziert.
Übrigens kann man den Speicherort der Benutzerverzeichnisse auch anpassen.

Das sehe ich anders. Es reicht nicht die Konfig- und Temp-Dateien in ein Userverzeichnis zu legen... obwohl das quick & dirty sicher möglich wäre.

Das eigentliche Problem geht los, wenn ein Muli noch im Hintergrund weiterläuft, da sein Herrchen temporär abgemeldet ist - und ein zweiter, dritter, vierter User das gleiche macht!

Denk' mal über folgende Punkte nach (und zwar gründlich):
* welche Client-Ports verwendet die jeweilige Instanz? Das muß konfliktfrei konfiguriert werden!
* was ist, wenn mehrere solcher Rechner mit festen IPs in einem Studentenwohnheim hinter einem NAT-Router hängen... wird komplex werden!
* im übrigen: sobald mehr als drei Mulis mit gleicher IP-Adresse aber unterschiedlichen Client-Ports auftauchen werden diese von anderen gebannt, da das ein Kriterium für die Leecher-Erkennung ist.
* was passiert mit der verfügbaren Bandbreite (speziell dem Upload) und den max. Verbindungen usw. usw. ???
* Wenn da plötzlich mehrere konkurieren, müssen entweder die Maximalwerte auf den Worst-Case eingestellt werden (jeden einzelnen so begrenzen, dass in der Summe keine Limits überschritten werden) - oder es muss ein deutlich intelligenteres USS-Feature her, welches nicht anängt zu schwingen und lastabhängig ausregelt!
* Und ganz nebenbei: Falls die einzelnen User zufällig auch noch gleiche Downloadinteressen haben, sich aber wegen "Privatsphäre" nicht absprechen, dann laden mehrere Mulis die gleichen Files runter ohne voneninander zu wissen!
Welche Verschwendung von Bandbreite!

=> Dieser quick&dirty Muli wäre schwer beherrschbar und müßte sich selbst gegen mehrere gleichzeitig laufende Instanzen schützen, damit diese sich nicht gegenseitig Resourcen wegfressen und blockieren... sonst knirscht's im Gebälk!

=> Sambal Olek's Einwurf mit einer grundlegenden Überarbeitung des Konzeptes und einer Client-Server-Architektur mit permanent laufendem Dienst im Hintergrund und einer Client-GUI mit Login ist der einzig sinnvolle Weg!
Schließlich soll das Muli ja durchlaufen!

=> Ansonsten bräuchte man zumindest einen eigenen eMule-Resource-Manager, der die Resourcen (Portvergabe, Limits, etc.) unter den Clients gerecht verteilt - ähnlich wie ein Scheduler im OS das für die Rechenzeit in Multitaskingsystemen macht... Denn das Muli wird und muss immer versuchen an die Grenzen des Systems zu gehen!

Meine Meinung zu Architektur

Dann mach mal. Das wurde schon in der Vergangenheit öfters Vorgschlagen. Nur wenn du dir mal die Entstehungsgeschichte von eMule anschaust, wirst du feststellen, das das mehr ein Hobby-Projekt war/ist.

Somit wurde auch keine Trennung von GUI & Logik-Schicht vorgenommen (was bei MFC sowieso immer so eine Sache ist). Klar kann man das nachträglich machen, wenn man (sehr viel) Zeit und Lust dazu hat. Soweit ich weiß hat man das bei amule versucht/gemacht?

Zu den Configs: Das ist auch so ein Thema. Eigentlich muß man bei den neueren Betriebsystemen immer damit rechnen das man im Programme-Ordner keine Schreibrechte hat. Dabei ist das nur ein Registry-Eintrag den man auslesen muß.

Ich hatte da mal ein Projekte wo ich das benötigt hatte:


Wenn man man dort ein Unterverzechnis anlegt Namens "eMule" hat man das Problem gelöst und unterschiedlich Configs sind möglich und da das Temp und Incoming Verzechnis in der eMule Config abgelegt sind ist dieses Problem auch gleich weg.

Somit dürfte das Problem bei Newbie's auch wegfallen, die beim updaten von eMule versehentlich ihre Configs überschreiben.

Die drei Zeilen in den Muli einzubinden dürfte doch kein Problem sein?

PS: Die Registry-Einträge existieren seit Win95.

Er sagte ja nicht, dass man es so machen soll, sonder nur, dass es der richtigere Weg wäre

Es stellt sich aber weiterhin die Frage nach dem Sinn. Warum für ein und die selbe Umgebung (Rechner, Router, Internetzugang) unterschiedliche Konfigurationen? Es müsste doch sowieso jedesmal das gleiche drinstehen.

Mit dem "newbiefreundlichen" Installer kann das eigentlich gar nicht passieren.

Auch auf die Gefahr, dass ich mich wiederhole: alleine die Tatsache dass es geht, ist noch lange kein Grund es zu machen.

Der Hauptgrund dafür ist eigentlich weniger das man unterschiedliche Konfigurationen für eMule erstellen kann, das ist eher mehr ein evtl. brauchbarer Nebeneffekt. Der Hauptgrund hierfür ist eher, das das Konzept bei Windows NT und alle nachfolgenden Windows-Versionen normalerweiße keine Schreibrechte dem normalen Benutzer auf das Programme-Verzeichnis gewährt. Das war nur in der Windows 9x/ME Reihe so, welche auf ein anderes Konzept aufbaut als die NT-Betriebsysteme.

Wenn dann bei Windows Vista das Konzept umgesetzt wird, das man in Zukunft nur mit normalen Benutzerrechten arbeitet und Admin-Rechte nur für Systemwartung, etc. verwendet werden (so wie bei allen Unix-System eben), wird es spätestens dann zu Problemen kommen. Aus diesem Grund finde ich die Idee gut dieses Problem schon vorzeitig zu beseitigen.

Ich glaube es wurde auch im deutschen Bereich schon diskutiert und erklärt:

Ja es entspricht nicht dem Windows Konzept, trotzdem wurde damals entschieden es so zu machen, da es einige Vorteile besitzt (z.B. dass eMule eben nicht die registry braucht, dadurch die Konfigurationsdatein einfach zu editieren bzw. zu übernehmen sind und der benutzer genau weiß, was eMule an seinem System wo speichert).
Da 99% der privaten Benutzer eh immer als Admin eingeloggt sind, sind die Vorteile gering für die meisten wenn das Multi-user knzept benutzt worden wäre und erfahrende User können sich das relativ einfach selber einrichten (z.B. indem eMule im Benutzerverzeichnis gespeichert wird). Natürlich sah die Betriebsystemlandschaft vor 3-4 Jahren auch noch etwas anders aus.

Sollte sich das bei Vista ändern wird natürlich auch eMule entsprechend angepasst bzw ggf. optional auch so zu entsprechender zeit

Das schöne am Windows-Konzept ist ja, dass es -kaum hat man sich darauf eingestellt - zur Verwirrung aller wieder geändert wird.
Und mit Windows Vista jetzt einen "neuen" Weg gehen, der sich in der Unix-Welt seit 20 Jahren mit Erfolg bewährt hat! (Ironie)
Die Registry - ich mochte sie nie - ich mag sie nicht - und ich werde sie nie mögen... darum gefällt mir der "einfache" transparente Ansatz von eMule so gut!
Aber damit kommen die Plug&Play Kids von heute nicht mehr klar...

Nach so viel Polemik jetzt auch noch was konstruktives:
* ich denke es macht schon Sinn "Setup" und "Benutzereinstellungen" in Zukunft zu trennen... aber halt mit Vorplanung und Sachverstand - nicht nur ein paar Dateien in ein anderes Verzeichnis schieben oder mehrfach anlegen. Nur ein paar Ideen (ist sicher nicht vollständig):
* Benutzerdaten und Verzeichnisse (Temp / Incoming) per default unter dem $Home (oder wie immer das bei M$ heissen mag) der Anwender einhängen.
* Rechner- und Verbindungsspezifische Setups einmal global ablegen und nur dem Administrator zugänglich machen (wie man das z.B. von den Windows Netzwerk und TCP/IP Einstellungen kennt).
* dabei gibt der Administrator Dinge wie z.B. Obergrenzen (max. Verbindungen / max. Upload / etc.) und Porteinstellungen vor. (Zur Not kann so eine .ini-Datei mit Schreibrecht auch ins Windows-Verzeichnis - ist nicht schön - aber machen viele).
* Benutzerkram wie die server.met, client.met, downloads müssen ins Benutzerverzeichnis.
* der einzelne Benutzer darf dann seine Parameter nur noch in den Grenzen ändern, die ihm der Administrator vorgibt... andere (wie die Ports) darf er gar nicht mehr anfassen.
* usw. usw. usw.
* eine Multi-User-Multitasking-Anwendung ist eMule damit aber trotzdem nicht... doch zumindst der Single-User-Umschaltung nähert man sich an.

Aber brauchen wir das alles wirklich?
Wird es jemals Systemadministratoren in grossen Unternehmen geben, die eMule Clients für alle Mitarbeiter einzurichten haben?

und natürlich wäre die Vorgehensweise unsinnig für den Normaluser und das Netzwerk, denn die Warteschlangen wären ja getrennt, wann sollen denn die User wechseln und wie oft? Schon mal überlegt, daß der Emule erstmal einige Zeit rennen muß?

Oder sollen die gleichzeitig laufen und sich die Bandbreite teilen und dann auch damit nur die Server übermäßig auslasten????


Und möglichst ziehen die verschiedenen User, die ja nichts voneinander wissen, dann auch noch zufällig die gleichen Files, echt toll:-((((

Ansonsten würde ich dann einfach mal versuchen, jedem User sein Emule mit unterschiedlichen Verzeichnissen zu installieren, das dürfte gehen, dafür das Prog mit dem Unsinn vollzustopfen, macht wenig Sinn.

Dann muß halt einer den Emule-Admin spielen, nur er hat Zugriff, die anderen müssen bei ihm die Dls bestellen...

Dartho hats erkannt
wer will das emule seine configs nur in ein verzeichnis schreibt soll es halt komplett da reinkopieren
und multiuser configs sind einfach schwachsinn weil es nicht funktionieren kann
wegen der warteliste

meine Worte

Die Registry war auch nur als Bsp. genannt. Der Pfad für Anwendungsdaten lässt sich auch aus der Umgebungsvariable APPDATA auslesen...

Ich finde es eben generell keine schlechte Idee, wenn Programme und Einstellungen getrennt werden. Das hat sich ja auch bei den Unix Betriebsystem bewährt.

Erspart einem immer das neu setzten von Rechten auf die einzelnen Dateien, da ich auch zu denen gehöre die nur mit normalen Benutzerrechten unter Windows arbeiten und das Admin-Account nur für die Systempfelge verwendet.

weiterer Vorteil: Beim Backuppen geht nix vergessen wenn man einfach das User-Verzeichnis sichert

Dann sollte es für dich 10 Sekunden in Anspruch nehmen, eMule in diesen pfad zu kopieren. Aber 99% der anderen Benutzer würden nicht wissen dass sie die Konfigurationsdateien in z.B. C:\Dokumente und Einstellungen\[User Account]\Lokale Einstellungen\Anwendungsdaten\eMule\... finden würden und ihre Downloads entsprechend nocheinmal an einem anderem Platz ( z.B. Eigene Dateien\eMule\Downloads\ )

Aufgrund der massiven Hardware-Abhängigkeiten von eMule macht es grundsätzlich keinen Sinn, mehrere Instanzen unabhängig voneinander zu konfigurieren. (Schon die bewußte Konfiguration zweier simultan laufender Esel ist in den meisten Fällen ein Drahtseilakt, den ich nur erfahrenen Anwendern empfehlen würde.) Dieselbe eMule-Konfiguration, die für den Einsatzfall als Einzelexemplar optimal an die Randbedingungen einer Installation angepaßt ist, kann schon bei zweimaliger simultaner Verwendung eine völlige Katastrophe darstellen.
eMule ist konzentionell einfach nicht multiuserfähig, weil alle Installationen sich die gemeinsamen Ressourcen teilen müssen, tendentiell aber jeder alles haben will und folglich nicht genug Suppe für alle da ist.

Als Administrator oder "Eingeschränkter" User mit komplettzugriff auf das eMule Verzeichnis:
kommt ein Virus geflogen, infiziert die emule.exe. Startet der Administrator emule.exe, ist das System infiziert.

Als Eingeschränkter User ohne Schreibrechte auf das eMule Programmverzeichnis und Konfiguration an den Ort wo sie hingehören:
kommt ein Virus geflogen, kann emule.exe nicht infizieren, startet Administrator emule.exe, passiert nichts.



Richtiges Usermanagement ist eben immer noch besser als die eingebaute Funktion im eMule, ihn nicht als Administrator zu starten.

Das nenne ich kurz und Bündig beschrieben, wieso das ganze sinnvoll ist.

setzt du einfach die emule.exe auf readonly für alle
dann können sogar dem admin viren um die ohren fliegen und emule wird nicht infiziert

Wieso das keine tolle Lösung ist, wurde bereits ein paar Postings vorher erläutert...

warum soll das nicht toll sein? emule.exe schreiben brauchst du nur bei update

Es geht mehr ums Konzept. Konfigurationdaten gehören einfach nicht zu den Programmdaten. Zwar hat das Windows bis heute tolleriert aber bald eben nicht mehr (siehe Windows Vista). Das hat auch tatsächlich Vorteile. z.B. das was duffbeer geschrieben hat...

Wenn man sich aMule/xMule anschaut, realisieren die das genauso, weil das eben bei Unix Betriebsystemen schon seit Jahren forciert wird.

Schau dir mal ein paar deiner (neueren) installierten Windows Programme an. Die halten ihr Programmverzeichnis ebenfalls frei von Dateien, die der Benutzer verändern können soll.

Ich glaub wir drehen uns im Kreis, liegt vieleicht auch daran dass der Titel des Threads relativ ungeschickt gewählt ist (denn um Multiuser-Betrieb gehts primär eben nicht!).

Ausserdem denk ich dass es früher oder später eh kommt (ist keine grosse Änderung, und irgendeiner wird sich schon erbarmen ^^).