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 - František Ryšánek

Stran: 1 ... 68 69 [70] 71 72 ... 89
1036
Hardware / Re:Doporučení NB/NUC pro teenagera na Linux
« kdy: 14. 12. 2018, 09:38:09 »
Full HD filmy? Pokud to není vyloženě starý dobrý MPEG2, tak u superlevného ntb moc nepočítejte, že to zvládne vyrenderovat film na full HD rozlišení v plné rychlosti. Na filmečky z YouTube asi v pohodě. A je asi jedno, jestli to bude repasovaný starší výkonný NTB nebo něco nového za cenu úplně nejmenší. Pokud byste pořizoval repas s diskrétní grafikou, tak mi to přijde jako recept na průser (bál bych se, že po letech provozu bude nahnilý motherboard - teplo, vakly v těch třech velikých BGA pouzdrech).

Osobně bych slevil z požadavku na full HD video (kodeky H.264 a H.265), zamáčkl slzu nad zbytečně koupenými Windows (nebo kdyžtak dual-boot) a vzal bych nejlevnější nový celeroní ntb s integrovanou grafikou, okolo 10-12 kKč, nejlépe nějaký ve slevě / vymetení skladu předchozího modelu. Takže to bude mít o generaci-dvě starý čipset a CPU a Linux už si s tím poradí. Bude k tomu dostupný novější BIOS, který přidá kompatibilitu s non-Windows OS. A vyhnout se velkým značkám, tam bych čekal kurvítka, naleštěnou bídu a klacky linuxu pod nohy. Dlouhodobě se vracím k SoHo modelům Acer (Extensa), případně Lenovo (Ideapad).

Koukám že ani není třeba kupovat windows. Jeden příklad. Bacha procesor uvnitř je ATOM. Ale podle mého moderní ATOM na školní/kancelářskou práci stačí a na YouTube třeba taky. Jsou tam k vidění i sestavy bez Windows s i3 (Skylake / Coffee Lake). Pokud se nebojíte, jsou k mání i kousky s AMD. A pod Linuxem i ty 4 GB jsou na desktop vcelku dostatečná kapacita - neživíte antivirák ani Windows Update. Upgrade bude nejspíš výměnou SODIMMu (původní 4 GB vyhodíte) - u superlevných strojů bacha, ať ty 4 GB nejsou onboard naletované a bez možnosti upgradu. Je škoda, že u levných strojů nejsou osaditelné dva kanály RAM, výrobce Vás tím ochudil o část výkonu... ale to se nedá nic dělat. Na většině e-shopů se dá vyfiltrovat určitě OS a procesor... Samozřejmě tato liga není nic pro srdcaře co kupují zásadně repasované Thinkpady.

1037
Sítě / Re:100gbit v Praze
« kdy: 14. 12. 2018, 08:39:58 »
Ptal jste se v NIXu?

1038
Hardware / Re:Externí disk nefunguje
« kdy: 13. 12. 2018, 13:26:06 »
Gratuluji. Kdyžtak 'lsusb -vt', ten vypíše strom zařízení. A nejlíp i 'lsusb -vv' (= ten ukecanej, kde jsou vidět nějaké rychlosti nebo rychlostní třídy zařízení, bohužel netuším, jestli ta informace sedí s rychlostí skutečně dohodnutou).

BTW USB3 porty bývají modré, USB2 porty černé. Ale nejde o barvu, jde o pinout. Ten se dá taky poznat, ale v samičích konektorech to chce baterku a ostré oči... s tím Vás asi trápit nemohu. USB3 port by měl obsahovat vedle "rychlých" trojkových signálů (dva páry) taky "dvojkové" signály. USB2 kontakty (4 piny) jsou v modrých i černých slotech na stejném místě, trojkové jsou v samcovi hluboko uvnitř, v samici naopak podél vnější hrany (5 pinů).

