CorePy является библиотекой для разработки на уровне ассемблера для процессоров x86, Cell BE и PowerPC. Простой API позволяет разрабатывать сложные высокопроизводительные приложения, использующие особенности процессора, включая многоядерность и потоковые расширения, такие как SSE, VMX и SPU, обычно недоступные из языков высокого уровня.

Основанный на передовой среде выполнения, CorePy позволяет разработчикам писать и выполнять низкоуровневые приложения непосредственно в коммандной строке или встраивать в Python приложения. За счет сокращения времени разработки низкоуровневых приложений CorePy значительно уменьшает существующий барьер при разработке низкоуровневых приложений.

CorePy является инструментом общего назначения, который можно применять при разработке широкого спектра приложений, включая разработку игр, мультимедийных систем, научных и высокопроизводительных приложений а также встраиваемых приложений. Эта библиотека использовалась для оптимизации приложений под процессоры x86, систем на PowerPC 970 и Cell BE и регулярно являлась более производительнее компилируемых языков для вычислительных задач (как обычное кодирование на asm :))

Один комментарий пользователя после нескольких часов работы с CorePy подытожил мнение большинства людей:

«CorePy опять сделал программирование на ассемблере интересным занятием!» (Alex Breuer)

CorePy был разработан Крисом Мюллером (Chris Mueller), Эндрю Фридли (Andrew Friedley) и Беном Мартином (Ben Martin). Значительный вклад внес Эндрю Ламсдейн (Andrew Lumsdaine) из Open Systems Lab университета Индианы.

CorePy это open source проект, доступный по лицензии BSD.

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

• Это было написано на PHP;
• Это было написано на таком PHP, что **** **** ***;
• Захардкожено было всё, и ни о какой расширяемости или настраиваемости речи не шло. А ведь нагрузка росла не по дням.

В общем, как настоящие русские парни, мы решили все сломать к хренам собачьим и построить заново, сделав красиво. Почесав репу решили, что apache+modperl — это для старпёров и не интересно, а fastcgi — путь слабых духом, поэтому все будем делать на nginx + его вечноэкспериментальный встроенный перл.

Позже я почувствовал себя на густозасеянном разного размера глаблями поле…

Уже были статьи про основы гита (0, 1, 2), были и статьи про внутреннее устройство репозитория. Сегодня поговорим, как простому смертному работать с гитом на автопилоте и не морочить себе голову.

Во-первых, шорткаты (в порядке убывания популярности):

alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'

Во-вторых, отображение текущей ветки в командной строке:

export PS1='`__git_ps1 "%s"` \w \$ '

Выглядит так:

lazy-args-in-futures ~/Work/io/oleganza-io.git $

(Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)

Типичный поток работы в одной ветке

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

Я встречал в сети много tutorial'ов по установке своего сервера git как на gitweb, так и на webdav, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной :)

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

Сегодня речь пойдет о:

• атомарных операциях в memcached;
• реализации счетчиков просмотров и онлайнеров.

Следующий пост будет посвящен проблеме одновременного перестроения кэшей.

Должен признаться, меня несколько смущало "щелкание винчестера" (WDC WD1200BEVS-75RST0) на моем Dell Inspiron. Я использую Ubuntu Linux и помню шумиху вокруг системы энергосбережения, которая должна была "убивать" жесткие диски наших компьютеров. В то время доказали, что это не более, чем глупости, что все будет исправлено и, вообще, переживать по данному поводу не стоит. Недавняя статья заставила меня еще раз более пристально понаблюдать за HDD и поэкспериментировать с настройками APM (advanced power management) и соотношением шум/производительность. Действительно, оказалось, что странные звуки вызваны парковкой головок диска.

Команды

sudo hdparm -M 254 /dev/sda
sudo hdparm -B 255 /dev/sda

решили проблему!

Однако, после перезагрузки я начал опять слышать характерные щелчки. Оказалось, что значение параметра '-B' (APM settings) не сохраняется. Для Ubuntu Linux решением этого оказалось редактирование /etc/hdparm.conf (раскомментировав 41-ю сроку получил запись 'apm = 255').

Если после данных манипуляций система не грузится, следует попробовать в grub дать параметр ядру 'nohdparm'.

Дополнительную полезную информацию можно найти на Ubuntu Forums.

 

На конференции Linux Plumbers Conference двое хакеров Арьян ван де Вен (Arjan van de Ven) и Оук Кок (Auke Kok) провели демонстрацию сразу двух систем Linux, каждая из которых загружалась быстрее пяти секунд. В первом варианте использовался модифицированный вариант дистрибутива Fedora, а во втором — модифицированный Moblin. В обоих случаях хакеры оптимизировали работу ядра (по вышеуказанной ссылке, а также в этом интервью можно узнать все подробности, что они сделали).

