Как вам а) убедиться, что этот фикс не вызывает новых проблем в других проектах;
Ну давайте смотреть на процесс. Вот есть изменение в libmoo. У нас монорепа на 200k продуктов. Нам надо отловить те, которые зависят от libmoo напрямую - это шаг 1. Как мы будем это искать? Наверняка есть какой-то список. Вести его в монорепе или в разбросе - нет разницы, всё равно добавлять вручную. (В автопоиск по всему дереву - не верю.)
CI автомат? Ему точно так же нужен явный список. А после этого вытаскивать отдельные подветки толстой репы (не тащить же её целиком!) или отдельные маленькие репы - разницы нет, или второе даже проще.
На любой такой коммит CI должен всё проверить.
Шаг 2 - проекты, связанные с зависящими (типа сетевого взаимодействия) - тем более тоже на основании явно описанных связей.
Так для чего мудохаться с моно?
(На самом деле есть одна тонкость с субмодулями: для некоторых ситуаций нужно хукать замену URL к модулям. Но это в тысячи раз проще поддержки монореп.)
б) доставить этот фикс на другие проекты (и не когда-нибудь, а поскорее).
О, вот тут действительно интересный вопрос. Если сводный коммит на библиотеку и все её зависимости, типа добавили один аргумент в функцию её API.
Но это само по себе проблемно. И коммит такой анализировать сложно, и грануляция страдает, и атомарность изменения как раз может быть субмодулями исключена, просто не потерять плавный переход на новую версию.
В Gerrit существует уже 10 лет, типа такого: https://gerrit-review.googlesource.com/c/plugins/scripts/+/411660 см. "relation chain" и номера patchsetʼов: после правки в предыдущем в цепочке следующие надо обновить или локально с пушем, или через средства сервера. В Мете изобрели велосипед.
А если использовать gui, то можно и отдельные diff'ы в отдельных файлах включать в коммит. И в git и в hg.
Вот.
1. В Git для этого не нужен какой-то отдельный GUI, всё из коробки.
2. Git позволяет это делать (без GUI, `add --e`) даже не с отдельными диффами, а со строками. Критично, когда в таком диффе на 2 строки изменения, которые должны пойти на сервер, 3 на отладочную печать и 4 на комментарий для себя, что тут происходит и почему.
Может, для мелких дежурных правок такое и не нужно, но для задачи типа моей текущей сейчас, где сплошное "сигнал пошёл через обсервер в состояние вложенной FSM", мои комментарии "какого хера? уточнить это место" не должны идти в коммит даже если они на хинди.
3. После я пересобираю правки и, например, переименования идут в один коммит, doxygen-пояснения - в другой (если их не было, потому что вот такая кодобаза), а функциональные правки - в третий. И только после этого я выставляю это в виде чистого, аккуратного результата, который легко ревьюить сейчас, читать даже через пару лет, прогонять через CI или bisect в любой момент.
А с Mercurial и его "вам это не нужно" в коммиты шли бы грязь, грязь и грязь из разнородных изменений и "я тут ещё одно место добавил и заодно функции описал".
В hg неудобно переписывать историю на сервере, да.
Польза от staging возникает задолго до пуша на сервер.
В гите есть только указатели на коммиты. А бранчи все выдумывают пре-коммит хуками кто во что горазд.
Вы тут "бранчами" называете теги сообщения коммита, которые показывают, в рамках какой разработки был сделан коммит. Ни в Git ни, на самом деле, в Hg это не нужно, если есть возможность писать его в сообщении коммита - что всегда и делается в процессе уровня больше чем "я и моя собака".
Как сами меркуриаловцы признают, "The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." В результате получаются ситуации типа "Две ветки-2 в пределах ветки-1 (не путать с веткой-3)" (ветка-1 это его внутренний branch, ветка-2 это безымянная голова, ветка-3 это bookmark).
Я уж не говорю о том, что он каждыйпо коммит хранит целым снепшотом состояния репозитория, а не просто диффом изменённых файлов
А это _в основе_ единственно правильный вариант (ну не учитываем, что объекты могут представляться в виде дельт, это уже вопрос сжатия репы). Трекинг копирования/переименования должен делаться уже отдельно поверх него.
Представление, где каждый каталог и файл представляются хэшом и собственно найти изменённые файлы между коммитами - это очень экономная операция (все случаи разных хэшей отбрасываются из сравнения), позволяет как раз очень экономно определять набор тех файлов, в пределах которых надо вести трекинг уже по их содержимому.
Для сложных случаев типа "переместили 200000 файлов и при этом изменением `#include <moo/foo/boo/boo.h>` на `#include <util/moo/foo/boo/boo.h>` поменяли их хэши... ну да, можно было бы придумать какие-то подпорки. Но, насколько видим, это даже для крупных реп не составляет большой проблемы.
а для отображения диффа и мёржа ему приходится опять же угадывать, где какие были изменения сравнивая разные снепшоты.
Ну и очень хорошо угадывает.
Опять же, да, я иногда (раз в два года) предпочёл бы видеть возможность явно ему сказать "считай, что Foo переименован в Boo, а историю Moo, сделанного клоном из него, надо вести отдельно". В целом, не настолько проблема.
Стиль Github, GitLab, Bitbucket - это "разрешим работать с распределённой VCS ко ак с централизованной". Это не родное для Git.
Более адекватное приспособление к стилю собственно Git это Gerrit. Он используется как серверная база в самом гугле (с сильными внутренними подточками). Но у него нету CI и прочих удобств в едином флаконе, их надо довинчивать.
1. staging area. В Mercurial ничего подобного нет и не планируют. А это (вместе с interactive rebase) практически единственное, что позволяет легко делать чистые коммиты, а не такие, в которых намешало 100500 разных типов правок.
Для меня любая VCS, в которой этого нет, непригодна.
2. Отсутствие зажима на определённые процессы разработки - который в Mercurial выглядит как множественные головы, тяжело изменяемый статус коммита вроде draft/public, и т.п.
Mercurial выглядит как "сэмулируем централизованную VCS на базе распределённой, но так, чтобы людям не надо было думать, что они делают".
Умеет. Вы, наверно, git clone запускали. Потому что если сделать init + fetch, то докачка работает с момента обрыва. Не идеально, некоторые мета-части передаются заново, но есть сохранение принятого.
Можно. Были даже примеры простых игр (уровня Pacman) как (U)EFI бинарей.
Проблема в том, что это отдельная платформа со своей спецификой, и что-то большое разрабатывать под неё тупо нет смысла. Вам придётся сделать свой R/W драйвер целевой FS, свою поддержку мультипроцессности в нужном стиле, достаточно богатое API для работы такого сервиса, сделать все нужные драйвера включая сетевой (EFI может его не предоставлять)... сама модель EFI ориентирована на простоту (ну, как её понимает Intel) и надёжность процесса, а не на скорость... с какого-то момента будет понятно, почему если "за морем телушка - полушка, да рубль перевоз", то грузить Linux с диска дешевле во всех смыслах:)
BIOS тупо загружает первый сектор с самого первого (по приотритету загрузки) диска и передает ему управление.
Если быть финально точным - бывали BIOS, которые пытались лезть в эту тему, особенно в районе конца 1990-х. Для них в загрузочных секторах файловых систем рисовали фиктивные FAT BPB, без которого могло молча отказаться грузить. Чем более "вендорский" комп, тем это вероятнее. Практически исчезло под давлением наличия альтернативных систем вроде Linux.
Вот только такая загрузка - жутко небезопасна...
Этого не понял. Чем она небезопасна, если диски подключить по ATA/SCSI/etc. это явное действие, после которого надо пересчитать загрузку, а всякие USB требуют явного вызова boot menu?
Моя сильно подозревать, что неосвоение адресной арифметики и ассемблера никак не происходит от какого-то "непонимания", а это заклин из-за боязни выйти из уютного мирка, защищённого от проблем с памятью. Кто преодолевает легко этот заклин - идёт дальше, пусть и с разумной осторожностью.
Именно поэтому "игрушки" системы "ну зависло - передёрнул по питанию" тут очень удобны.
И почему в PC перестали делать ROM Basic? Надо вернуть...
1) self должен присутствовать обязательным первым аргументом в методах, привязанных к объекту. (В принципе ничто не мешает назвать его при этом не self, а mamarama или хвостПитона, но все коллеги и статические анализаторы забьют ногами.) Для помеченных @classmethod точно так же должен быть cls.
2) Ссылка через self на поля объекта обязательна, такого, как в C++ с его "не нашли в локальных переменных - ищем в классе" нету и не предполагалось.
Оба пункта могут считаться и достоинством, и недостатком, кому как - но предмет для холивара дают по полной.
1. Объект это нечто, про что нам удобно думать, что у него есть граница, отделяющая от остального мира состояния программы, и есть более-менее чёткое определение, как он взаимодействует с остальным состоянием - и мы думаем и описываем это в коде так, что есть этот объект и есть взаимодействие с ним.
Это первично перед всем остальным, включая то, какие виды взаимодействия, явно ли присутствует слово object или class, и прочая и прочая и прочая.
2. Если у объекта есть собственный источник движения, это стиль Кея, Simula, Smalltalk и прочих. Это стиль "рыб в аквариуме", которые плавают, пускают пузырьки воздуха и перебрасываются данными в них. Сюда же следует включить 100500 агент-ориентированных сред, как, например, Erlang, где его внутренний процесс можно приравнять к объекту.
Если нет, а источник движения - внешний, как набор нитей (тредов) процессов, то это ООП стиля C++, Java, C#, VB, Pascal/Modula/Delphi/etc., Python, Ruby, тысячи их. Вот там вызываются методы, а не посылаются сообщения.
Это основное разграничение, по сравнению с которым остальные... ну не становятся совсем деталями, но менее заметны.
Дальнейшие рассказы автора статьи на 100% посвящены именно "пассивному" ООП со всей его спецификой. И при этом непонятны начальные намёки в сторону Кея, как ружьё, которое, несмотря на весь гнев Станиславского, провисело на стене всю пьесу без движения.
3. ООП предполагает инкапсуляцию - в принципе, потому что объекты, кроме самых примитивных, неизбежно имеют внутреннюю структуру.
Но защита инкапсуляции всеми private/protected/аналогами - вопрос не принципа, но уровня защиты от диверсий другими участниками в большом проекте, где невозможно следить за всем, что делает кодер за соседним столом. Поэтому "инкапсуляция" тут неоднозначна, роль защиты растёт со сложностью задач.
4. Полиморфизм наследования интерфейса - следующий критичный элемент, но он относится не к ООП самому по себе, а является неизбежным следствием необходимости контроля сложности. Посылка универсального сообщения "опиши себя текстом" в SmallTalk или вызов метода интерфейса в Java тут - перенос этой сложности с управляющего на управляемого. Разумеется, это не всегда в плюс (возможность вызвать в, к примеру, Python метод, которого нет, но который может быть добавлен или не добавлен в ходе жизни объекта назначением его "поля" - хорошо для всякой гибкости и плохо для отладки).
5. Наследование реализации - такой же метод справиться со сложностью, но там, где это полезно за счёт того, что большая часть общего кода собирается вместе. Есть задачи, где это в плюс, и есть где можно легко заабьюзить в минус. Пока что видим, что плюсов считается больше - потому что административно можно запретить наследование реализации в конкретном месте, но нельзя сделать, если язык её не поддерживает. Но есть языки, в которых её убрали намеренно.
Всё прочее - скорее местные особенности, чем принципы ООП.
Они ведь вроде бы вполне быстро обеспечивают произвольный доступ, есть ли смысл с ними заморачиваться такими структурами?
С ними - ещё более:)
На HDD дискрет перезаписи - 512 байт на классических, 4KB на многих новых (даже если они рапортуют логический размер блока всё те же 512 байт). А вот на SSD минимальный перезаписываемый объём может быть, например, 128KB. Умный контроллер набивает такую порцию многими блоками и обновляет вслед карту распределения, но чем меньше его таким грузить, тем лучше. Поэтому большая страница тут полезнее.
Хотя, 128KB для страницы B-дерева это многовато. Для таких применений придумали Log-structured merge tree.
Кстати в ГЛОНАСС не стали заморачиваться с високосными секундами, синхронизировали один раз и время идёт непрерывно.
GPS - точно так же, TAI время. PTP - точно так же. Но это не счёт в ядрах.
Ну это тем более странно, если системы реального времени завязаны на часы-минуты-секунды, в то время как нужен непрерывный счётчик времени.
Проблема в том, что база >99% систем реального времени, которые используются сейчас - это firm- и soft-realtime на базе чего-то Unix-подобного, в первую очередь Linux. Почему так - а потому что разработка на любом другом будет в разы дороже. А у Unix систем в принципе счёт в ядре в unixtime-без-вставных-секунд.
И тут при наличии багов лучше, кстати, подход BSD, которые вообще не пытаются эту секунду отрабатывать, возложив "растяжение" на длинные периоды (от 15 минут) средствами внешних NTP/etc. демонов. А вот Linux растягивает переходную секунду на две, и тут начинается полное ой.
5G это маленький пример. Не знаю, почему автор статьи взял его. И его можно решить очень грубо - да хоть порвать все разговоры в момент перехода.
Есть более серьёзные примеры. Все технологии непрерывного цикла с замером параметров, начиная с АЭС и химзаводов.
И что это за IT такое которое неспособно обработать лишнюю целую секунду
Вот такое вот IT. Которое экономит на тестировании, на сопровождении, всё, что можно и что нельзя. Я работал на таких проектах, где мы вводя мелкую новую фичу ломали фичи соседей и никто этого не видел до релиза, и они нам - точно так же:(
Ну вот это можно уже изучать на предмет оптимизации, конечно, хотя бы плагинами...
А
rerereв git не помогает? Вроде как раз для такого и задумана, после первой попытки, где надо таки разгрести вручную.Ну давайте смотреть на процесс. Вот есть изменение в libmoo. У нас монорепа на 200k продуктов. Нам надо отловить те, которые зависят от libmoo напрямую - это шаг 1. Как мы будем это искать? Наверняка есть какой-то список. Вести его в монорепе или в разбросе - нет разницы, всё равно добавлять вручную. (В автопоиск по всему дереву - не верю.)
CI автомат? Ему точно так же нужен явный список. А после этого вытаскивать отдельные подветки толстой репы (не тащить же её целиком!) или отдельные маленькие репы - разницы нет, или второе даже проще.
На любой такой коммит CI должен всё проверить.
Шаг 2 - проекты, связанные с зависящими (типа сетевого взаимодействия) - тем более тоже на основании явно описанных связей.
Так для чего мудохаться с моно?
(На самом деле есть одна тонкость с субмодулями: для некоторых ситуаций нужно хукать замену URL к модулям. Но это в тысячи раз проще поддержки монореп.)
О, вот тут действительно интересный вопрос. Если сводный коммит на библиотеку и все её зависимости, типа добавили один аргумент в функцию её API.
Но это само по себе проблемно. И коммит такой анализировать сложно, и грануляция страдает, и атомарность изменения как раз может быть субмодулями исключена, просто не потерять плавный переход на новую версию.
В Gerrit существует уже 10 лет, типа такого: https://gerrit-review.googlesource.com/c/plugins/scripts/+/411660
см. "relation chain" и номера patchsetʼов: после правки в предыдущем в цепочке следующие надо обновить или локально с пушем, или через средства сервера. В Мете изобрели велосипед.
Вот.
1. В Git для этого не нужен какой-то отдельный GUI, всё из коробки.
2. Git позволяет это делать (без GUI, `add --e`) даже не с отдельными диффами, а со строками. Критично, когда в таком диффе на 2 строки изменения, которые должны пойти на сервер, 3 на отладочную печать и 4 на комментарий для себя, что тут происходит и почему.
Может, для мелких дежурных правок такое и не нужно, но для задачи типа моей текущей сейчас, где сплошное "сигнал пошёл через обсервер в состояние вложенной FSM", мои комментарии "какого хера? уточнить это место" не должны идти в коммит даже если они на хинди.
3. После я пересобираю правки и, например, переименования идут в один коммит, doxygen-пояснения - в другой (если их не было, потому что вот такая кодобаза), а функциональные правки - в третий. И только после этого я выставляю это в виде чистого, аккуратного результата, который легко ревьюить сейчас, читать даже через пару лет, прогонять через CI или bisect в любой момент.
А с Mercurial и его "вам это не нужно" в коммиты шли бы грязь, грязь и грязь из разнородных изменений и "я тут ещё одно место добавил и заодно функции описал".
Польза от staging возникает задолго до пуша на сервер.
Угу - "даём работать с распределённой базой как с простой централизованной, но с плюшками".
Вы тут "бранчами" называете теги сообщения коммита, которые показывают, в рамках какой разработки был сделан коммит. Ни в Git ни, на самом деле, в Hg это не нужно, если есть возможность писать его в сообщении коммита - что всегда и делается в процессе уровня больше чем "я и моя собака".
Как сами меркуриаловцы признают, "The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." В результате получаются ситуации типа "Две ветки-2 в пределах ветки-1 (не путать с веткой-3)" (ветка-1 это его внутренний branch, ветка-2 это безымянная голова, ветка-3 это bookmark).
А это _в основе_ единственно правильный вариант (ну не учитываем, что объекты могут представляться в виде дельт, это уже вопрос сжатия репы). Трекинг копирования/переименования должен делаться уже отдельно поверх него.
Представление, где каждый каталог и файл представляются хэшом и собственно найти изменённые файлы между коммитами - это очень экономная операция (все случаи разных хэшей отбрасываются из сравнения), позволяет как раз очень экономно определять набор тех файлов, в пределах которых надо вести трекинг уже по их содержимому.
Для сложных случаев типа "переместили 200000 файлов и при этом изменением `#include <moo/foo/boo/boo.h>` на `#include <util/moo/foo/boo/boo.h>` поменяли их хэши... ну да, можно было бы придумать какие-то подпорки. Но, насколько видим, это даже для крупных реп не составляет большой проблемы.
Ну и очень хорошо угадывает.
Опять же, да, я иногда (раз в два года) предпочёл бы видеть возможность явно ему сказать "считай, что Foo переименован в Boo, а историю Moo, сделанного клоном из него, надо вести отдельно". В целом, не настолько проблема.
Ну зачем же так, всё проверяется:
Git: Initial release 7 April 2005
Mercurial: Initial release 19 April 2005
Стиль Github, GitLab, Bitbucket - это "разрешим работать с распределённой VCS ко ак с централизованной". Это не родное для Git.
Более адекватное приспособление к стилю собственно Git это Gerrit. Он используется как серверная база в самом гугле (с сильными внутренними подточками). Но у него нету CI и прочих удобств в едином флаконе, их надо довинчивать.
1. staging area. В Mercurial ничего подобного нет и не планируют. А это (вместе с interactive rebase) практически единственное, что позволяет легко делать чистые коммиты, а не такие, в которых намешало 100500 разных типов правок.
Для меня любая VCS, в которой этого нет, непригодна.
2. Отсутствие зажима на определённые процессы разработки - который в Mercurial выглядит как множественные головы, тяжело изменяемый статус коммита вроде draft/public, и т.п.
Mercurial выглядит как "сэмулируем централизованную VCS на базе распределённой, но так, чтобы людям не надо было думать, что они делают".
Умеет. Вы, наверно, git clone запускали. Потому что если сделать init + fetch, то докачка работает с момента обрыва. Не идеально, некоторые мета-части передаются заново, но есть сохранение принятого.
Ну и ещё есть https://github.com/johnzeng/ResumableGitClone и наверняка ещё десяток похожих проектов.
Можно. Были даже примеры простых игр (уровня Pacman) как (U)EFI бинарей.
Проблема в том, что это отдельная платформа со своей спецификой, и что-то большое разрабатывать под неё тупо нет смысла. Вам придётся сделать свой R/W драйвер целевой FS, свою поддержку мультипроцессности в нужном стиле, достаточно богатое API для работы такого сервиса, сделать все нужные драйвера включая сетевой (EFI может его не предоставлять)... сама модель EFI ориентирована на простоту (ну, как её понимает Intel) и надёжность процесса, а не на скорость... с какого-то момента будет понятно, почему если "за морем телушка - полушка, да рубль перевоз", то грузить Linux с диска дешевле во всех смыслах:)
Если быть финально точным - бывали BIOS, которые пытались лезть в эту тему, особенно в районе конца 1990-х. Для них в загрузочных секторах файловых систем рисовали фиктивные FAT BPB, без которого могло молча отказаться грузить. Чем более "вендорский" комп, тем это вероятнее. Практически исчезло под давлением наличия альтернативных систем вроде Linux.
Этого не понял. Чем она небезопасна, если диски подключить по ATA/SCSI/etc. это явное действие, после которого надо пересчитать загрузку, а всякие USB требуют явного вызова boot menu?
Точно не я:) я считаю VAX чудовищно корявым и избыточным.
А вот что выбрать на универсальную машину для трансляции в целевую... сейчас вопрос в принципе отработан в куче сходных вариантов.
Моя сильно подозревать, что неосвоение адресной арифметики и ассемблера никак не происходит от какого-то "непонимания", а это заклин из-за боязни выйти из уютного мирка, защищённого от проблем с памятью. Кто преодолевает легко этот заклин - идёт дальше, пусть и с разумной осторожностью.
Именно поэтому "игрушки" системы "ну зависло - передёрнул по питанию" тут очень удобны.
И почему в PC перестали делать ROM Basic? Надо вернуть...
1) self должен присутствовать обязательным первым аргументом в методах, привязанных к объекту. (В принципе ничто не мешает назвать его при этом не self, а mamarama или хвостПитона, но все коллеги и статические анализаторы забьют ногами.) Для помеченных
@classmethodточно так же должен быть cls.2) Ссылка через self на поля объекта обязательна, такого, как в C++ с его "не нашли в локальных переменных - ищем в классе" нету и не предполагалось.
Оба пункта могут считаться и достоинством, и недостатком, кому как - но предмет для холивара дают по полной.
1. Объект это нечто, про что нам удобно думать, что у него есть граница, отделяющая от остального мира состояния программы, и есть более-менее чёткое определение, как он взаимодействует с остальным состоянием - и мы думаем и описываем это в коде так, что есть этот объект и есть взаимодействие с ним.
Это первично перед всем остальным, включая то, какие виды взаимодействия, явно ли присутствует слово object или class, и прочая и прочая и прочая.
2. Если у объекта есть собственный источник движения, это стиль Кея, Simula, Smalltalk и прочих. Это стиль "рыб в аквариуме", которые плавают, пускают пузырьки воздуха и перебрасываются данными в них. Сюда же следует включить 100500 агент-ориентированных сред, как, например, Erlang, где его внутренний процесс можно приравнять к объекту.
Если нет, а источник движения - внешний, как набор нитей (тредов) процессов, то это ООП стиля C++, Java, C#, VB, Pascal/Modula/Delphi/etc., Python, Ruby, тысячи их. Вот там вызываются методы, а не посылаются сообщения.
Это основное разграничение, по сравнению с которым остальные... ну не становятся совсем деталями, но менее заметны.
Дальнейшие рассказы автора статьи на 100% посвящены именно "пассивному" ООП со всей его спецификой. И при этом непонятны начальные намёки в сторону Кея, как ружьё, которое, несмотря на весь гнев Станиславского, провисело на стене всю пьесу без движения.
3. ООП предполагает инкапсуляцию - в принципе, потому что объекты, кроме самых примитивных, неизбежно имеют внутреннюю структуру.
Но защита инкапсуляции всеми private/protected/аналогами - вопрос не принципа, но уровня защиты от диверсий другими участниками в большом проекте, где невозможно следить за всем, что делает кодер за соседним столом. Поэтому "инкапсуляция" тут неоднозначна, роль защиты растёт со сложностью задач.
4. Полиморфизм наследования интерфейса - следующий критичный элемент, но он относится не к ООП самому по себе, а является неизбежным следствием необходимости контроля сложности. Посылка универсального сообщения "опиши себя текстом" в SmallTalk или вызов метода интерфейса в Java тут - перенос этой сложности с управляющего на управляемого. Разумеется, это не всегда в плюс (возможность вызвать в, к примеру, Python метод, которого нет, но который может быть добавлен или не добавлен в ходе жизни объекта назначением его "поля" - хорошо для всякой гибкости и плохо для отладки).
5. Наследование реализации - такой же метод справиться со сложностью, но там, где это полезно за счёт того, что большая часть общего кода собирается вместе. Есть задачи, где это в плюс, и есть где можно легко заабьюзить в минус. Пока что видим, что плюсов считается больше - потому что административно можно запретить наследование реализации в конкретном месте, но нельзя сделать, если язык её не поддерживает. Но есть языки, в которых её убрали намеренно.
Всё прочее - скорее местные особенности, чем принципы ООП.
С ними - ещё более:)
На HDD дискрет перезаписи - 512 байт на классических, 4KB на многих новых (даже если они рапортуют логический размер блока всё те же 512 байт). А вот на SSD минимальный перезаписываемый объём может быть, например, 128KB. Умный контроллер набивает такую порцию многими блоками и обновляет вслед карту распределения, но чем меньше его таким грузить, тем лучше. Поэтому большая страница тут полезнее.
Хотя, 128KB для страницы B-дерева это многовато. Для таких применений придумали Log-structured merge tree.
GPS - точно так же, TAI время. PTP - точно так же. Но это не счёт в ядрах.
Проблема в том, что база >99% систем реального времени, которые используются сейчас - это firm- и soft-realtime на базе чего-то Unix-подобного, в первую очередь Linux. Почему так - а потому что разработка на любом другом будет в разы дороже. А у Unix систем в принципе счёт в ядре в unixtime-без-вставных-секунд.
И тут при наличии багов лучше, кстати, подход BSD, которые вообще не пытаются эту секунду отрабатывать, возложив "растяжение" на длинные периоды (от 15 минут) средствами внешних NTP/etc. демонов. А вот Linux растягивает переходную секунду на две, и тут начинается полное ой.
5G это маленький пример. Не знаю, почему автор статьи взял его. И его можно решить очень грубо - да хоть порвать все разговоры в момент перехода.
Есть более серьёзные примеры. Все технологии непрерывного цикла с замером параметров, начиная с АЭС и химзаводов.
Вот такое вот IT. Которое экономит на тестировании, на сопровождении, всё, что можно и что нельзя. Я работал на таких проектах, где мы вводя мелкую новую фичу ломали фичи соседей и никто этого не видел до релиза, и они нам - точно так же:(
Картинка паники ядра от совсем другой проблемы чем вставная секунда:) ну и в 2015 паники не было, были безвыходные заклины таймеровнедора.
Воспроизводить ситуацию как лишней, так и удалённой секунды тривиально, и проблема в том, что никто не хочет это делать.