Sajtóbejelentésben közölte az NVIDIA, hogy új linuxos drivere az előzőnél kétszer több FPS-t tol

Játék

Az NVIDIA sajtóhírben bejelentette, hogy legújabb linuxos NVIDIA GeForce eszközmeghajtó-programjai -- R310 -- az előzőknél kétszer nagyobb teljesítményre képesek.

A cég egy 3,2GHz-es Intel Core i7-3930K CPU-val, 8GB memóriával, GeForce GTX 680 GPU-val szerelt gépen, 32 bites Ubuntu 12.04 alatt hasonlította össze 304.51-es és 310.14-es verziójú drivereit. Az előbbi driverrel Left for Dead 2 (beta) alatt 142,7 FPS-t, az utóbbi driverrel 301,4 FPS-t mértek.

A sajtóhír itt olvasható. A driver letölthető a geforce.com-ról.

( akion | 2012. 11. 07., sze – 15:22 )

Hazaérek, tolok benchmarkot Xonotic-kal.

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Felesleges. Legalábbis emiatt a bejelentés miatt nem érdemes. A közlemény nem azt állítja, hogy megduplázták a teljesítményt:

"NVIDIA today announced the latest NVIDIA® GeForce® drivers -- R310 -- double the performance(1) "

"(1) Comparing 304.51 driver performance of 142.7 fps versus 310.14 driver performance of 301.4 fps in beta build of Left for Dead 2. All tests run on the same system using Intel Core i7-3930K CPU @ 3.20GHz with 8 GB memory, GeForce GTX 680 and Ubuntu 12.04 32-bit."

Marketing bullshit, de be jött mert beszélnek róla.

A méréseket azért köszi.

( after | 2012. 11. 07., sze – 15:31 )

Aki szeretné az R310-et megtalálni, a beta driverek között keresse. "Stabil" drivernek az R304-et ajánlja fel.

( emberk | 2012. 11. 07., sze – 15:36 )

Megnézem CUDA mit szól hozzá. Ha van mérésem szólok.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Nem ugy ertem hogy konkretan az OUYA-n (mivel azon mar konkretan Android lesz) csak, hogy szerintem hasonlo kezdemenyezes varhato. Ki lehetne hasznalni azt, hogy mar megvannak az eleg fejlett/olcso mobil GPU chip-ek. Igy tenyleg halott az olet, hogy az uj HL majd "csak" linuxon fog kijonni. Mar latom ahogy mindenki bebootolja az UBUTUT! es szijjellomindenkit!... Ez elfogadhatatlan lenne, viszont egy olcso konzol + marketing jol parositva eleg jo kis platformot eredmenyezve szvsz ...

Ezek utan elgondolkozhatnanak a TV gyartok, hogy bele rakjak-e ezt a TV-be gyarilag :D

( Pontscho | 2012. 11. 07., sze – 16:48 )

Ez tipikusan az a sztori, amit windows alatt is el szoktak kovetni, h a drivert optimalizaljak az alkalmazashoz es nem az alkalmazast a driverhez. Isten hozta ezeket a balhekat immaron linux alatt is, a marketing immaron fontosabb lett, mint a teljesitmeny. :)

---
pontscho / fresh!mindworkz

( freeoli v | 2012. 11. 07., sze – 19:05 )

Jójó fps hegyek, de milyen felbontason? Nem találtam meg, azért kérdezem.

( nagysa v | 2012. 11. 07., sze – 19:30 )

Kipróbáltam. :(
Debian wheezy 64-bit. Elindítottam a gl-117 játékot az előző 304-es driverrel. Az fps 59-60.

Majd az új beta 310-esel is. Nos az fps itt is 59-60.
A kártya gforce 9600.

Lehet, hogy át kell térjek egy modernebb 32 bites rendszerre? :)

( Replaced | 2012. 11. 07., sze – 19:40 )

eddig volt fele olyan lassu

hth

--
NetBSD - Simplicity is prerequisite for reliability

És ebből az 500-5000 játék fejlesztőiből hány volna képes fizetni az nvidiának egy ilyen szívességért, vagy tenne nvidia reklámot a játéka intrójába?
(Nem, nem állítom, hogy a valve fizetett az nvidiának, de elég nagy cég ahhoz, hogy a jövőben ezt bármikor megtehesse, ha úgy hozza érdeke.)

Még csak nem is arról van szó, hogy ki fizet, meg ki nem. Az 500-5000 játékból hány olyan van, ami egy modern videókártáyt megizzaszt? Tippelek: 3. Az az igazság, hogy a linuxos 3D játékok nekem a 90es évek végét idézik, amik egy 64 Mb-os G-force2 is elmennek.
-
Eclipselink beizzítása Jboss 7.1 környezetben

