Állítólag kiszivárgott a Windows XP forráskódja; a biztonsági szakértők már rá is cuppantak

Microsoft, Windows

Állítólag más operációs rendszerek kódjával egyetemben kiszivárgott a 4chan-ra torrent formájában a Windows XP SP1 / Windows Server 2003 forráskódja. A gyűjtemény mérete 43 GB-ra rúg.

A gyűjtemény tartalma:

  • MS DOS 3.30
  • MS DOS 6.0
  • Windows 2000
  • Windows CE 3
  • Windows CE 4
  • Windows CE 5
  • Windows Embedded 7
  • Windows Embedded CE
  • Windows NT 3.5
  • Windows NT 4

A torrentben található egy könyvár, amiben Bill Gates-ről találhatók konspirációs teóriás videók. A publikáló szerint a Windows XP forráskódja már évek óta kering privátban egyes hackerek közt. A Microsoft még nem erősítette meg a kiszivárgott anyag valódiságát.

( trey | 2020. 09. 25., p – 08:39 )

> Tamas Boczan: No, 2.93GB. The 42GB seems mostly junk to me. MS patents and some random conspiracy theory videos.

>> DEY!: You downloaded the entire thing? the 42 gb one?

trey @ gépház

( ssikiss | 2020. 09. 25., p – 08:55 )

A DEY! képen van egy "Windows 10" kezdetű csomag is.

( asch v | 2020. 09. 25., p – 08:58 )

Egy kis olvasnivaló hétvégére. Úgysem volt programom.

Ez nem azt jelenti feltétlenül, hogy hulladék a kód. Épp azért van ott, hogy a hívó függvény ezzel legyen tisztában. Mivel általában nem egy függvény old meg egy publikus API-t, ha minden egyes hívásnál ellenőrzünk mindent, az rettenetesen sok performance-t visz el feleslegesen.

Hasonló példa: C standard library-ban tudtommal egyetlen str* függvény sem ellenőrzi, hogy az argumentum nem NULL-e? Megtehetné, de minek? Legyen vele tisztában az, aki hívja.

Layered architektura eseten valoban leteznek olyanok, hogy mondjuk a rendszer hatarain ellenorizzuk a prekondiciok megletet. Onnantol kezdve a belsobb retegek mar vedettnek szamitanak. Nem tornek landzsat egyik megkozelites felett sem. 

Ha mindenki ellenorzi a prekondiciokat, akkor a prekondiciok esetleges valtozasat az egesz stack-en vegig kell verni, es ha hibaznak, akkor inkonzisztens lesz a cucc (nyilvan ezt is lehet azert okosan csinalni, hogy ne legyen a dolog nagyon redundans).

Viszont vedd figyelembe, hogy a prekondiciok ellenorzese nem mindig konnyu. Pl. kicsit problemas nem rekurziv mutexek eseten a mutexek allapotara vonatkozo prekondicio.

Az en velemenyem az, hogy inkabb az a fontos, hogy minden esetben jol definialt legyen, hogy mik a feltetelek, amik menten mukodik a rendszer, es ezzel tisztaban legyen az, aki dolgozik vele es epit ra.

Microsoft Windows SMBv3 Remote Code Execution Vulnerability (CVE-2020-0796)

On March 13, a POC was published on GitHub that explained how “CVE-2020-0796 is caused by a lack of bounds checking in offset size, which is directly passed to several subroutines. Passing a large value causes buffer overflow, and crash the kernel. With further work, this could be developed into a RCE exploit.

😔

trey @ gépház

Szerintem nem értetted meg a korábbi hozzászólásokat.

A kezdő hozzászólásodból az jön le, hogy szerinted alapból rossz, ha egy bármilyen fv nem ellenőrzi le a paramétereit.

Amit meg itt linkelsz, az arról szól, hogy egy kívülről jött data validságát nem ellenőrzi az OS (itt network-ön jött adatról van szó, de lehet bármi más is, OS hívás).

Ez a kettő tök más.

Az teljeses normális lehet, ha egy (nem API) fv nem ellenőrzi le a paramétereket (és ez ráadásul dokumentálva is van). Mivel lehet, hogy a paramétereket már egy felsőbb réteg ellenőrizte, ezért felesleges minden fv-ben újra és újra ellenőrizni. Nem beszélve arról, hogy egy csomoó olyan eset van, amikor nem is lehet ellenőrzni a validságot, mivel nincs meg minden info hozzá a fv-ben.

Egyébként az adott idézet is valami ilyesmiről szól: nem ellenőrzi a kód az offsetet, és ezt adja tovább fv-eknek. Valszeg nem az összes fv-ben (aminek tovább van adva az adott offset) kell ellenőrzni az offset validságát, hanem csak 1x, mielőtt az adott fv-eket meghívná az offset-tel.

Mellébeszélés. Az "assume" szó nem azt jelenti, hogy "nem ellenőrzöm, mert felsőbb réteg már ellenőrizte", vagy "ellenőrizve xy helyen (hol?)" hanem azt jelenti, hogy "nem ellenőrzöm, mert feltételezem érvényes".

Ez egy vicc.

trey @ gépház

Fogadsz egy vendéget. Beengeded a házba, a ház egy objektum van két bejárata. Minden egyes szoba előtt elkéred a személyiét tőle ismét, hogy ellenőrizd, hogy valóban az jött-e át egyik szobából a másikba, akinek mondja magát? (Különösen, ha az objektum, ami átjön immutable)

Nem azt mondtam, hogy sehol nem kell prekondiciokat ellenorizni. En azt mondtam, hogy definiald a belepesi pontokat a rendszeredbe, es kulonitsd el, hogy mi az, aminek kell ellenorizni (belepesi pontok) es mi az (vedett retegek), aminek nem. Ez egyszeru munkaoptimalizacio kerdese. Megteheted, hogy a kodod mindenhol ellenoriz, de ez rengeteg melo, es ezert semmifele tobbletet nem kapsz ahhoz kepest, hogy felelosen tervezel es toredek erofeszitessel megcsinalod a dolgodat. Es nem, nekem nem azzal az *egy szem* nullptr ellenorzessel van bajom, mert nekem a munkam soran nem egy parametert kell kezelnem.

Azzal az ervrendszerrel meg nemigen tudok mit kezdeni, amikor valaki egy "protected" layerben futo fuggvenyt gepiesen atmasol mashova es felhasznalja a kontextus megertese nelkul. Az csak a maga darwin dijat soporheti be. Ez olyan, mintha egy osztalynal onkenyesen megvaltoztatnad a public/private hozzafereseket es elvarnad, hogy az osztalyod helyesen mukodjon. Hat megis miert van lathatosagi megkulonboztetes? Tobbek kozott azert, mert vannak olyan fuggvenyek, amik a prekondiciokat nem allitjak helyre megfeleloen, ezert nem akarjuk oket hozzaferhetove tenni, hogy ne lehessen hibakat vedeni.

Hát azért nem egészen; az konkrétan többször is elhangzott - sőt innen indult - hogy nem kell a pointereket (vagy akármit) validálni, validálja az, aki hívja...az eredményt a CVE-k százai mutatják. És mindezt a teljesítmény nevében. Talán ha nem lenne annyira lassú az egész kód, akkor nem kéne azon rugózni, hogy spóroljuk meg azt a pár órajelet, amibe a validálás többnyire kerül.

Oldschool Computer - http://oscomp.hu

Pontosan erről beszéltem; nem - az egyébként amúgy is elspórolt - egysoros validálásoktól lassú ez a sok szemét program, tehát teljesen felesleges a teljesítményre hivatkozni a validálás elbliccelése kapcsán...

Oldschool Computer - http://oscomp.hu

pedig eléggé igaza van a kollégának. Aki nem tud asm vagy C kódot írni az jobb lenne ha nem nyilatkozna.

haha mindjárt jön egy proci tervező kolléga és mondani fogja, hogy fogjam be a pofámat ha nem tudom fejből az ARM mikrokódját lol...

na mindegy, egy fos rendszernek kiszivárgott a fos kódja.

GPLv3-as hozzászólás.

> Hasonló példa: C standard library-ban tudtommal egyetlen str* függvény sem ellenőrzi, hogy az argumentum nem NULL-e? Megtehetné, de minek? Legyen vele tisztában az, aki hívja.

Szomorú. A paramétereket minden esetben validálni kell. Ha írok valamilyen segédfüggvényt, a függvényen belül is ellenőrzöm a pointerek érvényességét. Akkor is, ha ez egy "internal" függvény, amit csak az én rutinjaim hívogatnak és azokban ugyanúgy le van validálva átádás előtt, hogy NULL-e, vagy sem. Ha ezt kihagyom, akkor az bug és az én saram. Miért? A kódújrahasznosíthatóság miatt. Ha felhasználom a segédfüggvényt másutt és ott a hívóban elfelejtem levalidálni a pointert, akkor ha NULL happenz, nem a közkedvelt és kriptikus ?LOAD ERROR segmentation fault üzenetet fogom visszakapni a prompton, hanem egy kontrollált hibakódot a programban és nem kell debuggolni, rögtön tudom mit kúrtam el.

Oldschool Computer - http://oscomp.hu

Ha felhasználom a segédfüggvényt másutt és ott a hívóban elfelejtem levalidálni a pointert

Hát nem szabad elfelejteni. :)

De viccet félretéve, szerintem oké az, hogy egy függvény pontosan egy dolgot csinál csak - pont a kódfelhasználás miatt. A validációra is csinálhatsz egy segédfüggvényt, ami semmi mást nem csinál a validáláson kívül.

> De viccet félretéve, szerintem oké az, hogy egy függvény pontosan egy dolgot csinál csak - pont a kódfelhasználás miatt. A validációra is csinálhatsz egy segédfüggvényt, ami semmi mást nem csinál a validáláson kívül.

Exception WTF has occurred...

Lécci mondd, hogy vicceltél, hogy az egy darab NULL-checket szervezzem ki segédfüggvénybe a függvényből; te most tkp. azt javasoltad nekem, hogy ez helyett:

int putbyte(char *ptr, char b)
{
	if (ptr == NULL)
	{
		return 1;
	}
	*ptr = b;
	return 0;
}

csináljam ezt:

bool invalid_ptr(void *ptr)
{
	return ptr == NULL;
}

int putbyte(char *ptr, char b)
{
	if (invalid_ptr((void *)ptr))
	{
		return 1;
	}
	*ptr = b;
	return 0;
}

Ennek mi értelme van?

Az "egy dolgot csinál" nagyon nem azt jelenti, amit te gondolsz.

Oldschool Computer - http://oscomp.hu

A kiinduló állítás nekem a screenshot volt, azt meg benéztem, hogy közben leszűkítettük a témát egyetlen konkrét validációra. Igazad van, a pointer != NULL-ra valóban nem kell külön függvény, haladjunk már. :)

Azt továbbra sem tartom problémának, hogy segédfüggvények (a screenshoton látható módon) nem végeznek olyan szintű logikai validációt, hogy az input "legitimate value"-e.

> benéztem, hogy közben leszűkítettük a témát egyetlen konkrét validációra

Szerintem nem vagy vele egyedül.

> Igazad van, a pointer != NULL-ra valóban nem kell külön függvény

Miért egy intervallum validációra, vagy egy egyezéses validációra kell?

> haladjunk már. :)

Nézzenek már oda, ROFL...

> Azt továbbra sem tartom problémának, hogy segédfüggvények (a screenshoton látható módon) nem végeznek olyan szintű logikai validációt, hogy az input "legitimate value"-e.

Tuti? Itt van pont egy azzal kapcsolatos sérülékenység...
Apropó, mennyi lett volna ezt levalidálni? Egy plusz if ebben a kódban? Micsoda erőforráspazarlás...oh, muh performance...

Oldschool Computer - http://oscomp.hu

Nem tudok ennyire éles határvonalakat húzni. Azt mondanám, hogy ami validáció nem triviális vagy úgy gondoljuk, hogy változhat vagy több helyen is szükség van ugyanarra a szabályrendszer szerinti validációra, akkor kiszervezném. Ennyi. Hogy valami beleesik-e valamelyik kategóriába, arra meg ott a józan ész.

Sőt, számíthat a projekt mérete is: dolgoztam olyan kódbázison, amibe több száz fulltime developer tolta bele a kódot - nyilván itt más megközelítést érdemes alkalmazni, mint egy pársoros scriptben. Én azt mondom, hogy ha van egy jól felépített (mielőtt random CVE-ket linkelsz, ez szükséges feltétel!) architektúra, akkor nem kell minden egyes pontján végrehajtani ugyanazokat az ellenőrzéseket.

Nyilván, ha nem tudod, hogy a függvényed sorsa mi lesz, és lehet, hogy összevissza hívogatja majd minden a nagyvilágban, akkor ja, ellenőrizd az inputot. Vagy ne, mert pl. az is lehet egy teljesen jó megközelítés, hogy a függvényed dokumentáltan exception ágra is futhat, aztán majd a hívó fél kezd vele, amit akar. Vagy lehet, hogy referentially transparent (erre btw van magyar szó?) függvényeket akarsz, mert mondjuk cache-elni akarod az input->output párokat, ott pláne nem javasolt helyben végezni az érdemi hibakezelést, mert az RT-ness miatt sokszor elég korlátozottak a lehetőségeid.

Egy plusz if ebben a kódban? Micsoda erőforráspazarlás...oh, muh performance...

Bevallom, a random idelinkelt sebezhetőségekkel és bugokkal nem nagyon foglalkoztam, mert C-ben csak nagyon minimálisan kellett dolgoznom eddig. Design patternekről tudok beszélgetni, de a C nyelv rejtelmeit hadd ne kelljen most megismernem. :D

Mindenesetre volt olyan munkám, ahol egy szimulációt kellett (tök azonos inputokkal) lefuttatni rengetegszer, órákban volt mérhető a különbség amit az ilyen tizedmásodperces feladatok átcsoportosításával le lehetett faragni. Nyilván itt jön be az, amit az előbb mondtam, hogy rendesen dokumentált környezetben dolgoztunk, nem kellett attól aggódni, hogy a százmillió task mellé elindít valaki még százmilliót nullpointerekkel meg február 30-ával.

> Azt mondanám, hogy ami validáció nem triviális vagy úgy gondoljuk, hogy változhat vagy több helyen is szükség van ugyanarra a szabályrendszer szerinti validációra, akkor kiszervezném.

Ez rendben is van, de te itt komplex dolgok validációjáról beszélsz, azt nyilván érdemes kiszervezni, már csak azért is, mert ha "központilag" van a validátorod, akkor nem fogod elkövetni azt a hibát, hogy a validálás N ponton történik, de ebből X ponton hibás, mert typo... Viszont itt nem ilyen szintű dolgokról volt szó, hanem olyanokról, mint azon a bizonyos screenshoton, ahol a validáció kb. kimerült volna egy db if-ben, ill. a segédfüggvényeknek átadott pointerek NULL-checkjéről, ami dettó kb. egy sor.

> Én azt mondom, hogy ha van egy jól felépített (mielőtt random CVE-ket linkelsz, ez szükséges feltétel!) architektúra, akkor nem kell minden egyes pontján végrehajtani ugyanazokat az ellenőrzéseket.

Hogyne! De ez akkor azzal is jár, hogy a kóderek betartják az írott és íratlan konvenciókat és a kód a 0. sortól az utolsóig auditálva van. Úgy nyilván csak a bejövő, ill. menet közben keletkező adatokat kell validálni. Csakhogy nem ez szokott lenni. És ilyenkor jön be a jobb félni, mint rákefélni. A screenshoton linkelt figyelmeztetés helyett is beírhatták volna azt az egy sornyi lekezelést és preventálhatták volna a belinkelt CVE-t. Ott sem volt meg az az integráltság, amiről te beszélsz.

> az is lehet egy teljesen jó megközelítés, hogy a függvényed dokumentáltan exception ágra is futhat, aztán majd a hívó fél kezd vele, amit akar.

C-ben exception? Ott olyan nincsen, csak crash, meg egyéb nem várt következmény. Ha exception alatt azt értetted, hogy hibakódot ad vissza, az oké, de akkor csak neked kell lekezelned a dolgot.

> Bevallom, a random idelinkelt sebezhetőségekkel és bugokkal nem nagyon foglalkoztam, mert C-ben csak nagyon minimálisan kellett dolgoznom eddig.

Random...? Pont az általad emlegetett screenshottal kapcsolatban linkeltem be egy sérülékenységet, arra kaptál CVE-t, amire hivatkoztál, ez minden csak nem random...

> Design patternekről tudok beszélgetni, de a C nyelv rejtelmeit hadd ne kelljen most megismernem. :D

Kelleni nem kell, csak ha egy C-kódban történő validáció szükségességét illetően szeretnél szakmai véleményt adni, akkor nem árt, lol. :P (Mert ugye ezt tetted, mert ez volt a téma a screenshottal és a libc függvényeivel.)

> Mindenesetre volt olyan munkám, ahol egy szimulációt kellett (tök azonos inputokkal) lefuttatni rengetegszer, órákban volt mérhető a különbség amit az ilyen tizedmásodperces feladatok átcsoportosításával le lehetett faragni. Nyilván itt jön be az, amit az előbb mondtam, hogy rendesen dokumentált környezetben dolgoztunk, nem kellett attól aggódni, hogy a százmillió task mellé elindít valaki még százmilliót nullpointerekkel meg február 30-ával.

Ezt kiveséztük. Csak annyit tennék hozzá, hogy egy interval-check, vagy egy NULL-check, az egy komparálás és egy feltételes ugrás gépi kódban, ami CPU-tól függően ugyan, de majdnem biztosan kevesebb, mint 10 CPU-ciklus, ami pl. 4 GHz-es órajel esetén olyan 2.5 ns körül mozog, vagyis egy ilyen validálás ennél kevesebb időt eszik. Ha akarod, számold ki, hogy mennyi ilyen validáció kellene ahhoz, hogy a különbség érezhető legyen.

Oldschool Computer - http://oscomp.hu

 De ez akkor azzal is jár, hogy a kóderek betartják az írott és íratlan konvenciókat és a kód a 0. sortól az utolsóig auditálva van.

Ezt nem lehet automatizálni? Ez a problémakör már évtizedek óta velünk van, más nyelvnél a compiler már olyanokra is tud warningout adni, hogy ha véges az értékkészlete egy függvénynek, akkor warningot ad, ha nem kezeled le mindet a túloldalon. 

C-ben exception? Ott olyan nincsen, csak crash, meg egyéb nem várt következmény. Ha exception alatt azt értetted, hogy hibakódot ad vissza, az oké, de akkor csak neked kell lekezelned a dolgot.

Az exception csak egy példa, imho a probléma nem nyelvfüggő. Lehetett volna scala-szerű Success/Failure megoldásról is beszélni, de lehet hibakód, vagy tényleg bármi.

