Fejlesztés Linux DeskTop vagy inkább WEB app. (Biztos, hogy kell nekünk a Linux? )

Flame

[Cím módosítva]

Üdv Mindenki!

Először is:
Nem szeretnék senkinek a hitvallásába gázolni!
pró-kontra.

Szeretnék visszatérni a programozásba és nagy dilemma előtt állok.
15 éve ismerem a Linuxot. Szerver oldalon szerintem nagyon jó!
Viszont 15 éve azt hallom, hogy 1 év múlva milyen jó lesz kliens oldalon is. És azóta sem jött a nagy áttörés.

Adatbázis kezelő programokat szeretnék készíteni. Amit tudok az az, hogy Linux Server, PostgreSQL :)

És itt jön a gondom:
Nagyon tetszik a VS C#. De ebben az esetben csak m$ gépekre tudok fejleszteni.
Legyek platform független?
- Java? Szerintem még mindig nagyon bugyuta desktop alkalmazásokra.
- Web alap? Akkor marad a PHP. Viszont ez megint nehézkes. Nincs DataSet, Binding, Grid stb...
-- ASP nem igazán fut Apache alatt.

Tapasztal szakemberek:
Van értelme web alapon gondolkoni? Jobb a C# mivel itthon úgyis a többség windows-t használ?
(számlázó, raktár, project, HR.. és hasonló alkalmazásokra gondolok)

  • 6347 megtekintés

( honorshark | 2010. 02. 12., p – 22:33 )

C++ / Qt meg hasonlok?

Amugy C#-ot lehet futtatni Linux / mas alatt Mono segitsegevel, tehat a dolog nem veszett. A gond ott jon hogy eleg nehezkes megoldani hogy cross-platform legyen a dolog. Linux alatt C#-ot fejleszteni meg kinszenvedes. (A monodevelop valami katasztrofa.)

Igen, és most néztem az árát. Nem túl baráti: 2995 euró. :(

The Qt Commercial Developer License is the appropriate version to use for the development of proprietary and/or commercial software. This version is for developers who do not want to share the source code with others or otherwise comply with the terms of the GNU Lesser General Public License version 2.1 or GNU GPL version 3.0.

http://qt.nokia.com/products/pricing

Ha a Qt platformnak a forrasaba belepiszkitasz, lebuildeled, es ezt nyujtod a felhasznalo fele. Tekintve hogy a Qt opensource platform, ez technikailag megteheto - es itt jon kepbe a licenc, miszerint jogilag viszont nem.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

- C#-ban fejleszteni eleve gyorsabb, mint C++-ban (nyilvan lehet olyan programozokat talalni, akik C++-ban is relative gyorsak, de en latom mindkettot, elobbiben joval porgosebb a fejlesztes).
- WPF-ben rengeteg kesz kontroll van
- WPF teljesen kompozit, Qt-ban nem tudsz olyat csinalni, hogy a sima Button-ba beleraksz egy Listboxot, amiben videok vannak (hulye pelda, tudom)
- WPF-ben vannak dependency propertyk, nagyon kenyelmes

----------------------
while (!sleep) sheep++;

( crape | 2010. 02. 12., p – 22:44 )

Mono-ról nem is hallottál?
www.wondeer.com : Mono-ban ASP.NET site. Mono gyorsan fejlődik, eddig igen stabilnak és bugmentesnek találtam.

( sz332 v | 2010. 02. 12., p – 22:45 )

Java-val konkrétan mi a gond? Tetszőleges RCP-vel (Eclipse RCP, Netbeans hasonló cucca)
"jól kinéző" progikat lehet írni, igazából szerintem mindent, amit más keretrendszerrel.

Java-ban (swing) sincs "vagy eddig én nem találtam" DataSet, DataTable, DataGrig, Binding. Egyszer már próbálkoztam vele, de pont ezek hiánya miatt elment tőle a kedvem.
Se kedvem se pénzem se időm ezeket magamnak megvalósítani.
Pedig elkezdtem egy saját DbTable -t a JTable-ből származtatva :) Csak pont a binding-nél elakadtam.

Hat de tevedsz. A Hibernate egy db-related dolog, a jsphez konkretan nulla koze van.

Technologiaban hasonlo, mint a JPA, csak itt nem csak JPA felulet van, hanem sajat is. Bar, ha ram hallgatsz, akkor toplink/eclipselink es jpa.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha neked ezek kellenek, akkor nem a Delphi a barátod? :)

Egyébként pontosan mi lenne a use case, amire használnád?

http://swingset.sourceforge.net/
http://www.ibm.com/developerworks/opensource/library/os-ecl-jfacedb1/

ami még kérdés, hogy milyen tapasztalatod van fejlesztés terén, mert ez is nagyon sokban meghatározza a lehetőségeket.

( lorinczi v | 2010. 02. 12., p – 23:00 )

Vedd figyelembe, hogy amatőr vagyok:
Évekig fejlesztettem VB 6/M$SQL 7 alatt, aztán gondoltak egyet M$-ék, és szépen lassan működésképtelenné váltak a progijaim. Ami NT alatt símán települt és futott, most helyből meghal.
Szerintem a webes felület ami szabványos, időtálló. Php alatt tényleg kevésbé kényelmes a fejlesztés, de ha a kliensen van egy működőképes böngésző, működik.
---------------------------------------------------------------------------
Környezetvédelmi nyilatkozat: Ez a hozzászólás kizárólag reciklált elektronok felhasználásával íródott.

Ebben egyet értek. Én is fejlesztettem VB6 alatt. ;)

Viszont a böngészők is kutyák :) Mennyi is van most? 4-5?
Mennyire is támogatják a szabványokat ? (pl.: css, html)
No meg jön a HLTM5. CSS ki tuja mennyi? Ezt eddig nem tudták egységesem követni.
És akkor még ott az xml, dhtml, javascript stb...

Azt sem értem, hogy miért nincs a mai napig egy RFC szabvány a dokumentumokra, táblázatokra, prezentációkra! Ha lenne akkor szerintem nem lenne gond, hogy most éppen openoffice-t vagy m$ office-t használok.

( agoston | 2010. 02. 12., p – 23:40 )

Ha már eldöntötted, hogy miben fejlesztesz, akkor minek teszed fel a kérdést? Mert nekem nagyon úgy tűnik, hogy c# nálad a nyerő.

A Desktop alkalmazásokhoz remek RAD a VS, csakhát az m$, minden vonzatával együtt.

A webes fejlesztés a telepítgetési/karbantartási maceráktól menekít meg, és mondjuk nem csak a cégnél, hanem otthon is lehet használni. Kétségtelen nincs hozzá olyan szép fejlesztő eszköz, de pl. java-hoz Eclipse-ből elég hasonló dolgokat pikk-pakk össze tudsz rakni.

Múlt héten néztem a Netbeans-t is, az is szépen alakul, talán nincs hozzá annyi framework támogatás (nekem ugyanis SEAM kellett volna).

Szóval szerintem érdemes kicsit körülnézni még, nem leragadni a m$-nál, lévén annak szerintem kicsit borsos az ára.

Különben a keretrendszerek pont azért vannak, hogy a böngészők különbségeit elfedjék. De ha zárt közösségnek fejlesztesz, akkor ugyanannyi erőszak megkövetelni a windows-t, mint hogy mondjuk IE-ben használják a web-es alkalmazást. Ha meg nagyobb közönségnek szánod, akkor meg sajnos gondolnod kell mindenféle más rendszerek használóira. Én pl. iszonyat módon utálom az IE6.0-át, de a stat-ok szerint az emberek 10%-a még mindig azt használja.

Éppen ez a bajom, hogy még nem döntöttem el. Igazából C# és PHP között vergődöm.

C#:
Csak win kliens. :(
M$ függőség :(
Kicsit macerás DB kezelés. (mivel PostgreSQL) |)
VS Express Free :)
Minden adott a DB fejlesztéshez :) [dataset,binging,grid, stb..]

PHP:
Semmi sincs igazából a DB fejlesztéshez :(
ami nagyon kellene a Grid és a Binding
Nincs igazán jó RAD hozzá :(
Web alapú |)
Free :)
Cross platform :)

Java:
Fenti kettő keveréke
Sokkal több idő kell a megtanulásához.

Mondjuk hogy a nevedben mit keres a java ilyen kerdesekkel... na mindegy :)

(Aki ismer, az tudja, hogy utolsok kozt fogom partolni azt a rendszert, de megis.)

Figyu, irhatsz egy ASP.NET appot, akkor lesz databindingod, meg minden ilyesmid, es linux desktoprol is hasznalhato lesz, mindossze kell hozza egy win szerver.

Irhatsz egy ext.js appot, akkor hirtelen lesz databindingod, igaz, az IE nem feltetlenul a megfelelo bongeszo egy nagy ext.js app futtatasara, de egy wines app feltelepitese versus mozilla vagy chrome feltelepitese .. erted.

Ext.JS-hez viszont nagyon folyamatban a rendes RAD, http://ajaxian.com/archives/extjs-designer

Van meg par ilyen, nem tudom, a capuccino vagy az atlas epp hol tart, ilyesmik porogtek tavaly: http://ajaxian.com/by/topic/atlas