Nem feltétlen játék. Itthon nagyon nem népszerű, sőt lenézett, szánalmasnak tartott virtuális világ. Persze jelentősen félreértelmezve mi is ez, igaz a neve is segít benne. Mindenesetre köze sincs a simshez, és sokszor a kitaszítottabb, szubkulturális roleplay világok csak itt készülnek el. Bár van ott minden, a harctól kezdve a járműves versenyeken át, 3D művészet, vagy akármilyen oktatás stb. is. Időnként szoktam róla írni főleg technikai dolgokat ide.
--
AGA@
Fork portal és az egyik logóm :)

Szerintem az a nagyon durva, hogy ugyanazon a hardveren, amin a cod2-t DX7 rendereléssel játszottam (mert DX9-el akadt, ha 1024*768 fölé vittem a felbontást) megboldogult gyerekkoromban, azon most megy a Crysis 2. Pedig azért messze nem ugyanúgy néz ki a két játék. Csak ugye utóbbit gondolom optimalizálták.

Bánom is én mitől, sokkal szebb és kész. :)
Nyilván sokat számít a "művészek" munkája, de azért gondolom az optimalizáció is játszik. Az jár a fejemben, hogy ugye van az a nyomás, hogy az újabb játékoknak illik jobban kinézniük, mint a régieknek, viszont a konzol hardverek nem fejlődnek. Így aztán gondolom kénytelenek a játékfejlesztők minden apró kis trükköt bevetni, amivel nyerni tudnak egy kis sebességet, hogy a felszabadult erőforrásokat valami szépre használhassák fel.

Javíts ki ha tévedek, de szerintem ez is olyan mint az animációs filmek. Ott azt szokták mondani, hogy azt a filmet lehet kivitelezni amit az elérhető munkaállomások közül egy darab egy év alatt le tudna renderelni. Természetesen nem azért mert egy gépen renderelnék a filmet, hanem azért, hogy normális sebességel lehessen dolgozni. Szóval egyik oldalról fontos, hogy mit tudnak az animátorok csinálni, de másik oldalról fontos az is, hogy ehhez megfelelő eszközeik legyenek. Sőt, ha alájuk raksz pár erősebb gépet vagy jobb szoftvert akkor azonos idő alatt szebb dolgot csinálnak.

( kmARC v | 2012. 11. 07., sze – 20:12 )

Elkaptunk egy diffet, ez volt benne: 


*** renderimpl.c	2011-04-31 17:43:59.948968323 -0600
--- renderimpl.c	2012-11-05 16:10:27.384955596 -0600
*************** int repaint(unsigned x, unsigned y) {
*** 82,87 ****
--- 82,90 ----
  
      if (strcmp(EVILGLOBALSTATE->platform, "windows") == 0) {
          // no performance-related degradation must go here EVER!
+     } else if (   strcmp(EVILGLOBALSTATE->platform, "linux") == 0
+                && strcmp(EVILGLOBALSTATE->flavor, "ubuntu") == 0) {
+         // they began to pay. See bug number #21. 
      } else {
          // shitty nongaming platforms with low revenues
          usleep(3);

( carlcolt | 2012. 11. 07., sze – 21:00 )

"kétszer több FPS-t tol"

Eddig csak Xonotic-ozni meg UT-zni tudott, mostmár COD-zni és CS-zni is tud? ;)

Egyébként azért kissé elgondolkoztató ilyen dolgokon a "még béta" kijelentés. Ez egy folyamatosan, hónapról hónapra fejlesztett szoftver, jellemzően inkább karbantartásokkal, utókövetésekkel. Ami itt most "béta", az az előző stabil driver továbbfejlesztett tesztváltozata. Illene már valami pozitívat felmutatnia.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

El is olvastad, hogy mire válaszoltál? Pont arról van szó, hogy a kirakat játék L4D2 "hasít", a többivel meg ugyanolyan lassú. Egyre inkább úgy tűnik, hogy a Windowson anno már bevált hype-kamu folyik itt is az NVIDIA részéről. De ne legyen igazam!

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

Most kicsit kínosan érzem magam (de teheti ezt mindenki, aki fentebb akár pozitívat, vagy negatívat mondott).
Nem furcsa senkinek se, hogy végig 75 FPS...? De, bizony, ez sync to vblank. Most néztem meg, az új driver alapból bekapcsolta, így már érthető, hogy végig alacsonyabb, mint 304-gyel.
Nincs mit tenni, újra kell mérnem.

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Ne örülj, egy mérés nem mérés, szvsz a témát érdemes több oldalról is körbejárni, több paramétert is változtatva.
Nekem ugyanis kb. netto marketing bullshit a bejelentés, hisz se egy grafikont, se egy screenshotot, semmit se mutattak be (ráadásul csak egy gépen, egy konfigurációval tesztelték).

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Szegénykém, ultimate beállításnál is a vblank fogja meg 52 fps körül, ugye?! De te az új méréseknél, amikor ugyanazokat az értékeket hozta a két driver, akkor is biztosan látod a 310-es kétszeres sebességét.

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

Mester, fejtse ki, legyen szíves, A-tól Z-ig, hogy akik nem értenek hozzá, mint én, még azok is megértsék! :)