Kelleni nem kell, csak ha egy C-kódban történő validáció szükségességét illetően szeretnél szakmai véleményt adni, akkor nem árt, lol. :P (Mert ugye ezt tetted

Nem. Ezt pedig többször leírtam: az a kérdés, amiről én beszélek, az nem függ az implementáció nyelvétől. Lehet pszeudokódban is példát írni rá. Lehetne azt is validálni, hogy nem próbálunk-e február 29-ére hivatkozni. Teljesen mindegy.

> Ezt nem lehet automatizálni? Ez a problémakör már évtizedek óta velünk van, más nyelvnél a compiler már olyanokra is tud warningout adni, hogy ha véges az értékkészlete egy függvénynek, akkor warningot ad, ha nem kezeled le mindet a túloldalon.

Nem találkoztam olyan C fordítóval, ami ilyen opciót kínált volna fel. Arra reklamál, ha nem inicializálod és műveletet végzel vele, ill. ha a vizsgálatban szükségszerűen mindig igaz, vagy hamis lesz a végeredmény.

> Nem. Ezt pedig többször leírtam: az a kérdés, amiről én beszélek, az nem függ az implementáció nyelvétől.

Hát ezzel csak az a baj, hogy szó szerint tettél egy olyan kijelentést, hogy

Azt továbbra sem tartom problémának, hogy segédfüggvények (a screenshoton látható módon) nem végeznek olyan szintű logikai validációt, hogy az input "legitimate value"-e.

és az is egy validálást megspóroló C kód volt, amiből CVE lett.

Oldschool Computer - http://oscomp.hu

Ezt nem lehet automatizálni?

Igazából ki kellene baszni a C-t a picsába, mint rendszerpogramozási nyelv, mert már számtalanszor bebizonyosodott, hogy szar, pont az ilyenek miatt. Ha valami nem lehet null, akkor ne lehessen átadni null-t, csá.

Mondjuk ugyanez el van baszva a Java-ban, C#-ban is. Ok, C#8-ban bejött a nonnullable reference type, de eléggé utólagosan hozzátákolt módon.

> Szerintem a példád nem jó, inkább héj szerű felépítésre kell gondolni.

A példám azt volt hivatott illusztrálni, hogy egy db NULL-check az egy sor és ez a te példádban is ugyanannyi.

> protected, private

C-ről volt szó, nem OOP nyelvekről.

Oldschool Computer - http://oscomp.hu

> A példám azt volt hivatott illusztrálni, hogy egy db NULL-check az egy sor és ez a te példádban is ugyanannyi.

Szerintem meg a két példa más. A te példádban az ellenőrzés megkerülhetetlen, míg az én példámban, ha szükséges megkerülhető (pl. performancia)

> C-ről volt szó, nem OOP nyelvekről.

Csak egy lehetőséget írtam arra, hogy mit lehet esetleg tenni a nem biztonságos függvényekkel. Van hogy a nyelv biztosít rá megoldást, van hogy a függvény neve figyelmeztet rá, hogy óvatosan járj el. Vagy éppen csak egy megjegyzést helyeznek el a függvény mellett.

> míg az én példámban, ha szükséges megkerülhető (pl. performancia)

Ja értem, mire céloztál, hogy lehet ezt is, meg azt is hívni és ha nem kell a check, akkor hívja az unsafe verziót. Nos, ezzel viszont az a baj, hogy a te példádban viszont az ellenőrzős verzió sokkal nagyobb overheadet fog okozni, mint az én ellenőrzésem, mert nálam egy komparálás és egy feltételes ugrás van beiktatva, nálad pedig a nested call miatt plusz egy függvényhívás, ami mindjárt egy raklap veremműveletet és ugrálást (argument pass, jump, return) is eredményez.

Oldschool Computer - http://oscomp.hu

Nem kell minden esetben validálni. Ez nem programozási (értsd: kódolási), hanem szoftvertervezési kérdés.

A pointerek ellenőrzéséhez azért annyit érdemes hozzátenni, hogy abban az esetben ha egy pointer nem 0, attól még nem valid. A 0-ra ellenőrzés is csak akkor ér valamit, ha a programban kivétel nélkül mindenhol betartják azt a konvenciót, hogy azok a pointerek, amikhez nem tartozik allokált memóriaterület azok értékét 0-ra állítják. De ez csak egy konvenció, nem pedig valami alapigazság. És abban meg pláne nem szabad eltévedni, hogy elhisszük, hgy egy nem 0 értékű pointer az valid. Mutathat az bárhova.

Pontosan. Sőt, C-ben hiába passzolok át egy string szerű valamit, ha nincs nulla karakter a végén, abból is lehetnek bajok.

Mondjuk én ezért szeretem azokat a változatokat használni, ahol a méretet is megadom. Sajnos ez a C-ben egy tervezési hiba, és nagy kár, hogy nagy részük csak a C99-ben került be.

Az egész C úgy lett felépítve, hogy a lehető legnagyobb teljesítményt adja az adott vason, ezért is van benne egy rakás undefined behaviour is.

Pontosan. Sőt, C-ben hiába passzolok át egy string szerű valamit, ha nincs nulla karakter a végén, abból is lehetnek bajok.

Meg az ellenkezőjéből is. Ld. PQescapeStringConn:

The parameter from points to the first character of the string that is to be escaped, and the length parameter gives the number of bytes in this string. A terminating zero byte is not required, and should not be counted in length. (If a terminating zero byte is found before length bytes are processed, PQescapeStringConn stops at the zero; the behavior is thus rather like strncpy.) to shall point to a buffer that is able to hold at least one more byte than twice the value of length, otherwise the behavior is undefined. Behavior is likewise undefined if the to and from strings overlap.

Anno régesrég futottam bele, mikor PHP-ból egy serializált objektumot akartam áttolni a pg_escape-nek, majd visszaolvasáskor levágta a nagyját, mert a retardáltak a PHP-nál egy \0 karakterrel választották el az osztály nevét és a member nevét PHP5-től (4-ben még nem volt láthatóság, így nem kellett odatenni az osztályt). Semmi más nem használ speciális karaktert a formátumban, nem értem, itt miért kellett, ráadásul pont a \0-t. (Egyébként mondtam már, hogy a \0 végű string monnyonle?)

> A pointerek ellenőrzéséhez azért annyit érdemes hozzátenni, hogy abban az esetben ha egy pointer nem 0, attól még nem valid. A 0-ra ellenőrzés is csak akkor ér valamit, ha a programban kivétel nélkül mindenhol betartják azt a konvenciót, hogy azok a pointerek, amikhez nem tartozik allokált memóriaterület azok értékét 0-ra állítják. De ez csak egy konvenció, nem pedig valami alapigazság. És abban meg pláne nem szabad eltévedni, hogy elhisszük, hgy egy nem 0 értékű pointer az valid. Mutathat az bárhova.

Ezt én is tudom. De egyfelől a pointer egyéb validitásának ellenőrzésére nincsenek C-ben standard eszközök, másfelől meg a kiinduló állítás konkrétan a NULL-check feleslegességét tartalmazta.

Oldschool Computer - http://oscomp.hu

Írhatsz te inicializálatlan területre is, van rá esély, hogy észre sem veszed. Az esetek egy részében jól is működik a program. Csak egy karakterrel írom túl, stb.

Vagy egy felszabadított pointer helyére. Ezért nincs semmi értelme a NULL check-nek, KIVÉVE akkor (amint más már említette), ha a programozó betartja, hogy az inicializálatlan pointereket NULL-ra állítja. Én mondjuk így szoktam.

Az ilyen egyszerű hibák felfedésére vannak sokkal jobb toolok, mint pl. a Valgrind. Na az alól sokkal kevésbé lehet kibújni, ő mindent ellenőriz. De megnézheted, hogy mekkora performance hit, emlékeim szerint kb. tízszeres szokott lenni.

> Írhatsz te inicializálatlan területre is, van rá esély, hogy észre sem veszed. Az esetek egy részében jól is működik a program. Csak egy karakterrel írom túl, stb.

Persze, mert lapokat kapsz, nem byte-okat. De ez nem jó működés, hanem mázli. Legközelebb meg simán összedől, mint fél disznó az ólban.

> Vagy egy felszabadított pointer helyére. Ezért nincs semmi értelme a NULL check-nek,

Vagyis szerinted ez a helyes kód:

int valami(char *input, size_t len)
{
	char *kecske;

	kecske = malloc(len);
	strncpy(kecske, input, len);
	// TODO: something with kecske
	return 0;
}

ez helyett?

int valami(char *input, size_t len)
{
	char *kecske;

	kecske = malloc(len);
	if (kecske == NULL)
	{
		return 1;
	}
	strncpy(kecske, input, len);
	// TODO: something with kecske
	return 0;
}

> KIVÉVE akkor (amint más már említette), ha a programozó betartja, hogy az inicializálatlan pointereket NULL-ra állítja. Én mondjuk így szoktam.

Én is (ha el nem felejtem :P).

> Az ilyen egyszerű hibák felfedésére vannak sokkal jobb toolok, mint pl. a Valgrind. Na az alól sokkal kevésbé lehet kibújni, ő mindent ellenőriz. De megnézheted, hogy mekkora performance hit, emlékeim szerint kb. tízszeres szokott lenni.

Nem Valgrind szintű ellenőrzésre gondoltam, könyörgöm. Ld. a kódot.

Oldschool Computer - http://oscomp.hu

Ez a validálásos izémizé egy nagyon érdekes kérdés, amivel magam is rengeteget gyötrődtem a Furor megalkotása során. Előbb ugyanis egy saját librarycsomagot írtam, amit mindenféle másra is használhatok; a Furor csak egyetlen program ami reá épül.

Na és vegyünk egy olyan példát, hogy van egy függvény, ami egy stringre mutató pointert vár inputként, aztán ezzel a stringgel csinálnia kell valamit. A string amúgy egy hossztárolós string, gyakorlatilag tehát egy struktúra. Na most, kell-e validálnia a függvényemnek, és ha igen, akkor konkrétan mit is?

Ellenőrizze-e le, hogy az a pointer null pointer-e? Tegyük fel ez egy olyan függvény ami rengeteg helyen van meghívva a programban. Bár egyetlen összehasonlítás időszükséglete kicsinek tűnhet, ha egy ciklus mélyén van, a ciklus lefutásának száma nagy is lehet, s így már sok kicsi sokra megy...

Aztán, önmagában a pointer esetleges NULL voltának ellenőrzése nem elég. Mi van, ha a string hossza maga nulla? Ez is problémás lehet ugye bizonyos esetekben, mert lehet hogy az a művelet amit a függvény végezni akar a stringgel, nem értelmezhető nulla hosszúságú string esetén.

És még rengeteg mindenféle elképzelhető.

Na most ezen gondok mindegyikére persze ki lehet találni egy hibakódot, mondván hogy minket nem érdekel az időveszteség, a biztonságra megyünk rá, mindig mindent validálunk és kész, és pontosan tudni akarjuk a hibakódból, mi a hiba! Oké. De ezesetben megint felmerül a kérdés, hogyan legyen visszaadva a hibakód. Nem mindig lehetséges az, hogy ugyanott adjuk vissza ahol az „értékes” eredményt, mert mi van ha a visszatérési érték minden bitje egyaránt szükséges lehet az „értékes” eredmény számára is!

De ez még nem is minden, mert ha valamiképp vissza is adjuk itt a hibakódot, a hívó függvénynek is mindig ellenőriznie kéne hogy értékes eredményt kapott-e vissza vagy hibakódot. Na és ha mégse ellenőrzi, az legalább akkora sechole mint az, ha már a hívott függvény se validál, épp csak az utóbbi annyiból jobb hogy akkor legalább időveszteség sincs...

Márpedig tudjuk jól, az efféle függvények visszatérési értékét (hibakódját) nem mindig ellenőrzik ám le a programozók...

Szóval az egész kérdéskör tele van alattomos csapdákkal. Tudom. Tapasztaltam.

Még az se okvetlenül nyerő ötlet hogy validáljon ugyan a függvény, de hiba esetén ne visszatérési értékekkel meg hibakódokkal szórakozzon, hanem dobjon egy kivételt. Eleve, kivételkezelés nem is minden programnyelvben létezik, de most maradjunk annál hogy épp itt e példában igen. Nos, egy alacsonyrendű függvényt számos különböző helyről lehet meghívni, és nem mindig szerencsés ám az egész program-palotát összeomlasztani váratlanul csak mert valahol hiba lépett fel. A kivételgenerálás a szememben valamiféle atombomba, egy overkill, amit nem bölcs doloog alacsonyrendű függvények döntésére bízni, mert olyasmi mintha egy gyermek kezébe adnánk a nukleáris rakéták indítógombját...

Szóval itt lényegében arról van szó, hogy az oké hogy egy program legyen a lehető legintelligensebb, de az intelligenciának szintjei vannak, és azt kell eldönteni, mennyi „okosságot” sőt „okoskodást” bízunk rá egyik vagy másik függvényre.

Én végül úgy döntöttem, hogy foglalkozzék minden függvény a MAGA DOLGÁVAL, azaz eleve abból induljon ki, hogy aki őt meghívta, az mindent rendben bocsátott az ő rendelkezésére. Elvégre a hívó, az az ÚR, a hívott meg a SZOLGA, és a szolga kutyakötelessége megbíznia az ő urában!

Ha minden függvény pontosan és lelkiismeretesen csinál meg mindent ami TŐLE FÜGG, akkor ott baj nem lehet. (a hardware-hibát meg efféléket most ne bolygassuk).

Persze nyilván lesznek olyan függvények amik ezt-azt mégis elfelejtenek, mert egyetlen programozó se tökéletes, engem kivéve... de az nem csoda, én persze hogy tökéletes vagyok, mert nem is vagyok programozó. Mindazonáltal, e megközelítés szerintem még mindig a leggyümölcsözőbb.

> Bár egyetlen összehasonlítás időszükséglete kicsinek tűnhet, ha egy ciklus mélyén van, a ciklus lefutásának száma nagy is lehet, s így már sok kicsi sokra megy...

Egy komparálás, egy feltételes ugrás. Fentebb kiszámoltam, hogy mennyit eszik. (pl. 4 GHz esetén kevesebb, mint 2.5 ns.) Lehet kiszámolni, hogy mennyi idő után válik érezhetővé.

> Mi van, ha a string hossza maga nulla?

Tekintve, hogy a stringkezelő függvények az első NUL karakterig végeznek műveletet: semmi. Rögtön kiszállnak. De ha le akarod validálni, akkor az plusz egy sor: if (*s == 0) return 0;

> Na most ezen gondok mindegyikére persze ki lehet találni egy hibakódot, mondván hogy minket nem érdekel az időveszteség

"Időveszteség." Két bekezdéssel feljebb leírtam, hogy mekkora "időveszteség".

> Nem mindig lehetséges az, hogy ugyanott adjuk vissza ahol az „értékes” eredményt, mert mi van ha a visszatérési érték minden bitje egyaránt szükséges lehet az „értékes” eredmény számára is!

Talán el kéne szeparálni a visszatérési eredményt a hibakódtól? A POSIX függvényeknél pl. bevett szokás, hogy ha az eredmény -1, akkor hiba van és a kódot az errno-ban találod.

> De ez még nem is minden, mert ha valamiképp vissza is adjuk itt a hibakódot, a hívó függvénynek is mindig ellenőriznie kéne hogy értékes eredményt kapott-e vissza vagy hibakódot. Na és ha mégse ellenőrzi, az legalább akkora sechole mint az, ha már a hívott függvény se validál, épp csak az utóbbi annyiból jobb hogy akkor legalább időveszteség sincs...

> Márpedig tudjuk jól, az efféle függvények visszatérési értékét (hibakódját) nem mindig ellenőrzik ám le a programozók...

Remélem ezzel nem azt akartad sugallani, hogy azért ne validáljunk függvényen belül, mert a hívó úgy sem csinál semmit a hibakódokkal... Az az ő sara, ha nem ellenőrzi, amit kéne.

> Elvégre a hívó, az az ÚR, a hívott meg a SZOLGA, és a szolga kutyakötelessége megbíznia az ő urában!

Dogmákkal nem tudok mit kezdeni. Az egészben az a szép, hogy egy bekezdéssel feljebb épp azt írod, hogy a programozók tojnak a visszatérési kódok lekezelésére, de itt meg már azt, hogy bízzunk meg abban, hogy jól csinálják.

Oldschool Computer - http://oscomp.hu

Talán el kéne szeparálni a visszatérési eredményt a hibakódtól? A POSIX függvényeknél pl. bevett szokás, hogy ha az eredmény -1, akkor hiba van és a kódot az errno-ban találod.

Látszik, meg se próbáltad megérteni amit írtam. Hogy a rákba adsz vissza mínusz egyet, ha az értékes visszatérési eredmény ami nem hibakód, az is lehet akkora hogy egy unsigned long long típus teljes értékkészlete is szükséges lehet rá, mert akadhatnak benne olyan értékek is, hm?!

Aztán jössz itt nekem stringnél a nullabájttal. Világosan leírtam pedig hogy HOSSZTÁROLÓS stringről beszélek. Hol van neked egy hossztárolós stringben a string végét jelző nullabájt?!

A többi kifogásodra is tudnék válaszolni, de nem teszem mert neked válaszolva "bolond" súlyosan megbántott engem. És különben is kitetszik hogy semmit nem próbáltál megérteni abból amit írtam.

> Látszik, meg se próbáltad megérteni amit írtam. Hogy a rákba adsz vissza mínusz egyet, ha az értékes visszatérési eredmény ami nem hibakód, az is lehet akkora hogy egy unsigned long long típus teljes értékkészlete is szükséges lehet rá, mert akadhatnak benne olyan értékek is, hm?!

Az egy példa volt a szeparálásra. Egy példa, ami a POSX-nál bevett szokás. A lényeg a szeparálás volt. Másik példa erre:

int div5wit(int input, int *error)
{
	if (input == 0)
	{
		*error = 1;
		return 0;
	}
	*error = 0;
	return 5 / input;
}

Vagy másképpen ugyanez:

int div5wit(int input, int *output)
{
	if (input == 0)
	{
		return 1;
	}
	*output = 5 / input;
	return 0;
}

Tessék, itt nem merülhet fel érttékkészletbeli probléma.

> Aztán jössz itt nekem stringnél a nullabájttal. Világosan leírtam pedig hogy HOSSZTÁROLÓS stringről beszélek.

Valahogy sikerült átugrani azt a bekezdést. Errare humanum est. Mindenesetre így is egy sor a dolgot lekezelni: if (s->length == 0) return 0;

> Hol van neked egy hossztárolós stringben a string végét jelző nullabájt?!

Nekem? Hát ha már kérdezed, nekem mindenütt, mert én kompatibilitásbeli okokból a hossztárolós stringek végére is odabiggyesztem a NUL karaktert. A hosszban természetesen az nincs jelölve, egyszerűen mindig +1 byte-ot allokálok neki.

Oldschool Computer - http://oscomp.hu

Legyen a string immutable, és legyen rá rendes reprezentáció. Onnan kezdve, hogy ha a konstruktor (mindegy, hogy most egy C függvény vagy egy OOP-s megoldás) lefut, akkor az vagy visszaad egy valid eredményt, vagy nem. Exception egyébként ezért jó, mert garantáltan nem kapsz vissza jó eredményt. Ha valaki nem kezeli a megfelelő helyen, vessen magára. (Vagy ott van még a monadikus Maybe megoldások, az is működhet, mert rákényszerít, hogy ellenőrizd, ha szar van.) Ezek megoldott problémák, csak használni kellene, nem a retek C ezer éves szarságait kerülgetni.

Exception egyébként ezért jó, mert garantáltan nem kapsz vissza jó eredményt. Ha valaki nem kezeli a megfelelő helyen, vessen magára. (Vagy ott van még a monadikus Maybe megoldások, az is működhet, mert rákényszerít, hogy ellenőrizd, ha szar van.)

+1, ezek már nem megoldhatatlan problémák

Igen, ez egy létező középút, hogy ki/bekapcsolható assertek vannak. Bár ez inkább véletlen hibák ellen véd, pláne ha azok a fejlesztés alatt kijönnek, támadhatóság ellen pont nem jó.

Ideális az volna, ha az ellenőrzéseket beleírnánk a kódba - akár deklaratíven - és a fordító tudná, hogy azok ellenőrzések, és globális optimalizációval azon hívási láncokban ahol tudja, hogy az már ellenőrizve volt, ott ki tudná hagyni.

Masik pelda a tombok indexelese: nem vegzunk minden egyes esetben range check-et, amikor valaki vegigmegy egy for ciklussal a tomb elemein, mert minek. Nem az stdlib feladata, hogy megvedje magat a hulyektol.

Performance es megbizhatosag. Arrol szol a programozas, hogy megtalald a ketto kozott az aranykozeputat. Ha valaki egyiket vagy masikat tartja csak fontosnak, az nem jo programozo.

Csak úgy mondom, hogy a számítás intenzív részeket nem a magas szintű nyelvekben szokták implementálni.

Példa: írsz egy C++ mátrix könyvtárat. Szépen overload-olod a [] operátorokat ahogy kell, hogy csináljon range checket. Ízlés kérdése, hogy out-of-range-nél exception vagy default value visszaadás, de akkor gondolj bele, hogy egy generic mátrix szorzás így megvalósítva mekkora overhead.

És miért kellene a hozzáférés operátornál range check? Amikor a szorzást meghívod, akkor lecsekkolod egyszer, rendben van, mész tovább. Persze csinálhatsz egy []_unsafe-et, ami nem check-el, és akkor ugyanott vagyunk, mint a fent kifogásolt soroknál. Hogy a valaminek a szub_függvénye nem csinál range check-et.

(hozzáteszem, nem ellenőriztem hogy a fenti függvényt milyen kontextusban használják)

> Csak úgy mondom, hogy a számítás intenzív részeket nem a magas szintű nyelvekben szokták implementálni.

Ezt én is tudom. Nem erről volt szó.

> Példa: írsz egy C++ mátrix könyvtárat. Szépen overload-olod a [] operátorokat ahogy kell, hogy csináljon range checket. Ízlés kérdése, hogy out-of-range-nél exception vagy default value visszaadás, de akkor gondolj bele, hogy egy generic mátrix szorzás így megvalósítva mekkora overhead.

Micsoda? Egy plusz elágazás? Csak maga a szorzás, mint művelet többet fog enni...

> És miért kellene a hozzáférés operátornál range check? Amikor a szorzást meghívod, akkor lecsekkolod egyszer, rendben van, mész tovább. Persze csinálhatsz egy []_unsafe-et, ami nem check-el, és akkor ugyanott vagyunk, mint a fent kifogásolt soroknál. Hogy a valaminek a szub_függvénye nem csinál range check-et.

Mert a range megváltozhat menetközben? Esetleg? Kitörölsz a tömbből, hozzáadsz, stb.

> (hozzáteszem, nem ellenőriztem hogy a fenti függvényt milyen kontextusban használják)

geleinek már mutattam hozzá kontextust.

Oldschool Computer - http://oscomp.hu

Es mi az a specifikus megkozelites? Nagyon jol hangzik, de adott helyzetben, adott feladatnal pl. nem elfogadhato, hogy ne legyen SSE/Altivec optimalizacio (mert mondjuk HPC-rol beszelunk). Es akkor az a magikus jotanacs, amit mar jopar kommenttel ezelott is felvetettem, hogy kis iq-t bevetve megoldhato, hogy mondjuk kivul a ciklusban ellenorizzuk, hogy valid-e az iteracio *egesze* es utana hagyni az ellenorzes nelkuli fuggvenyeket futni, es megnyerjuk az optimalizaciot. (Es itt csendben megemelem a kalapomat a c++ STL tervezoje elott, mert azt, hogy van operator[] es at() hivas, ami az eredmeny szempontjabol alig kulonbozik, *mindossze* az ellenorzest hagyja el az operator[]. Amikor az STL keszult, a vektorizalasra kepes forditok valoszinuleg max. a szuperszamitogepek sajatjai lehettek, ellenben sikerult ugy tervezni a nyelvet, hogy amikor ez mainstream lett, a szabvanyhoz nem kellett nyulni, hogy lehessen magas szintu nyelven olyan kodot irni, ami vektorizalhato!!!).

De persze itt jopar embernek beragadt a lemez, a "mindig mindenhol mindent ellenorizzuk, mert kulonben segfault meg bufferoverflow", eskuszom olyanok lennenk, mint a kommunistak, akik meg a besugo besugojara  is besugot allitottak, aztan csodalkoztak, hogy semmi nem tortenik, mert senkinek nem marad ideje a besugason kivul masra.

Nyilvan ha valakinek kedve van szetkurni a branch predictort vagy fel akarja fujni a kodszegmenset redundans ellenorzesekkel, mert akkor nem kell tervezni, hanem lehet nullptr-checkeket vim makrobol minden fuggvenybe beszurni... Legyen a vendegem, de ne hirdesse azt, hogy a zsebeben van a bolcsek kove es megtudna szerelni az osszes problemajat *is* az IT-nek.

Micsoda? Egy plusz elágazás? Csak maga a szorzás, mint művelet többet fog enni...

Egy plusz elágazás simán jelentősen le tud lassítani egy kicsi (de nagy iterációszámú) ciklust. Ha egy kód feleslegesen tele van téve elágazásokkal, akkor az nagyobb lesz (akár jelentős mértékben, mivel a branch targeteket alignolja a fordító), ergo a kód cache rosszabbul fog teljesíteni. A branch predictor is rosszabbul fog teljesíteni, mivel tele lesz szemetelve feleseges bejegyzésekkel. Ha pedig éppenséggel rosszul prediktálja a CPU a branch-et, akkor nem kell mondanom, mennyivel lesz lassabb a kód.

Szóval ez a hozzáállás, hogy ellenőrizzünk mindent mindenhol működik persze, csak a performance rosszabb lesz. Ami persze sok helyen nem számít annyira, de azért mondjuk egy OS-ben, alap SW-ekben igen. Nem szeretném, hogy telefonom akksiideje azért legyen 30%-kal kevesebb, mert felesleges ellenőrzések vannak benne.

> Egy plusz elágazás simán jelentősen le tud lassítani egy kicsi (de nagy iterációszámú) ciklust.

Hol mondtam én olyat, hogy egy ciklus kellős közepén ellenőrizzük le, minden iterációnál? Annak mi értelme lenne? Én arról beszéltem, hogy a függvény validálja a paramétereit.

> Nem szeretném, hogy telefonom akksiideje azért legyen 30%-kal kevesebb, mert felesleges ellenőrzések vannak benne.

Jobb, ha feltörik, mert nincs ellenőrzés ott, ahol kéne, hogy legyen? Egyébként még mindig nem arról beszéltem, hogy mindenhova tegyünk felesleges ellenőrzéseket.

Oldschool Computer - http://oscomp.hu

Lehetnek kis fv-ek is. Pl., ami egy sima tömb idx-edik elemét visszaadja (azért lehet érdemes fv-be tenni, mert debug mode-ban assert-elhet). És ezt simán hívhatod egy ciklus közepén is. Pl. C++-ban teljesen tipikus az ilyen, lásd std::vector::operator[].

 

Jobb, ha feltörik, mert nincs ellenőrzés ott, ahol kéne, hogy legyen?

Nem. Ellenőrzés legyen ott, ahova való. Én csak annyit állítok, hogy nem kell minden fv-ben ellenőrizni, ha egy feljebbi réteg már leellenőrizte az adott dolgot. Teljesen normális, hogy egy API-nak a felülete ellenőriz, de alatta már semmi. Mivel, ha rossz paraméter megy be egy internal function-nek, akkor az programhibát jelez, amit nem run-time kell megoldani. Fejlesztés/tesztelés közben legyen mechanizmus az ilyen hibák kiszűrésére (pl. assert), de a kész programban ezek feleslegesek. Csak a hibakezelést és a programot bonyolítják.

> Lehetnek kis fv-ek is. Pl., ami egy sima tömb idx-edik elemét visszaadja (azért lehet érdemes fv-be tenni, mert debug mode-ban assert-elhet). És ezt simán hívhatod egy ciklus közepén is. Pl. C++-ban teljesen tipikus az ilyen, lásd std::vector::operator[].

Release-ben nem célszerűbb ezt inline megoldani? Csak a függvényhívás többe kerül időben, mint magának a függvénynek a végrehajtása, ha tényleg olyan pici.

> Nem. Ellenőrzés legyen ott, ahova való. Én csak annyit állítok, hogy nem kell minden fv-ben ellenőrizni, ha egy feljebbi réteg már leellenőrizte az adott dolgot.

Ha leellenőrizte igen, ezt vitattuk geleivel is, hogy teljesen felesleges, ha le van ellenőrizve, de ehhez az kell, hogy aki a feljebbi réteget írta, az le is ellenőrizze.

> Teljesen normális, hogy egy API-nak a felülete ellenőriz, de alatta már semmi.

És itt van a lényeg, erről volt szó, ezért hurrogtak le. A topicban többször is elhangzott a NULL-check, ill. a range check feleslegessége és a szálindító kommentben pont a standard C lib API-ját hozta példának a kolléga, hogy az se ellenőriz, mert minek, ellenőrizze, aki hívja. És itt jön képbe, hogy pl. a GLibc hemzseg a sechole-októl, kinyitja az ember ezt a listát és tele van mindenféle buffer alapú sérülékenységgel.

Oldschool Computer - http://oscomp.hu

Ugye konkrétan a mátrix szorzásra reagáltál úgy, hogy ott az operator[]-hoz végülis mehet az ellenőrzés, mivel csak "egy elágazás". Nyilván az operator[] az inline lesz, függetlenül attól, hogy van-e benne ellenőrzés vagy nincs (ha performace-ra megyünk). Szerintem viszont hiba indexellenőrzést tenni bele (arról nem is beszélve, hogy mátrix szorzásnál legalább 2 index operator kell - a 2 mátrixból egy-egy - és utána lesz 1 szorzás+összeadás, ami 1 instruction manapság, pár órajel. Ebben az esetben simán lehet, hogy 2x-es lassulást okoz a felesleges ellenőrzés).

 

Hát, a libc dolog az érdekes. Őszintén szólva én egyetértek azzal, hogy ne ellenőrizzen. A libc-nek ez a része, ami itt felmerült (stringek, memcpy), igaziból nem egy API, hanem inkább utility fv-ek. Ha valaki szeretné, simán csinálhat wrapper fv-eket ezek köré, amik csekkolják a NULL-t. Engem zavarna, ha tudnám, hogy én mindig nem-NULL paraméterrel hívom az adott fv-t, de az belül még csekkolja. Illetve, nem csak hogy zavarna, hanem lassabb futást is eredményezne. Nem feltétlenül a plusz elágazás miatt a memcpy()-ben (és társaiban), hanem amiatt, hogy emiatt a fordító kevésbé tud optimalizálni, ha a memcpy() több garanciát ad. Hogy miért? A gyakran használt ilyesmi fv-eket a fordító kioptimalizálja, ha tudja. Pl., ha lehet tudni a memcpy-nél a másolandó blokk méretét fordítási időben, és az nem túl nagy, akkor odatesz pár load/store instructiont a memcpy helyett. Ha még NULL-ra is csekkolnia kellene, az jelentősen lassítana.

Nem beszélve arról, hogyha ezekbe hibakezelést akarunk tenni, akkor (hogy értelme is legyen) minden ilyen fv-nek kéne hibát visszaadnia, és azt le is kellene kezelni. Ez eléggé megdobná a program méretét, és nehezebben átláthatóvá tenné a (felesleges) hibakezelésével. Ki az, aki minden memcpy/stb. után vizsgálni akarja a visszatérési értékét, hogy minden rendben ment-e?

 

Sajnos a C nyelv ilyen lett, már régen abba kellett volna hagyni a használatát, és áttérni C++-ra, vagy (ha az elmúlt 10 évet nézem) valami még modernebbre, ami tud garanciát adni az ilyen memóriafelülírós dolgokra. A C++-t azért említem, mert pár szabály betartásával simán lehet olyan kódot írni, ami védett az ilyen jellegű hibák ellen. Nyilván ez a C-re is igaz, de akkor már nagyon kényelmetlen lenne használni.

> Ugye konkrétan a mátrix szorzásra reagáltál úgy, hogy ott az operator[]-hoz végülis mehet az ellenőrzés, mivel csak "egy elágazás". Nyilván az operator[] az inline lesz, függetlenül attól, hogy van-e benne ellenőrzés vagy nincs (ha performace-ra megyünk). Szerintem viszont hiba indexellenőrzést tenni bele (arról nem is beszélve, hogy mátrix szorzásnál legalább 2 index operator kell - a 2 mátrixból egy-egy - és utána lesz 1 szorzás+összeadás, ami 1 instruction manapság, pár órajel. Ebben az esetben simán lehet, hogy 2x-es lassulást okoz a felesleges ellenőrzés).

A mátrixnál már más is mondta, hogy okozhat optim problémát, én meg mondtam, hogy akkor ez specifikus eset, amihez specifikus megoldás kell. Egy ciklus belsejében nyilván nincs értelme újraellenőrizgetni a dolgot. Nem is mondtam ilyet, olyat meg pláne nem, hogy kőbe vannak vésve a validálási pontok, ez ilyen ökölszabály, hogy a bemenetet illik leellenőrizni.

> Hát, a libc dolog az érdekes. Őszintén szólva én egyetértek azzal, hogy ne ellenőrizzen. A libc-nek ez a része, ami itt felmerült (stringek, memcpy), igaziból nem egy API, hanem inkább utility fv-ek. Ha valaki szeretné, simán csinálhat wrapper fv-eket ezek köré, amik csekkolják a NULL-t. Engem zavarna, ha tudnám, hogy én mindig nem-NULL paraméterrel hívom az adott fv-t, de az belül még csekkolja. Illetve, nem csak hogy zavarna, hanem lassabb futást is eredményezne.

Ezt is javasolták már feljebb, a safe-wrappert, én meg erre mondtam, hogy ez a fajta ellenőrzés, hogy plusz egy nested-függvényhívás, ez sokkal súlyosabb overhead lesz, mint az egy darab elágazás a függvényen belül.

> Nem feltétlenül a plusz elágazás miatt a memcpy()-ben (és társaiban), hanem amiatt, hogy emiatt a fordító kevésbé tud optimalizálni, ha a memcpy() több garanciát ad. Hogy miért? A gyakran használt ilyesmi fv-eket a fordító kioptimalizálja, ha tudja. Pl., ha lehet tudni a memcpy-nél a másolandó blokk méretét fordítási időben, és az nem túl nagy, akkor odatesz pár load/store instructiont a memcpy helyett. Ha még NULL-ra is csekkolnia kellene, az jelentősen lassítana.

Ennyi erővel azt is csinálhatná a fordító, amit fentebb asch javasolt, hogy ha látja, hogy "kint" leellenőrizték a hívás előtt, akkor belülről kidobja az ellenőrzést. Mert mi van, ha nem ellenőrizték le? Akkor jönnek a crash-ek, meg a sechole-ok.

> Nem beszélve arról, hogyha ezekbe hibakezelést akarunk tenni, akkor (hogy értelme is legyen) minden ilyen fv-nek kéne hibát visszaadnia, és azt le is kellene kezelni. Ez eléggé megdobná a program méretét, és nehezebben átláthatóvá tenné a (felesleges) hibakezelésével.

Most komolyan pár if, meg return miatti plusz kB-okon akadunk fent, miközben több GB-os "framework"-ökre épül szinte az egész szoftvervilág? :(

> Ki az, aki minden memcpy/stb. után vizsgálni akarja a visszatérési értékét, hogy minden rendben ment-e?

Én. Nekem valami defektus miatt a mániám, hogy ha egy függvény visszaadhat valamilyen hibakódot, akkor azt lekezelem. Talán az agyamra ment ifjú koromban a windóz azzal, hogy nem tudjuk milyen hiba történt, de rászívtál, büdös júzer...
Sz*rk.: Itt mondjuk te is hasonlókat írtál két éve:

Szerintem ugyanazt mondjuk. Én csak azt mondom, hogy a "csak ha tudsz hozzáadni plusz infot" általában fent áll. Ha nem teszi meg a programozó, akkor lusta, és ennek az az eredménye az esetek egy részében, hogy rossz minőségű hibaüzenetet kap a user (vagy kerül a logba). Vagy épp az, hogy a hibát le lehetne kezelni normálisan, és nem a usernek kellene újra megpróbálnia.

Szerintem mindenki látott már "Hiba történt, próbáld újra" jellegű hibaüzenetet. Kb. ez az eredménye annak, ha vki a kód tetején kapja el az exceptiont.

Most akkor miről vitatkozunk?

> Sajnos a C nyelv ilyen lett, már régen abba kellett volna hagyni a használatát, és áttérni C++-ra, vagy (ha az elmúlt 10 évet nézem) valami még modernebbre, ami tud garanciát adni az ilyen memóriafelülírós dolgokra. A C++-t azért említem, mert pár szabály betartásával simán lehet olyan kódot írni, ami védett az ilyen jellegű hibák ellen. Nyilván ez a C-re is igaz, de akkor már nagyon kényelmetlen lenne használni.

C vs. C++ vitába nem szeretnék belemenni (szerintem nem is ugyanarra való a két nyelv), viszont azt azért ideírnám, hogy sérülékeny, vagy összeomlós kódot bármiben lehet írni (pont, mint FORTRAN kódot); a hülye programozó ellen a C++ sem véd. Azt viszont valahogy nem nagyon tudom értelmezni, hogy össznépileg megszavazzuk, hogy validálni nem kell, aztán meg a C rossz, mert segfault és buffer overflow...

Oldschool Computer - http://oscomp.hu

 Egy ciklus belsejében nyilván nincs értelme újraellenőrizgetni a dolgot

Jó, de érted, ha egy részről azt mondod, hogy egy fv ellenőrizze le a paramétereit, és az operator[] az egy fv, és használnánk egy matrix szorzó rutinban, akkor ott lesz a felesleges ellenőrzés. Ez abból a szempontból speciális eset, hogy tök egyszerűen látható, hogy jelentős performance veszteség a vége. De egyébként meg kb. az összes helyen, ahol operator[]-t hívunk, felesleges az ellenőrzés, hiszen szinte soha se megy rá a vezérlés. Ergo mindenhol performance csökkenést okoz. És nagyobb kódot. Nem pár KB-t. Hányszor van leírva egy kódban az indexelés? Rengetegszer. Mivel inline-oljuk, ezért meg fog nőni a kód mérete. Jó, mind1, nem akarok ezen tovább rugózni amúgy, kb. megbeszéltük.

 

ez ilyen ökölszabály, hogy a bemenetet illik leellenőrizni.

Sokaknál ez az ökölszabály, sokaknál meg nem. Nálam pl. tutira nem. Assert-et nagyon sokat használok, de azt szeretem, hogy release-ben gyorsan menjen a kód (azaz release-ben egy csomó fv paraméterei nincsenek ellenőrizve).

 

plusz egy nested-függvényhívás, ez sokkal súlyosabb overhead lesz, mint az egy darab elágazás a függvényen belül.

Ha csak egy plusz elágazásról beszélünk, akkor az be tud inline-olódni (annak minden hátrányával együtt), szóval súlyos overheadnek azért nem mondanám. Ill., nyilván csak akkor van értelme azt a verziót meghívni, ha nem tudjuk kizárni, hogy fennállhat a hiba lehetősége. Persze ezzel visszajuthatunk az elejére, hogy mikor melyik verziót kell használni, és ha a hibakezelés nélküli verziót használjuk, akkor ott a baj.

 

Ennyi erővel azt is csinálhatná a fordító, amit fentebb asch javasolt, hogy ha látja, hogy "kint" leellenőrizték a hívás előtt, akkor belülről kidobja az ellenőrzést. Mert mi van, ha nem ellenőrizték le? Akkor jönnek a crash-ek, meg a sechole-ok.

Igen, csinálják is a fordítók szerencsére ezt, ha inline az ellenőrzés kódja, vagy link time optimizationnal van fordítva. Persze ez még messze nem tökéletes, mert sokszor nem tudnak rájönni a felesleges ellenőrzésekre.

 

Most komolyan pár if, meg return miatti plusz kB-okon akadunk fent, miközben több GB-os "framework"-ökre épül szinte az egész szoftvervilág? :(

Nem feltétlenül a lefordított kód méretére gondoltam, hanem a forráskódéra. Hogy minden libc hivás után ott lesz a hibakezelés. Egyébként tutira nem pár KB-ról beszélünk, ha minden fv-ben ott a hibakezelés (és az azt meghívó kódban is). Szerintem simán százalékot lehetne mondani, hogy mennyivel lesz nagyobb a kód egy ilyentől. De csak hogy ne a levegőbe beszéljek: azon a kódon, amin dolgoztam az előző munkahelyemen, az assertes és nem assertes build között majdnem 2x méretkülönbség, és hasonló sebességkülönbség van (úgy értve a buildeket, hogy mind2 optimalizált; az egyikben ott vannak az assertek, a másikban pedig nincsenek). Nyilván ez csak egy project, máshol más számok lehetnek, de azért beszédes szerintem.

 

Én. Nekem valami defektus miatt a mániám, hogy ha egy függvény visszaadhat valamilyen hibakódot, akkor azt lekezelem.

Itt most arról az esetről beszélünk, hogy a hiba "elviekben" nem történhet meg, mert az programozó hibát jelent. Tehát, ha egy memcpy-t tutira nem NULL paraméterekkel hívom meg, akkor nem akarok hibakezelést se tenni a hívás után, mivel tudom, hogy soha nem fog rámenni a futás. Ergo nem is akarok lekezelni egy ilyen hibát.

 

Most akkor miről vitatkozunk?

Szerintem azt a vitát ne hozzuk be ide, mert teljesen másról szólt. Ott nem arról volt szó, hogy hogyan kezeljük le a programozók által elkövetett hibákat. Ott az exception kezelésről beszéltem, és arról, hogy szerintem az exc. kezelésnek az a feature-e, hogy eldobod, aztán valaki sokkal feljebb kapja el, nem sok értelme van. Hasznos tud lenni néha, de ha jó hibakezelést akarunk, akkor ez ritkán használt feature, és inkább az lesz belőle, hogy az emberek lusták lesznek hibát kezelni.

 

Azt viszont valahogy nem nagyon tudom értelmezni, hogy össznépileg megszavazzuk, hogy validálni nem kell, aztán meg a C rossz, mert segfault és buffer overflow...

Nem arról van szó, hogy összességében sehol se kell validálni, hanem arról, hogy az a szabály, hogy "a fv elején mindig validáljuk a paramétereket" nem feltétlenül állja meg a helyét. A C pedig igenis egy rossz programozási nyelv így 2020-ban. Valamikor jó nyelv volt, de azóta már vannak jobb programozási nyelvek. Vitázni én se akarok erről különösebben, csak azért lássuk be, hogy a világ elment a C mellett. Konkrétan szinte nincs olyan feladat, amit C-ben állnék neki megcsinálni, ha from-scratch kell valamit alkotni. Egy előnye van C++-szal szemben, hogy az ABI az nagyon kőbevésett, nincs vele problméma (persze C++-s kódhoz is lehet C-s API-t csinálni, sokan csinálják is). Ha ez nem számít, akkor el nem bírom képzelni, miért használna bárki C-t (mivel hogy C++-ban is kb. lehet C-ben programozni, és ha kell, akkor ott van a C++ összes jó feature-e).

> Jó, mind1, nem akarok ezen tovább rugózni amúgy, kb. megbeszéltük.

Szerintem sincs értelme ezt a részt tovább ragozni, már csak azért sem, mert C-ben ezt a hibát el sem követheti az ember, hiszen ott nincs operator overload.

> Ha csak egy plusz elágazásról beszélünk, akkor az be tud inline-olódni (annak minden hátrányával együtt), szóval súlyos overheadnek azért nem mondanám. Ill., nyilván csak akkor van értelme azt a verziót meghívni, ha nem tudjuk kizárni, hogy fennállhat a hiba lehetősége. Persze ezzel visszajuthatunk az elejére, hogy mikor melyik verziót kell használni, és ha a hibakezelés nélküli verziót használjuk, akkor ott a baj.

Mármint, hogy

int valami_unsafe(void *x)
{
	// mittudomen
	return 0;
}

int valami_safe(void *x)
{
	if (x == NULL)
	{
		return 1;
	}
	return valami_unsafe(x);
}

felállás esetén a valami_safe() függvénybe az egész valami_unsafe() inline-olódik a binárisban? Akkor azzal duplikáltad az egész függvény kódját a binárisban - már ha feltételezzük, hogy mind a kettőre szükség van - ami egy idő után nagyon sokra fog rúgni. Persze, ha az unsafe verziót nem hívjuk meg sehol, akkor az nem kerül külön bele, de akkor meg a végén - a binárisban - ugyanazt kaptad, mint ha csak simán lett volna egy elágazásod, hiszen a call-t inline-osította. Akkor már nem célszerűbb ezt makróval kikapcsolhatóvá tenni?

int valami(void *x)
{
#ifndef VALAMI_RELEASE
	if (x == NULL)
	{
		return 1;
	}
#endif
	// mittudomen
	return 0;
}

> "Igen, csinálják is a fordítók szerencsére ezt, ha inline az ellenőrzés kódja, vagy link time optimizationnal van fordítva. Persze ez még messze nem tökéletes, mert sokszor nem tudnak rájönni a felesleges ellenőrzésekre."

Akkor itt is kb. a makrós kapcsolgatás volna inkább célszerűbb, nem?

> Itt most arról az esetről beszélünk, hogy a hiba "elviekben" nem történhet meg, mert az programozó hibát jelent. Tehát, ha egy memcpy-t tutira nem NULL paraméterekkel hívom meg, akkor nem akarok hibakezelést se tenni a hívás után, mivel tudom, hogy soha nem fog rámenni a futás. Ergo nem is akarok lekezelni egy ilyen hibát.

Hát ez az, hogy "elviekben". Honnan tudjuk, hogy ez a gyakorlatban is fennáll?

> Nem arról van szó, hogy összességében sehol se kell validálni, hanem arról, hogy az a szabály, hogy "a fv elején mindig validáljuk a paramétereket" nem feltétlenül állja meg a helyét.

De ezt én nem is vitattam, már mondtam, hogy ez ökölszabály, nem szentírás. Ha nincs mit validálni, akkor nincs mit, de ahhoz elég sok feltételnek együtt kell állnia.

> A C pedig igenis egy rossz programozási nyelv így 2020-ban.

Mire rossz nyelv a C? Mire jobbak a többiek? Alacsonyszintű fejlesztésre, "hordozható assembly"-nek? Vagy alkalmazásfejlesztésre? Az előbbit csak C-ben csinálnám, az utóbbit csak abban nem. A C-nek is megvan a maga létjogosultsága a mai napig.

> (mivel hogy C++-ban is kb. lehet C-ben programozni, és ha kell, akkor ott van a C++ összes jó feature-e).

Ezt én is tudom.

> Ha ez nem számít, akkor el nem bírom képzelni, miért használna bárki C-t

Azért, mert ha a feladathoz nem kellett a C++ egyetlen extra feature-je sem (nem kezeltél memóriát, stringeket, nincsenek objektumaid, stb.), akkor amit írtál az akkor is C kód, ha C++ fordítóval fordítod le.

Oldschool Computer - http://oscomp.hu

a valami_safe() függvénybe az egész valami_unsafe() inline-olódik a binárisban? 

Nem, arra gondoltam, hogy a valami_safe inline-oldódik be.

Akkor már nem célszerűbb ezt makróval kikapcsolhatóvá tenni?

De igen, nekem ilyesmi a koncepcióm. Annyi különbséggel, hogy a programozási hibák okozzanak megállást a programban, és ne hibakódot adjanak vissza (most ugye debug mode-ról beszélünk). Szóval az assert-et javaslom az ilyen helyzetekre az "#ifdef ... return 1; #endif" helyett. De nyilván ez se teljeskörű szabály, amit mindig mindenhol alkalmazni kell.

 

Hát ez az, hogy "elviekben". Honnan tudjuk, hogy ez a gyakorlatban is fennáll?

Nyilván mindenki máshol húzhatja meg ezt a határt. Pl., ellenőrzöd-e minden összeadás előtt, hogy az eredmény belefér? Nyilván nem (pedig "signed int" esetén ez a C szabvány szerint ez undefined behavior, és "unsigned int" esetén is az overflow csúnya dolgokat tud csinálni). Én nagyon gyakran használom az assertet, ezzel ellenőrzöm a dolgokat. Van olyan software, amit így is hagyok, assertek maradnak benne (mert nem számít a performance, se az, ha esetlegesen elszáll a program. Viszont az igen, hogy a program helyes outputot adjon). De általában release-re kiszedem belőlük (egy alapos tesztelés után). Ezt pl. csak azért mondtam el, mert nekem van memcpy wrapperem, amiben van assert a NULL-ra (és arra vonatkozóan is, hogy nincs overlap). Debug-ban ott a csekk, release-ben pedig minden fut szépen gyorsan.

 

De ezt én nem is vitattam, már mondtam, hogy ez ökölszabály, nem szentírás. Ha nincs mit validálni, akkor nincs mit, de ahhoz elég sok feltételnek együtt kell állnia.

Még 1x: ez nem mindenkinek ökölszabály, és bizonyos esetekben kifejezetten káros. Egy project dönthet úgy, hogy ezt követi, lelke rajta, és utána esetlegesen egy profile-olás után kiszedheti a felesleges csekkolásokat (ha számít egyáltalán a performance). De az is lehet ökölszabály, hogy az interface-en lévő fv-ek ellenőrzik a paramétereket, az alattuk lévők pedig nem. Ez egy másik ökölszabály, ami más, mint amit te mondasz. De ezt már 1x leírtam, szóval ezen se akarok tovább rugózni.

 

A C-vel kapcsolatban pedig csak annyit, hogy "hordozható assembly"-nek is C++-t használnék. Nincs semmi okom arra, hogy leragadjak a C-nél. Meg tudok mindent valósítani C++-ban, amit C-ben meg tudok, kb. ugyanúgy? Igen. Viszont ha valami esetleg kell a C++-ból, akkor az is ott van. Szóval tényleg nem látom, hogy mi a létjogosultsága C-nek azóta, amióta van C++. De nyitott vagyok amúgy mondjuk egy példára, ahol az látszik, hogy igen, itt C fordítót jó használni egy adott feladatra (és a C++ nem jó), mert valamiért. Ha már csak azt az egy dolgot veszem, hogy std::array-t használnék a sima C tömb helyett (ami elkaphatja az index túlcímzést debug mode-ban), már megéri, hogy C++-t használjak (még ha amúgy full C jellegű kódot írok, akkor is).

 

De mind1, szerintem kissé elkanyarodtunk a témától. Én csak annyit szerettem volna megjegyezni, hogy performance és átláthatósági okokból nem tudok egyetérteni a "fv ellenőrizze le a paramétereket" ökölszabállyal: ez sok esetben ez nem jó szabály.

> Nem, arra gondoltam, hogy a valami_safe inline-oldódik be.

Ja ok, bocsi, nem volt egyértelmű.

> De igen, nekem ilyesmi a koncepcióm. Annyi különbséggel, hogy a programozási hibák okozzanak megállást a programban, és ne hibakódot adjanak vissza (most ugye debug mode-ról beszélünk). Szóval az assert-et javaslom az ilyen helyzetekre az "#ifdef ... return 1; #endif" helyett. De nyilván ez se teljeskörű szabály, amit mindig mindenhol alkalmazni kell.

Teljeskörű szabály nincs, de az garantáltan rossz hozzáállás, hogy semmit sem validálunk (nem, nem te mondtad).

> Nyilván mindenki máshol húzhatja meg ezt a határt. Pl., ellenőrzöd-e minden összeadás előtt, hogy az eredmény belefér? Nyilván nem (pedig "signed int" esetén ez a C szabvány szerint ez undefined behavior, és "unsigned int" esetén is az overflow csúnya dolgokat tud csinálni).

Természetesen csak akkor ellenőrzök az összeadás előtt, ha szükséges. Bár többnyire inkább a végeredményt ellenőrzöm le, hogy jó-e, pl. tömbindexnél.

> Én nagyon gyakran használom az assertet, ezzel ellenőrzöm a dolgokat. Van olyan software, amit így is hagyok, assertek maradnak benne (mert nem számít a performance, se az, ha esetlegesen elszáll a program. Viszont az igen, hogy a program helyes outputot adjon). De általában release-re kiszedem belőlük (egy alapos tesztelés után). Ezt pl. csak azért mondtam el, mert nekem van memcpy wrapperem, amiben van assert a NULL-ra (és arra vonatkozóan is, hogy nincs overlap). Debug-ban ott a csekk, release-ben pedig minden fut szépen gyorsan.

A végére csak konszenzusra jutunk.

> Nincs semmi okom arra, hogy leragadjak a C-nél. Meg tudok mindent valósítani C++-ban, amit C-ben meg tudok, kb. ugyanúgy? Igen. Viszont ha valami esetleg kell a C++-ból, akkor az is ott van.

"Ha valami esetleg kell", csak ha nem használsz semmit a C++-ból, akkor az C kód lesz.

> De nyitott vagyok amúgy mondjuk egy példára, ahol az látszik, hogy igen, itt C fordítót jó használni egy adott feladatra (és a C++ nem jó), mert valamiért.

Nem az, hogy "nem jó", hanem, hogy értelmetlen. Pl. - mondok egy primitív példát - van egy baromi egyszerű mikrokontrolleres környezeted, ami kb. abból áll, hogy van mondjuk kemény 4 db memóriacímed, amiről különféle szenzorértékeket, ill. I/O lábak szintjeit tudod beolvasni és van 8 másik memóriacímed, amikre 7 szegmenses kijelzők vannak aggatva, amiken a bejövő vackokat kijelzed. Itt gyakorlatilag semmi mást nem csinálsz, mint memóriacímeket piszkálsz, bitmaszkolsz, meg számolgatsz. Ezt persze akár assemblyben is meg lehetne írni, de akkor írhatod újra, ha mondjuk "fent" úgy döntenek, hogy architektúra csere van, viszont a feladat maga semmilyen szinten (sem sebességileg, sem méretileg) nem igényli, hogy assemblyben írd meg. És légy szíves ne írd azt, hogy ezt te inkább bedrótozod valami chipbe, mert nem ez volt a lényeg. :P Amire ki akarok lyukadni, hogy van olyan környezet és olyan feladat, ahol a C++ nem az, hogy nem jó, hanem egyszerűen értelmetlen, mert nincs amit használj belőle; ha abban is írod meg a kódodat, az tkp. C kód lesz.

Oldschool Computer - http://oscomp.hu

Okés, megértem a C/C++-os álláspontodat, de én egy kicsit másképp gondolkodok erről. Mivel semmi hátránya sincs C++-t használni az általad hozott példán se, én itt is C++-t használnék. Még ha első blikkre overkillnek tűnik is. De miért is overkill? A keletkező bináris kb. ugyanaz lesz. Most az, hogy közben ezt egy C vagy C++ fordító állítja elő, számomra teljesen mindegy.

Láttam már olyat, hogy egy MCU-ra lett egy C-s kód megírva (pár száz sor). Aztán tovább lett fejlesztve, egyre csak nőtt (pár ezer sor), és előjöttek azok a dolgok, amikre C++-ban van normális megoldás, itt pedig a C miatt pl. macro-kkal kellett bohóckodni. Csak azért, mert "ez MCU, és oda a C való". De ennek igaziból semmi racionális okát nem látom. Attól még, hogy valami embedded HW-re nem valami nagy software monstrum kell, hanem alkalomadtán csak pár száz/ezer soros kódja van, attól még előjöhetnek olyan problémák, amiket C++-ban szebben, jobban karbantarthatóan meg lehet valósítani, mint C-ben.

Na mindegy, ezen se kívánok többet rugózni, szóval köszi a beszélgetést :)

( bacsa81 | 2020. 09. 25., p – 09:10 )

Már 500 kínai programozó serényen dolgozik a kínai klónon amivel teljes Win kompatibilitást fognak elérni és kitiltják cakk und pakk a MS-t Kínából. Becsületükre legyen mondani ügyesen másolnak, nem eredeti minőségben, de működni szoktak a megoldásaik.

( uid_16313 | 2020. 09. 25., p – 09:11 )

Ha már végleg nem lehet rávenni a mai napig XP-t használókat, hogy váltsanak, ez egy elég jó húzás a plusz motivációhoz.

Régóta lerágott csont a téma.

Aki képes legacy operációs rendszert használva biztonságtudatosan viselkedni az Interneten, azt ez után sem fogják nagyobb eséllyel feltörni, mint a friss™ operációs rendszert használókat.

( Polesz v | 2020. 09. 25., p – 09:28 )

Na hajbazer, nem gondoltam volna, hogy eljön még a te időd! :)

Eljön majd, ha majd a Windows XP SP3 + Windows XP x64 Edition SP2 forráskódja szivárog ki minden frissítésének forráskódjával együtt és lesz open-source projekt, ami karbantartja, kompatíbilissá teszi az újabb Windows-verziókra fordított binárisokkal.

Most még egyelőre csak megkapta a Microsoft, amit már 6 éve megérdemelt volna.

A Linux FAT kód sem volt lopás, csak hasonlított a Microsoft szerint. Mégis inkább átírták, nehogy gond legyen belőle. Továbbra sem javaslom. A visszafejtés is egy szürke zóna, nem tanácsos ilyesmit csinálni. Az, hogy nem perelték MÉG be őket, nem jelenti azt, hogy sosem fogják.

Ezt úgy csinálják egyébként, hogy egy belenéz a kódba, dokumentálja a látottakat, majd egy olyan kóder, aki nem nézett sose bele a kódba, a megszülletett dokumentáció alapján implementálja a funkciót. Nem vagyok biztos benne, hogy ez kiállná egy per próbáját.

trey @ gépház

> A Linux FAT kód sem volt lopás, csak hasonlított a Microsoft szerint. Mégis inkább átírták, nehogy gond legyen belőle.

Kár volt. A hasonlóság kevés ahhoz, hogy azzal valakit tökön lehessen rúgni, ezt maga billy-boy mondta. :P

> Továbbra sem javaslom. A visszafejtés is egy szürke zóna, nem tanácsos ilyesmit csinálni. Az, hogy nem perelték MÉG be őket, nem jelenti azt, hogy sosem fogják.

Az amcsiknál precedensjog van, ha eddig nem perelték őket be, akkor nehezen fogják megmagyarázni, hogy most miért is kéne, hacsak nem egyértelmű, hogy kódot loptak, viszont azt tényleg egyértelműen bizonyítani kell tudni, hogy a kód lopott. Márpedig...

> Ezt úgy csinálják egyébként, hogy egy belenéz a kódba, dokumentálja a látottakat, majd egy olyan kóder, aki nem nézett sose bele a kódba, a megszülletett dokumentáció alapján implementálja a funkciót. Nem vagyok biztos benne, hogy ez kiállná egy per próbáját.

...ha még csak nem is lopnak, csak újraimplementálnak dolgokat (amihez a kiszivárgott forrásból puskáznak, azt is bizonyítani kéne tudni), arra elég nehéz lesz ráhúzni, hogy kódot loptak.

Oldschool Computer - http://oscomp.hu

> A precedensjog nem ezt jelenti.

Hát? Akkor mi az, ami ezt lefedi? Prior art? (Márhogy, eddig is volt opensource windows klón.)

> Egyébként elég legitimnek tűnne az a magyarázat, hogy "azért most perelünk, mert most férnek hozzá a kódhoz".

Ez sehol nem állna meg. Ez "guilty until proven innocent" érvelés; tessék bebizonyítani, hogy tényleg loptak.

Oldschool Computer - http://oscomp.hu

Hát?

A precedensjog az, amikor korábban meghozott bírói ítéletek jogforrásnak számítanak.

Akkor mi az, ami ezt lefedi?

USC szerzői jogi jogszabályokkal kapcsolatban nincs sok tapasztalatom, úgyhogy passz. :)

