Java w końcu wolna i otwarta

@Ponton nie bardzo rozumiem Twoje argumenty – po co usuwac stare rzeczy skoro tracisz w ten sposob kompatybilnosc? przyklad – owszem java.io nie bylo idealne ale na tamte czasy nie moglbys zaimplementowac na wszystkich systemach rozszerzen znanych z java.nio, podobnie z dbus – jak chcesz wprowadzic dbus do api java skoro nie ma go na wszystkich systemach – ba! w linuxie to bardzo swieza rzecz, ktora nie jest nawet czescia jadra! Nalezy pamietac ze przenosnosc java nie bierze sie z widzimisie jej projektantow ale z przekroju mozliwosci wszystkich systemow na ktore jest wydawana. Jesli zas chodzi o GUI to postepy sa olbrzymie w ostatnich latach – warto zobaczyc mozliwosci swing generowanego przez Netbeans6 lub tez wykorzystac SWT

Co z tego, że DBus nie jest w jądrze? Xorg też nie jest, a się go używa.

@dPeS: piszesz

> po co usuwac stare rzeczy skoro tracisz w ten sposob kompatybilnosc?

1. Nowocześniej

2. Szybsza praca

3. Mniej bajtów do pobierania

4. Lepiej (tu zawsze można dyskutować )

Zresztą inne projekty otwarte też tak robią. Przykład: PHP5 -> PHP6

Java też jest otwarta, więc też w końcu wolno – a przecież i tak zostaje zawsze możliwość instalacji wielu bibliotek (starsze dla starszych programów).

Mnie np. najbardziej irytuje stare AWT i Swing. Tym bibliotekom naprawdę należy się odświeżenie. Do tego rozszerzenia języka typu LINQ – no, byłoby naprawdę fajnie po ich dodaniu.

PHP to są fistaszki. Java to język nr 1 na świecie. A Ty tak po prostu chcesz rozwalić kompatybilność wsteczną. Nie, dzięki…

@wiktorw

Proces rozwoju PHP a Javy to w moim odczuciu rozne inne bajki, PHP to w tym porownaniu amatorski projekt, w ktorym od poczatku popelniano powazne bledy projektowe, co skutkowalo w pozniejszych koniecznych zmianach – jak pokazuje historia, niemalze co wersja PHP, to niekompatybilna wstecz.

O jakich innych projektach mowimy? O nadchodzacym Pythonie? Tutaj tak drastyczna zmiana rzeczywiscie nadejdzie, choc jezyki skryptowe to chyba troche inny swiat…

Uczynienie API niekompatybilnym wstecz na poziomie jakiejs biblioteki (np. QT3 vs QT4) a na poziomie jezyka lub jego podstawowego API – to inny poziom klopotow. W szczegolnosci w jezyku ktorego aplikacje z zalozenia maja dzialac na kazdej JVM bez rekompilacji.

Co nalezaloby odswiezyc w AWT/Swing? I czy nie daloby sie tego zrobic pozostawiajac stare API dzialajace?

Czy np. domkniec i jezyka zapytan w stylu LINQ(?) nie da sie zaimplementwowac zachowujac dzialanie starego kodu?

IMO zeby zerwac wsteczna kompatyiblnosc w Javie, trzeba miec do tego powazane powody. Mozna bylo rozwazac to np. w momencie wprowadzania typow generycznych, ktore sa po kompilacji zamazywane zeby wlasnie zachowac wsteczna kompatybilnosc. To bywa upierdliwe, ale wydaje mi sie znosne.

Czy sa jakies sensowne powody na horyzoncie?

Nie porównuj PHP do Javy bo to są dwie różne bajki jak już ktoś napisał. Nie widziałem jeszcze firmy która by napisała jakiś korporacyjny system w PHP.

W Javie się pisze małe programiki okienkowe jak i aplikacje korporacyjne a one mają działać a nie być przepisywane w kółko na nowe wersje co generuje nie rzadko ogromne koszta.

Dobrym przykładem jest tu też Linux, z wersji na wersję rzeczy które są rozwijane poza jądrem nie działają ze starszą wersją bo zmieniło się API czegoś.