_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

Hat igen, de lehet en ertem felre vagy felreertheto az irasom ... Az nem erdekes, hogy lassu vagy nem az sem vagy a meres pontos hanem az, hogy kijelentik, hogy 2x gyorsabb az uj cucc es ha valaki azt dobja be, hogy szerinte nem az, nem lehet vedeni a kijelentot azzal, hogy nade ez "beta" meg "egyáltalán ki játszik Xonotic-kal?"...

A hivatalos bejelentés linkjét is érdemes megnézni.
(1) Comparing 304.51 driver performance of 142.7 fps versus 310.14 driver performance of 301.4 fps in beta build of Left for Dead 2. All tests run on the same system using Intel Core i7-3930K CPU @ 3.20GHz with 8 GB memory, GeForce GTX 680 and Ubuntu 12.04 32-bit.

Ez ugyanolyan mint mikor kiadja az ATI vagy az NVidia az új drivereket és "Up to 30% in 2560x1400 in Metro 2033 with quad-SLi." Biztosan lesz másban is javulás, de lásd a másik hozzászólásom. Most a Steam-nek készült a driver. Aki bekerült, annak kell felraknia (már ha játszani akar). A többieknek ott a stable.

Most a nyílt ati körül is bűvészkednek különféle patchekkel. Vagyis inkább hacknek nevezném őket. Egyik másik dolog javul, egyik másik meg rosszabb lesz tőle.

Gondolom itt is rámentek nagyon a Steam debugra, aztán a többit meg nem nézték. Szerintem úgyis javítják, nem szoktak regressziókat hagyni.

( pepo v | 2012. 11. 07., sze – 23:36 )

Nekem ez a driver van fent reggel óta, de semmi többlet teljesítményt nem tapasztaltam GeForce 9600 GT GPU használata mellett.

Csatlakozom:
Nekem GT 610-es van, ami boarding pass ugyan (azaz beszállókártya :) , de ezen nem táltosodott meg a 310.14 a 304.60-hoz képest:

Unigine demó benchmarkok:
Sanctuary: 38 -> 42 fps
Tropics: 13 -> 15 fps

Cg példaprogikkal pedig határozottan visszaesett az fps érték, pl. 1290 -> 1260, 570 -> 530.
A glxgears minimálisat gyorsult, de hát, mint tudjuk, ő nem számít...

(Még nem olvastam át a doksiját, hátha megjelent valami gyökeresen új x config opció, vagy valamelyik régi törlendő, ami nekem be van állítva. Esetleg új nvidia kernel modul paraméter, pl. bazigyors=true. Ha valaki felfedezett ilyet, ne titkolja.)

Az nvidia fórumon még nincs válasz.

Viszont a bejelentésben ez benne van:


Certain statements in this press release including... statements as to: the impact and benefits of GeForce Drivers; ... are forward-looking statements that are subject to risks and uncertainties that could cause results to be materially different than expectations.

Szóval most megtudtuk, hogy lehet akárhogy is. Hasznos dolog egy jogász...

Edit: a Phoronixon már augusztusban is irták, hogy a l4d2 gyorsabb Linuxon. Szóval a Source engine miatt lehet leginkább.

Szóval a Source engine miatt lehet leginkább.

Az elég valószínűtlen, hogy az egyik platformon megy 60 fps-sel, a másikon meg 120 fps-sel. Csak egy esetben tudok ilyet elképzelni, ha mondjuk Windowson elkefélték a DirectX renderert, míg Linuxon jól megírták az OpenGL renderert. Minden más esetben a driver, vagy valamelyik alrendszer sokkal inkább felelős lehet a problémákért, szerintem. Ennyi sebességet egyszerűen nem lehet "találni", csak azért mert a Linux jó. Ez az egész dupla sebesség egy akkor bullshit, mint ide a mély űr! :)
_______________________________________________________________________

Android: https://play.google.com/store/search?q=artex+studios
iOS: http://itunes.apple.com/hu/artist/artex-studios-inc./id399983944

A Phoronixon van egy teszt, ez már reálisabb, és hasonlit ahhoz, amit én láttam.

Ez megemliti a kisérleti multithreades OpenGL opciót, bár a test suite anélkül futott. Ezzel még érdemes lehet próbálkozni.

Threaded Optimizations

