Arch Linux přesouvá soubory z /bin, /sbin a /usr/sbin do /usr/bin

Vývojáři Arch Linuxu upozorňují na problém související s přesunem souborů z adresářů /bin, /sbin a /usr/sbin do adresáře /usr/bin při aktualizaci systémů. Před necelým rokem byly přesunuty soubory z /lib do /usr/lib. Důvody přesunů jsou uvedeny například v článku Proč sloučit /usr na Fedora.cz.

5.6.2013 17:30 | Ladislav Hagara | Upozornění

Komentáře

[bugme]

Desna blbost. Nekdo nejmenovany neco neumi udelat a misto toho aby to opravil tak prizpusobi okolni system sve sr4cce.

[BFU]

Chapu to spravne, ze zakladni systemu, ktery ma fungovat bez pripojeneho /usr/ uz fungovat nebude moci?

[pavlix]

Ano.

[Filip Jirsák]

Opravdu platí tahle odpověď, i když je v dotazu to „už“? Není to náhodou tak, že v Archu základní systém bez připojeného /usr nefunguje už teď, takže se na tom nic nezmění?

[BFU]

To ovsem znamena, ze Arch je FUBAR a snaha to opravit jde uplne spatnou cestou. Ta separace ma dobry duvod, kdyz se system pokazi, lze ho stale nabootovat do runlevelu 1 a opravit s nastrojema dostupnyma v /bin a /sbin .

[pavlix]

Opravdu platí tahle odpověď, i když je v dotazu to „už“?

Ano. Jestliže doteď to fungovat mohlo (ať už to to konkrétnímu člověku fungovalo, nebo stačilo opravit některý z balíčků), teď už to fungovat nebude moci. To „už“ je zcela namístě.

Není to náhodou tak, že v Archu základní systém bez připojeného /usr nefunguje už teď

Na to se zeptej těch, kteří to používají, zda jim to funguje a především co všechno jim takto funguje.

takže se na tom nic nezmění?

Změní. Jestliže se dosut mohl kdokoli podílet na nápravě opravou jednotlivých balíků, po tomto kroku již náprava není možná. Jestliže to některým lidem doposud fungovalo a využívali to (netuším, zda konkrétně na Archlinuxu), tak si umím představit, že toto považují za změnu.

[jas]

V archu sa proste nabootuje live install cd (to uz by malo ist asi aj priamo z grub 2), pripoji root a pouzije pacman s nasmerovanym rootom na pripojeny root (pripadne chroot).

V archu by iny pristup moc fungovat ani nemohol, kedze pri niektorych updatoch nie je iste, ze system prejde cez boot noveho jadra a uchovava sa tam vzdy len jedna verzia jadra (vynimkou je stable jadro, ale to ked som skusal naposledy, tak kvoli systemd ani nenabootovalo).

[pavlix]

To, co píšeš, nesouvisí s příspěvkem, na který raguješ.

[jas]

... (netuším, zda konkrétně na Archlinuxu) ...

.

[pavlix]

Takže nic. Šlo jen o to, jakou to konkrétní lidé, co využívali oddělený /usr, používali Archlinux či nikoliv, nikoliv o obvyklý způsob použití Archlinux.

[jas]

Moze to byt pre teba nezvycajne a neuveritelne, ale ja som sa s tebou nesnazil hadat. Len som spominal dovody preco to tak v archu je a preco to v archu nik nepouziva pre tych, co nemaju s archom skusenosti (ako si priznal v komentari napr. ty).

[pavlix]

V pořádku. Mě jen zajímala souvislost s tím mým příspěvkem, ale když žádná není, tak se nic neděje.

[Tomáš Bžatek]

Proc mam pocit, ze Archlinux se riti do horoucich pekel, nasledujic Fedoru? Dependency hell, systemd, usrmove...

[bugme]

Obecne spousta veci okolo linuxu jde do pekel :-/ at uz systemd, tadle blbost, gnome 3, pulseaudio...

[pavlix]

Holt špatná vlna. Třeba pár lidí probudí.

[Rezza]

No ja osobne beru systemd jako zachranu Linuxu - i kdyz tam nesouhlasim se spoustou veci, nelibi se mi, jak nektere veci tlaci a maji jediny spravny pohled. Usrmove taky zpusobil bugu a bugu (to opravime, teda nekdo to opravi . Ale spousta bordelu, ve kterem bychom se jednoho dne utopili zmizela.

[kavol]

Ale spousta bordelu, ve kterem bychom se jednoho dne utopili zmizela.

jako například?

[Bedňa]

Mne príde že v /usr samotnom je hrozný bordel, nikdy som nepochopil tú nelogickosť, teda mohol by som sa aj rozpísať, ale kto by to čítal že? :) /sbin beriem že má svoje opodstatnenie, prečo nezačať od bordelu, ale toho čo funguje?

[...]

souborove systemy v soucasne podobe jsou v malem snad i prezitek. stejne je to jen takova otagovana kupa neporadku a pod ty tagy patri i prava(uid,gid,mod,label,..) a cesta je taky vlastne forma tagu. jen historicky se ty mandatorni tagy porad drzi v specializovanych strukturach umoznujici lepsi vykon.

tak proc si nechat rvat zily pro jeden tag...

[taz]

Už se někdo ptal na příklad. Před čím ho zachránil? Jak? Systemd nemá podle mého se záchranou nic společného. Začíná to monolitem, který se Lennart snaží oponovat tvrzením, že #ifdefy jsou přece znakem modulárního systému, pokračuje to hromadou logiky skryté v tom monolitu, kvůli které je skutečná dřina vyznat se dneska jak a proč systém startuje, o debugování nemluvím a (ne)končí to binárníma logama. Nejde ani popsat jak to je strašné, nelinuxové, neunixové. Každý, kdo měl co dělat s binárníma souborama ví, jaká slast je pracovat s textovým souborem, který může stále být bez problému čitelný i po značném poškození. A každý linux admin musí opravdu ujíždět na tom, kolik toho na svém systému dokáže s běžnýma souborovýma nástrojema. Dokud ovšem nedostane facku jméněm systemd s jeho desítkama *ctl příkazů. Ještěže stále existuje find, abych si je všechny mohl najít. Takže jestli si tou "záchranou" linuxu myslel sražení do pekla neprůhledných monolitů a binárních souborů tak, jak to mají jiné systémy, tak opravdu za takovou záchranu pěkně děkuju. Aby to ale neskončilo tak, že na každou blbost v userspace budu potřebovat speciální utilitu a aby nezůstalo jenom jádro ovládané přes prosté a geniální cat/echo.

[kralyk z abclinuxu]

Souhlasim, že binární logy jsou humus na entou, nicméně afaik se systemd log dá nasměrovat do syslog-ng.

Jinak ty námitky proti systemd bych bral trochu víc vážně, pokud by ti, kteří systemd kritizují, nabízeli nějakou rozumnou alternativu. To ovšem rozhodně není případ klasických init skriptů, tzn. pomalé kupy hnoje v BASHi. Možná, že se někdo potřebuje každej den ráno před nějakou prací/činností pohrabat ve střevech init systému, a tudíž ho potřebuje celý v BASHi, ale to rozhodně není případ většinového uživatele (a nejspíš stejně dotyční kecaj a nepotřebují do toho tak často / tak hodně zasahovat).

IMHO bylo celkem jasný, že klasický init skripty dřív nebo později něco nahradí, jestliže teda tolik lidí nechtělo systemd, proč se nezastali o nějaký jiný řešení? Třeba OpenRC tu byl dávno před systemd, takže příležitost tu určitě byla, bohužel, většina lidí vzkázala správcům distribucí něco ve stylu "Ne, budete pro nás spravovat naše milované init skripty. Cože? Že pro nás musíte de-facto vyvíjet vlastní init systém v bashi? To je váš problém".

[pavlix]

Naprosto s tebou souhlasím.

Třeba OpenRC tu byl dávno před systemd, takže příležitost tu určitě byla

Proto taky nikde v ničem, co napíše Lennart jméno OpenRC není vidět. A může se stát, že systemd trvale přebije i to OpenRC protože tím, že bylo vnuceno do enterprise distribucí, na něm teď visí docela dost peněz. OpenRC naproti tomu nezíská ani zlomek prostředků na vývoj, co získá systemd. A tím nemyslím jenom finanční prostředky.

[kralyk z abclinuxu]

Je to bohužel tak, přitom OpenRC bych fandil. Škoda.

[taz]

Budu opakovat, co už jsem tu jednou psal. To si myslíš jenom proto, že se Ti to ještě nerozbilo. Až budeš jednou řešit problém s bootem a systemd, sám si nafackuješ za to, co si teď řekl o bash skriptech. Jo, a rychlost není jediné měřítko kvality, často jde rychlost přímo proti kvalitě, to když třeba něco jede tak rychle, že Ti to nedá šanci přečíst chybové hlášky, nebo nedostaneš šanci stisknout potřebnou klávesu v ten pravý čas. Však Ty to jednou poznáš. A to si ještě představ, že ten počítač je 7000 km daleko.

[kralyk z abclinuxu]

No, tak systemd se mi zatím nějak drsně nerozsypal, ale pokud se to stane, nejspíš s tím budu opravdu mít problémy, a to zejména proto, že systemd zatim neznám moc do hloubky (což je ale můj problém). Jinak systém s klasickými init skripty se mi párkrát rozsypal a taky to není zrovna lahůdka se tím vším probírat.

Rychlost? Já rozhodně nenapsal, že to je jediné měřítko kvality. Ona nevýhoda těch bash skriptů není jen v pomalosti, ale taky v nutnosti je maintainovat zvlášť pro každou distribuci, resp. každou skupinu distribucí se specifickými init skripty, což je (bylo před systemd) docela hodně distribucí.

Jo, že to je na vzdáleném serveru nepříjemné, to věřim...

[taz]

Shell skripty ale nejsou nekompatibilní z podstaty věci, nekompatibilita init systémů vznikla historickým vývojem každé distribuce a tak strašné to nebylo, definice start/stop uložení pidu a v podstatě hotovo, žádná tragédie, nic, co by nešlo napsat genericky pro spoustu distribucí. Vzhledem k tomu, že žádné divoké přebírání systemd se nekoná tak to systemd naopak jenom zhoršuje, protože ten potřebuje úplně něco jiného. Ale to nepovažuju za problém, prostě je to nový systém. Až se budeš se systemd seznamovat, objevíš v ní fedora specific hooky, třeba si všimneš, že různé distribuce jinak umisťují wwwroot apache, že jinak pojmenovávají služby, vzpomeneš si na openRC, upstart, nebo prostě jenom konzervativní debian a možná si i uvědomíš, že nějaká unifikace se se systemd nemusí tak úplně dostavit.

[kralyk z abclinuxu]

Tak jasný, že by to šlo, jen by se muselo trochu chtít... což ovšem platí pro systemd taky...

[Jiří J.]

Taky bych byl raději za postupné nabalování featur na jednoduchý základní model. A před každou revoluční změnou pokud možno referendum namísto "dělali jsme na tom pár let, tady to máte, budete to muset používat".

Na druhou stranu se mi samotnými "init skripty" více líbí takový OpenRC, který v zásadě definuje jednoduchý layout (příklad), ale nebrání použití vlastního skriptového kódu. Takový "SysV 2.0". Ano, ta volnost může vést k neunifikovanému kódu, ale - upřímně - kdo tam ten kód chce dát, tak si jej tam přes unit file hooky stejně nacpe, daleko "prasáčtějším" způsobem.

ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'

Ano, tohle je přece ten lepší způsob.

 

No jo, už mlčím, flamewar stačil/stačí v jiné diskuzi.

[Tomáš Bžatek]

Bordel mozna zmizel ve Fedore, kde byl napr. glib v /lib[64] a to byla prasarna. U ostatnich distribuci je ale cisto a knihovny (+ kernel) jsou striktne separovane podle sveho urceni. Napr. mit moduly a firmware kernelu v /usr/lib64 mi pripada uchylne.

[Petr Ježek]

Ano vypadá to úchylně, ale jen do té chvíle, kdy se zamyslíme nad způsobem práce s těmito knihovnami a firmwarem (kdy co na popud čeho/koho to tahá). Něco jiného je mít zaražen přístup do šéfovy kanceláře a mít tam volný přístup, ale nemoci tam ovládat šéfem definované činnosti. Prostě šéfův kancl se ocitl v userspace i s řadou věcí, co tam jsou, ale bez možnosti uživatele s nimi bezlimitně zacházet.

[jyrki]

S tim bordelem je to dobrej joke. Na Linuxu me neskutecne stve, ze kdyz neco nefunguje nebo nejakou funkcnost postrada, tak jde nejakej blbec (nejcasteji Lennart) a napise jinou zhovadilost from scratch. Ted se sjednocuji adresare ale koukneme na aktivitu predchozich let - /media, /run, /opt.

[little.owl]

+1

[jyrki]

jeee, koukam ze jsme skoro sousedi, ja jsem ted v Burgess Hill

[xvasek]

Na pulseaudio mi nesahej, to je super věc!

[Pff]

Co maj doháje všichni proti PA? To je jedna z mála věcí co mi všude fungovala out-of-the-box a co nepadá...

[kavol]

no tak třeba to, že to je věc, která jim, narozdíl od tebe, zvuk znefunkčnila úplně nebo alespoň způsobila kopec problémů?

[Bedňa]

To je pravda, ale už sa dostalo do použiteľného štádia a pavucontrol sa to dá väčšinou naklikať.

[Jakub Lucký]

+1 (k příspěvku) a +5 (mých problémů k existujícímu kopci)

[pavlix]

Mně osobně teda dost zatěžuje procesor a způsobuje různé glitche při telefonování apod. A ještě se tomu sesypávala konfigurace po restartu, i když to už asi přestala. Jinak bych proti tomu nic neměl.

[Jiří J.]

Ještě aby to bylo jako normální služba, která jde vypnout, když chci přímo pracovat s ALSA a nechci, aby se mi v tom náhodně něco vrtalo a zamykalo si zvukovku. Po cca 15 minutách zkoumání možností vypínání pulseaudia na Ubuntu (upstart?) jsem se uchýlil k chmod -x. Tak trochu se bojím, že se socket-activated službami v systemd mi místy nezbyde nic jiného.

PS: Až mi tohle workaroundnou automatickým chmodem, tak mám v záloze ještě hardlinky!

[pavlix]

Ta manipulace se socket-activated službami je strašně nedomyšlená. Taky se uchyluju k podobným trikům.

[Petr Ježek]

Jasně, jde to všelijak. Jen je třeba se zeptat, na jaké úrovni jsou jaké služby volány, s jakým cílem a jakými efekty a koefekty, aby se userego nezpotilo ze suboptimálního chování systému, který nechápe. Tohle je denní chleba lidí kolem kernelu.

[pavlix]

Vedlejší efekty v současné době způsobují to, že ten systém jako celek se chová úplně debilně navzdory administrátorovi...

[little.owl]

Co je tam konkretne problem? Bugzilla ... ?

[pavlix]

Takovéty klasiky...

Ani nemám nikde seznam takových bugreportů, takže vytáhnu z paty jeden, který se mě nějak týkal:

https://bugzilla.redhat.com/show_bug.cgi?id=815243

Ale při troše snahy najdeš podobné bugreporty na další software, říkali mi lidi tuším o rsyslogu, takže se to netýká jen dbusových služeb.

[paralen]

napriklad toto

[Bedňa]

Pokiaľ chceš vychytávky pre každý program extra, rozhodne odporúčam OSSv4. Pri tom že PA už slušne funguje v porovnaní s OSSv4 je to niečo ako keď máš kolesá s podvozkom, motorom a volantom, jazdiť sa na tom dá, ale auto by som tomu ešte nehovoril.

[Václav "Darm" Novák]

Jestli už v OSSv4 vyřešili USB zvukovky a problémy se suspendem, rád přejdu :) Jo a umí to u každé aplikace nastavit zvlášť ze které zvukovky má hrát?

[Bedňa]

USB zvukovky sú shit :) OSS vyvíjali primárne pre profi zariadenia. Suspend sa "rieši", no nefunguje. Výstup na zvukovku som riešil nastavením daného programu kde ma mať výstup. Presmerovania na karty tam idú, ale nikdy som to neriešil, primárnym účelom OSS je kvalita.

[pavlix]

USB zvukovky sú shit :) OSS vyvíjali primárne pre profi zariadenia.

Tak už chápu, proč OSS na běžném linuxém trhu prohrává na plné čáře, když nedokáže nabídnout základní uživatelskou funkcionalitu.

[kavol]

jen je mi divné, že prohrává proti něčemu, co ji také nenabízí ...

[Václav "Darm" Novák]

Hmm, tak to je první případ USB zvukovky který vidím nejít pod PA. A to mi jich prošlo rukama hodně. Oproti tomu pod OSS je podpora absolutně zoufalá, i kdyby ten headset zvládl pod OSS hrát, nebude fungovat mikrofon. Takže tvrdit že funkcionalitu PA „také nenabízí“ na základě jednoho případu není zrovna fér.