Ez "guilty until proven innocent" érvelés; tessék bebizonyítani, hogy tényleg loptak.

Hát erre való a per. Keresetet bárki ellen indíthatsz, és az eljárás során bebizonyítod az igazad. Vagy nem, és akkor bukó. :)

Hát ezt majdnem biztos, hogy buknák, mindennemű bizonyíték nélkül.
De. Pusztán csak a "készüljünk fel a legrosszabbra" elv mentén, tételezzük fel, hogy neked van igazad, az ms "bebizonyítja" a tökkelütött amcsi bíróságnak, hogy a ReactOS fejlesztők kódot loptak, hogy a Π előállítható két egész szám hányadosaként, hogy a kutyák brekegnek és szatyorral szaporodnak, hogy Hannibal Lecter filantróp (ziccer, ziccer!), sőt még azt is majdnem sikerül bizonyítaniuk, hogy a win10 nem szar (azért lehetetlent ne kívánjunk már szegényektől). Itt jön képbe, hogy a ReactOS egy orosz projekt. Hol fogja őket érdekelni/érinteni egy amerikai bíróságon megszületett ítélet?

Oldschool Computer - http://oscomp.hu

Esetleg illegálisnak minősül a ReactOS használata az USA-ban, meg ahová az USA keze elér. Az oroszoknál meg a kínaiaknál nem fogják nyilván szankcionálni. De nálunk azért már van befolyásuk.
Ha pedig itt ugyanazon kalap alá fog esni, mint ha tört Windows XP futna a gépeden, akkor nem sok értelme lesz használni.

