Das Hinterherprogrammieren von MS Standards ist auf Dauer zwecklos, da MS ständig alle Specs ändern kann. Bei Openoffice versucht man seit 10 Jahren die .doc Specs nachzuprorgrammieren, aber es geling eben nur fast. Erst mit dem offenen .odt hat MS richtig Probleme gekriegt. Gibt es denn keine Alternative zu Cifs? Z.B. OpenAFS inkl. Client für alle OS, dazu noch eine Trennung von Metadaten und Fileserver, was erst bei NFS 4.1 geplant ist?
das sehe ich genauso: die opensource-gemeinde ist mittlerweile stark genug eigene standards zu formulieren - eben offene standards. mit mehr selbstbewußtsein kann man wohl behaupten, das M$ nicht das maß aller dinge ist: warum sollten wir nicht auch mal im server-umfeld etwas vorgeben? M$ hinterher zu programmieren hemmt wahrscheinlich nur die kreativität. gruss
Natürlich gibt es gute und vielleicht auch bessere Alternativen. Dies bringt mir aber herzlich wenig, wenn ich mit meinem Linuxrechner auf ein Windowsnetzwerk zugreifen möchte. Ich würde sogar behaupten, dass man einige linuxbasierte Fileserver komplett dicht machen könnte - bringt ja nichts, so etwas zu betreiben, wenn andere schon vorhandene Windowsserver nicht drauf zugreifen könnten bzw. müsste ich mir dann erst recht ein Windows installieren um auf das Netzwerk zugreifen zu können. Ich denke schon, dass was Server angeht auf der Linuxseite es mehr und somit meist auch bessere Möglichkeiten gibt. Denn da wo ich keine habe, habe ich immer die schlechtere Wahl. Schöne Grüße, phorkyas
Das "Hinterherprogrammieren von MS Standards" ist nicht zwecklos, sondern hat den Zweck, auf nicht sowohl auf der Clientseite als auch der Serverseite MS-Produkte einsetzen zu müssen.
Es macht immer Sinn, Kunden von Microsoft einen Ausweg anzubieten. Und für die Samba-Entwickler ist der Windows-Markt wohl für sich interessant. Ihre Fileserver sind kleiner, feiner und besser als alles was ein "Windows Home Server" zu bieten hat. Damit verdienen die teilweise einfach ihr gutes Geld.
Für uns kommt jedenfalls nichts ausser Samba in Frage, weil wir noch lange Jahre die RHEL3 Test-Systeme unterstützen wollen, und daher sowieso NFSv3 und/oder Samba brauchen, um auch auf diesen Systemen alle Dateien zu haben.
Und zu .doc möchte ich noch sagen, dass auch Microsoft ihre eigenen .doc nicht richtig lesen kann.
Von Crass Spektakel am Mo, 1. Oktober 2007 um 19:02 #
Ich hatte kürzlich die Ehre mit mehreren hochrangigen Microsoft-Programmierern (Kernel-Entwicklung, SMB-Implementierung, Posix-Schnittstellen) zu diskutieren.
Und diese meinten daß es absolut System habe daß Microsoft alle zwei Jahre sämtliche API/ABIs komplett über den Hausen wirft. Nur so kann man die Konkurrenz daran hindern, voll kompatibel zu werden. Gerade Dotnet spielt hier eine besondere Rolle: Hier geht es nicht nur um eine neue API/ABI sondern auch um eine neue Lizenz. Man verschenkt den Source aber infiziert die Szene mit virulenten Lizenzen - also macht MS mit Dotnet genau das was sie GPL vorwerfen.
Der Kampf ist noch lange nicht vorbei. Aber immerhin, was Microsoft jetzt macht sind mobile Reaktionsgefechte, kein ignorantes Aussitzen mehr. Da ist es nur noch ein kleiner Schritt bis zum Rückzugsgefecht.
Diese Taktik ist doch schon lange bekannt und wird auch von Microsoft mehr oder weniger offen zugegeben. Ich kann mich noch erinnern, dass damals mit voller Absicht Windows 3.1 inkompatibel zu DR-DOS gemacht wurde.
Was DotNet betrifft weiß ich nicht was Microsoft plant, werden sie gegen Mono die Patentkeule schwingen oder nicht? Fakt ist jedoch, dass die Ms-PL und die Ms-CL sogar nach Ansicht der FSF echte freie Software-Lizenzen sind. Ich sehe auf den ersten Blick keine Schwächung für die freie Software Community wenn sich diese Lizenzen weiter verbreiten. Im Gegenteil:
Microsoft sieht sich nicht an die GPLv3 gebunden, da sie meinen keine GPLv3-Software zu vertreiben. MS hat dabei in erster Linie Novell SLES im Blick. Jedoch betreibt MS das Open Source Hosting Portal codeplex.com. Und ... tada ... es gibt dort bereits Projekte die unter GPLv3 stehen. Also: MS betreibt Server von denen man GPLv3-Software herunter laden kann - deutlicher kann man GPLv3-Software kaum vertreiben.
schön, dass auf meine antwort wieder das vorgebete von der unumgänglichen marktmacht M$ folgt.... aber was wäre denn, wenn es einen opensource-server gebe, der (windows-)clients bei connect mit einer dll anfixt und ihnen so die funktionalität gibt, mit dem server zu arbeiten.... oder eine technik entwickelt wird, die keine zentralen server mehr braucht: die daten liegen, wo sie liegen und es gibt nur noch einen großen index - die clients im netz sind der server.... und so weiter. der kreativität sind keine grenzen gesetzt, ach nein, die gibt ja M$ für die opensource-entwickler vor also schauen wir, dass wir weiter kompatibel zu den fenstern bleiben.... gruss
Klar, weil alles andere immer noch an der Realität vorbei geht. Davon abgesehen ist SMB bereits das, was hier allen Ortens gefordert wird - ein freies, dokumentiertes Protokoll. Das MS daraus sein CIFS mit proprietären Erweiterungen gemacht hat ist unschön, aber nicht zu ändern, und das Samba nicht einfach CIFS hinterherentwickelt wurde zeigt schon der Fakt, dass die ersten Sambaversionen bereits einiges vor den ersten Windowsversionen mit CIFS erschienen sind.
ich habe gerade über google meinen fast 4jahre alten beitrag gefunden :) und da wir mittlerweile von der cloud (der daten-wolke) reden, waren doch meine vorschläge garnicht so weit weg... auch das daten im lan/intranet mit p2p/filesharing genutzt werden ist schon ein brauchbares konzept... fragt sich also, wie sich samba die nächsten 4 jahre entwickeln kann - nicht muss...
soso,saemtliche APIs...wie lange gibt es jetzt WinAPI schon? seit den 80gern? Die einzige API wo mir das bekannt ist, ist DirectX, wegen den rasanten aenderungen der HW faehigkeiten,kann man das aber sogar als nicht ganz sinnfrei einstufen.
ueberhaupt waere ABI aendern ja ein schuss nach hinten,da dann ja alle alten programme nichtmehr laufen wuerden,sondern angepasst oder zumindest neu uebersetzt werden muessten.
http://www.noooxml.org
gruss
Ich denke schon, dass was Server angeht auf der Linuxseite es mehr und somit meist auch bessere Möglichkeiten gibt. Denn da wo ich keine habe, habe ich immer die schlechtere Wahl.
Schöne Grüße,
phorkyas
MfG =HAL-9000=
Es macht immer Sinn, Kunden von Microsoft einen Ausweg anzubieten. Und für die Samba-Entwickler ist der Windows-Markt wohl für sich interessant. Ihre Fileserver sind kleiner, feiner und besser als alles was ein "Windows Home Server" zu bieten hat. Damit verdienen die teilweise einfach ihr gutes Geld.
Für uns kommt jedenfalls nichts ausser Samba in Frage, weil wir noch lange Jahre die RHEL3 Test-Systeme unterstützen wollen, und daher sowieso NFSv3 und/oder Samba brauchen, um auch auf diesen Systemen alle Dateien zu haben.
Und zu .doc möchte ich noch sagen, dass auch Microsoft ihre eigenen .doc nicht richtig lesen kann.
Gruss,
Kay
Stimmt. Das kann inzwischen sogar OpenOffice besser, besonders bei alten .doc Dokumenten
Und diese meinten daß es absolut System habe daß Microsoft alle zwei Jahre sämtliche API/ABIs komplett über den Hausen wirft. Nur so kann man die Konkurrenz daran hindern, voll kompatibel zu werden. Gerade Dotnet spielt hier eine besondere Rolle: Hier geht es nicht nur um eine neue API/ABI sondern auch um eine neue Lizenz. Man verschenkt den Source aber infiziert die Szene mit virulenten Lizenzen - also macht MS mit Dotnet genau das was sie GPL vorwerfen.
Der Kampf ist noch lange nicht vorbei. Aber immerhin, was Microsoft jetzt macht sind mobile Reaktionsgefechte, kein ignorantes Aussitzen mehr. Da ist es nur noch ein kleiner Schritt bis zum Rückzugsgefecht.
Quelle: http://en.wikiquote.org/wiki/Gandhi
Was DotNet betrifft weiß ich nicht was Microsoft plant, werden sie gegen Mono die Patentkeule schwingen oder nicht? Fakt ist jedoch, dass die Ms-PL und die Ms-CL sogar nach Ansicht der FSF echte freie Software-Lizenzen sind. Ich sehe auf den ersten Blick keine Schwächung für die freie Software Community wenn sich diese Lizenzen weiter verbreiten. Im Gegenteil:
Microsoft sieht sich nicht an die GPLv3 gebunden, da sie meinen keine GPLv3-Software zu vertreiben. MS hat dabei in erster Linie Novell SLES im Blick. Jedoch betreibt MS das Open Source Hosting Portal codeplex.com. Und ... tada ... es gibt dort bereits Projekte die unter GPLv3 stehen. Also: MS betreibt Server von denen man GPLv3-Software herunter laden kann - deutlicher kann man GPLv3-Software kaum vertreiben.
aber was wäre denn, wenn es einen opensource-server gebe, der (windows-)clients bei connect mit einer dll anfixt und ihnen so die funktionalität gibt, mit dem server zu arbeiten....
oder eine technik entwickelt wird, die keine zentralen server mehr braucht: die daten liegen, wo sie liegen und es gibt nur noch einen großen index - die clients im netz sind der server....
und so weiter.
der kreativität sind keine grenzen gesetzt, ach nein, die gibt ja M$ für die opensource-entwickler vor
gruss
lg
Erik
ich habe gerade über google meinen fast 4jahre alten beitrag gefunden :)
und da wir mittlerweile von der cloud (der daten-wolke) reden, waren doch meine vorschläge garnicht so weit weg...
auch das daten im lan/intranet mit p2p/filesharing genutzt werden ist schon ein brauchbares konzept...
fragt sich also, wie sich samba die nächsten 4 jahre entwickeln kann - nicht muss...
Die einzige API wo mir das bekannt ist, ist DirectX, wegen den rasanten aenderungen der HW faehigkeiten,kann man das aber sogar als nicht ganz sinnfrei einstufen.
ueberhaupt waere ABI aendern ja ein schuss nach hinten,da dann ja alle alten programme nichtmehr laufen wuerden,sondern angepasst oder zumindest neu uebersetzt werden muessten.