Oracle RedPatch - jádro RHEL pomocí GITu (diskuse)

[l4m4]

RHEL opatchovávají, seč jim síly stačí, takže na opatchování Javy už jim žádné nezbývají...

[victor8]

?

Nejaky problem?

[luky]

Zrejme narazi na zabugovanost jre na linuxu. V GUI knihovne (nepamatuju uz si jmeno) je dost chyb a Oracle na ne sere (stejne jako predtim SUN).

[Kamil Páral]

Toolkit se jmenuje Swing a je to podle mě naprosto mrtvá záležitost (vím, o čem mluvím, mám v tom napsanou Esmsku). Dá se to stále použít pro velmi specifické případy, ale příjemná GUI aplikace s v tom na Linuxu už nenapíše ani náhodou, a myslím že už ani na jiných systémech. Někde jsem četl, že chtějí časem Swing nahradit pomocí JavaFX, ale who cares, Java je na desktopu stejně už kompletně zabitá.

Myslím si ale, že reference byly k těm vážným bezpečnostním problémům, které jsou v Oracle Javě, a Oracle je patchuje se zpožděním několika měsíců.

[Zopper]

A to i když má opravný patch k dispozici hned po odhalení. :( Jak na tomto produktu mohou být postavené systémy pro el. bankovnictví v celém západním světě fakt nechápu, zlatá čr, kde skoro všude stačí akorát prohlížeč s javascriptem.

[JirkaH]

ty jsi to asi moc nepochopil...

[l4m4]

Myslím si ale, že reference byly k těm vážným bezpečnostním problémům, které jsou v Oracle Javě, a Oracle je patchuje se zpožděním několika měsíců.

Ano. Myslel jsem, že je zjevné, na co narážím.

[little.owl]

Někde jsem četl, že chtějí časem Swing nahradit pomocí JavaFX,

Ano a dokonce to uz po oraclovsku otevreli a plne by to melo byt udelano v lednu.

[Saljack]

A používá vůbec někdo JavaFX? Má s tím někdo zkušenosti. Koukal jsem, že je to celkem podobné QML a to mě teda vůbec nenadchlo.

[snajpa]

Jsou to idioti, obe dve strany. Mohli by se domluvit na necem jako Enterprise Kernel Alliance a benefitovaly by z toho obe firmy vcetne jejich zakazniku. Tohle, co predvadi Red Hat, se mi moc nelibi. A jak Oracle nemam rad, tak jim preju, aby se jim to darilo a dotahli to do konce - sam obcas narazim na nejaky bug (naposled otravne problemy s locky na NFS) a videt commity by se mi strasne hodilo v debugovani.

[Marek 'marx' Grác]

A ako by to malo fungovať? Tie patche sú v upstreame korektne, tam sa ich nikto nesnaží skryť. Teoreticky by to mohlo fungovať, ak by mal Oracle skutočne vlastný produkt, dohodli sa na rovnakých podporovaných verziách kernelu a zdieľali by sa náklady (RH má v kerneli obvykle 5x viac nového kódu než Oracle).

Takto to má Oracle za pár korún ( a čas naviac ), lebo stačí rozkľúčovať commit na patche. Časť je triviálna a časť je vďaka pravidelnému rozbíjaniu vnútora kernelu zabitá, takže by som nebol prekvapený, keby sa to rozdelilo na identifikované patche + bordel :)

[Michal Kubeček]

Časť je triviálna a časť je vďaka pravidelnému rozbíjaniu vnútora kernelu zabitá, takže by som nebol prekvapený, keby sa to rozdelilo na identifikované patche + bordel :)

Jeden z příspěvků v diskusi tvrdí, že to tak víceméně je - tj. jednotlivé identifikované upstreamové commity a pak jeden velký "ostatní mezi verzemi X a X+1".

[l4m4]

Problém by se snadno vyřešil, kdyby Oracle zkrachoval a nechal toho. Nebo toho alespoň nechal jen tak, protože toho prvního se asi v dohledné době nedočkáme. Jsem přesvědčen, že RedHat by pak přestal dělat naschvály -- začal s tím až v reakci na Oracle.

[kavol]

Jsem přesvědčen, že RedHat by pak přestal dělat naschvály -- začal s tím až v reakci na Oracle.

+1

miluju tyhlenty experty, co nechápou, že reakci předcházela akce ... anebo chápou, ale musí pomlouvat, kudy chodí, protože už nejsou na výplatní pásce RH?

[blami]

Otazkou pak jest, co RedHat tak stve, ze dela naschvaly.

Osobne nemam rad jednani, ze smerem k uzivateli volam "ooo jsme open a free as in freedom". A kdyz pak prijde nekdo komu se to hodi do jeho kramu, zkompiluje to a nabidne stejny servis levneji nebo dokonce zadara (jestli stejne mizerny, nebo stejne dobry necham na bystrem ctenari), tak zacnu delat naschvaly. Horsi varianta je, ze krome me konkurence se to dotkne i uzivatele (v tomhle pripade jiste ne bezneho, ale vedet ktery commit mi rozbil NFS zamky neni az tak od veci, jak uz tu nekdo rekl).

Reakci predchazi akce. Tou muze byt treba kritika o premrstenych cenach RedHatu databazovymi zakazniky Oraclu. Neni to trochu i tak?

[kovariadam]

Horsi varianta je, ze krome me konkurence se to dotkne i uzivatele (v tomhle pripade jiste ne bezneho, ale vedet ktery commit mi rozbil NFS zamky neni az tak od veci, jak uz tu nekdo rekl).

Subsciberi predsa k jednotlivym patchom pristup maju.

[blami]

Ano, ale ve smyslu GPL je teoreticky uzivatelem kazdy kdo kod pouziva - tedy i ten kdo si ho stahne a sam prelozi, a treba neni subscriberem RHEL. Samozrejme chapu, ze v byti subscriberem je pridana hodnota o ktere mluvite, jestli mi rozumite. Chtel jsem poukazat na to, ze RedHat tak trochu praktikuje metodu cukru a bice na ty kdo subscriberi nejsou (ale jsou stale uzivatele, nemluvim jen o uzivatelich OLS ale i treba CentOS).

Protoze jsem nikdy RHEL subscriberem nebyl, nevedel jsem ze subscriberi maji pristup i k jednotlivym patchum. Muzete mi zkusit svoji domenku na tema co brani Oracle v tom stat se subscriberem a jednotlive patche prevzit do Red Patche? Ve smyslu GPLv2 by takove jednani bylo tez v poradku, ne?

[pavlix]

Ano, ale ve smyslu GPL je teoreticky uzivatelem kazdy kdo kod pouziva

GPL z nějakého důvodu neřeší přístup k jednotlivým patchům, ale ke kompletním zdrojovým kódům. Přístup RH, je legální a legitimní, i když podle mě trochu nešťastný, ale nemám o tom dost informací, abych soudil.

Ve smyslu GPLv2 by takove jednani bylo tez v poradku, ne?

Je otázka, zda lze míchat přístup „být subscriberem“ a „užívat všech možností, které GPL poskytuje“. A je to právní otázka.

[kovariadam]

Ako tu uz viac krat bolo spomenute:

• Red Hat posiela vsetok kod do upstream jadra
• jednotlive patche vyvijane Red Hatom su viac-menej internym sposobom vyvoja a su poskytovane platiacim zakaznikom; ak uzivatelia CentOSu potrebuju detailny pristup k praci Red Hatu, maju moznost prejst na RHEL alebo mozu pouzivat upstream/iny kernel
• Oracle by sa mohol stat subscriberom, samozrejme, a mohol by s patchmi v ramci GPL pracovat, avsak tym by sa mu skoncila zmluva(to som videl tu v komentaroch, nie som si isty ci je to pravda, ale logiku to ma) - co mi vsak pride pochopitelne

Preco Oracle nelicencuje napriklad DTrace/zfs pod GPL a neposle ho do upstream jadra? Je to skutocne Red Hat kto by akokolvek znemoznoval komukolvek pouzivat/upravovat/dalej predavat ich jadro? Red Hat sa GPL drzi, Oracle sa mu vyhyba kde len moze, az na pripad kedy zneuziva pracu Red Hatu, vtedy sa im to hodi...

[kavol]

Ano, ale ve smyslu GPL je teoreticky uzivatelem kazdy kdo kod pouziva - tedy i ten kdo si ho stahne a sam prelozi, a treba neni subscriberem RHEL. Samozrejme chapu, ze v byti subscriberem je pridana hodnota o ktere mluvite, jestli mi rozumite. Chtel jsem poukazat na to, ze RedHat tak trochu praktikuje metodu cukru a bice na ty kdo subscriberi nejsou (ale jsou stale uzivatele, nemluvim jen o uzivatelich OLS ale i treba CentOS).

a) pak ale nejsou uživateli RHEL, a tedy není důvod, proč by pro ně RH měl něco dělat (resp. dělat ještě něco víc než co pro ně dělá), jak zde již bylo několikrát vysvětleno

b) věř mi, že otázka, jak co nejméně uškodit (i když přesnější by bylo "co nejvíc prospět") ostatním (tedy i CentOSu), byla přetřásána dokud kůň nezemřel a ještě dlouho poté

Protoze jsem nikdy RHEL subscriberem nebyl, ...

