IT megmérettetés és DevOps

Közösségi kerekasztal

Van ez az IT megmérettetés, tolja még valaki közülünk?

7 kategóriában vagyok, ebből 2 kicsit általánosabb programozással kapcsolatos: szoftvertechnológia és devops. A szoftvertechnológia még egész jó, a devopsban van pár dolog, amitől igencsak nagyot néztem. Mondok pár példát korábbi feladatokból.

Mire lehet automatikus tesztet írni? Bejelöltem, hogy arra is, hogy a kód nem fordul le, szerintük ez rossz. De már miért ne lehetne? Vagy azt nem tesztnek hívjuk? Nálunk a CI rendszerben van olyan teszt, ami azt nézi, hogy egy adott library vagy valami fordul-e.

Mik a TDD jellemzői? Bejelöltem többek között, hogy a hiba nem a kód hibája, hanem nem lett rá teszt írva. Szerintük rossz, de miért? Minden bugra ráfogható, hogy rossz tesztek miatt van, illetve én pl. minden hibajavítást repro teszttel kezdek. Vagy azért rossz, mert ez nem a TDD jellemzője, hanem valami másé? Másrészt szerintük helyes válasz, hogy a teszteseteket jóváhagyja a megrendelő. WTF, ilyen tényleg van?

Mikor refaktorál a programozó? Az én válaszaim és a helyes válaszok között nem sok a korreláció. Szerintük pl. hibajavításkor, de szerintem a refaktorálás nem változtatja a viselkedést, a bugfix pedig igen.

Hát úgy gondolom, ebben a devopsban elég sok a bullshit, meg az olyan ajánlás, ami a való életben nem teljesen/nem mindig úgy van.

  • 2544 megtekintés

( zeller | 2019. 10. 17., cs – 20:10 )

Máshol is vannak khm. vitatható dolgok... Az egyik aktuális feladatot "üresen" küldtem be, mert hiába tudom, mit kéne a megadott fájllal csinálni, de nincs a gépemen telepítve a szükséges app, úgyhogy nyaljanak sót :-P

( Jason v | 2019. 10. 17., cs – 23:11 )

"Mire lehet automatikus tesztet írni?" == "Mit tud a junit?" :D

"Szerintük pl. hibajavításkor, de szerintem a refaktorálás nem változtatja a viselkedést, a bugfix pedig igen."
Szerintem 100% neked van igazad: "Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior." (wiki Code_refactoring)

Nem is emelek ki többet, jól kivesézted. Elég megnézni a kiemelt támogatókat, vicc.

( E-Medve v | 2019. 10. 17., cs – 23:24 )

Ugyanezeket a "hibákat" követtem el én is a DevOps kategóriában. :-)

Tesztesetek vs. megrendelő: szerintem itt az acceptance tesztre gondolhattak, mert az kizárt, hogy minden unit teszttel rohangálnának az ügyfélhez/megrendelőhöz.

Sok esetben a feladat/kérdés nyelvezete van elrontva. Én például nagy naívan jelentkeztem az IT Security témakörre is. Sajnos eddig elég messze van a korábbi évek Hacking témakörétől, az inkább ilyen manageres dolog.

Én idén is 10 kategóriában indultam, de van már pár olyan, amiből jövőre inkább nem kérek.

Mondjuk az is megér egy misét, hogy írtam nekik 2 emailt - a legelsőt 2 hete -, de eddig még semmi reakció. Szóval kicsit úgy tűnik, hogy az első két évben meg lelkesek voltak.

Security: egyet értek, ilyen rizikó elemzéssel meg mittudoménmivel hagyjanak már :). Azért valamennyire kisakkoztam az eddigieket. A mostani 4. kör viszont kifejezetten érdekes volt.

Nekem a 7-ből a 6 elég jól megy, ami nagyon gáz, az a Python. Mert hogy ez igazából nem alap Python programozás, hanem NumPy és Pandas. Úgyhogy aki ismeri konkrétan a libraryt, annak sima ügy, aki nem, az így járt, mert 10 perc alatt még utánaolvasással se fog menni.

