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 ... 387 388 [389] 390 391 ... 618
5821
Distribuce / Re:Distro podobné BSD portům
« kdy: 18. 12. 2013, 23:53:07 »
Lenine, jakej je vlastně důvod nepoužít přímo BSD?

5822
Odkladiště / Nový side-channel attack na RSA
« kdy: 18. 12. 2013, 23:38:31 »
Izraelští kryptologové, mj. Shamir (!) dneska zveřejnili útok na RSA, konkrétně GnuPG pomocí akustického odposlechu počítače. Stačí prý obyčejný mobil na vzdálenost 30cm nebo speciální mikrofon na 4 metry a dají se zjistit hodně zajímavé věci o klíči, který se použije pro GPG šifrování nebo podepisování.

http://www.cs.tau.ac.il/~tromer/acoustic/ - tahle stránka už docela nezvládá, není divu :)
http://www.slideshare.net/daniel_bilar/acoustic-20131218 - paper

GnuPG to oznámili předem, takže oprava vyšla před zveřejněním článku:
http://lists.gnupg.org/pipermail/gnupg-devel/2013-December/028102.html
https://security-tracker.debian.org/tracker/CVE-2013-4576

Přijde mi to tak hustý, že mi to pořád připadá spíš jako dobrý předvánoční vtípek. Proto to taky radši nedávám do zpráviček, ať pak ze mě nemáte prd-el, vy hyeny! ;)

Co na to říkáte? Je to vtip nebo ne?! :)

Pro vtip: v roce 2004 podobnou věc prezentovali v zábavné sekci konference a teď se na to odvolávají.
Pro vtip: Magic-touch attack:  the attacker measures the chassis potential by merely touching the laptop chassis with his hand, while surreptitiously measuring his own body potential relative to the room's ground potential.
Pro vtip: Yes, power analysis, by measuring the current on the laptop's DC power supply, also works nicely using our low-bandwidth attack.
Něco mezi: Individual CPU operations are too fast for a microphone to pick up, but long operations (e.g., modular exponentiation in RSA) can create a characteristic acoustic spectral signature over many milliseconds, and these can be detected.
Proti vtipu: oficiální ohlášení ve vydání GPG?! Probublané do debianního advisory?! Trochu drsnej vtip, ne? :)
Proti vtipu: že by Shamir takhle krutě vtipkoval? Nebo že by někdo jeho jméno klidně uvedl na vtip bez jeho vědomí?!

No babo raď! :))

5823
Distribuce / Re:Distro podobné BSD portům
« kdy: 18. 12. 2013, 23:22:33 »
Dister, který se kompilují, je několik, ale žádné mi zatím nepřišlo tak jednoduché a čisté jako FreeBSD*

Už jsem tady říkal dávno, že místo Debian/kFreeBSD a Gentoo/FreeBSD by se hodil spíš opačnej hybrid (Linux kernel, BSD zbytek). Zatím jsem nic takovýho nenašel a docela dost hledal, takže pochybuju, že to existuje a je použitelný.

Pokud něco použitelnýho přece jenom najdeš, dej mi prosím vědět, taky bych o to stál.

* pro hnidopichy: to není flame, ale můj čistě subjektivní pocit


5824
Odkladiště / Re:Už praská bublina Bitcoin
« kdy: 18. 12. 2013, 22:17:14 »
Žádná z nich se nevyhlašuje
Ježkovanoho, co pořád máte s tím vylašuje nevyhlašuje? Když se podívám na online čísla z bitcoinové burzy, tak prostě vidím online čísla z bitcoinové burzy. Přečtete si do psích kulek na co reagujete chlapy kurňa už, hymbajz plantážníci! ;)

Tak třeba TWTRQ (než je z burzy vyhodili)
Tak příklad firmy, kterou si lidi kvůli podobnému názvu spletli s Twitterem asi nebude úplně typický případ :)

