Hallo!

Ich höre mir grad diesen Podcast von ChaosRadio Express an:


dort spricht der Samba-Entwickler Volker Lendecke über das Server Message Block (SMB) von IBM / Microsoft sowie über Samba, der SMB-"Kopie" besser Nachbau.

Da die EU eine Spezifikation von SMB haben möchte, versucht Microsoft dies zwar ist aber laut Herr Lendecke nicht dazu in der Lage, weil Microsoft noch Steinzeitcode mitschleppt. Das bedeutet: Selbst ein DOS-Rechner ist noch in der Lage mit einem Windows 2003 Server zu kommunizieren.
Und aufräumen trauen sie sich nicht (Microsoft), weil sie nicht wissen, wen sie dann ausschließen würden.


Der Podcast ist interessant!

Mal abgesehen davon, dass das Interview durchaus interessant ist -- nur mal der Form halber: das Interview ist veröffentlicht am 06.05.2006.

Inzwischen haben wir das Jahr 2010, und inzwischen ist Microsoft von der EU gezwungen worden, die SMB-API bzw. das SMB-Protokoll wenigstens gegen Geld Dritten und anderen Firmen zur Einsicht bzw. offiziell zur Verfügung zu stellen.

Microsoft verlangt dafür eine fünfstellige Lizenzgebühr. Diese Gebühr ist von einer deutschen Softwarefirma, die sehr in das Samba-Projekt eingebunden ist und ihre Geschäfte auf Samba aufbaut, kurz nach dem EU-Urteil an Microsoft gezahlt worden, und diese Firma, die seit Jahren eng und federführend am Samba-Projekt mitarbeitet, hat diese Original-Microsoft-Dokumente dann ausgewählten Samba-Entwicklern bzw. dem Samba-Projekt zur Verfügung gestellt. Seitdem wird das bisherige Samba, das man bisher immer nur per Analyse von Ergebnisprotokollen hat bauen können, teilweise auf diesen Original-Dokumenten von Microsoft weiterentwickelt. Seitdem steht Microsoft auch sonst mit Rat und Tat dem Samba-Team zur Verfügung. Seitdem tritt Microsoft auch desöfteren mit eigenen Entwicklern und Rednern auf Samba-Conventions und Samba-Vorträgen auf bzw. sponsort diese Veranstaltungen sogar.

Seit diesem EU-Urteil ist also viel Positives passiert. Und diese ganzen neuen Entwicklungen fließen sowohl in die aktuelle Samba 3.5-Serie als auch in die zukünftige Samba 4-Serie mit ein (Samba 3.5 ist ein stabiler Backport von Samba 4). Zur Info: Apples Samba gibt derzeit eine Versionsnummer von 3.0.28a-apple aus. Den Rest kann man sich dazudenken.

Ja ja.

Aber er sagt ja, daß SMB intern totales Gefrickel ist und Microsoft selbst nicht weiß, was da eigentlich passiert.

Und Samba ist ja im weitesten Sinne ein re-engeneering, ein Nachbau sozusagen.

Das Problem ist das SMB als solches Zur Offenlegung, zur Dokumentation der Schnittstellen:
Das ist ja soviel historischer Ballast drin, das es schwierig wird, dies zu dokumentieren um es anderen zu Verfügung zu stellen.
Microsoft ist ja bemüht, Kompatibilität bis in die Steinzeit zu "garantieren".

Also wenn MS intern etwas ändern würde, zu welchen anderen Produkten wären sie noch kompatibel?

Das heißt das Microsoft eines Tages auf die Nase fallen wird. Sie müssen also irgendwann mal einen Neuanfang machen, so nach dem Motto: "Wir fangen jetzt noch mal von vorne an."


Das da wäre?

Nur mal am Rande: AFP kann man wohl auch nur als Gefrickel bezeichnen. Die Programmierer von netatalk können da ein Lied von singen. IMHO ist das bei allen richtig alten Protokollen, bei denen man auf Abwärtskompatibilität setzt der Fall: Es werden einfach Code-Monster, die keiner mehr wirklich durchschauen kann...

Mag sein, dass es bei SMB noch etwas drastischer ist als bei manch anderem Projekt, aber an dieser Stelle Microsoft herauszupicken und an den Pranger zu stellen ist nicht wirklich fair.

Abwärtskompatibilität über viele Versionen und sauberes Design in Code und Dokumentation sind nur ganz schwer unter einen Hut zu bringen...


Und jetzt steinigt mich...

Ich glaube, das weißt Du schon längst. Wir sprachen schon mehrmals drüber. Du selber beklagst Dich hier doch andauernd über Probleme mit SMB von Deinem Mac im Zusammenhang mit Windows-PCs...
Über Deine Nachfrage bin ich deshalb etwas verwundert.

Zitat von hier:

und

Samba Adopts GPLv3 for Future Releases

[url]To be clear, all versions of Samba numbered 3.2 and later will be under the GPLv3, all versions of Samba numbered 3.0.x and before remain under the GPLv2.[/url]

Samba ist derzeit offiziell bei Version 3.5.4. Apples verwendetes Samba ist bei Version 3.0.28a. Apple patcht sich einen Wolf, um das alles nachzuholen, was zwischen 3.0.26 und der Upstream-Version des Samba-Projektes passiert ist. Anstatt einmal über seinen Schatten zu springen, die GPL3 mit ihren klaren Einschränkungen bzgl. Ansprüchen auf Patente zu akzeptieren und dann eben die neuesten Samba-Versionen einzusetzen, die das Samba-Projekt eben bietet. Stattdessen gibt's bei Apple eine veraltete Samba-Version, die mit neueren Windows-Versionen nicht oder nur schlecht zusammenarbeitet, und Apple muss hier die ganze Zeit nachpatchen. Wie lange wollen sie das machen? Es klappt doch jetzt schon nicht hinten und vorne, von MacOSX-Update zu MacOSX-Update ist in den Release-Notes von Apple zu lesen: "Proleme mit Samba hier, Probleme mit Samba da"...
Andere Linux-Distributionen, die keine Probleme mit der GPL3 haben, die setzen einfach die neueste Samba-Version ein, wo dann jeweils auch die neuesten Entwicklungen aus der Zusammenarbeit mit Microsoft eingeflossen sind, und gut ist.
Apple muss das alles von Hand nachregeln. Und kriegt's anscheinend nicht auf die Reihe. Was absolut verständlich ist bei der Masse, die sich da zuweilen in der Zwischenzeit seit Samba 3.0.x geändert hat bzw. Einzug in Samba 3.5 erhalten hat. Samba geht mit großen Schritten in Richtung 4er-Version. Und Apple bleibt an seinem Samba 3.0 kleben und versucht das mit dem aktuellen Stand auf Augenhöhe zu halten. Weil man wohl Schwierigkeiten mit der Akzeptanz der GPL3 hat, die Apple offenbar davon abhält, gleich eine aktuelle 3.5er-Version einzusetzen.

dieser ganze "mein mac soll mal mit dem xp rechner meines nachbarn daten tauschen" scheiss (ich nenne es bewusst so) ist eine elende frickelei.

