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 ... 11 12 [13] 14 15 ... 84
181
Hardware / Re:Výroba překříženého kabelu RJ12
« kdy: 08. 03. 2023, 11:24:02 »
Zkoušel jsem hledat jestli to schéma kabelu nejde najít a na jednom shopu jsem našel jakýsi obrázek kabelu k PDU a podle toho obrázku byla "čárka" na placatým kabelu u obou konektorů stejně - nešlo tedy o křížený kabel. Jelikož neznám přesný produkt, zkusil bych jít i touhle cestou, podle partnumberu si někde najít fotku kabelu a vydedukovat to z toho. Případně PDU rozebrat a kouknout jestli není popsaný pinout konektoru na DPS.

V tom kabelu je nejspíš nějaké low-volt DC napájení, něco jako 5/12/24V. To by se dalo najít i multimetrem. Případně zkusit doměřit ohmmetrem, jestli některý pin je zem (propojený na kostru PDU nebo na prostřední kolík v silových zásuvkách). To napájení se rozhodně křížit nesmí - a docela se divím, že PDUčko přežilo zkusmo připojení kříženým kabelem.

Dále tam bude pár žil komunikace. V nejjednodušším případě by stačily dvě žíly. To může být RS232 RX+TX, nebo UART TTL RX+TX, nebo RS485 A+B, nebo třeba I2C SDA+SCL. Nečekal bych tam RS422 RX A+B a TX A+B. Křížit by bylo potřeba komunikaci, která má na dedicated pinech RX a na jiných TX, tzn. RS232 nebo UART TTL nebo RS422 (čtyřdrát=dva páry). Pokud se to smí kaskádovat, tak spíš než RS232 bych tam čekal nějakou obousměrnou multipoint fyzickou vrstvu, např. RS485 nebo I2C - a tyto by se nejspíš zapojovaly 1:1 (datové signálové piny). Je možné, že to svobodné hvězdicové zapojení funguje jenom za předpokladu krátké délky vedení = správně by se měla dodržet lineární sběrnice ale kašleme na to.

S tímhle by pomohl skop. Koukat s ním na signálové piny master PDU. Zjistit nejdřív pravděpodobné napájecí žíly (zem a +), pravděpodobné komunikační žíly, ty si ošmatat skopem, a pokud je komunikace trvale zticha, tak zkusit na ty komunikační žíly koukat v okamžiku přivedení napájení PDUčku.

Citace
Avšak stále platí, že nejjednodušší je zeptat se výrobce/prodejce.
Amen.

P.S.: hehe takovej M-bus... to by byl setěr.

182
Hardware / Re:Výroba překříženého kabelu RJ12
« kdy: 07. 03. 2023, 16:09:37 »
Podle mého tazatel nedodal dostatek informací, a v internetech taky nelze nic moc dohledat.

Našel jsem nějaký návod. Ten kabel se používá ke vzájemnému "stohování komunikace" více managovatelných PDUček - viz obrázek na str.8. Sedí informace, že se jedná o RJ12 6P6C. Ale nikde ani stopa nějakého pinoutu nebo barviček. Doporučuji dotaz na technickou podporu výrobce, a/nebo pokud máte kus originálního exempláře, tak propískat. Možná by byly barvičky i vidět skrz čirý plast RJ12, pokud není konektor stíněný/krytovaný.
Třeba u stolních telefonů Panasonic bývá mikrotelefon připojený spirálovým čtyřdrátem RJ11 4P4C, který je "křížený" popsaným způsobem, tzn. 1..4=4..1 . Ale z toho naprosto nelze usuzovat, že crossover cable v případě nějakého nedokumentovaného proprietárního komunikačního propoje mezi PDU konkrétního výrobce bude zadrátován stejným způsobem. Pokud je originální kabel plochý, tak této variantě přidávám pár procent pravděpodobnosti - ale fakt bych nechtěl někomu tvrdit, že to je jediná možnost, přičemž v konečném důsledku by se přepólovalo napájení nebo odpálil linkový transceiver. Mimochodem návod zmiňuje, že v tom kabelu je i napájení (asi pro případ, že druhé PDUčko vyrazilo pojistku - tak aby mu fungoval aspoň management).

