Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 65 reacties
Submitter: Pacjack

De Protocol Freedom Information Foundation krijgt technische gegevens over Windows Server van Microsoft. De organisatie zal de documentatie onder andere beschikbaar stellen aan het Samba-project.

Medio september bekrachtigde het Europese Hof van Eerste Aanleg de beslissing van de Europese Commissie dat Microsoft concurrenten meer technische informatie over Windows Server moet verschaffen, zodat hun producten beter met Windows kunnen samenwerken.

De Pfif, een non-profitorganisatie die in het leven is geroepen door het Software Freedom Law Center, heeft in het kader van het besluit van de Europese Commissie nu voor tienduizend euro de Workgroup Server-protocollen verkregen. Voor dat geld mag het Samba-project de specificaties voor zijn software gebruiken.

De documentatie zelf moet geheim blijven, maar code op basis ervan mag zonder enig voorbehoud onder versie twee en drie van de GNU General Public License gepubliceerd worden. Andrew Tridgell, geestelijk vader van Samba, is blij met de overeenkomst: 'Het stelt ons in staat up-to-date te blijven met veranderingen in Microsoft Windows en het helpt ook andere vrijesoftwareprojecten die met Windows moeten kunnen samenwerken.'

Moderatie-faq Wijzig weergave

Reacties (65)

Dit toont aan dat de rechtszaken en boetes van de EU wel degelijk werken en bedrijven en organisaties van over de hele wereld profiteren hier van mee.

De gerechtelijke uitkomst komt voor de aanleiding vaak als mosterd na de maaltijd, maar er is toch duidelijk wel wat bereikt.

En uiteindelijk zal MS hier ook van profiteren. Meer organisaties kunnen nu met innovatieve producten komen en dat komt op de lange termijn ook het Windows platform ten goede. Misschien houd MS dan op met in nauwe termen te denken en het Windows domein als hun exclusieve speelveld te beschouwen waar ze op alle fronten heer en meester moeten zijn.
En uiteindelijk zal MS hier ook van profiteren
Ik denk het niet. Als MS hiervan had kunnen profiteren dan hadden ze dit al lang gedaan, ze zijn daar in Redmond ook niet op hun achterhoofd gevallen :)

Wat MS met het geheim houden van hun protocollen natuurlijk probeerde te bereiken is dat zij de allerbeste integratie van hun servers konden bereiken. Dus, stel, je hebt een MS server staan, dan kun je ook maar beter MS desktops gaan aanschaffen. En vice versa.
Dit werkt omdat MS zo'n groot marktaandeel heeft dat je moeilijk om hun heen kan.

Nu meer en meer protocollen van MS beschikbaar komen voor concurrentie, zul je uiteindelijk meer verschillende operating systems tegenkomen in bedrijven. En dat is een achteruitgang voor MS, omdat die nu nog op bepaalde gebieden bijna de hele markt in handen hebben.
Ik denk het niet. Als MS hiervan had kunnen profiteren dan hadden ze dit al lang gedaan, ze zijn daar in Redmond ook niet op hun achterhoofd gevallen
offtopic:
Heb jij Steve Ballmer wel eens bezig gezien? Die kerel is echt knettergek (en niet op positieve manier).


ontopic:

Microsoft heeft ondanks het feit dat ze daar inderdaad niet op hun achterhoofd zijn gevallen, ernstige moeite met vooruitgang (anders dan vooruitgang door ingekochte technologie). Zelf met werkelijk inovatieve zaken komen wordt bij Microsoft, heb ik 't idee, niet tot nauwelijks aangemoedigd, en dat doet zich gelden binnen alle facetten van de organisatie.

Het meest extreme wat ik Microsoft de laatste paar jaren heb zien doen was een compleet andere architectuur gebruiken voor de Xbox 360. (een tri-core powerpc), en daar houdt 't ook eigelijk wel op.
CIFS/SMB is dan ook een vrij oude standaard uit de tijd dat MS de filofie had om alles gesloten te houden, het doet MS niet zoveel pijn om die nu vrij te geven. Bij modernere standaarden als bv UPnP en OOXML gaven ze de specs al vanaf het begin vrij.

