Виктор Голованенко

Решение называется "адекватный начальник". Оставайтесь на окладе, продолжайте работать по 8 часов день с перерывом. Важно не количество отсиженного за работой времени, а качество сделанного.

Если вы будете работать по 16 часов, а на выходе будет фигня из-под коня - какой от этого прок? А оплату будете требовать в двойном размере. Не годится такое, не правильно это.

Как происходит доступ к эл. массива на уровне ядра?

Так же как и на уровне приложения -- через трансляцию виртуального адреса в физический.

Например массив Int* arr = new int[1024*1024*1024] он как храниться?

Если мы для определённости возьмём linux, то у ядра есть несколько разных способов выделения памяти, в зависимости от того, для чего эта память выделяется. Есть наиболее простой и стандартный kmalloc который выделяет память непрерывную как виртуально так и физически. Обычно этим механизмом нельзя выделить большой непрерывный кусок. Есть vmalloc, который выделяет непрерывную виртуально, но возможно прерывную физически память. Есть get_free_pages который выделяет непрерывные страницы физической памяти, возможно, не отображаемые ни в какие виртуальные адреса. Есть Contiguous Memory Allocator который при старте системы резервирует кусок непрерывной физической памяти и может аллоцировать оттуда куски по запросу.
Важный момент состоит в том, что аллокации делаемые ядром linux через упомянутые интерфейсы всегда обеспечиваются физической памятью, у памяти ядра нет пейджинга.

А физическая, для массива то же? Ведь, так будет доступ намного быстрее?

Почему быстрее? С точки зрения процессора всё равно будет трансляция виртуального адреса в физический, если повезёт -- попадание в TLB, если не повезёт -- ходить по каталогам и таблицам страниц в памяти.

получается эмулятор каждый адрес вычислять что ли?

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

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

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

Если не обрабатываем - то считается что делегируем обработку исключения той функции которая нас вызвала. По сути передаем управление "наверх". Тоесть кто вызвал - тот и обязан разруливать ситуацию. Очень похожий подход принят в акторной технологии.

Обычно механика исключений хорошо приживается в языках с Garbage Collectors.

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

добавить свой путь в PATH
зы пропиши в башрс пару строк
ифы лишеие выкини, я просто скопировал кусок целиком

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; 
	then . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ];
	then . /etc/bash_completion
  fi
fi

if [ -x /usr/games/fortune ];
then fortune ru |lolcat -F 0.7 ;
fi

##  сперва будет искать man на русском, а если его нет, то на английском.
export MANOPT="-L ru"

## По умолчанию, каждый экземпляр bash переписывает историю. То есть, если вы запустите два терминала, что-то в них сделаете, а потом закроете, то история сохранится только от последнего закрытого. (Она затрёт историю первого закрытого.) Это очень неудобно и легко исправляется вот такой командой:
shopt -s histappend

##[ -f ~/.fzf.bash ] && . ~/.fzf.bash


if [ -s ~/.Xmodmap ];
then xmodmap ~/.Xmodmap
fi

## для Wine
export MESA_GL_VERSION_OVERRIDE=4.5

Подстановкой по TAB занимается не ваш скрипт, это делает bash. А если быть совсем точным - bash-completion. В нем описаны для разных программ допустимые аргументы и варианты подстановок. Вам стоит разобраться в правилах написания bash-completion расширения под ваш скрипт и распространять скрипт вместе с этим расширением.

Ну, это проще простого:
1. Находим проблему в проекте, которая вам мешает
2. Исправляем её, убеждаемся, что новый код по стилю и требованиям совпадает со старым
3. Отправляем изменения так, как указано в требованиях проекта

Мой тебе совет: вливаться стоит только в новые проекты или с целью исправления ошибок.
Пошаговая инструкция:
1. создаешь форк репозитория
2. отправляешь PR'ы в основной репозиторий
3. как только твой вклад перевалит за 5-10% от его кода, можешь попроситься в owner'ы
3. profit!

Самое главное - разбираться в проекте. Читать его баг-трекер и понимать потребности и над чем работает сообщество. Я как-то пытался стать контрибутором apache ignite но не вышло. Времени не хватало. А потребности были со стороны нашего проекта.

Вобщем читаете баг-трекер. Берете проблему и разбираетесь. Поскольку речь идет о больших проектах то пройдут месяцы и годы прежде чем вы сможете делать фичи.

Техническая сторона не особо важна. Главное что у вас есть ценный merge-request который нечто исправляет и это НЕЧТО очень нужно в мире.

Как обычно, всё уже украдено до нас