Ekkor a backend lehet php, python, java, .net, assembly, erlang, nem tudom, mihez ertesz tenyleg.

Esetleg natur PHP eseten mondjuk nezz egy symfony -t, az general szepen crud-ot (=adatbazis-felulet). Javaban is van egy csomo ilyen projekt, egyesek RAD-nak is hivjak magukat (pl. ilyen ujabban a roo)

Vagy fejleszthetsz RAD-ot, azert annyira nem bonyesz egy databindingot megirni, csak bele kell gondolni.

(Tudom, kezdoket ne ijjesztgesek ilyenekkel, elnezest)

a java IDE-krol az "ezt nem gondoljatok komolyan" temakorben szivesen beszelgetek, de ELVILEG mintha a netbeans is segitene hasonlo dolgokban JSF felett, nem tudom, reg volt amikor ilyenekkel kellett szorakoznom, elmeletileg elkepzelheto, hogy mar annyira nem is bugosak, mint anno (ill. bugos akkor se volt, csak atgondolas helyett mindig megmagyaraztak, miert jo ugy ahogy nemaz)

Eclipse-hez van ilyen csoda, sok sikert hozza: http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.ve.examples/o…

A javahoz tenyleg sok ido kell, ebbe most nem megyek bele, hogy miert, mert megesznek reggelire, mindenesetre opciod mint a tenger, a postgres nem fog nagyon zavarni szerintem, es a kliensek jo ideig winen futnak meg varhatoan.

Upd: csak hogy lass GUI-s peldat javara meg: http://netbeans.org/community/magazine/html/03/matisse/

A VS csak a fejleszteshez kell, c# programot lehet buildelni netframeworkkel, az meg siman letoltheto. a mono is tudja futtatni az elkeszitett programot, mar ha nincs nagyon win specifikus dolgaid.

Ha mindenkepp ittis-ottis mukodo progit szeretnel akkor meg QT. (van qt addons for VS, szal tudsz azzal is fejleszteni)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Esetleg megnézhetnéd a wxWidgets cuccot is. http://www.wxwidgets.org/
C++ nyelv, cross-platform.
Azt nem tudom milyen IDE van hozzá, de QT-nél ezerszer jobb választás, mivel ez nem egy böszme, erőforrászabáló függvénytár. De az elvárásaidnak tejesen megfelel: szinte azonos app készíthető vele Winre, Linre, Macre, stb.
Gondold meg!

--

nTOMasz
"The hardest thing in this world is to live in it!"

Kevés akkora bug halmaz van, mint a wxWidgets. Jobb a Qt. Sokkal. Főleg, hogy a legtöbb Linux-on alapból fent van, wxWidgets-ből meg nézegetheted az egzotikus változatokat a különböző disztrók alatt. A wxWidgets-ben nagyon sok a WTF faktor, ráadásul nem is olyan szépen tervezett, mint a Qt. Emberünk megírja a kódot 4.3-as Qt kompatibilisre és bármilyen disztrón szépen el van vele (szerk.: talán CentOS-en még 4.2 van, tehát akkor arra írja).

Ráadásul az SQL kapcsolat kérdés volt, abban meg kb. makett kategória a wxWidget.

"böszme, erőforrászabáló" -> mutass rá légy szíves példát! Az ő programjához kell használni a QtCore-t, a QtGui-t és a QtSql-t, de hogy nehezítsünk linkeljük mellé a QtXml-t és a QtNetwork modult is. Ez nálam összesen 6 MB dll-ben (Qt 4.3.5, VS 2005 SP1-ben, Release fordítás, általam forgatva, Qt3 support nélkül.). 2010 van. 2001-ben sem volt gond a PIII-asomon 6 MB RAM...
--
http://www.naszta.hu

Kevés akkora bug halmaz van, mint a wxWidgets.
Ha valaki a HUP-ot olvasva akar átfogó véleményt kialakítani, akkor előbb utóbb arra a következtetésre jut, hogy minden egy hatalmas "bug halmaz", legjobban teszi, ha harakirit követ el, vagy ha elég kitartó, akkor elmegy kecskepásztornak, mert sikereket csak ott érhet el.
Mindeközben a "bug halmaz"-okkal mások sikeresen készítenek programokat.
Én a kevésbé kategorikus megfogalmazásokat szeretem. Mondjuk a valahogy így: "wxWidgets nekem nem igazán vált be, a QT-val viszont egészen jók a tapasztalataim." Vagy "A wxWidget x.yz verzióváltása után az addig jól működő dolgaim, instabilak lettek sőt gyakran hibásan vagy egyáltalán nem működtek." stb.
--
Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

Akkor legyen így: a wxWidgets nekem nem igazán vált be, a QT-val viszont egészen jók a tapasztalataim. A wxWidget több verzióváltása után az addig jól működő dolgaim instabilak lettek, sőt, gyakran hibásan, vagy egyáltalán nem működtek.

Így OK? :)
--
http://www.naszta.hu

Örülök, hogy megértetted a mondanivalóm lényegét. :-{)E
Kicsit tartottam tőle, hogy szurka-piszkának veszed, pedig egyáltalán nem annak szántam.
Abban csak reménykedem, hogy valamelyest egyet is értesz vele.
--
Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

( lepton | 2010. 02. 12., p – 23:58 )

Mar ne haragudj, de miert akarsz Linuxra fejleszteni, amit leirsz abbol az fenylik halvanyan mintha nem szabad szoftveres alkalmazast keszitenel... ha igy van akkor 2 okbol is felesleges linux ala fejleszteni, egyreszt kevesebben hasznaljak mint a wint, masreszt aki linuxot hasznal, azoknak az embereknek nagyresze, hisz a szabadszoftverek erejejeben :) es eszukben sincs penz fizetni egy szoftverert... amugy ha valoban lenne kereslet Linuxus ugyviteli alkalmazasokra, es valoban nagy ur lenne a Linux desktop alkalmazasok teren akkor nyilvan desktop fejleszto rendszerekbol is nagyobb valasztek lenne linuxra.... szoval... tudod fojtatni a gondolatmenetet.....

Qt-vel fejleszthetsz nem szabad szoftvert, sot mar LGPL licensszel is 4.5-s verzio ota, egyebkent meg ez nem igaz, hogy az iparban linuxot alkalmazo cegek ne fizetnenek a linuxert, igenis kifizetik, azt az egy drivert, vagy alkalmazast, ha mast a vasat, plusz a fejlesztojet, minthogy x windows licenszt vasaroljanak, sot egyre tobb kormanyzat, stb. allt at linuxra, itt is rengeteg cikk olvashato a HUP-on errol folyamatosan.

http://djszapi.homelinux.net

Igen, ez lehet jo indok ipari, ceges kornyezetben, de ott nem is volt kerdes hogy fizetnek-e azert amire szukseguk van.
De desktopon mas a helyzet... szolgaltatni akarhogy nezzuk nagyabol csak egyedenkent lehet... de legalabbis mindenestre kisebb celkozonsegnek, mintha "programot adnal" el, es akkor is ott van a kerdes, kinek szolgaltatsz, aki 10 eve Debiant hasznal? Vagy aki azt mondja o a nagy linuxos, de igazabol, csak van a gepen egy linux, es ha barmire szuksege van wint hasznal es persze elvarja (tisztelet a kiveteltol), hogy linux alatt azert 10-szer tobbet tudjon ugyanaz a dolog ingyen amiert mashol nem keveset kell fizetne... Azert pedig, hogy egy kis ceg egy ugyviteli szoftver miatt aljon at linuxra... meg kevesbe nepszeru...

Nem egyéneknek akarok desktopot üzemeltetni. Hanem cégeknek, de akár egyéneknek is, adott, jól körülhatárolt feladatokat akarok megoldani úgy, hogy ők megmondják, mi a probléma, a többit megoldom én. És nem linuxot adok el, hanem a probléma megoldása a szerződés tárgya.
"Azert pedig, hogy egy kis ceg egy ugyviteli szoftver miatt aljon at linuxra... meg kevesbe nepszeru...": pedig simán átállnak. Pontosabban nem érdekli őket, hogy mi micsoda, ők egy klikket akarnak, ami megoldja a bajukat. Hogy min fut, az nem merül fel kérdésként.

Bocsi, de egysíkúnak tűnik a nézőpontod a Linuxszal kapcsolatban. A Linux egy elég komoly üzlet tud lenni, főleg céges környezetben. Szóval, ha megfelelő portfólióval állsz elő, akkor egyáltalán nem felesleges rá fejleszteni.

Én magam, szívesen vennék rá programokat, ha megfelelően ki lenne dolgozva ez a kérdés és lenne egy normális desktop üzleti menet.

A szabad szoftveres fejlesztés és még Linuxon is csak választható opció és nem egy kötelező dolog.
===================================================
Ubuntu 8.04.4, AIX, Windows XP Home, Windows XP Pro

( sibidiba | 2010. 02. 13., szo – 01:43 )

