Flame

Kérdés adott: ki hogyan fordítaná magyarra, úgy, hogy az eredeti jelentéstartalma is megmaradjon és kifejező is legyen?

SZERK: Egy nagyon fontos dolgot elfelejtettem az éjjel: alapvetően SVC-k által használt repository-kra gondoltam.

Az itteni topik, kommentek olvasása közben egyre kevésbé értem, mi a "desktop".

Úgyhogy akkor szerintetek:

Mitől lesz a számítógép, rendszer, használat desktop.Vagyis, mi a desktop definíciója?

Megmondom mi van.

Továbbra sem értem, hogy az interneten egy szakmai portálon mi a leborult szivarvégnek szaladgálnak önjelölt Grétsy Lászlók valamint az eufemizmus tüzes kardhordozójaként véresen szétoffolva - jaj ez így nem magyaros - akarom mondani szétbaszva - jaj ez most minősíteni fog engem - szóval teljesen oda nem illően beleböfögve egy akármilyen hozzászólást, topikot, blogbejegyzést.

Mert, kérem szépen.

• Ezek a fajta tartalmak nem fognak szerepelni Magyar Országos Levéltárban, nem fognak bekerülni a himmnuszba, és nem fogják tanítani az iskolában, és nem fogják befolyásolni Magyarország diplomáciai kapcsolatait. Amennyiben mégis lesz erre igény - pl. „Mit mondott takemeaw jevgenyijnek a mainframe topikban a 123-as hozzászólásban?” Akkor vagy beteszik eredetiben, megcsillagozva, lefordítva vagy egy ügyes kezű lektor majd kivasalja az éleket a mondatokon.
• Mivel még csak nem is szépirodalmi műnek készülnek - azért érdemes lenne fellapozni pár Arany, Petőfi és társaitól pár érdekes elbaszást - szóval nincs értelme, hogy a kedves nácik nyelvük éles fésűjével próbáljanak rendet vágni benne. Ah', a művészi szabadsághoz mindenkinek joga van, nemcsak nektek majmoknak. Pláne egy blogban.
• Kedvenc mondatuk: ez téged minősít. Igen, és? Egy embert rengeteg minden minősít, ettől leszünk különbözők. Ha valaki lilára festi a haját vagy bazdmegez beszédközben, vagy szájszaga van: az is hozzá tartozik: Ő ilyen. Így szokta meg. Ő ilyen. Ó, hogy ez rossz? Szerintem meg az a rossz, hogy nem tudjuk elfogadni a másikat. Nem kötelező elovasni-végigolvasni egy helyesírásoktól hemzsegő bejegyzést, hozzászólást. Nem kötelező véleményt nyilvánítani. Inkább nevessetek bazdmeg, mint nyilvánosan eret vágjatok és utána saját pöcsötöket mutogatjátok.
• Bármilyen furcsán hangzik a rossz nyelvtani használat, a rossz helyesírás NEM intelligencia függvénye. Erre hivatkozni ennek hiányára utal. (Éne már láttam olyat, mikor a nem magyar anyanyelvűt máglyára ítélték mert nem ment neki a fűt-tűt-fát-füvet.) Arról nem is beszélve, hogy rengeteg olyan helyzet van amikor azért sírdogálnak, hogy diszgráfiás és az ekezetnelkul író miért fórumozik, él egyáltalán. Az viszont szerintem intelligencia kérdése ha valakinek gondot okoz a legtöbb esetben mégiscsak feldolgozni egy ilyen szöveget. (Jellemző példa: 20-an válaszoltak rá (= megértették), de jön valaki akit felháborít, hogy kamilyon.)
• A magyar nyelv szépségére hivatkozni meg igen vicces a bejövő hunglish szavak irritáló volta miatt, elég csak a gázrezsó, gázpedál, sparhelt, csákány, tehén szavainkra gondolni. Ja, hogy az már irodalom és történelem? Akkor ha már itt tartunk gondoljunk az artézi kútra meg egy magyar mesére. Vagy a doménre, hogy mi kell a népnek.
• A vidékre mutogatni, hogy onnan jön a sok köcsög nyelvromboló, hogy is mondjam elég vérlázító. Még jó, hogy a Józsefvárosban mindenki a bölcsészkaron fog végezni - cum laude.
• Nos. A másik dolog, hogy ezen a portálon nagyrészt van lehetőség felvenni emberkékkel kapcsolatot valamilyen módon, ezért az a helyes metódus ha látjátok hogy xy a blogbejegyzésébe irdatlan sok/nagy helyesírási hibát vét akkor ILLIK ott jelezni neki, nem pedig sziporkázóan velős off szálat indítani és visszajárni, azt táplálni ahelyett, hogy a témához valamit érdemben sikerüljön hozzászólni. Mert ez az igazi parasztság és faszmutogatás, nem pedig a muszály. Az vicces. Ti meg nem.
• 2 lehetséges ok van amikor mégis érdemes valakit kijavítani, ha szorosan kapcsolódik az általa felvetett/hozzászólt témához.
  (pl. Mikor zár be a Non-Stop a Blahán? vagy A kernel letörölte a webcamot.)