183
Bazar / Re:Sháním malý rack za půl darma
« kdy: 03. 03. 2023, 11:24:37 »
Otrava je, že tady snad nikdo nemá v e-shopu pořádný filtr na rozměry těchhle skříněk.
Nejlepší filtr jsem našel asi v RS-Online = zahraniční distributor, který nepatří mezi levné.

1500-1800 Kč za elektro rozvodnici přiměřených rozměrů zřejmě není vůbec úlet. Z druhé strany, pokud by to vyřešily čtyři prkýnka a půlmetr čtvereční Sololitu, a čas/práci moc neřešíte, tak jste v OBI apod. někde na nižších stokorunách... Ale popravdě, to už bych se spíš pokusil najít nějaký úložný plastový kontejnerek (nižší nebo vyšší) s kompatibilním víkem... dokonce se dělá varianta s integrovaným víkem na pantech. Fakt je, že to nejspíš nemá samozhášivost jako echt elektro krabice, takže pokud vám to na půdě blafne, tak já Vám to neporadil ;-)

Úložné/přepravní kontejnerky se dělají i kovové, ale jste zpátky na ceně za košer elektro rozvodnici.
Dál už mě leda napadá, zajít za místním klempířem a nechat ho střihnout a naohýbat na míru 2x U z pozinku. To by taky nemuselo být drahé.

184
Server / Re:Duplicitní zprávy ze Seznam.cz na Postfixu
« kdy: 02. 03. 2023, 17:43:44 »
Taky něco takového provozuju,  a tenhle problém jsem ještě nepotkal.
Měl bych k tomu spoustu doplňujících otázek, na které se nesluší dávat veřejné odpovědi.
Popravdě něco takového řešit, znamená mít nejlépe hands-on přístup :-(
Uvedu pár otázek/nápadů, na které si sám odpovězte = nechci tady veřejně číst odpovědi:
- nemáte ten stroj s postfixem až za nějakým CPE firewallem, který může SMTP relace nějak netriviálně filtrovat/mrvit?
- zkoušel jste si típnout tcpdumpem záznam takové relace? Upozorňuji na možnost, na serveru típnout do souboru a následně prohlížet PCAP někde offline, v pohodlí vysokého rozlišení, v grafickém tcpdumpu. Típnout do souboru můžete jenom podmnožinu provozu, která Vás zajímá.
- koukal jste do logů Postfixu? /var/log/mail.log nebo tak něco. Obvykle na sebe dost vykecá.
- v /etc/postfix/main.cf (ev.též master.cf) všelijaké "checks", "restrictions" nebo "content_filter" klauzule... je toho hodně. Co třeba nějaký content filter typu "rbl check", který se doptává kamsi do dáli, a může při tom timeoutovat ? (Ale je to divné, konkrétně RBL check tuším vykopne, aniž by zdvořile odpověděl na EHLO.) Ony různé tyhle kontroly se dají zařadit do různých fází průchodu zprávy serverem.
- když občas něco někde blbě dlouho hnije a timeoutuje, stojí za to zkontrolovat, jestli běhá správně DNS na Vašem serveru = jestli když se zeptá, tak dostane hbitě odpověď. Třeba nějaký ten reverzní dotaz na adresu přistupujícího "klienta" (odesílajícího SMTP). Taky bejvalo něco jako služba "ident", která se na firewallu filtrovala stylem "reject", aby selhala hned...
- třeba Postgrey se mi takhle nikdy neprojevil.
- jak moc je to Vaše distro mainstreamové, vs. obskurní / "svoje"... Jak moc je to bleeding edge.
- jak rychle se ty opakované zprávy hromadí? Kolik času uplyne mezi dvěma zprávami?
- přemejšlím / nejsem si jist, jestli se tak nemůže chovat nějaký problém v konfiguraci lokálního doručování. Netuším, kdy přesně Postfix v SMTP řekne "OK message accepted for delivery".

Hele tohle se Vás náhodou netýká?

185
:-/  CTRL+INS / SHIFT+INS je v některých situacích defaultní dvojhmat pro práci s clipboardem...

186
Vývoj / Re:Jak funguje cache v relační databázi?
« kdy: 02. 03. 2023, 11:29:05 »
Měl jsem představu, že tyhle věci fungují tak nějak samotížně. V relační databázi hlavně hleďte oindexovat všechno, podle čeho vazbíte nebo vyhledáváte. Toto je otázka návrhu datové základny = součást tvorby aplikace. A dejte RDBMS dostatek RAM. On by pak měl mít přirozený sklon, držet v RAMce všechno, co do ní jednou načetl (v interních strukturách, které k tomuto používá). V situaci, kdy má DB na disku větší velikost, než je objem RAM dostupný RDBMS, budou se "data cachovaná pro čtení" podle potřeby uvolňovat z RAMky nějakým LRU mechanismem.

Ještě pokud se týče indexace, tak bych možná rozlišoval mezi indexováním databázových klíčů, a indexací rozsáhlejších textů (např. popisů produktů) pro fulltextové vyhledávání - může se jednat o dvě různé disciplíny s různými nástroji.

Cache na straně DB klienta přenechám povolanějším, ostatně už se jich tu několik ozvalo :-)

