Nem kell a MIT programba az ingyen OS X

Látom jó helyen kérdezted ki szokott belnyúlni forrásba :)

Amúgy tényleg nem jellemző hogy otthon belenyúlkál az ember.

DE az alapitvány szempontjából:

Ha megvan a kód nem kell könyörögni / esetleg x*10000 USD-t fizetni egy gyors hibajavitásért, új featureért, hanem lehet találni olyan embert aki olcsón -akár ingyen, vagy egy laptopért :) - megoldja.

Dehát nyílt forrású. Letölthető a kernele. ;)

rossza a cikk cime. igy jobb lenne:

Még ingyen sem kell az MIT-nek a Mac OS X

:))

Vagy inkább: MIT akartok ti itt ezzel az OS X-el?

vagy "MIT nekunk Mac OS"

Az a másik portál.... :)

Az a másik portál.... :)

Hülye mighty mouse. :))

Én azért örülök annak hogy végre valahára nem csak a pénz számít hanem az elvek is érnek valamit a döntéshozók szemében.

miert a szabad/ingyenes, es az ingyenes kozott penzugyileg melyik a jobb?

:)

Allitsuk meg az elindexesedest!... meg idoben...

Természetesen a szabad/ingyenes, mert ebben azt és akkor írsz át amikor akarsz. Ha fizetőssé válna vagy bezárnák a kódot akkor meg lehet forkolni.

A "sima" ingyenes meg később lehet fizetős, vagy a támogatása lehet az stb. (nevezhetjük beetetésnek)

Szóval totál paranoia esetén jobb a szabad+ingyenes...

"Természetesen a szabad/ingyenes, mert ebben azt és akkor írsz át amikor akarsz"

Mostanában a fenti mondat az egyik kulcs érv ebben a témában. Azért kivéncsi lennék, tényleg ennyien szokták átírni az open-source cuccokat maguknak? Most nem 1-2 soros php-s cuccokról van szó, hanem mondjuk nagyobb dolgokról. (Kernel, myaql forrás, Postfix, qmail stb)

Engem speciel a legtöbb esetben annyira nem zavar, ha nem kapok forrást az ingyenes cucc mellé, ha garantálják, hogy a későbbiekben is ingyenes marad.

Se időm, se energiám - a tudásomról nem is beszélve -

hogy komplexebb programok átírogatásával foglalkozzak.

Másoknak mi a tapasztalata/gyakorlata ebben a témában?

Most ha lehet, ne menjünk át flame-be, tényleg érdekel, hogy ki mennyire szokta a "forráskód adta lehetőségeket" kihasználni.

Saját, nem túl extenzív tapasztalataim:

1. amikor nem működött rendesen a lirc a laptopomon akkor kb. fél óra munkával sikerült megtalálni a (nem is annyira triviális) hibát a forráskódban, a javítása már triviális volt.

Hasonló ötperces/félórás javításokat szinte hetente elkövet az ember, apt-get source, kijavít, dpkg-buildpackage, dpkg -i és készen is van.

Persze lehet küldeni bugreportot, de egyrészt az időbe telik, másrészt nem biztos hogy a te régi verziódat is javítják, upgrade további macera, etc.

2. amikor programokat írok C-ben (igen, muszáj C-ben írni), akkor nem jön rosszul ha meg tudom nézni "profi" matematikai programok forráskódját, pl. hogy hogyan is kell state of art normális eloszlású véletlenszámot generálni manapság. Sőt, akár át is tudom venni a kódot ha kell, többször megtörtént.

3. sokszor futtatok számítógépes szimulációkat a Condor rendszerben, ehhez viszont az kell hogy legalább újra lehessen linkelni a programokat statikusan egy módosított libc-vel. (Néha kicsit kell gyúrni a forráskódot is, általában csak triviális változtatásokat igényel.) Matlab, Mathematica tehát kilőve, nem baj, octave, scilab etc. vígan működik.

4. egy időben kénytelen voltam OSX-et használni, valami régi verziót egy G3-on. Az még nem is zavart hogy lassú volt, úgyis csak terminálnak használtam, annak jó lett volna, de az F12 (asszem) megnyomására mindig az arcomba lökte a cd tálcát, és ez a remek gomb pont a backspace fölött volt, attól 0mm-re a remek mac billentyűzeten. Support azt mondta hogy hát ehhez sajna frissíteni kell az operációs rendszert, különben nem tudom kikapcsolni (ez elég érdekes volt, mert ugyanolyan másik mac nem csinálta). Persze a frissítés a következő verzió megvásárlását jelentette volna ebben az esetben....

