Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Řešení dotazu:
Není již něco hotovo abych nad tím nestrávil hromadu času?
Vzdálený přístup do databáze.
Samozřejmě je pak naprosto nezbytné nastavit tam šifrování (TLS), je-li to „přes internet“.
Klient se dá spustit a udržovat v běhu třeba přes systemd
, aby měl stálé spojení a nenavazoval ho pokaždé znova. Může poslouchat někde na unixovém socketu SQL příkazy a případné chyby někam logovat.
(Navíc bych vřele doporučoval použití skutečné databáze (příklad: PostgreSQL), nikoliv béčkové hračky MySQL, ale to už je malinko mimo téma.)
Takového vzdáleného přístupu není nejmenší důvod se bát. Právě proto ho databáze (skutečné databáze, ne hračky, podotýkám) podporují a dobře umí, aby se používal.
V pg_hba.conf
se nastaví povinná autentifikace (hostssl
… scram-sha-256
) a vzdálený přístup se (dejme tomu) povolí jenom takovému uživateli, který do příslušných tabulek smí jenom přidávat (INSERT
) a nic jiného. V postgresql.conf
pak stačí nastavit ssl = on
, ssl_ca_file = '...'
, ssl_cert_file = '...'
, ssl_crl_file = '...'
, ssl_key_file = '...'
a je to. Ještě se to dá v pg_hba.conf
omezit podle IP adresy klienta, když na to přijde, i když to samozřejmě nenahrazuje ostatní autentifikační mechanismy.
Tohle^^^ má podle mě dostatek slupek bezpečnostní cibule. I kdyby někdo třeba ukradl soukromý klíč klienta + ukradl heslo k databázi (a to by musel už fakt hodně krást!), pořád by tam mohl data jenom přidávat, tj. nemohl by poškodit data, která tam už jsou.
Tolik tedy asi k tomu, jak přenést data přes internet a vyhnout se HTTPS POST
. (Samozřejmě předpokládám, že tam to S je, jinak je to fakt výsměch, co do bezpečnosti.)
Pokud na bezpečnosti aspoň trochu záleží (a není to celé 100% jenom domácí hračka, tj. LAN místo internetu atd.), vzdálený přístup do databáze může být nakonec jednodušší řešení s lepší autentifikací než HTTPS. Autentifikace certifikátem se u většiny HTTPS command-line klientů dělá poměrně špatně, zatímco pro databázové klienty je samozřejmostí.
Když budu chtít insertnout, řekněme, 3 čísla do tabulky, kolik mě to bude stát?
Řádově nulu. Na to se opravdu ptáš?
Tazatel neuvádí, kde je velká režie (a jak je velká režie definovaná). Předpokládám proto, že velká režie je na klientovi v souvislosti s opakovaným navazováním spojení.
Vyhodnocování SQL probíhá na serveru. Proto je krajně nepodstatné, kolik stojí SQL. Je snad INSERT
3 čísel těžký problém z hlediska vyhodnocení dotazu? Kdyby náhodou každé z těch čísel bylo výsledkem třeba 100 řádků SQL, co kdyby si správce celé vkládání připravil jako proceduru v PL/PgSQL? Vyřešeno. Nebudou náhodou mnohem dražší žurnálovací operace DBMS a jeho přístupy k úložišti nežli parsování toho dotazu? Asi jo, co?
Nemluvě o tom, že při použití HTTP bude k parsování SQL docházet taky, pokud bude HTTP frontend v nějakém dynamickém jazyce (místo ECPG s uloženými dotazy).
HTTPS POST má velkou režii, protože se:
Běžící PostgreSQL klient
To je všechno. Spojení je navázané (TCP i TLS), poslat v plaintextu 3 čísla je stejně "náročné" v HTTP i v SQL a ve finále se spojení nebude zavírat.
(Samozřejmě se nastaví keepalive, aby systemd
klienta po výpadku sítě / serveru obnovil, ale to už jsou technikálie (podle vzoru fekálie).)
Další možnost je HTTP pipelining, jenže: Command-line klienti, kdo z vás to má? (Nastavení pak bude přinejmenším stejně náročné jako nastavení databázového klienta. Na straně serveru to ovšem bude složitější.)
Tazatel neuvádí, kde je velká režie (a jak je velká režie definovaná). Předpokládám proto, že velká režie je na klientovi v souvislosti s opakovaným navazováním spojení.A já zase automaticky předpokládal, že tím myslí přenesená data.
curl
. Ti zdatnější mohou použít švýcarský nožík netcat
, u kterého je režie vskutku zanedbatelná.
Osobně používám v intranetu PHP jako serverMyslis toto?
...několik měřených hodnot na server do MySQL databáze ... po 30 vteřinách, občas po 10...To by podle mě arduino mohlo zvládnout levou zadní. Místo vlastního UDP protokolu bych zvážil MQTT/UDP, jelikož to jde přes UDP ale ten protokol je opět hotový a připravený k použití. Při srovnávní webserver + json api versus mysql klient bych použil radši mysql klienta, protože je tam tam opět ten protokol už hotový a připravený k použití, režie přitom bude podle mě nebude větší než u webserveru.
To by podle mě arduino mohlo zvládnout levou zadní.Já do teď nepochopil, jestli je klientem přímo to Arduino (pak by asi MySQL klient přes TLS moc realizovat nešel), nebo je Arduino připojené k linuxovému počítači.
To by podle mě arduino mohlo zvládnout levou zadní.Já to pochopil tak, že se tazatel snaží minimalizovat přenosy po síti, ne že má nedostatek výkonu.
Při srovnávní webserver + json api versus mysql klient bych použil radši mysql klienta, protože je tam tam opět ten protokol už hotový a připravený k použití, režie přitom bude podle mě nebude větší než u webserveru.Zase pokud těch klientů bude mít víc, tak bude opruz dělat jim v mysql uživatele a nastavovat správně oprávnění k té tabulce, aby nemohli vkládat data „za cizího“ a tak. Ve vlastním webovém handleru si autentizaci a tak vyřeší snadno jak potřebuje (a třeba klienty bude mít v další tabulce).
Doteď jsem to řešil přes HTML POST, ale připadá mi tam zbytečně velká režie.Co znamená „připadá“? Nějakých 100 bajtů nezbytných hlaviček u HTTP (nikoliv HTML) POST je problém? Nebo navázání spojení je problém? Nebo v čem je problém? Pokud nelze použít TCP spojení (ani ho recyklovat, aby se nemuselo navazovat pořád znovu), tak potom jedině to UDP, jak zmiňoval Jenda, ale nemá to korekci chyb, takže záleží, jak moc bude vadit, když ta data buď vůbec nedorazí, nebo dorazí poškozená.
Ľudia, Vy ste sa všetci zbláznili! Na Arduine implementovať MySQL klienta cez TLS? Nadväzovať komplikovaný Websocket?Protoze je potreba chranit data assets! (Samozrejmne, ze je naprosta blobost aby se koncove zarizeni pripojovalo do DB a to i v jinych pripadech.) Na tyhle ulohu bylo vymyslene MQTT pokud jej nelze pouzit tak HTTP POST.
Tiskni Sdílej: