Příspěvky

451

Software / Re:Kompatibilita binárních ovladačů pro AmLogic S905

« kdy: 29. 10. 2016, 13:12:23 »

Odpověď jsem našel tady: http://stackoverflow.com/questions/18106731/linux-kernel-module-ko-compatibility-between-kernels.
Takže moje další otázka je, jestli jde Android osekat na úroveň Tiny Core Linux, tzn. nechat jen jádro, ovladače, příkazový řádek a vtěsnat to pod 100 MB.

452

Software / Kompatibilita binárních ovladačů pro AmLogic S905

« kdy: 29. 10. 2016, 12:32:43 »

Dobrý den a předem se omlouvám za začátečnický a možná již dříve zodpovězený dotaz.
Závisí ovladač na verzi jádra ? Mám pocit, že při kompilaci se používají hlavičkové soubory z adresáře include/linux, takže se obávám, že ano.
Jde mi o to, jestli můžu použít binární closed-source ovladače z Androida např. v LibreElecu nebo Tiny Core Linuxu na procesoru AmLogic. Android z interní eMMC paměti bootuje strašně dlouho, zřejmě protože se načítájí stovky MB. Chci na tom jen jednu svou aplikaci s plným přístupem k HW a všem tlačítkům ovladače, takže mi víc vyhovuje Linux se všemi ovladači včetně HW akcelerace HEVC a kreslení do DirectFB.

453

Studium a uplatnění / Re:Návod jak začít s Javou (pro nevývojáře)

« kdy: 25. 10. 2016, 07:55:26 »

EE bych nechal na později, na začátku doporucuju JSP a servlety.

JSP a servlety nejsou EE ?

454

Hardware / Re:Herni PC a televize

« kdy: 24. 10. 2016, 08:27:14 »

Na přehrávání multimediálního obsahu mi stačí Android Media Player, za který jsem dal 150 korun...Dál má WiFi, čtečku karet a SATA port.

Můžeš prozradit název ? Kromě přijímače Fergusson Arriva 4K neznám přístroj s Androidem a SATA portem. Tedy pokud to není x86 verze. Marně hledám procesor se supernízkou spotřebou, plnou akcelerací H.265 a dvěma SATA porty. Ideálně ještě se dvěma vstupy TS a sběrnicí I2C a to celé na desce jakou má Raspberry Pi.

455

Vývoj / Re:Jak to vidíte se Swiftem?

« kdy: 15. 10. 2016, 07:07:57 »

Nevidím důvod, proč by měl být okrajovější než C#. Obojí jsou jazyky pro jednu platformu. Tak jako okrajově pronikl C# na Linux (na Linuxu je populárnější Java), pronikne Swift do Windows. Myslím, že okrajovější než Swift budou C++/Cx a Pascal.
A proč to vlastně řešíš ? Podstatné je, jak se Swift prosadí v systémech Apple (OS X, iOS) oproti Objective C. Myslím si, že se prosadí rychle, protože Objective C je horror. Programátoři C# taky většinou neřeší, jak se jejich jazyk prosadí mimo Windows.

456

Vývoj / Re:Internet Explorer nezpracuje data předaná Ajaxem

« kdy: 14. 10. 2016, 18:22:54 »

pouzivam debugger v browseru...fiddler je neco vic?

Co já vím, Fiddler je hlavně pro sdílení spustitelných ukázek na inernetu, místo vkládání kódu do diskuzního příspěvku. Ale v tomto případě by to ještě chtělo phpfiddle.

457

Windows a jiné systémy / Re:Starý program pod Win7+

« kdy: 11. 10. 2016, 12:05:47 »

Ostatní aplikace na WinE neběží ? Linux jako hlavní systém by byl určitě lepší než ve Virtuálu a asi i lepší než ReactOs. Navím mám dojem, že ReactOs taky nedá přímý přístup na HW.
Zajímalo by mě, jak se aplikace ve WinE dostane k tomu HW klíči.

458

Windows a jiné systémy / Re:Starý program pod Win7+