The NVIDIA OpenGL driver supports offloading its CPU computation to a worker thread. These optimizations typically benefit CPU-intensive applications, but might cause a decrease of performance in applications that heavily rely on synchronous OpenGL calls such as glGet*. Because of this, they are currently disabled by default.

Setting the __GL_THREADED_OPTIMIZATIONS environment variable to "1" before loading the NVIDIA OpenGL driver library will enable these optimizations for the lifetime of the application.

Amúgy sync to vblank ügyben:

Option "TripleBuffer" "boolean"

Enable or disable the use of triple buffering. If this option is enabled, OpenGL windows that sync to vblank and are double-buffered will be given a third buffer. This decreases the time an application stalls while waiting for vblank events, but increases latency slightly (delay between user input and displayed result).

Bocsi, hogy a szónoklatokat ezzel higítom, de kipróbáltam, mit csinál a multithread bekapcsolás.
Röviden: lelassítja a cuccot.

Részletek: (AthlonX2 3600, 32 bit 3.6.2 kernel, GT 610 GPU)

CPU load screenshot-ok itt:

Unigine Sanctuary és Tropics benchmarkok. (Grafikonok bal széle az új módi, jobb széle a hagyományos futtatás.)

Ha beállítom az OpenGL multithreading-et (MT), mindig
- nagyobb CPU kernel load és
- leesett framerate (15 vs 9, 42 vs 27 frame/s)
az eredmény.

Ahogy írja is a doksi, egyes progik nyernek a MT-n, mások nem. A Unigine-t profi engine-ként hirdetik, és sztem az is, mégis sokkal lassab a kisérleti MT-vel. Szóval nem triviális olyan appot írni, ami ki tudja használni a MT-t. Helyes, hogy gyári defaultként ki van kapcsolva.

spekula ON
Ahhoz, hogy nyerjen a multithreadingen egy app, az kell, hogy rengeteget számolgasson a megjelenítő thread-ben. Ekkor a számításokat ki lehet pakolni másik thread-be és nem akasztja meg a rajzolgatást. Persze ez nem megy, ha a rajzoláshoz kellenek a számítások.

Lehet, h. a demók azért lassultak ekkorát, mert azok arra vannak kihegyezve, hogy a GPU-t dolgoztassák nagyon, tehát nem CPU-ban izomkodnak. Vagy más okból :)
spekula OFF

Végre pár nap után kommentálta az nVidiától valaki az Unigine benchmarkot:

Unigine makes heavy use of synchronous GL operations that don't interact well with the threaded optimizations. In my testing, the applications that benefited most from it were Source engine games, and id Tech 4 games to a lesser extent (Doom 3, Quake 4).

Viszont kijött a 310.19, és ezzel az Unigine Sanctuary demo felgyorsult, de elég rendesen:

kb. 40 fps -> 70 fps.
Ugyanazok a beállítások, kernel, stb.
A többi Unigine demó nem gyorsult fel, de a Cg demók visszatértek a régi magasabb fps értékükre, amit még a 304.* alatt produkáltak.

Most akkor vagy a Sanctuary-t írták meg olyan spéci módon, hogy ez a driver különbség számít, vagy nem tudom...

( Sanya v | 2012. 11. 08., cs – 08:52 )

nekem 64 bites 12.10-ben ha nvidia drivert rakok fel optimus nélküli laptopra, akkor a 1920*1080 felbontású monitorom és az asztalom közepét mutatja az ubuntu következő indításra 640*480-as felbontással. grafikusan onnantól kezdve már semmit nem tudok csinálni :)

---

( akion | 2012. 11. 08., cs – 08:53 )

Na, mérési hiba (van ilyen) miatt vissza kell vonnom részlegesen a fentebbi állításom, miszerint nvidia suxx.

https://picasaweb.google.com/lh/photo/cmF5U8zk178EuJ1RY66e7qcb6hL-oNtVQ…

Az új driver mint fentebb írtam, valami miatt automatikusan bekapcsolta a sync to vblank funkciót, nem csoda, hogy végig 75 FPS értéket generált.
A grafikonon és az adatokon jól látszik, hogy kb. semilyen változás nem észlelhető (mondjuk ez egy nagyon fos ábra, még szórások sincsenek rajta, de ezt majd később pótolom).
Felmerülhet a kérdés, hogy "mi van akkor, ha a géped fostalicska, és csak ennyit tud?". Nos igen, ez egy lehetséges magyarázat. Adjunk még egy esélyt az Nvidiának, hátha processzor limitbe ütköztem! Darkplaces alatt az animációk kezelése ugyanis sajnos nem a GPU-n hanem a processzoron történik. Ezt jó ideje próbálta már több programozónk is megoldani, egyelőre hiába.
Van lehetőség a processzor teljesítményének hatását kiküszöbölni, az animációk kikapcsolásával (mod_alias_force_animated 0 cvar).
Délután újramérem mindkét driverrel így is, stay tuned....

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

