Примечание: этот пост — ироничное наблюдение на тему цикличности истории. Это самое наблюдение не несет какой-либо практической пользы, но в сути своей — весьма меткое, так что я решил, что им стоит поделиться с аудиторией. Ну и конечно же, встретимся в комментариях.

---

На прошлой неделе ноут, который я использую для разработки под MacOS, сообщил, что доступно обновление XCode. Я попытался его установить, но система сообщила, что ей недостаточно свободного места на диске для запуска программы установки. Окей, я удалил кучу файлов и попробовал снова. Все та же ошибка. Я пошел дальше и удалил еще кучу файлов и в довесок несколько неиспользуемых образов виртуальных машин. Эти манипуляции освободили на диске несколько десятков гигабайт, так что все должно было заработать. Я даже вычистил корзину, чтобы там ничего не «зависло», как это обычно бывает.

Но даже это не помогло: я получил все ту же ошибку.

С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

Но мне удалось сделать свой DNS сервер, который работает быстрее Google Public DNS, и в этой краткой заметке хочу поделится результатами.

Вступление от переводчика: На фоне массового входа в нашу жизнь различного рода контейнеров может быть довольно интересно и полезно узнать, с каких технологий это всё начиналось когда-то. Некоторые из них можно с пользой применять и по сей день, но не все о таких способах помнят (или знают, если не застали во время их бурного развития). Одной из таких технологий является User Mode Linux. Автор оригинала изрядно покопалась, разбираясь, что из старых наработок ещё работает, а что уже не очень, и собрала нечто вроде пошаговой инструкции о том, как самому себе завести доморощенный UML в 2к19. И да, мы пригласили на Хабр автора оригинального поста Cadey, так что если есть вопросы — задавайте на английском в комментариях.



User Mode в Linux — это, фактически, порт ядра Linux на само себя. Этот режим позволяет запустить полноценное ядро Linux в качестве пользовательского процесса и обычно используется разработчиками для тестирования драйверов. Но также этот режим полезен и в качестве инструмента общей изоляции, принцип которой схож с работой виртуальных машин. Данный режим обеспечивают большую изоляцию, чем Docker, но меньшую, чем полноценная виртуальная машина вроде KVM или Virtual Box.

Однажды, на одном интервью меня спросили, что ты будешь делать, если обнаружишь неработающий сервис из-за того, что на диске закончилось место?

Конечно же я ответил, что посмотрю, чем занято это место и если возможно, то почищу место.
Тогда интервьюер спросил, а что если на разделе нет свободного места, но и файлов, которые бы занимали все место, ты тоже не видишь?

На это я сказал, что всегда можно посмотреть открытые файл дескрипторы, например командой lsof и понять какое приложение заняло все доступное место, а дальше можно действовать по обстоятельствам, в зависимости от того, нужны ли данные.

Интервьюер прервал меня на последнем слове, дополнив свой вопрос: «Предположим, что данные нам не нужны, это просто дебаг лог, но приложение не работает из-за того, что не может записать дебаг»?

«окей», — ответил я, «мы можем выключить дебаг в конфиге приложения и перезапустить его».
Интервьюер возразил: «Нет, приложение мы перезапустить не можем, у нас в памяти все еще хранятся важные данные, а к самому сервису подключены важные клиенты, которых мы не можем заставлять переподключаться заново».

«ну хорошо», сказал я, «если мы не можем перезапускать приложение и данные нам не важны, то мы можем просто очистить этот открытый файл через файл дескриптор, даже если мы его не видим в команде ls на файловой системе».

Интервьюер остался доволен, а я нет.

Тогда я подумал, почему человек, проверяющий мои знания, не копает глубже? А что, если данные все-таки важны? Что если мы не можем перезапускать процесс, и при этом этот процесс пишет на файловую систему в раздел, на котором нет свободного места? Что если мы не можем потерять не только уже записанные данные, но и те данные, что этот процесс пишет или пытается записать?

Однажды мой знакомый, который на тот момент администрировал некое веб-приложение на сервере под управлением GNU/Linux, пожаловался на одного вредного администратора сервера. Тот ни в какую не хотел устанавливать htop, несмотря на все просьбы.

Я немного удивился и поинтересовался, в чём причина такого странного поведения. Если упростить, то дальнейший наш диалог получился вот таким:

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

Но почему у меня этот продукт с логотипом кита вызывает столь разнообразные эмоции? Ниже я перечислю те моменты, от которых бомбит. Возможно, что читатель будет не согласен или, напротив, найдет какие-то вещи, о которых не знал и сочтет интересными.

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Непредвиденные последствия

«Система кармы Хабра и ее влияние на пользователей» — это тема для курсовой как минимум
Тема про карму на «Пикабу»

Я мог бы начать эту статью с того, что я давно читаю Хабр, но это будет не совсем точным высказыванием. Правильный тезис звучал бы так: «я давно читаю статьи с Хабра» — но не интересовался тем, что происходит внутри сообщества, когда этой весной решил наконец-то зарегистрироваться. Это типичная ошибка человека, который приходит на Хабр из поисковика читать полезные статьи о тонкостях программирования или интересные новости из мира технологий. Пока ты видишь портал только с этой, положительной стороны, ты не задаёшься вопросами о том, что происходит под капотом. Конечно, в комментариях или статьях время от времени проскальзывали упоминания кармы — но ведь карма есть почти на всех крупных порталах (наивно полагал я), это нормально для саморегулирующихся интернет-сообществ.

Мне пришлось всерьёз задуматься об этом после того, как я неожиданно потерял возможность писать больше одного комментария в пять минут.

При этом внешне всё шло отлично: мои комментарии всё время плюсовали, мой рейтинг рос — и вдруг оказалось, что у меня отрицательная карма. Весь мой длительный опыт интернет-общения, все пользовательские привычки, да и банальный здравый смысл кричали мне, что это какая-то ошибка: показатель одобрения пользователя сайта другими пользователями сайта не может одновременно расти и падать! Но я решил не рубить сплеча, а провести небольшое исследование, как аналитическое (в виде изучения мнений пользователей о карме), так и статистическое (в виде анализа показателей аккаунтов).

Выбирая геймпад для своего компьютера, я остановился на DualShock4, так как мне понравилась идея, что можно будет слушать аудио через подключаемые к нему наушники. Но после покупки я узнал, что, оказывается, никто не знает, как передать звук на геймпад через Bluetooth. Поэтому я решил разобраться с данным вопросом. Если вам интересно узнать, как DualShock4 общается с игровой консолью, жду под катом.

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

Всё началось с американских комиксов после Второй Мировой. Дело в том, что до войны ввели запрет на продажу порнографии, а порнографией нередко занимались бывшие бутлегеры. И вот у них встали печатные станки, и надо было что-то срочно придумывать. Придумались комиксы, поскольку с накалом обстановки из-за войны начала расти потребность в простых штуках (а комиксы тогда делали так, что читать уметь далеко не обязательно) и простых же супергероях, дарящих утешение.

Появились Супермен и его братва. Чуть позже, примерно с появлением Чудо-женщины, всё это эволюционировало обратно к мягкой порнографии (оценочное суждение). Забегая вперёд — доктор психиатрических наук обвинял эту серию в развитии множества половых извращений у малолетних американцев. Почему? Да потому что для аудитории самый естественный сюжет с дамой в трусах поверх остальной не очень богатой одежды — быть в беде. Сексуально. Ну, насколько тогда было возможно.

Заблокировать подозрительное поведение программы? Смягчить последствия от эксплуатации уязвимостей? Исключить выполнение несанкционированного кода?
TOMOYO Linux — реализация мандатного управления доступом для операционной системы Linux. Встроена в ядро по умолчанию. Позволяет взять под контроль поведение системы и жестко ограничить в рамках заданной политики.

UPD: Телеграм чат для обсуждения оборудование Zyxel @zyxelru t.me/zyxelru

Представьте, что Вы владелец сети маленьких кофеен. Вам надо выпустить в интернет клиентов, с учётом требования закона об идентификации.
А так как Ваш бизнес — общепит, то наверняка у Вас нет обширных знаний в IT. Да и времени на разворачивание, как всегда, нет. Чем раньше откроем кафе — тем больше прибыль.

Самый быстрый способ поднять публичный Wi-Fi, который я нашёл.



Разворачиваем Wi-Fi для клиентов в нашей кофейне.

Обсуждение операторов сотовой связи в Телеграм t.me/opsosru

Уже давно как не смешные анекдоты ходят истории о платных мобильных подписках на IoT устройствах.


С Пикабу

Всем понятно, что без действий сотовых операторов эти подписки не обходятся.

Ну действительно, прекратите. Есть куча прикольных штук для соединения самых разнообразных проводов, а все равно технология «откусить зубами изоляцию, скрутить, замотать изолентой» жива до сих пор.

Привет Хабр.

Не так давно у меня появилось желание написать целую серию статей о безопасности, приватности и анонимности в интернете. Я не хочу тратить время читателей, в очередной раз описывая весьма плачевную ситуацию со сбором персональных данных, все это и так уже было сделано до меня, поэтому давайте сразу перейдём к делу.

И так, можно ли пользоваться мобильным устройством без серьёзного ущерба для приватности?

Ответ — да, можно, но для этого необходимо избавиться от ПО и сервисов, бесконтрольно собирающих данные. Для этого понадобится желание что-то изменить и любое устройство на которое можно установить кастомную систему Android (iOS по понятным причинам не рассматривается, а из альтернатив только SailfishOS и GNU/Linux, но эти системы можно установить на очень ограниченное число моделей). Всех кто заинтересовался я приглашаю под кат.

В статье разбираются популярные мифы и сценарии мошенничества с бесконтактными системами оплаты на примере настоящего POS-терминала, карт PayPass/payWave и телефонов с функцией Google Pay/Apple Pay.

Рассматриваемые темы:

• Можно ли НА САМОМ ДЕЛЕ украсть деньги, прислонившись POS-терминалом к карману? — мы попытаемся полностью воспроизвести этот сценарий мошенничества от начала до конца, с использованием настоящего POS-терминала и платежных карт в реальных условиях.
• В чем разница между физическими и виртуальными картами Apple Pay? — как происходит связывание физической карты и токена Apple Pay, и почему Apple Pay во много раз безопаснее обычной карты.
• Используем аппаратный NFC-сниффер (ISO 14443A) — воспользуемся устройством HydraNFC для перехвата данных между POS-терминалом и картой. Рассмотрим, какие конфиденциальные данные можно извлечь из перехваченного трафика.
• Разбираем протокол EMV — какими данными обменивается карта с POS-терминалом, используемый формат запросов, механизмы защиты от мошенничества и replay-атак.
• Исследуем операции без карты (CNP, MO/TO) — в каких случаях на самом деле(!) можно украсть деньги с карты, имея только реквизиты, считанные бесконтактно, а в каких нельзя.

Внимание!

В статье подробно описывается гипотетическая схема мошенничества, от начала и до конца, глазами мошенника, с целью покрыть все аспекты, в которых культивируются мифы и заблуждения. Несмотря на провокационный заголовок, основной вывод статьи — бесконтактные платежи достаточно безопасны, а атаки на них трудоемки и невыгодны.

Материалы в статье представлены исключительно в ознакомительных целях. Все сцены демонстрации мошенничества инсценированы и выполнены с согласия участвующих в них лиц. Все списанные деньги с карт были возвращены их владельцам. Воровство денег с карт является уголовным преступлением и преследуется по закону.

В этой статье я расскажу, как мне удалось портировать алгоритм рендера трехмерных сцен на формулы Excel (без макросов).

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

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

Осторожно: 19 картинок и 3 анимации под катом.

Это была славная охота.

Моя жизнь была посвящена ИТ-сфере. Я был инженером, создававшим интересные продукты для больших промышленных компаний. Моей географией была вся Россия, я вживую видел цеха КАМАЗа, ВАЗа и других автогигантов. Но всему в нашей судьбе настаёт предел, и я выгорел. О причинах расскажу как-нибудь в другой раз. Главное, что я, опытный разработчик и техник, ушёл на вольные хлеба и, поскольку у меня появилась семья, решил сделать бизнес — свой магазин товаров для детей, по особым принципам. В общем, как многие из программеров, сделать то, чего не достаёт мне среди предложений на рынке. И знаете, что? Я выяснил, что найти простейших, базовых, нужных профессионалов-подрядчиков очень сложно. Миллион фрилансеров и фирм, а выхлоп… Это был квест, и о нём я должен поведать миру. Не ходите по моим граблям.


Это самое лучшее, что описало моё состояние

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3