« kdy: 11. 10. 2016, 11:44:13 »

To je teda zajímavé že mi dosové aplikace fungují pod win 7 32b a ve win 10 32b ještě líp.

DOSový program prý jde jen ve W9x, z čehož vyplává, že nejede v NTVDM. Nejspíš potřebuje přímý přístup na HW, jak tu zaznělo. Jedině udělat dva drivery. Jeden bude v NTVDM odchytávat výjimky při pokusech o zápis IO portů a druhý bude zapisovat na IO porty.

To, že DOS jde jen pod 32b Windows je zásluha tolik opěvovaného AMD. Intel jako první přišel s 64-bitovým procesorem Itanium, ale s úplně novou instrukční sadou, který nebyl nativně zpětně kompatibilní. Díru na trhu vyplnilo AMD s CPU, které umělo jak novou instrukční sadu AMD64, tak i x86/IA32. Protože pro něj vznikla hromada software, Intelu nezbylo nic jiného, než implementovat AMD64.
Otázkou je, proč v AMD rozhodli, že nové instrukce budou jen v novém režimu "longmode", ve kterém nebude V86. Instrukční dekodér stejně musí umět i staré instrukce, takže mě rozumný důvod nenapadá. Nejde o to, aby v jednom programu mohly být všechny režimy najednou, to nešlo ani na 386. Jde o to, aby režim CPU šel nastavit na úrovni každé aplikace, jak bylo zvykem na 386 (byla volba V86, 16b PM a 32b PM).

459

Hardware / Re:O2 TV bez originálního set-top-boxu

« kdy: 11. 10. 2016, 11:27:39 »

Asi neprozradíš, proč to musí být bez settopboxu.
Na Android TV by to mělo jít, stejně jako jde například Poda.

460

Odkladiště / Re:V čem naprogramovat meteostanici na Raspberry Pi2?

« kdy: 02. 10. 2016, 18:43:23 »

Pokud chceš hw urychlené filtrované zmenšení obrazu, použij C++ a OpenGL.

461

Studium a uplatnění / Re:Studium JavaEE v době JS knihoven

« kdy: 02. 10. 2016, 18:39:10 »

Oracle Javu v podstatě pohřbil.

462

/dev/null / Re:Pro ty, kteri za min nez za 100 nevstanou z postele...

« kdy: 30. 09. 2016, 18:20:53 »

Kdo chce krást, nesmí se nechat chytit. Ti, co zadávali datové schránky, byli šikovnější.

463

Vývoj / Re:Vývoj sw pro Android v C, CPP bez Javy

« kdy: 18. 09. 2016, 07:33:26 »

Není GUI Androidu psané v Javě ? Aspoň mám takový pocit, že pro GUI na Androidu je Java stejné nutné zlo jako Objective C (nebo dnes Swift) na Mac OS X.

464

Vývoj / Re:Pametova a vypocetni narocnost JVM vs .NET

« kdy: 18. 09. 2016, 07:28:42 »

Celkem o tom pochybuji - máte např. nějaká měření, kde SQL Server počítá skalární součiny rychleji než aplikace v C#?

Pokud např. v MySQL bude skalární součin počítat UDF v C++, bude to rychlé jako C++. Vsadím se, že databáze s podporou GIS budou mít takové funkce vestavěné. Jde hlavně o to, že na moderním HW je výpočet součinu záležitostí několika strojových cyklů, narozdíl od režie na poslání vektoru přes soket do aplikace v C#. V Javě má navíc překvapivě vysokou režii ovladač JDBC. Mám změřeno, že načtení velkého objemu z MySQL je výrazně rychlejší v C přes libmysqlclient než v Javě přes Connector/J a navíc se nejprve vše načítá do RAM, než lze z Resultsetu načíst první záznam. Pokud je výstup výpočtu menší než vstup, je obvykle výhodnější provést výpočet v db serveru.

465

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 17. 09. 2016, 17:16:12 »

Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.

Firebird transakce má a u nás po havárii většinou dopadne hůř než MyISAM.