:) Marketing nélkül nem megy a dolog, de én a marketing alatt nem tisztára a reklámot (vagyis advertizingot értem), na de legyen igazad, habár akárhogy is nézed, a memóriakapacitás mindég gyorsabban fejlõdött mint a CPU teljesítmény, és ez a jövõben csak fokozódni látszik, tehát marketing ide vagy oda, szerintem jobban kell odafigyelni a kód sebességére mint a memóriaigényre. És aki programozik az tudja, hogy a kettõ alapjában nem fér össze, ha akarsz gyorsabb kódót akkor általában nem tudod a memóriaigényt is optimizálni, persze nem minden alkalommal de legtöbbször. Ami pedig a 10-évvel ezelõtti alkalmazásokat illeti, ha összehasonlítjuk õket a maiakkal akkor nagyon nagy a változás, funkcionálissan is de sokszor sebességben is, gondold csak el mire volt képes egy 3D Studio 4-es vagy most a MAX 8-as... persze az igaz, hogy az OO kód ezt a sebességi különbséget egy picit leszûkítette, de ha nem lett volna az OO akkor a mai komplexitású szoftver sem lenne, mert egyszerûen tiszta C-ben vagy ASM-ben egy MAX 8-ast lehetetlen megírni, elméletileg persze lehetséges, de nem lenne az a csapat aki ezt ki tudná hozni és még ha ebben is tévednék, akkor nem lenne az a csapat aki azt ki tudná hozni elfogadható idõn belül. Tehát minden technológiának megvannak az elõnyei és hátrányai, de legtöbbször éppen a lehetõ legjobban csináljuk, elméletben ugyan nem, de gyakorlatban sokszor lehetetlen kísérni az elméletet.
Ebben igazad van. Itt vagyunk mostmár 4GHz fele tartó procikkal, meg 10x annyi RAM-al, mint 10 éve, és az alkalmazások közel sem futnak gyorsabban, mint 10 éve. És annyi funkcionális bõvülés nem volt.
1. szted ki akarná megfizetni azt az 15000 ember egész napos munkáját? 2. egyáltalán nem igénye ez a felhasználónak. az az érdeke, h funkcionálisan használható legyen. mutass már nekem valamit a világban, ami tökéletes és sosincs vele gond. ezzel a felfogással biztos autód sincs és buszra se szoktál szállni, meg repülõn sem utazol. pedig a hiba bekövetkeztének esélye ugyan annyi (pl kocsinál), csak a következmények súlyosabbak. ennek ellenére használják az emberek. nemtom az sw-nek mér kéne teljesen tökéletesnek lenni. tudod egyáltalán, h az intel 4x86-os alaplapja volt az utcsó hw amit teljeskörûen leteszteltek?
nem is tudom minek eröltetem magam. egyértelmû, h egyáltalán nem vagy képben és még hajlandóságot sem mutatasz az érvek elfogadására. csak ugyan azt a bullshitet szajkózod.
"Pl. 2-3 év múlva nem lesz probléma (aprópénz lesz) 4 GB RAM-ot rakni a gépbe, am a mai átlag 8 szorossa lesz, de alig ha hiszem hogy addigra a CPU a mai átlag 2-3 szorossa is lenne."
Na ez megint egy marketing duma, már bocs :) Véletlenül nem marketing szakember vagy?
Mert ez olyan amit mondassz, hogy figyelj, vedd meg a Z.X.C autót ami ugyan aszfalton csak 20-al megy, de 2-3 év múlva mindenhol e-aszfalt lesz, amin fog tudni menni 200-al is.
Tehát a jelenbe nem elõnyös, de a jövõbe sem, mert azt feltételezed hogy a fejlõdés megáll. De nem áll meg, 2-3 év és megint itt egy új MS oprendszer egy új C%%%%++++ ami még 2x olyan lassú lesz 2x annyi erõforrást zabál (persze a programfejlesztés fele annyi ideig tart benne, ezért a programozók isteníteni fogják), tehát ha ugyanúgy rábeszéled a felhasználót hogy vegye meg, akkor megint csak lassan fog a gépén futni az alkalmazás, és így tovább örökkön-örökké, ergó sosem fog a felhasználó gépén olyan alkalmazás futni, amely azon megfelelõ sebességgel és nem a rendszert agyonterhelve mûködik. Tehát megint a felhasználó jár rosszul.
Neked meg az a bajod hogy végletesen be vagy szûkülve, azt fel kell fogni, hogy a felhasználót kurvára nem érdekli hogy 10-en dolgoztak a programján vagy 15000-en, hogy napi 5 órában vagy 24-ben, elvárja hogy a korszerûnek mondható hardverén a programok normális sebességgel és hibamentesen fussanak.
bármi változtatás csak jót tett volna a javanak :D ha sikerül ms-nek a cucc, akkor most nem örülhetnénk a .Net-ek. szal sun elérte, h erõs támogató helyett kapott egy mindent elsöprõ ellenfelet...
ugyan már, ms hova törekedett volna, amikor még csak 1 volt a sok kicsi sw cég között? akkor nem volt mit megtartania. egyszerûen kielégítette a piac igényét, ezért elterjedt.
Bár nyilván figyelembe vette a piaci igényeket is, de az MS szándékosan törekedett mindenféle eszközzel elérni a monopóliumot és megtartani azt. Lásd a Java megváltoztatására tett nem éppen dicsõ kisérlete.
#92 ha ze alatt azt érted, h nem programozási szentírásokat követett, hanem a piac valós igényeit próbálta kielégíteni akkor igazad van. én ezt inkább pozitívumnak veszem.
#91 félelmetes, mennyire nem vagy képben és ennek ellenére nem vagy hajlandó elfogadni a tapasztaltabbak állítását. tuti, h még 1 valós projektben sem vettél részt.
"a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elõ és az optimizálás meg a többi dolog csak másodlagos volt számukra."
Az MS azért lett sikeres, mert az üzleti oldalára koncentrált a szoftverfejlesztésnek, nem a technikai oldalára. Nem úgy ért el sikereket, hogy életképesebb szoftvert indított a versenyben, hanem úgy, hogy a versenyt alakította a maga termékéhez
Továbbra is az a véleményem hogy irreális hogy minden attól hangos hogy gyorsabb proci gyorsabb memória gyorsabb hardver...azzal senki se törõdik hogy a programozók lustasága/vagy a fejlesztést vezénylõ cég pénzéhsége miatt egyre lassabb programok jelennek meg. Tehát a hardver hiába gyorsul, ha a szoftver "költségkímélési szempontok" miatt lassabb lesz. Akkor legalább a korrektség miatt tájékoztatni kellene az átlagvásárlót, hogy azért kell kétévente új gépet vennie, mert a szoftvergyártó cégek minnél nagyobb haszonkulccsal akarnak dolgozni.
Egyébként a sebesség és erõforrásigény egy dolog, ma inkább a gond azzal van, hogy a szemét termékekhez hasonlóan szemét programok jelennek meg. Persze, a fejlesztõ mondhatja, hogy azért programoztam c#-ben mert basztam megtanulni programozni és szoros volt a határidõ, de 1. megtanulhatott volna programozni 2. szólni kell hogy a határidõ nem tartható, vagy a végeredmény szemét lesz.
Pont a Vistáról lehetett olyan cikket olvasni, hogy azért csúszott fél évet mert az MS vezetõje nem hitte el az egyik vezetõ programozója állítását, melyszerint az egész Vista fejlesztés úgy szar ahogy van, újra kell írni nulláról. Tehát a határidõre való hivatkozás nem éppen jó védekezés...
Korábban írta valaki az AMS-et, de én nem említettem az ASM programozást. Gyakorlatilag minden program elõbb utóbb AMS-ben (gépi kód szavasítva) fut, hiszen a proci azt érti, persze nem mindegy hogy ezt a fordító állítja elõ, vagy pedig maga az ember. Szerintem direkt ASM-ben való programozás specifikus esetekben lehet szükséges, pl. sebességkritikus részeknél. Nade ez nem azt jelenti hogy az egész alkalmazást ASM-ben kell írni (programozók ilyet nem gondolnának), hanem csak azt az adott részt (függvényt/szubritint/eljárást...) tehát akár a program kódméretének ezred vagy tízezred részét.
"de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni"
Utólag már nem lehet akármit megcsinálni. Az optimalizálás legeslegfontosabb része éppen a jó tervezés (nem csak adatbázisoknál). Az elsõdleges kérdés, hogy milyen adatokat kell egyáltalán tárolni, aztán jön az adatstruktúra és a munkafolyamatok felépítése, és végül a konkrét lekérdezések optimalizálása. Csak az utolsó fázist lehet utólag is könnyen elvégezni.
"mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet."
Általában nem nulláról kezdik. Ma már legtöbbször van egy régebbi rendszer, ami alapján a fontosabb üzemi paraméterek ismertek. Ha meg még nincs semmilyen korábbi adatbázis a cégnél, akkor sokkal-sokkal több idõt kell a tervezésre fordítani. Rettentõ költséges dolog utólag újratervezni az egész rendszert .
Az adabázis optimizálás vagy inkább nevezném tuningolás, egy extra komplex téma. És ha apró bázisról van szó akkor általában nem foglalkoznak vele, ha közepes bázisról van szó akkor már nem árt odafigyelni, míg massziv bázisok esetében a legfontosabb dolog. De minden esetben az SQL tuningolás egy komolyan kezelt vállalkozás kell, hogy legyen. Az adatbázis teljesítményét lehetetlen egyoldalúan növelni, vagyis szoros együttmûködésre van szükség a fejlesztõk az adatbázis adminisztrátorok az infrastruktúra vagyis rendszermérnökök (ide beleértem a rendszergazdákat is és a hálózati mérnököket is). Elõször is egy adatbázis teljesítménye nagyon függ az adatok struktúrájától, a normalizáció fokozatától (van ahol a denormalizáció gyorsít), az indexeléstõl, a hálozati forgalomtól (ez különössen érvényes amikor néhányezer kliens konkurensen lóg a rendszeren), stb. Tehát optimizálni az SQL kódot a többi nélkül nem nagyon érdemes, habár alapszabály, hogy oda kell figyelni a joins-okra és a subquery-kre, meg az ORDER BY-ra. És sokszor segít még az átlagos user pattern is, vagyis egyfajta Paretó diagram ami arról szól, hogy melyik adatcsoportot használják jobban, ezekre különössen odakell figyelni a tuningoláskor. Na, hogy ne dumáljak reggelig, az adatbázisok tudományának fele éppen a tuningolás, és ez nagyrendszerek esetében extra fontos, mert néhány extra CPU vagy extra szerver az évi költségeket képes jócskán megterhelni, mint licensz úgy karbantartási és energiaszámlákon keresztül, tehát ez egy olyan terület ahol az optimizáció nem elenyészhetõ, bár amikor nagyobb bázisokról beszélünk.
ezt egy fel pillanatig se kerdojelezem meg, de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni, mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet. Akkor aztan johet az oracle es kianalizalhatja magat es majd jol megmondja a statisztikai alapjan, hogy mi a szar meg mi a jo. Aztan ebbol elindulva - meg a felhasznalok epito otleteibol (lassu ez a szar) - mar lehet is optimalizalni. (szerintem)
egyelõre. de ha megfigyeled akkor láthatod, h azt is írtam, amint elterjednek a .netes programok, onnantól kezdve minden rendzser fejlesztõjének érdeke lesz implementálnija a frameworköt. és ebben semmi nem akadájozza meg, mivel teljesen nyílt a dolog. azon az osen, amin nincs framework, arra nem lehet .net-es progit írni...
Egyébként az nagy baromság, hogy a Vista csak biztonsági frissítésekeket tartalmaz. Nem is egyszer volt róla cikk itt az SG-n is, hogy teljesen újragondolták az egész platformot, majd félúton mégegyszer, amikor kiderült, hogy a HW nem a várt ütemben fejlõdik. És nem csupán a biztonságról van szó, sok más is javult (pl. memória kezelés). De az pláne vicces, hogy évekig a biztonság miatt fikázták az MS-t, és most hogy az új win legfõbb tulajsonsága a nagyobb biztonság, már azt mondják, hogy jó az XP is. Meg a win vs. linux vitákban is megy a fikázás, hogy milyen szar a win, aztán meg most kiderül, hogy semmi baj az xp-vel, nem is kell a vista.
"hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na."
Ott meg az SQL utasításokat kell optimalizálni. Az se könnyebb.
nem ertek veled teljesen egyet. mert persze hulyeseget nem fogsz leirni kodban, de peldaul meg veletlenul sem irtam volna 1.0-as frameworkon for ciklust foreach helyett pedig megmondtak, hogy sokkal lassab. es 1.1-ben ki is javitottak. aztan meg szamtalan ilyen van, pl most a 2.0-rol meseltek sokat a bemutato konferencian, hogy mi minden gyorsult. szoval en arra gondoltam, amikor azt irtam amit irtam, hogy a franc fog allandoan mindent IL kodra foditva leellenorizni, hogy ertelmesen foditja-e vagy sem.
Nezz meg egy switchet, hogy milyen lesz IL kodban :)
altalaban ervenyes, hogy real time dolgokat nem irnak ilyen nyelven -bar irtam mar valos ideju mozgaserzekelot. persze unsafe blokkban pointerekkel. ott erdemes pocsmorogni a sebesseggel, meg meregetni, de az, hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na.
hmm? ASM-ben sokkal könnyebb rossz kódot írni, mert ott nincs aki megakadályozzon, tehát lefoglalok a memóriából, és elfelejtem felszabadítani, akkor ez rossz kód, szintén beletömök egy long-ot értéket egy short-ba és ez is rossz kód, a biztonságról ne is beszéljünk, de még sorolhatnám, tehát ASM esetében a programozón múlik minden, mígy C-ben már nem annyira, habár ott is egy pici pointer aritmetika ha nem figyelünk oda zûrzavart okoz, C++ ettõl még egy picit többet segít a programozónak, C# meg már egész jó barátunk lesz. Szóval amit lejebb leírtam az áll, és oda kell figyelni, ismerni kell az architektúrát akármennyire is abstrakt szinten dolgozunk, de ha ASM-ben nyomjuk a dolgokat akkor sokkal de sokkal jobban oda kell figyelni, mert ott minden sorocska töllûnk függ, ellentétben a magasabb nyelvekkel ahol a könyvtárakban levõ funkciók, osztályok stb. kódja már elég jól van optimizálva, és széleskörûen van használva, ezért sokkal magasabb minõségre és biztonságosabb kódra támaszkodhatunk. Szóval ASM szerintem ma csak oda kell, ahol tényleg a teljesítmény a legfontosabb, vagyis olyan rutinok optimizálására amelyek sokszor futnak ezáltal sok ciklust és vagy memóriát takarítva meg. De a valóságban az az igazság, hogy nagyon kevés a jó kód, és már örülni szoktam, ha a kód átlagon felüli, és ha ehhez hasonlítanánk egy tökre csiszolt kódot akkor sirva fakadnánk, de a gyors fejlõdés és még gyorsabb elavúlás ehhez nem ad sem idõt sem szükséget. Ma egyszerûen sokkal fontosabb a funkcionális kód, aki nem hiszi, gondoljon a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elõ és az optimizálás meg a többi dolog csak másodlagos volt számukra. Tehát fontos a dolgokat meghatározott keretek közé rakni és úgy figyelni, ha csak egy vagy néhány dologra összpontosítunk akkor jobb ha nem is csináljuk, mert nem fog az ég világon semmit sem érni. Különben jól elmásztunk a Vistá-tól... vagy a Gartnertõl... :)
"A változások legnagyobb része ugyanis olyan biztonsági frissítésekbõl áll, amelyek különbözõ forrásokból jelenleg is hozzáférhetõk."
tovább:
"Az otthoni felhasználóknak azonban mindenképpen érdemes lesz belevágniuk a cserébe, már csak a nagyobb biztonság miatt is." De most akkor mirõõõl beszélünk?
Emiatt nem fogok 40rugót(vagy többet)kiadni. Nehogymá' a 'biztonság' miatt vegyek új csili-vili winfost
Mellesleg ezt az ablak elfordítgatósdit már egy sw program (is) tudja....
Persze, csak arról van szó, hogy pl. ASM-ben egy fokkal nehezebb nagyon rossz kódot írni (persze vannak kivételek), mint C-ben, és talán méginkább igaz ez a C++-ra, C#-ra, Javára, stb. Szal a programozón is sok múlik. De a legtöbben mégsem figyelnek oda. (Lásd pl. amit BlackRose írt a #78-ban.)
Különben egyértelmû, hogy a .NET a Windows világban sokkal jobb mint a Java, és én a Java-t csak a non-Windows világban támogatom, azért mert ott nincs .NET, a Mono ugyan fejlõdik, de legyünk komolyak, jelenleg nem igen fejleszt rajta senki sem komolyabb üzleti alkalmazást.
A másik dolog, pedig ha már a kód hordozhatóságának és optimizálásának a kombinációja a fõ téma, akkor az igazság ott van, hogy habár a fordítók verzióról verzióra jobbak, még mindég nem lehet tényleg optimális kódot írni, ha nem célozzuk meg az adott architektúrát, processzorcsaládot. Pl. nézzük a követlezõ peldát - na itt most C/C++ és ASM fánok mind meglesznek elégedve :)
int i; i = i / 4;
a fordtító a következõ kódot generálja...
mov eax, i cdq and edx, 3 add eax, edx sar eax, 2 mov i, eax
na most tegyük ugyanezt a következõ képpen...
unsigned int i; i = i / 4;
a fordító megtakarít egy csomó ciklust...
shr i, 2
tehát ismerve az x86 architektúrát, amikor lehet használom az unsigned tipust, másik architektúrákon ez lehet, hogy szintén jó lesz, de nem biztos, azokat is ismerni kell.
Na a baj ott van, hogy ha nem tudom ezt, és persze lusta vagyok gondolkodni, hogy az adott változónak csak pozitív értekei lehetnek vagy esetleg kell negatív is, akkor ezt én kihagyom és ezáltal lasabb tehát optimizátlanabb kódot írok. Na most ide bejön a MSIL a közepébe vagy a JVM kód, és most akkor itt sok minden magától a JIT-tõl függ, na a .NET elõnye itt éppen abban rejlik, hogy a JIT x86-ra optimizálódik, míg a Java esetében biztos, hogy szintén törekszenek az optimizálásra, de mivel több architektúrán kell, hogy dolgozzon ez vagy extra idõbe kerül a Sun fejlesztõinek, vagy egyszerûen kihagyják. Na szerintem ez is hozzájárul a Java és .NET közötti teljesítménykülönbséghez. Érdekes, de ha a fenti peldát C#-ban megírjuk a fordító jó MSIL kódot generál és a JIT is ugyanezt teszi, tehát megkapjuk az optimizált gépi kódot éppen úgy mintha sima C-ben írnánk, vagy ha akarjátok ASM-ben is.
Na jó, de az ASM meg a C közt sokkal nagyobb a különbség, mint a C és a C# között. A lényeg úgyis maga az algoritmus, azt meg semmilyen nyelv nem találja ki neked. Az, hogy a C#-ben bevezettek néhány magasabb szintû dolgot, az csak egy dolog, ezek viszonylag kis részei a programnak, és nem azok, amik felett órákig kell rágódni. Szóval azokat a függvényeket megírod több platformra, és készen vagy.
asszem kicsit elcsúsztunk, mert onnan indultunk ki, h C/C++ban optimálisabb végeredményt kapunk. nem arról volt szó, h maga a programozó hogy old meg egy metódust. Egy genercióval elõbbi példát véve, hiába kapunk ASMben optimálisabb kódot, mégis C/C++ben programozunk (sõt C helyett is inkább C++ban), mert egy komolyabb progi (akár egy játék) 10 év és 100 fõs csapat helyett 2 év 20 fõs csapatból is megvan. Ez a C#ban mégjobban elõjön, a létrejött kód újra hasznosíthatóbbságáról ([apto]de szép szó :)) nem is beszélve.
értem én. egyébként a kliens oldali kódnál teljesen más számít optimizációnak. nem kell azt szídni. ott a legfontosabb a forráskód mérete, aztán szünet, majd a teljesítménye. ezek a php-s dolgok is, meg olyanok, h méretüknél fogva egyáltalán nem éri meg optimizálni õket.
#70 ez is rendben, de a létrehozott objektum hiába foglal többet a memóriában, ha progrem többi része lehet semmenyit nem foglal, mert egy másik progival közösen használ (olvas!) egy memóriaterületet. ezért mondtam, h minnél több fut párhuzamosan, annál jobban elõjön. pl: memóriafoglalás párhuzamosan futtatott programnál (egységekben) .NetC# | JAVA 4 | 3 elindítom a köv progit: 6 | 6 kövnél: 8 | 9 10 | 12 12 | 15 14 | 18 és akkor még nem számoltam ide, h ekkora javanál már 6 JVM van betöltve.
de teljesen mind1, mert minden másban egyértelmûen jobb, tehát végeredményben .NetC# éri meg jobban.
Nem csak utólagos optimizálással lehet viszonylag optimális kódot készíteni, hanem átgondoltsággal, kiforrottabb programozási stílussal, jó programszervezéssel, stb. 5 perc gondolkodás többet ér, mint több óra "szívás". De milyen sokan megfeledkeznek errõl...
OK, de nem erre gondoltam. Pl. ha csinálsz egy új objektumot
blablaOsztaly blablaObjektum = new blablaOsztaly();
ez .NET-ben több memóriát zabál meg mint a Java környezetben, ha meg pl. ebbõl csinálsz egy 100.000-es array-t akkor ez akár 2-3 szor is több lehet mint a Java környezetben. De mégegyszer mondom, ugyanakkor 2x gyorsabban fogok dolgozni ugyanezekkel a nagy memóriazabáló objektumokkal mint a Javaban. Különben errõl valahol a TheServerSide.net-en vagy .com-on (egyik .NET, másik Java) lehetett olvasni, éppen a .NET 2.0-át és a Java 5-öt tették egymás ellen.
A kód optimizálása akkor fontos, ha a befektetett erõforrás és idõ megtérül azáltal, éppen úgy mint más dolgok által a listán. De a jelenlegi szoftverfejlesztésben a kód újrahasználhatósága (komponensek fejlesztése) általában a legfontosabb. A második helyen általában a kód biztonsági oldala van vagy bár kellene, hogy legyen, harmadik a kód jó azaz bõvíthetõ szervezése van. Az optimizáció a mai memóriaözönben meg processzor teljesítményben csak ritka alkalmazások esetén fontos, persze ez nem jelenti, hogy tökhülye kódod kell írni... de mégis megvan a határ. Általában azt tapasztalom, hogy azok a fejlesztõk akik ismerik a C/C++, vagy még jobb az ASM-emet is, azok jobb és optimizáltabb kódot írnak, azok az általában újkeletû fejlesztõk akiknek a Java vagy VB, Delphi volt a tanulóplatforma vagy még roszabb, webfejlesztéssel kezdték és JScript-en, PHP-én meg HTML-en lovagolnak, azok sokkal optimizálatlanabb kódot termelnek. Persze van kivétel, de általában ez a szabály. Különben a .NET-el tényleg lehet nemnormálissan optimizálatlan kódot írni, ezért kell elõbb jól megtanulni, sokan nekiûlnek és a Hallo World után produkciós kódot írnak, de ez általában szemét kód. Nem szeretem azokat akiknek nincs legalább 6-9 hónap erõss (mindennapi néhányórás) gyakorlatuk, egy csómó könyv elolvasásával együtt. Mennyire nem szeretem õket, annyira, hogy nem dolgozok velük. Különben a fejlesztõi munkakörnyezetemben 3 emberre számíthatok akik végig csinálták az ASM-tõl a C#-ig, és kimondott szabálynak tartom, hogy Phyton, Ruby, Perl vagy valami hasonló dolog is legyen az újjukban, mert a soknyelvûség nagyon jó effektussal jár mint az optimizált kód írására, úgy a jó szervezettségre is. Mégegyszer mondom nagyon kevés függ a platformtól, inkább az emberek határozzák meg a kód minõségét.
"A .NET mindenben jó, kivéve egy dologban nem, ez pedig a memóriaigény. És ennek megvan az oka, mivel abstrktizál kereskedni kell két dolog között ami nem éppen fér össze, nagyon neház ilyen magasszintû abstrakt környezetben memóriatakarékosnak és gyorsnak is lenni. Ha a .NET-et és a Java környezetet hasonlítom össze, akkor a .NET jóval gyorsabb, de jóval memóriaigényesebb is. Míg a Sun valahogy a kettõ közé beült, a Microsoft inkább a teljesítményt választotta."
ez addig igaz, míg 1db futó programról beszélünk. JVM-nél ha párhuzamosan elidítasz egy másik programot is, akkor egybõl minden erõforrás igénye megduplázódik. .NetFW-nél ez egyáltalán nem így mûködik. minnél több progit futtatsz párhuzamosan, annál jobban elõjön, h a .Net a jobb. példa: ha az elõzõ progi már betöltött egy osztály könyvtárat, akkor az újonnan indúló már ugyan azt fogja használni. JVMnél úgy tesz, mintha a másik nem is lenne. próbálkozások vannak, de egyelõre ahány JAVA progi fut, annyi JVM aktív. és lássuk be, az elég valószínûtlen, hogy egy gépen csak 1 progit futtasson az ember.
de .nettel ellentétben ennél nem lehet arra számítani, h az adott könyvtár rajta van a platformon, vagyis máris nem lehet rá építeni. az esetleges platformok könyvtárai közötti eltérésrõl nem is beszélve. már azzal is gond lehet, ha 1 fájlt el akarok menteni...
érdekes itt egy ilyen hír és még sincs flém. tök normális a vita. 100+ komment így is meglesz. mennyivel normálisabb lenne így az egész.
Lehet azert annal komolyabbakra is En pl egy ideig igy fejlesztettem egy kollegaval egy mesterseges intelligencia programot, igaz a grafikus resznel bebuktuk a hordozhatosagot Amugy mivel a .NET lenyeget tekintve igy mukodik, igy elmeletileg lehetseges lenne a dolog.
Einstein mondta, hogy az idõ relatív, mindenkinek van elég sõt sok ideje ha jól betudja osztani. A baj ott kezdõdik, hogy kevesen törõdnek vele... az idõ menedzment a legfontosabb dolog. És ezek nem vesznek igénybe órákat... mindõssze 20 percet. Motiváció? Na ezen lehetne gondolkodni... de mindenekelõtt, az ismétlés... vagyis mikor itt leírom a dolgokat akkor valójában újragondolom, tehát ismétlem (és még az ókori Romaiak mondták, hogy az ismétlés a tudás és bölcsesség annya), sõt van amikor e közben valami újra is rájövök, esetleg az itt olvasottak alapján valamit másként gondolok... tehát mi motiválja az embert a gondolkodásra? Szerintem, hogy emberibb legyen, munkámat és mindent amit csinálok úgy fogom fel mint egy szert ami egy felsõbb célért szolgál, az pedig, hogy emberibb legyek. Na most lehet, hogy nem a legjobban fejeztem ki magam, de talán érthetõ mire gondolok.
Hiába lassabb a C#, ha fényévekkel gyorsabb rajta fejleszteni. Ma se áll már neki senki asm-ben kódolni (max egyes rutinokat), mert elavul mire elkészül. Egyszerû dosos progikhoz elég volt, ma már irreális. Vegyük pl. a Vindóz Pistát: C#-ban is ennyi idõ megírni, asm-ben mikor lenne kész? 2500? Ráadásul az asm hw specifikus, hordozhatóság 0. Minden hw-re te kódolnád le külön?
BlackRose te nagyon ráérhetsz ha képes vagy naponta órákat áldozni ilyen parttalan vitákra. Egyébként szerintem sok dologban igazad van, csak nem értem mi motivál.
Arról nem szabad megfeledkezni, ha a szart sokáig tartogatják(tárolják) értékes trágya lesz belõle!
ah már megint ezzel jössz. egyáltalán nem mûködik 1 progrmamnál, h fogom a másik platform fordítóját és azzal készítem el a futtatható kódot. de ha még mûködne is, akkor sem lenne még a közelében sem az ilyen JVM/.Net megoldásoknak.
btw, ha jól tudom a egyelõre csak linuxra van (mono). de meglásd amint elterjednek a .Net programok minden létezõ platformra meg fog jelenni, mivel teljesen nyílt a cucc (ellentétben a JAVA-val...). a platform készítõjének érdeke lesz...
A .NET mindenben jó, kivéve egy dologban nem, ez pedig a memóriaigény. És ennek megvan az oka, mivel abstrktizál kereskedni kell két dolog között ami nem éppen fér össze, nagyon neház ilyen magasszintû abstrakt környezetben memóriatakarékosnak és gyorsnak is lenni. Ha a .NET-et és a Java környezetet hasonlítom össze, akkor a .NET jóval gyorsabb, de jóval memóriaigényesebb is. Míg a Sun valahogy a kettõ közé beült, a Microsoft inkább a teljesítményt választotta. Na most ahhoz képest, hogy a memória ma sokkal olcsobb mint a processzori erõ, és még eközben lineárissan lehet növelni, akkor azt hiszem az MS jobban választott. Vagyis sokkal olcsobb a gépbe bedobni 1 GB RAM-ot mint megduplázni a CPU teljesítményét, és ha figyelembe vesszük a memória nagyságának fejlõdését és a CPU teljesítmény fejlõdéséntk sebességét akkor ez a jövõben még igazabbá vállik. Pl. 2-3 év múlva nem lesz probléma (aprópénz lesz) 4 GB RAM-ot rakni a gépbe, am a mai átlag 8 szorossa lesz, de alig ha hiszem hogy addigra a CPU a mai átlag 2-3 szorossa is lenne. Persze nagyobb mennyiségû adat feldolgozása több CPU erõt zabál fel, de nem lineárissan, úgyhogy mindkét megoldásnak van elõnye is és hátránya is, rendszerint ez is az adott megoldástól függ. Az ATI .NET alapú bolondsága nem ide való alkalmazás és még valószínûleg teljessen optimizálatlan. Különben ha a memóriaigénynél tartunk akkor miért van az, hogy a Windows Media Player (ami egyáltalán nem takarékos a memóriával, sõt...) 3x kevesebb memóriát zabál fel mint az Apple iTunes? Pedig mindkettõ nativ kód. Magyarázat, programozási technikák, optimizási technikák stb... hogy melyik a jobb, hát egyik sem, mert nem ez a fontos, a fontos az, hogy a meglévõ megfizethetõ hardveren és szoftvere képes e kielégítõ felhasználói élményt produkálni úgy, hogy azt csinálja amire való. Különben szerintem mindkettõnek hiányzik egy ici pici feat-ja, nem tudod idõzíteni, a plazlistát. Tegyük fel, hogy reggel 7 óra 30 perckor szoljon a X playlista... ez kb. 10 sor kód, és mégsincs benne egyikben sem, a programozás nem a nyelv és nem a környezet titka, hanem az emberé, a programozóé, az ötleteké, az memóriafoglalás és a teljesítmény (gyorsaság) fontos, de közelrõl sem a legfontosabb.
A Microsoft jelenleg a világ IT kiadásainak mindössze 1.5% kaparintja meg, ez tény errõl maga Steve Ballmer beszélt a múlt hónapban. Tehát közelrõl sem gondolom, hogy az IT egyenlõ a Microsoftal. Az IT túlnyomó része az üzleti alkalmazások, amelyek specifikus dolgokat kezelnek, tesznek lehetõvé. A Microsoft csak az aki biztósítja a technológia szoftveres részét, vagyis kapok tõllük egy OS-t, egy szerver OS-t, hálózati rendszerrel egy adatbázist, esetleg clusterezési lehetõséget, fejlesztõi környezetet, és mindazokat a technológiákat amelyek lehetõvé teszik, hogy gyorsan és effektíven kifejlesszek egy alkalmazást amely pozitívan fog kihatni az adott cég mûködésére, megoldja a problémák egy részét stb. Na most mindez elérhetõ Microsoft nélkül is, van Sun, van AIX, van Linux, van Java, van Oracle stb... tehát egy jó üzleti megoldást megcsinálhatok Microsofton is meg teljessen Microsoft nélkül is. A kérdés, csak abban rejlik, hogy az adott cég melyiket választja és, hogy az adott munka elvégzésére esetleg melyik a jobb megoldás, mert ez nem mindég egyértelmû. Mivel itt a Win2000-rõl és XP-rõl Vistára való váltás volt a téma, én a jelen esetben csak a Microsoft megoldásokat vettem figyelembe, mert általában is elég kevés olyan cég van aki egy mûködõ Microsoft rendszert levált másra, legnagyobb esetben bõviti szintén MS technológiákon, vagy esetleg bõviti mással is, és ekkor már fontos az interoperabilitás. Na de most maradjunkj a tiszta MS megoldásoknál. Tehát azt mondod, hogy a spec alkalmazások a legfontosabbak. OK, ez a véleményed, de felhívnám a figyelmed, hogy ez alapvetõ dolgoknak mond ellen, vagyis nem lehet speciális dolog a legfontosabb dolog. A legfontosabb dolog az ami általánossan használható. Most én némi plusz kiadással, idõvel és tudással írhatok egy alkalmazást amelynek nincs szüksége semmire, nem kell neki OS, nem kell neki semmi, direkt boot-olod a gépet az alkalmazásba, és az alkalmazás kezeli a neki szükséges dolgokat a gépen, mint annak idején az Amiga játékok, direkt boot, nincs OS, nincs semmi amire nincs szükség, mindent maga az alkalmazás csinál. Na most ugye habár ez technikailag megoldható, ennek nem sok értelme lenne, pedig speciál alkalmazás lenne. Tehát az IT-ben a legfontosabb dolgok az enabling technologies-ek, az enabling software. Ez az ami lehetõvé teszi az alkalmazások nagymennyiségû létrejöttét, legyenek azok általános vagy speciális alkalmazások mindegy. A Windows volt az ami fontos volt a PC elterjedésére, nem a specifikus alkalmazások (habár a Word itt belesegített, de Windows nélkül nem lett volna a Word sem az ami lett). A VB volt az ami elõsegítette a Windows üzleti alkalmazások virágzását, a .NET az ami még jobban, a .NET és a Visual Studio az ami a webszolgáltatásokat tette lehetõvé (mindez a Microsoft platformon, a non-Microsoft oldalon ilyen fontos dolog pl. a Linux, a Java, a PHP, stb.). Tehát ezek az IT meghatározó ellemei és a meghatározó ellemek a legfontosabbak, persze nem kizárolagos fontosságúak, mert még sok minden másra is szükség van, a speciális alkalmazásokra való igényre is meg stb., de ez mind sokkal nehezebben elérhetõek vagy egyáltalán elérhetetlenek lennének ezek az enabling technológiák nélkül.
És egyetértek veled, hogy az USA-ban sem úgy mûködnek a dolgok, de ott valamivel közelebb vannak hozzá.
Miért is van az, hogy az ember túlórázik aprópénzért? Most ez itt off, de általában két meghatározó oka van a dolognak... (1) Nincsennek tartalékai és kivan szolgáltatva - na ez a középeurópai térségre különössen vonatkozik, és ezért lehajtja az ember a fejét és szó nélkül dolgozik. (2) A vezetõség tudatlansága, mert primitív alapokon jár, vagyis abban a tévhittben él, hogy a rabszolgaság az jót hoz nekik a konyhára... pedig egy modern gazdaságban ahol a kreativitás alapvetõ alkotó elleme a sikernek ez egyenlõ az öngyílkossággal, de ezen sajnos én nem tudok segíteni. Az meg szerintem a mi õröltségünk, hogy többet akarunk mint amennyire reális lehetõségünk van. Ezért is van az, hogy nincsennek tartalékaink. Az Indiai megelékszik a Pözsóval is, sõt még kevesebbel is, de soha nem fogja elkölteni keresetét egy autóra vagy valami élvezhetõ dologra, hanem megelékszik az olcsobb de funkcionális dolgokkal, kevesebb pénzért is elfogadja a munkát, de takarékoskodik, törekszik tartalékhoz jutni, és idõvel sikerül is majd neki. Ez a valóságtudatos és szerény viselkedés pozitív, ez teszi lehetõvé egy gazdaságilag alacsonyabb szinten élõ embernek a felzárkózást. Mi európaiak nem így dolgozunk, mi elõre akarunk és mindent akarunk. Õk annyit akarnak amit megérnek és akkor amikor megcsinálták az ellenértéket. Míg a gazdag európában vagy USA-ban az elõbbi model mûködik (valamennyire), mert ott már nagy tartalékok vannak felhalmozódva, és alapvetõ dolgok már akár generációkkal elõbb meg lettek oldva, addig európa szegényebb részein ez a filozófia a nyomor alapköve. Sajnos ezt a másikoldalon (és ezt már máshol is megvitattuk) az állam nagymértékben serkenti, úgy, hogy magas terheket tesz az emberek hátára, és úgy, hogy a megélhetési költségeket az egekbe emeli. Itt a valóságtól való elidegenedülés folyik, Pistike dolgozik egész nap, mindent világárakon fizet, de neki 3x vagy 5x a világárak allatt fizetünk. Na Indiában vagy Kínában ez nem így van, mert az igaz, hogy a Kínai 300 dollárért dolgozik, de egy ebédért nem 20 dollárt fizet, hanem 50 centet, de hasonlóan sokkal kisebb költségeken megtud élni mint az európai, és az igaz, hogy ezáltal csak pözsó-ról álmodozhat, de ehhez a pözsõhoz történetessen elõbb oda fog érni mint az szegény európai (fõleg szegény középeurópai) a Merdzsóhoz vagy BMW-hez. És ne gondold, hogy kinyalja a kezedet, mert nem, tisztességessen megdolgozik a pénzéért, és nagyon profi hozzáállással (tudom mert dolgoztam már velük), sokkal többet hoz ki kevesebb pénzbõl, minõségben is stb. és mégvalamit ha valamit esetleg elfelejtenél, akkor azt nem halgatja el, hanem felhívja rá a figyelmed, hogy nézz ide, úgy gondolom, hogy ez így jobb lenne, (igaz, hogy több munka számára - ugyanazért a pénzért, de a késõbbiekben megtérül neki, mert különössen megleszek elégedve vele, ellentétben az itteni gondolkodással ami abban nyilvánul meg, hogy hû de jó ezt nem vette észre, na 2 nappal kevesebb munka... aztán meg amikor használom a dolgot és eszreveszem, hogy na ez nem jutott eszembe, akkor kezdek elégedetlen lenni a dologgal.) Na most õszintén te melyiket választanád a többet kevesebbért, vagy a semmit sokért. Mindenesetre itt sokféle probléma találkozik úgyhogy a megoldás nehéz, nagyon nehéz. A valóság az, hogy a globalizáció nem olyasmi ami lesz, vagy nem lesz, hanem olyasmi ami VAN. Most ez ellen nem tehetünk semmit. Alkalmazkodni kell, és változni a helyzetnek megfelelõen. Aki az elsõk között teszi meg annak jó lesz, aki meg passzívan ül és várja, hátha magától elmúlik... hát arra egyáltalán nem vagyok irígy.
"Az, hogy a programozó 10 órát vagy 1000 órát dolgozik a kódon engem nem érdekel, csak az hogy melyik gyorsabb."
Altalaban ez nem igaz szerintem. Vannak nagyon sebessegigenyes alkalmazasok, ott szamit, de ahol a lassabb program is gyors, ott az szamit melyik az olcsobb, ami viszont attol fugg, hogy melyiket programoztak kevesebb ideig.
Amit leírtál, az szerintem amcsiban sem így mûködik.
Nem lusták vagyunk gondolkodni, kreatívnak lenni, hanem a dologgal az a gond, amit már máshol is megtárgyaltunk.
Egy cég pl felvesz 2 informatikást 5 ember helyére, felepénzért és dolgoztatja õket ingyen túlorában is. Ez után elvárod, hogy a csákó legyen még kreatív is? Minek? Hogy a CEO 20 milkós prémium helyett 30 at kapjon õ meg max egy meleg kézfogást, és tényleg max felkerüljön a hónap dolgozója táblára? Na ne vicceljünk?
Mindenki viszi ki a fejlesztõkapacitást távolkeletre, ahol 10-ed annyi pénzért napi 12 órát dolgoznak vidáman. És még kreatívak is hiszen boldogok hogy munkájuk van, megbecsültek stb. És ott a kultúrából, az elmaradottságból fakadóan sem kerül annyiba a csákó munkaerejének újratermelése. Láttad a reklámot az indiai szakember nem merdzsóra/volvóra vágyik, hanem pözsó306-ra, és azzal fittizik!!!!! Szal sokkal sokkal kevesebb pénzért is kinyalja a kezedet.
Mi itt a nyugati magas kultúránkkal csak arra vagyunk jók hogy felzabáljuk mindazt amit elénk raknak, hogy fogyasszunk. Persze ne túl válogatósan!
"Egy középvállalkozás vagy nagycég számára nagyon fontos, hogy a számítógépen dolgozó alkalmazottak benne legyenek a dologban, tudják a munkájukat, vagyis nem olyanok legyenek akiknek 2 perc allatt megmutatták... hanem igazi információ alkalmazottak, akiknek szintén napról napra követniük kell a dolgokat, tanulniuk, alkalmazkodniuk."
Az emberi teljesítõképességnek vannak határai, pláne, ha nincs ösztönözve a kreativitásra, lásd feljebb. Ha a wörddel csak feljegyzéskéket írok, akkor nem fogok azzal szórakozni, hogy mindenféle klipartokat, meg patterneket szúrogatok be a levélkéimbe, mint ahogy azt a M$ elképzeli. Egyszerûen nincs idõm ilyenekre!
Másrészt megette a fene az egészet, ha nem írtak nekem olyan progit, amit általános IT ismeretekkel és a saját területemhez tartozó szakértelemmmel el tudok mûködtetni.
Pl kérd meg a légiirnyítókat, hogy dolgozzanak kreatívabban, és ne csak használják, hanem értsenek is a számítógépes irányító rendszerhez és kisebb problémákat legyenek szívesek már saját maguk megoldani. Na abból lenne csak jó móka, meg felfordulás!;) És még alkaloida se kéne hozzá!
Fogd már fõl, hogy az IT legfontosab alkalmazásai nem az M$ által szállított irodai progi csomagok, hanem kis cégek által fejlesztett spec szofverek!!!!! Az meg hogy NT-n, w2000-en Xp-n vagy Pistán megy annak ha jól meg van írva édes mindegy!
Attól hogy az M$ csinálja a legnagyobb cirkuszt, még nem azt jelenti hogy AZ maga az IT. A win ugye mindenhol ott van, de ha csak az elterjedtségbõl indulunk ki mint legszembetûnöbb szempontbol, akkor az internet is vsupán csak egy nemzetközi pornómédia terjesztõ hálózat!!!!;))))
A Pista legfõbb elõnye a 64 bit támogatása lesz (WinXP64-et szinte semmi nem támogatja, mindenki erre vár), valamint a cikkben említett biztonsági javítások (ami hiába van ha a legtöbb júzer fel se teszi, vagy méginkább azt se tudja mit is kéne). Az XP-nél jobb lesz a Pista mindenképp, ráadásul a legtöbb embernek pont ugyanannyiba kerül mint az elõdei. :D
Ez fõként a sok textúrának köszönhetõ, ma már nem elég az egyenszinezés, többféle textúrát (effektek) is rá kell húzni ugyanarra az ojjektumra, abból se az 1*1-est, ez sok hely.
Jó, de a programozókat érdekli :) Egyébként ez igaz, bár nem tudom, hogy a .net miatt-e, de az alkalmazások memóriaigénye eléggé elszállt mostanában. Ez nem lenne baj, az a baj, hogy viszont rohadtul nincs arányban a +funkciókkal.
Minél magasab szintû egy programozási nyelv, annál lassabb. Az, hogy a programozó 10 órát vagy 1000 órát dolgozik a kódon engem nem érdekel, csak az hogy melyik gyorsabb.
Érdekes, hogy senki sem ágál az ellen hogy a gépek gyorsulnak... több ghz, több mag. De. De mikor megemlítem hogy az eddigi adatok alapján egy .NET alkalmazás lassabb mint egy C++ -ban megírt akkor egyesek szerint ez "beteges ellenállás".
A .NET és C++ sebesség különbségeirõl olvasgass programozói fórumokat, mindenki nem tévedhet.
.NET egyébként egy rémálom, elég megnézni az ATI catalyst control centert... fél éve mikor kipróbáltam megevett 100 megát, azaz egy 512MB-os gépen a szabad fizikai memória felét. Durva. A dobált hibaüzenetekrõl nem is beszélve. Jó, jó tudom hogy ez csak egy alkalmazás, viszont egy jól menõ cég olyan "programja" amit rengetegen használnak, és van is rá pénz fejleszteni. Mégis...
érdekes ez a beteges ellenállás. amikor kijött a JAVA mindenki hasra esett tõle. istenítették és hatalmas jövõt jósoltak neki. ebbõl persze semmi nem lett és igen hamar elõjöttek a hátrányok. kijött a .Net C# és folyamatosan fikázzák, miközben minden egyes paraméterében nagyságrendekkel jobb mint a JAVA. kisebb, gyorsabb, hatékonyabb és gyorsabban fejleszthetõ kód. a framework memória és kód kezelése is jobb/gyorsabb és biztonságosabb/stabilabb mint a JVM. tesztek szerint a C# compiler minimálisan fordít rosszabb kódot mint a C/C++é. ez teljesítményben a köv listát állítja fel: ASM, C/C++, C#. a kis kompromisszumért cserébe viszont platform független (és teljesen OO). amikor jött a C ugyan ez a rizsa ment, mint amit te is löksz, mondván, h az ASM az igazi. látjuk mi lett belõle. jelen operációs rendszereknél (win/lin/stb.) a framework miatt a C# nem alkalmas rendszer programozásra, mivel egy külön teljesen elválasztott szinten fut a megírt program. ez visziont a vistánál teljesen megváltozik, mivel ott a framwork lesz maga a rendszer és nem mellesleg maga a vista kódja is egy speckó C#-ban íródott(ik). egy nem rendszer programnál olyan minimális a C++ és a C# közötti teljesítmény különbség, h a kapott elõnyökért cserébe egyáltalán nem éri meg foglalkozni vele. fõleg, h _elméletileg_ hiába gyorsabb/energiatakarékosabb a C++ program, ha a gyakorlatban ez olyan minimális, h max "mûszerekkel" érzékelhetõ.
note: ha elsõ futtatásra lassú egy frameworköt használó program, nem kell kétségbe esni, másodikra már nem lesz az. ez a platform függetlenség ára.
"Game over, ha így jobban tetszik. Bye bye mikorfos. Persze ez még egy kicsit odébb van, de ami késik, az nem múlik :)"
Álmodik a nyomor hehehhe..... a Win egyere jobb lesz és az ellene felhozott érvek száma is egyre csökken,,,
pontonként haladva: 1. nem két percekrõl beszéle, hanem napok helyett órák vagy percek. 2. install? ugyan már, egy hálózatra feltelepíteni ugyan annyi mint 1 gépre, max 20 perc. fél órával elõbb bemegy a rendszergazda és kész... 2/b: tanulás: 1x kéne rendesen megtanítani nekik. az nem tanítás, amikor kis plusszért a rendszergazda tart pár kurzust 30/40 fõs csoportoknak.
3. patch: van ilyen, sp-nek rövidítik :) ezt egyébként úgy mondtad, mintha új verzsöntõl nem lehetne eldönteni, h felrakod-e vagy nem.
Egy 5 fõs vállalkozás 2-3 év múlva 8-10 fõs kell, hogy legyen minimum 12-15 optimum, vagy ha nem akkor nem jó csinálják. Persze ez most is a, hogy kellene, hogy legyen, nem pedig a ,hogy van. A dolog egyszerû. Van egyéni vagy szûkebb családi vállalkozás, és ez OK, ez kimarad, ide Linux és Open Office és hülyeség pénzt adni Windowsra meg stb. A többi cég aki nem ide tartozik annak felfelé kell menni, legalább évi 20%-al az az abszolút minimum, másképpen az ilyen cég csak tengõdni képes, még az USA-ban is, pedig ott sokkal jobban megvan olajozva a motor.
össze kéne fogni a cégeknek. ha például nagy tételben olcsóbb a szoftver, akkor a kamarán vagy valamifelé szakszervezeten, alapítványon keresztül érvényesíteni ezt és egy nagy megrendeléssel állni a szoftver forgalmazó elé. mondjuk minden évben kiírnának egy idõpontot, hogy azon a napon veszik meg a szoftvert, iratkozzon fel rá mindenki akinek kell akkortól. befizetnék a pénzt (lehetne akár egy alapítvány is) aztán ez a szervezet (alapítvány vagy kartel) azon a napon nagy tételben vásárolna majd utána meg továbbadná a szoftvere licenc jogát, mint ahogy pár hírrel odébb van, hogy ilyent lehet. mondjuk nem tudom nagy tételbe vásárolt szoftverrel mennyit lehetne így spórolni, ha elég sokat, akkor talán megérné.
én nem tudtam, hogy hány százalék (3 vagy 10), csak amit látok abból gondoltam, hogy meglehetõsen kevés. persze, jó volna sokan gondolkodnának úgy (és hozzá meg is lenne a lehetõségük, hogy úgy is tegyenek)ahogy írtad
Különben azt hiszem, hogy az ami tényleg lendületet ad majd a Vistának az a 64bit, vagyis mire bejön a Vista addig megérik a 64bit, plusz 1 év, és Photoshop, Corel, MAX, stb. nem lesz csak 64 biten, az üzleti alkalmazásokra ez nem annyira fontos, de maga a piac erre fogja terelni a dolgokat, vagyis egyszerûen az új hardware 64bites, az OS 64 bites, és ha itt van akkor miért nem használnánk ki, ha pedig használjuk, akkor a meglévõ hardver már úgy is elavult, biztosítás, garancia, stb. nem mûködik,ja és csak gátolja a fejlõdést... na akkor ki vele, és jön az új hardver és persze rajta a Vista. Kb. ez történt annak idején a Win 3.11 el is, jött a Win95 ha kellett ha nem. Érdekes dolog amirõl megfeletkeznek, a Vista új from the scratch TCP/IP stack-je 30-50% növeli a hálozati szélesség kihasználását (akit közelebbrõl érdekel a dolog, a PDC-n volt róla szó és a channel9.msdn.com -on is megtalálhatja. Na azért szerintem ez sem eldobnivaló, ha effektív jobb networkingot hoz magával, ez már elég nagy dolog a cégeknek amelyek egyébként is hálózati problémákkal mûködnek. Ja és az otthoni felhasználóknak is jobban folyik a stream...
egyébként ha a .NET jött szóba, az egyáltalán nem szemét munka, és nem is sokkal erõforrásigényesebb mint a native kód, persze itt most nem azt mondom, hogy olyan vagy majdnem olyan, de az alkalmazások 80%-ának tökéletessen megfelel. Persze mindég lesz olyan dolog amire natív C/C++ az igazi megoldás, sõt van ahol még az ml64.exe is segíthet (64 bites MASM - assembler), tehát mégegyszer nincs olyan dolog ami mindenre jó, de a .NET az egyszerûen óriási az üzleti alkalmazások nagy többségére.
Igen, csak mondjuk odaát az USA-ban (és a Gartner ugye inkább ott vizsgálódott mint itt), ez mondjuk kb. az általad említett 10%, Magyarországon én személyessen örülnék mint az állat ha 3% így mûködne és itt nem a kiscégekrõl hanem a közép és nagycégekrõl beszélek :( Tehát én itt nem azt mondtam, hogy mi a helyzet, hanem azt, hogy mi kellene, hogy legyen, vagyis azt, hogy (persze nem teljessen megfogalmazva), hogyan is kellene csinálni, hogy sikeres ország, sikeres gazdaságunk legyen. Azt hitték, hogy majd ha belépünk az EU-ba akkor minden OK lesz. Nem így van, mindenkinek megkell izzadnia a jobbért. Én itt a "többet ésszel mint erõvel" utat propagálom, aki komolyan akar az életébõl a cégébõl csinálni valamit (és olyan helyzetben van, hogy ezt teheti) akkor így kell, hogy cselekedjen. Különben ez érvényes a világ minden részére is, van ahol többé van ahol kevésbé. De alapszabáljnak el lehet fogadni, hogy minnél fejlettebb országról van szó annál kisebb az esély a sikerre, ha nem így cselekszünk, de ha idõvel mi is a fejlettek és gazdagok közé akarunk tartozni és nem csak álmodozni akkor oda csak így kerülhetünk. Na ezt akartam mondani. He he... hû de jó volna a 10%. :)
...igen olvasom amit írsz végre van benne egy olyan amit én a buta agyammal felfogok, nevezetesen hogy ma majd (majd) megjelennek olyan szoftverek amik csak vistával hajlandóak mûködni (izé milyen cég ír olyat ami csak...) akkor de csakis akkor ha a cégnek arra az alkalmazásra okvetlen szüksége van mert nincs más alternatíva az általa használt OS-ére, vagy olcsóbb mint az általa használt OS-en futó változat etc. akkor de csakis akkor megfontolhatja az átállást...
Mondjuk ez egyértelmû.
Programozási oldalról közelítve a dolgot már nem olyan kedvezõ a kép, hiszen pont a vista erõlteti majd a .net techológiát, amiben ugyan gyorsabb programozni, viszont lassabb és erõforrásigényesebb..tehát eleve szemét munka - mi sülhet ki belõle?
Ha lejebb olvasol, akkor látni fogod, hogy én sem az OS-rõl beszéltem, hanem a "Longhorn wave of products" ahogy a Microsoft nevezi mint komplett technológiák ötvezete, amely nélkül neház lesz a továbblépés (a Windows világban) és a Vista ennek szerves része. Különben nem agitálok, nem szokásom. És igen a vállalati alkalmazottak alkalmazásokat használnak amely OS-eken meg IT rendszereken futnak (mai hálózati környezetben maga az OS nem elég), de a fennt említett dolgok nem mûködnek régebb generációs OS-ekkel, vagy ha igen akkor nem optimálissan, lassabban, valami mindég akad amit ha beszámolunk, a végén úgy esik ki, hogy az upgrade a legolcsobb megoldás. Na de már egyszer leírtam, ha érdekel olvasd el lejebb.
BlackRose, amit írsz, marha jó meg szép és biztos van ahol úgy csinálják ahogy te írod, és így ebben a formában van is benne némi ráció, de hogy ezt így ebben a formában Magyarországon a cégekbõl max. 10 % ami csinálja arra is mérget mernék venni. és abban is biztos igazad van, hogy ezek is a közép és nagyobb méretû (és jólmenõ) cégek, ott elismerem, hogy a méretükbõl adódóan, meg az ennek köszönhetõ olcsób beszerzés-, betaníttatás-, átálítás- költségnek megtérülhet. (erre se minden esetbe vennék mérget) de mondjuk egy 5 fõs vállalkozásnál (és akad ilyen is azér szép számmal, meg kissebb is) már nem hiszem, hogy 2-3 évente megéri ez a teljeskörû software frissítés.
totya, én úgy látom, hogy egy új OS jópár szoftverbõl is újabb verziót indukál (pl. Office, Corel, stb.), persze lehet erõltetett az összefüggés, de én sokszor úgy láttam, hogy szinte csak az új OS hozadékaként adták pl az Office 95-öt meg a Corel 6-ost is (nekem most ezek ugrottak be, bár tom régi, szakállas példák, de lehetne újabbakat is mondani ), sõt BlackRose is hivatkozott rá, hogy a Vistához az Office 12...
valamit-el egyetértek. Bár õ inkább az alkalmazások verzióváltásainak (esetleges) szükségteleségérõl beszélt, és nem az OS-érõl...
"idõvel a rendszer nem fogja kísérni a munkafolyamatot, a minõség meghatározatlan, az ingadózás nagy "
Hát én továbbra sem értelek téged, lehet hogy hülye vagyok. De e fenti idézet és egy új oprendszerre való váltásra való agitálás (ami még meg sem jelent...) hogy jön össze az nekem rejtély. Egyébiránt én azt hiszem, hogy a vállalati alkalmazottak elsõdlegesen alkalmazásokat használnak az OS csak futtatja ezt (ha tudja). Majd valaki biztos meggyõz... van pár kedvencem :)
persze, oké, több gépre olcsóbb. de én (talán némi kis túlzással) embert nem láttam, akinek azon múlt volna, hogy elvégzi a munkáját, hogy office hatost vagy tizest használ. (az meg, hogy a betanulás/installálás bosszankodásai után napi 2 percel többet beszélget munkaidõben az alighanem nem sok gazdasági haszonnal bír) és ha így nézed, hiába, hogy nem százezer, hanem csak tízezres nagyságrend, installálni kell, kiesõ idõ van, stb., stb. ráadásul titkárnõ Mancikától nem lehet azt se elvárni, hogy 2 évente tanuljon meg egy szoftvert, mert az is elõfordulhat, hogy több idõt vesz el tõle, mint amit nyer az alatt a 2 évben. (tom kicsit pejoratív lett ez a "titkárnõ Mancikákra", tõlük ezúton is elnézést) sõt, tudok olyan esetrõl is, hogy valaki egy programot nagyon kiismert (pl. Photoshop 4)és a késõbbi verziók úgy változtak, hogy sok mindent ma is azzal csinál, mert azzal már tudja és nem tököl, h kitanulja, viszont sokan mondjuk a 6-os meg a 7-es Photoshoppal se csinálják meg azt, amit õ a négyessel (nagyon extrém példa, de valszeg Leonardo da Vinci se várt arra, hogy a boltba kapjon már temperát, de azér egész jól festett)
egy kérdés: miért nem patch formájába fejlesztik a szoftvereket? azaz, új funkciók ha megjelenik mindenki eldöntheti, h felteszi e vagy sem. (persze egy-egy patchért is kéne fizetni, de csak töredékét mint egy egész szoftvernek) nem is lennének mondjuk verziók vagy csak egész nagyon ritkán egész alapvetõ változtatásokkor. rugalmas szoftver lenne felhasználó felé bármikor nyújthatna olyan új funkciókat amire épp neki van szüksége (akár megjelenne e menüben, vagy épp egy párbeszédpanelt kiegészítene) és akár külsõ cég is írhatna ilyen patch-eket, hogy télleg a legpontosabban az adott célra megfelelõ program legyen a gépen (jó, nyilván kevésbé lenne üzlet mint most... bár sokan fejleszthetnének alá, nem csak egy cég, szal ez se biztos) ... meg nyilván cégek kiadnának ilyen patch csomagokat, stb. stb.
Igaz, de ebben az esetben minek váltani Vistára? Egy 2 tagú kereskedelmi minicégnek Linux+Open Office megteszi, és nekik még a Win2000 vagy a Vista is túlságossan felesleges. Tehát ha ugyanazt a munkát akarod csinálni amit eddig is csináltál akkor nincs szükséged változásra. A baj ott kezdõdik, hogy nem lehet ugyanazt csinálni amit tegnap csináltál, mert kicsi a haszon és jönnek a Kínaiak, Indiaiak meg stb. (ezt még véletlenül sem szabad elfelejteni, amit ma itt gyártunk és árulunk az holnap féláron jön majd Kínából napról napra jobb minõségben). De nem csak azoktól kell félteni az üzletet, hanem a helyi konkurenciától is, a multiktól is stb. Tehát az amirõl beszélek az új piacok teremtése, innováció. A titkárnõknek is követni kell ezt, vagy munkanélkül maradnak. Hidd el nekem a titkárnõm nem lehetne az aki nem tud követni, tanfolyamok és iskolák ezért léteznek. Egy üzleti megoldás különben nem csak a hardware és software, hanem egy teljes megoldás amely magába foglalja az üzemeltetést is, ezért vannak a fejlesztõk akik együttmûködve a felhasználóval kidolgozzák a tervet és megalkotják a megoldást, akkor a tanácsadók - konzulensek megtanítják az alkalmazottakat, hogy a rendszert használják, kihasználják, profi szinten. Ez mind beletartozik a megoldásba, nem csak az, hogy most telepítjük a szoftvert a méregdrága hardveren, beállítjuk a hálózatot és tanálják fel magukat, hanem megtanítsuk õket, hogy végig értsék a folyamatot, hogy tudják kezelni és a lehetõ legtöbbet vegyenek ki a rendszerbõl. Egy titkárnõnek nem kell, hogy értsen a defragmentáláshoz, meg a TCP/IP konfigurálásához, ez a rendszergazda, vagy ha kisebb a cég a külsõ informatikai partner-szállító dolga, de azon az alkalmazáson amelyel a munkát végzi, legyen az Word vagy valami testreszabott megoldás, én személyessen egy rövid idõn belül elvárom, hogy power user legyen, amikor a tanácsadó azt mondja, hogy OK, az emberek megtanulták, akkor jön az analízis, mit és hogyan lehet jobban, és ez a következõ lépés. Jön a rendszer továbbfejlesztése. Ha rendessen elmagyarázod a cég vezetõségének és azok nem hülyék akkor rendszerint benne vannak, mert megmutattad nekik, hogy kifizetõdõ a dolog. Ha ráhagyod a cégre, aki egyébként nem informatikai cég akkor a rendszer megáll, a userek lusták lesznek, kezdik átugrani a dolgokat, idõvel a rendszer nem fogja kísérni a munkafolyamatot, a minõség meghatározatlan, az ingadózás nagy (ma ilyenre sikerült holnapra olyanra, ma 5 percet várt az ügyfél holnap 3 órát... stb. - gondolom érted mire gondolok). Egy középvállalkozás vagy nagycég számára nagyon fontos, hogy a számítógépen dolgozó alkalmazottak benne legyenek a dologban, tudják a munkájukat, vagyis nem olyanok legyenek akiknek 2 perc allatt megmutatták... hanem igazi információ alkalmazottak, akiknek szintén napról napra követniük kell a dolgokat, tanulniuk, alkalmazkodniuk. Egy pici cégnél ez persze nem így megy, ott sokszor az csinálja aki legjobban ért hozzá (és legtöbbször az is kevés) meg emellett még 100 más dolgot is csinál, de mint mondtam az elsõ szakaszban nem kell nekik Vista az biztos, ha meg növekedni akarnak, akkor majd idõvel megjön a szükség. Es végén mit akarsz egyszerû fajlmegoszlással? Mert én eddig azt még mindenütt csak adattemetõnek tapasztaltam. Van egy rakás adat valahol a hálózatban, azt sem tudjuk, van e backup, de ha bedöglik nem baj, mert úgy sem kell... na ez az egyszerû fájlmegosztó hálózat, és ehhez kötném a hálózatok világtörténelmének legroszabb találmánya a peer-to-peer network, bár ami a cégeket illeti. Eredmény egy rakás fájl 100 helyen, 58 verzióban... és amikor már nem kell, akkor ott marad eltemetve, többször elõ sem hívjuk, nem nézzük meg, hogy mit is mond nekünk ez az adat. Ha nem vetted észre jelenleg a legnagyobb felhajtás a BI (Business Inteligence) körül van, mert fontos az adatokat ellemezni, analizálni, újrahasználni stb. Ha az adatokat nem használod akkor dobd el, mert feleslegessen terheli a rendszert, a zûrzavarban nem tudod megtalálni azt amire szükséged van és persze még pénzbe is kerül, mert akármennyire is kevésnek tûnik minden bájt pénzbe kerül, tárolni, stb. És egy fájlmegosztó rendszeren ebbõl nincs semmi.
De most mondjuk egy kiscég is, mondjuk egy bolt. Ahelyett, hogy megengedje magának, hogy a vevõnek azt mondja "nincs de jöjjön holnap", egy viszonylag egyszerû rendszer segítségével ezt megelõzheti. Akkor pl. automatikussan megrendelheti webszolgáltatás segítségével a beszállítótól az árút, automatikussan elkönyvelheti stb... és ez most nem éri meg a befektetett pénzt? Egyik oldalon túltermelik az egyetemek a szakembereket, másik oldalon ezek nagyrésze munkanélküli, mi meg ahelyett, hogy kihasználnánk ezeknek az embereknek a túdását és ilyen meg hasonló informatikai megoldásokat csináltatnánk velük, úgy akarunk dolgozni mint 10, 20 vagy akár 50 évvel ezelõtt, gyalog. Lusták vagyunk gondolkodni ezért van ez így. És mi a kifogás... a Manci úgysem fogja tudni (tanulja meg), meg én is lusta vagyok tanulni... ha ez a válasz akkor ne felejtsük el, hogy a Kínaiak nem lusták.
echo:
A legjobb fájlkezelõ a Directory Opus, biztos! egyszerûen konkurencia nélküli, és ismeri a tab-okat.
"És mivel naponta 12 órát üzleti megoldásokkal foglalkozom ebben teljessen biztos vagyok."
Na ja, azért ez a marketing szöveg. De a dolgot meg is lehet fordítan, pl nagy fontosságú rendszer "alkalmazásánál", ha az tesztelve NT-n lett akkor nem lehet átteni 2000-re vagy XP-re még ha futna is rajta. Egész addig mig az engedély meg nem érkezik.
//hangyányit off a fájlrendszer elérésérõl jutott eszembe. fix.tv-n a mechiansba beszéltek arról, h osXben mennyivel jobb, h a mappákhoz tipusok vannak rendelve (film/zene/képek), míg xp-ben ez a dokumentumokon belül a my docs zene/film stb. mappákra korlátozódik (pl a wmp ezeket a mappákat nézi meg, amikor arra nyomunk, h minden zene film jelenjen meg). arra panaszkodtak, h elég szar ez a fix mappa, jobban szeretnek sajátot használni (pl c:/zenéim/). a vicc az, h bármelyik nem rendszer mappára jobbkattinva a tulajdonságokban beállítható a mappa profilja és onnantól kezdve ugyan úgy viselkedik mint a doc & setting/user/docs/msdocs -on belüliek (rövídítettem...). ez egy tipikus olyan funkció, ami ezer éve elérhetõ, nincs is eldugva, és az emberek nem ismerik, miközben hiányolják a létét.
msnek volt vmi statisztikája nemrég, h az ofiszban számonkért újítások 90+%-a már generációk óta benne van...
minnél több gépre veszel "konfigot" annál olcsóbb, nem bolti árakkal kell számolni.
ofiszban igazából tényleg az a baj, h túl sokat tud. a röhely az, h sok embernek szüksége van bizonyos funkciókra, de lehet nem tudja, h képes rá pl a wörd és órákat elszenved más megoldásokkal (esetleg vmi favágos módszerrel próbálkozik, pedig van rá automatizáció).
0 új funkciókkal rendelkezõ sw-re is érdemes lehet újítani, mert feltehetõen a régiek lettek feljavítva (könyebb használhatóság). hiába tudta az elõzõ, ez jobban/egyszerûbben tudja -> idõt takaríthatok meg -> több pánzem marad -> idõvel behozza az árát.
#20 nem hiszem, pedig tényleg jó lenne. viszont az intézõ egész szép imprúvmenteken esett át (elõször jutott eszembe, h ne TC-t használjak egy fájl eléréséhez).
#21 az "vicc", h az új ms termék hullám pont a vállalati és fejlesztõi felhasználoknak hoz rengeteg újítást, home júzernek max csak a "csicsa" avalon lesz igazán új. persze idõvel a fejlesztõi oldalon tett fejlõdés a hóm júzer experimentjét is javítani fogják.
példának okáért (sz. szvsz) új ofiszra egy vállalatnak az új integrálta vállalati kommunikációs és üzletviteli megoldások miatt lenne érdemes váltani, persze ehhez nem árt a vállalat mûködését ráigazítani. a valóság az, h a vállalatok többsége egyáltalán nme használja ezeket ki, pedig ms-nek nagyon jó forgatókönyvei vannak a különbözõ szituációkra, és asszem a világ 2. legértékesebb cégének tanácsát érdemes megfogadni...
Informatika és tudomány
En pl egy ideig igy fejlesztettem egy kollegaval egy mesterseges intelligencia programot, igaz a grafikus resznel bebuktuk a hordozhatosagot 
Amugy mivel a .NET lenyeget tekintve igy mukodik, igy elmeletileg lehetseges lenne a dolog.
A baj ott kezdõdik, hogy kevesen törõdnek vele... az idõ menedzment a legfontosabb dolog. És ezek nem vesznek igénybe órákat... mindõssze 20 percet. 
