HUP Olvasók Választása Díj 2003-2011

HUP

traktor írta:

A 2011-es volt a 9. "HUP olvasók választása díj" szavazás, ami elég sok ahhoz, hogy érdemes legyen visszatekinteni kicsit. Ezért összegyűjtöttem az elmúlt évek eredményeit, és megnéztem hogyan változtak a trendek az egyes kategóriánkban. Az összesítés nem volt egyszerű, és 100%-nak korrektnek sem tekinthető, hiszen nem minden évben ugyanazok a kategóriák voltak, a kategórián belül megváltoztak az elemek, az is előfordult, hogy egy kategória nevet és egy kicsit fókuszt is váltott. Pl. a kedvenc verziókezelő kategóriába, kezdetben csak nyílt eszközök nevezhettek. Az átláthatóságkedvéért csak az első néhány meghatározó elemet vettem minden szavazásból. A kategóriák változásai miatt persze nem is sikerült trendet készíteni valamennyi valaha meghirdetett kategóriában, így összesen 15 kategóriában vannak eredmények, ott sem mindig mind a 9 évből. Ezen nehézségek ellenére azt hiszem tanulságosak az eredmények. A trendeket nem is szeretném kommentálni, beszéljenek a számok, aztán mindenki azt olvas ki belőlük amit szeretne.

HUP Olvasók Választása Díj 2003-2011

( lazly | 2012. 01. 19., cs – 19:46 )

Koszi az osszeallitast, tanulsagos! :)

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

( enpassant v | 2012. 01. 19., cs – 20:18 )

Köszi!
Megjegyzés: a Mercurial a legenden kétszer szerepel.

( BaT | 2012. 01. 19., cs – 20:30 )

A kedvenc fájlrendszer kategóriában hiányolom az ntfs-t, ha már egyszer második lett idén. Illetve a többi kategóriában is gyanúsan hiányoznak a microsoftos megoldások, de ott még betudható annak, hogy a mezőnyhöz képest sem túl népszerűek (gondolok itt a c#-ra vagy a visual studiora például).

( uid_720 | 2012. 01. 19., cs – 20:32 )

Elsőre ez jutott eszembe: "Ó de jó, ez tetszik" :-)
Köszönjük.

Fuszenecker_Róbert

( subchee | 2012. 01. 19., cs – 20:35 )

Aka: így lett Linux-portál a Unix-portálból.

( cherockee v | 2012. 01. 19., cs – 20:35 )

Köszönet, nekem tanulságos volt.

VLC-re váltóktól kérdem, miért? Komolyan, nekem minden vlc-s próbálkozásom alapvetően "ebben is abban is gyengébb" eredménnyel végződött, mit tud újabban a vlc, amit az mplayer nem? UI nem érdekel, nem használom.

Én épp gyötrődök a kettő között, nem is tudom melyikre szavaztam idén
Az mplayer bizonyos formátumokon tekeréstől el szokta veszíteni az A/V szinkront (pl mythtv-vel rögzített mpeg4 dvb-t, mtv videótáras streamelt wmv), meg általában streamelt tartalmakban megbízhatóbb a vlc (legyen az netről vagy egy tv kártyáról streamelve).

Régen zavart, hogy nem lehet szélesvásznú filmek alatti fekete részbe rakni a feliratot, ez 16:9-es monitorral már nem különösen érdekel. Továbbá a legjobb default gyorsbillentyűi, osd-je szerintem még mindig az mplayernek van.

És amit tudtommal egyedül az xbmc csinál jól: a feliratot a kép nagyítása után rakja rá, így nem néz ki ocsmányul kis felbontáson, vagy nem négyzet alakú pixeleknél se.

nem a kérdésedre válaszolok, de a legalacsaonyabb felhasználási szinten (ilyen az enyém) tökéletesen mindegy, hogy vlc-t vagy mplayert használ az ember. gyakorlatilag annyi konfigurálásra van szükség, hogyha a pornóban a seggreütés hangja el van csúszva, azt századmásodperc pontossággal tudjam csúsztatni, és kész. egyszer hozzászoktam a vlc kezelőbillentyűihez, ezért használom.

