A Microsoft publikálta az EU egyezségben szereplő interoperabilitás licencfeltételeit

Microsoft, Windows

Ok, akkor a cím kifejtése, mert ott nem fér ki rendesen. A Microsoft publikálta azokat a licencfeltételeket, amelyek az EU-val való megegyezése után az interoperabilitással kapcsolatosak. A Microsoft ezeket a licenceket "Microsoft Work Group Server Protocol Program License Agreements for Development and Product Distribution"-nek, röviden "WSPP Development Agreements"-nek nevezi. Az Európai Bizottság hivatalosan még nem fogadta el őket. A Groklaw a szokott módján veszi szemügyre a dolgot. Úgy tűnik, hogy a Samba-ra legjobban vonatkozó licenc a "No Patents" licenc. A Red Hat és az SFLC képviselői nem derűlátók, mert szerintük a Microsoft ajánlata nem kompatibilis a GPL-lel, így a Linux OS gyártók nem licencelhetnek ezen licenc(ek) alatt.

( asch v | 2007. 10. 25., cs – 14:32 )

Valaki magyarázza már el lécci(vagy adjon néhány pointert :-)), hogy mire vonatkozik ez a licensz?

A Sambát ilyen licensszel lehetne kihúzni az illegalitás mocsarából, vagy pedig csak akkor vonatkozna, ha a fejlesztők a Microsoft dokumentációját felhasználnák?

Bocs, de az egyik 53. oldalas "licenckét" még nem volt időnk elolvasni :))) Azt hiszem, hogy egy ideig elrágódnak még rajta.

Szerk:

No, azt írják a hozzáértők, hogy a Microsoft 10K euróért adja ki az interoperabilitáshoz szükséges doksikat. A kereskedelmi gyártók vásárolhatnak licencet az interoperabilitási dokumentációban levő Microsoft szabadalmakra. Ennek a szerzői jogdíja a realizált bevétel 0.4%-a. A nem kereskedelmi nyílt forrású projektek viszont ígéretet kaptak a szabadalmak használatára szerzői jogdíj mentesen. Egy probléma van ezzel. Olyan licencet kéne ehhez aláírni, amely nem kompatibilis a GPL-lel. Azaz, a Samba használhatná a szabadalmakat akár ingyen, ha aláírja a licencet. Amivel csak az a baj, hogy nem írhatja alá, mert ütközik a GPL-lel.

A tévedés jogát fenntartom, IANAL, meg az összes többi ilyenkor szokott szöveg....

--
trey @ gépház

( 2Geza | 2007. 10. 25., cs – 15:09 )

Nem igazan ertem, hogy mi szuksege van a linuxnak a Sambara, hiszen vannak remek network-filesystemek, pl nfs. Vagy ha ez nem megfelelo, akkor miert nem irnak zsenialis programozok az SMB-nel tiszer jobb protokolt? Azt sem ertem, hogy van aki hasznalja a Sambat egyatlalan, hiszen minden megcsinalhato linux alatt samba nelkul is...

Ez nem megoldas ha egy meglevo Windowsos haloba szeretnel (minnel kisebb felfordulassal) egy Linuxos szervert/desktopot betolni. Ilyenkor jol jonne ha ez az egy gep tudna alkalmazkodni a tobbihez. (Sok esetben a tobbi gephez kozod sincs, azokhoz nem nyulhatsz, mert mondjuk a Linuxos lapostopodat teszed ra egy ceges halozatra...)

Azért az NFS meg a SMB jogosultságkezelésben elég alapvető eltérések vannak, ami miatt a kettő nem teljesen csereszabatos egymással. A "use-case" eltérő.
Egyébiránt az újabb windows server kiadásokban van NFS szerver is.
Itt igazából nem az SMB protokoll fájlmegosztási funkciója szerintem a fő téma, hanem az Active Directory. Az lenne az igazi nagy szám, ha a Samba domain controller szerepet elláthatna, még nagyobb szám lenne, ha ezt akár vegyesen Windows serverekkel egy realmben. Érthető okokból a Microsoft ettől úgy fél, mint ördög a szenteltvíztől és minden létező módon megpróbálja megakadályozni, hogy a Samba fejlesztők ezt megcsinálják.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Ugyertem a Samban kivul. Az is erdekes, hogy szite naponta jelentenek be uj ueber skalazhato 64 bites btree journaling reliable filesystem terveket, amiket aztan zsenialis programozok ket honap alatt leprogramoznak, nem ertem ugyanakkor miert nincs samba+LDAP alternativa. Miert nem csinalnak egy sajat domain-systemet LDAP-os authentikacioval? Nincs ra igeny? Es akkor kidobhatnak vegre azt a "sotet folt" Sambat a linuxbol...

1) Sambán kívül: Novell Directory Services. Domain, LDAP alapú samba alternatíva. Linuxra is van eDirectory meg Novell Client. Egyéb kérdés? Yó nem nyilt forrású, de ez van.

2) Valószínűleg azért nem, mert 3 megoldás már telíti a piacot, egy 4. már nem tudna akkora teret nyerni, hogy megérje. De én azt ajánlom, hogy próbálkozz meg a dologgal, hiszen ez "szűz" terület, és ha van egy pici szerencséd, akkor hatalmasat kaszálhatsz.
De szerintem azért is van ez így, mert ezek a szoftverek bizonyítottak már sokszor és sok helyen. Mindenki szereti és megbízik benne. Egy új megoldásnak viszont ugyanazt az utat végig kell járnia mint amit ezek a rendszerek végigjártak, és még ekkor sem garantált a siker.

Hasonloan erveltem egy masik forumban a GCC-PCC-vel kapcsolatban: A Gcc egyeduralkodosagat nem fogja megtorni a PCC, a GCC elterjedtsege, megbizhatosaga, illetve ezek okozoja, azaz a beleolt emberi eroforras mennyisege miatt. Ez lenne a helyzet a Sambaval is? Nem akarom azt gondolni, hogy az Open Source fejlesztesi modell nem alkalmas az "ontisztulasra", sem jogilag, sem szakmailag. Pedig igy tunik: Ha egy "niche"-t mar betolt egy-ket szoftver, akkor az Open Source mar nem fog kitermelni tobb versenykepes alternativat, azaz nem kepes onmaga megujitasara. A regi megoldasok az osszes elonyukkel es hatranyukkal egyutt "betokozodik" a rendszerbe. Remelem nincs igazam.