Nagy Péter

> Esetleg illegálisnak minősül a ReactOS használata az USA-ban, meg ahová az USA keze elér. Az oroszoknál meg a kínaiaknál nem fogják nyilván szankcionálni. De nálunk azért már van befolyásuk.

Hogy az USA-ban be tudják-e tiltani, azt nem tudom. Lehet. De másutt? Egyáltalán hogyan akadályozzák meg, hogy az emberek feltelepítsék? Mindenkihez besétálnak és végigtúrják a gépeiket? De még ha elméletben fel is tételezzük ezt a lehetőséget; egy globálisan elérhető, ingyenes OS-nek mit fog ez ártani?

> Ha pedig itt ugyanazon kalap alá fog esni, mint ha tört Windows XP futna a gépeden, akkor nem sok értelme lesz használni.

Miért is? Ennyi erővel tört Xp-t sem volt értelme használni, aztán mégis használta az egész világ; magánembereket nem nagyon szankcionáltak kalóz windóz használata miatt...

Oldschool Computer - http://oscomp.hu

Miért is? Ennyi erővel tört Xp-t sem volt értelme használni, aztán mégis használta az egész világ; magánembereket nem nagyon szankcionáltak kalóz windóz használata miatt...

Szerintem elég gond, ha cégként szankcionálják. A ReactOS-ben az a egyik legjobb funkció, hogy régi Windows rendszereket lehet kiváltani céges környezetben jogtiszta programmal. 

Nagy Péter

Szerintem ez az USA-ban egyáltalán nem meredek. Abszolúte nem! Nyilván, ha betiltanák __szerzői__jogsértésre__ vagy más effélére hivatkozva a ReactOS-t, attól még nem macerálnák az egyszerű mezei polgárt ha az felteszi a gépére. (Ha valamiféle állambiztonsági aggály miatt tiltanák be, akkor lehet hogy mégis...)

Ellenben az efféle betiltás után nem lenne semmi picit is jelentős (kb 1 főnél nagyobb...) vállalkozás, amelyik fel merné tenni a progit az üzleti gépére...

És ezt a tiltást simán ki tudnák kényszeríteni a jogvédő szervek Magyarországon is. Oké, itt már lennének cégek amik ennek ellenére használnák. De minél nagyobb a cég, annál kevésbé merne kockáztatni...

Na most ennek fényében az oroszokon és Kínán kívül a ReactOS-nak nem lenne ÉRTELME. Mert ha egy cég vagy magánszemély már rászánja magát a szoftverlopásra (vagy arra, amit a törvény annak tart) akkor egyszerűbb neki tört windowst használni és kész. A reactos előnye épp az volna hogy legálisan lehessen windows nélkül windowsos programokat futtatni. LEGÁLISAN..

Hogy az USA-ban mit tudnak elérni, azt kár bolygatni, mert azt nem tudni. Annyit azért megjegyeznék, hogy a 2000-es évek elején megpróbálták elérni (mármint az ms), hogy a hobbiprogramozás bűncselekmény legyen. Nem sikerült nekik.

Viszont, hogy bárhol másutt betiltanának egy hobbi oprendszert, mert az USA fingik egyet, nos, azt hiszem, ha látom.

