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]
91
Sítě / Re:Problém s fragmenty IPv6
« kdy: 17. 02. 2019, 21:23:03 »
Nezahazují se samozřejmě všechny fragmenty kratší než IPV6_MIN_MTU (1280), ale jen ty, které nejsou poslední. Idea je taková, že standardní implementace seká paket podle MTU a do posledního fragmentu dá zbytek. Cílem toho patche bylo omezit rizika útoků typu FragmentSmack, které se snaží zatížit CPU příjemce posíláním velkého počtu nesmyslných fragmentů (ideálně co nejkratších).

Bohužel se ukázalo, že existují i reálné implementace, které rozdělují paket do fragmentů jinak, takže ten commit se asi v dohledné době bude revertovat, ale nejdřív bude potřeba změnit implementaci fragment queue pro IPv6 na rbtree (místo lineárního seznamu), stejně jako to už je u IPv4.

92
Hardware / Re:Bolest při psaní na mechanické klávesnici
« kdy: 09. 01. 2019, 10:06:13 »
Zrovna HyperX Alloy FPS jsem začal před časem používat, ale v "brown" variantě. Ze začátku mi hodně vadil naprosto tvrdý doraz, ale postupně jsem přizpůsobil styl psaní tak, abych nešel až do dorazu, nebo aspoň jen lehce; subjektivní pocit při psaní se tím hodně zlepšil. U "red", kde není žádná odezva ("prokliknutí" - i u "brown" je podstatně slabší, než jsem čekal), je to ale asi těžší.

93
Vývoj / Re:Kdy je refaktorizace uz hodne?
« kdy: 04. 07. 2018, 22:13:33 »
Již jsme se tu o tom bavili. Vždy je to přece o možnostech projektu. Projekt s backporty do 10 let starého kódu (např. LTS kernel) je úplně jiný než projekt, který provozuje firma sama a jen v jedné verzi (náš případ, ale takových je spoustu, typicky webové projekty). Proto vždy uvádím "pokud to projekt umožňuje".
Jednak jsem už psal, že 10 let je extrém (i když někdy to je v praxi ještě víc, a nejde jen o jádro, kde navíc velkou část upstreamových vývojářů starší verze také nezajímají), ale i u projektu, který nepotřebuje udržovat starší stable verze, je potřeba se každou chvíli podívat do historie, kde se ta či ona konstrukce vlastně vzala a proč (a ne, nejde to mít všechno v komentářích).

Vůbec nechci tvrdit, že refactoring je a priori špatně. Ale když tu vidím některé nadšené komentáře, jak je potřeba přepisovat průběžně, často a radostně, tak mi z toho trochu běhá mráz po zádech a vyprovokovalo mne to napsat podobně přehnaný příspěvek z druhé strany. Ono těch projektů, kde maintenance je výrazně méně než práce na nové funkcionalitě, nakonec až tak moc není a některým lidem by opravdu prospělo, kdyby si mohli na čas vyzkoušet odvrácenou stranu toho, co jim připadá tak skvělé a žádoucí. Takže než se člověk do něčeho takového pustí, měl by si sakra dobře rozmyslet, jestli jsou důvody dostatečně vážné (tj. ne jen "kdybych to psal dneska, udělal bych to jinak") a jestli přínos dostatečně převáží problémy, které tím způsobí.
Citace
Když si každý featuru naprogramuje po svém, máš po pár letech 5 různých variant a žádná není pořádně. Při šestém požadavku je daleko smysluplnější sednout a tři dny to čistit, sjednotit/zredukovat do jedné pořádně funkční a aktuální, než tam zase copy/paste naládovat šestou verzi. To není nic notorického, ale normální rozum.
Vidíte, mně třeba přijde, že "normální rozum" velí nenechat to dojít takhle daleko. Při nejlepší vůli se může stát, že se tam objeví dvě skoro stejné verze téhož a pak je většinou opravdu na místě to napravit (čím dříve tím lépe). Ale pět? To už IMHO signalizuje vážné problémy v komunikaci nebo absenci review (dost možná oboje).

94
Vývoj / Re:Kdy je refaktorizace uz hodne?
« kdy: 04. 07. 2018, 21:47:18 »
Pokud má ten člověk alespoň minimální možnosti a ty nenabízíš pozlacený kosmodrom jako bonus, tak se s tebou dotyčný rozloučí a půjde někam, kde se dá pracovat.
Jednak jsem (naivně, jak vidím) doufal, že bude zřejmé, že jde o nadsázku, jednak pokud by někdo opravdu ihned po příchodu trval na tom, že se musí bezpodmínečně překopat podle jeho představ projekt, který už nějakou dobu běží a na kterém pracují další vývojáři, aby "se dalo pracovat", pak by asi musel být sám pozlacený. Ona je spousta lidí, kteří jsou přesvědčeni o své genialitě (a někdy, i když zřídka, třeba i právem), ale pracovat s nimi na společném projektu je za trest.

95
Vývoj / Re:Kdy je refaktorizace uz hodne?
« kdy: 04. 07. 2018, 19:34:25 »
Deset let je možná extrém, ale jinak je ta "specifická situace" častější, než si myslíte. Ale pokud vám to umožní cítit se nadřazeně, facepalmujte si podle libosti.

96
Vývoj / Re:Kdy je refaktorizace uz hodne?
« kdy: 04. 07. 2018, 17:51:39 »
Přehnaně nadšené a notorické refaktoristy doporučuji aspoň tak na rok zařadit na pozici, kde bude rutinní součástí jejich práce backport oprav do různých verzí od nejnovějších po deset let staré a dohledávání, kde v historii došlo ke konkrétní změně. To by v tom byl čert, aby nezměnili pohled na to, jestli je bezpodmínečně nutné neustále něco učesávat a upravovat, aby to vypadalo víc cool.

97
Studium a uplatnění / Re:V IT už je teď každý inženýr?
« kdy: 04. 07. 2018, 08:09:41 »
Na to, aby věděl že Cisco dělá všechno špatně, tomu přece rozumět nepotřebuje.  ;D
Cisco samozřejmě nedělá "všechno špatně". Na druhou stranu, označit ještě dnes Cisco za průkopníka je IMHO hodně odvážné. Třeba jejich přístup k IPv6 bych s trochou nadsázky (ale jen malou) označil za pasivně agresivní; sice chápu, že chrání své ekonomické zájmy, ale coby "průkopníky" je to poněkud diskvalifikuje. Stejně tak když už tu byla řeč o "nových" protokolech (nebo prostě čemkoli jiném než TCP a UDP), tak způsob, jak funguje receive checksum offloading v jejich enic driveru, je ukázkovým příkladem "protocol ossification", jak se o ní mluví např. tady: https://www.youtube.com/watch?v=6VgmazGwL_Y (Z marketingového hlediska je holt výhodnější, když se s novou verzí přidá podpora pro další protokol, než kdyby rovnou od začátku podporovali univerzálně všechno.)

98
Studium a uplatnění / Re:V IT už je teď každý inženýr?
« kdy: 03. 07. 2018, 08:11:14 »
Ještě poznámka k tomuto:
Souhlasím, že ohledně "...schopen značného množství úkonů v praktické síťové administraci...." máte pravdu, avšak jsem přesvědčenej, že to vypovídá také i o těch dalších zmíněných vlastnostech "inženýrské myšlení a rozhled po oboru a jestli bude schopen odborně růst dál."
Rozhled, logické myšlení ani schopnost (a hlavně ochotu) učit se nové věci vám žádný kus papíru nezaručí. Ani vysokoškolský diplom (u některých škol je korelace větší, u některých menší, ale záruka to není nikde), ani certifikace nějaké komerční firmy. Pár CCNP jsem potkal a zejména jeden mi utkvěl v paměti, protože ten člověk byl ukázkovým příkladem naprosté absence toho, o čem tvrdíte, že je k získání CCNP nutností. Za celou dobu našeho rozhovoru nebyl schopen na obhajobu svého řešení použít jiný argument než "ale podle Cisco guidelines se to má dělat takhle" a vyvrcholilo to perlou "přece kdyby ta funkce byla k něčemu dobrá, tak ji Cisco bude nabízet taky". Samozřejmě že takoví nejsou zdaleka všichni držitelé Cisco certifikátů, ale bylo by naivní myslet si, že CCNP (nebo jakýkoli jiný certifikát) je garancí něčeho z toho, co mu přisuzujete.

Stran: 1 ... 5 6 [7]