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?
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.




Žádná z nich se nevyhlašujeJež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
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?
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.
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.
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í.
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ý.
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? [...]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.
Nějaký prostor, co by bylo možné s JVM dělat lépe ale v Javě to nešlo, tam prakticky není.
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)
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á

Protoze vlastne nejsou zapotrebi, evidentne se to po ekonomicke strance nevyplati nikomu vyvijetTo 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 efektivniUmí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ě).
jelikož v Javě ani JVM vůbec nejsou některé věci třeba čtení a zápis portuSamozř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.
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.
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.
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.
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).
jelikoz k transakci nemuselo dojitCena 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