A 2. pontban azt irod, hogy szuz terulet, ugyanakkor azt is, hogy 3-4 megoldas mar kielegiti az igenyeket. Most akkor melyik?

Egyebkent nekem van velemenyem arrol, hogy miert nem lenne sikeres egy nullarol indulo domain+network filesystem rendszer: Nehez jot csinalni ahoz kepest, amennyi elonnyel jarna. Mondhatni a mai posix rendszerekre epitve tul nagy "potencial gatat" kellene atugrani ahoz kepest, hogy csak annyi lenne a nyereseg, hogy "tiszta" megoldasokhoz jussunk.

Szerk:
Lemaradt egy fontos gondolat: Ahoz, hogy ezt a potencialgatat legyozhesse a kozosseg, fontos magasszintu strategiai donteseknek kellene szuletnie, amely alap infrastrukturava emeli az LDAP-ot, az LDAP alapu autentikaciot, es az ilyen authorizacio kepes filesystemeket. Leegyszerusitve "egyeduralkodova" kellene valnia a jelenlegi password/group file alapu azonositas, es az elterjedt filesystemek helyett. Ez persze nem fog bekovetkezni, de hogy ez most a "betokosodas" kovetkezmenye, vagy valami mas (pl _eleg jo_ a mostani megoldas is), nem tudom.

Mindenesetre azert az latszik, hogy az Open Source kornyezetben is nagyon fontos jelenseg, es a kovetktezmenyei is jelentosek az _egyeduralkodova_ valasnak.

Szerintem inkább annak tudható be, hogy a jelenlegi megoldások egyfelől már bizonyítottak, másfelől ismertek a problémái. Az emberek többsége mindig a kisebb ellenállás felé mozdul el, más szóval szeret a kitaposott úton járni. El tudom képzelni, hogy egy 4., 5., sokadik megoldás is életképes lenne - hosszútávon. Azonban le kell győznie egyfajta tehetetlenséget, nagy cégeknek kell mögé állni, és hirdetni minden fórumon, hogy ez yó. Sajnos enélkül a kutya nem fog az adott projekttel foglalkozni, mert egyszerűen nem éri meg a rizikó egy ismeretlen rendszerrel. A Samba, az NDS azért tud nagy lenni, mert nagy cégek állnak mögötte, harcolnak érte, hirdetik és oktatják ezen rendszerek használatát, iszonyú pénzeket ölve bele.

Az LDAP alap infrastruktúrává emelése csak vállalati rendszerek esetében yó ötlet, és általában a normálisabb helyeken LDAP + Kerberos authentikáció van, mert nagyban csak így érdemes csinálni. Hogy ez miért nem lett kvázi-standard, azt sajnos nem tudom, ez a rendszer tervezők egyéni döntéseinek eredménye. Az authorizációnak viszont nem kell az LDAP-ot támogatni, elég a jelenlegi PAM/NSS rendszer LDAP pluginjait feltenni, és minden, ami támogatja a PAM/NSS rendszert, támogatni fogja az LDAP alapú authorizációt is.

"Az emberek többsége mindig a kisebb ellenállás felé mozdul el"

Az egesz engem arra emlekeztet, amikor egy hires sakkozo sakkozott az "internet ellen", amikoris barki kuldhetett lepes javaslatot, es a rendszer statisztikai alapon dontott a bekuldott lepesek alapjan, azaz egyfajta szavazas alapjan dolt el a kovetkzo lepes. Mondanom sem kell, hogy a hires sakkozo siman legyozte az "internetet", azaz az intelligencia nem adodott ossze, sot, egyfajta felso korlattal is jart, ami joval kisebb volt a hires sakkozo kepessegeinel. Mi van, ha ilyen felso korlatokkal terhelt az Open Source fejlesztes is? Nem tudom biztosan, hogy igy van-e, de gyanus nekem.

Nem feltétlen, mert egy gép csak statisztikai alapon tud dönteni, de egy fejlesztő praktikai alapokon is. Egy fejlesztés esetén a fejlesztők intelligenciája összeadódik - legalábbis a fő fejlesztőké igen - mivel ők egymássalis kommunikálnak. Az ő tudásukhoz jön hozzá a külsős támogatók tudása. Egy OpenSource projekt esetében nagyon sok minden dönt a fejlesztés irányáról.

Ha olvastad a Katedrális és a Bazár című művet, tudod, miről beszélek, ha nem, musthave. Interneten magyarul is fent van, google pár találatból hozza.

Másfelől viszont itt nagy rendszerek tervezéséről beszélünk. Nyilván vannak olyan emberek, akik szeretnek a munkájuk során új dolgokat alkalmazni, de ők a kisebbség. Általánosságban elmondható, hogy egy nagyobb rendszer tervezése során nem feltétlen a legeslegújabb technológiákat vonultatjuk fel - kivált, ha azokat nem ismerjük eléggé, nem teszteltük, nincs tapasztalatunk vele. A rendszer menedzselése akkor egyszerű, ha ismert modulokból áll, és nagyrészt akkor válik bonyolulttá, ha az ismeretlen tényezők száma megnő. Márpedig minél bonyolultabb a rendszer későbbi menedzselése, annál inkább megnő az esélye hogy hiba keletkezik, és azt ugyebár nem szeretjük. :) És ugye egy ismeretlen rendszer esetében a hibakeresés és -javítás anyagi és időköltsége nagyobb az ismert rendszerben való hibakeresésnél és -javításnál.
Viszont az ilyen technológiák csak nagy rendszerekben mutatják ki igazáén a foguk fehérét, és innen a kör bezárul. Jórészt ez indokolja azt, hogy idő kell egy új technológia befutásához.
Nézd meg a Samba történetét. Nagyon sokáig alig volt ismert, hiába volt húzószlogen az, hogy Windows-kompatibilis. Csak sokkal-sokkal később kezdték felismerni a hasznosságát (ez mondjuk egybeesett az LDAP integráció meginnoválásával).

