Příspěvky

4156

Studium a uplatnění / Re:Problémy P, NP, NP-úplné, NP-těžké

« kdy: 08. 06. 2015, 21:46:04 »

Moc jsem to po sobě nečetl, ale snad to dává nějaký smysl.

Zapomněl jsi ještě na jeden důležitý teorém (tzv. Prýmkův):

Každá ptákovina, kterou:

• tě ve škole učí semestr až dva
• vůbec jí po těch dvou semestrech nerozumíš
• a budeš ji potřebovat jenom ke státnicím a pak už nikdy v životě

je v polynomiálním čase převoditelná na 36 řádků naprosto srozumitelného, jasného textu, který teprve ti umožní ty státnice udělat.

4157

Distribuce / Re:Co se děje s gentoo.org?

« kdy: 06. 06. 2015, 13:15:59 »

Tj. mělo by to (?) brát vždy nejdříve /ect/hosts (předpokládám, že to se míní tím "files")

Jo.

Možná je chyba v mém chápání DNS - myslel jsem (asi podobně jako Vy), že stačí přesměrovat nadřazenou doménu - rackcdn.com - a všechny podřazené tím budou mimo hru. Ale není to tak, resp. systém se tak nechová.

Jak jsem psal - "ping rackcdn.com" pingá localhost - ok. "ping 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com" pingá ven do internetu.

/etc/hosts je databáze hostů. Když program zavolá funkci gethostbyname, tak se knihovna do toho souboru koukne a pokud tam host je, použije tamní IP adresu. Pokud není, použije další metodu, typicky ten dotaz na DNS server.

Docela detailně je to popsaný v manpage: http://man7.org/linux/man-pages/man3/gethostbyname.3.html

Není ale nikde řečeno, že každý program musí použít tuhle metodu. Může mít klidně svoji implementaci převádění hostname na IP, může mít svoje cachování atd. atd.

Ten ping nebude pingat "do internetu", když do /etc/hosts dáš záznam pro toho konkrétního hosta:

A.B.C.D 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com

Pokud bys chtěl dělat složitější věci jako přesměrovávat domény, použít wildcardy apod., tak musíš mít lokální dns server, který tyhle operace bude provádět. Některé jsou jednoduché a určené přesně na takové operace, cachování apod. (např. dnsmasq)

4158

Distribuce / Re:Co se děje s gentoo.org?

« kdy: 06. 06. 2015, 10:58:17 »

I to kešování mě napadlo, vypnul jsem ho tedy "systemctl stop nscd.service", ale i poté "host rackcdn.com" vrací totéž, nezávisle na záznamu v /etc/hosts. Jediné místo kde se ten záznam "0.0.0.0 rackcdn.com" projevil bylo u "ping", kde "ping rackcdn.com" pingá localhost (127.0.0.1), ovšem "ping 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com" stále pingá 23.124.155.136 (e6923.g.akamaiedge.net). Mám prakticky nijak neupravený arch, možná je tam kromě nscd nějaké další kešování (ale neřekl bych).

Cachování u různých softwarů může fungovat různě. Typicky browser má vlastní cache ještě nad tou systémovou. Pořadí mechanismů, které se k tomu "systémovému" resolvování použijí, je nastavené v /etc/nsswitch.conf, položka "hosts:"

Modem resolvuje, "jen" má problém s tou adresou CDN. Na google.com vše ok, na té cdn adrese:

Kód: [Vybrat]

# host -v 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com 10.0.0.138

Trying "1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com"
;; connection timed out; no servers could be reached

Modemy mívají docela často v resolvovacím kódu chyby a příčin může být dost a jsou trochu obtížně dohledatelné. Neřešil bych to, nastavil nameserver na 8.8.8.8 a fertig

4159

Distribuce / Re:Co se děje s gentoo.org?

« kdy: 06. 06. 2015, 10:23:21 »

Sorry, překlep...

Přiznám se, že neznám přesně úlohu /etc/hosts.conf.

Záznamy v /etc/hosts (bez .conf!) se obvykle použijí pro resolvování jako první - teprve když se záznam nenajde tam, dotáže se počítač DNS serveru.

ovšem "host rackcdn.com" vrací stále totéž a z pohledu prohlížeče i po "tvrdém" reloadu se nic nemění

Resolvování může být cachované. A to ještě pro některé programy ano a pro některé ne...

Kód: [Vybrat]

# host rackcdn.com
rackcdn.com mail is handled by 20 mx2.emailsrvr.com.
rackcdn.com mail is handled by 10 mx1.emailsrvr.com.

