C fordítót érdemes 2-nél többször fordítani?

C/C++

Belevágtam a LFS-be és először ugye a meglévő toolokkal fordítunk forráskódot, hogy aztán az abból készült binárissal ismét lefordítsunk egy alap Linux konfigurációt.

Legyen a meglévő gcc verziója mondjuk 4.9. Legyen a letöltött gcc verziója 7.2. Az első fordítás eredménye egy 7.2-es gcc amit 4.9-es gcc-vel fordítottunk. A második fordítás eredménye egy 7.2-es gcc amit már 7.2-es gcc-vel fordítottunk -- viszont ezt egy 4.9-es gcc fordította. Lehet hülye kérdés, de van értelme még egyszer lefordítani? Vagy az output a második fordítástól kezdődően már mindig ugyanaz lesz?

( uid_395 v | 2017. 12. 25., h – 20:43 )

anyám meg salakmotoros :/
btw kérdés , mi a faszért foglalkozol ilyen dolgokkal? :)

Gyorsabb lesz-e, ha a 4.1-el fordítom le, vagy nem, mert azt már lefordította a 7.2-öt, de az meg a 4.3-at még nem, de a 4.4-el kompatibilis!!! bazmeg..

( Raynes | 2017. 12. 25., h – 20:49 )

Bazz, ezt a topikot, simán aláírásba mehetne az egész.

Ha komoly választ akarsz, már a 2. fordításnak sincs sok értelme, mivel nem nyersz rajta semmit, a 3.+ fordítás meg egyenesen baromság kategória.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

( answ | 2017. 12. 25., h – 20:49 )

Erdekes kerdes. Probald ki es vegezz mereseket!

( XMI | 2017. 12. 25., h – 20:57 )

Jóhiszemű válasz:
Nem, nem érdemes, mert a 7.2-es gcc ugyanazt a kimenetet fogja produkálni, függetlenül hogy őt mivel fordították le, legfeljebb a fordítás sebessége lesz eltérő.

Rosszhiszemű válasz:
http://delivery.acm.org/10.1145/360000/358210/reflections.pdf

A valóság valahol a kettő között van.
---
Régóta vágyok én, az androidok mezonkincsére már!

Köszi! Amúgy a tartalmát már ismertem, csak az eredeti cikket nem. Itt egy működő link: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Viszont a Gugli keresés kiadta ezt is, amit még nem ismertem: https://www.schneier.com/blog/archives/2006/01/countering_trus.html
Ez megválaszolja az eredeti kérdést is. Elég 2-szer lefordítani a fordító forrását saját magával, meg 2-szer egy másik fordítóval kezdve. Ha a 2 végeredmény binárisan egyforma, akkor a 2 fordító funkcionálisan egyforma. (Saccra szerintem azért lesznek nehézségek egyforma binárisok készítésével még normális fordítóval is.)

( joco01 v | 2017. 12. 25., h – 21:30 )

Ha egy adott C forrást fordítasz, akkor bármilyen fordítóval ugyanúgy működő binárist fogsz kapni (kivéve, ha bugos fordítóval próbálod), maximum performance tekintetében lesz eltérés. Feltehetjük, hogy a GCC 4.9 és 7.2 nem bugos, tehát mindkettő kimenete ugyanúgy fog működni, és azt is feltehetjük, hogy a 7.2 kimenete némileg gyorsabb lesz (de a megfelelő -O flag megadása sokkal többet nyom a latban).

A C nyelvben egy rakás specifikálatlan működés van, ezért egyáltalán nem biztos, hogy két különböző C fordító által produkált bináris ugyanúgy működik.

Létezik a C-nek egy subsetje, aminek a működése pontosan specifikált, ha csak ezt használjuk, akkor elvileg ugyanúgy fog működni különböző fordítókkal és architektúrákon is. Viszont ezt elég nehéz betartani, ha nincs rá ellenőrző infrastruktúra, akkor tuti nem fog sikerülni. Nem tudom a gcc ilyen-e.

Tehát előfordulhat, hogy a 4-essel és a 7-essel fordított nem ugyanúgy működik, és ez még nem is feltétlenül bug (abban az értelemben az, hogy nem specifikált működésre építő kódot nem illik írni, de mégis nagyon könnyű véletlenül összehozni ilyet).

És ez még csak a működés, a bináris pontos egyezése ennél is összetettebb kérdés. Gondolom a bináris reprodukálhatóság miatt szokás önmagával lefordítani egyszer.

Én arra tippelnék, hogy a 4-essel fordított 7-es által fordított 7-es, és a 7-essel fordított 7-essel fordított 7-es ugyanaz lesz, de mérget nem vennék rá. Ki kell próbálni :-).

(Érdekes feladat lenne olyan fordítót csinálni, ami előre megadott számú önmaga újrafordítása után stabilizálódik, addig mindig kicsit más binárist ad ki magából :-)

Ja, és azt sem tudom, hogy a gcc-nek van-e függősége, ha van, akkor azon is múlhat a működés az egyszerűség kedvéért :-).

És szerinted az egy jól megírt forráskód, ami undefined behaviort tartalmaz, vagy arra épít, hogy egy adott fordító adott módon rendez el a memóriában olyan dolgokat, amihez a forráskódnak amúgy semmi köze? Az még ezerszer rosszabb, mint egy GCCism. És saját magad lövöd tökön, ha a fordítód következő verziója alatt összefossa magát az egész rendszer. Igen, lehet ilyen szar kódot is írni, de ez ne legyen már érv.

