Vlákno názorů k článku
Systemd po odhlášení zabije všechny procesy na pozadí
od Tomaskom - https://github.com/tmux/tmux/issues/428
Vyvojar systemd pozaduje po vyvojarich tmuxu, aby pridali...
-
https://github.com/tmux/tmux/issues/428
Vyvojar systemd pozaduje po vyvojarich tmuxu, aby pridali kod pro podporu systemd...
A navrhuje k tomu pouzit dbus :-D -
j (neregistrovaný)
Se divte ... onehda sem rval na jednoho podobnyho idiota, kdyz sem u zakose patchul ssytem, a vsechno prestalo fungovat ... protoze oni se rozhodli, ze misto param=hodnota se bude ponovu pouzivat hodnota=param. Prej aby to bylo konzistentni se zbytkem aplikace. Ze na to zakaznici maji napojeny dalsi svoje veci (za miliony) jim vubec nedoslo ... nakonec sem je dokopal (skoro doslova) k tomu, ze deklarovali jeste verzi, a kdyz nebyla, tak se to chovalo postaru.
-
x (neregistrovaný)
A vyvojari tmux, kteri jsou v OpenBSD mu reknou svoje a poslou ho nekde :D Jednak uz ted je Gnome vzdy v OpenBSD drive nez v Linuxu, diky www.mtier.org , www.esdenera.com a dalsim (DuckDuckGo, Google, Facebook, Microsoft, Ebay atd. kteri davaji vice a vice penez do xBSD) a druhak maji davno sve BSD wrappery pro ty systemd srance.
Ono teoreticka sance tu je, ze by kod pro podporu systemd se mohl objevit v OpenBSD. Ma to par jednoduchych podminek.
1) Kod musi splnovat naroky na bezpecnost z OpenBSD, ne tu parodii z Linuxu
2) Kod musi byt kvalitni, prehledny a dokumentovany a ne to co je v systemd a jinde v Linuxu co vypada jak kdyz to prase pise certovym kopytem :D
3) Musi to vyvojar poradne zdokumentovat a man stranka podle toho musi vypadat a taky to musi jit pres mandoc. Jak vidim co vypousti RedHat a ty kecy o tom, ze kdyz chce nekdo dokumentaci, tak at si precte zdrojak, tak se nebojim toho, ze by v brzke dobe neco ze systemd bylo v Linuxu
4) Domrvit screen jeste vice nez je si na Linuxu porad muzete a zkusit ziskat pozici tmux :D -
Lol Phirae (neregistrovaný)
Jo, tak nějak poslali, zato maintainer z Debianu tam chtěl ochotně přidat závislost tmux-u na systemd. Ta distribuce je ztracená, nejvyšší čas opustit potápějící se loď.
-
j (neregistrovaný)
Co bys ty tatareh chtel resit? Ychtylovy podobnymu tobe negunguje rozjebany gnome, a proto chce po systemd aby to sestrelovalo ... a kvuli tomu maj vsichni predelavat vsechno, co funguje 30let? Proc by meli, oni nic rozbityho nemaj. A pridavat dalsi zavislosti == dalsi bugy.
Presne jako ve widlich. Misto textaku v XP do kteryho staci pripsat radek a je dalsi polozka v bootu ... mame od vist peknou binarku ... ke ktery M$ nejak opomel dodat tu GUI appku (dyk prece ve widlich se da vsechno delat z GUI ...) a tak kdyz nekdo chce zmenit boot, potrebuje si na to sosnout nejakej externi, dost pravdepodobne zavirovanej tool. Bomba.
I kdyby tam totiz tu zavislost pridali a rozbili tak vlastni SW, tak to stejne fungovat nebude, protoze ti kreteni za tyden zmenej rozhrani.
-
Lol Phirae (neregistrovaný)
Na tej issue inac je krasne demonstrovane ako banda anti-systemd riesi" problem. Miesto technickych veci spamovanie threadu
Problém je vyřešen zde. Tečka. Konec technické diskuse. LP a jeho banda análních řiťolezců žádný problém nevyřešila, naopak spoustu věcí rozbila a jako vrchol má tu drzost chtít tu svojí sračku nacpat do dalších projektů, kde vůbec není potřebná.
-
Lol Phirae (neregistrovaný)
Komentoval jsem "žádost" jakéhosi Poetteringova poskoka, aby vývojáři tmuxu nacpali do jejich projektu kód závisející na DBUSu, potažmo systemd. To je totiž přesně ten styl celé té grupy mlamojů okolo LP - oni rozbijou léta fungující věc, a pak chtějí po jiných, aby následky opravovali. Tenhle jejich modus operandi je neměnný již léta. jak si všimnul mj. Linus T..
-
Sten (neregistrovaný)
Co je na té žádosti špatného? Stejně jako ty píšeš žádosti, aby ostatní nepoužívali systemd, vývojáři Red Hatu a Debianu píší žádosti o podporu nových vlastností.
Všiml jsem si tam ale jednoho zásadního rozdílu oproti tvým žádostem. Nikdo tam nenadává vývojářům, že jsou blbci, ale snaží se přijít na nějaké rozumné řešení. Jak tam psal kentfrederic, POSIX tohle vůbec neřeší (a systemd rozhodně není jediný, kdo zabíjí procesy při odhlášení, MacOS X to dělá taky), takže nezabývá než vymyslet nějaké vlastní řešení. A dobrali se toho, že by to tmux měl dělat přes PAM, protože to neřeší jen problém se systemd, ale i problémy s SSH a GPG agenty. S čímž vývojáři systemd neměli problém, nikoho nenutí, aby to muselo být jedním konkrétním způsobem.
-
Lol Phirae (neregistrovaný)
Co je na té žádosti špatného?
To je vážně míněný dotaz? Kterou část z toho, že nový dbus rozbil Gnome -> jeho poskok si šel postěžovat -> LP vymyslel "řešení", že bude při odhlášení defaultně vraždit všechny procesy a přitom rozbil desítky let zcela bez problémů fungující věci (tmux/screen, mj.), potřebuješ ještě dovysvětlit? Takže výsledek je ten, že mlamojové kolem systemd rozbili hned několik věcí, vopravili velký hovno a ještě maj tu drzost "žádat" oběti jejich sabotážní činnosti, ať se s tím smíří a zařídí se podle toho? To je neuvěřitelný chování, tohle.
-
Lol Phirae (neregistrovaný)
Změnit fungování a rozbít jsou dvě rozdílné věci, což ovšem církev LP již léta odmítá chápat. Oni to navíc rozbíjejí úmyslně a zcela nesmyslně. A vyžadují po ostatních, aby následky jejich neumětelské činnosti neustále napravovali. A v rámci téhle sabotážní činnosti jako infekční chorobu šíří po nejrůznějších projektech závislost na té jejich sračce.
Tož asi tak. Další debata zjevně nebude produktivní.
-
Sten (neregistrovaný)
Změnou fungování se téměř vždy něco rozbije. V tomhle případě jde o nestandardní chování Linuxu při odhlášení, které třeba na certifikovaném UNIXu MacOS X (či kdysi certifikovaných Windows) není (a kde tmux taky nepřežije). Navíc problémy s tím nemá jen systemd, ale i SSH a GPG agenti, pam_ecryptfs a nejspíš mnoho dalšího software, který závisí na sezeních. Že to dosud nikdo neřešil, neznamená, že by bylo špatné to chtít konečně vyřešit, pouze že to dosud nikoho nepálilo tolik, aby tomu věnoval úsilí. Autoři tmuxu mají nakonec taky názor, že by to tmux měl řešit, jen se liší tím, jak by se to mělo udělat (nepřímo přes PAM místo přímo v systemd).
Ano, debata s tebou zjevně nemůže být produktivní. Poettering ve tvých představách zřejmě nutí správce ostatních distribucí přecházet na systemd unášeních jejich dětí a stejně tak autory dalších projektů nutí začleňovat podporu systemd umisťováním bomb pod sedadla jejich aut (pominu teď to, že je v té „sabotážní činnosti“ velmi nedůkladný, když mu stačí podpora PAM, který funguje i se sysvinitem a upstartem). Nedovedu si totiž představit, jakým jiným způsobem lze ve světě open source software někoho nutit něco implementovat. Dobrá zpráva pro tebe je, že taková paranoia se dá celkem dobře léčit, když se stavíš na adrese Ústavní 7, Praha 8. Anebo můžeš místo pomlouvání lidí, kteří něco dělají, také začít něco dělat a přidat se do vývoje Devuanu. Konkurence odjakživa žene vývoj kupředu.
-
MP (neregistrovaný)
Problem je v tom, ze neexistuje moznost, jak otestovat takovehle zmeny proti kazdemu SW, zvlast v tak rozsahlem svete utilit a buhviceho. A cekat na vsechny, az to opravi, tak to by se taky nemuselo vubec dockat. Navic, musi byt vuci cemu testovat opravy. Tohle je zacarovany kruh, ktery se bez rozbiti neceho neda vyresit.
-
dustin (neregistrovaný)
====
A cekat na vsechny, az to opravi, tak to by se taky nemuselo vubec dockat.
====A nebo tu změnu vůbec nebudu dělat. Např. nevidím důvod, proč by mi po odhlášení měl systém shodit všechny procesy, které jsem si při přihlášení nastartoval. Každá učebnice linuxu popisuje, jak spustit proces tak, aby přežil zavření terminálu/odhlášení (nohup, přesměrování in/out atd.). Přestanu tohle např. na debianu stable po upgradu platit?
-
Sten (neregistrovaný)
Zatím je to v Debianu vypnuté, dokud se tohle nevyřeší. screen a tmux by měly používat PAM sessiony, čímž tohle (a další podobné problémy) vyřeší. U nohup zatím není rozhodnuto, ale třeba v MacOS X také nefunguje. To, že se k němu nedá opětovně připojit či taková sezení vůbec vypsat, se tam bere jako zásadní nedostatek, kvůli kterému stálo za to jej zabít. Podobně byl na Linuxu používán a následně zabit třeba finger (schválně kolík systemd-haterů vůbec tuší, k čemu sloužil) a dnes po něm už nikdo ani neštěkne, protože všichni jsou zvyklí na PAM.
-
dustin (neregistrovaný)
Tak užitečnost fingeru a nohupu je asi trošku jiná, ne?
K nohupu se nepotřebuju připojovat. Prostě stačí, že ten proces běží dál. Potřebuju-li se připojovat, vyřeším si to screenou/tmuxem.
Kolik na debianích strojích běží legacy skriptů používajících nohup? Ty najednou přestanou fungovat? K čemu je taková změna dobrá?
-
Sten (neregistrovaný)
finger se dřív používal pro zjišťování informací o uživatelích. Taky na tom záviselo spousta skriptů a aplikací, obzvlášť v sítích s centrální správou uživatelů. Dneska už ani není součást standardní instalace, protože byl plně nahrazen getent. (Omlouvám se za trochu zmatení. Za tu změnu nemůže PAM, ale NSS.)
-
> Problem je v tom, ze neexistuje moznost, jak otestovat takovehle zmeny proti kazdemu SW, zvlast v tak rozsahlem svete utilit a buhviceho.
Ale no tak. Ak tomu typkovy nebolo *okamzite* jasne, ze takato zmena rozbije stovky cudzich rieseni, nemali by ho pustat ku klavesnici. A radsej ani k ostrim predmetom.
Skutocnost je ale taka, ze jemu to jasne bolo a nic testovat nepotreboval. Proste usudil, ze sa svet prisposobi jemu.
-
No to je zas radost číst... :(
Já prostě nedokážu pochopit, jaktože někdo, kdo píše zcela klíčovou komponentu OS (druhou hned po kernelu) a je za to placený mezinárodní korporací může takovýhle věci řešit až jako bugreporty. To jako lidem kolem systemd nedošlo, že asi lidi budou chtít používat tmux?! Proč neexistuje předem tabulka "tyhle typy sessions budou, mají tyhle a tyhle záludnosti a budeme je řešit takhle a takhle"? Fakt mi to hlava nebere, jak můžou lidi z RedHatu pracovat tak, že úplně libovolně cokoli rozbijí a až se někdo ozve, tak hledají řešení.