1039
Bazar / Re:Poptávka po malé desce s integrovaným CPU
« kdy: 13. 12. 2018, 13:18:28 »
...in-order jádra...
Není tohle v posledním roce vlastně výhoda? Narážím na Spectre a Meltdown...
Přiznám se, že podrobnosti Spectre a Meltdown neznám, ale pokud mohu soudit, ATOMy od BayTrail (Silvermont) po Gemini Lake (Goldmont Plus) jsou sice out-of-order až čtyřjádra, ovšem bez HT - a tušímže HT je v souvislosti s těmi bezpečnostními dírami horší zlo, než out of order execution. D525 je sice in-order, ale HTčko má. Kromě toho hloubka pipeline a vůbec složitost těchto optimalizací v out-of-order ATOMech bude citelně nižší než v plnotučných jádrech... Našel jsem nejistou zmínku ohledně novější díry "Speculative Store Bypass", kterou oficiálně trpí dvě nejmladší generace Apollo Lake a Gemini Lake (Goldmont a Goldmont Plus), ale problém není zmíněn u mírně starších BayTrail a Braswell (Silvermont / Airmont).

Meh... na nějaké to domácí žvýkání mě tyhle díry popravdě netrápí. Na HTPC vůbec ne, a na nějakém routeru... už někdo nahlásil remote exploit na dobře zabezpečeném boxu, který dobrovolně nikoho nepustí na SSH ani HTTP, určitě ne z divokého internetu? Zatím co jsem slyšel, tak Spectre/Meltdown a potomci jsou lokální útoky, člověk musí být napřed schopen spustit lokálně nějakou svoji binárku, kterou si do toho systému napřed musí nějak dopravit... Obvyklým exploitem je odposlouchávání sousedních virtuálů v témže hostingu. Ale moc to nesleduju, očekávám umravnění pokud se pletu :-)

Jo a na domácí hraní jistě nemám nic proti D525. Snad jen že oproti dnešním ATOMům žere asi trojnásobek. Ale pokud doma elektřinou topíte a máte termostat, tak je to nakonec asi jedno, jestli elektřina půjde pánubohu do oken rovnou, nebo ještě stihne vykonat nějakou užitečnou výpočetní práci... A každopádně palec nahoru za "domácí hraní". Vo vo vo tom to totiž je :-)

1040
Hardware / Re:Externí disk nefunguje
« kdy: 12. 12. 2018, 23:13:00 »
Takže ten externí disk má rozhraní USB3 ! A jede 330 kB/s? :-D :-D :-D
Vytanul mi na mysli PIO režim ATA rozhraní, ale popravdě i ten býval rychlejší.
Disk je také připojený správně na USB3 řadič.
V dumpu z lsusb dále vidím, že to má "SCSI" subclass nebo co...
Napadá mě zkusit ještě "smartctl -a /dev/sdXYZ" . Schválně jestli SMART proleze.
Nezkoušel jste ten disk připojit na USB port, který umí nanejvýš USB 2.0 ?

1041
Bazar / Re:Poptávka po malé desce s integrovaným CPU
« kdy: 12. 12. 2018, 22:57:28 »
Atom D525 je dost vykopávka, 45nm a in-order jádra. Oproti dnešním 22nm-14nm ATOMům s out-of-order jádry je to vykopávka žravá a pomalá. Ale taky dost kompatibilní, včetně tradiční intelovy in-house grafiky (model co ještě podporuje Windows XP).

Tzn. máte nějaký důvod, držet se staršího hardwaru?

1042
Hardware / Re:Externí disk nefunguje
« kdy: 11. 12. 2018, 09:42:35 »
Jestli se v tom divném hardwaru chcete ještě trochu povrtat, tak by mě případně zajímalo:
lsusb -vt
lsusb -vv
cat /proc/interrupts (nejlíp v průběhu kopírování 2x za sebou po nějaké době, třeba 10 s)

A spustit v terminálu "top" a třeba v něm ještě stisknout "1" aby ukázal jednotlivá CPU jádra (pokud to v distru není default) a velké "H" aby ukázal jednotlivá vlákna. Koukat na to v průběhu toho přehrávání. Bylo by zábavné, pokud by tu zátěž vykazoval třeba ksoftirqd, nebo naopak přehrávač videa.

Ten disk na sebe zatím nevykecal, co je uvnitř. => dále by bylo zajímavé, pokud to lze bez ztráty záruky, pouzdro lousknout a podívat se, co je uvnitř. Jestli je tam ještě rozebiratelný SATA konektor, nebo už je USB zapečené přímo na plošáku elektroniky disku (jak psal MasoxCZ). Náklonnost k SATA diskům značky Seagate totiž s původním tazatelem sdílím - a pokud by šlo osvobodit sata disk z neblahého originálního USB rámečku, tak je to taky cesta kupředu.