Már csak azért sem jó érv, mert ha bugos szar a fordító, a végeredmény minden esetben random lesz, és minden esetben rossz lesz. Az eredeti kérdésre akkor az a válasz, hogy végtelen sokáig fordíthatod újra magát, akkor se lesz jó. Ha viszont a fordító jól működik, akkor bőven elég egyszer, az eredmény minden esetben ugyanaz lesz. Olyan nincs, hogy 2 újrafordítás után, vagy 10 után, vagy mittudomén, hirtelen jó lesz az eredmény.

Jól megírt, csak éppen épít arra, hogy mi a fordító és a runtime, amely környezetben működik. Az egy dolog, hogy az ilyen kód nem hordozható, de van, hogy nem is hordozhatóságra terveznek.

Én sem szeretem az implicit működést, ami a környezetből következik, de attól még miért ne lenne jó kód ez? Maga a nyelv rossz, hogy megenged ilyet.

A bugos szar fordító meg hordozható kódból is csinálhat szart, a fordító milyensége egyáltalán nem érv a szabvány szerint fordítóspecifikus viselkedéseknél.
Ugyanis a bug az nem feature. Míg a fordítóspecifikus (pontosabban platformspecifikus) viselkedés, az feature. Ne keverjük a kettőt.

A platformspecifikus viselkedés gáz, de nem bug (írtam is példaként, hogy gccism). Nem okoz olyat, hogy az 1x lefordított cucc almát ír ki, a 2x meg körtét. Hacsak nem direkt szándékosan ilyet írsz. Szerintem a GCC nem ilyen. Továbbra is várom, valaki mutasson egy olyan GCC-t, ami 1x és 2x lefordítva más kimenetet ad. Mindenki ír mindent, hogy de ez is létezik, meg de az is létezik, igen igen, de az eredeti kérdés felett elsiklunk.

Nem GCCismről/clangismről van itt szó, hanem arról, hogy szabvány szerint gépfüggő viselkedést használsz.

Például amint leírod egy C kódban, hogy char, short, int vagy long, máris platformfüggő kódot írtál. Ugyanis az int meg a long mérete szabvány szerint gépfüggő.Pláne ha mondjuk még bitműveleteket is akarsz végezni, és feltételezed mondjuk, hogy az int az 32 bit hosszú.

Mégsem nevezzük az ilyen kódokat szaroknak. Pedig platformfüggőek. Például ha van egy olyan struct, ami tartalmaz ként int-et meg egy longot, az más méretű 32 biten és más 64 biten. Azaz a kód leírásakor undefined, hogy mekkora a mérete a struktúrának, csak fordításkor kap értéket. És ez még nem is csak az a fajta undefined behavior, amit a C megenged, ez színtisztán a gépfüggőség.

Vagy te talán nem használsz int, meg long adattípusokat, csak stdint.h szerinti exact-width típusokat?

Javaban, CLR-ben (C#, VB#) nincs ilyen, ott minden primitív típus adott méretű, attól függetlenül, hogy a CPU 64 vagy 32 bites.

Ezekben igazad van, a típusos nyelvek bizony alapból OS függők. Én ezt nem tartom sem nyelvi, sem programkoncepciós hibának. Sőt: a nyelv kínálja azt a lehetőséget, hogy az adott körülmények között optimálisan fusson: ez a lehetőség bizonyos esetekben (pl futásidőkritikus esetekben) kulcskérdés.

Még sőt: ez a konkrét dolog (mármint a típusosság illetve a környezethez idomítás, lehetősége) a C nyelv egyik legnagyobb erőssége és az alacsony nyelvi szint (?= hardverközeliség) egyenes folyománya.

üdv: m.

> Sol omnibus lucet.

Javaban OS és CPU-független a típusok mérete. Egy int mindig 32 bites, egy long mindig 64 bites stb.
C#-ban (meg minden más Common Language Infrastructure nyelvben) OS és CPU-független a típusok mérete. Lásd System.Int32 és hasonló típusokat.
Haskellben eleve az Integer típus korlátlan.
Adaban meg te definiálod a típusokat, totálisan rendszerfüggetlenül.
És mégis statikusan, erősen típusos nyelvek ezek.
Te mondtad, hogy a típusos nyelvek alapból OS-függők, pedig ez nincs így.

Azért erősen hatékonyságnövelő, ha a számábrázolás igazodik a hw architektúra kötöttségeihez. Sok számítást igénylő feladatok ezt remekül igazolják. Tehát a JavaScript vagy java baromságai nem annyira számítanak itt. Amint komoly feladatokról, adatfeldolgozásról beszélünk, rögtön jó, ha az első mondatomat figyelembe vesszük. Persze lehet javaban is hekkelni ilyesmit, de az olyan is lesz.

Ettől még igazad van, ha szó szerint értelmezzük azt, amire válaszoltál. :) De nézzünk néha a dolog mögé is.

Ez az érv nem állja meg a helyét. C-ben valóban gyorsabb programot lehet írni, mint Java-ban, de ennek nem az az oka, hogy a típusok mérete nem fix. Valójában ha _működő_ programot akar írni valaki, akkor a számábrázolás pontos ismerete elkerülhetetlen. Az, hogy egy változó lehet 16 vagy 32 bites is semmilyen előnyt nem jelent, egyedül csak kavart. Ugyanis amikor programot írunk, akkor minden változóhoz megtervezzük az értékkészletét, és aszerint választott bitszámban kell ábrázolni a számot. Az értelmesebb szabványok meg is követelik, hogy egzakt bithosszokat használjunk kizárólag.

Aminek minimális értelme lenne, ha lenne olyan típus, ami adott bitszámú, de az overflow és esetleg a negatívba fordulás nem specifikáltan működne. Ezzel ki tudná a fordító használni az architektúra specifikus kiskapukat, viszont a felső bitek a programból elérhetetlenek lennének, és nem bíztatná a programozót hibás program írására. Amit sajnos "sima" C-ben rendszeresen elkövetnek. Számtalan program van, ami arra épít, hogy az int legalább 32 bites, pedig valójában csak 16 bit garantált.

C-ben valójában azért lehet gyorsabb programot írni, mint például Java-ban, mert vannak struktúrák pointerek és malloc, amik a hatékony memória elrendezéseket lehetővé teszik a programozó számára. Ezek híján a Java programok a legtöbb változót több indirekción keresztül érik el, illetve cache-re nem nagyon lehet optimalizálni.

A számábrázolás igazodása a hw architektúrához nem az értékkészlet miatt fontos, hanem a rajtuk végzett műveletek sebessége miatt. Csak emiatt, de emiatt nagyon. Ez az egyik oka a gyorsabban futó eredménynek. A másik oka, hogy az adott architektúrára optimalizált kódot fordít az azon futó, arra készült compiler. Nincs futási időben semmilyen machináció, csak a futás. Ez a hordozhatóság mánia sok kárt okozott és fog okozni. És soha nem tud megvalósulni 100%-ban.

Szerintem magad sem érted, mit akarsz kifejezni.

Adva van egy kód, amiben a változók pontosan olyan hosszúak, amilyen hosszúnak lenniük kell.
Mert az, hogy egy változónak 32, 64 vagy 16 bit kell, azt a feladat határozza meg, és nem a CPU.

A JIT compiler meg ugyanúgy CPU natív utasításokat fog abból fordítani, hogy 32 bites, 64 bites vagy épp 16 bites memóriaterületeken illetve regisztereken kell műveletet végeznie. A JIT compiler pontosan úgy tudja, hogy ő ARM, X86, X86_64 vagy ARM64 architektúrán fut, mint az AOT compiler.

X86 architektúrákon amúgy van egy olyan szorzás, ami 64 bitekből 128 bitet csinál. Ez nagyon hasznos művelet lenne, ha például sokbites aritmetikát akarunk írni (fraktál ábrázolás, RSA, stb) és tudtommal még C-ben sem lehet kihasználni, csak ASM-ben.

Java-ban tuti nem lehet kihasználni, mert nincs is 128 bites típus.

Egyik barátom elég sokat szórakozott ilyenekkel (fraktálrajzolós programot írt), nézte, hogy mit hoz ki a Java aritmetikából, és az jött neki ki, hogy ha nagyon ráfekszik (loop unroll kódgenerátorral, rengeteg local változó, stb), akkor nagyon meg lehet közelíteni a C-t.

De magasszintű trükkökkel (közelítések, nagy fekete területek levágása, stb) sokkal többet lehetett optimalizálni, mint ilyen alacsonyszintű trükkökkel.

Azon programok köre tehát, ahol a számábrázolás optimlaizálás számít nagyon szűk. És azokat is be lehet natív libként rántani Java alá (JNI), amikor nyilvánvalóvá válik, hogy ez a szűk keresztmetszet.

"Java-ban tuti nem lehet kihasználni, mert nincs is 128 bites típus."
Jaja, mert BigInteger nem létezik, valóban.

Ha a mulq utasításra gondols, akkor a HotSpot JIT tudja, generál is mulq utasítást, ha kell. A HotSpot nem hülye azért :)
http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/166d744df0de

De persze ismerni kéne a Java-t. Sokan lenézik a HotSpotot, mert még azt hiszik, hogy a HotSpot még mindig Java 1.2-nél tart. De azóta eltelt 20 év.

Az igaz, hogy direktben nem lehet kihasználni. De nem a direkt használat a lényeg. Hanem a belőle képzett kód, amit a CPU végrehajt.

C-ben sincs amúgy 128 bites típus, az stdint.h-ban ilyen nincs.

A kód szintű hordozhatóság óriási érték tud lenni. Például beágyazott termék fejlesztésének jelentős része megtehető PC-n "szimulátorban", ha a kódod hordozható C. Ezzel rengeteg munkát (pénzt) lehet spórolni, és azáltal, hogy kerülöd a "dodgy" működéseket a minőség is javul. Ha pedig a következő termékverziód másik processzorra kerül, akkor csak a HAL layert írod újra, és minden működik tovább.

Hasonlóan, ha a cuccod működik ARM és PC platformon is, akkor az ár alapján döntheted el, hogy melyikből építed a terméket.

Még politikai szinten is hasznos: eldöntheted, hogy Trump, Putyin vagy a kínaiak csipjeire építed az államigazgatást :-).

