Příspěvky

181

Server / Re:Zvažuji přechod z Linuxu na FreeBSD

« kdy: 08. 04. 2025, 22:16:17 »

Já si nemůžu pomoct, ale provozovat něco na -CURRENT verzi FreeBSD nesvědčí o přílišné příčetnosti vývojářů. Jinak samozřejmě ten obrovský odliv testerů po tom, co předvedli s Plus variantou kdysi dostupnou pro "lab" nasazení zdarma je logicky vidět. Fakt to jde hodně z kopce.

Taky to na mě trochu působí, i přesně po tom už zmíněném cirkusu s kernelovým Wireguard driverem, který upstreamovali.

Na -STABLE byla, myslím, založená poslední větev CE 2.6.x tři roky zpátky, komerční verze podobně. A taky by mi asi přišlo logičtější udržet se toho a případně backportovat z -CURRENT jen nějaké zásadní fíčury. Ale samozřejmě neznám jejich přesnou motivaci k tomuhle kroku, ani jestli mají nějaké své vývojáře, co by se tím případně mohli zabývat.

proč nepoužívají na updaty bootenv, když je to na ZFS rootu.

Protože ty jsou pouze v placené verzi. 

Aha díky, toho jsem si nevšiml.. Jako chápu, že chtějí prodávat předplatné a škatule, na druhou stranu mi to přijde trochu zvrácené, zvlášť při testování v téhle formě.

Jinak, už jsem teď dohledal, co tam v té nové větvi 2.8.x je vlastně za potíž. Ty virtio věci i e1000 z QEMU chodí, ale z nějakého důvodu vše jen v legacy PCI (ne express) variantách.
Tzn. musel jsem v libvirt předělat testovací virtuál na model s čipsetem i440FX místo Q35, model síťovky z e1000e přehodit na e1000, nastavit pci bus na 0x00 atd. Pak už se to chytlo.

Já to mám naštěstí víceméně na své blbnutí.

182

Server / Re:Zvažuji přechod z Linuxu na FreeBSD

« kdy: 08. 04. 2025, 13:17:06 »

pfSense 2.8.0 CE založený na FreeBSD 15-CURRENT vydaný pred 6 dňami. 
https://docs.netgate.com/pfsense/en/latest/releases/2-8-0.html

No, leda kulový... https://www.pfsense.org/download/

No je to v systémovém update na beta kanálu, jsou tam buildy možná obden. Dělal jsem si jen rychlý test, asi bych to jen tak nedoporučil vzhledem k aktuálnímu stavu. Třeba se teď stává, že na konci toho in-place upgrade (nad kterým je úplně minimální kontrola) naběhne nový kernel a nevidí žádné virtio ani e1000 emulované síťovky ani virtio disky
Dá se z toho dostat jen tak, že se nabootujete starý, zálohovaný kernel.old s novým userlandem. Takže to sice emituje spoustu hezkých hlášek, ale aspoň se dostanete ze smyčky rebootů a můžete se tam třeba přihlásit. Někteří jiní odvážlivci mají podle všeho zas vcelku pravidelné kernel panicy i když jim to naběhne se všemi drivery (např. na Netgate krabičkách).
Dál jsem to nezkoumal, ale přide mi to spíš jako alfa než beta. Stejně jako nechápu, proč nepoužívají na updaty bootenv, když je to na ZFS rootu.

183

Desktop / Re:Náhrada Skype pro Linux

« kdy: 06. 04. 2025, 21:29:44 »

Tak ukončujte Firefox, jak jste zvyklý s viktorem, ale Chrome/Chromium si vyhraďte jen na tyhle aplikace mimo normální prohlížení a milosrdně ho nechte žít.
Až zavřete poslední takovouhle pseudo aplikaci křížkem v rohu, tak skončí i Chrome pod tím.

Nic, už mlčím

184

Desktop / Re:Náhrada Skype pro Linux

« kdy: 06. 04. 2025, 21:03:38 »

Webová aplikace není (pro mne) reálně použitelná. Od komunikační aplikace očekávám, že bude trvale aktivní a připravená na interakce - zatímco prohlížeč je neustále vypínán. To by znamenalo, že ve chvíli, kdy je prohlížeč vypnutý, nejsem dostupný (což je u mne většina času), a po každém zapnutí bych se musel znova a znova přihlašovat.
Což reálně diskvalifikuje ty Teamsy.

