pfg21

Ты уже сказал про старшие 20 бит, скорее всего знаешь про сегментную организацию виртуальной памяти.
20 бит используются в 32 битных системах, а сейчас большая часть 64 битная, но это не важно.
Принцип следующий:
Существует 3 таблицы:
- PGD - Page Global Directory
- PMD - Page Middle Directory
- PTE - Page Table Entry

Они иерархические, т.е. запись в PGD указывает на запись в PMD, а PMD - на PTE.
В итоге, ты приходишь с 3 "числами" - индексы для этих таблиц и последовательно приходишь к нужной PTE.
Но тебе нужно еще 4 число - смещение относительно полученного в PTE значения (там хранятся "начала" выделенных сегментов/интервалов памяти)
Теперь последовательно запиши эти адреса и получишь виртуальный адрес.

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

Как выделяется реальная память - деталь реализации, о которой знать не нужно.
Если интересно - вот статья про память в линуксе.

P.S. пример показан на C# - там собственная виртуальная память и GC. Поэтому показывает не то, что выделила ОС.

Теоретически можно, но на практике проще купить беспроводной, так дешевле и быстрее.
Есть тема: https://4pda.to/forum/index.php?showtopic=881589 но мертвая - почему написано выше.

Да где хочешь там и храни. У меня лично было так:
/home/user/jellyfin/movies
/home/user/jellyfin/cache
/home/user/jellyfin/config

вкладка Boot и далее

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

Теоретически, да и практически - делаете образ squashfs, делаете маленький образ initrd.
Загружаетесь с initrd в котором делаете remount рута на образ squashfs.

Почитать можно например здесь - https://magazine.odroid.com/article/using-squashfs...

Когда в корпоративном ЦОДе, где я был руководителем группы сисадминов, возникла такая ситуация, то уважаемый самый старший по возрасту сотрудник предложил простой способ, который в последствии был назван по его имени "методом Фаюршина".
Научно он звучит так:
"Если имеется канал передачи информации, подключенный с одной стороны к известному источнику информации и к неизвестному приемнику информации, с другой стороны, то временное прерывание канала передачи данных позволит идентифицировать неизвестную сторону, так как она обязательно найдет другой канал передачи данных субъекту, временно прервавшему канал связи, и сообщит ему о необходимости восстановления прерванного канала. Причем, чем важнее сторона, которую необходимо идентифицировать, тем быстрее произойдет обратная связь и мощнее сигнал".
Ну а по простому - выдергиваем кабель, ждем возмущений.
Не является рекомендацией, но полезно для изучения :-)

При такой постановке вопроса, очевидно, воткнуть в сервак ещё одну сетевуху, а в неё шнурок второй сети.

Вообще-то компьютерные сети представляют из себя стек протоколов модели ISO OSI, состоящий из разных уровней. Физический -> канальный -> сетевой -> сеансовый -> приложений -> представления. Вроде особо не напутал.
Что имеется ввиду под "физикой", физический уровень? Самый нижний? Так у Олифера нормально все объяснено. Проводные, беспроводные каналы передачи данных. Уровни, кодирование сигналов. Понятно и всеобъемлюще. Не зря стоит у книги гриф "рекомендовано МО РФ".
Кому и когда, реально, по факту, придется работать с физическим уровнем? Единожды, при прокладке Ethernet-кабеля (витой пары Cat UTP-5) - при построении проводной ЛВС (компзал, своя локалка, какая-то фирма и т. п.). Или устанавливать Wi-Fi точку доступа - в случае беспроводной ЛВС. Сейчас еще, интернет ребята приходят проводить. Кабеля тянут. Но там больше нужны строительные навыки (перфоратор и т. п.). Хотя уже полно где все подключено: по пять провайдеров на дом. Кроме новостроек - естетственно. Тут из новинок - оптика (оптоволокно) - своя, отдельная история.
Сами мы, как страна, ничего здесь своего не имеем и не разрабатываем. Увы. Чисто на аппаратном уровне - имеется ввиду. Так что сидеть с осциллографом и изучать сигналы на витой паре с целью их оптимизации и "допиливания" - что-то из области фантастики. Я про работу радиоинженеров.
Сдается мне, что как админы, так и безопасники, в основном, работают с вышележащими уровнями модели OSI. Там, где реально ковырять железки не требуется. Когда, так сказать, этот "фундамент" готов. Настраиваются параметры, все уже чисто за клавиатурой, программно. Глубоко куда-то лезть не надо. Все достаточно понятно. Знаний уровня "академик" не требуется. Так же как и знать наизусть 600 страниц талмуда по TCP/IP от разработчиков этих протоколов. Обычные специалисты знают это поверхностно, только ровно то, что нужно, достаточно для выполнения своих обязанностей, решения поставленной задачи. Не спорю, какие-нибудь гипотетические взломщики, пытаясь найти уязвимости в протоколах, не ленятся штудировать и такое. Все возможно.
В учебных заведениях упор идет на вышележащие уровни: сетевой, сеансовый, представления (приложений). Там присутствуют такие протоколы как: TCP/IP, UDP, FTP, HTTP - самые основные. Сами по себе они мудреные. Но просто почитать, в общем виде (та же википедия) - не помешало бы. Познакомиться, так сказать.
Выше приведены примеры сетей малого масштаба. MAN и LAN. Еще бывают: внутренние сети интернет-провайдеров и корпоративные системы и сети разных компаний. У них своя "кухня". Ну а Интернет - сеть сетей (WAN). Объединение сетей, так сказать. С присутствием некоторых магистральных, трансконтинентальных каналов связи. Проложенных по дну океана между континентами - например. И используемыми совместно разными организациями, странами. У нас, к примеру, магистральный канал связи есть у магистрального оператора связи Ростелекома. Другие провайдеры - организации поменьше масштабом.

Если я где-то приврал, то извиняюсь, старался не особо сочинять. :)
Вот, собственно, и все. Для начала.

Начните с этого: https://ru.wikipedia.org/wiki/Триггер
В качестве первого приближения ваш счётчик можно собрать из двоичного счётчика и двоичного дешифратора - будет работать. https://ru.wikipedia.org/wiki/Счётчик_(электроника)
https://ru.wikipedia.org/wiki/Дешифратор
Нормальная реализация (без оверхеда) должна получиться, IMHO, просто на базе триггеров.

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

Окей, если объяснить на пальцах, то есть два варианта.
1. Собственные знания модели. Большие языковые модели, по сути, умеют только одно: предсказывать следующее слово по набору предыдущих. Почти все остальные задачи сводятся к этому. Так что веса модели - это описание офигительно сложной функции, которая описывает взаимосвязь между предшествующим набором слов и последующим словом. Все "знания" модели, таким образом, сводятся к ответу на вопрос "какое слово будет дальше с наибольшей вероятностью?" Отсюда вытекают и слабые стороны языковых моделей - они не понимают, что пишут, они просто пишут "по аналогии".
2. Retrieval Augmented Generation. Грубо говоря, в распоряжении модели есть база текстов, где каждому фрагменту сопоставлено некоторое описание его смысла. Модель использует такое же представление смысла слов в запросе, чтобы найти подходящие по смыслу фрагменты. Найдя эти фрагменты, модель строит ответ уже на основании фрагментов И запроса. Это не требует переобучения модели для добавления новых знаний, как в первом случае. Но будут проблемы, если фрагменты слишком длинные или их слишком много.