Aki ebben a szakmában bármilyen nyelvben, eszközben leragad, az jobb ha nekiáll más szakmát tanulni, mert 4-5 éven belül munkanélküli lesz. IMHO jelenleg a VS a legfaszább IDE ami elérhető, de ez még nem döntő érv a C# mellett.

Nem kell igazából több kliensre, az csak ötlet? Sietsz? Akkor egyértelmű VS/C#. Feltéve ha tudod egyáltalán kezelni a Postrgre-t kényelmesen, mivel a VS ugye Ms only...

Különben nem szivatnám magam azzal, ami perzisztencia/ORM-et a .net nyújt. http://www.kevinwilliampang.com/post/How-Fanboys-See-NET-ORMs.aspx
Iszonyat sok, ineffektív, bloated kódot generál.
Könnyen lehet, hogy a Linux desktop éve sosem jön el, de a wines desktopok kora biztos, hogy még az életünkben leáldozik. Webes, javás alkalmazások pedig out-of-the box adnak átjárást(, még akkor is, ha az OS-ek következő generációját is az Ms szálltaná).

Java? Miért nem Java? Értem hogy a Swing kissé bugyutább mint a natív UI-k, de kell neked bonyolultabb? Ha nem valami cutting edge opengl/4d ui-t akarsz hekkelni, tök mindegy. Natív kinézet kell? Ott az SWT.

PHP? Hogy ne lennének ORM eszközök, teli van a web php frameworkkel (cake, zend, symfony...) Nem használni manapság frameworkoket elég nagy n000bság/script kiddység, szerintem. CakePHP-ben pl. egy konzolos utility nem csak a teljes Modellt generálja le neked adatbázisból, de a hozzá tartozó edit/view/list/add controllereket és nézeteket is.

--
The Net is indeed vast and infinite...
http://gablog.eu

Java? Miért nem Java? Értem hogy a Swing kissé bugyutább mint a natív UI-k, de kell neked bonyolultabb? Ha nem valami cutting edge opengl/4d ui-t akarsz hekkelni, tök mindegy. Natív kinézet kell? Ott az SWT.

A Swing is tud Java 6 óta natív kinézetet natív rendereléssel. És mégcsak külön cipelt lib se kell hozzá. Másrészt a Swing alapja a L&F, tehát úgy át lehet szabni, hogy nagyon. Érdemes megnézni például a Substance-t megnézni.

Az eredeti témában pedig nem értem igazán, hogy mi a baj a desktop Java-val. Hozzáértés kell csak, de az nem jár VS C# esetén se... a Swing esetén meg kell érteni a mögötte lévő tervezést és a tervezettséget és attól a pillanattól kezdve nagyon jól lehet haladni. De ehhez meg kell ugrani egy küszöböt, ami magasabb, mint más nyelvek esetén. :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Ne kezdjük már ismét, mindig az a vége, hogy nem lassú a Java, nekem meg elmegy 1-2 óra az életemből, amíg bebizonyítom, a makacs Java-tagadók meg nem hiszik el. Szóval ha kimérted akkor ide a mérési eredményeket, ha meg nem mérted ki, akkor ne írj hülyeségeket.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Személyes tapasztalat.

De lehet, hogy a java programozók nem tudnak programot írni, a C#-osok pedig igen.

Tök felesleges kimérni mindent, amikor látod egy GUI alkalmazáson, hogy ugrik-e, vagy sem. A java jellemzően nem ugrik, a C# igen. Innentől kezdve lehet benchmarkokat mutogatni, nem érdekel. Majd ha azt látom, hogy a java GUI rendes sebességgel megy, elhiszem.

A GUI tipikusan nem olyan, hogy ugyanazt a feladatot 10.000-szer végrehajtod. Mert mi a fenének klikkeljek rá 10.000-szer az Cancel-re, hogy a java rájöjjön, hogy optimalizálni kell.

Java programok:

vuze, jdictionary, java chess,...

Mono:

egy saját programommal szórakoztam egy kicsit, akkor láttam, hogy micsoda sebessége van.

Mindegy, ezen ne filozofáljunk, ha mondasz egy nap mint nap használt java programot gyors GUI-val (natív C,C++ implementáció nélkül), visszavonom a kijelentésem.

Bármelyik Swing-es program Java 6u10 fölött.

Ezen verzió alatt sem igen találkoztam olyan Java programmal, amelyik nem azonnal reagált volna. Persze ehhez úgy kell megírni, hogy az esemény kezelése külön szálban fusson (pár sor egyszer a programban), ne a GUI kezelését és rajzolását végző szálban dolgozzon (ahogy sokan teszik), mert akkor valóban lassan reagál, hiszen addig nem végez GUI visszajelzést, amíg az esemény le nem fut.

A natív C/C++ gyorsabb kapcsán is azt tudom mondani, hogy nem feltétlen gyorsabb, mint a Java. Két alkalommal már bebizonyítottam mérésekkel, akkor se hitte el mindenki, most nincs rá időm.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Akkor az elég trehány C/C++ kód lehetett.

Ha egy szépen kódolt alkalmazásra tekintünk, akkor a C/C++-nak általában 5-10% előnye van a java-hoz képest. (Most arról nem beszélek, hogy ez mennyivel több kódolással töltött óra az utóbbi környezetben.)

Egyébként nagyon sok múlik a kódolón és a fordítón. Egy rossz programozóval a C/C++ még rosszabb is, mint a java vagy a .net, hisz ott még "memory leak" is könnyen generálódik. :) Fordítóból pedig egyszer kell megnézni a kimeneti kódját a GCC-nek, az intel compilernek vagy az MS compilernek! Rögtön tudni fogod, hogy teljesítmény éhes rendszerre a GCC vicces tud lenni. Simán hoz az intel compiler 5-7%-ot a GCC-hez képest. Win alatt meg inkább lenyelem, hogy az MS nem támogat mindent a szabványban: cserében normálisabb kódot is generál, bár az intel compiler ott is partyban van, sőt.
--
http://www.naszta.hu

Ha egy szépen kódolt alkalmazásra tekintünk, akkor a C/C++-nak általában 5-10% előnye van a java-hoz képest.

Ezt annyi-de-annyi alkalommal hallottam már, aztán kiderült, az 5-10% előny sokszor a Java oldalán van. Lefuthatunk egy újabb kört, bár pár órát elvesz az ember életéből, de előtte érdekel, hogy mire alapozod az állításod: közvetlen tapasztalat vagy hallomás.
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Tapasztalat, bár a Java-s kódot nem én írtam. Azt egy olyan srác írta, aki állította magáról, hogy tud java-ban programozni. (Hihetőnek tűnt, mert jó volt C++-ban is, és ott azt mondta magáról, hogy még kell tanulnia.)