freigaben hier, rechnernamen da, ne domaine hier noch, da eine arbeitsgruppe, dann nur tausch in die eine richtung möglich, der eine rechner sieht den anderen nicht ... herrjeh! sowas klappt bei mir NIEMALS einfach so durch verbinden zweier rechner miteinander. am ende wirds immer ein usb stick

warum geht das nicht so: 2 rechner verbinden beide sehen sich im finder/dateibrowser tausch von daten in beide richtungen möglich (ok, freigaben/sperren von einzelnen dateien/ordner sollten, einfach!!, möglich sein)

(ja, ich bin absoluter laie. aber aufregen darf ich mich trotzdem, ja?)

sierkb: Danke! Ich ärgere mich seit Jahren über die veralteten Samba Versionen von Apple, ohne mich jemals ernsthaft gefragt zu haben, wieso das so ist. Deine Erklärung bringt zwar keine Linderung, aber Licht ins Dunkel!

Ich muss dazu einschränkend sagen: definitiv wissen tue ich es nicht, ob die GPL3 wirklich der tatsächliche Grund dafür ist für diese Situation. Aber die Dinge sind schon irgendwie augenfällig und dieser Zusammenhang drängt sich geradezu und förmlich auf, wenn man sich mal die Versionen gegenüberstellt und die damit korrelierenden Zeitpunkte, bis wann noch die lockerere GPL2 gilt und ab wann die verschärfte und strengere GPL3 gilt...

Also eigentlich finde ich das Sharing ganz stabil. Was mich nur wundert ist, wie ich bereits hier schon unzählige Male beschrieben habe, daß abgeschaltete Windows PCs noch sehr lange in der Seitenleiste des Finders kleben bleiben und wenn mehrere PCs an waren (!!!) das diese immer noch anklickbar sind, obwohl diese ausgeschaltet sind.

Aber wie du schon sagtest, sierkb, liegt das wohl an der veralteten SMB-Version die Apple nutzt.



Beim Mac dauert das eine weile bis der einen Windows PC erkennt.
Ich habe mal vom Apple Support gehört: "Haben Sie die Aktivierungsreihenfolge beachtet?" Das heißt doch, erst muß der Windows PC eingeschaltet sein bevor der Mac ihn sehen kann, oder?

Jedenfalls Sharing zwischen zwei Macs mit SMB geht problemlos, dank Zero Conf. Warum das mit Windows nicht möglich ist, liegt wohl an SMB und auch am OS selbst, wie es intern Daten verarbeitet. Denn wenn der Finder zu träge ist (das Programm an sich) oder es wird zu spät vom System benachrichtigt, kann SMB / Windows ja nix dafür.

Aber ich habe mal gehört, daß Apple und Microsoft unsinnigerweise sich selbst die Schuld in die Schuhe schieben, wenn etwas nicht klappt.

Jungs -- hört auf damit! Wenn dann habt ihr beide wohl Schuld, aber das sollte nicht das Thema sein, denn davon hat der Kunde ja nichts. Und jetzt tut nicht so, als ginge das nicht! Reißt euch gefälligst zusammen und arbeitet miteinander. Ihr müßt euch ja nicht küssen oder heiraten aber ein derartiges Verhalten ist kontraproduktiv.

Oder: Bill Gates und Steve Jobs plaudern auf freundschaftlicher Ebene miteinander.



mein Cousin meinte mal, es wäre nicht Apples Markt. hallo?! Natürlich! Ein Programm das die größtmögliche Kompatibilität hat - also mit vielen Systemen sprechen zu können - wird von Kunden geschätzt und auch weiterempfohlen.

Und ein Apple Mitarbeiter sagte mir mal, ob Apple dadurch nicht die eigene Position aufgibt. Da sagte ich nein, das müssen sie nicht. Sie programmieren das dann halt so, wie es von den Spezifikationen vorgesehen ist und wenn's dann nicht klappt, dann muß der andere ran (meinetwegen MS oder der Kunde).

Apple muß ja auch gar nicht alle SMB-Versionen unterstützen, bis XP reicht ja, als Beispiel. Oder ihr OS so umstellen, daß die Kommunikation mit Windows 3.11 möglich ist. Das verlangt keiner, nicht einmal ich.
Aber man sollte mit der Entwicklung schon mitgehen, da viele Leute - ich eingeschlossen - nun mal auf die SMB-Implementation angewiesen bin.

Ich mein, Sharing mit Windows geht ja, es funktioniert. Aber es könnte mit Sicherheit noch besser werden.

(Bei mir gibt es keinen Fehler bei SMB etc.)

MfG

PS: Apple ist in einigen Sachen manchmal ganz schön arrogant. Vielleicht sollten wir Apple vom hohen Roß herunterholen?

Grad' auf Apple discussions gefunden: .

Passt zu meiner bisherigen Aussage.

Interessant!

Und hier, wie nett!



http://support.apple.com/kb/TS3235

Echt? Hast du dazu mehr Informatioen? *unbedingt haben will*


Nö nö, es ging ja hier nur um SMB.

netatalk-admins@lists.sourceforge.net
http://sourceforge.net/projects/netatalk/

Schmarrn. Und ich bin Netatalk-Entwickler.

dom_beta holt gerade irgendwie seinen IT-Grundkurs nach. Letzte Woche hatte er auch schon so einen Link zu einer uralten Seite auf der auch Dinge standen, die mir mindestens schon genau so lang klar sind, wie sie da stehen.

franklahm: Schafft man es also zwischenzeitlich nicht mehr über AFP den kompletten Mac zum Absturz zu bringen? Vor drei Jahren hab ich das noch mit einem selbst kompilierten AFP geschafft, indem ich mit dem Mac nur darauf zugegriffen habe. Wie ist eigentlich die offizielle Dokumentation (von Apple) zu AFP? Gibt es da vernünftige Dokumente?

Praktisch alle NAS Hersteller nutzen Netatalk für den AFP Support. Dazu viele Firmen von klein bis groß. Die mir namentlich bekannte größte Installation steht bei Warner Brothers mit 50 Netatalk Servern und 500 TB Storage. Ich geh mal davon aus, das bei denen allen die Macs nicht dauernd komplett abstürzen beim Zugriff.Ja.

franklahm: Das wollte ich damit auch nicht sagen (das netatalk den Mac zum Absturz bringt). Ich selbst nutze Netatalk und bin den Entwicklern (auch Dir) sehr dankbar für die viele Arbeit!

Ich hatte nur immer (auch aus der Mailingliste) den Eindruck, dass sich Apple ähnlich blöd anstellt die Spezifikationen rauszugeben wie Microsoft (Danke für deine Links, war mir neu...).

Bei einer OS Umstellung (ich glaube 10.5 oder 10.4) hatte ich massive Probleme mit Rechnen auf der Linuxmaschine, und habe deshalb auf einer Testmaschine Netatalk selbst gebaut. Dabei ist es mir reproduzierbar gelungen, den Mac zum einfrieren zu bekommen. Es kann doch wohl bei einem anständigen Implementierung nicht sein, dass man sich auf einen funktionierenden Server verlässt... Wie gesagt: keine Kritik an Netatalk auf dem Server hatte ich meine Finger mit drin.

O.k. nachdem ich meinen Text eben noch mal gelesen habe: Das Protokoll mag ja in Ordnung sein, aber an der Implementierung von Apple hab ich manchmal so meine Zweifel...

Netatalk? Was machen die denn?