Vlc számomra több olyan kényelmi funkciót ad, amit mplayer nem tud, és valószínűleg soha nem is fog tudni az eltérő felhasználói igények miatt. Ilyesmire gondolok mint pl. stream közben guin levő record gomb, vagy youtube url lejátszása, illetve a >100%-os hangerő. Illetve a gui is jól el van találva, bár tudom ez téged nem érdekel (és ezért nem vagy a vlc célközönsége). Engem meg az nem érdekel, hogy a 1080p videókat 80%-os cpu usage helyett az mplayer 30%-kal képes lejátszani.

Szerintem meg de.

Nem.

A libavcodec es a libavformat csak egy plugin mplayer-ben. Az a/v sync kod Arpi sajatja, a libmpcodecs pedig egy csillio masik - ffmpegtol fuggetlen - codec halmazt tartalmaz, ahogy a libmpdemux szinten, a subtitle lib szinten sajat fejlesztesu, satobbisatobbi.

RTFS.

---
pontscho / fresh!mindworkz

Az MPlayer mostmár a gyakorlatban csak a libavcodec és libavformat librarykat használja.

Ehhez jönnek még az audió- és videókimenetek, meg az A/V szinkron kód.

Maga Árpi volt az aki FFmpeg frontendként definiálta az MPlayert.
http://hup.hu/cikkek/20101111/10_eves_az_mplayer#comment-1158983

Az, hogy a libavcodec-ben jobbara elsore megtalalja a szukseges codec-et, az nem jelenti azt, h mindig igy van. Ezert eleg sokszor van fallback regebbi codec-re. Masodsorban attol, h a codec es/vagy a demuxer az ffmpeg-bol kerul alkalmazasra az meg nem jelenti azt, h frontend. Harmadszor, fyi, az ffmpeg-ben eleg sok muxer/demuxer minosege meg a szukseges minimumot sem eri el, ezert van az, h sok esetben egy szar videoval az mplayer elbir, a tobbiek meg nem, leven muxer nem feltetlen abbol a libbol jon. Negyedreszt az MPlayer nem csak egy playerbol all, hanem egy encoder appbol is, ahol ha normalisan akar az ember fia tomoriteni, akkor ponthogy nem az ffmpeg-et hasznaja, egyreszt mert felesleges layer mindenfele indipendent codec fele, masreszt a libavcodec-ben levo encoderek jo resze hulladek minosegu. Otodszor, az mplayer nem csak en es decoderekbol, muxerekbol es demuxerekbol es a/v sync kodbol all, hanem van benne egy kobmeter pre es post process plugin, subtitle loader, meg mindenfele istennyila is minden iranyra, ami szinten fuggetlen az ffmpegtol.

Maga Árpi volt az aki FFmpeg frontendként definiálta az MPlayert.

A smiley megvolt?

Azert remelem nem nekem akarod megmagyarazni mi merre hany meter, mert az elegge epic fail lenne. :)

---
pontscho / fresh!mindworkz

Igazad van abban, hogy az MPlayer nem mindössze egy FFmpeg frontend, ez a napnál is világosabb.

Ez tényleg csak annak kérdése, hogy hogyan értelmezed a frontendet.

"hanem egy encoder appbol is"

Amit nem használsz ha normálisan akarsz tömöríteni, mert bugos, instabil, egyáltalán nincs használható állapotban.

Annyira azért nem akarhatod kétségbeesetten védeni az álláspontodat, hogy megemlíted a Mencoder-t, ez olyan dolog amit el kellene hallgatni.

Egyszóval igazad van, meg nekem is van némi igazam.

"Azert remelem nem nekem akarod megmagyarazni"

A hírhedt GMPlayer fejlesztőjének bármikor :-)

Nem vagyok ketsegbe esett, de egy volt mplayer fejlesztonek megmagyarazni milyen a projectje, azert az kemeny. :)

Amit nem használsz ha normálisan akarsz tömöríteni, mert bugos, instabil, egyáltalán nincs használható állapotban.

Azert koszoni szepen, a hibai ellenere eleg jol elvan itt nalunk napi hasznalatban.

A hírhedt GMPlayer fejlesztőjének bármikor :-)

Remelem - szokas szerint - nem csak szemelyeskedni ohajtasz.:-)

---
pontscho / fresh!mindworkz