Pardon, ale nerozumíme si.

Z webové aplikace můžete v Chrome nebo Chromiu udělat pseudo desktopovou.
https://support.google.com/chrome/answer/9658361
Tzn. chová se jako samostatná, má svůj .desktop spouštěcí soubor v ~/.local/share/applications, otevíráte a zavíráte jí úplně nezávisle na prohlížeči. Můžete si jí normálně přidat do ~/.config/autostart, pokud chcete atp.

Ten spouštěč může vypadat třeba takhle..

msmucr@msmucr-desktop:~> cat ~/.local/share/applications/chrome-mdpkiolbdkhdjpekfbkbmhigcaggjagi-Default.desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Google Chat
Exec=/opt/google/chrome/google-chrome --profile-directory=Default --app-id=mdpkiolbdkhdjpekfbkbmhigcaggjagi
Icon=chrome-mdpkiolbdkhdjpekfbkbmhigcaggjagi-Default
StartupWMClass=crx_mdpkiolbdkhdjpekfbkbmhigcaggjagi

Já mám takhle asi čtyři věci, co různě používám. Samozřejmě hledejte alternativy ke Skype atp.
Já to zmínil čistě kvůli tomu, že je to jedna s cest, jak na počítači trochu příjemněji koexistovat s aplikacemi, co jsou čistě webové. Až na výjimky to bývá funkčně velice podobné tomu, jako když ji vydavatel zabalí třeba do Flatpaku s ElectronJS.

185

Desktop / Re:Náhrada Skype pro Linux

« kdy: 06. 04. 2025, 11:57:01 »

Pro mě je to hlavně o tom, co používají ti, s kterými potřebuju komunikovat.
Chápu, že když se člověk shodne s pár dalšími lidmi na nějaké platformě, dá se vybrat i ledacos poměrně obskurního.

Takže, ať už se mi to líbí, nebo ne. Stejně budu muset tím Skype->Teams přechodem projít. Akorát je tam teď trochu zmatek, že tam jsou dva účty - jeden zmigrovaný včetně předchozích konverzací ze Skype a pak další MS účet, co jsem předtím používal na Teamsy. Zatím je to trochu opruz, ale moc jsem nezkoumal další alternativy.

Co se týká samotné aplikace, tak je mi to pro můj způsob používání na desktopu vcelku jedno. Už předtím byla Skype na Linux víceméně zabalená PWA aplikace s Electronem. V Chrome/Chromium není problém se přihlásit na danou webovou aplikaci (Teams, Google Chat, YT Music atp.) a nechat z toho nainstalovat samostatně spustitelnou aplikaci v systému, co běží nezávisle na hlavním browseru, přidá se do systémových nabídek, posílá to notifikace v GNOME atp.
Není to samozřejmě úplně optimální, ale co už, když člověk chce nebo potřebuje dané služby.

186

Hardware / Re:AMD a SuperMicro: přehozené frekvence v ACPI

« kdy: 04. 04. 2025, 11:56:39 »

Hm Debian, i tak bych dal jádro alespoň 6.3. Ten active je pro Zen2 bez problémů.

V těch backportech pro Bookworm je teď 6.12.
Zrovna nedávno jsem taky někde potřeboval vyzkoušet určitou změnu v novějších kernelech. Přidání repozitáře a instalace z backportů byla nejjednodušší, funguje to dobře.

187

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 04. 04. 2025, 11:10:40 »

Akosi sa mi spať nedá   

Hardware Version:
Archer AX23 v1.20

A mrzí má trochu to, že ten router nemá ani pol roka a je to len 1.2 verzia.

Njn. to by byla spíš náhoda, pokud byste to kupoval někdy teď . Podle release notes od firmware je V2 úplně nová (leden 2025).

Teoreticky byste mohl zkusit napsat na podporu TP-Linku, jestli neplánují dodat podporu pro Wireguard (víceméně softwarová věc) i do revize 1.2 v nějakém dalším firmware, pokud nějaký bude.
Možná naivní, vzhledem k tomu že je tam poslední verze z roku 2023 , ale jednou se mi takhle k něčemu podařilo ukecat ASUS, že do něčeho sáhli, dokonce mi poslali i beta FW.