Mi végeselemes megoldókat, vagy ahhoz kapcsolódó programokat írtunk. A mi megoldónk esetén egyébként 20% különbség jött ki, de a mi esetünk elég speciális volt. Azért írtam 5-10%-ot, mert egy csomó más részén a rendszernek nem volt különbség alapvetően a sebességben. A megoldóban jellemző feladat az az volt, hogy lefoglalsz egy nagy (200MB-tól-sok GB-osig tömböt, majd a benne található mátrix-ot megoldod. Akármelyik megoldási módszert is választod, nagyon sokszor nyúlsz a ramhoz és a pointer-hez és - szerintem - e miatt lesz lassabb java alatt (és persze .net alatt is). Ráadásul a megoldóban is rendesen kell optimalizálni a kódot, amit java esetén nem csak Te magad teszel. Nálunk olyan banális apróságokon is múlt néha a megoldási idő, mint a virtuális függvények hívási overhead-je (normális programoknál gyakorlatilag nem számít). Ilyenkor újra kellett gondolni az osztály felületét a +1-5% teljesítmény érdekében.

Nem szeretnék vitatkozni Veled, mert nincs miről. Mind két rendszernek megvan a helye, alapvetően más helyen játszanak. Ahol nem kritikus szempont ez az 5-10% teljesítmény, vagy kevesebb pénz van fejlesztésre, oda sokkal jobb a java, mert nem kell vele szívni annyit (memory leak, multi platform stb.). De ismerjük el, hogy vannak olyan feladatok, ahol viszont a C/C++ játszik, sokszor beültetett gépi kóddal, 2-5x több munkaórával az adott kódon.
--
http://www.naszta.hu

Magad mondod, hogy "egy csomó más részén a rendszernek nem volt különbség alapvetően a sebességben.". En nem gondolnam azt, hogy egy olyan feladatban, ahol nem mozgatnak meg ekkora adattomegeket, illetve nem kell kimondottan matematikai szamitasokkal pocsolni, rosszabb lenne a Java, mint a C++. Tovabbmegyek: a matematikai feladatok meg csak nem is a leggyakoribb esetei annak, amire a Java-t felhasznaljak.

Tisztaba kell lenni azzal, hogy a veso, barmily eros es kemeny, egy csavarnak valo luk kifurasara alkalmatlan. Ha az ember nagyon sokat kuzd vele, a vegeredmeny meglesz ugyan, de a megoldas ettol meg nem lesz szep. Olyankor az ember inkabb vegyen elo egy furofejet, es furja ki azt a nyomoronc lukat.

Matematikai feladatokra a Java viszonylag jol alkalmas, am a gyenge pont elsosorban a hatalmas adattomegek mozgatasa es kezelese. Az ilyen szamitasi feladatok (mint azt egyebkent irod is) nagyon sok optimalizalast igenyelnek, amit az adott platform tokeletes ismerete nelkul nem lehet rendesen megtenni, sok, olykor meg azzal egyutt sem konnyu.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem nincs olyan, amiben nem értünk egyet. Talán csak egy (mivel eredetileg is erre válaszoltam, nem is Neked):

Továbbra is tartom: 5-10%-kal gyorsabb a jól optimalizált kód C/C++-ban. És itt is egyet értünk: semmi értelme vesződni vele, ha 100 helyett 111 ms-mal tölti be a GUI-t a Java. Nem kell apache helikopterrel disznót vágni!

Csak azt sem szeretem, amikor jön a Java-s szaki, azt elmagyarázza, hogy C/C++-nál is lehet gyorsabb kódot írni Java-ban, majd még mondja is, hogy mondjak példát, hogy hol/mit csináltam. Mondtam. Lehet a Java gyorsabb, de csak akkor, ha a C/C++ kód trehány. Innen indult a "vita".
--
http://www.naszta.hu

Csak azt sem szeretem, amikor jön a Java-s szaki, azt elmagyarázza, hogy C/C++-nál is lehet gyorsabb kódot írni Java-ban, majd még mondja is, hogy mondjak példát, hogy hol/mit csináltam. Mondtam. Lehet a Java gyorsabb, de csak akkor, ha a C/C++ kód trehány. Innen indult a "vita".

Továbbra se igaz, ami írsz, ugyanis rendre elfeledkezel a Java "code morphing" jellegéről, amit a JIT és a HotSpot ad hozzá. Megcsinálhatod C/C++ esetén, hogy ráoptimalizálod a kimenetet egyfajta viselkedésre, és így azon esetekben adja a plusz 5-10% többlet teljesítményt, de csak azon az egypár esetben, amelyre felkészíted: amint olyan bemenetet kap, amely esetben inkább egy másik ciklusmagot kell kifejteni utasítások sorozatára, vagy más módon kell a CPU-ra optimalizálni, akkor már sokkal lassabb lehet. És ez az, ami miatt a Java sok esetben gyorsabb: mert képes a JIT és a HotSpot miatt az igények függvényében más-más részeit optimalizálni, és erre jelenleg nincs jó C/C++ alternatíva. Ha lenne C/C++ alá is JIT és HostSpot, akkor minden esetben gyorsabb lenne, mint a Java.
--
http://wiki.javaforum.hu/display/FREEBSD

C/C++-ban ilyenkor - a nem sufni cégek - szépen lekódolják az összes lehetséges ciklusmagot.

Félre ne érts! Nem azt állítom, hogy ez mindig gazdaságos: ilyenkor jön képbe a Java. Nem vagyok C/C++ fan boy. Ez is csak egy eszköz, de sebesség optimalizációra ma - talán - a legjobb eszköz. Nem vitatom el a Java érdemeit sem. Nem ebben a témában írtam is, hogy nagyon ideje lenne megtanulnom programozni benne. Bizony 1000 és 1 olyan hely és program van, ahol annyi kódot kéne így optimalizálni C/C++-ban, hogy nem érné meg leprogramozni az eszközt. És igen, ilyenkor egy trágya C/C++ kódnál sokkal jobb a Java vagy C#.

Szerintem már sokat közeledtünk. :)
--
http://www.naszta.hu

Akkor én is kifejteném szigorúan tudományos érvelésemet.
Azt minden óvodás tudja, hogy az Assemblynél gyorsabb nincs. Ezt követi a C, hiszen valahol (figyelem pontos forráshivatkozás!) azt olvastam, hogy a C nem más mint hordozható Assembly. Ezek után természetes, hogy a C++ csak gyorsabb lehet a C-nél, hiszen annyival jobb, hogy csak két darab "+" azaz a "++" tudja kifejezni felsőbbrendűségét. Ehhez képest a Java a fasorban sincs, mit is várnánk egy olyan nyelvtől amit a kávéról neveztek el!
Alapos szakismereteimet alátámasztandó elmondanám, hogy egyszer fontolóra vettem Stroustrup-féle C++ könyv megvásárlását. Azt pedig bárki belátja, hogy elég fajsúlyos könyv, nem holmi 24 órás gyorstalpaló!
Konklúzió: A Dzsava a fasorba sincs, míg a C és főleg a C++ eszméletlenül cool (and the ganag!)

Vicc vót ám! Pontosabban irónia. Nehogy holnap valaki erre hivatkozzon!
Mert szerintem történnek ilyenek.
--
Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba és kész!

A kérdés mindig az, hogy amennyivel több egy c++-os projektben a fejlesztési idő (beleértve a kézzel optimalizálást) annyiból nem lehetne még egy-két-három-tíz gépet venni? Mert egy havi fejlesztői bérből (mondjuk 500 bruttó) vesz a cég 4 darab elég erős számítógépet.

Tetszik a java, mert mindenutt fut, mert mindenutt lehet fejleszteni ra, etc. DE. Mocsok lassu. GUI alkalmazasok amik java-ban irodtak eddig csak piszok lassut lattam. Lehet _minden_ programot amit javaban irtak (es amit hasznalok) azt amatorok/benak irtak, de akkor is igy van sajnos. Ennek elleneben a C/C++(Qt/gtk pl) vagy C#-ban irodottak meg azonnal reszponzivak es azok is maradnak..

Lehet a szamokban java nyer, de.. sajnos a valosagban ez nem jon ossze. (Mint mar irtak is..)

Na varjal, te itt mar masrol beszelsz. A "felhasznaloi elmeny" nem elsosorban a sebessegrol szol, a nativ felulet hianyarol pedig nem a Java tehet, hanem a programozo, aki rosszul valasztott widgetkeszletet.

Nekem egyebkent peldaul a regi mobilomon poccre mennek a Java-s alkalmazasok, es egesz jo a felhasznaloi elmenyuk. Valamint a PC-men teljesen jo sebessegggel fut a NetBeans es az Eclipse is, mindketto nagyreszt Java-ban irodott stuff, a felhasznaloi elmenye kielegito, hogy mennyire nativ a felulete... nos, peldaul Mac alatt a NetBeans pofara teljesen olyan, mintha az XCode indult volna el - vagyis total nativ alkalmazas. Meg Windowson se sokkal kulonbozik egy atlag Windowsos programtol. Hogy a Gtk kinezet pocsekra sikeredett... nos... az nem a NetBeans hibaja. Mellesleg a Nimbus kinezet egy picivel jobb, en arra szoktam attekerni.

En elhiszem, hogy nalad/szamodra lassuak a Java alkalmazasok, csak annyifele Java alkalmazas van, hogy nem tudom, melyikrol beszelsz, melyik lassu nalad. Es foleg az a kerdes: miben all a lassusag oka. Nalunk peldaul a bankos applet nem azert lassu, mert szar a Java, hanem mert egyszeruen nagyon sokat var a szervertol a valaszra. Vagyis szar a teszt szerverunk.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az SWT-vel nincs baj. Az API undorító, de legalább gyorsan megy. A java-s alkalmazások jellemzően nem SWT-re készülnek, ezért alakul ki a lassú java feeling.

- a C# sokkal flexibilisebb: operator overloading, signed / unsigned típusok, property-k
- a C# naming conventionje undorító, a Java-nak szebb (függvénynevek nagybetűvel, hátborzongató)
- az Event kezelés mindkét nyelven gagyi
- a java exception kezelése nagyságrendekkel jobb, mint a C#-é. Az embernek C# alatt financiája nincs, hogy milyen Exception-ök jöhetnek
- a java keresztplatformos, meg a mono is, a többi MS-es extra az bullshit
- a java dokumentációja jobb, mint a C#-é

Összességében a C# mono-s változatát jobban szeretem, de a Qt-hez képest az sem rúg labdába. A Qiyoto-t (Qt#) még nem próbátam.

Az SWT-vel nincs baj. Az API undorító, de legalább gyorsan megy. A java-s alkalmazások jellemzően nem SWT-re készülnek, ezért alakul ki a lassú java feeling.

Eléggé placebó gyanús a dolog, mivel a Swing a Java 6 óta pont annyira natív, mint az SWT.
--
http://wiki.javaforum.hu/display/FREEBSD

Nem. Csak azért gondolom, mert gyors java GUI-s programot idáig nem láttam. Amit láttam, az nem volt gyors.

(Láttam gyors grafikus javas alkalmazást, de tegyük hozzá, hogy az SVG implementáció alatta C++-ban volt megírva, azt hiszem nem véletlenül nem java-t használtak SVG motornak).

Ha nem ertesz hozza, akkor miert beszelsz rola?

Teny, hogy a .net sokkal jobb GUI-ra, mint a Java. Errol persze legkevesbe sem a virtualis gep vagy a nyelv gyengesege tehet, egyszeruen a konkret UI framework jobb a .Netben. Pl. a GC joval erosebb a Java-ban.