(Ez nagyon mellékszál, de ez megütötte a szememet)

> Számtalan program van, ami arra épít, hogy az int legalább 32 bites, pedig valójában csak 16 bit garantált.

Amikor én tanultam, akkor mintha csak ennyi lett volna:
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

(Én ráadásul dolgoztam is olyan C-fordítóval, ahol sizeof(char|short|int) = 8 sizeof(long)=16 volt érvényben. De ez nyilván nem ma volt.)

Az melyik szabvánnyal jött, hogy az int legalább 16 bit?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Annó ANSI C-t tanítottak nekünk. Ott "az architektúra számára legkellemesebb" volt még a definíció.
Emlékeim szerint a C99 szigorított ezen. Ekkortól van a short-ra a 16 bit és ugye short <= int.

Ha netán a 8 bites architektúrával van dolgod, az int itt is 16 bites lett a C99 beszivárgása óta. Ellenben ha például avr-gcc fordítóval fordítasz 8 bites AVR-re és az int-re 8 bitest szeretnél, akkor "avr-gcc -mint8".

Egyébként a C99 szabványtól az architektúrafüggő int mellé bejött olyan is, hogy 

#include <stdint.h>

int8_t a;         // 8, 16, 32, 64 
int_least8_t b;
int_fast8_t c;

intptr_t d;       // lásd még: size_t

és unsigned megfelelői.

Az állításom nem volt hamis, maximum nem eléggé jól megfogalmazott. Azt írtam, hogy HA nem bugos a fordító, AKKOR nincs értelme többször újrafordítani saját magát (ha-akkor logika, teccikérteni?). Bugos alatt azt értem, hogy természetesen ha valaki direkt azt akarja, lehet olyan (szar) kódot is írni, amire ez nem igaz (tehát kihasználod egy fordító/nyelv nem definiált viselkedést). De ki tenne ilyet és miért? Azt továbbra is nagyon erősen gyanítom (de nem ellenőriztem le), hogy a GCC nem ilyen. Tehát a GCC következetesen fordít. Akárhányszor fordítod újra saját magát, ugyanúgy fog működni. Lehet, hogy a bájtkódban, vagy a performance-ban mérhetetlen kicsi különbség lesz, de a definiált C nyelv keretein belül határozottan ugyanúgy fog működni. Ez volt a nyitó kérdés, erre válaszoltam, hogy nem, nem érdemes újrafordítani a GCC-t saját magával.

Azt szeretném kérdezni, hogy te mivel vitázol? Avval, ahogyan megfogalmazom az állításomat? Jó, lehet vitázni arról, hogy a nem definiált működést alkalmazó+GCC verziók között eltörő+hordozhatatlan kód szar-e vagy sem, aki így szeret kódolni, hajrá. Vagy avval vitázol, hogy milyen következtetésre jutottam? Szerinted ha egy GCC 1x illetve 2x újrafordítasz magával, lényegi szempontból eltérő lesz az eredmény? Pl. az első eredmény egy C fordító lesz, a második körben már egy képernyővédő, a 3. újrafordítás után a Quake II? Vagy a 3x újrafordított GCC máshogyan fogja értelmezni a char típust? Vagy ha 1000x újrafordítod, akkor annyira optimális lesz az eredmény, hogy fénysebességgel fog fordulni minden? Én továbbra is a téma nyitókérdésére keresem a választ.

A kérdés inkább az, hogy te mivel vitázol? Senki nem állította, hogy lényegi szempontból más lesz. A disztrók azért szokták magával újrafordítani, hogy binárisan reprodukálható eredményük legyen.

Ennek például megvan az az előnye, hogy akár független harmadik fél is ellenőrizni tudja, hogy a fordítás során nem piszkáltak bele a binárisba.

A második újrafordításnak meg az az értelme, hogy leellenőrizzük, hogy esetleg nem néztünk-e be valamit, és valóban reprodukálható-e a kimenet binárisan.

Azon lehet vitatkozni, hogy van-e értelme LFS-t csinálni, és hogy van-e értelme mindezt ilyen szinten jól csinálni pusztán hobbiból. De hogy így kell jól csinálni, az tuti.

( gejzir | 2017. 12. 25., h – 21:31 )

Anno 98-ban DEC Alpha processzorra fordítottam gcc-t, az alap rendszer C fordítójával. Addig kellett újrafordítani az új gcc binárissal a forrást, amíg az ellenőrzés ki nem írta, hogy minimális az eltérés a 2 fordítás között.

Próbáltad diff-elni a két utolsó binárist?

Ezt gondold át megint.

Ha a fordító úgy van megírva és paraméterezve, hogy reproducible build-eket készít (vagyis azonos input mellett bitre azonos az output is), akkor nincs értelme újrafordítgatni.

Ha nem reproducible (pl. van valahol egy timestamp, vagy a metódusok sorrendje random), akkor az idők végezetéig fordíthatnál, mindig lesz random méretű eltérés (ugyanakkor számottevő, működést befolyásoló eltérés viszont sosem lesz).

Márpedig így kellett a hivatalos install guide alapján. Én is csodálkoztam az elején, de legalább 3x kellett újrafordítani (98-at írunk).

Most utánanéztem, ezt már magától csinálja a make, ha nulláról forditod a gcct.
https://gcc.gnu.org/install/build.html