hm, kdo to výše psal něco o tom, že chce vědět, který commit do jádra RHELu mu rozbil NFS?

[Lukas]

O cem to tady placate, jake naschvaly ? Vsechen jaderny kod vyvinuty v Red Hat je upstream, to je Vam malo ? Co by jste jeste nechteli ? Aby Vam vyvojari Red Hatu zdarma prisli k vam domu ukazat jak vlastne delaji svoji praci jejiz vysledek je volne k dispozici ?

Kdyz mi neco rozbije NFS zamky a jsem zakaznik Red Hat, tak jsou snad tady od toho aby to zase dali doporadku ... od toho jsem jejich zakaznik. Pokud nejsem zakaznik Red Hatu, nemuzu cekat ze mi nekdo pomuze a budu si holt muset v tom kodu ten problem najit sam - kod k dispozici mam. Nevidim jak neco takoveho muze mit negativni dopad na uzivatele...prave naopak ne ? Mam moznost do kodu zasahovat jak se mi zlibi.

[JirkaH]

+1

[Ivan]

RHEL vam tak maximalne doporuci abyste si nainstaloval nejnovejsi verzi kernelu. Kdyz uz ji mate tak jsou vetsinou v koncich. Ne ze by nemeli lidi co kernelu rozumi, akorat jich zrejme nemaji dost a tak voli zdrzovaci taktiku jako kazda jina komercni firma.

[Ivan Vecera]

Nejaka osobni zkusenost?

[Michal Kubeček]

To není žádná zdržovací taktika. Čas vývojářů je drahý (i ve smyslu finančním) a je neefektivní ho plýtvat na to, aby znovu a znovu analyzovali bugy, které už dávno opravili a vydali na ně update, jen proto, že zákazníkovi se nechtělo otestovat aktuální update a pořád používá verzi z DVD.

[Käyttäjä 11133]

To je jenom důkaz toho, že RHEL není Enterprise záležitost, nedokážu si představit, že mi support storage vendora říká "Nevím jestli je to způsobené starým firmware, ale projistotu si ho aktualizujte". Lidi na supportu nejdříve analyzují ten bug a až pokud se zjistí, čím je to způsobené (jaké je BUG ref. nr.) tak se případně doporučí aktualizace. Ale přístup typu "no projistotu to aktualizujte, co kdyby náhodou jsme to nějak záhadně opravili, přestože o tom neexistuje záznam v naší databázi bugů", to do Enterprise prostředí nepatří.

Ostatně to ani není v souladu s Change Managementem podle ITILu, protože na každou change (která představuje riziko pro provoz infrastruktury) je potřeba mít smysluplný důvod a to, že "vendor, kterému platím nemalé peníze za support říká, že by to MOŽNÁ mohlo být už opravené v novém releasu OS, kernelu,..." není validní důvod k tomu, abych riskoval nedostupnost infrastruktury.

[kyytaM]

Tak potom ani HP and EMC (VMware) nie je enterprise zalezitost. Prva otazka z HP je vzdy, ci je najnovsi firmware. :D

[Käyttäjä 11133]

Prva otazka z HP je vzdy, ci je najnovsi firmware. :D

No minimálně u EMC po tobě upgrade FW nevyžadují u VNX, stejně tak ho nevyžaduje NetApp, HDS USP ani IBM u DSka.

[victor8]

Tak potom neviem, zrejme aj taka IBMka budu len nejaki ne-enterptise garazisti...

Ked otvarame SW call, prvou otazkou je, ci pouzivame aktualne verzie AIXu / System microcodu/ VIO servra / whatever...

[Käyttäjä 11133]

Na čež jim řekneš že ne, a první blbec na help-line ti řekne že máš upgradovat, tak mu řekneš, že chceš mluvit s duty managerem a s ním už je rozumná řeč. :)

[Ivan]

JJ dneska uz to dela i IBM. Kde jsou ty doby kdy kernel vychazel jednou za dva roky. A v pripade padu se core dump kernelu ukladal na pasku a posilal do USA. Tu pasky jsme uz nikdy nevideli, nase ucetni z toho silela. Tehdy se taky nedelaly zadny velky reorganizace helpdesku a tak se lidi mezi sebou vice-mene znali a kdyz vedeli, ze jim vola nekdo rozumnej tak se tomu vic venovali. Dneska, kdyz zavolate na helpdesk tak ani nevite na kterym kontinente skoncite. A nedej boze aby meli v Indii nejaky statni svatek.

[xkucf03]

+1

[Pavel Stárek]

Jaké kua naschvály? Je to prostě komerční firma, tak si to bude (a může) dělat jak chce. Dodává zdrojáky? Dodává, tak o co jde? A v oblasti linuxu RedHat odvedl daleko více práce než Oracle a ne jen v jádře. A že se tady zrovna všichni bijou za nějaký pitomý Oracle.

[Käyttäjä 11133]

Víš jaký je rozdíl mezi RH a Oraclem? RH se tváří, že jsou hodná Open Source firma, která naplno zvládla napasovat na Open Source funkční business model, kdežto Oracle si na žádnou hodnou Open Source firmu nehraje.

[pavlix]

kdežto Oracle si na žádnou hodnou Open Source firmu nehraje.

A proto je Oracle platinovým členem Linux Foundation a hlavním partnerem hromady open source akcí.

[kavol]

na první část již bylo odpovězeno, takže bych se jen zeptal ...

Reakci predchazi akce. Tou muze byt treba kritika o premrstenych cenach RedHatu databazovymi zakazniky Oraclu. Neni to trochu i tak?

mno ... kolik že stojí systém a kolik že ta databáze?

[Käyttäjä 11133]

Takže (skutečné) Open Source ano, ale jen dokud nám někdo v souladu se špatným obchodním modelem nezačne konkurovat? :)

[pavlix]

Takže (skutečné) Open Source

Můžeš definovat, co je skutečné open source, které má platit pro Red Hat, a co je skutečné open source, které má platit i pro ty ostatní.

[Käyttäjä 11133]

Je to snadné, opensource může být cokoli, ale když zdrojáky releasneš u velkého projektu jednou za rok, bez historie commitů, nebo patchů, tak je to taková medvědí služba.

Když budu releasovat kód až po projetí preprocesorem, tak to taky bude opensource, ale asi budeš souhlasit, že to bude opensource pěkně na hovno, že?

[Michal Kubeček]

Je to snadné, opensource může být cokoli, ale když zdrojáky releasneš u velkého projektu jednou za rok, bez historie commitů, nebo patchů, tak je to taková medvědí služba.

Bohužel je takový přístup stále ještě dost rozšířený - viz třeba ksh nebo tcsh.

[pavlix]

Je to snadné, opensource může být cokoli, ale když zdrojáky releasneš u velkého projektu jednou za rok, bez historie commitů, nebo patchů, tak je to taková medvědí služba.

Zdrojáky k dispozici máš. Dokonce jednotlivé patche najdeš začleněné v upstreamu. Naprosto chápu, že by ti vyhovoval luxus mít k dispozici i jejich seznam nebo teda přímo patchset, radši než velký patch. Ale to není nic než tvé přání a nemění to nic na tom, zda je to open source či nikoliv.

Když budu releasovat kód až po projetí preprocesorem, tak to taky bude opensource, ale asi budeš souhlasit, že to bude opensource pěkně na hovno, že?

Tak to open source nebude a už vůbec ne GPL.

[Michal Vyskočil]

Když budu releasovat kód až po projetí preprocesorem, tak to taky bude opensource, ale asi budeš souhlasit, že to bude opensource pěkně na hovno, že?

2. Source Code
...
The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
open source definition

[Käyttäjä 11133]

Deliberately obfuscated source code

To platí i pro ty RH patche, ne? :)

[Michal Vyskočil]

No, pokud to chápu správně, tak RedHat poskytuje src.rpm balíky, kde je jeden tarball s vanilla kernelem a aplikovanými distribučními patchi. Obávám se, že buďto má slovo obfuscated ještě jiný význam, který neznám, anebo jej někdo napínáš až za únosnou mez

[Käyttäjä 11133]

jej někdo napínáš až za únosnou mez

Já bych řekl, že přesně na hranici únosné meze. :-p Ale stále trošičku uvnitř :D

[pavlix]

A tarball se zdrojáky bez originálů a bez patche by byl kde? To je totiž to jediné, co se požaduje po ostatních firmách.

[Käyttäjä 11133]

Na úplně stejném místě, protože diff umí spustit i cvičená opice, kdežto na segmentování jednotlivých patchů, z jednoho diffu tomu člověk už musí rozumět.

[pavlix]

No ne, mě by pořád zajímalo na jakémže to základě jsou ty povinnosti vyplývající z GPL a účasti na open source jiné pro Red Hat, než pro všechny ostatní.

[Michal Vyskočil]

Problémem bude to, že RedHat si dovolit něco změnit

[Michal Kubeček]

Do jisté míry ano. Již zmíněné ksh nebo tcsh (a další) takhle fungují odjakživa (a pokud ne odjakživa, tak předtím to bylo ještě horší) a i když si kvůli tomu postižení občas zanadávají, nikdo za to autory nepranýřuje.

[Michal Vyskočil]

To bude spíš tím, že historie změn v drobnostech jako ksh, nebo obskurnostech typu tcsh, prakticky nikoho nezajímá. Narozdíl od RedHatích jaderných patchů.

[Michal Kubeček]

Jistě. Proto jsem radši napsal "do jisté míry".

[pavlix]

Aha. To je asi to, co mě zajímalo.

[xkucf03]

opensource může být cokoli, ale když zdrojáky releasneš u velkého projektu jednou za rok, bez historie commitů, nebo patchů, tak je to taková medvědí služba

To by platilo jen za předpokladu, že bys i jednou za rok vydával binární verze a mezi tím nevydával ani aktualizace (včetně bezpečnostních). Jinak to open source není – viz jeho definice česky/anglicky.

Medvědí služba to rozhodně není a pro uživatele je to stále zásadní plus oproti proprietárnímu shitwaru – mám totiž zdrojáky, ze kterých si můžu zkompilovat přesně tu binární verzi, kterou používám.

Když budu releasovat kód až po projetí preprocesorem, tak to taky bude opensource, ale asi budeš souhlasit, že to bude opensource pěkně na hovno, že?

Buď to bude použitelné pro zkompilování binárek, které používám, nebo to není otevřený software. Opět viz definice:

Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

[Michal Kubeček]

mám totiž zdrojáky, ze kterých si můžu zkompilovat přesně tu binární verzi, kterou používám

Úplně přesně to bude jen pokud přesně zreprodukujete celé prostředí, ve kterém build provedete, což ani v kontrolovaném prostředí typu OBS nemusí být stoprocentně zaručeno. Ale až na výjimky by měl být výsledek funkčně ekvivalentní.

[xkucf03]

jj, tak jsem to myslel – binárky asi nebudou na bit stejné, ale budou stejně fungovat (funkce, kompatibilita s formáty, protokoly, API atd.).

[little.owl]

Staci se kouknout co musi delat v CentOS ....

[xkucf03]

Musí? On je někdo nutí?

[kavol]

Takže (skutečné) Open Source ano, ale jen dokud nám někdo v souladu se špatným obchodním modelem nezačne konkurovat? :)

co prosím? RH přestal být Open Source? - není to spíše tak, že se upravil právě ten obchodní model?

[Käyttäjä 11133]

Problém by se snadno taky vyřešil, kdyby Oracle přestal na RHELu podporovat Oracle DB, to by po RH v korporátní sféře už nikdo ani neštěkl a Oracle by mohl RH koupit za hubičku :D

[Franta]

1. to by nemohl udělat, ani kdyby chtěl, protože úřady pro ochranu hospodářské soutěže.
2. kdyby Red Hat koupili, tak se jim to rozpadne pod rukama jako většina open source projektů ze Sunu už kvůli odlivu lidí, protože pro redhaťáky je určitě dream job pracovat pro "nejsympatičtější" firmu v oboru. Inu, ne všechno se dá koupit penězi.
3. já bych si být nimi tak pevný v kramflecích s tou jejich databází nebyl. Podnikový trh má sice velkou setrvačnost, ale svět databází jde hodně dopředu, jsou tu nové trendy, nové typy databází, tak aby se jim jednou nestalo, že už nejsou tak nepostradatelní, natož aby někomu vyhrožovali, že ho nebudou podporovat.

[Marek 'marx' Grác]

1) Samozrejme, že by mohol. Stačí sprísniť podmienky pre certifikáciu, tak aby ich Red Hat nemohol splniť. Ale ono by to mohlo dopadnúť dvoma spôsobmi: * nahradiť Linux (lebo ak by certifikáciu zvládlo SuSe, tak to dá aj RH) * nahradiť Oracle - presun DB je hrôza, ale vďaka dlhej podpore na to mám ešte stále 5+ rokov

Táto možnosť nie je tak extrémne nereálna, aj preto RH rozširuje portfólio o veci typu virtualizácia, storage, jboss, ...

[pavlix]

Ona je otázka, kteří zákazníci se reálně nechají od Oracle dlouhodobě vydírat.

[David Jaša]

Viz maxovy blogy - "sice nás serou, ale jinam stejně nepřejdeme". Ono se to může změnit, ale nic rychlýho to nebude.

[pavlix]

Jo, tomu rozumím.

[Käyttäjä 11133]

Oracle nikoho nevydírá, jen má podmínky podpory, stejně jako je má HP, Dell, NetApp, EMC, SAP, RedHat, SUSE, IBM, a 99% firem v IT sektoru i dalších sektorech.

[pavlix]

Ani jsem netvrdil, že ano.

[Käyttäjä 11133]

No já nevím, mi se nezdá, že by se Solaris nějak rozpadl, jen se trošku shiftnul z "Operační systém pro všechny" na "Operační systém pro Exadata a Exalogic + pár skutečných zákazníků, kteří nešetří každou korunu a vyžadují robustnost".

[Michal Kubeček]

…tak se jim to rozpadne pod rukama jako většina open source projektů ze Sunu…

No já nevím, mi se nezdá, že by se Solaris nějak rozpadl…

Solaris je open source projekt?

[kyytaM]

A nacom by ten Oracle bezal? Na Windows? :)

[Käyttäjä 11133]

SUSE, AIX, Windows, Oracle Linux, Solaris.

[kyytaM]

Este si zabudol na HP-UX.:D Ano, Oracle Linux je fakt skvela volba, zabugovany paskvil s otrasnou podporou. A uz vidim s akym nadsenim bude Oracle hnat svojich zakaznikov z Red Hatu na AIX, k svojmu uhlavnemu nepriatelovi. Ked uz niekto prejde na servery a OS od IBM, tak preco rovno postupne neprejst na storage, zalohovanie a DB? A btw nie jeto prave Oracle, co kazdy rok pusta FUD ze AIX konci? :D Chapem, ze Oracle ma obrovske mnozstvo zakaznikov, ktori neriesia nejake drobne, ale tiez masivny prechod z RH na Solaris si akosi nedokazem predstavit, uz len kvoli poctu ludi, co vie robit s coraz minoritnejsim Solarisom. No SUSE - Novell to predal, nova spolocnost nema ziadne patenty (vsetko za babku skupil Microsoft a spol) a neviem ci uz niekto videl jej plan na najblzisich 5-10 rokov... Tak to uz si fakt len Windows... :D

[Michal Kubeček]

A btw nie jeto prave Oracle, co kazdy rok pusta FUD ze AIX konci?

To není FUD, to je klasická fáma nebo rovnou lež. FUD by byl něco jako "Na vašem místě bych dobře zvážil, jestli je rozumné sázet na budoucnost produktu X." - U jako Uncertainity, D jako Doubt. Ne natvrdo napálit "Produkt X bude končit."

No SUSE - Novell to predal, nova spolocnost nema ziadne patenty (vsetko za babku skupil Microsoft a spol) a neviem ci uz niekto videl jej plan na najblzisich 5-10 rokov...

No vidíte, že to umíte - tohle je FUD jak vyšitý.

[Käyttäjä 11133]

To není FUD, to je klasická fáma nebo rovnou lež. FUD by byl něco jako "Na vašem místě bych dobře zvážil, jestli je rozumné sázet na budoucnost produktu X." - U jako Uncertainity, D jako Doubt. Ne natvrdo napálit "Produkt X bude končit."

No já nevím, vzhledem k tomu, že jsem byl na pár prezentacích od IBM, kdy se nám ucházeli něco prodat, tak IBM je zrovna jedna z firem, která si to zaslouží, protože jejich obchodní taktiky a házení špíny na konkurenci je až směšné. IMHO si tím dělají medvědí službu, protože jsem se vždycky dozvěděl hromadu věcí o produktu konkurence, ale nikdy pořádně nic o produktu IBM a tak jsme většinou koupili tu konkurenci, když už jsme věděli jak to funguje. :D

[Michal Kubeček]

V mém příspěvku ale nešlo vůbec o to, kdo je hodný a kdo je zlý, a co si IBM zaslouží nebo nezaslouží. Jen se snažím bojovat proti tomu, že se termín FUD poslední dobou čím dál častěji bezmyšlenkovitě používá pro jednání nebo tvrzení, která s FUD taktikou nemají nic společného.

[kyytaM]

:D Tiez som sa dobre pobavil, ked do kancelarie prisiel priamo clovek z IBM, ze skusi sam s nasim loginom a heslom vyriesit neviditelnost nasich licenci na licencom portali IBM (po tom, co sa to uz tyzdne tahalo mailami a telefonatmi). Po hodine to vzdal. :D Nasledne dni potom uz len chodili CCcka so zufalymi prosbami a neskor vyhrazkami na vsemoznych ludi z inej divizie IBM. :D Ale treba uznat, ze napokon sa im to podarilo vyriesit...:D

[little.owl]

protože jsem se vždycky dozvěděl hromadu věcí o produktu konkurence, ale nikdy pořádně nic o produktu IBM

Prezentace IBM se vyznacuji tim, ze se snazi frazemi vzbudit dojem, ze jejich produkt silene potrebuji, bez neho ma firma brzy zkrachuje a neuspeje proti konkurenci, ale zjistit konkretne CO to vlastne prodavaji bylo pro me ponekud slozite a nejasne.

[Ivan]

O tom ze konci AIX jsem jeste neslysel. Na druhou stranu Oracle oznamil, ze konci s podporou pro Itanimum => konci HP-UX.

