who wanna be software developer?

Чекати, доки ядро компілюється — завдання для дуже пасивних і спокійних програмістів. Та й фізично, як не дивно, далеко не завжди є достатньо часу. Ось кілька порад, які допоможуть пришвидшити цей процес:

1. Якщо у вас багатоядерний процесор — запускайте make з параметром -j, значення якого вказує на кількість процесів, на які розпаралелюється компіляція. Так, наприклад, make -j 2 розпаралелює компіляцію на два процеси, що суттєво пришвидшує її на двоядерних процесорах.
2. Якщо можливо — запускайте gcc з ключиком -pipe, який змушує компілятор використовувати пайпи замість тимчасових файлів.
3. Вимкніть параметр CONFIG_DEBUG_KERNEL, якщо він вам не потрібен.
4. Повимикайте в конфігурації ядра усі непотрібні (ну гаразд, бодай найбільш явні) параметри.
5. Встановіть і налаштуйте ccache. Він кешує об’єктні файли. Щоправда, з ccache потрібно бути досить обережним, бо той може наробити чимало проблем, якщо вам потрібно перезібрати ядро з нуля, в такому разі не забувайте чистити кеш ccache.
6. Спробуйте distcc, який розпаралелює компіляцію на кілька фізичних машин.
7. Якщо маєте бодай 2 Ґб оперативки — спробуйте tmpfs. Він дозволяє змонтувати будь яку теку прямо в оперативну пам’ять, що суттєво пришвидшує роботу з тимчасовими файлами, яких під час компіляції створюється дуже не мало. Приклад:

# sudo mount -t tmpfs -o size=700M, mode=0777 tmpfs /usr/src/linux

Цей допис є продовженням і доповненням першого (Розробка для ядра Linux — 1. printk(“Привіт, світе!\n”)). Тут я розгляну такі базові, але дуже важливі речі, як залежність версій і таблиця символів ядра.

Read the rest of this entry »

Я нещодавно серйозно (як мені здається) взявся за вивчення такої крутої штукенції, як “Linux kernel development”. Я вихований девізом “I’ve learned. I’ll share”, тому спробую ділитись новою для мене інформацією з вами.

На жаль, у мене немає ані часу, ані бажання розжовувати кожну тему, до того ж, теоретичного матеріалу, як мені здається, предостатньо. У мене найбільші проблеми виникають при пошуку достатньо простих для розуміння прикладів. На них я і спробую зосередити свою увагу…

Read the rest of this entry »

Повернувся з конференції IT Jam 2009, котра, як не дивно, проходила у Києві, 5 грудня 2009 року.

Конференція велика, мабуть, найбільша в Україні з тих, що присв’ячені розробці програмного забезпечення (виправите мене?), організована компанією Ciklum, імовірно, для власного піару, подібного до того, як це робить корпорація Google зі своїми Google Developer Days, у чому, власне, немає нічого поганого.

Організовано усе досить не погано: шість окремих залів, розділених по категоріях:

• Agile (Scrum, XP, kanban), RIA (Flash, Silverlight, Flex)
• RIA (Flash, Silverlight, Flex)
• Dynamic Programming Languages (Ruby, Python, Perl)
• Mobile Development (iPhone, Android, Blackberry)
• CMS (Drupal, EPiServer, Joomla)
• Others

Read the rest of this entry »

Гаразд, вступу про користь і потрібність використання систем керування версіями не буде — це банально і тупо.

Проблема у тому, що їх використовують переважно для годиться, або ж тому що цього вимагає корпоративна/проектна політика. До того ж, далеко не найефектнішим чином, сприймаючи їх просто, як “місце, де зберігається уся ця фігня”. Гаразд, про це також не будемо, бо і це тема, про яку дуже багато написано.

Існує інша серйозна, і чомусь мало висвітлена (а може я просто надто мало читаю?) тема — фіксація зроблених змін. Під час, скажімо, періоду баґ фіксингу, усе зрозуміло: зафіксив баґ, [залив на review board,] закомітив. У такому випадку, і тобі просто організовувати політику комітів, й історія на сервері виглядає гламурною. Що ж робити під час активного девелопменту? Зі своїх спостережень, можу сказати, що більшість комітить власний код або у кінці робочого дня, за 30 секунд до вимкнення комп’ютера, або ж коли той комусь потрібні (колезі, тім ліду, рев’юверу, менеджеру, клієнту…).

Read the rest of this entry »