Osobní zkušenost: relativně levné "pseudoznačkové" USB/SATA bridge a šuplíky z Alzáče, CZC, Krupu apod. poslední dobou obvykle fungují zcela bez zaváhání (i v Linuxu). Zároveň souhlasím, že je zdravé, mít se na pozoru před superlevnými USB cetkami, které se prodávají jenom proto, že poštovné zpátky do reklamace je dražší, než nový kus.

Ohledně "uzavřených a designově vadných" výrobků slavných značek... ať si každý sám svobodně zvolí, zda chce podporovat kurvítkáře v jejich obchodní strategii. Nemohu popřít, že jakákoli svobodná skládačka v dnešní době představuje "známku punku" - takže pokud ta skládačka bude trochu estetická, tak jedině palec nahoru. Ostatně záleží na Vás, jak moc chcete vyčnívat :-)

1043
Nikoho z místních štammgastů nepřekvapí, pokud tady utrousím, že podle mého 27" je na full HD 1920x1080 přesně ta správná úhlopříčka.
Vlasů mi ubývá a moje oči už nejsou co bejvaly.
Pokud máte nějaké oblíbené starší aplikace, které neumí škálovat GUI (ikonky, popisky v menu) tak se nestyďte používat hrubší rastr. U nás v práci se tenhle formát v posledních cca 2 letech dost rozmohl.

A souhlasím, že je velmi dobrý nápad, pokud máte možnost, tak si přímo Váš kýžený displej někde prohlédnout. Ony totiž různé displeje mají různé rozložení barevných segmentů (tzv. subpixelů) v rámci každého obrazového bodu, a některé v hrubém rozlišení tahají za oči víc než jiné. (Například TV displeje zrovna na tenhle aspekt optimalizovány nejsou.)

1044
Hardware / Re:Externí disk nefunguje
« kdy: 10. 12. 2018, 08:57:31 »
Taktak... držet se otevřených rozhraní - včetně rozhraní SATA mezi diskem a šuplíkem, a včetně USB Mass Storage (nejlépe s podporou UAS, SAT nebo s nějakým proprietárním transportem ATA over USB s podporou v Linuxu).

On to není jenom Seagate, kdo dělá externí USB disky naschvál divné - Western Digital je totéž v bledě modrém. Smažete z disku původní obsah a je z něj cihla, apod. A šetřej na doraz na čipsetu USB Mass Storage řadiče.

Externích šuplíků nebo konvertorů USB/SATA je spousta, a když máte trochu přehled o "solidních neznačkách" na našem trhu, tak většinou při výběru chybu neuděláte. Recenze na velkých e-shopech bývají docela dobré vodítko i u méně známých "paznaček". Ono to vede taky k tomu, nekupovat horké novinky, což není špatný přístup v obecné rovině, a není to špatný přístup s ohledem na Linux. A nebudu se rozepisovat o sexy štíhlém pouzdře vs. chlazení.

Hehe BTW.

1045
Hardware / Re:Write once, read many storage
« kdy: 07. 12. 2018, 11:44:36 »
Ke všem správným poznámkám předřečníků si troufnu pípnout, že je poměrně blbost řešit toto v blokovém zařízení, na kterém byste chtěl provozovat nějaký standardní filesystém (který by nevěděl o to, že to zařízení je WORM) protože normální FS potřebuje občas nějaké bloky i přepsat. Navíc granularita zápisu by byla 1 blok (512B nebo tak něco kolem).

=> podle mého hledáte když už, tak zařízení "sekvenční", appendovatelné nejlépe po bajtech. Tzn. něco řádkovou tiskárnu s nekonečným traktorovým papírem, ale v elektronické podobě. Sériová linka se zapojeným pouze TX (Jenda) je ten správný princip.

Celé to ale správně zazdil pan Jirsák požadavkem na blockchain a časová razítka...

Uff ještě že mě toto neživí.

1046
Hardware / Re:Write once, read many storage
« kdy: 06. 12. 2018, 21:19:01 »
Myslím že P a Uuuu oba trefili hřebík na hlavičku.