Htx.

[Ps: A topik címét a nagy sikerű TROMA film a Surf Nazies Must Die - http://www.youtube.com/watch?v=bWvAtqhuiI4 - inspirálta, szóval nem kell komolyan venni.]

Lesz ebből a jó kis cuccból vajon egyszer az életben kiadott stabil verzió? Vagy marad az svn, cvs meg build scriptes hegesztős miegymás...? Nem értem, hogy miért nem lehet egyszerűen kiadni, úgy mint ahogy azt a többiek is teszik. Akik jobban benne vannak a témában, használják napi rendszerességgel meséljenek már, hogy mi folyik mostanság az e17 project körül.

Köszönöm, üdv!

Kezembe került 2005 ös prog okj vizsga kérdéssora és megoldókulcsa,

nektek mi a véleményetek? :P

Ja meg:

Amúgy rendes jó megoldások is jöhetnek ide.

udv!

jonehany ismerosom keresett mar meg mindenfele dologgal, pl forum spammelessel, jelszo feltoressel, keylogger alkalmazasaval/irasaval (persze mindenki megmagyarazza, hogy miert akarja). legutobb kb 5 perce

ti hogy kulditek el oket a ***** anyjukba? volt mar valakinek ilyennel dolga? hogyan magyaraztatok el, hogy bakker, ilyet nem kellene?

Van itt néhány régi hír:
2003
Román antivírus céget vásárol a Microsoft
A Microsoft felvásárolta a RAV AntiVirus fejlesztőjét
2005
A Microsoft vírusirtó céget vásárol

Ezzel végül is kezdett valamit a Microsoft?
Vagy "csak" a Windows Defender és a Microsoft Windows Rosszindulatú szoftvert eltávolító eszköz
lett az eredmény?

Egy ilyen nagy támadásnak kitett és laikus felhasználóknak szánt operációs rendszerbe igazán beépíthetne a Microsoft valami hatékony realtime vírus és spyware védelmet.
Tudom elég sok antivírus "megoldás" létezik, de ez is csak azt bizonyítja, hogy a Windows operációs rendszer önmagában elég sebezhető és nagyon kevés szolgáltatást nyújt, ha például összehasonlítjuk a ...

Sziasztok!

Egy igen kedves lelkületű, de ismeretlen személy létrehozott egy gmail fiókot. Ezzel a fiókkal feliratkozott jópár nagy forgalmú levelezőlistára, hírlevélre, majd a gmail fiók levelezését ráirányította egy ismerősöm fiókjára. Így gyakorlatilag percenként kap több száz számára spamnek minősülő levelet.

Lehet ezt a google felé jelezni valahol, mert pillanatnyilag semmi elérhetőséget nem találtam ezzel kapcsolatban?

Sajna a konkrét leveleket még nem láttam, mert a gép messze van tőlem, csak telefonon próbálok segíteni. A módszert viszont kipróbáltam a saját fiókjaimmal, és működik. :(

Sziasztok.

Ma arra keltem hogy két szervermen lévő (win 2003 és egy linuxoson is) összes index.php végén az alábbi kód volt beletéve:

http://hup.pastebin.com/f228a77b7

Tehát egy linuxos apache-os kiszolgálón, és egy win2003 IIS-es kiszolgálón lévő weboldalak index.php-je végén volt ez a kód, egyik pillanatról a másikra.

Mi okozhatta? Total Commander ? vagymi ?

A legutóbbi Solaris bejelentés kapcsán menetrendszerűen előjött, hogy bezzeg a Solarisban mennyire jó a stabil API, és Linuxban mennyire gáz, hogy folyamatos szívás van a változó API-k instabil implementációival.

Én azt nem tudom, hogy hogyan lehetne másképpen csinálni a Linux esetében? Mert egy alapvetően kereskedelmi rendszernél tudom a megoldást. Kell néhány tökös architekt, akik szép szóval - korbáccsal terelgetik a fejlesztőket a helyes irányba.

Linuxnál odáig könnyű eljutni, hogy "legyen jól megtervezett, stabil API". Csak utána a megvalósítási javaslatok el szoktak akadni.A probléma nagyon sokrétű:
- kultúra (cowboy-kódolás, "worksforme", "már csak tesztelni kell")
- technológia (nagyon sok architektúra, nagyon sok támogatott hardver, ... etc.)
- tesztelők kevesen vannak, és csak nagyon korlátozott konfigurációkon tesztelnek
- kevés kód review
- elégtelen fejlesztőeszközök
- nagyon sok ágon, sok irányba folyik a fejlesztés, az egyetlen minimális kohéziós erő a "mainline-ba kerülés" célja
...stb.

Ugyanakkor látszik, hogy a Linux ipar gyakorlatilag ehhez a helyzethez adaptálódott: a felhasználókat használják béta tesztelőnek
- "stabil" kernel kiadások pár havonta
- kb. félévente "stabil" Ubuntu, Fedora, OpenSuse kiadások, ahonnan a kitesztelt feature-ök bekerülnek az "enterprise" változatba)

Ha visszanézünk a kernelfejlesztés történetére:
2.0-nál azt mondtuk, várunk 2.0.5-ig, mielőtt felrakjuk.
2.2-nél talán 2.2.10 volt a mondás?
2.4-nél, ha jól emlékszem ez még tovább tolódott. Emlékszem olyanokra, hogy majd 2.4.30-nál...:)

