татко Крокодил

Първи ден в болницата.

Станах в 6:10, че да стигна в 7:45 пред кабинета за приемане. Вкъщи само малкия звяр беше толкова ранобуден, та можах даже да го нахраня, преди да изляза. Явно не съм се объркал кога е час пик, стигнах доста бързо.

Набодоха ме, наснимаха ме, погледна ме кардиолог, и понеже медицината в наши дни се движи по-бързо, утре ме оперират. Тоя път обаче съм втората операция за деня, т.е. не се знае кога ме почват и кога трябва да свърши (и дали няма предишната да отече много дълго и да ме разместят), та новини ще има по някое време.

Иначе, тук си е тихо и спокойно, има гледка към “Гешов”, и най-вероятно ще си изкарам времето в ровене в кода на haproxy, да можем да пуснем trafstat-а на едно интересно място.
(кодът му не е от най-радващите, и най-вече не изглежда да има на лесно място нещата, дето ми трябват…)

Та, невралгията ми се върна. След като проверих с един куп доктори дали не може да е нещо друго и взех едно второ мнение от едно светило, което оперира в момента в Пирогов, изводът е, че ще се отваря и ремонтира (и ще се види дали нещо ново не се е появило там, понеже и болката е от време на време различна). В понеделник (25.02) ме приемат в болницата, и по някое време след като ме изследват за стандартните неща, ще ме оперират. Ще намеря начин да има някакви update-и тук за заинтересуваните.

Като цяло не горя от радост, че ще бъда опериран, от друга страна, освен че ще се наспя, пак ще се реши проблемът с болката. Спокойно мога да кажа, че предната операция ми даде 5 години живот (успях да се оженя и да направя две деца, освен всичко останало), та ще съм щастлив и на още 5 :)

А може даже и да блогвам повече от болницата, въпреки идеята ми да посвърша малко работа, че да не ми е скучно.

Та, FOSDEM 2019. В bullet point-и, че не мога да събера нещо по-кохерентно:

– Занесохме си пак прилично количество хора от тук за видео екипа;
– Тази година бяхме с повече зали – 26 (+ една смяна в последния момент);
– … горното репи да яде в сравнение с идеята догодина да са над 30. Очаквам 2050-та FOSDEM да се случва в цял Брюксел;
– Понякога е притеснителен тонажа техника, който разнасяме напред-назад, с всичките стативи, камери, кутии и какво ли не;
– Сменяхме зала м/у събота и неделя, защото в първоначалната потече вода. ОТ СТЕНАТА (местната поддръжка на сградите дойте, видя, каза “това не е нормално” и си тръгна);
– Смяната към TCP реши старите проблеми (и добави нови);
– Audio monitoring-а се оказа много удобен;
– Имаме огромно количество бележки за post-mortem, догодина може да има някои много интересни промени във видеото;
– До сряда след конференцията бяха публикувани над 600 лекции.

Едно от интересните неща беше, че Емануил беше организирал нещо като пилотна младежка програма – едно девойче, 4-5 клас, от Англия (заедно с майка си), да дойде и да види FOSDEM. Много се зарадва на целия video setup и да разбере как работят нещата, и ми припомни, че можем/трябва да направим нещо такова и при нас, най-малкото на OpenFest, на принципа на програмите за социална отговорност (няма само Rails Girls да са такива, в крайна сметка).

Отдавна не съм писал, та накратко новини:

– чакаме втори звяр (знае се, че е мъжки, мислим име);
– върна ми се невралгията преди една седмица, следващата седмица съм на ЯМР и после ще видим;
– ще ходя пак на FOSDEM да се занимавам с видеото (въпреки невралгията, хаповете вършат някаква работа);

Около страничните всякакви проекти:
– работя по въпроса да имаме сървър с 10gbe порт за OpenFest (вече взех модули за switch-а, остана да харесам карта и да видя дали ще сменяме желязото), така ще си улесним малко свързаността, че с тоя LACP bond ме препсуваха три пъти;
– самият OpenFest мина доста добре. Аз се правех, че не съм в организацията;
– появяват се нови ipv6 тунели, който случайно не знае, че давам, да види в wiki-то по темата – има там едни гигабити да се напълнят, та обаждайте се, ако ви трябват;
– initLab би се радвал на още членове;

И вероятно много неща, дето не помня и трябва да описвам, особено случаи за дебъгване, ама за тях – като си спомня.

(английската версия е в блога на StorPool)

В последните няколко години StorPool се появяват на OpenFest. За да направим щанда по-забавен, измисляме някоя игра. Миналата година задачата изглеждаше измамно проста, но доста затрудни хората, та тази година реших да опитам с нещо по-лесно.

“Fix the problems” задачата е базирана на много някакви стандартни случки от админския живот, т.е. на нещо, което би трябвало да ви се е случвало. Представете си обаждане от приятел (което може да е в 8 сутринта), в което ви казват “live сме с тая система, ама даже не тръгва, ПОМОЩ”. Та, логвате се и откривате ужасяваща кочина, сглобена от неща, правени от различни хора на различни езици, не-тествана и пълна с малки и големи проблеми, и трябва да проработи.

(или може би само на мен се случва, знам ли…)

Може да се пробвате, като свалите задачката с примерни данни от quiz.storpool.com/of2018.tgz и се пробвате. Отговорът започва с “8”.

За приключилите и нетърпеливите, ето описание:
Задачата се състои от следните файлове: a.c, a.php, a.pl, a.py, run.sh (който си мислех да кръстя “a.sh”) и един Makefile. “run.sh” свързва всички останали заедно, да сметне някакъв резултат от данните в “data/” директорията.

Цялото нещо си има история – имало 4 различни програмиста – C файлът бил написан от човек, който говори английски, PHP-то от финландец, Perl-а от унгарец, Python-а от арабин, и shell script-а от българин. Всички са имали лошо мнение за останалите и са оставили коментари в кода по адрес на останалите.

Счупванията са сравнително тривиални, понеже time limit-а за цялата задача беше 30 минути и имаше разни заблуждаващи моменти. Започвам от свързващия файл и после по pipe-а:

run.sh навързва всичките останали. Основната грешка е, че липсва -0 параметъра на xargs (което се забелязва доста лесно, понеже find използва -print0). Друга гадост е, че файлът е с DOS-овски нови редове и не може да бъде стартиран нормално, или трябва да се подменят, или да си копирате отвътре pipe и да го пуснете на ръка.

В коментарите може да се види как авторът нарича останалите “идиоти” (което съм сигурен, че всички са виждали в някакъв вид), и списъкът му за пазаруване. Последното може да се вижда странно и невероятно, но е нещо, което съм виждал в production код – случва се, като трябва веднага да се запише нещо и човекът го мързи да отвори нов прозорец в редактора или да намери малко хартия.
(някакъв спомен ми се мотае, че случая, който бях виждал беше поръчка за KFC…)

a.php добавя 1 към всички числа, и за да дразни останалите разработчици, добавя и допълнителни интервал. Очевидната грешка е че вместо STDIN е написано STDON, което бързо се оправя.

В коментарите се вижда как програмистът не е щастлив с останалите от екипа и водката му е почти свършила. Не съм виждал лично подобен коментар, но съм чувал от достоверни източници за подобни случаи. Колкото до смисъла от подобен код, има ужасно много такива дребни неща в много проекти, които никога не е трябвало да съществуват, но все пак са там.

a.pl просто премахва всички интервали, т.е. създава едно голямо число от всичките числа на реда. Грешката е, че се използва $__ вместо $_ – лесна за забелязване правописна грешка.

В последния коментар на файла има оплакване, че авторът не е разбрал нищо от това, което останалите са говорили и че финландецът е бил пиян. В някакъв момент бях се замислил дали не искам да разпиша някъде целият разговор на тия хора, щеше или да е много забавно, или много болезнено.

a.py взима всички числа и връща остатъкът им при деление на 2^63 (което е hard-code-нато като 9223372036854775808). Грешката тук е, че цикълът започва с while False:, което няма никакъв смисъл, и смяната му на while True: решава проблема. Самият код е малко по-гаден от останалите, понеже има променливи с имена на арабски, които се изписват от дясно на ляво и могат да объркат терминала, но в крайна сметка тези части не трябва да се пипат.

Оплакването на края е, че ако не си бил взел трета жена, нямало да му се налага да работи с тези хора…

И накрая, a.c прави странни изчисления и вади остатъка от деление на 2^10 на резултата в шестнайсетичен вид (за да е достатъчно кратко, че да върши работа за отговор). Грешката в кода е, че целочисленият тип в началото е грешен и трябва да се работи с long long (което се вижда в останалия код). Това е и причината в Makefile да има -Werror -Wall, за да се забележи лесно проблема.

А коментарите във файла са премахнати заради “PARA-22”, което не би трябвало да има нужда от дообясняване.

Цялото нещо може да изглежда много невероятно, особено колко е чувствително към числата и размера им. Мога да се оправдая с това, че е игра и че основно трябва да е забавно (и че ме мързи), но за съжаление подобни неща съм виждал достатъчно често или са ми разказвали за тях. Поне се надявам, че участниците са се забавлявали:)

Записите са готови, може да се свалят от видеоархива или да се гледат в тубата.

(Това е лекцията ми от OpenFest 2018. Разказът не се получи много добре, понеже със задачите преди това забравил половината от нея, надявам се текстът да е по-добре. Също така мисля да публикувам кода за нея, понеже в него се появиха разни интересни неща)

Иска ми се да разкажа за OpenFest. Минаха много години и се събра много история, много идеи, много последствия – хубаво е да се знаят и да е ясно защо трябва да се продължат.

Лекцията не претендира за голяма изчерпателност, понеже ще отнеме два дни и малко ще попречи на останалите лекции :)

Отсега да предупредя, това е една много разхвърляна лекция, с подъл спамерски елемент.

Първият OpenFest беше 2003та. Започна като събитие за свободния софтуер, и се проведе в много градове из страната, като беше по едно (спрямо сегашните мащаби) малко събитие във всеки град.

В началото се движеше от съвсем малко хора, беше зората на free software/open source движението и ентусиастите не бяха много.

До преди това основното подобно събитие беше един малък семинар в Стара Загора всяка година, на българската Linux User група.

Това е една снимка на залата от първия openfest, издирена някъде от архивите на linux-bg.

А това е едно от първото ни споменавания във вестник, мисля, че беше Пазарджишки. Благодаря на човека, който го е снимал/сканирал:)

Учудващо, но идеите не са се променили много през годините. Има много изписани текстове, с дълги или не толкова дълги думи, които да обясняват целите на феста, но аз мен винаги в общи линии нещата са се характеризирали със следните две думи:

Две прости ясни думи. Тълкуването им може да се остави на въображението ви :)

Каквото и друго да измисля, в общи линии се включва в тези неща.

Ако някой направи tag cloud с темите, вероятно ще се стигне до горните няколко области. Разбира се, свързващото нещо беше Linux, понеже олицетворяваше всички тези неща в някакъв вид, и беше нещото, което ползвахме, да си вършим работата или да правим разни интересни неща…

Имало е всякакви интересни теми и хора на openfest през годините. Избрал съм няколко, за останалите трябва да се заровите в програмите или някой да напише подробна история :)

Останал ми е спомен от хората от wikipedia, които идваха да говорят на OpenFest – и за техническата и за не-толкова техническата си страна, докато още не бяха един от най-големите сайтове в internet-а.

Една от инициативите на общността беше (и още е) свободния софтуер в държавната администрация – употребата му, какви лицензи за какво да се купуват и всякакви такива теми. Не мисля, че мога да си спомня всичките неща, през които преминахме, но като един краен резултат (за който много голяма отговорност носи Божо Божанов) имаме закон, който задължава фирмите всичкия софтуер, който се пише за държавата да е open source и да се публикува свободно.

Дори вче имаме резултат от това :) Наскоро беше публикуван кодът на новия портал за отворени данни, който е от две части, и искам да обърна внимание на едната:

Ако нямахме този отворен код за държавния софтуер, нямаше да сме наясно и да можем да направим каквото и да е за код като по-горния. Оставил съм отдолу link, целият код е забавен, може да видите и history-то му, ще се забавлявате още повече. Може би е време за един по-организиран community audit на подобен код, след като имаме възможността.

И е интересно дали някой може да провери каква част от кода е copy-paste от stackoverflow.

Друга тема, с която се занимахме беше инициативата в Европейския съюз да се приемат софтуерните патенти. Който си е имал работа с писание на софтуер в щатите знае за какво става въпрос, който не – миналата година имаше лекция от Пейо Попов по темата как са се борили с един патентен трол по един тривиален софтуерен патент. Много съм щастлив, че инициативата се провали при нас такива патенти няма.

(не се сдържах за снимката. Спокойно мога да кажа, че това изглежда по-смисленото приложение на IoT, вместо многото устройства, които в наши дни се използват основно за източник на DDoS атаки)

Имаше IoT лекции на openfest преди да съм чул термина, и хората дори се забавляваха да си запояват/подкарват такива неща в рамките на феста (и почти традиционно да успяват да убият мрежата по някакъв начин).

Около това ми се иска и да спомена workshop-ите за запояване, които са доста свързани – една година Цветан Узунов от Olimex си хареса един ъгъл в interpred, извади едни поялници и два дни хора седяха и запояваха различни неща. Искам много да му благодаря за започнатата традиция :)

И да, съвсем съм наясно, че запояването дори бе неше основното – основното беше подкарването на всичките тия компоненти да вършат различните интересни (и странни) задачи, които им бяха измислили.

За съжаление нямам снимка на съвсем първото такова събитие, за това съм сложил снимка от едно от по-скорошните.

Извън техническите и легални неща, преди няколко години направихме лекция за депресията и отражението и в IT обществото. Наскоро забелязах как вече хората не се притесняват да говорят по темата и да възприемат депресията като сифилиса, та ми се ще да вярвам, че и ние сме имали някакво влияние за това :)

Разбира се, имаше доста промени през годините – местихме се в различни зали, нямахме медийно отразяване, защото или имаше избори, или предния ден застрелваха някого (беше се случило две години подред).

Интересно за някои хора може да е, че Интерпред беше мястото, от което се изнесохме, защото наистина ни отесня. Мисля, че още не сме публикували колко човека дойдоха, понеже има сериозен шанс да ни глобят…

В екипът идваха нови хора, стари решаваха да си починат, после се връщаха.

Текущите цели се меняха, като може би най-яркия пример е колко време беше отделено на кампанията срещу софтуерните патенти. Има и много други примери, но с годините съм ги забравил и вероятно трябва да се изпие много бира с много хора, че да ги съберем всички :)

Обаче, без да се усетим, стана нещо интересно…

Изведнъж се оказа, че сме победили. Когато започвахме, свободния софтуер се считаше за хобистка история, някакво забавление и нищо сериозно, разни хора се подсмихваха и обясняваха, че това не е сериозна работа и да вземем да правим нещо смислено.

В момента…

В момента звучи съвсем нормално и очаквано, че най-използваните мобилни и cloud операционни системи са Linux и Linux-базирани. Базата данни, която използват всички, включително почти всички мобилни устройства (не само android) е sqlite и в общо линии не мисля, че в наши дни е откриваем компютър или телефон без нея.

Ако в наши дни някой седне да разработва софтуер, почти без изключение съдържа доста open-source компоненти. Казвам почти, понеже сигурно някой ще открие нещо древно от времената на Cobol, което да няма, но па всичко, което се използва в наши дни е така, и присъствието на git във visual studio code е доста добър индикатор….

В общи линии хората разбраха, че предимствата на свободния софтуер и на отворените стандарти надминават имагинерните проблеми от тях.

Това не ни остави без причина да съществуваме – винаги някой е против отвореността и се намира някоя кауза (например чл. 13 и няколко други на директивата за авторско право на Европейския съюз, която е поредния опит да се наложи цензура в Internet). Отбелязал съм разни проблеми, които очаквам да са ни теми в бъдеще:

DRM-ът не изчезва, продължават опитите да бъде наложен по някакъв начин и интегриран в света ни, което си остава едно от най-гнусните посягания на софтуерната свобода.

Всичките code-of-conduct тип проблеми няма да стават по-леки, както ни показа последната случка с Linus. Искрено се надявам да ги надрастнем… Мариян имаше предложение тази година да организираме панел по темата тук, но на мен ми призля. Не съм сигурен дали бях прав да се противя, и се надявам някой с по-здрав стомах и желание да успее да го направи (и да се получи смислено).

Софтуерът ни расте главоломно и става невъзможен за разбиране и поддръжка. Отдавна сме минали границите на разбираемост, и ще ни е трудно да се върнем в тях, но виждам някакви опити.

Internet-ът става все по-централизиран, което поставя всякакви ограничения на технологиите и улеснява и подслушването и анализа на информацията. Не знам колко години ще са ни нужни, за да осъзнаем последствията от технологиите, за които говори Едуард Сноудън, и вероятно ще са нужни още толкова, за да разберем, че не са спрели да се развиват.

В последните месеци не чета новини, но не мисля, че има големи разлики в действията на политиците спрямо internet, софтуерът и технологиите. Генералното ми очакване е, че ще трябва да продължаваме да се борим с всякакви глупости, които ни пречат да работим, живеем и т.н.

Идеята на събитието не се е променила особено, въпреки промените в екипа и изминалото време. Смятам, че идеите са достатъчно силни, че да могат да мотивират достатъчно хора, които да случат всичко.

За всяко събитие е полезно да има нови хора, и препоръчвам на всеки, който има желание, да се обади.

Преди да продължа с причните да се включите, една скоба – не е задължително да сте част от екипа, за да участвате по някакъв начин.

Почти всяка година се намира някой да се оплаче (основно без причина), че нямало добри лекции. Отговорът е винаги – като имаше CfP, къде спахте? Има много хора в нашата държава (и наблизо), които се занимават с интересни неща и могат да ги разкажат, но ги знаят само те и няколко близки приятели. Ако случайно сте от тези хора или от близките приятели, припомняйте им в началото на септември, че има такова нещо като OpenFest :)

Това важи не само за лекции, но и за workshop-и, има много неща, които могат да бъдат показани и на които посетителите могат да се научат.

И сега към причините:

Не е лесно да се оцени крайния ефект от OpenFest. Основното, което имам са някакви мои преживявания, от типа “чух на openfest за това и се занимавам с него”, за разни лекции и разни хора. Мисля, че всяка година има хора, идващи за първи път, които се прибират с пълни глави и се чудят кое от всичките неща, които са видели, да захванат.

На колко от вас ви харесва светът, в който живеете? Вдигнете ръка.

За всички, които вдигнаха ръка – свържете ме с дилъра си:)

В някои отношения нещата са по-добре, отколкото преди 20 години – сега например доста по-малко се стрелят по улиците.

От друга страна обаче, технологиите и злоупотребата с тях, концентрирането на много отговорности в една компания и т.н. са доста притеснителни.

Извадих няколко заглавия от новини(докато писах лекцията, на random, от един ден), за да илюстрирам. Преди месец-два съвсем бях спрял да ги чета, погледнах колкото да намеря нещо илюстративно, и никак не ми беше трудно…

Та, в светът, в който живеем:
– 62% от сайтовете използват ужасяващо строшена технология
– огромна компания, известна с повреждащото си въздействие купува друга средно вредна компания, която обаче е работодател на много сериозна част от разработчиците на ядрото и други инфраструктурни технологии
– Пак да си припомним, всеки от нас носи по едно-две проследяващи/подслушващи устройства, които м/у другото стават да правим обаждания и за browser-и. Статията конкретно е как няколко разузнавания послушват американския президент, и съм склонен да кажа, че нищо от това не е особено учудващо за който и да е, който е писал софтуер за такива устройства.
– Хората (не само в Русия) им се пробутва безплатен интернет, за да бъдат продавани.

Има начини да се борим с това. Образоването на хората, говореното по темата, привличането на нови хора в това е от възможностите на OpenFest, и е нещо, в което може да се включите.

Това като цяло произхожда от един момент, който за мен е очевиден, но по някога се притеснявам, че не е така за всички:

Ще се направя на стар и ще кажа, че не е задължително да ни е гадно. Виждал съм времена, които са били зле, виждал съм и по-добре, виждал съм нещата да се променят и в едната и другата посока и общият ми извод е, че не е нужно да ни е гадно, няма някаква вселенска повеля, която го изисква. Можем да направим нещо по въпроса и в общи линии си зависи от нас да го направим.

И да минем към нещо по-приятно.

Може би само на мен ми е толкова интересно това, но едно от нещата, които най-много са ме радвали са, че си правим сами каквото можем. Всякаква инфраструктура, като мрежа, wifi, видео streaming, понякога ток – имаме сериозен знаещ екип, интересна техника и всякакви забавни неща, които правим с нея.

Сайтът ни за submit-ване на лекции сами сме го писали, този за гласуване е пригаждан, сайтът на събитието (който по принцип е един wordpress) е сериозно дописван от нас и може да се види цялата му история в github.

Изобщо, техническата ни част е рай за хората, които обичат предизвикателствата :)

(тези неща Мариян ги спомена след лекцията, реших, че е добре да ги включа)

Разбира се, не всички екипи са толкова технически, но са също толкова важни.

Екипът “Логистика” отговаря за това всичката ни нужна техника (която никак не е малко) да стигне от различните места, на които се намира, до самата зала, и после да се изнесе. Грижи се за положението на всички физически неща, както и за събирането ни на лекторите от летището, особено като носят десетки килограми странни неща с тях.

Медийният екип се грижи за цялото медийно покритие на събитието и обявяването на нещата преди него – статии в сайта, twitter, facebook, събиране на информация от лектори и т.н.. Този екип е едно от местата, в които прохождащи журналисти/студенти могат да се занимават да пишат и отразяват нещо реално и случващо се.

При всички доброволци си имаме и екип, който се грижи за тях – да са облечени, нахранени, да има къде да си починат и всички подобни неща. Като едно тяхно действие мога да кажа как миналата година бяхме предвидили за Team room едно от помещенията до NOC-а, в мазето (със собствена тоалетна). Дойде екипът volunteer support, погледна, каза “това е твърде депресиращо” и заради тях сега екипът може да си почива в стая с прозорци :)
(аз не разбирам тия неща, но явно на хората им харесва)

Екипът рецепция е един от най-видимите и доста натоварен – голяма част от хилядите ни посетители минават през рецепцията по един или друг начин.

И екипът хералди се занимава да представя лектори, да ги прекъсва като им свършва времето и всякакви такива забавни неща.

Това е схема на мрежата ни, докато бяхме в зала “България”. Понеже там е много красиво и няма никаква инфраструктура, трябваше да опънем около километър кабели (и 2 метра оптика, щото едни медни GBIC-и се бяха счупили), съответно мрежата е направена да издържа на прекъсване на което и да е трасе и има в себе си няколко цикъла. Също така тази мрежа е пример, че може да се подкара MSTP в мрежа с Cisco и TP-Link устройства.

Това е как ни изглежда setup-а за тази година за залата, в която се намираме в момента.

… а това е по-артистично нарисувана схема на setup от предишни години.

Това са плановете за разпределението на площите през 2016…

… а тези – на етажът, на който се намираме в момента.

За хората, които обичат да обитават мазета – това е NOC-а ни в зала България,

а това – текущия в ТехПарка. Има напредък, но пак си е мазе и е много удобно за всякакви хора, на които NOC-овете са нормалното обиталище :)

Това е една снимка на техниката ни за 2015, в общи линии може да видите почти цялата ни мрежа, разпъната на едно бюро, заедно с някаква част от wifi AP-тата.

А това е една хубава снимка от по-малкия ни video setup.

И скоро не ни се е налагало да си прекарваме по странен начин internet-а, но искам да покажа как нищо не ни е спирало – тук може да видите какви средства сме използвали за стабилизация на антена…

Една година в петъка преди openfest бях започнал да се разболявам. В понеделник бях съвсем здрав, и изобщо не си спомням да съм боледувал, имам спомен само от много тичане и задачи …

