. Хочу стать Linux Kernel Hacker, но.
Хочу стать Linux Kernel Hacker, но.

Хочу стать Linux Kernel Hacker, но.

Здравствуйте. Я студент, и меня интересует такой вопрос.

Мне нравится linux, интересно построение операционных систем. Сейчас читаю Таннебаума и Кернигана&Ритчи. Хочу стать настоящим спецом по ядру линукса. Но знакомые отговаривают и приводят такие доводы:

1) Процессоры развиваются, памяти становится всё больше, компиляторы умнеют, сборщики мусора работают всё лучше и лучше.

2) Работа скучная, придётся почти всё время сидеть в обнимку с дебаггером.

3) Работа скучная ещё и потому, что завязана на знании стандартов. Мало творчества, негде применять продвинутые алгоритмы.

4) Работа завязана на старых технологиях и подходах. Язык - С. Всё что есть в современном software engineering пройдёт мимо меня - паттерны, ООП, UML, MVC, функторы, акторы, функциональщина и многое многое другое.

Можете рассказать, что из этого правда, а что нет?

Работа завязана на старых технологиях и подходах. Язык - С. Всё что есть в современном software engineering пройдёт мимо меня - паттерны, ООП, UML, MVC, функторы, акторы, функциональщина и многое многое другое.

Ну разумеется ООП не будет. Просто потому что оно там и не нужно.

1) Процессоры развиваются, памяти становится всё больше, компиляторы умнеют, сборщики мусора работают всё лучше и лучше.

И какая тут связь? Из-за этого линукс вымрет что ли?

2) Работа скучная, придётся почти всё время сидеть в обнимку с дебаггером.

Без понятия, если честно. Я для драгонфлая, например, только фиксил баги. Тут более аналитические способности, а если не они то git bisect и история изменений.

3) Работа скучная ещё и потому, что завязана на знании стандартов. Мало творчества, негде применять продвинутые алгоритмы.

Тоже вещи параллельные - стандарты и алгоритмы.

4) Работа завязана на старых технологиях и подходах. Язык - С. Всё что есть в современном software engineering пройдёт мимо меня - паттерны, ООП, UML, MVC, функторы, акторы, функциональщина и многое многое другое.

Хорошая архитектура не зависит от языка. И ты ошибаешься, если ООП - это C++. В ядре linux наверняка ООП есть (во фре есть, по крайней мере).

Есть куча доводов против того, чтобы быть системщиком. но вот это:

гребаные баззворды. Аргументация на таком уровне - дешевые нубские понты.

А «продвинутые алгоритмы» приходится применять не реже, чем везде (т.е. почти никогда).

Есть куча доводов против того, чтобы быть системщиком.

А какие можно ещё привести доводы?

Хочу стать настоящим спецом по ядру линукса

И хотел бы, пошел не на ЛОР, а пофиксил бы баг 12309

Я ведь хотел сказать, что это баззворды, но перед пацанами стыдно. Сейчас сказали бы: «Ничего ты не понимаешь в мировых тенденциях. Иди пиши хеллоуворлды».

Я пока только учусь :)

Работа в основном без инструментальной поддержки (ага, отладка через printk), внимание к нерелевантным деталям (ты же на Си пишешь), периодическая необходимость знать неинтересную низкоуровневую муть типа деталей функционирования/багов конкретной шины IO или конкретных контроллеров прерываний. Короче, уровень абстракций низкий - не позволяет почувствовать себя крутым за счет навороченного фреймворка :)

Язык Си и низкоуровневое программирование по-прежнему актуально, так что не беспокойся. Просто ты слушал прикладников. А так работа тебе найдётся - кто портирует Android на новый смартфон? Кто программирует всякие микроконтроллеры? И всё это делается на Си, если не на Ассемблере вообще. Какая бы крутая железка не была, для неё всё равно сначала нужно написать драйвер.

Я ведь хотел сказать, что это баззворды, но перед пацанами стыдно

Ну, справедливости ради, всё это может быть полезным, но это уж точно не «самое интересное в SE».

А вот в драгонфлае есть такая фигня как vkernel - позволяет запускать и отлаживать ядро как юзерспейсный процесс (правда устройства пробрасывать не умеет, так что драйверы так не отладить). А в linux есть что-то подобное? Или самый лучший вариант - отлаживать его в виртуалке?

Лучше начни с хакинга самого себя для начала.

В Linux когда-то давно (еще до форка Dragonfly, да) был User-mode Linux. Он вроде и сечас жив, но, ИМХО, нерелевантен.

Просто потому что оно там и не нужно.

С ядра 2.4. Называется user mode linux.

Работа завязана на старых технологиях и подходах. Язык - С.

Вот мы ковыряем Openstack, и чем дальше, тем больше приходит понимание что это не софт, а операционная система. Только на следующем уровне абстракции. И все те же драйвера и файловые системы у нас, и сетевой стек, и kdbus, куда же без него. Вот systemd пока не хватает, сидим на инитскриптах..

И при этом регулярно приходится спускаться на уровень линуксового ядра и копаться в его проблемах.

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

Только надо понимать, что подходы и технологии - это вовсе не о языке речь. И не надо ограничиваться одним только «трушным сишным кодом» и делать вид что всё остальное тебя не касается.

п.1 - ерунда, ЯП со сборкой мусора никогда не заменят Си в его области. Все остальное - правда, к тому же учти что работу системным программистом найти куда труднее чем например веб-кодеру, а платят не то чтобы сильно больше.

а ты не лопнешь?

Типовые драйверы в ядре Linux отлично демонстрируют простое «ООП» на Сишке, если что.

Работа скучная, придётся почти всё время сидеть в обнимку с дебаггером.

СИСТЕМНЫЕ ХАКЕРЫ ОТРАЖАЮТ МЕДВЕЖЬЮ УГРОЗУ

И ОТГОНЯЮТ ЛЕТАЮЩИХ КРОКОДИЛОВ!!1

Ведро это целый мир трэшам, угара и чада кутежа.

1 - Есть embedded, где производительность не так высока и приходится сдерживать прекрасные порывы абстракционизма.

2 - Тут уж кому как. Иногда приходится и с дебаггером посидеть. особенно если драйвера пишешь.

3 - смотря что считать продвинутыми алгоритмами. диспетчеризация потоков в ядре - это тот ещё rocket science местами, RB-деревья и прочее. Другой разговор, что что-то непонятное без явного выигрыша в какой-то части и без особых регрессий в других, тебе Тролльвардс пропихнуть не даст.

4 - ООП в ядре есть, только тсс, никому ни слова об этом. а остальное изучается и применяется на сторонних проектах. Ибо если заниматься только ядром - очень быстро опухнешь и станешь злобным хикко-карликом.

А местами и с подвывертом.

Работа завязана на старых технологиях и подходах

чё мелочится , давай от русского и прочих языков разговорных откажимся ибо старые технологии и подходы,

ну и от арифметики( тоже не девочкова возраста) -

да и вообще адитивность величин это так не модно и совсем не прогрессивно,

ну а уж отсутствие делителей нуля совсем прошлая эра.

чё мелочится , давай от русского и прочих языков разговорных откажимся ибо старые технологии и подходы,

Ку и кю вполне достаточно.

кста реальне ООП это числа.

одно из самых абстрактных абстракций которыми ты оперируеш.

вообще если копнуть испорию и считать что эвм появились в том числе как следстиве взрыва математической логики то лучше понимаеш отчего структуры( предложеные Хоарам и сделаные в коболе) появились не сразу , да и появились у прикладников которые даже не вкурсе по жизни про возможность всё занумеровать т.е которым нужно отдельно поле яблоки поле апельсины а не одно хитроразрядкое яблосин.

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

Которых, кстати, сами и запускают. Just for fun.

Пасибище! Офигенский поток у чувака

1) Процессоры развиваются, памяти становится всё больше, компиляторы умнеют, сборщики мусора работают всё лучше и лучше

от этого работы (и CS в том числе) в ядре только прибавляется.

2) Работа скучная, придётся почти всё время сидеть в обнимку с дебаггером.

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

3) Работа скучная ещё и потому, что завязана на знании стандартов. Мало творчества, негде применять продвинутые алгоритмы.

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

4) Работа завязана на старых технологиях и подходах. Язык - С. Всё что есть в современном software engineering пройдёт мимо меня - паттерны, ООП, UML, MVC, функторы, акторы, функциональщина и многое многое другое.

с чего-бы? мало того что половина этого добра есть в ядрёной работе, так вам же никто не запрещает изучать и использовать сие в смежных вещах и просто так.

пункты 5 и 6 ТС просто не знает:

5) придётся дохрена читать мутных и кривых текстов на плохом английском. Во многих тонкостях ядра и актуальных новшествах можно разобраться только по блогах/публикациям авторов, в mail-архивах и по переписке. А авторы отнюдь не Шекспиры :-)

6) в какой-то момент заметишь, что подавляющую часть времени тратишь на блоги/публикации и переписку на кривом английском, отвечая на критику и защищая свой «продвинутый» алгоритм и пытаясь продвинуть-таки многолетний патчсет. Ядро это базар - там надо кричать

4) Работа завязана на старых технологиях и подходах. Язык - С. Всё что есть в современном software engineering пройдёт мимо меня - паттерны, ООП, UML, MVC, функторы, акторы, функциональщина и многое многое другое.

📎📎📎📎📎📎📎📎📎📎