1606
Vývoj / Re:Rekurze v Javě (i jinde)
« kdy: 20. 11. 2020, 19:59:59 »Tak jsem z toho ten bajtkód dostal:Díky.
public scala.runtime.Nothing$ x();
Code:
0: goto 0
A CPU to žere, předtím jsem to nějak blbě pustil.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
1607
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 20. 11. 2020, 16:39:29 »Např. při standartu BIP39 se každé slovo vybírá ze seznamu 2048 slov, takže při použití dvanácti slov se jedná o počet kombinací 2048 na dvanáctou.To je na heslo dostačující – je to zhruba stejné, jako dvacetiznakové heslo s malými a velkými písmeny, číslicemi a symboly.
Akorát bych heslo ze dvanácti slov nechtěl někam psát. A vůbec bych se nedivil, kdybyste někde narazil na limit délky hesla.
1608
Vývoj / Re:Rekurze v Javě (i jinde)
« kdy: 20. 11. 2020, 11:19:32 »Technická poznámka pro zajímavost: nepokračování bloku kódu může způsobit nejen výjimka, ale i nekonečná rekurze. Např. Scala má typ `Nothing`, který se typicky používá jako typ výsledku funkce, která nikdy neskončí.Znamená to, že to Scala překládá do jiného bajtkódu, než je volání funkce? Tj. neukládá se volání na zásobník a může to být skutečná nekonečná rekurze?
1609
Vývoj / Re:Rekurze v Javě (i jinde)
« kdy: 19. 11. 2020, 10:15:00 »
Zřejmě vás mate to, že v debuggeru nevidíte, v kterém volání té funkce jste. Pomůže, když se v debuggeru podíváte na zásobník volání – call stack. Tam uvidíte, jak se vnořujete do volání té funkce a zase vynořujete.
Tedy vy zavoláte poprvé seedFill. Podmínka se vyhodnotí jak pravdivá, skočí se dovnitř bloku. Následně se zavolá raster.setPixel – zapamatuje se aktuální místo v programu, skočí se do metody setPixel a ta se provádí. Když se dojde na konec metody setPixel, skočí se na zapamatované místo – tedy zpět do prvního volání metody seedFill. Pokračuje se sál, tam je (rekurzivní) volání seedFill – takže se opět zapamatuje aktuální místo a skočí se do metody seedFill – teď už je to druhé zanořené volání. V debuggeru to bude vypadat, že jste najednou skočil na začátek té metody seedFill, ale v zásobníku volání už ta metoda bude dvakrát. Provádí se druhé volání seedFill, v nějakém okamžiku se ukončí a provádění se vrací zpět na zapamatované místo – což je to první volání seedFill. To je to, co vám v debuggeru připadá, jako by byl začátek té metody přeskočen. Ve skutečnosti to ale znamená, že jste se jen vrátil do dříve spuštěné metody a pokračujete tam, kde jste prve skončil. Uvidíte to na zásobníku volání, kde v tu chvíli bude už jenom jedna metoda seedFill – jste zpět v tom prvním volání metody.
Mimochodem, používat na tuhle úlohu rekurzi není moc vhodné. Zásobník volání má omezenou kapacitu, u větších obrázků byste ji překročil.
Pokud se během toho posunu dostanu například na hranici nebo na jinou barvu pozadí tak je podmínka v ifu false a celý blok je přeskočen (krokování v debugeru), ale po tom neskončí jak bych očekával ale hned se vrátí zpět a pokračuje další metodou seedFill(x-1,y).Ono provádění té metody skončí. Ale provádění se tudíž vrátí do místa, odkud byla ta metoda vyvolána. A to místo je shodou okolností zase ta metoda seedFill, ale v předchozí iteraci – právě proto že je to rekurzivní volání.
Tedy vy zavoláte poprvé seedFill. Podmínka se vyhodnotí jak pravdivá, skočí se dovnitř bloku. Následně se zavolá raster.setPixel – zapamatuje se aktuální místo v programu, skočí se do metody setPixel a ta se provádí. Když se dojde na konec metody setPixel, skočí se na zapamatované místo – tedy zpět do prvního volání metody seedFill. Pokračuje se sál, tam je (rekurzivní) volání seedFill – takže se opět zapamatuje aktuální místo a skočí se do metody seedFill – teď už je to druhé zanořené volání. V debuggeru to bude vypadat, že jste najednou skočil na začátek té metody seedFill, ale v zásobníku volání už ta metoda bude dvakrát. Provádí se druhé volání seedFill, v nějakém okamžiku se ukončí a provádění se vrací zpět na zapamatované místo – což je to první volání seedFill. To je to, co vám v debuggeru připadá, jako by byl začátek té metody přeskočen. Ve skutečnosti to ale znamená, že jste se jen vrátil do dříve spuštěné metody a pokračujete tam, kde jste prve skončil. Uvidíte to na zásobníku volání, kde v tu chvíli bude už jenom jedna metoda seedFill – jste zpět v tom prvním volání metody.
Mimochodem, používat na tuhle úlohu rekurzi není moc vhodné. Zásobník volání má omezenou kapacitu, u větších obrázků byste ji překročil.
1610
Vývoj / Re:Rekurze v Javě (i jinde)
« kdy: 19. 11. 2020, 09:45:36 »
Nikdy se nespustí jen jeden řádek v bloku kódu. Blok kódu se provádí vždy celý od začátku do konce, přerušit jeho provádění může jenom výjimka. (Samozřejmě se bavíme o případu, kdy se blok kódu vůbec má provádět – pokud je ten blok kódu v ifu, provádí se jenom tehdy, když je podmínka splněna.)
Podmínka v ifu se vyhodnotí vždy jen v okamžiku, kdy program tou podmínkou prochází. Když se dodatečně změní proměnná a ten výraz v podmínce by se vyhodnotil jako false, nemá to už žádný vliv. Takže v následujícím kódu se normálně vypíše Hello, World!
Podmínka v ifu se vyhodnotí vždy jen v okamžiku, kdy program tou podmínkou prochází. Když se dodatečně změní proměnná a ten výraz v podmínce by se vyhodnotil jako false, nemá to už žádný vliv. Takže v následujícím kódu se normálně vypíše Hello, World!
Kód: [Vybrat]
boolean priznak = true;
if (priznak) {
priznak = false;
System.out.println("Hello World!");
}
1612
Software / Re:URL s netisknutelnými znaky se ve Firefoxu vyhledá Googlem
« kdy: 17. 11. 2020, 23:11:04 »
%C2%AD je volitelné rozdělení (soft hyphen).
O žádnou chybu se nejedná. Měl jste ve schránce text, ten jste vložil do vstupního řádku prohlížeče (který funguje jako adresní i vyhledávací). Prohlížeč prozkoumá vložený text, zjistí, že to není URL ani samotná adresa (bez protokolu), takže zbývá poslední varianta, že se jedná o obyčejný text, který chce uživatel vyhledat – a otevře přednastavený vyhledávač s tím textem.
Mimochodem, to tapetování fóra hloupými dotazy je celkem otravné. Připomíná mi to uživatele Pivotal. Ony se ty dotazy sice poznají hned podle titulku, ale člověku to nedá, chce si ověřit, zda to uhodl správně – a už je v tom, viz https://xkcd.com/386/ Chtělo by to na hlavní stránku funkci, že si člověk zakliká, které dotazy jsou podle něj od uživatele Hamparle, systém vyhodnotí, jaké má skóre, a pak ty dotazy schová.
O žádnou chybu se nejedná. Měl jste ve schránce text, ten jste vložil do vstupního řádku prohlížeče (který funguje jako adresní i vyhledávací). Prohlížeč prozkoumá vložený text, zjistí, že to není URL ani samotná adresa (bez protokolu), takže zbývá poslední varianta, že se jedná o obyčejný text, který chce uživatel vyhledat – a otevře přednastavený vyhledávač s tím textem.
Mimochodem, to tapetování fóra hloupými dotazy je celkem otravné. Připomíná mi to uživatele Pivotal. Ony se ty dotazy sice poznají hned podle titulku, ale člověku to nedá, chce si ověřit, zda to uhodl správně – a už je v tom, viz https://xkcd.com/386/ Chtělo by to na hlavní stránku funkci, že si člověk zakliká, které dotazy jsou podle něj od uživatele Hamparle, systém vyhodnotí, jaké má skóre, a pak ty dotazy schová.
1613
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 16. 11. 2020, 22:27:25 »No mnemotechniku tvorby hesla samozřejmě nesmíte dle Kerckhoffova principu tutlat, jak jinak by se ji nepřítel dozvěděl ?Nejste první a bohužel ani poslední, kdo si myslí, že security through obscurity je dobrý nápad. Přišel jste i s nejoblíbenějším argumentem – jak by se asi mohl přítel o té použité metodě dozvědět. Zvláštní je, že se tento argument obvykle objevuje až po té, co tu metodu někdo vykecá. Přičemž to, že slova místo spojovníků oddělujete tečkou nebo na konci místo vykřičníků přidáváte dolary na tom vůbec nic nemění. Ono totiž těch symbolů dostupných na klávesnici není zas tolik.
1614
Distribuce / Re:Nelze přidat uživatele: No UID/GID pair is available
« kdy: 16. 11. 2020, 21:45:56 »A ldapsearch vyzerá, že fungujeVy máte problém s ověřováním uživatelů proti LDAPu a po pěti komentářích z vás konečně vypadne první informace o LDAPu: „ldapsearch vyzerá, že funguje“. Vážně si myslíte, že vám na základě téhle informace někdo s LDAPem pomůže?
Pokud s tím problémem chcete opravdu pomoci, začněte tím, že sem dáte celou konfiguraci sssd/nscd.
1615
Distribuce / Re:Nelze přidat uživatele: No UID/GID pair is available
« kdy: 16. 11. 2020, 15:37:36 »
Pokud se z vašeho zařízení ověřují uživatelé proti LDAPu, musíte mít alespoň nakonfigurovaný přístup k tomu LDAPu a nakonfigurované, jaké dotazy se tam provádějí.
1616
Distribuce / Re:Nelze přidat uživatele: No UID/GID pair is available
« kdy: 16. 11. 2020, 14:26:22 »
Stále sem dáváte výpisy z /etc/passwd. Pokud ale používáte pro přihlašování i LDAP, je potřeba se podívat také tam.
1617
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 16. 11. 2020, 11:06:21 »Ps. Řešíte u takových ultra důležitých a ultra tajných dokumentů to, že třeba za 10/20/50 let nebude existovat žádný program, který by ty už v podstatě archeologické formáty dat dokázal přečíst?Jsou formáty určené pro dlouhodobou archivaci, např. PDF/A. Pokud by za 50 let nebyl žádný program, který by dokázal PDF/A přečíst, byly by vám stejně k ničemu i ty papírové originály (leda byste je v jeskyni u ohníčku ukazoval na důkaz toho, že vaše báchorky o dobách minulých mají reálný základ).
1618
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 16. 11. 2020, 09:34:30 »Mohl bych poprosit o vysvětlení? Domníval jsem se, že u běžné šifry musíte uhádnout celé heslo/klíč, aby výsledek vyšel - vy se snažíte naznačit, že několik neznámých znaků v klíči nevadí? tzn k rozluštění části stačí část klíče?Nešlo o rozluštění části klíče. Jde o to, že když klíč prodloužíte od dva náhodné bity, útočník musí vyzkoušet jen 4× víc možností. Pokud by mu dříve trvalo hrubou silou vyzkoušet všechny možnosti minutu, nově to budou čtyři minuty. Pokud by to dříve trvalo den, nově to budou čtyři dny. Pokud by to dříve bylo deset let, nově to bude čtyřicet let (za tu dobu se nepochybně rychlost hádání podstatně zvýší). Nic z toho není zajímavá změna – mimo jiné proto, že čtyřnásobné prodloužení můžete eliminovat tím, že místo jednoho zařízení zapojíte do louskání čtyři zařízení apod. Když chcete posílit bezpečnost, potřebujete se posouvat ne v násobcích ale v řádech.
1619
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 16. 11. 2020, 08:46:34 »Lol. Použít Kerckhoffův princip na mnemotechniku tvorby hesla je velmi ehm alternativní přístup ;-)Kerckhoffův princip používají všichni, kteří bezpečnosti aspoň trochu rozumí. Mezi laiky to může být alternativní přístup, to je klidně možné. Princip tvorby hesla je samozřejmě součástí principu šifrování.
1620
Odkladiště / Re:Jak ukrýt důležité heslo?
« kdy: 15. 11. 2020, 21:08:29 »Vaše úvaha je ale založená na znalosti skladby hesla - což je hodně vyjímečná znalost.Ne, není to výjimečná znalost. Security through obscurity není dobrý způsob zabezpečení.
Navíc jste do propočtů vůbec nezahrnul použití nestandardních nebo žádných oddělovačůO pár bitů entropie víc nebo míň, na tom nezáleží.
varianty s malými a velkými písmeny, varianty s diakritikouV tom vašem příkladu nic takového nebylo.
nakonec zase budete zkoušet všechny kombinace znakůNikoli.
