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

И така, да напиша за представянето на отборите, което продължи 6-7 часа (издържани само заради няколкото чаши Lagavulin).

(списък на отборите и source код)

Отбор 1 – FMI free time (отборът се състоеше само от един човек – Атанас Керезов, който в момента ми е на върха на класацията за дразнещи хора). Беше започнал система, която да може да се ползва за уговаряне на време за посещение на администрацията (като системата на КАТ), но не беше стигнал до никъде.

Отбор 2 – Old school – бяха написали система за тези, които могат да получават стипендии, да си попълнят данните и да могат да следят къде са в класирането. Не можах да си задам въпросите, че бързо ги изгониха, но се зачудих колко лесно ще е някой да смени IBAN-ите, които се подават, и да получи на хората стипендиите.

Отбор 3 – voltron – тук ми се губи и бележките не казват много, беше някаква система за дарения и следенето на развитието на кампаниите.

Отбор 4 – hackfmi_se – отбелязал съм, че са имали ужасна презентация. WordPress plugin, който да помага на за документите на докторантите, който и се оторизира през СУСИ (което прозвуча като перфектния backdoor да се събират user-и и пароли и да се използват за системата на втория отбор да се сменят IBAN-и).

Отбор 5 – noex1t – plugin за chrome, който може да разпознае encoding-а на даден текст и да го визуализира както трябва да е. Това беше една от малкото сериозни теоретични разработки – ползва речников метод, и може да разпознава дори прекодиран през две кодировки текст (например UTF8, закаран до cp1251 и после пак до UTF8). За това ползваше външен service (за което аз го питах дали не е privacy concern, хората да си пращат части от личната кореспонденция на трети лица, и той отговори, че за до две прекодирания може да го прави от plugin-а и няма да се налага). Човекът до мен имаше въпрос, който не успя да зададе, дали ако има текст на два езика в подаденото нещо, няма да се обърка системата.

Отбор 6 – hack Bulgaria, в който беше и Радорадо – бяха разработили интересна идея, API, чрез което може да се събират задачи (да речем по програмиране) и от тях да се генерират контролни. Към тях имаше мета-данни, та да може да се направи приложение, което приема отговорите и ги проверява. Изглеждаше доста добро и удобно, интересно дали ще намери приложение.

Отбор 7 – СМГ11 (хора от СМГ, 11-ти клас :) ) бяха направили система, която даваше възможност на кандидат-студентите на едно място да видят и сравнят различни специалности в различни университети, доколкото биха им били интересни/полезни. Имаха и система за рейтинги, т.е. можеше да се отбелязва коя специалност е хубава и коя не (по няколко признака). Цялото нещо беше работещо и това беше отбора, за който гласувах с 3 точки.
Питах ги как решават следния проблем – решавам, че някоя специалност е много трудна за влизане, та пускам един ботнет да гласува против нея усилено, хората виждат, че е с нисък рейтинг и се отказват да кандидатстват, което ми дава доста по-голям шанс. Нямаха решение, но ако я пуснат, с удоволствие ще се включа с нещо. Не ми се мисли колко ще ги мразят някои ВУЗ-ове…

Отбор 8 – VPR (на които бях ментор) – бяха направили система за помощ с бърз response, т.е. хората казват “трябва ми помощ за едно контролно утре”, дават краен срок, да речем половин час, след което чакат някой да влезе в системата, да хареса въпроса им и да се свържат. Системата им предлага свързване по някакъв chat в реално време (планираха да направят и видео/аудио разговори, но не им е стигнало времето), както и търсене по тагове на търсещи.
Демонстрираха работеща система, въпреки проблемите с internet-а.

Отбор 9 – full metal team – бяха едно количество деца от ТУЕС, които даже в началото в представянето си доста добре се избъзикаха с всички фирми, които се бяха представили (“имаме много офиси, навсякъде по света…”). За съжаление така и не схванах какво им прави системата, и съм си отбелязал да ги питам, но не стигнах до там.

Отбор 10 – #чичковитечервенотиквениковчета – бяха реализирали една идея по задание от реална организация, сайт за дистрибуция на книги. В общи линии има вариант да се задава търсещите организации (детски домове например) какво търсят, или някой да каже “ей-тука имам тия книги”, или “имам два кашона, дето искам да се отърва от тях” (т.е. конкретно моят случай :) ), и системата да се погрижи да свърже който с когото трябва и да улесни организирането на пренасянето. Ще чакам да кажат къде ще е deploy-ната и ще ги ползвам с удоволствие…

Отбор 11 – Едногор – пак хора от ТУЕС, в общи линии опростен web клиент за youtube, който да може да се ползва и на по-слаби машини. Филтрира реклами, всякаквите глупости от страни и показва само заглавие и самото клипче. Няма и autocomplete (за което хората питаха).
На въпроса “ако си сменят api-то, така че тоя клиент да не работи, т.е. ако тръгнат да го спират той какво ще направи” отговорът беше “това отне ден и половина да се напише, за следващото ще е пак толкова” (и цялата зала ръкопляска).

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

Отбор 13 – ДГ – беше система за организиране на дарения, базирана на wordpress. Идеята им беше хората през сайта да се уговарят, и даващите получаваха код, чрез който да си изпратят исканите неща. Имаха няколко метода за транспорт.
Питах ги тоя код, който се ползва как го генерират и могат ли 1) да го опростят или 2) да сложат в него някакъв error correction, понеже хората доста грешат, когато преписват.

Отбор 14 – recaro (бях им ментор) в общи линии имаха да решават traveling salesman проблема, но това, което показаха беше най-вече хардуер, който се връзва в колата и показва на шофьора какво има да разтовари, както и праща нагоре колко му е пълен резервоара, така да може от централната система да се следи какво се случва и да се праща към бензиностанция.
Имат възможност да вържат системата към CAN bus-а в колата, както и да сложат сензор в резервоара (ако е много стара), иначе частта в колата беше правена/писана с някакъв PIC18. Като цяло беше недовършен проекта и ми се стори леко странен.

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

Отбор 15 – madeinbg – търсачка за продукти, правени в България. Пак стандартна снабдителна задача, производителите попълват, хората търсят, като има и някакви chat-ове вътре, с които хората могат да задават някакви въпроси и т.н.

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

Отбор 17 – оркестър без име – бяха направили система за отбелязване по карта на интересни събития, които се случват в момента, например улични музиканти. Даваха възможност да се правят снимки (и в бъдеще – клипчета) и да се качват заедно със събитието, като нямаха идеята за live streaming. Цялото нещо беше хибридно мобилно приложение (т.е. html и js), което беше още по-учудващо (повечето такива неща работят с огромен зор).
За да го демонстрират, си доведоха един младеж с китара на сцената да посвири и да го снимат и качат. Това си беше малко hack в/у журито, нещо от типа на замайване с bells and whistles, и май мина, щото доста хора гласуваха за тях и спечелиха втора награда.

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

Отбор 19 – панда (на които бях ментор) – бяха направили благотворителна система за продаване на content. Създателя на съдържанието го качва, описва го, системата генерира thumb-ове и т.н., след което казва и за кои каузи да отиват парите от продажбите. Имаха реализирани и плащания през един payment процесор.
Имаше въпроси дали пазят кредитни карти (щото се въвеждат на техния сайт) – не, дали правят обработката на content-а в отделен процес/с друг user id – могат, въпрос на deployment, и дали става ясно какви са таксите и къде отиват – може да се expose-не.
Най-учудващото беше, че наистина са успели да го сглобят за два дни, може би трябваше да спечелят повече от трето място :) (вероятно им помогна, че няколко човека от екипа си работят професионално и пишат сериозно)

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

Отбор 21 – el romantico, на които бях ментор и които в петък имаха 4 идеи, в събота работеха по пета – бяха направили система за намиране на курсове (т.е. пак снабдителния проблем). Дава се възможност някой да предложи курс, да даде минимален брой хора, които да дойдат, и останалите да се записват. Системата им работеше :) Питахме ги дали имат филтриране по географска локация – казаха, че са го махнали, и нямат също така идея дали курсът в крайна сметка се случва или не.

Отбор 22 – RQ – бяха написали система за резервации в ресторанти и подобни заведения (и не беше ясно дали това има много връзка с благотворителната тематика на hackaton-а). Собствениците на заведения можеха да качват архитектурни скици на заведението си и да обработват заявки за резервации, като поставят хората на определени места. Скиците се работеха като bitmap-и, и резервациите се маркираха просто с правоъгълници, т.е. нямаше анализ и разпознаване на картинки, но бяха докарали пълна работеща система. Нямаха и автоматично разполагане на резервации. Имаха допълнителни бележки към всяка резервация, като metadata как да се разположат хората.

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

Отбор 24 – 42 (на които бях ментор) бяха направили визуализатор на произволни данни в/у карта чрез csv файлове. Ползваха за основа OpenStreetMap. Питахме дали може да комбинират няколко вида данни или да изобразяват функция от два вида (например брой училища на глава от населението за даден регион), нямаха го.
(те имаха доста по-мащабна идея, но явно не бяха успели да я доработят)

Отбор 25 – супер герои – бяха направили “мобилен app за доброта”, в общи линии като контролния дисплей на някой супер герой. Хората подават заявка за помощ през някакъв вариант на приложението, след което всеки докато си върви по улицата може да види къде наблизо има някакви проблеми и да се включи, ако иска. Примерът, който бяха дали е как можем да видим, че някой има проблеми с компютъра и е от нашия вход, и да идем да помогнем.
Планираха да сложат ACK за всеки, който е реших да иде да решава даден проблем, за да не се получава slashdot-ване на някой проблем.
Нямаха добро решение за случая ако някой използваше системата като honeypot, т.е. или да примамва хора, или да гледа къде има пострадали хора и да ходи да лешоядства – казаха, че оставят решението за пускане на заявка за помощ на самите крайни потребители.
Не беше съвсем ясно и какъв точно е target-а на приложението.
(работеше)

Отбор 26 – infinity – бяха написали система за регистрация на басове (облози, не музикалните инструменти, както си помислих в първия момент). В нея просто едната страна описва баса, другата го приема, и чрез системата си го помнят. Питахме ги дали не ги хваща закона за хазарта (което е доста вероятно, и не знаеха), и дали има вече такива приложения (май има, те не знаеха).

Отбор 27 – repl5 (бях им ментор) – бяха направили система за генериране на тестове (от тия, дето печатаме, за да изпитваме студентите). Един от менторите им беше помогнал с написването на разпознаването на изображения, за да може да се проверяват по-лесно тестовете.
Имаше бая въпроси към тях: как валидират генерираните тестове, т.е. как знаят, че не са повторили въпрос, или отговор (щото това винаги е бил първия бъг на всичките генератори, които съм виждал) – ще си напишат тестове към алгоритъма; възможност за повече от един верен отговор – имат; схемата им с табличката за попълване на факултетния номер (5 реда с числата от 0 до 9, и човек на всеки ред отбелязва поредната си цифра от факултетния номер) беше лесна за объркване – имат и друга; какво става, когато човек си коригира отговор на листа – разпознаването би трябвало да се справи (това не го вярвам).
Ще е хубаво най-накрая да има унифицирана система за това, но не е ясно дали ще е тази (иначе работи като приложение директно в browser-а на потребителя, само на javascript и генерира pdf-и, т.е. е доста portable, за разлика от много други, дето сме правили).

Отбор 28 – бащата на Кнут Хамсун (проверих в wikipedia, Педер Педерсен) – бяха направили проста система с QR кодове за информация за статуите из ФМИ, на кого са, какво е направил и т.н..
Оказа се, че те пишат в QR-а директно URL (а самия QR е на лист, залепен за статуята), което значи, че ако подменя листа с някакво друго url, хората ще отварят него. Решението им за в бъдеще е, че ако QR кодът е издълбан на статуята, то няма да работи номера с фалшификацията (а самия код е супер издръжлив на опити за промяна).

Отбор 29 – Оги самотния войн – беше нещо за предизвикателства/challenges, но нямам много бележки по него и не беше особено ясен (и не беше стигнал много далече, основно имаше някаква идея).

Отбор 30 – placeholder – бяха направили lock screen, който показва реклами, от които приходите по принцип да отиват за благотворителност. Единствената ми бележка е “ужасна идея”.

(приемам корекции и допълнения, сигурен съм, че имам доста грешки и пропуски)

(неособеноадекватенpost, пишете корекции ако видите нещо)

В последните три дни бях на HackFMI 3. То приключи преди около 12 часа, а сега съм леко адекватен и ще се опитам да напиша нещо по въпроса.

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

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

Всичките бяха интересни. Записал съм си някаква част от тях:
Единият отбор (VRP) правеше система за комуникация в реално време, да се откриват хората по конкретен проблем и да могат да си пишат и да прекарват аудио/видео в реално време. С тях си говорих за webrtc и как могат да решат проблема с NAT-а и изобщо да прекарат медията, съответно след като открихме, че няма TURN поддръжка в повечето browser-и, двете ми идеи бяха да се срещат през TOR, или да ползват някакъв flash chat (през red5 и нещо такова), понеже е докарано да работи.

Вторият (42) правеше карта на местата, удобни за инвалиди, т.е. overlay в/у google maps или OSM, който да използваш за да провериш къде можеш да отидеш да свършиш определена работа и да е достъпно. Там говорихме откъде могат да събират данни (OSM, OKFN проектите и т.н.), както и че атаката, която аз бих измислил в/у системата е да направя някакви много привлекателни места за такива хора (на картата), да застана там с едно паве и да ги обирам един по един.
(някъде по това време бях обвинен в безчовечност)
(в отбора имаше двама колеги от моя офис)

Третия отбор (El Romantico, който беше в стая 404 и бяха изтървали да се кръстят отбор “Not Found”) имаше 4 идеи (на следващия ден работеше по пета). Две от тях съвпадаха с други, които бях чул, третата беше вариант на patreon/gittip за България (което от няколко месеца и аз мисля), и четвъртото – система за обсъждане, подобна на reddit/slashdot с модерация. На четвъртата идея се появи и Кънев, който разказа една доста добра идея за такава система с гласуване – която дава възможност за конкретни въпроси да си дадеш гласа на някой друг участник в системата, и той да го използва вместо теб (което звучеше супер интересно и жалко, че не го направиха).

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

В събота имаше пак няколко слота за обикаляне по отбори – пак посетих първите (VRP, с webrtc-то), едни хора, които решаваха traveling salesman проблем, като цяло някакви хора, които решаваха проблема за запознаването (“Имаме хора, дето предлагат нещо и хора, които търсят нещо, да им улесним живота”). Едно изключение от тоя тип неща беше изцяло client-side генератор на тестове (такива, дето печатаме на хартия и с които изпиваме студентите) на javascript, който генерираше pdf-и.
(като цяло май много от нещата ми се губят, въпросите и отговорите ми се смесват в главата и не си водех бележки)
Бях взел Велин с мен, и той също остана учуден от това колко интересна е цялата работа, даже в един момент каза “А ако можеше да използваме цялата тая енергия за мирни цели…”.

В неделя нямаше менторстване, та използвах повечето време, което бях във ФМИ да подкарвам frab за различните конференции (в петък/събота Митьо ми беше помогнал да му setup-на deployment-а с puma), та в общи линии вече има frab.it-tour.bg, който тия дни ще пуснем официално.
(wifi-то беше ужасяващо през цялото време, повечето работа, която свърших беше на кабел, това трябва да му се измисли решение)

Последва закриващата част.

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

Започна изслушването на отборите (29 на брой), в около 19:00. Продължи до около 1:30… В един момент дадох на Яна ключовете от нас, да иде да донесе една бутилка Lagavulin, която бая помогна.
(списък с отборите/проектите и с source code-а им)

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

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

Като интересна статистика – броих, имаше около 20% жени в участниците, но нямаше нито една менторка (следващия път трябва да набутаме Яна да им помогне с маркетинговата част, и да видим кои програмистки биха се престрашили).
Също така имаше няколко ученически отбора – 10ти, 11-ти клас (които бяха даже с придружител, и едните трябваше да им пишат извинителна бележка, щото бяха първа смяна и нямаше шанс да спят достатъчно, че да могат нормално да идат на училище). Имаше и хора от други университети (например отбор на ТУ, който нарочно се беше кръстил УТ).
Спокойно мога да кажа, че в традицията на олимпиадите по информатика развращавахме младото поколение с това да висят ден и нощ, да пият нещо, което да ги държи будни, да пишат, дебъгват и да дремват по половин час по столове/бюра/дивани.

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

Останах малко след края да помогна с изчистването, после се видях с някакви хора пред факултета и в 3:15 се бях прибрал вкъщи, свърших малко работа и умрях. Тая сутрин съм изпил едно кафе и не усещам да има особен ефект…

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

Update: Напомниха ми да спомена, ученическите отбори бяха от СМГ, НПМГ и ТУЕС, като май ТУЕС бяха най-представени.

Update 2: А като си тръгвахме в 3 сутринта, имаше някакъв младеж, останал да спи някъде във факултета, понеже имал контролно в 8…

This is my talk from RIPE-SEE3, on the deployment of IPv6 in Sofia University. The presentation can be downloade in pdf or odp format.

I’ve put the slide number or the notes/comments I have in [], the rest is as close to what I said as I remember, with some corrections.

[1]

Hello. I’m going to talk about the IPv6 deployment in Sofia University. It’s an important example how this can be done on a medium-to-large scale, with no hardware upgrades or hidden costs.

This presentation was prepared by Vesselin Kolev, who did most of the architecture of the network there and was involved in its operations until recently.

(I want to clarify, we’re not the same person, and we’re not brothers, I get that question a lot)

[2]

Please note that I’m only doing this presentation, I was not involved in the deployment or any network operations of the university’s network.

[3]

These are the people that did and operated this deployment. Most of them aren’t there any more – Vesselin Kolev is at Technion in Israel, Nikolay Nikolov and Vladislav Rusanov are at Tradeo, Hristo Dragolov is at Manson, Radoslav Buchakchiev is at Aalbord University, Ivan Yordanov is at Interoute, Georgi Naidenov is a freelancer. Stefan Dimitrov, Vladislav Georgiev and Mariana Petkova are still at the university, and some of them (and some of the new people there) are at this conference, so if you have questions related to the current operations there, they’ll probably be able to answer better than me.

[4]

So, let me start with the addressing.

[5]

This is the current unicast network that’s in use in the university. It was assigned around February 2011 and was used from the 11th of February 2011 onwards. It’s a /47, later on I’ll explain why.

Also please note that the maintenance of the records in the RIPE database for the network is done only with PGP-signed emails, to protect this from hijacking. As noted by one previous speaker, there are a lot of cases in RIPE NCC, where bad people try to steal prefixes (as their value is rising), and that’s possible mostly because there aren’t good security measures in place in a lot of LIRs.

[6]

Before that, the university used a /35 from SpectrumNet (since then bought by Mobiltel), until they got their own allocation.

It should be noted that in IPv6, the renumbering is a lot easier than in IPv4 and this was done very fast.

[7]

Now, on the allocation policy,

[8]

this is how unicast addresses are assigned. It’s based on RFC4291, and for the basic entities in the university (faculties) there’s a /60, for each backbone network, server farm or virtual machine bridge there’s a /64, and all the additional allocations are the same as the initial size (on request).
Also, allocations of separate /64 are available for special/specific projects.

[9]

The university also utilizes RFC4139 addresses, for local restricted resources. The allocations are done on /32 basis.

[10]

Now, onto the intra- and inter-AS routing,

[11]

The software used is Quagga on CentOS.
There is a specific reason for using CentOS – the distribution is a recompilation of RHEL, and follows it closely, which means that it’s as stable as it gets – if there’s a security or other important update, just the pieces are backported to the current version of the software, which effectively means that you can have automatic updates running on your servers and routers and be confident that they won’t break horribly.
That’s in stark contrast with almost every router vendor I can think of.

[12]

The current transit providers for the university network are Unicom-B (the academic network in Bulgaria), and SpectrumNet (now owned by Mobiltel).
The university has private peering with Digital systems, Evolink (it changed it’s name from Lirex), ITD, Netissat and Neterra. It also provides an AS112 stub node.

(For the people that don’t know, AS112 is somewhat volunteer project run anycast nodes for the DNS servers for some zones that generate crap traffic, e.g. “example.com”, or the reverse zones for the RFC1918 addresses)

[13]

This is the basic schema of the external connectivity. The university has two border router, each of which is connected to both upstream providers (and to the private peers, but that would’ve cluttered the drawing too much). They’re interconnected through one of the MAN networks, and are in the Lozenetz campus (where the University Computing Center is, the main operator of the network) and the Rectorate.

[14]

These are the prefixes that the university originates. Here we can see why the university has a /47 – so it could be de-aggregated, for traffic engineering of the inbound traffic. That’s one problem that nothing has solved yet, and that would plague us for a lot more years…
Here each border router announces a /48, and both announce the /47, so they can effectively split the inbound traffic.

There’s also the IPv6 prefix for AS112, announced from both borders.

[15]

This is what every router should do for the prefix announces it receives. Basically, everything from a private ASN is dropped, and all prefixes that are not in 2000::/3 (the unicast part of the IPv6 space), are shorter than /3 or longer than /49 are also dropped.

[16]

Here you can see the schema of the backbone network – the two border routers, and the access routers of the faculties. They’re all under the administrative control of the network operations team.

[17]

For this schema to work efficiently, the two border routers do the job of route reflectors, and the access routers are route reflector clients – e.g. each access router has two BGP sessions, one with each border router, and that way it learns all the routes coming from the rest of the access routers.
This setup would’ve been unmanageable otherwise, as doing a full mesh of so many routers would’ve resulted in full mess.
[Ok, I didn’t think of that pun at the presentation]

[back to 16]

The initial idea was to actually have the border routers be route reflectors only, and have all the access routers in the VLANs of the external BGP peers, for the traffic to flow directly and not have the two borders as bottlenecks. This wasn’t implemented because of administrative/layer8-9 issues.

[19]

This is how the core network connects with the faculty networks – the access router is connected in a network with the routers of the faculty, and via OSPF (or RIP in some cases) it redistributes a default route to them.

(Yes, RIP is used and as someone told me a few hours ago, if it’s stupid and it works, maybe it’s not that stupid)

[20]

Now here’s something I would’ve done differently :)

Both OSPF and RIP are secured using IPSec, here’s how the config looks like.

[21]

This is not something that you usually see, mostly because it’s harder to configure and the weirdness in the interoperability of different IPSec implementations. For an university network, where risk factors like students exist, this provides a layer of protection of the routing daemons (which, to be frank, aren’t the most secure software you can find) from random packets that can be sent in those segments.
It’s reasonable to accept that the kernel’s IPSec code is more secure than the security code of the routing daemons.

This the only thing that this setup provides more than the other options – a pre-shared key is used, as there aren’t any implementations that have IKEv1 and can be used for this task.

Also, this is harder to operate and configure for untrained personnel, but the team decided to go ahead with the extra security.

[22]

And of course, there has to be some filtering.

[23]

Here’s a schema of one external link – in this case, to Neterra.

[24]

Here we can see the configuration of the packet filtering. This is basically an implementation of BCP38.

First, let me ask, how many of you know what BCP38 is?
[about 25-30% of the audience raise their hands]
And how many of you do it in their own networks?
[Three times less people raise their hands]
OK, for the rest – please google BCP38, and deploy it :)
[Actually, this RFC has a whole site dedicated to it]

Basically, what BCP38 says is that you must not allow inbound traffic from source addresses that are not routed through that interface. In the Cisco world it’s known as RPF (Reverse path filtering), AFAIK in Juniper it’s the same.

In Linux, this is done best using the routing subsystem. Here what we can see is that on the external interface we block everything that’s coming from addresses in our network, and on the internal – anything that’s not from the prefixes we originate.

[25]

Here we can see the setup on an access router (as we can see, BCP38 is deployed on both the border and access routers). Here we can differentiate and allow only the network of the end-users.

[26]

On the border routers, there’s also some filtering with IPtables, to disallow anyone outside of the backbone network to connect to the BGP daemon, and also to disallow anyone to query the NTP server.
(what’s not seen here is that connection tracking is disabled for the rest of the traffic, not to overload it)

[27]

On the access routers, we also have the filtering for the BGP daemon and the NTP server, but also

[28]

we filter out any traffic that’s not related to a connection that was established from the outside. This is the usually cited “benefit” of NAT and the reason for some ill-informed people to ask for NAT in IPv6.

With this, the big-bad-internet can’t connect directly to the workstations, which, let’s be frank, is a very good idea, knowing how bad the workstation OS security is.

[29]

The relevant services provided by the university have IPv6 enabled.

[30]

Most of the web server have had support since 2007.

The DNS servers too, and there’s also a very interesting anycast implementation for the recursive resolvers that I’ll talk in detail about later.

The email services also have supported IPv6 since 2007, and they got their first spam message over IPv6 in on the 12th of December, 2007 (which should be some kind of record, I got mine two years ago, from a server in some space-related institute in Russia).

[31]

ftp.uni-sofia.bg has been IPv6 enabled since 2010, it’s a service for mirroring different projects (for example Debian).

The university also operates some OpenVPN concentrators, that are accessible over IPv6 and can provide IPv6 services.

[32]

The coverage of the deployment is very good – in the first year they had more than 50% of the workstations in the Lozenetz campus with IPv6 connectivity, and today more than 85% of the workstation in the whole university have IPv6 connectivity.
(the rest don’t have it because of two reasons – either they are too old to support it, or they are not turning it on because they had problems with it at the beginning and are refusing to use it)

Around 20% of the traffic that the university does is IPv6.
[question from the public – what is in that traffic? We should be showing people that there’s actually IPv6 content out there, like facebook and youtube]

From my understanding (the university doesn’t have a policy to snoop on the users’ traffic) this is either to google(youtube), or to the CERN grid (which is IPv6 only). Yes, there actually exists a lot of content over IPv6, netflix/hulu have already deployed it, and it’s just a few of the big sites (twitter is an example) that are still holding back.

The university provides both ways for the configuration of end-nodes – Router Advertisement (RA) and DHCPv6. For most cases they’re both needed, as RA can’t provide DNS servers, and DHCPv6 can’t provide a gateway (which is something that’s really annoying to most people doing deployments).

[33]

Here’s how the default route is propagated in the network.

[34]