"Engem meg az nem érdekel, hogy a 1080p videókat 80%-os cpu usage helyett az mplayer 30%-kal képes lejátszani."
Tudná, ha nem lenne fos a vdpau, és nem fagyna csontra az egész kép... Nem tudom, hogy az nvidia driver szar, vagy az mplayer hibája, de jó ideje nem működik. Vdpau nélkül meg ugyanannyi cpuval játssza, mint a vlc (egyébként nincs 80%, 50-60).
--
Discover It - Have a lot of fun!

Igen, csak ez ugyanaz az eset, mint pl a W98 es az XP esete mondjuk egy 2003-4-5-os geppel: hiaba faek egyszeru az XP-hez kepest, nem az ujabb gepekre irtak. -> osszessegeben lassab.

mplayert meg anno AFAIK kifejezetten egyszalura irtak, kifejezetten azokra a gepekre. Nem tudom, tortent-e e teren valami jelentos valtozas, de ma mar masok az igenyek: tobbmagos processzorok egyre valtozatosabb architekturakkal valamint rabszolgamunkara egyre jobban programozhato GPU-k, segedprocesszorok, celhardverek, stb.

En is nagyon sokaig hasznaltam mplayert Windowson, aztan a hd filmek betettek. Az akkori VLC szinten hasznalhatatlan volt (azota valsz. fejlodott a dekoder), vegul megmaradtam a The KMPlayer + CoreAVC parosnal.

----------------
Lvl86 Troll

"Nem tudom, tortent-e e teren valami jelentos valtozas"

Hogyne, az FFmpeg-et továbbra is fejlesztik, képes kihasználni a többmagos processzorokat, ahogy az MPlayer is képes rá.

A hardveres videógyorsítás VA-API-val és annak backendjeivel teljeskörűen támogatott.

Az AVX utasításkészlet támogatásáról nem tudok sokat.

Nem ütöttél nagyon mellé, mert egy 1080p h264-es videó nekem az E8400-en ilyesmi körül mozog, ha action van :).
Az mplayer vdpau kimenettel ugyanezt jelentősen alacsonyabban elviszi, viszont egy egyszerű ablakváltásnál (alt+tab or so), fullscreenben ablak módba váltásnál, fullscreenes lejátszáskor bármi overlay felugrásnál (amarok osd, knotify bal alul) fagyi, kb 5 másodpercre semmi nem megy, utána a desktop többi része magához tér, és ctrl+alt+esc-kel ki lehet lőni.
--
Discover It - Have a lot of fun!

Az mplayer döglődik, alig fejlesztik, nyögvenyelős a kezelése is. Fénykorában még én is azt használtam, szerettem, jó volt, de elavult. Még a weboldalukat sem fejlesztik, milyen ratyin néz már ki? Meg mi az a CRT monitor a fejlécben? xD
A VLC viszont gyors, elegáns, olyanokat tud hogy lehidalsz és még a weboldaluk is modern!

Ha valakinek egy videolejátszónál az szempont, hogy elegáns és a weboldala is modern, akkor az nézze a kedvenc videolejátszójával a lejátszó weboldalán levő monoszkópot - lévén nem a lejátszandó videóra koncentrál. Szerintem az mplayer is gyors, és az is olyanokat tud, hogy lehidalsz - legalábbis valahányszor kell egy funkció, még mindig megvolt az mplayerben (tudom, igénytelen vagyok).
De persze én vagyok az az ember, aki nem érti, hogy pl. egy login ablaknál - ahol működik a beviteli mezők közötti ugrás pl. a Tab billentyűvel - ott miért kell az egér után kaparászni. Ugyanígy nem értem, hogy pl. egy képlopó funkciónál miért is jó az, hogy elegáns a hozzá tartozó gomb a GUI-n, ha egyszer *nekem* gyorsabb megnyomni a billentyűzeten mindig ugyanott levő "s" billentyűt, mint a mindig máshol levő egérkurzort a (z amúgy mindig ugyanott levő) gombra vinni a kattintáshoz.
No mindegy, ezt nem személyesen neked szántam, csak egy kicsit.

"Ugyanígy nem értem, hogy pl. egy képlopó funkciónál miért is jó az, hogy elegáns a hozzá tartozó gomb a GUI-n, ha egyszer *nekem* gyorsabb megnyomni a billentyűzeten mindig ugyanott levő "s" billentyűt, mint a mindig máshol levő egérkurzort a (z amúgy mindig ugyanott levő) gombra vinni a kattintáshoz."

