Portál AbcLinuxu, 8. května 2025 21:42
Jistě jste slyšel o jakési historce, kdy jeden osvícený vývojář vymazal nějaký bezvýznamný a zbytečný řádek v OpenSSL.
Nic takového jsem neslyšel. Z dostupných informací jsem vyrozuměl, že nějaká diskuze proběhla, ale problém byl způsoben zakomentováním něčeho úplně jiného, než co bylo diskutováno. Vzhledem k tomu, že se jedná o obejití klíčové funkce, považuji zvěsti o schválení ze strany OpenSSL za pohádky.
Nemluvě o tom, že do upstremu se to nedostalo.
Nechce se mi to ted hledat, ale opravdu ten debianni vyvojar posilal mail do openssl listu, kde mu to odsouhlasili (ten mail jsem cetl).
Já to četl tak, že to posílal do openssl konference, ale do jiné než měl … takže tam proti tomu nikdo neprotestoval, tudíž si myslel, že je všechno v pořádku.
S tou trapnou vymluvou, ze to byla spatna konference, prisli lide z OpenSSL az potom - a to i kdyz je ze lzi usvedcoval jejich vlastni web, kde byly konference popsane.
Ale premohl jsem tedy svou lenost a nasel ten thread - http://marc.info/?t=114651088900003&r=1&w=2 (pozor, prvni zprava je na konci). Snad to celou situaci trochu ozrejmi.
Pokud jsou mé informace správné, tak chtěl zakomentovat cast kodu a tak ho procistit. Bohuzel pak doslo k tomu, ze toho zakomentoval vice(mozna omylem) nez bylo "dohodnuto"..
To je moc zábavné od někoho, kdo sám link nepřidal .
IMHO nejvice flamuji ti, co na Debianu udelali nejmene.
Tim se netreba vzrusovat.
Podstatne ovsem je, ze i tak ma Debian _velmi_ silnou vyvojarskou komunitu. Mnozstvi baliku samo o sobe nic neni.
Podivej se, kolik jde z Debianu patchu do upstreamu. Ano, komercni firmy je prekonavaji, ale Debian je prevazne zkupina nadsencu. A presto prispivaji. A to tak, ze velmi.
Uspech Ubuntu je uspech Debianu. Debian by bez Ubuntu v klidu prezil. Ale obracene to uz neplati.
Ubuntu neni jednorazovy fork. Syncuje se s Debianeem v podstate permanentne. Diky tomu nepotrebuje tolik lidi. Proste kus prave prevezme z Debianu.
Aby bylo jasno, tohle neni kritika Ubuntu. Neni na tom nic spatne. Taky nepopiram, ze Ubuntu zase prispiva do Debianu.
Ona konkurence na tom taky neni zrovna ruzove (nic ve zlem, ale ktere distro nema problemy?).
A dlouhy vyvojovy cyklus u Debianu je v klidu. Ktera jina distribuce vychazi az jsou opraveny vsechny bugy krome Severity - Enhancement?
Vztahem Ubuntu a Debianu si nejsem, příliš jist. Ubuntu totiž čerpá z upstreamu rychleji než Debian. Podlemě ho potřebovli hlavně na rozjezd.
Neni pravda.
Koukni treba do /usr/share/doc. Najdes tam hodne souboru s "Debian" v nazvu.
Podle ceho urcujes, ze Ubuntu cerpa z upstreamu rychleji nez Debian? V Debianu je docela dost patchu z Ubuntu a vyvojove verze Ubuntu zacinaji syncem s Debianu.
Debian to v posledních letech nemá lehké. Podle mnohých totiž Ubuntu ukázalo, jak by měl přístup vývojářů Debianu vypadat, kdyby to dělali pořádně.Ne a ne a ne a ne! Když vývojáři Debianu z Ubuntu něco převezmou, většinou je to nějaká naprosto zbytečná hovadina. Teď naposledy převzali to, že se místo standardního jaderného fontu na konzoli zobrazuje nějaký jiný - místo hezkého hladkého písma tak člověk po aktualizaci má na obrazovce hnusný velký kostičky a musí hledat, jak by se jich zase zbavil. Pěkně děkuju. Jen ať se Debian hezky drží svého původního přístupu, že v systému nemá být to, o co si uživatel neřekl. Instalovat hovadiny, aby o sobě mohli říct, že jsou taky user friendly, je pitomost. (Už se těším, až ve výchozí instalaci Debianu bude taky pulseaudio. Fuj.
A co vlastního vyvíjí Debian?
Když vývojáři Debianu přejímají z ubuntu naprosté hovadiny, a podle #2 je naopak Ubuntu kriticky závislé na Debianu, zajímalo by mě, jak to je vlastně s tím Debianem? Ten je taky kriticky závislý na někom? Nebo snad sám hodně vyvíjí, zejména takový SW, který pak míří do upstreamu?
Kdyz jsem videl tohle naposledy nejakeho vyvojare Debianu resit, jeden ze zaveru byl, ze (vyjma zakladnich nastroju pro samotny Debian) vyvojari Debianu se Debianem pri vyvoji vlastnich aplikaci nijak neohaneji (tj. zadne "Jsem vyvojar Debianu a vytvoril jsem tenhle program."). Jinak Debian je distribuce, ne vyvojarska farma.
Ale jako priklad me napadaji treba Gammu Michala Cihare nebo Awesome Juliena Danjou (ktery vznikl, pokud me pamet neklame, castecne jako reakce na problemy s io... iceparticle :) ).
Pak bude asi zcestne argumentovat tim, ze Ubuntu je zavisle na Debianu. Kdyz Debian ze dne na den zmizi, Ubuntu asi jenom zacne brat jinde, kdyz ten kod stejne puvodem nepochazi z Debianu. V tom bych nevidel problem.
Co myslis tim kodem?
Ze Debian nedela kvanta vlstnich programu? Nebo treba bugfixy v Debianu?
Ubuntu se bez Debianu proste neobejde. Zadna jina silna distribuce s deb balicky se nedela. Nevim jak by byl narocny prechod na jiny druh balicku.
Nebo si myslis, ze Shuttleworth bude financovat stale vice lidi?
A co kdyz mu Ubuntu nezacne vydelavat? Co kdyz to proste z nejakeho duvodu zabali? Co potom?
Debian stoji na komunite a tak nestoji a pada s jednotlivcem. Ubuntu muze umrit v podstate ze dne na den.
Nemyslím si. Vzhledem k počtu klonů Ubuntu můžou prostě dělt toéž co dotěď jen s komunitou. Výsledek sice nebude v takovém stavu jako dnes, ale proč ne.
Nemyslím si že bez Debianu by si ty DEB balíky neuměli bastlit sami. A nakonec vždycky můžou přejít na RPM, což se mimochodem někde na nějakém Ubuntu brainstormingu volně dikutuje (povětšinou s nesouhlasem).
Nemyslím si. Vzhledem k počtu klonů Ubuntu můžou prostě dělt toéž co dotěď jen s komunitou. Výsledek sice nebude v takovém stavu jako dnes, ale proč ne.
Nemyslis si co? Ze pokud by Mark prestal platit vyvojare, ze by neslo Ubuntu do kopru? Mozna ne. Ale slo by s kvalitou dolu a tudiz i s pouzivanosti a pokud by casem nezkoncilo uplne, tak by jenom skomiralo nekde dole.
Nemyslím si že bez Debianu by si ty DEB balíky neuměli bastlit sami. A nakonec vždycky můžou přejít na RPM, což se mimochodem někde na nějakém Ubuntu brainstormingu volně dikutuje (povětšinou s nesouhlasem).
Ale tu vubec nejde o deb/rpm. Ty jsou v podstate obdobne. Tu jde o to, ze vyvojove Ubuntu zacina syncem z Debianu Sid a pak pridavaji vlastni patche (jestli jsou patche do Debianu a do upstreamu a v jakem mnozstvi ale nevim). Pokud by najednou museli vsechno delat sami, tak jsou v kelu protoze je jich malo.
Podivej se na repozitare "main" a "universe". Main je podporovan vyvojari Cannonical, Universe je nepodporovany komunitou spravovany sync z Debianu.
Aha, asi se rozchazime v nazoru na to, co je distribuce.
Distribuce ma za ukol sebrat hromadu existujicich programu ("upstream") a vytvorit neco, kde se ty programy daji pouzivat. Tj. primarnim cilem distribuce neni tvorit nove programy, ale starat se o "pouzitelnost" tech existujicich.
Jinak receno, distribuce se stara o to, abych nemusel resit, kterou verzi knihovny potrebuju ke ktere aplikaci, abych nemel konfiguraky rozhazene vsude mozne po disku, aby se mi programy netloukly a neprepisovaly si soubory atp.
pak z definice vyplývá, že distribuce nemůže být závislá na jiné distribuci protože ta není upstreamem.
Jenze Ubuntu bere uz hotove _baliky_ z Debianu, ne zdrojaky programu! To je rozdil mezi "upstreamem" a "upstream distribuci".
Nikoliv. Z oné definice plyne závislost na upstreamu, ale neplyne nic ohledně závislosti (nebo nezávislosti) na Debianu zrovna tak jako na nadúrodě banánů v Ekvádoru.
Jenže Ubuntu je závislé na Debianu. Proč jinak by Cannonical vyzýval Debian, by více spolupracovaly? Co totiž neudělají v Debianu, musejí udělat v Ubuntu.
No a já se tady někde ptal, co udělali v tom Debianu? Zatím se mi dostalo odpovědi typu DOC.
Co dělají? Dělají distribuci: balí software, testují jej, opravují chyby, zpětně portují opravy bezpečnostních chyb (a to dost dlouho, i když upstream je už úplně někde jinde), připravují konfiguraci, systémové programy začleňují do startovacích a konfiguračních schémat distribuce, řeší přechody mezi verzemi nebo alternativními implementacemi virtuálních (meta) balíků. A to vše na mnoha architekturách, v mnoha jazycích rozhraní. A samozřejmě komunikují s uživateli a s upstreamem, protože ani distribuce neexistuje ve vzduchoprázdnu.
A jen tak bokem ještě vyvíjejí distribuci samotnou (balíčkovací systém, instalátor, startovací skripty), udržují pro to vývojové nástroje (bugzilla, mailing listy, referenční testovací stoje, webové rozhraní k repozitářům atd.
To je vám málo? Zkoušel jste někdy spravovat balíky nějaké distribuce? To vůbec není configure && make && make install
.
Kdyz Debian ze dne na den zmizi, Ubuntu asi jenom zacne brat jinde, kdyz ten kod stejne puvodem nepochazi z Debianu.A kde? Vývojáři Debianu nedělají jenom to, že odněkud "berou". Poměrně hodně práce spočívá ve vytvoření balíčku ze zdrojového kódu, popřípadě úpravy specifické pro Debian (týkající se například umístění souborů). Za každým balíčkem stojí někdo, kdo vzal kód a ten balíček vyrobil. A čím větší projekt, tím víc práce. Jestliže Debian ze dne na den zmizí, tedy ze dne na den tito lidé přestanou dělat balíčky, odkud bude Ubuntu brát? Připomínám, že lidé, co dělali balíčky, ze dne na den zmizeli, takže Ubuntu může brát jenom zdrojové kódy z upstreamu, ale nemá k nim lidi, co by vyrobili balíčky, na kterých Ubuntu (i Debian) stojí a padá. Takže ne, začít brát jinde pro Ubuntu opravdu není tak snadné, jak by se na první pohled zdálo.
A co vlastního vyvíjí Debian?
Podle mnohých totiž Ubuntu ukázalo, jak by měl přístup vývojářů Debianu vypadat, kdyby to dělali pořádně.Obvykle se podobným hnusným zkratkám vyhýbám nicméně tady nelze jinak—ROFL! Nebyl by odkaz na některého z chytráků z řád "mnohých"? Chtěl bych se zasmát, díky.
Podle mě je problém v tom, že Debian používáš tak krátkou chvíli. Já ho používám výhradně už několik let. Teď musím na některých servrech pracovat se SUSE. A mám z toho stejné pocity jako ty z Debianu. Jak to člověk nemá zažité tak mu všechno přijde takové neohrabané (co to je třeba za bordel nějaký adresář /srv, jak se dají v Yastu nějak inteligentně vyhledávat balíky, atp.). Chce si to prostě zvyknout, a pak teprv hodnotit.
BTW: apt/aptitude. Prostě používám aptitude (ať už z řádky, nebo ncurses rozhraní), a nějaké spory jsou mi z hlediska uživatele ukradené. Prostě to funguje.
Jako uživateli mi spory nemohou být ukradené, protože chybějící koncepce toho,jak mám spravovat SW se mě dotýká. Můžu třeba spravovat SW pomocí Aptitude, ale jakmile použiju v GUI Synaptic, Atptitude již nebude vědět co jsem s čím nainstaloval a přijdu o možnost automatické odinstalace, což výhoda Aptitude. Takováto anarchie dvou poloficiáních defaultních nástrojů k ničemu nepřispívá.
/srv je součást standardu FHS, bordel je to, když ho někdo nemá.
Zatím mám bohužel z reakcí v diskuzi pocit, že všichni distributoři jsou idioti, protože jenom Debianí přístup je ten správný.
Atptitude již nebude vědět co jsem s čím nainstaloval a přijdu o možnost automatické odinstalace, což výhoda Aptitude.Zkus si nejdřív nastudovat informace, pak něco piš. Automatickou odinstalaci umí i apt-get
Zkus si nejdřív nastudovat, kde to vlastně diskutuješ. Tato funkcionalita Aptu je mnou zmiňována už v samotném blogpostu.
Smysl tohoto argumentu nechápu. Budu si jako vést evidenci, co jsem nainstaloval pomocí Aptitude, a co pomocí apt-get, abych pak věděl co mám čím odinstalovat?
Zkus si nejdřív nastudovat, kde to vlastně diskutuješ. Tato funkcionalita Aptu je mnou zmiňována už v samotném blogpostu.A přestože tuto funkcionalitu zmiňuješ v blogpostu, tak o Debianu jako takovém nevíš nic, což dokazuje:
Budu si jako vést evidenci, co jsem nainstaloval pomocí Aptitude, a co pomocí apt-get, abych pak věděl co mám čím odinstalovat?Kdyby sis totiž před kritizováním o fungování Debianu něco nastudoval, tak bys věděl, že nic takového dělat nemusíš. Otestujeme na programu původně nainstalovaném pomocí apt-get:
# apt-get autoremove openarena Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libspeexdsp1 openarena-data The following packages will be REMOVED: libspeexdsp1 openarena openarena-dataaptitude nepoužívám, ale nainstalované je, takže zkusíme, co bude dělat:
# aptitude remove openarena Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Writing extended state information... Done The following packages will be REMOVED: libspeexdsp1{u} openarena openarena-data{u}Přestože jsem si nevedl žádnou evidenci, mohu na odinstalovávání použít aptitude i apt-get a výsledek bude stejný. Za domácí úkol si zjisti, proč to tak je.
šmankote to je jak u blbejch. Já přece kritizuji že jsou dva. A nikoli to jak fungují! Já přece kritizuji, že Debian projekt definuje Aptitude jako replacement pro APT, a následně místo aby APT nechal odejít do důchodu, doplňuje mu funkcionalitu a cpe ho do wiki stránek. To je chaos bez koncepce. Ale koukám, že s Debianisty se asi diskutovat nedá
Já přece kritizuji že jsou dva.A v čem je problém? Vadí ti nějak existence apt-getu v tom, abys mohl používat replacement pro APT? A vzhledem k tomu, že funkcionalita je podobná, tak tě nemusí bolet, že ve wiki je apt-get. Pokud ho nechceš použít, použiješ aptitude. (A pokud nevíš jak, použij apt-get, protože viz výše)
Vadí mi, že jako nově příchozí mám problém se zorientovat, co Debian vlastně chce a kam jde (viz package management). Ovšem jak to tak sleduji, "Debian" je asi diagnóza.
Nesmysl.
Ja s Debianem zacinal a byl uplne v klidu. Ze ocekavas neco jineho neni chyba Debianu. Je to velmi oblibena distribuce a fakt, ze tobe nesedi te jeste neopravnuje k urazeni tech, kteri jej maji radi.
Jestli se ti nelibi, tak pouzivej neco jineho a mas to.
Nechapu proc delas takove ofrky kvuli tomu, ze mas dva instalatory balicku. Tak si jeden vyber a je to. Fakt nepochopim, cos chtel timto blogovym zapiskem rici.
Ze je tu apt-get a aptitude a ze ti stoji u hlavy hlapi s bouchackama a nuti te pouzivat oba dva?
/srv je součást standardu FHS, bordel je to, když ho někdo nemá.
Tak jsem se na ten FHS podival. IMHO podle definice /srv a /var ho Debian splnuje. Zalezi na tom co si predstavite pod pojmem "variable data". Mimochodem vzhledem k tomu, ze specifikace rika, ze /srv by melo slouzit pro "site specific data served by system" a tim definice konci, tak je podle ma tak trochu naprd. Protoze takovuhle definici se nedosahne jaksi cile FHS, a to obecnejsich navodu, nebot je uz na kazdem jak si srv rozdeli. Takze index apache pak muze byt v htdocs/ htdocs/default default/htdocs apache www. Proste zkratka kdekoliv, a opet podle toho jak se rozhodnou autori distribuce.
Ano.Zatím mám bohužel z reakcí v diskuzi pocit, že všichni distributoři jsou idioti, protože jenom Debianí přístup je ten správný.
>>Pán je poněkud zmaten, ne?
A čí je to podle vás chyba? Hlavně, že je čistotný vhodný do domácnosti. To jsem fakt potřeboval vědět.
Suddenly the Dungeon collapses!! - You die...A taky že jo! Bylo to to poslední, co jsem viděl, než se začaly sypat hlášky Input/Output error. Pravda, tohle jsem nečekal od Debianu ani já a už je to opraveno.
Nemělo to být spíš: if (navratova_hodnota = 1)?
Protože když je návratová hodnota nulová (==), měl by to být úspěch (tzn. nezobrazovat chybovou hlášku) a pokud se do té proměnné podaří přiřadit (=) nějaká hodnota, vykoná se stejná větev -- ta za ifem a na chybovou hlášku (za else) rovněž nedojde.
(leda že bys nulu považoval za neúspěch a jedničku za úspěch, ale to mi přijde proti konvencím -- návratová hodnota programu)
A opravdu je spravne, aby se v podmince provadelo prirazovani?
Imho by mel hulakat uz kompilator.
Ano. Je. Ale "if" je podminka.
Prirazovat v podmince je nesmysl. Zkus neco takoveho prenest do lidske mluvy? Taky z toho IMHO vznikne blabol.
> Zkus neco takoveho prenest do lidske mluvy?
Jestlize vysledek teto operace, oznacme si ho jako x, je ruzny od nuly, pak vypis x.
Opravdu ten jeden ušetřený řádek stojí za tu nepřehlednost a záhadné chyby?
předpokládám, že hodláte tvrdit, že v Céčku je rovnítko prostě přiřazení a hotovo, jenže mezi vyjadřovací schopností Céčka a lidským přemýšlením je velká bariéra, takže tenhle problém reálně prostě nastáváOd toho překladač (většinou) vyhazuje ten warning - kdo warningy nečte, ten má smůlu. A kdo programuje v C, tak ví, že = je přiřazení a porovnává se dvěma rovnítky za sebou. Jedno a dvě rovnítka od sebe ještě rozeznat jde - komu ne, ať programuje v Javě.
Ja osobne si myslim, ze je lepsi nejdriv priradit a pak testovat, nicmene znam velmi dobre programatory, kteri preferuji prirazeni v podmince.
není to správné a měl by – alespoň varování a nejlépe ohlásit chybu, protože to většinou skutečně chyba je.
viz #61
To je vcelku irelevantni - pokud standard jazyka C rika, ze to je korektni, pak by to melo jiz prelozit kompilatorem jazyka C (i kdyz to muze generovat warning). Takze tohle neni otazka na autory prekladace jazyka C, ale otazka na autory specifikace jazyka C.
Psal jsem sice, že by kompilátor měl vyhodit chybu, ale myslel jsem to tak, že by se měl změnit jak kompilátor, tak standard jazyka*. Nechci, aby kompilátor dělal něco, co odporuje standardu. IMHO tam (ve standardu) nikdy tahle možnost být neměla.
*) i když ten je dodatečně těžké měnit, protože by přestaly fungovat programy, které do teď fungovaly.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.