Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Michal Kubeček

Stran: 1 ... 5 6 [7] 8 9
91
Distribuce / Re:ZFS a Linux
« kdy: 22. 03. 2020, 17:57:38 »
Pokud mám já, jako uživatel (nebo maintainer distribuce) právo ty dvě části kódu (Linux pod GPL a ZFS pod CDDL) spojit v jeden funkční celek (a o tomto právu snad nikdo nepochybuje), na reálné situaci nic nezmění ani začlenění kódu do distribuce zdrojových kódů Linuxu. Jediné, co by bylo potřeba, by bylo administrativně oddělit původní ZFS dílo (které je pod CDDL) a kód od něj odvozený (neb ten by dál padal pod licenci CDDL), od vývoje jiných částí jádra tak, aby ty pod CDDL nespadly neúmyslně.
Tak to ale vůbec není. Uživatel si sice může tyhle udělat ledacos, ale rozhodně nemůže výsledek takového sloučení dál šířit jako jedno dílo, protože snad nikdo si nedovolí popírat, že by takové dílo bylo odvozeným dílem. Šíření v podobě "samostatného" modulu je otázka na delší diskusi, ale je dobré si uvědomit, že linuxové jádro je (přes některé prvky převzaté z microkernelů) ve své podstatě monolitické a že jakýkoli modul, který do něj naloadujete, se stává jeho plnohodnotnou součástí; dá se říci, že ten vztah je v mnoha ohledech ještě těsnější než mezi programem a dynamickou knihovnou. No a triky spočívající v tom, že budu jako distribuovat jen zdrojáky a nechám uživatele, ať si to jako přeloží sám (skriptem, který mu poskytnu), to je klasická ukázka toho, co se v lidové češtině označuje výrazem "ochcat předpis". Tedy počínání, jehož cílem je najít obezličku, která mi umožní porušit smysl předpisu, ale udělat to tak, abych mohl tvrdit, že jsem ho vlastně formálně dodržel.

Citace
Do jisté míry chápu snahu Linuxu zachovat si čistotu a mít všechny části kódu pod GPL.
Obávám se, že vaše neustálé opakování těchto tvrzení ukazuje, že nechápete jednak GPL, jednak vývojový model Linuxu. Linux jako celek má licenci GPL2 a kterákoli jeho část musí být licencovaná buď GPL2 nebo kombinací licencí z nichž jedna je GPL2. Tak je prostě ta  licence napsaná. Druhá věc, na kterou už vás mnozí opakovaně upozornili, je, že přelicencování Linuxu, které byste tak rád viděl, není reálně proveditelné ani v případě, že by k tomu byla většinová vůle. Buď by s tím totiž museli souhlasit všichni, kdo někdy přispěli kouskem kódu pod GPL2 - a jednak jsou lidé, kteří by zaručeně nesouhlasili, jednak je spousta autorů, kteří jsou dávno "nezvěstní". Nebo by bylo potřeba všechno, k čemu souhlas není, buď vyhodit nebo napsat znovu - a vzhledem k rozsahu je i tato možnost čistě teoretická. Mnozí to považují za výhodu, protože je to pojistka proti změně na licenci, se kterou by nesouhlasili (což je pro někoho třeba i GPL3); řada vývojářů také z tohoto důvodu zásadně nepřispívá do projektů, které požadují nějakou formu copyright assignment (CLA) - třeba já jsem se tomu zatím úspěšně vyhýbal.

Citace
Není však spravedlivé říkat, že za to může Oracle. Obě strany to mohou vyřešit naprosto stejnou měrou.
Jak jsem vysvětli výše (a už několikrát v minulosti), přelicencování Linuxu je možné jen v čistě teoretické rovině, praktická proveditelnost by byla víceméně nulová, i kdyby zájem byl. Oracle je v úplně jiné situaci, protože jako firma je to jedna entita, která drží veškerá potřebná práva. V případě Linuxu je nemá ani Linus Torvalds, ani Linux Foundation, ani žádná jiná fyzická nebo právnická osoba, jsou rozložena mezi (přinejmenším) tisíce různých lidí, z nichž mnohé by bylo obtížné i jen identifikovat (podívejte se, u kolik řádků současných zdrojáků vám git blame  ukáže ^1da177e4c3f4), natož dohledat (podívejte se, jak často se vyhazují položky z MAINTAINERS, protože adresa bouncuje, dotyčný není aktivní a novou adresu nikdo nezná, u řadových přispěvatelů je to ještě častější). A tohle všechno platilo dávno před tím, než Sun zveřejnil zdrojáky ZFS pod CDDL.
[/quote]

