A Sun 2006 végén kezdte nyílt forrásúvá tenni a Java-t. A cég azonban akkoriban nem tudta 100%-ban megnyitni, mindegy 96%-át tudta nyílt forrásúvá tenni. A fennmaradt 4% megnyitásáról - amelyben titkosítási, grafikai könyvtárak, hang engine és SNMP-vel kapcsolatos kódok vannak - azonban tárgyalnia kell(ett), mert nem birtokol(j|t)a a nyitáshoz szükséges jogokat.
A részletek itt.
- A hozzászóláshoz be kell jelentkezni
- 2609 megtekintés
Hozzászólások
Nem jó ez a "nyílt forrású" kifejezés, mert -sajnos tapasztalat, innen a hupról- a legtöbb OSS-fan azzal azonosítja, hogy a Java eddig zárt forrású (azaz csak bináris terjesztésű) volt, pedig nem:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/jdk12/Attic/Makefile
Mi tehát akkor a "closed source", azaz zárt forrás ellentéte? Az open source nem, pedig az lenne logikus.
Zárt forrás: nincs forráskódod.
Nyílt forrás: van forráskódod.
Szabad szoftver: van forráskódod és csinálhatsz is vele valamit (szabadabbtól (pld. PD) a korlátosabbig (pld. GPL és tsai)).
- A hozzászóláshoz be kell jelentkezni
sztem nem szokas nyilt forrasunak szamitani azt amikor a forraskod hoz valo hozzafereshez mindenfele doksikat kell alairnod.
- A hozzászóláshoz be kell jelentkezni
Az "I accept" gomb megnyomása aláírásnak számít? Különbséget érzek például a nyílt forrású Microsoft Windows között (amelynek a forrását bizonyos körülmények között megkaphatod, és ott valóban alá kell írni) és a Java között, amelynek a forrását ennél jóval könnyebben megszerezheted.
- A hozzászóláshoz be kell jelentkezni
nem tudom, hogy az i accept felett pontosan milyen szoveg van, de gyanitom, hogy pl megtiltja, hogy sajat jre-t fejlesszel utana :)
- A hozzászóláshoz be kell jelentkezni
Az a baj ezzel a felosztással, hogy a linkelt open source definíció nem csak annyit mond, hogy van forráskódod, hanem még 9 másik tényezőt is. Vagyis olyan, mint egy ogre: több rétegű :). Így az, hogy "nyílt = van kód", nem igaz, kell még ahhoz más is, pontosan az, amit nagyvonalúan a szabad szoftver alá soroltál.
A szabad szoftvert ugyanakkor nem kéne így összemosni a mindenféle "szabadabb" licencekkel, mert az FSF definiálta hogy mit hív szabadnak, az OSI meg hogy ő mit hív nyíltnak (ne menjünk bele az okokba, meg ádám-éváig vissza), jól van ez így, plusz a szabadságot eltérően értelmező csoportok TdR-től RMS-ig egy emberként kezdenének téged miatta flamelni, az meg kinek hiányzik :).
Igazából arra a helyzetre kéne kitalálni egy kifejezést, ami korábban a javanál is volt, hogy van ugyan forráskód, de nincs se belepofázás a fejlesztésbe, se forkolhatóság, se semmi komolyabb jogosítvány, ami miatt az OSI nyíltnak nyilváníthatná (vagy mint pl. az MS-féle shared source és hasonlók). Lehetne mondjuk "látható forrású"-nak nevezni :).
- A hozzászóláshoz be kell jelentkezni
A "nyilt forras" vs "szabad szoftver" szerintem alapvetoen egy "minek nevezzuk a gyereket" tipusu kerdes. RMS es ESR (azaz az FSF es az OSI) alapvetoen egyetertenek abban, hogy melyik licenceket tartjak nyilt forrasunak / szabad szoftvernek (PD, BSD, (L)GPL, CC-xx, Apache, Mozilla, ...), csak mindketto a sajat szaja ize szerint hivja oket. ESR ezt le is irta, pl. a Homesteading the Noosphere-ben, hogy azert "open source"-nak nevezi, mert az OSI inkabb a szabad szoftverek uzleti hasznalatat propagalando jott letre ("rationale, rationale"), mig RMS free sw-jenek az ideologiai toltete inkabb maganszemelyeknek szolt. ("help your neighbour", "your freedom") Az "open source" egy szandekosan semlegesebb (es laposabb) kifejezes, ami persze tud elonyos lenni, akkor is ha a "free sw" kifejezobb. Nem mindegy, hogy az egyszeri usernek, vagy egy cegnek akarod elmagyarazni, miert jo neki az altalad propagalt sw.
Az, hogy ezek milyen szepen kibekulnek, jol latszik azon, hogy mindketto elnevezesei benne vannak a F(L)OSS roviditesben, amirol - ha majd meg csavarnak egy-kettot rajta - mar a jo isten se fogja tudni, minek is volt a roviditese. (No meg aztan jottek meg tobben is, akik megint egy kicsit mast mondtak - BSD-sek, DFSG, Lessig, etc. - mondjuk ezekbol a MIT licenc (es valtozatai) valojaban inkabb meg RMS kortarsai)
ESR, RMS es az antikommercialitas:
http://catb.org/~esr/writings/homesteading/homesteading/ar01s02.html
Tisztabbak ezek a dolgok, ha a zart-nyilt-szabad harmas helyett tobb mindent is megkulonboztetunk, pl:
open-closed
public-private
free-proprietary
- A hozzászóláshoz be kell jelentkezni
juhú, mehet majd a
CFLAGS="-09 -march=s6000 -pipe=65536 -funroll-every-loop -mrice -mabi=rice -omg-optimized --disable-all-instructions -DREENABLE_FAST_EXECUTION" emerge sun-jdk :)
- A hozzászóláshoz be kell jelentkezni
Na erről beszélek. :(
FreeBSD-n erre 2000 óta lehetőséged van (egyszerűen, anélkül, hogy te magad pöcsölnél a forrással, azaz a ports rendszer részeként).
- A hozzászóláshoz be kell jelentkezni
WTB: működő jdk5/6 freebsd-n...
- A hozzászóláshoz be kell jelentkezni
működő jdk5 (mármint jdk-1.5) van. Az 1.6-os is jó úton halad
- A hozzászóláshoz be kell jelentkezni
én segfaultot kapok most is. :(
(jetty)
szerk. amd64
- A hozzászóláshoz be kell jelentkezni
Bocs, ehhez kene amd64-re forditanom a gepeimen, ezt nem tudom tesztelni. De ha szembejon egy, megnezem :-)
- A hozzászóláshoz be kell jelentkezni
Mi számít működőnek? Nekem jedit/eclipse/opends fut most a gépemen (némi browser pluginnel), illetve szoktam vele fordítani pár dolgot, amelyek aztán linuxos gépeken futnak.
FreeBSD 7/amd64
- A hozzászóláshoz be kell jelentkezni
alkalmazásszervereket szeretnék futtatni. vagy ha azt nem is, kezdetnek egy jetty megteszi. sajna mindig segfaultol :/ lehet, hogy csak ezekkel az alkalmazásokkal, de így elég szkeptikus vagyok
- A hozzászóláshoz be kell jelentkezni
Megértem, sajnos a javának (sem) elsődleges platformja a FreeBSD. Pedig mennyivel könnyebb lenne az életem (meg a kollegáké is)...
Mivel próbálod egyébként? (natív, linuxos, 1.5, 1.6, stb)
Apropó, ha már Solaris. :)
Ki, hogy menedzsel nagy számú Solaris farmokat? (az "egyenként" nem érdekel)
OS/csomagfrissítés, tesztelés, telepítés, terjesztés, rollback, konfigurációkezelés stb....
- A hozzászóláshoz be kell jelentkezni
nincs nagy számú farmom sajnos. Az egyes rendszerek annyira egyediek, különböző cégek nyúlkálnak hozzá, stb, hogy nincs is ilyen igény. Ennyi van:
- helyi patch repository
- patch-elés txt fileban lévő patch lista alapján (előre meghatározott, tesztelt)
- ahol ugyanazt csinálja több gép, ott szarakodás helyett mindig jumpstart + flash archívból újratelepítés
- ezeken egyébként pont SJWS van ami saját maga deploy-olja a konfigurációt a node-okra stb., nem nagyon számít ami alatta van, ha nagyon változik valami pl. új NFS mount akkor arra vannak scriptek, vagy reinstall.
- van egy rakás el****-tt kereskedelmi szoftver amihez jobb nem nyúlni. :)
- jellemzően ügyfeleknek dolgozunk ahol a rakás windows, linux PC közt van "A" Sun vas, amin valami nagyon fontos dolog fut, és nem hogy automatizálva, de sehogy nem szeretnék túlságosan bolygatni, mert "tavalyelőtt is a józsiék elrontották aztán milyen sokba került" (no comment)
- sun cluster + HA zone jó kombináció, amióta tud ilyet. igaz ezt is meg kell támogatni scriptekkel.
- linux alatt hogy csinálják ezt? a hardver menedzsment része nem érdekel, arra itt is vannak teljesen más megoldások.
A legnagyobb rendszerem 200 gépből állt de az FreeBSD volt és mind ugyanazt csinálta. 15:00 - 19:00 közt kész volt az egész, hardver telepítéssel együtt :) Csak a telepítő anyagot kellett előtte tesztelni, azt hiszem a sysinstall-ba is bele kellett nyúlni mert nem lehetett mindent automatikusan megcsinálni, amit szerettünk volna. Ehhez még volt néhány script az egyszerűbb dolgokhoz, ha túl nagy változás volt akkor itt is reinstall. :)
- A hozzászóláshoz be kell jelentkezni
> "A" Sun vas, amin valami nagyon fontos dolog fut, és nem hogy automatizálva, de sehogy nem szeretnék túlságosan bolygatni, mert "tavalyelőtt is a józsiék elrontották aztán milyen sokba került"
Ez mindig nagy dilemma: supportosok 3 napi dija vs. 6 hét eü. szabi + gipsz Józsinak kézre szivlapáttal való rácsapásból kifolyólag. :))
--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc
- A hozzászóláshoz be kell jelentkezni
Gondoltam, hogy nálatok inkább el vannak aprózva a dolgok (sok helyen, sokféle), emiatt kevésbé fontos az egységes menedzsment.
- A hozzászóláshoz be kell jelentkezni
BSD-s illusztracio
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
Hany bites a kepen a NetBSD?
- A hozzászóláshoz be kell jelentkezni
Pár dolgot érdemes tisztázni... :)
A Java, mint fogalom előírja a nyelv alapvető jellemzőit. A JVM, mint fogalom, előírja a virtuális gép jellemzőit. A J2SE, a J2ME és a J2EE előírja a szükséges osztályokat és azok funkcionális működését. A Sun nem zárta be a Java platformot soha, csak közzétette a specifikációt és - igaz pénzért - de adhat egy pecsétes papírt, hogy az adott implementáció kompatibilis.
A fentiekből adódóan az OpenJDK előtt is volt egy csomó Java implementáció, kezdve a nagy kék termékével, az IBM JDK-val, amely mondjuk nem nyilt forrású (az lesz valaha? :), folytatva az Apache Harmonyi projekttel, amely egy nyilt forrású JDK volt, aztán jól megszívták, amikor a Sun elindította az OpenJDK-t (azóta is hadban vannak egymással az Apache és a Sun, a JSR szavazásokon rendre a Sun ellen szavaznak). A Harmony ugye Apache licenc, ezért megjelentek a Harmony alapú JDK-k. Ezek többé-kevésbé kompatibilisek voltak a Sun JDK-val, de pénz vagy politikai elhatározás hiányában nem kaptak pecsétes papírt, ilyen a FreeBSD-s Java is.
--
http://www.javaforum.hu
- A hozzászóláshoz be kell jelentkezni
jdk7 modularitása lesz a jó.
- A hozzászóláshoz be kell jelentkezni
jo lesz az CPPFLAGS-nek is ;)
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
defaultból: CXXFLAGS="${CFLAGS}"
- A hozzászóláshoz be kell jelentkezni
Ne keverjunk keremszepen: CPPFLAGS - a cpp nevu C-preprocesszornak szol, CXXFLAGS pedig a c++ nevu kompiler-frontendnek. De hogy melyikotok melyikre gondolt ...
- A hozzászóláshoz be kell jelentkezni
ahh, CXX-re gondoltam :/
--
Segmentation violation -- Core dumped blues
- A hozzászóláshoz be kell jelentkezni
LICENSE="dlj-1.1"
sun-jdk -rol a legutobbi nyitas ota eltunt a fetch restriction. (Nem kell honlapjarol kezzel letolteni a csomagot es elfogadni licenset)
LICENSE="sun-j2sl-6"
java-sdk-docs
Ezt meg mindig le kell tolteni kezzel, marhara tud idegesiteni.
LICENSE="GPL-2-with-linking-exception sun-prerelease-jdk7"
openjdk
java-experimental overlay-bol.
- A hozzászóláshoz be kell jelentkezni