Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »
29.4.2011 17:31
stativ | skóre: 54
| blog: SlaNé roury
29.4.2011 17:59
michich | skóre: 51
| blog: ohrivane_parky
Ale vážně, ač se mi některé myšlenky líbí, tak opravdu doufám, že bude nějaký hezký a jendoduchý návod, jak naprostou většinu toho vypnout, nejlépe včetně celého systemd. Hlavně mi jde o servery, na desktopech to vzal čert. Ale server bootuje jednou za čas a moc se líbí, když mám jeden velkej init skript na začátek a pak spoustu malých pro jednotlivé služby. A hlavní výhody?:
* Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí
* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim
* Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.
Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...
Příklad za všechny: Kdysi jsme měli ve firmě po různých zákaznících roztroušeno docela dost serverů. A přes veškeré snahy se ty servery občas restartovaly a pak se zarazily na potřebě fsck. Z různých důvodů jsme vybrali řešení, kde server, který by rád kontrolu disku, nahodí síť, spustí ssh a pošle maíl. Admin se přihlásí, opraví a voila.
Půjde toto udělat v systemd? Jak to bude složité? Jak moc se do toho bude člověk muset hackovat? V normálním sysinitu si člověk našel všechny výskyty fsck v jednom skriptu a v případě, že to selhalo, tak přidal jeden řádek s něcím jako /sbin/emergency. Pak už šlo jen o to, odladit ten skript tak, aby vše fungovalo s read-only rootem, atd... Pointa je v tom, že člověku stačilo ani ne 5 minut na vyřešení té části ohledně initu a nemusel být žádný systemd hacker. Samozřejmě, že moje řešení mělo problémy při update těch systémových skriptů, ale s diff+patch to byl detail.
30.4.2011 08:38
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí
Nepovedal by som. Mám gentoo, kedysi som začal používať openrc a následne som zapol aj paralelné spustenie. Aj na jednojadrovom stroji to začalo bootovať zhruba 2x rýchlejšie. Výhoda paralelného štartu je v tom, že zatiaľ čo sa systém hrabe na disku služby, ktoré už majú načítané dáta sa môžu pekne počas hrabania spúšťať.
Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim
Mám gentoo a mám závislosti medzi službami. SSH mi ale rozhodne nespúšťa ani nezastavuje sieť. Závislosti sú hlavne medzi službami, ktoré potrbujú k svojmu behu iné služby. Väčšinou je to v celku príjemná pre užívateľa transparentná záležitosť, postačí do init skriptu napísať čo sa má pred ním spustiť a o všetko sa postará systém. Nemusím mať tak nastavených pri boote milion rôznych služieb, ale len tie, ktoré fakt potrebujem a zvyšok sa vďaka závislostiam natiahne samo.
Inak v systemd nie je taký problém používať pri spustení bash skripty ako teraz.
30.4.2011 14:05
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Ale i na notebooku mi celý linux bootuje asi 15 vteřin, což považuju za krásný čas.
Neverím. Pod 15s mi nenaštartuje ani len sieť a nie ešte hrúzy ako X.
2.5.2011 08:25
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
2.5.2011 08:51
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Shoda jmen to není a díky za pochvalu.
"
30.4.2011 10:26
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Vidím to hodně podobně.
Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí
Má to i mít nějaký readahead, takže je klidně možné, že jedno vlákno bude přednačítat data spouštěných služeb, ty by potom skutečně mohli startovat paralelně a o něco rychleji. Ovšem nejsem si jist, jestli celá tahle námaha za to opravdu stojí, u serveru, který se rebootuje jednou za update.
Mám teď pokusně rozjetý Debian 6, kde je taky nějaké paralelní spouštění a už jen takový výpis spouštěných služeb při startu systému je dost zmatený (některé výpisy jsou přes sebe). Což se dá samozřejmě ošetřit, ale opět je to jen zbytečná práce navíc.
Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim
IMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla). Při vypnutí ssh bych očekával, že se nic dalšího nevypne. I když i toto je diskutabilní. Ne vždy, když zapínám nějakou síťovou službu u toho chci zapínat ještě síť (ve smyslu nastavovat IP z nějaké konfigurace).
Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.
Na tohle jsem reagoval úplně stejně . Spousta služeb se startuje poměrně dlouho a startovat je až ve chvíli, kdy se tam připojí klienti ničemu nepomůže, naopak, ti první klienti budu čekat, až se to nastartuje. Kdyby ty služby již běželi, tak to mají hned.
To je právě ono. Já chápu, že na desktopu a spol to může být zajímavé. Konečně už Win NT4.0 vyskočily login dialog vcelku brzo, sice se nedalo přihlásit, protože neběžela služba winlogon, která se spouštěla podle abecedy,..... Ale když se ladí, proč se to při startu poto nebo proč něco nefunguje, tak díkybohu (jsouce ateistaVidím to hodně podobně.
Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojíMá to i mít nějaký readahead, takže je klidně možné, že jedno vlákno bude přednačítat data spouštěných služeb, ty by potom skutečně mohli startovat paralelně a o něco rychleji. Ovšem nejsem si jist, jestli celá tahle námaha za to opravdu stojí, u serveru, který se rebootuje jednou za update.
Mám teď pokusně rozjetý Debian 6, kde je taky nějaké paralelní spouštění a už jen takový výpis spouštěných služeb při startu systému je dost zmatený (některé výpisy jsou přes sebe). Což se dá samozřejmě ošetřit, ale opět je to jen zbytečná práce navíc.
) za jednoduchý spouštění one-by-one.
Já jsem právě narážel na to, že nějaký přechytralý systém závislostí dojde k pro mně nečekanému závěru, že když už neběží žádná služba, co by potřebovala síť, tak tu síť vypne. Na mém obstarožním iPAQu mi nefungovala OpenVPN jen proto, že ten jejich chytrý manažer síťových připojení odpojil GPRS ve chvíli, kdy zjistil, že v systému je (virtuální) síťovka...Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátimIMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla). Při vypnutí ssh bych očekával, že se nic dalšího nevypne. I když i toto je diskutabilní. Ne vždy, když zapínám nějakou síťovou službu u toho chci zapínat ještě síť (ve smyslu nastavovat IP z nějaké konfigurace).
Tak a druhá věc, které se obávám, je maglajs při startu. To mi nejdřív vznikne spoustá "dutých" socketů, pak přijde nějaký požadavek na službu (nejlépe přímo při bootování), ty služby se tak nějak začnou startovat (paralelně), já budu doufat, že se nezacyklí a že časem se to dostane do stavu, kdy to všechno běží? A co když se služba nespustí? Teď normálně zahlásí Failed, já se kouknu do logu a hle vidím, chyba v konfiguraci... Ale takhle? Služba běží, vše je ok, v socketu jsou nějaká data, ale nějak se nedaří spustit toho, kdo se o ně má postarat.... Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítámNějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.Na tohle jsem reagoval úplně stejně
Asi se stanu členem vývojového týmu a budu nenápadně škodit, ať se to nikdy nevydá ( a patentuju si guerilla developmnet)
Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítámTakyže jsi konzerva :). Myslím si, že logování nikdo nezatracuje, a failed služby budou úplně stejně failed jako dřív. Běžící aplikace zahlásí, že nedostala data ze sockety, o poruchové aplikaci init program zahlásí, že se ji nepodařilo spustit a ona sama pravděpodobně někde vypíše konkrétní důvod. Píšu jen svůj pohled na to, jak by to mělo vypadat. Je to něco relativně nového, takže se určitě objeví i nové chyby a problémy. Jinak sbližování desktopu a serveru je to, co mi na Linuxu přijde úplně nejlepší. Já třeba na testovacích nebo nově instalovaných serverech s velkou výhodou využívám jinak spíš desktopové vlastnosti typu multicast DNS, link-local IPv6 a další. Udržovat na server jiný init systém mi přijde škoda.
Chápu, že logování nikdo nezatracuje. Ale teď to funguje tak, že pokud služba nenaběhne, tak výpíše zhruba jednořádkový důvod přesně v tom místě, kde se měla spustit. A pak se v logu dohledají detaily. Ale když se mi teď nastartuje jen socket a až za x času se zjistí, že aplikace, která ho má zpracovávat nenabíhá?Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítámTakyže jsi konzerva :). Myslím si, že logování nikdo nezatracuje, a failed služby budou úplně stejně failed jako dřív. Běžící aplikace zahlásí, že nedostala data ze sockety, o poruchové aplikaci init program zahlásí, že se ji nepodařilo spustit a ona sama pravděpodobně někde vypíše konkrétní důvod.
Starting MySQL [OK] Starting httpd [OK] Starting readaehad_early MySQL datadir read failed. Aborting abnormally[OK] Stopping httpd [ok] Service MySQL [Failed]Vypadá to tak nemožně?
Píšu jen svůj pohled na to, jak by to mělo vypadat. Je to něco relativně nového, takže se určitě objeví i nové chyby a problémy. Jinak sbližování desktopu a serveru je to, co mi na Linuxu přijde úplně nejlepší. Já třeba na testovacích nebo nově instalovaných serverech s velkou výhodou využívám jinak spíš desktopové vlastnosti typu multicast DNS, link-local IPv6 a další.Některé ty novinky, se mi, po zralém ozkoušení (konzerva
), líbí taky. Ale tahle zrovna ne. A to sbližování, to se mi taky líbí, ale jen do chvíle, kdy to není válcování
Udržovat na server jiný init systém mi přijde škoda.No to mně právě taky, ale tenhle mně děsí.
30.4.2011 19:04
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Služba, která ke své činnosti databázi potřebuje se ovšem také musí umět vyrovnat s odpojením od databázového serveru (z důvodu například krátkodobého výpadku síťového spojení, restartu databázového serveru apod.) za provozu. Toto bych do jejího spouštění netahal, ta služba se může (z hlediska initu) spustit korektně i bez DB.Tak na tom se perfektně shodneme.
Navíc bylo by velkou chybou, kdyby byla v init skriptu definována závislost takovéto služby na databázi jakožto lokální službě. Databáze může být kdekoliv na síti.Taky dobrá poznámka.
Úspěšně se může spustit leda služba, která databází volitelně využívá.To záleží na tom, čemu říkáš úspěšně :). Tady jde jen o to, že se služba spustí a nehavaruje, ač třeba ještě není schopná autentizovat uživatele.
Výsledek úspěšného spuštění má být, že služba běží teď, nikoli to, že by služba možná jednou mohla běžet, nebo možná taky ne.Ona ta služba technicky běží teď. Co se týče pohledu uživatelů, ten bych do technické realizace vůbec netahal.
Pokud službě odejde ta databáze po spuštění, tak se dostane do havarovaného stavu, tj. opět neběží úspěšně.Pokud služba při odpojení od databáze havaruje, tak je to špatná služba a bál bych se, že bude mít i další problémy. Doporučuju hlásit chyby a omlátit programátorům o hlavu.
Tak mě popravdě nadchla už Lennartova přednáška na Fosdemu :).Letos jsem Fosdem vynechal, takže jsem se na tu přednášku kouknul teď. A musím říct, že mě spíš odradila: "Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..." "Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu. "Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..." "Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež. "Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)
"Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..."Co ti vadí na tom, že se závislosti definují pomocí funkce namísto pomocí jména? Stejně je tomu například u RPM balíčků. Mně to přijde skvělé.
"Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.Mně se osobně tenhle styl spouštění vždycky líbil. To SSH se stejně forkuje, tak co už.
"Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..."To vnímám jako velmi pozitivní... znamená to, že celý ten systém tak jak je znovu postavený není pomalejší, a to ještě není to spouštění není ani vyladěné. Až se to vyladí, má to teprve smysl benchmarkovat.
"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.To píšeš tak zmateně, že to nemá cenu komentovat.
"Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)Zrovna tohle si pamatuju jak říkal a souhlasím s ním, ale s tím, co jsi napsal ty to nemá vůbec nic společného.
Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat."Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..."Co ti vadí na tom, že se závislosti definují pomocí funkce namísto pomocí jména? Stejně je tomu například u RPM balíčků. Mně to přijde skvělé.
Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna."Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.Mně se osobně tenhle styl spouštění vždycky líbil. To SSH se stejně forkuje, tak co už.
Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace)."Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..."To vnímám jako velmi pozitivní... znamená to, že celý ten systém tak jak je znovu postavený není pomalejší, a to ještě není to spouštění není ani vyladěné. Až se to vyladí, má to teprve smysl benchmarkovat.
Ok, více polopaticky, ikdyž v tom videu to je pěkně pochopitelné. 1) Máme tu pěknou featuru, kdy se místo fsck spustí nejprve automount na daný mountpoint a pak fsck. A až ten fsck doběhne, tak se automountpoint odmpojí a připojí skutečný FS 2) Takže například taková Samba už může běžet a exportovat /home, ale když tam zkusí přistoupit, tak se zablokuje, protože to ve skutečnosti je teprve ten automount, a až doběhne fsck, tak se to připojí normálně, samba se odblokuje a vše bude vypadat, jakoby nic... 3) Otázka z pléna: A co když to fsck poběří v řádech minut až hodin? 4) Hmmm, aha... No tak se ta samba zablokuje a protože systemd si hlídá všechno pomocí timeoutů, tak se ta samba po cca minutě odblokuje s I/O errorem. No sice samba dostane I/O error, ale je to úplně stejné jako dřív, kde ta samba vůbec po dobu toho fsck neběžela. 5) Komentář z pléna: No to rozhodně stejné není, protože z hlediska klienta se ta samba tváří jako normálně přístupná, objeví se ty shary na sítí atd... 6) Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.To píšeš tak zmateně, že to nemá cenu komentovat.
A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky. Takže mohou nastat cca tyto varianty: 1) KDE/Gnome/... bude mít svůj session manager a systemd ho na linuxu nahradí sebou. 2) KDE/Gnome/... přejde na systemd. Varianta 1) zcela očividně přidělává spoustu práce a ikdyby jí všechnu udělali lidi od systemd, což se mi nezdá moc pravděpodobné, tak to určitě nebude kompatibilní a bude s tím spousta problémů... Varianta 2) Jsou dvě podvarianty. Buď ostatní systémy přestanou daná prostředí používat, nebo někdo naportuje systemd na ony platfomy, což nebude jendoduché, protože celé systemd je těžce postavené na linuxových technologiích (což samo o sobě mi nevadí)"Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)Zrovna tohle si pamatuju jak říkal a souhlasím s ním, ale s tím, co jsi napsal ty to nemá vůbec nic společného.
Všecko, co jsem psal, jsou víceméně mnou shrnuté otázky a odpovědi. Většinou dokonce uznal, že je to valid point, good question nebo tak...Ano, on je velice pozitivní ohledně připomínek.
Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.Ono to tvrzení právě bylo konzistentní, než jsi ho upravil :).
Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna.Kdo ti tvrdí, že to není velká změna (nevím, co míníš pojmem „konfigurační změna“)?
Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace).Od fosdemu už uplynula nějaká doba, takže jsem reagoval na tvůj „přepis“, kde jsi jaksi tohle vynechal. Mimochodem, pokud si v tom jádro nechá udělat maglajs, tak hádám, že by to chtělo opravu jádra, případně to doladit (nějaké hinty pro jádro, že teď je potřeba natáhnout radši větší kus dat pohromadě, pokud je to točitý disk). Každopádně ta rychlost je jediný bod, o který jsem se kdy bál :).
Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?Myslím, že je to tak jednoduchá věc, že bys ji zvládl popsat jednou větou, kdybys chtěl. Prostě Lennarta napadl zajímavý use case, který se nakonec neukázal jako až tak užitečný. To mi přijde naprosto OK. Nevidím důvod mu vyčítat, že se zmínil o tom, že systemd něco umí, a holt zvolí nedomyšlený příklad užití.
A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky.Směšuješ podle mě dohromady dvě nesouvisející věci. Jedna je, že teď při vývoji ho vůbec nezajímá starat se o jiné systémy, protože na to prostě nemá čas. Taky říkal, že nemá problém s tím, když se do toho někdo pustí. Jiná věc jsou jakési nápady či plány do budoucna, ale nikde na té přednášce netvrdil, že se systemd nebude v budoucnu udržovat i pro jiné systémy. Spíš naopak. Podle mě by bylo mnohem lepší, kdybyses zaměřil na aktuální problémy systemd a ty třeba i hlásil, než hořekoval nad nějakými mlhavými plány, u kterých může trvat roky než se uskuteční nebo zavrhnou. Tedy pokud se systemd vůbec hodláš nějak zabývat.
No ono bylo nekonzistetní pořád. Na jednom slajdu popisoval, jak se ty závislosti najdou samy tím, že se udělají ty sockety. A říkal něco jako: "Takže není potřeba ty závislosti nijak řešit, všecko se udělá samo". A pak se ho někdo zeptal, jak systemd pozná, které sockety a jak a on dodal, že se to musí napsat do unit filu. A pak se ho někdo zeptal, jak si s tim poradí ty démoni a on řekl, že se musí opatchovat.Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.Ono to tvrzení právě bylo konzistentní, než jsi ho upravil :).
On všude tvrdil, jak je to drop-in replacement, zpětně kompatibilní, nic moc to ve skutečnosti nemění, atd... "Konfigurační změna" je změna konfigurace. Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna.Kdo ti tvrdí, že to není velká změna (nevím, co míníš pojmem „konfigurační změna“)?
Já jsem mluvil o té přednášce. Nevynechal jsem to, pouze jsem to shrnul do "když nám byli všichni bozi naklonění", protože toho bylo trochu víc.Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace).Od fosdemu už uplynula nějaká doba, takže jsem reagoval na tvůj „přepis“, kde jsi jaksi tohle vynechal. Mimochodem, pokud si v tom jádro nechá udělat maglajs, tak hádám, že by to chtělo opravu jádra, případně to doladit (nějaké hinty pro jádro, že teď je potřeba natáhnout radši větší kus dat pohromadě, pokud je to točitý disk).
Každopádně ta rychlost je jediný bod, o který jsem se kdy bál :).No, když si vezmu ty jeho úvodní slajdy se slovy jako "agresivíní paralelizace" a těmi šipkami, kdy systemd to udělá všechno v jedné šipce ostatních systémů, tak zrovna rychlost by měla být asi podstatná, ne? A podotýkám, že já chápu, že ty šipky jsou sice stejně dlouhé, ale že to ve skutečnosti poběží déle, ale on přímo říkal: "a tady už vidíte, že je to o jednu šipku kratší..." (srovníní SystemV a Upstart)
Nejprve bych podotkl, že to nebyl usecase vymyšlený na místě na základě nějakého dotazu, ale předem připravený v rámci přednášky, takže není úplně OK, že byl špatně. Ale co je horší, to není use case, na který bych narazil, když něco udělám špatně. To je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambu. Ale ani to by nebylo nejhorší. Nejhorší je, že celá ta myšlenka je totálně nedotažená, z čehož vyplývá i to, že ten jeho use case nefunguje. A nebude fungovat spousta dalších, zatímco těch, kde to něco přinese bude pár. Protože tak, jak to popisoval, tak to přináší toto: "Pokud fsck poběží kratší dobu, než minutu, tak část té minuty ušetříme tím, že budeme spouštět věci během toho fsck a ty poběží, dokud nebudou ten kontrolovaný filesystém používat. Pokud se to do minuty stihne zkontrolovat, tak jsme něco malinko ušetřili, pokud ne můžeme nadělat šílený nepořádek.". Docela by mně zajímalo, co se stane, když tedy na /home poběží fsck a nějaká další služba bude třeba chtít projet home adresáře uživatelů, aby se podívala jestli s nimi něco nechce. Tak její start na minutu zmrzne a pak bude muset řešit I/O error.Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?Myslím, že je to tak jednoduchá věc, že bys ji zvládl popsat jednou větou, kdybys chtěl. Prostě Lennarta napadl zajímavý use case, který se nakonec neukázal jako až tak užitečný. To mi přijde naprosto OK. Nevidím důvod mu vyčítat, že se zmínil o tom, že systemd něco umí, a holt zvolí nedomyšlený příklad užití.
Tak to jsem asi koukal na jinou přednášku. "The thing is, if we focus on Linux, we have so many oppurtunities and with Linux specific APIs...because Linux is the most adavanced kernel....And Linux has all the awesome things..." (cca 31. minuta toho videa z Fosdemu).A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky.Směšuješ podle mě dohromady dvě nesouvisející věci. Jedna je, že teď při vývoji ho vůbec nezajímá starat se o jiné systémy, protože na to prostě nemá čas. Taky říkal, že nemá problém s tím, když se do toho někdo pustí. Jiná věc jsou jakési nápady či plány do budoucna, ale nikde na té přednášce netvrdil, že se systemd nebude v budoucnu udržovat i pro jiné systémy. Spíš naopak.
Podle mě by bylo mnohem lepší, kdybyses zaměřil na aktuální problémy systemd a ty třeba i hlásil, než hořekoval nad nějakými mlhavými plány, u kterých může trvat roky než se uskuteční nebo zavrhnou. Tedy pokud se systemd vůbec hodláš nějak zabývat.A dokonce to jsem chtěl udělat. Ať s tím mám nějaké reálnější zkušenosti, ikdyž radši bych se tomu obloukem vyhnul, ale to se zdá nebude možné. Stáhnul jsem si Fedoru15 beta, pustil VirtualBox a bác. Google+bugzila je chytrá a hle, systém potřebuje na instalaci 1GB RAM (skoro se mi chce říct wtf: 14ce stačilo půl, ale jsem slušně vychovaný a toleratní). Nu nevadí, sice budu muset něco povypínat, ale aspoň se to nainstaluje a pak to snad půjde snížit. Instalace se mi 3x řízla při kopírování souborů (pokaždé jinde) a jednou vlastní kopírování proběhlo za 10 vteřin (kupodivu to nic nenainstalovalo
)... A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemd
A pak se ho někdo zeptal, jak systemd pozná, které sockety a jak a on dodal, že se to musí napsat do unit filu. A pak se ho někdo zeptal, jak si s tim poradí ty démoni a on řekl, že se musí opatchovat.Já jsem měl to štěstí, že už jsem o systemd něco věděl, takže jsem jeho vyjádření pochopil tak jak je myslel. Možná se nevyjádřil přesně, on vůbec nepůsobí jako lektor či řečník, spíš jako programátor, který umí mluvit hlavně na své úrovni abstrakce. Já jsem mu v technickém smyslu rozuměl, takže jsem v tom nekonzistenci ani neviděl. Nicméně na funkci systemd to nic nemění, ani kdyby se v něčem při přednášce vyloženě seknul.
Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.Ono ti může být jedno, jak moc komplikovaná je migrace na systemd, když ji za tebe stejně provedou tvůrci distribuce.
No, když si vezmu ty jeho úvodní slajdy se slovy jako "agresivíní paralelizace" a těmi šipkami, kdy systemd to udělá všechno v jedné šipce ostatních systémů, tak zrovna rychlost by měla být asi podstatná, ne?Konceptuálně ano, ale otázka je, jestli je systemd dostatečně vyladěný, a jestli jeho konfigurace v dané distribuci je dostatečně vyladěná, případně jestli nějaký software nedělá vyložené nesmysly vzhledem k paralelnímu spuštění. Tzn, nevím, jestli už nadešel správný čas na benchmarky, jestli není příliš brzo.
To je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambuPodle toho, jestli správci balíku takovou změnu provedou. Pokud vím, tak systemd to pouze umožňuje, nevyžaduje.
A nebude fungovat spousta dalších, zatímco těch, kde to něco přinese bude pár.To si povíme, až to bude pár let v běžných distribucích. Zatím se prostě holt lišíme názoru na výsledek, který ještě není vidět.
Tak to jsem asi koukal na jinou přednášku.Spíš mám pocit, že vidíš rozpory tam, kde já žádné nevidím :). Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu. A já nevidím jediný důvod, proč by se Lennart měl nějak speciálně zabývat dalšíma platformama.
A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemdNojo... tak když se ti nepodaří ani dotáhnout instalace :). Neříkám, že je to tvoje vina, ale já už používám Fedoru 15 cca měsíc.
Nicméně na funkci systemd to nic nemění, ani kdyby se v něčem při přednášce vyloženě seknul.Ale už o několik příspěvků výše píšu, že reaguju na tu přednášku. Ta je pro mně něco, co mně má přesvědčit/seznámit/ohromit/... a to se jí vůbec nepovedlo.
To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd... Neříkám, že je to můj přístup, ale znám organizace, kde se na každou konfigurační změnu dělá opravdu postup typu: návrh změny->analýza dopadu->návrh backup postupu->vyzkoušení->nasazení... Například: V sshd(8) se dočteme: sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of seconds. Clients would have to wait too long if the key was regenerated every time. However, with small key sizes (e.g. 512) using sshd from inetd may be feasible. Je snadné říct, že dneska jsou CPU tak rychlé, že už to není pravda. Ale je to opravdu tak? A co když se přihlásí najednou x klientů? Takže pokud by se jednalo o nějaký opravdu důležitý sýstém, který podléhá tomu, co píšu výše, tak bude muset někdo sednout a zjistit, jak to s tím je. A to za mně ten autor distirbuce neudělá... A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.Ono ti může být jedno, jak moc komplikovaná je migrace na systemd, když ji za tebe stejně provedou tvůrci distribuce.
Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to dějeTo je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambuPodle toho, jestli správci balíku takovou změnu provedou. Pokud vím, tak systemd to pouze umožňuje, nevyžaduje.
Spíš mám pocit, že vidíš rozpory tam, kde já žádné nevidím :). Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu.Ale zároveň se naprosto jasně vyjádříl ve smyslu, že ho to nezajímá a že tomu nemíní nijak napomáhat a chce striktně využívat Linux only věcí...
A já nevidím jediný důvod, proč by se Lennart měl nějak speciálně zabývat dalšíma platformama.Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde. Je to cca 30. minuta na tom videu, přesně ten dotaz a jeho komentář ve stylu: "chceme nahradit sesison management v (něčem, co neběží jen na linuxu) (něčím, co beží jen na linuxu)".
Fedoru používám ještě od doby, kdy to ani Fedora nebyla. Dokonce ani Fedora Core. A mám pocit, že už jsem si se s ní vcelku "sčuchnul" a umím s ní dělat docela psí kusy. Ale přiznám se, že dvě hodiny neúspěšných instalací, to se mi ještě nestalo... A ač si myslím, že to moje chyba není, tak prostě zatím systém nainstalovaný nemám. Ale až bude zase chvíli nálada, tak se k tomu zkoušení vrátím, protože ať chci nebo nechci, tak pokud se Fedora 16 neodvrátí od Systemd, tak se s ním budu muset poprat...A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemdNojo... tak když se ti nepodaří ani dotáhnout instalace :). Neříkám, že je to tvoje vina, ale já už používám Fedoru 15 cca měsíc.
Ale už o několik příspěvků výše píšu, že reaguju na tu přednášku. Ta je pro mně něco, co mně má přesvědčit/seznámit/ohromit/... a to se jí vůbec nepovedlo.Mně ta přednáška se seznámením trochu pomohla, i když daleko víc pomohly Lennartovy texty. Ale já samozřejmě můžu psát jen za sebe, že.
To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd...Fajn, aspoň budu mít větší cenu na trhu práce, stejně jako s náskokem v IPv6 :).
A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.To katastrofické scénáře hodné teoriím o zničení veškeré výpočetní elektroniky rokem 2000.
Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to děje
Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde.Upřímně? Je mi to jedno, kdo z nich to bude. Ale správce systemd obvykle do konfigurace samby svévolně zasahovat nebude. Já nejsem v balíčkování distribucí nijak zběhlý, ale z toho mála co vím lze vyvodit, že akorát vymýšlíš blbosti. Stačí se podívat, který soubor kterému balíku náleží.
Ale zároveň se naprosto jasně vyjádříl ve smyslu, že ho to nezajímá a že tomu nemíní nijak napomáhat a chce striktně využívat Linux only věcí...A já přesně tomuto přístupu fandím a nevidím v tom žádný rozpor s tím, že jiní můžou zajistit, aby systemd běžel na jejich oblíbené platformě.
Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde.Nechápu, proč mu vyčítáš, že hledá další možná nasazení systému, na kterém pracuje. Mě to přijde naprosto normální a přirozené.
Ale přiznám se, že dvě hodiny neúspěšných instalací, to se mi ještě nestalo...Mě taky ne. Ale hlavně že za to může zrovna systemd.
To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd... Neříkám, že je to můj přístup, ale znám organizace, kde se na každou konfigurační změnu dělá opravdu postup typu: návrh změny->analýza dopadu->návrh backup postupu->vyzkoušení->nasazení... Například:No tak zrovna RHEL 6 má upstart a předpoklad je, že RHEL 7 bude se systemd, takže organizace budou muset přejít. Nicméně pro opravdu velké nasazení se používají věcičky jako puppet, takže je to spíše otázka integrace systemd s těmito konfiguračními nástroji.
A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.Tak znovu, že systemd něco umí neznamená, že takové nastavení je rozumné.
Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to dějePokud jde o možnost upravovat si systemd jednotky, tak toto je další výhoda systemd oproti klasickým skriptům. Systemd bere konfiguraci s
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
29.4.2011 23:16
30.4.2011 13:58
29.12.2011 18:43
/lib a z /etc, přičemž ten druhý je prioritní a určen pro uživatelské úpravy.
V praxi to znamená, že si můžeš upravit libovolný "init skript" a být bez obav, že update balíčku změny zase vrátí zpět.
Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu.Zajímalo by mě, kolik zastánců různých platforem je skutečně používá. Systemd je Linux only věc, stejně jako launchd je OS X only, nebo SMF je Solaris only. Port na jinou platformu je prakticky nemožný, protože je systemd pevně zadrátovaný s Linuxem - třeba jmenné soubory procesu, různé plánovače, nebo třeba cgroups a ostatní věcičky. Tohle všechno by se muselo na další platformu přenést a vlastně proč z ní dělat druhý Linux ...
1.5.2011 21:11
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Jenom takovou malou OT poznámku:
Pokud fsck poběží kratší dobu, než minutu
Opravdu bych chtěl vidět FS, který se při dnešních velikostech disků, bude kontrolovat (tím je myšlena úplná kontrola, ne kontrola na clean umount) pouze minutu.
1.5.2011 18:26
michich | skóre: 51
| blog: ohrivane_parky
Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.Tady vidím nedorozumění. Existují dvě kategorie závislostí, které jsou navzájem nezávislé (Lennart vždycky říká, že jsou ortogonální): potřeby (requirements; Requires, Wants) a řazení (ordering; Before, After). Vytvořením soketů předem se automaticky vyřeší pouze problém řazení. Je pravda, že démoni, kteří mají umět soketovou aktivaci využít, musí být pro tento účel opatchováni. Soketová aktivace ale není povinná. Pokud démon není takto opatchován, musí se holt pouštět klasickým způsobem a řazení musí být pak uvedeno ručně (Before=... nebo After=... v unit souboru, LSB hlavičkou v initskriptu, nebo pořadovým číslem v SysV symlinku).
Tady vidím nedorozumění.To není nedorozumění, já jsem to plně pochopil. Ale jak píšu výše, mám za to, že si tím protiřečí.
Ale jak píšu výše, mám za to, že si tím protiřečí.A já mám za to, že vůbec :).
1.5.2011 22:06
michich | skóre: 51
| blog: ohrivane_parky
takze sa linux dostal do pozicie, ktora mu tak vadi(la) na windows -- neberie ohlad na (mensie) alternativne systemy .. :-/To mi zní jako dva nesmysly v jedné větě. Nevím, koho přesně myslíš tím linuxem, když píšeš, že mu něco vadilo. A že nebere ohled? Zase kdo nebere ohled? Lennart? Torvalds? Pokud někdo bude chtít portovat systemd na svou oblíbenou platformu, způsob jistě najde.
1.5.2011 18:34
michich | skóre: 51
| blog: ohrivane_parky
ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.No změna to je, ale není nutné zrovna tuhle možnost využívat. Výchozí způsob spouštění sshd ve Fedoře 15 je stále ten původní (tedy že sshd si naslouchající soket dělá sám).
"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.Tohle je zas o tom, že systemd něco nového umí, ale výchozí nastavení to není. automounty ti to vyrobí, pokud si do /etc/fstab přidáš volbu
comment=systemd.automount. V F15 to běžně není.
(Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)To jeho nadužívání toho slova v přednáškách se mi taky nelíbí.
No změna to je, ale není nutné zrovna tuhle možnost využívat. Výchozí způsob spouštění sshd ve Fedoře 15 je stále ten původní (tedy že sshd si naslouchající soket dělá sám).Zrovna v tomhle případě mi je jedno, jak to to SSHd spouští. Ale u jiných věcí mi to jendo být nemusí a jsem rád, že se ve Fedoře k tomu staví konzervativněji
Tohle je zas o tom, že systemd něco nového umí, ale výchozí nastavení to není. automounty ti to vyrobí, pokud si do /etc/fstab přidáš volbu comment=systemd.automount. V F15 to běžně není.
Jenže jak už jsem psal výš, to není jen o tom, že to něco nového umí. Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů. A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouho
Mně se upřímně řečeno nelíbíl téměř celý jeho styl projevu, zavádějící slajdy, poměrně arogatní chování a možná bych řekl i ne zrovna dobře provedená (nebo aspoň špatně odprezentovaná) práce. A to jsou věci, které mi vadí u lidí, kteří mi chtějí měnit způsob, jak mi startuje systém(Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)To jeho nadužívání toho slova v přednáškách se mi taky nelíbí.
1.5.2011 20:38
michich | skóre: 51
| blog: ohrivane_parky
Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů.Ty víš, co všichni uživatelé potřebují? Já si umím představit, že si to zapnul pro disk, na kterém mám hudbu, aby mi občasný fsck spouštěný na tomto oddílu nezdržoval přihlášení do Gnome.
A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouhoNevím o tom, že by to vůbec někdy mělo být defaultně.
Samozřejmě, že nevím co chtějí všichni uživatelé. Ale několik jich znám a vím, že by mě s tímhle vyhnali... A ano myšlenka s tím fsck hudby, aby nebrzdil start gnome, to zní pěkně. Jen se obávám, že to tak idylické nebude. Napadá mně spousta šílených scénářů, ale třeba je to jen mou bujnou fantaziíCelá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů.Ty víš, co všichni uživatelé potřebují? Já si umím představit, že si to zapnul pro disk, na kterém mám hudbu, aby mi občasný fsck spouštěný na tomto oddílu nezdržoval přihlášení do Gnome.
A já právě doufám, že to tak zůstane co nejdéle...A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouhoNevím o tom, že by to vůbec někdy mělo být defaultně.
A ano myšlenka s tím fsck hudby, aby nebrzdil start gnome, to zní pěkně. Jen se obávám, že to tak idylické nebude.
Nebude. Většina lidí má jeden disk, takže fsck čehokoli na něm dokáže efektivně přidusit zbytek systému.
Zrovna v tomhle případě mi je jedno, jak to to SSHd spouští. Ale u jiných věcí mi to jendo být nemusí a jsem rád, že se ve Fedoře k tomu staví konzervativnějiTak ona se každá experimentální možnost nemusí hned použít v živé distribuci, že.
Jenže jak už jsem psal výš, to není jen o tom, že to něco nového umí. Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů. A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouhoOn to uživatel často ani nemusí poznat, natož aby mu to bránilo naplňovat své potřeby.
Mně se upřímně řečeno nelíbíl téměř celý jeho styl projevu, zavádějící slajdy, poměrně arogatní chování a možná bych řekl i ne zrovna dobře provedená (nebo aspoň špatně odprezentovaná) práce. A to jsou věci, které mi vadí u lidí, kteří mi chtějí měnit způsob, jak mi startuje systémZas na druhou stranu, on není ten, kdo ti mění způsob, jak ti startuje systém. On jenom tvoří nástroj pro to jiné startování, pokud mi něco neuniklo.
Zas na druhou stranu, on není ten, kdo ti mění způsob, jak ti startuje systém. On jenom tvoří nástroj pro to jiné startování, pokud mi něco neuniklo.Samozřejmě, že je to trochu zkratka z mé strany. On vytváří systém startování, který se zdá bude můj oblíbený distributor používat a protože se jedná o poměrně zásadní věc, tak se nedá moc očekávat, že budu mít jinou volbu, jakmile se onen zmíněný distributor rozhodne jeho výtvor používat. Samozřejmě kromě totálního řešení v podobě změny distributora, což je trošku overkill.
Samozřejmě kromě totálního řešení v podobě změny distributora, což je trošku overkill.
A navíc je tu riziko, že to nepomůže, protože ostatní přejdou na systemd taky.
upstart 
30.4.2011 16:07
michich | skóre: 51
| blog: ohrivane_parky
IMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla).Ani tak to není. Pánové, doporučuji vám prostě si to vyzkoušet, protože celá tahle debata je o tom, že všichni jenom spekulují o tom, jak by systemd mohlo fungovat, kdyby to bylo udělané špatně.
30.4.2011 16:02
michich | skóre: 51
| blog: ohrivane_parky
* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátimsystemd žádné automatické zastavování služeb při nepotřebnosti nedělá.
Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...Co třeba možnost zjištění, ke které službě patří daný proces a obráceně, spolehlivé zabití neposlušné služby, či dohled nad tím, že služby běží?
Z různých důvodů jsme vybrali řešení, kde server, který by rád kontrolu disku, nahodí síť, spustí ssh a pošle maíl. Admin se přihlásí, opraví a voila. Půjde toto udělat v systemd?systemd před přimountováním oddílu spouští službu fsck@DEVICE.service. Co má ta služba dělat, je definováno v odpovídajícím unit file. Ten se dá přebít unit filem stejného jména v /etc, takže klidně můžeš spouštět místo výchozího helperu systemd-fsck nějaký svůj oblíbený shell skript.
systemd žádné automatické zastavování služeb při nepotřebnosti nedělá.Ale D-busem startované služby se při nepotřebnosti můžou samy ukončit, ne?
30.4.2011 16:08
michich | skóre: 51
| blog: ohrivane_parky
1.5.2011 13:38
michich | skóre: 51
| blog: ohrivane_parky
* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátimLennart se vždy vyslovoval poměrně zdrženlivě k možnosti automatického vypínání z důvodu nečinnosti.
* Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.No pro webserver to skutečně není nijak rozumné nastavení. Naštěstí systemd odložené spuštění nevynucuje, je jednoduché nastavit webserver tak, aby se daná služba spouštěla okamžitě. Ono to dává v některých případech smysl (cups na mém notebooku) a někdy ne (cups na tiskovém serveru). Se systemd si můžete vybrat.
Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...Tak mimo integrace s cgroups nabízí systemd poměrně bohatou škálu různých ladících knoflíků jádra a nastavení, z nichž některé nejsou z prostředí shellu vůbec dostupné. Další výhodou je třeba to, že se služby spouštějí stejným předpisem nezávisle na způsob aktivace a nedochází k duplikaci, jako s
(x)inetd.
Tiskni
Sdílej:
