2015-04-19

April 19th, 2015 by Vasil Kolev

Първа сбирка на курса.

2015-04-16 “На ръба” в народния театър

April 16th, 2015 by Vasil Kolev

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

Представлението само по себе си беше гадно.

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

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

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

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

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

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

Накратко, иска ми се да кажа на автора, че не е прав и че и майка му не е права.

2015-04-15 end-to-end криптография за домашна/фирмена употреба

April 15th, 2015 by Vasil Kolev

Питаха ме тия дни “как да си говорим без да ни подслушват”, и понеже е просто, ето какво препоръчвам аз (и съм ползвал). Това не включва operational security неща (не говорете близо до други хора, не си качвайте записите някъде, не си давайте компютъра на непознати и т.н.), а само как да си направим setup, който може да се използва правилно. Базиран е на неща, които аз съм правил, т.е. конкретните препоръки са от моята практика.

Идеята е да имате end-to-end криптография (т.е. само крайните точки да могат да декриптират информацията) и forward secrecy (т.е. ако случайно някой ключ изтече, това да не дава възможност да се подслушва бъдещата комуникация). Това се постига с два протокола – OTR и ZRTP.

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

Като за начало – някакво собствено желязо, с криптиран диск, с debian stable и автоматични security update-и.
Ползвам debian, понеже си е стабилно и security update-ите работят както трябва и не чупят системата.
Криптирания диск е допълнителна мярка за сигурност. Реално на сървъра няма да пазите кой-знае каква важна информация, но си остава добра идея. Това влачи със себе си проблема, че на рестарт някой трябва да въвежда passphrase, но за това има начини да се прави по сравнително сигурен начин.
Виртуалните машини са твърде лесни за атака, че да се разчита на тях. Вариант са, защото при тоя setup данните не са чак толкова важни, но не ги препоръчвам.

Понеже всичката комуникация ще върви по TLS, е добре да си имате правилно подписан сертификат. Всички сме наясно, че сигурността на сертификатите е малко трагична, но помага понякога да се хванат разни MITM атаки. Има сравнително евтини CA-та, като скоро и ще работи това на EFF, което ще е съвсем безплатно.
Ако искате да избегнете всичките възможни атаки, може да си направите собствено CA и да го инсталирате по клиентите, но е по-сложно и доста често не се спазва както трябва и просто се казва на клиента да приема всякакви сертификати, което е лоша идея.

Следващата стъпка е XMPP (Jabber) сървър. Аз лично използвам ejabberd, понеже е сравнително прост за конфигурация, бърз и ако не трябва да дебъгвате S2S, направо идеален.
В него трябва да спрете некриптираните връзки като цяло, и да не включвате S2S (server-to-server) модула, така че да е ясно с кой говорите. Можете да си включите и конференциите, но за тях още няма end-to-end криптография.

Финално, трябват ви open-source клиенти, които да поддържат двата протокола (OTR и ZRTP). По принцип jitsi поддържа и двете и е доста добър избор (въпреки че е доста тежко и писано на java), като работи под всички desktop операционни системи и има alpha за android. За телефони (ios и android) за съобщения има chatsecure (само OTR). Също така аз самия ползвам pidgin с OTR plugin, който обаче няма ZRTP (и като цяло много кофти аудио поддръжка).
(някой може да допълни с още клиенти)

Този setup ви дава възможност да си говорите с end-to-end криптография и да сте много трудни/невъзможни за подслушване (по последните документи от NSA, OTR е нещо, за което не са намерили никакъв вариант да го счупят).

2015-04-09 Нов не-курс

April 8th, 2015 by Vasil Kolev

И ще правя новия курс. Подробности има на https://sa.ludost.net/?p=49, съвсем накратко:

Пак ще е не-курс;
Ще се провежда в initLab;
Такса – да сте член на лаба по време на курса;
Ще представлява да си правим ISP;
Желаещите да участват да се запишат в SA mailing list-ата.

Update: Понеже съм пропуснал да кажа, вероятно ще се провежда съботите от 14:00.

2015-04-05 Лекцията ми от “Дните на софтуерната архитектура”

April 5th, 2015 by Vasil Kolev

Водих лекция на темата инфраструктура на “дни на софтуерната архитектура”. Нещо не се хареса на публиката, но се надявам да е по-смилаема в текстов вид.

Ето и презентацията.

[slide 2 Кой съм аз]

Здравейте.

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

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

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

[slide 3 За какво ще ви говоря]

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

[slide 4 За какво няма да говоря]

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

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

[slide 5 Какво имам в предвид под “state”]