Jinak samozřejmě existují i proprietární řešení:
https://www.innodisk.com/en/technology/Security/write-protect

1047
Support není špatnej způsob, jak se dostat někam do trochu profi IT prostředí - a dál se uvidí.
Samotná ta práce prezentuje spoustu témat a motivací k dalšímu sebevzdělávání.
Bohužel k dalšímu odbornému postupu = specializaci může být žádoucí, přestat být ochotná děvečka pro všecko :-(

1048
Původnímu tazateli: ta deska má klasický MiniDIN 6-kolík PS/2 konektor. Takže si sežeňte klávesnici a myš s PS/2 konektorem a nejlíp ještě rozbočku (Y-cable) která sloučí 2x Mini-DIN do 1x Mini-DIN. On sice v návodu není pinout, ze kterého by plynulo, že má deska v Mini-DINu skutečně zapojeny všechny piny pro PS/2 i myš, ale dodnes je slušná šance, že ano (výjimky jsou naštěstí vzácné). Na pinech KBCLK+KBDATA umí deska autodetekovat i přímo připojenou myš (bez rozbočky), ale v tom případě nemáte klávesnici.  Každopádně na PS2 nefunguje hot-plug, musíte mít na PS2 všechno definitivně připojené před zapnutím počítače (tuším +5VSB může být v okamžiku připojení PS/2 věcí už přivedeno, ale neuděláte chybu, pokud bude počítač v tu chvíli vytažený ze zdi, on se dá počítač PS/2 klávesnicí taky probouzet apod.)

Jo a na pasivní redukce USB->PS2 bych u dnešních klávesnic a myší už moc nespoléhal, šváb v klávesnici/myši musel umět oba režimy (USB i PS2) a po přivedení napájení poznat, čím se motherboard snaží bavit.

Neznám čipsety AMD ani BIOSy co dává AsRock. Intel někdy od Broadwellu už vůbec nemá v čipsetu EHCI řadič (typický pro USB 2.0, s class-based podporou ve Win7 od přírody), jenom XHCI (typický pro USB 3.0). Odhadem to Intel provedl jako jedno dílčí opatření směrem k řízené záhubě Win7. Pokud AMD tento trend okopírovalo, tak si možná nepomůžete, pokud v BIOSu zakážete XHCI řadič (což je v návodu zmíněno). Pozor, nehraje roli, že máte zvenčí dostupné elektrické porty schopné provozu USB 2.0 (což jsou obvykle i všechny "modré" konektory, protože USB 2.0 tam má své tradiční nezávislé signálové linky). USB 2.0 zařízení lze připojit i na XHCI, buď skrz přídavný hub čip na motherboardu, nebo i přímo na čipset (hub je integrovaný) - prostě jenom vůči hostiteskému CPU už není ve stromě PCI zařízení vidět EHCI, všechno se to obsluhuje skrz XHCI.

No a jakmile Windowsy jednou nainstalujete, tak máte vyhráno. I pokud byste to provedl blafákem s přepnutím USB řadiče do EHCI režimu (pokud to čipset umožňuje), tzn. nemáte PS/2 KB/MS, tak už drivery pro XHCI doinstalujete v nouzi přes vzdálenou plochu.

Mimochodem, nejsem AMDčkař, driver pro grafiku do Win7 máte?

1049
Software / Re:Vysvětlení pojmu InitramFS
« kdy: 24. 11. 2018, 00:12:57 »
Ravise a RDa už se toho ujali, takže teď budu trochu nosit dříví do lesa...

a nasledne spusti /sbin/init, ktory pusta init scripty?

/sbin/init býval původně kdysi dávno jenom jeden - ten co se spouštěl z přímo mountnutého definitivního kořenového svazku. A máte pravdu, že spuštění initu (procesu s PID=1) skutečně následuje vzápětí po mountnutí rootu.

/sbin/init je především spustitelný program. Díky kernelové autodetekci, o jaký typ spustitelného programu se jedná, nemusí jít nutně o ELFový binár, může to být stejně tak nějaký skript, třeba shellový. Pokud se jedná o skript, správný interpreter se natáhne podle konvence #!/cesta/k/interpreteru na prvním řádku skriptu. Ten "hash a vykřičník" jsou skutečně vypečená finta, a právě na ně se jádro chytá. Pokud se nepletu, tak initial ramdisky takový skript pojmenovaný /sbin/init dříve obsahovaly. Jinak když si zkusíte poskládat bootovatelné "distro" skutečně od nuly, tak první školní příklad je ten, že na budoucí kořenový svazek nakopírujete všechny potřebné knihovny, především libc, a minimální sadu systémových prográmků, především shell, a jméno /sbin/init dáte symlinku na /bin/sh nebo tak něco. (Jasně - nebo na Váš skript.)

V situaci, kdy se mountne na / napřed dočasný initramfs, a až pak finální root, je samozřejmě otázkou, jestli bude /sbin/init jeden, nebo dva... V jednom odkazu co jsem vložil do té předchozí tapety je bootování skrz initrd popsáno včetně toho, že k remountu na finální kořenový svazek se používá syscall pivot_root()... čili někde kolem se zřejmě taky přepřáhne dočasný "init z initial ramdisku" na finální init. Pokud to máte takto zařízeno standardním způsobem. Alternativně by asi šlo, aby ten lehký init nebo init skript, co nastartoval z initrd, spustil "finální velký init" nějak explicitně. Vlastně by na to stačil jediný exec() a finální init by převzal i charakteristický PID=1. Nebo by ten velký init mohl nakonec startovat už přímo z initial RAMdiku? Teoreticky ano, ale tušímže to žádná mainstreamová distribuce takto nedělá... Chcete-li vědět, jak je to doopravdy, klidně se ponořte do zdrojáků své distribuce :-)

