🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:

[...]

> Mam swoje podejście do takich konstrukcji, oparte o zaawansowany MPI i
> współdzialanie procesów. (...)

Nie gniewaj się, ale w skrócie to brzmi tak: "ja też umiem zrobić koło".  ;)

Nie twierdzę, że masz zły pomysł.  Bardziej pasuje mi on jednak na ich 
droższe usługi (Private/Premium Tomcat i Private JBoss).

Do których to BTW ja pewnie po prostu VMWare bym użył...


W opcji jednak, o którą pytałem, JVMy są "Shared" (tu ładnie to widzać: 
http://www.4java.ca/index.html).  I Twój sposób, to po prostu nie to.

A po co łączyć?  Ano zapytaj praktyków.  Choćby pamięciowe narzuty można 
rozłożyć znacznie korzystniej na wspólnej maszynie, o łatwiejszej 
administracji, optymalizacjach i konserwacji serwera nie wspominając. 
Tylko z szacunku kosztów usług wynikałoby, że przynajmniej dwóch 
klientów hastują na jednej JVMie (w praktyce myślę, że gruuubo więcej...).

Wniosek (i cel pokazu):  bez Javowych zabezpieczeń, raczej mało 
bezpieczne by to było.  Nie sądzisz?


>> Możliwość jest, nieporównywalnie mniejsza jednak, niż w przypadku
>> ewidentnych dziur.
> 
> Zgadza się. Ale ja nie mierzę aż tak wysoko.

No cóż.  Niektórzy mierzą.


> No tak. Więc są potrzebne języki jakby naturalne dla takich systemów, więc
> potępianie wszystkiego w czambuł jest przesadą. 

A kto potępia?  Nikt nie zarzucał Ci tego, że używasz C++ do czegoś.  To 
Ty twierdzisz, że ochrona Javy jest niepotrzebna, dlatego, bo Ty jej nie 
potrzebujesz.  I to jest tu jedynie przesadą.


> Np. standard ISO C++ wskazuje, że rzutowanie np. void* na np. void (*)()
> jest nie dopuszczalne. Na normalnych maszynach tak wolno dlatego
> kompilatory sypią tylko warningi. Bo program mieści się wtej samej pamięci
> co dane i wskaźnik wolno Ci tak przeinterpretowywać (rzutowanie wskaźnika z
> obiektu void na wskaźnik do funkcji. Ale są maszyny w architekturze
> Harvardzkiej, czyli pamięć danych jest czymś innym niż pamięć programu -
> cała masa różnych DSP. I tam to jest zabronione, nie dlatego, że takie
> chłopaki mają widzimisie. Tak jest sprzętowo i wymuszane bezpieczeństwem
> (dane procesowe mogą wylatywać, moga się nie mieścić, program ma działać,
> oczywiście programista powinien zadbać o to czy tamto, ale już sprzętowa
> separacja daje minimalną ochronę). I C++ wspiera to i warning staje się
> błędem.

Fajnie.  Szkoda tylko, że te "normalne" maszyny, to większość tych, na 
które mierzy się dziś.  I gdzie niestety, jest co najwyżej namiastka 
tego o czym tu piszesz.

Dla kontrastu, *każda* Java SE ma security-managera od zawsze.  Czujesz 
różnicę?


>>> Są rzeczy specyficzne dla windowsa i dla unixa, i jak chcesz je
>>> użyć, to szybko kończysz na JNI, czy się mylę?
>> Bardzo się mylisz.  Większość kodu pod JVMy, przynajmniej wedle moich
>> danych, pisze się dziś w Javie.
> 
> A jak? Może jakiś link. Mam trochę softu w C/C++ który chętnie podepnę do
> maszyny, czy też da się ominąć JNI?

Da się, np. na socketach (z mniej wydajnych też bazy danych, 
web-services, itp.).  Poza tym, ważniejsze jest to, że większość ważnych 
usług systemu jest już dostępna na platformie (podkreślam, że na SE Java 
się nie kończy), więc korzystanie z natywa, to już dziś duże hackerstwo 
w świecie Javy.

Bywa też nawet tak, że opłaca się przepisać natywa na Javę i to może Cię 
zdziwi, po to aby było _szybciej_.  Przykładem niech będą BigDecimal i 
BigInteger z java.math, które początkowo były zaimplementowane natywnie, 
a po przepisaniu w całości na Javę, stały się przynajmniej używalne.

Powód:  JNI jest odporny na wszelkie optymalizacje JIT.


> Tak więc nie ma co całego świata nawracać na jedyny słuszny
> język, bo takiego nie ma :-).

Oczywiście, że nie ma.  Są tylko lepsze i gorsze.  :)  (czytaj: 
bardziej, lub mniej nadające się do tego co chcemy osiągnąć, finito)


> Przeglądałem ją jakiś czas temu i coś tam odpalałem, ale nie byłem
> zachwycony. Do wolnych instalacji, i to trochę specyficznych ano się nawet
> nadaje. Ale nie 100k sampli na sekndę, to już dla niej za wiele. Oni
> pokazują sterowanie robotami, ale takie coś to da się zrobić w Matlabie.
> Bazują na bardzo grubym założeniu, że roboty 2 i 3 generacji, mają zadawanie
> trajektori vektorowo, czyli mówisz jaka trajektoria o podajesz parametry
> tak więc zanim robot się ruszy spokojnie policzysz następną, bo ruch trwa
> trochę czasu. Natomiast wątpię, że laser to obsłuży, który wymaga naprawdę
> szybkich sterowań i wymaga bardzo dużej precyzji w samplowaniu.

Trochę to do mnie, przyznam, nie trafia.  Nie znam się na tym.  Ale za 
wnioski dziękuję.


>> A!  I tu już, jak w każdym zresztą zaufanym sofcie, ochroną bym się
>> najmniej przejmował.
> 
> No więc właśnie. O to chodzi, że czasem ficzery robią się bugami.

Nie bugami!  Stają się zbędne.  I wtedy się je po prostu wyłącza.

> 
> Cieszę się, że zaczynamy wspólnie ustalać, że są miejsca gdzie jednak C++ ma
> miejsce i nie wypiera z tamtąd Javy, bo i tak to nie jest miejsce dla
> niej :-).

Też się cieszę.  Zwróć tylko też uwagę, że w drugą stronę, jak 
najbardziej.  :-)


piotr