Мислех си да опиша екипа, но няма да ми стигнат нито думите, нито времето. Събрал съм малко снимки, колкото горе-долу да илюстрирам, но си казвам отсега, че изобщо не стигат:)

Това е една от най-първите снимки, когато даже имахме статуетка, която давахме на някой за принос в областта на свободния софтуер.

Тук седим и конфигурираме мрежа през 2005. Вече е минало достатъчно време да кажа спокойно, че човекът от ИЕЦ беше готин и просто каза – ето ви switch-а, настройте го както си искате.

Този сигурно някои от вас го познават…

Тук може да видите мрежар в нормалното си обиталище.

Екипът от 2013 (когато започнахме традицията всички да се покажат един път на сцената).

Екипът от 2014 (когато започнахме друга традиция, екипът да има отличаващи се тениски, за по-лесно ориентиране на посетителите).

Екипът от 2015 (това, което виждате най-вдясно са един малък духов квартет, който свири Имперския марш).

…а 2015 дори успяхме да усмихнем Яна, въпреки цялата лудница.

Тук има някакви хора, които мъкнат…

… и разни въоръжени такива. Ако не сте виждали хайдутин с пистолет и радиостанция, това ви е шанса.

Екипът от 2016.

Екипът от 2017.

И от 2018, може да видите как час от екипа стои в петък вечер в сървърното и оправя проблем, за да имаме internet на следващия ден. От другата страна на телефона съм аз, и много се зарадвах, че някой е снимал ситуацията, особено с човека, който се държи за главата.

И искам да завърша с една благодарност към всички, които през годините са допринасяли по някакъв начин за OpenFest. Събрах доколкото можах всички имена (надявам се не съм пропуснал никого)
Видеото, което пуснах.

Накратко, vote.openfest.org – може да гласувате за лекциите, които искате да видите на OpenFest 2018.

(английската версия е в блога на StorPool)

Това е един случай, който отне известно време да се дебъгне, включващ StorPool, виртуални машини, cgroup-и, OOM killer-а и кеширането. Части от него би трябвало да са полезни и на други хора/админи.

Започна с оплакване от клиента:

> Пак се случва, на тоя hypervisor виртуалните машини ги убива
> OOM killer-а. Това не се случва на hyervisor-и, на които няма
> cgroup-и, не може ли да не ги конфигурирате?