Ha lett volna source akkor azt gondolom nem tartott volna sokáig megtalálni benne hogy hol kell kikapcsolni...

Szóval az én személyes tapasztalatom az hogy igenis jól jön a forráskód. Egy ideális világban, ahol a vendor azonnal javítja a hibát és 7/24 hívható ott talán nem így lenne, mint ahogy elfogadom hogy bizonyos alkalmazásoknál nem is így van, pl. nagy adatbázis üzemeltetése az egy másik eset.

off: a veletlenszamos reszt honnet szeded? Monte-carlo szimulaciot irok, es kellene valami sophisticated modszer, most a NumRec-bol garazdalkodom.

A GNU R nevű szoftverből. http://www.r-project.org

apt-get source r-base

2005-11-16 09:35 -n:
> "Természetesen a szabad/ingyenes, mert ebben azt és akkor írsz át amikor
> akarsz"
>
> Mostanában a fenti mondat az egyik kulcs érv ebben a témában. Azért
> kivéncsi lennék, tényleg ennyien szokták átírni az open-source cuccokat
> maguknak? Most nem 1-2 soros php-s cuccokról van szó, hanem mondjuk nagyobb
> dolgokról. (Kernel, myaql forrás, Postfix, qmail stb)
>
> Engem speciel a legtöbb esetben annyira nem zavar, ha nem kapok forrást az
> ingyenes cucc mellé, ha garantálják, hogy a későbbiekben is ingyenes marad.

Engem sem elsosorban az ingyenesseg erdekel, hanem az a tudat, hogy
ezert a kesobbiekben sem kell nagy valoszinuseggel fizetnem es barmikor
valtoztathatok rajta, ha nekem valami nem tetszik (bar sose szoktam)

> Se időm, se energiám - a tudásomról nem is beszélve -
>
> hogy komplexebb programok átírogatásával foglalkozzak.
>
> Másoknak mi a tapasztalata/gyakorlata ebben a témában?
>
> Most ha lehet, ne menjünk át flame-be, tényleg érdekel, hogy ki mennyire
> szokta a "forráskód adta lehetőségeket" kihasználni.

A szabad -ban nem elsosorban az a jo (az en szememben), hogy nekiesek,
mint bolond az ajtonak es atirom a forrasat, hanem az, hogy ez barmikor
megtehetem. A masik elonye az, amit dacas is emlitett, hogy ha bezarnak
a kodjat, akkor az utolso, meg szabad licenszu kodot forkolhatom es
folyhat tovabb a fejlesztes.

halam uldozni fog az ismert vilagegyetem hataraig

Ami nem kis módosítás volt, az a diplomamunkám annak idején: az MPICH nevű MPI implementáció IO alrendszeréhez adtam támogatást a tanszéken fejlesztett clusterekre való parallel filesystemhez. Ezt nem lehetett volna megtenni, ha az MPICH nem nyílt forrású, triviálisan azért, mert akkor hogy módosítom, másrészt meg azért, mert akkor nincs előttem példa, h hogy is kellene ennek nekiállni.

A Silicon Image 3112 kontroller és bizonyos Seagate SATA lemezek együttműködése nem teljesen zökkenőmentes, és bár ez a zökkenő csak nagyon ritkán jön elő, vhol vmi queue size ezen esetekben 15 a default 128 helyett. Mitadisten, nekem ilyen kontrollerem és diszkem van. Backupoltam, megkerestem a kérdéses kódrészletet, átírtam a nagyobb értékre, és egyből kijött az 50+MB/sec-es átvitel a korábbi 20 helyett. Másfél-két éve nem volt még vele gond. Ezt mondjuk zárt forrású driver esetén nehéz lett volna, és túl sok ész se kellett hozzá.

Aztán vannak még kisebb bugfixek, módosítások pár általam használt programhoz (x-chat, subversion, websvn).

Eleinte a Linphone SIP telefon meg nem mukodott a NeophoneX szolgaltatassal. Forras le, hiba javit 5 perc alatt, fordit, voila.

Valami konzolos halozatfigyelo progi nem olyan formatumban tolta a statisztikat, mint ahogy nekem kellett volna, de amugy tokeletes volt. Forras le, atir 5 perc alatt, fordit, voila.

stb.

Ezek aprosagok, de ha nem lett volna szabad a cucc, nagyon sok idot csesztem volna el az alternativa keresesevel. Ha egyaltalan talaltam volna...