P.S. na latence dotaz-odpověď (při větším počtu sériově řazených dotazů = blbě napsaná aplikace) má vliv nastavení CPU C-states. Pokud si hardware provozujete sám, mrkněte do BIOSu, případně se to dá třeba v Linuxu poladit v kernel cmdline.

187
Bazar / Re:Sháním malý rack za půl darma
« kdy: 02. 03. 2023, 10:48:40 »
Ten switch bude 19" ?
Bude vedle něj patch panel třeba RJ45, nebo plánujete krimpovat RJčka rovnou na kabely ze zdi?
Kam tím dotazem mířím: snažím se lstivě uhodnout, kolik U tam má být k dispozici.

Jak hluboký je ten switch? (Jsou k vidění hloubky velmi různé, což na cenu a dostupnost vhodné skříně může mít značný vliv.)

Kolik ten switch žere? Prostředí je "pod střechou ale prašné" (= nějaká půda) ?
Kam mířím: má to být prachotěsné, nebo spíš větrané hmyzotěsné? Proti vosám stačí síť s okem třeba 3mm, ale pavouci a mouchy jsou taky pěkný svině...

Do čistého prostředí jsem nedávno dvě malé 2U skříně bastlil na míru. Například se dá od Tritonu koupit krátká EIA šína jako metráž. Pokud jde fakt jenom o ten 1U switch, dá se koupit třeba jenom elektro krabice vhodných rozměrů a na switchi budou s trochou štěstí uši rotovatelné o 90* = montáž na desku = nejsou ani potřeba EIA šíny, což zámečnickou integraci značně zjednoduší. Pravda je, že elektro krabice taky nejsou zadarmo. A třeba ohýbačku na plech má můj zaměstnavatel ve sklepě teprve pár měsíců...

188
V září 2021 jsem bezradně sháněl levný nekurvítkový noťas na domácí práci, a skončil jsem právě u Probooku, něco jako 450 G8. Ovšem s Intelem i3. AMD v té době buď nebylo, nebo v Probooku bylo v kombinaci s nějakými věcmi, které byly "naschvál nekomfortní". Ano rozšíření paměti (2x SODIMM slot), gigový ethernet v základu, podsvícená klávesnice - měl jsem tuším i nějaká kritéria ohledně displeje. A šasi těchto Probooků je částečně kovové = snad chvíli vydrží.

