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

(чак сега успявам да пиша)

Преди няколко седмици организирахме посещение на ученици от НПМГ в лаба – един техен учител (Теодор Катранджиев) се свърза с нас и пита дали може да но посетят и да видят какво правим.

Дойдоха в лаба, показахме им различните неща, които имаме и правим, обясних неформалния характер на мястото, и ги позабавлявахме с разните странни неща, които имаме – разказах им за системата за отваряне на вратата и контрол на лампите, показах им едно софтуерно радио, и един стар MFM-RLL харддиск (питаха ме колко е голям, казах – 10 или 20, и Теодор ми напомни да спомена, че това са мегабайти).

После отделихме едно прилично количество време да ни задават въпроси – в лаба бяха хората от camplight и те доста помогнаха. Имаше въпроси по темата работа, къде да учат след училище и всякакви такива неща (където обяснявах, че в България ФМИ на СУ е най-малко зле). Разказахме им за всякакви хакатони, за различни компании, които си търсят хора и всякакви такива неща, и се надявам че им бяхме полезни.

(и тия дни като обявим официално call for volunteers за openfest, ще им го пратим и на тях)

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

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

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

Първо сутринта отидох до ТУЕС, където имаше ТУЕСФест – интересната част беше, че навсякъде по стаите и коридорите ученици бяха изложили проекти, които бяха направили. Имаше толкова забавни неща, че ме хвана детска радост:
– машина за организиране на drinking game;
– група осмокласници бяха изкормили и mod-нали кафе машина, така че да могат да я командват гласово;
– имаше няколко security-ориентирани дипломни работи – IDS, reverse VPN, нещо, дето атакува wireless мрежи;
– излъчвател на DCF77;
– софтуерно радио – човекът с един RTL2832U си беше направил вузиализация на ефира и възможност за слушане на FM радио;
– минималистичен компютър от breadboard-ове и интегрални схеми, който наближаваше turing-complete машина;
… и някакви други, дето не съм запомнил, ТУЕС ще направят едно добро дело като публикуват списъка.

Следобеда отидох на Uber Open Source Summit в CityStage, където ме бяха поканили да участвам в панел на тема “Contributing to Open Source”. Дискусията се надявам да е била полезна на присъстващите, ще видя като излезе записът какви глупости съм говорил. Самото събитие беше приятно и се намериха доста хора, с които да си поговорим, та с удоволствие бих отишъл пак на нещо подобно. Като цяло имах очакването, че като събитие, организирано от голяма компания няма да ми е особено интересно/приятно, но тук се бяха справили и нямаше разните дразнещи спамерски моменти, които съм виждал на други места.

Update: Списък с проектите от ТуесФест.

(предхождащи post-ове по темата: FizzBuzz, FizzBuzz 2)
Задачката продължава да води до интересни идеи, та ще публикувам някои от тях.

В последно време търсим java програмист, та в едно от решенията имаше следното:

try {
	errorNumber=  1/(tmpNum%15);
} catch (ArithmeticException ae) {
	return "AB";
} 

Това за мен беше съвсем неизвестен начин да се напише if() :) Ползването на exception-и е страшно неефективно (поне под Linux генерира SIGFPE, т.е. ще мине за малко и през kernel-а), но е още един начин да се промени пътя на кода.

Също така, в езиците, в които няма goto цикълът може да се реализире с рекурсия, като функцията, в която се влиза се избира от масив (идеята дойде на Slackware, който написа реализация на php), и изглежда горе-долу по следния начин:

function printto99($i) {
	global $funcs;
	....
	$funcs[$i % 100]($i+1);
}
function print100($i) {
	global $funcs;
	....
	return;
}

$funcs = array(0 => printto99(), 1 => print100());

$funcs[0](1);

В …. частта се слага логиката какво да се печата, което ме мързи да разписвам пак.

В Java тази конкретна идиотщина може да се реализира, като вместо масив от функции се направи масив от обекти с общ родител, който има два наследника – printto99 и print100 и така да се направи цикъла.

Ясен Василев Колев, 51cm, 3800g, роден в 01:17 тая нощ.

Елена приспиваше звяра, в един момент чух рев, и я видях я да излиза от стаята с думите “доприспи го, изтекоха ми водите”. Всичко е минало лесно и сравнително бързо, сега като ходих да ги видя и на двамата много им се спеше. Прибирам си ги вероятно във вторник.

Обещавам да си чета от време на време mail-а, ако трябвам на някого.

Продължавам да се връщам в цивилизацията.

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

Като страничен ефект, това не доведе до никакви болки, т.е. явно операцията има ефект. От снощи съм почнал внимателно да намалявам дрогата, да видим.

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

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

И следболнично (трябваше да е вчера).

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

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

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

Дадоха ми и болничен. Той е 5 дни за в болницата и 30 (ТРИДЕСЕТ) дни вкъщи. Предния път на 10тия ден аз обикалях като идиот, не знам защо това е стандарта, особено за човек на моята възраст.

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

Нямам бъдещи планове за следващите няколко дни, освен да дремя и да ми се намества главата, после ще видим. Искрено ми се иска да мога да се върна малко на работа, преди Елена да роди и пак да съм неадекватен :)

Васил е в реанимация. Докторите са успели да пробият и да ремонтират главата му успешно. Сега чакаме да спре да халюцинира.

Кратки новини: операцията преди мен се проточи, та съм за утре, първа операция. Излежавам се с пълна сила.

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

Станах в 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-ват кода и да дават идеи.