Az volt a szitu, hogy volt egy vadiúj DEC alfa, ahol csak C fordító volt gyárilag. A gyári C++ fordító nagyon drága volt, a projektbe nem kalkulálták bele. Mondtam, hogy akkor fordítok rá gcct, hogy legyen C++. A gyári support mérnök persze hisztizett, hogy csak a gyári compilerrel lesz megfelelően optimalizálva a bináris a processzorra (amiben egyébként volt igazság).

Több fordításnak lehet értelme, a bináris nem volt minden fordítás után ugyanaz. Először a gyári C fordítóval kellett lefordítani a gcc-t, aztán az új binárissal saját magát, aztán az új binárissal még egyszer az egészet. Lehet, hogy közben kellett optimalizációt is váltanu, de ebben már nem vagyok biztos.

Megnézve a linket amit küldtem, ott volt a válasz a kérdésedre. Kiderül, hogy teljesen igazad van, és az is igaz amit én írtam.

Az 1. fordítás a gyári C fordítóval történik. A 2. fordítás már a lefordított GCC-vel, a 3. fordítás pedig ellenőrzési célt szolgál.

"If the comparison of stage2 and stage3 fails, this normally indicates that the stage2 compiler has compiled GCC incorrectly, and is therefore a potentially serious bug which you should investigate and report. (On a few systems, meaningful comparison of object files is impossible; they always appear “different”. If you encounter this problem, you will need to disable comparison in the Makefile.)"

Régen az ellenőrzést kézzel kellett csinálni, erre emlékeztem.

( juuzer | 2017. 12. 25., h – 22:54 )

Többszörös fordítást ellenőrzés miatt szoktak csinálni. Ha lefordított fordító 2-3 lépcsőben képes magát reprodukálni, akkor működőképesnek tekinthető.
Ha gcc-t váltasz, célszerű egyből libtool-t, llvm-et újraforgatni friss gcc-vel.

( Oops | 2017. 12. 26., k – 07:15 )

Off:

Tudjátok, a hozzászólásokból megint az jött le nekem, hogy aki informatikus és olyan nagyon biztos a dolgában, az még tapasztalatlan. (Akinek meg tapasztalatlansága mellet arroganciája is magas, az sajnálatra méltó.)

Ahogy öregszem, azt tanultam meg - és tanulom folyton -, hogy, bár láttam már karón varjút, sőt, fűben nyuszit is, nagyon hamar botlok elméletileg is váratlan dolgokba, és ezért óvatosan nyilvánítok véleményt és tisztelettel állok a kérdésekhez. Sokszor azt látom egyébiránt, hogy az ügyfél ezt először bénaságnak gondolja, gondolom azért, mert aki ért hozzá, az mondja meg a tutit azonnal:)

Én ahogy öregszem, egyre magabiztosabb vagyok, és apróságokon való fennakadás helyett egyre fontosabb dolgokra koncentrálok. Ha bejön egy apróság, amit nem vettem figyelembe, és gondot okoz, alázattal bevallom és tanulok belőle.

Amíg nem mutat nekem valaki egy olyan friss, stabil GCC forráskódot, ami kétszer fordítva eltérően működik, addig ezt egy mérsékelten érdekes, de inkább egyáltalán nem fontos kérdésnek tartom (ugyanakkor én se támogatom a kérdezőnek való durvább beszólást). Lehet, hogy valaki 10 vagy X éve látott ilyet, elhiszem. De rengeteg fejlesztő rengeteget dolgozott azon, hogy a GCC be legyen bugos, és én alapvetően bízok bennük.

Úgyse tud senki olyan N számot mondani, hogy "N-szer történő újrafordítás után fog jól működni a cucc" (maximum egy minimális performancia javulás fog változni +1 kör után, de a működés nem). Innen kezdve elég fölösleges az egész.

Igen, ugyanez a megfigyelésem.

Már 20 éve tanítom az ifjú padawanokat nagy rendszerek tervezésére, fejlesztésére; 4-5 éve, az y és z generációnál vettem észre a túlzott önbizalommal vegyes arroganciát. Most ha valamelyik megcsinált már 2 weboldalt minimális belső logikával egy tutorial alapján, abból vezeti le az egész világot.

Van az a mondás a magabiztossággal, kétellyel, okosakkal, hülyékkel. Én nem fogalmaznék ilyen sarkosan, de van alapja. :)

Szuper, akkor az évszámokról lehet vitatkozni, bár minek. Definíció szerint a Z generációsok azok "a nemzedék, amelynek kialakulásában a technika száguldó fejlődése játszott rendkívül fontos szerepet." (Wikipédia) Nem évszámtól számítják, nem az életkor számít. Mármint a Wikipédia szerint és szerintem.

Pedig számít az évszám, ennél nem lesz egyértelműbb:

"Ebből kiindulva az 1920 és 1939 között születettek az ún. veteránok, a Baby boom-korszak az 1940 és 1959 között született embereké, míg az X generációhoz az 1960 és 1979 között születettek tartoznak. Az Y generációba az 1980 és 1999 között, a Z generációba pedig a 2000 után születetteket sorolják."

--
Mobilbarát és reszponzív weboldal készítés

There are no precise dates for when this cohort starts or ends, but demographers and researchers typically use the mid-1990s to mid-2000s as starting birth years.
Forrás: https://en.wikipedia.org/wiki/Generation_Z

