metux

Besser unter dem Stichwort "Evaluation" verpacken. Kommt besser an ;-)

Zimbra Open Source

der letzte Parameter von pthread_create wird an die thread-routine übergeben.

Mir ist immernoch nicht klar, warum Du extra etwas völlig neues programmieren willst, anstatt einfach ein entsprechendes Tool (zB. Gosa) dafür aufzusetzen.

Was mir hier grad nicht ganz klar ist: was genau soll denn in welche Richtung genau optimiert werden ?

Als absolten Show-Stopper. Im professionelen Einsatz von Softwaresystemen will man zunächst jedes Update _zumindest_ erstmal auf einen pre-production-System auftesten, bevor man entscheidet, ob man es überhaupt auf ein Produktivsystem loslassen will.

Praktisch alle paketorientierten Protokolle. Man kann auch ein wenig mogeln und bereits während dem Empfang schon mit dem Weitersenden beginnen (wenn man auf die Fehlerkorrektur verzichtet) - wird im Layer-2 oft getan. Wir können aber auch auf die höheren Layer schauen und zB. SMTP nennen.

Braucht man diesen Support ? Und muß es unbedingt VMware sein ? (wir setzen, obwohl Vmware-Vertriebsparter, selbst vorallem KVM ein ...)

Daß man überall seine Fingerabdrücke hinterläßt und die leicht kopierbar sind, ist wohl noch niemanden hier aufgefallen ? ;-o

Warum genau hast Du Dich schon vornherein auf ein Produkt festgelegt ? Wäre es nicht angebracht, vorher auch erstmal andere Groupware-Systeme, (da fiele mir zB. als allererstes Zimbra ein) zu evaluieren ?

Also eine kundenseitige Dokumentation hat doch einen völlig anderen Scope. Daraus ergibt sich zB. eine viel gröbere Granularität, andere Strukturierung und Formulierungen. Sowas sollte man wohl besser manuell pflegen. Mit CVS kann man auch nur sehr, sehr eingeschränkt arbeiten. (sehr diplomatisch ausgedrückt!) Vielleicht sollte man da mal einen externen Berater einkaufen - richtig teuer, dann gibts auch mehr Anerkennung ;-o

Mal als kleine Randbemerkung: als IT-Integrator würde ich nie eine Software ausrollen, die sich irgendwann nach Belieben mal selbst updated. Absolutes no-go ! Und erst recht nicht, wenn sie sich auch noch von Ferne abschalten läßt.

Aha, also ein Trojanisches Pferd ;-o Wie wärs denn, wenn Du stattdessen mal genauer analysiertest, was der Kunde wirklich braucht. Warum will er überhaupt eine Cloud-basierte Lösung ? Welche Angebote gibts da ? Wie können die zu dem Bedarf des Unternehmens passen ? Wenn die Firma wirklich ernsthaft darüber nachdenkt, würde ich das ganze doch eher als Evaluationsprojekt aufziehen. Dh. es geht dann garnicht darum, das gleich für den Produktiveinsatz zu implementieren, sondern erstmal ein proof-of-concept zu erstellen, am besten gleich mit mehreren Alternativen, und anschließend die gewonnenen Erkenntnisse darstellen (pros/cons der einzelnen Varianten, Aufwände/Kosten, Nutzen, Auswirkungen auf längerfristige Strategien, usw).

Jep. AFAIK gehts ja in solchen Projekten darum, für ein bestimmtes Realproblem eine Lösung zu erarbeiten, dh. die eigentliche Aufgabenstellung liegt ein paar Layer höher.

Sehr schön erstmal, daß Du Dich nicht (wie leider viele andere) von vornherein auf bestimmte Produkte festlegst, sondern erstmal analysierst, was überhaupt in dem Falle geeignet ist. Ob die Zeiten realistisch sind, kann man natürlich ohne Kenntnis der Infrastruktur nicht beurteilen.

Technisch scheinst Du's ja alles verstanden zu haben. Aber darum gehts sicherlich in dem Projektantrag nicht, sondern stattdessen die kaufmännische Sichtweise. Dazu sollte man erstmal darstellen, warum überhaupt umziehen, warum überhaupt eigene HW, usw. und dann die groben Schritte der Umsetzung. Am Ende interessiert's den Kunden auch nicht, wie genau Du die Daten rüberschaufelst oder was Du im DNS tust, sondern vorallem erstmal der betriebswirtschaftliche Nutzen, die Kosten, der benötigte Zeitraum und evtl. Probleme (zB. downtimes)

Ich hab ein klein wenig den Eindruck, daß Du grad ein den klassischen großen Hammer in der Hand hast und verzweifelt nach Nägeln zum Krummklopfen suchst ;-) Die erste Frage, die bei einem Projekt gestellt werden sollte: -> Was wollen wir eigentlich erreichen, und wozu das Ganze ? Der geschäftliche Nutzen muß zunächst klar werden, dann untersucht man die verschiedenen Möglichkeiten und wählt die geeignetste aus. Ich würde da, zumindest in der Analyse auch den Scope etwas erweitern und dabei betrachten, welche Informationen (und wie) überhaupt ausgetauscht werden (sollen).

Warum nicht einfach mal mit der Suchmaschine Deiner Wahl ein fertiges Filter-Tool suchen und als Milter im MTA oder via Procmail eindocken ? Sowas geb ich unseren Admins mal als Zwischendurch-Tasks während der Kaffe kocht. Ein eigenständiges Projekt rechtfertigt das jedenfalls nicht - da ist schon der ganze Papierkrams viel aufwändiger als die eigentliche Arbeit.

Wozu ? Wo ist der betriebswirtschaftliche Nutzen ? Wie oben: wozu genau ? Ich gehe mal davon aus, daß Du den neuen Fileserver auch unter Windows betreiben willst. Das hat ja ohnehin schon eine sehr dürftige IO-Performance - das dann noch virtualisiert wird spaßig. Wie genau sind die Standorte angebunden ? Kommen die bereits ins interne Netz rein ? (snip) Ohjeh. Da sollte man wohl erstmal eine eingehende Reorganisation des Daten-Managements vornehmen, bevor man an irgendwelchen Servern rumschraubt. Streiche besser "Soll-Konzept", denn Du beschreibst hier schließlich nur die Zielstellung. Ein Konzept sähe ganz anders aus, aber das soll ja wohl auch erst innerhalb des Projektes erarbeitet werden. Zusammengefaßt sieht die eigentlich Aufgabenstellung doch eher danach aus, daß ein verteilter Filestore benötigt wird. Da würde ich doch erstmal untersuchen, welche Optionen es dafür gibt (vorallem auch mal auf diverse Appliances oder nach echten Server-Betriebssystemen umschauen), anstatt die Produktentscheidung schon von vornherein vorweg zu nehmen.

Wenn Du einen Printserver möchtest, warum legst Du Dich dann von vorn herein auf ein bestimmtes (noch nichtmal sonderlich gut geeignetes) Produkt fest ?

Warum denn unbedingt zertifiziert ?

Du brauchst wahrscheinlich für jeden Kanal einen Tuner. Am einfachsten wäre es vermutlich, ein Bündel alte Linux-basierte Reciever mit ethernet-Port aufstellen und ggf. die Firmware etwas anpassen.

Was genau nutzt das, wenn am Ende dann die History (der Mainline) dennoch mit solchen inkonsitenten/kaputten Versionsständen vermüllt ist ? Bei temporären Branches kann man das gerne machen, wenn man hinterher ohnehin alles nochmal mittels interaktivem rebase wieder aufräumt, aber permantentere branches (mainline, maintenance branches, etc) sollten stets nur in sich konsistente commits enthalten.

Wozu genau braucht man einen fingerprint-reader ? Damit Leute, die IT-Sicherheit nur aus schlechten Hollywood-Streifen kennen, besser schlafen können ?

Wozu neu entwickeln, wenn GOSa das schon kann ?