BTW, jak tak koukám, OSS stále neumí suspend. Yay.

[kavol]

vzhledem k tomu, že na tom krámu není nic speciálního, jádro ho umí, přes mplayer přehrávám, nemám důvod si myslet, že jde o problém konkrétního hardware - takže mám tak trošku problém věřit ti, že když si vezmu jiný kousek, co ti "prošel rukama", tak to najednou zázračně půjde

co se týče toho, co je nebo není fér, měl by ses vrátit o krok zpět, takovýto argument byl totiž použit proti OSS

no a pokud se dále budeme bavit na úrovni "a OSS ještě neumí tohle [suspend] a támhleto ...", tak věř, že nějaké bugy na PA ještě také v zásobě mám, například

[Bedňa]

Keď si zoberieš PA nad ALSA, čo je vo väčšine distribúcií, tak také základné porovnanie s ktorým súhlasím je na ArchWiki. Mám skúsenosť, že OSSv4 na kvalitných kartách dokáže lepšie detekovať funkcionalitu (viac možností nastavenia, v 50% ani netuším na čo slúžia). Tá podpora USB, onboard šmejdov atď. samozrejme nahráva PA/ALSA a tak to už asi zostane.

[Jakub Lucký]

Což odsuzuje OSSv4 navždy být v ústraní...

[pavlix]

Tá podpora USB, onboard šmejdov atď. samozrejme nahráva PA/ALSA a tak to už asi zostane.

V tom případě je potřeba se smířit s tím, že ALSA/PA/cokoliv je pro 99% lidí (i geeků) vhodnějším řešením než OSSv4. Já jsem třeba podobně smíření s Gentoo, kde patřím mezi tu menšinu, pro které se nějakým způsobem hodí, OSSv4 mě podle toho, co píšeš, nemá co nabídnout.

[Bedňa]

OSSv4 mě podle toho, co píšeš, nemá co nabídnout.

Na kvalitu všetci serú, made in China :)

[Jakub Lucký]

<parodie>Já bych si rád dobré nádobí pořídil, ale je škoda, že se na něm dá vařit jen pomocí Tesla transformátorů a nesmí se v tom vařit guláš</parodie>

hint: výběr zvukovek (vs. jejich potřebnost) + absence suspend

[Bedňa]

Ja som si kúpil kartu, aby som mal o niečo lepší zvuk než z buil-in.

[Jakub Lucký]

jenže kolik lidí

• vůbec může takovou věc využít, usuzujíc rozšiřující se vlastnictví notebooků?
• skutečně využije kvalitní zvukovou kartu? Vzhledem k běžným PC reproduktorům (o NB nemluvě) jen skupina audiofilů

Z toho vyplývá, že reálně je OSSv4 jen špičkou ledovce pro velmi nízký počet uživatelů. A není to o kvalitě, je to o poměru cena/výkon. Když si pouštím hudbu jen tak jako podkres, stačí mi repráky v laptopu/sluchátka. Když chci dobrou produkci, pustím to z tabletu(!) zapojeného do věže. A pochybuji, že bych poznal rozdíl mezi OSSv4 a ALSA, kdybych to z té věže pouštěl a pochybuji, že by to poznal některý z těch audiofilů, co se tady chlubí tím, jak poznají jednotlivé A/D převodníky...

<flame>Pulseaudio bych ale poznal, protože by to nehrálo...</flame>

[Bedňa]

Pulseaudio bych ale poznal, protože by to nehrálo...

Jako fakt dobré, to som sa fakt aj od srdca zasmial Podpora je ale fakt dosť slušná, pred cca 2rokmi to bolo odhadom 90%, wiki tuším uvádzala až 99%, samozrejme s módou všetko vešať všetko na USB to išlo dole. Prakticky by si so zariadením zaveseným na PCI nemal mať problémy.

Kvalita PA/ALSA veľmi stúpla za posledné obdobie, ale keď si spomenieš rok, dva dozadu, tie presluchy tam vždy boli počuť, holt vyššie harmonické a šum tam bol, na to nepotrebuješ ani hudobný sluch. Teda stále používam slúchadlá a tam to bolo fakt cítiť. Priznávam že za cca posledný polrok hrá PA výborne, až na to že zrovna tu mám komp, kde nieje dobrá podpora v PA a ignoruje mikrofón, nehovorím že sa toto v OSS nestáva, sám som tento problém riešil v poradni.

[Jakub Lucký]

Bohužel já s PA tolik dobrých zkušeností nemám... Momentálně mi APT zajistil, že snad ani mít nebudu:

# cat /etc/apt/preferences.d/01systemd-forbidden 
Package: systemd
Pin: origin ""
Pin-Priority: -1

Package: pulseaudio
Pin: origin ""
Pin-Priority: -1

[Václav HFechs Švirga]

to je dobré, hned si to tam šoupu

[pavlix]

Na kvalitu všetci serú, made in China :)

Pokud kvalita má kvalita znamenat, že mi to na 99% nebude dobře fungovat, pak jsem někde nepochopil nějakou ironii ;).

[Bedňa]

Spravidla to funguje výborne na stolových kompoch, nefunguje čo som linkoval vyššie. Nebola to irónia, prv neboli v móde USBkartičky :) a aj zameranie OSS ako som písal si dávalo za ciele kvalitu, presne ako to píšu na Arch wiki.

[lertimir]

Jaký shit? Slyšel jsi zvukovky jako Pro-Ject nebo Audiotrack MAYA U5 či DR.DAC2 DX nebo E-MU? To je jiná třída, ale je potřeba slušný řetězec dále, aby to bylo poznat.

Na druhou stranu souhlasím, že suspend je s problémy. Před časem jsem tu řešil, jak mi přestala fungovat zvukovka Asus Xonar Essence XT, a pak zase začala. A následně jsem si vzpomněl, že jsem v nějakém čase předtím měl jednou "suspend to RAM". Následně byla zvukovka nefunkční. Dokonce byla nefunkční i když jsem vypínal počítač a rozběhla se, až když jsem ho měl asi 2 dny vypnutý. Jestli to bylo skutečně uspáním už nebudu jaksi raději zkoušet.

A ještě o jaké kvalitě je v rámci digitálního zvuku řeč? Alsa má jiné algoritmy na přepočítání jedněch bitů na druhé? Nebo je kvalita podobná "víra" jako když na HiEnd veletrzích prodávají digitální kabely z čistého stříbra za nesmyslné ceny a tvrdí, že jsou pro přenos zvuku lepší než obyčejné UTP. Podle mne jde u digitálního zvuku o dvě věci. Dostat do zvukovky správné bity, a dostat je tam včas. Zbytek je na D/A převodnících.

[kavol]

Jaký shit? Slyšel jsi zvukovky jako Pro-Ject nebo Audiotrack MAYA U5 či DR.DAC2 DX nebo E-MU? To je jiná třída, ale je potřeba slušný řetězec dále, aby to bylo poznat.

no a pak jsou tu další věci, jako latence apod. ... jak si stojí USB v porovnání s FireWire, například?

[lertimir]

FireWire je nádherná sběrnice, a je mi dost líto, že s ní jabko tak blbě pracovalo, že se nerozšířila. Nicméně dobře provedenou kvalitní zvukovku by ani méně stabilní USB by neměla ohrozit. To co zvukovka potřebuje jsou data včas. A tak, jako nebereš data na přehrávání synchronně z disku, ale nějakou dobu máš dopředu načtenou v bufferu, se může chovat i dobrá zvukovka, oznámí přehrávači ať dává vzorky v předstihu a chytí je do bufferu. Stejně přesný timing si musí udělat sama, kromě toho skutečně shitu na motheboardech mají dobré zvukovky a D/A převodníky vlastní hodiny s ochranou proti jitteru při změnách teploty a dalších vlivech a vzorky si řídí samy.

A taky neříkám, že nejsou špatné USB zvukovky. Samozřejmě jsou. Ale jde to udělat i dobře.

[kavol]

FireWire je nádherná sběrnice, a je mi dost líto, že s ní jabko tak blbě pracovalo, že se nerozšířila. Nicméně dobře provedenou kvalitní zvukovku by ani méně stabilní USB by neměla ohrozit.

nevím, jak s tou kvalitou provedení, ale měl jsem krabici na disk s možností připojení jak USB tak FW, disk v tom se svejma možnostma ani neblížil teoretickejm přenosovejm rychlostem, a přesto na FW běhal rychleji než na USB, nemluvě o zátěži na procesoru ...

To co zvukovka potřebuje jsou data včas. A tak, jako nebereš data na přehrávání synchronně z disku, ale nějakou dobu máš dopředu načtenou v bufferu, se může chovat i dobrá zvukovka, oznámí přehrávači ať dává vzorky v předstihu a chytí je do bufferu.

celá tvoje úvaha stojí na tom, že je možné si o data říct dříve než je potřebuješ - což je pravda tak když si přehráváš nějakou mptrosku, ale už ne ve spoustě dalších případů (už třeba jen takový telefon, že ...)

[Václav "Darm" Novák]

Ve chvíli kdy máš připojeny midi klávesy a potřebuješ v reálném čase výstup syntezátoru nebo midi sekvenceru nabufferuješ naprosté kulové. Tedy, bez křišťálové koule jako přídavné periferie. Ale i tam jsou u dobrých USB zvukovek latence v pohodě. (samozřejmě předpokládám JACK)

[pc2005]

Dostat do zvukovky správné bity, a dostat je tam včas.

Nebude náhodou USB zvukovka používat na přenosy izochronní mód? Tedy mód: hlavně ať se to nezpozdí, nevadí, když občas nějaký paket vypadne.

[lertimir]

24 bitu na 88200Hz ve flacu jsou technicky nejkvalitnější nahrávky, které mám, a které znám, že se běžně používají. Bitové toky jsou někde těsně pod 3000kbit/s. I když je to 15x více než běžné mp3 tak pořád dost daleko od přenosových rychlostí na USB. Disky mi na USB jedou tak 35Mbit/s, což je víc než 10 více. Myslím, že dobře provedená zvukovka má dost rezervy.

[pc2005]

Na samotném 480Mbit hostovi asi jo. Na USB 1.1 by bylo 12Mbit už skoro saturovaný. Kodek umí většinou minimálně full duplexní stereo režim, HDA kodeky maj i třeba 6 výstupních kanálů (a víc). Navíc USB sběrnicí lezou různý start framy a handshaky, samozřejmě taky řídící signály pro mixer apod a občasné pakety pro autodetekci, řekl bych (s usb hubem jsem si ještě teda nehrál, ono i jedno USB zařízení bylo dost šílený ovládat), takže plná rychlost se nikdy nedosáhne.

Je otázka jak dobře to bude fungovat na 480Mbit hubu sdílené třeba s HD kamerou (navíc taky izochronní data).

BTW kolega na univerzitě dělá projekt se snímáním obličeje při mluvení (či co ) a má zapojené dvě HD kamery a Kinect a musel si koupit externí USB řadič, protože ač má asi 8 usb portů, tak jen asi 2 použitelné USB 2.0 hosty a libovolné dvě kamery na jednom USB hostovi nejvyšší kvalitu nezvládnou. Co ale zjistil je to, že zvukový zdroj z těch kamer je extrémně zarušený (podle mě indukce z usb kabelu nebo rušení od optiky kamery).

[Bedňa]

Mne to príde, že všetko čo je postavené na nejakom univerzálnom princípe (Universal Serial Bus) fungaje všade rovnako dobre zle Farbu zvuku robia vyššie harmonické, na toto robí veľký vplyv mix a samozrejme RTkernel je nevyhnutnosťou.

[lertimir]

Souhlas, barvu zvuku tvoří vyšší harmonické, a navíc nejen jejich výkonnostní poměr, ale i přímo fázové posuny mezi základní vlnou a harmonickou, ale tohle počítač řeší jen jako matematický problém.

Se vzorků v časech t, t+đt, t+2đt, ..., vyrobí jinou sadu vzorků ve stejných (nebo případně jiných časech) na to RTkernel není třeba, jen výkon v závislosti na komplikovanosti převodu. A pak výsledné vzorky pošle do zvukovky a tam je samozřejmě kritické jak má stabilní hodiny a jak kvalitní A/D převodníky.

Ale já nehájím USB, mě taky vadí, že když jede USB disk naplno tak USB bere asi 30% výkonu jednoho jádra. Někdy v roce 2004 jsem si koupil externí DVD vypalovačku, která měla USB a FireWire připojení a to byl obrovský rozdíl v rychlosti stabilitě a zátěži. Na USB se mi mnohokrát stalo, že počitač nedodal data včas a vypalování šlo do burn-proof opravy.

[jas]

USB zvukovky sú shit :)

ehm, odac? testy

Samozrejme je k nemu potrebny este zosilovac, ale ten uz nema s usb v podstate nic spolocne.

[Václav "Darm" Novák]

Jo aha, takže USB zvukovky se nepoužívají v profi sféře… Sure, samej shit.

[kavol]

Jo aha, takže USB zvukovky se nepoužívají v profi sféře…

nic takovýho kolega neřeknul, tak trošku nedáváš implikaci

Sure, samej shit.

jak tak koukám, tak víceméně jo

[Václav "Darm" Novák]

Je fakt že velká část z uvedených není výkvět profi kvality, ale i tak je to vysoká úroveň. V profi audiu už jsem interní zvukovku neviděl dlouho. Buď USB, nebo Firewire. A proto je tvrzení „USB jsou shit a OSS se dělá primárně pro profi použití“ poněkud zcestné. Protože dělat se pro profi použití, USB zvukovky budou jedna z hlavních priorit, ne něco co podle toho co vidím má po několika letech status „experimentální podpora výstupu, žádná podpora vstupu“

Osobně bych byl nejraději za pořešené OSS a nad ním PA, ale bohužel v tomto stavu OSS je to pro mě nepoužitelné :/

[kavol]

Je fakt že velká část z uvedených není výkvět profi kvality, ale i tak je to vysoká úroveň. V profi audiu už jsem interní zvukovku neviděl dlouho.

a kdo říká, že by v profi audiu hledal interní zvukovku?

Protože dělat se pro profi použití, USB zvukovky budou jedna z hlavních priorit

goto #288

[MadCatX]

https://wiki.archlinux.org/index.php/PulseAudio/Examples#Surround_sound_systems

[paralen]

to neriesi moj problem

[Martin Matějek]

To je ten zvukový server, který nefunguje jako démon - hraje jen, když je uživatel přihlášený a stačí aby uživatel přepnul z Xorg do konzole (přes Alt+Ctrl+F*), případně z jedné konzole do druhé a přestane hrát? Vývoj PA nesleduju, ale když jsem se díval naposledy, podle vývojářů to tak bylo správně (a cokoliv jiného je špatně nebo to nikdo nepoužívá).

Dá se tedy PA použít pro headless server/XMBC?

[kavol]

proč přepínat do konzole, stačí pustit novou session ...

[Franta]

Zrovna Gnome 3 mi přijde dobré (pro určitou cílovou skupinu, do které sice nepatřím, ale smysl IMHO má), PA je věc, která mi prostě funguje, nemám s tím problém a přináší některé zajímavé vlastnosti. Na systemd mám zatím nevyhraněný názor. Ale to přesouvání binárek se mi nelíbí.

[pavlix]

Zrovna Gnome 3 mi přijde dobré

Mě přijde konceptuálně skvělé, provedení žádný zázrak, stabilita vývoje pod kritickou hranicí a komunikace směrem k širší komunitě na bodu mrazu.

[Petr Ježek]

Ač jsem opět rutinně upgadoval (-Syu) před přečtením si poznámky a skončil v grub rescue konzoli, odmítám trpět pocity a dojmy, které nemají opodstatnění. Závislosti jsou dané charakterem a systémovými vazbami balíčků (platforma, framework, DM...). Lze mít Arch bez nabubřelostí a z nich plynoucích závislostí. Systemd mi funguje k plné spokojenosti analytika od první konfigurace po přechodu ze sysvinit, nemám si na co stěžovat. O spouštění binárek po zřetelném oddělení userspace od systému v kernelu snad není třeba diskutovat, do /usr pochopitelně binárky přirozeně patří tím spíše, čím přesněji funguje systemd. Tomáši, co vám na vyjmenovaném vlastně vadí? Tradice jsou fajn, ale přešlapování na místě nemá s životem nic společného...

[trekker.dk]

Tradice jsou fajn, ale přešlapování na místě

... moc krásná ukázka zmrdispeaku. Nemáme dobrý důvod, proč něco udělat, použijeme frázi, která zní ošklivě.

Překlad tvé věty do češtiny:

Tradice jsou fajn, ale zbytečné rozbíjení věcí, které doteď bez problémů fungovaly, nemá s životem nic společného.

To už moc nezní...

[kolcon]

aha, Lennart... nejak mi nefunguje jeho a de Icazova voodoo panenka :(

[mankind_boost]

Try harder!

[mankind_boost]

Lennart vrací úder
A zase se rozbije miliarda věcí. Proč mám někdy pocit, že je placen konkurencí?

[David Watzke]

To by mě zajímalo co se rozbije. Používám to už pár dní a furt nic.

[mankind_boost]

Zkuste si něco zkompilovat sám - v polovině případů se to přesune blbě a tak ve 30% to dokonce přeruší make target. Nedej bože, když je něco někde napevno zadrátovaný (to aby se člověk hrabal v kódu).

A hlavně: /usr vzniklo z jistých důvodů.

[MadCatX]

Ale kolik z těch důvodů pro vznik /usr má dneska skutečné opodstatnění? Napadá vás nějaký neobskurní případ, kdy má smysl mít /usr/bin jinde než /bin? Jak je již zmíněno na jiném místě v diskusi, systém bez připojeného /usr je stejně nepoužitelný.

Co by se při kompilaci mělo rozbít? Arch adresáře /bin a /sbin nezrušil úplně, jen z nich udělal symlinky na /usr/bin. Pokud je nějaký program tak fundamentálně zbastlený, že mu toto vadí, nebude progresivnější to opravit spíš než udržovat toto staré schéma adresářové struktury?

[mankind_boost]

Tak prosím, opravte stovky programů a knihoven
Mimochodem, znáte to Linusovo pravidlo, že kdyby nějaká oprava chyby něco rozbila, tak ji raději zahodí?

Krom toho to sjednocení /bin a /usr/bin nic dobrého nepřináší.

[Jiří Hubka]

+1 Bohužel musím s Archem skončit, škoda, ale poslední dobou to byl samej trabl. :(

[Petr Ježek]

Jsou snad symlinky místo adresářů hellhacky? Opravovat se může díky nim dlouhodobě. Vaše poslední věta je pak z říše ideologií.

[mankind_boost]

Tak mi řekněte, co dobrého to přináší? Že pár frikulínů si už nebude muset pamatovat, k čemu je /bin a k čemu /usr/bin?

[kavol]

Jak je již zmíněno na jiném místě v diskusi, systém bez připojeného /usr je stejně nepoužitelný.

ano, oblíbená Lennartovská lež ...

Arch možná, ale RHEL jsme na základě reálných požadavků zákazníků opravovali, aby bez namountovaného /usr použitelný byl

[pavlix]

To je ten smutnější příběh.

[little.owl]

Pokud tomu tak je, nazval bych to pruser.

[pavlix]

Tohle opravdu nesleduju a vlastně to ani nechci vědět. Ale mám dojem, že to bude jeden z těch menších průserů.

[MadCatX]

Co v tomto případě znamená použitelný? Že je možné spustit diagnostické a konfigurační nástroje, pomocí kterých se ten /usr připojí? Mimochodem, pokud RHEL potřeboval opravit, aby toto vůbec fungovalo, nenaznačuje to něco o tom, jak často je tato možnost využívána?

Nechci tvrdit, že se pro oddělený /usr nedá nalézt use-case (use-case se dá vymyslet na leccos, když se člověk snaží ), zároveň ale nevidím důvod, proč by tento historický relikt měl být standardem u desktopových dister.

[pavlix]

Mimochodem, pokud RHEL potřeboval opravit, aby toto vůbec fungovalo, nenaznačuje to něco o tom, jak často je tato možnost využívána?

Pokud něco nefunguje, tak to sice znamená, že to nikdo nepoužívá, ale neznamená to, že by to nikdo nepoužíval, kdyby to fungovalo.

zároveň ale nevidím důvod, proč by tento historický relikt měl být standardem u desktopových dister.

Mně osobně taky přijde zbytečné se upínat na kombinaci odděleného /usr a provozu bez initramfs (v rámci initramfs lze toto samozřejmě řešit), takže mi usrmove konceptuálně vyhovuje.

Beru ho jako takový cleanup. Jediné, co mi nevyhovuje je jako obvykle provedení, kdy se bez pádného zdůvodnění přidělá práce hromadě lidí. Jo, kdyby organizátoři usrmove dokázali odhadnout, otevřeně sdělit a zajistit i tu práci s tím spojenou (jinak než „máte to rozbité, opravte si to“), to by bylo jiné kafe.

[petr_p]

Fakticky se /bin přesunul do initramdisku. Dneska na Fedoře už obsahuje i kopii systemd, což skýtá mnohé přiležitosti pro milovníky adrenalinu, když v systému upgradujete systemd na verzi, která není kompatibilní s tou v initramdisku.

[pavlix]

Fakticky se /bin přesunul do initramdisku.

V rámci usrmove nikoliv. Roky jsem používal rootfs na LVM, tudíž jsem měl na initramfs stejné požadavky jako někdo, kdo by chtěl dnes provozovat /usr na LVM. Spíš bych řekl, že se odstranilo řešení, které bylo používané velmi malou částí uživatelů. To může být obecně dobrý i špatný krok.

Dneska na Fedoře už obsahuje i kopii systemd

Vhledem k tomu, že systemd obsahuje mimojiné i init, tak je to nutnost.

když v systému upgradujete systemd na verzi, která není kompatibilní s tou v initramdisku.

To může být legrace :). Tak nějak si říkám co má být co systemd nekopatibilní s tím s initramfs.

[Tomáš Bžatek]

LOL!

[little.owl]

když v systému upgradujete systemd na verzi, která není kompatibilní s tou v initramdisku.

Rozbita zpetna kompatibilita?

[Petr Ježek]

No já jsem příkladem, že jsem "to měl rozbité" čistě vinou vlastní lenosti a nerespektování veřejně doporučeného postupu. Děkuji za takové kopance a slibuji, že zase asi tak dva roky si dám na čtení novinek na archlinux.org pozor. Trochu mne rozhodila ta velká voda...

[pavlix]

Popravdě řečeno jsem neměl ani tak namysli problémy na straně uživatelů jako na straně packagerů.

[kavol]

Co v tomto případě znamená použitelný? Že je možné spustit diagnostické a konfigurační nástroje, pomocí kterých se ten /usr připojí?

ano, přesně tak, že zajistí prostředí, které je schopno /usr připojit

Mimochodem, pokud RHEL potřeboval opravit, aby toto vůbec fungovalo, nenaznačuje to něco o tom, jak často je tato možnost využívána?

nikoli, naznačuje to pouze to, jak mizerně je RHEL testován, resp. že i do něj se zavlékají chyby - když budeš, cojávím, třeba měnit kola na autě, a teprv po vyjetí z garáže zjistíš, že potřebujou dofouknout, svědčí to o tom, že s tím autem (resp. na té sadě kol) málo jezdíš, anebo tedy spíše o tom, že sis zavlekl chybu (nasadil nenahuštěná kola) a selhal v procesu kontroly (zapomněl změřit tlaky a dofouknout před vyjetím)?

Nechci tvrdit, že se pro oddělený /usr nedá nalézt use-case (use-case se dá vymyslet na leccos, když se člověk snaží ), zároveň ale nevidím důvod, proč by tento historický relikt měl být standardem u desktopových dister.

to já zase tedy nevidím důvod pro jiné "historické relikty", na kterých se tvrdě lpí, nicméně to není podstatné, důležité je, že nechápu, jaká pozitiva by to tedy mělo přinést - co se pro to desktopové distro změní přesunutím pár souborů a změnou několika adresářů na symlinky?

[Petr Ježek]

Možná tím, že pro vývoj se změť adresářů s binárkami změní v jediný path? nejde jen o to, jak desktopové distro funguje, ale také o to, jak je vývoje schopné...

[kavol]

Možná tím, že pro vývoj se změť adresářů s binárkami změní v jediný path?

pardon, ale této větě nerozumím?

nejde jen o to, jak desktopové distro funguje, ale také o to, jak je vývoje schopné...

jelikož i balíčkuju, tak o systémových cestách trošilinku tuším, a opravdu nemám pocit, že by jejich rozdělení jakkoli překáželo vývoji ...

[Petr Ježek]

Ech, když píšete kód spouštějící nějaké binárky, co je pro vás snazší - pracovat s několika různými adresáři s možností různého umístění na discích nebo s jediným? V balíčkování nemáte problém se závislostmi a jejich kontrolou? A co portace na různé platformy - ani tam není problém s množstvím adresářů? Systémové cesty jsou zajímavé tím, že mohou procesy po nich běhající urychlit nebo zpomalit a současně mohou zjednodušit nebo zkomplikovat jejich údržbu. A pak je tu pojetí userspace... Opravdu nevím, v čem je jediný /usr/bin skutečně horší než předchozí stav. Ale nejsem neomylný ani vševědoucí :)

[pavlix]

Ech, když píšete kód spouštějící nějaké binárky, co je pro vás snazší - pracovat s několika různými adresáři s možností různého umístění na discích nebo s jediným?

1) Pokud spouštím něco cizího a nechci do detekovat během kompilace, je nejlepší cestou to volat bez cesty, prostým jménem, a spoléhat na proměnnou prostředí $PATH, popřípadě pokud očekávám její debilní nastavení. Pokud je to něco systémového, tak bych radši volil rovnou #2.

2) Závislosti je nejlepší detekovat během konfigurace buildsystému, tedy během ./configure či ./autogen.sh. Pak je mi úplně jedno, jestli do seznamu cest přidím jednu nebo dvě navíc.

Navíc tento problém už je řešený z důvodu nekompatibility distribucí i v jiných oblastech souborového systému (libexec budiž příkladem), takže krok typu protlačíme usrmove do Fedory není řešením. Jediným řešeným by byla diskuze mezi distributory a vytvoření nového plošného standardu, kterým se všichni budou řídit. Popřípadě by dokument měl mít nějakou přílohu s konkrétními připomínkami a plánovanými výjimkami distribucí, které se z nějakého důvodu nechtějí něčemu podvolit.

Opravdu nevím, v čem je jediný /usr/bin skutečně horší než předchozí stav.

V tom, že samotný usrmove (dle slov mnoha packagerů a adminů) rozbil hromadu věcí, zatímco organizátoři tvrdili, že to nic nerozbije. Nakonec si to všichni opraví a administrátoři zvolí například řešení s initramfs.

Výsledkem tedy není žádná trága, ale dá se říct za hodně peněz ukrutně málo muziky.

[kavol]

Ech, když píšete kód spouštějící nějaké binárky, co je pro vás snazší - pracovat s několika různými adresáři s možností různého umístění na discích nebo s jediným?

hm, aha ... tak tedy za prvé k tomu předchozímu neporozumění, ono se to ale právě v "jediný" nezmění

a za druhé, jak již naznačil kolega, nepotřebuju pracovat s nějakými adresáři

V balíčkování nemáte problém se závislostmi a jejich kontrolou?

občas mám, ale nikoli kvůli cestám

A co portace na různé platformy - ani tam není problém s množstvím adresářů?

poslyš, slyšel jsi někdy třeba o cmake nebo autotools?

Systémové cesty jsou zajímavé tím, že mohou procesy po nich běhající urychlit nebo zpomalit a současně mohou zjednodušit nebo zkomplikovat jejich údržbu.

tuto vznešenou myšlénku jaksi nechápu ... jakože nějaký adresář budu mít namountovaný z rychlejšího disku a jiný z pomalejšího apod.?

A pak je tu pojetí userspace...

hm, tak jestli jsem teď napsal, že něco nechápu, tak tady už mě napadá jen něco o fakt dobrym matroši ...

Opravdu nevím, v čem je jediný /usr/bin skutečně horší než předchozí stav. Ale nejsem neomylný ani vševědoucí :)

prosím, nedělej ze sebe až takového debila, děkuji

[Petr Ježek]

+1

[kavol]

To by mě zajímalo co se rozbije.

hm, žeby separátní mountování /usr?

Používám to už pár dní a furt nic.

kolik používáš serverů s obskurními uložišti, kterým nestačí jaderné ovladače?

[David Watzke]

hm, žeby separátní mountování /usr?

OK, to je pravda. Ale neumím si představit use-case pro něco takového (a když už, asi by tam zrovna neběželo desktopový distro jako je Arch) - obsah /usr bývá dost závislý na ostatních adresářích a nevidím důvod pro jeho separaci.

kolik používáš serverů s obskurními uložišti, kterým nestačí jaderné ovladače?

Žádný, ale to mi přijde taky slušně okrajové... Spravuju stovky serverů, ale tohle jsem neviděl.

[taz]

Jestli nic jiného pořád oddělený /usr brání fragmentaci souborů důležitých pro boot a to je pro desktop dost zajímavá vlastnost. Takhle máš po pár aktualizacích třeba jaderné moduly kdoví kde. Ovšem možná to ty lišky podšité dělali ssdčkům na míru, jakože pro budoucnost. Haha, právě jsem řekl vtip...

[pavlix]

Tak rychlost bootu se systemd se tradičně testuje jen na SSD, že :). A kdo si na desktop SSD nepořídí, ten ho prostě mít rychlý nechce :D.

[kavol]

ehm

[kavol]

obsah /usr bývá dost závislý na ostatních adresářích

asi nerozumím, na čem by jako /usr mělo záviset?

a nevidím důvod pro jeho separaci.

třeba že může být read-only, narozdíl od takového /var?

kolik používáš serverů s obskurními uložišti, kterým nestačí jaderné ovladače?

Žádný, ale to mi přijde taky slušně okrajové... Spravuju stovky serverů, ale tohle jsem neviděl.

okrajové != nevýznamné

kolik z těch tvých serverů je něco jiného než x86?

když se tu budeme bavit dejme tomu o vybavení DreamWorks (jen ilustračně, nevím jaké konfigurace používají), kolik takových instalací po světě je, to je přece úplně okrajové, ne? - takže jim to v klidu rozbijeme, ať si radši nakoupí stejný hardware jako má Lennart, na tom bude systém chodit, nebo to úplně zabalí, koho zajímá nějakej Shrek, že?

[David Watzke]

obsah /usr bývá dost závislý na ostatních adresářích

asi nerozumím, na čem by jako /usr mělo záviset?

No na zbytku systému. Myslel jsem tím to, že třeba nelze používat stejný /usr v Ubuntu a v Archu.

a nevidím důvod pro jeho separaci.

třeba že může být read-only, narozdíl od takového /var?

Ok, to je dost netradiční požadavek, ale určitě to nejde nějak udělat, aby se při early bootu připojil / a do něj read-only /usr a pak to nabootovalo (se systemd)?

A především: pokud máš velmi specifický požadavky, bývá běžný, že budeš používat dost specifické řešení. Vím, že ty to asi vidíš jen jako když ti někdo hází klacky pod nohy, ale kvůli tomu tyhle věci nevznikaj. Kdyby se totiž vždycky hledělo úplně na každou prkotinu, tak se nikdy nikam vývoj nepohne.

PS: zrovna DreamWorks asi bude mít peníze na to zaplatit jednoho admina, aby jim připravil systém.

[pavlix]

Kdyby se totiž vždycky hledělo úplně na každou prkotinu, tak se nikdy nikam vývoj nepohne.

Otázka je, zda ten vývoj přinesl taky nějaká významná pozitiva, když už se tu diskutují negativa.

[David Watzke]

To je dobrá otázka. Nebudu tu řešit systemd, ale jen téma zprávičky.

U toho přesunu binárek mě napadají dvě výhody (kvůli kterým bych ho osobně ale stále nerealizoval): Za prvé se sníží počet "základních" adresářů v PATH, takže se to bude procházet o chlup rychleji. Za druhé se konečně budeme moci spolehnout na umístění "env" (ale i dalších nástrojů) při psaní shebangů ve stylu "#!/usr/bin/env python3". Přišel bych asi i na další, ale nechce se mi nad tím teď přemýšlet

[pavlix]

Za prvé se sníží počet "základních" adresářů v PATH

To není funkční výhoda, ale pouhý úklid (cleanup). Úklid by se měl typicky plánovat tak, aby co nejméně narušil provoz a aby všichni byli včas informovaní o změnách, které jsou pro ně nějak zásadní.

takže se to bude procházet o chlup rychleji

Optimalizace s prakticky nulovým efektem? To stejné, co výše.

Za druhé se konečně budeme moci spolehnout na umístění "env"

Zrovna to použití env, které máš namysli je ošklivý hack, který jen obchází neschopnost jiných nástrojů, ale co už.

(ale i dalších nástrojů) při psaní shebangů ve stylu "#!/usr/bin/env python3".

Snad jediná věc, o které má smysl se bavit. Nicméně tohle by se stejně nejlíp vyřešilo podporou "#!python3". A pokud jde o samotné env, tak na jeho vyřešení stačí jeden blbý symlink, který je zadarmo.

Takže pokud vezmu jenom ta pozitiva, co jsi uvedl ty, tak ta jsou nesporná, nicméně jejich význam je minimální. Férový člověk by změnu takto prezentoval a riskoval, že se setká s odmítnutím. Myslím si, že to L. dobře věděl a proto zvolil taktiku, která maximalizovala úspěch, protože on už se rozhodl a ostatní nejsou zajímaví (tedy kromě těch, kdo automaticky souhlasí).

[David Watzke]

Souhlasím s celým tvým komentářem, tak není co řešit