Egyszer írtam nekik emailt, jött rá automatikus válasz, hogy ticket készült belőle, aztán jött igazi válasz is. Hibás volt egy pontozás és javították.

De az említett DevOps kategóriában nem fogok vitát indítani, annyira vitatható néhány kérdés, hogy nincs is egyértelmű válasz. Van a programozásnak egy művészet része, azt nem lehet keretek közé szorítani, és azt mondani, hogy azt csak így vagy úgy lehet megoldani. A DevOps mögött olyannyira nincsenek még szilárd alapok, hogy maga a szó devops fogalom jelentése is sokszor vita tárgya, a HUP-on főleg :).

( gelei v | 2019. 10. 18., p – 09:58 )

- "Milyen hiteles forrásokra támaszkodhatunk, ha egy sérülékenységről részletes információkat szeretnénk megtudni?"
- Twitter ("Mindegyik")
- False

Hat oke, gondolom a vendor altal kozze tett CVE nem eleg hiteles/reszletes.

( gelei v | 2019. 10. 18., p – 10:10 )

Security: itt egy google drive link, tolts le onnan egy .rar-t

Erre csak az lenne elfogadhato magyarazat, hogy a feladat valojaban az, hogy nem szabad rakattintani a honeypotra. En pl. itt engedtem el a kategoriat.

( csabka v | 2019. 10. 18., p – 15:01 )

Valószínű nem a verseny szervezőkön múlik, hanem a hitelesítőkön aki vállalta, hogy kitalálja a kérdéseket, válaszokat. Amúgy biztos mindenki jobb kérdéseket tudna írni, hisz mindenki ért a focihoz _is_ Mo-n :-).
Aki csak itt puffog és nem a hivatalos csatornákon jelez vissza (érvényes ez szoftverek bugreportjaira is...), annak nem lesz semmi következménye, javítása.
Amúgy az IT közösség mindig is egymástól, egymás hibájából tanult, így nekem belefér, ha hiba van, csak vizsgálják ki. Az megint egy másik kérdés, hogy ugyan azt a hibát hányan jelzik és hányan tudják feldolgozni :-D bizonyára itt lesz némi szűk keresztmetszet. Én is jeleztem egy hibát, kaptam is választ hogy türelem vizsgáljuk.

Egyébként a fenti kérdést én is amikor először néztem elgondolkodtam mit is tanultam annó erről, mert mind pro mind kontra érvekkel ki lehet állni mellette is és szemben is.
Sajnos több kérdés is volt idén _is_ ami nem 0 / 1 hanem 0,5, amit ha akarom ide ha akarom oda kerekítek.

1. Automatikus tesztet bármire lehet írni, valószínű itt a TDD/BDD módszertanra kérdez rá, amit kódolás közben a fejlesztő folyamatosan futtat pl kódmódosításakor. Az ilyen tesztnek nincs értelme, ha nem fordul le a kód vagy szintaktikai hiba van és az IDE már visít, hisz akkor nincs mit tesztelni.

2. A hibajavításkor egyébként kimondottan javasolt, hogy teszt esetet kell létrehozni a hiba előidézésére, majd miközben megkezded a hibát javítani, akkor refaktorálj, hisz az eddig teszt esetek amik elvileg 100%-os lefedettséget adnak biztosítanak arról, hogy a refaktorálás végén a refaktorált kódrészlet úgy fog működni ahogy eddig, de a hiba nélkül. Feltétel persze, hogy nem legacy kód és a teszt esetek valóban a kód fejlődése előtt bővültek nem pedig utólag.

Szűk keresztmetszet: a számokból kb. látszik, hogy évről évre kb. ugyanannyi a jelentkező az egyes kategóriákban (értsd: nincs 10x szorzó, de sok helyen még 2x sincs). Ehhez képest az első két évben volt reakció 1-2-3 napon belül. Most még egy automata válasz sincs.