----------------------
while (!sleep) sheep++;

Nézd, amikor az ember nyelvet választ, nem érdekli az, hogy mik a java elméleti lehetőségei. Az, hogy jelenleg hogyan működik, az érdekel.

Amennyiben a java előhoz egy gyors GUI-t (akár olyan áron is, hogy natívban C-ben megcsinál mindent hordozhatóra), vissza fogom vonni a kijelentésemet.

A java is ugrana úgy, mint az állat, ha C-ben lenne a GUI zöme megírva.
A GTK# egy vékony wrapper a C-s GTK körül. Ennél fogva nem csoda, hogy teljesen más feeling-je van a GTK#-nak, mint a javas GUI-s alkalmazásoknak.

A mono-s GUI implementáció egyébként tele van unsafe pointerezgetéssel is, hogy gyorsabb legyen. Elég randa is miatta.

[Java és .Net]"Both use their own intermediate byte-code, Microsoft calling theirs Common Intermediate Language (CIL; formerly MSIL) and Sun calling theirs Java bytecode. On .NET the byte-code is always compiled before execution, either Just In Time (JIT) or in advance of execution using the Native Image Generator utility (NGEN). With Java the byte-code is either interpreted, compiled in advance, or compiled JIT."

http://en.wikipedia.org/wiki/.NET_Framework

Anno a német T-Com-nak írtam Java programokat, szerintem nem volt lassú. Legalábbis elég sok (80M ügyfél számlázási adatai...) rekordot felrolgozott pár óra alatt minden nap. (Igen, tudom adatfeldolgozásra ott a Cobol, de mi Javaztunk. Mono vagy ASM ott fel sem merült volna.)

Persze tudni kell a Javat hasznalni...

( hory v | 2010. 02. 13., szo – 07:33 )

A swing csak az egyik gui framework java-hoz, van meg kismillio egyeb. Nezd meg az SWT-t is, meg fogsz lepodni.

Amugy meg java-ban is lehet webes guit csinalni. Sot, manapsag, uzleti szoftverre NEM webes gui-t csinalni marhasag.

( rowcol | 2010. 02. 13., szo – 09:37 )

Java első körben, de mivel már régóta halálhírét keltik, és emiatt aggódsz, akkor .NET (C#, ahogy írod, vagy bármi ami kézreáll).
Linux-os monodevelop nem is olyan nagyon kínos, mint fentebb elhangzott. Mondjuk ez kényelem kérdése, PHP-t pl. én még mindig vi-al fejlesztek. Ha GTK# a GUI, akkor nem látok sok problémát a platformfüggetlenséggel (majd megmondják, hogy mire nem gondoltam :) ). Ha "kínszenvedsz" a mondodevelop-pal, akkor Win alatt kell fejleszteni, és csont nélkül fut Linux/mono alatt. Ugyanez igaz fordítva is.

Szerintem. :)

( zolti v | 2010. 02. 13., szo – 09:49 )

Szerintem adj egy napot a Qt-nek tesztelgesd. Én is VB vel kezdtem majd utána Delphi és így 5 év szünet után a Qt nagyon szimpatikus. Számomra az egyetlen IDE Linux alatt ami mindent tud amire szükségem van, és nem Java alapú.

+1

Pár éve gondoltam egyet, és át akartam állni egy komolyabb IDE-re a vim/gvim/gedit párosról ( kód-kiegészítés, auto-indent, build, run, és társai miatt ).
Megnéztem ezer és egy IDE-t ( anjuta, kdevelop, codeblocks, wxwidgets-ék IDE-jét, eclipse, netbeans, és még 100 másikat. ) Aztán ránéztem a QtCreator-ra, na ha valaki mutat ennél jobb Crossplatform IDE-t C++-hoz, ...

Részemről Visual Studio 2005 SP1 + Notepad++.

CMake, Qt, VTK és ParaView-hoz is tökéletes. :)

Linux meg megy virtuális gépen aztán néha behúzom a kódot SVN-ről vagy csak szimplán megosztom, aztán megy a teszt ott is. Kódolni szinte soha nem szoktam alatta. :) Most melóhelyen KDevelop3-mal tolom, mert Dual G5 Mac van alattam (Debian-nal), de remélem hamar felejtős lesz... :) Azt, hogy az XCode mekkora szutyok, meg ki sem fejtem... :)
--
http://www.naszta.hu

( suti | 2010. 02. 13., szo – 09:53 )

ha webalkalmazás szerűt fejlesztenél, akkor ott a GWT.
igaz, a databinding nincs, de vagy a 2.1, vagy a 2.2 -esbe fog belekerülni, jelenleg a 2.0.1-nél járnak.
_______
14.77 %

GWT-t ne.

A GWT egyesiti a java es a javascript technologiak hatranyait, megspekelve IDE alultamogatottsaggal. Kb. olyan erzes maga az API, mint amikor az ezredfordulon GTK-t programoztam, ami akkortajt nem volt rossz, de azert manapsag idejetmult. Ezen felul marha nehez kiszolni a js interpreternek (tudom, $wnd, hosszu, mitol nem megy), de a srac problemait ott bukja, hogy nincs rendes formtervezo hozza.

(Van fizetos GWT designer, csak akkor miert elony a listaban a VS express?:)

Abban egyetertek, hogy vallalati CRUD appot webes feluletre tervezunk, oke. Jo, ha AJAX-os, mert akkor van valami sebessege, oke. Kell hozza rendes IDE vagy valami tamogatas, mert eletbe nem vegzunk, oke (itt szevasz GWT).

Itt meg mindig lehet Visual Studio egy ASP.NET-tel, vegulis amit az general, nem sokkal nagyobb hulyeseg, mint amit a GWT csinal, sot, egy picit talan meg stabilabb is (a kozhiedelemmel ellentetben asp.net 3.5-ot agyonteszteltek firefoxban es safariban (=webkit = chrome)

Itt hatrany a wines szerver. De ha ezt akarja tanulni, csak megerosites kell, akkor hajra :)

Ha az illeto beszel javaul, nekiallhat a mindenfele top-notch agyontamogatott frameworkokkel dolgozni, az az igazsag, en JSF-hez lattam utoljara grafikus tervezot NetBeansben, az vegulis nyelvi szinten viszi a databindingot, de hogy mennyire jo a visual studio-ehoz kepest... azt nem tudom.

A GWT usereket altalaban el szoktam kuldeni egy rovid kis javascript tanfolyamra, hogy megismerkedjenek a nyelvvel, amit lazasan kerulnek, es megismerjek a bugos DOM libek kerulgetesenek modjat, maga a nyelv ugyanis qrva jol van implementalva mindenhol, bar sebesseg azert jobb az ujakban. A DOMnak vannak tipushibai, de ezek meg ismertek, a megoldasaikkal, az elrejto retegekkel egyutt.

JS-bol pedig lehet databindingos appot irni ext-tel, van hozza gui builder, a komplettebb IDE keszulget, de ott van meg 2-3 framework, amiben van ilyesmi.

De mindegy is. Ha visual studiozni akar, visual studiozzon, eclipse-be fel ora alatt rajon, hogy valami nem ugy megy, mint szeretne :)

Szerintem a GWT-nek is megvannak az előnyei:
- Nem értem miért mondod a rossz IDE támogatást, kevés olyan környezet van, ahol a böngészőben futó kódot ugyanonnan tudod debuggolni, ahonnan a szerveren futót. (Eclipse) Ráadásul az összes fontos böngészőre működik.
- Nekünk JSNI-vel nem volt sok bajunk, ha valamit tényleg könnyebb megcsinálni Javascriptben, akkor arra csináltunk egy kicsi libet, és azt hívtuk JSNI-vel.
- Nagy előny, hogy ugyanazokat a toolokat tudod használni kliens és szerver oldalon (Unit teszt, Eclipse refactoring, Checkstyle ... stb.)
- Ha Java fejlesztőid vannak, akkor jobb GWT kódot fognak írni (illetve hamarabb lesznek produktívak), mint Javascript kódot. Nyilván minden Java forrásnyelvű platformnak megvannak a saját buktatói (J2ME, Android, GWT ... stb.), de ezeket sok esetben gyorsabban ki lehet ismerni, mintha egy teljesen új platformot, új nyelvet kezdenél megismerni.

Javascriptnek is vannak kétségtelen előnyei, nagyon szép dolgokat lehet benne csinálni (gyenge típusosság, objektumalapúság...stb. miatt). Ezért nem is lehet általánosságban kijelenteni, hogy az egyik jobb mint a másik, mi is használjuk mindkettőt.

Ha már az Ext szóba került, ott van pl. az Ext GWT is. Mostmár annyira nincs elmaradva a "rendes" Ext mögött, és a GWT előnyeit is ki lehet vele használni.

Illetve írod, hogy Exthez van jó GUI builder. Van esetleg linked hozzá? Mert az Ext honlapon csak egy preview van az Ext Designerből, ami még menteni se tud. A többi, amit találtam meg eléggé kritikán aluli minőségű volt.

Üdv,
Gergely

( xbit | 2010. 02. 13., szo – 09:53 )