[David Watzke]

Ok, to je dost netradiční požadavek, ale určitě to nejde nějak udělat, aby se při early bootu připojil / a do něj read-only /usr a pak to nabootovalo (se systemd)?

Tak teď jsem se dočetl, že to tak na Archu je (/usr se připojuje z initramfs).

[pavlix]

Finální problém s usrmove po vyřešení všech těch drobností okolo se bude týkat jenom odpůrců initramfs.

[kavol]

obsah /usr bývá dost závislý na ostatních adresářích

asi nerozumím, na čem by jako /usr mělo záviset?

No na zbytku systému. Myslel jsem tím to, že třeba nelze používat stejný /usr v Ubuntu a v Archu.

hm, myslel jsem, že se bavíme o jednom systému - jinak je to argument asi jakože ten /usr nemůžeš použít ve Windows ...

a nevidím důvod pro jeho separaci.

třeba že může být read-only, narozdíl od takového /var?

Ok, to je dost netradiční požadavek, ale určitě to nejde nějak udělat, aby se při early bootu připojil / a do něj read-only /usr a pak to nabootovalo (se systemd)?

promiň, ale ty tvoje "tradice" mi už fakt lezou krkem - svět opravdu nekončí u tvojeho desktopu a "stovek serverů" které spravuješ

tuhle možnost svého času využíval třeba projekt Kiosk a vůbec je to oblíbené u některých "polotlustých" klientů (nevim, jak se ta kategorie správně jmenuje, hledat jsem líný)

A především: pokud máš velmi specifický požadavky, bývá běžný, že budeš používat dost specifické řešení.

hm, takže máme nějaké řešení, které si v klídku používají všichni, a nahradíme ho řešením, které může používat "většina", aby ti "specifičtí" najednou museli zavádět "specifická řešení", když jim doteď stačilo to obecné?

Vím, že ty to asi vidíš jen jako když ti někdo hází klacky pod nohy, ale kvůli tomu tyhle věci nevznikaj.

ještě jsem se nedozvěděl, kvůli čemu to tedy vzniká, pomineme-li Lennartovo ego?

kvůli těm pochybným výhodám s minimálním efektem, které jsou dalekosáhle převáženy nevýhodami, které už stály (deseti?)tisíce člověkohodin práce navíc?

Kdyby se totiž vždycky hledělo úplně na každou prkotinu, tak se nikdy nikam vývoj nepohne.

... jak nám denně Linus se svým pravidlem nerozbíjení existujícího dokazuje, že?

PS: zrovna DreamWorks asi bude mít peníze na to zaplatit jednoho admina, aby jim připravil systém.

to jako že kdo má peníze, tak je automaticky musí chtít vyhodit pro nic za nic, když by je vyhazovat nemusel, kdyby se nějakej exot nerozhodl všechno bezdůvodně překopat?

a co ti, co na toho admina nemají?

[David Watzke]

Ještě bych chápal remcání kolem systemd, protože jste zkostnatělý učit se něco novýho (a je to navíc v některých věcech fakt pošahaný), ale to jestli je /bin symlink nebo adresář a jestli mám binárky v /usr nebo ne, to mi fakt nepřijde podstatný... Je to sice IMHO zbytečná změna, kterou bych osobně nedělal, ale je mi to úplně jedno.

Ukázkou debilní změny je rozdíl mezi Win 7 na Win 8 a ne takovejhle detail.

[rADOn]

Jinak řečeno – já to nepotřebuju a zbytek světa ať si políbí… Je smutný že si ani neuvědomuješ jak přesně jsi předvedl Lennartův problém.

[mankind_boost]

+1000000!

[Petr Ježek]

Mám být zvědavý na to, co potřebujete vy a co vám symlink nanabídne? O druhých někteří soudí řádově snadněji a ochotněji než o sobě...

[pavlix]

Mám být zvědavý na to, co potřebujete vy a co vám symlink nanabídne?

To už se snad dá považovat za základní znalost, alespoň po přečtení zbytku této diskuze nebo čehokoli na toto téma.

[mankind_boost]

*facepalm*

[rADOn]

Co třeba opravit rozbitý sw raid? To je při dnešní spolehlivosti disků celkem "oblíbená" činnost. Matlat se s tím v initrd, to jí na oblibě hodně přidá…

[Rezza]

No neveril bys, kolik veci to rozbilo a ze na bugy s tim spojene narazime porad :)

[kralyk z abclinuxu]

+1

[mirec]

Snívam ...

Snívam o tom, že reaz updatnem arch a nič sa mi nerozbije. Mám za sebou 2 roky používania archu a ešte sa mi nestalo, že by po update niečo neprestalo ísť ...

[David Watzke]

Já používám už tři roky arch [testing] a je vcelku rarita, když se mi tu něco podělá. Když už, bývá to trivální opravit.

[otula]

s/tři/sedm +1

[Václav "Darm" Novák]

+1. 7 a jediné pořádné rozbití byl první update z postaršího instalačního obrazu, kdy jsem ještě nevěděl že se vyplatí sledovat co to při update napíše :)

[Petr Ježek]

+moc

[MilanK]

No, ale právě proto Arch používáme, ne? Není to krásný pocit, když se to zase podaří rozchodit?

[stativ]

To bude rukama. Používám Arch asi tak 5 let a za tu dobu se mi rozbil jen dvakrát a pokaždé to bylo kvůli mirroru, který měl aktuální jen část repozitáře. Stačilo počkat pár hodin, aktualizovat a vše běželo. Akorát člověk musí vědět, co za změny daný update přináší.

[mirec]

Mne napríklad momentálne nefunguje vôbec podpora png v gimpe (dosť zásadná vec). Riešenie je update gimpu ... na ktorý si netrúfam. Nemám tu v práci žiadne zariadenie z ktorého by som núdzovo mohol nabootovať okrem siete a ... po posledných celodenných problémoch s presunom /usr/lib si viem predstaviť ako to dopadne zase s týmito adresármi. Takže podčiarknuté a spočítané kašlem na png ako formát kým mi nedonesie bootovacie USB.

[stativ]

To skoro zní, jako bys dělal jenom partial updates. V tom případě bych se nedivil, že to máš pořád rozbité. GIMP používám celkem často, a na problém s PNG jsem nenarazil.

[Petr Ježek]

Installation CD...

[mirec]

To mám síce ešte na stole, ale už ho nemám kam strčiť :'(

[Admin]

Your answer is Debian

[mirec]

Vidím to skôr na inštaláciu gentoo (síce v práci je to trochu ehm ... ale na druhej strane posledných 7 rokov na gentoo neriešim problémy, jednoducho funguje.

[anonymous_coward]

Tak nějak. U Archu je nahrazeno zdržení při kompilaci sadomasochistickými updaty, které zaberou blíže neurčený časový úsek – ale hlavně, že je nyní v módě .

[Petr Ježek]

Mně moje osobní chyba při updatu ohledně /usr stála deset minut. Kdybych chvíli počkal a lépe četl info, problém neexistuje. Se systemd jsem neměl absolutně žádný problém, s grubem2 opět jen malý díky vlastní pitomosti. Arch není pro lemply...

[mrv]

to bude dobry, maminka s te pohladi a s tim zlobivim archem to vyridi tatinek ;)

[rADOn]

Jestli si myslíš že v gentoo nejsou žádné sado-maso updaty tak se šeredně mýlíš. libpng rozbíjí systém celkem pravidelně, upgrade gcc nebo libc dost připomíná ruskou ruletu a se vzájemně se blokujícími balíky qt jsem se navztekal bmw mluvit. Kdyby to nebyl nejlepší systém tak bych ho snad ani nepoužíval :-P

[mirec]

Neviem ako je to s emerge, ale paludis updaty nerozbíja. Ak sa mi napríklad updatne libpng zostane v systéme staršia verzia, takže sa programy linkované so staršou verziou nerozbijú. Keď už na ňu nie je nič linkované jednoducho sa odstráni.

[Václav "Darm" Novák]

Hmm, sadomasochistickými updaty… To jsem tak občas mrknul od Serious Sam 3 na druhý monitor jak se mi tam sypou nové balíčky, pak odinstaloval consolekit kterej ani nevím proč tam mám, ale blokoval zbytek updatu, provedl cvičný restart abych věděl že je vše v pořádku a vesele pokračoval v likvidaci emzáků. Sadomaso na 3 minuty.

A to mám plno věcí z AUR, překvapivě žádný problém.

[Josef Kufner]

Hm. Na Androidu se tohle jmenuje /system. Root je nějaký pseudo filesystem v paměti a /system je readonly partition. Upgrade systému ve stylu "přeplácneme novým imagem" nechávám dělat každou chvíli a ještě se to nepodělalo.

Jediné, co mne napadá, že by to rozbilo je, když je /usr na síti a síť nejde. Nenapadá mne ale, proč bych v takovém případě nedal na síť i / – ten počítač bude bez sítě nepoužitelný tak jako tak.

Může se rozbít ještě něco?

[kavol]

Nenapadá mne ale, proč bych v takovém případě nedal na síť i / – ten počítač bude bez sítě nepoužitelný tak jako tak.

no, tak třeba proto, že / ti umožní vůbec tu síť připojit?

[Dr. Eddy]

na pripojeni site nepotrebujes /, ale staci ti initramfs, ne?

Zatim jsem nevidel poradnej argument, proc je slouceni spatne. Jen samy kecy, ze to zakaznici RH _vazne_ _nutne_ a _bezpodminecne_ potrebuji.

[mankind_boost]

https://www.abclinuxu.cz/zpravicky/arch-linux-presouva-soubory-z-bin-sbin-a-usr-sbin-do-usr-bin/diskuse#45

[taz]

To si myslíš jenom proto, že se Ti to ještě nikdy nerozbilo. Fixovat systém z initramfs je pro admina největší trest. Kvůli téhle pohromě proteče ještě hodně slz. Drobná náplast pro mazáky na tuhle ránu může být snad jenom fakt, že zobáci ani lepší stav nepoznají, nebudou tedy trpět tak moc.

A co se argumentů týká, tak hlavně zatím nikdo nepředhodil žádný argument, proč je sloučení dobré nebo potřebné. Celé to proběhlo jenom na základě lží o kompatibilitě (s čím?) a lží o celé distribuci na jednom svazku. Distribuční balíčky ovšem mají své soubory taky v /etc nebo ve /var, žádné vylhané sdílení /usr se tak nemůže na systémech podobných Fedoře konat. O lži, že můj odjakživa oddělený /usr "už dávno nefungoval" se mi nechce skoro zmiňovat.

[pavlix]

A co se argumentů týká, tak hlavně zatím nikdo nepředhodil žádný argument, proč je sloučení dobré nebo potřebné. Celé to proběhlo jenom na základě lží o kompatibilitě (s čím?) a lží o celé distribuci na jednom svazku. Distribuční balíčky ovšem mají své soubory taky v /etc nebo ve /var, žádné vylhané sdílení /usr se tak nemůže na systémech podobných Fedoře konat. O lži, že můj odjakživa oddělený /usr "už dávno nefungoval" se mi nechce skoro zmiňovat.

Jo, ta argumentace byla debilní, ale mnoho lidí to nemělo šanci poznat a chytili se, včetně mě.

[kavol]

na pripojeni site nepotrebujes /, ale staci ti initramfs, ne?

a na co initramfs, když mám / ?

to, že se Fedora rozhodla posunout o léta zpátky, do dob, kdy po každém updatu kernelu muselo být znovu puštěno lilo, a vynahrazuje si to pouštěním dracutu či jak se ten krám jmenuje a místo prostého updatu konfigurace rovnou sestavuje celý minimální systém, ještě neznamená, že to tak chtějí všichni

Zatim jsem nevidel poradnej argument, proc je slouceni spatne.

kup si brejle :-p

především, je to změna - takže by tu měly být argumenty proč ji dělat, nikoli proč ji nedělat

Jen samy kecy, ze to zakaznici RH _vazne_ _nutne_ a _bezpodminecne_ potrebuji.

chápu, že pro mladé úspěšné frikulíny jsou některé enterprise záležitosti asi tak reálné, jako Paroubkovi marťani, nicméně narozdíl od těch marťanů jde o reálný problém

[Conscript89]

A ramdisk to nezvladne?

Pokud bych mel mit ale system (storage) na siti, tak bych to resil pomoci iBFT (iSCI).

[rADOn]

A ramdisk to nezvladne?

To máš asi tak – Kay & co. tvrdí že problémy spojeného /usr vyřeší ramdisk. Šťouralové tvrdí, že problémy s ramdiskem vyřeší oddělený /usr.

(disclaimer: já bootování skrz initrd nemám rád, takže jsem Štoural)

[pavlix]

Šťouralové tvrdí, že problémy s ramdiskem vyřeší oddělený /usr.

Jsou šťouralové a šťouralové, že. Jedni jenom šťourají, druzí jsou schopni i předložit relevantní argumenty ;).

[rADOn]

Zatím nejčastější argument pro spojení je "já to nepotřebuju". Ani v tom Kayově pamfletu se nic moc navíc nepíše.

Ja ti klidně jako argument nastřelím budoucí vývoj:

1. Fedora, Arch & spol. přechází na sloučený /usr. Říkejme jim Spojenci.
2. Spojenci zjišťují že věci jako kryptování a raidy nejdou po sloučení provozovat a že bez ramdisku nenabootují. (Lennart to přiznává už teď).
3. Spojenci zjišťují že nouzová obnova čehokoliv co se oživuje z ramdisku je neskutečný oser. Často nezbude než ručně projít procesem linuxrc a připojit si kořenový filesystém, aby se člověk dostal k potřebným nástrojům.
4. Do initrd začnou probublávat nástroje z userspace.
5. V initrd už je dost mocné prostředí, aby šlo některé opravy (obnova zavaděče, fsck…) dělat automaticky nebo aspoň nějak přiměřeně user-friendly klikačně. Samozřejmě to má tu a tam nějakou závislost.
6. Spojenci si začínají uvědomovat že initrd o velikostech v řádu desítek až stovek mega není úplně to pravé ořechové. Canonical oznamuje vlastní nekompatibilní řešení.
7. Udržovat dvě instance takové hromady kódu začíná být neúnosné, vznikají projekty na instalaci balíčků do prostředí initrd. Je patrná snaha aby nástroje v userspace i v ramdisku byly stejné, i za cenu dalšího přifouknutí initrd.
8. Někoho napadne, že když neudělá pivot_root ale rovnou připojí /var a /etc tak má použitelné prostředí pro embeded nebo nějaký set-top-box nebo tak něco. Doinstalovat do toho X nebo apače na klikací UI je piplačka ale jde to. Myšlenka se rychle šíří a progresivnější distra aktivně podporují možnost nainstalovat do initrd cokoliv se vejde do ramky.
9. Vzniká nová generace "live" dister které jsou jen soubory balíčků v initrd který lze nakopnout různými exotickými způsoby. Při potřebných úpravách balíčků vývojáři často vycházejí ze starých speců z dob odděleného /usr. Bystřejší si uvědomují, že něco je špatně.
10. Fedora oznamuje kontroverzní změnu – nepivotuje se na kořenový fs, ale jen se z něj bindnou potřebné adresáře na správná místa. Díky tomu nebude potřeba udržovat zvláštní balíky pro initrd což ušetří ohromnou spoustu práce.
11. Odpůrci této změny zahajují konkurenční projekt: když rozbalí obsah ramdisku na vlastní oddíl, dá se z něj nabootovat. Věci nesouvisející s bootovacím procesem zůstanou oddělené, aby je šlo dát na šifrovaný oddíl, raid nebo připojit přes síť…

Je to samozřejmě fikce, počítám že v reálu někdy kolem čtvrtého nebo pátého bodu Linus někoho epicky zjebe, gentoo oznámí konkurenční projekt a celé to vyšumí.

[pavlix]

Jo, z toho, co píšeš je zřejmé, že víš o čem mluvíš, i když samozřejmě zahrnuješ nejen fakta, ale i subjektivní hodnocení. Takže snad jen pár opravdových drobností:

4) Potřebné nástroje už tam jsou. Je možné, že se přidají další, ale pravděpodobně se budou alespoň částečně odlehčovat.

5) Pokud jde o automatický fsck, tak ten tam pokud vím je.

6) Beru jako vtip, i když je pravda, že v Canonicalu pár lidí tenhle tímhle typem smyslu pro humor disponuje.

8) Do jisté míry už se používá.

9) Live media ve formě initramdisku jsou běžná věc.

10) Na embedded se často k read-only image přidává overlay. Má to mimo jiné i tu výhodu, že se základní image nemění a tím třeba OpenWRT zajišťuje reset celé instalace.

11) Už se používá. Některé embedded distribuce potřebují různě patchované jádro, takže je přinejmenším nepraktické ho nahrazovat jádrem z běžné distribuce. A přitom zbytek té distribuce lze normálně normálně používat přes pivot_root třeba z externího harddisku. Typický postup pro spuštění Debianu nad polouzavřeným linuxovým embedded systémem.

Takže jsi vlastně předpověděl minulost ;). Dobré na tom je to, že s tím vším už jsou zkušenosti, takže pokud bys měl zájem v některé distribuci tlačit (alespoň jako alternativu) svoji cestu, tak už ji máš vyšlapanou.

[rADOn]

Já vím že se různé věci takhle už používají, některé používám sám. Právě proto jsem to tak napsal aby můj hypotetický scénář byl co nejméně hypotetický. Pointa je, že na konci máš situaci funkčně ekvivalentní oddělenému /usr. Kruh se uzavírá, a kromě nějakých kosmetických změn a spousty zbytečné práce se nic nestalo.

[pavlix]

Zas na druhou stranu musíš přiznat, že ten průběh už hodně reflektuje tvoje představy a přání. Ve skutečnosti se podle mě budou všechny tyhle body prolínat a budou se pořád v různých situacích používat různé techniky.

A kdyby se read-only image, ať už nahrávané bootloaderem, kernelem nebo čímkoli, osvědčily, tak mně osobně to nijak nevadí. Ale chápu, že jiní můžou mít jinou představu.

[rADOn]

Jasně, psal jsem rovnou že je to fikce. Nebylo mým záměrem linkovat budoucnost, ale ukázat na bod ke kterému ta budoucnost bude nějak konvergovat. Sloučení /usr tak jak je prezentovaný sice uklízí bordel (a to je chvályhodné) ale neřeší důvody které k jeho oddělení v první řadě vedly. Oddělený /usr to řešilo, takže si myslím že to je ten bod ke kterému to bude směřovat, byť to ve výsledku může vypadat úplně jinak.

[pavlix]

V tom případě jsme ve shodě.

[Josef Kufner]

Připojení k síti obstará už BIOS, když stahuje přes TFTP jádro a initrd. Když se pak mountuje /, tak máme DHCP klienta v jádře. Leží mi tu v šuplíku kus železa, kde jediné perzistentní úložiště je CMOS BIOSu na základní desce a jak krásně umí nabootovat

[pavlix]

Připojení k síti obstará už BIOS

To sice jo, ale jak? Majitelé linuxových strojů (často) chtějí jednotné, dynamické a plně funkční síťování, ne nějaké biosové hacky, aby se dal stáhnout image.

tak máme DHCP klienta v jádře

Moc informací o tom nikde není, takže citation needed, protože ve zdrojácích kernelu nic s dhcp v názvu nevidím, a pokud to existuje, tak to zřejmě to naštěstí nikdo moc nepoužívá.

Cpát takovéhle věci do kernelu je dost jalový nápad. Má to samé nevýhody a žádné výhody. DHCP klient potřebuje ke své práci jednu jedinou věc, a to je AF_INET/AF_INET6 UDP socket. Pokud si DHCP klient navíc hraje na konfiguračního démona, tak ještě NETLINK socket (+pár hacků na nedostatky netlinku).

To nemůže dopadnout jinak než blbě a to se přesně stalo s kernelovou podporou autokonfigurace IPv6.

[petr_p]

DHCP (nejen) klient v jádře je (IP_PNP_DHCP) a používá se právě v případě, že kořenový souborový systém je na síti. Můžeš si připsat čárku, já to takto na některých zařízeních taky používám.

[pavlix]

Tak už mám jednu čárku ;). Já bych asi za většiny okolností dal přednost konfigurace z initramfs, které mimochodem může jít rovněž ze sítě. Dá se tam mnohem víc kouzlit a není kvůli tomu potřeba zasahovat do jádra. Je nějaký důvod, proč ti IP_PNP_DHCP přijde vhodnější?

[Petr Ježek]

Přesně tak. Vypadá to, že svět se začíná dělit na ty, co síť používají a ty, co s ní administrují systém. V této diskusi je to o "líbí-nelíbí", vskutku silná argumentace :)

[pavlix]

Nerozumím řeči tvého kmene. Nicméně důvody pro omezování zasírání kernelu zbytečnostmi (rozuměj věcmi, které můžou stejně dobře fungovat v userspace) jsem snad podal dostatečně jasně. Pokud ne, rád doplním.

[petr_p]

Který firmware umí vedle jádra stáhnout i initramdisk? Kam se v DHCP zapisuje název initramdisku? Co vím, tak ve světě x86 musíš nejprve vložit další vrstvu zvanou PXE. Co když nemáš x86? Přibalíme initramdisk za obraz jádra? To pak budu při změně konfigurace přebalovat initramdisk (a pak ještě obraz jádra)? Prostě v určitých případech je život bez initramdisku jednodušší, na serveru máš obsah klientského kořene hezky přístupný ve VFS. Na vývoj, kdy potřebuješ každou chvíli přebootovat, neocenitelné.

[pavlix]

Který firmware umí vedle jádra stáhnout i initramdisk?

Triviálně každý, protože initramdisk jde přibalit k jádru. Ve skutečnosti se ale většinou stahuje initramdisk samostatně a používá se k tomu PXELINUX nebo jiný nástroj, který se ze sítě stáhne jako první.

Co když nemáš x86?

Tak potřebuješ nástroje pro svoji architekturu, to je přece normální.

Prostě v určitých případech je život bez initramdisku jednodušší

Popravdě řečeno mi nějak není jasné, co vlastně řešíš.

Jádro typicky potřebuje userspace k tomu, aby dělalo něco smysluplného. Nejjednodušší způsob, jak jádro může přistupovat k userspace je initramdisk, protože ten už v paměti je ve chvíli, kdy s jádro spustí. Pokud dokážeš zavést do paměti jádro, dokážeš tam s ním zavést i initramfs (ledažebys narazil na velikostní limit).

Samozřejmě je možné přímo do jádra cpát hromadu typických userspace nástrojů a používat je jako bridge mezi jádrem a úložištěm userspace. Třeba tam můžeme zduplikovat i celou síťovou autokonfiguraci. Co na tom, že jsme dodnes nebyli schopní zařídit, aby nám fungovala alespoň v userspace, kde je všechno mnohem jednodušší a udržovatelnější?

Je to vtipné. Když se nástroj z hlavního systému vykopíruje do initramfs, všichni řvou. Když se ale userspace nástroj vezme a přepíše jako kernelový modul, jsou všichni zticha. Přitom údržba složitějších kernelových nástrojů je takřka nemožná, což se ukazuje i na věcech jako bonding/teaming, IPv6 router discovery a mnoha dalších.

[David Jaša]

Samozřejmě je možné přímo do jádra cpát hromadu typických userspace nástrojů a používat je jako bridge mezi jádrem a úložištěm userspace. Třeba tam můžeme zduplikovat i celou síťovou autokonfiguraci. Co na tom, že jsme dodnes nebyli schopní zařídit, aby nám fungovala alespoň v userspace, kde je všechno mnohem jednodušší a udržovatelnější?

Je to vtipné. Když se nástroj z hlavního systému vykopíruje do initramfs, všichni řvou. Když se ale userspace nástroj vezme a přepíše jako kernelový modul, jsou všichni zticha. Přitom údržba složitějších kernelových nástrojů je takřka nemožná, což se ukazuje i na věcech jako bonding/teaming, IPv6 router discovery a mnoha dalších.

Z tohohle pohledu už začíná vypadat třeba umístění firewalld celkem logicky.

[pavlix]

V jakém smyslu?

[David Jaša]

Že to běží v jůzrspejsu. Ještě nějak dodělat exkluzivitu přístupu k netfilteru a naučit další věci nad tím používat firewalld pokud je dostupný, a možná ta konfigurace někdy nebude stát za úplný h...

[pavlix]

Že to běží v jůzrspejsu.

Už chápu. Je to tak. Můj názor je, že patří do kernelu holé minimum toho, co tam z nějakého důvodu musí být. Tedy engine pro filtrování paketů a minimální kód pro zpřístupnění vnitřní konfigurace toho engine do userspace.

Největší výhodou je to, že nemusíme co chvíli překopávat kernel a reimlementovat v něm znovu a znovu věci jen proto, že se nám přestaly líbit, stačí vyměnit userspace nástroj. Taky to umožňuje používat stejný kernel pro použití v embedded, na serverech i na laptopech.

Problém je v tom, jak vyvážit jednoduchost a flexibilitu u toho kernelového API. Na tom závisí, zda musíš mít nástroj s exkluzivním přístupem nebo zda je to jenom možnost a můžeš přístup ke konfiguraci i sdílet. U firewallu je to sdílení tradičně velmi špatné, u síťové konfigurace je o něco lepší.

[kapo]

V jádře přeci je volba "DHCP/BOOTP autoconfiguration" či jak se to jmenuje. A slouží to k tomu, že i bez initrd jsi schopný nabootovat po síti a připojit třeba NFS svazek jako root. A na to stačí jen parametry předané jádru. A je to v tom jádru už minimálně dekádu.

[pavlix]

Když vidím všechny tyto berličky jak dostat kernel bez userspace do provozu, tak mám initramfs ještě radši než kdy dřív.

[kavol]

Připojení k síti obstará už BIOS, když stahuje přes TFTP jádro a initrd.

prozradím ti sladké tajemství ... existuje moře hardware, které není x86, a se kterým se pracuje úplně jinak než jako s nějakou domácí krabicí z nejlacinějšího eshopu, včetně toho, že existují i sítě nepostavené nad IP, přičemž TFTP funguje nad UDP/IP, pokud tomu správně rozumím

[pavlix]

TFTP je skutečně jen jedna z možností a jeho typické využití vylučuje routing, takže nejenže vyžaduje UDP/IP, ale ani ho typicky neumí využít. Projekty jako iPXE pak dokážou nabídnout zcela flexibilní boot, který umí použít TFTP, HTTP a hromadu dalších možností po běžném internetu a jako open source lze dále vylepšovat.

Zcela jistě bys nad tím postavil i něco non-IP při troše snahy (a dostatku času) a je to stokrát lepší než nějaké intelí PXE sračky.

[pc2005]

Jj například cpát ramdisk přes JTAG ná vývojové desce je docela náročná sranda (asi dvojnásobná velikost oproti samotnýmu kernelu).

[pavlix]

Pokud do zařízení dokážeš dostat běhový image bez JTAGu, pak nevidím důvod tam nenacpat stejnou cestou i ten kernel.

[pc2005]

No právě to je vývoj. Doba cpaní kernelu se ještě dá překousnout, ale 30MB ramdisk by byl megaopruz.

[pavlix]

To zní jako kdyby sis myslel, že ti samotný kernel k něčemu je.

[pc2005]

No v tuhle chvíli zrovna jo .

[pavlix]

To by mě docela zajímalo, musím přiznat.

[pc2005]

Hrabal jsem se v architektuře Microblaze a výsledný efekt byl znatelný ještě před koncem bootu.

[kralyk z abclinuxu]

To už seš druhej, co popisuje 30MB initramdisk jako katastrofu. V čem přesně ten megaopruz spočívá?

Disclaimer: Nechci tím říct, že chci mít 30MB initramdisk, pokud možno nechci. Ovšem kdyby to bylo nutný, neviděl bych v tom takovej problém...

[pc2005]

Ten JTAG je na FPGA desce, čili tam by velký systém katastrofa byl (starší verze desky má třeba jen 128MB, ale identický postup programování). Megaopruz na té konkrétní desce je v tom, že 2MB kernel se nahrává asi minutu a půl. Ramdisk by to pak dal tak za čtvrt hodinky . Přičemž už se mi párkrát stalo, že jsem musel udělat dvě programování za sebou kvůli triviální chybě (opravitelné za sekundu).

[kralyk z abclinuxu]

Aha, sorry, nevšim jsem si, že ve vlákně se řeší JTAG. Tak tam to asi megaopruz bude, nicméně to je hodně specializovaný případ a trochu mimo téma...

[pc2005]

nicméně to je hodně specializovaný případ a trochu mimo téma...

Souhlasím...

[pavlix]

Ono to vypadá, že se v rámci vlákna zapomněly uvést zásadnější informace než JTAG, který uvedený byl.

[frEon]

a v cem ze to je lepsi?

[mankind_boost]

Že bez /usr nenabootujete.

[Dr. Eddy]

nabootujete s initramfs. A proc chcete pracovat bez /usr? Copak ho stejne nakonec nepripojite? A pokud treba ne, tak asi mate zvlastni potreby a nehodi se vam ubycejne distro pro obycejne desktopy a obycejne pouziti. No offense...

[mankind_boost]

"nabootujete s initramfs."
To je vtip? Zkoušel jste někdy bootovat systém síťově z nějakého serveru (teď nemám na mysli jen nějaké ftp/http)? To mám jako mít 30MB initrd?! "nehodi se vam ubycejne distro pro obycejne desktopy a obycejne pouziti."
To ano, problém je v tom, že to cpou skoro úplně všude.

[pavlix]

Mně to nepřijde jako vtip, ale jako tvrdá realita.

[Dr. Eddy]

1) ano zkousel, sitovy boot pres TFTP. 2) proc 30MB? 3) proc je problem 30MB? 4) porad nechapu, proc je to problem. Proc nemuzete pripojit /usr? Ikdyby jste nabootoval 30MB ramdisk, proc ten stroj vypinate a neuspavate?

Mozna jsem tupej (coz opravdu nevylucuju), ale prijde mi, ze spis hledate duvod, proc je to spatne, namisto hledani reseni v novem prostredi a moznosti, jak vam to muze usnadnit praci.

[mankind_boost]

"1) ano zkousel, sitovy boot pres TFTP.
Psal jsem, že ne FTP (tftp je dokonce ještě jednoduší) ale něco složitějšího (třeba zašifrovanej image systému přístupnej přes ssh).

"2) proc 30MB?"
Protože tyto složitější nástroje mají jisté závislosti (a 30 MB je ještě hodně střízlivý odhad).

"3) proc je problem 30MB?"
Initrd 30 MB! To je něco šíleného! Od toho tu snad mám kořenový adresář proboha, ne?!

"namisto hledani reseni v novem prostredi a moznosti"
Ale PROČ???? Toto členění je tady s námi desítky let a STÁLE FUNGUJE JAKO HODINKY.

P-R-O-Č to bourat?

[Dr. Eddy]

1) TFTP neni FTP, ale whatever. Nic slozitejsiho jsem nezkousel.

2) OK.

3) Fajn, strcte to do /usr. Od toho tu je.

4) Treba protoze to funguje suboptimalne a zmena se nezda nejak moc bolestiva? Treba se to da zlepsit a nemusime zit v tom zastaralem bordelu, co se kdysi zavedlo, kdyz byly dostupne disky s malinkou kapacitou? A proc to Solaris zavedl uz ve verzi 11?

[pavlix]

Tam je ještě výhoda, že zatímco initramfs v kombinaci s různými nástroji dokáže vyřešit de facto cokoli, tak cpaní dalších sraček do jádra strašně bojí, zvlášť když je pak člověk nemůže opravit z důvodu, že by na chybě už mohlo něco záviset.

[rADOn]

A proc to Solaris zavedl uz ve verzi 11?

Proč to nezavedly jiné unixy? Udělal jsem si takový menší průzkum googlem – BSDčka mají /usr. AIX má /usr. HP-UX má /usr. Irix má /usr. Kde jsou ty "ostatní komeřcní unixy" o kterých se píše v tom Kayově pamfletu?

[pavlix]

Solaris 11 má /usr taky, a aktuální Fedora taky, nebo jsem něco špatně pochopil?

[rADOn]

Ne, špatně jsem to napsal. Měl jsem samozřejmě na mysli oddělený /usr. Irixem si nejsem jistej, nenašel jsem přímo jeho hier(7) manstránku.

Pokud to někoho zajímá: HP-UX AIX FreeBSD OpenBSD

[pavlix]

Už chápu.

[frEon]

nevim jak aix a hp-ux, ale irix je samostatny svet/bordel sam o sobe. Uzivatele maj svuj ~ v /usr/ zakladni systemovy binarky (ls, echo, test a pod) jsou v oddelene /etc atd atd...

[Michal Kašpar]

No zrovna HP-UX má /bin -> /usr/bin a /lib -> /usr/lib. Ale je pravda, že si na kořeni nechává samostatné /sbin.

[rADOn]

Na symlinky sere pes, ty můžou být jaký chtěj. Hlavně se tam píše že:

/usr  Mount point for sharable user and system administration commands, libraries
and documentation.

/sbin  Essential system commands. Essential commands are defined as executables
that are needed to boot the system and mount the file systems. A full comple-
ment of utilities is available only after /usr is mounted.

Čili ať už je v tom /sbin cokoliv (a třeba mít tam initskripty se mi docela líbí) mělo by to stačit k nutný údržbě systému. Bez berliček jako je initrd. Pokud bude platit tohle, můžou být symlinky kde chtěj jaký chtěj ani nikdo (příčetnej) neřekne ani popel.

[Michal Kašpar]

