Ich verstehe nicht, warum sich viele Projekte so zersplittern müssen. Die Folge ist für den Endanwender, dass er zig Libs und deren Abhängigkeiten installieren muss. Bei oft verwendeten Bibliotheken wie gtk sind shared libraries sehr sinnvoll, wenn jedoch jede Softare ihre eigenen libs mitbringt die auch nur von dieser Software verwendet werden verstehe ich den Sinn nicht. Der Overhead bei den ganzen geladenen libs dürfte nicht unerheblich sein.
Auch das selbst kompilieren macht dann keinen Spaß mehr. Wenn es wenigstens so wäre, dass man je nach Gusto diverse Module weglassen könnte (z. B. mit "./configure --without-foobar"), aber selbst das geht nur in sehr wenigen Fällen. Z. B. fände ich einen einfachen schlanken Fileserver der SMB spricht und nichts mit Domänencontroller, ACLs, AD oder sonstigem Zeug zu tun hat sehr interessant, es würde für viele Zwecke reichen. Jede Printserver-Firmware kriegt das heute hin.
Wo ist da der große Unterschied? Den Useflags nach zu urteilen ist es möglich, Samba ohne ACL- und AD-Funktionalität zu kompilieren. Das entspricht deinem Wunsch.
und genau so ist es - die Patches werden entsprechend der USE-Flags eingespielt und dann wird das ganze compiliert; und somit hat man den gewuenschten Support in seiner Software oder nicht.
> Ich verstehe nicht, warum sich viele Projekte so zersplittern müssen. Damit man irgendwann einmal spezialisierte Teilkomponenten durch andere ersetzen, bzw. sie in anderen Projekten verwenden kann?
> Die Folge ist für den Endanwender, dass er zig Libs und deren Abhängigkeiten installieren muss. Wenn die modulare Architektur trotzdem mit dem Projekt selbst mitgeliefert wird, muss man überhaupt nichts separat installieren.
> wenn jedoch jede Softare ihre eigenen libs mitbringt die auch nur von dieser Software verwendet werden verstehe ich den Sinn nicht Auch eine interne Lib braucht zu ihrer Verwendung eine API-Spezifikation, was zumindest nicht schlecht für die Qualität des gesamten Projektcodes ist. Zweitens ist es sicher nett, wenn selten gebrauchte Funktionalität in externe Libs ausgelagert ist und nur dann im Speicher liegt, wenn sie dynamisch dazugeladen wird. Auch für die Fehlerbehebung ist es nett, unter Umständen nicht den ganzen Service neustarten zu müssen.
Für den Benutzer zählt doch nicht, wie die Software intern aufgebaut ist, sondern nur wie sie sich installieren lässt. Wenn ich meine Software in 5 handlichere, besser wartbare Bibliotheken aufteile, kann ich doch trotzdem alles unter einer Installationsroutine zusammenfassen.
Der Benutzer profitiert aber evtl. durch schnellere Entwicklungszeiten und weniger Bugs.
wenn jedoch jede Softare ihre eigenen libs mitbringt die auch nur von dieser Software verwendet werden verstehe ich den Sinn nicht
In diesem Falle geht es aber um Biblotheken, die auch von anderen Programmen benutzbar sein sollen. So ist diese modulare Architektur die Grundlage für Projekte wie Openchange, die sich dadurch auf ihre projektspezifischen Aufgaben konzentrieren können und die Implementierung der Microsoft Low-Level Netzwerkkommunikation mit Samba teilen.
Der Overhead bei den ganzen geladenen libs dürfte nicht unerheblich sein.
Wo soll da ein Overhead entstehen? Wenn überhaupt ein Unterschied sein sollte, dann eher dass Overhead vermieden wird in dem die selbe Bibliothek für zwei Programme nur einmal geladen werden muss.
Wo soll da ein Overhead entstehen? Wenn überhaupt ein Unterschied sein sollte, dann eher dass Overhead vermieden wird in dem die selbe Bibliothek für zwei Programme nur einmal geladen werden muss.
Deswegen redete ich auch von einem einzelnen Programm. Ein einzelnes statisch gelinktes Programm verbraucht mit Sicherheit weniger Speicher und ist schneller als ein dynamisch gelinktes Programm plus shared lib, da hier der Umweg über den dynamischen Linker gemacht werden muss.
>Dieser Overhead ist auf heutigen Systemen nur noch sehr schwer überhaupt meßbar
Du schreibst mir aus der Seele!
Gibt aber bereits Stoppuhren mit einer Auflösung im Pikosekundenbereich. Wenn du also mal in der Shell ein ls eingibst, gleichzeititg den Knopf an der Uhr drückst und wenn ls fertig ist nochmal, haste die genaue Zeit.
samba ist bei uns im büro einfach zu langsam, hat man ein windows share offen und kompiert dateien gehen locker 50mb/s (im gbit lan). Das ist wohl platten limitiert dann. Samba schaft das nicht, da gehen meistens so um die 10mb/s. Rechner ist definitiv mit gigabit ethernet angebunden, und die platten koennen es auch kaum sein, der linux pc hat die schnellsten platten von allen. Getestet auch im (software) raid-0, hilft nicht. Installiert man einen Apache auf der Linux Kiste und packt da ne riesige datei drauf kann man die dann endlich auch mit ~50mb/s (und mehr) ziehen. Liegt also wohl definitiv an samba.
"Liegt also wohl definitiv an samba." Schlage nicht in den Spiegel der Dir Deinen Admin zeigt :-)
Samba kann/muß an das Netzwerk und die Clienten angepaßt werden, siehe dazu Google "Samba performance tuning", die Killer sind meines Wissens * oplocks,share modes, read/write raw, socket options * follow wide links * hidden files o.ä. Ist der Samba Zugriff auf dem Fileserver selber auch so langsam?
bei dem angesprochenen Samba4-Migrationsplan handelt es sich um ein Projekt, das die Fertigen AD-Domain-Controller Features von Samba 4 mit den berwährten SMB-File-und-Drucker-Server Features von Samba 3 verbinden will. In dem Szenario laufen beide Dämonen (Samba3 und Samba4, wobei der Samba4 Dämon der Haupt-Prozess ist) und teilen sich die Kompetenzen (Lauschen auf Netzwerk-Ports, Namend Pipes/RPC Dienste).
Details können unter http://wiki.samba.org/index.php/Franky verfolgt werden. Nachdem der kombinierte Samba3/4-Build nun fast vollständig ist, sind offene Todos vor allem der Trusted-Domain Support via Samba3-Winbind und NetBIOS-Browsing Support in Samba4.
Ich verstehe nicht, warum sich viele Projekte so zersplittern müssen. Die Folge ist für den Endanwender, dass er zig Libs und deren Abhängigkeiten installieren muss. Bei oft verwendeten Bibliotheken wie gtk sind shared libraries sehr sinnvoll, wenn jedoch jede Softare ihre eigenen libs mitbringt die auch nur von dieser Software verwendet werden verstehe ich den Sinn nicht. Der Overhead bei den ganzen geladenen libs dürfte nicht unerheblich sein.
Auch das selbst kompilieren macht dann keinen Spaß mehr. Wenn es wenigstens so wäre, dass man je nach Gusto diverse Module weglassen könnte (z. B. mit "./configure --without-foobar"), aber selbst das geht nur in sehr wenigen Fällen. Z. B. fände ich einen einfachen schlanken Fileserver der SMB spricht und nichts mit Domänencontroller, ACLs, AD oder sonstigem Zeug zu tun hat sehr interessant, es würde für viele Zwecke reichen. Jede Printserver-Firmware kriegt das heute hin.
Calculating dependencies... done!
[ebuild R ] net-fs/samba-3.0.28a-r1 USE="acl cups ipv6 pam python readline -ads -async -automount -caps -doc -examples -fam -ldap -quotas (-selinux) -swat -syslog -winbind" LINGUAS="-ja -pl" 0 kB
Siehst du da durch oder magst es gern erklaert bekommen?
wird das ganze compiliert; und somit hat man den gewuenschten Support in seiner Software
oder nicht.
Damit man irgendwann einmal spezialisierte Teilkomponenten durch andere ersetzen, bzw. sie in anderen Projekten verwenden kann?
> Die Folge ist für den Endanwender, dass er zig Libs und deren Abhängigkeiten installieren muss.
Wenn die modulare Architektur trotzdem mit dem Projekt selbst mitgeliefert wird, muss man überhaupt nichts separat installieren.
> wenn jedoch jede Softare ihre eigenen libs mitbringt die auch nur von dieser Software verwendet werden verstehe ich den Sinn nicht
Auch eine interne Lib braucht zu ihrer Verwendung eine API-Spezifikation, was zumindest nicht schlecht für die Qualität des gesamten Projektcodes ist. Zweitens ist es sicher nett, wenn selten gebrauchte Funktionalität in externe Libs ausgelagert ist und nur dann im Speicher liegt, wenn sie dynamisch dazugeladen wird. Auch für die Fehlerbehebung ist es nett, unter Umständen nicht den ganzen Service neustarten zu müssen.
lg
Erik
Der Benutzer profitiert aber evtl. durch schnellere Entwicklungszeiten und weniger Bugs.
In diesem Falle geht es aber um Biblotheken, die auch von anderen Programmen benutzbar sein sollen. So ist diese modulare Architektur die Grundlage für Projekte wie Openchange, die sich dadurch auf ihre projektspezifischen Aufgaben konzentrieren können und die Implementierung der Microsoft Low-Level Netzwerkkommunikation mit Samba teilen.
Der Overhead bei den ganzen geladenen libs dürfte nicht unerheblich sein.
Wo soll da ein Overhead entstehen? Wenn überhaupt ein Unterschied sein sollte, dann eher dass Overhead vermieden wird in dem die selbe Bibliothek für zwei Programme nur einmal geladen werden muss.
Deswegen redete ich auch von einem einzelnen Programm. Ein einzelnes statisch gelinktes Programm verbraucht mit Sicherheit weniger Speicher und ist schneller als ein dynamisch gelinktes Programm plus shared lib, da hier der Umweg über den dynamischen Linker gemacht werden muss.
(Ich warte jetzt nur noch, daß jemand den alten 386er mit 4MB RAM als Benchmark rauszieht
)
Du schreibst mir aus der Seele!
Gibt aber bereits Stoppuhren mit einer Auflösung im Pikosekundenbereich. Wenn du also mal in der Shell ein ls eingibst, gleichzeititg den Knopf an der Uhr drückst und wenn ls fertig ist nochmal, haste die genaue Zeit.
Sollte es nicht GNU General Public License v3 (GNU GPLv3) heißen?
Gruss,
demon
Schlage nicht in den Spiegel der Dir Deinen Admin zeigt :-)
Samba kann/muß an das Netzwerk und die Clienten angepaßt werden, siehe dazu Google "Samba performance tuning", die Killer sind
meines Wissens
* oplocks,share modes, read/write raw, socket options
* follow wide links
* hidden files o.ä.
Ist der Samba Zugriff auf dem Fileserver selber auch so langsam?
Volker
bei dem angesprochenen Samba4-Migrationsplan handelt es sich um
ein Projekt, das die Fertigen AD-Domain-Controller Features von
Samba 4 mit den berwährten SMB-File-und-Drucker-Server Features
von Samba 3 verbinden will. In dem Szenario laufen beide Dämonen
(Samba3 und Samba4, wobei der Samba4 Dämon der Haupt-Prozess ist)
und teilen sich die Kompetenzen (Lauschen auf Netzwerk-Ports,
Namend Pipes/RPC Dienste).
Details können unter http://wiki.samba.org/index.php/Franky
verfolgt werden. Nachdem der kombinierte Samba3/4-Build nun fast
vollständig ist, sind offene Todos vor allem der Trusted-Domain
Support via Samba3-Winbind und NetBIOS-Browsing Support in Samba4.
Gruß - Michael