Nem mintha vlc-ben nem lenne gyorsbillentyű rá (shift+s). A gui azért van, hogy ha valamilyen funkciót ritkán használsz (a képlopás tipikusan ilyen), nem kell tudnod hozzá a gyorsbillentyűt.

Gőzöm sincs (*) - én az ilyeneket a TV saját lejátszójával játszatom le. És azt kell mondjam, néhány film 3D-ben való megnézése után sokkal kisebb durranásnak tartom az egész 3D-s TV/film világot, mint amennyire ezt a reklámok harsogják.

(*) vajon miért érzem, hogy az lesz a válasz, hogy az mplayer nem tudja, *bezzeg* a vlc igen?

Mert a csomagolás is számít!
A szépen tálalt ételt is jobb ízűen eszed egy elegáns étteremben, mint sem amit csak odamertek eléd egy menzán.
Egy programot legyen élmény használni. A weboldala is arra ösztönözzön, hogy igen, ezt a programot ki kell próbálnom! A VLC weboldala erre ösztönöz! Az mplayerére ránézek és: "Úr isten, ez a progi vajon az ezredforduló óta frissült?" Kedvem is elmegy hogy kipróbáljam.

( carlcolt | 2012. 01. 20., p – 09:41 )

Csak nekem nem jon be semmi ertelmes? (Linux+Firefox es Linux+Chrome sem)

Igen, annyi hogy a Chrome-on van flashblock. Kozben egy tok szuz Operaval sem mukodik. Linkre kattintva pedig orias egymas hegyen hatan levo betuket kapok minden bongeszovel, gondolom nem az a tartalom.

Lenyeg: amit latok az egy tok feher kep a flash helyen, meg folotte egy olvashatatlan link mindharom bongeszo szamara.

Szerk.: Windows es Firefox ugyanez.

( wachag | 2012. 01. 20., p – 09:48 )

Az Ubuntu, a Gnome és a KDE hanyatlása látványosnak tűnt számomra...

Amúgy azon elgondolkodtam, hogy ezeknek a trendek mennyire reprezentatívak, hisz a HUP-közösség évről évre változik, tehát a szavazótábor mindég más személyekből áll össze. Valaki, aki ilyennel foglalkozik, hozzá tud szólni?

En is ezen tunodtem el. GNOME es KDE is megszenvedte a verzio ugrasokat.
Illetve mekkora elorelepest hozott 1-2 projekt, megjelenese utan: git, chrome, web(mail)
Utobbi szerintem jol mutatja mennyire atkerulnek bongeszobe a funkciok.

A legfurcsabb viszont szamomra az Eclipse visszaesese 2007 ota. En itt pont forditott modban mukodok ugy latom, azota folyamatosan lepett elore, mara pedig alapertelmezett kornyezet lett.

Ez igaz, de amiket kiemeltem azok szerintem megalljak a helyuket hosszu evek osszeveteseben. Ezek a kategoriak, bongeszo, verziokezelo nem sokat valtoztak az evek soran. Talan a webmail-t kihagyhattam volna a listából, de igy is érdekes hogy első szereplésre 30% felett teljesitett, ami szegenysegi bizonyitvany az email kliensek szamara.

"web(mail)"

Ezt komolyan gondolod? Pl. a freemail 1996-ban már rendelkezett webmail-lel.

"Utobbi szerintem jol mutatja mennyire atkerulnek bongeszobe a funkciok."

Ez meg szomorú. Sajnos a webappok sem a felhasználói felület kényelmében, sem sebességben, sem desktop integrációban nem tudják felvenni a versenyt a natív alkalmazásokkal. Legfeljebb fallback-ként látom értelmét ezen alkalmazásoknak, pl. amikor idegen gépen akarom megnézni a leveleimet, akkor jó, hogy van. Remélem, nem vagyok egyedül az álláspontommal.

+1

Én is jobban szeretem a natív alkalmazásokat, ugyanakkor bevallom, ha valamire szükségem van, webes alkalmazást írok. Ennek az az oka, hogy nem értek a GTK-hoz, Qt-hoz, viszont remekül tudok teszem azt, PHP-ban röptében pdf file-t generálni, képet generálni, meg a böngészőben kialakítani a GUI-t.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Viszont ha csinálsz is helyi http-s rendszert, attól még nem függsz a távoli szerverhez kapcsolódó háló sebességétől, amit egyébként is sok tényező befolyásol. Szerintem ezért nem is a web GUI-val van gond, hanem az azokat összekapcsoló szolgáltatások közti hálóval.