И ще искам да изясня един-два термина, които ще споменавам от време на време в лекцията си.

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

[slide 6 Какво е инфраструктура?]

Терминът “инфраструктура” буквално значи “структурата отдолу”, т.е. това, на което се крепите (например подът и столовете в залата са инфраструктура, както и климатизацията и, електричеството и т.н.). Може да мрежите, които ползвате, може да е директно разни услуги (всичките “cloud” неща могат да се кръстят “infrastructure as a service”), но е нещо, което не контролирате пряко и на което разчитате.

То може да е и на сравнително високо ниво, като база данни, web или application сървър, в зависимост от това вие къде се намирате.

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

[slide 7 CAP теорема]

И нещо доста важно, т.нар. CAP теорема – която казва, че ако имате дистрибутирана система за съхраняване на state (т.е. например база данни), тя може да има само две от следните три свойства: консистентност (данните да са същите и на двете места), достъпност (винаги да работи) и partition tolerance (да може да работи при разцепване). Има някои подробности по дефиницията на консистентност и доколко съвпада с дефиницията от реалния свят, но за нашите цели теоремата важи в този си вид, и накратко ни казва “трудно е да се направи дистрибутирана база данни”.

[slide 8 ]

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

Забелязвате ли как съм кръстил схемите “сферичен кон”? Това, защото в реалния свят системите изглеждат ето така:

[slide 9 ]

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

[slide 10 Каква е моята работа]

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

[slide 11 ]

Single points of failure са може би основния проблем, който съм виждал в практиката.

[slide 12 ]

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

[slide 13 Как се създават в софтуера]

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

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

[slide 14 Как се избягват]

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

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

[slide 15 Дистрибутиран/подсигурен state (1/2)]

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

[slide 16 Дистрибутиран/подсигурен state (2/2)]

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

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

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

[slide 17 Всичко останало]

Та, както казах всичко останало се решава лесно с дублиране и load balancing.

[slide 18 ]

На схемата може да се види един не-толкова-сферичен кон, просто дублирана система, при която няма какво да отпадне, че да ни направи генерален проблем (може би с изключение на връзката към internet :) ).

[slide 19 TL;DR]

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

[slide 20 ]

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

[slide 21 ]

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

[slide 22 Накъде вървим]

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

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

Като пример мога да дам, че в момента един от най-бързите архитектурни модели за правене на сървъри, които process-ват много заявки е на принципа на co-routines, познати в windows-кия свят като “fibers”, а в erlang като “actors”. Идеята е, че вместо да имате цели thread-ове, които да изпълняват всеки по дадена задача, имате гигантско количество малки задачки, които се schedule-ват и изпълняват когато им е възможно. В книгата “The performance of open-source applications” има два такива примера (за съжаление на erlang и на haskell), но ако някой се интересува, мога да разкажа за такова решение с човешки езици за програмиране, която трябва да се появи като open-source някой ден.

[slide 23 Какво следва]

Това ни води до няколко важни неща, идващи от паралелното програмиране.

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

Трябва да избягваме зависимостите, доколкото можем, както и създаването на bottlenecks – единични компоненти, през които трябва да мине всичко (и които освен това ще са single points of failure).

[slide 24 ]

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

[slide 25 Всичко е мрежа]

Например вече всичко е мрежа. От вътрешната архитектура на процесорите, през дънните плати, SATA/SAS – всичките тези технологии представляват някакви мрежи в звездоподобна технология, със switch-ове и router-в тях, по някакви собствени протоколи. Да не говорим, че вече почти нищо не ни е локално (например базата данни ще ви е на същата машина само ако сте много малка услуга).

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

[slide 26 List of network fallacies]

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

[slide 28 Internet и мрежите не са reliable]

Да почнем от там, че internet и мрежите като цяло не са reliable. Нямате гаранция за нищо, всичко е best-effort и за да постигнете някаквите си нужни гаранции е необходимо да вкарате логика при вас, която да се справя с такива проблеми.

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

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

[slide 29 Да забравим латентността]

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

Един прост пример, който мога да дам е, че по принцип SSL протокола прави от 3 до 6 round-trip-а, т.е. отивания на пакети от единия до другия край, за да осъществи връзка. По принцип ако си говорите със сървър в същата държава, едно RTT е под 20ms, и това няма да се усети лесно като проблем, но ако говорите от Европа до Щатите и едно rtt е 150ms, изведнъж тази разлика става наистина осезаема – потребителите започват да усещат забавянето и да не искат да ви ползват сайта. Това може да се реши в софтуера с настройка на самия SSL протокол, но малко хора се занимават да му обръщат внимание.