[Michal Kubeček]

To sice Oracle oznámil, ale pokud si dobře vzpomínám, HP je dal k soudu pro porušení smlouvy a vyhrál.

[Käyttäjä 11133]

Teďka je otázka na jaké úrovni ta podpora bude...

[little.owl]

Nicmene je to dukaz toho, ze duverovat Oracle je ponekud problematicke.

[Käyttäjä 11133]

Důvěřovat kterékoli nadnárodní korporaci je poněkud problematické.

[little.owl]

Smlouvy a dlouhodobe zavazky obecne jsou vzdy do urcite miry otazka duvery.

[David Jaša]

Akorát u některých je to problematičtější, než u jiných.

[kavol]

Problém by se snadno taky vyřešil, kdyby Oracle přestal na RHELu podporovat Oracle DB, to by po RH v korporátní sféře už nikdo ani neštěkl a Oracle by mohl RH koupit za hubičku :D

na to, jakýho ze sebe děláš světáka, víš teda úplný hovno ... achjo, svět se opravdu v prdel obrací, dřív takový jako ty prodávali naleštěnej prd, ty už se ani nenamáháš leštit ... :-/

[little.owl]

domluvit na necem jako Enterprise Kernel Alliance a

Partnerstvi vyzaduje duveru a to je posledni co si Oracle muze koupit.

[x]

A less publicized and unintended use of the GPL is that it is very favorable to large companies that want to undercut software companies. In other words, the GPL is well suited for use as a marketing weapon, potentially reducing overall economic benefit and contributing to monopolistic behavior.

[l4m4]

Not gettin' your drift chap... Anyway [citation needed]...

[little.owl]

Ne. GPL primarne chrani koncove uzivatele, BSD chrani distributory. To je take duvod, proc se ji treba Apple a dalsi velke firmy boji jak cert krize.

[xkucf03]

+1

(nicméně i distributor má z GPLv3 výhody – např. ho nějaký přispěvatel/autor nemůže patentově trolovat a otravovat s údajnými patenty obsaženými v daném kódu)

[Max]

Nesouhlasím. Po mnoha zkušenostech s Oraclem, jeho politikou a taktikou, fakt ne.
Zdar Max

[Vskutečnosti Saýc]

Z jedne strany, Oracle jsou smejdi. Z druhe strany, RedHat nadsene tlaci systemd a secureboot (a uz si mne ruce jak microsoft povoli jen windows a redhat), takze by taky mel umrit. V duskedku, koho to zajima? At si klidne delaji naschvaly.

[Max]

Hmm, tímto nikoho nerozesměješ, zkus vymyslet jiný vtip .
Zdar Max

[Michal Kubeček]

Systemd je zlo, to ano, ale jak podle vás Red Hat "tlačí Secure Boot"? Podle mne Red Hat jen usilovně pracuje na tom, aby uživatelé, kteří mají (nebo budou mít) počítač s UEFI Secure Bootem, mohli jejich distribuce na takovém počítači používat, aniž by museli UEFI Secure Boot vypnout (což mnozí z různých důvodů ani udělat nemohou). Výsledky té práce dávají k dispozici i do příslušných upstreamových projektů, což jim těžko mohu mít za zlé. Totéž současně dělá i SuSE.

[l4m4]

Systemd by bylo zlo, kdybychom měli pěkně fungující a snadno spravovatelný init se spoustou užitečných fíčur. Jenže jsme měli SysV init.

[pavlix]

A nebo taky OpenRC. Neříkám, že je dokonalé, ale tvrzení, že byl k dispozici pouze sysvinit by bylo nesprávné.

[little.owl]

Mne by celkem vyhovovalo, pokud by se Debian rozhodl pro neco na bazi OpenRC, nebot potom by snad byla sance to udrzet.

Mit jenom systemd bych nechtel.

[pavlix]

Mám na to naprosto stejný názor. Z jiných důvodů po dlouhé době koketuju s Gentoo, a toto mi přijde jako hezký bonus. Gentoo si drželo vlastní init systém pár let, takže jsou celkem zvyklí.

[little.owl]

po dlouhé době koketuju s Gentoo

.... a ja s opet s Debianem ... Arch se prilis sfedorizoval ...

[pavlix]

Tak já to dělám ve prospěch plynulosti mojí práce, takže nepřímo i ve prospěch Fedory.

[Michal Kubeček]

To by bylo hezké, ale systemd je příklad projektu, se kterým koexistovat principiálně nelze, protože se snaží všechno ostatní buď potlačit nebo asimilovat.

Já jsem třeba uvažoval o tom, že bych se podílel na spravování repozitáře pro OpenSuSE se Sytem V initem, skripty a potřebnými nástroji, až se je Fredericu Crozatovi a spol. podaří vyštípat z oficiální distribuce. Jenže pak jsem viděl, jak se třesou na to, že jakmile se tak stane, zmrší spoustu dalších balíků tak, aby bez systemd nefungovaly (včetně třeba Gnome). Došlo mi, že bychom nakonec museli spravovat paralelní fork distribuce - nebo aspoň její podstatně velkou část.

Totéž se děje i v upstreamu - dnes už je asi každému jasné, že přes všechny sliby se bude systemd tým postupně snažit znefunkčnit udev pro non-systemd uživatele, kdyby nic jiného, tak už jen tím, že budou co nejdéle ignorovat bugy, které se týkají jen těch, kdo systemd nepoužívají (to už se děje).

Linuxový svět býval o svobodě výběru a koexistenci alternativ. Systemd (samozřejmě ne program, ale lidé za ním) se snaží veškeré alternativy zničit a znemožnit jim existenci. To jsem měl na mysli větou "systemd je zlo".

[kavol]

Já jsem třeba uvažoval o tom, že bych se podílel na spravování repozitáře pro OpenSuSE se Sytem V initem ... Došlo mi, že bychom nakonec museli spravovat paralelní fork distribuce - nebo aspoň její podstatně velkou část.

chápu správně, že jste se rozhodl na to vykašlat, jen protože je to příliš velké sousto?

to je velká škoda, resp. principiálně špatné uvažování, neb takto to bude sousto o to větší, že na to bude o člověka míň - a to zas může demotivovat další a další

naopak je třeba přesvědčit co nejvíc lidí, aby se tomu věnovali, a tím to sousto rozmělnit - třeba jen půlhodinky týdně, ale nevzdávat to a jít příkladem ostatním ... mraveniště taky nevznikne tak, že někdo někde vysype kýbl jehličí, nýbrž každý mraveneček tahá jednu jehličku za druhou

ostatně ani ten systemd neprogramuje celý Lennart, naopak, teď do toho buší spousty dalších lidí, kteří kdyby se toho nechytli ("je to moc práce"), tak po systemd neštěkne pes

"systemd je zlo"

tak nějak mě zvrhle těší slyšet od někoho jiného, co říkám už delší dobu

[Michal Kubeček]

chápu správně, že jste se rozhodl na to vykašlat, jen protože je to příliš velké sousto?

Ještě ne definitivně. Uvidím podle toho, kdo další bude ochoten se na tom podílet, a kolik klacků pod nohy stihne systemd tým naházet. Momentálně hlavně doufám, že prozatím zvítězí zdravý rozum a ve 12.3 System V init - s ohledem na plán vydat ji už v březnu - stále ještě bude.

[pavlix]

chápu správně, že jste se rozhodl na to vykašlat, jen protože je to příliš velké sousto?

to je velká škoda, resp. principiálně špatné uvažování, neb takto to bude sousto o to větší, že na to bude o člověka míň - a to zas může demotivovat další a další

Já bych to neviděl ani jako principiálně špatné uvažování, jako spíše vědomé odhadování, na co má chuť, čas a síly.

ostatně ani ten systemd neprogramuje celý Lennart, naopak, teď do toho buší spousty dalších lidí, kteří kdyby se toho nechytli ("je to moc práce"), tak po systemd neštěkne pes

Tady ti výjimečně musím dát za pravdu. Nicméně proto Lennart nepracuje s komunitou, ale projekt nejprve protlačí do Fedory, aby na projektu museli pracovat ti, kteří nechtějí mít příliš rozbitou Fedoru.

[kavol]

Já bych to neviděl ani jako principiálně špatné uvažování, jako spíše vědomé odhadování, na co má chuť, čas a síly.

chuť? - no, asi ano

čas a síly? - ale to je přesně moje pointa ... nějaký čas a síly do toho původně investovat chtěl; to, že to může skončit jako dost velký projekt, přeci není důvodem, aby neinvestoval aspoň to co může (co plánoval), netvrdím, že má investovat více a celý ten velký projekt táhnout sám, naopak, říkám, že je důležité nést si tu svoji jednu jehličku

Nicméně proto Lennart nepracuje s komunitou, ale projekt nejprve protlačí do Fedory, aby na projektu museli pracovat ti, kteří nechtějí mít příliš rozbitou Fedoru.

... což je věc, kterou stále nechápu, proč to ti lidi, místo aby ho s příslušnou blbostí vyhodili (máme FESCO apod.), tak raděj ztrácí svůj drahocenný čas, že to po něm opravují

[pavlix]