[Reactie gewijzigd door Dreamvoid op 21 december 2007 20:15]

Nou wil ik niet lullig zijn, ik zie hier een aantal hele goeie opmerking en meningen, maar...

Het gaat hier erover dat de: "Workgroup Server-protocollen", als ik dit lees is het eerste waar ik aan ga denken: "Hoe zit het dan met de server protocollen voor in een Domein omgeving...?".

want ik mag toch aannemen dat daar toch aardig wat verschillen in zullen zitten.
Dezelfde vraag werd op Slashdot gesteld en Jeremy Allison, één van de ontwikkelaars van Samba, antwoordt daarop dat ook alle Active Directory-protocollen hier deel van uitmaken.

\[edit: correctie link]

[Reactie gewijzigd door fondacio op 21 december 2007 14:12]

Ze blijven maar op de rug van Microsoft zitten he die EU?
Ach misschien verdient Microsoft er zelf ook nog wat aan.
En terecht, smb/cfis is niet eens een protocol dat MS heeft bedacht, ze hebben het gewoon overgenomen van Novell , en er toen allerlei aanpassigen aangedaan om het langzaam aan incompatibel te maken.

Nu is dat dus ongedaan gemaakt, is alleen maar beter voor de consument, de samba implementatie is altijd al veel sneller geweest maar ging soms vanwege de fouten in de impementatie van MS nog wel eens op z'n waffel in een windows omgeving.
Dus als ik het goed begrijp past Samba zijn software aan aan de brakke Microsoft implementatie alleen maar voor de combatibiliteit?
Een beetje de omgekeerde wereld.
alleen maar voor de combatibiliteit?
Waar gebruik je anders Samba voor?
Zonder een windows systeem in het netwerk kan je veel beter gebruik maken van NFS (Network File System), dat werkt sneller als SMB.
Dus zoals Olaf al zei, Samba is puur voor combatibiliteit met Windows.
Bij Windows Server 2008 icm Vista is het protocol volgens Microsoft verbeterd cq efficienter gemaakt. Dat zit neem ik aan ook in deze documentatie verwerkt?
Dat is toevallig! Ik las net dit: http://www.theregister.co...e_vista_copying_problems/

Wellicht komt dit niet voor tussen Windows Server en Vista, maar toch :9 .
Dat mag ook wel, aangezien Microsoft niet helemaal eerlijk speelt. Ik vind dit een hele goede stap op weg naar goed lopende gemengde omgevingen.
1x ¤ 10.000 euro, gok ik. Hoewel, er zullen misschien nog wel een paar partijen meer interesse hebben. Maar ik denk niet dat dat er ontzettend veel zullen zijn eigenlijk.
Die partijen kunnen het dan toch ook gewoon bij die pfif halen, zoals samba? Blijkbaar mogen ze het gewoon, onder een soort van nondisclosure agreement, verder distribueren, anders kon samba er niet bij.
Ik denk dat de pfif wel een paar voorwaarden voor zoiets heeft; Samba is een open source project, en ik denk dat andere serieuze projecten zoals deze ook wel de documentatie kunnen krijgen. Maar andere, commercieel ingestelde partijen kunnen mooi zelf hun licenties bij Microsoft halen lijkt mij.
Ik vraag me af in hoeverre dat een en ander op basis van de samba sourcecode te reverse engineeren is. Het lijkt me toch dat dit makkelijk door anderen te implementeren is, je hebt dan wel niet de documentatie maar toch.
Wat bedoel je met "dat"? Ik neem aan dat je weet dat heel Samba tot nu toe min of meer het resultaat was van het reverse-engineeren van de Windows-protocollen. Bedoel je dat je de nieuwe Samba-code die geschreven is op basis van de van Microsoft verkregen informatie weer anderen die niet het recht hebben de MS-documentatie in te zien, in staat zal stellen de protocollen te reverse-engineeren? Dat is voorstelbaar en dan betekent dat in de praktijk dat informatie over de protocollen breder verspreid zal worden. Op Slashdot stelde iemand de vraag hoe Samba-gebruikers zonder toegang tot de documentatie toch kunnen helpen bugs te pletten zonder daarbij de door MS vereiste vertrouwelijkheid te schaden. Eén van de Samba-developers geeft daarop dit antwoord:
They way it will work is as follows. We'll read the docs and work on creating client-side test cases and embedding them into Samba4 smbtorture. Once that's in place, any competent engineer can create the server-side implementation without having to have access to the actual docs. We need the test cases anyway (remember, untested code is broken code), so this is the way we've been going about doing things anyway. This should just open up new protocols and new protocol areas to implementation by others.
Die documentatie valt na het reverse engineren ook wel zelf te schrijven mag ik aannemen.
thekip bedoeld dat je aan de hand van de source van samba kunt afleiden wat er in de documentatie staat, oftewel hoe het zou moeten werken.
Reverse engineeren is hiervoor niet de juiste term.
De Pfif, een non-profitorganisatie die in het leven is geroepen door het Software Freedom Law Center, heeft in het kader van het besluit van de Europese Commissie nu voor tienduizend euro de Workgroup Server-protocollen verkregen. Voor dat geld mag het Samba-project de specificaties voor zijn software gebruiken.
Jammer dat de EC niet heeft geeist dat de documentatie/licentie gratis beschikbaar moet zijn.
Maar dat is toch ook onzin? Microsoft heeft het hele systeem ontwikkeld, daar is veel research in gegaan, dan mogen ze er toch ook op verdienen? We hebben het hier nog altijd over een bedrijf, niet een liefdadigheidsinstelling.