# host 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com
;; connection timed out; no servers could be reached

Tohle vypadá jakoby modem nemohl resolvovat vůbec. Můžeš zkusit:

Kód: [Vybrat]

# host -v www.google.com A.B.C.D

Kde A.B.C.D je IP adresa modemu (ve vnitřní síti - takže něco jako 196.168.1.1 nebo 10.0.0.1 apod.)

4160

Distribuce / Re:Co se děje s gentoo.org?

« kdy: 06. 06. 2015, 09:35:17 »

Takovéhle "exotické" domény jsou ok? Proč gentoo.org tahá font a skripty kdovíodkud?

Protože to je CDN [1], která umožňuje tahat soubory z bližšího serveru, nemusí se všechno tahat z jednoho místa pro uživatele z celé planety.

rackcdn.com patří RackSpace a na url není nic divného: https://www.rackspace.com/knowledge_center/frequently-asked-question/getting-started-with-cloud-files-streaming

[1] http://en.wikipedia.org/wiki/Content_delivery_network

4161

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 18:11:32 »

Přeruší ? O žádné přerušení Vaší činnosti jste nežádal ani jste k tomu nedával svolení Scheduler to provedl násilně, proti Vaší vůli, preemptivně přepnul do jiného vlákna a pak zase zpět

Ne, scheduler prepnul kontext, protoze mezitim doslo k ukonceni funkce, alokovani pameti, IO operaci, vyprseni casu, zatmeni mesice, nebo si nekdo prdnul. To mne jako vlakno X vubec nezajima. Mne uplne staci vedet, ze k tomu prepnuti NEKDY dojde. A VUBEC na tom nemusim spolupracovat.

4162

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 17:05:26 »

Takže jak se do mailboxu odpověď nevíte, zůstává v platnosti varianta s Marťany

Odpoved se do meho mailboxu dostane tak, ze moje vlakno (X) scheduler prerusi, spusti druhe vlakno (Y) a to mi vlozi zpravu do meho mailboxu. Z hlediska  vlakna X je to "z nicehoznic", protoze vlakno X vubec nevi o tom, ze bylo preruseno.

4163

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 17:03:17 »

Já teda nevím, ale není to prostě tak, že Mirek Prýmek se na to dívá z pohledu VM a Kolemjdoucí z pohledu OS případně železa? Mi to tak přijde.

Dyt to rikam: Kolemjdouci mota uroven a metauroven. Jenze ta metauroven nas v tomhle pripade nezajima - jestli VM zastavim zvnejsku (metauroven) na pulhodiny nebo deset let a pak spustim znovu, nema vubec zadny vliv na to, jestli uvnitr VM jde nebo nejde zrealizovat nejaka operace. VM ma vlastni tikani casu a vnejsi cas ho vubec nezajima. Jo, kdyby Kolemjdouci rekl "timhle zpusobem nejde udelat hard realtime", tak to je uplne jina pisnicka...

V jednom OS vlákně můžu mít asynchronní akce, nebo ne? Prostě se střídají a nepotřebuju na to ani víc OS procesů ani víc OS vláken. Tak to má třeba javascript.

Nebo mě opravte, jestli jsem mimo.

Ne, presne takhle to je - VM ma vlastni scheduler a sam VM-vlakna prepina uplne stejne jako OS prepina svoje vlakna. To je jakobych tvrdil, ze na jednojadernem CPU nejde udelat unixova roura...

4164

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 16:53:39 »

A ta odpověď se do mailboxu dostala jak ? Vy jste ji tam nedal a protože jste si dělal svoje věci tak adresát se nedostal k CPU. Zřejmě ji tam dali Marťani :-)

Coze? Mailbox je proste fronta. Takze vlozim zpravu do fronty (=asynchronne "zavolam") a jdu si delat, co chci. Kdykoli me to napadne, tak v ramci toho "co chci" koukam do sveho mailboxu, jestli mi nahodou mezitim neprisla odpoved. To je asynchronni volani. A zadny "preemptivni VM" k tomu proste neni potreba.

Zásadní rozdíl se zcela smaže, když pilný hlupák vrazí do funkce dlouhý výpočet.

Zasadni rozdil je mezi tim, kdyz explicitne se schedulerem musim kooperovat a kdyz jsou jenom stanovena pravidla, kdy scheduler context switch dela (protoze je to tak treba efektivni, vyhodne, jedoduche atd.) - pravidla, o kterych kod vubec nemusi vedet a jsou mu uplne putna, protoze on z jeho pohledu bezi linearne bez preruseni (coz je definice multitaskingu).