Vtim je v tom, že rozhodnutí je na něm. A na nich. A já je naprosto chápu, lennart je prostě vážený člen komunity, který řeší dlouhodobé nedostatky systému. A to je všeobecně považováno za dobrý argument. Na druhou stranu, to než něco udělal lennart, a proto to je špatně, je všeobecně považováno za špatný argument.

Nehledě na to, že umí hezky popisovat své úspěchy a plány lidem, kteří danému tématu moc nerozumí.

[kavol]

Nehledě na to, že umí hezky popisovat své úspěchy a plány lidem, kteří danému tématu moc nerozumí.

hm, to mi tak trošku připomnělo některé části poučného komiksu, na který mě včera kolega upozornil ...

[little.owl]

To je vyborny link, diky.

[pavlix]

Výborný je, ale měli použít Chucka Norrise. Ze začátku to působí až příliš důvěryhodně použitím mnoha známých faktů, dál mi z toho na každé stránce kouká „you have been trolled“.

[kavol]

Ze začátku to působí až příliš důvěryhodně použitím mnoha známých faktů,

a kde ten "počátek" podle tebe končí? - nechci lidi podceňovat, ale řekl bych, že pro většinu lidí končí "známá fakta" asi tak u druhého výskytu jména Tesla, neb ani neví, že byl srbského původu (pokud vůbec ví, že někdo takový existoval)

pokud o něm něco (více) víš, tak "známá fakta" pokračují až do konce - podle jakého klíče tedy rozhoduješ, že to "nepůsobí důvěryhodně" celé?

dál mi z toho na každé stránce kouká „you have been trolled“.

mno, tož to asi nevím, co znamená "you have been trolled", neb já to v tom teda nikde nevidím ...

[pavlix]

a kde ten "počátek" podle tebe končí?

Nemám tušení.

pokud o něm něco (více) víš, tak "známá fakta" pokračují až do konce

Beru na vědomí.

[pavlix]

dnes už je asi každému jasné, že přes všechny sliby se bude systemd tým postupně snažit znefunkčnit udev pro non-systemd uživatele

To jsem tak nějak pochopil od začátku, jiný důvod pro sloučení nevidím. A slibem nezarmoutíš, hlavně když ti to pomůže ten krok obhájit.

budou co nejdéle ignorovat bugy, které se týkají jen těch, kdo systemd nepoužívají (to už se děje).

To mě mrzí.

Linuxový svět býval o svobodě výběru a koexistenci alternativ. Systemd (samozřejmě ne program, ale lidé za ním) se snaží veškeré alternativy zničit a znemožnit jim existenci. To jsem měl na mysli větou "systemd je zlo".

Tady bych tě rád poopravil, aby to nevypadalo, že každé jméno za systemd znamená zlo. Momentálně na něm pracuje pár lidí, jejichž cílem je s tím nějak vyžít. Ono není jednoduché se systemd žít ani když ho použít chceš.

[Michal Vyskočil]

To jsem tak nějak pochopil od začátku, jiný důvod pro sloučení nevidím. A slibem nezarmoutíš, hlavně když ti to pomůže ten krok obhájit.

Nojo, od sloučení systemd a udev z toho mám dost protichůdné pocity a na technické důvody nevěřím. Pokud skutečně chtěli pouze sdílet kód, stačilo to udělat obdobu gnulib a tu si natáhnout jako submoduly do obou gitových stromů.

[pavlix]

Přesně tak.

[Michal Vyskočil]

Došlo mi, že bychom nakonec museli spravovat paralelní fork distribuce - nebo aspoň její podstatně velkou část

A to je právě ta pointa - kolik distribucí reálně používá více než jeden init systém? Takový luxus si může dovolit tak akorát Debian a to jenom proto, že práci na upstartu za něj dělá Canonical. Proto se tolik lidí snaží sysv z openSUSE "vyštípat" - udržovat je paralelně vedle sebe je moc práce a pokud vím, tak počet lidí ochotných udržovat sysv v openSUSE je 2, maximálně 3.

[Michal Kubeček]

Jenže takhle by to vůbec být nemuselo, kdyby se systemd jako projekt choval aspoň trochu slušně ke svému okolí a aktivně se nesnažil koexistenci znemožnit nebo aspoň co nejvíc znepříjemnit.

[Michal Vyskočil]

To pořád neodpovídá na otázku, kolik distribucí reálně podporuje více, než jeden init systém? A pokud takové nejsou, není to tak, že to vlastně nepřináší žádné výhody? Já za sebe vidím pouze nevýhody jako zdvojnásobení počet testovaných scénářů, nutnost opravovat chyby na dvou místech, zdvojnásobení objemu dokumentace a podobně, což je obrovský nárůst objemu práce. Celkove mi to přijde stejně rozumné, jako podporovat na jedné distribuci více formátů balíčků, sice to může udělat pár uživatelům radost, ale za technické komplikace to afaik vůbec nestojí.

[kavol]

To pořád neodpovídá na otázku, kolik distribucí reálně podporuje více, než jeden init systém?

nevim kolik dohromady, ale krom Debianu ještě Gentoo

A pokud takové nejsou, není to tak, že to vlastně nepřináší žádné výhody?

předpoklad nesplněn :-p

kromě toho, otázkou jest, o jakých výhodách se bavíme - prostý uživatel samozřejmě na jednom stroji nepotřebuje dva init systémy najednou, ale pokud potřebuje jeden z nich pro jeho specifika a zároveň potřebuje ono distro, tak je pro něj výhoda, pokud tento jeden podporován je, bez ohledu na to, kolik ostatních je podporováno také ... takže výhodou může být vyšší počet (spokojených) uživatelů

Já za sebe vidím pouze nevýhody jako zdvojnásobení počet testovaných scénářů,

co prosím? ony se všechny testy musí přepsat pro každý initsystém zvlášť?

nutnost opravovat chyby na dvou místech,

a jak vznikne taková dvojjediná chyba, která se objeví zároveň na dvou místech, aniž by se dala orpavit na místě jednom, tam kde vznikla?

zdvojnásobení objemu dokumentace a podobně, což je obrovský nárůst objemu práce.

totéž jako s tím počtem testů - když si čtu, například co mám napsat do my.cnf, tak si to opravdu nepotřebuju číst třikrát, jednou pro Gentoo s OpenRC, podruhé pro RHEL se SysV, a potřetí pro Fedoru se systemd ... jistě, když budu řešit, jak si nahodit nějakou vlastní službu, tak už si potřebuju přečíst různé věci pro různé systémy, ale to je (nebo měla by být a pokud není, tak je něco opravdu špatně) otázka asi tak dvou wiki/man stránek

Celkove mi to přijde stejně rozumné, jako podporovat na jedné distribuci více formátů balíčků, sice to může udělat pár uživatelům radost, ale za technické komplikace to afaik vůbec nestojí.

no a to je právě o té prorostlosti do systému ... kdyby šel systemd vyměnit tak, jako třeba windowmanager, tak bys tady nemusel házet přirovnáním k balíčkovači; nebo to, že distra podporují různé WM (a alternativy u spousty dalšího software), taky považuješ za blbost, a chtěl bys mít jedno distro pro každou možnou kombinaci softwaru?

[Michal Vyskočil]

nevim kolik dohromady, ale krom Debianu ještě Gentoo

citation needed - z jejich webu jsem nepochopil, zda používají sysv, nebo openrc. Systemd a ostatní jsou tam spíše zoufalý pokus, než reaálně použitelná věc.

co prosím? ony se všechny testy musí přepsat pro každý initsystém zvlášť?

Rozhodně minimálně ty, které se týkají spouštění služeb.

nutnost opravovat chyby na dvou místech,

a jak vznikne taková dvojjediná chyba, která se objeví zároveň na dvou místech, aniž by se dala orpavit na místě jednom, tam kde vznikla?

Viz předchozí odstavec - minimálně je třeba zajistit, zda se chyba vyskytuje i v init systému n-1.

totéž jako s tím počtem testů - když si čtu, například co mám napsat do my.cnf, tak si to opravdu nepotřebuju číst třikrát, jednou pro Gentoo s OpenRC, podruhé pro RHEL se SysV, a potřetí pro Fedoru se systemd ... jistě, když budu řešit, jak si nahodit nějakou vlastní službu, tak už si potřebuju přečíst různé věci pro různé systémy, ale to je (nebo měla by být a pokud není, tak je něco opravdu špatně) otázka asi tak dvou wiki/man stránek

Ty si to číst nepotřebuješ, takže to pro distributora není žádná práce navíc sepsat a udržovat (protože já to celou dobu píšu z pohledu distributora) dokumentaci pro více různých init systémů! Ale když padne strom v lese, ve kterém nikdo není, pořád se ozve rána.

no a to je právě o té prorostlosti do systému ... kdyby šel systemd vyměnit tak, jako třeba windowmanager, tak bys tady nemusel házet přirovnáním k balíčkovači; nebo to, že distra podporují různé WM (a alternativy u spousty dalšího software), taky považuješ za blbost, a chtěl bys mít jedno distro pro každou možnou kombinaci softwaru?

Jsou komponenty, které závislosti nemají - jako třeba WM, na kterém nezávisí nic a ty, které jsou do systému prorostlé (kernel, libc, balíčkovací systém, init systém, ...) a podporovat vícero klíčových komponent je pro distributora více práce, než přihodit jeden balíček s teď už dokonalým WM/textovým editorem/programovacím jazykem/přehrávačem muziky/a kdo ví čeho .