Nicméně to teď asi realisticky vypadá, že to jen s těmi samotnými routery, co máte ve stávající podobě, to tunelování nerozjedete.

Jinak ještě když se vrátím k OpenWRT pro AX 1800 (AX23), tak to vypadá, že to nainstalovat jde, je tam 16MB flash (což je tak hraniční)
https://openwrt.org/toh/hwdata/tp-link/tp-link_ax23_v1
https://forum.openwrt.org/search?q=AX23

Bohužel to vypadá, že tam visí nějaký problém s pomalou WiFi a určitými klienty.
https://forum.openwrt.org/t/ax23-very-slow-5ghz-wifi-on-windows/
Není to jen ten zakladatel vlákna, ale potvrzují to i jiní lidé (a tak trochu klasicky prohazují různé buildy OpenWRT a originální firmware).

Ty MR6400 mají jen 8MB flash a 64MB RAM, tam to bude ještě větší problém. Tam už by bylo nutné flashovat vždy speciální malé sestavení a v kombinaci s nějakými balíčky (třeba Zerotier a OpenVPN) by to bylo nejspíš bez UI s administrací jen z terminálu.
https://openwrt.org/supported_devices/864_warning

188

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 04. 04. 2025, 00:57:45 »

Hele, pohledme do manuálu od AX1800, tak mám podezření, že ten OpenVPN server v TPlinku moc nepočítá s tím, že by se na něj připojovala celá síť? Možná počítá, že se připojuje jen koncový klient (jedne počítač). Takže můžeš mít problém mu říci, že do spojení 1 routovat segment 192.168.80.0/24 a na spojení 2 posílat 192.168.81.0/24.
Dle manuálu to má umět i wireguard, tam by asi mohlo jít toto zařídit pomocí nastavení allowed IPs (client)?

No s tím OpenVPN serverem tam budou ještě další věci, kvůli kterým to přes něj pravděpodobně nepůjde řešit.
Ale asi jasno by bylo, kdyby se nastavila VPN, a pak se dohledal zkontroloval vygenerovaný server.conf, případně spuštěný  příkaz po připojení terminálem do routeru. Blbé je, že s tím asi nepůjde úplně hnout, a pak by nezbylo než opravdu nahodit ten server na jiném stroji uvnitř.

Nicméně ten Wireguard tam je potenciálně zajímavý. Já ho předtím nenašel, protože jsem se díval na HW revizi 1.2, kde je jen OpenVPN a PPTP. Ty jediné jsou pak i v emulátoru https://emulator.tp-link.com/AX1800/
HW revize 2 pak WG podle manuálu přidává, jak jste zmiňoval.

Takže vyvstává otázka, jakou má 55.lukas revizi toho AX 1800?
Pak to případně ozkoušet, jestli se tam nenarazí na nějaké další komplikace, kdy nějaká výchozí nastavení ve firmware nebo UI pro nastavení mohlo házet klacky pod nohy.

Jinak jsem byl upřímně překvapen, jak málo se tam dá pořád nastavit třeba ohledně firewallu, je tam jen globální on-off šoupátko, pingy zvenku a automaticky vytvářená pravidla pro port-mapping. IPv6 pak nastaveno asi jen z továrny - počítám, že je buď všechno iniciované z venku zakázáno, nebo povoleno
No už jsem s tím dlouho nedělal, ty staré TP-Link se zeleným UI a HTML framesetem na tom byly podobně, ale říkal jsem si, že mohli trochu rozšířit možnosti..

189

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 03. 04. 2025, 22:15:28 »

Teraz nad tým rozmýšľam a trochu sa strácam s jednou vecou.

Ja som napísal, že na AX1800 dám statickú ipv4 a spustím openvpn server. Ale teraz rozmýšľam, že zariadenie, ktoré sa bude dopytovať bude práve na ax1800. Nemal by byť potom ax1800 vlastne klient a posielať požiadavky na iné siete (aktuálne tie mr6400)?

Já doufám, že jsem otázku pochopil správně.

