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.


Příspěvky - Mirek Prýmek

Stran: 1 ... 170 171 [172] 173 174 ... 618
2566
Odkladiště / Re:Bitcoin mining
« kdy: 10. 03. 2017, 23:34:52 »
připojte se do našeho klubu, kde se snažíme uhodnout cenu bitcoinu pro spanovené období, zatím je to spíš sranda než nějaká hra...čím víc nás bude, tím to bude zajímavější...
No to musí být k popukání! A používáte siderický kyvadlo, záření minerálů, anděly nebo komunikaci s Aštarem?

2567
Sítě / Re:PXE boot hotového systému
« kdy: 02. 03. 2017, 17:39:51 »
Resp. to co tu výše píšete není o tom že by mi jel systém ze sítě ne? Je to o tom že spustím tenkého klienta a tím se pak připojím a systém běží na serveru, nebo se pletu?
Pres PXE se natahuje jenom bootloader (syslinux apod.), kernel a initrd. Zbytek se muze natahovat ruznym zpusobem (NFS, SMB, HTTP, ...) a bezet ruznym zpusobem (primo nad rw NFS, pres squashfs nad NFS, nebo se stahne nejakej image a pouzije jako ramdisk). Zalezi na tom, co na tom chce clovek provozovat a jake ma k dispozici zelezo.

2568
Sítě / Re:PXE boot hotového systému
« kdy: 02. 03. 2017, 15:24:28 »
ok, ale musim tedy buildnout 32 klienta a solo i 64bit ?
Anebo jet oboje na 32, pokud to neni nejakej zasadni problem.

2569
Sítě / Re:PXE boot hotového systému
« kdy: 02. 03. 2017, 15:16:58 »
mám několik klientů s architekturou 32bit a několik s 64bit, proto potřebuju řesení, kdy si při bootu ze sítě bude moci vybrat patřičný system, tedy server musí mít schopnost nabídnout několik typů OS.
To neni problem - pres PXE natahnes syslinux a v nem udelas menu klasickym zpusobem. Server zadnou zvlastni schopnost mit nepotrebuje.

2570
Sítě / Re:PXE - klient
« kdy: 02. 03. 2017, 14:10:01 »
Pokud to má být stroj s jasně daným účelem, ne desktop, tak bych šel do http://tinycorelinux.net/ mám s ním výborný zkušenosti. Dokumentace je skvělá: http://tinycorelinux.net/book.html

2571
Studium a uplatnění / Re:Kde studovat umělou inteligenci?
« kdy: 28. 02. 2017, 14:52:00 »
Ahaaa, takže ono to nejde, ale on to umí. To je dobrý, bych chtěl mít tvoji logiku. Takže je to fakt náhoda? Prostě měl jen štěstí a do počítače to nejde převést ::)
Pokud by měl počítač stejné znalosti a analytické schopnosti jako W. Buffett, tak by to šlo. Zatím je nemá.

Stejně tak pokud by měl počítač schopnosti jako G. Verdi, tak by uměl napsat nějakého nového Nabucca. Zatím je nemá. A neumíme říct, jestli někdy mít bude.

2572
Software / Re:Jaký softvér pro síťový backup?
« kdy: 28. 02. 2017, 10:24:21 »
Rozhodně Bareos. Free verze Baculy má nesmyslně zkrypleného Windows klienta, aby si člověk musel koupit placenou verzi. Bareos nic takového nemá, je plně OSS.

Podporované OS: http://doc.bareos.org/master/html/bareos-manual-main-reference.html#x1-458000B

2573
Studium a uplatnění / Re:Kde studovat umělou inteligenci?
« kdy: 28. 02. 2017, 09:26:19 »
Postupne si vypilujem co chcem a nechcem :-D Vdaka za tipy.
Jo, to je pro tebe imho nejdůležitější, abys nebyl zklamaný...

Napr. chcem pouzivat toto: http://caffe.berkeleyvision.org/ , chcel by som vediet ako to principialne funguje pod kapotou, ale nechcem to kodit (na to fakt nemam). Nechcem robit "zakladny" vyskum, ale aplikacny :-)
Jak psal kolega výš, k tomu, abys mohl používat strojové učení, ti stačí relativně málo speciálních znalostí. Potřebuješ hlavně vědět, jak se ta která knihovna používá - tj. hlavně umět nějak rozumně programovat a pořádně si to vyzkoušet na praktických aplikacích. Z teorie ti stačí víceméně znát "vysokoúrovňové vlastnosti" různých přístupů, algoritmů - umět aspoň nějak rámcově posoudit, jestli by ti daný algoritmus mohl nebo nemohl dát rozumný výsledek, jak data předzpracovat, aby byla pravděpodobnost úspěchu největší apod. Abys netrávil dny a týdny trénováním nějaké sítě na něco, co z principu rozeznat nemůže (jako třeba ty níž zmíněný akcie).

"ako to principialne funguje pod kapotou" má spoustu úrovní. Můžeš vědět "v tomhle kroku to hledá cestu do nejbližšího lokálního minima" nebo taky můžeš umět napsat složité rovnice, podle kterých se to realizuje a formálně dokazovat jejich vlastnosti. To první je pro jakoukoli rozumnou práci s ML potřeba, to druhé není, ať si kdo chce co chce říká, ať si mamka slzy utírá. Pokud nejsi talent na matiku a nemáš moře času na její dost podrobné studium, stejně se v tom daleko nedostaneš.

Spíš než se snažit jít hlavou proti zdi do oboru, ve kterém se (zatím) neorientuješ, by možná dávalo smysl využít znalostí psychologie a strojové učení zkusit aplikovat tam. To by mohlo být perspektivní - lidí se znalostí psychologie a (rozumnou) znalostí ML nebude moc.