[kavol]

nevim kolik dohromady, ale krom Debianu ještě Gentoo

citation needed - z jejich webu jsem nepochopil, zda používají sysv, nebo openrc.

používá OpenRC (viz např.); přičemž by to mělo poskytovat zpětnou kompatibilitu pro SysV skripty

Systemd a ostatní jsou tam spíše zoufalý pokus, než reaálně použitelná věc.

ROFL, takže o Gentoo víš tak málo, že ani nevíš, jaký init systém je tam defaultní, a ani si to na webu neumíš najít, ale zato seš si jistý, že ostatní initsystémy v Gentoo jsou nepoužitelný zoufalý pokus ... no, takže ... mám také říkat [citation needed]?

co prosím? ony se všechny testy musí přepsat pro každý initsystém zvlášť?

Rozhodně minimálně ty, které se týkají spouštění služeb.

a "týkají" myslíš co? - jako že si nějakou službu spouští, anebo že přímo testují to spouštění?

v druhém případě ano, ale to rozhodně neznamená "zdvojnásobení počtu testovaných scénářů" - pokud tedy připustíme, že existují i testy na něco jiného, třeba na funkčnost onoho démona, a ne jenom na jeho startování

v prvém případě záleží, jak prasácky jsou ty testy psané ... my třebas používáme (mimo jiné) BeakerLib, takže když službu startuju přes rlServiceStart, tak na testu nepotřebuju změnit ani písmenko a už vůbec nemusím vymýšlet nějaký duplicitní testovací scénář, o to, aby se služba startovala způsobem kompatibilním s init systémem užitém na daném distru, se mi postará ta knihovna

no a pak máme ještě testy, které se ani systémových služeb netýkají a žádné démony nespouští ... proč ty bych měl kvůli jinému initsystému zdvojovat, to je mi záhadou ... takže bavíme-li se na úrovni distribuce, skoro bych tak řekl, že mluvit o "zdvojnásobení počtu testovaných scénářů" je pěkná blbost ...

nutnost opravovat chyby na dvou místech,

a jak vznikne taková dvojjediná chyba, která se objeví zároveň na dvou místech, aniž by se dala orpavit na místě jednom, tam kde vznikla?

Viz předchozí odstavec - minimálně je třeba zajistit, zda se chyba vyskytuje i v init systému n-1.

pardon, ale předchozí odstavec to nijak nevysvětluje

buď mám chybu v tom konkrétním initsystému, a pak je pro něj specifická a nemá žádný vliv na jiný initsystém, tedy nepotřebuji ji opravovat na dvou místech

anebo mám chybu, která je někde jinde, třebas v démonovi, a tedy projeví se ve více initsystémech - pak ale opravuji toho démona, a tedy jedno místo, a ne že bych tu chybu opravoval v těch inistystémech, tedy na dvou (a více) místech

chybu, která má stejnou příčinu (tedy jde o stejnou chybu), která se projeví na více místech, a musím ji spravovat na všech těch místech, namísto abych odstranil tu příčinu, si dost dobře představit nedovedu - pak totiž asi ta příčina nebyla chyba, když ji nechci opravit

totéž jako s tím počtem testů - když si čtu, například co mám napsat do my.cnf, tak si to opravdu nepotřebuju číst třikrát, jednou pro Gentoo s OpenRC, podruhé pro RHEL se SysV, a potřetí pro Fedoru se systemd ... jistě, když budu řešit, jak si nahodit nějakou vlastní službu, tak už si potřebuju přečíst různé věci pro různé systémy, ale to je (nebo měla by být a pokud není, tak je něco opravdu špatně) otázka asi tak dvou wiki/man stránek

Ty si to číst nepotřebuješ, takže to pro distributora není žádná práce navíc sepsat a udržovat (protože já to celou dobu píšu z pohledu distributora) dokumentaci pro více různých init systémů! Ale když padne strom v lese, ve kterém nikdo není, pořád se ozve rána.

když jsme u toho čtení, obtěžoval ses vůbec přečíst, nač reaguješ?

tak si to tedy vezměme na tom konkrétním příkladě - popis my.cnf

můžeš mi prosím ukázat, jaké budou rozdíly, tedy co jiného ty jako distributor musíš do dokumentace my.cnf napsat na systému se SysV a co jiného na systému se systemd?

no a to je právě o té prorostlosti do systému ... kdyby šel systemd vyměnit tak, jako třeba windowmanager, tak bys tady nemusel házet přirovnáním k balíčkovači; nebo to, že distra podporují různé WM (a alternativy u spousty dalšího software), taky považuješ za blbost, a chtěl bys mít jedno distro pro každou možnou kombinaci softwaru?

Jsou komponenty, které závislosti nemají - jako třeba WM, na kterém nezávisí nic

ROFL, takže si své oblíbené KDE spustím bez kwinu (či jiného WM), když na WM nezávisí nic (a tedy asi můžu všechny WM odinstalovat a bude mi to fungovat i bez nich)?

a ty, které jsou do systému prorostlé (kernel, libc, balíčkovací systém, init systém, ...) a podporovat vícero klíčových komponent je pro distributora více práce, než přihodit jeden balíček s teď už dokonalým WM/textovým editorem/programovacím jazykem/přehrávačem muziky/a kdo ví čeho.

no, a to je právě to co kritizuju ... pochopitelně strom závislostí bude pro různé věci různě široký, nicméně ty závislosti by se měly zastavit na nějakém dobře definovaném rozhraní, a věci na jednu i na druhou stranu od něj by mělo být možné libovolně zaměňovat, a ne že ta závislost bude prorůstat skrz to rozhraní, a konkrétní věc na jedné straně bude požadovat konkrétní věc na straně druhé

takže takový KWin můžu vykopnout a dát místo něj třeba Sawfish, a prostředí mi bude fungovat, protože se to vše drží EWMH, tak by mělo být možné vykopnout systemd a dát místo něj třeba upstart, protože 99% ostatního software v distru je úplně jedno, jak je zařízeno startování systému a služeb; že to tak jednoduše nejde je chyba, kterou žádné přirovnávání k balíčkovači nezamaskuje - jaký formát balíčků distro používá mě zajímá u každého balíčku, jaký používá init systém mě naopak nezajímá u žádného z balíčků, o které se momentálně starám, a totéž platí pro drtivou většinu ostatních; ostatně, ani ten balíčkovač není zadrátován tak pevně, jen formát balíčků (čili to rozhraní, o kterém mluvím), místo rpm lze (na omezenou množinu úloh) použít busybox, třeba

[little.owl]

tak by mělo být možné vykopnout systemd a dát místo něj třeba upstart, protože 99% ostatního software v distru je úplně jedno, jak je zařízeno startování systému a služeb; že to tak jednoduše nejde je chyba,

+1

Tohle je klicova vec. System musi zustat modularni s rozumne specifikovanym interface mezi moduly a tohle neni nejsilnejsi stranka systemd. Tvrdit, ze je to zamer zatim nechci.

[little.owl]

Uzsi integrace se systemem ma v rade pripadu smysl a jak bylo napsano nize, pro vetsinu distribuci nema prakticky vyznam podporovat vice nez jeden init system a ostatne podobna situace je i na strane aplikaci - pocet variaci init systemu, ktere mohou rozumne podpovat je limitovany. Predtim to byla anarchie, takze urcitou unifikaci vitam, ale ne opacny extrem ve smyslu "jen systemd a nic jineho". Nezbyva nez doufat, ze se Debian a Gentoo based Linux distribuce a snad BSD se domluvi na nejake unifikovane alternative - rad bych videl postavene na OpenRC - a to dosti rychle, jinak jim ujede vlak a maji omezene sance to ustat.

[little.owl]

i na strane aplikaci

Aplikaci zde rozumim veci spoustene init systemem ....

[kavol]

no, to jste měli blbý ...

my jsme měli různý jiný initsystémy, a teď to máme (budeme mít) blbý my, protože máme (budeme mít) systemd

[Michal Kubeček]

Jakkoli System V init a skripty na něj navázané nejsou dokonalé, systemd pro mne rozhodně není změna k lepšímu.

[blami]

Krom toho ze to se zpravickou vubec nesouvisi, RedHat secureboot netlaci, muzou bud protestovat a brecet jako ostatni a nebo se proste smirit s tim ze Microsoft proste ovlada OEM vendory a nejak se k tomu postavit. Myslim ze yo-dawg bootloader je to nejlepsi co z toho jde vytezit pokud si ma nadale Fedoru moct nainstalovat i Franta uzivatel.

To, ze RedHat tlaci nejakou systematizaci bootu, ktery doposud zavisel na zcela nahodnem neselhani skriptu volajicich dalsi skripty volajicich dalsi skripty a ladil se asi tak dobre, jako se plastovou vidlickou dela generalka motoru dnesniho automobilu, vidim jen prinos. Nerikam ze systemd je genialni a vselek, ale aspon je to impulz. Fedora je zkratka Features First, takze se to tam protlacilo jak to bylo. Ted budou ostatni bud adoptovat nebo usmernovat. Verim, ze az systemd bude stary jako SysV init bude velice oblibeny. Me osobne se to jako napad libi. Jiste soucasti jako binarni logy nebo httpd streamovani sifrovanych logu jsou dost debilni, ale myslim ze po nejakem case plavby v rozbourenych vodach mezi jednotlivymi distribucemi budou lepsi kousky ponechany, ty horsi zahrabany.