5825
Odkladiště / Re:Už praská bublina Bitcoin
« kdy: 18. 12. 2013, 19:51:13 »
Tyhle úvahy jsou trochu mimo, žádná cena se nevyhlašuje. [...] Nevím, jakou aktuální cenu udává například MtGox [...] Ale hned na úvodní stránce v hlavičce jsou udané ceny čtyři: Last, high, low a w.avg (vážený průměr).
To je polemika se mnou? V čem?

Žádná cena se nevyhlašuje, udává se nějaká aktuální cena a vlastně se vyhlašují 4? Pick one...

ale podobnou volatilitu najdete občas i u akcií nebo komodit.
Můžu se zeptat na konkrétní příklad komodity nebo akcie se srovnatelnou volatilitou? (během 6 měsíců dvanáctinásobek, během jednoho dvou dnů desítky procent dolů třikrát za sebou během jednoho měsíce) Ne že bych nevěřil, jenom by mě to zajímalo, s ničím takovým jsem se zatím nesetkal.

5826
Odkladiště / Re:Už praská bublina Bitcoin
« kdy: 18. 12. 2013, 16:39:15 »
No to je jedno. Pointa byla ze u takhle volatilni komodity jakou je napriklad BTC se cena za kterou se podari prodat muze dramaticky zmenit behem okamziku, bez ohledu na posledni vyhlasenou (jedno jestli vcerejsi uzavera nebo nejake zprumerovani) a ze ji urcuje predevsim aktualni nalada.
No tak to je nejaká divná pointa, když se cena vyhlašuje až PO TOM, co transakce proběhla.

Že to je nepraktická měna na kupování čehokoli, to je jasný, ale o tom jsme se nebavili. Bavili jsme se o tržní kapitalizaci.

5827
Odkladiště / Re:Už praská bublina Bitcoin
« kdy: 18. 12. 2013, 16:10:16 »
I když teď si uvědomuju, že třeba na btc-e je to asi prostě cena poslední transakce. Dobře je to vidět tady: http://bitcoinwisdom.com/markets/btce/btcusd

Tak teď nevím, kde jsem slyšel ten klouzavej průměr :)

5828
Odkladiště / Re:už to praská
« kdy: 18. 12. 2013, 16:07:50 »
A od ceho se asi odviji cena, ze kterou se ta transakce nakonec realizuje ? Jestli se domnivate, ze podle vyhlasene ceny, na ktere burza naposled uzavirala, tak budete asi dost mimo ;-)
Nerozumím otázce. Bitcoinové burzy nezavírají nikdy - aktuální cena na burze je (pokud vím) klouzavý průměr X posledních proběhnuvších transakcí.

5829
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 16:00:51 »
A opravdu to tak funguje spolehlivě, je to odolné proti šťourání třeba přes reflexi ? To nevím, to se ptám.
Bavíme se čistě hypoteticky, takže: umím si představit, že by se pro určitý kód dala reflexe zakázat. A taky by třeba přístup k okolnímu světu šel jenom přes nějaký proxy-objekt, takže by se snadno dalo dokázat, co plugin opravdu může a co ne...

V cloudech se přesunuje celý běžící VM mezi fyzickými stroji, mají na to udělátor třeba ve VMWare.
No právě - a to je děsně těžkopádný.

5830
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 15:58:12 »
Pokud chcete porovnávat celkový uživatelský dojem – má někdo tyhle zkušenosti (pády, záseky, lagy) třeba s GMailem?
GMail je špatný příklad, protože tam fakt netušíme, jak co a proč má Google udělané, co je rychlé jenom díky cachování atd. atd.

Na to je jednoduchá odpověď – protože to takhle na internetových diskusních fórech lidé píšou. Co na tom, že to nemají podložené vlastními zkušenostmi, ale jen to navzájem opisují jeden od druhého…
Já to ale slýchám i od adminů, kteří javové aplikace reálně spravují. Je možné, že to je fakt tím, že úroveň programátorů v Javě je obecně průměrně nižší, tomu bych i věřil.

