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 ... 4 5 [6] 7 8 9
76
Škoda že není k dispozici datasheet RTL8125. Pokud byste měli někdo výpis 'ethtool -T' tak se pochlubte.
Jak tak koukám do zdrojáků, realtek phy driver nic neposkytuje a žádný realtek NIC driver neposkytuje nic jiného než ethtool_op_get_ts_info(), takže vrátí SOF_TIMESTAMPING_TX_SOFTWARE | SOF_TIMESTAMPING_RX_SOFTWARE | SOF_TIMESTAMPING_SOFTWARE. Nevím, co umí ten hardware, ale ať umí cokoli, driver to nepodporuje.

77
Takže chceš říct, že je na tom Intel líp?
Snad tě neurazí, že se tu budu delší dobu smát...
Wired rozhodně (wireless, to je poslední dobou smutný příběh). Kdyby nic jiného, tak už tím, že ty drivery primárně vyvíjejí přímo vývojáři z Intelu. U Realteku je to dobrovolník zvenku a dá se mluvit o úspěchu, když se z Realteku podaří vyrazit aspoň nějaké střípky dokumentace. Např. mezi 5.0 a 5.11 bylo 1346 commitů zasahujících do drivers/net/ethernet/intel a 1038 z nich má autora s @intel.com adresou; do drivers/net/ethernet/realtek to bylo 346 commitů a autora s @realtek.com má z nich... 0.

Smát se samozřejmě můžete čemu chcete.

78
Když 2.5 GbE tak snad raději Realteka ne?
Když vidím, jak to poslední dobou vypadá s jejich drivery (např. neustálé tanečky kolem toho, kde ASPM náhodou funguje, kde je rozbité a kde úplně rozbité) a jak Realtek "spolupracuje", tak... raději ne.

79
Mellanox ConnectX ... K tomu zřejmě driver ve vanilce...
U Mellanoxu bych se o linuxové drivery opravdu nebál, ono není dnes moc výrobců síťových zařízení, kteří by byli v Linuxu tak aktivní jako Mellanox.

80
Sítě / Re:Wifi k Ubiquiti EdgeRouter
« kdy: 02. 03. 2021, 10:09:08 »
Na domaci pouziti IMO bohate staci Ubiquiti UniFi UAP-AC-LR.
I ten LR může být přehnaný. Osobně používám v rodinném domku dva AP AC Lite (jeden v přízemí, jeden v patře) a stačí to taky. Teď je dokonce dočasně aktivní jen jeden a s přimhouřením oka stačí i to. Ale samozřejmě záleží na tom, jaké máte zdi, jaké rušení od sousedů a kde všude chcete wifi využívat.

81
Sítě / Re:Jaké VPN? Dokáže mě opravdu skrýt?
« kdy: 25. 02. 2021, 08:51:47 »
...vyhazují z práce a skoro lynčují lidi za to, co napsali před 15 nebo více lety, byť psali věci, které byly v zásadě nevinné a dobře myšlené
Ponechám-li stranou tu kombinaci demagogie a manipulace, nemohu si odpustit otázku, jak konkrétně "VPN" (v tom smyslu, jak ji chápete vy a tazatel) zabrání tomu, aby někdo po 15 letech vyvodil nějaké důsledky z toho, co jste napsal do e-mailu nebo na nějaké webové fórum.

82
Sítě / Re:Jaké VPN? Dokáže mě opravdu skrýt?
« kdy: 25. 02. 2021, 08:31:22 »
Z celého vyznění mám podezření, že:

1) chceš dělat přes VPN něco nekalého, což je nedobře
2) pleteš si VPN a darknet, což je, zejména pro tebe, taky špatně.
Tady je krásně vidět to nešťastné zmatení pojmů. Vy ve své odpovědi chápete termín "VPN" v původním významu, tj. jako nástroj umožňující zabezpečit kompletní provoz mezi dvěma počítači nebo sítěmi (nebo počítačem a sítí). Většina dnešních uživatelů - a nejspíš i tazatel - si pod tím ale představuje službu, kdy se vytvoří tunel mezi vámi a "poskytovatelem VPN" a veškerá vaše komunikace s Internetem se routuje přes ten tunel. (Čímž se dosáhne toho, že místo aby váš ISP viděl všechno, vidí všechno "poskytovatel VPN", což má asi být z nějakého důvodu pro vaše soukromí lepší. :-) )

83
Hardware / Re:Frekvence u pracovniho monitoru
« kdy: 10. 02. 2021, 23:54:09 »
Pokud vaší prácí není testování akčních her, tak to smysl nemá.