Разработчики уверяют, что результат показан без каких-либо трюков: окончание загрузки регистрируется только тогда, как CPU освобождается и прекращаются операции чтения с диска. Сама загрузка не включает в себя время входа в сеть, но включает загрузку NetworkManager.

Асинхронная инициализация железа позволила ускорить загрузку ядра до 1,02 с (на ядре 2.6.28 они уменьшат время до 0,5 с). Дальше загрузка шла параллельными потоками.

Raphaël — небольшая библиотека(20 килобайт) для построения векторной графики на веб-сайтах.

Она использует SVG и VML в качестве базы для создания графики. Учитывая то, что каждый созданный объект — DOM объект, то при помощи JavaScript обработчиков можно легко изменять их свойства и действия.

Допустим у вас есть сайт, на котором пользователи загружают видео, и это видео надо конвертировать в flv формат.
Делать это непосредственно после загрузки, в текущем рабочем потоке не хорошо, т.к. потоков этих ограниченное число, и при большой нагрузке сайт будет недоступен.
Будет гораздо лучше, если обработкой этих видео-файлов займется демон.

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

Обычно библиотеки python хорошо документированы. Однако случается, что иногда документации не хватает, особенно если речь заходит о веб-фреймворках и о каком-нибудь параметре request с десятком-другим свойств.

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

Update: похоже, что после обновления хабра появились проблемы с постингом больших статей. Старый текст, который был здесь ранее, хабр обрезал до середины, залить же новый мне не удалось — все время выдается ошибка «Возникла ошибка в получении XML данных: Internal Server Error» (насколько я понял, проблемы именно в большом объеме). Честно говоря, у меня сейчас нет ни времени ни желания разбираться с этим (к тому же переформатирование статьи из блога под хабр занимает довольно много времени), поэтому отсылаю вас к оригиналу — Очередной HowTo по Vim.

Привет всему сообществу Хабра.
Это мой первый пост и, надеюсь, не последний. Поэтому неизбежны всяческие недочеты, баги и некоторая водянистость текста, так что прошу строго не судить :)
К написанию этого поста меня сподвиг топик «Консоль для новичка.» habrahabr.ru/blog/linux/46610.html, где ISVir поднял острую, на мой взгляд, тему — как доступным языком рассказать новичкам о консоли, не отпугнув их мнимой сверх-сложностью.

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

Итак, что мы имеем:

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

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

в мане к find можно прочесть об остальных опциях и параметрах.

итак, с места в карьер — поиск всех файлов в каталоге /etc/, измененных за последние сутки:

Прочитав эту статью, я осознал, что Trac+SVN очень помогут в работе и решил настроить эту связку у себя на машине.

С недавних пор я использую Убунту линукс, потому установка и настройка проходили с учетом особенностей данной системы. LAMP у меня уже был установлен ранее, так же как и inadyn. В итоге я получил достаточно гибкую и удобную систему управления своими проэктами, к которой есть доступ по сети. Интересно, как сделать?

Как определить, что сайт сверстан качественно?
Есть много статей о том, как делать хорошо, но совсем нет – о том, как делать не надо, ведь даже валидный и кроссбраузерный сайт может быть сверстан отвратительно.

Из этой статьи вы узнаете:

• О плохих приемах современной верстки;
• О том, как даже не будучи профессионалом, за 5 минут определить плохо ли сверстан сайт или нет.

Отладка PHP-скриптов определенно недостаточно освещена в интернете. Потому многие, очень многие довольствуются print_r-ками. Очевидный недостаток такого способа — нельзя отладить AJAX, SOAP-сервисы, генераторы картинок и вообще скрипты, не отдающие непосредственно HTML-документов.

Javascript-разработчики используют для отладки Firebug. Как я им всегда завидовал. Лепота — выделенная консоль, net-монитор, отладчик, и все это в любимом браузере.

Так вот, нашел такое расширение Firebug — FirePHP. Оно позволяет выводить информацию в консоль Firebug непосредственно из PHP. Делается это довольно простым вызовом:

Когда в декабре я сказал себе: «Хватит с меня винды!» и перелез на Ubuntu 7.10 я, как наверное и многие, весьма сильно начал страдать от отсутствия нормального ICQ клиента. Никакие jabber-суррогаты меня не устраивали, даже не просите и не пинайте. Kopete и Pidgin — увольте. Они до сих пор не достигли функционала ни QIP'а, ни настроенной Miranda. Было обидно.

Когда идет речь о веб-разработках рано или поздно встаёт вопрос о том как и в чем подготавливать превью-картинки (thumbnail) на стороне веб-сервера. Вопрос о ручной подготовке отпадает автоматически, куда более приятно загрузить картинку и ни о чем больше не думать. Вот о том как не думать и пойдёт речь.