А вот автоматически переделывать пробелы на табы уже не такая тривиальная задача, можно и данные для справочников в .sql файлах попортить, и много других спорных моментов: таб это просто 4 пробела (или два? или три? или восемь?), или таб это способ допрыгнуть в колонку индексом кратную 4, т.е. таб может быть и на 1 и 2 и на 3 пробела или на четыре? Т.е. любители табов с т.з. заказчика, и не только заказчика занимаются какой-то ерундой. Место так особо не сэкономить, а какой еще в них смысл?

Про make если вспоминать, то все вроде гласно и негласно сошлись на том, что там с табами все изначально настолько печально, что make в реальности можно пользоваться только через какой CMake или autoconf. Т.е. фактически табы потерпели фиаско еще в 70-х.

TSV и тот проиграл CSV сразу на старте

А еще в Oracle PL/SQL оказывается изначальным стандартом отступы были табом на 3 пробела, в документации на 8.1.7 это особенно заметно: дедушки знали толк в извращениях :)

А вот реальной стабильной альтернативой Win'95 была Windows NT 4.0, очень достойный продукт своего времени, который мог запускать вытесняющей многозадачностью и DOS, и win16 и само собой win32, если в наличии были 16MB+ RAM (их можно было далеко не во всякую материнку того времени вставить)

Но основная идея да, заключается в том, что с 64 битами адреса и возможностью манипуляций с mmap(MAP_FIXED) многие старые парадигмы управления памятью из 16-, 31-, 32- битных миров из 70-х годов как минимум могут быть пересмотрены. К примеру можно играть в арены (region memory aka memory pools), с заданными циклами жизни, и не заниматься мелкодробным free() / delete - т.е. вместо malloc() / new выделять память, просто последовательно сдвигая HWM в заранее отмпаленном регионе, прям как в Java, и лишь в конце жизненного цикла (внешнего вызова, сессии, процесса) - просто удалять этот регион целиком. Внешние ресурсы (хендлы) - собирать в linked list и удалять вместе с регионом. Про деструкторы и вовсе забыть. Идея кстати не нова, вовсю используется в APR / apache httpd и PostreSQL, образцах long-running стабильности. В виде плюшки заодно и от memory reuse с undefined behavior проблем избавиться.

Реализацией пока не поделюсь, это отдельный исследовательский проект, думаю в следующем году выложить в github/MIT. Правда вопросами кольцевых буферов в аспекте непрерывной группы чанков я не озадачивался, пока не было необходимости. Пока там в части кольцевых буферов пока лишь аналог LMAX Disruptor для сверхскоростной межпроцессной IPC на lockfree алгоритмах. Для меня самого было удивительным, что даже в offset pointer на самом деле уже и не особо надо, если для всех изолированных процессов заранее замапить буфер в строго определенный адрес - так все процессы будут иметь единую сквозную адресацию.

И т.д. :)

И для замены ServiceNow оказывается уже существуют FreeITSM, iTop, GLPI - т.е. все давно изобретено до вас, для AI/PET проектов тема управления IT процессами точно не годится.

И платформ LowCode в последнее время тоже появилось десятки разных, еще одна скорее всего никому не нужна.

А еще можно вспомнить про LowСode платформу 1С, где тоже можно очень быстро создать конфигурацию для импортозамещения JIRA и ServiceNow :)

80TB это примерно 80млн чанков размером по 1MB. А при достижении "верхнего предела" можно просто взять паузу и сделать remap() активной часть буфера в начало.

Не просто так конечно - там уже нужно будет две последовательно очень большие области, скажем по 40TB. И если наш читающий хвост переехал из первой области во вторую (т.е. первая стала полностью не нужна), то мы быстро первую отмпаливаем целиком, вторую ставим на место первой через mremap(), и еще раз делаем заново mmap() второй области с MAP_FIXED.

Linux довольно консервативен в части использования диапазонов адресов - все что не первый и не последний терабайт из адресуемых 128TB userspace - это система практически не задействует сама (heap растет снизу вверх, стек и mmap()ы без указания адреса - сверху вниз).

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

Там другое забавнее. Если SDD промпт чуть более двух листов и генерируемый бандл больше условных 50к, то начинается веселая игра вида "уточняем вот тут требования или пытаемся исправить поведение, в результате вот тут вроде как чинится, но внезапно ломается в других местах, и даже там, где не просили; чиним уже там - ломается тут уже то, что собирались чинить изначально, в результате идем думать как все-таки завтра описать новые требования в SDD спеке, чтоб не сразу много поломалось на следующий день, а в конце недели решаем, что проще плюнуть и вернуться к ручному кодированию с явным контролем границ изменений".

Но вот что забавно - запуская один и тот-же промпт / SDD в разные дни - на выходе каждый раз получаешь абсолютно разные результаты, которые даже через meld или winmerge невозможно сравнить, а через git отслеживать изменения уже и вовсе бесполезно, настолько все прыгает хаотичным образом по файлам.

Но десятком подобных SDD итераций в принципе можно приблизиться к более-менее работоспособному результату в один случайный день, а в целом - как минимум продумать и описать вручную (а как еще?) модель данных, осознать-описать ключевые функции в этом самом SDD.
В результате будет на выходе формальное ТЗ, которое и для человеков тоже вполне себе полезный документ, и... да, не такой уж и плохой стартовый бандл, даже с какой-то структурой проекта, который как минимум компилируется, запускается, что-то отдаленно похожее на требования из ТЗ делает в рамках заданного стека и прочих ограничений.

И вот на этом вся AI революция и заканчивается, дальше начинаются реалии. Потому что этот бандл без ручных изменений выпускать в продакшин, даже в локальный intranet для каких видавших виды кладовщиков склада готовой продукции - уже в реальности не получится, и все причастные прекрасно знают почему :)

А после ручных изменений дальше весело играть в SDD уже не есть возможно, т.к. каждая новая итерация / генерация безжалостно потрет и все ранее внесенные в код ручные правки, и даже без ручных правок - аннулирует десятки часов "ручного" code-review и/или "ручного" UI-тестирования.
Т.е. на этом этапе или возвращаемся обратно на нулевой цикл генерировать очередной POC / MVP, или забираем на баланс старого доброго ручного сопровождения, доработки и тестирования этот самый удачный бандл.

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