0. Intro.

Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

Возникла задача: у нас есть компилятор собственного языка программирования, которым мы компилируем некоторый диалект бейсика в исходник на C.

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

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

Несложная задача. Только есть одно «но». Количество исходников, которые планируется использовать как эталонные — около 15 тысяч файлов, суммарным объемом чуть меньше гига (для удобства они завернуты в один TAR). Подобный «прогон» может быть весьма долгим. И есть естественное желание сделать тест максимально быстрым, используя многопроцессорную машину, ибо задача прекрасно распараллеливается.

Как вариант — можно сделать Makefile и запускать его с ключом "-j" в GNU Make. Но если написать специализированную многопоточную программу, то можно достичь лучшей производительности.

(вторая часть перевода статьи Разоблачение алгоритмов растеризации шрифтов)

Linux

Наследуя худшее

Windows растеризует шрифты плохо, Linux ещё хуже. Во всех Linux-системах, которые я видел, используется FreeType [10] Дэвида Тёрнера, Роберта Вильгельма и Вернера Лемберга. Это отличная библиотека, но способ её использования, к сожалению, нельзя назвать удачным. Типичный скриншот Linux выглядит так:



Вот полный скриншот:
ссылка

Сразу заметна проблема — чёрные пятна в скругленных углах, образовавшиеся в результате сглаживания. Вцелом, можно сказать, что косые штрихи выглядят тяжелее чем вертикальные, что в регультате производит впечатление «грязи». Вы можете возразить, что FreeType и Linux могли бы использовать схожую с ClearType субпиксельную растеризацию, но по мне это не даёт заметных преимуществ.

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

Добрый день, Хабражитель!

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

Итак, в данном посте я постарался изложить самые важные и значимые на мой взгляд моменты по работе со Swing и графикой — как создавать компоненты, как стилизовать интерфейс, чего делать не стоит и многое другое…

Вопрос на пять: что напечатает эта простая программа:

    #include <stdio.h>

    typedef int a;
    a b = 5;

    int main()
    {
       a(b);
       printf("%d\n", b);
       return 0;
    }

Уже натерпевшиеся от своего любимого языка, но ещё не прошерстившие всех бизонов gcc, почувствуют подвох — и правильно. Подсказка номер ноль: это скушает С++, но и простой С не подавится.

Здраствуй, Хабражитель!

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

Итак, сегодня я приведу здесь библиотеки, которые могут Вам помочь решить часто возникающие вопросы вроде «Как сделать это на Java?» по разным узким направлениям разработки.

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

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

Продолжаем описание классификатора порнографического видеоконтента, разработанного компанией Inventos (Licenzero, присутствующее в заголовке это не отдельная компания, а подразделение в компании Инвентос).

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

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

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

Часто (в том числе и на хабре) всплывает вопрос освещения, особенно «нанотехнологиченого» светодиодного и зачастую говны священных войн «светодиод» против люминисцентных ламп начинают подбурливать. Больше года я уже собирался написать статью о свете, и оно наконец свершилось.
Из этой статьи вы узнаете почему в фотостудиях не снимают с люминесцентными лампами, почему светодиоды до сих пор не захватили мир и стоит ли ими освещать улицы. Поехали!

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

Я отношу себя к категории ленивых фотолюбителей. У меня есть неплохая «беззеркальная зеркалка», иногда на меня нападает желание пощёлкать чего-нибудь вокруг себя. Однако я ленив, и ковыряться потом в полученном фотоархиве у меня ни времени, ни желания нет. Как правило фотографии просматриваются один-два раза сразу после съемки путём подключения фотоаппарата к телевизору через HDMI кабель. Затем фотографии отправляются в небытие каталог ~/Pictures/Photos/Unsorted и, как правило, остаются там навсегда. С различным спец. ПО я как-то не сдружился, посему этот бардак просуществовал почти два года. И вот, на волне изучения Haskell, я созрел для решения проблемы.