Oldschool Computer - http://oscomp.hu

Nekem csak Gates nyilt levele rémlik. Az ilyennel egyébként párszor agyonszopatták magukat. Valószínűleg hozzájárult a mobilplatformjaik "népszerűségéhez", hogy megtaposták az XDA-devst és az is, hogy a Visual Studio Express változatát nem lehetett Windows Mobile fejlesztésre használni. 

Az Open Letter to Hobbyists az nem az volt. Ott csak annyi történt, hogy volt ugye a MITS, ennek volt az Altair 8800-as nevű gépe. Allen és billy boy pedig felbérelték Monte Davidoffot, hogy írjon nekik rá BASIC-et (ez konkrétan benne van a levélben). A MITS kifizette nekik a BASIC-et és utána a géphez adták ingyen a vásárlóknak, akik meg korábban vásárolták a gépet, azoknak nem volt meg, ők lemásolták maguknak. És billy boy erre írta a levélben, hogy vegyék meg a BASIC-et, ne másolják le, mert ez nem fair, ez lopás. Hát kiröhögték, ahogy kellett. Csak akkor lett volna lopás, ha nincs Altair 8800-asod (again: járt a géphez), viszont akinek nincs Altair 8800-asa, az minek másolná le, mit kezdene vele?

Oldschool Computer - http://oscomp.hu

Nem értem a kérdésed.

"Beperelni" bárkit lehet. Ha van egy német egyesület, ami a német törvények alapján neked kárt okoz, akkor kártérítésre lehetsz jogosult. Ha van egy orosz magánszemély, aki neked kárt okoz, akkor kártérítésre lehetsz jogosult, és/vagy büntetőjogi következményei lehetnek. Sem a német, sem az orosz szerzői jogi jogszabályokat nem ismerem, úgyhogy ne kérdezz bele - majd ha valakit érdekel, kikeresi.

Nem az volt a kérdés, hogy a MS ezt megcsinálja-e, vagy ha igen, sikerül-e megpicsázni a ReactOS projektet. Az volt a kérdés, hogy az elvi lehetősége adott-e, hogy jogi úton próbáljon érvényt szerezni az őt ért vélt vagy valós sérelmeknek. Igen, adott a lehetőség, csak utazgatni kell hozzá. Ennyi. :)

Jó, hát pert indítani lehet akárkinek, akárki ellen, akárhol, én is beperelhetem a Holdat a venezuelai bíróságon, hogy nem sajtból van, hanem zsemlemorzsa-beton keverékből és ez szerintem jogsértő...biztos meg fogják ítélni. :P

A kérdés pedig pont nem az volt, hogy elméleti lehetősége van-e annak, hogy perelhetnek, mert az nem is volt kérdés (azt én se vitattam, mármint azt, hogy pert indíthatnak), hanem éppenhogy az, hogy ezzel be tudnak-e tenni a ReactOS projektnek, vagy sem. Én azt mondom, hogy szerintem nem, te azt mondod, hogy szerinted nem tudod...de azért reméled. :P

Oldschool Computer - http://oscomp.hu

Akkor azért FUD-oltak vele rendesen. ;)

Mitigating Risk on Your Technology Investment

Recently the origin of some of the code for the Linux Operating System Kernel has come into question. The SCO Group based in Lindon, Utah has filled suit against IBM for $3 Billion in damages due to Intellectual Property infringement. SCO has since then created a license for corporations that would license the use of the code, but for a fee of $199 per desktop and introductory price of $699 per processor on a server. This is a steep price to pay for a “Free Operating System”.  SCO’s CEO, Darl McBride said businesses that continue using Linux without a SCO license can expect legal action. "We're absolutely, 100 percent going to fight for our intellectual property rights," he said. "If we don't get there with licensing, we will have to move to enforcement actions."  

It is important to note that this litigation may take years to resolve and even if SCO does not prevail, the very fact that these Intellectual Property issues exist at all should cause any corporation to consider its use with extreme caution

Forrás

( answ | 2020. 09. 25., p – 11:42 )

Engem MS-DOS 6.0 jobban érdekel. Végre menni fog FreeDOS alatt Windows nem standard módban?

Szerintem a régi DOS-os kódokat nem sok értelme van megosztani. Mert tipikusan az egész ASM-ben van írva, ami azért nem segítség, mert aki erre volt kíváncsi, az debuggerrel 90%-ban, disassemblerrel (plusz symbol table alapján) 99%-ban vissza tudta állítani a kódot eddig is. Sajnos ezek a régi kódok amúgy is vállalhatatlanok mai szemmel, sok low level hack és gányolás van bennük. Ezek egy része akkoriban indokolt volt a kisebb hardverigény miatt, a másik része meg annak az eredménye, hogy akkor még nem voltak ilyen kiforrott, egységes fejlesztési módszertanok, így a kódminőség alacsonyabb volt, nem volt az egész úgy tagolva, úgy dokumentálva, nem állt olyan magas szinten a kódújrahasznosítást, multiplatformos megközelítés, stb.. Persze ettől még lehet segítség lenne pl. a FreeDOS, DosBox, stb. projekteknek, de kötve hiszem, hogy nagy jelentősége lenne. Eleve egy gányolt kódot majdnem olyan nehéz megérteni, mint vakon újraimplementálni az egészet inkább saját kútfőből.

Részben ugyanez az oka annak is, hogy a régi Windowsok forráskódját nem hozzák nyilvánosságra. Nem csak azért mert az újabb verziókhoz is megkönnyítené a támadásokat, ez csak a kisebbik része. Hanem az eredeti kódban lehet egy csomó hekkelés, ami mai szemmel vállalhatatlan, komolytalan, illetve lehetne benne olyan másoktól lopott kódok, amik eddig nem tűntek fel, de a forráskódot nézve azonnal rájönnének, hogy kitől származik, és a MS megütné a bokáját. Míg az MS számológép, GW-BASIC, stb. kódját azért tudták publikálni, mert az teljes egészében belső házi fejlesztés, egyszerű toolok, nem volt kód lopkodva máshonnan. Plusz utóbbiaknak már nincs használati értéke, hiszen vannak sokkal jobb Basic interpreterek, compilerök, jobb IDE környezetek, jobb text editorok, jobb számológép, math és math script szoftverek, amik eleve multiplatformos FOSS-ok, másrészt torony magasan verik.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( cherockee v | 2020. 09. 25., p – 13:31 )

A Windows CE vonal szivárgásáról nem látok fentebb kommentet, nem vagyok beágyazott fejlesztéssel foglalkozó, de úgy sejtem, hogy nagyon sok kritikus rendszer futhat még CE-n.

Ha nem válaszolnék kommentben, hát küldj privátot!

"The content of this torrent file includes source code for several of Microsoft's older operating systems, such as Windows 2000, Embedded (CE 3, CE 4, CE 5, CE, 7), Windows NT (3.5 and 4), XP, and Server 2003.

The files also contained the source code of the first Xbox operating system, MS-DOS (3.30 and 6), and the source code for various Windows 10 components."

 

https://www.zdnet.com/article/windows-xp-source-code-leaked-online-on-4chan-out-of-all-places/

Ha nem tilos, kirakhatom a torrent linket. Leszedtem a 43 gigás cuccot, benne az xp forrás egy 376 megás jelszóval védett rar. Ezt írja a readme:

Including 'windows_xp_source.rar' in this collection, even though it's password
protected. Maybe someone can crack (or guess) the password and see what's
inside. The archive is bigger than the other XP / Neptune source tree. It might
be genuine, it might not. But I'm including it just in case, since the file was
so hard to track down. Original upload date seems to have been around 2007 or
2008.

The hash key is:
$RAR3$*0*c9292efa2e495f90*044d2e5042869449c10f890c1cced438

Happy cracking!

Egyre misztikusabb...

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

( Raynes v | 2020. 09. 25., p – 19:49 )

Szerkesztve: 2020. 09. 25., p – 19:57

Amennyiben ez nem a szokásos fake hír, úgy nagyon örvendetes. Nagy segítség lesz mind a FreeDOS, mind a Wine projektnek, legalább 10 évnyi fejlesztési időt is meg tudnak spórolni rajta. Nyilván licencprobléma miatt kódokat nem tudnak 1:1-ben átemelni belőle, de akkor is oltári nagy segítség a nem dokumentál API hívások és egyéb korlátok megfejtése miatt. Sokkal könnyebb az eredeti kód alapján dolgozni, mint állandóan visszafejtegetni, meg fekete dobozos üzemmódban találgatni, hogy mi hogyan működik.

A másik jó oldala, amit már írtak, hogy ez segíti az XP-n ragadtakat is, hogy váltsanak róla, mivel így még nagyobb támadásnak lesznek kitéve. Az is igaz, hogy ellenkező irányba is hathat, ha valaki elkezd unofficial támogatást csinálni újra az XP-hez, hogy életben tartsa, és emiatt nem lehet tőle teljesen megszabadulni.

Amit viszont nem értek, hogy miért most? Sőt, egyáltalán azon csodálkozok, hogy az ilyen kódszivárgások nem gyakoribbak. Ugyanis a legnagyobb multiknál is elég kétséges állapotban szokott lenni biztonságilag az infrastruktúra, nyomatják a foltozatlan rendszereket, nuku vírusirtó és frissítés, mert lassít, meg megy az SMBv1-gyel, meg jelszó nélküli megosztásokkal és hasonlókkal vitézkedés, mert azjóaz, minek paranoiásnak lenni. Pedig azt hinné, hogy komoly cégeknél ezt már megoldották normálisan.

Szerk.: vissza az egész, persze, hogy fake, most olvasom. Jelszóval védett kamu anyag, csak felcsigázni a laikusokat. Biztosan kamu, nem a jelszó miatt, de a MS-ot ismerve még ha le is védik jelszóval, tuti nem rar-t használnak erre. Felesleges is az ilyet visszafejteni, mert biztosan valami kamu anyag van benne, háttérképek, vagy random fájlok vagy ilyesmi. Plusz ezek miatt sem szeretem a Twittert, Facebookot és a többi közösségi szemetet, megosztják ezt sok fake anyagot, nem is ellenőrzik, hogy mit osztanak meg, valódi vagy használható-e. Tényleg nem értem, hogy miért jó ész nélkül a share gombot nyomkodni. És akkor pikkelnek ezekre az oldalakra, hogy az álhírek miatt korlátozások vannak, pont ez az élő példa rá, hogy miért. Sok szerencsétlen letölti, mert jajj, kiszivárgott forráskód, kincs és miután leért 3-43 gigányi szemét, jönnek rá, ha rájönnek egyáltalán, hogy csak a sávszél és lemezterület lett rá elpazarolva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Jó, de gondolkodj már el rajta, hogy aki kiszivárogtat, az minek csomagolná jelszavazott rar-ba? Mert úgy nincs értelme megosztani, hogy aztán elrejtsd a tartalmát. Ez kb. olyan, hogy meghívlak egy ingyen sörre, nagy friss korsó, hideg, habos sörike, de aztán belehugyozok jól, hogy igyad. Mondom, tipikusan fake anyag, akinek csak egy kis minimális gyakorlata is van benne, azonnal kiszúrja. Már eleve kiindulásnak túl szépnek tűnt, hogy ennyi OS kódja mind egyszerre szivárogjon ki. Ami ennyire túl szép szokott lenni, az mindig kamu.

Meg azt se értem, hogy mi ez a rar mánia is. Erről már a múltkor írtam is egy másik témában. Főleg úgy nem értem, hogy a többi kamu anyag a megosztásban 7z-vel van tömörítve, akkor ez az egy miért rar? Akárhogy ragozzuk, baromság a köbön, a belecsomagolt összeesküvéses videókkal együtt. Léccel ütném az összes ilyen RoninDey és társai nímandot, akik az 5 perc hírnév miatt megosztják meg „confirm”-özik ezt a sok fake bélsarat. Az összes accountjával együtt örökre kitiltanám ezeket az oldalról.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem, de nem is érdekel. Egy párhuzamos univerzumban, egy szintén élből komolytalan megaupload linken. Állítólag ott megvan. Állítólag. Becs szó, mert annak értéke van és ez a RoninFaxtudjaki eleve egy megbízható forrás. Senkinek nem ajánlom, hogy rápocsékolja az idejét. Mondom, fake hír, fake anyag, pár nolifernek kellett az 5 perces hírnév a Fittyeren.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Na, mert az aztán sokkal jobb, hogy lesz egy nagy halom titkosított 7z, amiből épp úgy nem tudsz meg semmit, max csak annyiban lépsz előre kettőt hátrafelé, hogy a 7-zip-es fájlokon már nem AES128 titkosítás lesz, hanem AES256. Nem mintha a zdnet olyan komoly oldal lenne. Mondom, töltsd le, meg fogod látni, hogy hókusz-pókusz.

Ha valami valóban kiszivárogna, azt nem 5× betömörített jelszavas formában osztanák meg, hanem minél szélesebb tömegnek hozzáférhetően. Egy forráskód nem indokolja sem a többszörös, sem a jelszavas betömörítést. A jelszavazás akkor kell, ha futtatható állományok vannak benne, hogy potenciális vírusveszély miatt ezek a feltöltős oldalak ne pásztázzanak bele, és töröljék automatice. De ebben plain text source code-nak kell lennie, az nem igényli ezt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen, meg van nézve, mit csináljunk vele? Ha kifizeted az időmet, én letöltöm neked, csak azért, hogy bebizonyítsam, hogy az is kamu anyag. Abban is épp ilyen lejelszavazott kamu tömörítvények lesznek. Mondom, fejezzétek be az álhírek terjesztését. Nem értem mi a jó benne, hogy mesebeli linkekkel és anyagokkal etettek hiszékeny laikusokat. Eleve már a realitásérzéketeknek működnie kéne, nagy hirtelen kiszivárog ennyi OS-hez a kód, mind egyszerre, és a MS meg nem is kommentálja.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Na csak megnéztem egyet. Ott a 7zip-en nem volt jelszó volt benne egy rakat .cab (lol ez amúgy annyira MS lenne) amiben tényleg volt valaminek a forrása amit nem néztem meg. Ami furább, hogy volt benne pár build.log is amit azért megnéztem, hát a nadima nevű user nem lesz benn megdícsérve.  (bár már biztos elévült :P) 

Ettől még persze lehet az egész ordas kamu.

@Raynes

Nem tudom Te mit tettél, amitől ennyire biztosan állítod, hogy fake a cucc, de komolyan érdekelne, hogy miért vagy ennyire biztos benne.

Én mindenesetre letöltöttem a megaupload féle 3 gigás nt5src.7z archívot és szétpakoltam, mivel ez nem volt jelszóval védett. Volt benne pár .cab file, egyet szétszedtem. Bevallom nem láttam még official ms kódot, de ez nagyon annak tűnik. A könyvtárszerkezet, a copyright a források elején, stb. Elég nagy meló lenne egy ilyen fake cuccot összerakni. No majd meglátjuk ms mit böfög.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Nem, azért annyira nem vagyok Rar-ellenes. Csak szúrni szoktam kicsit a szemem, mert 1) indokolatlanul túl van tolva, 2) tipikusan komolytalan winpistis aspektusra vall és 3) már csak akkor nagyobb ínyencség, ha pár megás részekre is fel van darabolva, hogy FTP-s retro haxxxor anyag látszatát keltse. Természetesen erre a kódkiszivárgásra sem lennék ingerült, ha valós lenne, még a rarozás sem zavarna akkor, csak egyrészt nem szeretem ezeket a fake megosztásokat, másrészt meg azt se, hogy úgy fogják itt néhány pártját, hogy ők sem töltötték le, nem próbálták ki. Jó, persze én se töltöttem le, de én pont azt mondom, hogy nem éri meg ebbe időt ölni, meg sávszélt, lemezterületet áldozni rá. Már ezekkel a hozzászólásokkal is több időt vesztegettem el a témára, mint amennyit ténylegesen érdemelne, ha meg letölteném, azzal pont azt érném el, amit a fake megosztók eredetileg akartak. Persze, cáfoljatok, ha akartok, akkor töltsétek le, ha annyira ráértek erre, de nem nagyon hinném, hogy tévedek, nagyon meglepne, az ilyen típusú fake cuccot messziről ki szoktam szúrni, általában sehogy nem kerek. Egyik kolléga letöltötte itt, olvasom, ő valami cab fájlos mókát, meg build logot talált benne, de arról sem volt eldönthető, hogy valós forráskód-e.

De ahogy nézem, trey sem szopta be, mert úgy kezdődik a kirakott hír, hogy „állítólag”, és nem úgy van megfogalmazva, hogy valójában ez történt. Mondom, nekem is gyanús volt, már először is, de annyira elragadott először a téma, hogy elaludt a gyanakvásom, majd mikor visszaolvastam ezt a jelszavazott rar-os tapasztalatot valakitől, utána lettem benne biztos.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

3) már csak akkor nagyobb ínyencség, ha pár megás részekre is fel van darabolva, hogy FTP-s retro haxxxor anyag látszatát keltse

A napokban egy Google Takeout archívumot töltöttem le, valami 30 giga körül lehetett. Úgy 100-200 KBps sebességgel csorgott a cucc. Nyilván a kétharmadánál megszakadt a letöltés, és folytatni sem tudta, én meg üvöltve szidtam mindenkinek az anyját, aki eszembe jutott.

Újrageneráltam az archívumot, ezúttal 5 gigás részekre szabdalva. Elindítottam az összeset egyszerre, egy kivételével az összes lejött, azt elindítottam újra, és másodszorra az is sikerült.

Ebben biztos van valami tanulság. :)

Egyszer csináltam ilyet: zip-ben lehetett letölteni sok fájlt egyben, de a zip-et on-the-fly állította elő a szerver. Tök jó megoldás sok szempontból, viszont sajnos nem lehet újraindítani a letöltést. Ha egyszer elszállt, akkor vége. (Nyilván meg lehetne az újraindítást is oldani, de jó bonyolult volna.) Illetve nem tudja előre a szerver megmondani mekkora lesz, ezért a letöltésnél nincs százalékos visszajelzés sem.

( uid_21365 | 2020. 09. 26., szo – 02:36 )

Most olvastam hogy a csomagban levő leglényegesebb rész egy JELSZÓVAL VÉDETT állományba van tömörítve. És a jelszót nem tartalmazza az anyag többi része.

Na ezek után a véleményem az, hogy egy kamu dologról van szó, átverés az egész. Mondjuk amúgy se töltöttem volna le mert minek, én nem használok winszart. De ezek után még annyira se érdekel hogy hír szinten, vagy hogy is mondjam, szóval értitek...

Rémségesen megdöbbennék ha kiderülne hogy a hír nem kamu. Mert hát, aki mindenáron valamiféle modern Robin Hood akarna lenni és ellopja a kódot hogy az egész világ számára közkinccsé tegye, az mi a tökömnek jelszavazná le a közreadás előtt?!

Szerintem tehát átverés az egész.

Ki is csomagoltad akkor, és megnézted benne a forráskódot? Mondom, ha ennyire nem hisztek nekünk, én letöltöm nektek, csekkolom, de meglátjátok, hogy fake, meg kifizetitek az időmet. Mert előre tudom, hogy kamu, és pont azért nem töltöm le, mert a fake megosztó pont ezt akarta, hogy minél többen belelovalják magukat, letöltsék, és jól meg legyenek viccelve, hogy feleslegesen lett ennyi hálózati forgalom generálva.

Attól, hogy valami nincs jelszóval védve, még továbbra is lehet fake. Eleve ott van benne a jelszavazott rar, mellette meg a Bill Gates videók, az egész szemvakító default fehér Windows Intéző témával illusztrálva, élből komolytalan. Eléggé meglepő lenne, ha ennyi szemét van benne, pont az nt5src lenne valódi forráskód.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Te most tényleg write only módban vagy? Egyszer már leírtam. Fröcsögsz itt, pedig csak vissza kéne olvasni egy kicsit! Ki az a "nekünk"? ("ha ennyire nem hisztek nekünk") Tök jó, hogy te vagy az "előre tudom, hogy kamu", akkor talán a lottószámokat is nyomathatnád!

Én lettöltöttem (nt5src.7z, nem teszem közzé az url-t, de a fenti infók alapján nem nehéz megtalálni), szétpakoltam, belenéztem, és én aki nem vindóz forráskód szakértő vagyok, úgy gondolom, hogy valódi. Részleteket nyilván nem teszek közzé, mert nem szeretném, hogy megáll a fekete autó és símaszkos gyúrpetik a hátamba térdelnek. Fentebb írta valaki, hogy driver kód cert is van benne, még ha le is járt, eléggé valószínűsíti, hogy hiteles. Persze lehet, hogy tévedek, neked van igazad, és fake az egész. Ha ez kiderül, akkor beismerem, hogy tévedtem.

