Jun 2011
debunking the google webgl FUD
Remekbeszabott böngészőink már ma is - borzasztóan bugos és lassú - operációs rendszerként viselkednek (tessék csak gondolni a saját memóriakezelésre, a JavaScriptben futó x86 emulátorra), ennél fogva én már csak egy fájdalmas félmosollyal viseltetek azt látva, ahogyan az IT-ben manapság tobzódó ostoba faszparasztok a WebGL-t felszopják. Igen, a Google-ös köcsögről lesz szó.
From: Hunger
Date: 2011. június 24., péntek - 3:25
To: hup
Én is írhatnék szép bevezetőt, hogy:
Én vagyok a Google egyik legnagyobb rajongója. Továbbra is úgy gondolom, hogy a Linux jobb, mint az OSX vagy a Windows(*). Bizakodó voltam az Android kapcsán és bizakodok a következő ChromeOS-ben. A Google oldalán álltam a Viacom perben, az Oracle perben és még sok másikban. Szerintem a Gmail jobb ingyenes webmail, mint bármi más, amit használtam. Szerintem a Chrome sokkal nagyszerűbb, mint az Internet Explorer. Nagyon örültem, amikor elkezdődött a Chrome fejlesztése és versengeni kezdett a Firefox-szal.
stb. de inkább nézzük a tényeket:
> Microsoft has never supported OpenGL which is what WebGL is based on. Instead they have their DirectX API. The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in.
Ezzel teljes mértékben egyetértek.
Egészen bizonyos, hogy a Microsoft politikai céloktól - is - vezérelve mond ellent a WebGL-nek. Ellenben nem árt észben tartani, hogy a megfelelő politikai manővereket csak valós alapokra helyezett kommunikációval lehet hatásosan elérni. Azaz attól mert az MS elsődleges indoka politikai jellegű, még nem jelenti azt, hogy az alapvetően politikai célokra felhasznált IT biztonsági probléma csak mondvacsinált hazugság.
Tehát nem érv a WebGL biztonsága _mellett_, hogy a Microsoft csak azért támadja a WebGL-t, mert az nem DirectX-es...
Pont ellenkezőleg. A veszély nagyon is valós, ezért is próbál most a Mozilla és a Google célt érni azzal, hogy a Microsoftot megpróbálja ellehetetleníteni azzal a boszorkányüldözéssel, amely arra hivatkozik, hogy mivel az MS céljai nem teljesen tiszták, ezért a mondanivalója is eleve hazugság.
A valóság ellenben nem ennyire fekete és fehér...
> So, Is WebGL a security risk? IMO no more than any other part of the browser. Remember when IE had issues with specially formed JPG images? That was a bug. It was fixed. Problem solved. Remember when IE had issues with specially formed AVI files? That was a bug. It was fixed. Problem solved.
Úgy tűnik egyrészről, hogy ez a "security bugs to be just normal bugs" fertőző és ész nélkül veszik át Linus Torvaldstól ezt az ostobaságot a fejlesztők. Számára - és egyes burokba zárt fejlesztőknek - lehet, hogy a sebezhetőségek is csupán egyszerű programozási hibák, de a világ többi részén ez elég komoly fejfájást és dollármilliárdokban mérhető veszteséget termelő problémát jelent...
Másrészről a Fejlesztő Úr aranyosan összemossa a 'user space' biztonsági hibákat a 'kernel space' sebezhetőségekkel. Ez különösen aranyos pont egy Chrome fejlesztőtől, aki egy másik bekezdésben erősen ecseteli, hogy a WebGL azért lesz biztonságos, mert külön processzben fut a weblap:
> So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process.
Sajnos hiába fut külön processzben a weblap, homokozóban, megfeszítve, mágiával körbezárva, ráolvasva, töviskoronával a fején, bilincsben... a kihasznált biztonsági hiba nem a sandboxolt 'user space' böngésző alkalmazásban (vagy komponensében) van, hanem egy privilegizált driver kódjában a kernel memóriaterületén, amelyre nem lesz érvényes semmiféle korlátozás.
Ezért is irtó veszélyes átadni a WebGL utasításokat ellenőrzés nélkül a videokártya OpenGL interfacének. Természetesen nem is teszik ezt meg, legalábbis a Chrome fejlesztő szerint:
> The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers
Amiket azonban felsorol - mint validáció - csak néhány ismert hiba "workaround"-ja és nem pedig prevenciós céllal tervezett proaktív biztonsági megoldások... Erre viszonylag egyszerű példa lehet a korábban posztolt Proof-of-Concept WebGL kód, amelytől a kezdetektől elhasal az nVidia és az AMD/ATI driver mind Firefox, mind Chrome böngészők alatt a mai napig.
> Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues
Ez a kijelentés több szempontból sem igaz:
> So what do you do to prevent programs from accessing bugs in drivers? Well, #1 is you test your code and try to make sure it’s bug free.
A drága Chrome fejlesztő itt is csúsztat és összemossa a 'user space' security bugokat a 'kernel space' sebezhetőségekkel. Míg a böngészőt érintő biztonsági problémáknál ő - és az MS - felelősséget tud vállalni a hibákért, tesztelni és javítani tudja azokat, addig a WebGL interfacen át kihasznált video driver hibákat nem tudja azonos szinten feltárni és képtelen közvetlenül nyomást gyakorolni a fejlesztőire (hisz azok más cég - nVidia, AMD - alkalmazottai).
Jó példa erre az AMD/ATI video driver, amelyben köztudottan olyan biztonsági hiba van, amely a Microsoft EMET (Enhanced Mitigation Experience Toolkit) teljes védelmi funkciójának kihasználásakor (ASLR AlwaysOn) kékhalált okoz. Ez a probléma ugyan köztudott hónapok óta, még sincs javítva a mi napig az AMD/ATI video drivereiben...
(*) Lehet, hogy nem jobb minden szempontból, de még mindig inkább tartom biztonságosabbnak grsecurity/PaX és további third-party patchek felhasználása esetén, mint a Windows-t vagy az OSX-et.
Ui.: Tudom, hogy az 'olvasók' jórésze egy egyszerű "tl;dr" hozzáállással fogja honorálni a leírtakat, de legalább nagyjából öszeszedtem a jelenlegi WebGL-el kapcsolatos problémákat. A továbbiakban többet nem kívánok vele foglalkozni és rá időt pazarolni...
From: Hunger
Date: 2011. június 24., péntek - 3:25
To: hup
Én is írhatnék szép bevezetőt, hogy:
- Se a Googlenek, se a Microsoftnak, se más multinak nem dolgozom (vele ellentétben)
- Bármit amit mondok a munkáltatóm véleményét is képviselheti, tekintve hogy biztonsági kérdésekben az én szavamra hallgatnak (vele ellentétben)
Én vagyok a Google egyik legnagyobb rajongója. Továbbra is úgy gondolom, hogy a Linux jobb, mint az OSX vagy a Windows(*). Bizakodó voltam az Android kapcsán és bizakodok a következő ChromeOS-ben. A Google oldalán álltam a Viacom perben, az Oracle perben és még sok másikban. Szerintem a Gmail jobb ingyenes webmail, mint bármi más, amit használtam. Szerintem a Chrome sokkal nagyszerűbb, mint az Internet Explorer. Nagyon örültem, amikor elkezdődött a Chrome fejlesztése és versengeni kezdett a Firefox-szal.
stb. de inkább nézzük a tényeket:
> Microsoft has never supported OpenGL which is what WebGL is based on. Instead they have their DirectX API. The DirectX API is great but the #1 reason Microsoft doesn’t want to support anything based on OpenGL is that it robs them of some of their lock-in.
Ezzel teljes mértékben egyetértek.
Egészen bizonyos, hogy a Microsoft politikai céloktól - is - vezérelve mond ellent a WebGL-nek. Ellenben nem árt észben tartani, hogy a megfelelő politikai manővereket csak valós alapokra helyezett kommunikációval lehet hatásosan elérni. Azaz attól mert az MS elsődleges indoka politikai jellegű, még nem jelenti azt, hogy az alapvetően politikai célokra felhasznált IT biztonsági probléma csak mondvacsinált hazugság.
Tehát nem érv a WebGL biztonsága _mellett_, hogy a Microsoft csak azért támadja a WebGL-t, mert az nem DirectX-es...
Pont ellenkezőleg. A veszély nagyon is valós, ezért is próbál most a Mozilla és a Google célt érni azzal, hogy a Microsoftot megpróbálja ellehetetleníteni azzal a boszorkányüldözéssel, amely arra hivatkozik, hogy mivel az MS céljai nem teljesen tiszták, ezért a mondanivalója is eleve hazugság.
A valóság ellenben nem ennyire fekete és fehér...
> So, Is WebGL a security risk? IMO no more than any other part of the browser. Remember when IE had issues with specially formed JPG images? That was a bug. It was fixed. Problem solved. Remember when IE had issues with specially formed AVI files? That was a bug. It was fixed. Problem solved.
Úgy tűnik egyrészről, hogy ez a "security bugs to be just normal bugs" fertőző és ész nélkül veszik át Linus Torvaldstól ezt az ostobaságot a fejlesztők. Számára - és egyes burokba zárt fejlesztőknek - lehet, hogy a sebezhetőségek is csupán egyszerű programozási hibák, de a világ többi részén ez elég komoly fejfájást és dollármilliárdokban mérhető veszteséget termelő problémát jelent...
Másrészről a Fejlesztő Úr aranyosan összemossa a 'user space' biztonsági hibákat a 'kernel space' sebezhetőségekkel. Ez különösen aranyos pont egy Chrome fejlesztőtől, aki egy másik bekezdésben erősen ecseteli, hogy a WebGL azért lesz biztonságos, mert külön processzben fut a weblap:
> So what does Chrome do to keep WebGL safe? #1, like everything in Chrome, we run the webpage in its own process.
Sajnos hiába fut külön processzben a weblap, homokozóban, megfeszítve, mágiával körbezárva, ráolvasva, töviskoronával a fején, bilincsben... a kihasznált biztonsági hiba nem a sandboxolt 'user space' böngésző alkalmazásban (vagy komponensében) van, hanem egy privilegizált driver kódjában a kernel memóriaterületén, amelyre nem lesz érvényes semmiféle korlátozás.
Ezért is irtó veszélyes átadni a WebGL utasításokat ellenőrzés nélkül a videokártya OpenGL interfacének. Természetesen nem is teszik ezt meg, legalábbis a Chrome fejlesztő szerint:
> The other is that the GPU process validates EVERYTHING!!!! before calling the GPU drivers
Amiket azonban felsorol - mint validáció - csak néhány ismert hiba "workaround"-ja és nem pedig prevenciós céllal tervezett proaktív biztonsági megoldások... Erre viszonylag egyszerű példa lehet a korábban posztolt Proof-of-Concept WebGL kód, amelytől a kezdetektől elhasal az nVidia és az AMD/ATI driver mind Firefox, mind Chrome böngészők alatt a mai napig.
> Silverlight 5, that provides the EXACT SAME FEATURES with all the same issues
Ez a kijelentés több szempontból sem igaz:
- A Silverlight nem az OpenGL interfacét használja (ezt egy másik - korábbi - kijelentésében ő is elismeri, így ezt az állítását eleve önmaga cáfolja: DirectX for Silverlight). A DirectX-et a Microsoft fejleszti, az OpenGL interfacet viszont közvetlenül a video driver fejlesztői "biztosítják", amely közel sincs biztonsági szempontból annyira auditálva és körbejárva, mint a DirectX.
- A Silverlight nem önmagában adja át az alacsony-szintű utasításokat a video drivernek, hanem van egy wrappere, amely feldolgozza a kéréseket és a megfelelőnek ítélt hívásokat adja át a DirectX-nek, amely további ellenőrzéseket végez, mielőtt továbbítaná a video drivernek. (Ellenben a WebGL esetében, amely az egészet nélkülözve a video driver OpenGL interfacenek adja át közvetlenül a hívásokat)
- A Silverlight egy extra plugin, amely külön épül be - vagy nem épül be - a böngészőbe. A WebGL-t azonban alap funkciónak szánja a Google és a Mozilla és a jelenlegi verzióikban már alapértelmezetten bekapcsolva is található, veszélybe sodorva ezzel a felhasználóikat.
> So what do you do to prevent programs from accessing bugs in drivers? Well, #1 is you test your code and try to make sure it’s bug free.
A drága Chrome fejlesztő itt is csúsztat és összemossa a 'user space' security bugokat a 'kernel space' sebezhetőségekkel. Míg a böngészőt érintő biztonsági problémáknál ő - és az MS - felelősséget tud vállalni a hibákért, tesztelni és javítani tudja azokat, addig a WebGL interfacen át kihasznált video driver hibákat nem tudja azonos szinten feltárni és képtelen közvetlenül nyomást gyakorolni a fejlesztőire (hisz azok más cég - nVidia, AMD - alkalmazottai).
Jó példa erre az AMD/ATI video driver, amelyben köztudottan olyan biztonsági hiba van, amely a Microsoft EMET (Enhanced Mitigation Experience Toolkit) teljes védelmi funkciójának kihasználásakor (ASLR AlwaysOn) kékhalált okoz. Ez a probléma ugyan köztudott hónapok óta, még sincs javítva a mi napig az AMD/ATI video drivereiben...
(*) Lehet, hogy nem jobb minden szempontból, de még mindig inkább tartom biztonságosabbnak grsecurity/PaX és további third-party patchek felhasználása esetén, mint a Windows-t vagy az OSX-et.
Ui.: Tudom, hogy az 'olvasók' jórésze egy egyszerű "tl;dr" hozzáállással fogja honorálni a leírtakat, de legalább nagyjából öszeszedtem a jelenlegi WebGL-el kapcsolatos problémákat. A továbbiakban többet nem kívánok vele foglalkozni és rá időt pazarolni...
kind of scary videogame
2011/06/17 17:58 Category: games
gnu fucking grep
-rw------- 1 root wheel 12245 May 20 09:40 file1.txt
-rw------- 1 root wheel 15220 Jun 10 16:59 file2.txt
# time grep -f file1.txt file2.txt > /dev/null
5.32s user 0.02s system 99% cpu 5.354 total#!/bin/sh
for i in `cat file1.txt`; do grep $i file2.txt; done
# time sh ize.sh > /dev/null
0.84s user 2.38s system 120% cpu 2.678 total
YAHB
2011/06/14 09:06 Category: foss
yetanotherhupban: „ieorgjp” felhasználó hozzáférése blokkolt vagy még nincs aktiválva (természetesen újabb
meanwhile at linux
http://www.gossamer-threads.com/lists/linux/kernel/1390308
[ lwn ]
“Shut up unless you have any real arguments.”
Linus to PaXTeam, 2011
Here’s an argument for you:
witcher 2
2011/06/02 19:11 Category: games
Amelyik játékot nem lehet letenni, az remekmű (Dragon Age: Origins). Amelyiket egyszer, az egy merőben újszerű játék, ámde - éppen ezért - remekmű (Witcher 1). Amelyiket kétszer is le lehet, az viszont egy szar (Witcher 2) ...
Mondhatni kemény vagyok, de legalább igazságtalan. Manapság, amikor a közepesen/jól sikerült folytatások ritkábbak mint egy stabil linuxos filerendszer, a Witcher 2-t különösebb kritika nem érheti, lévén a legtöbb területen sikerült az előző részt pozitívan felülmúlni (gfx), vagy legalább a szintjét hozni (map, hangulat, questek). Ami gyökeresen más, az az előző részben sok embert elbátortalanító harcrendszer.
Ennek megváltoztatására látszik, hogy jelentős súlyt fektettek: a harc sokkal “óvatosabb” és taktikusabb lett. Ez akár még jó is lehetne, de nem az. Sikerült ugyanis agyoncsapni a játékot egy borzasztóan körülményes (clunky) karaktermozgással, és ezzel a Witcher 1-ben - végül - módfelett megkedvelt pörgő-forgó kombós gyilkolászás (mégiscsak egy mutáns gyilkológépről van szó) helyét egy féllábú, kezdő társastáncos csetlő-botló bénázása vette át.
Console-friendly... Meh.
Bármilyen mozgást is végez Geralt, az kivétel nélkül borzasztóan lassú, és az előző résszel szemben menet közben megváltoztathatatlan. Ehhez nagyon hasonló volt a változás például a Thief és Thief 3 kapcsán, utóbbi - többek közt - szintén azon vérzett el, hogy a szögletes irányítás miatt megszakadt a játékos és a főszereplő közötti immerzió.
Végeredményben egyetértek a Metacritic-en negatív/közepes értékelést adó játékosokkal (plusz lásd GOG fórum), akik szintén ezt emelték ki. Hozzá kell tenni azonban, hogy a Witcher 2 nem rossz játék, természetesen sokkal-sokkal jobb mint a borzalmas Dragon Age 2, valamint bizonyos, hogy a játék végére sokkal jobb véleménnyel leszek róla. Ehhez viszont harmadszorra is el kéne kezdeni játszani vele, jelenleg azonban a Gateway, a Deja Vu vagy az Ultima 7 is jobban vonz.
Witcher 1 > Witcher 2. “If it ain’t broke, don’t fix it.”
UPDATE: azóta már vagy hatodszorra is letettem. Sajnos minden fejlesztői igyekezet ellenére (illetve éppen azért) ez a játék szar.
UPDATE: voice-over sucks
Mondhatni kemény vagyok, de legalább igazságtalan. Manapság, amikor a közepesen/jól sikerült folytatások ritkábbak mint egy stabil linuxos filerendszer, a Witcher 2-t különösebb kritika nem érheti, lévén a legtöbb területen sikerült az előző részt pozitívan felülmúlni (gfx), vagy legalább a szintjét hozni (map, hangulat, questek). Ami gyökeresen más, az az előző részben sok embert elbátortalanító harcrendszer.
Ennek megváltoztatására látszik, hogy jelentős súlyt fektettek: a harc sokkal “óvatosabb” és taktikusabb lett. Ez akár még jó is lehetne, de nem az. Sikerült ugyanis agyoncsapni a játékot egy borzasztóan körülményes (clunky) karaktermozgással, és ezzel a Witcher 1-ben - végül - módfelett megkedvelt pörgő-forgó kombós gyilkolászás (mégiscsak egy mutáns gyilkológépről van szó) helyét egy féllábú, kezdő társastáncos csetlő-botló bénázása vette át.
Console-friendly... Meh.
Bármilyen mozgást is végez Geralt, az kivétel nélkül borzasztóan lassú, és az előző résszel szemben menet közben megváltoztathatatlan. Ehhez nagyon hasonló volt a változás például a Thief és Thief 3 kapcsán, utóbbi - többek közt - szintén azon vérzett el, hogy a szögletes irányítás miatt megszakadt a játékos és a főszereplő közötti immerzió.
Végeredményben egyetértek a Metacritic-en negatív/közepes értékelést adó játékosokkal (plusz lásd GOG fórum), akik szintén ezt emelték ki. Hozzá kell tenni azonban, hogy a Witcher 2 nem rossz játék, természetesen sokkal-sokkal jobb mint a borzalmas Dragon Age 2, valamint bizonyos, hogy a játék végére sokkal jobb véleménnyel leszek róla. Ehhez viszont harmadszorra is el kéne kezdeni játszani vele, jelenleg azonban a Gateway, a Deja Vu vagy az Ultima 7 is jobban vonz.
Witcher 1 > Witcher 2. “If it ain’t broke, don’t fix it.”
UPDATE: azóta már vagy hatodszorra is letettem. Sajnos minden fejlesztői igyekezet ellenére (illetve éppen azért) ez a játék szar.
UPDATE: voice-over sucks
java + ipv6
2011/06/01 06:32 Category: IT
piece of shit
“What really needs to happen is to port the Windows approach in the JVM to BSD. On Windows two sockets are created per ServerSocket; one for IPV6 and another for IPv4. This avoids the need to use v4mapped addresses and change the net.inet6.ip6.v6only sysctl.”
UPDATE: do not use the diablo java
“What really needs to happen is to port the Windows approach in the JVM to BSD. On Windows two sockets are created per ServerSocket; one for IPV6 and another for IPv4. This avoids the need to use v4mapped addresses and change the net.inet6.ip6.v6only sysctl.”
UPDATE: do not use the diablo java