Třeba zmíněný AMDčkový 455 G8 nevypadá úplně blbě. Starší procesor možná pro Linux jedině dobře. Obecně jak navrhoval @anonacct koupit nějakou vlajku z druhé ruky, tak starší hardware by měl znamenat míň problémů v Linuxu s kompatibilitou - ale obecně spotřební zboží z druhé ruky... trochu bych se bál skrytých vad ("náhodně to hnije").

Nemám aktuální informace ohledně podpory grafik AMD v Linuxu - na základě letitých historických zkušeností bych v tomto ohledu volil spíš Intel. Z hlediska výkonu mám poslední dobou takový srstnatě hřejivější pocit z AMD, ale nejsem si jistý, jak vychází starší AMD 5600U ve srovnání s aktuálním Intelem. Modulo moderní ošizené chlazení, člověk pak studuje CPU T-states, PROCHOT apod.

BTW tyhlety 450/455 G8 už nemají pozici ani SATA konektor pro 2.5" HDD. Jediný disk uvnitř je M.2. Taky to nemá CD mechaniku, a má to zoufale mizerné repráky. Prostě spíš kancelářský stroječek. Štíhlý a lehoučký.

189
Člověk, co ho práce vyloženě nebaví je samozřejmě celkem k ničemu. Ale výhra nemusí být ani opačný extrém, takový, co ho to naopak velmi baví.

Ten bude úkol dělat pětkrát tak dlouho proto, že si nutně musí vyzkoušet nejnovější design pattern, o kterém četl, přeorá (refaktoruje) navíc kód, na který by vůbec sahat nemusel (a zavleče tím do něj chyby), ale když on prostě nemohl snést pomyšlení, že používáme starou verzi knihovny a přitom je už týden k dispozici nová major verze, atp.
...

Když to není rozbité, tak to nevylepšuj.
Produktivní lenost aneb skeptická kritika samoúčelného pokrokářství.
Pozvedl jste pane sebevědomí staršímu člověku - děkuji Vám :-)

P.S.: já taky občas vylepšuju. A s gustem.

190
Server / Re:Náhrada Windows Terminal Serveru
« kdy: 11. 02. 2023, 23:01:49 »
- Už bych se možná poohlížel po řešení s VNC/RDP které běží na Wayland, protože ať chceme nebo ne, tak je to budoucnost Linux desktopu,

Troufnu si nesouhlasně mručet.
Schválně jsem se podíval, jestli Wayland umí vůbec běžet multi-session. Nenašel jsem dohromady nic.
I pokud by to bylo pod Waylandem podporováno, tak dávám přednost řešení, které je dosud podporováno a také otestováno mnoho let na živých užovkách.

Citace
- Viděl jsem doporučení na alternativní RDP server, nevím zda je to fakt jiná implementace nebo jen "RDP wrapper"... https://www.thinstuff.com/products/xpvs-server/ https://forum.root.cz/index.php?topic=11219.msg130839#msg130839
Taky bych měl jeden konkrétní tip

191
Server / Re:Náhrada Windows Terminal Serveru
« kdy: 11. 02. 2023, 13:44:01 »
No pokud ssebou netáhnete MS bagáž, tak jste myslím hodně za vodou! :-)

Jinak pokud se týče vzdáleného přístupu, tak pro Linux existuje VNC X-server a RDP server (xRDP), ale počítám že multiuser provoz nebude tak hladký, jako na Windows Serveru.

Proč? Takže... Vys....se na to?

Já bych neházel hned flintu do žita. Ten odkaz na AskUbuntu je snad 10 let starý. Já jsem xrdp zkusil tuším jednou a neměl jsem motivaci, trávit s tím víc času. Vyzkoušejte/otestujte, ujasněte si co tomu chybí, pozeptejte se co s tím...

