Příspěvky

1

Studium a uplatnění / Re:Platový posun - junior

« kdy: 10. 06. 2023, 08:49:37 »

Prozraďte mi prosím někdo tajemství, proč se dnes, v době streamerů, influencerů a dalších postradatelných profesí, firmy tak úzkostně bojí nabírat neozkoušené mladé lidi bez praxe, zvláště pak na zaměstnanecký poměr? Asi jen dělám něco blbě, ale fakt mě nemile překvapilo, jak obtížné je sehnat hned po škole trochu kvalifikovanější práci.

Pro firmu jsou junioři docela drazí z toho důvodu, že junior hned po škole není schopen přinést nějakou přidanou hodnotu. Musí se pro něj alokovat nějaký mentor (senior), který ho postupně všechno naučí, což může trvat tak 3 až 12 měsíců podle náročnosti práce a schopností juniora. Což reálně znamená, že senior toho udělá méně a firma navíc platí juniora. Ono se to otočí za těch 3 až 12 měsíců, pak už je i junior schopen produkovat nějaký rozumný výstup, ale problém je, že potom často junior ochází za lepším jinam. Pro firmu je to dost velké riziko, že "zainvestuje" do juniora a nevrátí se jí to. Proto jsou především malé firmy s nabíráním juniorů opatrné, větší šance pro juniory jsou v korporátech.

2

Vývoj / Re:C pre-preprocesor

« kdy: 11. 04. 2023, 20:47:40 »

Takze vse vyresim humpolackou metodou, radky tak, ze udelam spravny pocet newline za svym prepsanym kodem, aby to odpovidalo zdrojaku. A necham to at si vsechno resi pravidla Makefile, pro MSVC asi pres pre-compile command.

Upřímně, tohle mi zní jako ohýbák bez narovnáváku.

Prijde mi zajimave jak jsem dostal hromadu odpovedi ... ale ne na moje otazky .

Dostal jsi spoustu relevantních odpovědí, které ti říkají, proč nemáš dělat to, co se snažíš dělat. Pokud v tom chceš pokračovat, tak to je samozřejmě tvoje volba, jen potom nemůžeš očekávat, že dostaneš odpovědi na tvoje otázky.

3

Vývoj / Re:C pre-preprocesor

« kdy: 10. 04. 2023, 12:23:59 »

Již zmíněný capstone podporuje i RISCV, nebylo by řešením použít tohle? https://www.capstone-engine.org/

4

Vývoj / Re:HMAC, SHA1 (C++/AVX2 VS2022)

« kdy: 01. 01. 2023, 18:53:16 »

Je zajímavé, že pokud odkomentuji výpis posledních tří generovaných hesel, čas výpočtu se zásadně prodlouží.

Ale o tom zde už dobrou čtvrthodinu hovoříme, Mlho!

Pokud s těmi vygenerovanými hesly nic neděláš, tak ten program nemá žádný side effect a překladač všechny výpočty vyhodí pryč, protože proč by je tam nechával, když se výsledek na nic nepoužije...

5

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 15:49:21 »

Pokud jde o ty ego-obrany, myslim to asi trosku jinak.

Nevim jaky maji pocit lide "tlacici" Rust, rekl bych, ze jejich pocit muze byt z vetsi casti "mam skvely jazyk ktery vsem ukaze jak jsou/byli blbi" (a tim i "a jak ja to umim").

Myslím, že to trochu jinak. Pokud já někam tlačím Rust (obecně to nedělám moc rád), tak je to stylem "mám skvělý jazyk, který řeší spoustu bezpečnostních problémů, které jsou v C/C++ a je stejně rychlý". Ale i tohle se samozřejmě potkává s odporem, protože lidé změny moc nechtějí, to je přirozená lidská vlastnost.

Muj pocit neni nejake ohrozeni, popravde mi je jedno ze lide pouzivaji Rust, C#, Go, Javu, PHP, Python, atd. Jen mne opravdu nebavi resit problemy, ktere mi jini lide takto prinaseji do zivota. Takze bude-li podminkou prekladu kernelu mit Rust prekladac a resit nejake zavislosti, knihovny, apod., tak se to stava i mym problemem, ktery musim resit, bez pro mne pridane hodnoty.

V Linuxu bylo za dobu jeho existence objeveno asi 800 chyb souvisejících se špatnou práci s pamětí, většina s dopadem na bezpečnost (remote code execution, gain information...). A to se bavíme jen o známých chybách, těch zatím neobjevených bude řádově více. Žádná z těchto chyb v kernelu nebyla, pokud by se použil memory safe jazyk. Ty v tom možná nevidíš přidanou hodnotu, jiní lidé ale ano.

6

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 14:30:26 »