Ve všech případech, co tu byly zmíněny, je cílem propojit ty tři lok. sítě tak, abyste mezi nimi mohl libovolně komunikovat. Tzn. je úplně jedno odkud komunikaci začnete, jestli ze subnetu A, B nebo C a z jakéhokoliv zařízení. Ve výsledku by to mělo bez překladu adres projít bránami a tunely (zjednodušeně - tam se původní pakety zašifrují a přidají se hlavičky od konkrétního tunelovacího/VPN protokolu) a stejnou cestou pak zpátky vrátit odpověď.

Samozřejmě se to dá v dalším kole utáhnout jen na konkrétní IP adresy a porty pomocí firewallu (buď na těch PC, kde jsou klienti, nebo na routerech, pokud po poběží tam).
To, odkud a kam navazujete tunel, je pak technikálie, vedlejší věc, co se netýká komunikace uvnitř. Jakmile se tunel sestaví pakety v něm putují oběma směry.

190

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 03. 04. 2025, 19:37:52 »

Jen ještě teď jsem se díval do emulátoru UI od AX 1800, fakt tam toho není moc k nastavení ani ohledně OpenVPN serveru, je tam jen úplný základ a třeba teď naprosto netuším, jestli bude běžet komunikace mezi VPN klienty (konf. volba client-to-client v OpenVPN), což je pro tohle docela důležité.

Nemáte eventuálně v síti za AX 1800 nějaký počítač, kde by mohl běžet OpenVPN server?
Opravdu to může být i RPi nebo podobný SBC, případně pokud už tam máte nějaký server tak třeba virtuál na něm.. jinak to může na pokus běžet i ve virtuálu na vašem desktopu třeba.

I když, jakmile byste měl tři podobná zařízení (2x Dell a něco dalšího), už tam můžete taky dát rovnou WireGuard, který mi přijde v mnoha ohledech pro tohle přímočařejší.

191

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 03. 04. 2025, 17:26:23 »

A teraz nahlas rozmýšľam ďalej... Ak môj poskytovateľ internetu ponúka verejnú ipv4 za cca 3€ mesačne a na routri ax1800 by som zapol openvpn, tak mám vlastne vyriešenú časť servera?

Jo, k tomu tak trochu směřovaly moje úvahy, byť tedy s použitím zmíněných Mikrotiků jako místo MR6400.
Na AX 1800 s pevnou veřejnou adresou bude OpenVPN server, kam se připojí klienti, pak se přidají do AX1800 statické routy do sítí za těmi klienty. Jestli to nebude firewall v AX1800 nějak hloupě blokovat bez možnosti přenastavení (ty domácí routery mají většinou ten firewall hodně "dumbed down", aby to bylo jednoduché), tak by to mělo šlapat.

A je vôbec dobrý nápad ten router vystavovať na net?

Osobně bych se toho nebál, pokud budete chtít, můžete si to ještě šoupnout třeba na nestandardní port (místo 1194 např. 20194).

Už len potrebujem klientov?

Druhá časť otázky.
Predstavme si, že v sieti 4g routra by bolo Dell wyse s openvpn klientom. Dokázalo by toto zariadenie robiť prostredníka medzi openvpn serverom a Modbus tcp zariadením?

Běží na těch Dellech Linux, BSD..?
Mohlo by to fungovat, je to trochu variace na to, co už tu padlo.
Dell bude mít normální IP z toho rozsahu za LTE routerem, stejně jako Modbus zařízení.
Na něm bude rozběhnutý OpenVPN klient připojený do VPN sítě, který vytvoří po připojení tun rozhraní a bude na něm povolené forwardování paketů (tzn. bude fungovat jako router). Na LTE routeru pak budou nastavené správné statické routy do těch vzdálených podsítí, kdy ten Dell bude sloužit jako brána.
Tzn. když Modbus zařízení začne komunikovat na jiné, co je ve vzdálené podsíti, tak dorazí pakety na výchozí bránu (LTE router), ten je podle rout. tabulky pošle dál na ten Dell, který to zas dál otočí do tun rozhraní z OpenVPN a pošle na server.. až to dorazí do svého cíle. Cesta zpátky pak podobně.

192

Desktop / Re:Možnosti RDP na linuxovém desktopu

« kdy: 03. 04. 2025, 12:44:59 »