Szerintem a rendszer komplexitasa nem attol fugg, hogy mennyire uj (ismeretlen) technologiakat vonultatunk fel benne (ettol inkabb a riziko no meg). A komplexitas sokkal inkabb fugg a logikai absztrakciok mennyisegetol, a retegek szamatol (legalabbis ez jelzeserteku informacio), meg meg jopar dologtol, de a komplexitas temakore onmagaban nem egyszeru kerdes, probald csak meg definialni a fogalmat.

"Viszont az ilyen technológiák csak nagy rendszerekben mutatják ki igazáén a foguk fehérét, és innen a kör bezárul."

Egyetertek, bar lattunk mar arra peldat a MS-nal, hogy az uj technologiakat "lenyomjak a felhasznaloik torkan", es igy "eroszakoljak ki", hogy viszonylag hamar elterjedt (vagy egyeduralkodo) infrastrukturava valljon, amire aztan tovabb lehet epitkezni. Ez egy strategia a MS reszerol, es bar szivjak a fogukat a felhasznalok, nem biztos, hogy csak hatranya van (pl. minden win kliensbe bele van epitve egy mini LDAP szerverszeruseg, amin keresztul menedzselhetoek a lokalis userek. Igy az a user-management felulet, ami hasznalhato a domain adminsztracional, hasznalhato a kliens lokalis userei eseteben is - ezt en architekturalis szempontbol elegansnak tartom).

Szoval ez az "eroltetett" strategia idovel meghozza a gyumolcset, es ennek hozzaallasnak a hianyat en a bazaar modell korlatjanak tekintem -> Rogton itt van egy Open Source korlat, amit mas rendszerek nem feltetlenul utkoznek.

Ebben igazad van, és szerintem az az oka, hogy az OS fejlesztés leginkább olyan irányban haladt, hogy azt fejlesztik leginkább ami trendi vagy ami éppen nagyon fáj. Ami csak kicsit fáj, az évekig is húzódhat (ki nem látott már olyan bugot, ami benne volt a bugzillába 2 évvel ezelőtti nyitással, 1-2 havonta beszállingózó "nekemisezabajom" hozzászólásokkal és a mai napig nincs fixelve)

Persze, kellenek a prioritások, ugyanakkor a legtöbb projekt ma már nem a szigorúan vett bazár modell mentén működik, hanem a katedrális és a bazár modell egyfajta keverékeként. Valahol a kernelnél is ez folyik, csak időnként valaki veszi a fáradságot, hogy átnézze a bugtracker adatbázist, és az ilyen bugok ügyét megsürgesse valamelyik hardcore fejlesztőnél.
Ellenben az 1-2-3-10 emberes projekteknél erre nem mindig van erőforrás.
Vannak azért dicséretes kivételek, de sajnos elég kevés. Nekem pl. a Flock projekt esetén voltak olyan bugjaim, amik egy ideig csak kapták a különböző flageket, hogy akkor majd a következő verzióban fixa lesz, aztán egy szép nap levél jött egy fejlesztőtől, hogy akkor részletezném már ennek és ennek a bugnak természetét. Leírtam, elmondtam hogy ez és ez a bajom, ilyen és ilyen körülmények mellett, erre ő adott egy tanácsot, megpróbáltam, és működött. De amit mondott, az abszolút nem volt triviális.

Szóval nem mindig igaz a bazár modell sem már, de ez a fejlesztők hibája, és nem a modellé.

És szerinted konkrétan a rizikó mitől nő meg? Én nem az egész rendszer komplexitásának növekedéséről beszéltem, hanem csak a menedzsment komplexitásának növekedéséről. Márpedig ha a menedzsment bonyolultsága nő, nő a hibalehetőségek száma -> nő a rizikó.

Az erőltetett stratégiáról meg annyit, hogy persze működőképes, de milyen áron? Nézd már meg, jelenleg hol tart az MS úgy népszerűségben mind felhasználói körben?
Mit gondolsz miért terjednek úgy-annyira a nem MS alapú rendszerek? Nem csak azért mert azok sokkal jobbak, mint az MS-é. Van egy titkuk: Nem akarják az akaratukat a te torkodon lenyomni. Lehet, hogy te szereted, ha mindenféléket lenyomnak a torkodon, de én például nem szeretem. Én szeretem ha magam dönthetek arról, hogy mi kerüljön a gyomromba, és azt én szépen megrághatom és lenyelhetem. Elszakadva ettől a borzalmas hasonlattól: nem mindenki szereti, ha diktálnak neki. Honnan tudod te, hogy nem tévedsz esetleg? Mert te tévedhetetlen vagy? A fejlesztő ha bezárkózik a saját elefántcsonttornyába, az életbe nem jön rá, hogy valahol hibát követett el, mert nem érdekli a felhasználók zsivaja, ő akkor is lenyomja a felhasználók torkán a megoldását, ha azok belezöldülnek is.
Én ezt a megközelítést nemcsak hogy hibásnak tartom, de mélységesen el is ítélem. Nincs joga senkinek sem ahhoz, hogy megmondja másoknak, hogy azoknak mi a yó.

Javíts ki ha tévedek, de ha csak a következő lépésre lehetett szavazni, akkor elég törvényszerű, hogy a hires sakkozó legyőzze az Internetet. Hiszen ő végig tudott vinni egy konzekvens stratégiát, míg az interneten találkozók nem tudnak összebeszélni a stratégiát illetőleg. De talán a megoldás is itt van elásva, az az OS projekt sikeres, ahol rendszeres időközönként vannak megbeszélések nem csak a kódot illetőleg, de a fejlesztési iránnyal kapcsolatban is (melyek a prioritások).

