Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Mirek Prýmek

Stran: 1 ... 194 195 [196] 197 198 ... 618
2927
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 15:01:16 »
Prymek tu plakal, ze mu Canonical uz rok neopravil prachobycejny bug v init scriptu.
Ne, neplakal. Prymek si to opravil sam.

2928
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 14:47:34 »
A mimochodem, dá se předpokládat, že systemd bude dál Windowsovatět, takže časem bude služba napojená na nějaký kdovíjaký shim (nějaký spešl adhoc dbus socket nebo jánevímco), takže normálně v terminálu už ani spustit nepůjde.

Jasně, je to argumentace šikmou plochou, ale imho je to legitimní obava. A kdyby se to naplnilo, tak je Linux definitivně v zadeki.

2929
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 14:44:01 »
Takže jsme opět u toho, že problém je, že programátoři systemd jsou neschopní, nikoliv u problému se systemd jako takovým? Platily by vaše námitky úplně stejně, pokud by systemd fungovalo bez chyby a autoři by bugy řešili promptně a rychle?
Ne, problém je primárně v tom, že u systemd jsi upstreamu víc vydán na milost a nemilost. Což je právě ta nejistota, o které pořád mluvím.

2930
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 14:21:18 »
Takže otázka zní, jde systemd poštelovat
A taky shellscripty můžeš poštelovat nezávisle na už běžících službách. Ale zkus si opatchovat PID 1 a spustit pomocí něj novou službu...

2931
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 14:19:36 »
Admin ma mit zaplaceny support, aby to ta firma opravila.
:))) Chtěl bych vidět tu cenu supportu za službu "opravíme vám cokoliv do 24 hodin, abyste do ničeho nemuseli sahat". Jistě by to byla velmi výhodná koupě :)

Bez supportu se vsak vsechno bastli zleva zprava a jsou to pak mnohdy nedokumentovane zmeny, o kterych nikdo nevi.
A proč by o nich nikdo neměl vědět? Admin konfiguruje a konfigurace se řeší konfiguračním managementem, každá změna je zdokumentovaná.

To, že je potřeba něco opravit, přece neznamená, že se sshčknu na server, udělám to ručně a do pěti minut zapomenu.

pokud je nekdo prilis konzervativni
Jistě, "příliš X" je vždycky špatně. Třeba příliš obecná tvrzení jsou úplně k ničemu.

2932
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 14:01:16 »
Já si nemůžu pomoct, ale mně to pořád připadá jak lépe organizovaný nepořádek...
Proč nepořádek? Deklarativní popis služby je jenom nastavení nějakých proměnných. U systemd je to v nějakém .ini formátu, u toho, co jsem ti ukázal, je to v shellovém formátu var=val. V čem ti přijde tak zásadní zlepšení shell->.ini? Mně to přijde jako spíš zhoršení, protože v shell formátu si může - pokud budu chtít - načíst hodnoty libovolným spuštěním příkazu. Třeba wgetem z konfiguračního serveru. U systemd to neuděláš. A kdyby to lidi chtěli, tak se zavede další proměnná "ReadConfigFromHttp", pak se zjistí, že k načítání přes HTTP potřebuješ http knihovnu, tak se http knihovna vloží do binárky PID 1 a následujících deset let se v ní budou nacházet bezpečnostní chyby, umožňující eskalaci na roota. Ale hlavně, že to není nepořádek ;)

Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" a druhý "systemd je blbě napsaný software se spoustou bugů a neschopnýma (nebo všeho schopnýma) vývojářema". S druhým argumentem souhlasím, ale ten první nechápu. Pořád.
Jenže ten první argument zní spíš "proč vrtat do něčeho, co funguje?" - každý admin se na změnu dívá stylem "máme silný argument, proč změnu dělat?" a ne "Máme silný argument, proč změnu NEdělat?"

Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Ale blbost. Buď je ta oprava triviální, nebo si třeba uděláš jiný startup skript bokem. Kařdopádně oboje děláš nějaký configuration managementem (puppet, ansible, salt...), takže je to změna jako každá jiná.