Na ja, es gibt ja Samba 4 das ja ganz schlank ist und keinen Ballast enthält.

Jetzt fände ich es richtig, wenn Apple und Microsoft diesen Weg ebenfalls gehen und ihre Protokolle komplett neu entwickeln.

Apple hat ja den Vorteil, daß sie die alten Protokolle, wie PowerPC mit Rosetta, als Unter-Schicht, mitnehmen können bzw. könnten.

Also diesen Weg würde ich gehen. Wer weiß, mit 10.7 ist ja vielleicht schon so.

Nein. -- Ich habe SMB exemplarisch als Beispiel genommen, weil eben Tim Pritlove im Gespräch mit Teut Waldemann erzählte, daß er das Gefühl hat, daß die Computer immer langsamer werden und daß einfach die Snappiness fehlt.

Das liegt daran, daß wie GeWoldi es schon sagte, Codemonster werden und viele Sachen einfach so zusammengeschustert werden - mehr oder weniger - ohne Sinn und Verstand.

Aber diesen Eindruck von Überladen und Langsam habe ich schon seit längerem; das fällt einem besonders dann auf, wenn man etwas anspruchsvoller ist und sich wundert warum Grafikeffekte auf neuerer Hardware langsamer sind als auf 3 Jahre älterer Hardware.


PS: Ich weiß wie alt der Podcast ist, ich kann lesen, es ist aber auch ein guter Podcast.

weiß jemand ob Apple eine neuere SMB-Version in 10.6.5 einbauen wird?

Ich glaube, eine neuere SMB-Version bekommen wir erst wieder mit den SL-Nachfolger...

na super....

oh toll, Probleme mit AFP und SMB mit Mac OS X:



http://www.macuser.de/forum/f138/gibt-funktionierende-netzwerkdateisysteme-539033/


da muß Apple dringend was tun.

ich glaube daran liegt es nicht, sondern eher da dran:


Samba mit experimentellem SMB2-Protokoll - Golem.de
http://www.golem.de/1003/73529.html



die Nachricht ist vom 02.03.2010 !


Wenn 3.5 stabil läuft mit der SMB-2.0-Untersützung, dann wird Apple diese wohl auch einsetzen.

Wenn Du so willst, dürftest Du Samba nie einsetzen. Das ganze Ding ist von der ersten Stunde an experimentell. Von der ersten Stunde an ist es ein Raten und Reverse-Engineering von Microsofts SMB-Implementierung und ein Tappen im Dunkeln gewesen. Erst seit ein paar Jahren, seit dem sich Microsoft per Gerichtsbeschluss da öffnen MUSSTE, seitdem hat man mehr Gewissheit und stabile Grundlagen.

So dermaßen gut gelungen, dass man immer wieder erstaunt war über die Jahre, WIE gut man da eigentlich gearbeitet hatte und teilwweise Microsofts eigene Implementierung teilweise performancemäßig sogar noch übertraf/übertrifft. Und seit die in das Projekt sehr involvierte Firma Sernet da seit dem europäischen Gerichtsurteil offizielle Microsoft-Spezifikationen dazu gekauft und dem Projekt zur Verfügung gestellt hat und Microsoft seitdem auch dem Samba-Projekt wieder aktiv mit Rat und Tat und Entwicklern zur Seite steht, ist man da auf einem sehr guten Weg und teilweise echt erstaunt, WIE gut man da in der Vergangenheit und bisher gearbeitet hatte und hat.

Mittlerweile halt eben auch mit Hilfe von Microsoft selber bzw. basierend auf Original Microsoft-Spezifikationen und Dokumenten.

Das ganze dürfte also schon ziemlich stabil sein, auch wenn's offiziell und vielleicht erstmal über Jahre als experimentell gekennzeichnet ist und sich dementsprechend auch in einer ungraden Versionsnummer niederschlägt (im Open-Source-bereich ja gang und gäbe, dass man da sehr konservativ und zurückhaltend ist und lieber etwas als experimentell oder noch nicht stabil kennzeichnet, auch wenn's schon seit Jahren stabil und zuverlässig im Produktiveinsatz ist).

Das glaubst Du doch wohl selber nicht. Samba 3.5 wird schon auf anderen Unices und Linux-Versionen im Produktiv-Einsatz verwendet. Und zwar mehrheitlich sicher mehr und öfters als Apple das mit seinen Macs tut. ich glaube viel eher dran, dass der wahre Grund da wirklich die GPL2 und die GPL3 ist, womit Apple da ein Problem hat, weil alle nachfolgenden Versionen von Samba nach 3.0.x unter der GPL3 stehen und nicht mehr unter der GPL2. Und damit hat Apple seo seine lieben Akzeptanz-Probleme. Und setzt dann lieber auf einer Version auf, die noch unter GPL2 steht und versucht dann alles das, was später in den neueren Versionen an Verbesserungen vorhanden ist, mühsam und per Hand in diese früher Version backzuporten, was Apple aber anscheinend nicht so gelingen will bzw. sie da der Upstream-Entwicklung nicht richtig hinterherkommen. Schau Dir nur mal auf opensource.apple.com das diesbzgl. Patch-Verzeichnis von Apple bei deren Samba an. Das ist ja fast länger und größer als deren komplette Samba-Implementierung.

Und: Du siehst an den jüngsten Entscheidungen Apples bzgl. Java, dass sie mit bestimmten Entwicklungen nicht hinterherkommen und immer irgendwie zurückhinken, wenn sie so abgekoppelt sind von der Upstream-Entwicklung und versuchen alles selber hinzubekommen. Das artet dann eben in Gefrickel und teilweise nicht mehr tolerablem Zeitverzug aus, und deshalb haben sie das Ganze jetzt (höchst sinnvollerweise!) auch an Oracle bzw. die OpenJDK-Community zurückgegeben bzw. legen's in deren Hände (was man schon längts hätte tun sollen), damit Java unter MacOSX eine stabile und gut Zukunft haben kann.

dom_beta:

Übrigens: wenn man mal unter MacOSX noch weitere GNU Software so durchgeht, die unter der GPL steht, so fällt auf, dass es noch mehr Software zu geben scheint, bei der Apple nicht mitziehen will, was den Sprung von GPL2 auf GPL3 angeht: auch die unter MacOSX eingesetzte Standard-Shell, die GNU Bash, ist bei MacOSX 10.6 derzeit immer noch die Version 3.2.x und nicht die seit Februar 2009 existierende Bash in der Version 4, derzeit aktuell inder Version 4.1:

bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.