Bavime se s tou psychologii kazdy o necem jinem, ale to je tema mimo tento server, do ktereho nechci zabredat vic, nez ze by to u mnoha lidi mohl byt "ego-obranny mechanismus".

To je docela zajímavé téma a přijde mi, že obranný mechanismus je na obou stranách. Hodně lidí z C/C++ komunity vidí v Rustu ohrožení, protože se může stát, že Rust C/C++ v budoucnu nahradí. Lidé obecně nemají rádi změny a drží se toho, co znají, to je normální lidské chování. Takže se Rustu logicky brání. Naopak lidé z Rust komunity na ně tlačí někdy až moc agresivně, což vede řekněme k různým nedorozuměním.

Ja rozhodne v cecku nevidim karku, ale prave naopak v mnoha "modernich" jazycich vidim spis "moderni auto ktere prinasi vic problemu nez uzitku". Bohuzel to jsou i novejsi C++, ktere se myslim uzaviraji do vlastniho sveta "reseni problemu ktere sam jazyk prinesl".

Problémem C je, že má na svědomí asi tak 90% kritických bezpečnostních chyb kvůli tomu, že je memory unsafe. Google uvádí, že dle jeho statistik připadá jedna bezpečnostní chyba na 1000 řádek C kódu. To je strašné číslo a nejde s tím nic dělat, protože ty chyby způsobuje lidský faktor. Lidé prostě nejsou schopni psát v C bez chyb. Takže jediné řešení je zbavit se C a použít memory safe jazyk. Tím zmizí 90% kritických bezpečnostních chyb.

Muzete mi dat priklad toho rozsireni C o memory safe reseni ?

Z C není možné udělat memory safe jazyk bez ztráty zpětné kompatibility. C by se muselo hodně předělat a vzniklo by něco podobného Rustu. Proto takové snahy nemají smysl, lepší je začít znovu a C nechat být. Tady nejde jít cestou evoluce, revoluční změna je nutná.

7

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 04. 12. 2022, 10:30:01 »

Zajímavá aktivita Googlu, ale je po tom taková poptávka, aby to překročilo brány firmy? Těch projektů takhle víc zašlo než se udrželo.

Carbon v Google vzniknul primárně ze dvou důvodů:

• Bezpečnost C++ je hrozná, Carbon tohle (částečně) řeší.
• C++ steering committee dlohodobě ignorovala snahy Google o rozbití ABI, což Google považuje za nutné k dalšímu rozvoji C++ (tady jsem na straně Google).

Carbon je zajímavý počit, ale jedním z jeho primárních cílů byla dobrá interoperabilita s existujícím C++ kódem, což dost omezuje při návrhu jazyka, nemohli to prostě udělat celé od základu jinak (jak to udělal třeba Rust). Google má spoustu existujícího kódu v C++ a nemůže si dovolit všechno zahodit a přepsat, proto potřebuje jazyk, ze kterého půjde volat existující C++ kód. Důsledem je, že Carbon v součané podobě není memory safe. Někdy možná bude, ale vyžádalo by si to zpětně nekompatibilní změny v designu jazyka. Takže pocity z Carbonu jsou zatím spíš rozpačité, oproti C++ je to posun vpřed, ale zároveň je to takové polovičané řešení, primárně kvůli požadavku na interoperabilitu s C++.

8

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 03. 12. 2022, 13:29:32 »

Ten clanek o Androidu je celkem vagni, nejsou tam absolutni cisla a co v tom Rustu bylo pridano. Nedokazu si z toho udelat smysluplny obrazek.

Jak vágní, četl jsi to vůbec? Je to tam uvedeno docela přesně:

 In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.

Nicméně absolutní čísla nejsou až tak důležitá, hlavní je trend. Google má v plánu zbavit se v dlouhodobém horizontu memory unsafe jazyků v Androidu, což znamená konec C/C++. Co je nahradí, je celkem jasné, Rust pro performance kritické části, případně Kotlin/Java tam, kde nevadí garbage collector.

9

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 03. 12. 2022, 12:37:16 »

Priznam se, ze jsem tema prilis necetl, mozna tu padla odpoved; prijde mi diskuse skoro jako nabozenstvi. Zeptal bych se:

1) Jake jsou nejvetsi *zname* projekty v Rustu? Chvili jsem hledal a uspokojivou odpoved na svoji otazku jsem nenasel. Mozna zdejsi znalci Rustu vytahnou seznam.

2) A jsou nejake vyznamnejsi *komercni* projekty v Rustu?

Viz předchozí příspěvky, stačil by Android? Tam je Rustu docela dost: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

Linux kernel má taky docela dobře našlápnuto, ale tam se Rust teprve začíná integrovat.

10

Vývoj / Re:Je Rust jazyk budoucnosti?