Konkrétní příklad: triviální chyba ve startup skriptu služby v Ubuntu. Ticket bez opravy visí v bugzille rok: https://plus.google.com/+MiroslavPrymek/posts/TAYTy8DHMLq Co myslíš, že má admin udělat? Opravit to a mít stabilní server, nebo rok čekat, až se někdo v Canonicallu rozhoupe?

Tak ono taky záleží na tom, co chceš logovat. Nevím, co je stupidního na tom dělit to pomocí \n, když víš, že v té zprávě ten enter nebude.
Jenže to nikdy nevíš. Logované zprávy typicky citují nějaká vstupní data, kde se \n může objevit i když to nečekáš. A celej logging se ti takovou blbostí může rozesrat. Spolíhat na to, že se ti nikdy v logované zprávě neobjeví BĚŽNÝ znak, je hloupost. Nemluvě o tom, že třeba stacktracy \n vždycky obsahují - a nechceš mít jeden stacktrace rozdělený na dvacet samostatných zpráv. Čili minimálně pro jakýkoliv jazyk, který v případě chyby vyhodí stacktrace je to no-go.

Můžeš si to klidně tisknout v jsonu a pak si to někde v log managementu naparsovat. Popravdě syslog zas tak špatný není, máš tam severitu a to je vlastně asi nejdůležitější. Ale ono je typické takové to "jsem na tomhle systému, z nějakého důvodu mi neběží X, co se stalo". A pokud to něco vypsalo, přes journalctl to snadno najdeš.
Však jo, syslog je v pohodě (když máš nad ním nějaký ten strukturovaný formát). Ale opakuju otázku: jaké strukturované formáty podporuje systemd-logger, pokud aplikace loguje na stderr? Pokud chci jeho logy dostat do rsyslogd, jak mi je předá? Rozdělí podle \n? To ale nechci. Mám možnost ho donutit k jinému chování? Kolik hodin/dní/týdnů to budu zjišťovat? Kolik hacků budu muset udělat, abych dosáhl chování, které už jsem měl odladěné? Kolik hodin/dní/týdnů bude nalezené nové řešení fungovat, než se někdo v upstreamu rozhodne to změnit?

Chápej, tohle jsou otázky, které adminy zajímají. Ne nějakej přiblblej rychlejší boot a "čistější" popisy služeb.

Pokud tím myslíš z důvodu věcí, které systemd přináší, tak teda nesouhlasím, pro mě to teda výrazný krok dopředu je.
No ale ještě jsi neuvedl jedinou věc, která by už dávno nebyla vyřešená i bez systemd a která by zároveň výrazně pálila výrazné množství adminů...

2933
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 12:10:41 »
Prepísat do Haskella.
Alebo do iného hentého s. funkcionára.
To už existuje: https://www.gnu.org/software/shepherd/ :)

2934
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 19. 05. 2016, 10:44:32 »
Já nevím, jak to funguje ve FreebBSD - asi dobře.
Takový typický startskript vypadá takhle:
https://github.com/freebsd/freebsd-ports/blob/master/sysutils/rsyslog8/files/rsyslogd.in
- obsahuje jenom deklarace, všechny výkonné části jsou v shellové "knihovně" - společné všem službám.

Že chceš službu startovat při startu OS řekneš tím, že do /etc/rc.conf přidáš jeden řádek:
Kód: [Vybrat]
rsyslogd_enable="YES"

Pokud bys chtěl třeba umístit někam jinam pidfile, přidáš druhý:
Kód: [Vybrat]
rsyslogd_pidfile="/neco/nekde/rsyslogd.pid"

Stejným stylem si může každá služba definovat svoje vlastní optiony, takže třeba do /etc/rc.conf dáš:
Kód: [Vybrat]
slapd_sockets="/neco/nekde/slapd_socket"