aruljatok mar el miert nem jo a linux "cliens" oldalon azaz gondolom ezzel azt akarta mondani a szerzo hogy desktop felhasznalasra? Mellesleg megjegyzem, hogy nem vagyok desktop linux felhasznalo, de amikor az voltam 5 eve, akkor sem volt semmi gondom vele.

Mostanra a kde es tarsai ahhoz kepest is fejlodtek, csili vilibb lett az egesz, tehat ezzel nem lehet nagy gond.

A funkcionalitasokat tekintve pl a frissitesek automatikusak, GUIban is vezerelhetoek, nem ugy mint annak idejen amikor apt-get et scriptelgettuk...

Masik erv amit meg fel szoktak hozni, az a "nagy, kereskedelmi" szoftverek mint pl photoshop hianya, ami eleve egy szuk kozensegnek szol szol, nevezetesen designereknek. Aki pedig neves designer es nem boldogul a gimpel valszeg meg kevesebben vannak, de javitsatok ki.

Meg egy ellenervre tudok gondolni: szaggat a jatek windows emilator alatt(marha az ember gamer is, de ez esetben inkabb celhardvere van...)

Az utobbi idoben az emberek a weben toltik desktop tevekenysegeik sacc 98%at.
akkor miert is nem jo a linux desktopra?

zsolt

Egyetértek.

Viszont valamiért egy designer ragaszkodik a Photoshophoz. Például azért, mert pixelgrafikán kívül nyomtatott újságokat is csinál, ezért megvette az összes Adobe terméket jellemzően OSX-re :) Linuxon csak szerencsétlenkedne az Inkscape-el és GIMP-el.

A linux átlagos desktop felhasználásra tökéletes és még többre is, sőt van amire egyáltalán nem alkalmas pl a windows. Mondjuk komoly munkára.

--
http://sandor.czettner.hu

Tök egyet értek.

Szerver oldalon abszolút nyerő lehet a linux, de workstation oldalon semmi értelme. Mi iparági szabvány programokat használunk (Adobe, Quark, Avid, Canopus, Playbox) ezek szóba se jönnek linux alatt. Az irodai szekciót lehetne linux alá költöztetni (dokumentumok, böngészés) de minek tartsunk fent két platformot??? Jobban bonyolítaná a napi életet.

Az a bajom, hogy a desktopok (saccoljunk) 99.9%-án windows van és akárhányszor a linux desktop éve kerül szóba, mindig az az ellenérv, hogy a linuxon nem fut a fotóbolt. Ebből azt a téves következtetést kellene levonni, hogy minden desktopon kell a fotóbolt, mert különben agyhalál van.

Az teljesen rendben van, hogy speciális helyeken, mint pl. egy újság szerkesztősége vagy a nyomda, speciális cuccokat használnak és a cucchoz veszik az oprendszert. De ne legyen már egy újságnak pontosan ugyanannyi olvasója, mint szerkesztője... Meg ne mondjuk már, hogy azért, mert az újságban objektíven indokolható módon kell a windows, akkor ez az érv igaz a maradék 99.3%-ra is.

számodra.
egyébként pedig azt jelenti, hogy aki linuxból akar megélni, az nem Mari néni nyavalyáit akarja megoldani, hanem azokét a cégekét, akik képesek és hajlandók fizetni érte.

A desktop linux éve? kit érdekel, adnak érte valamit a közértben? Ahol meg rendes informatika van, ott pedig a piac nagyobb részének megvan minden, amire szüksége lehet.

Ez elmondható bármelyik OS-ről.

Mellesleg Mari néni nyavalyáit elsődlegesen a HW gyártók lelkesítő szlogenje "PC-ét minden likba, párdon otthonba" és a félművelt otthoni anykey fanszőrbojok akarják nagyobb részt megoldani úgy, hogy Mari néninek ezeknek a csodálatos vasak, emberek megjelenése előtt nem is volt semmi nyavalyája.

Mivel Linux több nyavalyát hordoz magában Mari nénik, de a cégek részére is, ezért különösen kedvelik a HW gyártók "mézes kalács" szerepében.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Mondjuk arra nem gondolsz, hogy a fotóbolt az azért is jó, mert nem kell lasszóval fogni rá a jómunkásembert, jól elterjedt biztos formátum könnyű rá munkást alkalmazni. Egy cég nem engedheti meg magának, hogy olyan platformon dolgozzon/dolgoztasson amire nincs megfelelően képzett munkaerő.

Nem a profilról van szó, hanem arról, hogy egy nagyobb megrendelés esetén plusz munkaerőt kell foglalkoztatni, betegség esetén plusz munkaerőt kell foglalkoztatni, szabadságolás esetén plusz munkaerőt kell foglalkoztatni..... És akkor nem árt, ha gyorsan kerítessz jómunkást.

Akkor kezdjük elölről, mert úgy látom, sokan nem értik. A következő állítások szoktak elhangzani (vállalati környezetet feltételezve):
1. a desktop gépek legalább 99.9%-án windows fut.
2. a fotóbolt nem fut linuxon, nincs linuxra másik helyettesítő alkalmazás.
3. emiatt nem lehet áttérni desktopon linuxra.

Ebből azt a téves következtetést lehet levonni, hogy minden gépen lennie kell fotóboltnak, mert minden gépen aktívan használják. Ordas nagy baromság.

A helyes következtetések tehát:
1. a gépek azon kis százalékán, amin valóban érdemi munka folyik fotóbolttal, nem lehet áttérni linuxra
2. ugyanez igaz lehet más, specifikus alkalmazásokra is
3. de mivel a gépek tömegét office-re meg ilyenekre használják, ezért a gépek zöme minden további nélkül átállítható linuxra.

És ha a gépek 10%-ára kell üzemszerűen fotóbolt, meg másik 10%-án van valami specifikus cucc, akkor is a jelenlegi 99.9% windows penetrációban majdnem 80% esélyes a linuxos desktopra.

Ez a fotóbolt téma egy univerzális kötözködési lehetőség a windows fanoknak. Mert valós szakmai alapja *NINCS*.

Szerk: ami indoklást írtál a hsz-edben, az a fotóboltot üzemszerűen használó cégekre igaz. A többi majdnem 90%-ra meg nem.

Meggyőzöd bankokat, állami hivatalokat, KSH-át, APEHet, anyámtíkját, hogy használható Linuxos klienseket adjanak a kis, közép vállalkozásoknak, és ne zárkózzanak el azonnal bármi probléma esetén (önök, nem a javallót környezetet használnak).
Adsz kész ERP-t, kész és nem félkész tesztelésre váró élőben betaalfaprerelizmajdkiheggeszted könyvelői, raktár programokat, valamint nem drágábban, mint ami van win alá és nyert ügyed van.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

Jellemzően nem a vállalat minden dolgozója könyvel egyszerre, hanem a könyvelés. Jellemzően a járulékok bevallása, a banki műveletek elvégzése is feljogosított emberhez köthető, tehát nem igaz, hogy minden gépre kell könyvelőprogram.

ERP és egyéb nagyvállalati cucc kérdésben ott az sap meg az oracle cuccai, azok futnak linuxon és elég bátornak kell lenni ahhoz, hogy valaki prealfa állapotúnak mondja őket.

És ezekhez jön a gépek zöme, mondhatni, elsöprő többsége, ahol emailben érkező problémákat pár webes felületen megoldanak pár kattintással és írnak rá valami választ. Használnak levelezést, böngészőt meg wordot. Na ide tipikusan rohadtul nem kell windows.

Egyébként is nagyvállalatnál nagyon divat a terminálszerver-kliens verzió, mert nem szeretnek sok pc-re szoftvert felrakni, arra a néhány, helyettesíthetetlen programra ezután is lehet terminálszervert használni.

Eleg konnyu azzal ervelni, hogy a vallalat nem minden gepen fut ez meg az, csakhogy van par apro picike gond. Ha az ember tisztan Linuxos rendszert tervez, megszabadul egy csomo gondtol, nyugtol, hekkelestol, nem beszelve arrol, hogy a homogen kliensgep-halozatnak is megvan a maga elonye. Peldaul lehet normalis SSO-t bevezetni, nem kell kinlodni a Samba/Windows Server kerdeskorrel, satobbi.

Arrol nem is beszelve, hogy valoban nem minden gepre kell ez meg az, de ha az ember vegigszamolja, oda jut, hogy gyakorlatilag a halozatnak csak egy kis szegmenset tudja atallitani Linuxra, mert a tobbi gepen olyan rendszer fut, amit nem lehet. Nem azert, mert mindegyiken ugyanaz fut, hanem mindegyiken masfele rendszer fut, amit nem lehet atallitani.

ERP-vel kapcsolatban kerdeznem: vajon a kliensek is leteznek Linuxra, vagy csak a szerverek? Mert nem mindegy am...