Az egyik észrevételem egyébként az volt, hogy egy pedagógiai szempontból normális checkbox kérdésnél legalább 1, legfeljebb N-1 lehetőség a helyes. Tehát pedagógiailag hibás a feladat, ha nem kell pipálni semmit. Ellenben az már helyes, ha be kell pipálnod az "Egyik sem" opciót. Ugyanígy pedagógiailag hibás, ha mindet végig kell pipálni. Ott illene lenni egy "Mindegyik" pipálható opciónak ilyen esetben.

( gelei v | 2019. 11. 01., p – 20:25 )

Na most ugye az 5-6-7. fodulot “biztonsagi okokbol” (lol) csak egy meghatarozott idoablakban lehet megcsinalni.

Az otodik fordulonal belepni sem sikerult mar, ugy le volt terhelve a szerver, majd nem sokkal kesobb erkezett az email, hogy egy csunya gonosz csiter megdosolta a szervert, tonkreteve ezzel masok jatekat.

A hatodik fordulonak ugy alltunk neki, hogy mar a CloudFlare vedte a jatek tisztasagat, guess what, error 522, timeout. Kivancsian varom, mi lesz a magyarazat.

(ha valaki olvassa onnan ezt a kommentet: az nem DDoS, hogy szandekosan betereltetek az osszes jatekost egy 20 perces idokeretbe)

Ez igy eleg cringe, le is iratkoztam, nehogy artson az image-emnek a ket bukott fordulo okozta deficit a tabellan.

Az ötödik fordulónál is volt már CloudFlare, legalábbis én 1 hete onnan kaptam 520-522-524-et vegyesen.

Ha jól emlékszek, akkor indulásnál közölték, hogy melyik kategóriában hány induló van. 10 kategóriára jelentkeztem, 9 kategóriában 250-570 fő, a Szoftvertechnológiában nekem 1000-es szám dereng. Lehet, hogy ezt az 1000-es számot már nem bírja a jelenlegi rendszer.

A hatodik fordulónál a kérdéssort nagynehezen kiköhögte a CloudFlare, de hogy sikeres volt-e a submit, az már más kérdés... 2 perc tekerés után kaptam egy 524-et.

Érdekes, nálam egy-két szám kicsit eltér, talán a leiratkozások miatt: IT sec (565), SWtech (998), web (491).

Illetve kiegészítésül: frontend (351), python (551), unity (167), a jövő programozója (821). Ez utóbbinál külső domainen vannak a feladatsorok, ami jobban állja a sarat.

( zeller | 2019. 11. 01., p – 21:18 )

Nekem sikerült egyik témából más fontos dolog miatt lemaradni, egy másikról meg hasonló gondok okán, úgyhogy leíratkozás nálam is megvolt... :-/

( egeresz | 2019. 11. 01., p – 21:29 )

A múltkori (5. forduló, okt. 25 péntek 20:00 ) -nél az volt az érzésem, hogy a rendszer elérte a teljesítőképessége határát. Nem ddos jellegűen halt meg, hanem normál túlterhelésjellegűen. Most (nov.1 péntek 20:00) nem tapasztalható az ok, ugyanis egyszer sem volt reszponzív az oldal. (pontosabban 20:03 táján bejelentkezni be tudtam, de pár másodperccel rá a rendszer elesett).

Úgy néz ki, hogy a fejlesztőjük/üzemeltetésük a user oldali (böngészőben implementált) dolgokban otthon van, de a szerver oldalban elég gyengus. Fizetnek egy CDN szolgáltatást (cloudfare) az oldja meg minden teljesítményigényt. (nem fogja).

Nézzünk pár régi trükköt a megbízhatóság növelésére!