[Reactie gewijzigd door Neko Koneko op 21 december 2007 11:33]

Maar dat is toch ook onzin?
Nee. MS heeft een monopoliepositie en het is toch onzin om toe te laten dat ze die positie versterken door het lastig te maken met MS clients/servers te praten?

Het is niet alsof ze hun source code moeten publiceren, het gaat gewoon om de protocollen.
Als MS gewoon standaardprotocollen had gebruikt, hadden ze niet eens wat hoeven publiceren.
Als MS gewoon standaardprotocollen had gebruikt, hadden ze de vrijheid niet om eigen veranderingen door te voeren - met een minder functioneel product als gevolg. Het ligt wat genuanceerder.
Interoperabiliteit gaat om vrijheden van de gebruikers, niet om vrijheden van een fabrikant. Het is in het belang van de gebruikers dat dingen goed met elkaar kunnen samenwerken maar niet in het belang van de fabrikant. Een fabrikant verkoopt meer wanneer het juist niet compatible is met de rest omdat een gebruiker dan de nodige dingen van die fabrikant moet aanschaffen i.p.v. dat het bij de concurrentie kan gaan shoppen.

Dit hele verhaal staat semi-los van functionaliteit en kwaliteit van een product. Je kunt prima de functionaliteit van een standaard uitbreiden. Je geeft gewoon de verbeteringen die je hebt door en de groep bepaald uiteindelijk of ze doorgevoerd worden of niet. Wat de een een verbetering vindt betekent lang niet altijd dat het ook om een daadwerkelijke verbetering gaat. Sommige ideeën zijn dusdanig fout dat je ze gewoon absoluut niet geïmplementeerd zou willen hebben. In dat opzicht beïnvloed dat dus ook weer de kwaliteit van zo'n standaard. Ook interoperabiliteit heeft invloed op de functionaliteit (uitwisselen van data tussen software zou een klant ook kunnen opnemen als functionaliteit van een product).

Het verhaal is een stuk anders dan hoe jij het er nu neerzet omdat je domweg alleen kijkt vanuit de optiek van de fabrikant en de optiek van de gebruiker (waar het uiteindelijk allemaal om gaat want die koopt je product) volledig buiten beschouwing laat.
weet nog goed dat er een tijd was dat apple alleen met apple werkte, en ibm alleen met ibm. toen kwamen er standaarden en werkte alles samen.
microsoft sprong hier op in door deze te ondersteunen (goed). maar met de jaren, wanneer microsoft grooter werd. zijn ze bastaarden en nieuwe protocolen gaan maken. en vervolgens houden ze deze weer gesloten. terug naar af dus.

DAAROM vindt ik dat ze deze moeten vrij geven, zodat er alsnog betrouwbare communicatie mogelijk is tussen machine A en machine B terwijl deze bijde op totaal andere systemen draaien.