(
Смисълът изобщо да имаме cgroup-и е, че няма друг начин да се резервират памет и процесори за даден набор процеси. Понеже storage системата е една от най-чувствителните части на системата към латентности и подобни проблеми (или, нека сме по-точни, всичко останало е много чувствително към проблеми на storage системата), доста е полезно да е предпазена от всичко останало. По същия начин е полезно и да се разделят виртуалните машини и системните процеси, за да не го отнесе грешното нещо при някой memory leak или побъркан allocation. Също така, има много забавен вариант за memory deadlock (който го има с всяка storage система, която не е в kernel-а и с някои които са вътре, който може да бъде описан по следния начин:

Процес към kernel-а: искам памет
Kernel към процеса: ей-сега
Kernel (говори си сам): то искаш, ама няма. Нямам какво да освободя друго, но мога да flush-на някакъв dirty cache
Kernel към storage системата: на ти тия данни, запиши ги
Storage системата към kernel-а: разбира се, за теб си режа даже ноктите без упойка
Storage системата (говори си сама): тия данни не са aling-нати както трябва за гнусния хардуер отдолу, трябва да ги копирам малко и наместя
Storage системата към kernel-а: искам памет
)

Разбира се, цялото нещо нямаше да е чак такъв проблем, ако Linux-кия OOM killer и cgroup-ите работеха правилно, но версиите по всичките kernel-и, които срещаме (което значи CentOS[67], т.е. kernel с име 3.10.xxx и с diff спрямо оригинала, който вероятно е колкото 30% от кода) се държат странно и от време на време застрелват sshd вместо който трябва. Новите идеи за отношенията м/у OOM killer-а и cgroup-ите се очертава да ни стъжнят живота още повече.

Та, за да си резервира човек някакъв набор памет за набор от процеси на KVM hypervisor, трябва да създаде memory cgroup-а за системните неща (system.slice), виртуалните машини (machine.slice), може би user-ските неща (user.slice), и в нашия случай storpool.slice. После за всички тия групи сборът на лимитите трябва да е с около 1-2GB по-малък от общата памет (понеже някаква част си е за kernel-а и той никъде не я account-ва), и да се подсигури, че всички процеси са по тези cgroup-и или техни деца, и няма никой в root cgroup-ата. Това се постига с разни опции на libvirt, systemd и малко тел+тиксо, но като цяло върши работа.

Има обаче известен проблем с memory cgroup-ите, буфер кеша и OOM killer-а. Ако не ползвате cgroup-и и не ви стига паметта, kernel-ът по принцип flush-ва dirty page-овете (т.е. незаписаните данни) и clean cache (прочетени файлове от файловата система), та да си върне памет и да може да я даде на който я иска. В случая с cgroup-ите обаче clean cache не се почиства, и предпочитания за kernel-а начин е просто да пусне OOM killer-а, който да застреля някой полезен процес.

(За който бори такива проблеми, има доста полезна информация колко памет е account-ната за какво в “memory.stat” за всяка cgroup-а в /sys, например /sys/fs/cgroup/memory/machine.slice/memory.stat)

Ако си говорим принципно, в случая с виртуалните машини това не трябва да е проблем, понеже те няма причина да ползват кеш – вътре във виртуалката ще има какъвто и трябва, и няма смисъл да се хаби двойно памет (съответно всичките дискове се настройват с cache=none). Да не говорим, че не-спирането на кеша (който разбира се е пуснат по default, ама post за идиотските default-и в qemu/libvirt ще е бая) не позволява да се правят live миграции (libvirt-а отказва, щото можело да доведе до загуба на данни).

(Което всъщност е оправено в https://github.com/qemu/qemu/commit/dd577a26ff03b6829721b1ffbbf9e7c411b72378, но още не изглежда да е merge-нато, благодаря на колегите, че ми го посочиха)

Повечето оркестрационни системи в наши дни ползват “cache=none” в техните конфигурации (и интеграциите на StorPool с тях гледат да го настроят, ако има как), но в този конкретен случай системата имаше някакви много стари виртуалки, правени от стари template-и (някои от които ползваха IDE вместо virtio), и със съответния default. Правилното решение за тези виртуалки би било да се оправи template-а и да се рестартират, но по някаква причина хората не са щастливи да рестартират виртуалките на клиентите, и предполагам, че и клиентите не са големи фенове на идеята. Също така имаше някаква странна причина (която мозъкът ми е изтрил) да не може да се сменят конкретно тези template-и.

Не сме първите, които удрят проблема с “твърде много clean cache в паметта, който не ни трябва”. Ето какво ни хрумна и какво направихме в крайна сметка:

Първата идея, която ни хрумна беше периодично да почистваме buffer cache, с “echo 3 > /proc/sys/vm/drop_caches”. Това ще сработи, но като решение е доста тъпа брадва, понеже и ще изхвърли от кеша полезни неща (и системата ще си препрочита libc-то постоянно).

Втората идея се появи с това, че има нещо много хубаво, наречено LD_PRELOAD, с което в общи линии може да се прихване всякаква функция, която се вика от дадено binary и да се добави още нещо. По този начин може да се прихване open() и ако се открие, че е block device, да му се сложи флаг O_DIRECT (който в общи линии значи “опитай се да не ползваш buffer cache”). Проблемът на O_DIRECT е, че има някои неприятни ограничения, като например изискването паметта и offset-ите при писане/четене да са подравнени по някакъв начин, като 512 байта подравняване би трябвало да са ОК, ако не се ползва файлова система (където може да се наложи подравняване на page size или повече). Понеже няма как да знаем какво прави виртуалната машина отгоре, имаше шанс да се наложи да прихващаме всички read() и write() и да правим копие на данните в наша, подравнена памет, което щеше да е прилично количество писане и щеше да е трудно да няма грешки.

Сетихме се също така, че в kernel-а има интерфейс, наречен posix_fadvise(), който може да се използва да маркира някаква част от кеша като “няма да ми трябва повече” (които kernel-а да разкара). Това можеше да се използва с LD_PRELOAD за read()-ове, като просто се маркираше прочетеното като POSIX_FADV_DONTNEED. Идеята я имаше донякъде реализирана в https://code.google.com/archive/p/pagecache-mangagement/ и тръгнах да я дописвам да прави нещо по-просто (просто posix_fadvise() веднага след read, вместо сложни сметки с колко кеш да се позволява на процес).

Някъде в тоя момент CTO-то ни попита “а то всъщност трябва ли да се вика posix_fadvise() от процеса, или може от всякъде”? Оказа се, че в същото repo има прост инструмент, който изхвърля от кеша данните за даден файл (или блоково устройство), наречен “fadv” (който открих след като написах същите 5 реда).

Крайният резултат беше малък скрипт, който пуска “fadv” за всички наши устройства и ги държи извън кеша, което се каза приемлив workaround. Оказа се и доста бърз – на първото си стартиране му отне около минута да изхвърли около 100GB от кеша, на следващите си пускания минаваше за под секунда.

(обмислям лекция за OpenFest по темата разни инструменти за debug-ване, които съм открил в последно време, звучи ли интересно на някого?)

Тия дни около една лекция на hack conf за scale-ването на приложения, разговори с разни хора за архитектура на системи и дебъгването на някакви готови неща почна да ми се мотае следния въпрос: наистина ли базите данни са толкова бавни и защо?

Въпросът идва от идеята, че единият начин да си спестиш натоварването в пиковите моменти на базата е да буферираш в някаква опашка (напр. Apache Kafka) заявките, така че да може да наваксаш в някакви по-тихи периоди. Това го чух и като идея изобщо за влизащите заявки в системата, без значение дали са batch заявки или такива директно от потребители.

За да не се губят данни, тази опашка трябва да persist-ва данните, т.е. реално да представлява един transaction log, който да се пише на диска преди да се отговори на клиента, че данните са получени. За да се приемат тези данни, вероятно е нужна и малко валидация, да се види дали са “приемливи”/отговарят на constraint-ите на системата.

… което е точно каквото прави всъщност базата данни. По това, което съм виждал (и чел в “Transaction processing”, което май все още е книгата “как се пише база данни”), базата прави точно това – проверява няколко неща и пише транзакцията в лога. Промяната на реалните данни се случва на batch-ове, като се затвори текущия сегмент от transaction log-а, така че писането в базата би трябвало да е бая бърза операция. Четенето се случва от кеш или от реалните данни, така че ако transaction log-а не е на същия хардуер, като цяло няма обективна причина опашката да помага, реално е вършене на същата работа още веднъж.

Та явно базите данни са по-бавни, отколкото би трябвало. Някой да има наблюдения по темата?

След дълго гласуване, Европейската комисия ще предложи да се разкара DST (daylight savings time), смяната на времето, вероятно от 2019. Което е прекрасно и вярна стъпка по пътя всички да сме по UC и да не се занимаваме с глупости.

По случая някакви хора се оплакват, че трябва да се променя някакво количество код, за да се вземе предвид тази промяна. Което е тотална идиотщина, понеже за който не знае, timezone файла/базата се променя ПОСТОЯННО, най-лесно може да се види от архива на tz-announce листата на IANA, където се казват новите release-и, или github repo-то на tz базата, където има още по-подробна информация. Само някой, дето не му се е налагало никога да се занимава с time zone-и може да си мисли, че те са нещо супер статично и ясно, и че махането на европейското DST е някаква сериозна и “опасна” промяна.

(или който не е виждал как даже debian пъхат тоя update във всеки minor release, въпреки че не е свързан със security)

Та, има още стъпки по темата, но махането на европейското DST, и в един момент – единна европейска времева зона, биха били добро начало да проимаме някаква свястно и глобално използваемо време.

Както някои хора знаят, вече имаме закон, който казва “каквото се пише за държавата, трябва да е open source и version control-а му да е публичен”. Също така, в момента порталът за отворени данни се пренаписва в две части, и след някакво ходене по мъките едната е публикувана в github, където хората могат да review-ват кода и да дават идеи.

Днес борихме забавен проблем от типа “може да се дава за пример как се дебъгва нещо, което не разбираш”.

Оригиналното оплакване беше “защо ми е толкова висок пинга до тия машини”. Проследихме го до router-а им, едно FreeBSD (скоро update-вано), което върши разни вътрешни поддържащи дейности и е router за един набор тестова железария.
(аз, ако някой не знае, от FreeBSD не разбирам и конкретно на тая машина съм и се заканил да я преинсталирам с Debian, ама ме спират)

Проблемът беше доста на random и за различни хора. Основното нещо, което се забелязваше в top беше, че 25% от процесорното време отиват в "interrupt", което в общи линии значеше един от 4те core-а на процесора (машината няма hyper-threading). Понеже ми се искаше да имам някаква по-свястна видимост, реших така и така да тествам prometheus при нас, съответно update-нах port-овете на машината (оказва се, че node_exporter-а на prometheus вече го има там), сипах една виртуалка в офисния клъстер, сипах един prometheus и го вързах в grafana-та ни.
(все повече и повече обичам секундните статистики, не знам дали съм го казвал)

Проблемът с 25-те процента в interrupt си се виждаше много хубаво на графиките, и не корелираше с мрежов трафик или каквото и да е. След като си задавах въпроса “какъв е еквивалента на perf top във FreeBSD” открих един много полезен сайт с DTrace примери и по-специално hotkernel програмчето, което можеше да ми каже за даден период от време къде е висял kernel-а. Оказа се, че освен двете idle функции, основно се стои в vm_page_scan_contig(), т.е. някой усилено се опитваше да си заделя последователна памет. Нямаше някъде информация за някакъв известен такъв бъг (и се надявам google да индексира това за следващия, който търси).

Някъде в този момент се оказа, че backup-ите ни, които ходят до тази машина през един NFS вървят доста бавно – сетихме се от мрежовия проблем. В един момент колегата каза “абе, я да видим ако спрем писането им за малко дали нещо ще се промени” и изведнъж проблемът изчезна. Последва въпросът “това от NFS-а ли е, или от ZFS-а отдолу?”, което лесно се тества с едно копиране отвън, и се оказа, че този път (за разлика от доста други) NFS-ът е невинен.

Та, оказахме се с проблем, че като се опитваме да пишем по ZFS-а, той се опитва да си заделя памет, това го бави много и всичко върви зле, а докато kernel-а му търси памет, всичко, дето се опитва да се schedule-не на тоя процесор (като например прекъсванията на една от опашките на мрежовата карта) страда.

Ровихме разни неща по ZFS-а, и в един момент около размислите по паметта видяхме, че от 16GB памет 14GB се води "wired", т.е. заета от kernel-а за някакви неща, в случая изглеждаше да е за ARC кеша на ZFS. Решихме да я намалим, като и пипнахме vfs.zfs.arc_max на 10GB, което обаче нямаше ефект. С малко ровене открихме, че “то няма начин да се чисти кеша, но ако някое приложение си поиска памет, ще се flush-не”, съответно докато си извадя C програмката, дето яде памет, колегата драсна следното:


python -c 'a="b"*1024**4'


(което реално се опитва да изяде 1TB памет, та трябваше да го утрепем в един момент)

Съответно в момента, в който се появи някаква свободна памет, проблемът спря да се появява. Накратко казано, default-ната стойност за количество кеш на ZFS-а е толкова висока, че изяжда цялата памет, и прави всичките му нужни memory allocation-и много бавни, което потрошава цялата производителност. Вероятно това е някаква скорошна промяна, та се чудим дали/къде да го report-ваме.

Update: Разбира се, някой трябва да чете документация – sysctl-то трябва да отиде в loader.conf, преди да се пали root-а и т.н., понеже ZFS-а тия неща ги поглежда само докато си пуска pool-а и после не ни обръща внимание. С един reboot нещата се оправиха…

Това иначе никога няма да го кача, та ето го като dump от оригналния документ, ако някой му се занимава да го преведе до смислен html да каже да му дам link към оригинала.

OpenFest 2017 network write-up

Стандартното празнуване на деня на системния администратор – следващия петък (27ми юли), в “Кривото” на ъгъла на “Дондуков” и “Будапеща”.

Update: бях отворил единична кавичка и затворил двойна, което беше строшило вида на целия блог…

Тия дни прочетох “Proofs and Refutations” на Имре Лакатош (Imre Lakatos), унгарски математик и математически философ.

Книгата ми хареса много, понеже ми показа процесът на развиване на една теорема и доказателствата ѝ, пътят по който се е стигнало до нея (или терминът може би е ориентираното дърво, не точно път, понеже има и доста от задънените улици). За разлика от повечето ми учебници по математика, книгата ми дава идея защо дадено доказателство се развива по този начин, защо са избрани тези дефиниционни множества и други начални моменти, и въпреки формалното обяснение да покаже практическото/разбираемо такова.
(един учебник с толкова информация вероятно щеше да е около 5 пъти по-дебел, но щях да го чета с удоволствие)

Като погледна назад към коя математика ми е останала в главата и коя не, разделителят в общи линии изглежда като да съм си отговорил на въпроса “защо” (я има|се ползва), понякога и “защото е тривиална”. Голяма част от останалото е отказало да ми се лепне в главата, и понякога ми се е налагало по-късно да се ровя в него и да се опитвам да разбера, когато ми е трябвало (и когато много често съм се спирал на изцяло приложната му страна, без да задълбавам (полета на Галоа) , или просто да придобия бегла представа (решетки, които още не мога да докарам до някакво интуитивно ниво)).

Остават разни интересни въпроси:

– Грешно ли се преподава математика? Явно не съвсем, при условие, че една прилична част все пак съм я научил (и ако трябва, мога да си изведа формулата за решение на квадратно уравнение, например). Дали може да се подобри по смислен начин?
– Ако хората имат нужда от повествование (narrative, разказ), за да запомнят/схванат нещо, това дали не е бъг в главите ни, който трябва да оправим, или нещо, от което трябва да се възползваме?
– Някой да знае учебници, които обясняват по този начин различни математики? Не говоря за безумно глупавите от типа на “head first statistics”, а някакви, които могат да опишат процесът на извеждане на текущата теория, причините за това и по какво се работи в момента, може би комбинация от математика и история (без премълчаванията, за които Лакатос пише)?

Интересно също кои са наследниците на Лакатош. Карл Попът му е предшественик, но да речем, че неговите идеи достатъчно са се просмукали в каквото друго съм чел, и ми е интересно какво ново (и смислено) има в областта в последните 50-тина години…

p.s. ако някой знае къде има книгата на Лакатош на български, да ми пише, има някакви хора, на които искам да я дам и които няма как да я четат в оригинал.

Тия дни ми се случи да напиша две малки парчета код, които да ми решат някакъв проблем.

Първото е sproxy – малък демон, който чете на stdin, пълни един цикличен буфер и го дава на всеки, който се закачи за него. Използвам го, за да заместя multicast-а във FOSDEM-ските videobox-ове – видео потокът от encoder-а в кутията се налива в sproxy-то и си тече, и консуматорите (локалния recorder, voctomix-а, разни дебъгващи хора) могат да се свържат до него и да си дърпат видеото. Сумарно стана около 120 реда код на C – кратко, изчистено и доста просто.
Остана да му допиша още един порт, на който като се върже клиент, получава бързо всичко, което е в буфера (в момента който се свърже, получава всичко ново), за малкия tool по кутиите, който взима текущия кадър от видеото да го покаже на дисплея.
(писах го няколко часа и го дебъгвах още толкова)

А по време на първите лекции на БургасConf си сглобих нещо малко ffmpeg с ebur128 филтъра, малко питонски код, InfluxDB и Grafana, което в сравнително реално време да ми чертае нивото на звука от stream-а (примерен изглед). Цялата работа опря до един ffmpeg команден ред, един regex и една функция, която сипва данните в influx-а.
(в grafana-та има и един “километраж”, което е може би най-безсмисления тип визуализация, сложих го като демонстрация. Понеже не се оправя с отрицателни стойности, нещата, дето показва са +70db)
Нещото се оказа толкова лесно и удобно, че даже го показах в един lightning talk на БургасConf. С още малко доработка мисля да влезе в monitoring-а на FOSDEM и разните други конференции, които правим. Ще го кача след доработката, че сега никак не ме радва как работи и как няма буфериране, ако базата почне да се бави.

Такива неща са пример колко полезно и важно е човек да може да пише поне малко, понеже с малко код и съществуващия софтуер човек може да постигне интересни неща. Ето за това не мога да смятам системен администратор, който не може да пише за истински такъв. Чудя се мога ли да измисля някакъв курс за писане на дребни хакове :)

Днес се проведе първата Национална конференция на “Да България”.

Обичам заниманията с неща, които други не са правили. Днес това беше реализираното електронно гласуване за всичките точки от дневния ред, което изглежда е първото такова нещо, правено в България, като малка демонстрация, че е нещо, което всъщност може да работи. В рамките на няколко часа бяха направени 45 гласувания, едно от които с интегрална бюлетина. От наблюденията ми на подобни неща (например на учредяването на партията), дори с перфектна организация и много преброители няма как едно гласуване да е под 10 минути, а тук се справяхме за 2-3. Цялата технология беше разработена от няколко човека (от приложението до backend-а) и издържа съвсем спокойно на цялото натоварване без на сървъра да му мигне окото.

В периода, в който вървеше live stream нямаше гласувания, но се надявам в някой момент да можем да публикуваме запис от протичането на едно примерно гласуване – режисьорската работа какво кога къде да показвам на моменти ми идваше много, особено при темповете, с които работехме към края, когато всички вече бяха свикнали със задачите си.

Не беше най-уморителното събитие, в което съм участвал (OpenFest и FOSDEM определено са по-страшни, а gaming турнира в рамките на Animes Expo беше в порядъци по-неприятен), но определено ще имам нужда да си почина малко.

Днес е Take Action Day за чл. 13 по новата директива по темата авторски права и Internet, за която писах и преди.

Сайтове по темата – saveourinternet.eu, FB страница, twitter.

Писнало ми е да обяснявам на някакви хора, че не трябва и не може да се цензурира internet-а, но явно трябва да се повтаря от време на време.

Не мога да си обясня как БДЖ не са фалирали.

Преди месец и нещо ходих към Бургас, където бяха Елена и звяра, и понеже тя се притесняваше от многото катастрофи по онова време по Тракия, ме помоли да си взема влака. Той пътува около 6 часа, и беше идеално време за четене.

Самият влак беше приятен и доста удобен, но интересното беше с билетите – първото ми откритие беше, че за online продажба има сумарно 12 билета. После, на гарата казваха “за тоя влак местата свършиха”, а влакът определено не беше пълен, нито се напълни. Изводът, до който стигнах с малко гледане е, че хората нямат online сисема, а всяка гара по пътя има раздаден набор от места и тя може да си ги продаде до където реши, но не могат да се използват от някоя гара, където има по-голямо търсене, т.е. те ВСЕ ОЩЕ нямат online система за резервиране/продаване на места.
(нещата са толкова объркани, че наскоро се оказа, че от касите в София (щото online местата вече бяха свършили) човек не може да си вземе и билет за обратната посока)

Това ми е супер учуващо, понеже технологията за тия неща я има почти от времената, в които бях малък (една централна база данни и някакъв приличен хардуер). Комуникацията те си я имат по принцип – БДЖ още от едни много отдавнашни времена имаше паралелна комуникационна мрежа и не мисля, че навръзването на всички гари към централната система ще е особен проблем, просто защото те и сега имат някаква връзка, иначе нямаше да могат да си управляват влаковете.

Също ми е учудващо, че откакто има системата за online купуване на билети, в нея има още 1-2 нови маршрута (в сравнение с момента, в който я пуснаха), а не цялата им мрежа. Може би някой трябва да ги довлачи в текущия век?