Tak šlo spíš o to, že HP-UX má / a /usr do značné míry sloučené už dávno. Protože to, co je v /sbin je určené opravdu pouze pro boot a připojení a s nástroji dostupnými na řadě distribucí v /bin se to moc z hlediska komfortu při opravě nedá srovnávat a důvodem, proč je to tady, bude, že HP-UX initrd nemá. Nicméně z hlediska opravitelnosti se mi tohle řešení asi taky líbí víc, protože různé varianty initrd už jsem k opravám používatl a autory jsem v těch chvílích zrovna nechválil. Na druhou stranu je initrd flexibilnější (nevyžaduje připojení / fs).

[pavlix]

A tím, že se Linux používá v hodně různých prostředích a s hodně různými podmínkami, tak se ta flexibilita reálně využije.

[David Jaša]

Ona to není jen flexibilita, ale i blbuvzdornost (resilience) a (možná neintuitivně) menší paměťové nároky. Initrd umožňuje mít ovladače pro všechna zařízení 1) dostupná a 2) v modulech. To první znamená, že s jen trochu slušně nastavenými lokálními úložišti se dá vyměňovat hw téměř jakkoliv a vždy to nabootoje jako by se nechumelilo, a to druhé zase umožňuje splnit 1) aniž by musely být všechny drivery zakompilované a tedy v paměti.

To, že se initrd začíná používat i v arm krabičkách, mluví za všechno.

[Petr Ježek]

ad 1): Nestandardní operace.
ad 3): Přináší /usr na odlišném oddílu nějaké výhody? Jinak bezvýznamné.
P-R-O-Č upgradujete bleeding-edge distro?

[pavlix]

Přináší /usr na odlišném oddílu nějaké výhody? Jinak bezvýznamné.

Původní i nový /usr lze používat read-only mimo dobu instalace balíků, takže za použití vhodných nástrojů (nemám, nezkoušel jsem) je možné /usr libovolně sdílet a ukládat i na média nevhodná pro častý zápis.

Ať se ozve někdo, kdo nějaký systém takto reálně provozuje ;). Ostatní výhody mi připadají málo významné (poskládání věcí na disku apod).

[lertimir]

Před 18 lety jsem takto provozoval SunOS 4.x asi pro 5 stanic s /usr na NFS. Ale to byla zcela jiná doba. Nyní by to read-only na /usr mohlo mít možná význam proti rootkit útoku. Ale jinak v současnosti odděluji jen /home, pro LVM /boot a pro servery /var a /srv.

[R]

Preco je problem 30 MB? Lebo zabijes 30 MB RAM + dvakrat tolko na dekompresiu. Takze je mozne, ze ani so 128 MB RAM nenabootujes...

[Petr Ježek]

Která moderní zařízení disponují pouhými 128 MB RAM?

[pc2005]

ADSL modemy, wifi routery, ... (já mám například 16MB tuším)

[mrv]

a na nich rozjedete archlinux? to jsem nevedel, ze do tehlech veci se davaj x86 procesory...

[mankind_boost]

Nebavíme se jen o Arch a modemech.

[pavlix]

Vím, že jen odpovídáš na otázku, ale vezmu-li do úvahy širší kontext... Tam se typicky read-only běhový image používá a zápisy se provádí mimo něj, ne? Tím je situace relativně podobná situaci s ramdiskem. Nehledě na to, že narozdíl od PC mívají tyto stroje často i řádově menší úložný prostor oproti RAM, takže co se vejde komprimované na flash, to se vejde dekomprimované do RAM úplně s přehledem.

[pc2005]

Tak jsem se přinutil najít heslo a připojit se na busyboxí shell. ADSL modemů mám vícero, tenhle je spíš light verze (bez wifi a jen jeden ethernet port). Velikost flash je 2MB, velikost RAM je dokonce asi jen 8MB. Image z flash je tvořen kernelem a userspace ve squashfs, kterej se mountuje read only. V systému je ramdisk na /var, zbytek RAM sežere asi kernel a ssh a http démoni. Tedy žádný fs ve zkopírovaném ramdisku.

Je to sice už starší model (dlink DSL-321), ale řekl bych, že ostatní se budou řídit stejným heslem a to, že když je dost RAM na rozbalení a zkopírování obrazu fs, tak bude lepší použít levnější a menší RAM a načítat to read only. Je sice možný, že se mýlím, ale ten čipset umí klasický SPI paměti (tedy určitě kapacity 16MB, ale možná i víc).

[pavlix]

Tak jsem se přinutil najít heslo a připojit se na busyboxí shell. ADSL modemů mám vícero, tenhle je spíš light verze (bez wifi a jen jeden ethernet port). Velikost flash je 2MB, velikost RAM je dokonce asi jen 8MB. Image z flash je tvořen kernelem a userspace ve squashfs, kterej se mountuje read only. V systému je ramdisk na /var, zbytek RAM sežere asi kernel a ssh a http démoni. Tedy žádný fs ve zkopírovaném ramdisku.

Tedy přesně odpovídá tomu, co jsem psal.

[pc2005]

Pouze s rozdílem, že RAM není permanentně zaplněná ramdiskem, ale jen občas nějakým bufferem dekompresního algoritmu pro squashfs. Spotřebovává tedy míň místa a kdyby byl squashfs zapisovatelný filesystém, tak by šlo ty data i zapisovat zpět.

P.S. Nevím přesné statistiky kompresního poměru ARM binárek zkomprimovaných squashfs (LZMA?). Ale je zde docela šance, že by se u mého modelu dekomprimovaný image do RAM fakt nevešel.

P.P.S. U takové krabičky bych v dalším hypotetickém kroku vývoje místo ramdisku IMHO spíš investoval do flash a nějakýho eXecute In Place filesystému (i když tady je ta flash sériová a asi pomalá...).

[pavlix]

Pouze s rozdílem, že RAM není permanentně zaplněná ramdiskem, ale jen občas nějakým bufferem dekompresního algoritmu pro squashfs.

Přesně tak. I když si asi dokážeš představit, že dostatek RAM je i v tomto případě velkou výhodou.

Ale je zde docela šance, že by se u mého modelu dekomprimovaný image do RAM fakt nevešel.

Je to možné.

[mankind_boost]

Chápete, že je to dosti závážná nevýhoda? A to je jen kapka v moři...

[kralyk z abclinuxu]

To je vtip? Zkoušel jste někdy bootovat systém síťově z nějakého serveru (teď nemám na mysli jen nějaké ftp/http)? To mám jako mít 30MB initrd?!

No a co by se stalo tak hroznýho, kdyby initrd měl 30MB? Pravděpodobně by se nestalo v zásadě nic ani kdyby měl 150MB...

Krom toho dneska by neměl být problém nabootovat plnohodnotný systém odněkud ze sítě (nebo třeba z myši ), což bude jistě o dost použitelnější/pohodlnější než pracovat v init 1.

[pc2005]

Musí se načíst najednou celý, přičemž kdyby byl na disku, tak ti stačí načíst jen některé soubory (další až za čas a nebo vůbec).

[BFU]

TFTP ma limit na velikost souboru 32 MB ... jenom nektere extenze umi vic, ale neni to standard.

[pc2005]

V tom případě udělat malý ramdisk co natáhne velký ramdisk a ten až nabootuje kompletní distribuci .

[mankind_boost]

Takhle nějak si to asi Lennart představuje

[pavlix]

Takhle nějak se to při bootování ze sítě nezávisle na L. často dělá.

[Delaunay]

Ten malý ramdisk by mohl natáhnout ten velký a ten už by nepotřeboval nic dalšího bootovat, protože už by to vlastně byl téměř cílový stav. Pak už jen nezapomenout připojit /usr/home a můžeme pracovat

[pavlix]

Takhle zhruba mělo fungovat dosud neobnovené boot.kernel.org a funguje tak boot.fedoraproject.org.

[pavlix]

Jedno z typických použití iPXE a jemu podobných.

[kralyk z abclinuxu]

TFTP ma limit na velikost souboru 32 MB ... jenom nektere extenze umi vic, ale neni to standard.

Ty "extenze" mají RFC, takže to mi přijde dostatečně standardní...

Jinak prosímvás, uklidněte se, těch 150MB byla nadsázka jako prase, to by mohla být velikost nějaké minimalistické grafické live distribuce. Do 32MB initrd se snad musejí vejít všechny potřebný základní command-line nástroje. Nebo vy snad v init 1 provozujete MySQL server?

[Delaunay]

Jak to tak pozoruji, tak když používám 100 MB pro /boot a 500 MB pro / (root) a vše ostatní mám na LVM (samozřejmě včetně /usr), tak se ze mě rázem stává nepřizpůsobivý občan. Dobře, jsem s tím srozuměn, zítra si jdu pro dávky

Tento způsob bootování zdá se být poněkud nešťastný. Nejen proto, že si budu muset společně s notebookem přenášet v batohu i diskové pole pro ukládání všech těch "cool", "hot" a "eye-candy" ramdisků, které jsem naposledy používal před mnoha lety a které nyní budou mít velikosti srovnatelné s průměrně velkými distribucemi. Zároveň mi do nich prosím přibalte i X Server s nějakými těmi akčními střílečkami, abych si po dobu co bude jedno CPU pátrat po perifériích a hledat cokoliv co by se dalo případně pivotnout mohl vybíjet vztek v multiplayeru společně s jinými podobně postiženými uživateli moderního linuxu

[pavlix]

Dobře, jsem s tím srozuměn, zítra si jdu pro dávky

Spíš si jdeš vyrobit initramfs image ;).

diskové pole pro ukládání všech těch "cool", "hot" a "eye-candy" ramdisků, které jsem naposledy používal před mnoha lety a které nyní budou mít velikosti srovnatelné s průměrně velkými distribucemi.

Gentoo, root na LVM:

-rw-r--r-- 1 root root 3.8M Dec 13 01:26 initramfs-genkernel-x86_64-3.6.8-gentoo

Fedoří je nějakej strašně nenažranej, ale to není můj problém.

[David Jaša]

Fedoří je nějakej strašně nenažranej, ale to není můj problém.

Spíš ten gentusáckej bude odlehčenej o ovladače věcí, který ty v životě neuvidíš, ale one-size-fits-all initrd binární distribuce na někdy někde natrefí.

Teda osobně se mi líbí spíš ten druhý přístup, kór když ani tak to není nic strašnýho (F19):

$ du -sm /boot/{vmlinuz,initr}*
5	/boot/vmlinuz-0-rescue-e1f6ffd81ce8478aa08e14b9ff7c0a4e
5	/boot/vmlinuz-3.9.2-301.fc19.x86_64
5	/boot/vmlinuz-3.9.4-300.fc19.x86_64
26	/boot/initramfs-0-rescue-e1f6ffd81ce8478aa08e14b9ff7c0a4e.img
12	/boot/initramfs-3.9.2-301.fc19.x86_64.img
9	/boot/initramfs-3.9.4-300.fc19.x86_64.img

[pavlix]

Spíš ten gentusáckej bude odlehčenej o ovladače věcí, který ty v životě neuvidíš, ale one-size-fits-all initrd binární distribuce na někdy někde natrefí.

Je to standardní genkernelový, nic jsem nevyhazoval. Takže buď lépe filtruje generické věci podle potřeb (například LVM jsem musel ručně povolit), nebo jsou nějak jinak nastavené defaults i pro hardware. Netuším.

[kavol]

Gentoo, WTF na jednom disku LVM?

kavol boot # ls init*
ls: nelze přistoupit k init*: Adresář nebo soubor neexistuje

:-p

[Josef Kufner]

Co se ti nezdá na LVM na jednom disku? Taky to tak mám. LVM leží na šifrovaném disku a v LVM mám dvě partition – / a swap.

[kavol]

řekl bych něco o kanónech na vrabce

jaký je důvod mít na šifrovaném disku LVM?

[pavlix]

Šifrování nemá na důvody pro LVM žádný vliv.

[David Jaša]

To bys tam radši měl partišny? To LVM mi tam sedí víc.

[kavol]

To bys tam radši měl partišny?

ano, o jednu zbytečnou vrstvu méně

To LVM mi tam sedí víc.

proč?

[David Jaša]

Protože je s tím podstatně menší opruz, když je potřeba šibovat s velikostma. Vadí ta mezivrstva něčemu za předpokladu, že je zarovnaná na celé bloky na disku?

[kavol]

a jak často potřebuješ šibovat s velikostma a proč to děláš?

- na výše použitém stroji mám jednu partition přes celý disk a nevidím důvod to měnit

na stroji, kde potřebuju šifrování, mám nešifrovaný /boot a šifrovaný / a swap zvlášť, tedy tři partition daných velikostí, a nevidím důvod to měnit

[David Jaša]

a jak často potřebuješ šibovat s velikostma a proč to děláš?

Málo často, ale když musíš, tak musíš.

a šifrovaný / a swap zvlášť,

Takže zadáváš při bootu heslo dvakrát?

[kavol]

a jak často potřebuješ šibovat s velikostma a proč to děláš?

Málo často, ale když musíš, tak musíš.

protože "musíš"? - sorry, ale to je dosti prapodivný důvod ...

a šifrovaný / a swap zvlášť,

Takže zadáváš při bootu heslo dvakrát?

jak už jsem odpovídal, jen jednou

[David Watzke]

Já mám taky LVM přes jeden (3 TB) sw raid1. Důvodem je větší flexibilita. Nemusím se rozhodovat jak to celé rozdělit hned teď, ale můžu to různě resizovat postupně, jak se mi zlíbí a testovat různý nový filesystemy pro specifický účely. Jako třeba btrfs pro VDB nebo portage tree na gentoo, atp. Nebo volný místo v LVM můžu použít pro dočasnej oddíl pro defragmentaci, a tak dále. Chápeš? Je to docela smysluplná volba.

[kavol]

Chápeš? Je to docela smysluplná volba.

i když netestuju různý nový filesystémy pro specifický účely? - ne, nechápu

[David Watzke]

Pokud víš předem, jak to chceš mít rozdělený, tak pak ano, LVM by byla nesmyslná volba a bylo by to přidání vrstvy navíc, jak říkáš. Ale ta vrstva navíc má tak malej vliv, že při sebemenší pochybnostï o tom rozdělení se vyplatí to LVM nasadit. Vezmi si například oddíly pro /var a /var/lib/mysql - nevíš předem jak moc ta databáze poroste v porovnání s varem, na kterém chceš mít jinej FS... Neber prosím moje komentáře jako že se ti snažím podsouvat, že to potřebuješ - nejsem pošuk. Jen se snažím vysvětlit ti nějakej use case pro LVM nad jedním "zařízením".

[pavlix]

Jen se snažím vysvětlit ti nějakej use case pro LVM nad jedním "zařízením".

A zrovna dokonce odlišný use case než mám já, čímž přispíváš k rozmanitosti. Já typicky LVM používám na provoz více operačních systémů, ať už jde o virtualizaci, dualboot nebo chroot, u kterého se počítá s tím, že by to někdy mohlo běžet samostatně. Nasazuju LVM ve všech případech s výjimkou těch, kdy můžu disk rozdělit jednorázově při instalaci.

[kavol]

no, dokud nepřišlo KDE4, tak jsem na desktopu use case pro mysql neměl ... a od té doby, co jsem od KDE4 utekl, tak také nemám a krom toho, ta databáze byla někde ~/.local a ne /var/lib...

ale baví mě, jak se tu někdo snaží obhájit "slušně okrajový" use case, zatímco prve tu psal něco vo tom, jak si na danou věc má dotyčný, kdo to potřebuje, najmout admina, co mu to vyřeší - tak hele, já ti vyřešim změnu velikosti oddílů i bez LVM, kolik dáš?

[pavlix]

já ti vyřešim změnu velikosti oddílů i bez LVM, kolik dáš?

Když dáme dost vysokou pokutu za ztrátu dat, tak bych se toho nebál. Budeš dostávat za úkol bez LVM řešit ty stejné úlohy, na které jsem dole psal, že LVM používám ;).

A ani ti nebudu nadávat za to, že je změna velikosti bez LVM řádově pomalejší.

[kavol]

p.s. tím neříkám, že LVM považuju za naprosto neužitečný a chci ho zrušit tak, jak někteří zde přítomní oddělenej /usr - pouze že nevidím důvod cpát ho všude

[pavlix]

Já taky nevidím důvod ho cpát všude. Co se mi ale běžně nestává je, že by se mi hodilo do jedné VG zařazovat více než jednu PV.

[kavol]

chm, možná jsem blbě pochopil tvůj příspěvek, který toto odstartoval, ale když už to běží ... musím říct, že mě to baví - jeh houšť a větší svazky! LVM do každé rodiny!

[pavlix]

chm, možná jsem blbě pochopil tvůj příspěvek, který toto odstartoval

To je dost možné. Příspěvek výše to ale myslím popisuje docela přesně.

[Josef Kufner]

Při bootu a probuzení ze swsuspu stačí zadat heslo jednou.

[kavol]

jak to souvisí s LVM?

- viz co jsem říkal Dejvovi, mám šifrovaný / i swap a heslo zadávám jednou (a nemám LVM)

[pavlix]

Gentoo, WTF na jednom disku LVM?

