🚀 go-pugleaf

Witam

Piotr Kobzda wrote:

>> Rozumiem. Ale nadal nie rozumiem zagrożenia, które teoretycznie coś może
>> wnieść do C++ z zewnątrz. Pomijam kwestię, że Ty możesz wnieść jakieś
>> śmieci w swoim kodzie. Chodzi mi o to co może zrobić ktoś z zewnątrz?
> 
> A czym byłoby "zewnętrze" dla Ciebie, gdybyś miał oprogramować np. taką
> usługę:
>
http://www.4java.ca/sharedTomcat.htm?PHPSESSID=acec7b605c17dd3400279ad54fec91d1
> 
> ?

Mam swoje podejście do takich konstrukcji, oparte o zaawansowany MPI i
współdzialanie procesów. Przy czym mówię o MPI na wyższym poziomie niż MPI
użwane dla wieloprocesorów typu Cray, czy inne.

I powiem tak, chula i jeszcze ma zaletę, że przenosi się pomiędzy
komputerami w sieci, czyli nawet nie muszę usługi odpalać na głównej
maszynie serwera. Ot taki rozproszony system (obiektowy).

Teraz pracuję, aby zrobić MVC oparte o to dla aplikacji mających GUI, czyli
odpalasz GUI zdalnie. Szyfrowanie i takie tam są jakby kwestią naturalnego
pluginu w systemie. Ale dopiero mam szkielet więc nie mogę wypowiadać się o
sukcesie. W każdym razie np. podpinanie wielu widoków do jednego modelu
jest całkiem luzackie, poprostu odpalasz dodatkowy proces i jeśli proces
macierzysty uznaje taką opcję, po prostu udostępnia dane dla dodatkowego
widoku po stronie servera nic nie zmieniam.
 
> No zważywszy, że JDK to raptem 6,5 MLOCów, powiedzieć kategoryczne nie
> to oczywiście nonsens...  I choć lista dotychczas wykrytych bugów w
> zabezpieczeniach Javy jest zadziwiająco krótka (mam nadzieję, że już tam
> trafiłeś), to jednak każdy ze zgłoszonych alertów (na dziś 342 w
> "category:security" od roku 2002), to potencjalna szansa zrobienia "a ku
> ku", więc na "na pewno nie" nie licz u mnie.

Cieszę się, że nie idealizujesz. Dyskusja zaczyna mi się coraz bardziej
podobać.
 
> Możliwość jest, nieporównywalnie mniejsza jednak, niż w przypadku
> ewidentnych dziur.

Zgadza się. Ale ja nie mierzę aż tak wysoko.

> No coś Ty?  To co trzeba robić w tych środowiskach, to zupełnie poza
> tematem, tam to nawet do zmiennoprzecinków do niedawana nie było, jak
> myślisz, dlaczego?  Myślisz, że w obliczu ograniczeń platformy,
> dodatkowa ochrona kodu, która przecież za darmo nie jest, to rzecz
> priorytetowa?

No tak. Więc są potrzebne języki jakby naturalne dla takich systemów, więc
potępianie wszystkiego w czambuł jest przesadą. 
 
> Java właśnie po to powstała, aby unifikować te wszystkie sposoby.  Co
> nie jest może zawsze pożądane, niemniej jak się okazuje, w wielu
> przypadkach jest wygodne.

Zgada się, ale tego nikt niepodnosił w tym wątku, a właśnie takie wymagania
są stawiane dla C++, żeby był w miarę nie unifikujący.

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.
 
>> 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?
 
> I do tego, ja też bym Javy, o której mówimy nie użył.

No więc widzisz, zaczynamy określać taką czy inną niszę gdzie C/C++ są
lepsze. Nie ma znaczenia czy to jest 20 czy 10% rynku jest i stale bedzie.
Tak jak języki funkcyjne mają swoją niszę, czy Prolog też ma swoje
zastosowania. Tak więc nie ma co całego świata nawracać na jedyny słuszny
język, bo takiego nie ma :-). Nikomu nie każę forbić frontendu do SAP'a w
C++. Ale silniki baz danych raczej w Javie nie są pisane (chociaż jest taka
mała baza danych napisana w Javie), ale duże bazy to już nie.
 
> Musiałaby to być implementacja JSR-1, np. JamaicaVM
> (http://www.aicas.com/jamaica.html) -- choć co do jej jakości, musiałbym
> się najpierw przekonać, a nie mam jak dotąd takich potrzeb, może więc Ty
> ją wypróbujesz?  (W ewentualnych wynikach jestem oczywiście
> zainteresowany)

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.

> 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.
 
> Nadal jednak podtrzymuję zdanie, że mieć ochronę, która w razie potrzeby
> jest niezawodna (nawet jeśli tylko w teorii), jest lepiej, niż mieć ją
> dziurawą (co wykazane zostało).

Ale ja nie mówię, że Javę, czy C# należy wywalić w czambuł. Chociaż wolę
Javę niż C# zewzględu na to, że Microsoft leje na przenoścność C#.

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 :-).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/