of zit ik hier nu totaal verkeerd? (niet gewoon bashen dan maar argumenten, dank u)
Ja, en alle nasi is ook hetzelfde. Als de standaardprotocollen voldoende waren voor MS, zouden ze niet investeren in het (door)ontwikkelen van hun eigen. Alleen omdat een bepaald protocol of wat dan ook standaard is, betekent niet dat het aan de eisen en wensen van een gebruiker voldoet.
Als de standaardprotocollen voldoende waren voor MS... ..betekent niet dat het aan de eisen en wensen van een gebruiker voldoet.
Je haalt twee dingen door elkaar: Microsoft ontwikkelt die standaarden niet om aan de wensen van de klant te voldoen, maar om aan de eisen van haar eigen aandeelhouders te voldoen; om meer geld te kunnen verdienen dus; het doel van ieder beursgenoteerd bedrijf in handen van aandeelhouders. Of dacht je soms dat ABN-AMRO is / wordt opgesplitst om aan de wensen van de klanten te voldoen?
Alleen omdat een bepaald protocol of wat dan ook standaard is, betekent niet dat het aan de eisen en wensen van een gebruiker voldoet.
Nee, idd niet als de gebruiker zelf zijn wensen niet kenbaar kan maken, zoals bij ECMA - waar alleen hele grote (soft/hardware-)bedrijven (lijstje) stemrecht kunnen verwerven en tweederde van de bestaande leden (die grote bedrijven dus) het ermee eens moet zijn voordat een nieuw bedrijf stemrecht kan krijgen (Zie artikel 4.2 ECMA lidmaatschap).

Kijk eens naar wie er in de landelijke standaardenorganisaties (zoals NEN) zitten; dat zijn bijna nooit eindgebruikers, degenen die geld kunnen besparen door fatsoenlijke standaarden! Nee, het zijn de bedrijven die de software maken, aanpassen, en er applicaties voor maken - degenen die er geld aan kunnen verdienen als de standaarden niet aan de wensen van de klant voldoen; dan worden zij immers betaald om die extra software / conversie-methoden te laten maken!

Dat is heel erg jammer; standaarden zijn ervoor bedoeld de klant geld te besparen, niet hem extra geld te kosten.

[Reactie gewijzigd door kidde op 21 december 2007 23:04]

beetje naief om te denken dat standaarden altijd vooruitgang opleveren.
Juis tom de standaarden heeen werken kan voor een betere toepassing zorgen. daar heb je dan uiteraard wel een prijs voor te belaten.
standaarden helpen vooruitgang. maar deze moeten uiteraard wel eerst ontwikkeld worden. tot dan is het geen standaard.

(bijna) iedereen geeft na verloop van tijd zijn protocolen vrij voor standardizatie, behalve microsoft natuurlijk....
http://ubiqx.org/cifs/SMB.html

Like NetBIOS, the Server Message Block protocol originated a long time ago at IBM. Microsoft embraced it, extended it, and in 1996 gave it a marketing upgrade by renaming it "CIFS".
want 4-letterige acronymen liggen beter in de markt dan 3-letterige, :+.
Wanneer jij commerciele software verkoopt, kom ik met deze post bij je aankloppen om zo alle technische interne documentatie over je code op te vragen.
In mijn geval mag je de publiekelijke documentatie (hoe je ermee moet babbelen) rustig hebben.
De interne documentatie (hoe het op code-niveau werkt) krijg je niet.
Dat is goed nieuws! Laten we hopen dat Samba nóg beter dan het al doet gaat samenwerken met windows machines in gemengde omgevingen. Ik ben wel benieuwd of windows zélf nu ook echt zich aan deze specificaties houdt, anders heb je er alsnog weinig aan. Bij OOXML is dat bijvoorbeeld niet het geval.
Ik denk dan dat MS een lange rechtszaak te wachten staat met torenhoge boetes. Eerst de verplichte documentatie verkopen en daar dan van af wijken is NOT done.

Het enige wat ik me afvraag is onder welke voorwaarden deze documentatie is verkregen. Is het een 'as-is' snapshot van het huidige protocol of is voor dit bedrag een soort licentie verkregen op de documentatie die ook toekomstige versies bevat?
De documentatie is door de Protocol Freedom Information Foundation (PFIF) aangeschaft voor 10.000 dollar. Vervolgens kunnen Samba ontwikkelaars deze documentatie inzien. Hiervoor moeten ze wel een NDA (non-disclosure agreement tekenen). Er zijn geen restricties op de implementaties van de protocollen die m.b.v. deze documentatie worden gemaakt.

Meer informatie is te lezen op:
http://www.linuxworld.com...to-hand-over-windows.html
De beslissing gaat alleen over de documentatie voor de huidige code. Als MS een nieuw protocol ontwikkelt, valt dat niet letterlijk onder de uitspraak, al zal mevrouw Kroes bijzonder boos worden als MS dat dan niet vrijwillig voor eveneens 10.000 euro aanbiedt.

@hAl: de regels komen anders te liggen als blijkt dat jij je dominante positie in de markt misbruikt met die innovaties. Dan krijg je boetes en plichten die normale bedrijven nooit opgelegd zouden krijgen. Zoals de plicht om je API's te publiceren en gratis octrooilicenties te verlenen voor implementaties die daaraan conformeren.

Als MS nu met SMB+ komt die volledig incompatibel is met de huidige SMB, hebben ze echt een probleem.

[Reactie gewijzigd door Arnoud Engelfriet op 21 december 2007 17:45]

Zo werkt het niet natuurlijk.
Als MS miljoenen uitgeeft aan het ontwikkelen van bepaalde zaken en die patenteerd dan hoeft MS dat niet zonder meer voor 10.000 euro aan te bieden.

Wel zal dan verwacht worden dat ze een vorm van RAND licensing aanbieden.
Als MS miljoenen uitgeeft aan het ontwikkelen
Als ja, maar dat kunnen ze toch niet bewijzen. Aan de technieken waar het om gaat (Active Directory, SMB-protocol) heeft Microsoft namelijk helemaal geen miljoenen uitgegeven, omdat ze al door anderen ontwikkeld zijn en MS ze alleen heeft overgenomen en er alleen een gesloten uitbreiding opmaakte die niet compatibel was met de oude open standaarden (SMB-protocol van IBM, LDAP en X.500 voor AD); daarmee effectief een lock-in creërende.

Hadden ze nu gewoon die oude standaarden gebruikt in hun software en deze niet uitgebreid op een gesloten manier, hadden ze

-Ten eerste die miljoenen kunnen steken in het ontwikkelen van fatsoenlijke veilige software,
-Ten tweede nu geen ruzie met het Commissariaat van mededinging van de EU gehad.
Als MS nu met SMB+ komt die volledig incompatibel is met de huidige SMB, hebben ze echt een probleem.
Nou, dat kan wel eens meevallen. Microsoft roept gewoon dat het een héél nieuw protocol is. En tja, daar hadden we het nog niet over gehad. Kortom: weer zeker een jaar juridisch gehannes, wat met getouwtrek door advocaten makkelijk tot 2 jaar opgetrokken kan worden. En ondertussen zitten de Linux-gebruikers weer met een probleem.

Microsoft heeft Novell in het verleden dit kunstje al eens geflikt, destijds ging het om de samenwerking tussen Windows NT4.0 en de Novell client. Dat werd door een servicepack van Microsoft "per ongeluk" om zeep geholpen... Heeft maanden geduurd voor er een oplossing voor kwam.
Nou, dat kan wel eens meevallen. Microsoft roept gewoon dat het een héél nieuw protocol is. En tja, daar hadden we het nog niet over gehad. Kortom: weer zeker een jaar juridisch gehannes, wat met getouwtrek door advocaten makkelijk tot 2 jaar opgetrokken kan worden.

Het enige "jammere" voor MS is in zo'n situatie dat ze al veroordeeld zijn voor een vergelijkbaar vergrijp. Als dan ook maar iemand een klacht indiend bij de EC en meteen via een kort geding een verkoop stop van alle betrokken producten eist dan is de kans heel groot dat dat nu wel lukt.
In de vorige situatie was het economisch belang veel groter om toch de software te blijven verkopen en was er nog twijfel over de schuldvraag.