В данном топике речь пойдет о причинах, вызывающих длинные паузы сборщика мусора и о способах борьбы с ними. Рассказывать я буду о CMS (low pause), так как на данный момент это наиболее часто используемый алгоритм для приложений с большой памятью и требованием малой задержки (low latency). Описание дается в предположении, что у вас приложение крутится на боксе с большим объемом памяти и большим количеством процессоров.

Пользователь yruslan опубликовал хорошую статью про арифметику с плавающей запятой: «Что нужно знать про арифметику с плавающей запятой».

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

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

Урок 1 <<

Вступление

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

А именно: я расскажу о том как лучше смоделировать гусеничное шасси в 3d редакторе для того чтобы оно могло адекватно двигаться и реагировать на неровности ландшафта, также дам вам готовую модель которую вы можете видеть в демо, затем вы узнаете как все это дело оживить и привести в движение с помощью Wheel Collider’ов.

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

Сервис так понравился нашей команде, что мы решили поделиться им с вами.

В комментариях к нашей предыдущей статье высказывались вполне логичные претензии, в основном – от тех, кто в теме. Дескать, приведенный нами пример проектирования детали компьютерного корпуса в системе CATIA – это форменное забивание гвоздей микроскопом. Действительно, если перевести аналогию на более привычные пользователям Хабра IT-решения, это все равно, что устанавливать фотошоп только для изменения размера картинки. С компьютерным корпусом, допустим, справится и более простая система автоматизированного проектирования, но начать нам хотелось с какого-то простого примера.

Теперь перейдем к сложному и более реалистичному. Одним из клиентов Dassault Systemes (французской компании) является французский же автоконцерн PSA Peugeot Citroen. В разработке автомобилей этого альянса используется не только 3D CAD-система CATIA, но и многие другие программные решения. Вместе они составляют целую систему, которую принято коротко именовать PLM (Product Lifecycle Management) – Система управления жизненным циклом изделия. Собственно проектирование какого-либо продукта – это только небольшая часть всей системы.

Огромное внимание уделяется вопросу управления деятельностью крупного предприятия, у которого могут быть тысячи сотрудников, так или иначе ответственных за конкретный проект, сотни подрядчиков и десятки проблем, возникающих каждую минуту и требующих решения. Фактически система PLM настолько многогранна, что включает в себя многие элементы других (тоже непростых) программных комплексов, названия которых также состоят из трех букв: CRM, ERP и так далее. Только здесь продукт поставлен во главу, а значит такое решение – для компаний, создающих то, что можно потрогать руками. Например, автомобили.

Внутри – начало рассказа о системе PLM с точки зрения менеджера проекта, а также простой пример проектирования конструкции автомобиля в CATIA V6.

Тут смотрите какое дело…

Вступление

Итак вы уже не новички в Unity, вы умеете создавать сцену, расставлять объекты на сцене, создавать terrain, делать префабы и тд… и главное — работать со скриптами, либо вы уже изучили статьи: Unity3D для начинающих — Туториал 1 и Unity3d script basics. Все эти знания вам пригодятся ведь в этом уроке мы двинемся намного дальше.

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

Собственно то что вы видите на изображении сверху (это будет результат данного урока) вы можете опробовать «вживую» прямо в браузере. Хотите сделать это сами? Тогда добро пожаловать под кат

Перевод статьи "(How to Write a (Lisp) Interpreter (in Python))" Питера Норвига. В данной статье Питер довольно кратко, но емко описывает принцип работы интерпретаторов и показывает как можно написать совсем крошечный (всего 90 строк на Python) интерпретатор подмножества языка Scheme. Перевод публикуется с разрешения автора.

Питер Норвиг (англ. Peter Norvig) — американский ученый в области вычислительной техники. В данный момент работает директором по исследованиям (ранее — директор по качеству поиска) в корпорации Google. Ранее являлся главой Подразделения вычислительной техники в исследовательском центре Амес NASA, где он руководил штатом из двухсот ученых, занимающихся разработками NASA в областях анатомии и робототехники, автоматизированной разработке ПО и анализа данных, нейроинженерии, разработки коллективных систем, и принятия решений, основанном на симуляции.