Позавчера (28 марта 2012 года) в сообществе «ПараТайп» в LiveJournal было опубликовано объявление о появлении «PT Mono Bold»:

Как и его предшественник «PT Mono», этот шрифт является моноширинным, распространяется свободно (по лицензии OFL), создан при финансовом участии Google и будет распространяться через сайт Google Web Fonts (правда, пока ещё там не появился).

Даровитый и плодовитый дизайнер-шрифтовик Иван Гладких, более известный как Джованни Лемонад (Jovanny Lemonad), в очередной раз показал миру свою плодовитость: позавчера он порадовал нас переработанною и дополненною версией шрифта Cuprum в четырёх начертаниях, а сегодня — шрифтом Russo.


Шрифт доступен для бесплатного скачивания по свободной лицензии SIL OFL 1.1; на сайте Google Web Fonts он также присутствует под именем «Russo One».

Любителям шрифта Cuprum настала пора сугубо возрадоваться: его автор, даровитый и плодовитый дизайнер-шрифтовик Иван Гладких, более известный как Джованни Лемонад (Jovanny Lemonad), сегодня выпустил переработанную и существенно дополненную версию своего детища. Вместо одного прежнего начертания Cuprum теперь наделён четырьмя!

Всякий, кому доводилось читать две прекрасные статьи Тима Брауна «Type rendering: operating systems» и затем «Type rendering: web browsers» (в октябре 2010 года) или самостоятельно исследовать тот же вопрос, тот уж знает, что в Windows, в зависимости от версии Windows, браузеры могут пользоваться одной или двумя различными системами антиалиасинга (сглаживания контуров) отрисовываемого шрифта.

Наилучшею из двух является система ClearType в DirectWrite (которою современные версии IE и Файерфокса пользуются в Windows 7 и в Windows Server 2008 R2 — а также в Windows Vista и в Windows Server 2008, если там установлен Platform Update): в ней контуры сглаживаются как в горизонтальном направлении (с использованием субпиксельной отрисовки ClearType), так и в вертикальном.

Менее хорошею является прежняя система ClearType в GDI+ (которою буквально все браузеры пользуются в Windows XP): она использует только субпиксельную отрисовку контуров шрифта в горизонтальном направлении — но ничуть не мешает проявляться «ступенькам» всякий раз, когда линия символа перескакивает в вертикальном направлении с одной строчки пикселов на другую. Эта особенность делает особенно тягостным отображение почти горизонтальных линий — имеющихся, например, во вчерашнем шрифте Russo.

Но оказывается, что случается и противоположная проблема: те шрифты, видом которых дизайнер-шрифтовик был долгие годы всецело удовлетворён в Windows XP, в некоторых размерах могут стать пренеприятно тонкими после их отображения в DirectWrite в более современных операционных системах. Этакими оказались, в частности, шрифты Arial, Tahoma и Verdana, распространявшиеся Корпорацией Microsoft в составе операционных систем семейства Windows. На сайте DebugTheWeb вы без труда отыщете ту тестовую страницу, на которой для вашего свéдения (и для сведéния на холсте <canvas>) приводятся скриншоты, демонстрирующие эту проблему; вы можете там сравнить своё отображение шрифтов с эталонным.

Mosh — замена(или дополнение) SSH. Он быстрее и отзывчивее, особенно на линках с высокой задержкой, например, в мобильных сетях. Набираете символ, и моментально видите его на экране, так же, как и в локальном терминале. Почему? Потому, что в Mosh реализован так называемый local line editing, который не дожидается ответа от сервера, а сразу все отображает на экране. Работает даже в полноэкранных приложениях, вроде vim или emacs. И это далеко не единственный плюс!

Привет, хабралюди!

Тема консольного скринкастинга уже поднималась на хабре, но я хочу рассказать вам о чем-то лучшем. jeck_landin рекомендует утилиту script и scriptreplay для записи и воспроизведения скринкастов. А я буду рекомендовать вам свой велосипед и объясню чем он лучше :)

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

Вопрос этот у меня возник не случайно. Есть интересный проект, заказчиками которого являются фанаты Айпадов и Айфонов. Им очень важно, чтобы сайт одинаково хорошо отображался и там и там. То есть ширина экрана плавает от 800 до 2000 пикселей в ширину.