- valami CDN megoldás (ezük van, ugorjunk)
- a bejelentkeztető egy önnálló domain, van benne állítható limit, hogy hány usert engedje be. Nem dependál sem az arculati oldal, sem a verseny oldal működésére
- A versenyoldal a 'submit' gomb esetén letárolja az adatot. Akkor is, ha elmúlt a 10 perc. Lehetőleg valami olyan helyre, ahova bőszen lehet írni. (független a feldolgozó DB-től) ez azért kell, hogy elvi lehetőség legyen az értékes adatok utólagos  kinyerésére, ha elesett a DB
- A log nem tartalmaz névfeloldást. Semmi nem végez hálózatfüggő névfeloldást. (sem ldap, sem bind)
- DB backendet meg kellene tolni. Egyrészt programozó oldalról (lockok hogyan is vannak, van-e long query) másrészt DB admin oldalról (ott van-e index, ahol kell, táblaterek hogyan vannak) harmadrészt rendszergazda oldalról (dedikált DB gép, elég-e a memória, SSD van-e alatta, hogyan is van a DB cluster, nem véletlenül péntek este 8-kor indul a heti full backup?)
- A verseny oldal másik domain, másik vas, mint a ithon.info. Az egyikre beeső terhelés ne egye el a CPU-ját a másiknak.
- Itt most nem jelentkezett, de nem ártana, ha a versenyoldal minden kiszolgált elemét (összes js, összes css, összes font) saját kézben lévő szerver adná. Az is elég arcvesztés, ha egy harmadik féll összedőlése miatt áll a verseny.

Egyébként —ha csak nincs valami algoritmukusan elszúrva, amikor is "n" konkurens felet deadlockol a DB— egyszerű és nagyszerű segítség a DB táblaterét (adatfájljait) berakni egy frissen vásárolt NVMe storage cardba. Néha az is segít, ha leállítod a multi-master DB replikát :-)

 

egyébként köszi a blogbejegyzést, így legalább nem indítok másikat.

Akkor ezek szerint nem csak nekem tűnt fel, hogy jellemzően a péntek esti finálé fordulókkal van para. :-)

Érdekes módon a hétfő-kedd-csütörtök fordulóknál maximum egy picit megemelkedett az oldalbetöltés, de annyi.

Egyébként egész jó kis listát szedtél össze.

Most volt a szoftvertech pótforduló, megin' túlterheltnek tünik a rendszer.

Nagyon sokáig tartott a feladatlap betöltés (20 sec).

A feladatlap elküldés is (1-2 perc!)

Viszont most nem dobott ki időtullépés miatt, ezekszerint reszeltek az időtúllépés-ellenőrzésen. Jó.

Befogadta a beküldésemet, hurrá.

Nekem azt dobta, hogy "Már korábban kitöltötted a tesztet.", utólag megnéztem a "megoldásaimat", a 2., 3. és 5. feladatokat "elrontottam", meg "állítólag" majdnem az összeset. (Ez az eddigi helyes válaszok százalékos arányának ismeretében vicces.)

A probléma csak annyi, hogy ezek a kérdések korábban már szerepeltek Devops, Szoftvertechnológia és Weboldalkészítés témakörben és ott hogy-hogynem helyeset küldtem be. Jeleztem feléjük, roppant kíváncsi leszek a végeredményre. Érdekes, hogy ez a Szoftvertechnológia témakör ennyire mumus.

Azt írta a noreply@ithon, hogy

A ma esti fordulót ismét ellehetetlenítette a kedves "barátunk", pedig az új feladatokkal is igyekeztünk humorral kezelni valakinek a furcsa zavarát, ebbe sok energiát beleölve. Elküldhetnénk a "pokolba", de szerintem ő már ott van. A harag olyan, mintha egy pohár mérget innál annak reményében, hogy a másik fog meghalni, így ez most részünkről elmarad. Inkább hálát adunk, hogy ennyi fejlődni akaró, a tudására sokat adó ember választja a játékot, ezzel is jó példát mutatva egy olyan ágazatban, ami ma a világot leginkább mozgatja. Tegyetek így ti is.
Pontosan hogyan kezeljük erről rövidesen küldünk információt egyeztetve a partnerrel. Újabb pótforduló már biztosan online nem lesz, mivel a díjátadóig erre már nem lesz idő, de valamilyen kreatív megoldással fogunk előállni.
 