Koukám tady v Debianu 9 na /sbin/init jednak na finálním rootu (diskový oddíl),
jednak v initial RAMdisku. V obou "svazcích" skutečně takový soubor existuje.
Na disku se jedná o symlink na systemd, uvnitř initrd se jedná zřejmě o hardlink
(jeden z mnoha) na multifukční ELFový binár busyboxu. Takže nejen Gentoo má v initrd zapečený poloplnohodnotný busybox ;-)

Jo a pokud jde o to, co "init" vlastně dělá: ten skript nebo minimální "přípravátor" v initial RAMdisku skutečně hlavně provede pár skriptů (nějaké ty přípravné práce). Pokud jde o "finální velký init", tak tradiční sysv init volal napřed rc.sysinit, pak snad rc.local, a pak všechny startovací skripty různých služeb/démonů, kteří v systému běží. Systemd má konfiguraci trochu jinou a taky o jeho celkové koncepci by se dalo dlouze debatovat, ale v podstatě se opět jedná především o "service manager".

Len bohuzial, stale nerozumiem pojmu 'predom priraveny obraz zavadzacieho systemu na disk'. Stale som nejako v tom, ze ovladace, moduli su priamo v jadre... Preto odpadava nutnosti instalovat ovladace oproti win... A aj ked nahravam nejake moduli do jadra, napr. conntrack modul, nenahravam ho do initramfs...

Smíchal jste několik rovin :-)

Linux má skutečně pro spoustu hardwaru "ovladače" v tom smyslu, že jsou přítomny v upstream vanilkovém stromě zdrojových kódů (textů, programů v jazyce C) a Linus a jeho pobočníci tyto ovladače dlouhodobě oprašují/udržují kompatibilní s "kernel core" tzn. se základem jádra.

Prvním krokem při kompilaci jádra ze zdrojáků je to, že vlezete např. do "make menuconfig", kde u jednotlivých ovladačů zvolíte, zda se mají přilinkovat k hlavnímu bináru jádra (tzv. "monoliticky") nebo zda se mají slinkovat do podoby externích souborů s příponou .ko, těm se říká "jaderné moduly". Je to obdoba dynamických knihoven v user space. Třetí možnost v menuconfigu je, ovladač z buildu zcela vynechat.

Bývaly kdysi dávno doby, kdy hotové binární jádro (výsledek kompilace) tvořil jediný monolit. Ovladače ke kompilaci se daly jenom povolit/zakázat. Pokud povolit, tak to automaticky znamenalo přilinkování do zmíněného monolitu. V zájmu modularity binárních distribucí (bez potřeby kompilovat jádro pro každý stroj zvlášť) byly poměrně záhy zavedeny "moduly": malé úlomky, které se k monolitu daly za jízdy podle potřeby připojovat (a odpojovat).