92
Distribuce / Re:ZFS a Linux
« kdy: 22. 03. 2020, 01:47:23 »
Jestli někdo pro to může něco udělat, tak je to Linux. Připustit, že vybraná část jádra nebude GPL, ale ještě svobodnější CDDL.
I když pominu, že to těžko může udělat "Linux" (což je operační systém), především to neumožňují ty licence.

Citace
Co vadí maintainerům Linuxu je právě ta přílišná volnost. ... Podle mě by to ničemu neublížilo, jediný rozdíl by byl, že by ZFS mohl někdo další z Linuxu vykuchat a šířit bez zdrojových kódů, jen jako binární součást.
Dlouhodobě se snažíte vyvolat tento dojem, ale kdybyste se obtěžoval podívat, zjistil byste, že ve zdrojácích jádra je spousta souborů a dokonce i celých driverů, které mají duální licencování GPL2 např. s BSD nebo MIT - a když jejich autorům nevadilo, že je někdo může (vašimi slovy) "vykuchat a šířit bez zdrojových kódů", tak to prostě problém není. Koneckonců je to tak často právě proto, že tentýž kód je (případně s úpravami) používán i jinde. Ten skutečný problém, který se stále snažíte popírat, je, že CDDL takové duální licencování neumožňuje. Takže jediný, kdo s tou situací může něco udělat, je Oracle.

93
Distribuce / Re:ZFS a Linux
« kdy: 21. 03. 2020, 12:03:57 »
Pokud vim tak potom co Oracle prevzal Sun tak se rozdelil i vyvoj ZFS na 2 vetve......proto ZFS od Oraclu neni kompatibilni s dnesni ZFS od *BSD komunity.
Navic kdyz se podivame na %-uelni slozeni aktualniho kodu, tak uz je z nej drtiva vetsina napsana jako opensource projekt cili pod BSD licenci.....
Pokud to celé nejde šířit pod GPL2 - a to nejde - tak to pro účely použití v Linuxu nic neřeší.

Citace
Je nekolik firem ktere defacto sousedi s Oraclem a bez problemu prodavaj HW incl. ZFS i jako enterprise reseni- viz.napr https://www.ixsystems.com/
A běží jim na tom Linux? Co jsem hledal, vypadá to, že spíš nějaké varianty BSD, což je z licenčního hlediska úplně jiná situace.

Realita je prostě taková, že Sun zvolil licenci, která vylučuje začlenění do linuxového jádra (a s odstupem času už je jedno, jestli to byl záměr nebo jen vedlejší efekt), a ani Sun ani Oracle od té doby nedali ani v nejmenším najevo, že by tu situaci chtěli nějak vyřešit, přestože si jí museli a musejí být vědomi. Takže jediný logický závěr je, že Oracle ZFS v Linuxu nechce. Je to jejich právo, já to tak beru a vybírám si z filesystémů, které v Linuxu podporované jsou. Pokud je někdo přesvědčen, že je pro něj ZFS tak nepostradatelný, že mu to za ty problémy stojí, je to jeho boj.

94
Distribuce / Re:ZFS a Linux
« kdy: 18. 03. 2020, 12:17:10 »
Je to slepá ulička. Sun zveřejnil implementaci ZFS pod licencí, která je nekompatibilní s linuxovým jádrem a ani Oracle (který mezitím Sun koupil a má potřebná práva) ani v nejmenším nenaznačil, že by se chystal svůj postoj změnit. Dokud se to nezmění, bude ZFS na Linuxu záležitost projektů balancujících na hraně právní nejistoty a hlavně bez šance na začlenění do upstreamu.

ZFS má sice nepříliš početný, ale o to hlasitější fanclub hlásající, jak je ZFS dokonalý a Linux bez něj nemá smysl, ale realita je taková, že přes některé zajímavé featury to není zase takový zázrak, aby to stálo za licenční problémy.

