From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Piotr Kobzda wrote:
> Rzeczony wcześniej String np. jest w Javie immutable, nie dlatego, że
> implementujący go zaufali dobrej woli programistów, ale dlatego, że ma
> _zabezpieczone_ wnętrze.
Ale powiedz mi, o co chodzi z takim bezpieczeństwem. Kto napada Twoją
aplikację w takim sensie. Jak dostaję/kupuję jakąś bibliotekę, to czy moim
pierwszym odruchem jest wywalenie jej do góry nagami?
> Wiesz co mógłby zrobić servlet na dużym serversze, gdyby takiej
> gwarancji nie było? Zagrozić mógłby potencjalnie nie sobie, ale
> wszystkim hostowanym aplikacjom.
Ale, jak? Nie kapuję jak może zagrozić. Jest napisany skompilowany,
przetestowany, co się może wydażyć?
> Tymczasem, podobnie jak Stringa, nie boję się przekazać obcemu kodowi
> unmodifiableSet(), czy czegokolwiek chronionego dostępem, bez obawy, że
> coś się z tym niedobrego stanie, czy choćby i niechcący, zrobi mi ktoś
> coś złego "w środku"...
No widzisz unmodifable, rozumiane jako const, czy jako immutable?
>> Wydaje mi się, że nie o to chodzi w programowaniu i w bezpieczeństwie.
>
> Nie wiem o co chodzi w programowaniu. To jednak o czym mówimy, to
> _bezpieczeństwo_, jakkolwiek Ty byś na to nie patrzył.
To znaczy właśnie nie kapuję jakie to jest bezpieczeństwo i przez czym?
Jeżeli przed błędami programistów, to jaktycznie problemem w kodzie C++ są
rzutowania wzięte z C.
Reszta ewentualnych szkód nie dzieje się przez przypadek. Więc nie wiem
przed czym mam się zabezpieczać.
> Oczywiście, bezpieczeństwo nie na tym się kończy, tu dopiero tak
> naprawdę się zaczyna (o czym we wskazanych wcześniej papierach też sporo
> jest...). Bez tego jednak, nie ma sensu iść dalej...
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?
> Żaden ze znanych mi systemów na taką swobodę nie pozwala.
DOS? Systemy, a w zasadzie loadery programów na małe procki.
> Tu mówimy jednak o dość precyzyjnych zabiegach, które na poziomie C++ są
> możliwe. Na poziomie platformy Javy (oczywiście, nie tylko) nie.
Nie; czy trudno? To jest różnica. Bo jeśli trudno, to złośliwiec też Ci
sypnie aplikację.
Poza tym cały czas zapominasz o bardzo prostym fakcie, że języki wysokiego
rzędu nie sa tak wszędobylskie jak C i C++.
Zauważ, że na komórki jest JVM ME, ale nie jest tak, że ona eliminuje
system. Zanim odpalisz JVM, to starują ci normalne programy napisane w C i
C++. Szczególnie silny tu jest Symbian OS, który ma całkiem dobry
kompilator C++ - nie znam jego biblioteki standardowej, ale komnpilator
jest ok jak na taki mały sprzęt. Poza tym JVM ME to nie za dużo potrafi.
A ostatnia sprawa to kwestia wykorzystania naturalnych zasobów danego
systemu/sprzętu. JVM dość unifikuje systemy i sprzęt (z tym są kłopoty), bo
JVM w ogóle ma problem ze sprzętem, ale to pominę skupię się na samym
systemie. Są rzeczy specyficzne dla windowsa i dla unixa, i jak chcesz je
użyć, to szybko kończysz na JNI, czy się mylę?
Np. użycie użądzeń unixowych, czy typowych raw unix socket, albo sprawa
pracy z ramdyskami. ale nie izolowanymi od systemu. Bo w JVM możesz zrobić
ramdysk i możesz tam nawet zapuścić kompilację kodu i w ogóle różne rzeczy.
Jednak ZTCW do tego ram dysku nie ma dostępu żaden inny proces systemowy.
Albo dalej kazdy system ma swoje komendy wywłaszczające zadania. Jak to
użyć? Raz z kolegą na linuksie odpaliliśmy sterownik który pracował w cyklu
100kHz, czyli odczyt danych, wyznaczenie sterowania, przekazanie sterowania
na zewnątrz zabierało 10[us]. Ale po każdym takim teście sterowania, które
nie było wykonywane a muzo, tylko na żywym sprzęcie (drivery do lasera),
zegar systemowy czasu rzeczywistego (dla RTlinuxa) opóźniał się o czas
eksperymentu. Już nie mówię o innych usługach systemu, które wisiały. Itd.
itp. są rzeczy których Java nie oferuje, bo nie powinna. A ja właśnie
takich spraw dotykam i dlatego wolę mieć niebezpieczny jezyk C++ czy C,
który kiedy potrzebuję usłuży mi nisko osadzonymi w systemie usługami.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Piotr Kobzda wrote:
> Seweryn Habdank-Wojewódzki wrote:
>
>> A czy nie da się uzyskać dostępu? Są takie paskudne opcje rzutowania
>> objektów na moje objekty i czy to się nie powiedzie?
>
> Da się. Jak się o to umiejętnie poprosi. "A to", to właśnie przykład
> refleksyjnej prośby o dostęp. Można też wykorzystać np.
> PrivilegedActions, Guard'y itp. Wszystko to jednak, pod ścisłą kontrolą
> SecurityManager'a, tudzież Twojego kodu zawsze pozostanie.
>
> Żadnego paskudztwa.
Rozumiem. Ale zadam jeszcze raz naiwne pytanie, po co? "Po co" rozumiane nie
jako "bez sensu" tylko w jakim celu?
Może JVM przejmuje funkcje, które powinien spełniać system? Rozumiem taką
troskę, bo Windows jest dziurawy jak sito, Solaris jest mocno
niedopieszczony, linux jest często eksperymentalny (co nie zawsze jest
równoważne z byciem dziurawym, ale przy pytaniu o bezpieczeństwo
eksperymantalność nie jest mile widziana).
Ale są systemy bezpieczniejsze. Sieciowe bezpieczeństwo AIX, HPUX, czy nawet
FreeBSD. Maszyny wieloprocesorowe np. z UNICOS'em na pokładzie oraz
dedykowanymi kompilatorami typu PGI, które "natywnie" używają MPI.
Bezpieczeństwo typu RT dają np. LynxOS, QNX, VxWorks, OpenVMS.
Dotego dochodzą sprawy sprżetu zarówno wewnętrznego jak i zewnętrznego - nie
ma szans zunifikować wszystkiego - uważam że to dobrze.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Adam Karpierz wrote:
> Użytkownik "Piotr Kobzda" <pikob gazeta.pl> napisał:
>
>> Żaden ze znanych mi systemów na taką swobodę nie pozwala. Tu mówimy
>> jednak o dość precyzyjnych zabiegach, które na poziomie C++ są możliwe.
>
> Sprecyzujmy i nie demonizujmy.
> Te zabiegi nie sa ani finezyjne ani precyzyjne
> Te zabiegi sa ze tak delikatnie powiem typu 'pala w leb'.
> Wlasnie to jest bolesne ze na takie typowo 'stadionowe' zagrywki
> C++ jest nieodporny.
QA + grep i stadionowy programista leci z dymem.
Jeżeli robi taki sztuczki celowo, to co wtedy? Ficzer czy bug?
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: "Adam Karpierz" <karpierz _NOSPAM_python.pl>
Subject: Re: Groovy
Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail wp.pl> napisał:
>> Sprecyzujmy i nie demonizujmy.
>> Te zabiegi nie sa ani finezyjne ani precyzyjne
>> Te zabiegi sa ze tak delikatnie powiem typu 'pala w leb'.
>> Wlasnie to jest bolesne ze na takie typowo 'stadionowe' zagrywki
>> C++ jest nieodporny.
>
> QA + grep i stadionowy programista leci z dymem.
Czlowieku przestan sie osmieszac :)
QA ma inne cele i o kodzie wie tyle co nic.
Jesli Cie tego na studiach doktoranckich uczyli to lepiej zostan
na uczelni bo zderzenie z przemyslem moze spowodowac
u Ciebie raptowna chorobe Basedowa.
> Jeżeli robi taki sztuczki celowo, to co wtedy? Ficzer czy bug?
No wlasnie ?
Kto powie 'nie wolno' nawet gdyby zobaczyl a powiem mu
ze w takim razie cofne to ale 'nie bedzie dzialac' bo sie nie da
(teoetycznei zgodnie z prawda). I co ?
A 'dziala' to w przemyslowym IT slowo magiczne.
Usprawiedliwia i 'namaszcza' wszytsko !.
Dlatego jest tak wazne zeby sie faktycznei nie dalo
(jezyk nie pozwala) a nie zeby politycznie zabraniac.
AK
From: Marcin 'Qrczak' Kowalczyk <qrczak knm.org.pl>
Subject: Re: Groovy
Dnia 17-05-2007, czw o godzinie 01:21 +0200, Adam Karpierz napisa=C5=82(a):
> Kto powie 'nie wolno'
Ten sam, kto m=C3=B3wi, =C5=BCe nie wolno nazywa=C4=87 wszystkich zmiennych
dwuliterowymi nazwami ani robi=C4=87 funkcji na 5000 linijek. To te=C5=BC c=
hcesz
wymusza=C4=87 na poziomie j=C4=99zyka, czy te=C5=BC wystarczy, =C5=BCeby pr=
ogrami=C5=9Bci
kierowali si=C4=99 ostrzejszymi kryteriami ni=C5=BC "u mnie dzia=C5=82a"?
> Dlatego jest tak wazne zeby sie faktycznei nie dalo
> (jezyk nie pozwala) a nie zeby politycznie zabraniac.
Nieprawda, z regu=C5=82y nie jest wa=C5=BCne.
Jedyna sytuacja, kiedy jest wa=C5=BCne, to piaskownica pozwalaj=C4=85ca uru=
chamia=C4=87
kod, kt=C3=B3remu nie ufamy. Ona i tak wymaga du=C5=BCo wi=C4=99cej mechani=
zm=C3=B3w
ochronnych ni=C5=BC egzekwowanie prywatno=C5=9Bci i C++ nigdy do tego nie
aspirowa=C5=82o.
--=20
__("< Marcin Kowalczyk
\__/ qrczak knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Adam Karpierz wrote:
>>> Wlasnie to jest bolesne ze na takie typowo 'stadionowe' zagrywki
>>> C++ jest nieodporny.
>>
>> QA + grep i stadionowy programista leci z dymem.
>
> Czlowieku przestan sie osmieszac :)
> QA ma inne cele i o kodzie wie tyle co nic.
E tam. Nawet open sourcowy programi CCCC wychwytuje pewne trywialne bugi w
programie i pewne niebezpieczne konstrukcje.
Zresztą co za problem machnąć programik np. w pythonie albo w samym C++,
który szuka w kodzie rzutowania C like? I jeszcze paru innych kłopotliwych
spraw.
Nie rozumiem, czemu traktujemy programistę jako wrednego psychola, który
chce szkodzić.
> Jesli Cie tego na studiach doktoranckich uczyli to lepiej zostan
> na uczelni bo zderzenie z przemyslem moze spowodowac
> u Ciebie raptowna chorobe Basedowa.
Może.
>> Jeżeli robi taki sztuczki celowo, to co wtedy? Ficzer czy bug?
>
> No wlasnie ?
> Kto powie 'nie wolno' nawet gdyby zobaczyl a powiem mu
> ze w takim razie cofne to ale 'nie bedzie dzialac' bo sie nie da
> (teoetycznei zgodnie z prawda). I co ?
No właśnie, co?
> A 'dziala' to w przemyslowym IT slowo magiczne.
> Usprawiedliwia i 'namaszcza' wszytsko !.
Tak? A w takich cudach jak przy wyznaczaniu poprawności kodu, działa nie
wystarczy. Są wymagania, kiedy działa teraz nie oznacza działa za chwilę.
I tu języki nie pomagają.
> Dlatego jest tak wazne zeby sie faktycznei nie dalo
> (jezyk nie pozwala) a nie zeby politycznie zabraniac.
Myślę, że nie.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Marcin 'Qrczak' Kowalczyk wrote:
> Jedyna sytuacja, kiedy jest ważne, to piaskownica pozwalająca uruchamiać
> kod, któremu nie ufamy. Ona i tak wymaga dużo więcej mechanizmów
> ochronnych niż egzekwowanie prywatności i C++ nigdy do tego nie
> aspirowało.
Ja tylko się zastanawiam, czy to nie jest aby zadanie systemu, a nie języka.
Na X'ach, jak coś się zepsuje to szkodzi to tylko userowi który to odpalił.
W minixie nawet usługi oferowane przez moduły do mikrojądra sa w zamierzeniu
tak pisane, że jak coś palnie to nie ma problemu.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: A.L. <fela 2005.com>
Subject: Re: Groovy
On Thu, 17 May 2007 00:15:51 +0200, Seweryn Habdank-Wojewódzki
<shw_mail wp.pl> wrote:
>Witam
>
>Adam Karpierz wrote:
>
>> Użytkownik "Piotr Kobzda" <pikob gazeta.pl> napisał:
>>
>>> Żaden ze znanych mi systemów na taką swobodę nie pozwala. Tu mówimy
>>> jednak o dość precyzyjnych zabiegach, które na poziomie C++ są możliwe.
>>
>> Sprecyzujmy i nie demonizujmy.
>> Te zabiegi nie sa ani finezyjne ani precyzyjne
>> Te zabiegi sa ze tak delikatnie powiem typu 'pala w leb'.
>> Wlasnie to jest bolesne ze na takie typowo 'stadionowe' zagrywki
>> C++ jest nieodporny.
>
>QA + grep i stadionowy programista leci z dymem.
>
QA nawet nie oglada kodu. Co wiecej, QA w ogole nie wie ze jakis kod
istnieje.
Jyz raz sugerowalem ze niewiele Pan wie o przemyslowym wytwazraniu
oprogramowania, a teraz to ponaiwam.
A.L.
From: "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl>
Subject: Re: Groovy
Seweryn Habdank-Wojewódzki <shw_mail wp.pl> napisał(a):
> Witam
>
> Piotr Kobzda wrote:
>
> > Seweryn Habdank-Wojewódzki wrote:
> >
> >> A czy nie da się uzyskać dostępu? Są takie paskudne opcje rzutowania
> >> objektów na moje objekty i czy to się nie powiedzie?
> >
> > Da się. Jak się o to umiejętnie poprosi. "A to", to właśnie przykład
> > refleksyjnej prośby o dostęp. Można też wykorzystać np.
> > PrivilegedActions, Guard'y itp. Wszystko to jednak, pod ścisłą kontrolą
> > SecurityManager'a, tudzież Twojego kodu zawsze pozostanie.
> >
> > Żadnego paskudztwa.
>
> Rozumiem. Ale zadam jeszcze raz naiwne pytanie, po co? "Po co" rozumiane nie
> jako "bez sensu" tylko w jakim celu?
>
> Może JVM przejmuje funkcje, które powinien spełniać system?
Ktos tu czegos nie rozumie. By wynullowac atrybut w obiekcie nalezy wykonac
ciag instrukcji bytekodowych. Za przypisanie atrybutu jest odpowiedzialna
instrukcja putfield.
p.field = 10;
generuje JVM code taki:
aload_1 ; push object in local varable 1 (i.e. p) onto the stack
bipush 10 ; push the integer 10 onto the stack
putfield xyz/ClassXYZ/field I ; set the value of the integer field
p.field to 10
zatem czy ktos probuje dobrac sie do cudzych pol prywatnych jest weryfikowalne
na poziomie bytekodu. Jesli ktos napisze paskudny bytekod, to weryfikator JVM
go poprostu nie przepusci i tyle. Zadnymi rzutowaniami ani niczym innym tu nie
pomozesz.
A.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
From: "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl>
Subject: Re: Groovy
Piotr Kobzda <pikob gazeta.pl> napisał(a):
>
> I do tego, ja też bym Javy, o której mówimy nie użył.
>
> 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)
BTW wszystko wskazuje na to Java Real Time za jakis czas zostanie
przetestowane w NASDAQ:
"Next came the announcement for version 2.0 of the Sun Java Real-Time
specification (Java RTS), along with a tantalizing example of how easily Java
technology-threaded applications can be ported to Java RTS. In this case, he
demonstrated that you can simply change instances of java.lang.Thread to
javax.realtime.RealtimeThread, and you immediately inherit all of the power of
Java RTS technology.
Green then introduced Anna Ewing, CIO of the NASDAQ exchange. NASDAQ is
currently running its trading technology on the Java platform. NASDAQ
pioneered electronic trading 36 years ago, and its systems are considered the
fastest in the industry. In fact, at any point in time, NASDAQ may need to
process over 150,000 transactions per second. With that in mind, Ewing talked
about how the NASDAQ exchange will be converting from Java to Java RTS
technology in the near future and how important compatibility with Java
technology is to NASDAQ's market. "We are currently working with your team on
prototyping on next-generation platform for real-time Java. We love how moving
from Java to Real-Time Java is very easy.""
To bylo na niedawnej JavaOne.
Nawiasem mowiac: 150k transakcji na sekunde. To cholernie duzo.
A.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
A.L. wrote:
>>QA + grep i stadionowy programista leci z dymem.
>>
> QA nawet nie oglada kodu. Co wiecej, QA w ogole nie wie ze jakis kod
> istnieje.
>
> Jyz raz sugerowalem ze niewiele Pan wie o przemyslowym wytwazraniu
> oprogramowania, a teraz to ponaiwam.
Niewiele to nie znaczy nic.
http://www.programmingresearch.com/solutions/qacpp_benefits2.htm
http://www.programmingresearch.com/solutions/qaj2.htm
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Aleksander Galicki wrote:
> Nawiasem mowiac: 150k transakcji na sekunde. To cholernie duzo.
To dużo, tylko pytanie ile procków ile maszyn to będzie obsługiwać.
W C/C++ mieliśmy 100k na sekundę na jednym procku 2 lata temu + system
linuxRT, czyli system patchowany pod RT, a nie RT.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
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
\/\/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Aleksander Galicki wrote:
> Ktos tu czegos nie rozumie. By wynullowac atrybut w obiekcie nalezy
> wykonac ciag instrukcji bytekodowych. Za przypisanie atrybutu jest
> odpowiedzialna instrukcja putfield.
Tak? A to ciekawe? Po kompilacji, to już nic się nie da zrobić. Chyba tylko
rozgrzebywać i to nie bytecode, tylko język maszynowy.
Chciałbym abyśmy rozróżniali dwa etapy.
1. Pisanie kodu - w C++ oparte o zaufanie, że user nie tnie gałęzi na której
siedzi.
2. Uzycie softu, życzę powodzenia w resetowaniu zamiennych prywatnych
wewnątrz czyjegoś kodu - jakiejś biblioteki.
> zatem czy ktos probuje dobrac sie do cudzych pol prywatnych jest
> weryfikowalne na poziomie bytekodu. Jesli ktos napisze paskudny bytekod,
> to weryfikator JVM go poprostu nie przepusci i tyle. Zadnymi rzutowaniami
> ani niczym innym tu nie pomozesz.
Nie da się do maila w kleiś tego co robi kompilator, więc nie pokazę co
można a czego nie można. W każdym razie po kompilacji, to takie numery nie
przechodzą, co najwuyżej dla klasy najwyższej i co najwyżej można
zresetować pimpla. To jest naprawdę mały kłopot. Jak ktoś zresetuje
najwyżej położony pimpl, to poprostu nie uruchomi modułu, funkcji etc.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: "yapann" <yapann odwa.pl>
Subject: Re: w?tpliwo?ć ad. systemowych przypadków użycia
Użytkownik "A.L." <fela 2005.com> napisał w wiadomości
> nonsensownego watku na tej grupie nie widzialem.
zwazywszy na twój aktywny w nim udział, wnioski nasuwają się same.
Proszę, nie przeszkadzaj.
From: ToJaJarek <tojajarek gmail.com>
Subject: =?iso-8859-2?q?Re:_czy_przypadek_u=BFycia_jest_wymaganim?=
On 16 Maj, 14:41, "yapann" <yap... odwa.pl> wrote:
> U=BFytkownik ""Piotr Dembi=F1ski"" <p... gazeta.pl> napisa=B3 w wiadomo=
=B6ci
>
> > Istniej=B1 tzw. dobre praktyki okre=B6lania wymaga=F1.
>
> zatem, czy uzna=B3by=B6 okre=B6lenie: 'przypadek u=BFycia jest wymaganiem=
' za
> niepoprawne, ze wzgl=EAdu na kt=F3r=B1=B6 z wytycznych wspomnianych prakt=
yk?
>
> Istot=B1 mojego pytania jest unikni=EAcie ra=BF=B1cych nieprawid=B3owo=B6=
ci w
> nazewnictwie i merytoryce podczas pos=B3ugiwania si=EA terminologi=B1 dob=
rych
> praktyk okre=B6lania wymaga=F1.
Mom zdaniem PU mo=BFe by=E6 wymaganiem ale nie musi. S=B3uszna uwaga
brzmia=B3a: czego oczekuje zamawiajacy?
Wymagania na system mo=BFna zamkn=B1=E6 stwierdzeniem: "system ma wspiera=
=E6
proces wystawiania faktur zgodnie z obowi=B1zujacymi przepisami,
pozwala=E6 na sporz=B1dzanie wymaganych przepisami zestawie=F1 i raport=F3w
dla urz=EAd=F3w.". Mo=BFna jednak spisa=E6 seri=EA interakcji z systemem
typu :logowanie, wprowadzanie danych kontrahent=F3w ..........." i
zabrn=B1=E6 w opas=B3e i pracoch=B3onne (czytaj kosztowne) dokumenty plus
skomplikowana (czytaj kosztowna) procedura zmian w projekcie.
W obu przypadkach s=B1 to jednak przypadki u=BFycia, kwestia ich
og=F3lno=B6ci. Rzecz w tym, =BFe im s=B1 one bardziej szczeg=F3=B3owe tym b=
ardziej
ograniczaj=B1 inwencj=EA wykonawcy i podnosz=B1 koszty zarz=B1dzania zmiana=
mi
w projekcie ale im s=B1 bardziej og=F3lne tym bardziej projekt nara=BFony
jest na ryzyko, =BFe klient nie odbierze produktu.
Ot moim zdaniem sztuka kompromisu. Dlatego ja jak okre=B6lam wymagania
to nie opisuj=EA ich od razu przypadkami u=BFycia (czym czymkolwiek innym
takim) a spisuj=EA cele jakie zamawiaj=B1cy chce tym programem
fakturowania osi=B1gn=B1c a moga to by=E6 np.: skr=F3cenie czasu wystawiania
faktur do 5 minut, minimalizacja b=B3ednych faktur do poziomu 1%, dost=EAp
do historii sprzeda=BFy z ostatniego roku, generowanie danych do
deklaracji podatkowych. To s=B1 cele biznesowe, taki opis pozwala na
okre=B6lenie zakresu projektu i odebranie go. Szczeg=F3=B3y interfejsu itp.
to etap projektowania i modelowania. W tym przypadku PU s=B1 narz=EAdziem
analizy i projektowania a nie okre=B6lania wymaga=F1.
From: "Aleksander Galicki" <tretete WYTNIJ.gazeta.pl>
Subject: Re: Groovy
Seweryn Habdank-Wojewódzki <shw_mail wp.pl> napisał(a):
> Witam
>
> Aleksander Galicki wrote:
>
> > Ktos tu czegos nie rozumie. By wynullowac atrybut w obiekcie nalezy
> > wykonac ciag instrukcji bytekodowych. Za przypisanie atrybutu jest
> > odpowiedzialna instrukcja putfield.
>
> Tak? A to ciekawe? Po kompilacji, to już nic się nie da zrobić. Chyba tylko
> rozgrzebywać i to nie bytecode, tylko język maszynowy.
>
> Chciałbym abyśmy rozróżniali dwa etapy.
>
> 1. Pisanie kodu - w C++
Pardon, ale mnie nie obchodzi jak to jest w C++, ja jedynie klaryfikuje jak
to jest w Javie. W Javie najnizszym poziomem jest bytekod i sporo z
dotychczas znalezionych dziur w Javie dotyczyla 'dziwnego' bytekodu. Ale to
bylo juz dosc dawno temu.
Odnosnie 100k transakcji. Pan nie specjalnie chyba sobie wyobraza jak takie
transakcje moga wygladac w podobnych do NASDAQ systemach. Ja tez tego nie
wiem dokladnie. Ale bylbym raczej bardzo zdziwiony gdyby do 150k transakcji
na sek NASDAQ mial mniej niz setka boxow/procesorow. Niezaleznie od tego w
jakim jezyku by to pisali. Jakis czas temu pisalem o zabawnych problemach
wydajnosciowych jednej z najwiekszych aplikacji w Ruby. Tam bylo ok 600 tr/
sek i musieli rozpraszac aplikacje i baze danych. 600, nie 150k. A i
zlozonosc transakcji w przypadku tamtej aplikacji byla raczej nieporownywalna
do tych w NASDAQ.
(proponuje pobawic sie i zobaczyc ilu procesorow potrzeba by Oracle
przetrawil 150k razy na sec 'SELECT 1 FROM DUAL')
A.
--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
From: Seweryn =?ISO-8859-2?Q?Habdank=2DWojew=F3dzki?= <shw_mail wp.pl>
Subject: Re: Groovy
Witam
Aleksander Galicki wrote:
> Pardon, ale mnie nie obchodzi jak to jest w C++, ja jedynie klaryfikuje
> jak to jest w Javie.
To dobrze. Ja też tylko klaryfikuje informacje o tymco wolno i kiedy, a
czego nie da sie zrobić i kiedy w C++.
> Odnosnie 100k transakcji. Pan nie specjalnie chyba sobie wyobraza jak
> takie transakcje moga wygladac w podobnych do NASDAQ systemach. Ja tez
> tego nie wiem dokladnie. Ale bylbym raczej bardzo zdziwiony gdyby do 150k
> transakcji na sek NASDAQ mial mniej niz setka boxow/procesorow.
> Niezaleznie od tego w jakim jezyku by to pisali. Jakis czas temu pisalem o
> zabawnych problemach wydajnosciowych jednej z najwiekszych aplikacji w
> Ruby. Tam bylo ok 600 tr/ sek i musieli rozpraszac aplikacje i baze
> danych. 600, nie 150k. A i zlozonosc transakcji w przypadku tamtej
> aplikacji byla raczej nieporownywalna do tych w NASDAQ.
> (proponuje pobawic sie i zobaczyc ilu procesorow potrzeba by Oracle
> przetrawil 150k razy na sec 'SELECT 1 FROM DUAL')
Rozumiem, ale transakcje bazodanowe to nie jedyna domena systemów RT. I to
też warto powiedzieć, czyż nie? Poza tym co Pan robi jak się Panu baza
danych dusi? czy system jest szybszy od bazy? Zapewne to jest kwestia
projeku zawierania transakcji, a to już nie jest kwestia języka, tylko
wiedzy ogólniejszej.
Pozdrawiam.
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
From: Piotr Kobzda <pikob gazeta.pl>
Subject: Re: Groovy
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
From: A.L. <fela 2005.com>
Subject: Re: Groovy
On Thu, 17 May 2007 09:37:07 +0200, Seweryn Habdank-Wojewódzki
<shw_mail wp.pl> wrote:
>Witam
>
>Aleksander Galicki wrote:
>
>> Nawiasem mowiac: 150k transakcji na sekunde. To cholernie duzo.
>
>To dużo, tylko pytanie ile procków ile maszyn to będzie obsługiwać.
>
>W C/C++ mieliśmy 100k na sekundę na jednym procku 2 lata temu + system
>linuxRT, czyli system patchowany pod RT, a nie RT.
>
To zalezy od definicji "tranzakcji".
A.L.
From: Piotr Kobzda <pikob gazeta.pl>
Subject: Re: Groovy
Piotr Kobzda wrote:
[...]
> Do których to BTW ja pewnie po prostu VMWare bym użył...
No, z tym to przesadziłem. Zwykła JVMa na każdego usera w zupełności
widzę tu wystarcza:
http://www.4java.ca/faq.html#q98984
Resztę załatwia Apache. Czyli nie trzeba nic wymyślać.
piotr
From: "yapann" <yapann odwa.pl>
Subject: narzędzia wspomagające pracę z przypadkami użycia
czy znacie jakieś edytory PU, bądź inne CASE do pracy z przypadkami użycia?
Czy ktoś pracował z 'UC Workbench'?
From: Marcin 'Qrczak' Kowalczyk <qrczak knm.org.pl>
Subject: Re: Open Source, patenty i Microsoft
Dnia 15-05-2007, wto o godzinie 11:58 -0500, A.L. napisa=C5=82(a):
> "Microsoft takes on the free world
> Microsoft claims that free software like Linux, which runs a big chunk
> of corporate America, violates 235 of its patents. It wants royalties
> from distributors and users. Users like you, maybe. Fortune's Roger
> Parloff reports."..
To blef, FUD.
http://7thguard.net/news.php?id=3D5583
http://jakilinux.org/newsy/to-fud-nie-fakty/
http://showusthecode.com/
--=20
__("< Marcin Kowalczyk
\__/ qrczak knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Mariusz Lotko <imie.nazwisko wp.pl>
Subject: Re: =?ISO-8859-2?Q?narz=EAdzia_wspomagaj=B1ce_prac=EA_z_przypadkami_u=BFycia?=
yapann wrote:
> czy znacie jakieś edytory PU, bądź inne CASE do pracy z przypadkami
> użycia?
Jedyne, co widziałem "wystającego ponad standard", to tworzenie kart CRC
w sposób półautomatyczny ze słownego (a raczej tabelarycznego) opisu UC.
Ale to już jakby krok dalej. Dostępne w Visual Paradigm for UML.
--
Mariusz Lotko
From: "Adam Karpierz" <karpierz _NOSPAM_python.pl>
Subject: Re: Groovy
Użytkownik "Seweryn Habdank-Wojewódzki" <shw_mail wp.pl> napisał:
> Rozumiem, ale transakcje bazodanowe to nie jedyna domena systemów RT. I to
> też warto powiedzieć, czyż nie? Poza tym co Pan robi jak się Panu baza
> danych dusi? czy system jest szybszy od bazy? Zapewne to jest kwestia
> projeku zawierania transakcji, a to już nie jest kwestia języka, tylko
> wiedzy ogólniejszej.
Obawiam sie ze Pan o czyms kompletnie innym mowi niz transakcje
na NASDAQ. Tam zapewne chodzi o transakcje _gieldowe_
a na taka sobie pojedyncza to zapewne jest wiecej niz jedno
'odwolanie' do bazy itp mediow :)
AK
From: "Adam Karpierz" <karpierz _NOSPAM_python.pl>
Subject: Re: Groovy
Użytkownik "Marcin 'Qrczak' Kowalczyk" <qrczak knm.org.pl> napisał:
>> Nie Panie kochany.
>> To problem badziewnego boosta ktory
>> nie wspiera _natywnego_ kompilatora dla Suna.
>
> Jeśli błędy są w poprawnym kodzie C++, to jest to wina kompilatora.
[..]
> Jak jest w tym przypadku? W czym są błędy?
Panie Qrczak zapewniam Pana ze w _przemyslowym_
programowaniu niewspieranie standardowego natywnego
kompilatora jest _zawsze_ wina biblioteki ktpr ago nie wspiera
bez wzgledu na to jaki by ten kompilator nie byl.
Tak sie sklada ze na Sun-nie natywnym kompilatorem jest
kosztujacy ciezkie pieniadze Sun C++ a nie zadne gcc.
AK