Zápisky z LinuxAltu (diskuse)

[xkucf03]

Klidně body, ale nemuselo by to být zrovna v <pre/>

[Michal Kubeček]

Souhlasím, v kombinaci s těmi kilometrovými řádky je to děs.

[Saljack]

Přesně vyšoupni to z toho pre ať se to dá normálně přečíst.

[Jendа]

Hmm, čekal jsem, že na širším viewportu než 800 px na notebooku to bude vypadat líp. Nějaký tip na parsovátko, co z toho vyrobí zanořený <ul> seznam, nebo si mám něco ubastlit?

[Jendа]

Zkusil jsem to prohnat parserem z DokuWiki, snad je to lepší.

[xkucf03]

jj, o hodně lepší, díky (no, ale už jsem to vlastně přelouskal v tom <pre/>, takže znova to číst nebudu ). Jinak na tyhle věci používám Markdown (BTW: lze v něm psát i komentáře na KP )

[Bedňa]

bite my shiny metal ass

[Michal Kubeček]

No, podle toho, co jsem zatím viděl, je systemd zatím jedna velká katastrofa a bude ještě zatraceně dlouho trvat, než to aspoň nebude horší. Co se týká toho, jestli to vůbec někdy bude lepší, jsem dost skeptický - (možná) pár sekund při bootu rozhodně nevynahradí komplikovanější konfiguraci, diagnostiku a ladění chyb.

[pavlix]

Konfigurace (ve smyslu unit files) mi už teď přijde přehlednější než initskripty. Pro těch „možná pár sekund“ doporučuju zhlédnout přednášku o systemd z ELCE, pokud už jsou k dispozici videa.

[Michal Kubeček]

Video není potřeba, měl jsem tu (pochybnou) čest zkusit si to na reálném systému. Nějaké zrychlení tam možná bylo, ale rozhodně nestálo za ty obrovské problémy. I když… to by nejspíš nestálo ani v případě, že by systém bootoval v nulovém čase. Jediné štěstí je, že v OpenSuSE 12.1 aspoň částečně zvítězil zdravý rozum a jde to celkem snadno přepnout na klasický System V init.

[Jendа]

A co konkrétně za problémy jsi tam měl? Mně to z té přednášky přišlo jako celkem dobrý nápad, ale ještě jsem to na svém systému nezkoušel.

[Michal Kubeček]

Třeba takové, že při startu bez zjevného důvodu nenaběhne KDM a když už ho spustím ručně, stejně selže inicializace KDE desktopu. A spousty dalších drobných radostí, kdy tu a tam zjistím, že něco nenastartovalo ve správném pořadí nebo dokonce nenastartovalo vůbec. Nebo třeba systém vytuhne během ukončování.

Mně se moc nelíbí ani ta idea. Před rychlostí startu systému upřednostním funkčnost, spolehlivost a snadnou udržovatelnost a diagnostiku. Tohle všechno bohužel systemd nenabízí. Funkčnost se snad časem doladit podaří, možná i spolehlivost, ale co se týká těch zbylých dvou, ty holt bohužel padnou za oběť popularitě závodů v bootování. :-( Už teď se děsím dne, kdy se tohle neštěstí dostane do SLE.

[michich]

S diagnostikou problémů to bylo špatné ve Fedoře 15, protože chybový výstup služeb šel často do /dev/null. Ve Fedoře 16 jde už ve výchozím nastavení stdout a stderr služeb do syslogu (máme tam sice chybku, že jiné typu unitů než service svůj výstup směrují blbě, ale to spravíme updatem). To logování v systemd je dokonce uděláno tak, že do syslogu se dostane i to, co se vygeneruje před spuštěním rsyslog. Třeba i záznam z provedeného fsck. To jsme nemívali.

Já už jsem si na přehled, který mi poskytuje systemctl, zvyknul tak, že si neumím představit být bez toho. Kvůli tomu všemu si myslím, že diagnostika bude nakonec lepší bež kdykoliv předtím.

systemd rozhodně není jen o závodech v bootování a je škoda, že takový dojem vzniknul. Asi to Lennart ze začátku příliš zdůrazňoval.

[Michal Kubeček]

Já jsem bohužel ještě žádný jiný přínos neviděl. Tedy abych se vyjádřil přesně: viděl jsem seznam pár dalších věcí, které sice byly prezentovány jako výhody, ale jejich přínos pro mne je v lepším případě nulový.

[Jezekus]

Celkem s Vami souhlasim, snazil jsem se na to zvyknout (Fedora 15), ale stale davam mnohem radeji prednost puvodnimu init systemu, ktery jiz behem bootovani predal (me jako uzivateli) jednoznacnou informaci o tom jak na tom jsou dane sluzby. Toto bohuzel s prichodem systemd zaniklo, nepreberna sbirka textu pri startu, kde se micha x desitek sluzeb se svymi vypisy starting, started...
Je mozne, ze to bude nekdy v budoucnu prinos bohuzel v soucasne situaci mi to prijde velice neohrabane a slozite na spravu.

[Radek Hladik]

Viz např. můj dotaz, kde ovšem musím říct, že hodně bylo opravdu způsobenou tou beta verzi. Ovšem bugy považuju za poměrně zásadní.

Dále mi při startu chybí můj oblíbený seznam OK, což chápu, že je čistě subjektivní věc, ale vypovídá to něco o návrhu celého systému. Jak jsem se učil ve škole, když děláte nový systém, není moudré dávat pryč věci, na které jsou lidi zvyklí. V současné chvíli je start směsicí všemožných výpisů, které jsou všemožně propletené. A přitom by stačilo, aby systemd místo "Started postfix" napsal "Start of postfix [ OK ]".

Co se teoretických námitek týče, už se to tu řešilo, např zde. Mně osobně se nelíbí už ani ta idea, ani přístup autora, vlastně jediné, co se mi líbí je ta možnost mít lepší přehled o službách a co k nim patří. Což je víceméně věc cgroups.

Závěrem je vhodné podotknout, že ve Fedoře je možné nahradit systemd a původní upstart, ikdyž to dá práci. Ostatně pokud se systemd nějak rychle nezlepší, plánuju to udělat, protože na většině strojů stejně spouštím tak málo služeb, že si ty init skripty zvládnu udžovat sám, když bude potřeba

[Radek Hladik]

Myslel jsem samozřejme "nahradit systemd původním upstartem", ale nějak jsem se v tom zamotal

[petr_p]

Nechci vám kazit radost, ale do Fedory 16 se řada služeb přepsala pro systemd a podpora pro systemv se zahodila. Takže si sice upstart nainstalujete, ale nebude mít co spustit.

[maleprase]

tak par rozumnych lidi podporu pro sysv nezahodila ale pridala podbalicek -sysvinit, namatkou openssh, rsyslog, lvm2, ...

takze upstart se da nainstalovat, je i co spustit, akorat je potreba vypnout selinux, protoze dracut uz inicializaci neprovadi a samotny upstart pro to podporu nema

[pavlix]

akorat je potreba vypnout selinux

Tomu říkám řešení :).

[maleprase]

tak jde to i se selinuxem, jen to chce trochu vic snahy. jestli je vubec nekdo kdo by to vyuzil, muzu to rozepsat.

[Radek Hladik]

protože na většině strojů stejně spouštím tak málo služeb, že si ty init skripty zvládnu udžovat sám, když bude potřeba

Osobně si myslím, že syntaktický rozbor této věty (pro hnidopichy věty vedlejší) by neměl být zas až tak těžký. leč pro jistotu ho přikládám i s podrobnějším vysvětlením.

Každopádně zamýšlené vyznění je takové, že při malém počtu služeb, které na většině strojů používám (cca 15-20 rc.skriptů, z toho 5 mých vlastních), je možné si ty skripty udržet funkční svépomocí. Fedora 14 jich je pořád plná (což je vzhledem k přístupu Lennarta Poetteringa s podivem), pro další Fedory některé balíčky obsahují init skripty. Dále máme další různé distribuce, které nejsou v tomto tak pokrokové. A samozřejmě máme různé editory, kterými je možné skripty upravovat a protože se většina skriptů skládá ze zavolání binárky s nějakými parametry a případně killem podle PID, tak to zas takové zlo není. Také nesmíme zapomínat na autory programů, kteří různé skripty občas distribuují se svými programy. Někteří možná nebudou žhaví do přepisování svých démonů (přestože to Lennart očekává), takže si například dají pozor, aby jejich init skripty pod upstartem fungovaly. Koneckonců to, že Fedora už nepoužívá upstart, neznamená, že upstart už nepoužívá nikdo.

Jen pro zajímavost jsem si porovnal init skript pro SSH z Fedory Core 4 a z Fedory 14, což je řekněme při frekvenci dvě Fedory za rok 5 let rozdíl. A pravdou je, že se liší poměrně hodně, ale vše jsou to věci, které se týkají věcí okolo Fedory (rhgb vs plymouth,rozdělení generování klíčů na dvě části, přidání možnosti force-reload,...) nikoliv však vlastního spuštění ssh. A upřímně řečeno, dokud mne systemd nepřesvědčí, tak klidně budu mít 15-ti řádkové initskripty ve tvaru: spusť binárku, zabij PID...

Co je výrazně horší, jsou systémové skripty (především rc.sys). Ovšem i zde toho požaduju poměrně málo, ve F16 je pořád ještě funkční balíček, takže i tam to nějakou dobu vydrží.

Osobně bych si troufnul prorokovat, že chleba se začne lámat tak u Fedory 20-21, kdy doufám buď bude systemd na smetišti dějin (aka smetištěd ) nebo bude rozumně použitelný.

A taky jsem zvědavý, co na to RHEL, protože upřímně řečeno, dostat v komerční verzi Linuxu systemd v současné podobě, tak nebudu moc spokojený zákazník...

[Michal Kubeček]

A taky jsem zvědavý, co na to RHEL, protože upřímně řečeno, dostat v komerční verzi Linuxu systemd v současné podobě, tak nebudu moc spokojený zákazník...

IMHO to je tak, že do RHEL 6 ho nikdo cpát nebude a RHEL 7 je ještě daleko. A právě proto, aby se to do RHEL 7 stihlo odladit (nebo zavrḧnout), ho teď natlačili do Fedory. (Kvíz: najděte pět rozdílů oproti situaci se SLES 11/12 a OpenSuSE… nebo aspoň jeden.)

[pavlix]

Video není potřeba

Však jasné, někteří lidé sledují aktuální dění a vzdělávají se, jiní ne. Takže díky za to, že nám s té první skupiny neděláš konkurenci :).

[=^..^= AmigaPower®]

Ty jsi ztracenej kámo, jediná klika pro další generace je, že se fakt asi kvůli tomu ani nerozmnožíš....

[xkucf03]

WTF?

[=^..^= AmigaPower®]

...nic, spi...

[xkucf03]

Proč je největším škůdcem akademická sféra?

[Mrkva]

Dovolil bych si tipnout: koleje.

[pools]

http://info.siliconhill.cz/2011/10/klub-silicon-hill-vs-protipiratska-unie-roska-%e2%80%9ctahnete-na-strahove-vladne-warez%e2%80%9d/

[Vašek Lorenc]

Tipuji, že je to kvůli tomu, že tam kupa lidí má neaktualizovaná Windows, často nenastavené antiviry nebo osobní firewally, někde něco pochytají a pak to donesou na koleje/přednášky, kde se to rozjede.. a konektivita univerzit je v řádu gigabitů, takže to občas může menším firmám pěkně zatopit.

[Jendа]

//je tam záznam :)

Říkal, že spousta studentů hledá seberealizaci v dostávání se do cizích systémů.

[ʚĭɞ 🍉]

Některé fotky snad ani nebudu publikovat.

[ʚĭɞ 🍉]

Moje fotky.

[Bedňa]

Fakt ostré

[ʚĭɞ 🍉]

Zkoušel jsi někdy za špatných světelných podmínek fotit sklem s horší světelností a pokud možno bez blesku... lidi na dálku?

Navíc jsem se moc nezabýval vyvoláváním.

[kralyk z abclinuxu]

Tak ta přednáška o SDR musela bejt hodně zajímavá... Škoda, že jsou veškerý trxy stále tak drahý. Jestliže to USRP stojí $700+ tak to už si skoro člověk může koupit některý FT-čko, ačkoli teda s tím se asi nedaj dělat takový bejkárny. Zajímalo by mě porovnání kvality, případně komfortu RX/TX na USRP vs na FT-čku nebo jiným běžným trxu.

[Ondrej 'SanTiago' Zajicek]

Jeste je zajimave low-cost reseni pouzit jako vstup nejakou videokartu s Bt878, ta ma z nejakych duvodu v sobe A/D prevodnik se samplovaci frekvenci 448 kHz. Proti USRP nic moc, ale zas lepsi nez zvukovka. viz.

[PetrHL]

aby Fedora byla použitelné pro radioamatéry

Ale o CQRLOGu ani zmínka . Nedovedu si představit použití pro radioamatéry bez pořádného staničního deníku.

[maleprase]

2006 Upstart specifikuje přes LSB standardní hlavičku init skriptů; zparsují se hlavičky, vyrobí se strom závislostí mezi službami (sshd potřebuje síť) a spustí se to paralelně

upstart zadne LSB hlavicky neparsuje. kompatibilita upstart a sysvinit skriptu je zajistena fakticky pouze ulohou rc (/etc/init/rc.conf) ktera pousti skript "/etc/rc.d/rc $RUNLEVEL"

naopak systemd se o kompatibilitu se SysV init skriptama pokousi tim ze z kazdeho initskriptu vytvori meta .service se stejnym jmenem a na zaklade LSB hlavicek vygeneruje zavislosti.

[michich]

# snažte se neprasit konfiguraci démonů do /etc/(default,sysconfig), ale do unit souborů, aby to bylo distro-wide

To je nedorozumění. Konfigurace démonů opravdu nepatří do souborů v /etc/(default,sysconfig), kde si každá distribuce vymýšlí vlastní formát, ale do unit souborů taky ne. Démon má idálně sám načítat svůj konfigurační soubor v /etc, použitelný v každé distribuci. Neměl by spoléhat na to, že mu nějaký startovací skript všechny možné volby předá na příkazové řádce.

[Michal Kubeček]

Obávám se, že to je přesně ten způsob uvažování, který u vývojářů ostatních unixových systémů (a upstreamových projektů) vyvolává nepřátelské postoje k Linuxu. Tedy konkrétně přístup, že my jsme si tady něco vymysleli, tak je to jedině správně a všechny projekty jsou povinny se bez řečí okamžitě přizpůsobit a zahodit to, jak to dělaly dosud (třeba klasická "démonizace" nebo předávání parametrů na příkazové řádce); a to včetně těch, které nemají Linux jako hlavní cílovou platformu, a těch, které nemají Linux vůbec jako cílovou platformu.

[michich]

Ne, to není povinnost. Jenom dobré doporučení.

[pavlix]

Obávám se, že to je přesně ten způsob uvažování, který u vývojářů ostatních unixových systémů

Obávám se, že v případě těch vývojářů, kteří s tím mají nějaký problém, je to spíš jejich problém než kohokoli jiného.