Igen, persze. De ugyanakkor a sakkozó felhasználók nem kommunikáltak sem egymással sem a sakkozóval, és a sakkozónak nem is volt lehetősége minden lépésajánlatot megismerni, és felismerni bennük esetleg a megdöbbentő lehetőségeket.
A fejlesztés ebben különböik a sakkozó történetétől: egy fejlesztő minden lehetőséget lát, és esélye van meglátni azt, hogy a projekt rossz irányba halad. Természetesen a projekt így is lehet sikeres (lsd. Microsoft), csak épp egy bizonyos idő után a felhasználók száma stagnálni fog, bebetonozott felhasználók lesznek.

Másfelől viszont a felhasználókkal is kommunikál egy fejlesztő, és esetleg egy felhasználó rá tudja ébreszteni őt arra, hogy valamikor volt egy hibás elmélete, ami valamiért hibás részeket szült az amúgy teljesen jó egészbe.

A sakk hasonlat eleg jo, erdemes boncolgatni kicsit. Van mondjuk 100 embered, es ok csoportosan hoznak donteseket egy sakk partiban a vilag legjobb sakkozojaval szemben. Hogyan szervezned meg, hogy ez a 100 ember a legjobb sakk teljesitmenyt nyujtsa? Az en szamomra a bazar modell azt jelenti, hogy hagyjuk magara ezt a 100 embert, rovid ido alatt kialakul egyfajta onszervezett struktura. (Ez a struktura magan fogja viseli a tagok szemelyiseg jegyeit, kepessegeit.) A nagy kerdes az, hogy ez a struktura konvergalni fog-e az optimalis szervezettseghez? Esetleg milyen tavol all az idealis szervezodestol (azaz az elmeleti maximalis teljesitmenytol), es hogyan lehetne javitani rajta?

Szerintem a sakk szabályai túl szűk időkorlátot állítanak a fejlődés tanulmányozásához, illetve maga az, hogy szabályok közé van a dolog kényszerítve, más fejlődési ábrát fog mutatni, hiszen a fejlesztők nincsenek ennyire kötött szabályokhoz kötve. Mondhatja pl. a fejlesztő (a sak hasonlatnál maradva egy picit), hogy rossz ötlet volt ezt a lépést a sakk szabályai szerint tenni, ezt a lépést tegyük meg a lóval átlósan, mert akkor mattot lehet adni a következő lépésben. Ezt a sakkban nem teheted meg. Ez egy nagyon kifacsart helyzet, de arra akartam rávilágítani, hogy egy fejlesztő képes minden addigi munkáját félredobni, és teljesen más szabályok szerint létrehozni a programot - egyetlen ember ötletéből megvilágosodván.

A sakkot azert tartom jo hasonlatnak, mert benne strategiakat lehet/kell felallitani tobb szinten is, "alacsony" szinten, lokalisan, par babu kontextusaban, illetve "magasabbb" szinten, azaz party szinten is, pl hogy neha bealdozom a lokalis strategiam egy nagyobb perspektivaju cel elerese erdekeben. (Pl. bealdozom a ket bastyam egy trukkos mattert.)

Szvsz pontosan ez van a szoftverfejlesztesben is. A kulonbozo "absztrakcios szintu" strategiak egyuttese hatarozza meg a szoftver, vagy a szoftver rendszer sikeret. Ahoz, hogy jo szoftvert keszits, a teljes strategia skalat minnel teljesebben kellene lefognod. Nagyon osszetett problema ez tobb okbol is, peladul mar csak azert is, mert az egyes eltero szintu strategiak ervenyessegi kore elter, gyakran ellentmondhatnak egymasnak, az egyik strategia "felulirhatja" a masikat.

Namost a bazaar modell, amelyik kizarolag az onszervezodesre epit, jellegebol kovetkezoen nem is fokuszal a strategia skala magasabb szintjeire (*ez az elmelet*). Nincsen lehetosege erre, az onszervezodes nem jut el a szervezettseg ilyen szintu fokara (a magasabb szintu szervezettsegi fok ugynis szukseges feltetel, ezt nem haghatod at, nincs ilyen, hogy "atlosan lepek a loval"). Nem azt mondom, hogy ez mindig igy van, csak annyit, hogy altalaban igy van.

Tehat en azt mondom, hogy egy softverfejlesztoi kozosseg szervezodottsegi szintje alapvetoen meghatarozza a kozosseg eredmenyeit. Peldaul az a megfigyeles, hogy egy-egy opensource eszkoz egyeduralkodova valasa nem egy "tudatos" dontes eredemenye (hanem altalaban veletlenul dol el), illetve hogy a kialakult egyeduralkodo eszkoz gyakorlatilag kimozditahtatlanul bebetonozodik, alatamasztja azt az nezetem, hogy az OpenSource fejlesztesek szervezodesi szintje alacsony, magasabb szintu strategiak nincsenek, vagy csak nagyon keves van. (*ez pedig az elmelet alatamasztasa megfigyelesekkel*)

Ez akkor lenne igaz, ha nem lenne core fejleszőgárda, aki azért a főbb irányvonalakat képviselik. Természetesen bele kell kalkulálni, hogy ők is módosíthatják az elképzeléseket, de a magasabb szintű stratégiát a core fejlesztők képviselik, ők mondják meg, hogy akkor mégis mi kerül be a projektbe, és mi az, ami nem. Nekik kell meghatározni azokat a célokat, melyek mentén a projekt haladni fog. Nézd meg például a mostanság kezdődő Ubuntu konferenciát, ahol a következő LTS kiadás főbb irányairól döntenek majd a projekt core fejlesztői/package maintainerei. És az Ubuntu nyílt forrású.

> Peldaul az a megfigyeles, hogy egy-egy opensource eszkoz egyeduralkodova valasa nem egy "tudatos" dontes eredemenye (hanem altalaban veletlenul dol el)