Azért tartom a Xonotic-ot jó benchmarknak, mert a Phoronix is több helyen ezzel szokott mérni, az Openbenchmarking része.
Amivel én mérek, az a saját benchmark scriptünk, ami 7 grafikai konfiggal, konfigonként 4x végigmér egy elég akciódús demót.

----------------------------------------------------------
"One should strive to achieve; not sit in bitter regret."
www.xonotic.org

( Smokey2k | 2012. 11. 08., cs – 14:18 )

hihetetlen hogy ennyi év porhintés után még mindég vannak emberek akik bármit is elhisznek az nvidia bullshitb-ől, mondjuk eleve az se semmi hogy valaki még hisz a linux desktop évében :)

SZVSZ a Linux desktop éve mindenkinek máskor jön el. A legtöbbeknek sohasem (szerencsére). Nekem meg valamikor az ezredforduló magasságában, és azóta folyamatosan itt van.
Folyamatosan változik, ez tény. Van ami egyre jobb benne (eszköz driver ellátottság), van ami nem igazán fejlődik.
Mint bármelyik másik desktop OS.
Csaba

Én pedig azt, amikor az általam használt desktopokon többségbe kerül.

Amúgy persze, egyetértünk. Csak ugye világos, hogy senki nem beszél komoly kontextusban már nagyon régen a Linux Desktop Évéről, amikor előkerül, akkor a Linux Desktop lesajnálása a téma.
Amúgy szerintem pont elég user van Linux Desktopon ahhoz, hogy nekem megfelelően fejlesszék a releváns szoftvereket. Nem szeretném egyébként, ha sokkal több user lenne, mert akkor még több amatőr jelenne meg a fórumokon. Én azt látom szívesen, ha a Linux Desktop megmarad annak, ami most, egy viszonylag szűk, de viszonylag hozzáértő réteg rendszerének. Aki teljesen a maguk szája íze szerint hajlítgathatják a rendszert, ahogy nekik jól esik.
Csaba

Erről már írtam egy másik topikban bővebben.
Röviden összefoglalva: a Linux egy kísérleti/kutatási operációs rendszer, így is kell kezelni. Hozzáértők készítik hozzáértőknek.
http://hup.hu/node/118537?comments_per_page=9999#comment-1524540
Ebben a threadben írtam erről.

Azok úgy is sikerülnek, tele vannak csak az adott disztribúciót érintő bugokkal, és olyan userekkel, akik bejelentik bugnak azt, aminek a megoldása egy félsoros script az rc.local-ba Arch-on pl., és az Arch userek eközben ezt meg is csinálják a wikiből bugreport nélkül.

Röviden: a Linux továbbra is hozzáértők munkája hozzáértőknek, minden más elképzelés halott asztali felhasználásra (is)

Ez érdekes. Az őseim Ubuntut használnak. Soha életükben nem tanítottak nekik informatikát és valahogy az Ubuntunál emlegetett bug áradat is elmaradt a dzsunka laptopjaikon, mert teljes megelégedéssel használják, csak az egyikük Unity helyett Gnome fallback-et. Biztos olyan bugos és annyira nem értenek hozzá, hogy az már a visszájára fordult.

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

Tévedés. Itt olyan szintű kérdésekről van szó, ami Windows-on éppen úgy gond lenne. Teszem azt, hogyan lehet megnézni egy DVD filmet? Windows-on, Linuxon ugyanúgy kell használni a VLC-t, de hogy az az "ugyanúgy" hogy van, el kell mondani. Vagy hogyan lehet YouTube videót kirakni teljes képernyőre? Hát úgy, hogy a megfelelő helyre kell bökni az egérrel.

Itt nem oprendszer-specifikus kérdésekről van szó, nem bash-ben tanítok bárkit is programozni. Tehát a kérdés nem azért merül fel, mert Linuxot használnak, s Windows esetén fel sem merülne a kérdés, hanem azért, mert számítógépet használnak.

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

Amíg ilyen feladatok jönnek elő, addig nincs is baj. A gond ott kezdődik, hogy "miért nem látja/miért látja fejjel lefele a webkamerámat a Skype", "Hogy tudom a telefonkönyvemet úgy felrakni mint régen a Nokia PC Suite-tal", "Teleraktam a /home-ot, mit töröljek le?" meg "Hogyan tudom a Bluetooth headsetemet működésre bírni vele".

És akkor nem beszéltünk a KDE-ben és GNOME-ban is előforduló "jobb gomb, panel eltávolítása, ok gomb, pánikból reszet gomb" folyamatról, azt jóval könnyebb elrontani, mint Windowson, egyszer csak task managerük se lesz.