------------------

Hele, uz me to hrani si na kocku a mys fakt nebavi. Porad nevim, co vlastne chcete dokazat, proc a jak, a uz me nebavi se na to ptat porad dokola. Tak nekdy priste nashle...

4165

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 15:47:13 »

Vykonat asynchronní událost na základě zprávy můžete jen v preemptivním prostředí.

Porad nechapu, proc by to tak melo byt. Zpravu proste umistim do mailboxu adresata a odpoved si vyzvednu ze sveho mailboxu. Mezitim si delam co chci. Proc bych k tomu potreboval preemptivni multitasking, to prave nechapu.

Bingo, pokud vlákno v kooperativním multitaskingu neprovede smluvenou činnost, tak má Scheduler smůlu. Nemusí to být pouze specifický bytecode, mohou to být i vhodné funkce, třeba počátek/konec redukce nebo funkce, alokace nové paměti, volání IO operace a jiné.

No to je ale zasadni rozdil. Udelat nejakou explicitni cinnost, jejiz jediny vyznam a smysl je predat rizeni scheduleru je uplne neco jineho nez pravidlo, ze scheduler provede context switch jenom za nejake vhodne prilezitosti (konec funkce atd.)

To, ze ve vlakne dojde k ukonceni funkce prece neni "kooperace se schedulerem" a uz vubec to nema nic spolecneho s moznosti asynchronniho posilani zprav.

4166

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 13:14:49 »

Mezitím jsem si pročetl Erlang a preemptivní není ani Erlang Thread-switch je tam synchronní záležitost a může nastat pouze mezi jednotlivými redukcemi. Iluze preemptivnosti spočívá v tom že redukce se z povahy jazyka nedá napsat jako časově dlouhá věc. To co trvá dlouho, třeba komunikace s ODBC, se vystrčilo ven z erlang vlákna.

Nejspis tady panuje nejake zasadni nedorozumeni. Cemu rikate "preemptivni" v kontextu kodu vykonavaneho ve VM a jak to souvisi s moznosti asynchronniho posilani zprav?

Samozrejme, ze veci, ktere sahaji mimo VM muzou kod uvnitr VM zaseknout, o tom se snad nemusime bavit, to je jasne, ne?! Proto se to taky "vystrci ven", aby to ty procesy uvnitr VM neblokovalo.

V realitě většina praktických implementací VM to takto nemá a přepíná vlákna pouze při jisté dávce spolupráce s kódem vlákna.

Opet, co presne tim myslite? Ze instrukcni sada toho VM obsahuje nejakou instrukci "SWITCH", ktera preda rizeni scheduleru? Takze kdyz vytvorim bytekod, ktery tu instrukci obsahovat nebude, tak se rizeni scheduleru nepreda? To snad takhle nemuzete myslet, jaky VM to takhle ma?!

4167

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 11:49:00 »

zmínkou o kernelu jsem narážel na toto:

v user-space jen tak nenaprogramujete

Jo, to je (pro me) nepochopitelne michani zakladni urovne s metaurovni.

4168

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 11:38:54 »

tak teď by se mělo ukázat, že to nejde naprogramovat mimo kernel... ono to ale asi půjde, mi se to povedlo a to nejsem zrovna hvězdný programátor

S kernelem to nemá vůbec nic společnýho. VM je prostě VM - má vlastní virtuální čas (krokování). Jediné, čím ho může vnější svět (kernel) ovlivnit, je, že vzdálenost mezi dvěma kroky (instrukcemi) VM bude různě dlouhá v sekundách reálného času. To nás ale vůbec nezajímá, nemá to žádný vliv na to, co uvnitř VM jde nebo nejde udělat, je to metaúroveň.

4169

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 11:26:08 »

a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)

Řekl jste si o to: proces je zásobníkový automat se dvěma zásobníky a jedním mailboxem

4170

Vývoj / Re:Použití Objective-C mimo Apple

« kdy: 04. 06. 2015, 11:19:44 »

nejdřív přesně definujte asynchronnost

Asynchronnost znamená, že proces X pošle procesu Y instrukci, že má vykonat činnost Z, na výsledek této činnosti proces X nemusí čekat, ale může se klidně pustit do činnosti A a o ukončení činnosti Z procesu Y je informován nepředvídatelně kdykoli v budoucnosti nezávisle na tom, co právě dělá proces X.