( persicsb | 2019. 11. 14., cs – 06:54 )

Az egész játék valódi célja fejvadász adatbázis építése, így várjatok ettől bármi minőséget. 

( gelei v | 2020. 09. 17., cs – 16:29 )

Szerkesztve: 2020. 09. 17., cs – 16:31

Apa, kezdődik! :D

Jött az email, hogy lehet regisztrálni.

  1. Regisztráltam.
  2. "Sikertelen bejelentkezés"
  3. Oh, meg kell erősíteni az emailt, jogos. Megerősítem.
  4. "Sikertelen bejelentkezés"
  5. Talán rossz jelszót írt be a Chrome jelszókezelő? Megpróbálom kézzel.
  6. "Sikertelen bejelentkezés"
  7. Jelszó visszaállítás, ezúttal kézzel kitöltve.
  8. "Sikertelen bejelentkezés"
  9. szerk: Ismét jelszó visszaállítás, ezúttal mellőzve a számokat és nagybetűket.
  10. Siker.

Hát jó.

nyilván nézzük, ha egy reg. lukra fut, de azért több mint 1800-nak sikerült. Az emailben pedig ment szeptember közepén az értesítő szöveg az előreggel együtt, hogy mikortól lehet Kategóriát választani. Már lehet 21+1-re.

 

Adatlopás, és fejvadász "elcsábítás": már 3 éve megy. Meg lehet kérdezni, kit kerestünk meg állás ügyben aki ehhez külön nem járult hozzá vagy nem maga kérte. Elsőként javaslom ezt a kb. 240 embert https://ithon.info/blog/2019/12/12/ok-az-orszag-legjobb-it-szakemberei-… a kategória és név alapján egy jó részük megtalálható közösségi oldalon. Aki egyiküket sem ismeri, hát...  Persze ez nem azt jelenti, hogy nem lehet állás szempontból következménye. Többekről tudjuk, hogy ma máshol dolgoznak, a korábbi többszöröséért a versenynek köszönhetően. De ez nem egy levadszós játék, de nyilnán munkáltatói márkaismertség növelés szempontjából a cégeknek egy jó szakmai lehetőség. Az vesse rám az első követ aki szerint nem jobb, hogy ilyenen keresztül megmutatja a cég a sajátosságait, mikkel foglalkoznak, vagy betekintést mutat a gondolkodásukba (nyilván nem mindenki) és  helyette nem azzal akar különbözni, hogy másmilyen színű a sosem használt babzsákfotel és milyen saját névre szóló sört kínál.

 

Nevezési díj: A visszatérést és újboli bizalamt ingyen nevezéssel honoráljuk. Aki visszatér, már tudja mit kap, és jó eséllyel végigjátssza. Az a játékos köszönjük nem kell, aki benevez mindegyikre és annyira veszi komolyan, hogy szinte semennyire nem játssza végig. Így a helyezéseket teszi nem kellően hitelessé. Tavaly volt először fizetés: akik fizettek nevezési díjat 95% vigigjátszotta, aki nem 71%. 

( pulaygellert | 2020. 10. 13., k – 14:48 )

Sziasztok! Beleállok személyesen a kritikákba. :-)

Tavaly sajnos tényleg megtörtént a Ddos, több ízben és tényleg egyes kategóriák fordulóit ellehetetlenítette. Mondhatnánk a fene gondolta, hogy valaki ebből csinál szórakozást, hogy mások játékát elrontaja. Hiba volt erre úgy tűnik nem eléggé felkészülni, illetve azt feltételeztük, hogy aki alvállakozóként bevállalta, a tudás birtokában van, ettől még a felelősség az enyém. 