Pro inspiraci by mohl sloužit třeba Radvan Bahbouh s jeho sociomapováním. To je imho cesta, která má smysl - svůj obor obohatit znalostí z jiného oboru, přijít s něčím novým.

Víš, kdyby ta ai byla takovy leharo, tak tady neoxidujes ale vydelavas miliony na burze :D

Predikce ciselny rady, nic vic :)
Jo, číselná řada. Akorát drtivě ovlivněná externími vlivy, které nemáš kvantifikované. Výborně řešitelné pomocí strojového učení s křišťálovou koulí.

2574
Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Timto je puvidni tazateluv problem vyresen a vlakno se muze uzavrit. Transportnim protokolem bude WBSI (Whatever binary shit inside), jenom bych se primlouval za malyho indiana, mohla by teoreticky nastat situace, kdy soucasti deploymentu bude i netcal z intelu na sparc.
To uz udelal Microsoft s PowerShellem ;)

2575
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text
Fakt?

Tohle teda asi není unix roura:
Kód: [Vybrat]
cat /dev/sda1 | cat >/dev/sda2

2576
Roury mohou být užitečné.
Roury jsou užitečné - ale na to, na co se používají, ne v té znásilněné podobě, kterou navrhuje anonym.

Pokud chci, aby něco bylo rychlé, nesmím data často převádět z jedné reprezentace na jinou. Častá serializace a následná deserializace je spolehlivý zabiják výkonu (to je i slabé místo těch microservices, zvlášť pokud se použije http a json, což je teď móda). A úplně ideální je s datama ani nehejbat - radši pamět sdílím než kopíruju.

Čili anonym to možná myslí dobře, ale vymýšlí prostě hranaté kolo. Lepší by bylo si nastudovat existující používané architektury a případně přemýšlet nad tím, jak je vylepšit, než si myslet, že všichni na světě jsou pitomci, všechno dělají blbě a já teď vyřeším všechny problémy světa zcela geniálním způsobem, kterej ještě nikdy nikoho nenapadl :)

2577
P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky.
To se už dávno používá, protože Python sám o sobě je hodně pomalý, jeden z nejpomalejších jazyků vůbec. Všechny ty "vědecké výpočty v Pythonu" spočívají v tom, že se pomocí Pythonu lepí dohromady céčkové knihovny, které dělají ten vlastní výkonově náročný výpočet. Je to docela dobrý přístup - v Pythonu se píše rychle a pohodlně a céčková implementace tomu dodá patřičný švih. Akorát ten GIL to trochu hatí ;)

...ale přes roury s lidsky čitelnou serializací se to fakt nedělá, to by ses daleko nedostal...

2578
Druha vec je, ze ma generovat lidmi citelny vystup.
Což je často největší limitace. Zašmodrcháš se do problémů typu "a jak mám vlastně oddělovat jednotlivé názvy souborů, aby ten znak zaručeně nemohl název souboru obsahovat?" viz "find . -print0 | xargs -0".

...o předávání složitějších struktur než pouhá posloupnost stringů ani nemluvě... Kdybys do té tvé architektury fakt šel, skončíš u předávání nějakých serializací (nedejmatkopřírodo JSONem) a nejednou to moc jako dobrý nápad vypadat nebude...

2579
Neber si to osobně, ale silně mi to přijde jako vymýšlení kola. Hranatýho.

Spíš se podívej na pojem "microservices". Je to teď aktuální buzzword s coolfaktorem MAX_INT. Jak už to tak bývá, když se toho chytne hipster, kterej to implementuje jenom kvůli tomu cool factoru, může to špatným, neuváženým návrhem totálně zprasit, ale základní myšlenka je v principu správná (microservices se s velkým humbukem v podstatě snaží udělat to, co se v Erlangu používá jako základní princip přes dvacet let). Při návrhu je potřeba rozumně a střízlivě uvažovat nad tím, která komponenta je stavová, která nestavová, kterou můžu libovolně škálovat, jak se budou komponenty v systému vzájemně hledat, kde budou fyzicky běžet, kdo je bude supervidovat apod. Klíčová slova: CoreOS, Project atomic, Kubernetes, Docker Swarm, etcd...

Spustitelné komponenty imho nejsou dobrý nápad - buď je spouštíš s každým requestem, což je neefektivní, nebo někde naslouchají, což zase znamená, že nemají "console API", jak píšeš. Jak budeš se spustitelnou komponentou komunikovat ze vzdáleného stroje?!

Nejpalčivější problém téhle úplně decouplované architektury je v tom, jak zajistit, aby ti nevznikl špagetový systém vzájemného volání API nikdo neví odkud kam a kdy - zašmodrchaný uzel, který nejsi schopnej rozdělit na logické celky. Nedokážeš říct, co přestane fungovat, když vyřadíš nebo upgraduješ nějakou komponentu...

2580
Docela zajímavá je otázka vytížení serveru - pokud mi víc lidí přistupuje na živé informace, tak když to rozumně navrhnu před REST, tak tam můžu dát HTTP caching reverse proxy;
Živá data stejně typicky cachovat nemůžeš, protože neznáš expiraci.

ale nemůže to být trochu problém?
Může. Ale erlang se dá dost snadno clusterovat a websockety v Phoenixu jsou na to od začátku navržené, takže se dá jít i touhle cestou. A přinejhorším kritické části můžeš do toho http vždycky přepsat - ale až to reálně bude výkonnostní problém, ne předem.

Viz https://dockyard.com/blog/2016/01/28/running-elixir-and-phoenix-projects-on-a-cluster-of-nodes
https://groups.google.com/d/msg/phoenix-talk/zjwitSVACUc/7gh8q9hBDgAJ

Stran: 1 ... 170 171 [172] 173 174 ... 618