Na, azért ez így nem igaz. Nekem sokszor kellett telefonról segítenem: "Na, igen, mit ír ki? Jó, nyomd meg az Igen-t." És hasonlók. Természetesne nem is mondom, hogy a Windows a legjobb operációs rendszer (több esetben is kitárgyaltuk, hogy mindegyik szar), csak a Windows az, amivel kevesebb a szívás.

a Windows az, amivel kevesebb a szívás

Ahhoz képest én eddig a Windows-zal szívtam a legtöbbet. Eleve hiányolom a megszokott eszközeimet, éppen ezért van az, hogy ha windows-os gép javításához hívnak, viszek magammal linuxos live CD-t, hogy legalább kezdeni tudjak valamit a géppel.

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

Engem sokkal gyakrabban kerestek a problémáikkal, míg Windowst használtak. Én nem SSH-zok be Linuxon és nem oldom meg a gondjaikat, mert a rendszerrel kapcsolatban nem is szokott lenni. Inkább olyan jellegű kérdésük szokott lenni, hogy hogyan tudnak CD-t rippelni és zenét vágni a telefonjukra csengőhangnak, de ilyet Windowson sem csináltak.

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

Ebben igazad lenne, ha csak registry kulcs módosítással lehetne ellátni alapvető rendszergazdai feladatokat és nem GUI-ból. Ettől függetlenül én is szeretem a UNIX filozófiának megfelelő szöveges konfigurációs fájlokat, de ettől még a Linux nem lesz rajtam kívül túl sok mindenkinek barátságosan használható

"És Linuxban valóban minden szöveg és valóban minden file?"

Nem, pont ez a baj, hogy egyre kevésbé követi a Unix filozófiát (élen a systemd journaljával pl.)

"És valóban jó az, hogy minden szöveg?"

Egy bizonyos hozzáértési szint fölött: igen, mindenképpen jó (lenne)

De egy biztos: Linux esetén több minden szöveg, mint Windows esetén (rendszer "mélyét" nézve).

"kommentelt konfigurációs file szerkesztése kézreállóbb"

Szerntem egy átlagfelhasználónak közreállóbb a megfelelő UI-n kibökni a megfelelő pipát.

Hihetetlen, hogy 2012-ben még _mindig_ itt tartotok...

Registry... érdekes, hogy mindig a Linuxos userek panaszkodnak a registry miatt. Szerintem évek óta nem használtam regeditet. Másrészt a kommenteken kívül el lehetne diskurálni arról, hogy mennyi hátránya van a textfilenak egy típusos, jogosultság-kezelt kulcs-érték alapú adatbázishoz képest. Bár mint mindtam, igen ritka az, hogy valamit registryben kelljen turkálni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Registry témához hozzátenném, hogy ha valamiért mégis kézzel kellene beleturkálni a registrybe, és mondjuk erre 1-nél több helyen lenne szükség, .reg fileokkal sokkal egyszerűbb megoldani, mint a különböző szintaktikájú config fileokra bonyolult szövegfeldolgozást végző egyedi scripteket írni.

Modern scriptnyelvek világában ez nagyon nem igaz, elég könnyű rendes sztringmanipulációs scriptet írni, szerintem még meg se kellett nyomnod a regeditben az F3-at a következő kereséséhez, mire én készvagyok egy config fájl átíróscriptjével.

Mégegyszer mondom: ha valami szöveg, az mindig kezelhetőbb, olvashatóbb, és ezt továbbra is fenntartom. Saxusnak talán picit igaza van a jogosultságkezeléses részében a registry-nek, de más előnye tényleg nincs annak az olvashatatlan hulladéknak. (Na jó, abban is igaza van, hogy ritkábban kell Winen registry-hez nyúlni, mint config file-hoz Linux/Unix-okban, de ettől még a registry nem lesz jól és könnyen kezelhető).

"Modern scriptnyelvek világában ez nagyon nem igaz, elég könnyű rendes sztringmanipulációs scriptet írni"

== taknyolni valamit arra a feladatra, amire nincs jól bejáratott szabványos megoldás. Registryt csak egyféleképp lehet szerkeszteni. Config file meg... Nos, ahány program, annyi féle.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"taknyolni valamit arra a feladatra, amire nincs jól bejáratott szabványos megoldás"

Ettől még nem lesz rossz önmagában az, hogy textfile-ként tároljuk a konfigokat, az nem a "legyen textfile minden config" filozófia hibája, hogy nem voltak képesek ennyi év alatt egy szabványt kialakítani rá és használni, mellesleg a registry-be is tudnak érdekes programok érdekes marhaságokat hajigálni. Aláírom, hogy érdekesen működik Linuxon egy-két text alapú config, de ettől függetlenül szerintem meg lehetne azt legalább olyan korrektre csinálni (vagy korrektebbre) mint a Registry-t (de gyorsabbra és hatékonyabbra midneképpen).