95
Motto: když držíte v ruce kladivo, každý problém vypadá jako hřebík.

Ad 1:
Kód: [Vybrat]
for f in *; do echo "${f/najdi/nahrad}"; done

Ad 2:
Kód: [Vybrat]
date +%Y

Ad 3: Prostě to rozepište na jednotlivé transformace, stejně to tak bude mnohem čitelnější a přehlednější.

96
Sítě / Re:rozdeleni switche
« kdy: 12. 01. 2020, 00:57:07 »
U levnějších "domácích" switchů tomu říkají "port based VLAN"; sice to má v názvu "VLAN", ale s 802.1Q to nemá nic společného, prostě jen jednotlivým skupinám portů přiřadíte "VLAN" a porty pak komunikují jen v rámci skupin. Totéž ale nakonfigurujete i s normální VLAN konfigurací, jak už bylo řečeno: každému portu přiřadíte jen jednu VLAN jako untagged+PVID, tím pádem nikde žádné tagy nebudou a vy budete mít jednotlivé skupiny navzájem oddělené.

Jediný problém by asi byl, kdybyste potřeboval v rámci toho "podswitche" používat 802.1Q. K tomu pak slouží "nested VLAN" (802.1ad).

97
Hardware / Re:Hyperthreading na desktopu?
« kdy: 03. 12. 2019, 13:58:19 »
Předpokládám, že popsaná skupina zranitelností L1TF a MDS, která souvisí s HT, se netýká pouze procesorů Intel, jako některé/většina ze zranitelností za poslední cca 2.5 roku, ale týká se všech CPU s HT. Je tento předpoklad správný?
Není. Hyperthreading podporují např. i procesory Ryzen a Epyc, které těmito zranitelnostmi netrpí.

98
Sítě / Re:IPtables blokace komunikace mezi eth0 a eth4
« kdy: 18. 09. 2019, 22:05:54 »
Už to bylo vysvětleno, ale zkusím to napsat trochu jednodušeji. O tom, jestli bude příchozí paket filtrován řetězcem INPUT nebo FORWARD, rozhduje jen to, jestli je to paket "pro mne" (INPUT) nebo "pro někoho jiného" (FORWARD). Když si odmyslíme různé neobvyklé konfigurace, tak obvykle jde jen o to, jestli je cílová adresa "moje" nebo ne, přičemž není vůbec důležité, jestli ji mám nastavenou právě na tom rozhraní, kam paket přišel, nebo na kterémkoli jiném (viz též termín "weak host model").

Lokálně generovaný paket (v tomto případě echo reply) pak půjde za normálních okolností přes OUTPUT, ne FORWARD.

99
Vývoj / Re:Použití příkazu GOTO v jazyku C
« kdy: 21. 08. 2019, 05:41:08 »
Samozřejmě, můžete si pamatovat , že "když funkce X selže, musím někde zavolat a_finit, protože ona to neudělala"; podle mě pak ale kód přestává být srozumitelný.
Hlavně rychle přestane být udržovatelný. Bude potřeba pořád hlídat, jestli na to někdo nezapomněl. Když se bude volat na deseti místech, tak aby si na to člověk radši napsal wrapper - ale když tu funkci budu pokaždé volat přes (stejný) wrapper, tím spíš vynikne, že cleanup měl být rovnou v té funkci. A ani z logického hlediska to nedává smysl, pokud funkce něco alokuje, má to po návratu zůstat alokované jen v případě, že volající potřebuje, aby to alokované zůstalo.

Navíc jsme se tu bavili o případech, kdy těch inicializačních kroků je víc, selhat může kterýkoli z nich a volající obecně neví, který to byl a co je potřeba uklidit. Nemluvě o tom, že v praxi to často nebude jen prosté a_init() ... a_finit(), protože se úklidové funkci bude předávat pointer na to, co se má uklidit, který volající ani nebude mít k dispozici.

100
Vývoj / Re:Použití příkazu GOTO v jazyku C
« kdy: 20. 08. 2019, 22:12:05 »
musíte testovat návratovou hodnotu funkce při každém volání. Goto zjednodušuje použití těch funkcí, kde může nastat chybový stav. Může vyskočit i z více úrovní volání.
Ano jistě, ale šlo mi spíš o to přímé return err, místo Goto Exit,
To si můžete dovolit tam, kde nepotřebujete před návratem provést nějaký úklid. Samozřejmě jde použít i něco jako
Kód: [Vybrat]
        ret = init_foo();
        if (ret < 0) {
                /* cleanup */
                return ret;
        }
