MrWater

Зачем я постоянно отвечаю на такие вопросы?

Учись, учись и ещё раз учись. Я вот тоже где-то в твоём возрасте захотел осилить ИБ, даже профильный бакалавриат отучился, да вот... Не то это всё, ну не то. Но есть и плюсы, на данный момент очень много нерешённых проблем, которые решать как-то всё таки надо, да и подходов даже к их решению качественно не сложилось, другое дело физика - с ней всё проще, видишь, записываешь, выводишь модель, подтверждаешь, повторить. В ИБ всё сложнее, тут какие-то машины Тьюринга, теоремы ВЫП, 3-ВЫП и прочая ересь, да, в этом есть своя красота и логика, но уж чего точно здесь не встретить - так это простоты.

К вопросу о математике, она простая. Самое сложное и контр-интуитивное что тебе потребуется в ИБ - так это теория вероятностей. Вот простейшая задачка: есть 8 шкатулок, с вероятностью 50% в одну из них положили рубль, потом открыли 7 шкатулок подряд и рубля в ней не нашли. С какой вероятностью в последней, восьмой шкатулке окажется рубль? Это очень простая, в некотором смысле даже классическая задача в теории вероятностей, охватывающая базовые вещи, решать её имеет смысл именно что в лоб, без использования всяких ухищрений. Это не сложно, там одна формула, но понять её на качественном уровне не так-то просто, но любое помехоустойчивое (WiFi) и энтропийное (7zip) кодирования эксплуатирует эти идеи во всей своей красе. Рекуррентные выражения, вычеты, поля и операции над его элементами, да щепотка комбинаторики, в общем-то большего и не требуется. Очень логичная, с ограниченным набором правил.

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

Алсо. Отдельная история со скрипт кидди. Лично по мне это должна быть чрезвычайно низкооплачиваемая должность ибо по сути от бабушки, умеющей включать ПК, такой ремесленник мало чем отличается. Объём данных возрастает, ну да ладно. Немного сложнее быть аналитиком, тут потребуется не просто ПК включать, но и отчёты писать, но в целом он не сильно дальше ушёл, а современное ПО нередко само отчёты составляет, только печатай и подпись ставь.

UPD. Немного системы не помешает (искать очень просто, выделяем ISBN, ПКМ, отправить в гугл, радуемся):

1. Талмуд "от и до", очень помог в своё время и помогает иногда до сих пор. Алгоритмы. Построение и Анализ, Кормена, Лейзерсона и других. 978-5-8459-2016-4
   
2. Высокоэффективная и чрезвычайно информативная, простая и сложная, интересная и потрясающая. Конкретная Математика. Кнут, Грэхэм, Паташкин 978-5-8459-1923-6
   
3. Кибернетика? Преобразования фурье? Без паники! Цифровая Обработка Сигналов. Юкио Сато. 978-5-94120-251-5
   
4. Что это? Манга? Про статистику? Да ну! Занимательная Статистика от Сина Такахаши. 978-5-94120-244-7
   

Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

UPDATE
На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,

Общие советы, что уже были даны:
+ учи js,
+ учи english хотя бы до intermediate,
+ генерируй портфолио,
+ какой же верстальщик без своего сайта? сделай его идеальным и храни там своё портфолио и контакты, по возможности ставь на создаваемые сайты свой копирайт со ссылкой на портфолио (конечно, если заказчик не возражает),
+ в свободное время потерзай какой нибудь backend (RoR или Django)

От себя добавлю: бросай PHP и никогда о нём не думай, может он и становиться лучше, но ему никогда не избавиться от своего тёмного прошлого (и переменных со знака доллара, вот ужас!). Когда будет пара хороших отзывов, смело иди на фриланс биржи, вроде odesk. C RoR и хорошим, красивым, технологичным, кроссбраузерным фротендом там вполне можно иметь и по $100 в час.

Ах да, учись быстро копипастить. Использовать плагины. Избавляйся от всяческих попыток напилить велосипед, даже если так будет быстрее и лучше. Со временем, это мастерство позволит тебе делать сайты со скоростью пулемёта. Тогда ты постигнешь тёмный дзен и получишь свою порцию печенек. Я на полном серьёзе, когда ты поднимаешь сервер за 2 минуты, ставишь на него Bootstrap за 1 минуту и подгоняешь его (натягиваешь вёрстку из заранее созданных темплейтов) за 5 минут, обвешиваешь нужными виджетами из js, html5 и css3 за 5 минут и через 15 минут после получения заказа отправляешь заказчику наступает странное чувство эйфории. Конечно, это непостяжимый дзен, как всегда, по закону Мёрфи, какая-нибудь библиотека отвалиться, что-нибудь заглючит, а где-нибудь поползёт вёрстка и дебаг займёт пару часов, но всё же, делать полноценный сайт за 3 часа - бесценно. Для всего остального есть MasterCard.

Тут все пишут про отличия. Рискну написать про сходства.

Во-первых, о чём бы ни писала Елена и Си++ и C# - оба языки общего назначения. Даже больше, оказывается - C# ни разу не заточён под объёмную библиотеку (или фреймворк) .NET, однако с ним намного, много проще. Но если таки учитывать .NET, то для Си++ есть Boost и Qt, так что здесь скорее паритет - библиотек для обоих хватает.
Во-вторых, сложность разработки на Си++ часто преувеличена. Разве только дисциплины надо поболее - выстрелить в ногу здесь попроще. Однако при этом Си++ будет чутка более гибкий и без танцев с бубнами unmanaged код не запустить на C#. Если внезапно потребуется.
В-третьих, оба языка, раз они общего назначения, таки мультипарадигмальные. То есть они реализуют большинство практик. И хотя Си++ развивается довольно медленно, сейчас Си++ резко догнал C# в плане нереализованных фич (здесь как минимум лямбды). Ну и метапрограммирования у Си++ поболее будет (наглая ложь).
В-четвёртых, оба языка кроссплатформеные. Впрочем, C# будет более кроссплатформенный, чем Си++. Разве только тот же Qt резко стёр границы, но это не значит почти ничего - C# компилируется в тот же самый CIL для всех платформ, Си++ - в совершенно разный код для разных платформ (i386, amd64, ARM Cortex-AXX).
Наконец, в пятых, синтаксис у них действительно очень похож. Оба языка принадлежат к семейству Алгол-подобных, так что и брейсы, и остальные скобки здесь имеют примерно одно предназначение.

Различия, которые казалось бы делают языки совершенно разными, таки не столь принципиальны на том уровне абстракции, на котором был задан вопрос. А различия действительно колоссальны: C# - managed код, что означает, что скомпилированный код будет исполнятся не на прямую в CPU, а на специальной виртуальной машине. Это съедает производительность, но сильно облегчает перенос кода. Ну и потом, C# - полупроприетарный ответ Java (что интересно, так как получается, что C# - более свободный, чем Java), которая была создана как замена сложному и небезопасному C++ в том числе.

В общем, как человек, который начал давно с C#, продолжив C++ и по пути изучив Python, Java, D и другую ООП-чушь могу с уверенностью сказать, что разницы в общем-то и нет... То есть придётся немного проникнуться в чуть другую философию и выяснить, какие проблемы более новый язык пытался решить. Но если подходить к этому, как подошёл lookid, то это скорее не как изучать языки одной языковой группы, а как изучать один и тот же язык в разное время или в разных сферах.

Почему так? Потому что ООП... Оно как бы ООП, ничего сверхъестесственного ни один язык не предлагает, это не Haskell, и тем более не Brainfuck. Так что принципиально общие вещи в них будут. То подмножество, что реализует машину Тьюринга - у них общие. Сами посмотрите: циклы, ветвления, передача аргументов, арифметика... С небольшими правками всё совершенно одинаковое. Да, Дмитрий совершенно прав, traits на C# не повторишь, ибо та аналогия будет уже не traits, однако... Это уже [programming_language] related, то есть это попытка совладать с особенностями.

Немного пруфов: лично я ходящий пруф. Зная C++ и C# и немного Java я просто начал программировать на Python. При том, что Python даже алголоподобным не принадлежит. А всё потому, что логика одна и та же, хотя различий между Python и C(++|#) намного, много больше. Но не читая почти никаких туториалов, пройдясь галопом по европам с документацией сейчас я знаю python достаточно для серьёзного проекта.

UPD. По поводу метапрограммирования... Таки рантайм рефлекшн шарпа тащит. И хотя ни макросов, ни шаблонов, ничего. Но изменять код на лету - это уже очень круто. По дефолту плюсы так не умеют, и хотя шаблоны с макросами тащат, сильно, очень сильно тащат и вытаскивают его, Си++, со дна, надо признать - рефлешн у шарпа будет поинтереснее. Извиняюсь за дезу.

Начнём с того, что Лисп не функциональный. Тем, кто приходит в Лисп из мира императивных языков может так казаться, но я пришел в Лисп после Хаскела и я тебе точно говорю, Лисп - не функциональный.
Теперь по теме - оба языка крайне интересны и способны взорвать мозг, но Хаскел вставляет сильнее, он действительно заумный и изобилует супер-дупер новыми изощренными технологиями программирования (Аппликативные функторы, комбинаторы, монады, ленивые вычисления), но что тебе действительно взорвёт мозг - это чистота языка (нельзя совершать побочные эффекты т.е. не напишешь в консоль где хочешь, не присвоишь значение переменной), отсутствие циклов и декларативность (ты не пишешь "как", а пишешь "что" представляет из себя задача). Но это только в начале. Когда освоишься, оказывается, что Хаскел очень выразителен и краток. Но есть у него и минусы - он очень сложен, ОЧЕНЬ. Серьезно, даже через пол года, у тебя по-прежнему будут проблемы. Уверен, 95% хаскелистов не объяснят в подробности, как работает Hello world на хаскеле, который выглядит так:

main::IO ()
main = do
putStrLn "Hello world!"

выглядит не сложно, но вот что скрывается под водой: все вычисления происходят в монаде IO т.к. только в ней разрешены побочные эффекты. Побочный эффект (действие ввода-вывода) выполняется только тогда, когда вернётся в main т.к. побочные эффекты разрешены только в main (поэтому и только в монаде IO т.к. main возвращает IO () ). Что такое IO ()? Это как бы список действий, которые туда запихиваются и объединяются в цепочку, чтобы быть последовательными (вне монады порядок выполнения твоих инструкций не определён, счастливого дебага). Эти действия на самом деле не выполняются сразу, а представляют из себя "обещание" сделать это действие, которое реализуется как только что-то уже действующее не затребует результат, в нашем случае это консоль... в общем и это только верхушка айсберга, я еще про типы не говорил, про извлечение и упаковку в монаду, про отображения множеств, карринг и тд.
В общем хаскел это интересно, но очень сложно. Даже если не пообломаешь зубы, у тебя очень долго будут проблемы с дебагом, с пониманием всяких астральных техник, которые плодятся день и ночь, вроде стрелок или линз. Да и понять чужой код на хаскеле часто очень сложно, потому что каждый считает, что просто обязан применить все заумные штуки, которые он знает, ведь разве не для этого он учил хаскел? А ведь потом люди будут читать это...
Теперь пара слов о Лиспе - тут у меня меньше опыта, но идея такая - это программируемый язык программирования. Кроме того, что в нём есть макросы - специальные инструменты, чтобы писать программу которая напишет программу, так и сам язык представляет из себя синтаксическое дерево в своём первозданном виде, что открывает безграничные возможности в метапрограммировании. В общем идея такая - этот язык в умелых руках становится абсолютно чем захочешь. Нравится хаскел и ФП? Отлично, сейчас реализуем. Хочешь ленивые вычисления? На! Хочешь классы? Вот! Хочешь логическое программирование? Держи! При всём этом язык крайне прост, может даже проще Си.
Так, что я тебе посоветую? Наверное, начинай с Хаскела - он тащит за собой огромную теоретическую базу и целый арсенал таких приёмов программирования, которые тебе и не снились. Выучишь, освоишься - подумай о лиспе. Но! Тебе в любом случае нужно будет ставить Emacs - это самая лучшая среда для этих обоих языков, а Emacs конфигурируется на Emacs Lisp, так что у тебя будет возможность на него посмотреть. Посмотри видео по емаксу https://www.youtube.com/playlist?list=PLECBtie1W1t... (там и про Emacs Lisp есть глава), потом качаешь "Хаскел во имя добра" и "О хаскел по-человечески" и читаешь их параллельно - в первой хорошее мягкое введение, а во второй практика - она нужна сразу, чтобы хотябы знать, как создать проект с помощью cabal и собрать его, а то Липовача пол книги в интерпретаторе сидит.