Dlatego chodzi mi o forka, gdzie stara Java byłaby rozwijana z numerkami 1.x, a nowa np. z 2.x.

Aktualnie mamy 6.0 już Taki fork by nie miał racji bytu bo dla piszących w Javie stabilność API to podstawa. Wychodzi nowa wersja, uruchamiasz stary kod bez problemu na niej i dostajesz możliwość używania rzeczy z nowej wersji a nie marnujesz czasu na przepisywaniu czegoś na nowe API by użyć nowych rzeczy które oferuje nowa wersja. Stare API wcale nie ciąży – widać to na przykładzie stare IO a NIO – jak już ktoś już z resztą wspomniał.

@POnton: jakie widzisz konkretnie powody zeby zrywac to kompatybilnosc i tworzyc oddzielna galaz?

@zawir

Jakiś czas temu przy testowaniu możliwości "odchudzenia" Javy było słychać o czymś takim jak "Java BVrowser Edition". Pełne JRE wypadło około 15.5 MB, zaś odchudzone wersje ok. 2.6-3.5 MB. Skoro od Suna i tak najwięcej teraz słychać o JavaFX, to możliwość uruchamiania "małej" Javy w przeglądarce jest bardzo kusząca. Mały download, szybki start – akurat konkurencja dla Flash-a.

