Saboteur

"драйвер это чаще всего графический инсталлятор"
"Если в винде драйвер это инсталлятор, то что есть драйвер в Linux и OS X?"

Не приравнивайте инсталлятор драйвера и сам драйвер. Драйвер в винде может предствлять собой один .inf файл, и не иметь никакого инсталлятора.

У вас вообще сильно перепутано что такое драйвер и в качестве отличия драйверов между системами вы видите только способ установки, но всем системам нужны драйвера.

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

В Mac производитель железа и ОС один и тот же, поэтому идет с ОС, но для некоторых устройств - также на диске или с сайта, но так как производитель один, несложно организовать автоматическое скачивание, и даже сторонняя периферия сертифицируется в Apple, что упрощает автоматизацию.

С виндой идет множество вшитых драйверов, которые не требуют от вас никаких действий, чтобы работать. Чем старше винда, тем больше девайсов, которые определятся сами.
Но множество девайсов выпускаются без особого взаимодействия с MS, просто пользуясь их рекомендациями, WHQL драйвера считаются стабильными, но любой может написать драйвер к своему устройству, выложить на своем сайте, и понятно что MS про это может и не знать.

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

Если взять видеокарту, которая поддерживает DirectX12, то в Линуксе его (DirectX) вообще нет, и Линукс не сможет пользоваться всеми фичами, предоставляемыми карточкой, вот и ответ почему Линукс работает со многими устройствами стандартными драйверами, а Windows требует индивидуальный.

Виндовс, как и многие другие ОС, не хранят шифрованные пароли.
Хранится хеш паролей.

Хеш получается путем односторонних алгоритмических преобразований. Обратная операция невозможна.
Для авторизации, пароль который вы ввели хешируется, и хеш сравнивается с тем, что сохранен - если они совпали, значит вы ввели правильный пароль.

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

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

В 99% случаев, помогает правка реестра. Да это муторно, может быть уйдет минут 20-40, но вполне нормально можно поправить буквы.
Заходите в реестр, ищете старый путь, каждый меняете на новый.

Можете экспортировать некоторые ветки реестра, и поправить их в любом редакторе с заменой, потом импорт.

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

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

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

В общем так:
Вычитывать код, вникать в его суть - никто не станет. Просто нет времени. Даже для сеньоров - проще нанять человека и проверить его на испытательном сроке, а на гитхабе смотрят примерно так:

1. Что это вообще за проект, какие задачи решает, насколько он сложен.
2. Подход к стилистике - если уже выложил на гитхаб, то посмотреть качество комментариев к коммитам, вкратце посмотреть пользуется ли человек хоть какой-то стилистикой. Если проект не лично ваш, а командный - это оценивается чуть выше (ну понятно, что по вкладу в проект), но работать в команде сложнее, чем вести сольный, поэтому и оценивается это лучше - вас же в команду хотят нанять, и это приоритет.
3. Собственно самое главное - само резюме - где работал, что делал, почему менял работу, навыки и иностранный.

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

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

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

У нас тестовые задания придумывали сами, давали комп с инетом и оставляли на 15-60 минут (в зависимости от уровня). Строго время не спрашивали, просто говорили - сделаешь - зови. Потом смотрели на решение, уточняли выбор решения и его правильность.
Единственный раз заподозрили нечестность, когда один кандидат звонил другу по телефону, чтобы тот ему подсказал. Искать готовое в гугле - не запрещается, но консультация с другим человеком - как бы читерство.

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

С другой стороны, зависит от данных. Если вы хотите бэкапы скидывать, вдобавок которые еще нужно предварительно архивировать, то самый быстрый способ такой:

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

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

хранить настройки в txt - некорректно. Есть определенные стандарты и стилистика кода, к именованию файлов это тоже относится. txt - для инструкций, разных readme.txt, для install.txt, для лицензионных соглашений. Но удаление .txt файлов не должно влиять на работу системы.

Тоже и наоборот - хранить обычный текст в .log файле - странная затея.

Можно настроить, чтобы для разных хостов использовались разные ключи.
Вам нужно почитать про $HOME/.ssh/config

host 127.0.0.1
	User saboteur
	IdentityFile с:\my_id1.rsa

host 127.0.0.2
	User dart_vader
	IdentityFile с:\my_id2.rsa