Te mit tettél, mi alapján állítod hogy fake? Másodszor halljuk a seggszagú "kifizetitek az időmet" szardumát, kezd elég szánalmas lenni...

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Szerintem meg kell várnunk Hajzaber mérnökúrat neki még áll rendelkezésére olyan operációs rendszer/fejlesztői környezet amin lefordul. :P

De az XP legfontosabb részét - a passziánszt - kis tákolás után nekem is sikerült. (úgyhogy az tutira valid :D)

(Az is lehet, hogy a csomagban lévő környezettel egyszerű, de idegen exe-ket nem szívesen futtatok :))

Az enyémben van: kép

Vagy erre gondoltál: pasziánsz van - passziánsz nincs.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Nekem is bántja a szemem, de én csak halkan morgok egyet.

És ha valaki pusztán időtöltésként egy saját szkriptnyelvén írt segédprogramot átír GW-BASIC-be, majd azt FORTRAN66-ba? És ezek után az eredetit átírja Pythonba, majd azt Bash-szkriptbe? És mindezután az eredetit ismét átírja, de most Pascalba és ezt ALGOL60-ba? Ugye, hogy ez is normális? Egy barátom kérdezi.

Igen, write only. De kösz, hogy megnézted, ezek szerint tévedtem. Bár szerintem teljesen érthető, hogy ilyen jelszavazott, bénán tálalt szutykokra beriasztott a detektorom, és feleslegesen nem akartam x gigát letölteni, meg felhívtam más figyelmét is, hogy ilyeneket ész nélkül ne töltsön, ne osszon meg, hacsak nincs ellenőrizve a valódisága, vagy nem hajlandó saját maga ellenőrizni, ez valahol közös felelősség, és információtudatosság is egyben. Remélem érthető, nekem ez egyáltalán nem sexag. Nem vontam itt kétségbe senki hozzáértését, meg nem személyeskedni akartam, vagy titeket hergelni, egyszerűen a tálalás alapján annyira hiteltelennek tűnt, hogy feleslegesnek láttam volna akár 1 megát is letölteni belőle, nem hogy ennyi gigát, és tátott szájjal belefutni ebbe a twitteren nyomatjuk a rar jelszavas kamukat, csak olyan emberek megosztásai alapján, akik zsigerből nyomták rá a megosztást. Nyilván addig nem ugrok rá, amíg valaki nem ír róla valami konkrétat, olyan, aki ellenőrizte is. Inkább tűnjek így hülyének, hogy tévedtem, mint hogy lúzer mód beizgulva a hülyeségen lehúzzam, és utána essek arcra, hogy jól beszopattak. A zdnetes meg twitteres „szakértő”-kre nem adtam első körben, mert azoknak semmi hitele, hiszen pont ők vesznek részt az egész terjesztésében. De így, hogy ellenőriztétek, oké. Lehet akkor én is ránézek, pusztán kíváncsiságból, találok-e érdekeset a kódban.

A driver kód cert részt olvastam, de tudomásom szerint driveres rész korábban is szivárgott ki, talán májusban. Bár az még mindig nem valami bizalomgerjesztő, hogy lehetségesnek tartod, hogy tévedsz, ha most tényleg ezek a dolgok vannak benne, akkor mi lenne a tévedés?

Láttam már pár ilyen „szivárgást”, eddig mindegyik vagy teljesen kamu volt, vagy ugyan valós anyag volt, csak olyan apró részlet szivárgott ki, kisebb kódrészt, amit az ember max. a hajára kenhetett, de ment rajta a hiszti, hogy milyen durván kiszivárgott, most majd jól megtörik az egészet, amiből persze nem lett semmi. Ehhez még hozzájön, hogy az ilyen windows intézős png-s, alcohol 12946534% mdf lemezképet jelszavas winrar-ba csomagolós jóemberek megbízhatóságát és komolyságát már a torrent scene-ről jól lehet ismerni, ez, meg a Word-be jpegként beszúrt szkennelt doksik nálam már olyan intő jel, mint a nigériai herceg e-mailjei.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Inkább tűnjek így hülyének, hogy tévedtem, mint hogy lúzer mód beizgulva a hülyeségen lehúzzam, és utána essek arcra, hogy jól beszopattak

Miért, akkor mi történt volna? Mármint azon kívül, hogy egy teljesen értelmetlen vita nem történt volna meg. :D

Ehhez még hozzájön, hogy az ilyen windows intézős png-s, alcohol 12946534% mdf lemezképet jelszavas winrar-ba csomagolós jóemberek megbízhatóságát és komolyságát már a torrent scene-ről jól lehet ismerni, ez, meg a Word-be jpegként beszúrt szkennelt doksik nálam már olyan intő jel, mint a nigériai herceg e-mailjei.

Mi? :D

Windowsra volt(/van) egy Alcohol 120% névre hallgató felhasználóbarát szoftver, amivel bárki szenvedés nélkül tudott lemezképet létrehozni, csatolni és írni, beleértve némelyik másolásvédett optikai lemezt is. Társunknak valószínűleg az fáj, hogy a linuxos homokozóban bakancsban pancsikoló szabad fiatalemberek képtelenek voltak olyan egyszerűen használható szoftvert készíteni – egy amúgy nem is létező problémára –, amivel a Windows hegemóniájából egy porszemnyi darab letörhető lett volna.

:)

UNIX-ok alatt lemezképet egy könyvtár tartalmából létrehozni, kb. ennyi

mkisofs -o image.iso directory

és ez nem csak Linuxon megy, hanem *BSD, OSX, Solaris és egyéb UNIX-ok alatt is. (Egyébként windowsra is van.)
Felcsatolni meg ennyi Linux alatt:

mount -o loop image.iso /path/to/mountpoint

FreeBSD alatt:

mdconfig -a -t vnode -f image.iso -u 1 && mount -t cd9660 /dev/md1 /path/to/mountpoint

OpenBSD alatt:

vnconfig vnd0 image.iso && mount -t cd9660 /dev/vnd0c /path/to/mountpoint

OSX alatt:

hdiutil mount image.iso

Solaris alatt:

mount -F hsfs -o ro `lofiadm -a image.iso` /path/to/mountpoint

Egyszóval azokra, amiket felsoroltál, volt egysoros parancssori megoldás, UNIX-ok alatt. Erre valami egyszerű GUI-t rádobni valami scriptnyelvből, vagy UNIX shellscriptből pár perc, de valószínűleg amúgy is zsákszámra van belőlük a neten.

Oldschool Computer - http://oscomp.hu

Így van. Normális OS-en egy sorból (vagy mkisofs vagy dd, attól függően, hogy miről kell készíteni) intézhető, sztenderd formátumban, ami aztán később bárhol elolvasható. Míg az Alcohol 120% egy proprietary fizetős szoftver, ami a saját nem szabványos formátumában ment, és a felhasználókat vendor-lock-inbe köti be.

Persze ezt lehet magyarázni a windows intézős, winrarozós, alcoholozós matyiknak, úgyse fogják megérteni, hogy miről van szó. Ők csak addig látnak, hogy szép, színes ikonos a felülete, meg ők ezt szokták meg használni, és akkor biztosan a legjobb.

Egyébként Linuxon és BSD-n is megnyitható, átkonvertálható az Alcohol-féle .mdf, ott van ár az mdf2iso tool, meg a .rar állományok is kezelhetők (tesztelés és kitömörítés erejéig) unrar vagy p7zip, stb. segítségével, de ennek ellenére kicseszés ilyen formátumokat használni.

Ez az Alcohol egyébként Windowson azért népszerű, mert egy időben ez tudott lementeni kizárólag lemezképet másolásvédett CD-kről, így a warez scene elterjesztette, de jó pár ember a mai napig nem tudja elengedni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

és a felhasználókat vendor-lock-inbe köti be.

Egyébként Linuxon és BSD-n is megnyitható, átkonvertálható az Alcohol-féle .mdf, ott van ár az mdf2iso tool

Összezavarodtam egy kicsit. :)

Btw a Daemon Tools is megnyitja az MDF fájlokat, meg még pár másik, pl. a Virtual CloneDrive, még ha hivatalos supportot nem is ad az utóbbi.

Míg az Alcohol 120% egy proprietary fizetős szoftver, ami a saját nem szabványos formátumában ment, és a felhasználókat vendor-lock-inbe köti be.

Akkor lenne vendor lock-in, ha a program csak a saját formátumát támogatná.

Persze ezt lehet magyarázni a windows intézős, winrarozós, alcoholozós matyiknak, úgyse fogják megérteni, hogy miről van szó. Ők csak addig látnak, hogy szép, színes ikonos a felülete, meg ők ezt szokták meg használni, és akkor biztosan a legjobb.

Neked talán nem tetszik, és a "Linuxnál" nem szoktad meg, de ez van, amikor az emberek faszverés és egymás análintruderezése helyett valós tömegigényekre készítenek használható szoftvert.

:)

Már, hogy windózon miért egy windózos szoftver lett népszerű és nem UNIX-os megoldások? Nem tudom, ezt hogy hoztad össze, de őszintén gratulálok hozzá. Ne zavartasd magad, hogy csak arra hívtam fel a figyelmet, hogy azok, amiket bolond felsorolt, hogy ezeket windóz alatt milyen faszán meg lehetett oldani egy 3rd party programmal, azokat a többi rendszer OOB tudta, egyetlen sorból.
Vagy arról beszélsz, hogy parancssorba kell gépelni és az nem "felhasználóbarát"? Ehhez is csak gratulálni tudok. Még mindig arról van szó, hogy UNIX-ok alatt a UNIX-felhasználók hogy oldották meg azt, amihez windózon 3rd party cucc kellett; irreleváns, hogy a windózjúzerek többsége iszonyodik a parancssortól, mert nem róluk volt szó.

Oldschool Computer - http://oscomp.hu

Még mindig arról van szó, hogy UNIX-ok alatt a UNIX-felhasználók hogy oldották meg azt, amihez windózon 3rd party cucc kellett

vs

a linuxos homokozóban bakancsban pancsikoló szabad fiatalemberek képtelenek voltak olyan egyszerűen használható szoftvert készíteni

Vagy az is lehet, hogy mégsem arról volt szó, hogy UNIX-ok alatt a UNIX-felhasználók hogy oldották meg azt, amihez windózon 3rd party cucc kellett.

Túl homályosan fogalmaztam. Reméltem, hogy az "egy amúgy nem is létező problémára" élesíti az ellentmondás-detektort, ami riasztja a gondolkodás beindításáért felelős alrendszert, de nem így történt. Az én hibám, kevés információt közöltem, azt is részben proprietary formátumban.

:)

> Az Alcohol 120%-ra volt igény? Igen.

windózon? Lehet. UNIX-on? Szerinted?

> Az általad felsorolt szoftverek ugyanazt az igényt akarták kielégíteni? Nem.

Márhogy lemezképek létrehozását és csatolását? Nekem úgy tűnik kielégítik. Vagy azt, hogy GUI-val lehessen ugyanezt? Van rá GUI. Több is. Ha mást nem is, a K3B-t biztos ismered; az nem csak CD-t/DVD-t írt, de frontendként is funkcionál különféle ISO handling tool-okhoz.

BTW, ez ugyan cheat, de WINE alól megy az Alcohol. (A fizetős verziójából csak 10 éves teszt van az AppDB-ben, nyilván ma már az is menne rendesen.)

Oldschool Computer - http://oscomp.hu

Eredetileg azt állítottad, hogy azért nem sikerült csökkenteni a windows hegemóniáját, mert a túloldalon képtelenek voltak létrehozni egy olyan szoftvert, amivel ugyanazt meg lehetett volna csinálni szenvedés nélkül, mint az Alcohollal. Kiderült, hogy ez kb. úgy ahogy van, nem igaz (Ott a K3B. Működik. Úgy 1998-1999 óta. Talán még öregebb, mint az Alcohol.) és erre most azt mondod, hogy hiába van alternatíva, mert magára a UNIX-ra nem volt igény a windowsos berkekben. Egyszóval megcáfoltad a saját állításodat arról, hogy miért nem sikerült letörni a windows hegemóniájából: nem a szoftverek hiánya miatt, hanem azért, mert a windózjúzereknek nem volt igényük semmi másra, nekik számítógép = windóz.

Oldschool Computer - http://oscomp.hu

Csak a lényeget értetted félre. Akkoriban a melldöngetés mellett lehetett volna villantani is. Nem történt meg. Az Alcohol azzal villantott, hogy kezelte a másolásvédett lemezeket. A K3b mit tudott? Legjobb esetben ugyanazt, amit a Nero. Ingyen.(!!!!!!!) Már ha egy random hardverrendszer "Linux" alatti használatára kétségek nélkül rámondható volt: ingyen.

Most, hogy – újra – jól rávertük a faszt az optikai lemezekre, lehetne reagálni az eredeti felvetésre is, vagyis arra, hogy társunk azokra a szoftverekre fúj, amiket akkor szerettek meg használni a windowsos tömegek, amikor az OSS közösség kevesebb tejet szophatott a multik csecseiből, ami azzal járt, hogy kevesebb vonzó, felhasználóbarát szoftver készült egy ingyenes rendszerekre (nem írtam el). Az akkoriban villantani tudó OSS szoftverek jó része Windowsra is elkészült, ha volt rájuk igény, így a "Linux" vonzóságához kevésbé járultak hozzá. Aztán a Google odabaszott az Androiddal, végre lett egy "Linux", amire volt tömegigény. Aztán ma néhány "linuxos" ugyanazt a szar melldöngető dumát nyomatja, ami legkésőbb a kilencvenes évek végén már biztosan gáz volt. Amúgy azzal teljes mértékben egyetértek, hogy célszerű törekedni nyílt/szabad formátumok/szoftverek/stb. használatára, csak a "trágyadomb mellett aludtam" beütést illene elhagyni, ha már korábban nem sikerült. Az meg tényleg méteres hab a tortán, hogy egy "linuxos" azokat a szoftvereket fikázza, amelyek tíz-harminc éve – feltehetően – piaci alapon léteznek, – feltehetően – a használóik megelégedésére.

:)

> Csak a lényeget értetted félre. Akkoriban a melldöngetés mellett lehetett volna villantani is. Nem történt meg. Az Alcohol azzal villantott, hogy kezelte a másolásvédett lemezeket. A K3b mit tudott? Legjobb esetben ugyanazt, amit a Nero. Ingyen.(!!!!!!!) Már ha egy random hardverrendszer "Linux" alatti használatára kétségek nélkül rámondható volt: ingyen.

Mondd, te hallottál már a másolásvédett CD-k rippelésére való cdparanoia-ról, abcde-ről, valamint a DVD-k titkosításának felörésére való DeCSS-ről, meg az abból keletkezett libdvdcss-ről? A K3B ezeket is használja (ill. az abcde-t konkrétan nem tudom), kb. amióta megjelentek, egyszóval a K3B is tudta másolni a másolásvédett lemezeket. Miféle villantásról beszélsz akkor? Nem tudom, mit tudott a Nero, de amiket eddig felsoroltál, hogy az Alcohol tudta, azt a K3B is tudja a különféle command line tool-okon át.

> Most, hogy – újra – jól rávertük a faszt az optikai lemezekre, lehetne reagálni az eredeti felvetésre is, vagyis arra, hogy társunk azokra a szoftverekre fúj, amiket akkor szerettek meg használni a windowsos tömegek, amikor az OSS közösség kevesebb tejet szophatott a multik csecseiből, ami azzal járt, hogy kevesebb vonzó, felhasználóbarát szoftver készült egy ingyenes rendszerekre (nem írtam el). Az akkoriban villantani tudó OSS szoftverek jó része Windowsra is elkészült, ha volt rájuk igény, így a "Linux" vonzóságához kevésbé járultak hozzá. Aztán a Google odabaszott az Androiddal, végre lett egy "Linux", amire volt tömegigény. Aztán ma néhány "linuxos" ugyanazt a szar melldöngető dumát nyomatja, ami legkésőbb a kilencvenes évek végén már biztosan gáz volt. Amúgy azzal teljes mértékben egyetértek, hogy célszerű törekedni nyílt/szabad formátumok/szoftverek/stb. használatára, csak a "trágyadomb mellett aludtam" beütést illene elhagyni, ha már korábban nem sikerült. Az meg tényleg méteres hab a tortán, hogy egy "linuxos" azokat a szoftvereket fikázza, amelyek tíz-harminc éve – feltehetően – piaci alapon léteznek, – feltehetően – a használóik megelégedésére.

Hogy Raynes vagy a többi linuxos mire fúj, vagy sem, az nem az én dolgom. Én nem vagyok még csak ún. "linuxos" sem. Amire én reagáltam, az az volt, hogy te azt írtad, hogy nem sikerült az alternatív rendszerek fejlesztőinek a windowsos szoftverek életképes alternatíváit elkészíteniük; csak épp de, sikerült. Évekkel azelőtt, hogy windowson megszülettek volna azok, amikre alternatívát adtak.

Apropó,

> "Az akkoriban villantani tudó OSS szoftverek jó része Windowsra is elkészült"

#define "jó része". Anno ezek a szoftverek valamelyik nagyobb projekt környékén tömörültek, CDE, KDE, Xfce (akkor még XForms alapokon), GNOME, stb. Ezek többségét tipikusan UNIX-okra írták meg és nem volt windowsos verziója. K3B sincs windowsra.

Oldschool Computer - http://oscomp.hu

Tudom, hogy tudod, de az Alcohol készítői a másolásvédett szoftverek adathordozóinak másolásában látták meg a piaci rést...

Többnyire nem sikerültek olyan jól, mint amekkora a sztereotip "linuxos" arc volt.

Pl. Mozilla, MPlayer, GIMP, StarOffice, FFmpeg, mindenféle libek stb. Szinte minden értékes szoftvernek született windowsos változata, és sokuk máig él. A asztali környezetek belterjes szoftvereinek többsége senkinek nem kellett volna, hiszen volt alternatívájuk, ellenben GTK és Qt van Windowsra, mert általuk az értékkel bíró szoftvereket könnyebb több platformra fejleszteni.

:)

Lehet, de ugyanezt meg lehetett csinálni a többi platformon is.

Ha arcméretet kell vizsgálni, a windowsos világ arcméretét nem lehet felülmúlni... Azt hiszik, hogy a piaci részesedésük a minőség miatt van és véletlenül sem a marketing miatt, miközben évekkel, néha évtizedekkel kullognak a többiek mögött. Az meg pláne nem a windows érdeme, hogy a normálisan megírt kereskedelmi szoftvereknek ez a fő célplatformja, hanem nemes egyszerűséggel a piaci részesedésé, ami meg - mint leírtam - a marketing eredménye. És ez egy öngerjesztő kör: ezt használja mindenki, erre jönnek ki a kereskedelmi cuccok (meg OSX-re, de az Apple-ös ökoszisztémát nem sokan akarják megfizetni), a többiek le vannak szarva, tehát még inkább ezt fogják használni. És ennek nincs köze ahhoz, hogy mit "villantottak" az alterplatformok.

Ezek valóban crossplatformok, de ez csak pár darab. #define "értékes". Kinek mi az. GTK és Qt van windowsra, de az önmagában kevés.

Oldschool Computer - http://oscomp.hu

Biztos úgy van. Gondolom, volt értelme is, és a Wine vitte a másolásvédett szoftvereket, sőt, rengeteg idő maradt játszani, mert nem a rendszer működőképesre reszelésével kellett foglalkozni...

Biztos azt hiszik... Jahh, nincs köze, de azért a jó cuccok át lettek írva Windowsra, plusz a Google tudott sikeres platformot csinálni a "Linuxból"...

Lehet, hogy nem tűnt fel, de átlagfelhasználókról volt szó...

:)

> Gondolom, volt értelme is, és a Wine vitte a másolásvédett szoftvereket

Mert ugye csak szoftvereket terjesztenek másolásvédett CD-n/DVD-n, zenét, filmet, azt nem. (Egyébként egy részüket vitte, nyilván nem mindet.)

> mert nem a rendszer működőképesre reszelésével kellett foglalkozni...

Egyfelől, attól, hogy volt akinek nem sikerült működőképesre reszelni a Linuxot/BSD-t, attól még volt olyan is akinek sikerült, másrészt nem csak Linux/BSD van, az OSX-et nem nagyon kellett reszelgetni, ahhoz, hogy működjön, harmadfelől meg éppen a windows az, amit állandóan tutujgatni kell, mint valami rossz tamagocsit, ítéletnapig reszelheted, sose fog működni. (Oké, a winxp és a win7 már majdnem, leszámítva apróbb fasságokat, microsoftságokat, de mi van a többivel? Kiemelten az aktuális win10-zel... When do you want to update today?)

> Jahh, nincs köze, de azért a jó cuccok át lettek írva Windowsra

Egy részük. Meg megint, #define "jó cuccok". Kinek mi a jó cucc.

> plusz a Google tudott sikeres platformot csinálni a "Linuxból"...

Érdekes, nekik vajon miért sikerült? Csak nem azért, mert volt elég pénzük marketingre?

> Lehet, hogy nem tűnt fel, de átlagfelhasználókról volt szó...