84
taky mě to napadlo, ale myslím, že tohle by nefungovalo při kolizi IP rozsahů na těch dvou interface, nebo se mýlím?
Proč by nemělo? Konfliktní routy nejsou problém, pokud nejsou ve stejné tabulce. Pravidla vám pak říkají, ve které tabulce (nebo obecně ve kterých a v jakém pořadí) se má pro daný paket provést lookup.

85
všechno bude nakonec komunikovat přes mqtt takže by tak mohly komunikovat i obě instance komunikačního software (za předpokladu že najdu vhodnou implementaci podporující unix sockety, nebo přes unix sockety rmi).
Pro komunikaci mezi netns se používají veth rozhraní. Pomocí
Kód: [Vybrat]
ip link add veth1 type veth peer name veth2
si vytvoříte pár rozhaní, který funguje tak, že paket, který se odešle přes jedno z nich, se objeví jako příchozí na druhém. Jedno rozhraní necháte v init netns a druhé přesunete do toho druhého.

86
Sítě / Re:Síťovka blokuje port - může?
« kdy: 20. 01. 2021, 00:49:17 »
Sitovka jako takova rozumi jen IEEE 802.3 ramcum, driver k sitovce muze znat treba 802.1q ramce, ale porty zna vetsinou az IP stack....
To není tak úplně pravda, i běžné konzumní síťové adaptéry umějí přinejmenším počítat a ověřovat TCP a UDP checksumy a provádět TSO. Ty chytřejší by pak uměly třeba i tu filtraci podle portů - viz např. "ethtool -N" a "ethtool -X". Tím samozřejmě nechci tvrdit, že tohle je ten případ, jen že představa, že síťovou kartu nezajímá nic za ethernetovou hlavičkou (kromě FCS), je hodně vzdálená realitě.

87
Klíče se tam "neukládají", nýbrž "generují" a nikdy kartu neopustí (nejdou vykopírovat). Je tedy nutné kartu fyzicky vlastnit.
Přinejmenším Yubikey a Nitrokey umožňují oboje: buď vygenerování klíče přímo v tokenu nebo uložení existujícího klíče do tokenu. Ta druhá varianta se hodí v případě, že je potřeba buď mít stejný klíč ve více tokenech nebo mít zálohu pro případ poškození nebo poruchy tokenu. (Čistě technicky i pro případ jeho ztráty, ale v takovém případě je z bezpečnostních důvodů žádoucí klíč revokovat.)

88
Odkladiště / Re:Argumenty bezpečnosti open-source
« kdy: 28. 04. 2020, 11:10:47 »
Především je potřeba si uvědomit, že nelze automaticky předpokládat, že počet vydaných oprav odpovídá počtu nalezených chyb. Když nějaký projekt nebude vydávat opravy vůbec, nemůžu z toho přece vyvozovat, že ten software nemá žádné chyby. Zrovna tak sice praxe některých komerčních firem vydávat opravy kumulativně např. jednou za měsíc sice na první pohled vypadá prakticky (je otravné pořád instalovat nějaké updaty), ale znamená to, že zákazník bude často na opravu konkrétní chyby zbytečně čekat déle, než je nutné.

Není žádný důvod předpokládat, že by v open source bylo a priori víc chyb. U obou modelů jsou projekty vedené dobře a projekty udržované mizerně. Celkově bych ale spíš řekl, že public scrutiny u open source nutí vývojáře k větší sebekázni a lepší kultuře. Viděl jsem zdrojáky některých projektů, které byly dlouhodobě vyvíjeny jako closed source a potom otevřeny, viděl jsem zdrojáky některých out of tree jaderných modulů a s trochou cynické nadsázky bych řekl, že hlavním důvodem, proč mnohé firmy upřednostňují closed source vývoj, není ani tak strach o jejich drahocenné know-how, ale spíš strach z ostudy, kdyby ty zdrojáky viděl někdo cizí.

89
Distribuce / Re:ZFS a Linux
« kdy: 23. 03. 2020, 08:38:24 »
Pokud smí zdrojové kódy i binárky šířit jedna distribuce, nemůže existovat ani překážka k tomu, aby takový kód byl součástí Linuxu rovnou. Stejně jako distribuce explicitně označuje Linux jako GPL, a ZFS jako CDDL, stejné rozdělení by nemuselo být až v distribuci, ale rovnou v Linuxu.
Za prvé: je velký rozdíl mezi distribucí (souborem mnoha nezávislých programů od různých autorů a kolektivů) a jádrem (jeden softwarový projekt). Za druhé: to, že Canonical začal cosi distribuovat, ani zdaleka není zárukou, že je to v pořádku a že žádné riziko nehrozí. On to totiž klidně může být výsledek nějaké neveřejné dohody. Nebo může Oracle jen čekat, až bude potenciálních obětí víc. Nebo prostě žalobu teprve připravují. A i kdyby jim to opravdu bylo jedno a rozhodli se "nechat to být", ani to by pořád ještě neznamenalo, že žádný problém neexistuje (a že třeba časem názor nezmění).

