Správce sbírky fotografií digiKam byl vydán ve verzi 8.3.0. Jedná se o převážně opravné vydání doplněné o aktualizace knihoven a drobné úpravy uživatelského rozhraní, ale dostala se do něj např. práce na automatickém štítkování z obsahu obrázků, výstup projektu z GSoC 2023.
Byl vydán Mozilla Firefox 124.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 124 je již k dispozici také na Flathubu a Snapcraftu.
Man Yue Mo z GitHub Security Lab se podrobně rozepsal o již opravené zranitelnosti CVE-2023-6241 v Arm Mali GPU umožňující získání roota na telefonu Pixel 8 s povoleným MTE (Memory Tagging Extension).
V San José probíhá vývojářská konference NVIDIA GTC 2024. CEO společnosti NVIDIA Jensen Huang měl dvouhodinovou keynote, ve které představil celou řadu novinek: NVIDIA Blackwell platform, NVIDIA NIM microservices, NVIDIA Omniverse Cloud APIs, Project GR00T, …
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Od 21. do 23. března proběhnou Arduino Days 2024. Sledovat bude možné oficiální streamy. Zúčastnit se lze i lokálních akcí. V Česku jsou aktuálně registrovány dvě: v Praze na Matfyzu a v Poličce v městské knihovně.
Letošní ročník konference LinuxDays se uskuteční o víkendu 12. a 13. října, opět se potkáme v pražských Dejvicích na FIT ČVUT. Také během letošního ročníku nás budou čekat desítky přednášek, workshopy, stánky a spousta doprovodného programu. Aktuální dění můžete sledovat na Twitteru, Facebooku nebo na Mastodonu, přidat se můžete také do telegramové diskusní skupiny.
Byla vydána nová major verze 2.0.0 a krátce na to opravné verze 2.0.1 open source online editoru Etherpad (Wikipedie) umožňujícího společné úpravy v reálném čase.
Matematický software GNU Octave byl vydán ve verzi 9.1.0. Podrobnosti v poznámkách k vydání. Nově je preferovaný grafický backend Qt a preferovaná verze Qt 6. V tomto vydání byly přepracovány funkce pro převod čísel z desítkové soustavy. Jako obvykle jsou zahrnuta také výkonnostní vylepšení a zlepšení kompatibility s Matlabem.
Jiří Eischmann z desktopového týmu Red Hatu se v příspěvku Linuxový desktop: Co vám chybí na svém blogu ptá, co uživatele na Fedora Workstation a na linuxovém desktopu obecně trápí a co by desktopový tým mohl zlepšit. Pokud máte nějaké podněty, napište mu je do komentářů.
Tiskni Sdílej:
+1
Určitě jste se díval do manových stránek? Protože systemd mi přijde jako nejlépe zdokumentovaný nástroj v celém běžném systému. Ty manové stránky jsou rozsáhlé, mají příklady, je jich kopa, a jsou logicky napsané. Aktuálně mám v systému 157 manových stránek začínajících na systemd.
Len tak mimochodom, mohol by si ukázať nejaký viac stránkový bash init skript, ktorý si prerobil na 10 riadkový systemd konfiguračný súbor?Tieto rozprávky sú novou urban legend. +1 za sysvinit. Že koľko zo žiadostí bude vyslišaných? V RH tak 0% No a ešte tie vyhodené prachy za Wayland. Xká už za desatinu mohli robiť to o čom sa Waylandákom sníva a manažér mohol mať z ušetrených prachov barák. Sa čudujem, že do takýchto zbytočných vecí Jiří ešte púšťa, keď vie že sa nič nezmení.
Len tak mimochodom, mohol by si ukázať nejaký viac stránkový bash init skript, ktorý si prerobil na 10 riadkový systemd konfiguračný súbor?Tak narychlo som zagooglil: uTorrent init skript (cca 200 riadkov) vs 9 riadkov systemd konfiguracie. Nie je to uplne fer, lebo ta systemd verzia spusta nejaky extra skript, ale ked sa na ten skript pozries, dal by sa integrovat priamo do service konfiguracie s nejakymi 3 extra riadkami. Alebo napriklad taky monit. Tam uz ten rozdiel vo velkosti konfiguracie nie je az taky velky, ale so sytemd viem, ze ked stopnem service, tak urcite sa ukoncia vsetky procesy. Tiez sa mi postara o restartnutie v pripade, ze service padne s nejakou chybou. Proste je tam out of the box o dost viac funkcionality ktoru nemusim explicitne definovat.
Za příklad bych mohl dát třeba minecraft server.Kdysi jsem neskutecne ragoval, kdyz mi nejaka starsi verze Minecraft serveru (spustena z jineho adresare) zapsala data primo do ~.
Tak ona je otázka, zda by ty rc skripty nešly napsat lépe a zda by pouhé jejich přepsání nepřineslo značnou úsporu. Protože u některých kreací skutečně zůstává rozum stát.Na to bylo X let v Y ruznych distribucich, a nejak se nedarilo, a pak prisel systemd a mame to na par radcich, chodici na vsech distribucich, ktere ho pouzivaji.
a pak prisel systemd a mame to na par radcich,A máme prvý init ktorý dokáže spadnúť. Tie hacky aby niečo chodilo sú len presunuté zo skriptov v tom blobe, takže sa problém len presunul. Nedejú sa tu žiadné zázraky a ani sa nevyrába hmota z ničoho. Má to jeden problém, že to namiesto komunity ostalo na pár ľuďoch a stojí to za kulové. Všetky tie hacky sú za roky v init skriptoch a nemusíš ich nijak riešiť a písať 200riadkové bash skripty, stačí ich použiť. Ďalší Urban Legend.
Tie hacky aby niečo chodilo sú len presunuté zo skriptov v tom blobe, takže sa problém len presunul. Nedejú sa tu žiadné zázraky a ani sa nevyrába hmota z ničoho. Má to jeden problém, že to namiesto komunity ostalo na pár ľuďoch a stojí to za kulové.A dale:
Všetky tie hacky sú za roky v init skriptoch a nemusíš ich nijak riešiť a písať 200riadkové bash skripty, stačí ich použiť.Oboji je zcela v poradku danym zpusobem resit. Jestli tam nedoslo k jinym chybam, to uz je druha otazka. Ty zde ovsem nekritizujes konkretne systemd, presto, ze je to tvym zjevnym zamerem, coz tak nejak vypovida o kvalite toho prispevku.
co je v softwarovem inzenyrstvi povazovano za dobrou praxiAsi nechápu úplně přesně co přesně je v tomto případě považováno za dobrou praxi. Opravdu se někde učí, že je dobré všechny hacky (míněno v negativním slova smyslu) naházet na jednu hromadu? Já za dobré inženýrské řešení považuji takový návrh, který hacky buď nepotřebuje, a nebo na ně včas a velmi důrazně upozorní. Tj že třeba takový program prostě nepojede, dokud ho někdo neopraví. Protože ten první postup vede ke stavu, který je například u her, které zcela v rozporu se specifikací pracují s D3D nebo OGL a dohánějí to potom ovladače GPU, které odhadují, co asi tak ta hra chce vykreslit. Bohužel se to dostalo do stavu, kdy autoři software ty chyby ani neřeší a rovnou to hází na bedra vývojářům ovladačů, kteří si ovšem nemohou dovolit to neřešit (což by bylo správné řešení), protože na konkurenční kartě to jede. Totéž se dělá u toho MC serveru, který je zvykem pouštět v ramdisku (world data), protože ten datový model je tak zprasený, že na normálním disku to nestíhá seekovat. Tím, že se to od počátku vráželo do ramdisku se celý problém jen oddálil. A toto je třeba důvod, proč nemám rád systemd. Protože může vyvolat velmi nedobré návyky. Však on to systemd vyřeší. Simple nejede, namlátím tam fork. Pošlu tam pipe. Samo to restartne můj proces po pádu, proč se štvát s robustností. Atd.
Opravdu se někde učí, že je dobré všechny hacky (míněno v negativním slova smyslu) naházet na jednu hromadu?To zalezi. Pokud ho potrebujes na nekolika ruznych mistech (tj. v ruznych init skriptech), tak je lepsi ho presunout na jedno misto a dobre ho zdokumentovat.
Já za dobré inženýrské řešení považuji takový návrh, který hacky buď nepotřebuje, a nebo na ně včas a velmi důrazně upozorní.Takove reseni by bylo nadrazene mnou uvedenemu reseni (a postupny vyvoj to, v nekterych pripadech, muze umoznit; nejprve hack presunes z N ruznych mist na jedno misto, a pak jej i z toho jedineho mista odstranis uplne). Zajimaji me fakta, nikoliv neci subjektivni emoce. V predchozim prispevku, na ktery jsem reagoval, ty fakta nevidim. Vidim jen emoce a nedostatecne kvalitni prispevek, ktery otevira prostor pro spekulace (coz jsem presne udelal, abych vyprovokoval kvalifikovanou odpoved). Uvidime, zda se mi ji dostane. O ktere konkretni hacky se jedna? Jsou ty hacky specificke pro systemd, nebo se to tyka i Upstartu a treba OpenRC? Etc. Muj subjektivni dojem ze systemd je negativni, protoze (razeno dle dulezitosti): 1/ se domnivam, ze projekt takoveho rozsahu/vyznamu je prilis mlady na pouziti v produkcnich systemech (zejmena me nemile prekvapilo zarazeni do konzervativniho Debianu), 2/ vidim/slycham nepekne veci o pristupu autoru, a v neposledni rade, 3/ jsem musel do noci/rana louskat manualove stranky pri migraci naseho serveru z Upstartu na systemd (a neustale jsem narazel na nejake problemy, kde dodnes nevim, nakolik to bylo stresem/nevyspalosti a nakolik nedostatecnou presnosti manpages; v ramci objektivity nezbyva nez predpokladat primarne prvni variantu). Nicmene, jak jsem rekl, tohle je subjektivni dojem, nikoliv informovany nazor, ktery bych si rad udelal, ale nedostava se mi ho. Subjektivni dojem neni hodny verejne publikace, zvlast ne v pripadech, kdy by cilem mela byt konstruktivni diskuze. Pisu to jen pro uplnost, protoze jinak me nekdo za chvili zacne stavet do role obhajce systemd a bude se dozadovat argumentu, ktere mu vsak nemuzu poskytnout.
Zajimaji me fakta, nikoliv neci subjektivni emoce.Jenže ony i ty emoce jsou v životě velmi důležité. Člověk není stroj, člověk se nerozhoduje racionálně (potom by byl označen za psychopata), člověk je tvor racionalizující (tedy své rozhodnutí zpět tu lépe tu hůře dokáže obhájit). A pokud někoho, kdo má zrovna tu smůlu, že na rozdíl o těch ostatních s tím systémem každodenně pracuje, naserete, tak už se s ním jen těžko pohne. Problém je, že diskuse o sd jsou velmi často čistě emoční. Přijde tam admin, který s tím má nějaký problém (kupodivu proto, že sd používá, nikoliv proto, že chce jen hatovat) a odpovědí je mu buď NOTABUG WONTFIX, nebo v případě české diskuse výsměch o tom, že se nechce učit nic nového. A celá diskuse jde do kopru. Admin na to přijde sám, ale ta pachuť zůstane. Já nevím, jaké konkrétní hacky má kdo na mysli. To musí odpovědět on. Sám za sebe, používal jsem léta letoucí rc.v a no problemo. Používám na FreeBSD ten jejich systém a no problemo ještě o řád víc (je to čistější, přehlednější, jednodušší). Používám systemd a už jsem odhalil několik bugů. Nic z toho nebyl show stopper, jako admin si poradím. Ale nad některými bugy zůstává rozum stát. Jak to, že si toho nevšimla kontrola? Jak to, že si toho nevšiml autor? Chci dál používat takový systém? Mám vlastně na výběr? Protože admin nežije ve vakuu, admin má zkušenosti s mnoha předchozími systémy. Já mám zkušenosti dneska už prakticky desítky milionhodin z běhu různých služeb (stovky systémů, tisíce služeb, hromada let). Ty služby se nějak chovají, nějak (ne)napadají, autoři k nim mají nějaký vztah. Ano, je to opět o těch emocích, spíše bych řekl o šestém smyslu. Prostě se ti do mozku zažere, ok, takhle je to dobře, takhle se to má dělat. Šestý smysl se tvoří zkušeností a na něm je postavené řemeslo. Potom přejdeš (z donucení) na systém, o kterém ti všichni tvrdí, jak je skvělý a jak je úžasný, ok, tak si něco vyzkoušíš a okamžitě narazíš na problém. A ptáš se, jak je možné, že na to ještě nikdo nenarazil? A potom se jen pročítáš bugreporty a nestačíš se divit, co vše bugzilla snese.
Jenže ony i ty emoce jsou v životě velmi důležité. Člověk není stroj, člověk se nerozhoduje racionálně (potom by byl označen za psychopata), člověk je tvor racionalizující (tedy své rozhodnutí zpět tu lépe tu hůře dokáže obhájit).Asi taky zalezi jak ktery clovek a do jake miry. Predevsim jsem ale mluvil o teto diskuzi, kdy me opravdu nezajima, jaky z ceho ma kdo pocit. Ne o tom, ze si pri poslechu hudby zakazuji prozivat emoce.
A pokud někoho, kdo má zrovna tu smůlu, že na rozdíl o těch ostatních s tím systémem každodenně pracuje, naserete, tak už se s ním jen těžko pohne.Jeho problem.
Já nevím, jaké konkrétní hacky má kdo na mysli. To musí odpovědět on.Nic jineho neocekavam.
Sám za sebe, používal jsem léta letoucí rc.v a no problemo. Používám na FreeBSD ten jejich systém a no problemo ještě o řád víc (je to čistější, přehlednější, jednodušší). Používám systemd a už jsem odhalil několik bugů.Pak uvedeni tech bugu muze byt argument proti systemd. V idealnim pripade i s odkazy na GitHub issues. Ostatni si pak muzou udelat objektivni nazor.
Chci dál používat takový systém? Mám vlastně na výběr?Zase nevidim, k cemu to smeruje. Prirozene chces pouzivat to nejlepsi. Pokud neco nefunguje (a pritom to driv fungovalo), tak je to proste problem toho daneho reseni a muzes jej za to opravnene kritizovat (stejne jako rozhodnuti distribuce takove spatne reseni pouzit).
Ano, je to opět o těch emocích, spíše bych řekl o šestém smyslu. Prostě se ti do mozku zažere, ok, takhle je to dobře, takhle se to má dělat. Šestý smysl se tvoří zkušeností a na něm je postavené řemeslo.Jaky sesty smysl? Proste mas zkusenosti, tj. znalost moznych reseni a to, cemu se rika hands-on experience. Muzes objektivne posoudit vyhody a nevyhody kazdeho reseni a rozhodnout, ktere je pro dany ucel nejlepsi. Pokud to nejde zcela rozhodnout exaktne formalnimi metodami (coz nejde), bude to zatizene temi emocemi a subjektivnim vnimanim, ale ta odchylka by nemela byt zvlast vyznamna.
Potom přejdeš (z donucení) na systém, o kterém ti všichni tvrdí, jak je skvělý a jak je úžasný, ok, tak si něco vyzkoušíš a okamžitě narazíš na problém.Proto me zajimaji spis ty fakticke informace nez neci nazor, ze je to skvele a uzasne, popr. to vyzkousim sam. Pokud narazim na konkretni problemy, pak je lze opet pouzit jako protiargumenty. Nevidim, v cem je problem.
Na to bylo X let v Y ruznych distribucich, a nejak se nedariloTak otázkou je, jestli nebylo jen potřeba pořádně prásknout do stolu a konečně nedonutit lidi, aby na tom začali makat. Ten impuls přišel se systemd, ale to nemusí být nutně jeho zásluha.* Když srovnám rc skripty v FreeBSD a v linuxu, tak tam jistý rozdíl pozoruji. Konfigurace celého systému v jednom souboru, jednotlivé skriptíky jednoduché a čitelné. Vše v bashi (nebo v tom jejich csh).
a pak prisel systemd a mame to na par radcichJo OK. Ale taky je potřeba vidět těch pár desítek tisíc řádků v C za tím. *) Ono taky je asi dobré se zamyslet nad tím, jak tato situace vznikla, protože rc.v skripty v linuxu co si pamatuji z konce 90 let, tak taky nebyly nijak brutálně složité. Takže něco nastalo časem, co tam přineslo ten balast.
Povedzme, ze aplikacia zavisi na DB. Systemd ti toto automaticky osetri a vie napriklad korektne zastavit aplikaciu pred tym ako stopne DB. (A opacne, vie spustit DB predtym ako nastartuje aplikaciu)Tohle je sice moc krásné, ale v životě nastávají i složitější situace. Například db a aplikace na jiném stroji. Síť může vypadnout. Databázi je nutno restartovat. Apod. To znamená, že ta aplikace tak jako tak musí počítat se situacemi, kdy tu db prostě nemá. Buď ji ještě nemá, nebo ji už nemá, nebo ji za chvíli opět bude mít. Takže nakonec je úplně jedno, jestli db nastartuje dřív jak aplikace, nebo naopak. Nehledě na to, že systemd nepozná, zda už je ta db nastartovaná a zda může přijímat dotazy. Některé db mají velmi dlouhý recovery proces (nebo check proces) a může trvat klidně i desítky minut, než db připustí první připojení. Takže systemd tohle sice řeší (a řeší to poměrně elegantně), ale z principu nemůže vyřešit všechny problémy a ta aplikace s těmi problémy stejně musí počítat.
Nehledě na to, že systemd nepozná, zda už je ta db nastartovaná a zda může přijímat dotazy. Některé db mají velmi dlouhý recovery proces (nebo check proces) a může trvat klidně i desítky minut, než db připustí první připojení.To sa da riesit viacerymi sposobmi, ale sluzba vie systemd oznamit, ze je plne nastartovana. Dokonca si vies takto poriesit aj watchdog prostrednictvom ktoreho vie systemd pravidelne kontrolovat stav sluzby.
Tu ide o princip, ze take veci sa deju pomerne casto.No a v každém konkrétním případě se dá najít lepší řešení bez systemd.
ale sluzba vie systemd oznamitNo, ehm, ale to zase vytváří další zbytečnou závislost na systemd. Aby služba dokázala sdělit systemd, že už je naběhlá, tak musí implementovat minimálně tu notifikační část. Takový plíživý vendor lock in. Nehledě na to, že ta služba může být sice naběhlá, ale ze pět minut sletí a proces zůstane vyset třeba v nekonečném čekání. Takže systemd bude happy, jak mu krásně všechno běží a jak se služby poctivě ohlásily po startu, ale funkční to není. Apropos, proč jsem si na to po týdnu vzpoměl:
root@rss:~# systemctl status ● rss State: running Jobs: 0 queued Failed: 0 units
root@rss:~# systemctl --failed 0 loaded units listed. Pass --all to see loaded but inactive units, too.Takže všechno krásně běží no ne? No kdyby všechno krásně běželo, tak bych se s tím komentářem ani nepsal. Takže:
root@rss:~# systemctl status ttrss.service ● ttrss.service - ttrss_backend Loaded: loaded (/etc/systemd/system/ttrss.service; enabled; vendor preset: enabled) Active: inactive (dead) since Sat 2017-05-13 20:15:08 CEST; 16min ago Process: 148 ExecStart=/var/www/html/update_daemon2.php (code=exited, status=0/SUCCESS) Main PID: 148 (code=exited, status=0/SUCCESS) May 13 20:15:04 rss systemd[1]: Started ttrss_backend. May 13 20:15:08 rss update_daemon2.php[148]: PHP Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL:Super ne?
code=exited, status=0/SUCCESS
Služba sice havarovala, protože nastartovala o 1s dřív, než se inicializovala databáze, ale prostě SUCCESS.
Ten autor se ani neobtěžuje správně používat návratové kódy procesu. Asi je to moc zastaralý koncept a je potřeba vyvinout exitcodesd-ng, aby to chvíli zase někdo používal.
Ne, problém opravdu není v initu.
No a v každém konkrétním případě se dá najít lepší řešení bez systemd.Nejaky priklad by nebol? Lepsie riesenie v com? Ze okrem initu budes mat milion dalsich rovnatiek na ohybatka aby si kazdy konkretny pripad osetril?
Takže systemd bude happy, jak mu krásně všechno běží a jak se služby poctivě ohlásily po startu, ale funkční to není.V tom pripade vies pouzit watchdog, ktory systemd tiez podporuje a ked sa sluzba po dlhsej dobe neozve je povazovana za failed. Osobne si myslim, ze toto uz by mal riesit nejaky monitoring a nie init system - ak teda nie je zlyhanie sluzby sucastou beznej prevadzky. (ak sa teda nebavime o desktope, tam samozrejme BFU nebude prevadzkovat monitorovaci system, ze?) Rad by som videl tu systemd konfiguraciu pre ttrss, pretoze toto vyzera, ze je (okrem teda zleho navratoveho kodu) aj zle nastavena sluzba. Pokial ma bezat sluzba stale, tak by mala byt nastavena tak, aby ju systemd restartoval aj v pripade, ze sa ukonci s nulou. A opat podotykam, ze systemd umoznuje aby ttrss pockal kym bude databaza ready, cize k takejto situacii vobec nemuselo dojst, keby boli sluzby dobre nastavene, nepripada mi to ako problem systemd. Ja nevravim, ze systemd je bez chyby, ale 99% problemov co tu ludia pisu je bud zlym nastavenim sluzby, tym, ze ludia nevedia o systemd ani uplne zaklady, alebo ide o chyby ktore sa objavia vo vyvojovej vetve systemd , ale hned je o tom tisic clankov, pretoze "zle zle systemd" generuje vela klikov..
..
, akurat, ze rm ma tieto pripady specialne osetrene a odmietne ..
vymazat.
Ze okrem initu budes mat milion dalsich rovnatiek na ohybatka aby si kazdy konkretny pripad osetril?Jaká rovnátka na ohejbátka?
Osobne si myslim, ze toto uz by mal riesit nejaky monitoring a nie init system - ak teda nie je zlyhanie sluzby sucastou beznej prevadzky.Ano, to si myslím, také, potom ovšem nepotřebuji, aby init systém monitorovat běh té služby. Stejně o ní nic nezjistí.
Rad by som videl tu systemd konfiguraciu pre ttrss, pretoze toto vyzera, ze je (okrem teda zleho navratoveho kodu) aj zle nastavena sluzba.Asi jsem to napsal nevhodně. Já v tomto nepodezřívám systemd. Ten se zachoval správně. Proces se spustil, po chvíli se ukončil s exit code 0 a systemd to správně vyhodnotil jako success. Služba prostě stojí, vše je v pořádku. Jinak ta unita je trivka:
[Service] User=www-data ExecStart=/var/www/html/update_daemon2.php [Install] WantedBy=multi-user.targetNa tom není co řešit. Problém je v tom
update_daemon2.php
, který si naforkuje childy a v každém z nich se pokouší pracovat. Problém je, že jak spadnou childy, tak se hlavní proces ukončí jako exit code 0. Prostě špatně napsané. To už by bylo lepší, kdyby ty workchildy byly volány jako unita Type=oneshot
a přes systemd.timer
. (Jenže to by zase nesměl být v systemd bug s logováním rychle běžících úloh. Už od roku 2012.)
To, co jsem chtěl tímto příkladem ukázat je to, že pokud se autor ani neobtěžuje vracet správně návratové kódy, tak to stejně žádný systemd nevyřeší.
Pokial ma bezat sluzba stale, tak by mala byt nastavena tak, aby ju systemd restartoval aj v pripade, ze sa ukonci s nulou.Což považuji za chybu, že tam ta možnost vůbec je. Jen to dále sníží tlak na to, psát ty programy správně.
Lepsie riesenie v com?Lepší řešení v tom, že autoři budou psát robustní software. Co jsme v diskusích často četli, jako hlavní plus systemd? Snadné psaní unit. Autorům se prostě nechtělo psát "složité" init skripty. Jenže ty init skritpy nebyly složité "prostě proto", ale z toho důvodu, že ten jejich software prostě něco zanedbal. Nevím jako kdo, ale já si prostě občas něco pustím jako
program -d
- neřeším ani unitu, nic, prostě jen tak program -d
. A ono to běží.
Tzn. fakticky jediné, co má init řešit, je spuštění definovaných programů. To, že to nejde, ukazuje na problém. Ten problém ovšem nevyřeší systemd. Za 10 let se bude řešit totéž.
Třeba to, proč existuje něco jako exit codes a proč tím autory někdo otravuje. Už jsem podobných nářků slyšel několik.
/etc/init.d/something stop
, tak tam mas ako dlasi bod kontrolu s ps
ci neostali bezat nejake procesy. Tolko z praxe.
Systemd mi v tomto pride trosku realnejsi, ze ti umozni aj zle napisany kod spustit s relativne jednoduchou konfiguraciou a nehra sa na to, ze budes v inite spustat iba perfektne napisany kod. Lebo proste nebudes. Kym si bude kazdy implementovat polovicu initu, tak proste bude vela pripadov, kedy ta funkcionalita bude hrozna.
Podla mna mas vacsiu sancu s tym, ked ten tlak na developerov uvolnis, povies im, ze nech sa vykaslu na init a napisu to co maju - teda samotnu sluzbu a par riadkov konfiguracie ako ju spustit. To ti aspon dava ake take standardne rozhranie.
Uz len fakt ze si viem overridnut cez service.d subory jednotlive nastavenia sluzby bez toho ze by som musel menit distribucne init skripty mi pripada ako velky krok vpred. Jasne v idealnom svete nahlasim bug, autor to opravi a ideme dalej. Ale v praxi to znamena, ze sa to cele opravi po deadline kdesi za par rokov, alebo vobec, lebo bug je velmi specificky pre moj use case..
Tak to beriem ja. Je systemd dokonaly? Ani zdaleka. Ale ziaden kod nie je dokonaly a systemd dokaze ten ubohy kod jednotlivych sluzieb aspon ako-tak spustit a ked pride na to aj udrzat v behu a o to ide.
Od toho mam predsa init system, aby mi spustil veci na pozadi.
nohup program &nebo ještě snadněji:
daemon -u user -c pwd programOno navíc hodit program na pozadí (tj odpojit se od control terminalu) není žádná raketová věda.
Co sa tyka tlaku na autorov, tak je to podla mna proste tak, ze skutocny tlak je deadline ktory ma a nie aby init skripty krasne fungovali.No já se bavím o FOSS. Pokud si někdo soukromě chce mastit svůj produkt a zanechávat si problémy do budoucna, tak je to jeho rozhodnutí. Ve FreeSoftware žádné deadline nejsou.
Mali sme uz roky aby sa tieto veci opravili a co tu mame? Mame tu runbook kde sa pise, ze ked spustis /etc/init.d/something stop, tak tam mas ako dlasi bod kontrolu s ps ci neostali bezat nejake procesy.
Systemd mi v tomto pride trosku realnejsi, ze ti umozni aj zle napisany kod spustit s relativne jednoduchou konfiguraciou a nehra sa na to, ze budes v inite spustat iba perfektne napisany kod.Ano, tohle je přesně to, kam jsem chtěl dojít. Takže vy máte vadný program. Víte o tom, že je vadný. Dnes to řešíte tím, že po stop se ještě díváte na ps. Systemd to "vyřeší" tak, že po stop zabije celou grupu. Ve skutečnosti není vyřešené nic, ten program je stále vadný, jen to není tolik vidět. Gratuluji.
Podla mna mas vacsiu sancu s tym, ked ten tlak na developerov uvolnis, povies im, ze nech sa vykaslu na init a napisu to co maju - teda samotnu sluzbu a par riadkov konfiguracie ako ju spustit.Ok, tomuto rozumím, ale je potřeba si stále uvědomit, že na tu službu to stále klade nemalé nároky. Viz příklad s tím minecraft serverem výše. Někomu přišlo hrozně fajn přijímat příkazy na stdin. Už jen taková blbost způsobí, že je poměrně těžký problém to korektně zaslužbovat. Tzn stále se nelze vykašlat na všechno a systemd sebral část problémů, ale rozhodně ne všechny.
Uz len fakt ze si viem overridnut cez service.d subory jednotlive nastavenia sluzby bez toho ze by som musel menit distribucne init skripty mi pripada ako velky krok vpred.Souhlasím.
[bsd ~]# cat /etc/rc.conf | grep postgres postgresql_class="postgres" postgresql_enable="YES" postgresql_data="/tank/db/postgres/data96"Pro nastavení konkrétních parametrů skutečně nemusím měnit distribuční init skript. Ale můžu se do něj podívat, protože na počátku obsahují nápovědu, co lze nastavit:
# Add the following line to /etc/rc.conf to enable PostgreSQL: # # postgresql_enable="YES" # # optional # postgresql_data="/var/db/postgres/data96" # postgresql_flags="-w -s -m fast" # postgresql_initdb_flags="--encoding=utf-8 --lc-collate=C" # postgresql_class="default" # postgresql_profiles=""(Zrovna včera jsem řešil, jak na FBSD přesunout postgresql jinam, otevřel jsem jeho init skript, abych se podíval, jak vlastně volá
pg_ctl
a jaké tomu předává pamatery, protože v confu data_directory neřeší. A čekalo na mě tohle milé překvapení.)
Ve FreeSoftware žádné deadline nejsou.Heh. Keby to tak bola pravda. Mozno nemas ciaru na kalendari (a vela vacsich projektov nieco take ma aj ked su OSS), ale mas len limitovany cas a ten ako developer mozes investovat bud do znovuvynaliezania kolesa, alebo si mozes povedat, ze ta init netrapi a cas vyuzijes efektivnejsie.
Ono navíc hodit program na pozadí (tj odpojit se od control terminalu) není žádná raketová věda.V tom sa zhodneme. Napriek tomu pre skoro kazdy service ktory mi na serveroch bezi autori povazovali za nutne implementovat nejaku formu daemonizacie..
Ve skutečnosti není vyřešené nic, ten program je stále vadný, jen to není tolik vidět.Tu nejde o to, ci to je alebo nie je vidiet. Ide o to, ze vahu toho problemu prenasam z programu kde je ukoncenie child procesov len vedlajsia cinnost nepodstatna pre samotne fungovanie sluzby na init system, kde je korektne (alebo aspon spolahlive) unoncenie sluzby sucastou zakladnej funkcionality. K prikladu s Postgres len tolko, ze kolko takych sluzieb mas v systeme, kde mas aku-taku konfigurovatelnost vs tych, kde proste neostane ine ako prepisat init skript k svojmu obrazu? Lebo u systemd tak vies override-nut kazdu sluzbu a autor pre to zvycajne nemusel ani pohnut prstom. Mne to proste pride ze si vyberas medzi systemd, kde az na vynimky v praxi takmer vsetko funguje hoci teoreticky je to hrozny bordel alebo inou init sluzbou, kde sice teoreticky mozes mat vsetko krasne a funkcne, ale v praxi je to hrozny bordel. Mne sa proste nechce cakat dalsich 20 rokov na idealne riesenie napriek tomu, ze sa za poslednych 20 rokov nic nezlepsilo, skor naopak. Mozno je to tym, ze Linux pouzivam aj profesionalne a potrebujem sa zivit tym, co funguje teraz, nie ty co by mohlo fungovat niekedy v buducnosti bez deadline. Myslim, ze ty si na tom pracovne rovnako, takze je to mozno proste iny pristup k veci. Mozno som mensi idealista. Nic v zlom, samozrejme. Budem s tebou nesuhlasit az do krvi, ale som presvedceny o tom, ze treba zastancov za obe strany.
Ide o to, ze vahu toho problemu prenasam z programu kde je ukoncenie child procesov len vedlajsia cinnost nepodstatna pre samotne fungovanie sluzby na init system, kde je korektne (alebo aspon spolahlive) unoncenie sluzby sucastou zakladnej funkcionality.Ukončení procesů, které si sám forknu, není moje starost?
K prikladu s Postgres len tolko, ze kolko takych sluzieb mas v systeme, kde mas aku-taku konfigurovatelnost vs tych, kde proste neostane ine ako prepisat init skript k svojmu obrazu? Lebo u systemd tak vies override-nut kazdu sluzbu a autor pre to zvycajne nemusel ani pohnut prstom.To byl příklad, který měl ilustrovat to, že pro konfiguraci služby nepotřebuju přepsat rc skript. Stačí k tomu běžné prostředky shellu, není k vůli tomu potřeba systemd. A může to být velmi přehledné. Jo, systemd override je dobrá věc a sám to používám pro doplnění některých unit. S tím souhlasím. Ale ono to jde i jinak.
Mne to proste pride ze si vyberas medzi systemd, kde az na vynimky v praxi takmer vsetko funguje hoci teoreticky je to hrozny bordel alebo inou init sluzbou, kde sice teoreticky mozes mat vsetko krasne a funkcne, ale v praxi je to hrozny bordel.Tak bordel. No možná proto dávám příklady z freebsd, jako takový trolling vůči linuxu a jako ukázka, že když se chce, tak v tom žádný bordel být nemusí.
Mozno je to tym, ze Linux pouzivam aj profesionalne a potrebujem sa zivit tym, co funguje teraz, nie ty co by mohlo fungovat niekedy v buducnosti bez deadline.Mě administrace linuxu živí už asi 11 let.
Myslim, ze ty si na tom pracovne rovnako, takze je to mozno proste iny pristup k veci.Spousta věcí, které zde (tj na abclinuxu) píšu, tak vychází z mé praxe. Sice nepíšu přímo o problémech, co mám v práci (to jsem si zakázal), ale snažím se hledat ilustrativní příklady, které to popíšou. Jedním z nich je třeba to, že není dobré maskovat vadné programy, protože ono to nakonec vybublá na povrch někde, kde to klasicky napáchá nejvíc škody. Naopak, na vadné programy je potřeba hlasitě upozorňovat, aby je už nikdo nikde nepoužil. Nebo alespoň ne na mých serverech.
Ukončení procesů, které si sám forknu, není moje starost?Jasne, ze to je tvoja starost, ale ked nieco zlyha, tak je casto hrozne zlozite taku situaciu riesit interne, tam je jednoduchsie to riesit "zvonku" systemom, ktory tu sluzbu spustil. Prakticky priklad: Plex odmieta nastartovat, lebo si naposledy po sebe neupratal pidfile. Keby autori neriesili somariny s PID a spolahli sa na to, ze funkcny init nespusti plex 2x sucasne, tak taky problem nemam.
A může to být velmi přehledné.Moze, ale v praxi vela sluzieb takych nebude. Prax vs. teoria.
Mě administrace linuxu živí už asi 11 let.Detto.
Naopak, na vadné programy je potřeba hlasitě upozorňovat, aby je už nikdo nikde nepoužil.Problem je, ze ja si nie vzdy mozem vybrat ake programy budeme pouzivat. Legacy veci, rozne komercne platformy alebo OSS programy, ktore proste nemaju lepsiu alternativu. Mozem nahlasit bug (a casto tak urobim), ale bezat to musi uz vcera. :-/ Ak to mas inak, tak ti zavidim.
Problem je, ze ja si nie vzdy mozem vybrat ake programy budeme pouzivat.No já jsem naštěstí v pozici, že můžu kecat do návrhu našich systémů po stránce použitých technologií (samozřejmě v rámci možností, nejsem tam sám), takže nakonec adminuju jen to, co jsem si sám nadrobil. Mě baví zkoumat nové technologie a zjišťovat, na co by to šlo použít a snažím se o tom informovat i ostatní. Už jsem to chtěl napsat k předchozímu komentáři, ale adminovat systémy, kde si nemůžu vybírat, bych fakt nechtěl a tu práci bych nedělal. Samozřejmě i u nás se stane, že tam jsou některé systémy poněkud déle, než by se nám líbilo a z poněkud divných komponent, ale to nakonec používám jako argument u dalšího návrhu, že takto tedy ne, pánové.
sieťovo transparentný Wayland-Stacila by radna integrace se SPICE protokolem.
gnome-tweak-tool nebo /etc/systemd/logind.conf
Hodili by sa mi scrollbary, ktoré nemiznú pod kurzorom myši a GTK3 témy ktoré sa nerozbijú každou verziou (alebo jedna konzervatívna oficiálne podporovaná téma v ktorej fungujú scrollbary normálne a ovládzcie prvky nemajú kilometrové rozostupy).