Saboteur

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

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

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

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

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

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

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

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

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

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

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

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

100BASE-T is any of several Fast Ethernet standards for twisted pair cables, including: 100BASE-TX (100 Mbit/s over two-pair Cat5 or better cable), 100BASE-T4 (100 Mbit/s over four-pair Cat3 or better cable, defunct), 100BASE-T2 (100 Mbit/s over two-pair Cat3 or better cable, also defunct). The segment length for a 100BASE-T cable is limited to 100 metres (328 ft) (as with 10BASE-T and gigabit Ethernet). All are or were standards under IEEE 802.3 (approved 1995). Almost all 100BASE-T installations are 100BASE-TX.

In the early days of Fast Ethernet, much vendor advertising centered on claims by competing standards that said vendors' standards will work better with existing cables than other standards. In practice, it was quickly discovered that few existing networks actually met the assumed standards, because 10 Megabit Ethernet was very tolerant of minor deviations from specified electrical characteristics and few installers ever bothered to make exact measurements of cable and connection quality; if Ethernet worked over a cable, no matter how well it worked, it was deemed acceptable. Thus most networks had to be rewired for 100 Megabit speed whether or not there had supposedly been CAT3 or CAT5 cable runs.[citation needed]

https://en.wikipedia.org/wiki/Fast_Ethernet#100BASE-TX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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