Vzhledem k tomu ze OLS je jen rebrand RHELu + par uzitecnych vychytavek jako KSPLICE nebo UEK (kazdy at si prebere, ma-li to pro nej cenu), i Oracle adoptuje systemd pokud (a ze bude) soucasti RHEL7. Takze ten Vas prispevek vlastne totalne postrada jakoukoliv logiku.

PS: nikdo vam nebrani napsat lepsi systemd a prinutit vendory aby zrusili secureboot

[Michal Vyskočil]

Jiste soucasti jako binarni logy nebo httpd streamovani sifrovanych logu jsou dost debilni, ale myslim ze po nejakem case plavby v rozbourenych vodach mezi jednotlivymi distribucemi budou lepsi kousky ponechany, ty horsi zahrabany.

Hmm, dokud bude u vesla Lennart, tak se afaik s journald nijak moc nepohne.

[pavlix]

Dokud budou lidé protestovat především proti novým konceptům, které mají vedle negativ i spoustu pozitiv, tak má Lennart své jisté. Těžko se někdo bude nějak víc zajímat o argumenty typu logy přece musí být textové a nestrukturované a ve stejném formátu, protože takové byly vždycky.

[little.owl]

Jako by zagzipovany log nebyl binarka ....

[pavlix]

Na druhou stranu, někde tu psal Martin Mareš, že rozlišuje, co jde zpracovat se standardními nástroji a mezi ty se gzip jistě řadí.

[xkucf03]

A co taková ASN.1 v BER kódování, kterou si v pohodě otevřu třeba Wiresharkem a jinými nástroji? Ta se řadí kam?

BTW: trochu mne štve strach některých lidí z binárních formátů/protokolů. Kvůli proprietárním nezdokumentovaným shitům nejmenovaných koprorací snad není potřeba zavrhnout binární formáty jako takové – ne vše binární je špatné. Stačí, když je to standardizované a dobře zdokumentované a může to být k užitku.

[pavlix]

A co taková ASN.1 v BER kódování, kterou si v pohodě otevřu třeba Wiresharkem a jinými nástroji? Ta se řadí kam?

Otevření ve Wiresharku neříká vůbec nic o tom, jak dobře se to bude zpracovávat. Tedy tato informace nemá na zařazení vliv. Pokud bys ale napsal, že nejlepší způsob jak s tím pracovat je opisovat z Wiresharku*, tak by se možná odpověď našla.

BTW: trochu mne štve strach některých lidí z binárních formátů/protokolů.

A přesně proto píšu, že dokud budou lidi argumentovat proti JournalD (pouze) na základě toho, že používá binární logy, tak nemá smysl brát jejich argumenty vůbec vážně. A to si uvědomuje i lennart a proto se těmto lidem jen směje. Naopak mu tento argument dodává pocit výjimečnosti.

* Jen příklad, Wireshark nepoužívám.

[Franta]

Co používáš místo toho? (nějak mi přijde zvláštní, aby se někdo zabýval školením TCP/IP a nepoužíval Wireshark)

[pavlix]

Na školeních pracujeme téměř výhradně s konzolovými nástroji. Kdo pochopí princip a osahá si ho CLI nástroji, tak se v GUItku zorientuje za pár minut.

[Franta]

A pro analýzu jednotlivých protokolů tedy používáš co? Resp. víš o funkční náhradě Wiresharku pro CLI?

[pavlix]

Pokud nepotřebuješ zrovna hledat hesla v ICQ komunikaci, tak lze použít tcpdump.

[Franta]

Lidé používají Wireshark i na užitečnější věci, než hledání hesel k ICQ No nic, asi se tu nic zajímavého nedozvím.

[pavlix]

No nic, asi se tu nic zajímavého nedozvím.

Na co ses ptal, na to odpovídám. Já se tu nejspíš taky nedozvím, co přesně umí Wireshark tak ďábelsky fikaného, kromě toho, že umí stejné informace hezčeji zobrazit.

[Michal Kubeček]

Pro mne je třeba dost zásadní funkce "follow TCP stream", ale i na to IIRC existují textové utilitky. Jinak obecně umí zobrazit víc informací z protokolů aplikační vrstvy. Párkrát jsem dokonce využil i to, že wireshark umí z RTP streamu vytáhnout zvuk ve formátu, který už se dá přehrávat mplayerem a dál konvertovat (AU nebo něco takového).

Bohužel se za to platí tím, že je každou chvíli bezpečnostní chyba v některém z těch analyzátorů, která umožňuje spuštění kódu šikovně zformátovaným paketem. :-(

[pavlix]

Tohle nevypadá zle:

http://src.carnivore.it/streams/about

[Michal Kubeček]

Díky, vyzkouším.

[Michal Vyskočil]

Dokud budou lidé protestovat především proti novým konceptům, které mají vedle negativ i spoustu pozitiv, tak má Lennart své jisté. Těžko se někdo bude nějak víc zajímat o argumenty typu logy přece musí být textové a nestrukturované a ve stejném formátu, protože takové byly vždycky.

Docela by mě zajímalo, kde protestuji proti novým konceptům. Dokonce ani binární logy nejsou takový problémem, když stačí nainstalovat syslog démona a textové jsou zpět. Já spíše polemizuji s tím, zda věci jako HTTP/JSON, nebo QR kódy jsou něco, co by nemohla být volitelná závislost journald.

[David Jaša]

svět kolem systemd má celkově problém s modularitou a volitelnými závislostmi.

[pavlix]

Docela by mě zajímalo, kde protestuji proti novým konceptům

Mě taky. A než se se mnou začneš znovu hádat, tak se prosím podívej, zda jsem něco takového skutečně tvrdil.

Já spíše polemizuji s tím, zda věci jako HTTP/JSON, nebo QR kódy jsou něco, co by nemohla být volitelná závislost journald.

Mohly… :D, to by zatraceně měly. A pochybné kryptografické pokusy by měly být spravovány zcela separátně a nebo zařazeny do adresáře examples a kompilovány pomocí make -C examples.

[Michal Vyskočil]

Mě taky. A než se se mnou začneš znovu hádat, tak se prosím podívej, zda jsem něco takového skutečně tvrdil.

Mea culpa, špatně jsem pochopil tvůj text.

[pavlix]

A dokonce jsi na lehkou provokaci odpověděl vstřícně :). Beru to jako podání ruky.

[pavlix]

Jo sorry, to byl druhý Michal navíc :).

[pavlix]

nadsene tlaci systemd

Za systemd si můžeme sami přespříliš konzervativním přístupem. Pokud by situace v této oblasti nebyla tak špatná, jak byla, po systemd by nikdo neštěkl.

nadsene tlaci a secureboot

Citation needed?

[Pavel Stárek]

Nechápu to nechuť lidí k systemd. Mne se to líbí, funguje to, tak co. Akorát se budu muset naučit psát unity pro ty moje pidi démonky, ale na to je dost času.

[pavlix]

Já jsem to taky nechápal, dokud jsem o něm věděl jen jako uživatel systému. Ale pak člověk zjistí, že je to relativně nové a je potřeba se to naučit. A najednou není z čeho a najednou člověk nemá, koho se zeptat. Nakonec vlastně má. Ale celé je to jedna velká komplikace. Nedostatek dokumentace. Nedostatek srovnání se stávajícími řešeními jako je OpenRC. Podezření, že autory nezajímal stávající software řešící stejné problémy. To je věc, kterou jsem musel řešit i u blbé ročníkové práce na střední škole.

Nic není černobílé.

[kavol]

Podezření, že autory nezajímal stávající software řešící stejné problémy.

"podezření"? - ROFL

[pavlix]

Jo. Taky se bavím nad tím, co jsem sám napsal :).

[Michal Vyskočil]

Nedostatek dokumentace

A to si onehdá někdo na lwn.net ztěžoval, že problémem systemd je naopak tuna manuálových stránek a Lennartových blogů - člověk se všem nezavděčí.

[pavlix]

Nedostatek nemusí být jen o množství, ale i o kvalitě, dostupnosti a pokrytí tématu.

[Michal Vyskočil]

Dobře a co konkrétně z toho je problém systemd? Jsou manuálové stránky nekvalitní? Nebo nedostupné? Která témata nejsou pokryta?

[pavlix]

Nejsem schopný ti se svými znalostmi vyjmenovat všechno, jde spíš o konkrétní jednotlivé zkušenosti. Co podle mě není pokryto je interakce mezi všemi třemi procesy, tedy systemd, dbusem a aplikací.

Víc než dokumentace mi ale vadí debilní návrhy od lidí, kteří jsou na systemd nějak zainteresovaní. Třeba jsem se ptal lennarta na to, co doporučí, když služba potřebuje dva démony, kteří mají startovat vždy spolu a končit zrovnatak (racoon2).

Odpovědí bylo, ať použiju target místo service, což:

1) Vůbec neřeší problém, a ani se ho vlastně netýká.

2) Přináší problémy nové, jakože uživatel dá systemctl start racoon2.service a taková služba neexistuje.

