Internet běží sice převážně na TCP/IP, ale v rámci jednoho počítače máme i vhodnější způsoby komunikace. V tomto článku se podíváme na unixové doménové sokety a jejich použití v Javě. Předáme si souborové popisovače (FD) z rodičovského procesu potomkovi a ukážeme si princip socket activation. Nakonfigurujeme si služby v klasickém xinetd i moderním systemd a nakonec propojíme Jetty a Apache HTTPD pomocí unixového soketu.

Říká se, že když něco vypustíte na internet, už to nejde vzít zpátky – ostatní to začnou kopírovat a informace/data se nekontrolovatelně šíří. Bohužel to ale platí spíš v případech, kdy byste to vzít zpátky chtěli. A naopak jindy se může stát, že hodnotný obsah zmizí a už jej nedohledáte. Software resp. jeho zdrojové kódy se většinou neztrácejí – alespoň ne ty hojně používané programy – u nich se vždy najde někdo, kdo měl kopii a podělí se o ni s ostatními. Ale u různých menších programů a knihoven se klidně může stát, že je autor smaže a už je nedohledáte.

Tohle je jeden z důvodů, proč mít zálohované zdrojové kódy programů, které používáme. V tomto článku se tedy podíváme na to, jak tyto zálohy systematicky udržovat.

Bash je nejpoužívanějším shellem, přes něj nejčastěji ovládáme systém z příkazové řádky a píšeme v něm skripty. Nahromadilo se mi tu pár poznámek týkajících se Bashe, tak tady jsou. Doufám, že to přispěje k pohodě vašich Vánoc.

Zatímco v oblasti softwaru jsme se dostali do stavu, kdy všechny běžné potřeby uživatele lze uspokojit svobodným softwarem (operační systém, nástroje, aplikace…), a uživatel má tak plnou kontrolu nad svým systémem, v oblasti hardwaru jsou stále uživatelé většinou závislí na tom proprietárním-uzavřeném. Uzavřenost – jak softwaru, tak hardwaru – má řadu negativních dopadů. Jde buď o těžko odhalitelné a často neopravitelné chyby nebo o záměrně škodlivé vlastnosti. Poslední roky jsou v tomto ohledu zvlášť bohaté: Intel AMT/ME (trojský kůň přímo v procesoru, před kterým nás FSF varovala už někdy v roce 2014) nebo Spectre a Meltdown. Ať už jde o chybu, záměrně škodlivou vlastnost nebo kombinaci obojího, důsledky jsou stejné – počítač přestává poslouchat svého uživatele/vlastníka a řídí se pokyny někoho jiného, komu buď předává naše data (šifrovací klíče, citlivé soubory…) nebo nám zabrání v používání počítače (např. DRM), pozmění či smaže data. Tohle je jednoznačně nežádoucí stav – a to bez ohledu na to, zda jste běžný uživatel, banka, výrobní firma, vládní organizace nebo armáda. Současná situace v oboru je hodně špatná.

Nicméně i v případě hardwaru se situace zlepšuje. Cestou, jak z toho ven, je otevřenost a veřejná kontrola – nad zdrojovým kódem i nad hardwarovými návrhy. Máme poměrně silné hnutí tvůrců otevřeného hardwaru, vzniká spousta desek a zařízení, ke kterým jejich autoři zveřejňují schémata a seznamy součástek, zdrojové kódy firmwarů, návrhy pro FPGA a návody na výrobu. Ale i v těchto případech zůstává většinou zásadní část systému – procesor počítače nebo MCU (microcontroller) menšího zařízení – uzavřená. Není to vinou autorů těchto návrhů, ale tím, že otevřené součástky na trhu chybí – nebo alespoň donedávna chyběly. Ovšem i tady jsme na dobré cestě: máme architekturu OpenPOWER pro výkonné servery a pracovní stanice a máme RISC-V a lowRISC pro menší zařízení.

Většina lidí resp. jejich pracovních stanic, mobilů, dalších osobních zařízení a větších počítačů už je připojena k internetu. Současným trendem (už pár let) je připojování „věcí“ k internetu tzv. IoT. Věcmi jsou buď různá čidla, která posílají naměřené hodnoty do sítě, nebo akční členy, které na základě přijatých zpráv něco dělají, případně kombinovaná zařízení, která přijímají i odesílají zprávy zároveň.

Časem bude možná nějakou formou konektivity vybavené každé zařízení. Může se vám to nelíbit, můžete s tím nesouhlasit, ale… znáte to. Úspěšnou strategií je zajistit, aby použité technologie byly otevřené nikoli proprietární, aby síť patřila nám, abychom to byli my, kdo má vliv na její fungování, abychom dostupnou konektivitu používali tam, kde to má smysl, a v ostatních případech ji mohli vypnout nebo odstranit. V současné době se rozšiřuje IoT síť, která stojí na otevřených principech a na které se může podílet každý z nás.

Mám tu Roland Rubix 44, tak zde je stručný dokumentační zápisek o této USB zvukové kartě a pár fotek. Mimochodem, firmu Roland možná znáte díky MT-32 nebo TR-808. Ale tentokrát se podíváme na jejich současný hardware.

Obecně se nedoporučuje předávat citlivá data (např. hesla) programům jako parametry na příkazové řádce. Důvodem je jednak to, že se spuštěné příkazy ukládají do historie, a jednak to, že by se k parametrům mohli dostat jiní uživatelé resp. procesy na témže počítači. Bezpečnější je proto citlivé údaje předávat buď ve formě souborů (kterým lze nastavit práva) nebo přes standardní vstup (rouru).

Řada programů možnost zadat heslo na příkazové řádce zrušila nebo nikdy nenabízela – podporují pouze interaktivní režim nebo předání souborem či rourou. Některé programy zadání hesla parametrem stále umožňují a některé v sobě mají jakousi ochranu, která zabrání tomu, aby takto zadané heslo šlo snadno zjistit z výpisu procesů. V následujícím článku se podíváme, jak si takový program skrývající hesla můžeme napsat sami.

Ternární operátor většinou bereme jako stručnější, ale obsahově totožný, zápis if-else bloku, v jehož větvích jen nastavujeme proměnnou nebo vracíme hodnotu. Jsou ale vždy tyto zápisy ekvivalentní? Můžeme automaticky nahrazovat stávající kód ternárními operátory?

Dnes oprášíme zase jednu starou dobrou technologii – paralelení port – a ukážeme si, jak ji softwarově ovládat. Protože je to dost nízkoúrovňová záležitost, nebude to tentokrát v Javě ale v C++. Cíl bude poměrně skromný: generovat obdélníkový signál s frekvencí 10 000 Hz a zadanou střídou (což zde neznamená střed chleba). Ve výsledku budu signál generovat jiným programem, nicméně nejdřív si chci otestovat jednotlivé části systému samostatně, takže teď to bude jen LEDka a pár řádků kódu bez nějakých složitostí.

Před dvaceti pěti lety vzniklo něco, co předurčilo podobu budoucích herních ovladačů, včetně těch dnešních (jako třeba DualShock pro Sony PlayStation 4). Pojďme se podívat na dva významné gamepady té doby – Gravis PC GamePad a ovladač k herní konsoli Nintendo SNES (resp. Super Famicom).

Základní rozložení – čtyř-směrový ovladač vlevo a čtyři tlačítka vpravo – se od té doby drží jako nepsaný standard, jen se přidávají případná další tlačítka a funkce.