Als je in een gestolen auto rijd kan de politie je nog heen zenden de eerste keer met een procesverbaal als je een legitiem verhaal hebt. Word je toch (terecht) veroordeeld en rijd je een paar jaar later weer in een gestolen auto dan zal de politie wat minder snel geloven dat het de auto van een vriend is en dat je echt niet wist dat hij gestolen was.
Is het niet een specificatie van hoe windows server 2003 omgaat met de protocollen etc. M.a.w. als ze zelf ervan afwijken dan is het geen correcte specificatie meer, aangezien deze betrekking heeft op hun softwarepakket... dus dan krijgen ze weer een flinke boete.
Ik denk dan dat MS een lange rechtszaak te wachten staat met torenhoge boetes. Eerst de verplichte documentatie verkopen en daar dan van af wijken is NOT done.
Het jatten van andermans code, en gewoon implementeren, ook niet... MS heeft een historie, dienaangaande - DOS 6, anyone?

[Reactie gewijzigd door The Van op 21 december 2007 14:32]

Wat is er met DOS 6? Ik heb nog wel nostalgische gevoelens bij DOS 6.22, dat waren nog eens tijden ;)

Maar ja, als je het over historie wilt hebben door te herinneren aan oude DOS tijden, dan zou ik nog maar eens zoeken naar hoe MS aan DOS is gekomen destijds. ;)
Je bedoelt Stac dat boos werd om Doublespace? Daar zou code gestolen zijn, zei Stacker, maar uiteindelijk ging de zaak puur over octrooiinbreuk.

(Boze tongen beweren al jaren dat deze verloren zaak voor MS de reden was om zelf octrooien aan te gaan vragen, maar dat terzijde)
Hoe kunnen ze nou ooit afwijken van OOXML als de 'specificatie' niets meer is dan een soort van documentatie van hoe het in MSO2k7 geimplementeerd is, compleet met onzin als "render dit element zoals Word 95" erbij....
Tenzij ze opzettelijk aan het liegen zijn natuurlijk, maar dat zou te snel naar voren komen als suites als OpenOffice.org het ook daadwerkelijk implementeren en MSO blijkt af te wijken van zichzelf.
Het klopt wel dat er 2 "versies" zijn van OOXML: EOOXML, de door ECMA gepubliceerde specificatie, en MSOOXML, het door Microsoft geimplementeerde formaat in Office 2007. In principe is een document dat opgemaakt is in EOOXML altijd compatible met MSOOXML, maar andersom hoeft dat niet zo te zijn.

Maar het klopt inderdaad ook dat hetzelfde het geval is bij ODF, want de bestanden die door OpenOffice.org gegenereerd worden kunnen ook dingen bevatten die niet in de ODF-specificatie zitten. Idem voor bestanden die door KOffice gegenereerd zijn.

Kortom, het is wat kort door de bocht om te stellen dat MS zich niet aan de OOXML-specificaties houdt, maar in de praktijk zul je wel altijd verschillen houden.
Het kan best zijn dat MS Office 2007 enigzins afwijkt van OOXML maar dat zullen voornamelijk bugs zijn en niet eigen keuzes in de specificatie.
De suggestie dat MS een dialect er op na houdt is niet juist en wordt ook niet ondersteund met enigerlei feiten.

Voor minstens 99.9% is wat er uit MS Office komt gewoon pure OOXML.
en dat is niet anders als het geval is met OOo en ODF.
en dat wijkt dus niet af van de concurrentie die precies hetzelfde doet op OO gebeid.
Dus; wat is je punt?

Als je vraagt om betere en completere documentatie van beide formaten dan heb je mijn steun.
Terecht voorbeeld van "render dit element zoals Word 95". Alleen hoe belangrijk is dat element, hoe vaak komt het voor. Juist, bijna nooit ...
Ik ben wel benieuwd of windows zélf nu ook echt zich aan deze specificaties houdt, anders heb je er alsnog weinig aan.
Bij dit soort dingen (protocollen e.d.) moeten ze zeer zeker wel dichtbij de gedocumenteerde versie blijven, anders krijg je incompatibiliteit tussen de verschillende Microsoft producten. Je spreekt hier over honderden mensen die intern in Microsoft met deze documentatie / protocollen werken, die kun je niet zomaar even vertellen om af te wijken van de standaard om de licentiehouders te dwarsbomen.