Что нам делать с картинками в оформлении?

Да, сейчас все браузеры научились хорошо масштабировать сайты. Нажал Ctrl, покрутил скроллом, и твой сайт в том размере, как тебе удобно. Но если растровую картинку 30 на 80 пикселей увеличить в трое, красоты это не прибавит.

Мы в нашей рутинной работе верстальщиков уже привыкли к тому, что полностью зависим от пикселей. Мы все считаем в пикселях. Не важно, как мы встраиваем картину: в фоне или тегом Img.

Я вижу 2 принципиальных решения:

1. Использование разных файлов под конкретное разрешение, JS определяет размер экрана, предлагает определенный файл CSS, который в свою очередь подгружает нужные картинки.

2. Переход на векторную графику в оформлении сайта.

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

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

Добрый день.

Однажды от скуки, решил залезть в Web Developer Tools на стартовую страницу Chromium. Попробовал побаловаться с favicon посещаемых сайтов. Обнаружил ссылку на изображение вида:

chrome://favicon/size/16/http://habrahabr.ru/

Используя великие возможности внутреннего зрения для себя понял что 16 в адресе — это размер favicon

Интересно, подумал я, а если заменить число 16, на 64?

Так и сделал:

chrome://favicon/size/64/http://habrahabr.ru/

Открыл в новой вкладке этот адрес — и всё

Совсем недавно возникла интересная задача: реализовать закрытие доступа к веб-сайту из вне, на время технических работ. Мне показалось, что это довольно распространенная задачка, решение которой заинтересует многих.
Один из возможных вариантов решения — ниже.

Введение

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

• Разные шаблоны для имен файлов: 4 — Звезда | 04 — Звезда | 04. Звезда
• Разные имена исполнителей в тегах: Чиж & Co | Чиж и Ко. | Mylene Farmer | Mylène Farmer
• Не указаны исполнители альбома (что приводит к полному бардаку в альбомах-компиляциях)
• Не совсем корректная информация об альбомах, состоящих из нескольких дисков
• Путаница в годах изданий и переизданий (ремастеринг, и т.д.)

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

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

В процессе работы над проектом с использованием Node.js в качестве серверсайда, возникла задача запуска JS скрипта в качестве сервиса, со всем плюшками типа start, stop, restart. По этой теме в принципе уже достаточно информации, но она в основном сводится к использованию Monit + Init под линуксом, либо кратких советов типа «use nodemon, Luke».

В моём случае в качестве продакшн-сервера была машина на FreeBSD. В качестве утилиты запускающей JS файл как процесс мне приглянулся forever. Эта штука, в отличии от nodemon, умеет следить за запущенными под ней процессами и поднимать их при падении без ожидания изменения в исходниках скрипта, что очень удобно именно на продакшене. К тому же forever умеет показывать текущий список запущеных процессов, с отображением их аптайма, ну и позволяет останавливать/перезапускать процессы по имени или индексу.

Недолго думая, был написан rc.d скрипт:

Многим известны книги Томаса Лимончелли по системному администрированию, очень ценные для админа книжки. На его сайте тоже немало интересного, среди прочего нашёл такую статью: «A list of dumb things to check». На русском языке она, к сожалению, не нагуглилась, переводил сам. После допилинга под свои условия буду использовать как часть КМБ у себя в отделе, а первоначальный перевод выкладываю тут.

Жил да был сервер в далекой стране. По техническим характеристикам для своего времени он был не плох — Intel Core Quad Q6600 2.4GHz 8GB RAМ Intel DQ965GF motherboard, 3ware7xxx/8xxx raid controller и 2 SATA диска по 300GB в raid 1 масcиве.

И вот однажды решил на этом сервере один из дисков в raid умереть — а раз решил, то и умер. Естественно было предположить, где один диск умер, там и второй умереть может — надо менять. Да и расширить дисковое пространство не помешает, подумали мы.
Кое-как с грехом пополам купили новые 2TB диски — кризис и в далеких буржуйских странах был с жесткими дисками. Сервер был критически важным, но выключать и мучать его можно было некоторое время — были дублеры.

Решили мы обновить и программное обеспечение…

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

Чуть более года назад у меня появился Android телефон и сразу же передо мной встал вопрос, что использовать для путешествий, навигации. Как ни крути, но телефон с GPS и интернетом — очень удобен, особенно в незнакомых местах. Просмотрев все существовашие тогда приложения, был немного разочарован. Одно не работает без интернета, другое не поддерживает навигации, третье не ищет POI, четвертое не имеет векторных карт и т.д. Были конечно и бесплатные коммерческие аналоги, но у одних карты подкачали, у других отзывы, а все-таки когда платишь — хочется получить что-то, за что платишь.
Стоит отметить, что в поисках приложений, открыл совершенно замечательный проект OpenStreetMap с отличной детализацией для Беларуси. Поэтому, собрав все силы и желание сделать что-то бесплатное, доступное и нужное, открыл на googlecode проект OsmAnd.

Это первая статья из серии «Сети для самых маленьких». Мы с товарищем thegluck долго думали с чего начать: маршрутизация, VLAN'ы, настройка оборудования.
В итоге решили начать с вещи фундаментальной и, можно сказать, самой важной: планирование. Поскольку цикл рассчитан на совсем новичков, то и пройдём весь путь от начала до конца.

Предполагается, что вы, как минимум читали о эталонной модели OSI (то же на англ.), о стеке протоколов TCP/IP (англ.), знаете о типах существующих VLAN’ов (эту статью я настоятельно рекомендую к прочтению), о наиболее популярном сейчас port-based VLAN и о IP адресах (более подробно). Мы понимаем, что для новичков «OSI» и «TCP/IP» — это страшные слова. Но не переживайте, не для того, чтобы запугать вас, мы их используем. Это то, с чем вам придётся встречаться каждый день, поэтому в течение этого цикла мы постараемся раскрыть их смысл и отношение к реальности.



Начнём с постановки задачи. Есть некая фирма, занимающаяся, допустим, производством лифтов, идущих только вверх, и потому называется ООО «Лифт ми ап». Расположены они в старом здании на Арбате, и сгнившие провода, воткнутые в пожжёные и прожжёные коммутаторы времён 10Base-T не ожидают подключения новых серверов по гигабитным карточкам. Итак у них катастрофическая потребность в сетевой инфраструктуре и денег куры не клюют, что даёт вам возможность безграничного выбора. Это чудесный сон любого инженера. А вы вчера выдержали собеседование и в сложной борьбе по праву получили должность сетевого администратора. И теперь вы в ней первый и единственный в своём роде. Поздравляем! Что дальше?

Посмотрите на рисунок. Вот так конфигурируется классический NAT на маршрутизаторе Cisco, допустим там больше ничего не сконфигурировано. А теперь ответьте сами себе на вопрос. Может ли при определенных условиях кто-либо обратиться извне на RDP порт (TCP 3389) супер секретного сервера 192.168.0.250 и попытаться подобать пароль к нему. Уточним, что сервер стоит одиноко в сети и никуда сам не обращается (имеется в виду, что на нем нет никаких троянов, автоматических обновлений и прочих прелестей).

Считаете — нет? Вспомним анекдот.

Лекция по филологии. Старый профессор рассказывает:

— В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но, нет ни одного языка в мире, в котором двойное согласие означает отрицание. Голос с задней парты:

Не могу не поделиться с общественностью прекрасным переводом статьи The Limoncelli Test: 32 Questions for Your Sysadmin Team

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

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

Обновим на них базу данных временных поясов вручную.
Это несложно и именно об этом пойдет речь в этой заметке.

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

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

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

Данная методика существует давно, мне встречались разные реализации этой идеи разными специалистами, а эта вариация в более кратком виде была описана мною еще 5 лет назад в рассылке exim-users@exim.org (статью еще можно найти в архиве рассылки), но, несмотря на простоту реализации и наличие документации, сейчас они применяются почтовыми администраторами нечасто.

На примере почты компании «Horns'n'Hoofs» с доменом hornsnhoofs.com попробуем рассмотреть не выдуманные, а вполне работоспособные «в бою» приемы фильтрации.