Mi az ami számomra vonzó a Linuxban és miért használom csak ezt?
2002-11-18T21:22:23+01:00
2002-11-22T22:31:10+01:00
2022-07-27T21:31:50+02:00
  • Sziasztok!

    Én elsősorban azért kezdtem el érdeklődni a Linux iránt, mert az Internet Explorer gyakran lefagyott (Win 98 alatt futtatva). Akkoriban még létezett a 150 Ft-os kedvezmény, amit így nem tudtam szándékom szerint kihasználni. Gondoltam Linux alatt futtatva a letöltőprogramot nem kell újrakezdenem egy letöltést sem.

    Később az a kellemetlen meglepetés ért, hogy míg Linux alatt tudtam használni a Yamaha Xwave 6000 típusú hangkártyámat, addig a Windows XP hardver-kompatibilitás elemzője inkompatibilisnek találta a hangkártyámat.

    Persze fontos volt a biztonság is, és reméltem, hogy a Linux megismerésével a számtech ismereteim is bővülnek.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    "mkeresztes" barátunk igen pontosan fogalmazott sajnos és éppen azért, hogy mindezeket elkerüljem, direkt úgy fogalmaztam a témanyitóban, hogy nehogy véletlenül valamilyen "összehasonlítgatósdi"-nak tünjék e fórum, vagy egy "mellét veregető pingvin" képe rajzolódjon ki.

    Tehát továbbra is az a cél, hogy pártalan és valós képet fessünk itt a Linuxról, mint akik használjuk naponta és megelégedve.
    Mindezt nyugodt higgadt szavakkal leírva és nem bíráló vagy összehasonlítgató (lenéző) stílusban.
    Mutasd a teljes hozzászólást!
  • A linux 'kozossegi erzese' paratlan. Akarcsak annak idejen a "Csoki" pentek esti osszejovetelen. Szamomra ez a legfontosabb.
    Mutasd a teljes hozzászólást!
  • Sziasztok,

    Miert van az ugy, hogy valaki elindit egy temat es rogton ra bizonyos emberkek, akik valoszinuleg feltunesi viszketegsegben szenvednek, rogton belekotnyeleskednek olyan dolgokkal amiknek semmi kozuk a temahoz? Miert szeretik ezek az emberek kavarni a sz*rt? Nem volna jobb ha inditananak egy uj temat ha van valami (meg)osztani valojuk?
    Az eredeti tema, ha meg valaki emlekszik ra, ez volt:

    "Ezt a fórumot abból a célból nyitottam, hogy ha bárki gondolja, akkor írja ide az élményeit, tapasztalatait, vagy azt,. hogy hogyan ismerkedett meg a Linux-szal és miért maradt meg mellette a mindennapokban. Ugyanis még sokak előtt ismeretlen e rendszer és bár növekvőben van a tábora, de nem árt ha első kézből kap egy "érdeklődő személy" híreket olyan forrásból, ahol valóban tapasztalati alapon vannak információk és nem mindenféle mende-monda és féligazságok kapcsán."
    Mutasd a teljes hozzászólást!
  • Az, hogy egy "deprecated" technológiához hozzáférést biztosit a .NET, nem jelenti azt, hogy azt neked használni is kell.

    Tény, hogy Win32 alatt .NET-ből szükséged lehet COM interopra, de nem feltétlenül.

    És nincs olyan nagyon sok Win32-specifikus dolog a .NET Framework-ben, de nem is cél, hogy ne legyen benne.
    Mutasd a teljes hozzászólást!
  • Szabvány az ami szabványosítva van. Azaz szabványos a bytekód formátuma, az objektumok, függvények, stb. elérése. De a könyvtárak már nincsenek szabványosítva, nem is lehetnek mivel egy rakat win32 specifikus dolog van benne. Ha teljesen szabványos, hordozható környezetet akartak volna csinálni akkor az kb úgy nézett volna ki mint a Java. Mivel nem ilyen így kb annyira lesz szabányos mint a C, azaz van egy standard library amivel a forráskód hordozható (sőt, eggyel jobb mert a bináris is hordozható) de lesz benne egy rakat OS függő dolog is.
    Mutasd a teljes hozzászólást!
  • "Más kérdés hogy akkor már egy füst alatt csinálnak GTK-s, QT-s, Gnome-os, stb interfészeket is neki. Így végül létrejön majd egy olyan .NET platform ami elég nagy mértékben, bár nem 100%-ban kompatiblis az M$-ral, viszont tud majd egy csomó olyan dolgot is amit az M$ nem, ez persze a másik oldalra is igaz, de kis erőfeszítéssel lehet majd olyan kódot csinálni ami mindkét platformon megy."


    Most akkor ennek mi értelme van?
    A .NET egy szabvány platform, méghozzá nem is rossz megvalósítással. Ha valaki holnap egy XY OS-re csinál egy HASONLÓT és "meg még egy csomó olyan dolgot amit az MS nem tud" akkor Te most azt mondod, hogy milyen fa*a csávó mert megcsinált olyat is amit az MS nem tudott/akart. Én pedig azt mondom, hogy HÜLYE, mert ha nem 100%-ig kompatibilis, akkor nem ér semmit. Ha van egy SZABVÁNY akkor azt lehet más platformra implementálni de nem kéne tőle eltérni.
    Mutasd a teljes hozzászólást!
  • Te szandekosan nezed hulyenek a vitapartnereidet?

    Bocs, az alapján amit írtál úgy tűnt nem igazán láttál még wine-t működés közben. Amúgy létezik ilyen emuláció is, bosch, vmware. Ezek tényleg tesztelésre szánt dolgok (bár a vmware akár élesen is használható egy kellőképp bika gépen).
    Mutasd a teljes hozzászólást!
  • "emulációt ne úgy képzeld el mint a C64 emulátort és társait"

    Te szandekosan nezed hulyenek a vitapartnereidet?
    Mutasd a teljes hozzászólást!
  • Senki nem talált fel semmit feleslegesen, a BDE-re is szükség volt anno (más kérdés hogy nem igazán szerettem őt úgy ahogy működött). Egyebek közt a PHP, Perl, stb fejlesztői sem, ezek is korábbiak mint Pl. az ADO ráadásul platformfüggetlenek is.
    Mutasd a teljes hozzászólást!
  • Szerintem ezt csak a nem-windozosok fajlaljak.

    Szerintem fogják ezt a windowsos fejlesztők is fájlalni csak várd ki a végét Ugyanis ha jól értelmezem a hírekből az M$ stratégiáját, ő épp a WIN32-től akar szép csönben eltávolodni hogy a .NET-es programokat használni lehessen a ping-pong labdától az űrállomásokig mindenben. Na most, szvsz ennek nem tesz igazán jót a túl nagy win függőség...

    Arra, hogy win kornyezetet _emulaljon_ az adott konyezetben. Az eredeti nyilvan sokkal hatekonyabb.

    Az emulációt ne úgy képzeld el mint a C64 emulátort és társait. Nem arról van szó hogy egy virtuális gépet szimulál a rendszer prociemulációval, hanem egyszerűen megvalósítja a win32-es hívásokat linux alatt. Nincs igazán lényegi sebességkülönbség egy wine alatt futó progi és a natív windows vagy linuxos alkalmazás között.
    Mutasd a teljes hozzászólást!
  • Meg a dbExpressre, meg az IBX-re meg a többire

    A dbExpress-re a platformfüggetlenség miatt van szükség (az ADO ugye nem az), az IBX meg natív komponens, amit az IB-hez drótozott alkalmazásokban érdemes használni, performance okok miatt. A lényeg, hogy a Borland nem "talált fel" semmit, amire nem volt szükség (tehát nem n+1-edik interfészeket hozott létre). Ahogy szavaidból kivettem, Te ezt állítottad (egyel korábban).
    Mutasd a teljes hozzászólást!
  • Feltételezem, itt a BDE-re gondolsz. Ezzel csak az a baj, hogy a BDE évekkek (évtizeddel) el?bb létezett, mint az ADO.

    Meg a dbExpressre, meg az IBX-re meg a többire Nincs is ezzel semmi baj, mindenki használja azt ami szimpatikus neki.

    Ha már használtad volna mindegyiket, akkor tudnád, hogy ég és föld különbségek vannak sebességben és egyéb tekintetben is ezek között.

    Ezt egy percig sem vitatom. Itt csak arról van szó hogy az hogy egy program X interfészen keresztül fér hozzá egy adatbázisszerverhez semmiben nem zavarja a másik programot ami viszont az Y interfészt használja. Azaz lehet hogy az egyik progi mondjuk Kylix alól IBX-szel vagy dbExpressel viszi fel az adatokat, majd egy másik program PHP-ből teszi elérhetővé a neten. Ez nem olyan mint a régi szép DOS-os időkben amikor Pl. a Turbo pascalban használatos adatbázisokat (már nem emléxem a nevére) nem lehetett elérni más nyelvből.
    Mutasd a teljes hozzászólást!
  • "szegény mono fejlesztők"

    Hehe, ez jo :)

    "ha az M$ nem tervezett előre és win32API függővé tette egy picit a .NET-et "
    Szerintem ezt csak a nem-windozosok fajlaljak. Az MS tovabb fejlesztette a _sajat_ rendszeret, nemertem miert varsz el egy cegtol olyasmit, hogy sajat strategiaja ellen lepjen... Egyszeruen nem ertelek, mikor ilyen erveket hozol fel.

    "A wine/winelib ugyanis erre lett kitalálva..."
    Arra, hogy win kornyezetet _emulaljon_ az adott konyezetben. Az eredeti nyilvan sokkal hatekonyabb. Az emulacio tesztelesnel, illetve gazdasagossagi szempontokat figyelembe veve johet szoba csak. De emulaciora epiteni ?!?! Ezerszer meggondolando.

    RDBMS Jol ertelmezem, hogy ez a Realtional DataBase Management System akar lenni? Ebbol miert lenne csak egy? Ebbol rengeteg van, linux alatt is. En az ezekre epulo API-k egysegesseget hianyolom. Az RDBMS-nek persze, hogy teljesen mind1, hogy ki hogyan cseszegeti oket, itt arrol van szo, hogy minden apinak megvannak a jellegezessegei, hibai, erossegei, es ha valaki jo minosegu kodot akar irni, akkor az osszes kis api tulajdonsagait ismernie kell. Nem veletlen, hogy amig en jartas vagyok az ADO-ban, addig a Borland BDE-t nem ismerem annyira, igy ha lehet elkerulom. Az egysegesites nelkuli API-k eseteben ezt nem teheted meg, szoval kompromisszumra kenyszerulsz. Felaldozod a jo minosegu kodot, mert nincs idod minden kis api kiismeresere. (Ja bocs, free fejlesztes eseten persze van idod, csak lusta vagy)
    Mutasd a teljes hozzászólást!
  • Egyébként Pl. a Delphi windowson is a saját API-ját használja (amellett hogy elérhető az ADO is).

    Feltételezem, itt a BDE-re gondolsz. Ezzel csak az a baj, hogy a BDE évekkek (évtizeddel) előbb létezett, mint az ADO.

    Na most nem mindegy annak a szerencsétlen Interbase szevernek hogy most dbExpress alól piszkálom vagy PHP alól vagy ADO-ból, esetleg jdbc-n vagy odbc-n keresztül ?

    Ha már használtad volna mindegyiket, akkor tudnád, hogy ég és föld különbségek vannak sebességben és egyéb tekintetben is ezek között. Itt nem csak a köztes rétegek számának növekedéséből adódó teljesítménycsökkenésre kell gondolni, hanem arra is, hogy pl. egy ADO jóval nagyobb mértékben engedi paraméterezni a kapcsolatokat, lékérdezéseket, mint mondjuk egy ODBC, aminek következtében a teljesítmény sokkal inkább a konkrét alkalmazási logikához igazítható, "idomítható".
    Mutasd a teljes hozzászólást!
  • Ujabb szep peldaja az elore tervezes hianyanak. Oldjunk meg mindent barmilyen aron, nemszamit a hatekonysag, csak mukodjon. De ugyanilyen pelda, hogy mindenki megcsinalja a sajat kis adatbazis apijat, ahelyett, hogy lenne egy jol megtervezett api (lasd ADO), ami ala mindenki a providereit irna meg. Ehelyett mindenki szenved, ha egymas adatbazisaban kell turkani.


    Mit csináljanak szegény mono fejlesztők ha az M$ nem tervezett előre és win32API függővé tette egy picit a .NET-et ? Nagyjából két út állt előttük: 1. nekiállnak és írnak egy saját win32 implementációt, 2. felhasználják a meglévőt. Egyébként ugyanezt tette az M$ is, csak ő a saját win32 API megvalósítását használta a .NET-hez. Nem igazából látom hogy ez mennyivel lenne kevésbé hatékony mint ha újra megvalósítják a win32 API-t. Egyébként nem csak az előre tervezés hiányától szenvedő mono project választota ezt az utat, hanem Pl. a borland Kylix implementációja is erre épül, vagy a CorelDraw 9 és a Corel Office linuxos verziója meg még egy rakat másik nagy cég kereskedelmi programja. A wine/winelib ugyanis erre lett kitalálva...

    Egyébként Pl. a Delphi windowson is a saját API-ját használja (amellett hogy elérhető az ADO is). Azt meg hogy szenvednének a programok az egymás adatbázisában való turkáláskor végképp nem értem, amikor az API mögött lévő RDBMS ugyanaz. Na most nem mindegy annak a szerencsétlen Interbase szevernek hogy most dbExpress alól piszkálom vagy PHP alól vagy ADO-ból, esetleg jdbc-n vagy odbc-n keresztül ?
    Mutasd a teljes hozzászólást!
  • "[...] win32 API hívásokat már most is úgy oldja meg hogy a wine-t használja. Szvsz így lesz megoldva a COM és a többi windowsos dolog is."

    Ujabb szep peldaja az elore tervezes hianyanak. Oldjunk meg mindent barmilyen aron, nemszamit a hatekonysag, csak mukodjon. De ugyanilyen pelda, hogy mindenki megcsinalja a sajat kis adatbazis apijat, ahelyett, hogy lenne egy jol megtervezett api (lasd ADO), ami ala mindenki a providereit irna meg. Ehelyett mindenki szenved, ha egymas adatbazisaban kell turkani.
    Mutasd a teljes hozzászólást!
  • Az M$ pont itt fogja megszívni a .NET-tel szerintem. Ugyanis a .NET egyik fő indítéka hogy végre megszabaduljon a nem túl szerencsés csillagazat alatt született WIN32 API-tól. Viszont igen erősen kötődik hozzá. Ez egyébként igazából a mono-nak nem akadály: a windows.forms és a natív win32 API hívásokat már most is úgy oldja meg hogy a wine-t használja. Szvsz így lesz megoldva a COM és a többi windowsos dolog is.
    Mutasd a teljes hozzászólást!
  • Nem ismerem olyan részletesen az ADO API-t hogy meg tudjam mondani mennyire bonyolult egy ilyen. Mindenesetre adatbázis interface architektúrája Pl. a Gnome-nak is van (gnome-db) elég rég óta. Más kérdés hogy nem igazán használja senki mivel az ügyviteli programot Kylixban írja az ember aminek ugye van saját ilyenje (dbExpress, ráadásul nem is rossz a cuccos) a kisebb webes dolgokat pedig PHP-ben (neki viszont szintén van saját adatkezelő interfésze). Ugyanez a helyzet egyébként a Perl és a Python nyelvvel. A mononak pedig szintén meg vannak valósítva (vagy épp megvalósítás alatt vannak) az idevágó dolgok (de ő speciel már tudja használni a gnome-db-t is).
    Mutasd a teljes hozzászólást!
  • tompp:
    Az MS-nek "konnyu" dolga volt a dotnetet raepiteni a mar meglevo speckokra (megint az ADO-val hozakodok...) pl. az ADO.NET egyertelmuen ADO alapu, tul sokat nem tettek hozza. De mit fognak kezdeni a mono 'implementatorai' ??? Raadasul COM hatter (compatibilitas) nelkul a .NET nagyon sokat veszitene az ertekebol, unixokon pedig nincs is meg a COM hatter... Nem veletlenul csinalta meg az MS csak win platformra a .NET-et(uzletpolitikai okokon kivul) igazan sokat csak win alatt er.
    Mutasd a teljes hozzászólást!
  • "Nem. Arra példa hogy a linux is elmegy a userek irányába, olykor előbb is mint a win."

    Es tudod miert? Mert egy skinezest joval egyszerubb es latvanyosabb megvalositani, mint mondjuk egy ADO API-t. Szo sincs a userbarat szempontrol, mint strategiarol.
    Mutasd a teljes hozzászólást!
  • a hangsuly a "mast sem tesz"-en volt.
    Mutasd a teljes hozzászólást!
  • A mono nem masolata, hanem implementacioja a dotnet-nek. A M$ eppen szabvanyositja a dotnet-et (CLX) es a standard tervezet barki szamara hozzaferheto.

    Mutasd a teljes hozzászólást!
  • Azt hiszem az nem kerdes, hogy a Linuxos alkalmazasok vagy a Linux versenyezhet-e a Windowsal. Mar azt teszi.
    Azonkivul barmennyire is igyekeznek a nagy cegek (pl. Ximian, vagy Sun) bolondbiztos Linuxot csinalni, nem igazan ez a fogyasztokozonseg. Ok viszont Pingvin-politikat folytatnak, reven a sajat termekuk az otthoni piacon versenykeptelen.

    Ettol fuggetlenul a M$ igazan csiszolhatna mar a parancssoron egy keveset. Legalabb valtoztathato fontkeszletet ...
    Mutasd a teljes hozzászólást!
  • Szoval ez lenne a specifikaciok ereje? A Skinezes? Nem is tudom, hogy nem pont a linuxosok szoktak-e azt mondani, hogy a win nem mas mint csillivili jo marketingel? Es akkor azzal josz, hogy a KDE skinezheto? Mokas.


    Nem. Arra példa hogy a linux is elmegy a userek irányába, olykor előbb is mint a win.


    Koppintasrol meg par szot. Mindenki otleteket masol mindenkitol. Ez igy helyes.


    A mono arra lett volna pelda, hogy a free vilag mast sem tesz, csak mas otleteit valositja meg, amit nem elitelek, hanem kicsit sajnalok.


    Világos. Ha az M$ másol valamit az így helyes, ha a free világ akkor azt ugyan nem ítéled el csak kicsit sajnálod

    Nos, a mono-nak bizonyos mértékig muszály M$ kompatiblisnek lennie elvégre az a cél hogy a .NET-nek legyen egy M$-tól független implementációja. Más kérdés hogy akkor már egy füst alatt csinálnak GTK-s, QT-s, Gnome-os, stb interfészeket is neki. Így végül létrejön majd egy olyan .NET platform ami elég nagy mértékben, bár nem 100%-ban kompatiblis az M$-ral, viszont tud majd egy csomó olyan dolgot is amit az M$ nem, ez persze a másik oldalra is igaz, de kis erőfeszítéssel lehet majd olyan kódot csinálni ami mindkét platformon megy.

    Én is jobban örültem volna ha ez az egész dolog nyílt platformon zajlik ahol az egész rendszer platformfüggetlen, de ez van. Most viszont hogy az M$ kihozta a szabad világnak muszály alkalmazkodnia ha életben akar maradni.
    Mutasd a teljes hozzászólást!
  • Ez nem így m?ködik. Pont a piaci alapokon m?köd? cégek a fizetetett programozóikkal azok akik a legjobban megérzik ha valamit nem úgy csinálnak ahogy az ügyfél szeretné, mert a piac azonnal szelektál, és az ügyfél máris vált egy másik céghez, aki jobb, stabilabb, gyorsabb alkalmazást készít neki.


    Azért a cégek nem tudnak annyira könnyen váltani. 1. A szoftvert már megvették, nem szívesen fizetnének ki ugyanannyit egy másik szoftverért. 2. Az adatok már abban a szoftverben vannak rögzítve. 3. Nagyobb cég esetén az ügyvitel ki van valahogy alakítva, ezt nem olcsó átalakítani egy másik cég szoftverére vagy az adott szoftvert átalakítani az adott céghez. Arról az esetről nem is beszélve amikor a Gipsz Jakab Bt megcsinálja a Pistike KFT websiteját, a dolog műxik aztán szépen elfelejtik egymást. Egy év múlva pedig (amikor a gari letelik, már ha van ilyen) meg összeomlik az egész...

    Ezzel szemben a nyílt forrású projektnél nincs közvetlen visszacsatolás a célközönség és a fejleszt?k között

    Ez így ebben a formájában nem igaz A legtöbb nyílt kódú programnak van levlistája, a jobbaknak külön user levlista is.
    De az is egy lehetőség hogy fogsz egy másik nyílt kódú programot és használod azt. Én sem szeretem a Bluefish-t ezért használom a Quanta-t. Ízlések és pofonok...

    Kivételek persze az olyan nyílt forrású projektek, ahol valami nagy tapasztalattal rendelkez? cég áll a háttérben

    Azért a KDE, Gnome, Apache, stb elég jól elvan enélkül is...
    Mutasd a teljes hozzászólást!
  • "Túl nagy felelősség a céges programozót, sőt magát a céget sem terheli"

    Ne viccelj! Minden azon mulik, hogy a megrendelonek milyen a benyomasa rolad, mi a velemenye a munkadrol, legalabbis egeszseges gazdasagban ezen kene mulnia.

    "Gnome már vagy 5-6 éve témázható, pár éve a KDE is az "

    Szoval ez lenne a specifikaciok ereje? A Skinezes? Nem is tudom, hogy nem pont a linuxosok szoktak-e azt mondani, hogy a win nem mas mint csillivili jo marketingel? Es akkor azzal josz, hogy a KDE skinezheto? Mokas.

    Koppintasrol meg par szot. Mindenki otleteket masol mindenkitol. Ez igy helyes. Ha en autogyarat szeretnek epiteni, akkor abbol valoszinuleg 4 gumikereku, 1 kormanyu, kezifekes, ABS-es, stb. autok gurulnanak ki. Akkor en most masoltam? Igen. Elitelendo? Nemhiszem. Vegelethatatlan a lista az egymas otleteinek sajat megvalositasarol az IT iparban, hat persze. A mono arra lett volna pelda, hogy a free vilag mast sem tesz, csak mas otleteit valositja meg, amit nem elitelek, hanem kicsit sajnalok.
    Mutasd a teljes hozzászólást!
  • Túl nagy felelősség a céges programozót, sőt magát a céget sem terheli. Lásd licenszszerzősések. Viszont az hogy egy nagy projectbe mi megy be vagy mi nem megy be azt azért eléggé megnézik, és ha nem megy be az egyrészt azt jelenti hogy hiába dolgoztál, másrészt ha túl nagy hülyeséget csinálsz akkor egy rakás embernek meg lesz a véleménye rólad (és az nem túl pozitív).

    Ez nem így működik. Pont a piaci alapokon működő cégek a fizetetett programozóikkal azok akik a legjobban megérzik ha valamit nem úgy csinálnak ahogy az ügyfél szeretné, mert a piac azonnal szelektál, és az ügyfél máris vált egy másik céghez, aki jobb, stabilabb, gyorsabb alkalmazást készít neki. (Ez alól egyetlen kivétel van: ha monopolhelyzetben van valaki.) A licenszerződések csak a kártérítés-követelésektől védik meg a fejlesztőt, de ha nem tud újabb szoftvereket eladni, akkor gyorsan felkopik az álla.

    Ezzel szemben a nyílt forrású projektnél nincs közvetlen visszacsatolás a célközönség és a fejlesztők között (most azt, hogy valaki megírja a véleményét a programról, felejtsük el, mert én pl. egy ujjamon meg tudom számolni hány ilyen levet készítettem; ha szarul működött a program egyszerűen lenyomtam, és kerestem másikat), és éppn ezért hajlamosak az ilyen projektek teljesen más irányba elmenni, mint amit a felhasználók igényelnek.

    Elsősorban ez az oka annak, hogy a Linux, és általában a nyílt forrású alkalmazások nem igazán tudnak versenyezni a kereskedelmi alkalmazásokkal. (Kivételek persze az olyan nyílt forrású projektek, ahol valami nagy tapasztalattal rendelkező cég áll a háttérben, és irányítja a fejlesztést, mint pl. az Apple a Darwin esetén, a Sun az OpenOffice-nál, stb.)
    Mutasd a teljes hozzászólást!
  • Meg ha ez igy is lenne (ami szerintem nincs igy, mert a programozot nem terheli feleloseg

    Túl nagy felelősség a céges programozót, sőt magát a céget sem terheli. Lásd licenszszerzősések. Viszont az hogy egy nagy projectbe mi megy be vagy mi nem megy be azt azért eléggé megnézik, és ha nem megy be az egyrészt azt jelenti hogy hiába dolgoztál, másrészt ha túl nagy hülyeséget csinálsz akkor egy rakás embernek meg lesz a véleménye rólad (és az nem túl pozitív).

    Nem tervezel elore. Az adott eszkozokkel megvalositod a celjaidat, vagy a projekt celjait, de uj infrastrukturat nem hozol letre, se te, se mas csak a mar meglevoeket hasznalod, es ezekre epitessz. Nem hozol letre OLE-t, COM-ot, ACtiveX-t, DCOM-t, SOAP-t, DirectX-t, ADO-t, ASP-t, .NET-et, stb.


    Azok a projectek amik ezt igénylik (Pl. KDE, Gnome) igenis terveznek előre, megvan a roadmap, a tervezet feature-ök, és ezek a dolgok elég sok innovációt is tartalmaznak. Pl. a Gnome már vagy 5-6 éve témázható, pár éve a KDE is az (lásd most az XP). Mindkettőnek van saját komponens architektúrája meg egy rakás más szolgáltatása.

    SOAP: Ez speciel egy igen jó példa arra hogy hogyan kellene működinük a dolgoknak. Több cég közös megállapodása és nyílt szabvány (w3c). El is érhető mindenfelől, egyebek közt linux alól ugyanúgy mint W$ alól.

    ASP: Végül is az is van az Apache-ból elérhető, de igazából linux alatt a PHP terjedt el, szvsz ez arra a célra amire ezek ki vannak találva tökéletes. Ráadásul platformfüggetlen, sőt valamivel még gyorsabb is.

    Lenyúlás/koppintás: Az igaz hogy a mono a .NET koppintása, viszont a .NET pedig a javáé (ugyanaz a managed kód, JIT, memória management, stb). Sajnos sok mindent koppintani kell nem azért mert nem lehetne jobbat kitalálni mint amit az M$ csinál, csak ugye az erősebb kutya b*szik, így a linuxos programoknak alkalmazkodniuk kell az M$-hoz ha élni akarnak. És ez vitathatatlanul az M$ előnye, ugyanis egyfelől sokkal könnyebb valamit kitalálni és megvalósítani mint egy már meglévő dolgot lemásolni, pláne ha az adott dolog még nincs is ledokumentálva. A másik probléma pedig amikor valaki izomból bevezet egy általánosan használt dolgot aztán jól levédi.
    Mutasd a teljes hozzászólást!
  • Szia Szinbád!

    Az őszinteséged dícséretes!

    És ebből is (amit írtál) talán (sokak) láthatják, hogy azért már csak nem olyan "gagyi" ez a Linux-nak nevezett 'csecsebecse'.
    Mutasd a teljes hozzászólást!
abcd