« kdy: 03. 12. 2022, 10:04:02 »

Z jiného soudku: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html

To je hodně dobrá reklama na Rust. Z celého článku bych vypíchnul tohle:

To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.

Rust je paměťově bezpečný jen do té doby, než se použije unsafe. Ale zároveň z toho článku plyne, že unsafe normálně není potřeba vůbec používat. V celém UWB stacku mají použitý unsafe jen 2x z důvodu interoperability s Javou. Takže praxe ukazuje, že Rust plní to, co sliboval: paměťově bezpečný jazyk bez garbage collectoru s rychlostí C.

11

Vývoj / Re:Načtení 2D pole v C

« kdy: 22. 11. 2022, 07:56:46 »

presne tak, ak bude s tym experimentovat i tie "kritické bezpečnostní chyby" si najde a odstrani sam

To co jsi vyrobil, je klasický buffer overflow s přepsáním zásobníku a návratové adresy na něm, což je ta úplně nejkritičtější a velmi snadno zneužitelná chyba. Začátečník si nic sám neodstaní a učit ho tohle opravdu není dobrý nápad. Fakt bych nepsal "kritické bezpečnostní chyby" v uvozovkách, tím jenom dokazuješ, že bezpečnosti moc nerozumíš. Doporučil bych ti používat paměťove bezpečný jazyk a držet se od C dál. To bych ostatně doporučil úplně všem, protože praxe ukázala, že psát bezpečný software v C neumí nikdo. Takový člověk prostě neexistuje, nedá se to uhlídat.

12

Vývoj / Re:Načtení 2D pole v C

« kdy: 21. 11. 2022, 21:22:33 »

Je to super, jak z toho školního příkladu chcete udělat skoro produkční kód.

Je v pořádku, že je ve školním projektu undefined behavior na třech místech? S tím, že jsou to kritické bezpečnostní chyby?

Mimochodem, co jsou ty tři chyby?

• Buffer overflow na počet řádků.
• Buffer overflow na počet sloupců.
• Neinicializovaná matrix. Prakticky celou neinicializovanou matrix je možné vypsat, to je hodně dat. Tím to ale nekončí. V kombinaci s buffer overflow je možné vypsat úplně všechno, co je na zásobníku. Celý zásobník procesu, ke kterému se útočník snadno dostane. To může být fakt hodně potenciálně citlivých dat. Jako chápu, že to většina lidí neřeší, ale kritická bezpečnostní chyba to prostě je.

13

Vývoj / Re:Načtení 2D pole v C

« kdy: 21. 11. 2022, 21:06:45 »

a ze to je v realu chyba nevadi, protoze se zaroven muze ukazat co se stane kdyz se prejede nektery index.

V reálu je to undefined behavior, takže se může stát cokoliv. Začátečník na to bude koukat a nebude chápat, co se děje. Proto není C vhodný jazyk pro začátečníka. Když už s tím ale někdo začíná, je mu od začátku potřeba vysvětlovat, co je to undefined behavior, protože když to nebude vědět, nebude rozumnět tomu, proč to nefunguje (a může to dělat cokoliv).

jakmile se nauci pointery, pak se muze naucit jak alokovat pole na heapu.

Jde to napsat bezpečně i se staticky alokovaným polem. S tím je vhodné začít.

14

Vývoj / Re:Načtení 2D pole v C

« kdy: 21. 11. 2022, 20:07:32 »

Toto su malicherne nedostatky, ktore sa daju lahko osetrit.

Asi máme jiný názor na to, co jsou malicherné nedostatky. Já vidím tři kritické bezpečnostní chyby.

Keby si mal nejaku sebareflexiu, tak by si namiesto kritiky radsej postol vlastny funkcny kod, co sa ale nestalo.

Kdybys měl nějakou sebereflexi, poděkoval bys za kostruktivní code review.

15

Vývoj / Re:Načtení 2D pole v C

« kdy: 21. 11. 2022, 19:12:00 »

To neni produkcny kod ale iba ukazka JAK NA TO.

To je spíš ukázka, JAK TO NEDĚLAT. Problémů je tam víc.

Nestačí ošetřit počet řádků, další buffer overflow nastane, když bude v řádku víc jak MAX_COLS (100) prvků. To jde snadno docílit, protože MAX_LINE_LENGTH je 256, jde tam nacpat až 128 prvků. Výsledek je úplně stejný, přepis stacku s (remote) code execution.

Pak je tam uninitialized memory access v případě, když budou mít řádky různý počet sloupců, matrix není inicializované. Neinicializovaná data se potom vypisují a může tam být cokoliv, třeba šifrovací klíče, které program používá.

Tohle bych začátečníkovi fakt neukazoval.