Taky docela záleží, jaké používáte desktopové prostředí.
Jestli máte například distribuci, kde je GNOME 47 nebo 48. Tak tam je takový hybrid na vzdálené připojování přes RDP v podstatě už součástí.
Má to své mouchy (radši bych byl, aby byla možnost používat to jen jako vzdálený přístup na fyzickou konzoli, jako u X11 a vnc modulu ve starších distibucích), ale funguje to asi takhle.

V syst. nastavení GNOME se v sekci Remote Desktop zapnou volby Desktop Sharing a Remote Login, vyplní se hesla atp.
Remote Login běží přes RDP na standardním portu 3389, Desktop Sharing pak na 3390.. oboje se pak samozřejmě musí povolit na ve firewallu.

Desktop sharing slouží k připojení na existující fyzickou session, když už je tam přihlášený uživatel. A má vždy stejné rozlišení jako fyzická plocha.
Remote login pak funguje jako třeba RDP na Windows, ale nesmí tam být už daný uživatel přihlášený. Tzn. systém je GDM přihlašovací obrazovce - po startu počítače, nebo odhlášení nějaké předchozí session.
Pak se tam jde připojit přes RDP, přihlásit do GDM a oveře se session, kdy se rozlišení přizpůsobuje klientovi.

Je to bohužel takové "nedopečené", hlavně tím jak jsou tam ty dva RDP servery na různých portech, nedokážou si to elegantně předávat atp.
Na druhou stranu to je asi jediná možnost, když máte zapnutý Wayland a Mutter, nebo chcete zas rozumné RDP. A chodí to pak vcelku obstojně.

Další opruz s těmi různými VNC variantami jakmile se začnou řešit nekompatibilní rozšíření toho základního VNC protokolu. Takže třeba TigerVNC server a viewer má jako jediný vyřešené kopírování textu přes schránku v jiném kódování než Latin-1, ale jeho implementace není kompatibilní s novějšími verzemi RealVNC a TightVNC (které se hodně používá na Windows), takže se musí používat jen pekelný TigerVNC Viewer.
Libvnc, což je knihovna, kterou používá spousta služeb na sdílení přes VNC, tohle zas neumí vůbec.

Je to celkově na Linux desktop fakt opruz. A kolikrát pro mě třeba i showstopper v nasazení Linuxu místo Windows na nějaké jednoúčelové stanice, kde je potřeba, aby se různí uživatelé spolehlivě přihlašovali na jednu společnou plochu, kde běží víceméně pořád nějaká specifická aplikace, nebo řešit lokální administrační přístup.
V tomhle ohledu jsou jak free i komerční VNC servery na Windows nebo i Apple Remote Desktop mnohem lepší.
Bohužel tím jak jede už několik let ta dichotomie s X11 a Waylandem. Ten má v mnoha ohledech úplně jinou filozofii, sdílení musí být na úrovni konkrétního kompozitoru a jde to kupředu spíš malými a rozporuplnými krůčky.
Navíc je tam často i kolize toho, že na dané úkoly se prostě víc hodí LTS distribuce, kam se velice obtížně instalují nové verze těch desktopových prostředí a nehrozí zřejmě, že by o to měl někdo takový zájem,a aby tyhle fíčury backportovali.

193

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 03. 04. 2025, 11:44:28 »

Při myšlence přidat si tam malý Mikrotik a Zerotier, tak pozor na to, že jen pro některé architektury CPU to Mikrotik umí. Zdá se, že stále platí omezení pro modely s ARM/ARM64 procesorem: https://help.mikrotik.com/docs/spaces/ROS/pages/83755083/ZeroTier

Jiná možnost je nějaké malé RPi, do toho Zerotier nebo jiný typ VPN půjde nacpat...

Žádná krabice neí dokonalá. A kdy už umí vše, tak zase je udělaná tak, že nesplňuje třeba požadavky na EMC. :-)

Jo, s tím Zerotierem a ARMem to je samozřejmě dobrý point. Stejné omezení pak platí i pro kontejnery na RouterOS.
Já tam ZT třeba ani nezkoušel právě proto, že mám své dva starší routery, co mají ještě MIPS CPU.