Auch hier fällt wieder auf: Version 3.2.48 war die letzte Version der Bash, die unter der GPL 2 erschien. Ab dann kam Bash 4.0, und seitdem steht die Bash unter der GPL 3. Was Unternehmen wie Apple und Microsoft weniger gefällt, weil die GPL in der Version 3 explizite Patent-Ausschlusklauseln hat. Als direkte Lehre aus dem Novell-Microsoft-Deal zum Schutz vor Software-Patentklagen und auf diese Weise von Unternehmen wie Microsoft über den Tisch gezogen und ggf. verklagt zu werden. Solche Klauseln schmecken weder Microsoft noch Apple.
Und deshalb bleibt Apple dann lieber bei der Version, die zuletzt unter der GPL 2 stand, auch wenn sich das rad der Entwicklung dieser Software schon längst weiterdreht, nur halt unter einer für sie (ganz bewusst!) stärker einengenden Lizenz. Weil sowohl. Microsoft wie auch Apple in dieser Hinsicht lieber nehmen anstatt zurückzugeben und lieber eigene Erweiterungen einbauen wollen bzw. sich diese Türe offenhalten wollen als diese Erweiterungen ggf. auch mal transparent wieder an die Software-Gemeinschaft zurückzugeben. Deshalb mögen sowohl Microsoft wie auch Apple die BSD-Lizenz oder BSD-like-Lizenzen so gerne: weil man da nehmen kann wie es einem beliebt und machen kann, was man damit will (offen lassen, closed-source draus machen, mit eigener patentgeschützter Technik erweitern etc. pp.), ohne jemanden zu fragen und ohne irgendjemandem Rechenschaft ablegen zu müssen.

Daher dann lieber was Veraltetes einsetzn, nur weil die Lizenz-Situation da noch günstiger für Apple steht als etwas Aktuelles, wo die Lizenzsituation für sie inzwischen ungünstiger steht. Bedanken darf sich Apple bzgl. der Notwendigkeit der GPL 3 übrigens bei Microsoft. Hätten die das damals nicht so schamlos ausgenutzt bzw. so schamlos versucht, an Geist und Sinn der GPL2 vorbei ihre Patentdeals und substanzlosen Klagedrohungen verschiedenen Unternehmen gegenüber durchzuziehen, hätte es die GPL 3 nie gegeben. Die wurde erst notwendig und aus der Taufe gehoben, als man mitbekam, wie schlitzohrig Microsoft da vorgegangen ist, um die GPL2 hintenherum auszuhebeln und zu schwächen und an ihr vorbei substanzlose Patentforderungen zu erheben bzw. Unternehmen wie auch Anwender damit zu erpressen oder unter Druck zu setzen, mit ihnen einen Patentdeal (im Sinne eines Nicht-Angriffspakts) einzugehen.
Und Apple denkt und handelt da prinzipiell sicher nicht sehr viel anders als Microsoft, was die GPL2 und die GPL3 und die Softwarepatent-Situation angeht.

Wenn man also schon GPL-Software einsetzen muss, weil unvermeidbar und kein adäquater Ersatz im BSD-Lager bzw. unter einer BSD-Lizenz erhältlich ist, dann lieber welche, die unter GPL2 steht als eine, die unter der GPL3 steht und die damit noch viel klarer und deutlicher definiert, was man mit der Software machen darf und was nicht.

Ich nehme mal an, dass auch genau das einer der Gründe ist, warum sich Apple auch so beim LLVM-/Clang-Compiler-Framwork angagiert und das bevorzugt einsetzt. Weil LLVM unter einer BSD-Lizenz steht, GCC aber unter der GPL bzw. LGPL. Auch da wäre nun mal näher zu prüfen, ob der aktuelle GCC mittlerweile nicht ebenso unter der GPL 3 steht, und ob nicht auch da Apple bisher noch auf genau jene letzte GCC-Version setzt, die noch unter der GPL 2 und LGPL 2 steht:

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Aktuelles stabiles Release von GCC ist derzeit GCC 4.4.5 und

Und siehe da: und zeigen auch hier wieder: Release 4.2.x war die letzte Release-Linie von GCC, die noch unter GPL2 bzw. LGPL2 stand, und seit der Release-Linie 4.3 finden sich nicht nur GPL2/LGPL2 im Source-tree von GCC, sondern auch die ungeliebte GPL3 und LGPL3. Und deshalb bleibt Apple davor dann stehen bzw. sucht dann lieber nach Alternativen unter BSD-Lizenz (namentlich LLVM). Obwohl Apple jahrelang zu GCC beigetragen hat, um ihn (nicht uneigennützig) Objective-C fähig zu machen bzw. dort sogar ein eigenes Unter-Repository unterhält.

Siehe dazu auch:
GNU.org: Why Upgrade to GPLv3

Ich glaube, das ist alles mehr als ein Zufall, und dahinter steckt bei Apple Methode. Eigentlich könnte man diesbzgl. mal den kompletten Darwin-Unterbau von MacOSX abklopfen, an welchen Stellen Apple da noch so verfährt bzw. aufgrund des Wechsels der betreffenden GNU Software von der GPL2 zur GPL3 nur um der Lizenz willen wie ein störrischer Esel stehenbleibt und diesbzgl. lieber veraltete Softare einsetzt (und die notfalls versucht an allen Ecken und Kanten fitzuspritzen und es am Ende doch nicht hinbekommt, mit der aktuellen Entwicklung Schritt zu halten) anstatt schlicht und einfach die neuere Upstream-Version zu verwenden, bei welcher das gesamte restliche Unix- und Linux-Universum weniger Probleme hat diese einzusetzen.

Ein "reverse engineering" ist das nicht! Das tun die Leute eben nicht.

Ich weiß nicht ob du den verlinkten Artikel gelesen hast, da steht:


das heißt für mich übersetzt soviel wie:

Im Grunde wird SMB 2 aus Windows Vista und 7 schon unterstützt, allerdings gibt es hier und da noch Schwierigkeiten, deshalb wird die SMB 2 Unterstützung standardmäßig nicht sofort angeboten sondern muß explizit aktiviert werden.

Mit 3.5.x wird das wohl besser.

dom_beta:

Sondern die jahrelange Protokoll-Analyse und das Mithören und Mitschneiden des SMB-Netzwerkverkehrs während der Kommunikation und des Datentransfers mit Windows-Rechnern und dann das entsprechende zielgerichtete Programmieren auf genau diese Analysen hin ist stattdessen genau was?

Habe ich. Muss ich dem jetzt irgendeine besondere Bedeutung zumessen, was da bei Golem steht? Zumal: hast DU ihn denn selber mal genau gelesen und auch verstanden? Da ist in dem Zusammenhang nämlich auch vom Linux-Kernel die Rede, der da für gewisse Dinge grad' angepasst/optimiert wurde: "Zusätzlich wurde die Zeitstempelauflösung komplett an Windows angepasst und kann nun alle 100 Nanosekunden gesetzt werden. Dafür ist ein Kernel ab Version 2.6.22 und Glibc 2.6 oder höher Voraussetzung." Also eigentlich ist diese Golem-Meldung dann wohl eher eine Meldung, die den Linux-Kernel im Zusammenspiel mit Samba betrifft und weniger eine, die generell die aktuelle Samba-Entwicklung (und damit evtl. Samba und MacOSX) betrifft.

Und Frage: Seit wann ist SMB 2 seitens Microsoft im Einsatz?
Wer mischt da derzeit mit und hilft mit, die aktuelle Samba-Linie möglichst gut an die aktuelle Windows-Welt anzupassen bzw. miteinander zu harmonisieren? Das ist nicht zuletzt auch Microsoft selber, die da mithelfen? Und auch IBM und andere Firmen.