Tohle je ale přece přesně o tom „hrubém výkonu“. Co chcete masivně paralelizovat na JDownloaderu, eclipse, Androidu? [...]
Nějaký prostor, co by bylo možné s JVM dělat lépe ale v Javě to nešlo, tam prakticky není.
Měl bych takový možná hloupý příklad, do vnitřností JVM opravdu nevidím... V Erlangu jsou afaik všechny odkazy v paměti z principu věci vždycky jednosměrné (vždycky odkaz jenom na starší data) -> neexistují cykly -> GC může být podstatně jednodušší, rychlejší a nemá takový dopad na latenci.
Takový nějaký podobný efekt by v JVM nastat nemohl? Že by prostě z nějakého principu jazyka došlo k tomu, že by celkově ta aplikace měla "hezčí chování"? 

Jedině si vzít nějakou kategorii aplikací, kde se vyskytují aplikace obojího druhu – samozřejmě s tou výhradou, že závěry nebude možné aplikovat na jiné druhy aplikací. Třeba by se takhle mohly porovnat webové servery – Apache, Nginx, IIS, Jetty, Tomcat, něco postaveného na Netty (třeba server Avastu). I v téhle kategorii je každý určený na něco jiného, ale určité srovnání by se udělat dalo.
Přesně tam myslím ta debata předtím směřovala: "ukažte mi aplikace v oblasti XY, které se prosadily".

Čas který stráví program v kernel space musí být minimální. V případě javy a (buď JVM a nebo jazelle na ARM) by se tento čas opravdu velmi protáhl.
Samozřejmě by v kernel space nejel celý JVM, to dá rozum. Proto zmínka o mikrokernelu.

Píšete o Androidu, že? Takže proč že se to neujal?
Android je pořád klasický stack. Já jsem myslel podstatně tenčí vrstvu pod JVM, opravdu jenom ve stylu nějakého speciálního mikrokernelu... (něco ala L4Linux)

5831
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 15:44:55 »
Sun to zkousel, ale vime jak to posledni roky se Sunem bylo, nejak takto: http://static.arstechnica.net/assets/2009/04/sun-oracle-thumb-640xauto-4590.jpg  :-)
Tak to je výborný :))

Ty investice do Linuxu a hlavne predtim do Unixu by nekdo musel udelat znovu a asi by neziskal nejak vyznamnou hodnotu, jen o jednu vrstvu mezi aplikaci a HW mene; ale nevim, treba to napadne nekoho z IBM nebo podobnych molochu.
Já mám stejně pořád takový podezření, jestli to nebylo právě podobně jako s tím Looking Glass - je to bomba koncept, přináší to super nové možnosti, dokázali jsme, že to v javě zrealizovat jde, ale ... ...ale bohužel je to nepoužitelně pomalý a padá to jenom se na to člověk podívá :)

(ale to je tím, že jsem k javě tak nějak předem skeptickej, žádný reálný důvody pro tenhle dojem nemám :)

5832
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 15:22:14 »
Protoze vlastne nejsou zapotrebi, evidentne se to po ekonomicke strance nevyplati nikomu vyvijet
To by mě právě zajímalo. Sun se o to pokoušel, takže si asi myslel, že by se to hodit mohlo. A zajímalo by mě, jestli to utnuli, protože se to nedařilo, nebo prostě jenom kvůli katování kostů...

Proc cpat JVM na nizsi vrstvu nez je nutne a efektivni
Umím si představit, že by to mohlo přinést spoustu úplně nových možností - hlavně pro bezpečnost: třeba snadnější verifikaci kritických částí kódu, nebo třeba lepší granularitu oprávnění a jejich volnou kombinovatelnost - ne jenom podle uživatele, jak je to víceméně dneska, ale podle funkcionality - a to ne jenom na úrovni procesů, ale i uvnitř nich - např. konkrétní plugin má právo udělat operace X,Y,Z, jiný X,Y a jiný Y,Z - a to všechno v rámci jednoho procesu a verifikovatelně (za předpokladu, že jvm pracuje správně).
Nebo právě různé ty klaudové skopičiny - třeba snadnější migrace běžících procesů by se určitě hodila, dneska se to řeší buď celkem krkolomně, nebo neřeší vůbec...