Ale stran toho Zerotieru asi bude záležet hlavně na tom, jestli to bude fungovat na konkrétních připojeních s dvojitým NATem, přesně jak jste psal. Ideální by z tohohle hlediska bylo přímé IPv6, což už tu říkal jjrsk. Kdoví možná to pro ta LTE připojení chystá i slovenský TME.

Já co se teď v rychlosti díval, tak třeba tahle škatule vypadá jako vcelku rozumná náhrada těch MR6400.
Má to ARM, LTE modem, integrovaný Wireguard, OpenVPN, L2TP/IPSEC a i ten Zerotier
https://mikrotik.com/product/hap_ax_lite_lte6
Za 1800,- (resp. něco přes 70 EUR) bez daně mi to nepřijde o moc dražší sranda než třeba dokoupit něco jako RPi4, zvlášť pokud by se podařilo prodat ty původní TP-Linky.

A pak bude spousta možností, jak to udělat.. VPS, VPN služba venku, Zerotier, přikoupení pevné IP pro server na jednom z těch míst.

194

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 02. 04. 2025, 23:55:22 »

Jinak receno potrebujes, jak tu zaznelo, alespon jeden stroj s verejnou adresou. Samotny tunel muzes vyrobit treba pomoci ssh, coz typicky skoro kazda krabicka umi. Nejspis i ty zmineny MR6400 a AX1800.

A jak by mu to ssh v té situaci mělo pomoct? V krabičkách bude nejspíš Dropbear ssh server čistě pro administraci. Ten spousty užitečných věcí neumí (třeba tunelování s tun rozhraními), také mít nejspíš vypnutý i remote TCP forwarding.
Navíc se sice v těch routerech dá spousta věcí nakopnout ad-hoc, třeba tak že se tam připojíš telnetem, zabiješ nějaký proces a spustíš ho s jinými parametry, ale už tam není žádná možnost jak to nastavení udělat persistentní. Má to většinou své read-only init skripty, co nemají žádný hook, kde by se daly spustit jakékoliv další příkazy.

195

Sítě / Re:Komunikácia medzi viacerými sieťami cez OpenVPN

« kdy: 02. 04. 2025, 23:42:19 »

Vyzerá to, že len niektoré TPLinky vedia OpenVPN klienta. Respektíve tu sa dajú vyfiltrovať všetky s OpenVPN klientom: https://www.tp-link.com/us/home-networking/wifi-router/?filterby=AND%7C6112

Jo těch dalších možností, jak to udělat dál, případně co třeba koupit, bude spousta.
Od výměny LTE routerů za jiné, přes přidání nějakých lacinějších základních Mikrotiků, kam by se třeba připojila jen ta zařízení, co na sebe mají vidět, až po třeba zkoumání toho jestli by na stávajících TP-Linkách nemohl běžet OpenWRT, jak zmínili ostatní.

U té poslední zmíněné možnosti je jen pořád potřeba mít na paměti, že to není oficiální firmware, a musíte mít i trochu štěstí s modelem, že to bude v pohodě chodit.
Proces toho přeflashování nemusí být úplně jednoduchý a pořád tam je nějaká míra rizika, že pokud se něco nepodaří, můžete router "bricknout" a znefunkčnit. Pak můžete potřebovat na i připojení z PC na interní JTAG rozhraní, abyste se z toho dostal.
Další problémy můžou nastat i v provozu, kdy nemusí všechno dobře chodit. Třeba WiFi, nebo jsem také zažil situaci (zrovna s nějakým starým TP-Linkem), kdy se s OpenWRT přehříval SoC, pak celé mrzlo a musel jsem se vrátit na původní firmware.
Finálně také můžou nastat problémy i s malou flash paměti zařízení, protože se tam pak nemusí vejít všechny balíčky, co chcete.
Nakonec i samotné OpenWRT má sice relativně spousty možností, ale i své quirky a třeba upgrady major verzí můžou být víceméně na re-flash.

Což není tak, že bych hanil OpenWRT, které umí vdechnout život zařízením, kterých byste se jinak musel zbavit, nebo vás od toho chtěl nutně odradit. Jen dodávám další kontext. Určitě si načtěte nějaké info pročtěte fóra. Nicméně je klidně možné, že to pro vás nebude a radši se rozhodnete sáhnout po něčem hotovém (třeba ty Mikrotiky).