Elindult a Refaktor Magazin

Mozgalmas pár napon vagyok túl, megnyomtuk a gombot a Refaktor Magazinon, végre online, és van is rajta tartalom. Nem sok, 6 cikket sikerült végül összehozni, de ez is több, mint a semmi. Jövő héttől heti egy cikk, és heti egy talk videó megy ki remélhetőleg.

A hosszú távú cél az, hogy megtaláljuk a magyar piacon azokat a cégeket, akik szeretnének tenni azért, hogy az egyetemi / OKJ-s oktatáson túl is legyen olyan tartalom és lehetőség, amivel az ifjú titánok fejlődni tudnak. Nyilván esélytelen, hogy egy komplett oktatási tananyagot össze tudjunk rakni, de erről nincs is szó, szerintem elég érdekes dolgokról írni, és ez önmagában motiváló lehet azoknak, akik tanulni akarnak.

Meglátjuk, mit hoz a jövő. Cikkek, ötletek, kritika jöhet a kommentekben. :)

Hozzászólások

A .single #content szélességét vedd kisebbre nagy felbontáson, fárasztó ilyen hosszú sorokat olvasni.

A cél ugye az, hogy minél több olvasó legyen? Mert akkor a dizájnert le kéne önteni egy vödör hideg vízzel, hogy magához térjen: a fehér alapon halványszürke szöveg egyrészt rosszul olvasható, másrészt valahogy a 2000-res évek elején volt divatban.

Amúgy csak így tovább!

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Egy apró megjegyzés a Low level debugolás cikkhez. Írod:

"Azok a függvények, amiket a kernel módban futó rendszermag (avagy: a kernel) biztosít számunkra, rendszerhívásoknak nevezzük. Ilyen rendszerhívások például a file megnyitás (fopen), hálózati kapcsolat nyitása (connect), stb."

Az fopen() és a connect() sem syscall.
Pl. az fopen() a standard c libraryben van megvalósítva, így a rendszerhívás vagy rendszerhívások (int, svc, ...) majd ott történnek meg. Az open() viszont syscall.

A connect nem syscall. Sőt az open sem az, abban az esetben, ha a forrásban inklúdolod (c/c++ példánál maradva) a megfelelő headert, mert ilyenkor maga a header mögötti library (akár dinamikusan lesz jelen (.dll, .so), akár statikusan belefordul (.a)), mint afféle wrapper "közted" és a kernel között, fogja a tényleges syscall-(oka)t megvalósítani oly módon, hogy az adott függvényben (pl. open), beállítja a regisztereket a megfelelő argumentumokkal (az adott cpu/soc architektúrára jellemző abi/eabi-nak megfelelően) és meghívja a syscall-t. A syscall maga az a gépi kódú utasítás, amelynek hatására megtörténik a privilégium-szint váltás. Ez az utasítás x86 esetében az int gépi kódú utasítás, míg arm esetében svc (swi) utasítás, etc.
Így valódi, "kézzel hívott" syscall hívást az a felhasználó használ manapság, aki assemblyben ír programot, feltéve, hogy nem használ semmiféle libet.

Nezd, a manpage azt mondja, hogy syscall, es a straceban is megjelenik, es ami definiciot en talaltam, aszerint "System call is the services provided by Linux kernel.". Hacsak nincs mas is amit syscallnak hivnak, sztem a connect egy syscall. Az, hogy van egy azonos nevu libc hivas, a cikk szempontjabol nem lenyeges.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

A 3 oszlop legfelul, legyen inkabb 2 oszlop es a "veremcsere" kerdeseket hozd fel egyik oszlopnak.

Az ok egyszeru: a cikkek majdnem statikusak
(egy kinn van egy hetig minimum es nem valtozik),
mig a veremcsere lenne a lenyege az oldalnak (ha jol veszem ki),
es dinamikus is (nap kozben tobbszor valtozik).

Az ember olyan, hogy ranez valamire, ahh, ez megegyezik az elozovel,
nem fog lejjebb gorgetni.

A nepszeru elferhetne ez alatt (a veremcsere kerdesek alatt).

De persze ez csak javaslat, meg a szokasos duma.
Nekem nem faj jobban, akarhogy is csinaljatok...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Kedden este a sörözésen eszembe sem jutott: nem úgy volt, hogy találtatok valami stackoverflow szerű valamit? Igazából azt nagyon hiányolom szinte mindenhonnan.

Kisebb update: kiment az elso heti cikk, ugy tunik, a heti 1 tarthato lesz. A talkokbol vagy heti egy lesz, vagy ha sok jon be, akkor heti 2.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

Ezeket a cikkeket mennyire nézitek/nézetitek át? Nyelvhelyesség, helyesírás szempontjából sajnos eléggé sok baj van velük (az elfogadható átlagnál sokkal több, elég fájdalmas hiba van benne). Úgy gondolom, nem árthatna erre is adni egy kicsit.