OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
user1
a proces pod user2
z něj bude chtít číst.
někde ve var,/var/run, /tmp nebo /var/tmp. Jinde to nemá co dělat.
/var/spool/<jméno služby>
když to budu považovat za systémovou službu, tak je to naprosto adekvátní místo.
Já osobně to mám takto:
mkfifo /tmp/alarm chmod 660 /tmp/alarm
A pod svou session startuji:
while true; do osd_cat ... < /tmp/alarm; done &
Jakýkoliv program pak může provést echo "zprava" > /tmp/alarm
.
Nebo v čem jiném by ten váš druhý program byl než ve smyčce.Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.
Přiznávám se bez mučení, že mám asi dlouhé vedení, ale ten tvůj příspěvek nechápu...Jenže on právě v žádné smyčce běžet nebude, bude ve stavu S a čekat na vstup z té roury.Nebo v čem jiném by ten váš druhý program byl než ve smyčce.Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.
Pokud čte z roury tak v žádné smyčce není. Zkuste si to spustit jen tak v terminálu. Zjistíte, že se spustí a zastaví se na čtení a nepokračuje, dokud nemá načtena data, tj. dokud do roury jiný proces nepustí EOF. Když má načteno tak pokračuje, tj. zobrazí načtený text a ukončí se.
Smyčka jej znovu spustí a on se opět zastaví dokud nepřijde vstup. Je zcela lhostejné, zda čeká na vstup sekundu nebo 2 hodiny, po tu dobu se neprovádí žádné instrukce a program stojí.
while true do # čekání while ! [ -f /tmp/baf ] do sleep 1 done rm -f /tmp/baf # reakce echo Lek. done… je ukázkou aktivního čekání na událost:
touch /tmp/bafKdežto při pasivním čekání program prostě řekne operačnímu systému "Hele až se něco bude dít, tak mě vzbuď." a jde spát.
mkfifo /tmp/fifo while true do # čekání cat /tmp/fifo >/dev/null # reakce echo Lek. doneBude čekat na událost:
echo Baf >/tmp/fifoJak je vidět, oba programy mají nějakou hlavní smyčku, která však s vlastním čekáním nemá vůbec nic společného a v žádném z případů by tam nemusela být – program by pak počkal na jednu událost a skončil. Nicméně v případě aktivního čekání by bylo možné nahradit čekací cyklus jednoduchou konstrukcí if a nechat program běhat ve hlavní smyčce. To je vhodné, pokud by program měl provádět více věcí najednou. Pro pasivní čekání by bylo v takovém případě nutno využít něco jako select() či alarm(), což má své výhody i nevýhody. Tak snad už je jasné, kde který cyklus je a co dělá nebo spíš nedělá
write
?
Nebo talk
, v komibnaci s pípáním to nelze ignorovat
trap 'echo dostal jsem' USR1a pres kill se mu z jineho procesu posle signal:
kill -USR1 [cislo processu]
shutdown -k now "zprava"
mkfifo /tmp/mojerouraa pak zpracovávací skript
while read promenna < /tmp/mojeroura; do if [ $promenna == zpracuj ] then #proved zpracovani fi #pripadne misto if nejaky case pro vic moznosti doneUpřímě nechápu, proč se chceš vyhnout cyklům? Jasně, třeba cykly typu "while /bin/true; do if grep "akce" /tmp/ridicisoubor; then udelej_akci; fi; sleep 1; done" jsou trošku hloupý, ale když se cyklus postaví tak, jak jsem psal, při volání příkazu read se skript zastaví a bude čekat tak dlouho, dokud se v rouře neobjeví informace. Pokud informace bude EOF, cyklus se ukončí. Pokud bude něco jiného, řádek se uloží do proměnné "promenna" a dá se s ní pak v tělě cyklu pracovat... -miky PS. řešit to přes sudo? neni to drobet brutální?
PS. řešit to přes sudo? neni to drobet brutální?No ve srovnání s psaním nějakého scriptu, který musí jako proces běžet celou dobu a mít vyřešen případný respawn, protože spadnout to může vždycky atd, ... No tak sudo je teda fakt jednodužší a mnohem spolehlivější způsob.
Tiskni Sdílej: