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

All this comes from our work on getting a stable and redundant link for servers without resorting to things like routing protocols, and is the product of some years of “research” (hitting the next problem and solving it).

The Linux kernel has a (deceptively simple) mechanism for “bonding” two interfaces as one, to use for load-balancing and fail-over. It is really well documented in https://www.kernel.org/doc/Documentation/networking/bonding.txt and if some of my explanations are lacking, that’s the proper document to look into.

There are all kinds of modes, but there are two that make sense in Ethernet networks – active-backup and 802.1ad. 802.1ad requires support from the switch side, and for proper redundancy when you’re connecting to two switches to have them stacked or clustered. Stacked switches crash together, clustered also, but a bit less. So, for proper redundancy you’d like to have the two switches you connect to as independent as possible, which rules out 802.1ad.
(802.1ad is also known as LACP, link aggregation control protocol. When connecting to two different switches, it’s known as MLAG, multi-chassis link aggregation.)

For the sake of illustration, let’s say we have a network with two switches (SW1 and SW2) and two hosts, A and B. A is connected to SW1 and SW2, so is B.

By default the active-backup bond just monitors the state of the link (“miimon”). This should work in a better world, where switches are supposed to die completely when they can’t forward packets, but that’s not the case in the real world. Even without the “fun” failure modes where a switch stops forwarding without killing the links, there’s also the option that someone mis-configures a VLAN and blackholes the traffic you care about. As miimon can’t detect any such issues and fail-over to the other interfaces, it’s not very useful in Ethernet networks.

There is another option, something called “ARP monitor” – the bond sends ARP requests to a set of pre-configured targets and listens for the replies, if the replies stop, the interface is deemed dead and failed-over. This is a step in the right direction.

To have this properly configured, you need to have more than one target (so the death of that one target does not make the node think it has no connectivity), and to configure it for any node in the targets to be reachable to make the link active (the arp_all_targets option). All these are somewhat obvious and easy to set up, together with the preferred arp_interval to know how often to send packets.

And all this would’ve been fine if not for the weird default behavior of the Linux bonding to take any received ARP traffic as an indication that the link is OK. So if you get disconnected from the targets, but there are some other hosts in the partition created on that “side” of the network, you’ll never switch to the other interface, never mind that you can’t reach the targets via the current active interface.

The next option is called “arp_validate”. It tells the bond to actually look in the received ARP traffic if it’s from the targets (well, almost, but we’ll get to that). It can be told to look to “validate” no interface, the active one, or both. I have no idea why the validation is not “on” by default, and I haven’t dug in the history enough to check, but I’m guessing it’s something related to the weak host model and the issues I’ve had with ARP.

“arp_validate=active” takes care of checking what’s received on the currently active interface, so it should resolve most issues. However, it doesn’t help when the backup interface is not correctly connected and receives some ARP traffic, and it’s not possible to check /proc/net/bonding/bondX and know if it’s safe to switch the active interface for some reason (so you switch, and hopefully bounce back pretty quickly). To allow for monitoring the state of the backup interface, you should use “arp_validate=all”.

Which would be great if that worked. This part took me some reading of the sources to get right, see this part of bond_arp_rcv() in drivers/net/bonding/bond_main.c, especially the three calls to bond_validate_arp() on lines 3284, 3288 and 3290. Is there something weird there?

That’s correct, in the check on line 3288 the “tip” and “sip” arguments (source and destination) are swapped. A closer reading of the documentation and the source shows that if you validate the traffic to the backup interface, the ONLY traffic that will make this interface “up” is our own broadcast traffic send to the targets, not for example broadcasts received from the targets themselves (which I expected to be the case). I’m thinking about submitting a patch to the documentation in that regard.

So, in general this should work, but we had a lot of cases where the backup interface refused to hear the broadcasts sent via the active interface. After some time we were able to trace these cases to two specific NIC drivers – i40e and ice, both Intel NICs.

Small bit of theory before explaining what the issue was – the Linux bond sets the same MAC address on all Ethernet interfaces in the same bond.

And, there’s this small option called source pruning, which roughly translates to “drop all received packets that have my MAC address as source”. Which might make sense in some situations, but definitely not in a bond with “arp_validate=all”. So, for i40e this is just an ethtool option, but for ice NICs this looks to be hardcoded, and I’ve opened an issue for this to be configurable, so hopefully in some years it’ll get fixed.

postscript 1:

bpftrace is a wonderful tool that helped a lot to attach to the bond_arp_rcv() and other functions and see what’s going on. For any issue which strace can’t see (like “something returns EINVAL and you have no idea why), this looks to be the next step.

postscript 2:

I noted that two bonding mechanisms make sense in Ethernet network. There are some more modes, which are either “broadcast” (send all packets via all links) or “balance the traffic based on a function”. Both these types of modes will weird out the switches, because they’ll see traffic from the same MAC address coming from two different places and would constantly be updating their tables where these MACs are, with very fun consequences.

These modes made a lot more sense for serial links back in the days, adding two SLIP or PPP links to a bond with the default mode (balance with round-robin) was the cheapest way to get twice the bandwidth without any extra complexity.

The most resilient (but hardest to implement and more complex) solution for anything like this would be full-mesh BFD and BGP, which would make sure you only use paths that you can communicate on (doesn’t help with MTU blackholes, but pretty much nothing does). I’ve never seen it done, though :)

The zero edition of ConfConf passed (a month ago).

For several years we have been talking to the people from FOSDEM that it would be nice to have some kind of gathering/conference for people who, like us, organize open-source and similar conferences. Some time ago, the same idea was for an event only for video-streaming/recording (with the working title “vocconf”), but we got nowhere.

So this year, after we had FOSDEM and went to the FOSSASIA summit in Bangkok, we decided to move things forward. We decided to call it ConfConf, we made a simple website, and started inviting people. Our idea was for it to be invite-only, a small un-conference somewhere relatively cheap and central, so that we could get by with a minimal budget. Sofia turned out to be a suitable place – we managed to reserve the conference rooms at the Hemus Hotel, half of the visitors stayed there, and so the 40 or so people who gathered were together almost the entire time.

People came from Sweden, Belgium, the Netherlands, France, Germany, Serbia, Bulgaria, Vietnam, South Korea and Taiwan (we should write somewhere on the website which events they attended).

There was some concern that people wouldn’t want to talk, would be shy, etc. It turned out to be completely unfounded – this is a topic that most organizers have no one to talk to, and very shy people don’t organize conferences (and don’t go to conferences to organize them). I don’t think we stopped talking for two and a half days, during the event, at breakfast, dinner, lunch or even on the way somewhere. My head can’t digest all the conversations yet, but we have notes from all the sessions and we will organize them somewhere.

We started a bit chaotically, our wiki-type software broke (hedgedoc is cool, but definitely not for 20 people writing on the same page at the same time), so we switched to flipcharts, but in the end, with people who are always organizing things, we didn’t encounter anything that could stop us. We did a number of group sessions, some with everyone present, and somewhere we have a recording of the opening and closing, which might be good for publication.

(Organizationally, the event was made to be simple, on purpose – so that even the organizers could participate, and not think about the details of the organization. We had rented the conference rooms of the Hemus Hotel, had lunch there, had reserved tables for dinner at the hotel (for Friday), at CoKitchen and at Kolovoz 41, and basically that was almost everything. There was no planning of streaming and recording, no preparation of a program, or anything else time-consuming)

I can safely say that these were about 40 of the coolest people I have ever met. No matter where they were from, they were interesting conversationalists, they did interesting things and had something to tell.

After some rest, we will plan the next one – there are talks about whether it could be somewhere in Asia, or some other more central place that more people can easily reach (if a local team is found in Istanbul, for example, it would be interesting). Who knows, maybe it’ll be in Vietnam…

The whole event also gave me an interesting perspective. In Bulgaria and in a decent part of Europe in general, many of these events were started at by infrastructure people (mainly system administrators), as the main ones in need of such software and with the desire to get involved in getting it up and running and adding to it. This doesn’t seem to have been the case in most of Asia – there, infrastructure people seem to be only at large telecoms, where problems were solved with a lot of money, buying software or some big development department. There was no idea of a neighborhood ISP, someone to roll out servers/forums and other such things.
(I’m still collecting and reading literature on the history of the Internet in Asia, something else may pop up)

Another interesting thing about my explanations about how a decent part of the event organization and all the things like videobox were done in our free time was “in India people don’t have free time”. I’ve noticed this in countries with various clients and what time they write to us – I work for a company of workaholics, and we still don’t write over such a wide range of hours as some people in India. For South Korea it was “people have jobs and hobbies, but they do both putting in their all”, so it might be better there :)

Мина нулевото издание на ConfConf (преди месец).

От няколко години си говорим с хората от FOSDEM, че би било хубаво да има някаква сбирка/конференция за хората, които като нас организират open-source и подобни конференции. Преди време същата идея беше за събитие само за videostreaming/recording (с работното заглавие vocconf), но там не стигнахме до никъде.

За това в крайна сметка тази година, след като случихме FOSDEM и ходихме на FOSSASIA summit-а в Банкок, решихме да придвижим нещата. Решихме да се казва confconf, направихме един прост сайт, и започнахме да каним хора. Идеята ни беше да е invite-only, малка un-конференция някъде на сравнително евтино и централно място, за да можем да минем с минимален бюджет. София се оказа подходящо място – успяхме да запазим залите в хотел Хемус, половината посетители и отседнаха там, и така 40-тината човека, които се събрахме бяхме заедно през почти цялото време.

Дойдоха хора от Швеция, Белгия, Холандия, Франция, Германия, Сърбия, България, Виетнам, Южна Корея и Тайван (някъде на сайта би трябвало да напишем кои събития присъстваха).

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

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

(Организационно, събитието беше направено да е просто, съвсем целенасочено – така дори организаторите да могат основно да участват, а не да мислят подробности около организацията. Бяхме наели залите на хотел “Хемус”, обядвахме там, запазили бяхме маси за вечеря в хотела (за петък), в CoKitchen и в Коловоз 41, и в общи линии това беше почти всичко. Нямаше планиране на streaming и recording, нямаше събиране на програма, или каквото и да е друго много времеемко)

Спокойно мога да кажа, че това бяха 40тина от най-готините хора, с които съм се срещал. Без значение откъде бяха, бяха интересни събеседници, правеха интересни неща и имаха какво да разкажат.

Като си починем, ще планираме следващото такова – има разговори дали да не е някъде в Азия, или някое друго по-централно място, до което повече хора да могат лесно да стигнат (ако се намери локален екип в Истанбул например, ще е интересно). Кой знае, може па да е във Виетнам…

Цялото събитие също така ми даде интересна перспектива. В България и изобщо в прилична част на Европа много от тези събития бяха започнати едно време от инфраструктурни хора (основно системни администратори), като основни нуждаещи се от подобен софтуер и с желанието да се занимаваме да го подкараме и допишем. Това не изглежда да е бил случая в по-голяма част от Азия – там инфраструктурните хора изглежда да са само по големи телекоми, където проблемите са се решавали с много пари, купуване на софтуер или някакъв голям отдел за разработки. Нямало е идеята за квартален доставчик, някой да търкаля сървъри/форуми и други такива неща.
(още събирам и чета литература за история на интернета в Азия, може да изскочи още нещо)

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

Такъв post не съм писал от 10 години.

Снощи в клуб/кино “Кабана” (едно нещо на открито до НДК) Kultur Shock направиха “таен” концерт, т.е. такъв, който обявили от сцената в Пловдив преди два дни (и питали дали има кой да ги закара до София :) ).

Мястото е сравнително малко и се напълни добре, беше доста плътно пред сцената. А самите Kultur Shock свириха както правят по принцип – без паузи между песните, с много желание и весели както винаги. Обещаха и да дойдат за нещо по-голямо догодина, за 30-годишнината си (и горе-долу 20-годишнина от първия си концерт тук), по някое време през април.

Не съм сигурен доколко са ми липсвали концертите, но гледайки ефекта, спокойно мога да кажа, че са по-евтини от антидепресантите :)

p.s. имам още 2-3 полунаписани неща, които тряба да пусна в близките дни.

(опитвам се да пиша по-често, но нямам особено добри теми)

Нещата около OpenFest се движат – вече има пуснат call for presentations и call for volunteers.

Различното тази година е новият поток за лекции, да го кажем, “не за стари хора”. Лекции, насочени към хора, които сега започват, дето не са насъбрали 15-20 години опит, но искат да навлязат и да научат нови неща. Не изглежда да има нещо, насочено към такива хора (изключая събития, които обясняват как AI-то ще ги остави без работа, в което малоумие не искам да навлизам), а е важно да има такива.
Дори може да се каже, че на практика едно време OpenFest беше това – лекциите бяха много по-уводни, понеже бяха неща, които никой не е виждал.

(за CfP използваме Pretalx, което изглежда ползват всички, включително CCC и FOSDEM. В системата има всичко, дето ни трябва, можем да си я хостнем сами, и ни отне (с невероятната помощ от Сашо Шопов) две-три седмици да и направим превод на български).

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

Системите за гласуване са криво нещо. Не стига, че има теорема на Arrow, ами и доста неща не са съвсем очевидни.

Да речем, че имате 4ма кандидати и трябва да изберете 2ма от тях. Някои опции са:
– По един глас от всеки гласуващ за 1 кандидат;
– По един глас от всеки гласуващ за възможна двойка кандидати;
– По един глас от всеки гласуващ за 2ма кандидати;
– Condorcet и взимане на първите двама.

Във хода на обсъждането някой каза за първите два варианта, че са еквивалентни като резултат. Стори ми се грешно, но нямах времето да си го разписвам, а и за конкретния случай нямаше да промени крайния резултат. Но контра-примерът е съвсем прост:

Кандидатите са ни A, B, C, D;
Взимаме N човека, които предпочитат кандидатите в ред (A, B, C, D) и M човека, които предпочитат (C, D, B, A). На първия метод първия вид хора ни дават N на брой A и M на брой C, а вторият ни дава N на брой (A, B) и M на брой (C,D), та при всяко N > M имаме съвсем различен резултат.
(и това дори не е особено патологичен случай на разпределение на предпочитания)

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

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

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

В дискусиите после имаше няколко човека, които споменаха римския триумвират и колко много не е проработил (толкова се повтаряше, че когато Христо Иванов се изказа, изрично каза, че не е строил Римската империя), а в един момент някой даде пример с триумвирата след смъртта на Сталин, как понеже него не е можел един човек да го замести били трима. Добре, че се усети да каже “Не сравнявам Христо със Сталин”…

И целия разговор ме върна 10 години в миналото, когато променяхме неща по устава на Фондация “Отворени проекти” и исках да направя така, че трима човека да можем да представляваме фондацията. Тогава имаше съпротива от някои хора, че “трябва един да носи отговорност” и други подобни доводи, които чух и сега на събранието.
В крайна сметка го направихме, и сработи страхотно – в годините, в които аз, Яна и Мариян се занимавахме, и тримата можехме да представляваме фондацията и да движим нещата. При добре сработен екип това се получава доста добре, а даже по законите на Паркинсън трима човека е доста добро число за управляващ орган…
(съдът всъщност отказа частта с представителството на тримата и го направихме с пълномощни)

От друга страна, в нашата държава все още има идеята, че има там един отгоре, дето казва какво става, и ще дойде, и ще ни оправи. Надявам се да го надрастнем някой ден.

Тази година StorPool бяхме спонсор на HackTues 11, и едно от нещата, които търсеха от нас, бяха ментори или членове на журито. Аз предпочетох да съм ментор, и се уговорих да си работя от там за двата дни на хакатона (четвъртък и петък).

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

По правилата тази година, отборите си избираха менторите. Мен ме избра екип W-BT. Според тях основно заради python-а, който бях написал, че знам, според neter, понеже проектът им бил свързан със стари хора и им трябвал някакъв такъв.
(чак пък стар, само три пъти по-възрастен съм от тях)

Бяха (учудващо, поне за мен) добре организирани – бяха измислили какво точно ще правят още преди да се видя с тях, имаха сравнително добро разпределение на задачите, и дори за да избегнат забраната за всички под 9ти клас да стоят по цяла нощ/спят в залата, бяха си взели едно airbnb наблизо, от което да работят през нощта (което ми се видя като много добър hack).

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

(in other news, чудя се дали има смисъл да направя лекция “debug чрез print”, за нея имам страхотна история, която включва Алан Тюринг и Клод Шанън)

Не знам обаче как работеха всичките в тоя шум. В “Джон Атанасов” бяха наредени маси за всички отбори, бяха им докарали ток, и всички си работеха, но имаше много разговори и около 50-55db фонов шум (според калпавия измерващ app на телефона ми). Аз имах и някаква друга работа и определено ми пречеше, та по средата на хакатона се прежалих и си поръчах свестни слушалки (които ще дойдат съвсем навреме, следващата седмица…). Мисля си, че това беше основната причина да съм толкова уморен събота следобед и да не остана за финалната част, прибрах се и си легнах.

Та след като си направиха последните commit-и в 6:50 сутринта (при 6:59 краен срок), моите хора се явиха пред журито в 10:39. Това не беше най-лошия вариант де, имаше хора пред журито в 08:00, т.е. съвсем да не могат да поспят. Мисля, че бяха едни от най-добре справилите се с тази част, въпреки шума (част от полуфиналите бяха отстрани в “джобовете”, където на OpenFest-а слагаме детския кът и щандове, и нямаше начин да се ограничи шумът), ранния час и средно подлите въпроси от журито.

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

От нещата, които ми направиха неприятно впечатление (както и на колегите) беше начинът на използване на AI нещата и цялостното очакване, че те “знаят” какво правят. Имаше не само “дай chatgpt-то да ни изгенерира еди-какво-си”, но и в самите проекти имаше “и това го подаваме на OpenAI и то ни отговаря” (любимият ми пример беше при един проект, който анализираше извлечения от банкови сметки, как един член на журито пита “Добре, аз ей-сега му дадох един PDF от някакъв курсов проект, и то от него си измисли някакво голямо количество транзакции, това очаквано ли е?”). Мисля, че трябваше да има награда за не-използващи AI, или поне ползващи го по смислен начин.
(фирмената награда я дадохме на отбор, който това го беше направил както трябва)
Изобщо, тоя стохастичен папагал не е достатъчно добре разбран, и се струва магия на всички, както blockchain-а (който беше “тук нещо се случва и ставаш богат”). Чудя се дали мога да намеря някой да го обясни правилно.

Обаче най-важното беше, че всички бая се забавляваха, въпреки че подобно събитие по дефиниция си е напрегнато (и всичкият му график беше твърде оптимистичен, например почти без почивки между представянията за полуфиналите). Настроението се беше пренесло и върху журито – тяхната работа на практика е да се заяждат с участниците, но се усещаше един такъв тон на забавление в цялото нещо.
На финалите в журито имаше един член (който заслужава отделна награда), който изнамираше паролите, които хората бяха commit-нали и влизаше по админските и контролни системи на повечето проекти (един отбор си беше забравил AWS (или GCP?) token-ите в някакви commit-нати файлове и можеше да им се спре всичко). При един от отборите беше питал “Ама тук сте оставили админската парола на keycloak-а (през който минава всичката автентикация на приложението им) в един файл, то така не може ли всеки да влезе да вижда тия неща” и от отбора сравнително бързо успяха да отговорят “Ами то ние сме я сложили там, за да може да я види журито и по-добре да разгледа проекта”.
(5 минути смях в залата и ръкопляскания)

Ако мога да участвам догодина, едно от нещата, които бих направил/помогнал биха били някакви допълнителни workshop-и преди събитието, особено за по-младшите участници, за неща “как да работим по-ефективно” (сега е имало някакви, провеждани от предишни участници, но не мисля, че нещата, дето ми се иска са били засегнати). Това ми беше с доста участници наблюдението, че можеха да си спестят прилично време, ако ползваха alt-tab, разни други клавишни комбинации и като цяло някаква по-ясна организация на работното пространство. Мога даже да цитирам един разговор от при мен,
“Ползвай стрелката нагоре, защо се мъчиш да го пишеш наново”
“Уф, и баща ми все това ми казва”

This is a talk about the video-box that we used to run video on FOSDEM 2025, and that we’re testing, sorry, using, to do video at FOSSASIA 2025 :)

(abstract)

Over the past years, the FOSDEM conference (a free and open-source developer event in Europe) has hacked together its own video recording and streaming setup. We stream 30 rooms with a video team that’s less than 30 people. The latest iteration of that was a lot of fun, and we’d like to share with everyone what it looks like, what it can do and how fun and hackable it is. We will explain our setup, and give a rundown of what’s in those weird boxes you might have seen.

The project is fully open source software and hardware, and everything is available in FOSDEM’s GitHub repos.

If you don’t want to listen to me, but want to see for yourself, everything – the hardware designs, assembly instructions, sources, ansible recipes – are in those two repos. Hack away :)
(there’s even a FOSSASIA branch for the things we had to change for this event)

The initial idea of this talk was to explain how useful this box is to any kind of event, for streaming, recording, etc, etc.. But there’s one more important point that I want to make, after talking to some people here.

THIS IS NOT HARD.

What you can see in this presentation and what we do is the product of a few slightly insane people. We didn’t know that some stuff was hard, and we didn’t care, we just tried to see what will happen. There were problems, there were wrong directions, but as you see, we have it working, and I do think that it’s possible for anyone here to do it.

This is one of the reasons we give the source for it – that people can learn from it, play with it, use it, etc.. It’s possible for people to create any such project – I have seen this again and again and again. I even have a favourite joke about it, I hope it translates well…

The mathematician Dantzig as a student was late for one lecture, came in the lecture room after everyone had left, and saw two mathematical problems written on the blackboard. He thought that those were homework, wrote them down, and went home. On the next day, he was a bit early, went to the professor and said:
“From the homework yesterday, I managed to solve the first one, but I’m having trouble with the second one”
“What homework?”
“The two problems that were written on the board”
“But… but… those were examples of unsolvable problems!”

So, seriously. When you look at the box, you shouldn’t think “wow, what great thing/product”. You should be thinking “I can make one better/I can make it better”.

And to show what we’ve been through (because people see only the end result) – here is an example of a setup for part of the development. It loks scary, feels like it can catch fire if you touch anything, and is so far from what you see in the box.

And this is a temporary version of the power board. I am not sure if you can see it very well, and I’m not sure you would want to see this horrible contraption. You should not be afraid to make things like this and experiment. Yes, it takes time, yes, it sometimes catches fire, but when that happens you just put out the fire and think of a new way forward. In the end it works!:)

Seriously. Experiment and do stupid things. This is how people learn.

(I’ve heard that there are some really smart people that learn from other people’s mistakes, but at least I need to make my own:) )

To explain where all this comes from, a few short words about FOSDEM – it’s the largest open-source event in Europe. It gathers some thousands of people in a cold, windy and rainy place with good beer to present and discuss all kinds of open-source projects. It’s a bit crazy, with 30 parallel tracks and more than a thousand talks.

And I’m really happy to be a part of it. It’s one of the things that I participate in that no other group does, and that’s mostly because nobody is crazy enough :)

So, large event, large venue (multiple buildings), only half a day for the setup. We have next to no manpower and no time :) . We want to have working video, because there are a lot of lazy people around the world that don’t feel like traveling to FOSDEM, and rooms are often so full that people sit outside and watch the streams.

And, FOSDEM is a completely open and free event, we can’t just throw money at the problem and have a setup that would cost a few million dollars.

This is the overall architecture of the video at FOSDEM. We capture the camera and the presenter’s slides, they get sent to a video mixer, which mostly creates a picture-in-picture stream. That stream gets sent to the outside world to see, and gets recorded so it can be reviewed later.

A few things in this setup we didn’t finish for this year, like audio transport over the network (which would’ve saved us one long cable per room), but there’s always next year :)

This setup scales really well – we’ve done FOSDEM with between 20 and 30 rooms, and are pretty confident it would scale to a hundred or more. We manage to set the up in half day with 7-8 teams with 3 people each, and to tear it down after the event in three hours.

Not having too many people, we prioritize the ease of setup and operation. We’re also lazy :)

And such an event requires a tremendous amount of computing power to mix the video…

… just kidding. 10-year old laptops can deal with that without any issues :) You can also see them here in the racks (Ikea wine racks). These machines run software called “voctomix”, developed in Python by c3voc and which does some magic with gstreamer.

Remember the slide with “this is not hard”?

To show how much code we’ve written to run all that infrastructure above, I ran the tool that counts lines of code, and when I removed one external javascript library, this is what’s left. With 1500 lines of code you can run the video of one of the largest conferences there is.

There’s a bit more code in the firmware for the hardware and few other external things, but the above is enough for almost everything.

For 7-8 years we used this, but it was getting old (and some of the wood a bit moldy). It was a combination of a Banana PI, sata SSD, small switch, one BMD recorder (device that captures HDMI and gives it over USB), and for half of the boxes, a scaler – something that you can plug any laptop in and it’ll be able to change the signal to something that we can use.

The last part is always a problem, because laptops do weird things. Not to mention Macbooks.

As the old boxes were breaking down, we made a stopgap measure – a laptop, and a capture card, in a transportable form-factor. This worked relatively well for 2024, but was larger than we liked, and the laptops we got for cheap had USB issues (which were fixed in a newer version of the laptop, but that did not have Ethernet ports).

You can see it on this picture in action – it’s the laptop with purple background and the box below it.

This worked pretty well, but was a bit unwieldy, and the box itself was almost empty. We couldn’t come up with a way to put the laptop in, so we started looking at options.

Then, Martijn Braam visited us during the 2024 event and metioned “you know, I’ve made a stand-alone open-source audio mixer, it’s a simple board and a chip”. We thought we can use it and get rid of the mixers we carry around, some cables, etc.

Here’s a picture of someone from our senior staff, responsible for the design of the power board and a lot of the low-level hardware and assembly. As you see, he has all the tools needed for the job. He was the other person really interested in designing hardware.

And if we have to say what were the driving words behind the project, it was this. We wanted something that doesn’t cost too much, that we can make in large amounts and that could do all the weird things we wanted.

The thing is, as soon as you start to make your own hardware, you start to get greedy and ask “what else can we do?”.There are so many interesting things you can add, to handle tasks that you were doing with extra hardware or software before.

So the first is trivial, we need to power things inside, so you design your own power board.

Then, we have microphone receivers. They are battery-powered, but can also be powered via USB. So now we have 4 charging ports (and we can turn them off and on from software).

And for crazy ideas, why not design a radio INSIDE the box, that can just receive wireless microphones? Turns out that is pretty much possible, we didn’t have the time for it and there were some snags… But even to me this sounds crazy.

And well, in the end, how hard would it be to design a network switch? Turns out, not that hard. We needed just one revision to make it work, and a few days ago, just becase we can, we added initial support for VLANs in the switch – so that can actually do interesting network topologies.

This is the part in movies where there’s montage with a music background. We worked on different pieces through the summer of 2024, a few months ago…

We started assembling it. This is a simple assembly flow chart :) Might look daunting, but it actually took just two-three weekends and about 10 people to assemble, provision and test 70 boxes.

And because we were running late, this mostly happened in the weekend between Christmas and New Year. Not sure how to translate this to you, but let’s say we were the only people working in the country…

We got the boxes ready somewhere mid-January, and ran FOSDEM 2025 with them 2 weeks later.
And it worked. We still can’t believe it did. We even managed to do a talk there about the box itself :)
And yes, much like this very talk, we had the idea of actually having a talk, less than 24h before.

This is how the box looks on the inside. I’ve left a few of them open while running, so you can all see them.

There are two boards that we did not design: a Raxda X4 (an Intel-based single board computer) and a MS2131-based HDMI capture device with a loop out (but we’re working on that one).

The rest is:
An audio mixer with three inputs and two outputs. So you can have three microphones (enough for almost everything), one output to your camera and one to the room sound system. We needed a microcontroller with USB support, so we added an off-the-shelf Teensy on top of it.

An ethernet switch, so you can also connect other boxes and devices to the network (and build your own network). I’m actually afraid to show the topology we have right now in this venue :)

A power board powers the other boards, and provides the external charging ports. Plus it controls the fans, has a temperature sensor, controls the pass-through USB port to the radxa and more.

And a handful of breakout boards, to be able to cable things up neatly.

If you take a look in the training rooms, you’ll see an interesting modification of the setup. It uses an USB camera, has a single box, and can do all video and video mixing in that single box. So one box like this, one cheap camera, microphones, and you can record & stream a room pretty quicky.

This is still under development (I made a few fixes in the last few days, and there’ll be more). Its current interface is “SSH into it and run commands”, which is not easy for most people. But, this is also being worked on, so at some point there will be even an user-friendly box :)

Of course, we are not even remotely close to what we want. There are so many ideas than those just listed here, and even some of these were thought up while we were writing this presentation, and I can’t wait to show it to the rest of the team.

I really hope they don’t lynch me.

These are two things from our TODO, as an example. As an open-source project, we welcome patches :)

We have tried to make sure this is useful not just to us. The boxes, the software around them, the overal ideas can be useful to everyone who does events or video for events, and should be possible to do video streaming and recording in an easy, stable way with a good quality. You won’t get the very nice features (like a multi-camera setup, drones taking photos from above, etc.), but you will have the sound, the presentation, the lecturer visible and recordings which would be usable to everyone that has not being able to attend.

FOSDEM lends this stuff, and we’re happy to explain how to use it. You can also build your own and we can help with the specifics if needed (but everything should be in the repo anyway).

And we can always use more contributors :)

Remember this slide? Do not be afraid to hack. Do not think this is something extremely complex and impossible to do to. You just need to start.

Please do :)

Ходихме да правим видеото на FOSSASIA Summit 2025.

С Марк и Гери сме правили някакви такива неща и преди, за State of the map (който обаче беше в Брюксел). Сега събитието беше в Банкок, който е на 10тина часа път, 5 часа напред в часовата зона, 20 градуса по-топъл и влажен като Бургас през лятото.

Та, подготвихме някакъв хардуер, и на вълни – първо Марк, после аз, накрая Гери – се добрахме до Банкок. Така Марк можеше да подготви локално каквото може, аз да донеса каквото липсва и Гери – каквото съвсем сме забравили (както се наложи).

Събитието се случваше в “True Digital Park Event Center”, което е място за събития и отдалечена работа (т.е. за “дигитални номади”, каквито се опитват да привлекат). Технически доста добре направено, с инфраструктура и с бая наляти пари в него. От нещата, които ми направиха впечатление:
– Залата има три големи LED екрана, които са на релси и могат да се местят по 3 от 4те стени, както и да правят един голям екран, 4.5м на 24м (в България има някакви такива екрани под наем, и цената винаги ми се е струвала безумна);
– Озвучаването беше на един голям цифров миксер някъде, и хората си ходеха с едни таблети и настройваха нивата в залите;
– Имаха портове за звук, Ethernet и контрол на всякакви неща (като осветление, пак RJ45) равномерно по стените;
– Практикаблите им (парчетата от сцена) бяха регулируеми, лесни за транспорт (на колела) и много стабилни. Жалко, че няма как да ползваме такива (но ако догодина пак е там и участваме, ще си искам предварително няколко такива);
– В една от малките зали вместо това имаше 3 проектора, та в общи линии от всякъде да виждаш какво се презентира (говорим за зала до около 50-60 човека);

Планът на самото събитие беше доста сложен – там имат зала от три части (донякъде като голямата зала на “Джон Атанасов), която за различни дни/части от деня щеше да е подредена различно, с местене на сцени и т.н.. Самите ние си го изяснявахме в движение, а някакви неща само по гол план не стават, та (разбира се) някакви неща се променяха в последния момент. Добре, че хората от мястото бяха разбрани (и супер учтиви).
(еххх, ако говорех езика, бях отишъл там един месец по-рано и бяхме правили заедно генералното планиране, какви неща можеше да направим …)

Имаше на практика два големи потока и три зали като за по-малки лекции/workshop-и (“training rooms”). Нашият план беше с приоритет да направим големите зали с нормалния FOSDEM-ски setup (камера, два video box-а, voctomix на един лаптоп), после да направим малките с един смален вариант, в който в един videobox слагаме USB камера и той го играе миксер (video-mixer-single ролята в github), и ако остане време, да подкараме Voc2Mix най-накрая.

По някаква причина аз бях сметнал, че с 6 box-а ще се справим – бяхме дали два на организаторите още на FOSDEM, аз носех 2 и Марк носеше два. Един ден преди събитието, когато аз бях кацнал, Марк пита дали съм сигурен в сметката си, щото 2+2+3 не е 5, а 7 (и да, канят се да ми направят тениска с 2+2+3=5), а техниката, която бяхме дали на организаторите беше останала в Германия. Та, в общи линии съвсем в последния момент един човек от FOSDEM staff-а закара 4 кутии до офиса на Гери, където той приключваше с някаква работа и откъдето щеше да ходи на летището, и това ни спаси. Имам да пращам много бири…

С двете големи зали се оправихме, малките обаче не работеха от първия ден и там си използваха в началото стария setup, който представлява странен софтуер, който се пуска на лаптоп, stream-ва екрана и звука, и го закарва до някакъв китайски provider. Никой май не го обича, но това имат засега, надявам се да можем да променим малко нещата.

А понеже не бяхме от съвсем началото и не бяхме наясно с начина на работа, имаше доста синхронизационни проблеми – кой stream къде отива (те имаха отделни за всяка зала за преди и след обяд, например), пускането на stream някъде го активираше и едни тестове преждевременно казаха на хората, че събитието е започнало, разнасяхме slide-ове по всякакви начини – за някои зали нямаше как да се ползват лекторските лаптопи (понеже мястото не можеше да занесе HDMI до сцената в някакви конфигурации), та имаше един лаптоп на контролните маси, до който трябваше да стигнат презентациите. Не може да си представите колко е трудно да се пренесе файл през 2025та година между два лаптопа, особено когато нямаш usb flash-ка, хората са с всякакви лаптопи (например без USB-A портове), и имат презентации във всякакви странни формати. И разбира се са ги променяли в последния момент.
Следващата година ще има кабел на сцената навсякъде и вероятно бан на всички Mac-ове.

И като стана въпрос за в последния момент, ние се зачудихме дали да не направим лекция за videobox-а, и разписах една – тия дни ще я допрегледам и кача. Основното послание беше, че тва не е rocket surgery, а аз отдавна исках да кажа нещо по темата…

Доброволците им бяха страхотни. Прилично количество студенти и т.н., но ако им дадеш задача, я правеха – в момента, в който някой застанеше на камерата, нямах притеснения, че ще свърши каквото трябва. Докато си водехме лекцията, трябваше да оставя един от тях да се разправя с лекторите, да могат да си пуснат презентациите от лаптопа (където нещата бяха комбинация от флашки, смяна на лаптопа и някакви неща в един google drive) и той се справи без някакъв проблем. Един от тях много помогна и с пазаруването на техника предварително – нямахме свестен вариант за наемане, но се оказа, че дори стативи можем да вземем евтино от някакви магазини там (личи си, че са по-близо от нас до aliexpress…).

За самият Банкок – изглеждаше ми като някаква смесица от щатите и България, умножено по много…
– Хората карат от грешната страна на пътя (така де, грешна за мен :) )
– Кабелите им вървят по стълбове, както в някои древни времена при нас. Имам малко снимки, трябва да ги кача;
– Има супер лъскави неща до супер изпаднали. На street view много добре се вижда по пътя от хотела, в който бяхме (Marsi hotel) до мястото на събитието;
– Интернетът им е добре. Аз си взех една SIM карта на летището, и не ми направи проблем никъде, на някои места си я ползвах за hotspot. Като бонус, номерът ми започваше с +666…

(не си активирах roaming, а намерих начин за forward на моя номер натам, цените за roaming са безумни)

Някои неща обаче са съвсем различни:
– Почти всичката им храна е или люта, или сладка, или и двете. Аз съм поотвикнал от лютото, ама там дори не-лютото пак си беше прилична работа;
– Хората са много много учтиви. Толкова, че аз се чувствах като някакъв грубиян през повечето време;
– В главата ми още звучи “каа” (което е нещото, което добавено в края на изречението го прави в учтива форма). Направо очаквам хората да казват “Добър ден, каа”…

Прибирането ми беше супер уморително. Сутринта в неделя открих, че съм поръчал таксито за следващата седмица (но ми поръчаха от хотела нещо, та беше ок). Автоматичното гише нещо не мис е радваше на паспорта, та ми помагаха, после бях забравил вода в бутилката, не можах да се ориентирам по пътя в security check-а, и накрая си бях сложил boarding pass-а с грешната страна на скенера. Добре, че явно са свикнали с туристи-идиоти…

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

Още се освестявам от FOSDEM, но вече можем да движим някакви неща около OpenFest – имаме си дати (17-18 октомври), имаме разни забавни идеи и малко по малко време да ги правим.

Едното нещо е, че си сменяме системата за submit-ване на лекции към pretalx. След като дълги години изборът беше pentabarf (чиито сайт даже вече го няма) или да си пишем нещо (както имахме clarion за OpenFest), сега вече има нормално работеща система, която CCC и FOSDEM са проходили доста добре, и успява да свърши работа. Тази година ползвах pretalx-а на FOSDEM и бях приятно изненадан колко човешко е като интерфейс и функционалност.

Та, ако на някой му е скучно, сме започнали превод в translate.pretalx.com. Има 1500 неща за превод, от които в последните дни сме превели около 150.
(а няма начин да пуснем системата за самия фест без български без да бъда линчуван)

Има и разни интересни нововъведения за CfP-то и програмата, но тях ще ги разкажа като ги случим :)

Случихме FOSDEM 2025.

Мисля, че това беше събитието, в което наляхме най-много усилия много хора. Получи се много добре (така де, с по-малко проблеми от очакваното)

Нещата започнаха още на предишното издание, където в NOC-а дойде да ни види Martijn Braam и да ни каже “беше ми скучно по едно време и тука си направих аудио миксер със сравнително проста платка и едно Teensy 4 за контролер”…
(пак от при него, нашата версия на миксера и ethernet switch-а)

И се започна нов дизайн на кутията (неофициално версия 2.5). Версия 2 беше една 4-портова мрежова карта на USB със switch в нея, една capture карта, базирана на MS2131 чип (с вграден loop-out) и един USB hub, на който да се закачат. Всичко останало се вършеше от един лаптоп, който ползвахме за encoder, да показва статус и всякакви такива неща.

Планът за новия дизайн беше:
– да махнем лаптопа
– да сложим екран на кутията
– да си спестим всякакъв друг хардуер, съответно
– да си вградим аудио миксер
– да имаме начин да си зареждаме батериите на микрофоните в движение
– (съвсем нагло, не успяхме) да вградим приемник за микрофоните в миксера

Съответно, Martijn и Ангел от наша страна се заеха с дизайн на платки.
(около това аз осъзнах колко мразя хардуера)

Не знам дали мога да разкажа всичко случило се в рамките на годината. Най-лесно е е да се види history-то на video repo-то.

Малко интересни моменти:
cursor.c, нещо малко, което като се preload-не, прави всяко ползване на SDL да крие курсора. Защото иначе ако човек прави с ffmpeg изход към HDMI порта на компютъра, поне в Debian остава един курсор в горния ляв ъгъл (написването и тестването на цялото нещо отне по-малко време от rebuild на ffmpeg, та за това е в такъв вид);
Инструкции за сглобяване, заедно с план за поточна линия/workshop за сглобяване на много кутии от много хора;

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

За основен компютър вътре в кутията избрахме Radxa x4. Изискванията ни бяха да е x86-64, да има Intel-ско GPU (защото за тях има mainline support за хардуерен encoding), и да е достъпна/налична. Има един много полезен сайт на Martijn, hackerboards.com, в който човек може да търси каквото компютърче му трябва. Първоначално тествахме с Raxda X2L, но заемаше доста място, и имаше проблем със захранването (оправен в по-новите версии, но все пак). В крайна сметка се оказа, че за подобни пари можем да вземем 110 X4-ки, с вграден eMMC flash и всякакви екстри (вкл. bluetooth/wifi, които не ползвахме), и се спряхме на тях.

Ще отделя малко повече време на историята на вентилаторите, понеже имаше много въпроси защо звучат така. Без да изпадам в подробности, които не разбирам, ситуацията е следната:
– на power board-а си имаме чип, който може да контролира вентилаторите, по документация или със стойност на PWM, или на база обороти;
– контролът на база обороти не работи. След като написах една реализация, която следваше дословно datasheet-а и не свърши никаква работа, отидох да видя source за същото нещо в linux kernel, и се оказа, че и там не го ползват на база обороти;
– поради някакви неща с навързването, чипът може и да поддържа един байт за PWM, но на практика има разлика само при 3-4, при всички останали или спира, или е на максимална скорост;
– Въпреки, че сме купили еднакви, хубави вентилатори, различните стойности на PWM-а имат различен ефект върху тях. Също така, различна температура/влажност в стаята, фаза на луната и т.н. също влияят различно. Което води до това, че понякога вентилаторите спират и трябва да им се вдигне стойността да развъртят, което води до виене;
– Което виене вероятно се чува на прилична част от лекциите;
– Понеже на дъното на кутията имаме 2 мм метална пластина, която го покрива цялото и я ползваме за радиатор, имаше разговор дали да не ги спрем изобщо (понеже по време на тестовете не успяхме да го прегреем), но не ни се рискуваше.

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

Металната пластина на дъното се оказа невероятно добра идея. Всичко дойде от там, че ако бяхме следвали стария принцип на закрепяне, трябваше да проектираме и 3d-принтираме много много различни и дребни части, които някакси да закрепим за малкото дупки на кутията многото платки. Идеята да направим една голяма платка отпадна много бързо, понеже две от платките изобщо не бяха правени от нас (Radxa x4 и HDMI capture картата), и щеше да затрудни много процеса на дебъгване и правене на нови ревизии. В един момент си казахме “а защо не просто едно желязо и да завиваме в него”, което почти като страничен ефект се оказа невероятно ефективен радиатор (преди него Radxa x4-ката прегряваше и забиваше в рамките на 10 минути, а Radxa X2L си смъкваше процесора на 500MHz, и обмисляхме всякакви варианти за охлаждане).

Октомври и ноември около други неща бяхме поприключили дизайна, и започна поръчването на всички части. Добрите хора от МиНоЛаб ни услужиха с място, където да струпаме всичко, да можем лесно да товарим и разтоварваме и да сглобяваме. Събрахме части за 70 кутии и организирахме sweatshop по Коледа, в който да ги сглобим, с допълнителна стъпка малко след нова година да инсталираме екраните.
(първоначалният план беше да сглобяваме в initLab, но щеше да ни е трудно да се съберем, и съвсем не ми се мисли как щяхме да носим кашоните с неща нагоре-надолу по ония стълби. За това в initLab беше повечето тестване и разни други разработнически дейности)

Не знам дали мога да обясня какво невероятно преживяване беше сглобяването. 10-15 човека, в дните между Коледа и нова година и после първия weekend на януари, от купчина части и джунджурии направихме 70 работещи, инсталирани и тествани кутии, с които преценихме, че може да се случи FOSDEM (60 за залите и 10 резервни). Ако се бяхме забавили с още една седмица, можеше да направим още, но твърде много приближаваше събитието, и щеше да е сложно да ползваме мястото за сглобяване.

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

За да се справим изобщо, махнахме следните функционалности:
– loop-out през портовете на Radxa-та, вместо през capture картата. Така щяхме и да можем да показваме нещо различно на екрана, докато няма нищо включено. Основната причина да го няма беше, че не можахме да намерим 110 бр. къси microHDMI-HDMI кабели;
– Да избегнем един кабел и да носим аудиото между двете кутии по мрежата. Подкарах един proof of concept с AES67, но не остана време да го направя production ready;
– Горното беше спряно и от това, че поради някакъв синхронизационен проблем audio mixer-a crash-ва, ако му ползваме USB audio-то. Има няколко идеи за как да го оправим, но сравнително късно намерихме, че причината е една промяна, която го прави да работи на 48KHz вместо на 44.1KHz, и води до разсинхронизация на USB-то и четене на грешна памет;
– Пак заради липса на един кабел и време не довършихме функционалността да може да се пуска звук от презентацията на лектора. В някои зали няма озвучаване, та това нямаше да е полезно, но за други щеше да е, а все повече лектори искат да пускат звук;
– Единият ни USB порт на кутията трябваше да ходи директно в Radxa-та, за да можем да правим разни интересни неща. И за него нямахме подходящ кабел, но и донякъде по-добре, понеже това си е жив backdoor в кутията и не сме доизмислили как някой да не пъхне клавиатура и да почне да прави мизерии…

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

В последната седмица успях да оправя още няколко неща, като да имаме и 480p stream (не само за хората на гаден DSL, но за хората на Wi-Fi в самия университет, които не успяваха да влязат в залите).

И така, започнахме FOSDEM 2025 с хардуер, приготвен преди 3 седмици, с известни проблеми и не-достатъчно-тестван. Ако имахме толкова проблеми, колкото очаквах, щях да използвам цялата тая история като пример за децата ми какво да не правят.
Отидохме около 30 човека от България, и бяхме голямата част на видео екипа. Въпреки всичките ми планове да съберем доброволци от други места, не ми се получи – успях да направя един online инструктаж точно една седмица преди FOSDEM, а нямах как по-рано (поради приключването на сглобяването в началото на януари, след което се разболях така, че все още кашлям). Надеждата ми е, след като сглобим останалите кутии, да видим дали разни hackerspace-ове няма да им харесат (щото с тях може да се правят доста интересни неща) и така да съберем още желаещи.

Имахме учудващо малко проблеми.

Основният ни проблем дойде от известния проблем с memory leak-овете на Voctomix – бяхме планирали да мигрираме към Voc2mix, който беше release-нат лятото, но не ни остана време да го преборим (той щеше да ни даде и още възможности, като например повече от 2 аудио канала и съответно начин да носим backup аудио). Това доведе до дупки в някои лекции, и за догодина има няколко идеи как да се оправи.

Другият по-често срещан проблем (3-4 пъти) беше, че определен входен сигнал в capture картата успява да я ошашка, и да и спре loop out-а. Не е ясно защо е, нямаме source на firmware и не можем да намерим документация на чипа (Macrosilicon MS2131, ако на някой му се намира, няма да откажа).
(има предположение, че определени macbook M1-та го правят това с побъркването на capture картата, накрая ще вземем да ги забраним)

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

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

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

Накрая дадохме назаем 2 кутии и един mixing laptop на FOSSASIA, има шанс да ги ползват скоро :)

От новите неща тази година – наслагахме стационарни телефони по VOC-овете и на разни други места, да видим как ще се получи. Закачихме и малко мобилни телефони на SIP към същата централа, за който желаеше. Експериментът беше успешен, ползваха се прилично (и вече има желаещи да има на още места). Може дори донякъде да заместят walkie-talkie-тата (дето още не мога да ги заобичам).

За самия FOSDEM не мога да кажа много – пак беше голяма лудница и пълно с хора, доколкото знам тази година доста по-добре са поддържали залите да не се препълнят. За мен най-интересното беше отделният “junior” track, за деца да ходят на workshop-и и да им разказват полезни неща. Това е нещо, което при нас май в момента го няма (едно време hackconf беше ориентиран към ученици, ама вече го няма), и би било хубаво да се появи.

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

We did FOSDEM 2025.

I think this was the event where we put the most effort into by the most people. It went very well (or, well, with less problems than expected)

Things started at the previous edition, where Martijn Braam came to see us at the NOC and said “I was bored at one point and I made an audio mixer with a relatively simple board and a Teensy 4 as a controller”…

(also from his blog, our version of the mixer and the Ethernet switch)

So a new design of the box began (unofficially version 2.5). Version 2 was a 4-port USB network card with a switch in it, a capture card based on the MS2131 chip (with built-in loop-out) and a USB hub to hook them up to. Everything else was done from a laptop that we used as an encoder, to show status and all that sort of stuff.

The plan for the new design was:
– to remove the laptop
– to put a screen on the box
– to save on any other hardware, respectively
– to build an audio mixer
– to have a way to charge the microphone batteries on the go
– (quite brazenly, bit it failed) to build a receiver for the microphones in the mixer

Accordingly, Martijn and Angel from our side started designing the boards.
(this is where I realized how much I hate hardware)

I don’t know if I can tell you everything that happened within the year. The easiest way is to look at the history of the video repo.

A few interesting points:
cursor.c, a small thing that, when preloaded, makes every use of SDL hide the cursor. Because otherwise, if you output to the HDMI port of the computer with ffmpeg, at least in Debian there is a cursor in the upper left corner (writing and testing the whole thing took less time than rebuilding ffmpeg, so that’s why it’s like this);
Assembly instructions, along with a plan for a production line/workshop for assembling many boxes by many people;

Martijn made a very nice video about the box, and with Angel they presented it in one of the FOSDEM talks, the recording is already uploaded.

For the main computer inside the box we chose a Radxa x4. Our requirements were that it be x86-64, have an Intel GPU (because they have mainline support for hardware encoding), and be affordable/available. There is a very useful site by Martijn, hackerboards.com, where you can search for any computer you need. Initially we tested with Raxda X2L, but it took up a lot of space, and there was a problem with the power supply (fixed in newer versions, but still). In the end, it turned out that for a similar amount of money we could get 110 X4s, with built-in eMMC flash and all sorts of extras (including bluetooth/wifi, which we didn’t use), and we settled on them.

I’ll spend a little more time on the history of the fans, because there were a lot of questions about why they sound like that. Without going into details that I don’t understand, the situation is as follows:
– on the power board we have a chip that can control the fans, according to the documentation either with a PWM value or based on RPM;
– the RPM-based control doesn’t work. After I wrote an implementation that followed the datasheet verbatim and didn’t do anything, I went to see the source for the same thing in the Linux kernel, and it turned out that they don’t use it based on RPM there either;
– due to some details with the wiring, the chip can support one byte for PWM, but in practice there is only a difference at 3-4, with all the others it either stalls or is at maximum speed;
– Although we bought the same, nice fans, different PWM values have different effects on them. Also, different temperature/humidity in the room, moon phase, etc. also have different effects. Which leads to the fact that sometimes the fans stop and their value has to be increased to spin, which leads to whining;
– Which whine is probably heard in a decent part of the lectures;
– Since we have a 2 mm metal plate on the bottom of the case that covers the whole case and we use it as a radiator, there was a discussion about whether to stop them altogether (because during the tests we were not able to overheat it), but we didn’t feel like taking the risk.

Unfortunately, the sound of these fans will be heard in many of the lectures. If someone comes up with a filter to remove it, please send it to us…

The metal plate on the bottom turned out to be an incredibly good idea. It all came from the fact that if we had followed the old principle of fastening, we would have had to design many different and small parts to be 3D-printed, which we can somehow attach to the few holes of the case so they can hold all the boards. The idea of making one big board was dropped very quickly, because two of the boards were not made by us at all (Radxa x4 and HDMI capture card), and it would have made the process of debugging and making new revisions very difficult. At one point we said to ourselves “why not just make one piece of iron and screw it in”, which almost as a side effect turned out to be an incredibly effective radiator (before that, the Radxa x4 would overheat and crash within 10 minutes, and the Radxa X2L would throttle its processor to 500MHz, and we were considering all sorts of cooling options).

In October and November, we had finished the design and started ordering all the parts. The good people at MinoLab provided us with a place to get all the pieces, so we could easily load and unload and assemble. We built 70 boxes out of parts we had by organizing a sweatshop at Christmas to assemble them, with an additional step shortly after the new year to install the screens.
(the original plan was to assemble at initLab, but it would have been difficult for us to fit there, and I can’t imagine how we would have carried the boxes of stuff up and down those stairs. That’s why most of the testing and various other development activities were at initLab)

I don’t know if I can explain what an incredible experience the assembly was. In the days between Christmas and New Year and then the first weekend of January, 10-15 people made 70 working, installed and tested boxes from a pile of parts and gadgets we had. We estimated that FOSDEM could happen with that many (60 for the rooms and 10 spare). If we had delayed another week, we could have built more, but the event was getting too close, and it would have been complicated to use the assembly site.

In the end, on January 7th we managed to send everything to Belgium, and it arrived there a week later.
This was very much on the verge, and we were about to activate the backup plan (which was to rent a truck and drive it there ourselves, and in extreme cases we could assemble some of the boxes on the way, in the back of the truck)

To be able to have something working, we removed the following functionalities:
– loop-out through the Radxa HDMI ports, instead of through the capture card. This way we could show something different on the screen while nothing was on. The main reason it wasn’t there was that we couldn’t find 110 pcs of short microHDMI-HDMI cables;
– To avoid one cable and carry the audio between the two boxes over the network. I ran a proof of concept with AES67, but there was no time left to make it production ready;
– The above was also stopped by the fact that due to some synchronization problem the audio mixer crashes if we use USB audio on it. There are several ideas on how to fix it, but relatively late we found that the cause was a change that makes it work at 48KHz instead of 44.1KHz, and that leads to USB desynchronization and reading the wrong memory;
– Again due to the lack of one cable and time we didn’t finish the functionality to be able to play sound from the lecturer’s presentation. Some rooms don’t have sound, so this wouldn’t be useful, but for others it would be, and more and more lecturers want to play sound these days;
– One of the USB ports on the box had to go directly to the Radxa, so we could do some interesting things. We didn’t have a suitable cable for it, but it was the better thing to do, because this is a live backdoor into the box and we haven’t figured out how to prevent someone from sticking a keyboard in and starting to make trouble…

But, we had all the functionality from previous years, along with an audio mixer that was built in (one less thing to carry), and whose levels we could monitor in real time and change when necessary (without having to send someone in the room). As an added bonus, random people couldn’t change the sound settings, because the box doesn’t have any controls :). In general, the audio mixer and things around it deserve a separate post, which Albert (who wrote most of the code) wrote :)

In the last week I managed to fix a few more things, like having a 480p stream (not only for people on crappy DSL, but for people on Wi-Fi at the university itself, who couldn’t get into the rooms).

So, we started FOSDEM 2025 with hardware that was prepared 3 weeks ago, with some problems and not-tested-enough. If we had as many problems as I expected, I would use this whole story as an example for my children of what not to do.
About 30 of us went from Bulgaria, and we were the majority of the video team. Despite all my plans to gather volunteers from other places, it didn’t work out – I managed to do an online briefing exactly one week before FOSDEM, and I couldn’t do it any earlier (due to the assembly finishing in early January, after which I got so sick that I’m still coughing). My hope is that after we assemble the rest of the boxes, we can see if various hackerspaces won’t like them (because you can do some interesting things with them) and that way we would gather more people who want to play with them and help at FOSDEM.

We had surprisingly few problems.

Our main problem came from the famous problem with Voctomix memory leaks – we had planned to migrate to Voc2mix, which was released in the summer, but we didn’t have time to test and integrate it (it would have given us more options, such as more than 2 audio channels and a way to carry backup audio). This led to holes in some lectures, and for next year there are a few ideas on how to fix it.

The other more common problem (3-4 times) was that a certain input signal in the capture card manages to screw it up and stop its loop out. It’s not clear why, we don’t have the firmware source and we can’t find documentation for the chip (Macrosilicon MS2131, if anyone has it, I won’t refuse).
(there is an assumption that certain macbook M1s do this with the capture card going crazy, eventually we will ban them)

Otherwise, a couple of boards died, the power went out in one room, nothing flooded, despite delays due to the network being deployed on Friday, we were ready at a relatively normal time, so we could go to bed on time, and the tear-down was also completed calmly enough so that everyone could eat normally.

We even managed to rewrite the way to visualize the sound levels (we separated the two channels), by moving the entire calculation of the levels to a separate machine and database (to free up processor time for the video mixers).

And I made the mistake on Saturday night of going to the staff dinner, which dragged on for a long time and, together with the fatigue from everything else, led to the fact that I had to sit down and take a nap somewhere on Sunday afternoon. Either I’ve lost my form, or I just haven’t been able to recover from my illness…

We also lent 2 boxes and a mixing laptop to FOSSASIA, there’s a chance they’ll use them soon :)

Some of the new things this year – we’ve been putting fixed phones on the VOCs and in various other places, to see if they’d help. We also hooked up some SIP mobile phones to the same PBX, for those who wanted them. The experiment was a success, they were used quite a bit (and there are already people who want them in more places). They might even replace walkie-talkies to some extent (which I still can’t get used to).

I can’t say much about FOSDEM itself – it was still very large and full of people, but as far as I know this year they’ve kept the rooms from getting crowded much better. For me, the most interesting thing was the separate “junior” track, for kids to go to workshops and be shown useful things. This is something that seems to be missing here in Bulgaria (hackconf used to be student-oriented, but it’s gone now), and it would be nice if it re-appeared.

And to end with a big thank you to all the volunteers who helped and didn’t strangle me (because the whole exercise wasn’t easy at all) – without you this wouldn’t have had a chance to happen, so thank you very much. And I’d be happy if you joined again next year :)

Равносметъчно…

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

– Децата, as usual, продължават да растат. Понеже гледането на деца в София е леко екстремно преживяване, започнаха училище в Бургас (където им намерихме едно много добро такова);
– Успяхме да случим FOSDEM 2024. Така и не написах нещо по темата, но вероятно ще напиша за следващия, понеже
– По-голямата част от годината се занимаваме да направим следващия revision на video-box-а на FOSDEM. Което води до много занимавания с хардуер и последно три дни сглобяване, на който му е интересно може да разгледа в repo-то. Ще гледам да го разпиша по-подробно като сме готови;
– Случи се OpenFest 2024, в който нямах участие, и в който някаква прилична част от екипа се разпадна. В момента съм се върнал и подреждам нещата (има събран core, говорено с малко спонсори, и даже дати – 18 и 19 октомври в техпарка). Знаех в какво се забърквам, знам, че не е ясно дали трябваше да си го причинявам и не можах да оставя така нещата;
– Това с OpenFest беше половината причина да напиша лекция тая година, този път за екипи. Ще ми се следващата ми лекция да е за нещо техническо, че имам поне 3 идеи;
– Работата си е интересна и много (както обикновено). Тази година успях да си напълня екипа и сега си правим малка реорганизация;
– И последното, chervarium почина по-миналата седмица. Мислим на 8ми януари на ИББ да го полеем прощално…

Да видим 2025.

Снощи е починал Атанас Бъчваров (който повечето хора познават като chervarium).

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

И бих искал да напиша още нещо по темата, но ще изчака…

Update: погребението е в неделя, 22.12, от 13:30 в Ямбол (на гробищата)

(запис в видео-архива или в youtube)

Преди известно време NSA разсекретиха лекция, която (по това време капитан, после адмирал) Grace Hopper изнесла при тях през 1982 година. В тази лекция има много интересни неща и я препоръчвам на всички да я изгледат, но една част от нея ме побутна да направя моята.
(всички, които гледат лекцията почват да искат да имат баба като нея)

(ако някой не знае коя е Grace Hopper, силно препоръчвам да се се зарови)

Явно се сблъска в главата ми с много други неща, свързани с “мениджмънт”, “човешки ресурси”, “модерно робство” (за мен термина “човешки ресурси” е наследство от времената, когато робството е било нормално. Честно казано, даже очаквах да намеря някой римски термин като “Homo subjecto” (човекопредметност), на който да е наследство).

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

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

Тази лекция събира опита ми от последните двайсетина години с някакво количество книги, изчетени по темата. Опитът ми е от различни фирми (последната е StorPool), и доброволчески организации като OpenFest, FOSDEM, IT турнето и разни други.

Този въпрос го има и накрая.

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

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

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

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

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

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

Малко източници, на които съм се базирал.

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

Военните организации са друг интересен пример. Теорията им съществуват от много отдавна, и при тях доста от лошите идеи са отмрели (понякога съвсем буквално). Доста от техните идеи са неприложими извън тяхната сфера (например принципите им за team building са незаконни), но има и много полезни неща.

За системите от хора (т.е. организации) има също написано много, ще се появява на разни места из лекцията.

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

Да започнем с това как се събират правилните хора.

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

Хората, с които работите определят дали ще си свършвате работата, дали ще ви харесва, или сутрин ще трябва да си разреждате кафето с нещо по-спиртно, за да може да понесете деня.
(Личен съвет – ако откриете, че започвате да си сипвате алкохол от сутринта, за да може да си вършите работата, е време да напуснете. Както и ако в понеделник сутрин ви става лошо при мисълта, че трябва да ходите на работа)

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

Ще базирам тази част основно на какво правим в StorPool, но доста неща са подобни и при търсенето на доброволци, и твърдя, че са приложими за повечето IT специалности.

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

Първия път пуснахме обява по нормалния начин, видяхме 20-30 CV-та, от тях избрахме 10 по някакъв начин, и ги поканихме на интервюта.
След като приключихме с тях (отне около седмица), седнахме, поговорихме и си казахме “NEVER AGAIN”. Обърнахме процеса, като сега първо пращаме на кандидата задачи, и след и ако реши някаква част от тях, каним на интервю.

CV-тата на хората дават идея за какво да си говориш с тях. От там нататък стойността им не е особено голяма – хората лъжат, доста често ненарочно, и разликата между двама човека със същото CV може да е от земята до небето. А интервю с грешния вид човек е изпитание и уморително упражнение, което спокойно може да се пропусне.

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

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

Важно е задачите да са реални. Това има допълнителния момент, че кандидатът може да разпознае неща, с които се е борил и да разбере, че не е сам :)

И разбира се, трябва някакво разнообразие, не може да дадем същата задача 5 пъти с различни параметри. Най-малко никъде работата няма такова нещо.

Задачите са прекрасен филтър.
Има хора, които изобщо отказват да обърнат внимание, защото смятат, че са над такива неща. Има хора, които не намират подобни неща за интересни. Има такива, които не могат да решат нищо от тях. И наскоро дори имаше случай “не смятам, че някога в реалната работа ще ми се наложи да правят A и B (неща от задачите).

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

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

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

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

И разбира се, ако хората им харесва, няма да искат да си тръгнат. Достатъчно често попадам на случаи, в които хората искат да напуснат и да идат някъде дори на по-ниска заплата. От друга страна пък, никога няма да забравя как се опитвахме да подмамим при нас Боби Станимиров. Бяхме го завели на обяд в едно много приятно заведение, говорехме си, обяснявахме колко интересни неща правим, и той в един момент каза “Да, вашето е интересно. Ама при нас лекуваме рак.”
(той тогава беше във viewray, те правят комбинация от ядрено-магнитен резонанс и гама-нож, т.е. докторите могат да гледат докато режат с гама ножа)

Да си харесваш работата всъщност не е толкова рядко, а хората харесват какви ли не работи. Може би най-простия пример, който имам е как хора ходят, учат във ФМИ и вместо да след това да работят за много пари в IT-то, стават учители – професия, която (да цитирам един мой любим сериал) комбинира стреса на неврохируг със заплащането на продавач в магазин.
Шапка им свалям на тези хора, аз не бих могъл.

(или всички доктори)

Слайдът, разбира се, може да се чете като “отклонение е да си харесвате работата”. И такива отклонения трябват :)

Благодаря, че ми намериха този графит, който беше написан едно време, мисля на ул. “Париж”, и който е донякъде крайната фаза на харесването на работата и мотивираността. Поне според мен, човек трябва да може сутрин да си отговаря на този въпрос или с “да”, или с “ще направя нещо, че отговорът да е ‘да'”.
(предполагам не е полезно да мислиш за умиране всяка сутрин, та може да бъде разредено кога се преосмисля, но принципът си остава :) )

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

Човек и добре да живее, трябва да си говори с други хора. Процес на наемане без интервюта няма как да се направи.

Виждал съм различни варианти на интервюта. Може би най-любимото ми беше в google, където им бях на гости за един ден, сложиха ме в една стая и различни екипни lead-ове ме разпитваха в продължение на около 5-6 часа.
(може би заради това Дъблин ми стана другия любим град след София)

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

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

И има едно “човешко” интервю (все ми се карат, като го наричам така, та приетия термин е “не-техническо”). Целта му е да хване проблеми с човека, които ние не сме видели.

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

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

Учудващо, разликите в доброволческите организации са основно в реда на случващото се. Много често доброволците директно почват с един изпитателен срок, преди да навлязат повече в организацията :)

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

Това е като продължение на частта с типа хора, който искаш.

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

Културата е нещо, което съществува в екипа, но трябва да е подкрепено на всяко едно ниво.

И понеже това е някакво вятърничаво като обяснение, ето конкретни примери.

Един пример, който ще дам, е FOSDEM и open-source решенията. Видеото на FOSDEM винаги е било с open-source решения, доколкото е възможно, и когато е имало възможност да се направи още нещо отворено, като например смяната на един capture device с друг, това винаги е било подкрепяно от цялата организация, въпреки отражението върху бюджета на събитието. Това винаги е важало и за всичко, което се ползва – ако има възможност, се прави с open-source софтуер, ако ще и самата организация да си го напише, без възражения от типа “не можем ли да ползваме онова готовото и да не се занимаваме”.

Друг пример – за нещо, което не осъзнавах, че е добре да се формализира – е т.нар. blameless postmortem. Идеята е следната – ако се случи грешка, която да доведе до сериозни последствия (в нашия случай – downtime), се пише postmortem документ, който описва как се е случило събитието, какво е довело до него, и какво може да се направи, за да не се случва пак.
Blameless частта е, че вместо да кажем “Пешо пипна там и то се счупи, та ще му хвърлим един бой”, се прави по-трудното – изяснява се процеса, грешката и как да не се стигне пак до там. Така се правят по-малко грешки, и не се стига до там, че хората не смеят да правят нищо, за да не пострадат.
(и това е обратно на културата на твърде много места, които съм виждал)

Свързано с това по-горе, културата трябва да приема, че грешките са нещо възможно, и че са някаква част от learning процеса. Щом това успяват да го приемат в области като медицината и воденето на война (USMC имат изрично записано, че “there must be no ‘zero defects’ mentality”), където заради грешки умират хора, не мисля, че и в IT-то не може да се приложи.

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

Това си мисля, че е познато на всички. Ще се връщам към него, но просто ще кажа, че всеки в един екип трябва да може да е Бай Иван, без значение позицията.

Съвсем дискриминационно ще кажа, че има правилни и неправилни хора, с които да работиш.

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

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

Аз не мисля, че мога да мотивирам някой, който не би могъл да се мотивира сам (и определено не искам). Мога да покажа работата, да обясня какво е интересното, какви неща никъде другаде не правят (или в случая на доброволчеството – какво постигаме), но всичко това е безсмислено, ако човекът не е достатъчно self-driven, за да може сам да се мотивира и да се движи напред.

И да натъртя още веднъж идеята, ще дам пример за едно обяснение към студенти, как по партита като се забиват с някой от подходящия пол, преди секс да не търсят “consent”, а “entusiasm”.

При доброволците има важен момент, който следва от предното. За да си харесваш работата и да си достатъчно желаещ да се занимаваш с нея (особено за без пари), трябва да го припознаеш като нещо свое. И това е едно от най-важните неща в подобни организации – да събере хора с обща цел, които приемат целите на организацията за свои.

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

Така и обратната връзка не се приема като нещо лошо, а като нещо, което помага да се движите напред. Екипът не трябва да има страх да каже на някой “моткаш се” или “това е грешно”, какото и всеки в екипа трябва да е ок с подобен feedback. Ако сме се подбрали правилно, нищо от това не е с цел да тормози другия, а с цел да си свършим работата.

Та може би поговоркара за сговорната дружина може да е “дружина с обща осъзната цел планина повдига”, понеже съм го виждал в действие :)

Крис Хадфийлд, който първо ми беше познат от една глава на “How to” (на темата “как да приземим космическата совалка на различни странни места”) има една глава в книгата си “An astornaut’s guide to life on Earth”, в която обяснява какво е правилното нещо, към което да се стремиш да си в един екип. Отговорът му е, че винаги поне трябва да си на нула, т.е. да поддържаш нивото на работа на екипа.

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

Това е и истинската дефиниция на “екипен” човек за мен. Като пример как не се прави, ще дам скорошната случка, в която maintainer-а на Rust за linux kernel-а се отказа да се занимава, защото му било омръзнало да го занимават с “нетехнически” проблеми. Което показва колко заблуден е бил, щом е очаквал, че проблемите му ще са само такива – цялото това нещо, което се опитва да направи е като да накара ламята Спаска да танцува балет. И колкото да обяснява колко гениален е тоя балет, има много други подробности, преди това да има шанс да се случи.

Изобщо по темата за убеждаването на хората и прокарването на идеи, препоръчвам лекцията на Грейс Хопър, която споменах в началото. Тя обяснява за добри начини за постигане на промени в подобни обстоятелства (тя все пак е работела за department of defense и други подобни гигантски структури).

Иначе, имало е доста странни въпроси по интервюта, които са ми помогнали да изчистя моето очакване за какво е екипност и какво всъщност очакват хората. Най-странния въпрос, който са ми задавали беше дали сме повече adversarial или cooperative – което за мен беше невероятно, понеже никога не съм бил/очаквал някой такъв екип да е adversarial и хората да се състезават, вместо да си помагат. Предполагам, някъде има приложение, но поне за мен не е в рамките на една организация, която се опитва да върши работа.

Понеже до тук говорих за общите неща в хората, извън тях, останалото няма значение. В разните екипи, в които съм бил и са били ефективни е имало хора от всякаквите възможни части на обществото, по всякакви признаци, и това определено помага да се избегне groupthink-а (или поне да се намали). Дори в текущия ми екип, който на практика е само системни администратори, има следните под-видове хора: бивши военни, тонрежисьори, готвачи, заварчици и т.н.. Ако попаднем на необитаем остров, няма да ни е скучно, няма да умрем от глад и сигурно ще намерим начин да се измъкнем…

А последния link – ако не сте го чели, отделете му 20 минути. Той обяснява колко бързо свикват хората с глупостите в една организация. Заради него ние правим едно post-onboarding интервю с всеки нов човек, горе-долу на втория месец, в което сядаме и започваме да задаваме въпроси от типа “сега, докато още не си свикнал с нашите глупости, кажи какво не ти се вижда вярно”. Силно препоръчвам и като четиво и като практика.
(в началото имаше доста моменти в тези разговори, в които си казвах “а, ама и аз имах проблем с това, и то все още не е правилно”)

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

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

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

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

И ролята на водещия екипа в такива дискусии (освен нормалното участие) е да сумаризира и да отпушва дискусията, когато забие в някоя ненужна посока. Формално накрая може да произнесе решението и да носи отговорност за него, но то на практика трябва да идва от екипа.

Понякога консенсус не се получава – опциите са много, мненията са различни, има нужда да си подредим по предпочитаност някакви опции. В такива случаи може да се прибегне до някакво гласуване, като обаче е важно да сме наясно с изборите, и как точно избираме. Темата за системите за гласуване е много обширна и няма да се спирам на нея, но препоръчвам на всички да се запознаят с модифицирания Condorcet метод, който се ползва в Debian проекта.

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

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

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

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

Ако нямате стенографиращ екип, и не сте водили дискусията по mail, то на практика се разчита само на паметта на хората. Паметта на хората е нещо ужасно (който не го вярва, да прочете “Невидимата горила”). За това всяка организация би трябвало има писмена институционна памет (не само хора, дето помнят някакви неща), за да може да се обръща към нея в такива моменти.

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

Документирането никак не е лесно, но се изплаща многократно.

И тук някъде идва разговорът за воденето на екипа.

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

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

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

Това е един списък, дето написах още в началото, докато си правех плана на лекцията. За мен е сравнително очевиден, но сам по себе си не е особено интересен. Може да се намери в някакъв вид в много книги, включително в голяма част от всичката военна фантастика :)

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

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

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

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

А може просто да няма формализиран lead, и ролята да се мести, или просто да се случва сама. Това също е работещ вариант при правилните хора, и е просто една голяма “резервна скамейка”, от която някой става, когато е нужно.

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

Да си призная, тези хора ми бяха от любимите екипи :)

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

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

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

А трябва ли да се занимваме с това? Да сме в екип, да го поддържаме, да работим заедно?

За някои хора не. Има достатъчно неща, за които може да си one-man show и да сработят, и познавам хора, които правят точно това – гледат да са единствените, които се занимават с дадено нещо и да си го организират така, че да не им е проблем.

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

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

Оставям един slide с малко допълнителни ресурси, има ли някакви въпроси?

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

Вчера с Благо направихме self-hosting workshop, и има запис. Ще се постарая да намерим начин останалите неща, дето се случват там да се записват и да ходят във видео архива.

vote.openfest.org, както винаги. Гласуването помага за подреждането на лекциите и понякога за избора им.

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

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

Тия дни обаче попаднах на запис на лекция на Grace Hopper в NSA, който наскоро са разсекретили (и в който няма нищо особено секретно или тайно). За лекция, която е изнесена преди 30-40 години, нещата са доста интересни и на място, доста от проблемите от тогава съществуват и сега, а самият разказ и начинът на разказване са едни от най-добрите, дето съм виждал.

Та, препоръчвам.

initLab стана на 14 години.

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

Хубаво е, че лабът съществува толкова години. Това е едно от малкото места, на които хора могат да се съберат и да свършат нещо интересно, в почти произволна посока, без някакви особени ограничения и задължения, просто за удоволствието и знанията. През годините са организирани толкова събития, че ми е трудно да ги изброя (във времената, когато бях в управителния съвет си спомням колко дълъг ставаше отчетът за дейността, просто защото целогодишно се случват някакви неща). Без initLab щеше да е доста по-трудна организацията на OpenFest, на доброволците, които ходим на FOSDEM, study групите за Rails Girls, както и на много знайни и незнайни други проекти.

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

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

Има запазени 2-3 маси в “Дондуковъ” (където се провежда и ИББ), за 26.07 (петък), 19:00, на мое име.

Ще има и във Варна, ще update-на за там като ми кажат къде ще е.

Update: За Варна – “Черната овца” до ЖП гарата, на името на Тодор Петков, пак от 19:00, пак 26.07.

Update: За Велико Търново – “Тихият кът” от 20:00, пак 26.07.