Приветствую, %username%.

Перед вами вторая статья из цикла о разработке ОС на Go + asm.

Part 0x00
Part 0x01

Изначально я планировал, что вторая статья будет про обработку прерываний, но Go накладывает свои корректировки — сейчас будет описано простое выделение памяти и часть рантайма Go, которая нам пригодится, но будет переписано. На самом деле это подготовка к третьей статье — куче и допиливанию рантайма.

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

Слабонервным просьба закрыть статью — все, что может быть написанно на Go будет написанно на нем!

Доброго времени суток %username%.

Захотелось мне пописать что-то ненормальное. Выбор пал на ОС, в конце-концов каждый программист должен написать свою ОС, пусть хотя бы учебную.

Как некоторым известно, я очень люблю язык Go ну, и решил попробовать написать на нем. Что из этого получилось — под хабракатом.

Part 0x00
Part 0x01

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

Особенно отмечу, что не пытаюсь полностью описать язык, а только одну его сторону. Это мой личный взгляд на философию Rust, не обязательно совпадающий с официальной позицией разработчиков! Кроме того, Rust не будет очевиден пришельцу из других языков: кривая обучение довольно резкая, и не раз компилятор заставит вас мысленно сказать «wtf» на пути к просветлению.

Однажды судьба свела меня с ней. С первого взгляда я был ослеплен и долгое время не мог отвести от нее взгляд. Шло время, но она не переставала меня удивлять, иногда казалось, что я изучил ее вдоль и поперек, но она снова переворачивала все мои представления. Ее гибкости не было предела, а потом я узнал, что она умеет еще и… ООП!

Как-то я всерьез занялся покорением ООП в lua. И все, что я находил в интернете по этой теме, было вырвиглазными нагромождениями кода с обилием нижних подчеркиваний, которые никак не вписывались в элегантность этого языка. Поэтому я решил искать простое решение.

После прочтения множества умных книжек и разбора нескольких ужасных реализаций ООП, я, крупица за крупицей, собирал все самое полезное и простое, пока не выработал свой стиль объектно ориентированного программирования на lua.

Предлагаю читателям «Хабрахабра» перевод публикации «How I shrunk a Docker image by 98.8% – featuring fanotify».

Несколько недель назад я делал внутренний доклад о Docker. Во время презентации один из админов спросил простой на первый взгляд вопрос: «Есть ли что-то вроде „программы похудения для Docker образов“»?

Для решения этой проблемы вы можете найти несколько вполне адекватных подходов в интернете, вроде удаления директорий кэша, временных файлов, уменьшение разных избыточных пакетов, если не всего образа. Но если подумать, действительно ли нам необходима полностью рабочая Linux система? Какие файлы нам действительно необходимы в отдельно взятом образе? Для Go binary я нашел радикальный и довольно эффективный подход. Он был собран статически, почти без внешних зависимостей. Конечный образ — 6.12 МB.

Перевод инфраструктуры hexlet.io на Docker потребовал от нас определенных усилий. Мы отказались от многих старых подходов и инструментов, переосмыслили значение многих привычных вещей. То, что получилось в итоге, нам нравится. Самое главное – этот переход позволил сильно все упростить, унифицировать и сделать гораздо более поддерживаемым. В этой статье мы расскажем о той схеме для разворачивания инфраструктуры и деплоя, к которой в итоге пришли, а так же опишем плюсы и минусы данного подхода.

Типичный любитель λ-исчисления.

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

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

С лямбда исчислением я был знаком очень поверхностно, так как почти всегда статьи об этом разделе математики состоят полностью из формул, которые никак не попробовать на практике не представляется возможным. Поэтому пришла идея разобраться с ним на практике, и возможно привлечь на темную сторону силы адептов машины Тьюринга ООП.

Если вас не пугает Lisp, много лямбд и y-combinator (не тот, который с новостями),

Несколько лет назад с удовольствием играл в небольшую любительскую браузерную игру, созданную по мотивам классической «Majesty: The Fantasy Kingdom Sim». Очень скоро в ней обнаружилось несколько уязвимостей и багов, включая весьма пригодные для «эксплуатации». История того, как я писал скрипты-эксплоиты, репортил баги и позже немного участвовал в разработке игры – ниже. Думаю, она неплохо проиллюстрирует несколько нестандартный, гиковский подход пользователя к игре, о котором может быть полезно знать разработчикам.

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



