Стоит учитывать разницу в надежности (та же память, например ECC существенно понижает вероятность инверсии бита), нормальные аппаратные raid'ы, нормальные SAS диски, нормальные процы (на разных паттернах xeon e7 и core i7 существенно различаются и под серверные задачи лучше использовать xeon), нормальные блоки питания с горячей заменой. Плюс тестирование всего этого барахла (как например отличаются электронные компоненты с военной приемкой и без)…
Здесь в первую очередь вопрос юзабилити. И упрощенные языки разметки здесь выигрывают, как мне кажется. Разметка, используемая в muse напоминает тот же markdown.
Я при написании статей пишу их в немного модифицированном markdown, после чего конвертирую в html.
Например, я не ожидал, что будет столько голосов за bbcode, который по удобству написания сравним с html.
которая даст доступ с <remote_host>:<remote_port> к <local_host>:<local_port>.
Следует также упомянуть полезные ключи -N и -f. Первый указывает, что на удаленной стороне не нужно ничего выполнять, второй отправляет в бэкграунд. Удобна их комбинация, если надо только пробросить порт.
Извините, если ошибся. Данное сильное предположение базируется на том, что Вы проживаете в Иркутске (судя по профилю). А в Сибири живет существенно меньше иностранцев (id est не граждан РФ) чем, скажем, в Москве или на Дальнем Востоке.
Вспоминается cgit (веб интерфейс к гиту). Очень напоминает перловый gitweb (который поставляется по умолчанию). Написан на C. Под CGI вообще без разницы, если стандартными средствами можно прочитать env-переменные и стандартный ввод и писать в стандартный вывод.
Строго говоря, это не сопроцессор, а часть ядра ARM. И режим jazelle аналогичен thumb, тоже отражается в CPSR, использует специальную команду BXJ для перехода на java-байткод. Встраивается в pipeline ядра перед декодированием инструкции.
Кажется, такие микросхемы (процессоры) есть для Java.
Не совсем так. Например, у ARM есть режим в котором может исполняться байткод, да не весь. То, что не умеет процессор — вызывает прерывание, в котором и происходит обработка более сложных инструкций.
Это аналогично популярной ныне виртуализации, где большая часть кода выполняется на реальном процессоре, а небольшое подмножество команд — программно.
Много больше. Даже на x86/x86_64 их больше одного.
Что уж говорить о других архитектурах, где каждый городит свой asm. Все таки ассемблер тесно связан с машинным кодом и отражает архитектуру конкретного CPU.
Для этого необходимо делать периодический rebase feature-ветки на upstream. Это позволяет поддерживать кодовую базу feature-ветки в актуальном состоянии.
Например, в случае gettext все наблюдаемые (предназначенные для вывода) строковые литералы на английском обрамляются в вызов специального макроса _("...").
В сборку добавляется дополнительный этап генерации *.po-файлов, которые определяют маппинг исходных строковых литералов на локализованные сообщения. Полученный *.po-файл отдается переводчику.
Это, конечно, только часть локализации. Но существенно лучше, чем ничего.
При локализации
Дорого, очень. Зато всё прекрасно с резервированием, занимаемым местом и потребляемым питанием.
HAML удобен для описания layout'а, а не написания контента. Прекрасная статья по этому поводу: chriseppstein.github.com/blog/2010/02/08/haml-sucks-for-content/
Я при написании статей пишу их в немного модифицированном markdown, после чего конвертирую в html.
Например, я не ожидал, что будет столько голосов за bbcode, который по удобству написания сравним с html.
В той части, где Вы указали local_host указывается к какому хосту и порту будет привязан проброшенный туннель на удаленной стороне.
Ещё полезна обратная фича
которая даст доступ с <remote_host>:<remote_port> к <local_host>:<local_port>.
Следует также упомянуть полезные ключи
-Nи-f. Первый указывает, что на удаленной стороне не нужно ничего выполнять, второй отправляет в бэкграунд. Удобна их комбинация, если надо только пробросить порт.Не совсем так. Например, у ARM есть режим в котором может исполняться байткод, да не весь. То, что не умеет процессор — вызывает прерывание, в котором и происходит обработка более сложных инструкций.
Это аналогично популярной ныне виртуализации, где большая часть кода выполняется на реальном процессоре, а небольшое подмножество команд — программно.
Что уж говорить о других архитектурах, где каждый городит свой asm. Все таки ассемблер тесно связан с машинным кодом и отражает архитектуру конкретного CPU.
Так и рождается код, который непонятен даже его написавшим.
Например, в случае gettext все наблюдаемые (предназначенные для вывода) строковые литералы на английском обрамляются в вызов специального макроса _("...").
В сборку добавляется дополнительный этап генерации *.po-файлов, которые определяют маппинг исходных строковых литералов на локализованные сообщения. Полученный *.po-файл отдается переводчику.
Это, конечно, только часть локализации. Но существенно лучше, чем ничего.
При локализации