Én is róluk beszéltem, ők ették meg a marketinget, nem a geekek...

Oldschool Computer - http://oscomp.hu

A hangos/videós piaci rést már betömte más. A windowsos világ már csak ilyen, nem készül mindenre ezer világmegváltó alternatíva.

Tudom, hogy sikerélmény használhatóra reszelni egy "Linuxot".

Továbbra is: átlagfelhasználókról volt szó.

Azért nem fitymálnám le, hogy felfedeztek egy jövedelmezőnek látszó piaci rést, kitaláltak rá egy koncepciót, és csapongás és széthúzás helyett megvalósították.

Szerintem sok "linuxos""geek"  is szívesen beszopta volna pl. azt a marketinget, melynek keretében a gyártótól kap drivert a hardvereihez.

:)

> A windowsos világ már csak ilyen, nem készül mindenre ezer világmegváltó alternatíva.

Ezt nem tudom honnan vetted, de ez eszelős baromság, 100x akkora felhasználótábora van a windowsnak, ennek megfelelően sokkal nagyobb fejlesztőtábora és szoftverparkja is; van bőven "világmegváltó alternatívából" windows alá is.

> Tudom, hogy sikerélmény használhatóra reszelni egy "Linuxot".

És egy windowst? Ja, azt lehetetlen.

> Továbbra is: átlagfelhasználókról volt szó.

Én is róluk beszéltem: nekik lehetetlen használhatóra reszelni egy windowst, nem véletlenül nyaggatják vele állandóan a számítástechnikusokat, hogy "javítsák meg a "gépüket"", azaz a windowst, mert az a ritkább, hogy tényleg a gép szar, leginkább csak megint kinyírták a windowst.

> Azért nem fitymálnám le, hogy felfedeztek egy jövedelmezőnek látszó piaci rést, kitaláltak rá egy koncepciót, és csapongás és széthúzás helyett megvalósították.

Te helyette lefitymáltad mások munkáját, méghozzá zéró alappal, mert mint kiderült, minden megvolt az Alcohol tudásából a túloldalon is. Széthúzás meg mindenütt van. Jópofa egyébként, hogy egy cég munkája kapcsán prézsmitálsz, hogy nem volt csapongás, meg széthúzás; pár fős fizetett csapatban miért lenne? Megvalósítani meg megvalósították a túloldalon is, amit kellett.

> Szerintem sok "linuxos""geek" is szívesen beszopta volna pl. azt a marketinget, melynek keretében a gyártótól kap drivert a hardvereihez.

Azt nem ők szopták volna be, hanem dettó az átlagfelhasználók és akkor a megnövekedett piac miatt lett volna driver oda is. Nem tudom feltűnt-e, de a droidnál pontosan ez történt.

Oldschool Computer - http://oscomp.hu

Azok csak alternatívák, nem világmegváltó alternatívák.

Megfelelőbb kifejezés a "szükségtelen".

Azt hittem azt kérdezted, milyen szoftvereket használnak ők, mik a jó cuccok.

A munkájukat sosem fitymáltam le, csak a hangoskodóik és a valóság közti ellentmondásokat firtattam.

Jah, csak a beszopáshoz abba kellett volna hagyni a faszverést. A Google csapatának sikerült visszafogni a faszverést, meg is lett az eredménye. Felesleges volt újra leírnod, amit már leírtam.

:)

> Azok csak alternatívák, nem világmegváltó alternatívák.

Akkor #define "világmegváltó alternatíva". Mert az, hogy valaki csinál egy alternatívát, az miért világmegváltás UNIX-on és miért nem az windowson?

> Megfelelőbb kifejezés a "szükségtelen".

Reszelni a windowst? Tekintve, hogy reménytelen, tulajdonképpen szükségtelen is... (Egyébként meg faszt szükségtelen, állandóan igényel valami csesztetést a windows, mindig van valami baja, ha nincs akkor csinál magának.)

> Azt hittem azt kérdezted, milyen szoftvereket használnak ők, mik a jó cuccok.

Csak rámutattam, hogy a UNIX-oknak és a fejlesztőiknek minden szart a nyakába varrsz, míg a windowsnál meg nem, ott minden fasza. Ld. még "világmegváltás", meg "azt szükségtelen reszelni".

> A munkájukat sosem fitymáltam le, csak a hangoskodóik és a valóság közti ellentmondásokat firtattam.

A valóság az, hogy a dolgok elsöprő többségére van windowson kívüli megoldás, te meg ennek az ellenkezőjét állítottad, azaz éppen a valóságot tagadtad.

> Jah, csak a beszopáshoz abba kellett volna hagyni a faszverést. A Google csapatának sikerült visszafogni a faszverést, meg is lett az eredménye. Felesleges volt újra leírnod, amit már leírtam.

A gúgelnél és a mikiszoftnál nagyobb faszverőket keresve sem lehet találni. Nem volt felesleges, mert ebből is kiviláglott, hogy mekkora kettős mércével mérsz.

Oldschool Computer - http://oscomp.hu

Windows esetén nincs meg a világmegváltás lehetőségének illúziója, hiszen millió versenytárs van, és abból száz biztosan zseni. "Linux" esetén a világmegváltás illúziója szinte szükségszerű, hiszen épp azért használ "Linuxot", mert az átlagos világ nem elég jó neki. Arról nem is beszélve, ha ettől különlegesnek érzi magát, és azt hiszi, hogy a kódolmányával egy Linus-szerű útra lép.

Opel Corsából nem lesz Ferrari.

Félreértetted.

Félreértetted.

Az Android sikeres termék lett. A "desktop" "Linux" is persze, csak nem úgy, és nem azok által, akik világmegváltást ;) vizionáltak. A közösségi "Linux" ugyanúgy sehol sincs, ahogy régen, a legtöbb érték cégek pénzén kerül bele. Hosszabb távon csak fegyelemmel lehet – piacképes – értéket teremteni.

:)

Az illúzió lényege, hogy nem vagy kapcsolatban a valósággal, ez pedig nem függ attól, hogy mennyi vetélytársad van; a windowsnak 100x annyi felhasználója van, így 100x akkora az esélye is, hogy ilyen világmegváltó marhák előforduljanak, mint Linux alatt és 10x akkora, mint OSX alatt. Ami pedig ezt a "különlegesnek érzi magát" kitételt illeti, ez leginkább a te rosszindulatú belemagyarázásod, ahogy ez a folyamatos világmegváltásosdi is. Biztos van ilyen is, de a többség azért kódol, mert a) élvezi, b) szüksége van arra, amit épp csinál, c) fizetnek neki érte. (Eme halmazok között megengedő-vagy kapcsolat van.) Nem tudom feltűnt-e, de többszázezer UNIX-os fejlesztő van a világon, de ilyen Poettering féle baromállatból, akik szétkúrnak mindent, csak párszáz. (Az más kérdés, hogy nagyon rossz helyen vannak, de az meg nem véletlen...)

Ez nem változtat azon, hogy a windows ugyanolyan "felhasználóbarátságtalan", mint a Linux, csak épp más okok miatt. Nincs már jó OS, csak szar, meg kevésbé szar. Előbbibe tartoznak a különféle hulladék szoftverek (systemd/pulseaudio/gtk3/python3-ban-a-fél-rendszer/egyéb-freedesktop-fosok) által megfertőzött Linuxok és - az xp-t és a hetest leszámítva - a windowsok.

Hát akkor mit is szerettél volna mondani?

Hát akkor mit is szerettél volna mondani?

Neked nagyon a májadra ment ez a világmegváltás, úgy látom, mert megállás nélkül ezen lovagolsz. Tudod ki volt az, aki annyira "megváltani" akarta a világot? A jó öreg billy boy. Hoci, pécét minden lakásba és windózt rá, mert az biztos jó lesz. Az eredményt látjuk. A desktop Linux üzleti piac szempontjából sehol sincs a mai napig, de mint mondtam, nem csak Linux van.

Oldschool Computer - http://oscomp.hu

Bár az még mindig nem valami bizalomgerjesztő, hogy lehetségesnek tartod, hogy tévedsz, ha most tényleg ezek a dolgok vannak benne, akkor mi lenne a tévedés?

Azért nem zárom ki, hogy tévedek, mert én nem láttam és nem ellenőriztem ezt a bizonyos cert-et, amit idéztek, nem vettem a fáradtságot, hogy megkeressem (esetleg pár másikat, lehet akad benne gazdagon). A rendelkezésre álló információk, és saját tudásom alapján gondoltam, hogy hiteles, ellentétben a Te feltételezéseiddel szemben.

Én minden ilyen "bejelentést" szkeptikusan fogadok, de mielőtt véleményt nyilvánítanák, legalább minimálisan utánanézek. Itt van pl. az sha1 collision. Megláttam, hát mondom ez egy ordas kamu. De mielőtt szétkürtöltem volna, hogy mekkora kamu, letöltöttem a két KÜLÖNBÖZŐ pdf-et, megnéztem az sha1 hash-eket, amik AZONOSAK voltak, és leesett a pofám. Én így csinálom.

De tényleg, szóljon már egy szaki, lezárva ezt az iszapbírkózást!

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Vissza az egész. Egy másik fórumon is megnézte egy olyan veterán user, akinek bízok a véleményében, és ő is azt mondta, hogy a 43 gigás fájl nagy része szemét, az XP-s forráskód része meg tényleg olyan lejelszavazott rar, amihez nincs jelszó. Egy linuxos YouTube videó, és ez ugyan ezt megerősíti, de a kisebbik, 6 gigás leakről viszont meg azt mondja, hogy abban valid kód van tényleg, 2k3, XP, 2k.

Szóval ha részben is, tényleg segszag, a 43 gigás fájlt NE töltse le senki. A kisebbik megosztással lehet próbálkozni, aki tényleg kíváncsi a kódra. Az ugyanis bizonyíthatóan valós kódot tartalmaz, legalábbis az XP-re vonatkozóan biztos.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Szerintem már élből egy oltári nagy igénytelenség, amit csak kb. „magabiztos számítógépfelhasználó” titulusú, egységsugarúak szoktak használni, főleg ebben a default formában. Egyébként azóta tisztázódott. A 43 gigás fájl korábbi leakeket tartalmaz, és egy gányolt gyűjtemény. A mostani leaket a 6 gigás megosztás tartalmazza, de az már hiteles, lefordítható a kód, de ez utóbbi megosztásban nincsenek is lámaságok, se egy rar fájl, se egy intézős screenshot, szóval meg is látszik, hogy más állította össze a kettőt. Pont ezt mondtam, de nekem nem hittétek el, hanem csak pellengéreztétek az általam írtakat.

Egyébként meg nem azt írtam, hogy tilos default témás Windows Intézőt, WinRar-t, Alcohol 120%-ot, stb. használni, mert semmilyen lámerrendőrség nem megy szál ki a helyszínre gumibotozni, hanem csak azt, hogy ha előfordul ezekkel egy komolyabb anyag, azt én hajlamos vagyok winpisti szintet szimatolva nem valami komolyan venni, és jelen esetben ez be is jött a 43 gigás megosztásnál, tehát még csak azt se mondható, hogy csak ilyen légből kapott elmélet lenne.

De enélkül is, ha valakinek odaülök a gépéhez, vagy screencastben, videón látom a rendszerét, már a testreszabás mértékéből, beállításokból, általa használt alkalmazásokból, ikonokból meg tudom könnyen mondani hogy mennyire power user, vagy mennyire egységsugarú. Legalábbis az esetek 99,99%-ában teljesen biztosan látni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Gondolom te is így használod, és ezzel belegázoltam a lelki világodba, pedig nem volt szándékos. Nem akarok arrogáns meg lekezelő lenni. Nem tudom mióta űzöd a PC-s ipart, és mi a háttered, de ha már 30+ éve tolod te is, és klasszik 8-biten, DOS-on keresztül a Linuxig megjársz minden rendszert, akkor máshogy kezdesz dolgokat látni. Ennyi.

Épp ezért írom, hogy egyébként azzal sincs baj, ha te is így használod, Windows Intéző, szemkiégető default fehér téma. Mert nem a leghatékonyabb, nem a legigényesebb, de mindenki azt használ, amit akar, szabad világ van. De, ha tőled is jönne egy jelentős leak anyag, és ezeket a jegyeket meglátnám rajta, nem venném komolyan, mert ezzel a szinttel szerintem nem kéne 1337 leak H4XXX0Rkodni, ennyi. Ezen meg lehet sértődni, pedig nem sértésnek van szánva, hanem egy megfigyelés, szemlélet kérdése.

Ez kicsit olyan, mintha elmennék Hello Kitty-s pizsamában ilyen harcművészeti összejövetelkre, és úgy próbálnám Chuck Norris-jellegű bad ass kungfu mesteri szintet előadni, hogy még a cipőfűzöm se tudom megkötni, de erőltetnék ilyen cifra pörgőrúgásokat, akkor elfogadnám, hogy bénának tűnök, kuncognak rajtam, és nem állnék feljebb, hogy de vegyetek már komolyan, mert nem lenne reális, meg csak még jobban röhögnének. Az egész oda egyszerűsödik le, hogy akármi is XY dologban az ember szintje, tudja azt reálisan kezelni.

Bár az is igaz,hogy ez néha a visszájára fordul. Néha kő profik a behúzzák, hogy egy stock-nak tűnő rendszeren nyomulnak, lamer tool-lal, hogy megtévesszék a szemlélőt. Pl. a YouTube-on van egy amerikai gyerek, aki ilyen magukat MS ügyfélszolgálatnak kiadó indiai IT scammereket szopat. Felhívja őket, hogy baj van a gépével, ezt meg azt írta ki. Kapcsolódnak a gépére. Persze a scammer azt nem tudja, hogy egy előre preparált, default rendszernek kinéző, klónozott, eldobható virtuális gépre csatlakozik, amire semmi nincs telepítve, de néhány rendszertool bat fájllal meg registry hackkel cinkelve van. A csávó közben nyomja a dumát, hogy ő kezdő, meg nem ért hozzá, erre az indiai elkezdi hekkelni a gépét, hogy túszul ejtse, és pénzt csikarjon ki, de nem hogy ez nem sikerül neki gyanús hibaüzenetek miatt, hanem a végén ő lesz visszafelé meghekkelve :D

Ennél a 43 gigás megosztásnál is el tudom képzelni, hogy igazából egy jó humorérzékű profi csinálta, de szándékosan ilyen intézős, winraros formában, hogy a sok laikusnak pont emiatt tűnjön hitelesebbnek, mert akkor a sok egységsugarú jobban bukik az anyagra, hogy igazi warez underground scene winhaxxxor stílusban van tálalva, közben meg csak jól megtréfálják, mert kamu az egész. Ahogy írtam, ez volt főként az oka, amit miatt nem töltöttem le.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

szemkiégető default fehér téma

Mindent szemkiégető fehér témával használok, legyen az Windows Intéző, IntelliJ, VS, stb., mert a dark mode rohadtul fárasztja a szemem.

Ez kicsit olyan, mintha elmennék Hello Kitty-s pizsamában ilyen harcművészeti összejövetelkre

Imho inkább olyan, mintha elmennél az összejövetelre gyári fehér karatés ruhában, vagy rallizni úgy, hogy nincs telerakva matricával a gép. :)

Akkor elég fura szemvilágod lehet, hallod. Mondom, a default Win10 témának nem is az a baja, hogy világos, mert világos témában is vannak kulturáltak, pl. vim solarized light. Hanem hogy nagy kontrasztos, rikítófehér háttéren fekete betűk, citromsárga ikonokkal. Majd próbáld ki, hogy pár óra gépezés után hirtelen csukd be a szemed, és magad előtt fogsz látni egy nagy fehér foltot.

Szerintem csak rossz dark témákat próbáltál, túl nagy vagy túl kicsi kontrasztosat, vagy túl komor feketét, stb.. Megéri ezt testre szabni, mert a szemed világa hálája meg, különösen fontos, ha napi sok órát bámulod a kijelzőt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

The Dark Side of Dark Mode

HUP Fórum téma itt.

A világos téma használatának az a trükkje, hogy a kijelző brightnessét nem szabad túl nagyra állítani, illetve mindig legyen ambiens fény ami megvilágítja a kijelző környékét. Illetve éjszaka érdemes melegebb színhőmérsékletet használni a.k.a. night mode vagy night light, de ez már valamennyire független a téma világosságától.

Szerintem ez egyéni kérdés, én pl minimum fényerőn se szeretem a világos témát, egyrészt azért mert nem tetszik, másrészt pedig tapasztalom (főleg éjszakai melónál) hogy határozottan kevésbé bántja a szememet.

Persze ettől függetlenül lehet hogy másnak erről más a véleménye, használja amit szeretne, de én örülök hogy divatba jött a dark mode témakör. Már tizensok éves linuxokban is az tetszett hogy át lehet variálni sötétre amikor még az XP is kibökte a szememet úgy virított.

( uid_21365 | 2020. 09. 27., v – 01:37 )

Jó, hát itt olvasom hogy egyesek szerint mégis komoly az anyag ESETLEG.

Aha, értem. Szóval nem kizárt hogy esetleg és netántán van némi esélye annak, hogy talán... mert a passziánsz, az benne van!

Oké. De ebből nekem nem az jön le hogy a Windows forráskódja szivárgott ki, hanem hogy a passziánszé, egy csomó eyecandy hülyeséggel együtt.

Én majd akkor hiszek a Windows forráskódjának kiszivárgásában, ha valaki le tudja fordítani azt a forráskódot úgy, hogy eredményül egy futtatható Windowst kapjon... És persze ha ebből cikk is lesz valahol, tutoriállal hogy miként lehet lefordítani meg minden!

Nem azért hogy utánacsináljam, mert engem nem érdekel a Win. De akkor legalább elhiszem hogy megvan a forráskód. Addig nem.

És mert az életem ideje drága, leiratkozom a témáról. Megyek inkább citerát gyakorolni... Nagyon megszerettem.

( kisg v | 2020. 09. 27., v – 19:10 )

Nem ellenőriztem, de tweet szerint nem konkrétan ezt használták ki az EternalBlue-ban? Vagy az csak clickbait?

Az input ellenőrzésről: sokan itt szoftverfejlesztő fejjel gondolkodnak, tehát feltételezik, hogy elég a "publikus API-ban szereplő" függvényeket mint belépési pontokat védeni, hiszen kívülről "hagyományos módon" egy privát függvényt nem lehet meghívni.

Azonban egy támadó szemszögéből bármi, ami futtatható memórialapon van potenciálisan használható kód, tehát ha pl. egy DLL-t / .so-t valaki betölt egy process címterébe, akkor onnan abból bármilyen kódot meghívhat, még a szimbólumtáblában sem kell feltétlenül szerepelnie. Ez ellen védekezni teljesen más szemléletet igényel. 

A másik, hogy egy támadónak nem szükséges, hogy a kód amit ír minden esetben működjön, elég ha már néhány %-ban sikerül, ha elég sokszor tud észrevétlenül próbálkozni.

Ugyanakkor az input (és output!) validációnak is vannak korlátai: fentebb sok vita volt pl. NULL checkről. Azt gondolom, hogy ez nem kérdés, legyen NULL check és értelmes input validáció. De legyünk tisztában azzal, hogy ez mi ellen véd, és mik a korlátai. Pl. honnan tudjuk, hogy a nem NULL érték nem szemétre mutat? Mit teszünk ha mégis? Lekezeljük-e legalább korrekt módon a SEGV signalt? Csak olyan string műveleteket használunk, ami maximum megadott lépést tesz? (pl. strnlen az strlen helyett) 

A legtöbb komolyabb szoftverben van elég kiterjedt memória validáció beépítve, de élesben ezeknek a nagy része mégis ki van kapcsolva, és nem véletlenül: ezeknek a validációknak jelentős futásidejű költsége van, ami pl. egy JS engine vagy OS kernel esetében azt jelentené, hogy az egész gép jelentősen lassabb, több energiát használ, illetve notebook esetén jóval hamarabb lemerül.

Ebből már talán látszik, hogy ez (is) egy bonyolult terület, és egyik irányból sem lehet egy félmondattal elintézni.

Ui: A grsecurity fanboyságot már úgysem mosom le magamról, de érdemes megnézni, hogy milyen fordítópluginjaik vannak, amik pont a szoftverek (illetve főleg a kernel) önvédelmét hivatottak segíteni.

Az teljes nonszensz, hogy az ellen védekezni kellene, hogy ne legyen egy program lefordított kódjában olyan, amit esetlegesen egy támadó elindítva valami csúnyaságot csináljon. Ez nem az a kategória, ami ellen "védekezni" lehet. Tehetsz te bármilyen ellenőrzést a függvényed elejére, ha én nem a függvényed elejére ugrok, hanem az ellenőrzések utáni részre. Ha egy támadó már ott tart, hogy bármilyen címre oda tudra ugrasztani a program countert, akkor már kb. bármit meg tud csinálni, nincs igazán szüksége arra, hogy legyen egy olyan kódrészlet, amit ilyen módon ki tud használni. Persze nem azt mondom, hogy tutira soha nem tud jól jönni ez, de szerintem elképesztően ritka lehet.