BAT felvetésére +1. Valaki már megfogalmazta itt a múltkor a nem tetszését, hogy mire elértük hogy van olcsó erős vasunk viszonylag kényelmes modern szoftverekkel, erre most a gagyi net kapcsolatunk miatt kell malmozni olyan szoftverek esetében is, amelyekhez van offline megfelelő. Pl. levél keresés, amely helyi app-ban is lehetséges.

Persze érthető az elfelhősödés mögötti motiváció. Sokkal könnyebb admin oldalról managelni így a user-ek rendszerét, meg egyéb.

Úgy, ahogy mondod. Én a böngészőt GUI-nak használom lokális gépen futó httpd és php kiszolgálással.

Ami a felhősödést illeti, remélem, nem fajulnak oda a dolgok, hogy kikerülhetetlen legyen. Én idegenkedem tőle elsősorban adatvédelmi okokból. Szeretem birtokon belül tudni a dolgaimat.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"Ennek az az oka, hogy nem értek a GTK-hoz, Qt-hoz, "

Értem, szóval azért mozduljon el egy egész ipar egy hulladék protokol/platform pároshoz, mert egyesek lusták/képtelenek/nem akarnak megtanulni/vagy csak szimplán nem tudnak normális szoftvereket fejleszteni.

Pedig a C+GTK-nál és a Qt-nél is vannak egyszerűbben használható dolgok (Java, C#).

----------------
Lvl86 Troll

Már csak az a kérdés, elolvastad-e a hozzászólásomat. Magam is azt írtam, a natív alkalmazásokat szeretem, mint felhasználó. Aztán mint mellékkörülmény, töredelmesen bevallottam, hogy ugyanakkor a böngésző egy csábító felület arra, hogy GUI-ként használja az ember, s localhost-on futó webszerver futtassa azt a például php kódot, amivel az ember megvalósítja a feladatot.

Sehol sem írtam azt, hogy én lennék az ipari etalon, s hozzám kellene igazodnia a világnak. Pusztán arról beszéltem, hogy ha az embernek nincs kedve, ideje megtanulni olyan eszközök használatát, amellyel GUI-t lehet csinálni, a böngésző mindig kéznél van.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Ez valóban így van. Az egyetlen lényeges dolog, hogy te magadnak azt és úgy raksz össze, ahogy neked tetszik. De ha "eladható" szoftver kiadása a cél, akkor elvárom a fejlesztőktől azt az igényességet, hogy (ha csak a szoftver sajátosságai miatt ez nem lehetséges vagy nem érné meg*), akkor készítsenek natív guit.

*: pl. nyilván senki nem fog natív alkalmazást használni facebookozáshoz, de az nem is munkaeszköz.

A munkaeszközöknél általában több felhasználó használ egy-egy szoftvert, és ott sokkal előnyösebb a szerver - vékony kliens (böngésző) párosítás.
Ma még sok olyan terület van (főleg az egyéni felhasználóknál), ahol célszerű natív programokat írni, de ezek köre egyre szűkül, mivel jószerint ma már mindent meg lehet vékony kliensen is valósítani és rengeteg előnye van a kevés hátránya mellett.

Üzemeltetési és fejlesztési oldalról nyilván sokkal kényelmesebb vékonykliensre fejleszteni, de felhasználói oldalról nagyon gyakran sikerül beleütközni olyan limitációkba, amik natív alkalmazás esetén nem lennének szükségesek.

Pl. a gmail-en egyszerre max. 50 vagy 100 üzenet jeleníthető meg egy oldalon, ha valami műveletet több 100, netán több 1000 üzenetre szeretnél végrehajtani, azt csak 50-100-as adagokban teheted meg. Viszont ha fogsz egy imap klienst, az nem fogja szétdarabolni az üzeneteidet oldalakra, az egy mappában megjeleníti az adott címkéhez tartozó összes üzenetet, akkor is ha több száz vagy több 1000 üzenetről van szó.

Az a baj, hogy a fejlesztők nem gondolnak arra, hogy ezeket a szoftvereket sokan minden nap órákon keresztül fogják használni, és már az rengeteget számíthat, ha 1-1 művelet elvégzése közben meg lehet spórolni pár egérkattintást, vagy egér helyett lehet használni rendes billentyű-kombinációkat.

"Az a baj, hogy a fejlesztők nem gondolnak arra, hogy ezeket a szoftvereket sokan minden nap órákon keresztül fogják használni, és már az rengeteget számíthat, ha 1-1 művelet elvégzése közben meg lehet spórolni pár egérkattintást, vagy egér helyett lehet használni rendes billentyű-kombinációkat."

Ez az adott megvalósítástól függ, vékony kliensen is lehet kényelmes szoftvert csinálni, és vastagon is lehet kényelmetlent.

A példád sem a vékonykliens problémája, hanem a megvalósításé. Nyilván felesleges több ezer üzenetet megjeleníteni egyszerre, de attól még egy műveletet végre lehet hajtani mindegyiken (a több ezren is). Arról nem is beszélve, hogy akár meg is lehet jeleníteni dinamikus listával.

"Nyilván felesleges több ezer üzenetet megjeleníteni egyszerre,"

Valószínűleg élmény egy 10000 elemes cikklistát 100-asával végiglapozni, ahelyett, hogy egy nagy listát legörgetsz. Eleve onnan indul a probléma, hogy a böngészőben egy 10000 elemes lista megjelenítése már önmagában lassú, hát ha te még abban rendezni, szűrni akarsz (akár kliens oldalon), ésatöbbi.

----------------
Lvl86 Troll

"Nyilván felesleges több ezer üzenetet megjeleníteni egyszerre,"
"Valószínűleg élmény egy 10000 elemes cikklistát 100-asával végiglapozni,"

Arra utaltam, hogy van ennél hatékonyabb és jobb módszer, pl. szűrés.
Illetve azt is írtam, hogy ha ez a nagyon fontos funkció kellene, akkor még az is megoldható. Itt egy példa 20000 elemre, de lehetne akármennyi is.

a gmail-en egyszerre max. 50 vagy 100 üzenet jeleníthető meg egy oldalon, ha valami műveletet több 100, netán több 1000 üzenetre szeretnél végrehajtani, azt csak 50-100-as adagokban teheted meg.

Nem teljesen. A napokban használtam a Gmail webes felületét, és úgy tűnt, hogy a keresés/szűrés alapján megjelenített listáknál (pl. egy címkéhez tartozó levelek megjelenítése is keresésnek/szűrésnek számít) megkérdezte, hogy a keresésnek/szűrésnek megfelelő összes elemet akarom-e bizergálni.

Viszont ha fogsz egy imap klienst, az nem fogja szétdarabolni az üzeneteidet oldalakra, az egy mappában megjeleníti az adott címkéhez tartozó összes üzenetet, akkor is ha több száz vagy több 1000 üzenetről van szó.

Már csak az a kérdés, ha valamit kezdeni is akarsz a levelekkel, akkor az asztali géped és IMAP-kliensed vagy a Google szerverei csinálják meg neked gyorsabban?

:)