На PHDays уже дважды выступали «крестные отцы» локпикинга и физической безопасности из организации TOOOL (The Open Organisation Of Lockpickers) — профессиональные медвежатники в белых шляпах и лучшие специалисты в мире по недостаткам различных типов замков. Их стол с отмычками и замками традиционно был одним из самых популярных на форуме и любой из участников имел возможность попробовать себя в роли взломщика.

OsmocomBB — это проект, целью которого является свободная (Open Source) имплементация стека протоколов GSM. OsmocomBB предоставляет исходный код прошивок для совместимых телефонов, а также программное обеспечение для их взаимодействия с компьютером. В этом цикле статей я постараюсь описать наиболее интересные возможности, тонкости и ошибки, которые могут возникнуть при работе с данным ПО. Заинтересованных приглашаю под кат!

Привет, Хабрахабр! Наверняка, многие из вас задумывались о разработке собственной игры, но, к сожалению, существует много факторов, которые, всё же, не позволяют нам начать работу над игрой своей мечты: учеба, работа, семья и т.д. Да и, к тому же, мы просто боимся бросить всё и осуществить свою мечту, ибо многих пугает неизвестность, которая нас поджидает, как только мы отклонимся от общепринятых стремлений. В данной статье я расскажу вам о своём нелегком пути к воплощению идеи, ради которой я поставил все на кон.

Билл Гейтс на своём канале на Youtube предлагает несколько книг для чтения летом, что он делает последние пару лет. Список книг — под катом.

В прошлый раз я рассказал об исследовании связи звука с текстом в движке UE3. Сегодня рассмотрю подробнее более простой случай — разбор пакета звуков Bioshock Infinite, с которого начиналась полная локализация этой игры на русский язык.

Разбор ресурсов — это как разгадывание ребуса или кроссворда: начинаем с одной стороны, и постепенно узнавая значение все новых полей, разгадываем всё остальное. Сначала структура ресурсов игры была для нас как тёмный лес. Но постепенно мы узнавали о них всё больше и больше, одно тянуло за собой другое, и в итоге были исследованы и модифицированы практически все ресурсы игры: звук, текстуры, 3D-модели. Пример надписи, изменённой в виде модели вместе с текстурой, картами освещения и отражения, светящимися лампочками, бликами и тенью, можно видеть на картинке.

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

Предисловие

Итак, в предыдущей статье мы начали собирать LFS, остановившись на том, что собрали временную систему, располагающую всем необходимым для дальнейшей сборки инструментарием.

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

Однако, прежде чем двигаться дальше, немного отойдем от классической схемы, предлагаемой авторами книги и сделаем вот что

$ su - lfs
$ wget http://roy.marples.name/downloads/dhcpcd/dhcpcd-6.7.1.tar.bz2 --directory-prefix=$LFS/sources
$ wget http://www.linuxfromscratch.org/blfs/downloads/7.7/blfs-bootscripts-20150304.tar.bz2 --directory-prefix=$LFS/sources
$ logout

Дело в том, что стандартная документация, касающаяся сборки базовой системы не описывает процесс настройки сети в случае, когда вы будете получать ip-адрес от DNS провайдера, или в случае, если динамический ip выдает вам ваш домашний роутер. Или в том случае, если Вы выполняете сборку под ВМ, имеющей доступ к сети через NAT.

Поэтому после того как мы соберем всё и вся, мы дополнительно установим и настроим DHCP-клиент, который позволит свеженькой системе получить ip сразу после перезагрузки и иметь таки доступ в сеть. Этот шаг относится уже к книге BLFS.

Сроки удержания информации зависят от температуры

Твердотельные накопители имеют ряд преимуществ над традиционными жёсткими дисками: это потребляемая энергия, время и скорость доступа. И год от года основной недостаток становится менее заметным — SSD дешевеют.

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

Засматриваетесь на 4K UHD-мониторы, но ваш лаптоп не поддерживает высокие разрешения? Купили монитор и миритесь с частотой обновления в 30Гц? Повремените с апгрейдом.

TL;DR: 3840×2160@43 Гц, 3200×1800@60 Гц, 2560×1440@86 Гц на Intel HD 3000 Sandy Bridge; 3840×2160@52 Гц на Intel Iris 5100 Haswell.

Предыстория

