Hozzászólások
-
SzerzőBejegyzés
-
LCoder wrote:Anno írtam bmp-t kezelő progit Turbo C-ben még DOS alatt, (képújság szoftver önkormányzatnak a helyi TV-re, volt szerkesztő és megjelenítő része is és windows-os bmp-ket is meg tudott jeleníteni, sőt ha jól emlékszem még bmp-t rajzolni is lehetett vele DOS alatt) nem volt az annyira nagy varázsolás…
Jójó, de nem arról van szó, hogy a beépített fgvket használod, hanem hogy nulláról megírod.
medveapu wrote:„Az üzemi összmunkás teste előtte jár a hajtómű keletkezésének”Parse error.
vizsla wrote:„Plusz, a tömörítetlen bmp szerkezete egyszerű mint a fa_szeg”
… egyszóval megint sületlenséget beszélsz… amiről nincs fogalmad. Mert, ha nem így lenne, akkor tudnád, hogy egy bmp-nél össze-vissza kell ugrálni a memóriában, hogy kicsihold a képet. (A valódi ok, hogy má$ legyen, ne legyen kompatibilis, csak az terjedjen – kihasználva a piaci előnyt. És mivel semmi értelmeset nem tudott kitalálni a m$, ezért össze-vissza keverte a biteket… Na már most eleve komolytalan egy cég, amitől mindössze ennyi telik (meg még nagyobb aljasságok, lásd szabadalmak).)Mellesleg meg nem hinném, hogy ott az msnél gondot okozna a jpg vagy a png _szabvány_ implementálása (főleg, hogy a pöttynetben fogadok van rá támogatás, ahogyan a tiffre is — különben mindjárt nagyon csalódok 🙂 ).
vizsla wrote:„Plusz, a tömörítetlen bmp szerkezete egyszerű mint a fa_szeg”
… egyszóval megint sületlenséget beszélsz… amiről nincs fogalmad. Mert, ha nem így lenne, akkor tudnád, hogy egy bmp-nél össze-vissza kell ugrálni a memóriában, hogy kicsihold a képet. (A valódi ok, hogy má$ legyen, ne legyen kompatibilis, csak az terjedjen – kihasználva a piaci előnyt. És mivel semmi értelmeset nem tudott kitalálni a m$, ezért össze-vissza keverte a biteket… Na már most eleve komolytalan egy cég, amitől mindössze ennyi telik (meg még nagyobb aljasságok, lásd szabadalmak).)Mellesleg meg nem hinném, hogy ott az msnél gondot okozna a jpg vagy a png _szabvány_ implementálása (főleg, hogy a pöttynetben fogadok van rá támogatás, ahogyan a tiffre is — különben mindjárt nagyon csalódok 🙂 ).
Hehe… és akkor ki mondja, hogy a Linux nem elég enterprájz neki? 🙂
Hehe… és akkor ki mondja, hogy a Linux nem elég enterprájz neki? 🙂
LCoder wrote:Persze hogy az a célja. Ők windows eladásában érdekeltek, következésképp az az érdekük hogy minél profibb .NET-et fejlesszenek a linuxos/unixos fejlesztők átcsábítására. Persze a másik oldal ennek az ellenkezőjében érdekelt, nem véletlenül adja a SUN sem ingyen a Netbeanst és rakja bele a fejlesztéseket számolatlanul. És alapvetően nem olyan rossz ez így, legalábbis a fejlesztők szempontjából. Nekem is jó hogy a M$ adja ki a jobbnál jobb visual studiókat igen szolid áron, és a javás fejlesztőknek sem rossz a Netbeans és az Eclipse mögé érkező vállalati fejlesztés.
A linuxnak szvsz inkább ott lehet problémája hogy míg a SUN-nak az élete nem elsősorban a javás eladásoktól függ, addig a M$ esetén a windows és az office eladásból jön elsősorban a pénz. Azaz ők sokkal inkább érdekeltek a .NET fejlesztésében mint a SUN a javáéban. Ennek ellenére a SUN is elég szépen rakja bele az erőforrásokat a NB fejlesztésébe, meg a java is fejlődget szépen, még ha lassabban is mint a .NET. Szvsz a linux szempontjából inkább az lehet kínos hogy míg a .NET az eléggé windowst jelent – kivéve a mono projectet – addig a java nem jelent automatikusan linuxot. Azaz amíg a windowsnak lesz egy profi API-ja (és szép lassan felváltja a jó öreg win32-t) addig linux alatt a java csak az egyik API marad a többi jóval kevésbé szerencsés, de „natív” API mellett. Szvsz a linuxnak vagy mono irányba kellene elmennie, vagy valami a SUN-os java desktop-hoz hasonló dolgot kellene kitalálnia ha hosszú távon versenyben akar maradni.Azért a Linuxot sem kell félteni. Nem hinném, hogy lesz egységes API, inkább tendenciák lesznek, és ahhoz fognak igazodni egyes libraryk. Ez merőben új dolog lesz a programozóknak, viszont óriási szabadságot fog adni, és ha több platformra kell fejleszteni (márpedig a világ ebbe az irányba halad), akkor sokkal jobban jönnek ki. Pár ilyen töredék: a qt4 és a kde4 API-ja valami nagyon durva, nemcsak telejsíti a freedesktop.org követelményeit, de rendesen rak is mellé; lesz userspace kernel api is nemsokára (a fuse mellé). And so on, jönnek az újabbnál újabb dolgok folyamatosan.
A SUN-nak meg elég jó piaca van a java-val, gyakorlatilag be van betonozva. Ha egy olyan szolgáltatásplatformot akarok írni, ami a lehető legtöbb helyre (az összes mobiltelefon, web, wap, gyak a legtöbb elterjedt oprenszer) eljut, akkor egyértelmű a dolog.
LCoder wrote:Persze hogy az a célja. Ők windows eladásában érdekeltek, következésképp az az érdekük hogy minél profibb .NET-et fejlesszenek a linuxos/unixos fejlesztők átcsábítására. Persze a másik oldal ennek az ellenkezőjében érdekelt, nem véletlenül adja a SUN sem ingyen a Netbeanst és rakja bele a fejlesztéseket számolatlanul. És alapvetően nem olyan rossz ez így, legalábbis a fejlesztők szempontjából. Nekem is jó hogy a M$ adja ki a jobbnál jobb visual studiókat igen szolid áron, és a javás fejlesztőknek sem rossz a Netbeans és az Eclipse mögé érkező vállalati fejlesztés.
A linuxnak szvsz inkább ott lehet problémája hogy míg a SUN-nak az élete nem elsősorban a javás eladásoktól függ, addig a M$ esetén a windows és az office eladásból jön elsősorban a pénz. Azaz ők sokkal inkább érdekeltek a .NET fejlesztésében mint a SUN a javáéban. Ennek ellenére a SUN is elég szépen rakja bele az erőforrásokat a NB fejlesztésébe, meg a java is fejlődget szépen, még ha lassabban is mint a .NET. Szvsz a linux szempontjából inkább az lehet kínos hogy míg a .NET az eléggé windowst jelent – kivéve a mono projectet – addig a java nem jelent automatikusan linuxot. Azaz amíg a windowsnak lesz egy profi API-ja (és szép lassan felváltja a jó öreg win32-t) addig linux alatt a java csak az egyik API marad a többi jóval kevésbé szerencsés, de „natív” API mellett. Szvsz a linuxnak vagy mono irányba kellene elmennie, vagy valami a SUN-os java desktop-hoz hasonló dolgot kellene kitalálnia ha hosszú távon versenyben akar maradni.Azért a Linuxot sem kell félteni. Nem hinném, hogy lesz egységes API, inkább tendenciák lesznek, és ahhoz fognak igazodni egyes libraryk. Ez merőben új dolog lesz a programozóknak, viszont óriási szabadságot fog adni, és ha több platformra kell fejleszteni (márpedig a világ ebbe az irányba halad), akkor sokkal jobban jönnek ki. Pár ilyen töredék: a qt4 és a kde4 API-ja valami nagyon durva, nemcsak telejsíti a freedesktop.org követelményeit, de rendesen rak is mellé; lesz userspace kernel api is nemsokára (a fuse mellé). And so on, jönnek az újabbnál újabb dolgok folyamatosan.
A SUN-nak meg elég jó piaca van a java-val, gyakorlatilag be van betonozva. Ha egy olyan szolgáltatásplatformot akarok írni, ami a lehető legtöbb helyre (az összes mobiltelefon, web, wap, gyak a legtöbb elterjedt oprenszer) eljut, akkor egyértelmű a dolog.
Jah, az MS célja a vendor lockin. Nem véletlen, hogy mindenkinek adni akarnak pöttynetet, mivel az infóiparban ökölszabály, hogy az a platform nyer, amelyiken a legtöbb és legjobb programok elérhetőek. Ezt lovagolja meg újra és újra az MS. Itt jön szarul az, hogy a Linux meg nem akarja kényszeríteni a felhasználókat magához, mivel egy csomó Linuxos programnak van win32 portja.
Jah, az MS célja a vendor lockin. Nem véletlen, hogy mindenkinek adni akarnak pöttynetet, mivel az infóiparban ökölszabály, hogy az a platform nyer, amelyiken a legtöbb és legjobb programok elérhetőek. Ezt lovagolja meg újra és újra az MS. Itt jön szarul az, hogy a Linux meg nem akarja kényszeríteni a felhasználókat magához, mivel egy csomó Linuxos programnak van win32 portja.
-
SzerzőBejegyzés
legutóbbi hsz