A német wikipédia is csak a "There are no precise dates"-t erősíti:

Als Generation Z (kurz Gen Z) wird schlagwortartig die Nachfolge-Generation der Generation Y bezeichnet. Ihre Mitglieder kamen von etwa 1995 bis 2010 zur Welt.[1][2] Andere Klassifikationen fassen die Jahrgänge 2000 bis 2015 hierfür zusammen.[3]
Forrás: https://de.wikipedia.org/wiki/Generation_Z

Ez az egész generációs dolog elég off topic itt. De hogy én se maradjak ki belőle: :-)

Ennek az egész vitának nincs semmi értelme. Az eddigi generációk mind 20 évet kaptak. Így, ha a tendencia folytatódik, akkor 2020 körül érkezik a következő generáció. Zs? A? Teljesen mindegy, hogy 2020-tól, vagy 2022-től fogják számolni az új generáció megjelenését. Utána már a mostani Z generáció fog azon dolgozni, hogy megteremtse az őt követő generáció jövőjét. Tehát a Z generációnak van még 2-3 jó éve. :-)

Egyébként társadalmi szempontból (a technológiától és technikától függetlenül) úgy számoltak, hogy egy családban 25 évenként követik egymást a generációk. Azért, mert az embereknek ilyen idős korukban általában már volt egy két gyermekük, és sokan már nem is vállaltak „idősebb” korukban többet. Ehhez képest most már az első gyermek érkezése sokaknál csak 30 éves kor után várható. Tehát a családi generációk inkább már 30-35 évenként fogják követni egymás.

És ha már off topic: Ennek lesz egy olyan, valószínűleg nem kívánt mellékhatása, hogy a jövőben kb. 65-70 éves korában fogja karjába venni az ember az első unokáját, és csak kevesen fogják megélni, hogy az unokájuk leérettségizik.

Itt egy pszichomókus elég jól összefoglalja:
https://www.youtube.com/watch?v=h4EWxAaz0Fg

Megpróbálom a problémás egyedek viselkedésének esszenciáját összegyűjteni, szóval csak negatívumokat írok.

A túlzott önérzet szinte mindig gond volt. Félreértés ne essék, én szeretem az önálló embereket, de itt szinte kezelhetetlenül a saját fejük után mentek, nem volt csapatjáték.

Általánosan igaz, hogy az aktuális hype-ok mentén gondolkodtak - HDD Hype Driven Development, mindig abban hittek, amit utoljára olvastak a kedvenc technikai blogon, mindenki más véleménye hülyeség. Volt, hogy országos, vagy akár nemzetközi rendszert akartak átírni évjárattól függően PHP-ba, RubyOn Rails-be, Erlangba vagy NodeJS-be. :) Az mindegy, hogy az adott rendszerben kb. 40 emberév munka van már.

Olvasták a szilikon völgyi színezett sztorikat és állandóan ingyen irodai gyümölcsöt, csokit, csapatépítést, filmvetítést, közös irodai melléktevékenységeket szerveztek, sokszor a munka rovására.

Viszont tipikusan a legnagyobb hangú srácoknál a teljesítmény "meg nem gyütt". Sokszor a tényleges feladatmegoldás helyett keretrendszerek, pár soros proof of concept kódok tesztelgetésével és lényegtelen funkciók reszelgetésével szórakoztak. Rendszeres volt az adott feladatra tervezett idő háromszoros-négyszeres túllépése, majd az utólagos magyarázkodás. Arra hivatkoztak, hogy irreálisak a határidők. :) Volt olyan, hogy a szerintem 2 napos feladatra kaptak egy hetet (5 napot), majd mikor meg akarta magyarázni az aktuális delikvens, hogy rosszul lett tervezve a feladat, leültettem magam mellé a 3 fő hangadót és 6 óra alatt előttük végigcsináltam a feladatukat. Az hatott kb. egy hónapig. :)

Az a baj, hogy 1-2 hangadó nagyon meg tudja mérgezni a munkahelyi légkört.

az egész generációs felosztás egy marketing bullshit.
videó előre: https://www.youtube.com/watch?v=xbt99rhf6zc

persze, én is szeretem azt gondolni, hogy az én még hátde, de aki márcsak egy évvel később született, az már hátdenem, de... ez minden korosztály saját érzése volt a történelem folyamán, hogy ő többet ér, mint aki utána született.
(lásd az idézett magazin címlapokat az elmúlt ~50 évből a fenti videóban)

amivel valszeg találkozol, hogy az info ma egy tömegszakma lett, mindenkit felvesznek dolgozni, és becsúszik olyan is, aki ~20 éve lapátot támasztott a patak szélén.
ezt hajlandó vagyok aláírni - de ez nem generációs probléma, ez az IT problémája, s nekünk, azt IT-soknak kell megugrania.

Jól van, akkor megnyugodtam. Nem vagyok informatikus, csak szimplán arrogáns ezek szerint, de akkor legalább tapasztalatlannak nem vagyok mondható a definíciód szerint.