Давным-давно, когда все мониторы были большими и кинескопными, компьютеры использовали фиксированные разрешения и тайминги для вывода изображения на экран. Тайминги были описаны в стандарте Display Monitor Timings (DMT), и не существовало универсального метода расчета таймингов для использования нестандартного разрешения. Мониторы отправляли компьютеру информацию о себе через специальный протокол Extended display identification data (EDID), который содержал DMT-таблицу с поддерживаемыми режимами. Шло время, мониторам стало не хватать разрешений из DMT. В 1999 году VESA представляет Generalized Timing Formula (GTF) — универсальный способ расчета таймингов для любого разрешения (с определенной точностью). Всего через 3 года, в 2002 году, его заменил стандарт Coordinated Video Timings (CVT), в котором описывается способ чуть более точного рассчитывания таймингов.

Оба стандарта были созданы с учетом особенностей хода луча в электро-лучевой трубке, вводились специальные задержки для того, чтобы магнитное поле успело измениться. Жидкокристаллические мониторы, напротив, таких задержек не требуют, поэтому для них был разработан стандарт CVT Reduced Blanking (CVT-R или CVT-RB), который является копией CVT без задержек для CRT, что позволило значительно снизить требуемую пропускную способность интерфейса. В 2013 году вышло обновление CVT-R c индексом v2, но, к сожалению, открытого описания стандарта в интернете нет, а сама VESA продает его за $350.

История

Наконец-то настала эра высокой плотности пикселей и на ПК. На протяжении последних нескольких лет, нас встречал театр абсурда, когда на мобильные устройства ставят пятидюймовые матрицы с разрешением 1920×1080, полки магазинов уставлены большими 4K-телевизорами (хоть на них и смотрят с расстояния 2-4 метров), а мониторы как были, так и оставались с пикселями с кулак. Подавляющее большинство говорит, что Full HD выглядит «достаточно хорошо» и на 27" мониторе, забывая, что предыдущее «достаточно хорошо» чрезвычайно быстро ушло после выхода iPad с Retina. Вероятнее всего, такая стагнация произошла из-за плохой поддержки высокой плотности пикселей в Windows, которая более-менее устаканилась только к выходу Windows 8.1.

Предисловие

Для того чтобы установить на свой компьютер Linux и начать его использовать для конкретных задач существует масса способов. Выбор дистрибутивов чрезвычайно широк, на любой вкус и цвет — и «для домохозяек» и для продвинутых пользвателей, допускающие любой уровень кастомизации, в том числе и сборку из исходников под конкретное железо. Установка системы в принципе доступна любому, мало-мальски грамотному пользователю ПК. И, если не погружаться в популярные по сей дей холивары на тему «Linux vs Другая ОС», то и спользование данной системы не требует знаний, которые были обязательными для новоиспеченного линуксоида скажем десять лет назад. С моей, глубоко субъективной точки зрения, за более чем десять лет, которые я наблюдаю за развитием этой системы, линукс стал более дружественен к новичкам и избавился от многих проблем, присущих ему в прошлом. И это хорошо.

Пингвины ручной сборки...


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

Не буду витеивато излагать истории о том «как космические корабли бороздят… и когда Земля была огненным шаром...». Я отвечу на поставленный вопрос исходя из своей позиции — я собираю LFS потому, что мне просто интересно это сделать. Я вижу в этом процессе хорошую возможность заглянуть «под капот» системы. Допускаю, что этот путь сложно назвать оптимальным. Тем не менее, данная статья, и последующие за ней будут посвящены процессу ручной сборки Linux-системы. Данные статьи не будут переводом документации по сборке — в этом нет особой нужды. Акценты будут расставлены на специфике и ньюансах процесса, с которыми пришлось столкнуться автору лично. Будем считать этот цикл чем-то вроде дневника неофита.

Обсуждение статьи "Не совсем крутой Ruby" зашло достаточно далеко: недостатки и достоинства Ruby между делом перетекали в обсуждение недостатков и достоинств Python. Не сильно удивило то, что передача self в качестве первого аргумента метода класса, некоторым хабравчанам кажется лишней. Ну что ж, не хотите явного self, будет вам неявный this! Под катом, немного магии на чистом Python.

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

Забейте. Функциональный код отличается одним свойством: отсутствием побочных эффектов. Он не полагается на данные вне текущей функции, и не меняет данные, находящиеся вне функции. Все остальные «свойства» можно вывести из этого.

Нефункциональная функция:

a = 0
def increment1():
    global a
    a += 1

Функциональная функция:

def increment2(a):
    return a + 1

Вместо проходов по списку используйте map и reduce

Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…