Základní binární "monolit" jádra je na disku uložen v /boot/vmlinuz-blablabla-verze. Odtud ho při startu sosá bootloader. Moduly .ko na disku spinkají uložené v /lib/modules/verze/... . Do obrazu initial RAMdisku se nakopírují pouze moduly, které jsou před mountnutím finálního rootu potřeba - což nejsou zdaleka všechny. V dnešních univerzálních desktopových distribucích bývá "distribuční" kernel zkompilovaný prakticky se všemi dostupnými ovladači v modulární podobě (.ko) takže příslušný podadresář v /lib/modules/verze je pěkně košatý a nafouklý. Natáhnout modul z disku do jádra (tzn. vlastně ho "spustit") je možno rukama z příkazového řádku příkazem insmod nebo modprobe. Modprobe je schopen automaticky dotahat všechny moduly, na kterých požadovaný modul závisí (systém má k dispozici mapu vzájemných závislostí). Dalšími příkazy z téhle rodiny jsou lsmod a rmmod.

Pod linuxem soubor .ko je něco jako pod Windows soubor .sys. V obou případech se jedná o kus binárního kódu, který lze zavést do běžícího kernelu, a modul/ovladač se definovaným způsobem uvnitř kernelu přihlásí / zapojí do práce. Že se pod Windows soubory .SYS distribuují pohromadě s popisným souborem .INF a podpisem .CAT, a na rozdíl od Linuxu nejsou příliš jemně verzované, to je v zásadě malá nuance, která souvisí s modelem vývoje softwaru (každý operační systém ho má postavený trochu jinak, zcela jistě Linux vs. Windows).

Co je to ovladač: je to malé bago spustitelného kódu, s nějakou standardizovanou "hlavičkou" / datovou strukturou s předepsanými údaji a odkazy na výkonné funkce modulu. Je to vlastně kolekce volatelných funkcí. Některé ty funkce jsou "zveřejněné", tvoří rozhraní modulu vůči zbytku jádra - jiné jsou "privátní", modul je používá pouze interně. Pokud někdy uslyšíte o "tabulce symbolů", tak se jedná o jména funkcí a proměnných uvnitř modulu (především těch veřejných). Velikou tabulku symbolů obsahuje také hlavní monolit jádra. Vzájemné vypořádání symbolů poskytovaných a požadovaných mezi monolitem a moduly navzájem je náplní práce kernelového dynamického linkeru... (Velmi podobně to funguje u user space programů a dynamických knihoven. Ovšem zatímco user-space program při nevyřešených zavislostech zhavaruje, kernelový linker jenom odmítne natáhnout modul, pro který nemohl vyřešit všechny závislosti.)

Na úrovni zdrojových kódů je "ovladač" opět kolekce funkcí - ve zdrojákách. K vytvoření jednoho binárního kernelového modulu může být potřeba jeden nebo více zdrojáků = textových souborů s příponou .c. Předpis pro sestavení modulu z jednoho či více zdrojáků je obsažen v tzv. Makefile. Přesněji zrovna v kernelu se jedná o celý rozsáhlý strom dílčích souborů Makefile a Kconfig (oba jsou to textové soubory) - granularitu skladby (linkování modulů) lze detailně ovlivnit konfigurací kernelu.
Obvykle je granularita kernelových modulů volená tak, že jeden modul = jeden ovladač, pro specifický hardware. Ale klidně může jeden modul obsahovat ovladačů několik. Kromě toho ne všechny moduly obsahují drivery pro hardware, často modul opouzdřuje nějakou čistě softwarovou fičuru v systému. Třeba nějaké dílčí "porovnávací pravidlo" pro netfilter.
Přesto pojmy "modul" a "ovladač" v obecné mluvě často dost splývají.