Citace
PS: https://github.com/neutrinolabs/xorgxrdp vypadá dobře, ale nikdy jsem to v provozu ani neviděl.
Souhlas, myslím že to míří správným směrem. O tomhle jsem nevěděl.

Citace
* Ověření užíváků musí být vůči AD.

AD by měla mít LDAP interface. A možná je i přímější cesta (kerberos?). Možná v tom bude na Linuxu zapojený PAM. Osobně pro "AD vs. Linux" nemám use case, ale divil bych se, pokud by tahle cestička nebyla prošlápnutá.

Citace
* Vzhled by měl být pěkný, aby neměli pocit, že vyrazili na výlet do roku 1995.
Heh já jsem za návrat do hadích let docela vděčný. Konkrétně XFCE s malou dopomocí umí vypadat hodně podobně jako Win95/W2k. Akorát v Debianu 11 jsem si všiml, že je by default zapnutá průhlednost - nepoužívám.

Dobrá zpráva je, že je čistě na Vás, jaký window manager nasadíte a jak ho přikrášlíte. Jsem si téměř jist, že dokonce i jednotliví uživatelé mohou mít v přihlášené relaci prostředí každý podle svého.

Citace
* Že se bude drbat video jsem asi smířený, byť mám Atinu, co to umí akcelerovat pro Widlo TS...ale ta asi nepojede.
Přiznám se, že tady neznám podrobnosti. MS RDS tuším umí poslat video overlay komprimovaný a renderovat ho na klientu. Podobně snad i nové verze VNC. Ohledně xrdp + xorgxrdp nechci nic slibovat, neznám - ale možná ten nápad není předem ztracený :-)

Citace
* Ad parametry serveru: Mám k dispozici lacinou jebku ~20/40 jader a 256 GB RAM, což je hodnota lepší Workstationy no, ale jako úplný základ by to mělo stačit a 10 GB RAM na jednoho by taky mohlo stačit.
Nejprve z mé strany deklarace předpojatosti: jsem konzerva a zpátečník.

Proboha tohle přece není jebka! :-)
Já mám na Windows Terminal Serveru ke dvaceti uživatelům taky, pravda je že mi tam nebydlej s browserem a emailem, ale dohromady jim stačej čtyři jádra a donedávna 8 GB RAM.

Pravda je, že moderní browser s mnoha taby žere RAMku jako protrženej. A třeba Thunderbird taky není úplný střízlíček, vídám spotřebu RAM pár set MB. To je ta moderní doba.

Podobná píseň bude LibreOffice.

Na bináry tohoto softu, domnívám se, zabere částečně deduplikace v RAMce. Pokud Vám to poběží pod společnou instancí OS, tak by stránkovací mechanismus měl mít přehled, že konkrétní binár už je v RAMce zavedený a stačí příslušné stránky namapovat více procesům. Takže jeden binár firefoxu poběží více uživatelům (heap, stack a další věci jsou oddělené). Resp. od přírody to funguje se sdílenými knihovnami, nevím jak se základním binárem (ale on není zase tak velký). Nevím jak Java / javascriptový runtime a další věci = zda je systém vnímá jako "read-only deduplikovatelné" nebo jako data (bude to nějaký mix). Povšechně mám spíše skeptický dojem, že taková ta neuvěřitelná velkorysost/nenasytnost moderních browserů na RAMku se týká "RW dat" a tedy deduplikaci podléhat nebude.

Držel bych se dál od FlatPaku a SNAPu.

Pokud se týče browserů, nedávno jsem měl na nějakém diskless Debianu vedle sebe nainstalovaný Firefox, Chromium, ostrý Chrome a PaleMoon. Proběhly experimenty se symlinkováním .cache do tmpfs apod. Pokud budete mít vespod perzistentní storage tak tyhle blbosti zbytečně do RAMky nestěhujte (ledaže by to bylo výhodné z hlediska IOps zátěže na disky).