Osobně LVM používám výhradně nad jedním fyzickým zařízením či nad jedním RAIDovým polem.

[kavol]

a k čemu je to v tom případě dobré?

[pavlix]

K tomu, abych mohl kdykoli za běhu zasahovat do rozdělené disků následujícími operacemi:

1) Bezpečně přidat nový oddíl a dát mu jméno.

2) Bezpečně zvětšit oddíl (a filesystém), kde mi dochází místo.

3) Bezpečně odstranit oddíl a uvolnit zabraný prostor pro další využití.

4) V některých případech nechat #1, #2 a #3 na nástroji, který spravuje oddíly pro virtuální stroje.

LVM je velmi flexibilní, takže dokážu pochopit, že někdo jiný ho využívá jinýmy způsoby a z jiných důvodů. Jestli chceš, můžeš uvést ty své.

[kavol]

ok, čili vpodstatě pracuješ s oddíly tak, jako já se soubory ... 1) qemu-img 2) neřeším 3) rm

[rADOn]

O.M.F.S.M. genkernel a initrd. Styď se člověče, to už můžeš rovnou provozovat blbuntu. Srsly, ještě nedávno bych lidem co jsou líný kompilovat kernel doporučil Archa, ale teď už si nejsem tak jistej…

[David Jaša]

K čemu že je dobrý si ten kernel kompilovat?

[Honza Jaroš]

Tohle jsem nějak nepochopil - co je špatného na genkernelu? Přece v podstatě dělá při překladu jádra totéž, co portage při instalaci aplikací...

[pavlix]

+1

[pavlix]

O.M.F.S.M. genkernel a initrd. Styď se člověče, to už můžeš rovnou provozovat blbuntu.

[flame]Nepatřím mezi frikulíny, co mají Gentoo kvůli kompenzaci malého penisu, tudíž můžu nástroje vybírat podle subjektivní užitečnosti a nikoliv podle cool effectu ;).[/flame]

Srsly, ještě nedávno bych lidem co jsou líný kompilovat kernel doporučil Archa, ale teď už si nejsem tak jistej…

Nevím jak ty, ale já rád přenechám kompilaci počítači. Mimochodem, jak dlouho ti ta kompilace trvá?

[rADOn]

Jestli jsme se dotknul tak se omlouvam, nemyslel jsem to nijak zle. Proste me to prekvapuje, cekal bych ze kdyz ma nekdo cas matlat se s gentoo, tak je nastaveni si vlastniho kernelu celkem detail. A kdyz na takovy blbiny nekdo cas nema (coz je, nedelam si iluze, 99% lidi tak na gentoo ani nepomysli... zkratka mi to nejde dohromady. Muzes mi prozradit co te na gentoo zlakalo? Kdyz to teda neni penisem

Mimochodem, jak dlouho ti ta kompilace trvá?

Urcitne podstatne min nez pres genkernel, pacz 99% jadra jsou veci ktery nikdy nevyuzijes a daj se vypnout. Co trva DLOUHO je dopracovat se k funkcnimu .configu, zvlast kdyz to clovek dela poprve. Na notesech s ICH cipovkou ktery jsou vsecky na jedno brdo a uz to celkem znam je to prace nacisto tak na pul odpoledne.

[Honza Jaroš]

Technický dotaz: zkusil jste někdy spustit genkernel třeba s parametrem --menuconfig?

[Honza Jaroš]

Pokud ne, doporučuji spustit genkernel --help a věnovat pozornost sekci Kernel Configuration settings a parametru --kernel-config.

[rADOn]

Ja jsem naposled spustil genkernel kdyz jsem s gentoo zacinal, to uz je nejakych deset let Tehdy se v install guide psalo neco jako "kdyz umis, nastav si to sam a nasledujici kapitolu preskoc". Pokud vim je to tam dodnes a ja to dodnes preskakuju.

[Honza Jaroš]

No, a já už deset let spouštím menuconfig z genkernelu...

[kavol]

"čas matlat se s gentoo"? - sorry, ale za poslední rok jsem správou Gentoo na dvou strojích a instalací na třetím strávil významně méně času nežli s mojí pracovní Fedorou ...

[pavlix]

To chápu.

[pavlix]

Jestli jsme se dotknul tak se omlouvam, nemyslel jsem to nijak zle.

Ani ne, navíc jsem byl ve svém komentáři o poznání drzejší než ty, takže nemám nárok být uražený.

Proste me to prekvapuje, cekal bych ze kdyz ma nekdo cas matlat se s gentoo, tak je nastaveni si vlastniho kernelu celkem detail.

1) Nikde jsem netvrdil, že kernel nekonfiguruju. A genkernel považuju za skvělý nástroj, který plní svůj účel, pokud ho správně nastavím.

2) Patlání s Gentoo věnuju minimum času. Většinu času naopak využívám výhod, které ten systém poskytuje a čas díky němu šetřím.

Muzes mi prozradit co te na gentoo zlakalo?

Šetří mi čas a ulehčuje mi práci. Část toho, co dělám, je zásah do klíčových systémových komponent, což má za následek různé problémy se závislostmi a neznám systém, ve kterém by se řešily tak jednoduše jako v Gentoo. Kromě toho Gentoo umí při minimálním úsilí vybuildovat hromadu běžného open source software.

Popravdě řečeno jsem kdysi Gentoo odolával několik let, kdy ho používala majorita mých linuxových známých. Asi před šesti lety jsem potřeboval co nejrychleji vyzískat systém dle zadání (i konkrétní verze některých komponent), aby odpovídal nějakému embedded systému a Gentoo v chrootu byla bezkonkurenčně nejrychlejší možnost, jak toho dosáhnout.

Tehdy jsem zkusmo z toho chrootu udělal živý systém a nějaký ten rok jsem to s úspěchem používal. To dost zdržovalo, protože tehdejší stroje, co jsem měl, nebyly úplně srovnatelné s tím, co mám dneska.

Před rokem jsem se začal znovu věnovat vývoji systémových komponent, tak jsem si na jeden stroj Gentoo nainstaloval.

[little.owl]

Kulva, pratele, jestli se v mem profilu objevi Gentoo, tak za to muzes ty s Kavolem.

Nestvete me!

[pavlix]

;)

[Jardík]

Co je spíš vyjebaný je, že /lib je symlink na /usr/lib, knihovna linkeru je v /usr/lib, ale GCC v Archu stále linkuje k /lib/ld.so

[stativ]

Pokud se dobře vzpomínám, tak je to tak kvůli tomu, že některé proprietární aplikace pak padaly.

[Petr Ježek]

Ano, je to tak. A hezky to ukazuje na pravou podstatu problému...

[mankind_boost]

Že je to GCC nakonfigurované tak, aby se drželo standardu? Nebo v čem je problém?

[kavol]

Důvody přesunů jsou uvedeny například v článku Proč sloučit /usr na Fedora.cz.

Kupka hnoje, nesmyslů, polopravd i vyložených lží je uvedena například v článku Proč sloučit /usr na Fedora.cz.

[pet]

+1

[pavlix]

Mně v podstatě nevadí ani systemd ani usrmove. Obojí by mi teoreticky vyhovovalo, jen škoda, že se celý vývoj neubírá směrem k užitné hodnotě a plnění reálným požadavkům. Snad se blýská na lepší časy ;).

[Bedňa]

To je dnešný trend nadnárodných spoločností :) Ešte sa dočkáš toho aby si vyvíjal nejakú aktivitu na zlepšenie niečoho, musíš to robiť, ale nesmie to časovo ohroziť tvoju prácu. Keď povieš že to niečo nestíhaš, tak prvý krát ti to prejde, ale že si na to nemal čas celý mesiac to ti neuveria :D

[pavlix]

Což je jeden z důvodů, proč měním alespoň pracovní zařazení.

[Bedňa]

Jj ako šéf Red Hat budeš toho môcť veľa zmeniť :)

[pavlix]

Tak ten byl hodně dobrej :D.

[stativ]

Nojo, přece nepůjdeme přímo za lepšími zítřky, když místo toho můžeme dělat spoustu úkroků stranou.

[pavlix]

Otázkou je, proč to říkáš mně. :)

[stativ]

Jako doplnění toho, co jsi říkal.

[pavlix]

OK.

[martin-ux]

Napad je to dobry, uvidme aka vsak bude realizacia. Niektori, co spominali problem pri single rezime: nemal by byt problem spravit napr. /rescue, kde budu staticky zlinkovane binarky pre pracu v tomto rezime (tak ako ma napriklad FreeBSD).

[pavlix]

To už mě přijde lepší linuxový přístup s initramdiskem, který si můžeš jako celek schovat a použít starší v případě nouze.

[martin-ux]

V tom osobne nevidim ziadnu vyhodu. I ten initrd image musi byt ulozeny na disku. Na FS mozes jednoducho k nemu pristup podla potreby. To je ako kebyze si z-tar-ujem /sbin a roztarovany bude len v specifickom pripade.

[pavlix]

V tom osobne nevidim ziadnu vyhodu.

Pak ti asi nemůžu pomoci, pokud nevidíš ani tu, kterou jsem napsal výše.

I ten initrd image musi byt ulozeny na disku.

To, co píšeš je nesmysl, takže nevím, jak bych měl reagovat. Může být samozřejmě uložen na jakémkoli zařízení, které umožňuje ukládat a číst relativně malé množství dat a může k němu být přistupováno různými způsoby.

Na FS mozes jednoducho k nemu pristup podla potreby.

Pokud by toto byla pravda, tak by žádný initramfs nikdy nevznikl.

[martin-ux]

Ja ale pomoc nepotrebujem :). A reagovat nemusis, to nie je podmienka.

Ja v tom nevidim ziadnu vyhodu; ostatne spomenuli to tu uz aj ostatni. A ano, kernel si ma (=~mal by) poznat / FS bez initrd.

[pavlix]

Tak duševní slepota není úplně něco s čím bych se vytahoval.

[smoco]

Toto je pekna blbost este ze arch nepouzivam. Usr na samostatnom disku ma zmysel - napr ked je na lvm. Vies ho zvacsovat ked potrebujes. Zase / mimo lvm ma taky zmysel ze ked sa ti to lvm pokazi vies si ho opravit - lvm je radovo zlozitejsie cize ti treba na jeho opravu viacej nastrojov. Mozes vsetko dat do / co neni na lvm ale ten uz nikdy nerozsiris alebo vsetko do lvm ale potom potrebujes ramdisk (co som doteraz nepotreboval). Po novom ked sa lvm pokazi musis pouzivat rescue cd , co ti napr IPMI neumozni bez toho by si mal nejaku vendor extension.

[pavlix]

To jsou všechno jednotlivé obezličky jak některé věci rozchodit bez initramfs, když s initramfs funguje dobře nejen těch pár specifických věcí, které jsi popsal, ale i ty ostatní. Navíc můžeš mít vedle bootovacího initramfs samostatný rescue initramfs, pokud ti to nějak pomůže, popřípadě můžeš mít schovaný starší initramfs pokud bys náhodou vygeneroval nefunkční.

S initramfs není problém mít na LVM i root a naopak není problém mít image s nástroji na opravu čehokoli, nejen LVM. To, co píšeš, podle mě nejsou dostatečné argumenty.

[Mrkva]

Pořád slyším "initramfs, initramfs". To ale *není* řešení z několika prostých důvodů:

1. Initramfs se před použitím musí celý nahrát do paměti, na stroji s málo RAM mám smůlu.

2. Když chci v rescue prostředí kouknout např. na rootovo .bash_history, a to rescue prostředí je initramfs mám smůlu.

3. Initramfs je read-only, když si chci uložit nějaké logy, dumpy a podobně tak mám smůlu.

Jasné?

[little.owl]

Jaka je prumerna velikost RAM a initramfs?

Dalsi agumenty nestoji ani za komentar.

[pavlix]

Harald říkal na Fedoře tuším něco o 12 MB nerozbalených i s NetworkManagerem a závislostmi včetně kryptoknihoven. Jenže si nepamatuju kolik rozbalených.

Průměrná velikost RAM není ani tak zajímavá jako rozumná spodní hranice. A tu v dnešní době vidím na 128 MB pro console-only, pokud se v tom nechceš příliš vrtat. Pod 128 to vidím už spíše na specializované embedded distribuce, kde se to řeší jinak. Aby se tomu běžně říkalo počítač, tak by to mělo mít podle mě 1GB, takže se takovéhle věci vůbec neřeší.

[little.owl]

Harald říkal na Fedoře tuším něco o 12 MB nerozbalených i s NetworkManagerem a závislostmi včetně kryptoknihoven.

Tak nejak. Ty reci o 500MB mi prijdou uplne mimo.

Pod 128 to vidím už spíše na specializované embedded distribuce, kde se to řeší jinak.

Presne tak. Nejmensi system na kterem loaduji Linux ma 32MB a skutecne se resi vse jinak.

[pavlix]

1. Initramfs se před použitím musí celý nahrát do paměti, na stroji s málo RAM mám smůlu.

Stroje s málo RAM neprovozuju. I blbej router za pár stovek má 32 MB. Stroj, na kterém chceš dělat něco reálného, by těch 128 MB mohl dneska v minimu mít, ne?

Pokud v dnešní době provozuješ stroje s <128 MB s podstatnou částí FS na komplikovanějším úložišti, musíš počítat, že s tím bude trochu práce navíc (třeba vyházení nepotřebných věcí z initramfs).

2. Když chci v rescue prostředí kouknout např. na rootovo .bash_history, a to rescue prostředí je initramfs mám smůlu.

Pokud jsi schopný namountovat root, tak se k tomu dostaneš. Pokud ne, tak se k tomu nedostaneš stejně tak. Tenhle argument neberu.

3. Initramfs je read-only, když si chci uložit nějaké logy, dumpy a podobně tak mám smůlu.

Stačí si namountovat read-write úložiště a můžeš si do něj psát, co chceš, bez ohledu na to, že samotný initramfs je read-only.

Jasné?

Podle mě jsi napsal jeden jediný relevantní argument, a to ten úplně první. Já osobně initramfs vidím nejen jako řešení, ale v mnohých případech jako nejlepší řešení a kdyby sloušený /usr byl status quo, tak bych ho 100% upřednostil před jeho rozdělováním.

[Mrkva]

Pokud jsi schopný namountovat root, tak se k tomu dostaneš. Pokud ne, tak se k tomu nedostaneš stejně tak. Tenhle argument neberu.

Porovnáváme initramfs a root. Ekvivalent pro "nenamountuji root na stroji s bez initramfs" je "nenatáhnu initramfs".

Stačí si namountovat read-write úložiště a můžeš si do něj psát, co chceš, bez ohledu na to, že samotný initramfs je read-only.

Opět. S namounotvaným / můžu psát rovnou a nemusím řešit nějaké externí úložiště, mountování dalších FS a podobně. Zkrátka je to jednodušší.

[pavlix]

Porovnáváme initramfs a root.

Pokud se stále bavíš o bootovacím či rescue initramfs, tak nikoliv, protože v obou případech je ultimátním cílem připojit funkční root.

Zkrátka je to jednodušší.

A nebo složitější, záleží na úhlu pohledu. Mám dojem, že se někdy donutím o tomhle napsat článek, protože diskuze byla velmi inspirující.

[R]

Pridavat stale dalsie a dalsie veci do initramfs nie je riesenie. Uz tam bude chybat len Xorg s KDE 5. Bude to mat 500 MB, na nabootovanie bude potrebne minimalne 2 GB RAM a BIOS bude ten initramfs z disku citat pol hodinu.

[little.owl]

Pitomost.

[pavlix]

Pridavat stale dalsie a dalsie veci do initramfs nie je riesenie.

Naprosto souhlasím. Do bootovacího initramfs patří jenom nástroje nutné pro boot, popřípadě sada nejzákladnějších nástrojů pro opravu. V lepším případě můžeš mít k dispozici separátní rescue initramfs, kde bude cokoliv.

Uz tam bude chybat len Xorg s KDE 5.

Ale vůbec není problém postavit initramfs třeba včetně Xorg a co já vím Gnome Shellu. A není na tom vůbec nic špatně, initramfs jde používat na více účelů než jenom ten hlavní.

Pokud se ale bavíme o tom, zda v klasickém initramfs mají být nástroje potřebné k namountování klíčových filesystémů, tak ty by tam podle mě být měly a dost těžko mě budeš přesvědčovat, že ne.

[taz]

Tak hele pověz mi, co zrovna obsahuje tvuj initramfs, já Ti mezitím řeknu, co je v mém /, nějakou pohádku od Boženy Němcové a možná Ti i stihnu krásně zazpívat. Když se dostane i na ten hypotetický rescue, možná to bude i nějajá árie z prodané nevěsty. A protože toho určitě ještě nebudeš mít dost, zkusíme přidat záchranný shell skript adminuv-svycarsky-nozik. Ty do initramfs, já na /, než to budeš mít, dám si partičku šachů, abych Tě víc nerozptyloval. Když to konečně budeš mít, zkusíme nainstalovat nové jádro a uvidíme jestli Ti ten skript zůstal v aktuálním initramfs. A takhle budeme pokračovat tak dlouho, dokud Ti nedojde, že standardní filesystem s normálním přístupem je něco tak skvělého, že jenom blázen se o to může dobrovolně připravit. Prozačátek mi ale můžeš říct, jak mi pomůže starý schovaný initramfs nabootovat nové jádro, to mě fakt zajímá, jak to začaruješ, aby si se dostal k potřebným modulům