Terminal szerver: ez egy jo erv, ha az adott programok fel vannak keszitve a terminalszerveren torteno futtatasra, azonban ez sajnos nem mindig van igy. Jellemzoen a penzugyi programokkal van a legtobb gond, reszint mert zomukben meg a DOS/Win98 erabol jonnek, reszint pedig ebbol fakadoan a kutya nem fejleszti mar oket. Persze itt is konnyu azt mondani, hogy "hat akkor at kell allni olyan szoftverre, ami megy, fejlesztik, etc." csakhogy egy vallalat tizensok evre visszameno konyveleset nem fogsz talalni embert, aki atvinne neked szerelembol. Es most nem csak arrol van szo, hogy a kotelezo penzugyi ot evet vigyuk at, ha valamiert kell egy meg ennel is regebbi szamla, mindenki meg van love, mert eselye sincs elohivni az adott kornyezetben az illeto programot, es termeszetesen ezert a rendszergazda lesz a felelos (es teljesen mindegy, milyen papirt kivel irattal ala).

Szoval, osszessegeben: baromi konnyu azzal ervelni, hogy a halozat nem minden szamitogepe egyforma, azonban jelenleg Linuxra mindenfele programbol hiany van, igy nagyjabol minden masodik-harmadik gepen olyan programmal/rendszerrel fogsz szembesulni, amit nem lehet atallitani - a legkulonfelebb okok miatt. Es a vezetoseg meg nem fogja alairni azt, hogy akkor most azt az ot gepet, amit a titkarnok birtokolnak, te at kivanod allitani Linuxra, a tobbi otven pedig marad, mert akkor az az ot is maradhat.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Úgy látom, én is elkanyarodtam az eredeti mondanivalómtól, hát kanyarodjunk vissza.
Használj azt, amit akarsz, indokold vagy ne indokold kedved szerint, de ha már indoklod, az az indoklás legyen valós. Mert az az állítás, hogy azért nem lehet áttérni desktopon linuxra, mert nincs hozzá fotóbolt, az marhaság.

Konkrétan csak a PS-t figyelembe véve mari néni gépén, igazad van.

Amúgy tetszett, ahogyan a kis, közép vállalkozásoknak Mon Oraclet, SAPot ajánlottad.

Lényegében Linuxnak nincs mit adnia alapvető dolgokon kívül a kis, közép vállalkozásoknak. A zenész, építész tanuljon meg programozni vállalkozásán belül vagy képezze át magát integrátornak. Értem...

Persze Red Hat, Novel adhat pénzes megoldást, de nem vagyok meggyőződve róla, ahogyan a piac sem (észrevenne ugyanis mindenki a tömeges váltást), hogy olcsobb mint MS termékvonalát pénzelni.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

nem ajánlottam, elhangzott kérdésként, hogy van-e rá szoftver. van.
olyan, amilyen...
egyébként sap-nak van kkv szoftvercsomagja, az árát nem tudom, nem is érdekel.

A zenész, építész ne tanuljon meg programozni (bár tőlem megtanulhat, ezen a fórumon is van, aki hidat épít meg programoz), hanem használja azt, ami neki megfelel. Csak azt kellene belátni végre, hogy nem a zenész meg az építész a nagy tömeg a felhasználókban.

Annál, hogy beszorultál egy gyártóhoz, minden olcsóbb... A piac azért nem látja a változást, mert mindenkinek régi, poros elképzelései vannak a linuxról. De ez változni fog, ha jól emlékszem, kötelezővé tették a nyílt formátumot az államigazgatásban.

( mljava | 2010. 02. 13., szo – 12:03 )

Úgy látom, hogy jobb lenne valami web-es dolog felé kanyarodni.
Vagy Qt ;) (Adok neki pár napot megnézem)

PHP-hoz mondjon valaki egy használható fejlesztő eszközt ami kezel legalább egy framework-öt és a jquery-t.

En konkretan mondom, hogy a penzugyi szfera szivas ilyen szempontbol. Van egy csomo DOS alapu cucc, ami termeszetesen csak nyuglodik DOS emulator alatt. Van egy csomo MS Access alapu stuff, amivel megint ilyen meg olyan bajok vannak. Van egy csomo uzleti banki terminal program, ami eselytelen linuxon futni, es a terminal szerveres futtatas is eleg necces. A kulonbozo konyvelo programokkal is csak a nyug van.

Benne voltam egy ilyen projekt elokeszuleteibe, es azt kell mondjam, eleg sokat kinlodtunk. Sokkal lassabban novekedett a "Mukodik" oldal listaja mint a "Nem mukodik" oldale. Raadasul volt egy csomo (4-5) CAD-ves gep is, amivel aztan eselytelenek voltunk barmit is csinalni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Off, de a linux desktop evehey szerintem a linux keszitok fejeben kene rendet rakni...

De mar jonnek ki a linux-alapu cuccok, en is azert vagyok OS X-en, mert ha terminalt akarok nyitni, megnyitom, viszont alap dolgokat kezel terminal nelkul, es nem kell felevente ujratelepitenem a rendszert ha a legujabb szoftvereket akarom hasznalni (sot, akar le is tolthetem oket az internetrol, repository varazs nelkul! Mily sarlatansag...)

Apro fix: az OSX BSD es nem Linux alapu (hal' istennek). Egyebkent maximalisan igazad van. Ha nem lenne oly erdemtelenul draga a Mac vas, biztos, hogy kidobnam a jelenlegi gepeimet, es Macet vennek.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( mljava | 2010. 02. 13., szo – 12:06 )

Egyébként nem titok, ha a saját felhasználásra készült app-om jól fut akkor akár a munkaterületemen belül el is adhatom.

Sietek? Lehet. Januártól élesben szeretném használni. ;)

( Nickname | 2010. 02. 13., szo – 12:59 )

ZKlib - szép, java, browserben, MVC-vel, integrálhatósággal, ha akarod webservice hátul, ha akarod php-val segíted meg, stb, stb. Magasan veri a GWT-t. Mobilon is megy (Android, IPhone, etc) Ha kell van hozzá support pénzért.
www.zkoss.org

( asch v | 2010. 02. 13., szo – 14:39 )

Szerintem tanuld meg mindet, szerezz megrendelést és akkor döntsd el hogy mi a legjobb a megvalósításra (ha olyan szerencsés vagy, hogy nem mondja meg a megrendelő).

A hozzáállásodon pedig változtass, mert a "nincs sok időm rá, de nagyon jó dolgot akarok csinálni és sok pénzért eladni" nem megy. Csak akkor talán ha már profi vagy és a kisujjadban van minden. De az csak akkor leszel, ha nem sajnálod az idődet és az energiádat tanulásra. Ördögi kör.

( lzskiss | 2010. 02. 13., szo – 19:22 )

Python.
Frameworknek meg Web2Py.

OpenBSD 4.6/i386 theo for the prezident:D

( Little Dragon | 2010. 02. 14., v – 03:16 )

Ha kedveled a C#-ot, akkor az adatkezelesi es uzleti logika reteg lehet .NET, fog menni monoval is. Szerintem (bar... lasd lent).