Nem szerettem volna ezzel lezárni, bár elhihetitek sok bosszúságot okozott a játékosoknak, a legtöbbet én őszültem. ezért nyilván idén lesz ismét, az üzemeltetést másra bíztuk és a blog elején felvetett dolgokra üzeni a DovOps-os:

  • Amazon Cloudfront-on át lehet elérni a szerverünket
  • Amazon WAF védi
  • aki megtalálja a szerverünket (plusz pont nem jár érte) azt kitiltjuk
  • a szerveren mod_qos utasítja el a D/DoS kéréseket
  • nagyon vékony az API-nk, sok száz kérést kibír
  • a frontend egy VueJS SPA, ami CDN-ről töltődik be

A DDoS egy dolog, viszont mikor írtam levelet valamelyik kérdéssel kapcsolatban is napokig tartott bármilyen reakció, szóval hiszi a piszi :D

Jahh az ilyenekről nem is beszélve, mikor a verseny végén még kap egy ilyet az ember, miután megírták hogy benne vagy a 20ban :D

Sajnos az utolsó előtti pillanatban történt pontmódosulások miatt (pl. a szakmai hitelesítő által elfogadott kérdéses feladat), a tárgyban megnevezett szektorban lecsúsztál a TOP20-ból.

Mind1 ebből 3 részvétel bőven elég vót :>

Fedora 41, Thinkpad x280

Jogos. Van a versenynek egy érdekes sajátossága: beleállunk minden olyan szakmai kérdésbe, amit egy játékos vitat. Mindegyikbe. Tavaly több ezer üzenet jött. (néhány tucat kérdésben, de mégis ugye több százan beküldték) Ennek így is kell lennie, mert milyen már, ha egy feladatra a választ máshogyan is meg lehet közelíteni, és így más is lehet helyes, mint amit a feladatíró legjobb tudása szerint gondolt és ezért ne ismerjük el, ha igaza van a vitatott kérdést beküldőnek. Nem csak elismerjük, hanem mi több az: "Akinek mindig igaza van" különdíjjal az agilis, több látószögből váló látásmódot hozzáállást még díjazzuk is. 

Na már most - és igazából ettől lesz szakmailag hiteles és nagy presztizsű a verseny - volt olyan JAVA feladvány tavaly, amikor az Oracle hivatalos dokumentációját javították ki utólag az észrevétel miatt, és az Oracle külön állásfoglalást tett, mert a feladatíró cég beküldte az észrevételt nekik. És a játékosnak igazat adtak...ja, csak hetekkel később. 

A te konkrét eseted ha jól emlékszem Beágyazott C-ben volt, és a konkrét cég, külön csapattal ült össze a kérdést megvitatni. Csak nehezen ült össze a "konzílium" Melyik lett volna korrekt: 1. a játékos nem kap pontot mert elhúzódott a bírálat pedig igaza volt és érdemtelenül lett valaki egy bizonyos helyezett 2. bár nekünk kellemetlen volt, mégis újraszámoltuk a pontokat az adott kérdés miatt, és így pont te lecsúsztál a legjobb 20-ból. 

Én döntöttem így, Te hogy döntöttél volna a helyemben?

Szóval mindenki kap választ, de olykor hetekig is eltarthat döntés.

Idén azért feladtuk a leckét annak aki a nevezett különdíjra pályázik, mert sok szűrőn mennek át a kérdések.

Külön köszönöm azoknak, akik korrektül és kedvesen fogalmazzák meg a kérdéseiket ez ad kedvet a későbbiekre is. És azt sem bánjuk, ha előbb utánajársz a kérdésnek teljesen és csak utána küldöd be, mert úgy a 80%-a a beküldött leveleknek végül visszautasításra kerül, mert nem jogos.