Опираясь на свой личный опыт общения с заказчиками на Upwork, могу сказать что их там две группы:

1. Тем, кому надо по дешевле
   
2. Тем, кому надо
   

В первое время ты работаешь за символическое вознаграждение, набираешь опыт, отзывы, профиль работ. В этом тебе поможет первая группа людей. Затем, когда люди видят что ты реально можешь делать работу, которую им надо, ты начинаешь работать с людьми второй группы, где уже ставки повыше.

Лично у меня был рубеж в 25 проектов в диапазоне 30-50 у.е., после которого я зашел на hourly rate контракт, по которому работаю до сих пор.

https://github.com/zualex/devmap
images.vfl.ru/ii/1466366676/e324255d/13079149.png
www.webdesigndegreecenter.org/learn-to-code

Никакие и все.

Немного лирики. Дело в том, что нейронные сети штука очень непонятная. Она неплохо классифицирует, вроде бы умеет учиться. Но вот принимать решения она почти не умеет. То есть, в каком-то смысле она принимает решения, во время классификации, соотнося образ к паттерну, однако на деле всё как-то печальнее. А ещё она совершенно не умеет выполнять алгоритмы в классическом смысле слова. Ну и получается, что вся суть нейронной сети, всё, что она будет делать определяется её параметрами и входными данными. Вроде бы и похоже на алгоритм, но алгоритм можно определить 1) без входных параметров (классический), 2) не параметрами, а набором действий. Нейронная сеть более... Аналоговая.
Отсюда мы подходим к тому, что нам обязательно нужен будет дифференциальный и функциональный аппараты. К сожалению, современные компьютеры не способны адекватно работать с бесконечно малым и большим, поэтому нам обязательно потребуются методы приближения: это и сами вычислительные методы, и некоторые методы оптимизации (они и по другим причинам потребуются). Да и совсем не лишними будут теория чисел, статистика, мат.логика и определённо более общие теории вероятностей и случайных процессов.

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

Но стоит понимать, что все эти разделы очень тесно переплетены. Не получиться поднять какую-то одну часть отдельно от другой. Всё взаимосвязано. Вообще, очень рекомендую khan academy - наикрутейшая штука. По всей видимости, есть всё, что я здесь описал.

Нажал ctrl+enter рановато...
Как можно заметить, в общем-то нужна вся математика. Если какой-то раздел не указан, то он скорее всего будет затронут в других разделах.

Однако, нейронные сети очень новая... Практика. По сути они работают примерно так: мы берём туеву хучу интегральных и дифференциальных уравнений, берём какое-то приближение и реализуем "квантуя" и "дискретезируя", а потом запускаем. Причём в момент отсчётов всё вроде бы хорошо - процессы идут, ошибка обратно распространяется, однако... Есть небольшая проблема в том, что между этими обновлениями нашей модели как бы и не существует. И если в реальном мире частота дискретизации ну невероятно высока, настолько, что мир кажется гладким (впрочем, есть возможность, что он такой и есть - сейчас не совсем понятно, какой мир и в самом деле), однако в нашей модели эта частота получается ну очень низкой. Поэтому учёные просто молятся, чтобы ничего плохого между этапами существования их модели не произошло. Честно говоря - сомнительное занятие.

Так что, если не желаете продвигать науку вперёд, очень советую бросить это дело. Можете построить пару простейших перцептронов, однако на большее советую не рассчитывать. Сыровато.

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

Вопросы 1 и 2 я пропущу- потому что это спровоцирует тут нехилый холиварчик :) В понятие "лучший" всегда вкладывается личный смысл. С моей точки зрения для серверов лучший дистриб - это CentOS. Если бы они не продали душу Поттерингу в 7-й версии - я бы с него не ушел.
3. Любой популярный дистриб имеет множество приложений, дополнительных репозиториев, коммунити. Оно может быть больше или меньше, но оно всегда есть.
4 - 5. Любой дистриб, потому что большая часть приложений работает в любом дистрибе
6. Любой source-based. Все пакетные дистрибы основаны на том факте, что Вы ставите только пакеты и руками в систему не лезете, некоторые даже не предполагают работу в консоли - только через настроечный гуй
7. Gentoo однозначно. Если уж совсем хочется полного хардкора - slakware или LFS
8. Коммунити есть у каждого дистриба.

В развитии дистрибов есть сейчас две линии - и как бы мы ни открещивались от этого, оно существует обьективно. Есть пакетные дистрибы, развитие которых идет в сторону приближения к юзеру - в сторону упрощения, уменьшения, скрытия. Почему им всем понравился systemd - c одной стороны он свою работу делает, с другой стороны он мутный, сложный с бинарными логами - юзер просто так в него не полезет. Пакетные дистрибы основаны на том факте, что ничего в систему не ставится помимо пакетов, если же это правило нарушить - можно огрести много-много проблем. Они конечно все решаемые, но нужно иметь достаточную квалификацию, чтобы их разгрести.
Есть source-based дистрибы, развитие которых идет по классической линии - для того, чтобы развернуть систему, нужно обладать достаточной квалификацией, чтобы ее развернуть. Старт там труднее, но после того, как одолеешь порог входа, работа с любым пакетным дистрибом щелкается как орешек.
Почему обычно советуют бубунту? Считается, что это наиболее легкий в освоении дистриб. Но освоив бубунту/федору/дебиан или даже центос/RH/SUSE - Вы освоите именно дистрибутив. Да, знания по общему устройству Linux тоже будут. Но в основном будут знания о том, какими кнопочками (в лучшем случае, какими командами) настраивать те или иные сервисы - установка дистриба, управление пакетами и настройка сервисов в любом дистрибе своя. Освоив source-based дистриб - Вы освоите именно Linux - потому что понятие "дружественный source-based дистриб" - это немного анекдот. Чтобы этот "дружественный" дистриб взлетел - придется долго и упорно гуглить.

eax.me/programming-language-learning - вот очень хорошая практика.

Да что же вы все думаете, что нужно платить огромные $$$ для обучения.
Есть куча ресурсов с бесплатной информацией, к примеру - startandroid.ru - бесплатные видеоуроки, статьи.
Есть официальная документация, где все разжевано , но только нужно знание английского(да и без этого можно обойтись, есть 100500 разных переводчиков).
Не хватает практики? Так возьмите и напишите что-нибудь, если нехватка фантазии, то пролистайте play market , попробуйте написать что-нибудь что понравилось, вот вам и практика.
За год-два можно набраться хорошего опыта для работы в более менее профессиональной компании и получать доход от 50 до 100т. и больше в зависимости от опыта. Маленький город - это не проблема если есть интернет, выучите , практикуйтесь, наберитесь опыта и покажите, что умеете, вам либо предложат удаленную работу , либо предложат помощь в переезде и т.д.

Как уже много раз советовал, возьмите маленький фреймворк, поймите его устройство, напишите пару простеньких сайтов. Далее сами поймете что вам требуется изучать и практиковать.

Присоединяйся к разработке the-tale.org

Все исходники открыты: https://github.com/Tiendil/the-tale

Берёшь задачу делаешь, делаешь пул-реквест, получаешь критику, пока всё правильно не будет сделано, и код попадает в рабочий проект.

В вики на гитхабе рассказано подробнее.

Если можешь сделать сортировку масива «пузырьком», то переходи дальше. Если нет — то разберись в простейшей работе с массивами и таки сделай эту сортировку.

Сделай простой сайт (не статический, а с базой данных).
И усложняй, приделывая:
— админку для добавления, удаления и редактирования страниц (практика основных простых запросов к БД)
— сделай регистрацию и авторизацию на своем сайте (практика работы с $_POST и $_GET, сессии, cookies)
— сделай чтобы страницы могли быть вложенны друг в друга и чтобы можно было в админке изменять у страницы родителя. На сайте выводи дерево страницы. (познаешь основы «деревьев», рекурсию)
— сделай форму для закачки файла (практика прастейшей работы с файлами)
— сделай чтобы закачивалась картинка и масштабировалась (практика работы c библиотекой GD для работы с изображениями). Можно капчу попробовать сделать кстати.

Потом прочитай, что такое MVC и можешь все переделать под этот шаблон проектирования.