Alapvetően valóban nem egy vagy több ember tudatos döntése, hanem általában a használat során dől el. De az, hogy ez véletlen lenne, azzal vitatkoznék. Igenis, meghatározhatók olyan paraméterek, amely alapján egy projekt nagyon nagy százalékos eséllyel egyeduralkodó lesz a piacon. Ilyen például a kompatibilitás, a menedzselhetőség, a stabilitás, az integrálhatóság. Nem célom, hogy ezt ismertessem, de ha végignézed csak pár területen az egyeduralkodó szoftvereket, magad is rájöhetsz arra, hogy ezek nem véletlen paraméterek.
Továbbmegyek: Ez még csak nem is az OpenSource projektek sajátja, pontosan ugyanez játszódik le a zárt forrású, pénzért kapható szoftverek körében is. Nincs különbség tehát e téren. És ha végiggondolod, arra is rájössz hogy miért: pontosan a paraméterek általánossága miatt. Hiszen egy zárt projekt ugyanúgy lehet yól integrálható, könnyen menedzselhető, nagy kompatibilitású mint egy nyílt forrású projekt.

Totalis opensource fejlesztesi kapacitas szvsz. felulmul mindent.
Hatalmas megosztottsag, ezert tobbszazszor feltalaljak melegvizet.
pl. rengeteg disztro, kulonbozo celok.

Az LDAP kozel sem olyan elterjedt, es jelenlegi felhasznalasi tippek amiket lattam kozel sem univerzalisak.
Ahogy hasznaljak auth -ra siman megfelelne egy NIS,mysql,pgsql ... stb. auth is.
Ezekre az eszkozokre jonnek toolok, rendszreint nem univerzalisak, kis progik amik az adott felhasznalo(rendszergazda) adott problemajat megoldja.
(Sot lehet, hogy egy uj eszkoz kene, vagy egy kevesse ismert megoldas jobb lenne, de 200 kombonensed epit ra, akkor nem biztos, hogy lecsereled, amikor 400 workaroundod van a jelenleg rendszeredhez, hogy az idealishoz hasonlitson, LDAP-ot mezei userek/programozok nem hasznaljak, pedig ok hajlamosabbak lennenk inkabb valtoztatni, mint nagy cegek,de nem is talalkoznak vele)

Az onszervezodes feltetle, egy kenyszer (pl. bearamlo energai) elerjen egy bizonyos szintet, ez nincs meg gyakran.

A masik, ha valami baromi ujjat szeretnel beletenni a rendszerbe, megszunik a komtibilitas a binary only softwerekkel.
Egyesek a mostani valtasokat is tulsagosan gyorsnak tartjak, es visszafele kompatibilitast hianyoljak.
pl. -Wl,hash-style=gnu -mregparm=3 -msseregparm forgatott rendszer jobb lesz, de nem lesz kompatibilis a regi binarisokkal.
libc beli torteneseket szabvanyok irjak elo, ill. par eszkoz epit olyan dologra amit jobb lenne megvaltoztatni.

Nehogy azt higgye valaki ezeket nem lepik meg, ott ahol nagyon muszaly megteszik, de neha nem terjed el a fenti okok miatt.


Az LDAP kozel sem olyan elterjedt, es jelenlegi felhasznalasi tippek amiket lattam kozel sem univerzalisak.
Ahogy hasznaljak auth -ra siman megfelelne egy NIS,mysql,pgsql ... stb. auth is.

Azért, mert sok ember nem látja meg az LDAP-ban rejlő lehetőségeket, én nem mondanám hogy annyira rossz dolog.
Azonfelül a *SQL alapú authentikáció sok felhasználó esetén drasztikus erőforrásigényeket támaszt az LDAP-hoz képest, a NIS pedig manapság már igencsak túlhaladott technológia, új tervezésű rendszerbe nem tennék NIS-t.

A másik cél amire szerintem helytelenül használják az SQL-t a levelezés virtual hostingja. Egy sok felhasználós/sok domaines rendszer esetében ez megint csak erőforrásigényes, ha az authentikációt is hozzávessük, akkor szerintem akkora költséget kapunk, ami ennek a területnek nem jár. Tény és való, az SQL alapú rendszerek viszonylag könnyen menedzselhetők - de ebben ki is merül minden előnyük.

Szóval az LDAP-ot igenis yól használják fel, csak azt nem ismerik fel, hogy egy LDAP alapú rendszerben mekkora lehetőségek rejlenek.

Hömmm... LDAP meg egyáltalán nem erőforrásigényes, és mindenféle üzleti struktúra simán lemodellezhető benne (Alapvetően fa struktúrájú hierarchia, szükséges keresztkapcsolatokkal, illetve jogosultságonként meghatározott öröklődéssel (nem öröklődik, felfelé, illetve lefelé terjed a fán)). Mindezt könnyen, rugalmasan.

Torvenyszeruen igen, ha mind a szaz ember gyozelemre torekszik es igyekszik apait/anyait beleadni. (De az barmilyen jateknal / feladatnal igy van)
Most mondhatok par szervezti felepitest, de minek.

"Esetleg milyen tavol all az idealis szervezodestol (azaz az elmeleti maximalis teljesitmenytol), es hogyan lehetne javitani rajta?"
A leheto legkozelebb, es az csoport maga keresi ennek modjat. (1-(1/t) szerure illeszkedo fuggveny, +zajjal )

"ha mind a szaz ember gyozelemre torekszik es igyekszik apait/anyait beleadni."

Erdekes, vitara erdemes kijelentes. Annyit azert csak elismersz, hogy nagysagrendekkel nagyobb az eselye egy magasabb szintu szervezodesnek akkor, ha ez a 100 ember egy szobaba van osszezarva, annal, mintha tobb foldreszen, kizarolag emailekkel kommunikalnanak egymassal? (Itt a kommunikacio fontossagat szerettem volna kiemelni, mint kulcsfontossagu elem a belso folyamatok gyorsabb es hatekonyabba valasahoz. Azaz szvsz egy elosztott projekt eleve hendikeppel indul egy nem elosztottal szemben, kifejezetten akkor, ha onszervezodo kontextusban vizsgaljuk.)

"Az onszervezodes feltetle, egy kenyszer (pl. bearamlo energai) elerjen egy bizonyos szintet"