jelikož v Javě ani JVM vůbec nejsou některé věci třeba čtení a zápis portu
Samozřejmě jsem počítal s tím, že takový JVM-OS by měl to JVM trochu upravené oproti tomu současnému :)

Částečně to jde, dá se šachovat s dostupností DLL, ale není to obvyklé.
Pořádně to nejde, protože v rámci jednoho procesu může libovolný kód kamkoli zapsat, odkudkoli číst a cokoli spustit. Takže buď operaci X může udělat celý proces, nebo žádná jeho část.

5833
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 14:53:45 »
A JVM vyrobíte a spustíte v čem ? Odpovím si sám v nativním kódu. Taktéž tam bude muset být něco co toho bumbrlíčka JVM dokáže dostat a spustit, bude tam muset být podpora na přepínání vláken a a procesů a další věci a ovladače budou nutně muset být v nativním kódu.

Jasně, ale (naprosto laicky a neinformovaně) si umím představit, že ten kód pod JVM by byl opravdu minimalistický ve stylu mikrokernelu a většina logiky by byla už v jvm. Vždyť třeba takový driver v principu může jenom předávat data tam a zpátky a veškerá logika by klidně mohla být v javě (pokud by platilo, že výkon javy je v pohodě).

Plná kontrola nad běžícím kódem je dávno hotová, je to režim virtuální paměti v x86,. Povšimněte si že od W2K a na Linuxu asi odjakživa se aplikace nemohou bořit navzájem, taktéž nemohou bořit jádro.

Pod plnou kontrolou si představuju něco takového jakože třeba mám plugin, který může využívat jenom nějakou část funkcionality, protože na jinou prostě nemá jak šáhnout. To je trochu něco jiného než kód, který si může skákat kamkoli ho napadne.

Platforma s tenkou vrstvou pro JVM se neujala proto, že vždycky se našel nějak blb co uměl aplikaci napsat nativně s lepšími výsledky než v Javě.
Pokud by to bylo opravdu tak, tak by to byla odpověď na otázku, jestli je java stejně v pohodě* jako C nebo ne.

* všeobjímající termín zahrnující všechny myslitelné metriky jako spotřeba paměti, rychlost, vyvážený výkon, paralelizovatelnost atd. :)

5834
Vývoj / Re:Proč je Java pomalá a problémová?
« kdy: 18. 12. 2013, 14:38:02 »
OS z principu musí být hromada nativního kódu spouštěného vzápětí po Resetu, ovládající hardware a mimo jiné umožňující zavádět do paměti nativní aplikace a spouštět je. Jelikož pro Javu není a nebude HW, OS v Javě nikdy nebude moci vzniknout.
Proč by musela? Poměr mezi množstvím kódu pod JVM a nad JVM může být celkem libovolný, ne? Umím si představit, že platforma s jenom tenoučkou nativní vrstvou pod JVM, napsanou namíru určitému virtuálizovanému hw, by mohla být celkem terno. Akorát se to prostě ještě přes mnohé pokusy neobjevilo. A docela by mě zajímalo, proč (pokud je pravda, že java je výkonostně plně srovnatelná třeba s C).

Mít možnost plné kontroly a inspekce spouštěného kódu na vysoké úrovni by přece byla pecka. Nejenom z bezpečnostních důvodů...

5835
Odkladiště / Re:už to praská
« kdy: 18. 12. 2013, 14:31:37 »
jelikoz k transakci nemuselo dojit
Cena se odvíjí od transakcí, ke kterým na burzách skutečně dochází.

Nekdo opatrny by se IMHO nepoustel do spekulativniho obchodovani s BTC!
To je asi pravda. Tak řekněme od víc hamižných k méně hamižným :)

Stran: 1 ... 387 388 [389] 390 391 ... 618