Czego mi brakuje w Swing? Łatwego sięgania do elementów niektórych kontrolek (np. JList) – żeby coś modyfikować w trakcie pracy aplikacji, trzeba robić drugi obiekt z modelem. Inne szanowane biblioteki tak nie mają (VCL, WinForms, GTK#, WxWidgets). Brakuje mi łatwego sortowania list, combo i tabel – dotąd posiłkowałem się niestandardowymi GlazedLists. Brakowało mi frameworku do robienia aplikacji typu desktop – zarządzanie dokumentem, itp. (NetBeans 6 wspiera już coś takiego). Brakowało mi łatwego wiązania kontrolek z danymi (jak w .NET czy w Delphi), chociaż od niedawna jest już Beans Binding. Wygląd nie zgadzający się w 100% z systemowym, nie najlepsze wsparcie dla GTK2, nieprzetłumaczone okienka Otwórz/Zapisz plik (tylko angielski), czas domyślnego dwukliku myszą w X pod Linuksem ustawiony na 100ms (ja używam w GNOME 400-600ms). I jeszcze kilka takich uciążliwości, do których trzeba przywyknąć pisząc w Javie+Swing.

Żeby nie było nieporozumień – nauczam Javy, jestem bardzo za tym rozwiązaniem, ale Java jest dla specjalistów. Da się to opanować, ale ciężko się tego uczy porównując np. z Delphi+VCL. A jaki jest szok kulturowy gdy się okazuje, że w Visual Studio łatwe rzeczy (jak większość projektów na studiach) pisze się bardzo łatwo… To mi się robi smutno.

Trudno nazwać bibliotekę WxWidgets "szanowaną", gdyż jest mocno wzorowana na MFC, które z punktu widzenia zasad projektowania obiektowo zorientowanego jest koszmarkiem. Jeśli chodzi o ddzielenie modelu od widoku w Swingu, to jest ono jak najbardziej ideologiczne poprawne . Osobiście uważam Swing za jedną z przyjemniejszych bibliotek GUI, lepsze może jest tylko Qt 4.

@wiktorw:

Hm, nie slyszalem o takich planach dla przegladarek. Prawde mowiac nie specjalnie interesuje sie tematem, bo Jave uzywam gdzie indziej.

Swing rzeczywiscie nie zawsze bywa najlatwiejszy w uzyciu, ale wydaje sie elastyczny i sensownie zaprojektowany.

Co do brakujacego frameworku i tego czego nie ma Swing, to moze warto zerknac na spojrzec na SWT/JFace, albo lepiej cale Eclipse RCP? W Eclipse, SWT nie ma tez problemu niepelnej natywnosci aplikacji, np. wspomnianego problemu dwukliku (nie zwrocilem nigdy uwagi).

Tak czy inaczej, nawet jesli mialaby powstac odchudzona wersja browser (byloby J2SE, J2ME i J2BE?), albo cos mialoby sie zmienic w Swingu, to chyba nie potrzeba do tego rewolucji na poziomie jezyka?

"Tak czy inaczej, nawet jesli mialaby powstac odchudzona wersja browser (byloby J2SE, J2ME i J2BE?), albo cos mialoby sie zmienic w Swingu, to chyba nie potrzeba do tego rewolucji na poziomie jezyka?"

I tu trafiłeś w sedno. Język na dzień dzisiejszy jest wystarczający, kuleją biblioteki i (trochę) środowisko wykonawcze. Mechanizm kompilacji Just In Time, maszyna wirtualna z mechanizmem HotSpot – to są świetne rzeczy. Ale np. zimny start appletu czy uruchomienie aplikacji przez Java WebStart są wyraźnie odczuwalne.

Szybsze, wygodniejsze rozwiązania powodują przyzwyczajenie deweloperów. Większość problemów przy ostatecznym kończeniu systemów przed wdrożeniem odbywa się w wielu powtarzających się cyklach poprawka-kompilacja-debugowanie. Jak kto przywyknie do Javy (i np. NetBeans, Eclipse, JDeveloper, czy JBuilder/Code Gear) to super. Jak przywyknie do Visual Studio (a jest to bardzo skuteczne narzędzie dla programistów) – no cóż, w efekcie dołoży cegiełkę do imperium MS.

Platforma Java EE wymiata na serwerach. Chociaż dużo sensu ma wykorzystanie backend-u napisanego w Javie (logika biznesowa) a frontend-u napisanego w czymś skryptowym, jak np. PHP (szybkie prototypowanie, łatwość zmian, brak rekompilacji, szybki wynik końcowy). Rzeźbienie webowego GUI w JSF jest owszem, rewelacyjne pod względem ideowym, ale koszmarne do nauczenia i kłopotliwe przy wdrożeniu (te ciągłe compile-undeploy-deploy). Ze smutkiem stwierdzam, że nawet już ASP.NET jest w tym lepsze.

Szybkość niezmiernie się liczy w dzisiejszych czasach, konkurencja nie śpi. Szybciej = taniej, czyli można prowadzić skuteczniejszy marketing i taniej (niestety? właśnie?) zatrudniać programistów. Słyszałem takie słowo w telewizji: komodyzacja, może warto je znać?

Artykuły na temat Java+PHP w sieci:

PHP on Java: Best of Both Worlds?
http://www.infoq.com/news/2007/10/php-java-stack

Caucho Resin adds PHP (PHP pages are compiled in the background to byte-code, and the resulting performance is six times that of Apache mod_php)
http://www.theserverside.com/news/thread.tss?thre…

PHP and Java Technology Integration (Gutmans presents a live demo on how to use a J2EE back-end system application server and a Zend platform as a PHP/Java technology bridge to achieve optimal interoperability)
http://developers.sun.com/learning/javaoneonline/…

@wiktorw

Czego mi brakuje w Swing? Łatwego sięgania do elementów niektórych kontrolek (np. JList) – żeby coś modyfikować w trakcie pracy aplikacji, trzeba robić drugi obiekt z modelem

Nie rozumiem. Do JList jest gotowy DefaultListModel – do prototypowania i prostych zastosowan spokojnie wystarczy.

"Do JList jest gotowy DefaultListModel"

Właśnie. I pisząc kod "z palca" pamięta się o tym, że trzeba: 1. stworzyć kontrolkę

2. stworzyć dla niej model

3. powiązać kontrolkę z modelem

Tworząc aplikację w NetBeans (szybko prototypując i podając startowe elementy listy) dostaje się jakiś własny obiekt dziedziczący z ListModel, którego nie można modyfikować. Trzeba samemu napisać kod, który tworzy modyfikowalny model, skopiuje domyślne wartości i podmieni model w kontrolce. To boli. A miało być szybkie prototypowanie.

A czy nie można by tak *OPCJONALNIE* podawać kontrolce własny model (10% specjalnych potrzeb), a domyślne zachowanie zostawić proste i skuteczne (90% typowych przypadków)? Ten motyw się powtarza w Swing – i nie, że nie umiem w nim programować, ale trochę zaczyna on przypominać eksperyment naukowy programowania interfejsu użytkownika z podejściem wysoko obiektowym.

2. stworzyć dla niej model

model = new DefaultListModel();

1. stworzyć kontrolkę

3. powiązać kontrolkę z modelem

list = new JList(model);

dostaje się jakiś własny obiekt dziedziczący z ListModel, którego nie można modyfikować.

model.addElement(…);

model.removeElementAt(…);

(przyklady wziete stad

====

Sorry, moim zdaniem szukasz dziury w calym.

[mode="zły_poranek"]

Widzisz, znam te przykłady od 10 lat… I już mi się trochę przejadły. JA WIEM ŻE TO NIETRUDNE, nie musisz mi tego udowadniać. Ja twierdzę, że jest to NIEWYGODNE w porównaniu z innymi bibliotekami obsługiwanymi w środowiskach typu RAD.

A co mi powiesz, szanowna kropko, na łatwość sortowania zawartości kontrolek JList, JComboBox i JTable? (mój nie-ulubiony przykład)

[/mode]

To nienaturalne, żeby projektując interfejs w Matisse pod NetBeans dla kolejnego okna dialogowego co i rusz przechodzić do kodu i dla każdej kontrolki pisać: zrób DefaultCoTrzebaModel, powiąż z kontrolką. Albo więc leżą biblioteki albo NetBeans. I mam na myśli własną, średnio zaawansowaną aplikację.

Jednak mimo to cenię Javę i szanuję, ale uważam, że inne biblioteki, języki i środowiska nie zasypiają gruszek w popiele. Brak zmian to stanie w miejscu, a tego raczej nikt Javie nie życzy. Swing był jednak zaprojektowany dawno temu i dopiero ostatnio pojawiły się pewne ulepszenia (np. Beans Binding).

Nie trzeba przechodzić do kodu, żeby przypisać Model. Jest specjalna właściwość do tego.

No dobrze, znalazłem wywiad z twórcą framework-u do Beans Binding:

http://www.artima.com/lejava/articles/beans_bindi…

W obliczu możliwego wprowadzenia obsługi właściwości w języku Java zaczyna to wyglądać jaśniej (no i w końcu może przestanę narzekać ). Miłego dnia!

A ja już standardowo zapytam – wiesz chociaż po co ci te 64 bity, czy tylko masz za szybki procesor, za dużo RAM-u i chcesz sobie podgrzać w pokoju?

tzn. że 64bit system na 64bit procku, służy tylko do generowania większej ilości ciepła? możesz rozwinąć swoją myśl?

Zajmuję się GISem i 64 bity dla mnie to podstawa, mam serdecznie dość walki z tym, że nie mogę zmapować do pamięci pliku większego niż 2 GB ani, ani zaalokować więcej niż 2 GB RAMu. Niektóre moje programy potrafią "łyknąć" do 20 GB i dopóki program zachowuje się "kulturalnie", tzn. nie biega losowo po całej pamięci, tylko po w miarę wolno się zmieniającym niewielkim zbiorze roboczym, to wszystko chodzi całkiem-całkiem w na komputerze z 6GB RAM + 32GB swap. Zaimplementowanie używanych przeze mnie struktur danych w pamięci zewnętrznej wymagałoby o wiele więcej roboty (std::map -> B-drzewa, inne -> hmmm…), choć może wynik byłby bardziej wydajny.

Zupełnie nie rozumiem, czemu Sun nie może zrobić 64-bitowego pluginu javy, zwłaszcza że mają dobrze działającą 64-bitową maszynę wirtualną. Podobne kłopoty ma Adobe z pluginem Flasha. Czy w API w mozillowych pluginów jest jakiś hak, który przywiązuje je do 32-bitów?

Sam pisałem już to wiele razy. 64bitowy system nie daje żadnych korzyści w normalnym użytkowaniu, zalety można jedynie zobaczyć przy np. jakimś encodowaniu.

Druga strona medalu to to że w systemie 64bitowym wszystkie wskaźniki na pamięć mają wielkość 64bitów co potrafi przy tym samym oprogramowaniu na 32bitach dać wzrost nawet kilkudziesięciu procent. Do tego dochodzą wspomniane problemy z wtyczką do Javy, Flasha itd. – nie opłaca się.

Druga strona medalu to to że w systemie 64bitowym wszystkie wskaźniki na pamięć mają wielkość 64bitów co potrafi przy tym samym oprogramowaniu na 32bitach dać wzrost nawet kilkudziesięciu procent. Do tego dochodzą wspomniane problemy z wtyczką do Javy, Flasha itd. – nie opłaca się.

Que?? Chyba nie wiesz o czym piszesz, a jeśli wiesz to proszę wyjaśnij mi dla czego tak sądzisz.

Nie widzę żadengo związku poza możliwością adresowania większego obszaru i braku koniecznośći stosowania sztuczek w stylu PAE jeśli się chce wyjść poza 4GB. Co w zasadzie wydajności jedynie może pomóc. Inna sprawa, że 64-bity w wydaniu Intela (w przeciwieństwie do rodzimego rozwiązania AMD) były początkowo dość kulawe, nie wiem jak sprawa się ma obecnie w Core2Duo, ale może to o czym piszesz bierze się właśnie z tego powodu.

W każdym razie na prcesorach AMD 64-bitowe systemy (szczególnie Linux) dostają skrzydeł. Polecam sprawdzić choćby szybkość renderingu Sunfolw-a wykonany na 32-bitowym i 64-bitowym JRE Suna:
http://sfwiki.geneome.net/index.php5?title=Benchm…

Wiem o czym pisze i napisałem dlaczego tak sądzę. Dlatego powiedziałem że przy normalnym użytkowaniu 64bity mają więcej wad niż zalet, rzadko komu potrzeba adresować więcej niż 2GB pamięci na proces (oczywiście niektórzy potrzebują takich rozwiązań [wspomniana pamięć, encoding, rendering] i wtedy warto jest iść w 64bity) a jeżeli nie potrzeba to nie ma sensu zmagać się z problemami których wcale nie musi być.

64bity w wydaniu Intela to przeszłośc i już nikt o tym nie pamięta, to co piszę dotyczy AMD64.

No jakoś ja nie odczułem tych skrzydeł, co gorsza spowolnienie i większe zużycie pamięci nie dostając nic w zamian. Co do podanego benchmarka – wszystko fajnie – tak jak wspomniałem już na początku encoding, rendering owszem będzie szybszy. Odpal ten test na 32bit i 64bit JRE i spójrz na wielkość zajmowanej pamięci przez proces JRE – strzelam że na 64bit będzie co najmniej 50% więcej. Na codzień programuję w Javie i zajętość pamięci przez IDE (Eclipse, NetBeans) na 32/64bit to różnica ok 70%.

Wiem o czym pisze i napisałem dlaczego tak sądzę.

To znaczy twierdzisz, że 64-bitowe wskaźniki spowalniają obliczenia? Wolne żarty. Dla tego właśnie myślę, że chyba nie wiesz o czym piszesz. Co do zapotrzebowania na pamięć, to w przypadku najnowszych gier 2GB na Viście jest wymaganym minimum, a 4GB zalecaną konfiguracją, więc nie wydaje mi się, żeby była to taka awangarda.

W każdym razie niem mam pojęcia o jakim spowolnieniu piszesz, bo nigdy z takowym nie miałem do czynienia, prócz – jak pisałem wcześniej, intelowej implementacji zwanej EM64T, która nie wiam jak się obecnie zachowuje.

Odpal ten test na 32bit i 64bit JRE i spójrz na wielkość zajmowanej pamięci przez proces JRE – strzelam że na 64bit będzie co najmniej 50% więcej. Na codzień programuję w Javie i zajętość pamięci przez IDE (Eclipse, NetBeans) na 32/64bit to różnica ok 70%.

Hmm, chyba jednak nie używasz zbyt często 64-bitowego JRE Javy.

Primo, zurzycie pamięci naprawdę niewiele się różni (szczególnie na client JVM), secundo, powiedz mi jak odpaliłeś Eclipse na 64-bitach, bo mi się to póki co nie udało (wersja dla Windows). Może dla tego, że oficjalne wsparcie dla 64-biów mieć będzie dopiero Ganymede…

Czy ja gdzieś pisałem że chodzi o wydajność obliczeń? Pisałem o zużyciu pamięci – zacytuję siebie:

Druga strona medalu to to że w systemie 64bitowym wszystkie wskaźniki na pamięć mają wielkość 64bitów co potrafi przy tym samym oprogramowaniu na 32bitach dać wzrost nawet kilkudziesięciu procent.

Fakt nie napisałem jasno że mam na myśli pamięć ale nie można było tego odebrać w taki sposób jak piszesz. To że komputery mają po 2/4GB pamięci to nie znaczy że mam ją zużywać na potrzeby 64bitowego systemu jeżeli nie jest mi to potrzebne.

Używam 64bitowego JRE na codzień w środowisku serwerowym gdzie owe 64bit to aktualnie podstawa, to czy jest to client czy server JIT nie ma najmniejszego znaczenia – zawsze są używane 64bitowe referencje (pakowanie referencji ma np. BEA JRockit, która potrafi w 64bitowym środowisku używać 32bitowych referencji a gdy zajdzie potrzeba używa 64bitowych). Więc tu akurat wiem co mówię. Polecam sprawdzić samemu (prosty programik tworzący masę obiektów i sleep) uruchomić na 32bit JRE i zobaczyć zużycie, analogicznie do 64bit i wyniki porównać. Co do Eclipse-a to niestety nie pamiętam – była to wersja bodajże 3.2 odpalana na Linuksie.

Zwracam honor jeśli chodzi o zużuycie pamięci przez Javę, to potrafi ono być 2 razy większe przy 64-bitach (choc to mocno zależy od aplikacji):
http://benjchristensen.wordpress.com/2007/02/16/3… http://escher.elis.ugent.be/publ/Edocs/DOC/P106_0…
Algorytmy, które implementwałem w Javie były intensywne obliczeniowo, ale nie pamięciowo, stąd nie miałem świdomości, że tak to może wyglądać.

Natomiast jesli chodzi o wydajność nadal twierdzę, że 64-bitowy OS nie ustępuje wydajnością 32-bitowemu. Problemy, są conajwyżej na poziomie mieszania bibliotek 64/32-bitowych, którego robić się nie da i stąd te problemy z flashem itp. Ale to z wydajnością nie ma nic wspólnego.

Sam pisałem już to wiele razy. 64bitowy system nie daje żadnych korzyści w normalnym użytkowaniu, zalety można jedynie zobaczyć przy np. jakimś encodowaniu.

64bit system to przede wszystkim możliwość zaadresowania więcej niż 4GB pamięci i to jest podstawowa zaleta. W czasach gdy 2GB pamięci RAM to standard, już niedługo będziemy potrzebowali (przynajmniej niektórzy) jeszcze więcej pamięci (gry są naprawdę żarłoczne) i wtedy przejście na 64 będzie nieuniknione. Oczywiście to w przypadku desktopa, bo w przypadku serwerów praktycznie już teraz stosuje się więcej pamięci niż potrafi 32 bity potrafią zaadresować. Jednak w przypadku serwerów problemów nie ma, są jedynie na desktopie.

@gotar

1. Bo mam wrażenie, że 64 bity to przyszłość, a 32 to teraźniejszość i powoli, acz nieubłaganie przeszłość.

2. Bo lubię nowe wyzwania i chcę trochę poeksperymentować i zobaczyć, jak to działa.

3. Bo procek ma 64 bity i nie widzę powodu, aby nie wykorzystać jego możliwości w tym zakresie.

Więc w sumie – why not?

Co do ramu to jest przecież PXE, 64bit to tylko chwyt marketingowy, wymuszajacy wymianę sprzętu obecnie do normalnej pracy i multimediów starczy Pentium M 1,4-1,7GHz

Zla odpowiedz. Prawidlowa odpowiedz to 64-bitowa

przestrzen adresowa, czyli po chlopsku, mozliwosc

przewalania wiekszej ilosci danych w pamieci.

Idac tokiem rozumowania gotara, po co nam 32 bity? Albo 16?

W sensie turinga, 4-bitowy 4004 byl kompletny, wystarczyloby

wiec tylko podgonic mu zegar do paru gigahercow.

> Co do ramu to jest przecież PXE

Dowiedz sie jak dziala PXE i jakie ograniczenia
pozwala ominac, wtedy wroc i zacznij dyskutowac.

@michug: Chyba chodziło ci o PAE.

jakie PXE masz na myśli, bo mi się to kojarzy jedynie z bootowaniem przez sieć, które w żaden sposób mi do tego konktekstu nie pasuje.

apropos procesorów i ilości pamięci: moje zestawy wyglądają mniejwięcej tak:

AMD sempron 2400+ (1666 MHz) + 512 MB RAM DDR2 + ~512 MB SWAP, grafa ATI Radeon, nie pamiętam typu, ale ma już kilka lat

Intel Pentium III M (800-1200 MHz) + 256 MB SDRAM + 512 MB SWAP, grafa intel i810

Skrzynka (AMD) jest dla mnie całkowicie wystarczająca, zdarzało mi się nawet grać w heroesów pod wine ( na kubuntu ) i810

laptop (P III) mógłby mieć lepszą grafikę / grafika nie jest w pełni wykorzystana, ale na ogół mi to nie przeszkadza. Do zwykłej pracy biurowej, internetu, słuchania muzyki, a nawet oglądania filmów jest całkowicie wystarczający. Jedynie Big Buck Bunny się ciął, ale tam jest wyższa rozdzielczość niż typowa – z divixami czy rmvb nie ma żadnych problemów.

Ubuntu co prawda chodziło dość ciężko, ale już debian działa naprawdę przyjemnie. Nawet za bardzo nie mieli dyskiem (swap)

To byłoby chyba wszystko w kontekście potrzebnej mocy procesora i ilości pamięci na biurko.

Aha, zestaw AMD duron 800 MHz + 128 MB RAM + 512 SWAP chodzi z kubuntu dość ciężko, ale z debianem go nie sprawdzałem. Jednak jestem pewien, że taki zestaw również jest wystarczający, ponieważ laptop po zmianie kubuntu -> debian + KDE z mojego pukntu widzenia (użytkownika) to wręcz rakieta w porównaniu do tego, co było.

Tak tylko chciałbym aby to jeszcze uzasadnił, bo z mojego doświadczenia wcale nie wynika aby Java była jakoś specjalnie powolna.

Wszystkie aplikacje użytkowe napisane z użyciem Javy i jego "genialnych" GUI wskazują na żółwią wolność. Ciekawe natomiast jakby się Java spisywała z takim QtJambi np…

Z moich testów wynika, że java uruchamiana z opcją server jest szybsza od analogicznego kodu skompilowanego z -O2 w GCC 3 i gcc 4.0, oraz wolniejsza od GCC 4.2. Program testowy to proste liczenie liczby fibonaciego rekurencyjne. Twórcy GCC poczynili mocne zmiany w GCC 4.2 i rzeczywiście kod C++ skompilowany tym kompilatorem jest naprawdę szybki. Sądzę, że prawdopodobnie dodadzą podobne optymalizacje do kompilatora JIT w VM Javy. Niestety przy tworzeniu wersji 1.6 i 1.7 głównie siły idą na otwarcie i kompatybilność, optymalizacja kompilatora JIT nie jest uwzględniana, co pewnie zmieni się wkrótce. Generalnie Java nie jest powolna, to że kiedyś była nie znaczy, że jest nadal – aktualnie rzekoma powolność Javy to MIT.

@Rsh:

Co prawda *NIE* "wszystkie aplikacje użytkowe napisane z użyciem Javy i jego “genialnych” GUI wskazują na żółwią wolność". Bo wystarczy popatrzeć np. na Eclipse czy Azureusa, które to aplikacje działają w oparciu o SWT.

Ale to jest jeden z typowych argumentów za tym, aby w Javie zrobić jakieś porządne zmiany. A przynajmniej w AWT/Swing – jak pisałem wcześniej. I co prawda nie jestem gorącym orędownikiem SWT, ale przynajmniej jest to przykład, że można!

Wykonałem test dodatkowo dla pythona . Aby doczekać się aż python obliczy liczbę fibonacciego, zmniejszyłem wartość liczoną z 43 do 40 i taki efekt:

:

- java -server: 0m 1.487s (dłużej od gcc bo odpalenie VM + skompilowanie bytekodu zajmuje czas i gcc dodatkowo włączyłem z -O3 )

- gcc -O3: 0m 0.911s

- python: 3m 26.133s

:

Test przeprowadzony na MacBook Pro Intel C3D 22GHz, Mac OS X 10.4.

GCC 4.0.1 (Apple), Java 1.5.0_13-121, Python 2.3.5

:

Jak widać python jest 226 razy wolniejszy od gcc -O3 i 138 razy wolniejszy od javy -sever. Jeżeli mówimy o żółwiej wolności to mówmy o pythone, rubym, bashu, BASICu, i innych językach INTERPRETOWANYCH. Żółwia wolność Javy to MIT i warto to zapamiętać.

Jeśli tak, to super. Dzięki za link.

coś nie bardzo panowie wciąż openjdk się nie kompiluje na freebsd

Kogo obchodzi openjdk? Wazne, ze Sunowa Java sie kompiluje.

Sunowa to ja sobie moge z paczek, ale chodzi mi openjdk bo obiecywali dodać ją do CD

Ale _po co_? Jesli "bo mozna", to sugerowalbym raczej Linuksa. BSD raczej nie jest od rzeczy bez praktycznych zastosowan. ;->

dla mnie skrypty na www są bardzo praktyczne, a ta sunowa wersja na BSD chodzi cholernie mułowato tak, że mam pozapychane buffory

Nie wszyscy używają Fx'a, a niektóre przeglądarki (vide konqueror) radzą sobie z tym tak jak powinny.

Poza tym ŻADNYCH innych problemów nie ma.

Najlepiej moje zdanie odda stwierdzenie: "jeśli nie widać różnicy, to po co wybierać ustępującą technologię?"

@AdeBe: niestety 64bit jest sporym problemem na desktopie, bo:

- flash

- plugin do appletów javy

- komercyjne gry closed-source, których raczej nikt nie przekompiluje

:

Generalnie problematyczne jest jak zwykle oprogramowanie z zamkniętym kodem.

:

Przeciętny user może mieć problemy z instalacją bibliotek 32bit i 64bit. BTW. szkoda, że Linux nie potrafi linkować dynamicznie biblioteki 32bit z programem 64bit. Szkoda, że potraktowano architekturę 64bit jako coś nowego, a nie następną wersję x86. Wtedy wiele problemów by zniknęło i nie trzeba by pisać osobnego plugina dla FF pod 64bit.

To nie Linux nie potrafi tylko takie coś jest technicznie nie wykonalne.

architekturę 64bit jako coś nowego, a nie następną wersję x86. Wtedy wiele problemów by zniknęło i nie trzeba by pisać osobnego plugina dla FF pod 64bit.

To nie jest problem Linuksa tylko sposobu w jaki została zaprojektowana architektura AMD64. Ponieważ i tak większość współczesnych OS-ów nie używała segmentacji do zarządzania pamięcią, korzystając w tym celu ze stron, więc w "long mode" w trybie 64-bitowym zarzucono zupełnie tą koncepcję na rzecz rozszerzeń w podsystemie stronicowania pamięci. Z kolei "long mode" w trybie kompatybilności zachowuje się identycznie jak dotychczasowy 32-bitowy tryb chroniony, stąd 64-bitowy kod nie może się wykonywać w trybie kompatybilności i vice versa. Biblioteki, łączone z kodem z natury rzeczy muszą spełniać to samo wymaganie.