Společnost Espressif (ESP8266, ESP32, …) získala většinový podíl ve společnosti M5Stack, čímž posiluje ekosystém AIoT.
Byla vydána nová stabilní verze 3.5 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). Přehled novinek také na YouTube. Nově lze využívat cloud (audio.com). Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
50 let operačního systému CP/M, článek na webu Computer History Museum věnovaný operačnímu systému CP/M. Gary Kildall z Digital Research jej vytvořil v roce 1974.
Byl zveřejněn program a spuštěna registrace na letošní konferenci Prague PostgreSQL Developer Day, která se koná 4. a 5. června. Na programu jsou 4 workshopy a 8 přednášek na různá témata o PostgreSQL, od konfigurace a zálohování po využití pro AI a vector search. Stejně jako v předchozích letech se konference koná v prostorách FIT ČVUT v Praze.
Po 48 letech Zilog končí s výrobou 8bitového mikroprocesoru Zilog Z80 (Z84C00 Z80). Mikroprocesor byl uveden na trh v červenci 1976. Poslední objednávky jsou přijímány do 14. června [pdf].
Ještě letos vyjde Kingdom Come: Deliverance II (YouTube), pokračování počítačové hry Kingdom Come: Deliverance (Wikipedie, ProtonDB Gold).
Thunderbird 128, příští major verze naplánovaná na červenec, přijde s nativní podporou Exchange napsanou v Rustu.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Novým vedoucím je Andreas Tille.
Po osmi měsících vývoje byla vydána nová verze 0.12.0 programovacího jazyka Zig (GitHub, Wikipedie). Přispělo 268 vývojářů. Přehled novinek v poznámkách k vydání.
Poslední měsíc byl plný zajímavých akcí, o kterých Vám bastlíři z projektu MacGyver mohou povědět, protože se na ně sami vydali. Kde všude byli, ptáte se? Objevili se na Installfestu, Arduino Day, Hackaday Europe a tajném srazu bastlířů z Twitteru. A z každé akce pro vás mají zajímavé poznatky.
… více »depend() { use clock logger need localmount provide cron } start() { ebegin "Starting vixie-cron" start-stop-daemon --start --quiet --exec /usr/sbin/cron eend $? } stop() { ebegin "Stopping vixie-cron" start-stop-daemon --stop --quiet --pidfile /var/run/cron.pid eend $? }a myslím, že to o moc líp ani nejde. Paralelní spouštění? Není problém,
RC_PARALLEL_STARTUP="yes"
. Nepřehledný? Neřekl bych. V Pythonu by to bylo rychlejší? Těžko, když:
amd64 ~ # time python -c exit # a to není první "start", ale druhý! real 0m0.052s user 0m0.013s sys 0m0.002s amd64 ~ # time bash -c exit real 0m0.003s user 0m0.000s sys 0m0.003sa spustit musí v podstatě totéž...
No nevím, znám jen Gentoo a tam máme init skripty třeba takový (vixie-cron):Takhle to vypadá pěkně. Ale když se člověk trochu podívá pod pokličku, tak už to taková radost být nemusí.
a myslím, že to o moc líp ani nejde.Všechno jde zlepšit! Nebo taky pokazit ...
Paralelní spouštění? Není problémNo, ve Fedoře to zatím problém je. Proto jsem se do toho pustil.
V Pythonu by to bylo rychlejší? Těžko, když:Ech, takových benchmarků už jsem viděl ...amd64 ~ # time python -c exit # a to není první "start", ale druhý! real 0m0.052s amd64 ~ # time bash -c exit real 0m0.003s
No, ve Fedoře to zatím problém je. Proto jsem se do toho pustil.Aha
A Python s Bashem nehodlám dále srovnávat - myslím, že vše již bylo řečeno. Jestliže se někdo domnívá, že Bash je rychlejší, tak mu to už vyvracet nebudu. Ale ten dotyčný si ke své škodě lže do kapsy.Ne, to netvrdím... tvrdím, že Python i Bash spustí externí prográmky stejně rychle a o ty jde především. Teď mě napadlo, že by ty init-skripty mohly být v C, to by to nabootovalo ještě rychleji
Teď mě napadlo, že by ty init-skripty mohly být v C, to by to nabootovalo ještě rychlejiTím chceš říct, že ještě nemáš na Gentoo Init-NG?
V Pythonu by to bylo rychlejší? Těžko, když: amd64 ~ # time python -c exit # a to není první "start", ale druhý! real 0m0.052s user 0m0.013s sys 0m0.002s amd64 ~ # time bash -c exit real 0m0.003s user 0m0.000s sys 0m0.003s a spustit musí v podstatě totéž...Omyl, Python se spouští jednou, bash cca 200-500x. To už je rozdíl, že? Python skripty budou kompilované a nebudou se muset opakovaně znova a znova parsovat. Běh programu v Pythonu je mnohem rychlejší než v Bashi. Z bash scriptů se nepočítaněkrát spouští další procesy typu sed, u pythonu to jede v rámci binárky. Udělejte si skript, kde se stokrát vyhodnocuje regulární výraz, jednou v bashi+sedu jednou v pythonu a hoďte sem výsledek, pak se pobavíme, co je rychlejší.
ad zavislosti, mozno by neskodilo definovat, co ta ktora sluzba ovplyvnuje. Myslim, ze by stacilo definovat, ci ovplyvnuje nastavenie systemu (napr "network") a najprv spustit vsetky ovplyvnujuce a potom neovplyvnujuce. Napr (moj oblubeny) ntpd nastavenie ovplyvnuje, ale vyzaduje funkcnu siet, ale napr sshd ci apache nan nepotrebuju explicitnu zavislost. Takych moze byt viac, specifickych pre ten ktory stroj.
technicke poznamky:Já ve skutečnosti potřebuju, aby se thready ovlivňovaly. Ale musí to být kontrolovaně, jinak se z toho stane splašené stádo. K tomu účelu existuje řada synchronizačních mechanismů. V Pythonu je přímá podpora zámků, reentrantních zámků, podmínkových objektů, semaforů a událostí. Já jsem použil ty události.
- ako chcete zabranit, aby sa thready neovplyvnovali (fork je fork)?
- ako to bude fungovat napr nie pre "sleep 1", ale pre "apachectl start" (pricom samozrejme vyzadujem, aby sa sluzba restartla po pripadnom pad, okrem situacie, ked ju rucne zhodim?Apachectl hodlám přepsat, protože se mi nelíbí
ad zavislosti, mozno by neskodilo definovat, co ta ktora sluzba ovplyvnuje. Myslim, ze by stacilo definovat, ci ovplyvnuje nastavenie systemu (napr "network") a najprv spustit vsetky ovplyvnujuce a potom neovplyvnujuce. Napr (moj oblubeny) ntpd nastavenie ovplyvnuje, ale vyzaduje funkcnu siet, ale napr sshd ci apache nan nepotrebuju explicitnu zavislost. Takych moze byt viac, specifickych pre ten ktory stroj.Jojo, taky myslím, že je to rozumná věc, bez které by to byla hrůza. Jinak by se u všech služeb musela explicitně psát závislost např. na fsck, raidu apod. a jistě by se na něco zapomnělo.
odporucam vam rozmyslat o 0..n v odpovedi na nasledovne:
- kolko je distribucii ?
- kolko je sposobov nasadenia ?
- kolko produktov poskytuje dany typ sluzby ?
- kolko instancii sluzby je mozne spustit ?
- kolko produktov bude na cielovom stroji nainstalovanych ?
dobre by bolo zobrat vsetky existujuce daemony (freshmeat.net pomoze), popisat si ich zavislosti, nakreslit si ich postupnost a potom si uvedomit, ze lubovolna cast moze byt (dokoncia viac krat), ale i nemusi
otazka navyse nesmerovala priamo k apachectl, ale k sposobu, ako mienite "kontrolovat" proces, od ktoreho nedostanete SIGCHLD.
- Distribucí je spousta. Každá to dělá po svém.odporucam vam rozmyslat o 0..n v odpovedi na nasledovne:
- kolko je distribucii ?
- kolko je sposobov nasadenia ?
- kolko produktov poskytuje dany typ sluzby ?
- kolko instancii sluzby je mozne spustit ?
- kolko produktov bude na cielovom stroji nainstalovanych ?
dobre by bolo zobrat vsetky existujuce daemony (freshmeat.net pomoze), popisat si ich zavislosti, nakreslit si ich postupnost a potom si uvedomit, ze lubovolna cast moze byt (dokoncia viac krat), ale i nemusiAle no ták ...
otazka navyse nesmerovala priamo k apachectl, ale k sposobu, ako mienite "kontrolovat" proces, od ktoreho nedostanete SIGCHLD.Tak teď nevím, o čem mluvíte. apachectl nijak nereaguje na SIGCHLD - je mu to úplně jedno. Co myslíte tím "kontrolováním"? Jestliže nějakého démona pustím přímo, tak se přece snadno dozvím, že skončil. Jestliže ho pustím přes wrapper, tak mám prostě smůlu a musím zjišťovat existenci PIDu nebo se dívat na otevřené porty nebo tak něco. Nepřipadá vám, že děláte z komára velblouda (alias ťavu)
Tiskni Sdílej: