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 »

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

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

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

Read the rest of this entry »

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

Я просто в невібенному шоці — багатомільйонна європейська нація з кількістю розробників, які можуть створити три кремнієвих долини почала щось робити. Ну і типу зустрічайте: rozrobka.com.

Я аж ціпенію від шоку: здавалося б, стільки хороших перспективних хлопців, а інколи так туплять, що хоч бери, і головою цв’яхи забивай… Хоча, я все одно вірю, що усе буде меґа кльово!