ale v případech, o kterých se tu bavíme, bude toho úklidu přibývat, jak bude přibývat provedených inicializací.
Tam je problém, že v případě, kdy selže třeba b_init musí mít vyšší vrstva kódu na paměti, že by měla zavolat a_finit.
Problém nevidím, může to ta vrstva poznat? O to v tom příkladu snad nešlo... Určitě by se to pak napsalo úplně jinak, ne?
Zkuste se podívat třeba sem na funkci inet6_init() a rozmyslete si, jak by ten kód vypadal, kdybyste se chtěl za každou cenu vyhnout použití goto.

101
Vývoj / Re:Cvičení Bitových operátorů z knihy o jazyku C
« kdy: 05. 08. 2019, 13:18:47 »
To první je určitě špatně, protože takhle nikdy nemůžete vrátit nulu tam, kde původní x mělo jedničku, musel byste použít něco podobného jako máte v tom invertuj(). Ty masky jsou IMHO taky špatně, spíš by to mělo být
Kód: [Vybrat]
~(~(unsigned int)0 << n) << p
V invertuj() bude jednodušší použít x ^ mask, což vám invertuje právě ty bity, které jsou v masce a ponechá zbytek.

Pokud víte, kolik má typ bitů (a máte ošetřené nesmyslné vstupy), pak si můžete ušetřit jednu negaci a použít
Kód: [Vybrat]
(~(unsigned)0 >> BITS_PER_INT - n) << p
Často se také používá trik s (1U << n) - 1, ale pak je potřeba ošetřit nebo vyloučit n rovné přímo bitové délce typu.

102
Sítě / Re:Instalace LAN v novostavbě
« kdy: 31. 07. 2019, 07:23:28 »
Keystone znamená, že na na konec drátového kabelu se jednotlivě krimpují RJ45 zásuvkové "kostičky", které se pak jednotlivě vkládají do patch panelů a pozedních zásuvek.Takže koupíte jenom tolik kostiček, kolik zrovna potřebujete, a snáz se s nimi jednotlivě pracuje, než s celým copánkem kabelů - zejména u víceportového patch-panelu.
Pro úplnost: existují dva typy keystone zásuvek. Jeden se nařízne přímo na kabel (existují i v "beznástrojové" variantě) a na druhé straně má zásuvku, druhý je vlastně "spojka" se zásuvkou na obou stranách, do které se i vzadu zapojí klasický RJ-45 konektor. To se může hodit např. v situaci, kdy chci na patch panel vyvést nějaké zařízení, které je ve stejném racku, pak na propojení stačí hotový krátký patch kabel.

Keystone varianta patch panelu je sice dražší (ne samotný patch panel, ale je potřeba samostatně dokoupit zásuvky), ale když jsem si představil, co by obnášelo přidat další kabel do už zapojeného patch panelu, byla to jasná volba. Navíc se do keystone patch panelu dají sehnat i jiné typy zásuvek než jen RJ-45, např. USB nebo HDMI.

103
Sítě / Re:Tečka za doménou udělá hokej?
« kdy: 24. 06. 2019, 07:57:00 »
Kompletní jméno včetně tečky na konci by se mělo vždy interpretovat jako přesně to jméno, které jste napsal. Bez té koncové tečky může resolver v závislosti na konfiguraci přidat search doménu, viz resolv.conf(5), parametry domain, search a ndots.

104
Hardware / Re:Intel nebo AMD?
« kdy: 11. 06. 2019, 07:00:23 »
Je ale pravda, ze na dmaci pouziti tyto patche nejsou potreba.
Jen pokud tím domácím použitím myslíte počítač, ze kterého nepřistupujete na web.

105
Sítě / Re:Rozvaděč pro domácí síť a učení
« kdy: 30. 04. 2019, 07:31:03 »
Pod to je jedno, ale pokud byste se vrátil k variantě připevnění na zeď, pak bych doporučil spíš nějaký case s odnímatelnými bočnicemi.

Stran: 1 ... 5 6 [7] 8 9