Citace
Viz výše. Společná distribuce GPL Linuxu a non-GPL jiných součástí by nemusela vyžadovat přelicencování ani na jedné straně.
Tato vaše interpretace GPL a pojmu "autorské dílo" je dosti unikátní a rozhodně není předmětem většinového konsensu.

Citace
Oraclu vůbec nevadí, když se ZFS bude šířit dál jako součást (chcete-li: přívěsek) něčeho dalšího. Oni se nemají k čemu vyjadřovat, co měnit.
A to víte odkud? Máte nějaké právně závazné vyjádření? Nebo je to jen vaše osobní interpretace textu těch licencí?

Citace
To by si ovšem Linux nesměl myslet, že je pupek světa a že všichni jsou tu od toho, aby se dávali na "správnou víru". Než aby se hledalo technické a administrativní řešení a vyhovělo se licencím, vedou se žabomyší spory a poměřují se pindíky.
Předně: Linux si nic nemyslí, Linux je operační systém. Linus rozhodně není žádný GNU evangelista, licenci GPL2 zvolil v roce 1991 z praktických důvodů a i poté mnohokrát ukázal, že je pragmatik, ne ideolog (a byl za to také ze strany FSF a Richarda Stallmana mnohokrát kritizován). Realita je prostě taková, že ta licence tady je, není reálně proveditelné ji změnit (i kdyby někdo chtěl) a je třeba ji respektovat. Pokud Sun zvolil licenci, která šíření i pod GPL2 neumožňuje, a Sun ani Oracle na tom dodnes nic nezměnili, pak prostě o to, aby ZFS v Linuxu být mohl, nestojí. Já to jen respektuji a nesnažím se vymýšlet krkolomné myšlenkové konstrukce k tomu, abych ho tam mít mohl. Stejně tak to respektují maintaineři linuxových filesystémů.

Pindíky do toho z nějakého záhadného důvodu (opakovaně) taháte jen vy, mně je váš pindík úplně ukradený.

Citace
Btrfs, nedosahuje produkční jakosti pro enterprise. Ne všechny podniky, ale zatím většina dává přednost ZFS, pročež Btrfs chybí v této oblasti jak vendoři, tak i zkušenosti z praxe.
Reality check: btrfs je od SLE11-SP3 (červenec 2013) plně podporovaný a používaný enterprise zákazníky.

Citace
Pokud se něco nezmění, tak Btrfs bude čím dál víc konvergovat k vlastnostem žádaným v SOHO a enterprise segment nebude mít ještě dlouho jinou volbu, než ZFS.
Reality check: už pár let platí, že výrazná většina vývojářů btrfs jsou zaměstnanci SUSE nebo Facebooku. Pro žádnou z těchto firem není SOHO těžištěm jejich zájmu.

90
Distribuce / Re:ZFS a Linux
« kdy: 23. 03. 2020, 08:13:29 »
Myslím, že není potřeba přelicencovat zdrojáky Linuxu. Co si vzpomínám, existují legálně moduly kernelu, které nejsou pod GPL, a dokonce jsou uzavřené. Má to tuším jakési omezení, co mohou non-GPL moduly volat, a co už ne. Důvod – pokud si dobře vzpomínám – spočívá v tom, že kernelový modul využívající tu omezenou podmnožinu funkcí je jistou analogií k procesu, který taky může (omezeně) volat některé funkce kernelu, aniž by musel být pod GPL.
Takové moduly sice existují, ale ohledně toho, zda je jejich šíření v souladu s licencí, zdaleka nepanuje shoda. To, že zatím nikdo necítil potřebu hnát to před soud, neznamená, že to je v pořádku. Doporučuji zamyslet se nad tím, že např. linkovat non-GPL program proti GPL knihovně v pořádku není a nikdo to nerozporuje (jinak by nebyla potřeba LGPL). A jak už jsem řekl, vztah mezi jádrem a modulem je ještě těsnější, než je to u programu a dynamicky linkované knihovny. Koneckonců, kdyby se mělo všeobecně za to, že non-GPL moduly jsou v pořádku, necítily by firmy potřebu vymýšlet obezličky typu DKMS nebo "GPL kondom".

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