"Nem teljesen. A napokban használtam a Gmail webes felületét, és úgy tűnt, hogy a keresés/szűrés alapján megjelenített listáknál (pl. egy címkéhez tartozó levelek megjelenítése is keresésnek/szűrésnek számít) megkérdezte, hogy a keresésnek/szűrésnek megfelelő összes elemet akarom-e bizergálni."

Az a baj ezzel, hogy szűrés nélkül nem igazán működik. Pl. az első oldalon nincs egyetlen olvasatlan levelem se, de a másodiktól kezdve van. Ha az első oldalon kijelölöm az összes olvasatlan levelem, akkor 0 levelet fog kijelölni, és fel se ajánlja, hogy a többi oldalon levő olvasatlan levelet is megjelölhetem.

"Már csak az a kérdés, ha valamit kezdeni is akarsz a levelekkel, akkor az asztali géped és IMAP-kliensed vagy a Google szerverei csinálják meg neked gyorsabban?"

Ebben az az érdekes, hogy nem az imap kliens hajtja végre a műveleteket, az csak közli azokat a google szervereivel, amik végrehajtják azokat. Tehát továbbra is a google szerverei dolgoznak, a kliensnek csak a megjelenítés a feladata, amire viszont a vastagkliens alkalmasabb.

Az a probléma, hogy nem kevés embertől hallottam már vissza ugyanezt a mondatot, és sajnos vélek felfedezni egy kis párhuzamot aközött, hogy a mostani munkahelyemen is több időt elvesz a korábbi gányolmányok felszámolása, mint amennyit akartam vele foglalkozni, amelyet oda tudok visszavezetni, hogy "hát mert PHP-ben egyszerű volt összegá^Wmegoldani".