Pořadí spouštění to umí (to jsou ty značky PROVIDE, REQUIRE, BEFORE). Supervidovat služby to neumí (pokud to u některé služby chci, používám supervisord).

Samozřejmě některé služby vyžadují trochu speciální zacházení, takže tam se pak nadefinují vlastní start/stop funkce:
https://github.com/freebsd/freebsd-ports/blob/master/www/nginx/files/nginx.in

Pokud se ta služba chová potřebným způsobem (neforkuje apod.), je to naprosto bezproblémové a rock-solid. Jediné služby, kde jsem zaznamenal větší problémy, jsou erlangové, protože ty při start a stop dělají různé psí kusy a občas funguje blbě restart. Vím to, proto místo restartu dělám start stop, problem solved :)

Pidfily jsou hack, protože to, že to číslo procesu v pidfilu má nějakou relevanci taky je docela náhoda.
Nevím, jaká by v tom měla být náhoda. Klasické inity prostě po službách požadují, aby se daemonizovaly a zachovaly pid. Pokud se daemonizovat neumí, použije se jako obálka ten zmíněný daemon( 8 ).

Ale vůbec nechápu, co je špatného na tom, že
- daemon je normální unixový standardní program, který normálně běží a může klidně logovat na stdout stderr
- zda je ten program živý kontroluje systémový daemon napřímo
- výstupy jsou pěkně tříděny, opatřeny časovou značkou
- konfigurace se provádí deklarativní formou
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)

Ještě drobná poznámka k
a může klidně logovat na stdout stderr
Tobě jako programátorovi to možná přijde jako super nápad, ale je to jedna z nejhorších věcí, co se dá s logováním udělat. Std{out|err} je totiž stream. A do logu potřebuješ dostat záznamy. Takže musíš do toho stdxxx emitovat nějaký strukturovaný formát, který jde na záznamy rozdělit (nejstupidnější řešení je rozdělit ho pomocí \n). Jaké strukturované formáty umí systemd po stdxxx přijímat? Co když budu chtít použít jiný? Tohle já třeba nevím. A musel bych to studovat, zatímco u současných řešení už to mám nastudované a vyřešené. A tohle je přesně ono - pro adminy je to regres - abys dosáhl funkcionality, kterou máš už teď, musíš znovu investovat práci a ladění a i tak budeš žít v nejistotě, jak se to zachová v situacích, které jsi neotestoval. A tohle všechno, aby ses dostal do stavu stejného (ne lepšího) než jsi měl předtím.

Mě to nějak připadá, jako dohadovat se s vývojářem PHP, že přechod na lepší jazyk mu přinese nic než spoustu práce a nejistoty, protože s PHP špagetama už se sžil, vychytal si jejich vlastnosti a žádné úplně zásadní nevýhody nemají. [...] A na argumenty typu "tohle umím, proč bych měl přecházet na něco jiného" začínám být trochu alergický.
Admini jsou přirozeně konzervativní. Každá změna je ohrožení stability. I pokud je to změna vyloženě k lepšímu, pořád je to pro admina nepříjemné. A pokud je to změna, která nic nepřináší, ale zároveň je vysoce riziková, je to prostě enormní osina v ...

Srovnání s PHP je mimo, protože tam předpokládáš vysoký kvalitativní skok (druhý jazyk je třeba daleko produktivnější). To při téhle změně prostě neplatí. Z hlediska admina je to změna pro změnu "aby to bylo čistější".

2935
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 18. 05. 2016, 21:43:36 »
P.S.
žádné úplně zásadní nevýhody nemají.
to, že init skripty ve spoustě linuxových distribucí jsou k zblití a často nefungují, to je jiná kapitola. Zprasit jde samozřejmě všechno. Ale taky to jde napsat inteligentně (viz třeba ty init skripty ve FreeBSD - většinou na pár řádků, čistě "deklarativní").