Ovladače od třetích stran mají v Linuxu těžký život, hlavně kvůli jemnému verzování kernelů. To souvisí s průběžným inkrementárním vývojem a releasováním linuxového kernelu jakožto softwaru. Pod Windows obvykle stačí, aby byl driver kompatibilní s poměrně hrubým základním číslem verze kernelu (cca na úrovni verzí Windows). Pod Windows dokonce existují mechanismy (styl programování), jak zařídit, že může být binárka ovladače kompatibilní s více verzemi Windows.
Zato pod Linuxem je prakticky vynuceno, že zavést do jádra lze pouze modul zkompilovaný proti téže třímístné verzi kernelu (resp. včetně "patchlevel ocásku verze", který si můžete sami definovat při kompilaci), ba dokonce lze zapnout verzování až na úrovni "sériového čísla buildu". Dnešní distribuce toto mají běžně v distibučním kernelu zapnuto, já to ve svých custom kernelech vypínám, abych při ladění modulů nemusel po rekompilaci hlavního kernelu rekompilovat bez pardonu taky všechny externí (out of tree) ovladače.

Ovladač, od kterého máte k dispozici kompletní zdrojáky, můžete poměrně snadno přikopírovat a zaháčkovat do vanilkového stromu, který jste si stáhl na lokální disk - a zkompilovat "in tree". Existuje ale také oficiálně podporovaný postup, jak svůj custom ovladač zkompilovat "out of tree", pouze s odkazem na hlavní strom někde jinde na disku (a jeho verzování). Rozdíl je nakonec vlastně jenom v cestě k adresáři, kde se zdrojáky "vašeho" modulu nacházejí. Čili toto platí pro "ovladače třetích stran", pokud jsou k dispozici kompletní zdrojáky.

Jiná je situace u ovladačů třetích stran, které obsahují "binární blob". Překlad mnoha tradičních programovacích jazyků do binárního executable kódu se děje ve dvou krocích: kompilace a linkování. První krok vyrobí z jednotlivého zdrojového souboru (např. .c) "polotovar" zvaný "objektový soubor" (.o nebo třeba .obj). Ve druhém kroku se několik objektových souborů slinkuje do potřebného finálního formátu: to může být user-space executable binárka, nebo statická či dynamická knihovna, nebo třeba kernelový modul. Výrobci hardwaru mají i pod Linuxem sklon, nedávat volně k dispozici zdrojové kódy ovladačů. Nechtějí podporovat konkurenci apod. Takže dodávají nějakou interní knihovnu ovladače v podobě "objektového polotovaru". A to je právě ten ohavný binární blob. On obsahuje tabulku symbolů, takže jeho funkce lze volat - ale zároveň je to černá skříňka, do jejíž vnitřní logiky nikdo nevidí. A může se stát, že ten blob byl zkompilovaný proti starší verzi kernelu (jde o deklarace structů a prototypy funkcí, ale taky o věci hlouběji pod kapotou), takže když ho jenom obalíte do open-source "košilky" a tu zkompilujete proti kýženému novějšímu kernelu, tak to vypadá navenek OK, ale ten blob může za provozu způsobovat chyby. Což je vedle ideologického imperativu dost dobrý praktický důvod, proč se binárním blobům v ovladačích bránit. A že se Linux (Linus) brání zuby nehty.

Končím - chtěl jsem něco vysvětlit a spíš do toho jenom dál a dál zabředávám...

1050
Sítě / Re:LTE pásma 1,8 GHz vs. 3,7 GHz
« kdy: 23. 11. 2018, 21:13:13 »
Mu-mimo 8x8 umí technologie od Cambium Networks i v 5ghz včetně TDD a funkcni GPS synchronizace...

Err... Cambium Networks - v pásmu 5 GHz jistě, ale tipnu si, že se jedná spíš o "wifi-newifi" s media-access mechanismem TDMA, nikoli o "LTE TDD" (terminus technicus).


Omyl Cambium nepoužívá TDMA to co vy zmiňujete se snaží používat Ubiquiti. To wifi-newifi. Se zbytkem s vámi souhlasím.

Namátkou jsem si vybral tenhle spec sheet, linknutý odsud. Ano píše se tam TDD. Ale taky 802.11ac wave 2. Takže máte pravdu, že to skutečně není "wifi-newifi". Je to docela normální 802.11ac. Ta specifikace firmy Cambium se k "media access mechanismu" nijak dál nevyjadřuje - a jak už jsem zmínil, v obecném smyslu TDD je i standardní half-duplexní CSMA-CA. Frekvenční kanál je jenom jeden, a účastníci se střídají ve vysílání.

Stran: 1 ... 68 69 [70] 71 72 ... 89