This was actually a surprise for me – there are actually two default routes in IPv6. One is ::/0, which includes the whole address space, and there is 2000::/3, which includes only the unicast space. There is a use for sending just 2000::/3, to be able to fence devices/virtual machines from the internet, but to leave them access to local resources (so they can update after a security breach, for example).

[35]

Here is how you redistribute ::/0, by first creating a null route and adding it in the configuration.

[36]

And here’s how it’s propagated in the network, using OSPF.

[37]

We can do the same for 2000::/3,

[38]

and push it to the virtual machines, who also have connectivity to the local resources through a different path.

[39]

Now, this is something very interesting that was done to have a highly-available recursive DNS resolver for the whole network.

[40 and 41 are the same, sorry for the mistake]

[41]

This is how a node works. Basically, there’s a small program (“manager”) that checks every millisecond if the BIND daemon responds, and if it’s just starting, it adds the anycast resolver addresses to the loopback interface and redistributes a route through OSPF.

(note the addresses used – FEC0::.. – turns out that this is the default resolver for MS windows, so this was the easiest choice. Seems that even in the land of IPv6 we still get dictated by MS what to do)

[42]

If the name server daemon dies, the manager withdraws the addresses.

Also, if the whole nodes dies, the OSPF announce will be withdrawn with it.

[43][44][43][44][43][44]

Here you can see what changes when a node is active. If one node is down, the routers will see the route to the other one, and send traffic accordingly.

[45]

And if they’re both operational, the routers in both campuses get the routes to the node in the other campus with lower local preference, so if they route traffic just to their own, and this way the traffic is load-balanced.

[46]

Thank you, and before the questions, I just want to show you again

[3]

the people that made this deployment. They deserve the credit for it :)

[In the questions section, Stefan Dimitrov from SU stood up and explained that now they have three border routers, the third one is at the 4th kilometer campus]

И мина RIPE-SEE-3.

Проведе се в х-л Кемпински, за два дни, беше с малко лекции/workshop-и и доста разговори/networking (видях се с хора, с които не се бях виждал от 10+ години).

Пропуснах първите неща от първия ден, че бях зает да си нося лаптопа на ремонт (и все пак да се наспя), та хванах сесиите след обяда. Първо слушах човека от DT по темата за новата мрежа, която правят (TeraStream) – интересна идея, забавното беше как чак 2011 осъзнали, че мрежата им е остаряла и не става, но па сега я правят както трябва – чист ipv6 (ipv4 е service с тунели отгоре), 100gbps и anycast на интересните услуги. Също така им е хрумнало в адреса да слагат няколко бита, които да играят ролята на QoS битовете, и да раздават няколко префикса на потребител, например един за видео/телевизия, един за voice, един за internet, и мислят как да стандартизират процеса за избиране на source адрес.
RIPE разказаха за различните неща, които правят – конференции и т.н., Erik Vinecke от cisco разказа нещо за мерене на ipv6 deployment-и, което заедно със следващите две неща не слушах, понеже си препрочитах моята лекция.
(чух някакви части от лекцията на Nathalie Trenaman за нейния deployment на ipv6 у тях, и си беше интересно и доста мъчително, Мариян я пита във въпросите що се е мъчила да се занимава с vendor-и, вместо да ползва opensource неща)

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

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

Втория ден започна с лекция за Ansible (което се оказа някакъв вариант на chef/puppet/cfengine), нищо интересно, след което имаше доста интересна лекция за “Crowdsourcing Infrastructure Geolocation”, т.е. проект, който по различни начини определя къде се намират ip-тата на разни router-и, за да може човек да си визуализира traceroute (note to self, да си оправя всичките DNS LOC записи). Искрено се надявам проекта да успее :)

От следващите неща слушах IXP панела, където от няколко български exchange-а, един чешки и (май единствения) сръбски хората обсъждаха различни оперативни неща. За съжаление не успяха да стигнат до техническата част, но доста дъвкаха for-profit и non-profit моделите, което пак беше интересно.

Следващият слот беше по “Governance” темата и привлече най-страшните въпроси. Първо говори един човек от CERT България (който не беше лектора по програма) и беше в общи линии изяден с парцалите, понеже нищо не знаеше.
После говори Венета Донова за net neutrality-то в Европа и в България, основно за законовите моменти около него – беше разширение и update на лекцията и от openfest (ако не се лъжа), и се получи доста добре.
Последва я Аглика Клайн от Europol EC3 – отдел, който се занимава с техническата част на разследванията, анализа и координиране на операции. В общи линии въпросите към нея бяха “защо да ви вярваме”, “вие сте тия, дето ни тровят най-много живота”, спряхме се на това как детското порно се използва основно срещу доставчиците (имаме си достатъчно такива случаи в България) и т.н., и т.н.. Успя да издържи на въпросите, но се измъкна от някои въпроси. Имаше и момента, че от една страна нямат право да приемат feedback и каквото и да е от хората или фирмите (само от държавите-членки), но от друга страна са пускали по молба на microsoft advisory, да кажат на хората, че XP-то спира да се поддържа.
(после имаше и допълнителни разговори и обяснение как една от причините никак да не ги обичаме е, че ги използват много усилено срещу нас, и че те са от хората, които трябва да се борят за улесняване на security research-а, не срещу него (както са направили в Германия със забраната да се пишат exploit-и), трябва да и пратя на FX лекцията за хардуера, който law enforcement хората ползват и колко е счупен)

Имаше три lightning talk-а, от които единия беше за BGNOG-а (който споменах по-горе), успяхме да стигнем от идея до реализация за около 12 часа.

В последният слот интересните лекции бяха две. Едната беше за RIPE Atlas проекта, и за anchor машините (за които мисля да взема една в нашия datacenter, Мариян се замисли за три), самият проект има лесен начин да се интегрира в monitoring системите ми и мисля тия дни да му отделя малко време. Другата лекция беше сравнителен анализ на internet-а в България, Турция и Румъния, гледан от BGP гледна точка, от Renesys – накратко, в Турция нещата не са добре, при нас и в Румъния са доста по-чисти, като в Румъния са около три пъти по-големи. Удобни сме от гледна точка на латентност за финансови и т.н. институции да си слагат тук нещата, дано успеем да се възползваме.

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

Update: Трябваше да привлачим и Яна на събитието, понеже изкарах накрая поне половин час да давам идеи как да привлекат повече хора – имаше около 220 дошли, и те го считаха за голям успех, но аз си мисля, че даже чистите мрежови администратори в България са поне 150-200 и щеше да им е интересно да дойдат. Едното нещо, което може да помогне е NOG-а, другото – просто да си говорят директно с някакво количество хора/LIR-ове, не през някакви тежки mass mail-вания до адреси от базата им, щото тях никой не ги чете сериозно.

Update 2: Сайт с наземни кабели, за който не знаех (като допълнение на за подводните).

“Чичо Тони, тримата глупаци и ДС” (и трейлър).

Почти никой не прави у нас филми, дето да си заслужават времето дори да ги изтеглиш, какво остава да ги гледаш. Явно па тези, които си струват, се намира кой да ги преследва и да се опитва да ги спре/забрани.

Весела Казакова е направила филм за човекът зад голяма част от анимациите, които се водят на Доньо Донев, и който не е признат основно защото ДС не са го харесвали. Пробвайте се да отделите малко време, да не трябва да се примиряваме с “Хубав е филма, като за български”.

Весела Казакова е говорила пред Капитал по темата.

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

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

А аз в неделя сутрин докато тихичко си работех ми опука дисплея на лаптопа, та по случая тия дни ще съм малко offline през деня (ще съм на RIPE SEE-3 и ще съм малко ограничен в това кога ще мога да съм си пред машината).

(имах един таблет с мен и от него свърших някакви неща, ама клавиатурата му е нечовешка. Добре поне, че gps-а му работеше добре и че offline картите на OSM са точни, та да ми е полезен)

И днес беше деня на посещението в Аушвиц.

(четох си по пътя “Dominion” на C.J.Sansom, частта в която изселват евреите в Англия, беше странно)

Обиколката продължи няколко часа – първо в Аушвиц 1, после в Аушвиц 2 – Биркенау. Първият лагер е доста по-малък, вторият прилича на набор бараки за животни посред полето. Доста са запазени, особено телените огради и доста от сградите, и си е интересно да видиш на живо как са изглеждали нещата (и например как изглеждат два тона човешка коса). Не мисля, че преживяването е за хора с по-слаби нерви, нищо, че екскурзоводите са доста внимателни и се стараят да обясняват спокойно и нетормозещо.

Жалко, че няма така запазени лагери от ГУЛАГ-а, да може да се направи едно хубаво сравнение.

И дойде време да си използвам странния подарък за рождения ден – екскурзия до Аушвиц/Биркенау (Освиенцим).

Полетът ми беше в нормално време и с online checkin-а даже идиотското задръстване по Цариградско шосе не беше проблем. Летях през Виена и стигнах съвсем спокойно в Краков (само в последния полет имаше някакъв пиян руснак с трима цивилни полицаи около него).

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

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

Та, аз мисля да се излежавам, чета и може да попиша по една лекция, ако на някой му трябвам – няма ме :)

(обществено-полезната работа я свърших, писах mail на админа на www.uni-sofia.bg, че са vulnerable за heartbleed проблема)

Не че не сте видели от други места, но:
DSA-2896
heartbleed.com
официалния сайт на openssl.

apt-get update && apt-get -y dist-upgrade и ритнете каквото трябва.

(алтернативното заглавие беше fuckfuckfuckfuckfuckfuckfuckfuckfuckfuck)

Update: Сайт, който тества за проблема.
Update 2 command-line test tool.

RIPE SEE-3 ще се проведе следващата седмица в София. Ще има двама български лектори (Венета Донова и аз), публикували са програма, ако искате да дойдете, все още може да се регистрирате.

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

(и определено можеше да е по-добре, не става добре да говоря на конференции, където имам занимания и с организацията)

Single points of failure

[за какво става въпрос]

Single point of failure е единичен компонент от система, при чиито отказ цялата система спира да работи.

В системите, които правим/ползваме и са повече от един сървър, на който ни е всичко (т.е. един гигантски SPOF) такива неща пак се срещат доста често.

[авиационен модел]

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

[авиационен модел 2]

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

Също така системите стават твърде усложнени, като пример – A380, който е наистина подсигурена система, има в себе си 530км кабели. Цената да се изгради и да се поддържа такава система не е по силите на някой друг.

[три неща]

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

[Софтуерни]

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

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

[Meatware]

Човешките SPOF-ове са още по-гадна работа. Известни са още като “Bus factor”, т.е. колко човека трябва да ги блъсне автобус, за да спре да работи даден проект (и в много случаи факторът е 1).

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

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

[цена]

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

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

[state]

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

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

Искам да го повторя и да покажа, не съществуват stateless системи.

[примерна не-stateless система]

Ето един често срещан пример – смята се, че ако имаме такава схема, то web сървърите ни са stateless, понеже реално са взаимозаменяеми.

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

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

[решения]

Ето няколкото типа решения на проблема.

[do nothing]

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

[backup plan]

Може да не е толкова безсмислен като тоя от слайда :)
Тук решението е да знаем какво правим, ако нещо се счупи. За някои по-малко важни системи например backup plan-а може да е “машината е в гаранция, ако се счупи нещо, обаждаме се на тия от които сме я взели и така”, или “обаждаме се на другарче”.

[cold spare]

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

Това е и едно от най-често срещаните решения, понеже доста лесно се прави. От друга страна може да предизвика прилично количество donwtime, докато се “стопли” резервата.

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

[hot spare]

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

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

Тук има един специфичен момент, т.нар. fencing – ако втората система поема работата на главната, трябва по някакъв начин да се гарантира, че главната е спряла и не прави нищо, за да не се стигне до омазване на shared state или нещо такова. За целта има няколко типа решения, някои от които просто спират тока на главната :)

[CAP теорема]

И така, преди да си говорим за най-хубавия начин – да имате N на брой машини, те да вършат едновременно работа и хем да се scale-вате, хем да сте защитени от сривове, да кажа защо това е непостижима мечта…

Теоремата е съвсем проста и гласи следното: една дистрибутирана система може да има най-много две от следните три свойства: Консистентна, винаги достъпна, издържаща разделение.

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

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

Издръжливостта на разделение значи, че не може да се достигне т.нар. split brain ситуация – ако системата се раздели на две части, не може двете да мажат в/у данните и да се получи при тях различна версия.

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

[дистрибутиране]

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

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

[load ballancers + web]

Това е един доста класически случай за повечето сайтове, на които не им се иска да имат downtime. Слагате отпред два load ballancer-а, които знаят кой от web сървърите отзад работи и балансират м/у тях заявките. Това работи много добре, сравнително стандартизирано е и сглабянето му не отнема особено много време. Достатъчно стандартно е, че amazon да предлагат компонентите му като някакъв service.

При отпадане на компоненти системата го усеща и спира да му подава трафик.

RAID масивите са доста близки като идея до това.

[синхронни бази]

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

[hack-ът за eventual consistency]

И има една добавка, като удобен hack при системи, при които има случаи, в които може да се прочетат стари данни, т.нар. eventual consistency.

В общи линии това представлява система, за която операциите за писане са приключили при запис в X компонента, като обикновено X=N/2 + 1. Тогава имаме inconstent четене, което може да чете от 1 компонент, и ако ни трябва консистентно, четем от N-X+1 компонента. Това се използва основно за системи, при които консистетният read е рядка операция.

[sharding + replication]

Това е текущият метод за репликиране на база данни. В общи линии умножавате факторите за на колко искате да разделите данните (за performance) и за redundancy и получавате колко железа ви трябват (в случая са 2X2).

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

Преди няколко седмици излезе първото издание на “Is Parallel Programming Hard, And, If So, What Can You Do About It?” – книга под creative commons на Paul McKinley (по принцип kernel developer). Полезна е и информацията в нея е доста прясна и точна (а и като гледам, голяма част от нещата там не са се променяли от доста време, и има неща като RCU, memory бариери и т.н.) и я препоръчвам на всички.

Аз разпечатах десетина копия, и в момента има по едно в initLab, VarnaLab, BurgasLab и hackafe, като се планира втори print run, ако има хора, които имат желание да си вземат. Цената ще е около 30лв на копие, ако имате желание, пишете.
(или може да си я четете online или да си я разпечатате сами, не е сложно:) )

Мина RogueConf 2014. Направихме го тоя път в Боровец, в х-л Radina’s way, и си изкарахме доста добре.

(записи)

(има странен момент с името. На разни материали беше объркано и беше Rougeconf (“розова конференция”), та това в един момент стана официалното име. Мисли се догодина да е RoughConf (а ако Стефан реши да е RogeConf, аз няма да ида))

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

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

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

От лекциите мога да препоръчам:

“Storpool – Reinvent all the wheels” на Боян Кроснов (трябва да я направи в два часа);
Общество.бг на Димитър Димитров(lightning talk)
“СофтУни – докъде сме с проекта” на Светлин Наков (голямо шоу);
Maycamp arena на Валентин Михов – невероятно идеен и готин проект, силно препоръчвам;

Разходка през съвременния CPU pipeline на Борислав Станимиров – освен, че беше много добре описано, беше и ултра забавно, страхотна лекция за всички, които искат да разберат как работят модерните процесори;

…и като цяло да разгледате всичките лекции.

А от не-лекциите, Стефан жонглира.

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

(за “масонския” елемент, т.е. че беше invite only и пак някакви хора се оплакват, че не са поканени – нещастните от това хора могат да си организират собствена и да не ни канят)

Update: Явно много ми се е спяло снощи. Още няколко интересни неща:
Боби трябва да направи някой ден лекция с резултатите от трите мъжки въпроса, които задава;
Титов направи интересен кратък talk за linux fibers, в който за съжаления няма код, но е едно от по-забавните неща, които сме правили в последните няколко месеца;
Аз разказах на хората какво е ИББ и защо трябва да има повече такива събития;