To nema nikakve veze sa programskom podrškom za razvijanje takvih programa.
Mislim linux i skaliranje...lolz....sve do jučer je ispred poziva svakog syscalla bio lock_kernel(). Grepaj malo 2.4 sorseve pa se divi tom divnom non-preemptive, SMP-unsafe kernelu.
Citat:
Mogao si sve to da uradiš i na Javi. Imaš na primer JavaBeans.
Što nije nikakav argument za linux, jer java ima i win implementaciju (bolju i konzistentniju čak, jedna ali vrijedna, hehhe).
Citat:
Uostalom, .NET zasnovane aplikacije možeš i da pišeš i da "ćeraš" pod Linuxom.
Samo parcijalno... jesi čuo da netko u enterpise okruženju koristi Apache/mod_mono kao zamjenu za nativnu .net podršku u IIS-u?
Ja nisam.
Evo Munchen nešto experminatira...na kraju su jadničci morali zavrtiti windoze pod VMware, heheh....vidjet ćemo još o tome kako su prošli, da li su troškovi prelaska donijeli manji TCO u konačnici :)
Citat:
Ivan Dimkovic:Takodje, Windows 2003 i nove verzije XP (SP2) su kompajlirane sa potpuno novom CRT bibliotekom koja ni nema opasne funkcije koje su ranije bili meta za razno razne exploite.
Istina istina :) /GS i /SAFESEH u userlandu, DEP, NX bit...jako dobre stvari.
Citat:
U novom Visual Studio-u 2005 ni ne mozes da ga nateras da ti prihvati stare nesigurne pozive, period.
Hehe, vidjeti za početak
ovo
Također, vrlo je važno reći da SafeCRT biblioteka je trenutno u procesu
standardizacije i da je MS taj koji to gura. Inače se na svakoj platformi koriste raznorazni hackovi za sl. svrhu, tako da je ovo jako dobra stvar.
Znači vjerojatno tamo negdje za koju godinu će gcc postati compliant sa ovim novim safe extenzijama jezika, što dobijate sa windozom već danas za dž :)
Također je vrlo zanimljivo u VS2005, ako uradiš ovako nešto prije početka koda:
Code:
#define _CRT_SECURE_COPP_OVERLOAD_STANDARD_NAMES 1
automatski se unsafe verzije expandiraju na safe (strcpy() na strcpy_s() i sl.) :)))
Ovo naravno nije uvijek primjenjivo, ali je zato jako kul kad jest :)
Pogledajte recimo ovaj nedavni interview o tome kako će ProPolice (sigurnosna extenzija gcc-a) raditi na GPL kupusuri i što o tome misle BSD developeri koji su ga napravili:
Citat:
Marc Espie: Nope. gcc 3.4 adds a whole set of C++ problems we don't want to deal with right now (more stringent syntax, catastrophic memory increases in some cases), and gcc 4.0 is definitely not mature technology yet, and it's even slower than gcc 3.4.
ORN: In a previous interview I did with Richard Stallman, he stated that gcc will include ProPolice. I hope this is this good news for you. Is there any other technology that you would like to see imported into gcc?
Marc Espie: OK, this might be the scoop you're looking for.
This is not news to me. This is definitely not good news. In this instance, Richard was all talk, and no action. There is absolutely nothing going on that indicates that ProPolice will be a part of future GCC releases.
Let me publicize that more. The GCC people are going to say they haven't had any luck collaborating with Etoh Hiroaki.
I've inquired into the problem, I've offered to help by acting as liaison between the GCC developers and Etoh Hiroaki. I got a lukewarm response at best.
Right now, the ProPolice technology is not considered stable enough for inclusion in GCC. Technically, the stuff Etoh does is a nice hack that plays interesting games with GCC internals. Those games are actually not really supported inside of GCC. (ProPolice assumes the frames have a given internal representation, which is 99 percent the case in practice, but is not part of the GCC internals' contract.)
And this is it--this is as far as ProPolice integration so far has gone. Richard asked for ProPolice to be integrated, which does not cost him anything. It's just a PR move, as far as I'm concerned. No resources have been devoted in actually pushing for ProPolice to be integrated.
The GCC people are handling other stuff, which is more important for them, which is something I quite understand.
There is absolutely nothing going on where ProPolice integration is concerned.
Yes, there's a lot of work. Ask the OpenBSD developers how many issues we had to solve in gcc in taking ProPolice from the "proof of concept" stage to "integrated compiler technology in the gcc we ship." Hundreds of hours. Sweat and blood.
Well, right now, ProPolice stops at GCC 3.4. No one has a working ProPolice for GCC 4.0. No one is devoting enough resources to ensure this will happen. And you think we will switch to GCC 4.0? Think again.
Instead, GCC 4.0 will ship with a framework called mudflap, which does about as much as "flap, flap, flap" flying through code. It catches one valid bound violation every April the 1st, and complains about valid code every other day of the year.
No ProPolice in sight.
Hah, da nema MS-a, što bi jadni linuxaši umrli od buffer overflowa :))
Re: Windows vs Linux - programiranje
Re: Windows vs Linux - programiranje