[slide 30 Твърде много данни по твърде малка тръба]

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

Има неща от типа на remote dma – т.е. да накарате две системи да си предават данни, вместо да ги копирате през себе си. Може да погледнете bittorrent протокола и какво умее – в момента това е най-бързия начин за прехвърляне на информация до много места в internet.

[slide 31 Голи данни по пробита мрежа]

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

На теория трябва да се криптират само важните данни, но понеже няма начин да се определи кои данни са важни, е далеч по-лесно и по правилно да се криптира всичко.

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

[slide 32 Мрежата ще отговаря на всичките ви изисквания]

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

[slide 33 … и т.н.]

Мрежите са нещо прекрасно, те са бъдещето, пътя, истината и живота :) Могат много да ви помогнат, могат да ви съсипят и е важно да ги познавате в подробности.

[slide 34 ]

И ще поговоря малко по темата дизайн на системи, понеже има голямо отношение към инфраструктурата и комуникацията с нея. Ще започна с нещо просто, разликата м/у store&forward архитектури и pass-through.

[slide 35 Дефиниция]

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

[slide 36 Примерна система]

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

[slide 37 Предимства и недостатъци]

Тук и двата начина си имат предимства и недостатъци. Pass-through има по-ниска латентност, което понякога може да се окаже наистина важно, но от друга страна може да се претовари по-лесно и е по-чупливо от store&forward. Pass-through и са по-сложни за дистрибутиране.

[slide 38 Извод]

Pass-through като цяло е доста по-ефективно решение, ако ви е нужна скорост, но препоръчвам store&forward за всичко, което не е критично – може да издържи доста повече на проблеми и по-лесно се възстановява след проблеми.

[slide 40 ]

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

[slide 41 (почти) Всичките ни системи са комплексни]

Ние почти нямаме линейни системи в практиката. Всичко, което правим има странни интеракции в него и е огромно като размер. Дал съм пример как Airbus A380 без да броим софтуера има 4 милиона компонента, а само linux kernel-а е над 12 милиона реда код, или ако го компилираме, в себе си има над милион условни прехода.

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

[slide 42 Тъжни факти]

Ние на практика нямаме толкова голяма система, която наистина да разбираме, която да може да бъде разбрана от един човек – а от друга страна очакваме, че всеки един програмист може да се справи със съществуващите ни системи. Като комбинираме това, че средно имаме по 10-15 грешки на 1000 реда код в изтествани и release-нати продукти е учудващо, че нещо изобщо работи.

В механичния свят е по-лесно да направим система, с чиито failure mode-ове да сме наясно при отпадане на един или два компонента – например сме сравнително наясно с двигателите на колите, но реално погледнато всичко по-сложно от това ни е сложно.

[slide 43 Може да се мине със следния цитат]

Винаги обичам да давам този цитат. За който не е запознат, Jim Gray е човекът, измислил голяма част от теорията за backend-ите на базите данни, които ползваме в наши дни (например цялата ACID идея).

[slide 44 Изроди]

Изводите мисля, че са ясни, нека да правим прости неща, доколкото можем, и да се стремим към простота. Неколкократно съм виждал система да бъде реализирана добре в 10к реда код, и лошо в 100к, и си мисля, че си заслужава усилието да правим минималистично нещата.

[slide 45 ]

И ще приключа с нещо наистина страшно.

[slide 46 Какво е bitrot]

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

[slide 47 Статистика от wikipedia]

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

[slide 48 Случки от реалния свят]

В една система с 395 милиона файла имаха около 300 грешки в рамките на месец, и в последната седмица – 3 (това беше проверка по sha1 checksum-а на файловете). Това са свестни, малко по-стари сървъри, с raid5 масиви, а софтуерът е съвсем малко и много внимателно изтестван и прегледан – и все пак се появяват такива проблеми. Скоро 1PB няма да е огромно число, а нещо нормално и очаквано, и можем да очакваме при всички ни да се видят такива проблеми.

И нещо още по-неприятно – едни приятели имат софтуер, на който правят сериозни regression test-ове. В техния lab се появили някакви crash-ове, които се появявали по странно време без никаква логика, и след известно време открили, че това се случва само на сървърите без ECC памет. Машините имали 16-32 GB памет и не са били купувани на битака :)

[slide 49 row-hammer exploit]

И, нещо съвсем скорошно, т.нар. row-hammer exploit, че ако пишете много някъде по паметта, можете да flip-нете бит на друго място. С това даже бяха успели да напишат и exploit, с който да може през browser-а и sandbox-а му да се излезе и да се получи root достъп.