=> držím palce, hrajte si co se do Vás vejde. Na základní ověření principů / prvotní instalaci by Vám měl stačit počítač řekněme s dvoujádrem a 4 GB RAM (reálně nejspíš i míň). A pokud byste za provozu došel do stádia, kdy Vám nestačí Vašich skromných 20 jader a 256 GB RAM na stávajícím serveru, tak zrovna Linux je výbornej v tom, že prostě vyměníte motherboard a CPU, připojíte disky a jede se dál - pokud nenarazíte na problém z toho soudku, že Vám pro nový hardware ve stávajícím kernelu chybí nějaký ovladač, což je řešitelné (v zásadě upgradem kernelu před stěhováním na nový HW).

Mimochodem stovka brouzdajících užovek může generovat docela slušný provoz na disk = do keší jednotlivých instancí browserů. Tak bacha ať máte k dispozici dost IOps :-)

192
Server / Re:Náhrada Windows Terminal Serveru
« kdy: 11. 02. 2023, 10:54:38 »
Upřesněte prosím zadání :-) Co na tom terminal serveru potřebujete provozovat za software? Cosi Windowsového?

Protože třeba pod Wine dodnes chybí některé součástky Windows API, na kterých závisí komerční wokenní soft - všelijaké krypto/autentikační knihovny... Nebo může Vaše business aplikace sama o sobě běžet, ale některé její funkce budou záviset na nějakých dalších součástkách / API (OLE, .NET runtime, MSXML,...) které se Vám nepodaří zprovoznit. I pokud by se Vám podařilo, rozjet cojávím nějaké účetnictví, tak nemáte jistotu, že se to v buducnu nerozbije - v takové situaci potřebujete podporu od výrobce toho softu, a Wine nejspíš nebude podporovaná platforma OS...

Kromě toho, co si pamatuju, tak prostředí vytvářené Wine je v principu single-user desktop + systémová skořápka zvaná Prefix nebo Bottle - tuším má například svoji instanci Windows Registry. A jedna "bottle" nemůže běžet víckrát paralelně / víceuživatelsky. Dá se vytvořit více bottles, třeba pro každý login jedna. Ale když si spustíte paralelně víc "bottles" na multi-user UNIXu (Linuxu) tak jednotlivé běžící instance jsou navzájem do značné míry oddělené, nechová se to jako Windows Server kde vidíte v process listu i binárky ostatních uživatelů, a nejsem si jistý, zda se lze vyhnout duplicitnímu ládování např. binárek aplikace, která poběží ve více "bottles" zároveň.

Jinak pokud se týče vzdáleného přístupu, tak pro Linux existuje VNC X-server a RDP server (xRDP), ale počítám že multiuser provoz nebude tak hladký, jako na Windows Serveru.

Pravda je, že jsem to delší dobu nezkoušel, takže jednotlivé detaily mohly mezitím doznat pokroku.

A samozřejmě je tu X Windows protokol, ten tu byl odjakživa :-) V tom případě grafické prostředí běží na lokální stanici, aplikace na multi-user stroji se připojují na vzdálený "displej". Viz "paradoxní" názvosloví X-server vs. X-client.

Pak mě napadá, že by šlo na linux-based hypervizoru provozovat větší počet virtuálů, ve kterých by byly zavřené jednotlivé instance desktopových windows. Přístup opět přes VNC nebo RDP. Toto se samozřejmě opět nechová jako Windows Terminal Server, spíš jako stádečko jednotlivých počítačů v LANce. Nemám nastudováno, zda lze např. mezi virtuály využívat deduplikace, aby shodné stránky RAM s executable kódem (read-only) nemusely být v RAMce pro každý virtuál zvlášť... na disku se něco takového zařídit dá (viz COW images), ale za jízdy v RAMce? Nevím. Prostě virtuály emulující holý PC hardware mají tradičně poměrně tlustou skořápku. Takže by default pro jednotlivý virtuál počítejte třeba 8 GB RAM, kdežto jedna relace na TS s nějakým účetnictvím si reálně vystačí třeba s 200 MB RAM...