Szabványnak hozzá pl. nem lenne rossz első körben akár egy xml, vagy akár az, ahogy pl. az nginx config file-ja kinéz, nem én döntöm el, de meg lehetne ezt szépen és egységesen oldani.

Szinte meg se merem jegyezni, hogy windowson van szabványos config formátum is ini néven.

Lehet, hogy felhasználói szempontból kényelmesebb a txt config, de alkalmazásfejlesztői szempontból egyszerűbb a registry. Márpedig egy ideális világban a beállításokat a szoftverek nem csak olvassák, de generálják is, vagyis a felhasználónak nem is kell olvasnia, írnia azokat. Ekkor pedig mindenképp jobb egy könnyebben lekérdezhető, típusos adatbázis.

A mai világban, amikor van egy teherautónyi megoldás, amik teljesen automatikusan benyalják és vissza is írják neked ezeket a config fájlokat, van ennek bármi jelentősége? Ellenben nekem a magánvéleményem az, hogy nem túl szerencsés egy központi tárat fenntartani, ahova mindenki azt szemetel, amit akar, lelassítva ezzel az egész rendszer működését.
Ha pl. csak a Microsoft appok számára lenne fenntartva, mindenki más meg config fájlokat használna, én sem akarnám kihajítani az ablakon a gépemet, mert már megint lassú a win7 (pedig mikor felraktam, még jó volt).
(Viccet félretéve, offtopicolva: gondolom, ennek a jelenségnek nem egyedül a registry az oka, de létezik. Pedig igazán nem sok dolog van telepítve.)

Az hogy az egyik lassít, nem zárja ki azt, hogy a másik is.

Ha kerestél már registry-ben, tudod, hogy az minden, csak nem optimális, hogy minden ott tárol mindent.

Mellesleg nekem a Vista volt minden idők leglassabb Windows-a... és furcsamód egy frissen telepített Win XP és egy frissen telepített Win 7 10x olyan gyorsan végigszaladt a registry-n kereséskor, mint egy frissen telepített Vista regeditje. Utóbbinál látszott, hogy lényegesen több registry-elem van mint a másik kettőnél. De elképzelhető, hogy ebből rossz következtetést vontam le.

Igen, ezt fogják mondani, mert soha nem is használták csak elhitték amit innen-onnan hallottak róla. Akik pedig használták azok gyakran olyan régi gépen amin a Win 7 se menne rendesen.
Semmi baj nem volt a Vista-val korszerű gépen, csak a felhasználók ugyanazon a gépen akarták futtatni amin az XP-t is. Amikor a 7 kijött akkor már jobb volt a helyzet, mert már a gagyi gépek is jobbak voltak.
A memóriaigény tény, hogy sokat javult a Windows 7-re, de nem annyit mint sokan gondolják. Ugyanis a SuperFetch álltal használt memória (tulajdonképpen egy cache) is foglalt memóriának látszott, de ha kellett volna akkor az felszabadítható lett volna. A Windows 7 esetében a SuperFetch kevésbé agresszív és ha jól emlékszem nem is látszik foglalt memóriaként.
(Itt most kitérhetnék a Mojave Experiment-re és hogy a Win 7 inkább csak egy Vista R2, de ennek utánanézhetsz máshol is ha érdekel.)

" brutális memóriaigényét"

Igen, 512M ram kevés volt neki. W7-nek is az, FYI.

" érezhetően lassabb volt "

Volt. Aztán jött az SP1-2. ;) De önmagában nézve a W7 is lassabb, mint az XP (leszámítva pár dolgot, pl. jobb IO kezelés érzésre, hw gyorsított UI, bár egy része már Vista-ban is megvolt.)

MS megmondta, hogy nem a kőkorszaki gépekre szánja, de akinek legalább egy PDC-je volt 1-2G rammal azok érdekes módon nem picsogtak. Ha volt SP1-2, végképp nem.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igazság szerint ez csak egy vaktában lövés volt tőlem, érzésre. Fogalmam sincs, pontosan hogy néz ki az a motor, ami a registry-t hajcsa', így nem tudom, hogy mennyiben számít a mérete. Ha majd egyszer nagyon unatkozom, megpróbálok beletölteni 1-2 giga random adatot, aztán megnézem, mit produkál a rendszer.

"meg lehetne azt legalább olyan korrektre csinálni "

Most akkor jobb a registry vagy sem? :)

"de gyorsabbra és hatékonyabbra midneképpen"

