Хочу стать 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, функторы, акторы, функциональщина и многое многое другое.