Olyannyira ritka, hogy itt egy Wikipédia szócikk az egyik változatáról: https://en.wikipedia.org/wiki/Return-oriented_programming

A lényege a mondandómnak az, hogy természetesen tegyünk fel zárat az ajtókra, ablakokra, és használjuk is őket (input és output validáció), de értsük azt, hogy a támadó lehet, hogy a falon vagy alagúton jön át, és ezekre is lehet és kell készülni a tervezés során, pl. processz / konténer / VM határok helyes megválasztásával.

Bónuszkérdés: hogyan csinálsz Linuxon zero-trust shared memory kommunikációt - tehát amikor nem kell megbíznia egymásban a kommunikáló feleknek? Mert a hagyományos POSIX shm esetén az író oldal mindig átírhatja a memóriát, miközben az olvasó éppen olvas. A "nem csinálok" nem jó válasz, mert olyan sávszélesség és latency követelmények vannak, hogy shm-en kívül nincs más opció. :)

It is therefore possible to search for an opcode that alters control flow, most notably the return instruction (0xC3) and then look backwards in the binary for preceding bytes that form possibly useful instructions. These sets of instruction "gadgets" can then be chained by overwriting the return address, via a buffer overrun exploit, with the address of the first instruction of the first gadget. The first address of subsequent gadgets is then written successively onto the stack. At the conclusion of the first gadget, a return instruction will be executed, which will pop the address of the next gadget off the stack and jump to it.

Tehát egyrészt kell hozzá egy hagyományos memóriakorrupciós hiba, ami eleve számtalan lehetőséget ad az exploitálásra. Másrészt innentől a támadó oda ugrik a kódban ahová akar, még az se garantált, hogy a kódot az eredeti utasításoknak megfelelően fogja használni. Vagyis innentől a hajadra kenheted a függvényeidbe írt ellenőrzéseket, azokat a támadó simán elkerüli.

Az analógiádnál maradva, a támadó továbbra is a nyitva hagyott ajtón jön be, de a házban már a falon keresztül közlekedik.

Nekem ez egy kicsit az "amúgy is szar az egész, minek tegyek én bele több munkát" hozzáállásnak tűnik. Műszaki beállítottságú, kicsit OCD-s emberként nekem ez kurva furának tűnik. Kb. minek ellenőrizzem, hogy be van-e zárva a lakás ajtaja, ha egy tankkal úgyis bejönnek a falon.

trey @ gépház

Nem, ebben a szálban teljesen másról van szó. Arról, hogy pl. egy autót úgy tervezzünk meg, hogy ne legyenek benne olyan alkatrészek, amiket rosszindulatúan összeszerelve a keletkezett valami alkalmas élet kioltására. Mert hátha ezt valaki megcsinálja, és utána megöl vele egy embert. Nyilván ez nem szempont egy autó tervezésénél.

Azaz a témánál maradva ne lehessen egy programban kis darabokból összeollózni egy olyan kódsorozatot, aminek segítségével aztán fel tudjuk törni a rendszert (persze ahhoz, hogy ezt az összeollózást meg tudd csinálni, már előtte valami védelmi vonalat már meghackeltél, mivel egy rendszer alapból nem teszi azt lehetővé, hogy a darabjait csak úgy meghívogasd). A kis darabok összerakásánál vajmi keveset számít az, hogy vannak-e ellenőrzések a függvények elején, mert egész egyszerűen az ellenőrzések utáni kód-darabokat fogom használni.

Lehet, hogy léteznek technikák ezt a feltörési metódust elkerülni, de a "teszek ellenőrzést a fv. elejére" nem tartozik ezek közé.

Pontosan értem, hogy miről van szó, az utolsó mondatára reagáltam. Most már kezded azzal védeni az input validation hiányát, hogy a támadó át tudja ugrani. Ja. Több vagy sokkal több munkával. Ennyi erővel egyetlen mitigációs technológia sem ér semmit, mert nincs olyan amit ne lehetne áthágni.

Miért nem mondod azt, hogy spórolsz a melóval? Egyszerűbb lenne, mint kifogásokat keresni.

trey @ gépház

Nem, szerintem nem érted, hogy ebbel a szálban miről van szó. Ebben az esetben semmi munkát se jelent átugrani a validationt. Épp ellenkezőleg, ez kb. alapból így jön ki a hackelésből. Itt nem arról van szó, hogy az adott ellenőrzést átugorjuk. Hanem arról, hogy a rendszer hack-elése céljából azt csináljuk, hogy egy adott fv. ne a rendeltetési helyére ugorjon vissza, hanem valahova máshova, ahol pont az a dolog van, ami a hackelés szempontjából hasznos. A "valahova máshova"-t pedig a hacker dönti el. Nyilván nem egy olyan címet fog választani, ahol ott a validáció, és a kívánt részre már nem ér el a futtatás. Hanem azt a címet fogja választani, ami már a validáció után van.

De természetesen ez nem ennyire egyszerű, mivel a kérdéses kódrészlet meghívásakor a paramétereknek úgy kell beállítva lenniük, ahogy azt a hacker akarja. Ha a stackről szedi a paramétereket a kódrészlet, akkor könnyebb az eset. De ha pl. regiszterből, akkor az adott regiszert be kell állítani a kívánt értékre. Amit mondjuk egy másik kódrészlet segítségével lehet megtenni (ha szerencséje van a hackernek, akkor lesz ilyen rész, amit fel tud használni).

 

És nem mondom azt, hogy spórolok a melóval, mert nem csak ez az egyetlen szempont, sőt. Ha technikailag úgy gondolom, hogy az adott validálás kell, akkor beleteszem, akármennyi ideig is tart lefejleszteni. De itt nem gondolom azt, hogy az adott validálás kell.

Az mondandódból az jön le, hogy érdemes a privát fv-ek inputjat is ellenőrizni, mivel kevésébé feltörhetővé teszi a kódot az általad említett módszerrel (ha nem ilyesmit akartál mondani, akkor tárgytalan a hozzászólásom). Erre mondtam azt, hogy az ellenőrzések nem számítanak ebben az esetben, mert az ellenőrzések utánra ugrok. Ez általad linkelt wikipedia cikk is kb. erről szól, hogy a fv-ekben létezhetnek olyan kód-darabok (fv-ek kilépési pontja előtt általában), amik esetlegesen segítenek egy olyan szekvenciát felállítani, amik segítenek feltörni a rendszert. Az állításomat továbbra is fenntartom, hogy ez egyrészt ritka eset, másrészt programozóként te a program írása közben erre nem fogsz tudni felkészülni. Úgy értve, hogy a kód írása közben nem fog tudni a fejedben járni az, hogy leírsz-e bármit bárhova, amit aztán később egy hacker fel tud használni. Ez nonszensz. Nem a program írását kell ez esetben másképp csinálni, hanem írod a programot úgy, ahogy szoktad, és valami más technikával biztosítod, hogy ilyen módon ne, vagy kevésbé lehessen feltörni a programot. Tehát az helytelen gondolatmenet, hogy "ide teszek egy plusz checket, mert így majd nehezebb lesz feltörni a programot". Legalábbis ezt a hackelési metódust nem igazán fogod ezzel nehezebbé tenni.

A shared memóriás kérdésed nem igazán értem, hogy most hogy jön ehhez a témához, meg magát a kérdést se igazán értem. Arról van szó, hogy nem rosszindulatból, hanem csak a kommunikáció jellegéből adódóan átírhatja a küldő fél a memória tartalmát, miközben a fogadó fél azt olvassa? Ha lockless megoldás kell, akkor gondolom ezt egyszerűen ki lehet szűrni egy checksummal a blokk végén (a checksum méretét akkorának választva, amekkorának azt az előfordulás gyakorisága megköveteli), vagy ha a lockos megoldás jó, akkor valami szinkronizációs primitívvel el lehet kerülni, hogy írás legyen az olvasás közben (pl. linuxon a semafor, vagy windowson a mutex).

 

Szerk.: az, hogy ez a technika nagyon ritka lenne, visszaszívom. Simán előfordulhat, ez az a lépés szükséges ahhoz, hogy (pár OS hívás segítségével, map) olyan kód fusson, amit már a hacker akar.

Szerintem a lockok és hasonlók nem működnek szándékos támadás ellen, mert a támadó egyszerűen nem lockolna és kész.

A példa relevanciája talán az is lehet, hogy ha mondjuk no-copy API-t akarnál csinálni Ethernethez, USB3-hoz, stb. Tehát a user processznek olyan memóriát kell elérnie, amibe a kernel, vagy akár DMA teszi az adatblokkokat. Ez elég kellemetlen komplexitással jár, ha mindezt biztonságosan akarjuk megcsinálni.

Vagy hasonló dolog volna, ha a Kernelhívásokat úgy akarnánk megcsinálni, hogy ne kelljen drága kontextus switch hozzájuk. Lehetne péládul, hogy a user processz egy round-robinba írja a kernel hívásokat paraméterekkel, és egy ilyenbe várja a válaszokat: teljesen blokkolás- és kontextusváltás-mentes API-t lehetne így csinálni, külön magon futna a kernel, és külön a user processz. Ez nagyteljesítményű kiszolgálóknál hasznos lehetne. Ha megnézed még egy epoll alapú kiszolgálónál is igencsak jelentős overhead-je van a kernelhívásoknak főleg kis üzenetek esetén. Pedig az már eleve teljesítményre van optimalizálva. Emiatt nem hülyeség ilyeneken gondolkodni.

Én megvárnám, míg a kérdező pontosítja a kérdést, mert egyelőre (mint azt írtam is) nem igazán értem, hogy jött ez a kérdés a szálhoz. Ha arra gondol, hogy mivel a memória tartalma bármikor megváltozhat, azért mindenhol csekkolni kell a tartalmát, akkor arra egyáltalán nem az a megoldás szerintem, hogy mindenhova ellenőrzést teszünk. Honnét tudja pl., hogy nem-e 2 valid darabbol összetett blokkot fog feldolgozni? Vagy 2 adott időpillanatban tök valid a csomag (checksummal ellenőrizve), csak épp különbözőek (mert a teljes csomag felül lett írva a feldolgozás közben). Ha mindenhol ellenőrzi a csomagot (checksumra), akkor ennyi erővel az elején lemásohatná egyszer inkább. Kivéve persze, ha nem fér bele a memóriába. Mindegy, nem akarok gondolkozni tovább ezen, amíg nincs pontosítva a kérdés.

Ránéztem egy kicsit a dologra, és igen, az EternalBlue-nak része az ebben a fv-ben lévő bug. De a bug nem amiatt van, mert a paramétereket nem validálja. Hanem egyszerű bug van a fv-ben belül: van egy 32 bites érték, amit aztán 16 bites értékkel update-el, a felső 16 bit pedig marad ugyanaz. Tehát rosszul update-el egy értéket, amit aztán a későbbiekben arra használ valszeg (ezt már nem néztem meg), hogy offsetként használva beleírjon a memóriába.

Nemtom mi lehet az oka ennek a bugnak, de elképzelhető, hogy ezt a kódot 16 bites OS-re írták először, és rosszul portolták 32 bitre.

( goodbyte v | 2020. 10. 02., p – 13:37 )

Na akkor , csámcsogni:

 

https://www.zdnet.com/article/windows-xp-leak-confirmed-after-user-comp…

https://pcworld.hu/pcwlite/itt-a-bizonyitek-tenyleg-kiszivargott-a-wind…

"Egy felhasználó a kiszivárgott kódot működő operációs rendszerré alakította, így bebizonyosodott, hogy a Windows XP forráskódja került elő nemrég."

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Nem hiszti, a 43 gigás, rar-t tartalmazó csomag az tényleg fake is, igaz csak részben. A másik, az a nem egészen 6 gigás csomag, amiben a WinXP, 2k3, 2k forráskódja van, cab fájlokban, az tényleg legit kód, lefordították. Vannak benne hiányosságok, pl. nem tartalmazza a winlogon-t, meg a drivereket, de egyébként működik, használható a kód, egyeznek a lefordított binárisok a hivatalos kiadásokkal. Továbbá nem csak a Megáról lehet tölteni, hanem torrentről is. Tudom, trollkodtál egy jóízűt, de csak a poén kedvéért pontosítok.

Egyébként meg én örülök a legjobban, hogy legalább részben tévedtem, és az egyik megosztás tényleg nem kamu, mert ezzel sokat fog profitálni a ReactOS, Wine projekt, sokat javítva a Windowszal való tényleges kompatibilitáson.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Úgy, hogy a kész lefordított bináris fájlokat összevetették az adott időszakban kiadott hivatalos MS lemezképen lévő binárisokkal, és bájtra és bitre pontosan egyeznek a fájlok, amit ha kiegészítesz a hiányzó fájlokkal a lemezképről, úgy bootképes rendszert kapsz. Igaz erről az összehasonlításról nincs videó, de arról volt, hogy tényleg mutatták hogy kell lefordítani, és videóra vették elejétől a végéig, hogy tényleg lefordul a kód. Tehát nem ilyen twitteres fake-elésről van szó jelen esetben, hanem tényleges forráskód került ki.

Ezt csak azért említem, mert eddig, amíg ezt nem tették közzé, addig ilyen zdnetes, nevenincs Twitter WinRar Matyiknak kellett elhinni bemondásra, hogy ők állítólag validálták, mert ők aztán valakik, meg állítólag nagyon értenek hozzá. Természetes, hogy nekik nem hittem el én se bemondásra, tök komolytalannak tűnt eddig, főleg, hogy a nagyobbik, 43 gigás megosztás egy része tényleg kamu, azt eleve ki kellett volna hagyni a híresztelésből, mert csak információs szemét, ne töltse senki.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( kroozo v | 2020. 10. 04., v – 11:55 )

> Úgy, hogy a kész lefordított bináris fájlokat összevetették az adott időszakban kiadott hivatalos MS lemezképen lévő binárisokkal, és bájtra és bitre pontosan egyeznek a fájlok

Hű, na valami ilyesmitől tartottam. Te ugye nem nagyon szoktál fejleszteni, ha ezt megetted? Mert azt szeretném mondani, hogy ha most ráböknék egy random projectre githubon, ami Cben van, és azt kérném, hogy légyszi csinálj bitre pontosan egyező binárist úgy, hogy nem ér belenézni CI fileokba, csak a sourceba, alig hiszem, hogy sikerülne. Hogy ma valaki bitre pontosan ugyanolyat fordítson, mint egy fasztudja, 20 éves bináris, hát, good luck.

Most ne engem támadjál. Én nem akarom rád tolni, csak azt írom, hogy videós bizonyíték van rá. Nem az összehasonlításra, csak arra, hogy lefordul, de ehhez képest én nem tudom, hogy mi neked abban a hihetetlen, hogy pontosan ugyanaz a bináris fordul le. Ne felejtsd el, hogy ez nem llvm, meg gcc, hogy make-kel fordítod konfigscript lefutása után, meg különböző architektúrákra fordul, mindenféle debug symbol-lal, meg dinamikus és statikus linkelési kombókkal. Ez a cucc a saját build scriptjeivel jön, egyféle megoldáson fordul 32 bit onlyra, Windows alatt, azonos beállításokkal, utasításkészletekkel, nem sok optimalizációval, így nekem egyáltalán nem hihetetlen, hogy ugyanarra a binárisra fordul, talán még valami aláírós tool is lefut fordítás után, szóval ez egy készre drótozott házi megoldás, ami így is van megtervezve. Nem véletlen, hogy a MS eltávolíttatta a videót.

Ez nem függ össze azzal, hogy én C-s githubos projektet tudok-e neked lefordítani bitre pontos binárisokká, arról én is tudom, hogy lehetetlen ebben a formában, ahogy kéred. Nyilván én nem fogok ilyen szarokat forgatni, nincs szükségem XP-re, csak annak erejéig mondtam, mert te kérdezted. Teljesen megértem, hogy kétkedsz, egyrészt nem láttad a videót, meg elsőre, ha visszaolvasol, nekem is beindult a fake detektorom, ami a nagyobbik megosztásnál helyesnek is bizonyult. Nem is arra van ez az egész forráskód, hogy a végfelhasználó forgasson magának egy rendszert, hanem ez az egész videó csak egy validáció miatt volt, hogy ne a MS-ra kelljen várni, meg noname bulvárlapos szakértőkre, mire megerősítik. Eleve nem is volt célja, hogy binárisegyezőséget is keressen, csak hogy lefordul-e, kamu-e a kód vagy nem. Ezt majd rendszerépítők úgyis széthekkelik, saját kiadásokat forgatnak majd a célközönségnek, na az majd nem lesz bitre pontos, azt garantálom. Kihekkelnek belőle egy csomó védelmet, extrákat tesznek bele, nem is lesz cél, hogy az eredeti lemezképeket állítsák elő, azt mindig is le lehetett tölteni hivatalos MS-os lemezkép formájában.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem támadlak, csak erős ellentmondás volt abban nekem, hogy a fenti teljesen jogos szkepticizmusod egy ilyen bitre ugyanaz érvttől mitől fordult meg, mert nálam legalább annyira red flagnek hangzik egy ilyen, mint a sokszáz giga forrás leak, és kíváncsi voltam, hogy van-e valami, amit nem látok.

De feljebb már más is felvilágosított, hogy felületes voltam, ebben benne van a toolchain is, elnézést, nem láttam :)

Pedig ez bitre pontosan fordul. Nem csoda, mert egyféle architektúra, egyféle utasításkészletkombóval fordul, azaz egyféle target, a MS saját compilere, .bat fájlban saját beállítások, persze, hogy ugyanaz az eredmény fordul. Pont, ahogy írod, saját toolchain teljesen, az elejétől a végéig minden be van készítve a csomagba, a forráskód mellé, kompletten fordul a cucc, saját mindenével, egészen a lemezkép legenerálásig, driverek aláírásáig. Ez nem gcc, meg llvm, mint Linux meg BSD alatt, hogy ahány compiler verzió/bináris, ahogy arch, ahány utasításkészlet, ahány optimalizáció, annyiféle bináris pördül ki, és még debug symbolokkal is cifrázva lenne.

Egyébként itt egy újabb videó, ahol a Win2003-at forgatják le, igaz itt bináris egyezőséget nem mutatják (az az XP-s videó sajnos el lett távolítva a YouTube-ról, by MS), de simán felépül neki lemezkép, ami virtuális gépben probléma nélkül bootképes. Tehát semmiképp nem kamu. Bináris egyezőség ezen a második videón nem is lehet, mert megváltoztatta a gyerek a dátumot, meg az aláírás is módosult. Egyelőre még csak kóstolgatják az illetékesek a témát, hogy hogyan lehet fordítás közben a warningok számát csökkenteni, hogy lehet a forráskódból hiányzó részeket pótolni (driver aláírás, winlogon, stb.). Majd ahogy megy előre az idő, egyre inkább simább buildek lesznek, aztán saját hekkelt editionök.

A Wine és ReactOS-nek is nagy lökést fog ez adni, igaz nekik vigyázni kell, hogy nem meríthetnek közvetlen a kódból, hanem előbb valakinek a kód alapján API specifikációt kell készítenie, míg egy másoknak tisztán ez utóbbiból clean room-os újraimplementációt. Ez nem csak a jogi védelem miatt tesz jót, de az újraimplementáció modernebb kódként jót tesz a kódminőségnek, hordozhatóságnak, biztonságnak is, az eredeti kódban sok gányolás és low level hack van, amit már el lehetne hagyni.

Bár ennek a forráskód-kiszivárgásnak van árnyoldala is. Ha nem szivárog ki a kód, akkor ez a 2k/XP/2k3 ág sokkal gyorsabban elhal, elfelejtik az emberek, ahogy látják, hogy már semmi nem támogatja, és tovább lépnek modernebb alternatívákra. Viszont így, hogy a kód kiszivárgott, meg magánban támogatott buildek és kiadások lesznek, ez bekonzerválja az NT5.x-es megoldásokat még hosszú időre, sokan nem fogják emiatt elengedni, mert végtelen haladékot kapnak. Ilyen hajbazer, flashdesinger, stb. féle emberek most már igazolva látják majd, hogy 2099-ben is XP-t használjanak. Más részről az emulátorosok dolgát is meg megkönnyíti, más rendszerek alá is jobb Win-emulátorok készülnek, ami meg a platformok közötti átjárást könnyíti meg és az ellenkező irányba hathat, aki csak azért használt XP-t, mert valami ócskasága csak azon ment, az most el tudja engedni majd. Illetve akik még mindig XP-n maradtak, főleg cégek, szervezetek, azok viszont a nyílt forráskód alapján megnövekedett támadásoktól félve most lehet dobni fogják. Nem lehet még egyértelműen látni a hosszú távú hatásokat, csak jósolgatni lehet keresztben-hosszában.

“The world runs on Excel spreadsheets.” (Dylan Beattie)