Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Byl vydán Mozilla Firefox 143.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Nově se Firefox při ukončování anonymního režimu zeptá, zda chcete smazat stažené soubory. Dialog pro povolení přístupu ke kameře zobrazuje náhled. Obzvláště užitečné při přepínání mezi více kamerami. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 143 bude brzy k dispozici také na Flathubu a Snapcraftu.
Byla vydána betaverze Fedora Linuxu 43 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 21. října.
Multiplatformní emulátor terminálu Ghostty byl vydán ve verzi 1.2 (𝕏, Mastodon). Přehled novinek, vylepšení a nových efektů v poznámkách k vydání.
Byla vydána nová verze 4.5 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
#!/usr/bin/env python services = { 'service1':{ 'description':'This is service 1', 'start':'sleep 1', 'runs_forever':False, 'depends_on':[] }, 'service2':{ 'description':'This is service 2', 'start':'sleep 2', 'runs_forever':True, 'depends_on':['service1'] }, 'service3':{ 'description':'This is service 3', 'start':'sleep 4', 'runs_forever':True, 'depends_on':['service2'] }, 'service4':{ 'description':'This is service 4', 'start':'sleep 8', 'runs_forever':True, 'depends_on':['service1', 'service2', 'service3'] } }U každé služby je jméno (service1 až service4), popisek, startovací příkaz, dále příznak 'runs_forever' a závislosti na jiných službách. Ten příznak 'runs_forever' říká, že nemá smysl čekat na ukončení dané služby. Je to například služba sshd, apache, mysql a tak. Jestliže je na takovou službu vázána nějaká závislost jiné služby, pak se nečeká na ukončení, nýbrž na start. Opakem je situace, kdy runs_forever je nepravda. To jsou zpravidla jednorázové akce, u kterých se musí čekat na ukončení (třeba fsck, natahování jaderných modulů, mountování filesystémů atd.).
#!/usr/bin/env python import threading, subprocess from services import services events = {} class Serv(threading.Thread): def __init__(self, services, name): events[name] = threading.Event() threading.Thread.__init__(self) self.service = services[name] self.name = name def run(self): print self.name, 'is about to start' for name_dep in services[self.name]['depends_on']: print self.name, 'is waiting for', name_dep events[name_dep].wait() print 'starting', self.name cmd = self.service['start'].split() proc = subprocess.Popen(cmd) if not self.service['runs_forever']: proc.wait() print self.name, 'is finished (DONE)' else: print self.name, 'runs as daemon (DONE)' events[self.name].set() all_serv = [Serv(services, name) for name in services] for serv in all_serv: serv.start()Tak se začnou dít věci
service3 is about to start service3 is waiting for service2 service2 is about to start service2 is waiting for service1 service1 is about to start starting service1 service4 is about to start service4 is waiting for service1 service1 is finished (DONE) starting service2 service2 runs as daemon (DONE) service4 is waiting for service2 service4 is waiting for service3 starting service3 service3 runs as daemon (DONE) starting service4 service4 runs as daemon (DONE)Je fakt psina si s tím trochu pohrát. Zvlášť s cyklickými závislostmi
Tiskni
Sdílej:
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)