[pavlix]

http://www.flickr.com/photos/54644045@N08/5055032357/

[taz]

Já vím, obvykle nemluví k věci a snaží se druhou stranu urazit. Ale v takovém případě jen stačí v rozhovoru nepokračovat tak, jako to teď udělám já.

[Petr Ježek]

Koukám, že tu nikdo netuší, k čemu všemu je instalační médium... Pochopitelně ramdisk je elegantní řešení všeho popisovaného, že se sním doposud nepracovalo je spíše svědectví o adminovi...

[xxxxxxxxx]

Osobne mam linux velmi rad a pracujem s nim denne v praci, ale ten bordel v suborovom system nevyvazi ziadne tvrdenie o nejakej spetnej kompatibilite, proste vyvojary by sa mali zobudit a prist s niecim novym. Vyvoj ide dopredu nie dozadu, nechapem naco je koncovemu uzivatelovy kompatibilita s nejakym inym systemom ktory vzivote nevidel ani nechce vidiet, alebo architekturou ktoru prestali vyrabat pred 25 rokmi. Inak nasrat setko do jedneho adresara a nazvat ho bin, lib ... mohol byt uzasny napad mozno pred 20 rokmi, este potom musis udrziavat nejku posranu databazu kde co je aby si to mohol odinstalovat (este som nestretol distribuciu v ktorej by po odinstalovani v system po danom programe nezostal nejaky bordel config alebo sa neposrala databaza nainstalovanych applikacii) ... si zoberte priklad s mac os, kazda app ma vlasny adresar a ked ho hodim do kosa je prec, koniec. Prajem pekny den :)

[Bedňa]

Evidente vieš o adrasárovej štruktúre Linuxu kulové. Čo tak malé porovnanie s Win?

[xxxxxxxxx]

Mozno ano mozno nie (o tom ake mam znalosti a nie mozeme polemizovat pri pive ...), staci mi vediet ze v to je bordel, win to je bordel na 2 tam si pre istotu este mnohokrat projekty niesly vsetky knihovny sebou, odporne. Pozri nemam jasne riesenie toho problemu ale sucasny stav nejake potrebuje.

[Bedňa]

Konfiguráky u užívateľa je jedna z veci čo som si na Linuxe zamiloval a dnes sa tuším rovnako správa aj Win. Odinštaluješ, nainštaluješ a nastavenia sa ti zachovajú pre každého užívateľa. Chceš aby to všetci užívatelia mali rovnaké, tam všetkým užívateľom nakopíruješ ten istý konfig, nieje to krása :) Niečo sa pokurví, konfig zmažeš, easy.

[pavlix]

si zoberte priklad s mac os, kazda app ma vlasny adresar a ked ho hodim do kosa je prec, koniec. Prajem pekny den :)

Proboha jenom to ne.

[R]

Mac OS X ma tiez /bin a /usr...

[xxxxxxxxx]

pravda ma ale je tam len skutocne zakladny system ±10 systemovych nastrojov, no nic nie je dokonale. Nemusis prevziat zle veci predsa

[mankind_boost]

Přečti si FHS.

[xxxxxxxxx]

Ja nemyslim tym ze je tam bordel to ze nevieme kde co je v linuxe ale to ze je v tych adresaroch piate cez deviate, proste ked sa kuknem do svojeho ubuntu v usr/bin je tam ±2500 binariek, a to tam skoro nainstalovane nic nemam. Predstav si ze prides do kniznice a tam to nebude zoradene podla abecedy a zanru alebo autora ale bude tam napisane "knihy" a bude tam chytry knihovnik ktory tam robi 20 rokov a vie kde je co, ja sa necudujem ze ludia potrebuju mat na svojich pocitacoch indexovanie a vyhladavanie lokalneho obsahu (ked nevies kde co je tak a mas tam toho mraky co ti ine zostava ze)

[Josef Kufner]

Vždyť tak je to zcela v pořádku. A je to tak i v knihovně.

V knihovně máš také knihy na vcelku neuspořádané hromadě (řazení je podle ID, ne podle názvu) a pak máš vedle různě řazené indexy (kartotétky) pro rychlé vyhledávání, kde se dozvíš polohu a ID hledané knihy.

Když chceš spustit program, otevřeš si menu, kde je máš seřazené podle čeho chceš. Když klikneš na položku v menu, veme se název (ID), koukne se do { /bin, /usr/bin, /usr/local/bin } na polohu na disku a tadáá.

[mankind_boost]

"Predstav si ze prides do kniznice a tam to nebude zoradene podla abecedy"
Dynamic loader cache? Nic ti to něříká?

[Admin]

Ja som za - jebat 20 rocne standardy!

[Dadam]

Hlavně v průběhu updatu nerestartovat. A neodinstalovávat grub s tím, že zapomenete nainstalovat grub2. A když už, tak zkontrolovat jestli funguje cdromka a máte po ruce live cd. A když ne, tak mít aspoň připravený druhý počítač, na kterém se nesekají downloady velkých souborů. Ideálně to ani nedělejte dva dny před deadline projektu v práci.

Ale jinak celkem poučně strávené 4 hodiny.

Za ty tři roky první update co mi "rozesral" systém, a to to ještě byla moje chyba.

Jinak co má každý proti systemd? Odečtěme pana L. Odečtěme lidi co mrnčí že je to jiné než starý systém. Co zbyde za problémy? Proč když vadí tak strašné spoustě lidí, tak se dostává všude, a nikde se nevynořují distibuce bez něj? Z toho, co vidím (přiznávám, že moc aktivně nesleduju), se mi zdá, že na systemd se nejvíc nadává v hospodě u piva.

[potato]

Spousta lidí prostě nesnáší pana L. a hledá důvody, proč včechno, co dělá, je vždy špatně. Komprimace souborů v /usr/share/doc v Debianu je naprosto naprd, už mi rozbila mnohem víc věcí než systemd, pluseaudio a všechny další lennartoviny dohromady, ale zkuste na ni debianistům sáhnout...

[pavlix]

Spousta lidí prostě nesnáší pana L.

A proč asi?

[Petr Ježek]

Racionální vysvětlení emotivních postojů je předem prohraná bitva :)

[mankind_boost]

Všechno má nějaký důvod. To není, že se statisíce lidí najednou seberou a začnou "hejtovat"

[pavlix]

Spíš by bylo zajímavé, proč ti stejní lidé stejným způsobem nenadávají na jiné aktivní open source vývojáře. Já neříkám, že to jde plně racionálně vysvětlit, ale než bych těm lidem nadával, že na něj nadávají, tak bych se o ty důvody alespoň zajímal. Ono je hrozně krásné házet hesly jako haters gonna hate, jenže ty se jednou hodí tomu, jednou jinému.

[pavlix]

Z toho, co vidím (přiznávám, že moc aktivně nesleduju), se mi zdá, že na systemd se nejvíc nadává v hospodě u piva.

Je to tak. Další problém je v tom, že Lennart řeší reálné problémy, na které jiní dlouhodobě kašlou a na tom si sbírá body. Aneb když veteráni usnou na vavřínech, musí vzít vývoj do ruky někdo nový a odbornístí ani pečlivostí se jim vůbec nemusí rovnat.

[rADOn]

Zajímavý že já z toho mám přesně opačnej pocit – že Lennart a Kay jsou chytrý kluci s dobrejma nápadama, ale zaměří se na jednu věc a unikají jim reálný problémy okolo.

[bugme]

Ja mam z nich pocit ze to sou Windowsaci a chcou vsechno pokurvit tim ze to chcou priblizit svemu oblibenemu os.

[mrv]

ja mam pocit, ze jsi idiot a mel bys tahnout do prdele.

[Petr Ježek]

Schopnost řešit věci systémově z gruntu není rovnoměrně rozdělena mezi populaci. Je potvrzeno, že držkují nejvíce ti, kteří místo poděkování, když už nic neplatili, nejsouce schopni podílet se na vývoji či alespoň respektovat doporučení uživatelům, nechtějí žádné změny, protože si zvykli. Proč ale potom používaní Archlinux mi uniká...

[pavlix]

Tady máš naprostou pravdu. Tady je akorát problém s tím, že držkují už i ti, co se aktivně podílejí a dokonce i open source veteráni.

[pavlix]

To ale vůbec není opačný pocit. Pokud teda nebereš jako opačné to, že ty si myslíš, že jim ty (druhotné) problémy unikají, zatímco já si myslím, že je k tomu ještě navíc vědomě ignorují, protože se na nich nedá tak hezky blejsknout a může to bez problémů odedřít „námezdní síla“ z Brna.

[mrw]

Na hlavní stránce archu je návod, jak postupovat. Žel jsem ho neprovedl důsledně a některé balíčky mně přišly jako hodně systémové, rozhodně mnou nezkompilované, tak jsem je tam nechal a po resetu systém nenaběhl

Rychlá pomoc je taková, že jsem stáhnul poslední instalační CD archu, nabootoval a z živého systému jsem překopíroval /bin a /sbin na HDD a už zase všechno jelo.

Stejně ale chci arch přeinstalovat, abych se zbavil starých konfiguráků initu a mého konfiguračního slepence systemd+init. Také mám nainstalovány věci o kterých ani nevím, už jsem na ně zapoměl a jen zabírají na disku místo, takže i proto čistá instalace.

Teď jen řeším, kam zálohovat 400 GB RAW fotek a protože má káždý ze známých zaplněný externí HDD svýma věcma, zkusím to jen překopírovat na nově vytvořený oddíl na HDD.

[Petr Ježek]

Slepenec je snadno odstranitelný ve prospěch čistého systemd snadno dle wiki. Nicméně úklid bince je žádoucí univerzálně :)

[mrw]

Arch úspěšně přeinstalován, systemd je celkem jednoduchý akorát mě překvapilo, že se moje síťová karta nejmenuje eth0. Asi 10 minut jsem se pral se "systemd enable dhcpcd@eth0" a až pak jsem přišel na to, že se tam píše místo eth0 cosi strašně škaredého.

Jinak klávesnice do konzole je cz-qwertz a ne cz-lat2 jak by plynulo z anglického "instal guide" a odkazované tabulky.

Český font do konzole jsem nerozjel, v českém návodu avizovaný "Lat2-Terminus16" mně nějak nefunguje.Dál to neřeším, stejně hned startuju do KDE.

Takže to by byly dva zápory a jinak vše funguje. Jsem rád, že jsem si takto konečně "uklidil"

[pavlix]

Arch úspěšně přeinstalován, systemd je celkem jednoduchý akorát mě překvapilo, že se moje síťová karta nejmenuje eth0. Asi 10 minut jsem se pral se "systemd enable dhcpcd@eth0" a až pak jsem přišel na to, že se tam píše místo eth0 cosi strašně škaredého.

Pokaždé, když mám co dočinění s dhcpcd, tak si jen ověřím, že ho fakt nemám rád.

[kralyk z abclinuxu]

+1. dhclient rulez.

[pavlix]

Tak mě hlavně přijde, že dali vývojáři dhcpcd špatné jméno. Působí to jako by to měl být DHCP klient a oni z toho zatím dělají další NetworkManager ;).

[PSIkappa]

Staci mat busybox a system je znovu pouzitelny. Bud ho priamo zapracovat do initram-u alebo ho kludne mozete mat ulozeny v /bin.

Rozne embedded krabicky s linuxom vlastne ani nic ine nepouzivaju a dokazu normalne fungovat.

http://busybox.net/

[p.c.x.]

RH strikes back. S LSB jim to moc nevyslo - jen mala cast distribuci ho akceptovala a zaplatila vypalne. Se systemd je to uz jina liga.

Priznavam, ze by me nenapadlo jak jednoduse jim to muze projit a jak lehce vetsina hracu na poli tvurcu/provozovatelu distribuci padne do zajeti. Vim jak vyznamne se RH podilel a podili na upstreamovych projektech, ale tohle podle me uz prekrocilo unosnou hranici. Chapu, ze je to komercni subjekt a cilem je dominance na trhu a s tim spojene zisky, ale s pouzivanyma metodama na urovni vendor lock-inu nebo sirenim FUDu se nemuzu ztotoznit a nezadaji si ani s jednou nejmenovanou firmou z Redmondu.

Ten "napad" na slouceni adresaru vidim jen jako zkousku demonstrace sily a vlivu. Nejdriv se umele vytvori problem ("neco nefunguje, prestoze to funguje", "neco hrozi, prestoze neohrozuje") a pak se prijde s predem pripravenym resenim, ktere je nutne bleskove prosadit, aby cile nezacaly o tom vic premyslet. Vysledkem je ziskani pozice, upevneni moci nebo primo naplneni kapes. Tenhle princip funguje univerzalne, ve vetsim i v ramci politickych systemu.

[pavlix]

Hezké. Kdyby v RH nepanovalo zděšení nad výsledky této práce.

[taz]

Kdyby to RH opravdu děsilo, RH by to nedělal.

[kavol]

a "RH" je co?

je tvůj výrok vůbec nějak v rozporu s tím, co napsal pavlix, anebo co se tím snažíš říct?

[taz]

RH je podnik, který "to" všechno dělá. Jestli to tam náhodou opravdu někoho vzrušuje a spravedlivě si na to zanadává o obědové pauze nebo na kuřplace, nebude to nikdo důležitý. To bude něco jako když se ve škodovce rozčilují uklizečky, že je prodali němcům, nemyslím si, že by někoho napadlo říkat tomu zděšení v mladé boleslavi. To se tím snažím říct.

[kavol]

RH je podnik, který "to" všechno dělá.

to zní skoro jako kdybysme byli Borgové

pokud uklízečky ve škodovce navrhujou motory nebo se staraj o splnění příslušnejch certifikací při crash testech apod., no tak potom ti to přirovnání i sedí ...

[pavlix]

Kdybys alespoň pečlivě četl, na co reaguješ, když už je to jen jedna věta...

[gnat]

Děkuji ti náčelníku, že jsi mi to objasnil v širších politických souvislostech. Já si doteď myslel že to vznklo tak, že se partička vývojářů zhulila a přišlo jim jako báječnej nápad rozbít něco, co desítky let bez problémů funguje.

[rADOn]

Nemusí být všechno hned spiknutí a zlý úmysl. Když si přečteš to Kayovo zdůvodnění, tak se tam pořád mluví o snadnější portaci kódu z komerčních unixů. Hned jsem si říkal že určitě dělá pro nějakou firmu která se tím zabývá. Je běžné že firmy přispívaj do linuxu prací na něčem co je pálí a tím se věci hýbou kupředu. Taky je běžné že když tím rozbijou něco co sami nepotřebujou tak je jim to u prdele a je na širší komunitě aby to zkorigovala – viz třeba trnitá cesta andráše do jádra. Nic složitějšího v tom není.

[Petr Ježek]

Jo, to nejen zní rozumně, ale je to dle mých informací i realita. Přiznejme si, že jediný problém s migrací binárek je množství fixů v značně chaoticky tvořeném systému, ve standarním udržovaném problém neexistuje. Pak je tu nutnost symlinků kvůli proprietárním binárkám, jejichž vývoj je neovlivnitelný (prozatím), což je jen dočasný oční nesoulad. Pak je tu ale potenciálně něco, co jde znalostně mimo mne - jak souvisí migrace binárek pod /usr s bezpečností systému?

[mankind_boost]

"v značně chaoticky tvořeném systému, ve standarním udržovaném problém neexistuje."
? Slyšel jste vůbec někdy o FHS? Nebo LSB?

[pavlix]

Tohle mi nepřijde jako relevantní argument. Zrovna tihle kluci s oblibou FHS ignorují, vysvětlují si ho po svém nebo si vysvětlují návrh jako finální standard. A pokud jde o LSB, to snad ani radši nebudu komentovat.

[mankind_boost]

"Zrovna tihle kluci s oblibou FHS ignorují"
To myslíte Lennarta?

[pavlix]

Tak nějak.

[kralyk z abclinuxu]

Slyšel jste vůbec někdy o FHS?

Jo. Například adresáře /etc/xml a /etc/sgml nepovažuju za nejbrilantnější nápady ve FHS. Nic není černobílý...

Mimochodem, ví někdo, jak má vypadat FHS 3.0?

[pavlix]

Hned jsem si říkal že určitě dělá pro nějakou firmu která se tím zabývá.

Rovněž mám občas pocit, že někteří jedinci pracují pro jinou firmu, než pro tu, která je zaměstnává ;).

[nyan]

Jenom dalsi mirny vopruz, kterejch zacina byt v Archu spousta... misto toho aby resili skutecne problemy distra, jako treba neexistenci debuginfo balicku...