Jinak MS Windows Server obsahuje odpradávna systémové API, nad kterým běží MS Terminal Services / Remote Desktop Service. Tohle API je veřejné, a existují legální komerční alternativy MS TS/RDS. Nejslavnější je Citrix, ale jsou i další. Ve výsledku máte zcela standardní prostředí Windows Serveru, včetně aktualizací, včetně MS podpory, kompletní WinAPI pro aplikace a různý pomocný software, jenom "remote desktop" služba se chová jinak a může mít v detailech jiné vlastnosti, než jaké byste dostal skrze standardní MS RDS. Microsoft dostane zaplaceno za licence a Vás třeba nemusí tolik... tlačit bota v některých praktických provozních aspektech.

Pokud *není* požadavkem, provozovat Win32 (Win64) aplikace, tzn. stačí standardní Linux, tak moc nechápu, co řešíte :-) Snad leda nějakou tu centrální autentikaci a správu uživatelských účtů v prostředí heterogenní LAN...

Jinak pokud řešíte terminal server v LAN, tak se dají pořešit "po svém" taky klientská pracoviště: svůj linux bootující diskless přes PXE + NFS root, může být hodně holý (jenom RDP/VNC klient) nebo naopak i dost tlustý, jak je ctěná libost... můžete mít na serveru sdílený adresář s binárkami (read-only root) a RW home adresáře... taky se dělají komerční řešení "tenkých diskless klientů", typicky na bázi Linuxu (bejvala i na Windows CE). Na obecném PCčku umí běžet třeba komerční linuxový ThinManager, což je kompletní řešení tenkých klientů s centrální správou. Tato třída hraček Vám samozřejmě neřeší "cestující klienty", kteří potřebují plnotučný OS a přístup skrz VPN.

193
Sítě / Re:Může switch nebo router spojovat fragmenty TCP?
« kdy: 08. 02. 2023, 11:32:34 »
Mimo soutěž / na okraj, zaujala mě zmínka o RTL8153... pro zajímaovst, to je na PCI-e nebo na USB ?

194
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 08. 02. 2023, 11:30:41 »
Hele... suspend/resume byl tradičně tu a tam vachrlatej i na PCčkách, kde pro to má BIOS standardizované služby (dřív APM, později ACPI).

Ten ODROID s ARMem, má něco jako ACPI/EFI? Spíš pochybuju... ten suspend/resume bude spíš proprietární záležitost. Zahlédl jsem nějaké zmínky o závislosti na binárním blobu... Probuzení ze "suspend to RAM" nebo odemčení ze screensaveru (uspaný pouze video výstup? nebo změna video režimu) může mít nějaký společný zádrhel - bug v klubku ovladačů pro grafiku.

195
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 07. 02. 2023, 14:34:27 »
BTW: info dal male, nicmene:
[...] Stalo se mi totiž že uspaný SBC se neprobral [...]
Mějte prosím shovívavost se starším člověkem :-)
Zkratku SBC znám jako "Single Board Computer". Tam kde dělám, výrobci do této kategorie řadí všelijaké x86 boardíky v mechanických formátech PC104, 3.5" biscuit, 5.25", někteří dokonce ITX a PICMG, nemluvě o všelijakých proprietárních a "otevřených" miniaturních formátech (ETX, Q7 a mnohé další). Většina toho v mém dohledu jsou PCčka, tu a tam nějaký ARM - jenom odhaduji, že mimo moji bublinu jsou ARMové desky mnohem populárnější a možná mají co do počtu prodaných kusů většinu trhu...

Stran: 1 ... 11 12 [13] 14 15 ... 84