----------------
Lvl86 Troll

"Vagy zavar, hogy php-ben a változók nevei előtt van egy $ jel?"

loool, majd biztos ez lesz a hatalmas katasztrofa :D:D csak ezert utalhatja a php-t, biztos nincs ra semmi mas oka :D :D

meg azert ganyolnak benne szar kodokat, mert $ kell a valtozok ele ROTFL, ha nem kene a $, akkor csak okosabbak tudnanak benne programozni :D:D

(majd olvass el egyszer egy nemaltalad irt php kodot, megerted)

Gondolom, értetted a cinizmust a kérdésemben. Néha én is ámokot futok, de azt csak én tartom karban. Például nem nagyon szeretek kommentelni. Ugyanakkor a változó- és függvényneveim árulkodók.

Egyébként minden nyelven lehet gányolni, s ezekben lehet normálisan is programozni. Éppen a php szintaktikájában viszonyleg közel áll a C-hez, viszont sok vonatkozásban kényelmesebb a C-nél. Talán ezért szeretik. Meg nyilván lassabb, hiszen interpretált nyelv, szemben a compilált C-vel. Akár assembly-ben is írhat valaki rettenetes kódot. Nem függ a nyelvtől ez.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Hogyan írnád azt, hogy gépi kódra fordított?

Ennek lehet, az az oka, hogy mindenféle "webmesterek" egyik leggyakrabban használt eszköze a php. Ráadásul nem, mintha a php scriptet csak webszerver futtathatna, vagy bármilyen kapcsolatba kellene hozni azt a böngészővel. Bármikor írhat az ember sima futtatható kódot benne:


#!/usr/bin/php
<?php
for ($i = 0; $i < 10; $i++) {
    echo "{$i}\n";
}
?>

Ezt csak arra írtam, hogy a statisztikát a webhuszárok rontják szerintem, nem a php-t kiáltanám ki bűnösnek.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"Vagy zavar, hogy php-ben a változók nevei előtt van egy $ jel?"

Miután kb. 3,5 éve a (elsősorban) a PHP-ből élek, azt hiszem, nokomment.

"Miért kell felszámolni ezeket a gányolmányokat? "

Azt hiszem, az Excelből kijövő CSV-kben lévő "érvénytelen karakterek" $str = str_replace(chr(xyz), "randomkarakter", $str); hegyek vs $content = iconv('iso-8859-1', 'utf-8', file_get_contents()); -tel való javíthatósága és az XML fájl preg_match_all() -lal való feldolgozása sokmindent elárul ezen kódok minőségéről, megbízhatóságáról és rugalmasságáról.

----------------
Lvl86 Troll

Te kérdezted, hogy miért kell felszámolni ezeket a gányolmányokat. :)

Csupán apró megjegyzésként közöltem, hogy nagyságrendekkel több hasonló PHP kóddal találkozok, mint mondjuk C#-ossal vagy Java-val. Igen, ott is megvannak a gyönyörűségek (igaz, szerintem ott inkább jellemző az, hogy nagyon enterspajzok akarnak lenni és túltervezik az egészet), de mivel magasabb a kerítés ÉS általában a nyelv is megköveteli, hogy gondold végig, hogy mit akarsz, kevesebb gányolmány születik.

Alapelv: egy fejlesztő tud PHP-ban _IS_ programozni, egy PHPistuka _csak_ PHP-ban tud "programozni".

----------------
Lvl86 Troll

( dash | 2012. 01. 20., p – 10:07 )

az egyes kategóriánkban -> az egyes kategóriákban

( Kambus | 2012. 01. 20., p – 11:21 )

Kedvenc webböngésző -> madár fej
Kedvenc email kliens -> bálna

HOVD ascii diagram art? :)