A kliens, pedig lehet .Net Windows-on, Linux-on meg mono + gtk-sharp.
(http://www.mono-project.com/Image:Md2.png)

PostgreSQL-hez van .net-es driver. (http://npgsql.projects.postgresql.org)

Biztosan lesznek kompatibilitasi problemak .net es mono kozott.
Mikor legutobb probaltam (kb. 1 eve), akkor eppen a mono nem tudta beolvasni (DataTable.ReadXML) azt az XML-t ,amit Windows-on mentettem el (DataTable.WriteXml). Visszafele mukodik.
A mono fejlesztok azt allitottak, hogy az MS nem jol implementalta a datetime tipusu adatmezo xml-be valo irasat, igy ez nem hiba az O oldalukrol (vagy valami hasonlo). Ettol persze meg az en programom nem mukodik.

ASP.NET-et Apache alatt, meg nem ismerem.

Ha dontottel, ird meg, mert erdekel, hogy mit valasztottal es miert.

Sok sikert!

Eleve mono-ra kell fejleszteni, ha C#-ot akarsz Linuxra és Windowsra.

Ennek 3 hátulütője van (GUI):
- ha GTK#-ot használsz, az elég messze van a Windows natívtól
- ha Windows.Forms-ot, az egy kalap szar
- a WPF meg nem működik C# alatt

Ami mégrosszabb hír, hogy wine alatt a DotNet 3.5 Framework sem megy.
(talán jó hír, hogy a 3.0-t nemrég sikerült elindítani). Nem könnyű keresztplatformos alkalmazást írni C#-pal.

Én javaslom:
- a GUI-t el kell választani az alkalmazás logikájától egy interfésszel
- Windows alatt WPF-fel megy + DotNet Framework 3.5
- Linux alatt GTK# + Mono

Tetszik a C# és az npgsql-t használom ;)
Viszonylag gyorsan elkészíthető vele minden mejelenítés és csak a háttérmunkára kell koncentrálni.

Nagyon tetszik a PHP is, de még mindig nem találtam hozzá értelmes IDE-t.
Pl: PHP+Symfhony+jquery. De itt nagyon lassú a fejelesztés.

A háttérmunka lekódolása kb. ua. idő mindkettőben. PHP-ban lassabb a megjelenés kivitelezése, hibakezelés és a végeredmény is kevésbé rugalmas.

Ott tartok, hogy C# lesz belőle, PHP marad egyszerű webes megjelenítéshez.
Aztán a C# végeredmény vagy megy Mono-val vagy nem.

:(

Eclipse-ben van PHP IDE (PDT), jó debugger támogatással (Zend és XDebug is). Tud pl. automatikus XDebug session indítást, tehát nem kell Launch konfigurációkkal szenvedni, hanem csak beállítod a breakpointokat, behívod az oldalt (vagy elindítod a szkriptet) és már megy is.

Mivel a PHP egyáltalán szóba jött, ezért felteszem, hogy web UI-ról beszélünk, és nem PHP-GTK meg hasonló egzotikus megoldásokról.

Szerintem asztali alkalmazáshoz hasonló Web UI-t leggyorsabban ExtJS-el vagy GWT esetén Ext GWT-vel tudsz előállítani.

A szerver oldal mindkét esetben teljesen független a kliens oldaltól, tehát használhatsz C#-ot, Java-t, PHP-t ... stb.

Mit értesz azon, hogy a hibakezelés kevésbé rugalmas PHP-ban? PHP5-nek már szerintem korrekt a kivételkezelése. (Igen, nincs benne finally. Kellemetlen, de sokáig Pythonban is hasonló volt a helyzet.)

Szerk: A C# választása is teljesen jó lehet. Ha a projekt során teszteltek valamilyen szinten Mono-val is, hogy legalább a backend szépen fusson (a backend nyilván teljesen külön fordítható tesztelhető komponens lesz...:) ), akkor amennyiben szükséges, viszonylag egyszerűen elé tudtok tenni egy Linuxon is működő GUI-t.

Üdv,
Gergely

En azt hiszem ertem a sracot, de mljava, javits ki, ha tevedek.

Azt varja az IDE-tol, hogy legyen benne egy GUI builder, amivel dataport-szeruen rahuzhatja az elemeket, meghozza vizualisan. Ha pedig valamivel baj van,a validacios hibakat is vizualisan szerkeszthesse.

Bar nem egy nagy wasistdas egy ilyet osszedobni akar symfony fole, nyilvan egyedul dolgozva, nem pedig holmi team fejekent (ahol kulonosebb idegbaj nelkul tervezunk-keszitunk ilyeneket) nem erre szeretne koncentralni, hanem a fejlesztesre.

Marpedig vizualis GUI builder van jo a visual studioban, es vonzza a C#, ami valoban nem egy rossz nyelv.

Ez egy atlag javasnak ( :P ) nem tunik fel, mivel a rendszerrel eleve van annyi szopas, hogy a legkisebb baja az legyen, nincs grafikus UI builder. Ennek ellenere egyebkent vannak ilyenek.

Ha raeros kedvembe lennek, lehet rittyentenek egy webes GUI-buildert symfonyhoz, ami szepen tamogat data bindingot, de nyilvan ennyire en se erek ra a mas melojaval foglalkozni, akkor se, ha annyira nem veszes.

Az XDebug, meg ilyesmik, ezek nyilvan jo dolgok, a legtobb PHP fejleszto nem tud ezek letezeserol (es bizonyos kornyezetekben sajnos nem is hasznalhatoak).

Szoval o igazabol vizualis fejlesztest szeretne az IDE-tol, szamara ezt jelenti az IDE. Hiaba ugyanannyi lekodolni egy onclick-et kezzel, megis mas eleterzes.

Na, ez az, amit a VS szepen tamogat, elvileg vannak JSF cuccok, php-hoz ritkan vannak ilyenek (delphi tud elvileg ilyet: http://www.infoworld.com/d/developer-world/codegear-extends-delphi-php-… ), JS frameworkok egy reszeben van hasonlo (Atlas, Ext designer, Morfik....), de ezeket meg kevesbe ismeri, a backendet meg akkor is meg kell irni egy masik rendszerben.

Magyarorszagon C# programot fejleszteni teljesen rendben van. Az MS kilora megvette az allami szektort anno, amit lehet negativan felfogni, viszont vannak windows szerverek. Kulfoldon mar nem eri meg ilyet csinalni, meg kulfoldi meloszerzeshez is kevesbe jo gyakorlat, de itthon teljesen oke.

Azt sose ertettem, hogy az eclipse PHP mitol jobb, igaz, en javahoz IDEA-t, php-hoz meg makrozott / pluginezett vimet hasznalok.

Symfony-project.org a barátod, nagyon jó kis cucc. Én Eclipse-sel fejlesztek PHP-t,
xdebug támogatással, teljesen jól működik.

PHP framework-öt azért kell használni, mert ha ilyen kérdéseid vannak, amilyen, inkább
használj framework-ot, minthogy ugyanazt megírd, rosszabbul, azt az időt a fejlesztésre
is fordíthattad volna.

PHP-val azt szeretném elérni, hogy formázott beviteli mezőim legyenek a formokon.
Csak számok, csak betűk, stb...

Hiba esetén ne a formra irogassa az üzeneteket, hanem "MessageBox"-ba.
Legyen DataGrid-em, master/detail tábla stb..

Legyen tudatába a felhasználó, hogy web program előtt ül, de azért a kinézet a lehető legjobban hasonlítson egy desktop app-ra.

Talán még emlékeztek az áttérésre Dos-ról Win32-re.
Abban az időben Clipper programozó voltam majd egy rövid ideig VB6, Delphi5
Akkor is sok olyan dolgot kellett win alatt megvalósítani, hogy az új progi kezelésében hasonlítson a Dos-os elődjéhez.
Pl.: falnak mentem attól, hogy nem bírták megszokni az Enter helyett a Tab használatát.

Most valami hasonló lenne. Eddig win32 desktop alkalmazás fut és ezt kellene kiváltani a lehető legkissebb zökkenéssel.

Sajna a programozásból jóidőre kiestem, de azért nem vagyok tök kezdő. PHP-t régóta használom kisebb megoldásokhoz, Java-val is próbálkoztam, de az az én koromban már túl tömény :)

Tudom, hogy a fent írt dolgokhoz javascript kell és az ellenőrzést külön meg kell írni PHP-ban is ha jót akarok magamnak.

Azért az ExtJS sok lenne. Szép-szép, de....

http://www.symfony-project.org/book/1_2/10-Forms#Form%20Validation

Kliensoldali validatort itt leirjak, hogy raksz be:

http://blog.adryjanek.eu/2009/01/15/symfony-12-using-sfform-with-jquery…

Igazabol nem lenne egy nagy wasistdas egy olyan osztaly megirasa, ami a yaml-bol legeneralja neked a jQuery validatort, de ezt radbiznam.

( janoszen v | 2010. 02. 15., h – 21:13 )

Ha van kedved, nézd meg a XULt. Érdekes összvér, de szerver oldali komponensekkel megtámogatva rendkívül gyorsan lehet hálózati alkalmazásokat fejleszteni. Ha ma este lesz egy kis időm, befejezem a howtomat a blogomban.

( radix | 2010. 02. 18., cs – 00:28 )

Webes alkalmazást csinálj, 2010-et írunk, és jön a Cloud.....

Ez nem ilyen egyszerű, imho a kérdésfelvetés is rossz. A desktop és a webgui nem közvetlen versenytársak. A cloudnak meg mi köze az egészhez?

Pl. ügyviteli alkalmazásokban a gyorsbillentyűk, nyomtatás, szkennelés, gyors kontrollok és képernyőtartalom gyors felépítése, akár igen egzotikus perifériák kezelése, desktoppal való integráltság meg a hasonló dolgok sokat számítanak, sőt, gyakran ez a lényeg. Ezt necces megcsinálni böngészős klienssel (igaz, az activex lehetőségeit nem ismerem, gondolom linuxon az tárgytalan) viszont "természetesen" :) jönnek ezek a fícsörök desktop API-knál... még egy szempont, hogy egy tranzakcionális, csillió I/O-t végző ügyviteli rendszerben a http és a rá épülő rettenetek egyike sem ideális protokoll a kliensek és a szerver közé, böngésző alapú (esetleg ajaxos) GUIba viszont más protokollt nehéz beletenni, legalábbis nem tipikus.

A nemfunkcionális követelményekből gyakran elég jól átjön, melyik GUI technológia a célravezetőbb, vagy melyik a kényszerből használandó.

( tamaas | 2010. 02. 22., h – 11:13 )

Szerintem kezdj Java-zni.
Hibernate-tel elég sok adatbázist nagyon szépen lekezelsz (értsd, tök mindegy milyen DB van a háttérben, te ugyanúgy látod őket). Emellett nagyon szépen generálhatóak így a Bean-jeid UML-ből. Nem kell SQL statementekkel szarakodni. (Csak ha valami speciális dolgot akarsz.)

Az alkalmazáslogika a Javaban nagyon szépen leprogramozható. Ha ügyes vagy, akkor gyors is.

A felület meg majdnem tökmindegy. Swing ha ablakos programot akarsz, JSF ha webeset. Ha megérted a működésüket, akkor szeretni fogod őket.

Nem mellékesen relatíve platformfüggetlen a szerver oldal is, és a kliens is.

Üdv: Tamaas