Ez azt is jelentette, hogy egyre kevesebben használtak fejlesztői kernelt, ezért egyre kevésbé voltak kitesztelve, közben egyre nagyobb mennyiségű kódot kellett volna tesztelni.

Erre volt válasz a külön "fejlesztői fa" megszüntetése. Persze a felhasználó nem hülye, és most már elég ritkán van arra szükség, hogy maga fordítgasson kernelt, tehát ő használja a disztribútorok kerneleit. Ergo a vanilla kerneleknek megint kicsi a tesztbázisa, a disztribútorok tesztkapacitása véges, tehát megint a végfelhasználók fogják tesztelni...

Ezen csak több QA erőforrással lehetne segíteni, de:
-a QA néhány megszállott embertől eltekintve tipikusan "fizetett munka" jellegű tevékenység
-a cégek saját QA erőforrásaikat nyilván a saját érdekeiknek megfelelően vetik be, és nem a vanilla kernel feature by feature tesztelésére
-nincs túl nagy hagyománya az automatizált teszteknek a kernelfejlesztők körében, az LTP nekem édeskevésnek tűnik.
- elsőként el kéne dönteni, hogy _mit_ akarunk tesztelni, és mikor tekintjük a tesztet sikeresnek...egyik sem triviális
- ezt a tevékenységet valamilyen non-profit, de anyagilag jól támogatott szervezetnek kéne koordinálnia, pl. Linux Foundation. Egyelőre nem látni túl nagy mozgást ezen a téren.

"Jól megtervezett API-k":
API tervezésnek több módja van, lássuk hogyan működik ez Linux esetében (vigyázat, a következő rész erős iróniát tartalmaz):
1. Bizottság alapú:
- követelményeket gyűjtünk: ezeket az emaileket senki nem olvassa el, ha konferenciát szervezünk, arra kb. 5 ember jön el, akikkel egyébként is egyetértünk
- összerakjuk az API-t, kiküldjük reviewra: most kapunk 3 kommentet, amiből 2 a névkonvenciónkat vitatja, 1 pedig felhívja a figyelmet néhány nyelvtani hibára a kommentekben.
- implementáljuk: mire idáig eljutottunk, Gipsz 23 Jakab egyetemi hallgató már összehackelt egy megoldást a problémára, ami ugyan nem olyan jó mint a mienk, de már van 10 másik felhasználó, és ezerrel lobbiznak, hogy az övék kerüljön bele a kernelbe.

2. Evolúciós alapú:
- gyorsan eljutunk worksforme szintre
- ezerrel nyomjuk a marketinget (LWN cikk havonta a minimum :) )
- belobbizzuk a mainline-ba, amint már 1 architektúrán nem Oops-ol.
- ha egy másik architektúra/alrendszer/driver jön, hogy ez náluk így nem fog menni / lassú lesz / nem így kéne, akkor szétflameljük őket
- amig ők a flametől égő sebeiket nyalogatják, gyorsan összedobjuk a v2-t az API-ból, ami néhány dolgot javít a jogos észrevételek közül. Persze a lényeget nem.
- mivel már a mainline-ban vagyunk, v2 pikk-pakk bekerül (Andrew Morton morog egy kicsit, de senkit nem érdekel mit mond)
- ezzel egyidőben bejelentjük, hogy a current + 1 -es verziótól a v1-et nem támogatjuk, mindenki portoljon v2-re.
- ...

Mivel tudjuk, hogy a Linux esetében jelenleg kizárólag a 2. verzióval lehet eredményt elérni (akik az elsőt próbálták, nagyrészt még mindig out of tree patchként tengetik életüket), és fentebb illusztráltuk, hogy ez félkész kódokat / rossz API-kat eredményez, szerintem jobban járunk, ha nem próbálják a rossz API-kat bebetonozni, és 10+ éven át támogatni...

Persze, ha valaki rájön, hogy hogyan lehet gyorsan, jó és időtálló API-kat tervezni, amelyek kiscsillió architektúrán/hardver eszközzel működnek, egymásnak ellentmondó követelményeknek felelnek meg (embedded vs. enterprise), és Gipsz 23 Jakab egyetemi hallgató, valamint Xi Huan junior szoftverfejlesztő is képes őket használni, akkor szerintem nagyon sokan imába foglalják majd a nevét...

Nektek mi a véleményetek?

Üdv,
Gergely