Abgesehen davon: auch wenn's offiziell noch als experimentell gekennzeichnet ist, heißt das noch lange nicht, dass es nicht evtl. schon längst ziemlich brauchbar und zuverlässig arbeitet und verwendet werden kann. Wie schon gesagt: gerade im Open-Source-Bereich ist man das SEHR konservativ mit solchen Aussagen und kennzeichnet lieber etwas über Jahre als experimentell oder beta oder gibt ihm eine kleine Versionsnummer bzw. eine Versionsnummer kleiner eins oder bewusst unter einer magischen großen Versionsnummer und lässt das Ganze dann über Jahre so, als dass man zu früh irgendwas als fertig und stabil deklariert und diese Versprechen dann am Ende so nicht eingehalten werden können.
Von daher kann der ganze SMB2-Zustand da derzeit schon stabiler und zuverlässiger sein als Du dem Golem-Artikel da zu entnehmen scheinst.

Schau Dir mal die aktuelle Versionslinie von Samba an, die ist bereits 3.5.x (genauer: 3.5.6). Und schau Dir mal an, wo in der restlichen Unix-und Linuxwelt Samba 3.5.x bereits ausgeliefert wird und in Produktivumgebungen überall eingesetzt wird und warum.

Übrigens, Nachtrag bzgl. GPL2 vs. GPL3: es halten sich zu dem Thema hartnäckig die Gerüchte, dass u.a. auch das der wahre Grund gewesen sein könnte, dass Apple die CUPS-Technologie nebst seinem Core-Entwickler Michael Sweet und seiner Software Firma Easy Software Products aufgekauft haben könnte (sogar im CUPS-eigenen Forum ist da sogar ein entsprechener Eintrag zu finden, der dort unwidersprochen ist). Weil Apple nämlich nur so die Gefahr bannen konnte, dass diese für sie so essentielle Technologie ebenfalls unter die für sie unattraktive GPL3 fallen könnte bzw. Michael Sweet sich dazu entschließen würde, CUPS von der GPL2 auf die GPL3 umzustellen. Und bevor das eben geschehen konnte, hat Apple den Laden dann erstmal aufgekauft. Um dann als erste Amtshandlung schnell zu erklären, dass das Teil weiterhin unter der GPL2 bleibe, Apple sich aber per Liznez-Exception bzw. zusätzlicher Sonderlizenz einen Sonderstatus für CUPS unter MacOSX vorbehalte, der es Apple erlaube, CUPS für eigene Zwecke speziell aufzubohren und abzuwandeln und Teile davon nicht freizustellen (also etwas, was man unter einer GPL3 hätte nicht machen können, weil die genausowas verhindert hätte).

wenn du dir den Podcast angehörst hättest, wüßtest du es besser.

Es ist ja nicht so, dass ich nur Deinen Podcast und Deiner Golem-Quelle folge und derlei Entwicklungen mitverfolge. Samba und die ganzen Querelen mit Microsoft darum ist mir schon seit mehreren Jahren ein Begriff aus der restlichen Linux-/Unix-Welt. Ebenso wie CUPS etc.

Und um Dich zu beruhigen: den von Dir angeführten Podcast habe ich sehr wohl interessiert mitverfolgt (und zwar komplett). Natürlich kann ich mich irren, aber ich kann nicht erkennen, dass er mir da in meinen bisherigen Aussagen widerspricht. Möglicherweise hast Du ihn ja nicht ganz oder falsch verstanden, das kann ja auch sein.

sierkb: Worauf willst du eigentlich hinaus? GPL3 einzusetzen wäre für Apple einfach tödlich. Egal wie man zu Softwarepatenten seht, die gibt es nunmal und sind rechtlich bindend. Da wäre es selten dämlich von Apple sich mit der GPL3 als einzige große Firma selbst ein Bein zustellen. Deswegen wird wohl Apple nie GPLv3 einsetzten.

Das positive daran ist, dass Apple jetzt verstärkt andere Open Source Projekte unter freieren Lizenzen unterstützt. FreeBSD z.B. freut sich, bekommen sie doch jetzt endlich einen nicht-GPL Ersatz für ihren Compiler.

Volker Lendecke hat Tim Pritlove's Aussage des reverse engineering energisch widersprochen.

Offensichtlich hörst du nur das, was du hören willst!

Daraufhin, dass deutlich wird, dass es diesbzgl. möglicherweise und sehr wahrscheinlich rein lizenzrechtliche/lizenzpolitische Gründe sind, warum Apple bestimmte Software auf einem gewissen alten Stand eingefroren ausliefert und keine technischen Gründe.

Inwieweit?

Ja, leider.

Kommt drauf an, in welchem Land/Kontinent Du lebst, ob sie dort allgemein rechtlich anerkannt und damit dann bindend und durchsetzbar sind oder nicht.

Kommt drauf an, was bezweckt wird. Warum stellt eine Firma sich damit zwangsläufig selber ein Bein? Muss nicht.

Das ist wohl wahrscheinlich.

Das ist aber nichts Neues. Zumal Apple sich immer nur dort engagiert, wo es einen direkten und unmittelbaren Nutzen davon hat, zur Not ist man zwar formell dabei, entwickelt aber unter diesem Dach trotzdem nur für sich und seine eigenen Belange. Zudem: welche anderen Software-Projekte meinst Du da denn konkret, an denen Apple altruistischer partizipiert als bei den anderen, wo wohl eher der Eigennutz im Vordergrund steht?