Az nem lett volna megoldas, hogy nem top20, hanem - mondjuk - top22 van az adott kategoriaban, kifejtve, hogy miert? (esetleg ha a top20 is kapott valami kezzelfoghato dijat, megkerdezni a szponzorokat, hogy hajlandoak-e meg beletenni egy picit)

Egyebkent IOCCC-n kulon kategoria van a szabalyok sajatsagos ertelmezesere, a hackthissite-on meg bonuszpontot kap, aki az oldalt magat feltori. Szoval ez a kulondij jo otlet, es nem annyira szokatlan, mint elsore latszik. KoMaL-nal (legalabbis amikor versenyeztem, akkor ugy volt) minden feladat 5 pontot er, de masodik megoldasert lehet +3 bonuszpontot kapni. Egyszer nekem is sikerult, tul lazan volt megfogalmazva egy geometriai pelda, bebizonyitottam ugy, ahogy ok ertettek, aztan adtam a masik ertelmezes szerint egy ellenpeldat.

A strange game. The only winning move is not to play. How about a nice game of chess?

lett helyezése, csak nem a top20-ban (ők voltak meghívva a díjátadóra). Bónuszpontot meg nem jó, ha adunk, mert attól, hogy nem reklamált, mert sejtette, hogy más is beküldi, azért ő nem kap pontot. Akkor abban érdekelt, hogy minden hülyeségre írjon, az meg nem érdekünk, mert ilyenkor jön amikor minden logikát megerőszakolva küld be nem életszerű magyarázatokat. Persze meg fogom ezeket nézni, mert mindig jók az új tippek.

Tuti nem jól emlékszel mert sose indultam, vagy akármilyen programozási feladattal, csakis network meg linux admin. 

A kérdések voltak szarok, főleg linux-nál. Mert én is észrevettem, hogy 1-1 problémát többféleképpen meg lehet csinálni/oldani, jól. Viszont pontot csak 1 re adtatok. Így ez nekem kicsit visszatetsző volt már akkor is, de mondtam üsse kavics. Aztán még végén is változik a pontozás :D Ami ha azt nézzük elindulok egy versenyen amin megvannak a szabályok, aztán a végén változik a szabály, mindenesetre érdekes :>

Fedora 41, Thinkpad x280

Bocsánat, ha a kategóriára nem jól emlékeztem. Nem a pontozás változott, hanem a helyes megoldások elfogadása. Nehézségtől függ, hogy összes helyes választ fogad csak el, vagy elég csak 1, de nem zárja ki, hogy van több. Vannak érvek egyik és másik ellen és mellett is.

 Nem a pontozás változott, hanem a helyes megoldások elfogadása.

Ami végül is a pontozáson látszott meg ;>

Nem az olyan kérdésekre gondoltam, ahol már eleve írták, hogy több válasz lehetséges, hanem mikor 1 válasz volt lehetséges, de a probléma megoldása erősen subjektív, és ki így ki úgy csinálná meg.

Mind1 hagyjuk is, régen volt igaz se volt ...

Fedora 41, Thinkpad x280

Jó pár éve ismerem személyesen Gellértet és jószándékú pozitív szemléletű. Szerintem ez is vezette rá, hogy keressen -ahogy írta is- egy "win-win" szituációt számunkra szakembereknek.

Nekem tetszettek az eddigi évek verseny feladatai a kezdetleges hibái ellenére és azt merem állítani, hogy a színvonal is egyre jobb lett. Kevesebb probléma volt, ha volt is valami szerintem időben meghozott vállalható döntések születtek.

Persze mindenben _is_ lehet hibát találni és sajnos társadalmi alaptermészet a fujjolás.... minden esetre jó, hogy van ez a verseny! 
Volt olyan feladat (HUP-os "on topic" is legyen :-D) a Linux kategóriában, amiből tanultam is, mert ebben a kontextusban nem találkoztam még sparse fájlokkal ( lastlog fájl mérete miért lehet pl ~100 Gb).