Továbbra is tartom, hogy a topik hülyeség, mondvacsinált, generált, nem valós, nem életszerű probléma. Eleve ott van benne egy mocsok nagy csúsztatás, hogy „mondjuk” 4.9-es gcc-vel fordul le először a gcc a topiknyitó szerint. De ki a fa-rock mondaná ezt, ráadásul mindjárt királyi többesben? Mindjárt azonnal lehet 7.2.1-es binárissal fordítani a legalább ilyen friss vagy még frissebb forráskódot LFS-hez és Gentoo-hoz is, és nem kell többször újrafordítgatni, meg lehet lépni, még senkit nem vitt el a mentő miatta, hogy védőfelszerelés nélkül mindjárt friss gcc-vel fordított, és nem pocsékolta a saját idejét. De ha nem is 7.2.1-essel, de valami késői 6.x-essel, akkor sem a Biblia előtti időkből származó verzióval, azok a debianosoknak valók.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Jaja, tapasztalt arrogáns vagy.

Nem akartam személyeskedni olyan nagyon, meg hát nem te voltál, aki igazán csúnyákat mondott, ezért is nem válaszként, hanem hozzászólásként írtam, de most már így, hogy végre megnyugodtál, téged sem került el a rock, be kellett szólnod egy komolyabbat is a topicnyitónak.

Nem a szakmai igazadat vitatom, én hozzá sem tudok szólni ehhez a kérdéshez. De miért gúnyolod ki azt, aki (szerinted) butaságot kérdez? Miért jó az neked? És ha már jó neked, hogy más alacsonyabbrendűségén elmosolyodsz, akkor miért nem teszed mindezt úgy profi módra, a bajszod alatt? Miért jó, hogy a debianosoknak is beszólsz,
most gyorsan? (Figyelj, ezek kérdések voltak.)

Elnézést, lehet kicsit keményre sikerült a hangnem. Csak fel tudom magam húzni hülyeségeken, és ez nem is anyira a topiknyitó által feltett kérdésre vonatkozik. Elhiszem, hogy nem akart vele rosszat, és benne mindez kíváncsiságból felmerült, hanem hozzájött az utána a témát védő néhány szakértő, akik szerint ez egy teljesen jogos probléma, többször érdemes fordítani, aki ezt nem ismeri be, az arrogáns, tapasztalatlan kezdő.

YouTube-on is volt most egy hasonló téma, egy magát hifista szakértőnek valló jenki elkezdett okoskodni egy egyik techmoan videó alatt, hogy a FLAC az nem veszteségmentes, mert annyira tömörít, hogy annyi infó nem férhet bele a headerbe (?), biztos valahol csal, meg csak 16 bit / 96 kHz-es mintavételezést támogat. Ráérő, türelmes emberek linkekkel elmagyarázták neki, hogy miért nincs igaza, igenis lossless, 32 bites felbontást, meg 655 kHz-et is támogat, erre nyomja tovább az okoskodást, hogy stúdiókban is azért használnak wav-ot meg DXD-t, mert azok veszteségmentesek, míg a FLAC igazából nem, csak valami kommersz Wav-utánzat, meg az ő 3500 kbps-os Wav fájlai jobban szólnak a FLAC-nál. Most erre is kapott magyarázatot, hogy a FLAC-nál CPU-idő megy el a ki-be tömörítésre, azért nem használják a stúdióanyag feldolgozásánál. Még nem néztem vissza, de már előre látom, hogy erre is ki fog találni valami okosságot, hogy valami 1972-es ukrán hifibüfi magazinban olvasta, hogy valakinek az ismerőse látott olyat, hogy valaki egyszer az ABX teszten hallott különbséget a Wav meg a FLAC között, anélkül hogy találgatni próbált volna. Csak azt nem értem, hogy ki engedi ezeket netezni. Ennél már csak az súlyosabb, mikor egy másik szagértő is becsatlakozik az ilyenekhez, segíteni védeni a szakmai hülyeséget.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

+inf. és BÚÉK :-)

Erről mindig az az eset jut eszembe, amikor egyszer felvettem egy "profi" C++ fejlesztőt és a kódjából úgy tünt, hogy szerinte az include "akarmi.h" és include < akarmi.h > ugyanaz...
Amikor rákérdeztem, hogy tudja-e mi a különség, azt mondta semmi. Ezen kiakadtam, mert ezt még én is tudtam, pedig nem vagyok profi C++ fejlesztő. De nem ez volt a fő gond vele, hanem, hogy nem hitte el nekem, hogy különbség van köztük. Helyette nekem esett, hogy én nehogy megmagyarázzam már neki, ő már évek óta C++ fejlesztőként dolgozik... Ezek után elbúcsúztam tőle, nem azért mert nem tudott programozni, hanem a hozzáállása miatt.

( iattilagy | 2017. 12. 26., k – 10:49 )

Eltérés max. akkor lehet ha bugos, mert túl régi a másik gcc és nem támogat valamit rendesen (azért a compiler nem egy egyszerű szerzet, tele van specifikus hekkel a forrás). Szóval lehet, hogy olyan létezik, hogy ki kell kapcsolni valamilyen optimalizáló flaget, utána meg újra forgatni a kimenettel bekapcsolva a flaget. Viszont az új gcc optimalizálhat jobban, ezért gyorsulhat a fordítás, ami nem feltétlen marhaság.

( sigellef | 2017. 12. 28., cs – 10:13 )