2936
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 18. 05. 2016, 21:42:06 »
Součástí std. instalace to není, možná jako nějaký balíček.
Ale je (mluvím o FreeBSD):
Kód: [Vybrat]
# which daemon
/usr/sbin/daemon

Třeba proto, že řešení před PIDfily vypadá dost jako hack.
Tak hack, je to prostě určitý druh handlu, čemu konkrétně to vadí? Přijde ti třeba jako hack, že tmux má v /tmp nějaký svůj socket? Nebylo by lepší se na něj připojovat přes DBUS? :)

Integrace s cluster-warem funguje v pohodě. Závislosti fungují. Věci je vhodné řešit "systémově" a nikoliv nějakým hackem do init.d. Ale hlavně - tady si pořád všichni stěžují a já jsem fakt nepochopil na co.
Líbí se ti třeba, jak systémově řeší služby Windows? Co můžeš mít proti? Závislosti fungují, logování taky. Paráda, ne?

Různí lidi si stěžují na různé věci, ale admini nejspíš na to, že jim to nepřinese nic než spoustu práce a nejistoty. Protože se starými inity se už sžili, vychytali si jejich vlastnosti a žádné úplně zásadní nevýhody nemají.

2937
Vývoj / Re:Má Haskell budoucnost?
« kdy: 18. 05. 2016, 14:56:45 »
Bude k tomu nějaký materiál?
Myslíš třeba jako kilo koksu? :)

Je to první setkání, asi spíš jenom pokec.

2938
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 18. 05. 2016, 13:19:53 »
Daemonizace v unixu je prostě tristní a jsem konečně rád, že to prostě nemusím programovat. Žádný double-forky a podobně, řešení čehokoliv - napíšu unit soubor a je to. Super. Problém vyřešen.
Nevím jak v různých distribucích Linuxu, ale ve FreeBSD je https://www.freebsd.org/cgi/man.cgi?query=daemon&sektion=8 který to řeší úplně v pohodě.

Taky se na to dá dívat opačně: všechny serverové aplikace daemon mód už mají, takže opět systemd nic nového nepřináší. Maximálně může ušetřit práci u zbrusu nových serverových aplikací, ale ty se dají úplně v pohodě řešit právě nějakou obdobou daemon(8). Takže opět ta samá otázka: "a stojí to za to?!" ;)

2939
Odkladiště / Re:Proč jsou všichni proti systemd?
« kdy: 18. 05. 2016, 13:11:55 »
Takze je v dusledku lautr jedno, jestli je na serveru initd nebo systemd.
Pokud je někde situace taková jaká píšeš (ne všude je), tak pak systemd už vůbec nic nepřináší, jenom způsobuje riziko a nejistotu. Takže v takové situaci to vůbec jedno není.

2940
Vývoj / Re:Má Haskell budoucnost?
« kdy: 18. 05. 2016, 10:14:20 »
... a nebyl by ochoten mi to někdo teda vysvětlit? Když už jsme u toho, tak by mě to docela zajímalo. Monoid je asociativní - monoid je operace >>=. Operace >>= je řetězení operací za sebe. V monadu to znamená řetězení instrukcí za sebe (<> taky může počítat maximum). Takže se na to taky dá dívat jako na List, který interpret pomocí fold (>>=) interpretuje. Nebo nedá?

A endofunktor v té definici teda znamená co?
Docela dobrý vysvětlení máš tady: http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-issue ale podle mě nemá smysl si s tím lámat hlavu. Pokud tě aspoň úvod do teorie kategorií zajímá, tak bych vřele doporučil http://www1.eafit.edu.co/asr/pubs/others/cain-screen.pdf - je to nejsrozumitelnější popis pro programátora, jakej jsem zatím viděl. Už kolem strany 30 by ti to mělo začít být jasný a v kapitole 6.2.1 je to pak úplně explcitně.

Stran: 1 ... 194 195 [196] 197 198 ... 618