Miután rengeteg beállítás egy számként van tárolva, amelyeket külön élvezet textfilek esetén konvertálgatni ezt erősen kétlem. Szöveget parseolni mindig szívás.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Remek az UI, csak nem jó. Alapvető baja, hogy nem tudok rajta szabályt alkalmazni, nem scriptelhető. Másik baja, hogy nehezen migrálható. Hagy ne nevezzem azt migrálásnak, hogy nézem a szomszéd képernyőt, s ugyanoda teszem a pipát ezen, ahol azon van.

Aztán mondd már meg nekem, légy oly kedves, hol tudom beállítani Windows XP-n, hogy az RTC-ben tárolt időre úgy tekintsen az XP, hogy az UTC idő. Mert erre faszányos GUI megoldást nem találtam, bár nagyon kellett volna! További vicc, bár ez már nem az MS sara, hogy vannak windows-os programok, amelyek talán megkerülve az oprendszert(?), az RTC-t veszik alapul, de azt local time-nak nézik, s pont leszarják, hogy be van jegyezve a registry-be, hogy az RTC UTC-t tárol. Aztán csináljon az ember jól működő dual-boot-os gépet. Hát már hogy a fenébe ne...

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

Attól, hogy van egy ui fölötte, mi akadályoz meg abban, hogy beleturkálj a registrybe scriptből?

UTC-t xp csak hírből ismeri, én is próbáltam úgy használni, de nem érdemes. Nálam állandóan elfelejtette, hogy most UTC-t mutat és visszaállt localtimera, azaz 1-2 órával kevesebbet mutatott időszámítás függvényében. Ezek után szerintem inkább jó, hogy nincs rá gui opció, így sokkal kevesebb ember tapasztalhatta meg, hogy mennyire nem működik. :)

Jogos, amit mondasz. Ugyanakkor a text konfig két dolgot is megvalósít: ember számára jól áttekinthető, ugyanakkor scripttel hekkelhető. Nem igazán értem, minek egy text editornál bonyolultabb GUI konfigurációhoz.

Én is valami hasonlót tapasztaltam. Akkor csak simán bugba szaladtam bele?

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

"ember számára jól áttekinthető, ugyanakkor scripttel hekkelhető. Nem igazán értem, minek egy text editornál bonyolultabb GUI konfigurációhoz."

Kérlek, scriptelj Apache VirtualHost beállításokat...

A hiba ott kezdődik, hogy alapvetően a lustaság az, ami miatt a textfile ennyire elfogadott módszer. Ha az user bele tud túrni a textfile-ba, akkor nem kell UI-t faragni hozzá. Aztán, hogy esetleg hülyeséget ír be a fájlba, mert nem volt semmi, ami megakadályozza, az meg már PEBKAC és "véletlenül sem" tervezési hiba...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Mivel az include előbb oldódik fel, mint a (rész)konfigurációs file értelmezésre kerülne, természetesen ekkor úgy kell hibát keresned, hogy az eredeti fileban megnézed a sorokat az include-ig, kivonod 43-ból, majd a kapott számú sort nézed meg az include-ban. Baromi kényelmes, tényleg.
Amúgy Apache-ot konfigolni még az egyszerűbb esetek közé tartozik, mert legalább jó a dokumentációja.
Én programozóként attól kapok kétoldali áttétes agyfaszt, amikor egy embedded használatra is (azaz nem különálló alkalmazásként futtatva) szánt szoftverkomponens (pl. JMS szerver, HTTP szerver és ilyesmik) saját konfigurációs állományt követel meg, adott néven. Tipikusan a JBossos projektek ilyenek, pl. HornetQ.
Így aztán elesik az a lehetőség is, hogy az alkalmazásodnak 1 konfigurációs forrása legyen.

"Mivel az include előbb oldódik fel, mint a (rész)konfigurációs file értelmezésre kerülne, természetesen ekkor úgy kell hibát keresned, hogy az eredeti fileban megnézed a sorokat az include-ig, kivonod 43-ból, majd a kapott számú sort nézed meg az include-ban. Baromi kényelmes, tényleg."

Mondjuk az a szoftverfejlesztő is menjen inkább kapálni, aki az includeot "szó szerint" hajtja végre egy konfigurációs fájlon. Ha egy c fordító meg tudja oldani, hogy file/sor alakban ad hibaüzenetet, akkor mindenkinek meg kell tudnia oldani. :)

"Remek az UI, csak nem jó."

Arra, hogy te beállíts valamit?

"Alapvető baja, hogy nem tudok rajta szabályt alkalmazni, nem scriptelhető. "

Beállítások importálása/exportálása. Registry is kimenthető spec.

"Másik baja, hogy nehezen migrálható."

Kimenthető.

"További vicc, bár ez már nem az MS sara"

Ahogy mondod: kontárokat ki kellene irtani az IT területéről.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™