Erstens ist in der gesamten Unix-Welt GNU-Software zu hause und quasi nicht mehr wegzudenken, selbst unter Solaris, man denke da nur mal an die GNU Bash und verschiedene andere GNU Tools, deren Äquivalent aus der BSD-Welt allerhöchst altbacken und unbequem aussieht und ist und deshalb von vielen verschmäht wird zugunsten der besseren und moderneren GNU-Tools.
Abgesehen davon ist LLVM eine tolle Konkurrenz zur GNU Compiler Collection (GCC), muss sich GCC doch anstrengen, da nicht den Anschluss zu verlieren bzw. zu stagnieren, wenn LLVM weiter solche Fortschritte macht wie bisher. Allerdings ist der von LLVM produzierte Code noch nicht überall dem von GCC ebenbürtig bzw. GCC hat in einigen Bereichen die Nase noch vorne (weshalb Apple bisher GCC ja auch noch einsetzt, weil's dazu bisher einfach noch keine bessere Alternative gibt). Trotzdem entwickelt sich auch GCC beständig weiter -- bisher sogar was Obj-C betrifft, in Grenzen sogar mit Apples Mithilfe.
Einziger Knackpunkt für Apple, da untreu zu werden, dürfte eben vor allem die GPL3-Geschichte sein. Ich bin mir nicht sicher, ob Apple ebenfalls so langsam aber sicher zu LLVM wechseln würde (LLVM ist ja kompatibel zum GCC bzw. kann GCC einbinden), wenn GCC nicht von der GPL2 zur GPL3 gewechselt hätte. Möglicherweise wäre Apple dann einer der treuesten und überzeugtesten GCC-Verwender, GCC gehört ja fest zu MacOSX dazu bzw. zu Apples Developer Tools -- wie eben bisher seit Jahren auch schon.

Und zweitens ist Apples UNIX-Chef kein Geringerer als Jordan K. Hubbard, Mitbegründer und Core-Mitglied von FreeBSD. Kein Wunder also, dass durch diese Nähe und Verbundenheit und dem sicher nicht ausbleibenden Austausch da auch Einiges zumindest nach FreeBSD wieder zurückfließt...

Ich habe es mir eben in Gänze nochmal angehört.
Ja, er widerspricht dem Begriff "Reverse Engineering". Und erklärt auch warum. Er widerspricht allerdings nicht dem Begriff Re-Engenieering. Und wo liegt der Unterschied zwischen beiden Begriffen? Erklärt Volker Lendecke ebenfalls. Aus seiner Sicht. Die nicht unbedingt so von allen geteilt werden muss bzw. juristisch durchaus umstritten ist. Und warum macht er das? Und vor allem: zu welchem Zeitpunkt war dieses Interview? War das Samba-Projekt zum Zeitpunkt des Interviews schon im Besitz von Sernets eingekauften Microsoft-Spezifikationen? Nein. Welche Rolle spielen genau solche Dokumente in bezug auf Lendecks Definition von "Reverse Engineering"?
Was sagt Lendeck später im Verlauf des Interviews nochmal zur allgemeinen Definition von Reverse Engineering und wann es im allgemeinen weltweit anerkannt und hierzulande rechtlich unbedenklich und erlaubt ist?

Warum wohl hat Microsoft über Jahre leere, unbewiesene Drohungen in Richtung verschiedener Linux-Distributoren (außer Novell, denn mit denen hat man ja einen Patent-Deal abgeschlossen) und auch in Richtung Samba-Projekt ausgesprochen?

Warum wohl ging im Samba-Team die Angst um, als es im Rahmen der EU-Verhandlung/-Prozesses gegen Microsoft zu mehreren Treffen kam, in denen eingeweihten Leuten Einblick in Microsofts Quellcode und Spezifikationen gegeben worden ist? Warum wohl hatte man im Samba-Projekt diese am Ende dieses Verfahrens freigegebenen Spezifikations-Dokumente, die Sernet ihnen beschafft hatte, erstmal mit spitzen Fingern angefasst?

Weil es quasi unmöglich ist, sich einen solchen Code anzuschauen und davon dann unbeeinflusst nach Hause zu gehen und dann einer möglichen Anschuldigung, man hätte sich das alles ja nur abgeguckt, glaubhaft entgegenzusetzen, dass der eigene Code tatsächlich ohne Wissen der Original-Dokumente entstanden ist!
Weil man sich nicht zum Vorwurf machen lassen wollte, man hätte tatsächlich bestehenden Code analysiert und adaptiert.

Samba ist über Jahre ohne Dokumentationen und ohne Code von Microsoft entstanden! Nur durch reine Netzwerk- und Protokollanalyse.

Nur noch Juristen und Microsoft und ein Volker Lendecke, der sich in einem solchen Interview sicher nicht auf juristisches Glatteis begeben will, fangen da dann an, spitzfindig zu definieren, ob das nun Reverse Engineering ist oder Re-Engineering bzw. "nur" Protokollanalyse (diesen Audruck bevorzugte Volker Lendecke ja in dem Interview). Was meinst Du, was losgewesen wäre, wenn Volker Lendecke freimütig bekannt hätte: "ja, das ist Reverse Engineering, was wir hier machen." Microsoft hätte sofort ein gefundenes Fressen gehabt und seine Anwälte losgeschickt mit den Worten: "Sie haben's sogar öffentlich zugegeben, dass sie Reverse-Engineering machen!".

Schau mal, wie bei Wikipedia Reverse-Engineering definiert wird:

Laut Volker Lendecke ist es also kein Reverse-Engineering, weil sie keinen Code von Microsoft dazu je zu Gesicht bekommen haben, den sie rückimplementieren konnten/können. Mittlerweile ist das Samba-Projekt aber im Besitz von Microsoft-Material, ja Microsoft steht ihnen sogar mit Rat und Tat zur Seite. Das ist jetzt alles NACH diesem EU-Gerichtsverfahren, das Microsoft mit Bausch und Bogen verloren hat. Das Interview mit Volker Lendecke war VOR dem Abschkuss des Verfahrens, da stand also noch so Einiges auf dem Spiel. Deshalb MUSSTE er da diese Äußerung machen, schon um sich und dem gesamten Samba-Projekt nicht unfreiwillig ein juristisches Bein zu stellen.

Zur Geschichte von Samba und dem Thema Protokoll- und Netzwerkanalyse u.a. ebenfalls bei Wikipedias Samba-Eintrag:

Diese Praxis wurde bei der Entwicklung von Samba mangels Spezifikationen und Original-Code, derer man habhaft sein konnte, über Jahre beibehalten und fortgeführt. Nur so ist Samba entstanden und gewachsen. Ein großer Teil des von Dir angeführten Interviews beschäftigt sich nur damit und mit den damit verbundenen Schwierigkeiten.

Microsoft würde sowas sehr wohl als Reverse-Engineering betrachten bzw. hat's jahrelang. Ohne Grund haben die nicht mit dem Säbel gerasselt. Ob da nun konkret Microsoft-Code, den man anschauen kann oder nicht, ist eine juristische Spitzfindigkeit. Genau deshalb hat man beim Samba-Team über Jahre äußerst peinlich genau drauf geachtet und teilweise sogar bestimmte Leute von einem Code-Review bzgl. Microsofts Quellen ferngehalten, um sich nicht einem solchen juristischen Vorwurf des Reverse-Engineerings auszusetzen. Ein Begriff, der für einige ganz sicher eng mit dem Code selber zusammenhängt und dessen Re-Implementierung und für andere schon früher losgeht (siehe dazu als Anhalt u.a. die Definitin/Erklärung, die man bei Wikipedia finden kann: und in deren Sinne Samba sehr wohl Reverse-Engineering ist und schon immer war, auch wenn man lange Zeit keinen Original-Code zur Einsicht hatte. Nicht ohne Grund ist dieser Wikipedia-Eintrag ja auch in dem Interview unten nochmal verlinkt).

Mittlerweile kann man da wohl insgesamt entspannter bei der Sache sein und sogar offiziell von Re-Ingeneering sprechen (und muss da nicht mehr so zimperlich und spitzfindig sein bei der Begriffswahl wie Volker Lendecke es in dem Interview war, das noch in einer Zeit der Unsicherheit stattfand, bevor das EU-Gerichtsurteil hier einige Schritte ermöglichte), denn das Samba-Projekt ist nach diesem wegweisenden EU-Urteil ganz legal im Besitz von entsprechenden Microsoft-Spezifikationen und Dokumenten und hat ganz legal Einblick in den Code erhalten bzw. Microsoft mauert da nicht länger und hilft sogar aus.

dieses Rekompilieren wäre, wenn sie sich Windows-Dateien von CD etc. angeschaut hätten, bzw. wenn sie diese re-kompliliert hätten.
Das haben sie aber nicht gemacht.

Aber wie gesagt, das hat Herr Lendecke in dem Podcast bereits ausführlich erklärt.

Nach wessen Aussage wäre das Rekompilieren zwingend notwendig, um als Reverse-Engineering bezeichnet zu werden?

Was meinst Du, wer im Laufe des EU-Gerichtsprozess da teilweise ins Gericht geladen war und wer sich da den Code,der da von Microsoft offengelegt worden ist, angeschaut hat? Und was meinst Du, wie umstritten genau das, bei allem Positiven, innerhalb des Samba-Projektes gewesen ist? Es hat sogar Stimmen gegeben, Leute vom Samba-Projekt auszuschließen undsie nicht in die Nähe des Samba-Codes zu lassen, die im Zuge eines solchen Code-Reviews auch nur aus der Ferne Einblick in Microsofts Code hatten. Solche Leute galten bei einigen Samba-Hardlinern als "verseucht". Weil man danach sich dem Risiko ausgesetzt sah, dass wenn solche Leute bei Samba auch nur noch eine Zeile Code schreiben würden, sie nicht unbeeinflusst wären von dem Code, den sie im Zuge dieses Code-Reviews an Original-Code von Microsoft gesehen hätten.
Das alles war aber VOR dem endgültigen Gerichtsurteil und VOR dem Zeitpunkt als Sernet da gegen eine Lizenzgebühr von 10.000 US Dollar als direkte Folge des EU-gerichtsurteils die Microsoft'schen Original-Unterlagen ins Samba-Projekt einbrachte. Und das war auch BEVOR Microsoft und das Samba-Projekt als direkte Folge dieser Entwicklungen wieder näher zusammenrückten und Informationen auf legale und offizielel Weise austauschten. Mittlerweile ist das aber alles ein wenig anders und entspannter und legaler. Weil man eben nun im Besitz gewisser Original-Dokumente von Microsoft ist, weil Microsoft hier aufgrund des Urteils sich gegenüber dem Samba-Projekt handzahmer zeigt und man sogar aufeinanderzugegangen ist und zusammenarbeitet. Microsoft tritt seit einiger Zeit sogar als großer Sponsor und Teilnehmer und mit Vertretern als Redner auf diversen Samba-Conventions bzw. Samba-Konferenzen auf.

Nur das Re-Kompilieren und in Umlauf bringen dessen, was man vorher gemacht hat (egal, wie es zustandegekommen ist) ist aber kein alleiniges Merkmal, umals Re-Engineering betrachtet zu werden. Re-Engineering umfasst da wohl doch eine ganze Menge mehr. Und von genau dieser Menge trifft da so Einiges auf Samba zu, auch wenn der Code, den man da geschrieben hat, nicht auf der Grundlage vom Original-Code entstanden ist sondern durch andere Analysemethoden. Auch dazu sagt Herr Lendecke was in seinem Interview, wie dazu die internationale Meinung und sogar die juristische Meinung in puncto Sicherstellung von Interoperabilität und wissenschaftlichen Zwecken ist, was Re-Engineering allgemein anbelangt. Er sagt nämlich damit ziemlich am Schluss nichts anderes, dass selbst wenn man es offiziell als Re-Engineering bezeichnen würde, was das Samba-Team da jahrelang gemacht hat, es unter diesen Gesichtspunkten wahrscheinlich völlig legal wäre, solange man es entweder nur für wissenschaftliche Studienzwecke täte und dann nicht in Umlauf brächte oder eben (und genau das ist der Punkt, um den es hier geht), um Interoperabilität sicherzustellen, die aufgrund des Monopol-Charakters bzw. der Monopolgefahr anders nicht herzustellen wäre. Und genau Letzteres ist hier der Fall.

Lange Jahre ganz bewusst nicht. Jetzt, da sowohl offizielle Spezifikationen auf dem Tisch liegen und auch Microsoft selber da aushilft (evtl. sogar auch mit Code?) bin ich mir da gar nicht mehr so sicher, ob man da mittlerweile nicht viel lockerer rangehen kann bzw. das tut.

Seine Erklärungen widersprechen überhaupt nicht den meinigen. Im Grunde bestätigen seine Erklärungen nur die meinigen bzw. seine und meine decken sich und ergänzen sich gegenseitig.

dom_beta:

Lies mal:

Samba Team Blog, 7 August 2009


Samba Team Blog, 25 December 2009 (Getting to Samba 4)

Bitte alles lesen, aber u.a. findet sich da folgende Aussage drin (damals, im Dezember 2009):
Andrew Bartlett (Samba Team): A year since Microsoft's EU appeal failed
A Trip report for CIFS Conference and AD Plugfest, Sep-0ct 2008.

IT News.au: Microsoft says Samba co-operation working well (Aug 31, 2010)

Das alles fand und findet statt deutlich NACH dem Interview mit Volker Lendecke, auf welches Du Dich beziehst und welches im Mai 2006 stattfand. Und zu der Zeit sah das alles noch viel viel ungünstiger aus und war viel viel unbequemer, eben weil man per sehr mühevollem Reverse-Engineering per Protokoll- und Netzwerkanalyse sich alles hart erarbeiten musste und im Grunde immer nur im Dunkeln tappte auf der Suche nach dem richtigen und passenden Weg.

Und, um den Schluss zum Eingangsthema wiederzufinden, an den Errungenschaften, die eben seitdem gerade durch die erzwungene Offenlegung der Spezifikationen und durch die Mitarbeit und auch die Code-Beiträge Microsofts zustandegekommen sind, hat Apple irgendwie nicht richtig teil bzw. müht sich damit ab, weil sie offenbar Akzeptanzprobleme mit der GPL3 haben und aktuelle Samba-Versionen eben unter der GPL3 stehen statt wie bisher unter der GPL2. Ergo hockt nun Apple auf diesen veralteten Samba-Versionen und muss versuchen, die aktuellen Entwicklungen, die in Samba stattfinden (wozu eben auch die Beiträge und das Know-How von Microsoft gehören) irgendwie seiner veralteten Samba-Version beizubringen, obwohl es doch viel einfacher und sinnvoller wäre, schlicht und einfach eine aktuelle Samba-Version einzusetzen, die diese Errungenschaften schon alle ab Werk in sich trägt.
Und ich bezweifele, dass es Apple auf Dauer gelingen wird, diesen für sie so aufwendigen und mit ziemlich viel Arbeit verbundenen Zustand weiter aufrechtzuerhalten. Das bindet nämlich unnütz Kräfte, und man hinkt zwangsläufig immer der Hauptentwicklung hinterher bzw. halst sich Probleme auf, die nicht unbedingt sein müssten. Siehe auch am Beispiel Java, weshalb man das aus ziemlich ähnlichen Gründen nun endlich aus der Hand gegeben hat. Dort ist man ja jahrelang auch einen Sonderweg gegangen und wollte da alles selbst machen bzw. seinen eigenen Kopf durchsetzen, und Apple hat sich damit im Grunde übernommen bzw. braucht seine Kräfte anderorts dringender.

Das (recht aktuelle) Interview mit Tom Hanrahan, director of Microsoft's Open Source Labs unter fasst die aktuelle Lage und äußerst positive Entwicklung eigentlich wunderbar zusammen. Das geht an Apple derzeit alles vorbei bzw. Apple macht es sich bzgl. dieser ganzen so wunderbaren und begrüßenswerten Entwicklung und Zusammenarbeit mit Microsoft unnötig schwer. Weil Apple offenbar Akzeptanz-Probleme mit der GPL3 hat, unter der das aktuelle Samba eben mittlerweile steht (was Microsoft offenbar nicht abhält, trotzdem an der Entwicklung von Samba aktiv mitzuhelfen und sogar auch selber Code beizusteuern -- eine positive Entwicklung, wovon mancher im Samba-Team bei allem Optimismus noch vor kurzer Zeit nicht zu träumen gewagt hätte).

Hallo,

na ja, wenn das so negativi weiter geht mit Apple, müssen sie diesen Absatz aus ihrer Mac OS X Beschreibung streichen:

ich hoffe aber mal, daß sie Samba 3.5 einsetzen werden. Ein Teil von Mac OS X ist ja auch Open Source.


MfG

Du meinst nicht, dass sie das schon längst getan hätten, wenn sie gewollt hätten? Immerhin ist Samba offiziell schon bei Version 3.5.6 und geht so langsam auf Version 3.6 zu...

Ja und? Was hat das damit zu tun, wie alt bzw. wie aktuell genau dieser Open-Source-Stack namens Darwin ist, auf den Apple sein MacOSX aufbaut? Auch dieser Open-Source-Stack will aktuell gehalten sein bzw. entwickelt sich in seinen einzelnen Bestandteilen weiter. Da hinkt Apple an so mancher Stelle hinterher bzw. braucht zwischendurch immer mal wieder Anschub (und sei es, dass man einen entsprechenden Bug in deren Bug-Datenbank schreibt, damit die in die Puschen kommen und daran erinnert werden, dass es diese Software bei ihnen ja auch noch gibt), damit sie da ein Update bringen. Ich könnte Dir so manche Software aus diesem Open-Source-Fundament aufzählen, die von Apple seit einiger Zeit nicht mehr erneuert worden ist, obwohls da noch nicht mal potentzielle lizenzrechtliche Bedenken gibt bzw. geben kann. Und erst, wenn man sie mehrmals drauf aufmerksam macht und anstubst (und selbst dann noch nichtmal unbedingt), wird dann mal irgendwann auf einen aktuellen Stand geupdatet. Subversion ist so ein Beispiel: das hängt derzeit auch noch bei Version 1.6.5 fest, obwohl Subversion mittlerweile bei Version 1.6.13 angekommen ist und kurz vor Version 1.7 steht. Zwischenzeitlich aktualisiert Apple da durchaus, nur sind die Zeiträume dazwischen teilweise unverständlich und irre lange, die Apple sich da Zeit lässt. Warum eigentlich? Bei anderen Dingen bekommen sie Aktualität bzw. Halbwegs-Aktualität doch auch hin.
Diverse Programme aus deren Unix-Stack Darwin könnten da mal aktualisiert werden, teilweise sind die noch nicht mal von Leopard auf Snow Leopard aktualisiert worden. Ohne Not. Tidy ist so ein Beispiel. Das krebst da imemr noch auf einer Jahre zurückliegenden Version herum. Obwohl ich einen Bug geschrieben habe. Obwohl ich diesen Bug sogar bei OpenRadar öffentlich gemacht habe. Obwohl ich sogar bei MacPorts und auch bei FreeBSD in der Ports Collection eine Aktualisierung erreicht habe. Nur Apple schafft's irgendwie nicht. Und derer Beispiele gäbe es viele zu nennen, was dieverse Unix-Programme und -Bibliotheken angeht.

Apple pennt da schlicht und einfach auch nicht selten bzw. lässt's schleifen. Im Fall von Samba glaube ich jedoch, dass es allein oben genannte lizenzrechtliche Gründe hat, sonst würde Samba unter MacOSX nicht schon so lange und behaarlich bei eben genau dieser Versionsnummer, die es immer noch offiziell hat, festgefroren sein. Immerhin ist Samba ziemlich essentiell unter Unix und nichts Unwichtiges, bei dem man sich unbedingt leisten sollte, hier der Gesamtentwicklung hinterherzuhinken oder es schleifen zu lassen. Aber Apple leistet sich eben diesen Luxus. Und lässt Dinge eben schleifen, teilweise bis zur Schmerzgrenze und bis zum nicht mehr Tolerablen. Das können andere Unices und Linux-Distributionen besser, die geben da i.d.R. ein deutlich besseres Erscheinungsbild ab, was das alles angeht, wenn man nicht gerade eine ultrakonservative Debian- oder Red-Hat-Distribution hernimmt, die mit Software von vorgestern bestückt ist und dann vom Distributor erstmal ein paar Jahre nicht weiter angefasst wird, bevor sie erneuert wird.

Hallo sierkb,

ist ja gut! Ich versteh dich ja!

Das ist sehr gut möglich, daß es am Rechtlichen hapert, es kann aber auch sein, daß ...

in dieser Version irgendetwas fehlt, was Apple möglicherweise benötigt. Ich bin kein Entwickler und bin leider noch nicht so sehr darin involviert, aber es könnte aber auch sein, daß Samba 3.5.x für Apple noch nicht ausgereift ist.

Oder sie möchten erst einmal Microsoft Exchange unterstützen.

Oh je, da sind die Apples vollkommen schmerzfrei!


MfG

Was könnte das denn beispielweise sein? Fehlt das anderen Unix-Distributoren auch, die da weniger Probleme damit haben im Gegensatz zu Apple ein aktuelles Samba einzusetzen?
Abgesehen davon: das Samba-Projekt ist mittlerweile im Besitz aller notwendigen Unterlagen und Spezifikationen. Und Microsoft hilt da mit, man tauscht sich aus, stellt gegenseitig Entwickler ab, teilt Testlabore, teilt Testsuiten.
Es sollte Apple ein Leichtes sein, sich da mit seinen Wünschen einzuklingken, wenn's da offene Fragen ihrerseits gäbe. Da würde sich garantiert jemand drum kümmern, und im Zweifel würde im Rahmen der Zusammenarbeit da sicher Microsoft sogar direkt aushelfen. Oder Apple würde im Rahmen des Samba-Projektes selber Hand anlegen und sich unter anleitung und Mithilfe der anderen und von Microsoft direkt seinen für sie notwendigen Code selber schreiben. So, wie sie es beim GCC und bezüglich dessen Objective-C-Fähigkeiten ja auch gemacht haben. Die braucht nämlich sonst eigentlich niemand außer Apple. Also hat Apple dem GCC höchstselbst beigebracht, mit Objective-C-Code umzugehen und zu erzeugen. Und zwar nicht im stillen Kämmerlein, sondern offiziell als Bestandteil des offiziellen GCC und im Rahmen der normalen GCC-Entwicklung.

Wenn es also einen solchen Spezial-Bedarf bzgl. Samba unter MacOSX geben sollte, könnte Apple sich da also auch ganz offiziell in die Samba-Entwicklung mit einklinken und ggf. durch eigene aktive Mitarbeit ganz offiziell Samba dazu befähigen oder befähigen lassen, ihren Ansprüchen zu genügen. Im besten Falle würden sie dann vielleicht sogar nochdirekte Hilfe von Microsoft selber bekommen, das möglichst galant und glatt hinzubekommen.

Wo wäre da das Problem? Es sei denn, ja es sei denn, Apple hätte ein grundsätzliches Problem damit -- und zwar ursächlich in bezug auf die GPL3 unter der Samba eben mittlerweile steht und eine sogenannte Tivoisation [url]http://en.wikipedia.org/wiki/Tivoization[url] eben nicht ermöglicht, die Apple aber evtl. gerne hätte oder anstrebt oder sich als potentielle Hintertüre offenhalten will.