[slide 50 Инструкции за цивилното население]

Това е ужасно.

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

[slide 51 ]

И няколко книги, които могат да са ви полезни:

* “The Architecture of Open-source Applications”, vol. 1 и 2
* “The Performance of Open-source Applications”
* “Beautiful Data”
* “Normal Accidents: Living with High-Risk Technologies”, Charles Perrow
* “Cryptography Engineering”, Schneier, Ferguson & Konho

2015-04-01 presentation build system

April 1st, 2015 by Vasil Kolev

(мразя днешния ден, та да взема поне аз да свърша нещо полезно)

Тия дни около курса по мрежова сигурност си update-нах системата за build-ване на презентации и съответно съм я качил в github. Бая улеснява живота:

– Може да си добавяте картинки както си искате, системата ги resize-ва и следи коя презентация от кои зависи и я rebuild-ва;
– Както и преди, може да си пишете текста на презентацията заедно със слайдовете и се extract-ва автоматично;
– Може да си правите страници със заглавия ( ‘###’ и на следващия ред ‘#### някакво заглавие’ и ще запълни цялата страница с него);
– Вече няма нужда да пишете каквото и да е в Makefile-а, той автоматично захапва всички .pandoc файлове в текущата директория.

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

2015-03-26 drop database

March 26th, 2015 by Vasil Kolev

Днес получих поредното потвърждение за любимия си израз “Системният администратор се учи на гърба на потребителите”.

Правехме някаква миграция на obshtestvo, и около нея се налагаше няколко пъти да се drop-ват и преналиват едни бази. Хванах се на няколко пъти как съм пуснал DROP DATABASE и чак след това съм погледнал къде съм го пуснал, и не го бях сбъркал нито един път.
(нещото беше малко под пара, иначе гледам да правя нещата по-бавно)

Това не-сбъркване е продукт на МНОГО омазвания преди това, изгубени данни, възстановяване от backup-и и псуване. Трябва да има такива практически, реалистични упражнения и занимания за хората, които се занимават с админстване, просто защото “добрите практики” не стигат, особено като човек бърза, а аз още твърдя, че добър админ се познава по това как се справя като го вдигнат в 4 сутринта с махмурлук…

И по темата, тия дни се каня да си обявя новия не-курс, подробности за това – скоро.

2015-03-12 Отмениха задължението за data retention

March 12th, 2015 by Vasil Kolev

Днес Конституционният съд на Република България обяви за незаконен data retention-а (сезиран от Омбудсмана по молба на Асен Тотин). Днес по-късно се чака пълното мнение на съда, но като цяло задължението на ISP-тата по въпроса отпада.
(самите членове от закона може да се видят тук, вече има и новина с подвеждащо заглавие)

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

2015-03-08 RailsGirls – март 2015

March 8th, 2015 by Vasil Kolev

Този петък и събота се поведе поредното издание на Rails Girls Sofia. Аз бях там да помагам инфраструктурно, и около някакви разговори стигнах до странни изводи…

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

RailsGirls е социална програма на IT обществото. Тя цели да помогне на едно малцинство (жени, които нямат никакъв опит и твърде малко опции) да видят какво представлява програмирането, какво могат да правят те и дали би било подходяща област за тях. Като цяло целият формат е ориентиран така, че в ден и половина да може да покаже достатъчно основни неща, за да си изяснят хората какво е това програмирането, какво иска като мислене и дали да продължат опитите да се занимават.
На теория от това не трябва да има никаква нужда – това трябва да се случва с всички хора в училище (заедно с много други варианти за професионално развитие), където хората да са придобили някаква основна представа, след което да могат и след 10-20 години да решат, че това им е интересно и да седнат да го учат (я с online курсове, я в разните софтуерни академии, или във ФМИ на СУ или ПУ). Реално обаче в момента нивото на преподаване на информатика не се подобрява, а върви в посоката “да обясним на децата как да са юзъри” (против което ние едно време правехме опити да се борим, и май пак трябва).

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

(и който не е щастлив от това, което се прави, може да се заеме да направи нещо по-добро. Ще помагаме даже…)

2015-03-01 мина крокодиловден

March 1st, 2015 by Vasil Kolev

Отпразнувах пак крокодиловден. Направих го на 27ми, понеже 23ти се падаше в понеделник, а от МТСП ме помолиха да не се пада преди работен ден, че от колективния махмурлук БВП-то на страната видимо падало.

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

Следва стандартния списък подаръци, доколкото успявам да се сетя:
Бутилка Laphroaig (Мартин);
Бутилка Glenfiddich (Щеряна);
Котка (звучи ето така), или по-точно Digitech bass synth wah ефект (bofh);
Билети за Apocalyptica в Пловдив (там съм ги слушал за пръв път преди бая годин) (iffi и Калоян);
Ваучер за Декстрофобия и един за 3keyrooms (едното от Ива/Калоян, другото от Явор/Таня и още някой, не помня кое как се падаше);
смарткарта за pgp ключове и четец за нея от Merlijn и Моника (ще си сменям явно ключа тия дни);
Един zero-day от RealEnder (тестван, работи, да видим дали иска да го публикува);
Бинокъл (не помня от кого);
Мегафон, ще свърши добра работа по конференциите (Пешо);
Лампа и крушка за нея (Пенчев, Велин, Боян), че нямало у нас достатъчно приглушено осветление (замислих се да си взема още 2-3);
Lego, някакъв багер (Боян), разни хора изявиха вече желание да идват у нас да го сглобяват;
Метроном (Кънев) (без коментар);
Книгата “Плетене на една кука for dummies” (Никсън);
Книгата “Никой не обича крокодила” (Бобсън), някаква древна руска от 1974та;
Мангата “Fullmetal alchemst”, 1ви том (Антоанета);
Книгата “Алекс” на Пиет Льометр (Бойчо);
Книгата “Уискито на Шакълтън” на Невил Пийт (Миши), заедно с една картичка, която вероятно Снежи няма да ми разреши да сканирам и кача, но е много забавна;
“Книжка за зайчетата-самоубийци” (Владо младшия) – питайте google за bunny suicides;
Торбичка желирани крокодили (fredson);
Една рисунка на глухарчета (Нели);
Плато за сервиране на мезета (Мариела и Румен);
Чаша с крокодил в нея (нещо такова) (Румен);
и финално, майсторски клас за уиски тестване (от голяма група хора – Митьо, Стефан, Боян, Яна, Марио, Владо Василев, Стеф, Витков, Недко, Точо, Петко, Мариян, dzver, Кунев и Гери, Благовест, Печкин, Пламен и pCloud-ския екип), както и торба родопски био-картофи.

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

Ако се сетя/открия още нещо, ще дописвам.

Update: Също така едно bonsai дърво (от Наков), което май не става за ядене.

2015-02-27 Reverse engineering for beginners

February 27th, 2015 by Vasil Kolev

Тия дни приключих с първата редакция на Reverse Engineering for Beginngers на Денис Юричев, и снощи ми е merge-нал последния pull request.

Книгата е много добра за начинаещи не само в reverse engineering-а, но и за хора, които искат да видят как работи отдолу асемблера и какво генерират компилаторите. Пълно е с всякакви интересни факти и като цяло не е много за четене (въпреки че генерираният pdf е около 950 страници). Има вид на подходящ учебник за един нормален едносеместриален курс, та даже някой може да реши да пробва да води по него :) Книгата е под creative commons лиценз, и може да се ползва за всякакви цели.

По принцип source на книгата може да се намери в github, авторът приема смислени редакции. Аз мисля да направя втори пас за редактиране, понеже досега оправях английския да звучи като английски и да е ясен, но може да се направи доста по темата да звучи наистина добре. Ако някой може да помогне с нещо друго (LaTeX-а не е чак толкова сложен), няма лошо да праща :) В todo-то на автора има “MIPS, Objective-C, Visual Basic, anti-debugging tricks, Windows NT kernel debugger, Java, .NET, Oracle RDBMS”, а в самата книга на доста места има “TODO” (например да се опишат в appendix A разни SIMD x86 инструкции).

2015-02-24 CitizenFour

February 24th, 2015 by Vasil Kolev

Преди ден-два Citizenfour спечели Оскар за най-добър документален филм, а вчера в Reddit имаше AMA с Glenn Greenwald, Laura Poitras и Edward Snowden.

Филмът трябва да се гледа.

Което и вече е доста по-възможно, защото въпреки че няма release-нато DVD, поради едно дело срещу филма той официално е in the public record, т.е. public domain (новина в hackernews, съдебно решение) и по случая може да се свали от cryptome, или от mirror-а при мен (свалил съм само HD версията).

Ако има желаещи, може да организираме и още една прожекция в initlab (направо да направим double feature заедно с The Internet’s own boy, филмът за Aaron Swartz).

Update: Филмът вече е и в archive.org

2015-02-11 Библиотеката на initLab и POC||GTFO

February 11th, 2015 by Vasil Kolev

Лабът си има две библиотеки и нещо като book crossing…
(може директно да гледате снимки, или да четете и обясненията по-долу)

Библиотеките са една голяма в коридора (1, 2) и една малка в рубинената стая.

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

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

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

POC||GTFO (т.е. Proof-of-concept or get the fuck out) е едно доста интересно списание, правено от някаква част от екипа на phrack. Издава се под САМИЗДАТ лиценз (т.е. може да го печатате и т.н., но трябва да отпечатате копия и за хората около вас), и е бая забавно.

До тук в съдържанието му могат да се срещнат неща като “как да направим един файл да е pdf и swf”, “javascript random генератор”, “операционна система в 512 байта и pdf файл, който boot-ва”, “как да познаем, че сме под QEMU, а не на истински MIPS” и всякакви други странности. Прилична част от нещата имат практическо приложение (ако се занимавате със странни/весели неща), а останалите са приятни четива за забавни хакове.

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

Ако ви е интересно (а би трябвало да е), погледнете моя mirror, или минете през близкия ви лаб, за да видите хартиен брой :)

2015-01-27 maintenance

January 27th, 2015 by Vasil Kolev

Днес следобед (27.01.2015) ще рестартирам marla.

Update: приключи успешно.

2015-01-26 “The Imitation Game” и Алан Тюринг

January 26th, 2015 by Vasil Kolev

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

Гледах “The imitation game”, след което прочетох “Alan Turing: The Enigma”(по която уж е правен филма) и крайното ми мнение е, че не струва:
– Ненужно драматичен е, през цялото време основната ми мисъл беше “тука прекаляват”;
– Избрали са за ролята на Тюринг актьор, който играе аутисти и психопати (и докарва още повече драматичност);
– Сериозно се различава от реалността (има доста неща в wikipedia по въпроса) – например Enigma-та е счупена от поляците, след което англичаните доразвиват идеята, като ролята на Тюринг е сериозна, но не е като на единствен човек, който е бутал цялото нещо;
– Споменали са само малка част от работата му, криптоаналитичните му занимания не са по-важни от машината на Тюринг и приносът му в създаването на информатиката (“Computer science” звучи по-подходящо, ама “компютърни науки” не изглежда добре). Силно препоръчвам на всички програмисти и изобщо компютърджии “The Annotated Turing: A Guided Tour Through Alan Turing’s Historic Paper on Computability and the Turing Machine”, обяснение на paper-а му по темата изчислимост, в който могат да се видят в общи линии за пръв път различни основни програмистки похвати.

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

А днес гледах “Citizenfour”, на чиито принцип е трябвало да направят филма за Тюринг.
(и това е филм, който трябва да гледате, и за който силно се надявам (и изобщо не вярвам) да го дават по кината в България)

2015-01-20 записи от OpenFest 2014

January 20th, 2015 by Vasil Kolev

И най-накрая сме готови с (почти) всички видеа от OpenFest 2014, може да се свалят от архива, или да се гледат в тубата. Липсва ни само едно видео (“I reject your reality and substitute my own”), което самите хора ще си го редактират и ще качат.

An Open Letter to Mr. David Cameron

January 13th, 2015 by Vasil Kolev

(this is a guest post from Boyan Krosnov, the original is here)

An open letter to Mr. David Cameron,

Sir,

This letter is in reaction to you statement: ” But the question remains: are we going to allow a means of communications which it simply isn’t possible to read. My answer to that question is: ‘No we must not’. “Source: link

Mr. Cameron, firstly this letter has nothing to do with recent events in Paris. It is solely addressing the issue of private communications.

End-to-end computer-assisted encryption with ephemeral keys has existed on this world since at least 1977. Even 130 years ago, in 1885, the one-time pad was already invented. If you don’t understand what these are, then please ask your technical advisers. Essentially, someone with a book (for one-time pad), a pen and a sheet of paper can encrypt and decrypt secret messages from/to a party located on the other end of the world. They can communicate these messages in public using a variety of low tech means. For example, they could post innocent-looking messages in a classifieds section of a newspaper. Anyone, without the necessary procedures and a copy of the pad, would not be able to know the content of their communication, and if the scheme is implemented correctly, would not be able to detect that a conversation is taking place. This is not a new development. Even the modern idea of a Sneakernet has existed at least as long as the Internet has existed.

Short of inventing a time machine, your goal is unachievable. :)

On a more serious note though, what you are promoting in your speech is scary and deeply immoral.

Since end-to-end encryption exists, I know of only three ways you could try to achieve your goal of total on-demand, and probably retro-active snoop-ability of communications. These are ineffective and in some cases even impossible to implement, but anyway here they are:

  • Option 1. to have a backdoor in every end-point device manufactured in the UK or brought in through the UK border. This approach does not prevent a sufficiently dedicated person from building a secure end-point from scratch, like with the one-time pad and newspaper approach I mentioned. Backdooring online services is a sub-case of this.

    and/or
  • Option 2. to introduce a key escrow requirement for all encrypted communication beginning and ending and maybe even crossing the UK, and also detect and block all encrypted communication, not conforming to the key escrow rules. The latter might be impossible to implement, but that’s a whole other matter.

    and/or
  • Option 3. Ban encrypted communication altogether. Which would tear down the whole of what you call “the digital economy”, and revert the UK back to a technological state resembling the 80s, while the rest of the world moves on.

The reality of the matter is that all three, apart from being totally ineffective in dealing with the threat of isolated terrorist acts, open the door for massive abuse, not just by the government, but also by related and unrelated third parties. Other people have explained this a lot better than I ever could. For example, in Cory Doctorow’s talk here. To quote just one line ” – … but we both understand, that if our government decided that weaponizing water-bourne parasites was more important than addressing them and curing them, then we would need a new government.”

Let me be clear on one point: We don’t trust nation states with our private thoughts and conversations. We need private communications not just for the paranoid, perverts and criminals, but for businesses, law enforcement, journalists and for regular every-day private conversations between friends and family members.

Your scheme would ruin private communication for all of us. The bad guys are already using secure and undetectable communication media.

Privacy is the opposite of total surveillance. You can’t have both. So unfortunately, for the goals you outlined, we need to have a working and secure private communication for everyone in the world to use, regardless of their sex, skin color, sexual orientation, age, religious views (or lack thereof), wealth, social status or intent. Your scheme for a total surveillance state must be stopped.

With good meaning and respect,
Boyan Krosnov
Sofia, 2015-01-13

(c) 2015, Boyan Krosnov, public domain

2015-01-06

January 6th, 2015 by Vasil Kolev

Някои дреболии, дето изникват тия дни:

Описание как да си настроим ssh-а, така че да е минимално vulnerable към възможните проблеми (дето се мисли, че съществуват след лекцията на Апелбаум)
(мисля, че автора прекалява, ама па параноята е нещо важно в нашата професия)
(събирам желание да си rekey-на сървърите)

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

Също така, в initlab ще има лекция/дискусия на тема “Design patterns for web-application scaling”, която даже ще stream-ваме online. Ще е в общи линии админска, но вероятно ще се допускат developer-и, ако не говорят много глупости.
(няма какво да се притеснявате, vloo ни е забранил да ползваме брадвата в тоя студ, а па и земята е твърде замръзнала, че да заравяме някой)

За тестове сме пуснали initLab TV, което в общи линии върти всичките записи, дето има на va.ludost.net.

Всички видеа от 31C3 са качени, ако има достатъчно желаещи, може да организираме гледане на най-добрите.

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

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

2014-12-30 31C3 ден 4

December 30th, 2014 by Vasil Kolev

И последен ден на 31C3.

Започнах с лекцията за online гласуването в Норвегия – имаше реализирана система на база на ел-Гамал (където има интересната възможност да се събират криптирани числа, без да се виждат), по принцип “стандартът” по темата е горе-долу този (не помня url-тата по въпроса). Докато тествали открили няколко бъга, но като цяло защитата в дълбочина ги спряла. Отказали са се от системата, понеже не давала нищо повече – не се увеличил броя гласуващи и като цяло гласувалите по internet не били различни от тези, които гласували на място.

“Why are computers so @#!*, and what can we do about it?” беше сравнително скучно (някъде по средата излязох да ям и го слушах през gsm-а), поредното нещо по темата как трябва да си правим кода доказуем и да ползваме технологиите за целта.

Във “State of the onion” имаше разни интересни неща, които съм си отбелязал – ooniprobe (мислех да взема една хардуерна проба, но вероятно просто софтуерното нещо ще е достатъчно), направили са TOR weekly news, и Roger е разказвал на NSA около 2008ма колко е готин TOR и във Washington post има статия по въпроса (след като едно от leak-натите неща от Snowden са били бележките на хората от NSA от тая среща).

Infrastructure review беше доста интересно, setup-ът им става все по-голям всяка година и все по-интересен, чак ми идва желание да се включа в някой екип. Гледайте го за повече подробности.