elméletileg: egyazon programot fordítva, ugyanozon beállításokkal ugyanazon procira, ugyanazon rendszerre, bitre pontosan ugyanazt kéne produkálnia a két eltérő verziójú fordítóknak.
gyakorlatilag: fölösleges diff-fel hasonlítgatni, mert a fájlméretek is eltérőek.

viszont: egyazon verziójú fordító, ha más-más verziójú fordítóval lett lefordítva, hiába tér el binárisan, a velük fordított program ugyanaz lesz.

Tehát: ha a glibc-től eljutottál a gcc-ig, érdemes újrafordítani, kivéve akkor, ha a tool-ban is ugyanazt a verziójú gcc-t használod.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

" bitre pontosan ugyanazt kéne produkálnia a két eltérő verziójú fordítóknak."
Ez nem igaz.
Például ha a forráskód tartalmazza a __DATE__ vagy a __TIME__ szabványos makrót, akkor azt a preprocesszor mindig és mindig más értékre bontja ki, a fordítás idejétől függően.

Elég, ha az újabb kiszúr olyan párhuzamosítható műveletsort, amit az előző még nem, vagy amit az előző elrontott - és új programverziókat általában azért adnak ki, mert az előző valamit nem még tudott, vagy nem tudott elég jól (ami nem kell, hogy de facto bugot jelentsen).
Egy fordító esetében nem kötelező, hogy a bináris végeredményre vonatkozzon az újítás/jobbítás, de legalábbis nem szentségtörés azt is várni.

Két eltérő verziójú C fordító közül az újabb gyakran tud még olyan gyorsítási trükköket, amit a régi nem. Ez lehet utasításbeli (pl. AVX alkalmazása), vagy pusztán utasítás idők alapján másképp számolja.

Elnagyolt példa egy ősrégi és egy mai C fordító eltérő kódjára: 

int modulo10(int number) {
    return number%10;
}

Ezt réges-régen a "div" assembly utasítással tanultuk, amely az EDX:EAX regiszterpárban levő értéket elosztja a div argumentumával. Eredmény EAX-ben, maradék EDX-ben. Ez utóbbit adja vissza a függvény elvileg.

Viszont ha a fenti kódot lefordítod GCC-vel, akkor abban nem lesz div, annál inkább szorzás, szándékos túlcsordulás, shiftelés, kivonás, összegzés. Ennek segítségével a proci a hardveres DIV utasításánál gyorsabb megoldást tud csinálni. Furcsa elsőre, de nézd meg magad is, hogy mit fordít belőle a GCC -O2 hatására.

A fenti egy elnagyolt példa, már régen nem div-et használ erre a GCC, de vannak olyan napi dolgok, ahol az új verzióban szintén bevetnek ilyen trükköket.

Az viszont biztos, hogy a kiszámolt eredmény egyik esetben sem lehet a valóságtól eltérő. A lefordított kiszámoló program utasításai viszont a más verziójú C fordító esetén lehet más, általában gyorsabb futású megoldás.

( hajbazer v | 2017. 12. 30., szo – 20:22 )

Van egy olyan rossz előérzetem, hogy nem a megfelelő fórumon tetted fel a kérdést. Itt befektetői/menedzser módba kapcsolt, az időt pénznek konstansként definiáló, ár-érték arányokat vizslató, out of the box koffein-kód konverziós mérnök urak alkotják a hangadó elitet. Ők azok, akiket a szakma ilyesféle csínja-bínja egyáltalán nem érdekel, csak az, amiben van innováció™ és piaci érték™. Ez nem ellened szól, én kifejezetten örülök, hogy a tiedhez hasonló, normális témák is vannak a fórumon. Csak ne vedd magadra, ha a HUP legnagyobb szaktekintélyei első kézből a "mi értelme ennek", "nem éri meg" közhelyeikkel igyekeznek majd lekezelni. Jó látni, hogy valaki belefog ilyenekbe, vagy legalább érdeklődik. Sok sikert kívánok az LFS projektedhez!

Na mostmar tenyleg Subscribe.

Hogy jutottam el idaig:
1. Latom csomo uj hupmeme link van, tobbseguk idemutat
2. Kerdesben: "lehet hulye kerdes"
3. Sok hulye, egymastol is eltero es magabiztos de teves valasz cafolja a 2-es allitast
4. Szol fentebb Oops forumtars, hogy sokan arrogansan szakma iranti tisztelet teljes hianyaban leirjak a rossz megoldast mint "biztosan jo"
5. Raynes lepluszegyezi a 4.-ben irt hozzaszolast, mintha ertene, es aztan "lebaromsagozza" a topikban felvazolt problemat.
6. Ezekutan megerkezel te, es ide is belekevered a topikba a profitorientalt (bocsanat, extraprofit-orientalt) szferaban dolgozok agyfertozeset. De legalabb konzisztensen eddigi onmagaddal sok sikert kivansz az LFS-hez.

Hat en most kipattogtatok egy 15 literes popcornt. Pedig a Viszkishez csak 4.5 literest vettem.

A kirántott kardot leszámítva egyetértek: én is örülök, ha látok még olyat, aki lárpúrlár basztat valamit, annak ellenére, hogy én ahhoz már vén marha vagyok. Viszont emlékszem még, hogy lárpúrlár basztatások alatt (is) vénmarhultam meg.
Ulláccik, nálam vénebbek is járnak erre, akiknek ezt az epizódot Alzheimer doktor már kitakarta az emlékporfólióból.