Abszolut! Vegre valaki, aki ervel ezzel! En ilyen kenyszerito (inkabb motivalo) eronek erzem a penzt peldaul, az open fejleszteseknel pedig a lelkesedest(?), szakmai kihivasokat(?), szakmai sovinizmust(?), esetleg az ideologiai onigazolast(?). Egyet ertek azzal is, hogy az Open Source kozosseg oriasi mennyisegu emberi eroforrassal rendelkezik, ugyanakkor szerintem ennek nagy reszet "elfustolik", "eldisszipaljak" a semmibe, a szervezetlenseg okan.

Szeretnem viszont tisztabban latni, hogy miert gondolod, hogy ha a 100 ember megfeleloen all a feladathoz, akkor garantaltan kozelit az onszervezodes foka/strukturaja a problema megoldasahoz optimalis (mar ha van ilyen) szervezodeshez. Miert gondolod azt, hogy az optimalishoz kozelito uton nem ragad be a rendszer egy lokalis minimumba. Ha erre valaszolsz, akkor mondok majd egy genetikai algoritmusos hasonlatot, csak nem akarom feleslegesen koptatni a billentyuzetet.

En az Open Source fejlesztesi modell onszervezo folyamatai magasabb szintuve valasa elleneben a kovetkezo gatakat latom:
- Kommunikacio. Kiemelten fontos, hiszen ezen az uton alakul ki a belso feleadatmegosztas, a belso folyamatok minosege. A valosagra vetitve itt nem csak az egyes teamek belso kommunikaciojarol van szo, hanem a teamvezetok, architektek egymassal valo kommunikaciojarol is. Tehat en itt nem csak azt latom problemanak, hogy foleg emailen megy a komminukacio, hanem, hogy nincs meg az igeny bizonyos vezetoi szint felett az egymassal valo kommunikaciora.
- A belso folyamatok parhuzamosan alakulnak ki a megoldando feladat megoldasaval egyutt. Ez azert rossz, mert a fejlesztes elejen az adhoc, nem letisztult (esetleg hibas) folyamatok/dontesek ranyomjak a belyeguket a fejlesztesre. (A sakkos peldaval: A csapat a party elejen szuboptimalis donteseket hoz, amelyeket aztan mar nem lehet visszacsinalni)
- Onszervezo modon nem alakul ki az onszervezodest kontrollalo alcsoport (pl. QM). (Mig egy penz alapu fejlesztesnel mar viszonylag alacsony meretnel is szukseges a quality management (30-50 fo).

Probaltma objektiven, es nagyon nem kerek. Itt van pl egy reszlete (leforditva):

"Az ismerősöm szerint az erőforrások megszerzése gyakran védekezés. Ha egyszer rendelkezésre állnak az emberek, a gépek és az irodahelyiség, akkor ezeket meg kell védeni az ugyanezekért az erőforrásokért versengő társvezetőktől és a magas beosztású vezetőktől, akik a korlátozott erőforrásokat lehető leghatékonyabban próbálják elosztani."

Forras: http://www.hwsw.hu/oldal.php3?cikkid=848&oldal=12

Ez milyen komolytan erv. Tele van ilyenekkel, nem all ossze. Kalandozik ossze vissza, allitasait megalapozatlanul hagyja, az egesznek ilyen hurraoptimista hangulata van.

"Mert nem lehetseges."

Ertem. Ne haragudj meg ram, de ezt en kevesnek tartom. Jol latom, hogy fizikus hallgato vagy? Szerintem te pontosan tudod, hogy egy osszetett, nem statikus rendszerrol nem mondhatunk ilyen egyszeru kijelenteseket.

Itt van peldaul az a megfigyelesem, hogy egy egyeduralkodova valo Open Source software kvazi kimozdithatatlanul ott ragad az osszes elonyevel es hatranyaval egyutt. Konkrean ez a megfigyeles engem az evoluciora emlekeztet: Peldaul volt az elolenyek egy csoportja, amely kulso (kitin)vazat fejlesztett ki, ilyenek peldaul ma a rovarok. A kulso vaz rengeteg elonnyel jar, ugyanakkor peldaul bekorlatozza a leny meretet, azaz pl. emberi intelligenciaju rovar egyed fizikai okok miatt nem lehetseges. Marpedig a rovarok eselye arra, hogy belso vazat novesszenek minimalis: A "dontes" annak idejen megszuletett, a kulso vaz modszere a rovaroknal bebetonozodott, sok egyeb rendszer epul ra, megbolygatni nem lehet. (Ettol persze meg sikeres elolenyek, de a korlataik nyilvanvaloak.)

Remelem ez mar egy szerencsesebb hasonlat. Tehat szeretnem, ha vilagossa valna a mondanivalom: Szeretnem konkretabban latni, hogy az Open Source miert nem kepvisel egy olyan "evolucios torzset", ahol a korabbi, kvazi veletlenul kialakult struktura (Linux kernel, GCC, X11, Gnome-KDE, SQL szerverek, linux disztribuciok, firefox, posix, etc.) nem korlatozzak be egy jovobeli, hipotetikusan fontos szempont szerint az egesz rendszer fejlodeset.

- Evolutcioban az egyéné a főszerep, önszervezodő folyamtoknál meg a csoporté, és nem halnak meg, ha rosszul jatsznak, (tanulhatnak a hibaikbol is). (Egymással konkeráló projekteknél inkább érvényesek az evolutciós játékszabályok (hogy még bonyultabb legyen, emberek igazolhatnák át, vagy akár több projektben is részt vesznek))

- Én nem a fejlesztők egymással való kommunikálásában látom a hibát, sokkal inkább a felhasználók és fejlesztők között. A legkritikusabb elem a problémák/igények nincsenek súlyozzva, a felhasználók igényei/gyakoriság szerint . Pl. nem kerül elő, hogy egy adott bugot csak 1 ember tud reprodukálni, vagy mindenki. Nem derül ki, hogy XY megváltoztátását YX re 1 ember gondolja jogosnak vagy 5 millió, a jelenlegi szabályok miatt, nem szabad ismételni ilyen igényeket.

- Igen , de az idővel letisztul.

-QM csoport kialkul(hat) így is, ha csoport számára fontos a csoporton kivüli személyek igényinek kielégitése is. Mert ugyebár saját igény szüli gyakorta az OpenSource projekteket.
(Ha tesztelésekre gondoltál, az gyakran "Sok szem között minden hiba jelentéktelen" elv dominál, és műkodik is egy-két anyázás közepedte , gyakori, hogy a fejlesztők lemérik, hogy mekkora joságot raknak hozzá)

Ez a sakkos hasonlat azt hiszem nem szerencsés a témában. Egy naygmester ellen gyakorlatilag 0 az esélye 100 gyenge sakkozónak a nyerésre teszőleges szervezettség esetén is. Érdemes elolvasni Mérő László Észjárások című könyvét. A "nagymesterré" váláshoz kb. 10 évnyi megfeszített tanulás és gyakorlás szükséges a sakkban, de valószínűleg a zenében és a matematikában is. És a sakkozó esetén ez kb. több tízezer olyan séma ismeretét jelenti, amelyek nagy részét szavakkal el sem tudja mondani.
Ezt a tudást 100 gyenge sakkozó nem tudom elképzelni, hogy _bármiféle_ szervezettséggel helyettesíteni tudná egy sakkjátszma alatt.

Igaz nem irtam le explicite, de nem tuztem ki celul, hogy legyozzenek egy nagymestert, ez a kitetel (azaz, hogy nagymesterrel jatszanak) csak azert kerult be, hogy a feladat _eleg_ nehez legyen (mint a szoftverfejlesztes altalaban). Szoval a sakk itt mint nehez problema szerepelt, ugy, hogy nezzuk meg mit produkal egy onszervezodo rendszer illetve egy erosen kontrollalt szervezodes egy nehez problemaval szemben.

A sakk itt azért nem jó példa, mert önszerveződően sem lesznek sokkal erősebbek a "társalkodók" (régen tényleg voltak ilyen meccsek). Az eredmény ugyanis csak 0, 1/2 és 1 lehet, és sosem tudják egy 0 eredmény után, hogy miért vesztettek, ellentétben egy szoftver folyamatos fejlődésével.

Attól, hogy erőlszakolod a szabályokat, még nem lesz a példa a való életre illeszkedő.

A szoftverfejlesztés sokkal kevésbé kötött a sakknál. Pl. én kevesebb tudással is létre hozhatok egy olyan szoftvert, amit egy nálam nagyobb tudású nem tud már, mert neki ez a probléma nem kihívás, ugyanakkor fel tudja használni a projektemet az ő egyik nagyobb projektjében, mert eredeti módon közelítettem meg a problémát.

A másik, hogy én kevesebb tudással is tudhatok valamiben jobb programot írni egy nagyobb tudású programozónál.

Tehát itt a sakk sok szabálya egyáltalán nem érvényesül. A világ nem egy sakkjátszma alapján működik, a szoftverfejlesztés meg pláne nem. Az általad úgy-annyira megvetett Katedrális és Bazár című műben is sok olyan esemény van a fetchmail fejlesztése során, ami abszolút nem illik bele a sakkjátszma-elméletedbe.

( anr | 2007. 10. 25., cs – 15:47 )

na ha ez ikompatibilis, akkor ujabb idohuzas. az eu elutasitja es ujra birsagol, nade ez uj eljaras

a M$ az opensource-el kapcsolatban kizarolag atbaszas, megsemmisites, kivegzes, legyilkolas, es sok FUDFUDFUD dolgot csinal.
van aki masra szamitott?

nembaj, kap majd meg 1milliard$ buntetest az EU-tol. ott sem jogi analfabetak ulnek.

--
Live free, or I f'ing kill you.

Röhögve nem fogja kifizetni, de csak azért nem, mert bízik abban hogy ezt az összeget rövid időn belül úgyis beszedi máshonnan. Azonban ha az EU nemcsak pénzbüntetéssel, hanem szankciókkal sújtaná az MS-t (nem hozhat forgalomba bizonyos termékeket, stb), az sokkal komolyabb érvágás lenne MS-nek. Kérdés, ezt a jelen helyzetben EU megteheti-e...

Szerintem ha akarná, megtehetné. Itt minden attól függ, az EU mennyire veszi komolyan az MS szankcionálását. Nyilván, persze érvágás egymrd dollár, de azért elég nagy piaca van jelenleg a MS-nak, hogy önmagában a büntetés ne legyen elég arra, hogy komolyabb mértékű gondolkodásra késztesse őt.
Más kérdés azonban a MS szerepe az európai gazdaság minden szegmensében, hiszen a kormányzati rendszerek jó része MS termék vagy Windows alapú, nagyon kevés helyen van még Linux, és ez a kör túl lassan bővül. A gond inkább ekörül lesz, azaz hogy az EU képes-e bizonyos értelemben a saját nyakához szorítani a pengét? Hiszen nyilván, ha az MS-sel szállnak harcba, az kihathat az ügyfélkapcsolatra is.

Azért nem fogja megtenni az EU, mert ez sajnos sokkal inkább a pénzfejésre megy, mint arra, hogy valami kézzel fogható eredményt érjenek el. A tiltás az EU-nak nem okozna közvetlen bevételt, legalábbis nem rövidtávon, márpedig kis hazánkhoz hasonlóan ott is elsődlegesen költségvetés rövidtávú foltozgatásra kell a zsé.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

( kienzan | 2007. 10. 25., cs – 21:11 )

Tiszteletem!

Ertem en, hogy nem kompatibilis, de konkretan miert is nem? Valaki tudna egy reszletesebb leirast vagy valami?

( ezqgtouvszfgc | 2007. 10. 25., cs – 21:48 )

Ficsor:

21 CÁFOLAT AZ IRÁNYELVJAVASLATRÓL
1. Az irányelvjavaslat (IJ) NEM követi az amerikai példát, hanem
ebben gátolná meg az ESZH-t; az IJ célja a status quo megőrzése.
2. Az IJ NEM az ESZH 30 000 „jogszerűtlen” szabadalomengedélyező
döntésének utólagos „legalizálását” szolgálja.
3. Az ESZH ugyanis NEM folytat az ESZE-vel ellentétes
joggyakorlatot a számítógéppel megvalósított találmányok kapcsán.
4. Európában NEM adtak szabadalmat (de máshol sem) a „kettős
kattintásra”, a „webáruházra”, az „elektronikus bevásárlókosárra”
vagy a hitelkártyával való fizetésre.
5. Az IJ NEM vezeti be a szoftver szabadalmazhatóságát; azt éppen
kizárja, ezért az IJ NEM „szoftverszabadalmi” tervezet.
[...]
7. Az IJ szövege NEM pontatlan, NEM hagy értelmezési bizonytalanságot és
NEM nyit „kiskapukat” a szoftver szabadalmazhatósága felé

Ezért tkp nem is lehet szoftverszabadalmi megállapodás a Microsofttal...

( bastya_elvtars | 2007. 10. 25., cs – 23:06 )

Egyébként majd most jön mindenki, hogy "az enyimével sem kompatibilis, tessék átírni"?
It doesn't matter if you like my song as long as you can hear me sing

( pepo v | 2007. 10. 26., p – 09:19 )

Lehet, hogy tévedek, de a smb egy protokol, ami Unix rendszeren egy Samba nevű prg. (is) tud kezelni. A protokollra is vonatkozn(án)ak MS licenszek?

Pedig nekem úgy rémlik, hogy az SMB az IBM és a Microsoft közös szüleménye még abból az időkből amikor nagy volt a barátság.
Az hogy RFC-t is írtak róla az meg nem igen jelent semmit a felhasználói jog szempontjából. Lehet sőt valószínűleg tartom, hogy akár szabadalom is védi.

( hrgy84 | 2007. 10. 31., sze – 10:58 )

Marpedig a rovarok eselye arra, hogy belso vazat novesszenek minimalis: A "dontes" annak idejen megszuletett, a kulso vaz modszere a rovaroknal bebetonozodott ...

Először is, ez a hasonlat tényleg yó, már amennyiben ismerjük a biológia törvényeit.

A rovarok kitinpáncélja nem egy "döntés" eredménye, hanem az akklimatizációé. Azaz a kitinpáncél azért fejlődött ki, mert szükséges volt egy védelmi rendszer a külső behatások ellen (időjárás, ragadozók), és ez volt a legkissebb ellenállás módszerének leginkább megfelelő megoldás.

Vetítsük ezt vissza az OpenSource közösségre:

A ma kialakult "egyeduralmi rendszer" nem valódi tudatos döntés eredménye, hanem a legkisebb ellenállás törvénye alakította ezt ki. Valamilyen szinten ez persze tudatos, de a rendszer egészére nézve nem mondhatjuk, hogy ez tudatos lenne.
Nyilvánvalóan azért alakult ki így ez a rendszer, ezen elemekkel, mert ezen elemek valamilyen oknál fogva előnyösek voltak - akkor és ott. Mivel előnyeiket ezek a rendszerek el nem veszítették (a rovarok páncélja sem gyengült számottevően az idők során), így ezek mindmáig kedvelt infrastrukturális alapok. Ismerjük erényeiket és hibájukat egyaránt - itt jön képbe a legkisebb ellenállás elve.
Nyilván, mivel az ember alapvetően lusta faj, ami egyszer sikeres volt, azt igyekszik másutt is hasznosítani - hiszen már egyszer bizonyított! Természetesen kialakultak másféle megoldások is (a hüllők például nem kitinpáncéllal próbálkoztak), ami a maguk területén sikeresek voltak, de vagy valamely hibájuk miatt nem terjedtek el, vagy hiányzott belőlük egy vagy több olyan előny, mellyel az "egyeduralkodó" szoftverek már rendelkeztek (például a rovarok nem vették át a hüllők kemény bőrpáncélját, mert az méretükhöz képest nehéz volt, és jó pár strukturális változást igényelt volna).

Természetesen a mai rendszerek bizonyos szempontból bebetonozottnak tűnnek, ugyanakkor nem látom lehetetlennek azt, hogy ha jönne egy újabb elem, mely rendelkezik a jelenlegi megoldás összes előnyével, és ráadásul még valami újat is fel tud mutatni, akkor az lenne a befutó.

Csakhogy: A jelenlegi megoldások elég hosszú idő alatt alakultak ki, sokféle igény formálta őket olyanná, ahogy azokat ma ismerjük. Nulláról egy teljesen új rendszert létrehozni ugyanilyen tulajdonságokkal összehasonlíthatatlanul nagyobb erőfeszítést kíván, mint a jelenlegi rendszerek megértése és továbbfejlesztése.
Úgy a nyílt mint a zárt forrású közösségnek azonban van egy bizonyos tehetetlensége. Mint ahogy például a Sun se jön ki egy új LDAP megoldással, a nyílt forrású közösség sem fog kijönni vele, éspedig azért nem, mert egy ilyen megoldás létrehozása nagyobb befektetést kíván (anyagi illetve munka), mint a jelenlegi megoldások foltozása. Ezzel együtt nincs is értelme, hiszen ma már nincs olyan valós igény, amit a jelenlegi megoldások le ne fednének.
Annak idején volt evolúció, mert nagyon kevés szoftver volt, és azok nem voltak épp a legjobb minőségűek, viszont a javításuk lassan zajlott. Ma már nincs meg ez a hajtóerő, mert ma már minden igény ki van elégítve, ám ha mégis új igény merülne fel, azt sokkal egyszerűbb a jelenlegi megoldásokba beleintegrálni, mint ezért új megoldást kifejleszteni.

Természetesen a forráskód egy idő után átláthatatlanná válik a külső szemlélő számára, de ez a belső (core) fejlesztőket ez egyáltalán nem zavarja, ők átlátják a kódot, és aki rászánja magát, több-kevesebb idő után szintén átlátja a kódot. Nyilván vannak kódtisztítási lépések (ahogy a linux kernelnél is nemrégiben), ám ez inkább afféle kozmetika, valós igény nincs rá.