TOR deanonimization talk-а разказа как са изброили доколкото е възможно hidden service-ите в мрежата и какво горе-долу има на тях. Също така обясниха как с pattern-а на трафика, ако човек има достъп до guard node на потребителя и има достатъчно места, на които да следи изходящия трафик, има някакъв вариант да се види къде отива, както и ако имат някакъв такъв достъп до guard node на hidden service. Като цяло нищо ново, и за съжаление нямаше хубаво описание на ловенето на traffic pattern-и.

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

2014-12-23 31C3 ден 3

December 30th, 2014 by Vasil Kolev

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

Сутринта започна с лекция за full-body scanners, т.е. скенерите, които от известно време се ползват на американските летища и разни други места за разглеждане на пътниците. Хората бяха разгледали един от скенерите (Rapiscan Secure 1000), който работи с backscatter рентгенови лъчи. Нещата, които разказаха са, че:
– скенерът не генерира достатъчно радиация, за да е опасен (нивата са съвсем мижави), и като цяло не е лесно да е пипне така, че да е опасен;
– има начин да се подслушва донякъде образа, който вади, извън самия скенер (почти като подслушването на нечий монитор, като се знаят периодите на хоризонтално и вертикално сканиране и като може да се уловят отдалече разсеяните лъчи);
– оригиналният софтуер може да записва картинки (на ДИСКЕТА), твърди се, че тоя на TSA нямал тая функционалност;
– има вариант да се атакува машината, т.е. да се пренесе през нея нещо, което трябва да хване, по няколко начина (например като се направи да е само спрямо фона и да не се различава от него, или като се нанесе по тялото и да не се отличава от него, в случая с пластичния експлозив).
Този тип машини в момента не се ползват от TSA, понеже са искали да се отърват от гледането на “голи” хора, и софтуера да казва “еди-къде-си по човека има съмнителен обект”, а още никой не е успял да го напише (и звучи като доста безнадеждна задача).
Имаше и други забавни моменти, например как са си купили машината от ebay и се опитват да се снабдят с машина от другия вид (ако не се лъжа, с милиметрови вълни), за да изследват и нея.

Let’s build a quantum computer не беше лошо, в общи линии беше някакъв малък увод (непълен) в квантовите компютри и как човекът за две години като дипломна работа е сглобил 2-qubit-ов компютър, който работи при около 10-13 градуса по Келвин.

Между останалите лекции се засякох с Филип Пепс (от FOSDEM) и си говорехме с него и още някой по темата за техните видео записи и мрежата им, и как може да им потрябват hack-ове от типа на опъването-на-кабели-като-за-български-internet (лепена оптика с duct tape по стените, например). Има шанс да ходя до там да се забавлявам догодина…

Лекцията за NORX/Caesar беше за един конкурс за authenticated encryption, шифър с метод за прилагане. Представиха конкурса и техния участник (който изглежда интересен, но е цял шифър с метода и бая ме притеснява), направен със съвсем прости операции и като цяло доста по-прост от доста блокови шифри, които съм виждал.
Странно ми беше, че конкурса е за метод за прилагане И шифър, т.е. не просто за за метода (като нещо, което да замести GCM/CBC и компания), та за това голяма част от участниците просто ползват AES.

Лекцията за ядрените оръжия беше леко забавно, но в нея нямаше нищо, което го няма в wikipedia.

Докато си почивах, се запознах с човека от totalism.net, в общи линии hackerspace на един остров не-съвсем-в-нищото, където има net, топло е и човек може да си работи и почива спокойно, като даже не излиза особено скъпо. Bandwidth-а им не е много, но ако някой ден реша да ходя на “почивка”, може да е там…

Последва стандартния whisky workshop, на който се насмуках прилично. Харесах си сериозно само едно уиски, някакъв странен edition на glenfarcas, дето беше cask strength, 60 градуса и с истински вкус/
аромат.

Гледах лекцията за Computer science in DPRK (т.е. по темата Северна Корея), имаше интересни моменти – как имат клон на OSX с превод (почти на принципа, на който нашите хора едно време крадяха и превеждаха софтуер директно в binary-тата), как имат таблет с аналогова телевизия, клон на andoid с patch-нати app-ове (и добавени, като например един с речи на лидерите им). Като цяло доста полезна гледна точка (лекторът беше водил лекции там в един от университетите).

А лекцията за exploit-ването в perl беше адски забавна, как явно самите хора, които ползват perl не схващат някои негови кривотии и как самият език не се държи по очаквания начин (т.е. как реално погледнато някои неща в него се държат като в shell script, а не като в LISP) и какви адски забавни атаки могат да се получат (например, да се пробута аргумент който като се предаде на функция, да се приеме като два аргумента и да избута тия след него). Аз лично се смях с глас…