Trochu omylem jsem řekl, že navíc sám používám stále service racoon2 start, to mi bylo řečeno, že dělám blbě, že je to nepodporováno.

Další problém byl s tím D-Busem, což způsobovalo, že service NetworkManager stop zastavilo NetworkManager a ten se do deseti vteřin znovu spustil. Jakou radu jsem dostal tentokrát, na dotaz jak opravit ukončování systémové služby?

Mám prý používat mask místo stop. Krásné řešení:

1) To neřeší problém, protože uživatel chce službu zastavit stejným způsobem jako zastavuje ty ostatní.

2) To způsobí, že služba nejde spustit. Dokud se neodmaskuje.

3) To způsobí, že se služba nemůže spustit při startu. A to už pokročilý uživatel, který si chtěl jen něco zkusit s vypnutým NM, nemusí být vůbec u počítače a může tam být nějaký příbuzný, jehož jediný dojem bude „zase mi nejde internet“.

Nakonec jsem sehnal michicha, což byl první člověk, který mi byl schopný říct, o co jde. To je další problém. Když něco nenajdu v dokumentaci, nebo to podle dokumentace nefunguje (například zastavím službu a ona se sama spustí), a nevěděl bych konkrétně zakým jít, tak zeptat se na irc nebo někde na bugzille je fakt lahůdka.

[little.owl]

Podobna zkusenost. Ja jsem nakonec zacal ctenim zdrojoveho kodu systemd, nebot to byla nejrychlejsi cesta jak se dohrabat k nejake odpovedi na specifickou otazku. Ale celkove dokumentace k system neni zas tak uplne spatna.

[pavlix]

Já pro svoji práci potřebuju číst zdrojové kódy kernelu, libnl a dalších ptákovin. Systemd už by bylo moc.

[Michal Vyskočil]

Víc než dokumentace mi ale vadí debilní návrhy od lidí, kteří jsou na systemd nějak zainteresovaní. Třeba jsem se ptal lennarta na to, co doporučí, když služba potřebuje ...

To je zvláštní, protože systemd pro toto podporu má - mělo by v racoon2-slave.service (nebo jak se to má jmenovat) stačit uvést

PartOf=racoon2.service

a ještě zakázat manuální spouštění a zastavování slave jednotky - RefuseManualStart=, RefuseManualStop= a nakonec ještě RequiredBy=racoon2.service, což zaručí, že racoon2.service spustí i slave jednotku.

Více v systemd.unit

O D-BUS aktivaci toho moc nevím, tam nedokážu tak rychle pomoci. Ale obvykle stačí se ptát na systemd-devel - když už nic, tak Lennart tam na tyhle dotazy neodpovídá, to dělá komunita .

[pavlix]

To je zvláštní, protože systemd pro toto podporu má - mělo by v racoon2-slave.service (nebo jak se to má jmenovat) stačit uvést

Právě. Je to řešitelné, i když jsem se dostal k jinému řešení než pomocí PartOf, jestli teda byl už v tu dobu k dispozici. Ale co navrhl lennart, jsem napsal výše.

A to jsem mu to popisoval podrobněji než zde.

O D-BUS aktivaci toho moc nevím, tam nedokážu tak rychle pomoci. Ale obvykle stačí se ptát na systemd-devel - když už nic, tak Lennart tam na tyhle dotazy neodpovídá, to dělá komunita .

A o tom to je. Musíš se dostat přes nárazníkovou zónu :). Pak už víš, jak a kde se zeptat a tyhle základní problémy jdou řešit. Ale ta D-Bus aktivace mě teď netrápí, protože za ty roky, co se měla zablokovat, se přišlo na to, že je jednodušší ukecat gnomáky, aby se nepokoušeli NM z gnome shellu aktivovat.

[Michal Kubeček]

Kvantita není všechno. Lennart Poettering si sice možná pamatuje, ve kterém konkrétním zápisku daný problém a jeho řešení popsal, ale pro člověka, který hledá odpověď hledá, to může být podobně frustrující jako prohrabávat se hromadou RFC popisujících DNS.

[Michal Vyskočil]

Takže by měl systemd napovídat i příslušnou dokumentaci? Něco jako tohle?

[Michal Kubeček]

Ne. Stačilo by, aby dokumentace byla srozumitelná, tj. dala se (začít) číst i bez toho, aby byl člověk expertem na systemd, byla na jednom místě a rozumně strukturovaná. Z dokumentace k systemd mám podobné pocity jako z již zmíněných specifikací DNS nebo dokumentace k OBS. Ve všech těchto případech mi většinou nezbyde než použít Google a doufat.

[pavlix]

Bývá zvykem dokumentaci dodávat pohromadě a ne v blogových zápiscích.

[Pavel Stárek]

Hehe, to docela kontrastuje s tím, jak Lennart v nějakém svém postu na Google Plus psal, že systemd je skvěle zdokumentovaný Nevím. Jak říkám, teď ho taky vidím pouze z pohledu uživatele, ale napsat si unitu snad nebude takový problém.

[pavlix]

Hehe, to docela kontrastuje s tím, jak Lennart v nějakém svém postu na Google Plus psal, že systemd je skvěle zdokumentovaný

Ano. On je skvěle zdokumentovaný, podle lennartových měřítek. Na druhou stranu, podle mých měřítek není moc věcí, o kterých bych řekl, že jsou skvěle zdokumentované. Problém je, že systemd zasahuje do všeho možného dalšího a přebírá část funkcí různých dalších subsystémů včetně D-Busu.

Nevím. Jak říkám, teď ho taky vidím pouze z pohledu uživatele, ale napsat si unitu snad nebude takový problém.

V projektu NetworkManageru jsme se za několik měsíců nedokázali shodnout, co náš unitfile dělá ve vztahu k D-Busu. Když nám pomůžeš, budeme rádi :), ale je to i o tom několika lidem vysvětlit, jak to funguje, tak aby (a) věřili a (b) souhlasili s výsledným řešením.

[l4m4]

Za systemd si můžeme sami přespříliš konzervativním přístupem. Pokud by situace v této oblasti nebyla tak špatná, jak byla, po systemd by nikdo neštěkl.

+1

[nyan]

Pokud by situace v této oblasti nebyla tak špatná

Ehmmm... jak spatna ? jakoze sme OMG bootovali misto 6 vterin 16 ? fak desne me zajima, v cem byla ta situace tak spatna...

[pavlix]

Přesně tento přístup způsobil problémy se systemd, které dnes máme. Pokud máš pocit, že systemd, openrc a další jsou jen o času bootování, tak se asi není o čem bavit. Pokud máš pocit, že zkrácení bootu ze 16 vteřin na 6 není významné, tak se rovněž nemáme o čem bavit.

Pokud na požadavky po desetiletí odpovídáš „to není potřeba“ a pak přijde chlap, který odpoví „tady to máte“, koho si asi budou víc vážit?

[nyan]

Přesně tento přístup způsobil problémy se systemd, které dnes máme. Pokud máš pocit, že systemd, openrc a další jsou jen o času bootování, tak se asi není o čem bavit.

Ne, nemam ten pocit... a obavam se ze nechapu co myslite tim "tento pristup" ?

Pokud máš pocit, že zkrácení bootu ze 16 vteřin na 6 není významné, tak se rovněž nemáme o čem bavit.

Pro jistou skupinu mozna ano. Pro jinou skupinu - treba do ktere patrim ja, ktery zadava 2 hesla pri bootu (luks + desktop login) - rekl bych ze spravne slovo je zanedbatelne. Plus samozrejme ta skupina ktera sve laptopy jenom uspava... Zkraceni z dvou minut u RHEL 5 na <30 vterin u RHEL 6 - tam bych pouzil slovo vyznamne. A to co predvedl harald - zkraceni z tusim 6 na 4 vteriny.. tam mi napada jen latinske prislovi: qui gives a sh*t ?

Pokud na požadavky po desetiletí odpovídáš „to není potřeba“ a pak přijde chlap, který odpoví „tady to máte“, koho si asi budou víc vážit?

Zda se, ze vsichni si vazi toho chlapa, i kdyz 99.99% z nich se vubec nepodivalo na tu kocku kterou ma v pytli, jenom na tu reklamnou tabuli v jeho ruce.

[pavlix]

Ne, nemam ten pocit... a obavam se ze nechapu co myslite tim "tento pristup" ?

Pro účely přátelské debaty bychom si mohli tykat, ne? Dobře, pokud nepovažuješ situaci za špatnou, chápu, řekejme ji neoptimální.

Pro jistou skupinu mozna ano. Pro jinou skupinu - treba do ktere patrim ja, ktery zadava 2 hesla pri bootu (luks + desktop login) - rekl bych ze spravne slovo je zanedbatelne.

A pro další skupiny, která rovněž zadává dvě hesla při bootu, na to bude mít přesně opačný názor než ty. Protože čekají o to déle, že při každém čekání začnou dělat něco jiného (třeba kafe), tudíž je celkový čas ještě mnohem delší.

Ale to je jen příklad. Podstatné je třeba to, jak to působí na tu skupinu, která rozdává peníze.

Zda se, ze vsichni si vazi toho chlapa, i kdyz 99.99% z nich se vubec nepodivalo na tu kocku kterou ma v pytli, jenom na tu reklamnou tabuli v jeho ruce.

Bohužel.