Daarnaast kunnen de huidige licentiehouders hun geld terugeisen, plus eventueel gemaakte kosten, als ze dat zouden doen.
Geld terugkrijgen is lastig aangezien de standaard gratis door Ecma beschikbaar wordt gesteld en niet door MS.

MS geeft dus geen licenties op de specificatie maar verstrekt hoogstens hun rechten op eventuele benodigde patenten. Dat is dus anders dan bovenstaande situatie mbt de protocollen waarbij MS wel de specificatie controleert en onder licentie verstrekt.

Bij OOXML is er geen dergelijke licentie maar mag je deze specificatie van Ecma vrijelijk en gratis gebruiken (zoalsalle Ecma standaarden)
en is daarnaast door MS een toezegging gedaan aan iedereen dat zij geen patentrechten zullen gebruiken tegen enigerlei benodigde teopassing van hun technologie om Office Open XML te kunnen gebruiken.
Protocol Freedom Information Foundation, Software Freedom Law Center, Free Software Foundation etc. Er zijn bijna nog meer vrije software stichtingen dan linux distributies ;)
Precies, het lijkt alleen om Workgroup te gaan, de Domein omgeving wordt niet nader genoemd.
Ik ben toch wel benieuwd hoeveel daadwerkelijk nuttige gegevens ze uit de documentatie gaan halen. Dwz. in hoeverre zit de huidige implementatie ernaast? Voor hetzelfde geld (letterlijk) hoeven ze alleen meer adhv de documentatie de bestaande implementatie bij te schaven.
Op zich een goed iets, maar dit zet wel de deur wagenwijd open voor allerlei malware of andere dingen die je niet wilt in een server omgeving omdat iedereen de code van Samba in kan zien.
Dus de tijd zal uitwijzen of de EC iets verstandigs heeft gedaan.
Als jouw serveromgeving of software kwetsbaar is wanneer je protocol-informatie of broncode vrijgeeft is er wat ernstig mis en zou ik er ver vandaan blijven... De code van Samba is openbaar, net als die van Linux e.d. Heeft dat nou voor extra malware gezorgd?

[Reactie gewijzigd door JanDM op 21 december 2007 12:09]

Op servers en embedded systemen zijn Linux en Samba echt geen onbekenden hoor. Wat jij hier verdedigt is security through obscurity, en dat is geen security. Wanneer het openen van protocollen of code zorgt voor extra malware of problemen is er iets goed fout. Marktaandeel of niet.

[Reactie gewijzigd door JanDM op 21 december 2007 13:33]

Vrijwel iedere webserver die men rijk is draait iets van een unix/linux smaak met Apache als webserver. Meeste aanvallen vinden dan ook op die machines plaats omdat ze een stuk interessanter zijn aangezien er bij lange na niet zoveel Windows machines met IIS zijn als webserver. Wat zegt marktaandeel dus over security? Eigenlijk helemaal niets.

Met open source software kan iedereen (zowel de goeden als de slechten) de broncode inzien. Een rariteit is misschien snel ingebouwd maar ook weer snel eruit gesloopt (code wordt niet domweg maar even zonder enige controle in de rest van de code gemikt en er zijn zat mensen die broncode napluizen, ook al is het maar omdat ze aan het bughunten zijn). Je wil met je rariteit zoveel mogelijk impact hebben en dat heb je hiermee dus totaal niet. Het hele idee en effect van zo'n rariteit is dan helemaal weg waardoor het dus ook compleet useless is om het in te bouwen.

Het gaat uiteindelijk om hoe de software is ontworpen en niet om het marktaandeel/populariteit/etc van het stuk software!
De meeste (vage) dingen die ik in mijn apache access logs zie gaan over obscure .exe bestanden die gepoogd worden aangeroepen te worden. :P
De meeste aanvallen die ik op mijn server terug zie komen zijn of site specifieke dingen (sql injection ed,) of windows vuln. acties. (om het even of het IIS of apache onder windows is).

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True