Цели цифрового рубля цб не раскрывает. Отбрыкиваются дешевыми отписками. Из того, что заявили:
счета цр будут храниться напрямую в цб. т.е. функцию расчетов потихоньку отбирают у банков. вспоминаем также сбп. на банках оставляют кредиты/депозиты/факторинг и пр. сложную бизнес-логику.
цб заявляет, что комиссии по переводам цр будут ниже, чем в банках. а на начальном этапе и вовсе отменят, скорее всего.
из того, о чем промолчали:
есть большая вероятность, что выдачу пенсий и бюджетные зп, счета эскроу в строительстве сделают в цр. счета цр государство через цб может более плотно контролировать за счет того, что они НЕ размазаны по банкам. по-сути, счета будут в одной базе.
есть ощущение, что наличные деньги заменят цр. технология позволяет вести оффлайн расчеты. а физический выпуск монет и банкнот государству дорого обходится. здесь же проблема фальшивомонетчиков. здесь же - обмен ветхих купюр. эти все затраты можно скинуть, применив цр.
цр может быть использован как средство международных расчетов в БРИКС. кто первым встал, того и тапки, так сказать. при этом, влияние россии в своем кластере сильно увеличится.
так что, если автор воспринимает цр, как актив, на котором можно будет как-то заработать, то напрасно. курс будет поддерживаться к рублю как 1 к 1.
так было в россии раньше, поскольку оглядывались на мвф. с начала сво забили уже на этот мвф и могут печатать, сколько влезет. поэтому, тема цифрового рубля уже не коррелирует с печатью валюты.
С отказом от расчетов в usd возникли определенные трудности с международными расчетами. Поскольку торговый баланс практически ни с одной страной не соблюдается. Возникла идея вести международные расчеты или их часть в крипте.
Биткоину взрослые дяди не доверяют. Потому как ничем не обеспечен. И плодить еще один рычаг влияния на россию - наши не будут. Но вот поиграться со своей криптовалютой - можно. По-сути, она будет ничем не хуже биткоина, но только будет обеспечена звр России. И если пойдет, то крипта возьмет на себя международные расчеты хотя бы в БРИКС.
если говорить про юзеров в инете, то им вообще по барабану crl. Т.е. устанавливается шифрованное соединение с сервером и норм. И пофиг, что сертификат сервера протух. Конечно, браузеры пищат и пытаются что-то там проверять, но как указал ранее, они не знают откуда брать правильные crl-ы. Далеко не во всех ca указаны точки дистрибьюции crl. И здесь помимо crl-а может быть куча мест для подлога.
Имеет смысл говорить о crl именно для случаев авторизации клиента, например, в госуслугах. Т.е. когда серверу ОЧЕНЬ важно проверить валидность сертификата клыента. Но, как уже сказал, сервер является корпоративной системой. И в ней можно настроить все то, о чем говорил.
Были у нас случаи в банке, когда прилетал непонятный сертификат и проверить его не получалось на известных СА УЦ. Безопасники описали эту ситуацию так: клиент че-то там важное присылает и делает квалифицир. подпись сертификатом какого-то нового УЦ. При этом, клиент готов ждать минут 5, после чего идет в другой банк. Возник вопрос - а чего вы от разработки то хотите? Чтобы мы автоматом в систему закинули чей-то ca,crl, ctl и на них валидировали документы вашего клыента? Безопасники ушли чесать репу.
Ну, то есть, со стороны сервера доверенные точки дистрибьюции crl известны заранее. И это проблема безопасников их своевременно как-то обновлять.
А проблема удостоверения серверных сертификатов пока решается только лишь путем успешного хендшейка на сертификатах. Никакие crl-ы или иные механизмы вас здесь не спасут.
К слову, ocsp решает какие-то проблемы только если сама прога УЦ выставляет этот сервис в инет. Иначе, опять возникают интеграционные задержки. А это, как понимаете, не самая мудрая мысль ввиду ddos,так на переполнение буфера и прочих прелестей, которые пойдут мимо всех файрволов прямиком в систему УЦ.
Так что, улучшая механизм crl, вы получаете новые риски в карту безопасности общего решения. А серьезные дядьки на каждый такой риск должны сделать систему мониторинга наступления этого риска, описать сценарий действий при наступлении риска. Установить sla устранения риска.Короче, заняться риск-менеджментом. И делать это никому не хочется. Со старыми crl куда как проще: все риски давно прописаны, а обновление crl раз в пару дней - никого не напрягает. В те редкие случаи, когда надо быстро отозвать сертификат - вызванивают руками нужный уц.
Пока не понятно, в чем состоит "разгон". Все приемы, что приведены с статье - интересны с архитектурной точки зрения и "правильности" построения кода. Но все эти приемы не устраняют основные причины замедления при работе с блоками памяти.
Проблемы с выделением и освобождением памяти в с++ примерно такие:
В мультипоточной среде, если используется одна куча памяти (heap), то в своих операциях она использует средства синхронизации ОС. Т.о. если потоков много, то они начинают "ждать" друг-друга, поскольку операции выделения, освобождения и перераспределения размера блока не очень быстрые (особенно в драйверах). Также, если они должны учесть выравнивание выделенного блока на определенную границу. Для избежания этого можно делать несколько куч. Главное - не запутаться в них. Система управления кучами - здесь бы помогла. Т.е. по какому принципу их разделять, когда создавать, какого размера и т.д.
Любая куча быстро замусоривается/фрагментируется, если в ней происходит работа с разного размера блоками. Попытка использования такого блока в операциях выделения и изменения размера приводит к увеличению задержек в п.1. Какая-то необычная структура кучи могла бы повысить скорость работы с ней.
Стандартные средства синхронизации ОС, используемые в куче (критическая секция, мьютекс) НЕ гарантируют доступ к ресурсу в порядке какой-то очередности. Т.е. если конкурентных потоков очень много, то один из первых запросов может ждать захвата ресурса О-О-очень долго (по меркам процессора и даже профайлера).
Сборщик "мусора" в с++ - традиционная головная боль, если начинаешь хоть как-то сам управлять этими кучами. умные указатели гарантируют лишь своевременное освобождение ресурса. Дефрагментацией приходится заниматься либо в момент освобождения блока (что существенно замедляет операцию освобождения), либо отдельным процессом, который тоже лочит всю кучу и мешает другим потокам с ней работать.
механизм crl -старый и не рассчитан на большие нагрузки (отзыв сертификатов каждый час), но там есть разные костыли, которые позволяют использовать его до сих пор.
например, не обязательно выпускать все сертификаты строго на одном са. можно сделать несколько sub-ca и тогда список crl сокращается в несколько раз. а уж несколько тысяч строк в crl-это разговор ни о чем. файл о несколько десятков килобайт.
если все сертификаты в crl имеют not after меньше текущей даты, то список можно обнулить. ну или выбить из него такие сертификаты.
можно выдавать сертификаты на ограниченный срок. практически все центры выдают их на год или меньший срок.
про корректно подписанный, но не актуальный- не понял. если вы имеете ввиду ныне устаревший, но ранее валидный crl, так их нужно брать со строго установленного источника по https с обменом на сертификатах, я об этом говорил.
если даже некто попытается стать man in the middle,то поскольку шифрование в tls соединении происходит на сертификатах и их ключах, то такой man тупо не сможет завершить даже handshake tls, а не то чтобы передать устаревший crl.
опять же, говорил ранее, что сам tls может работать и вообще без шифрования, может и на слабых ключах, может и на прегенеренных ключах без клиентского сертификата. эти все штуковины нужно отключать на сервере для такого случая. а у клиента должен быть готов сертификат, который сервер опознает валидным для целей обмена по tls.
это нормально, когда ваша система вводится в эксплуатацию, вы определяете круг источников сертификатов+crl и прописываете у себя их ca (напомню, есть еще ctl списки, их тоже нужно учитывать). просто тупо брать в инете чей-то crl и пытаться его использовать - это дыра в безопасности. с течением времени, безопасники добавляют новые источники и удаляют не действующие. обычная история в банке. сам делал такие процессы.
т.о. 1 задача здесь сводится к установлению НАДЕЖНОГО (не на словах) соединения к вполне конкретному источнику и уж потом ставится задача предачи в таком соединении списка crl.
что касается новых вариантов обмена. их надо изучать на предмет различных угроз. ввиду сложности новых механизмов, безопасники не спешат их разрешать, пока не появятся вменяемые исследования кибер-специалистов.
например, идея сшивки мне кажется очень подозрительной. и нужно долго моделировать ситуации, чтобы убедиться, что это будет работать не хуже
Не понятен наезд на crl. Это просто файл. Передавать его можно как по http, так и по https. Либо строго по https. Вопрос только в том, чтобы клиентская сторона tls всегда запрашивала сертификат сервера и проверяла его валидность. Чтобы так работал tls протокол, нужно его настроить соответствующим образом на клиенте и на сервере.
В итоге, клиент проверяет сертификат сервера и затем - подписанный crl уц. Первое - гарантирует, что crl пришел из правильного места. Второе- что сам crl валидный.
Т.о. при правильной настройке проблем с безопасностью для crl-нет.
Другое дело, что если УЦ и публикующий сервер- это разные информационные системы, то могут быть задержки со своевременной публикацией нового crl, какие-то проблемы с недонастроенными цепочками сертификатов уц и web-сервера. и т.д. Но это - уже тонкости конкретных реализаций и к общей концепции безопасности pki они отношения не имеют.
понятно. хотя доля таких - не велика. править один вордовый файл несколькими юзерами одновременно - сильно устаревший архитектурный подход. напомню, что сам пакет офиса уже переполз в облако. и уже сам производитель не рекомендует так делать. иначе, есть ненулевая вероятность просто запортить файл, даже если он хранится на надежном файл-сервере. были случаи.
у figma есть серверная часть. как и у git. как и у других подобных корпоративных продуктов. здесь проблем быть не должно.
не очень понятно, зачем в многоюзеровском режиме рассчитывать значение индекса параллельно для разных юзеров. очевидно, что речь идет об учетной системе, где количество юзеров далеко не бесконечно. в warehouse индексы можно сделать, если они вообще используются, на этапе загрузки данных - здесь конкуренция минимальна.
для учетной системы, думаю, лучше рассчитывать значение индекса под блокировкой. это позволит в каждый момент времени иметь только один расчет и сократит длину значения индекса до минимально возможной. потуги юзеров разрулит другой механизм - блокировка ресурса.
а то получается, сначала вели разговор про 1 бит на вставку и меньше, а потом - бах и 25 бит timestamp на вставку, и то не факт, что 2 юзера в одну и ту же миллисекунду не вставят свои значения. хотя, вероятность, конечно. не большая. но по закону подлости в промышленной системе она наступит.
из недавних моих исследований следует, что при нагрузке 5-10 запросов в сек на операцию, блокировки справляются очень хорошо. особенно, если их очень правильно сделать. но это уже другая история😄
а че sys.com то не сработал? все-равно компилировал исходники, надо было проверку на версию dos отключить перед компиляцией. вроде, оно там все от mbr-а до файлов загрузки переносит.
чего вы кипятитесь? я вам на мозоль наступил? вы расставили акценты совсем не туда. Вы упираете на безразмерность потока. И говорите о том, что ничего не вечно и все конечно.
Поток данных - это просто концепция. Ну получит отправитель в какой-то момент ошибку и что? Отправка то все-равно идет блоками. Т.е. периодически клиент может получать ответ. Данные устаревают и теряются. Обычное дело.
Акцент нужно было делать на то, что файлы в ос сейчас хранят НЕ структурированную с точки зрения ос информацию. А предлагается хранить структурированную, много более сложную.
Но все это все-равно хранится внутри одного файла.
Идея была в том, чтобы существенно усилить этот механизм. По тем направлениям, о которых рассказал. А вы все твердите про бесконечны поток. Можно на уровне ОС заменить все файлы вот такими хранилищами, откуда будет удобно доставать тот или иной тип ресурса.
Волшебства в мире нет и я это понимаю не хуже вас.
Нужно обращать внимание на более практические темы, а не вдаваться в утопии.
Новые веяния- это очень хорошо. но скорее, речь шла об известном в linux утверждении.
Но!!! Никто не заметил маленькую хитрость? Много позднее Торвальд исправил это изречение на "все есть файловый дескриптор". Уже даже по этой причине фраза "все - есть файл" - устарела.
А "знатоки" тут с пеной у рта доказывают обратное. Казино никогда не проигрывает?
Спасибо всем за комментарии.
ps вспомнил, что кто-то таки упомянул фразу торвальда. Прости, друг, подзабыл.
уточните, на файловом дескрипторе или сокете? например, винда не рассматривает сокет как файловое устройство. там свое api чтения и записи в сокет. более того, в сокетах винды появились события. это-то кае укладывается на файловый ввод-вывод?
про io_uring и aio- ничего не знаю, не знаток архитектуры линухов. но если они древние, то почему древние?
не увидел, где я сказал, что мне oob не нравится. я сказал, что через файловый ввод-вывод нельзя протащить oob данные. это фишка только сокетов. с какого перепугу все решили, что файловый ввод-вывод так умеет?
ну так используется 2 дескриптора, а не один. пример не показателен. потому что внутри механизма существуют блокировки на параллельное использование каждого файлового хендла. А в вашем примере блокировка не сработает ввиду другого хендла.
ну, нередкость открыть 40 окон в браузере. каждое окно содержит ленту. если делать хендл на каждый элемент ленты, да еще те, которые скрыты вне экрана (а мы не знаем, так ли это, хотя такое- плохой паттерн), то легко вылезти за лимит хендлов.
любой поток винды, использующий com открывает скрытое окно, минимум одно. выяснил случайно. в винде есть функция переключения активных десктопов. она не работает, если в потоке было создано хоть одно окно. из потока, работающего с com объектами она тоже не работает. приходится запускать чистый поток и переключать оттуда. но эта фишка нигде в msdn не описана. отсюда - вывод: винда сама использует эти хендлы даже в вашем потоке, а не только в системных. и сколько из них она использует - фиг знает.
про хендлы: опытным путем проверял только хендлы кучи памяти и графические. но возможно, это на поток, а не на процесс. глубже не копал.
Проблема не была озвучена, потому что ее нет. Цель статьи - не описание проблемы и тем более вариантов ее решения.
Вы когда-нибудь видели такую поделку? смотришь на нее с одной стороны - видно одно слово, смотришь с другой - появляется совсем другое слово.
Точка зрения важна. Она формирует идею, которая потом воплощается в реализации.
Смотря на проблему хранения только с точки зрения файлов, разработка напрочь отвергает иные, иногда интересные и более прогрессивные, варианты реализаций.
Вы видите, какое сопротивление встречает простая идея замены файла стримом? Ну был хендл файла, станет хендл стрима. А чем проблема? Но нет! Нельзя покушаться на святое! Автор нифига не понимает ни в архитектуре и ни в абстрактном мышлении.
И ничего, что сокет только в линухе как-то совместим с файловыми операциями, а винда не рассматривает сокет как файловый дескриптор. Да класть на винду и мак! "Сокет- это файловый дескриптор!" - громогласно провозглашает линуксовод. Даже не пытаясь вникнуть в суть и природу этого сокета.
Криптооперации есть и в ядре. Но мне очень сложно представить, что имея на входе криптооперации 10 байт строки 'аааа...', на выходе получаем 15 байт билиберды - это какая-то файловая операция. И это часть механизма ядра.
Еще там есть виртуальная память. которая тоже складируется на диск. Без файловых хендлов. Совсем. Это для вас новость?
Если уже на то пошло, доля файловых операций в любом драйвере, любой программе начинается от 10—15%. А все остальное что? Реализация паттернов проектирования (по современным представлениям так должно быть): фабрики и фабричные методы, стратегии и фасады, синглтоны и машины состояний и т.д. Где здесь файловый ввод? Нету его там. Только где-то в играх доля файловых операций может подняться до 45%. Ну еще файл-сервера.
Автор "прыгает" в попытке показать несколько разных примеров. Т.е. что это не единичный случай. А не оттого, что где-то колет.
Очевидно, что просто мысли автора до вас не дошли по какой-то причине. Но как есть..
это два измерения, а не двумерное время. очевидно же, что время для них - одно и то же, а вот вектор пространства - меняется.
Цели цифрового рубля цб не раскрывает. Отбрыкиваются дешевыми отписками. Из того, что заявили:
счета цр будут храниться напрямую в цб. т.е. функцию расчетов потихоньку отбирают у банков. вспоминаем также сбп. на банках оставляют кредиты/депозиты/факторинг и пр. сложную бизнес-логику.
цб заявляет, что комиссии по переводам цр будут ниже, чем в банках. а на начальном этапе и вовсе отменят, скорее всего.
из того, о чем промолчали:
есть большая вероятность, что выдачу пенсий и бюджетные зп, счета эскроу в строительстве сделают в цр. счета цр государство через цб может более плотно контролировать за счет того, что они НЕ размазаны по банкам. по-сути, счета будут в одной базе.
есть ощущение, что наличные деньги заменят цр. технология позволяет вести оффлайн расчеты. а физический выпуск монет и банкнот государству дорого обходится. здесь же проблема фальшивомонетчиков. здесь же - обмен ветхих купюр. эти все затраты можно скинуть, применив цр.
цр может быть использован как средство международных расчетов в БРИКС. кто первым встал, того и тапки, так сказать. при этом, влияние россии в своем кластере сильно увеличится.
так что, если автор воспринимает цр, как актив, на котором можно будет как-то заработать, то напрасно. курс будет поддерживаться к рублю как 1 к 1.
так было в россии раньше, поскольку оглядывались на мвф. с начала сво забили уже на этот мвф и могут печатать, сколько влезет. поэтому, тема цифрового рубля уже не коррелирует с печатью валюты.
С отказом от расчетов в usd возникли определенные трудности с международными расчетами. Поскольку торговый баланс практически ни с одной страной не соблюдается. Возникла идея вести международные расчеты или их часть в крипте.
Биткоину взрослые дяди не доверяют. Потому как ничем не обеспечен. И плодить еще один рычаг влияния на россию - наши не будут. Но вот поиграться со своей криптовалютой - можно. По-сути, она будет ничем не хуже биткоина, но только будет обеспечена звр России. И если пойдет, то крипта возьмет на себя международные расчеты хотя бы в БРИКС.
если говорить про юзеров в инете, то им вообще по барабану crl. Т.е. устанавливается шифрованное соединение с сервером и норм. И пофиг, что сертификат сервера протух. Конечно, браузеры пищат и пытаются что-то там проверять, но как указал ранее, они не знают откуда брать правильные crl-ы. Далеко не во всех ca указаны точки дистрибьюции crl. И здесь помимо crl-а может быть куча мест для подлога.
Имеет смысл говорить о crl именно для случаев авторизации клиента, например, в госуслугах. Т.е. когда серверу ОЧЕНЬ важно проверить валидность сертификата клыента. Но, как уже сказал, сервер является корпоративной системой. И в ней можно настроить все то, о чем говорил.
Были у нас случаи в банке, когда прилетал непонятный сертификат и проверить его не получалось на известных СА УЦ. Безопасники описали эту ситуацию так: клиент че-то там важное присылает и делает квалифицир. подпись сертификатом какого-то нового УЦ. При этом, клиент готов ждать минут 5, после чего идет в другой банк. Возник вопрос - а чего вы от разработки то хотите? Чтобы мы автоматом в систему закинули чей-то ca,crl, ctl и на них валидировали документы вашего клыента? Безопасники ушли чесать репу.
Ну, то есть, со стороны сервера доверенные точки дистрибьюции crl известны заранее. И это проблема безопасников их своевременно как-то обновлять.
А проблема удостоверения серверных сертификатов пока решается только лишь путем успешного хендшейка на сертификатах. Никакие crl-ы или иные механизмы вас здесь не спасут.
К слову, ocsp решает какие-то проблемы только если сама прога УЦ выставляет этот сервис в инет. Иначе, опять возникают интеграционные задержки. А это, как понимаете, не самая мудрая мысль ввиду ddos,так на переполнение буфера и прочих прелестей, которые пойдут мимо всех файрволов прямиком в систему УЦ.
Так что, улучшая механизм crl, вы получаете новые риски в карту безопасности общего решения. А серьезные дядьки на каждый такой риск должны сделать систему мониторинга наступления этого риска, описать сценарий действий при наступлении риска. Установить sla устранения риска.Короче, заняться риск-менеджментом. И делать это никому не хочется. Со старыми crl куда как проще: все риски давно прописаны, а обновление crl раз в пару дней - никого не напрягает. В те редкие случаи, когда надо быстро отозвать сертификат - вызванивают руками нужный уц.
Пока не понятно, в чем состоит "разгон". Все приемы, что приведены с статье - интересны с архитектурной точки зрения и "правильности" построения кода. Но все эти приемы не устраняют основные причины замедления при работе с блоками памяти.
Проблемы с выделением и освобождением памяти в с++ примерно такие:
В мультипоточной среде, если используется одна куча памяти (heap), то в своих операциях она использует средства синхронизации ОС. Т.о. если потоков много, то они начинают "ждать" друг-друга, поскольку операции выделения, освобождения и перераспределения размера блока не очень быстрые (особенно в драйверах). Также, если они должны учесть выравнивание выделенного блока на определенную границу. Для избежания этого можно делать несколько куч. Главное - не запутаться в них. Система управления кучами - здесь бы помогла. Т.е. по какому принципу их разделять, когда создавать, какого размера и т.д.
Любая куча быстро замусоривается/фрагментируется, если в ней происходит работа с разного размера блоками. Попытка использования такого блока в операциях выделения и изменения размера приводит к увеличению задержек в п.1. Какая-то необычная структура кучи могла бы повысить скорость работы с ней.
Стандартные средства синхронизации ОС, используемые в куче (критическая секция, мьютекс) НЕ гарантируют доступ к ресурсу в порядке какой-то очередности. Т.е. если конкурентных потоков очень много, то один из первых запросов может ждать захвата ресурса О-О-очень долго (по меркам процессора и даже профайлера).
Сборщик "мусора" в с++ - традиционная головная боль, если начинаешь хоть как-то сам управлять этими кучами. умные указатели гарантируют лишь своевременное освобождение ресурса. Дефрагментацией приходится заниматься либо в момент освобождения блока (что существенно замедляет операцию освобождения), либо отдельным процессом, который тоже лочит всю кучу и мешает другим потокам с ней работать.
Ну, что-то такое.
механизм crl -старый и не рассчитан на большие нагрузки (отзыв сертификатов каждый час), но там есть разные костыли, которые позволяют использовать его до сих пор.
например, не обязательно выпускать все сертификаты строго на одном са. можно сделать несколько sub-ca и тогда список crl сокращается в несколько раз. а уж несколько тысяч строк в crl-это разговор ни о чем. файл о несколько десятков килобайт.
если все сертификаты в crl имеют not after меньше текущей даты, то список можно обнулить. ну или выбить из него такие сертификаты.
можно выдавать сертификаты на ограниченный срок. практически все центры выдают их на год или меньший срок.
про корректно подписанный, но не актуальный- не понял. если вы имеете ввиду ныне устаревший, но ранее валидный crl, так их нужно брать со строго установленного источника по https с обменом на сертификатах, я об этом говорил.
если даже некто попытается стать man in the middle,то поскольку шифрование в tls соединении происходит на сертификатах и их ключах, то такой man тупо не сможет завершить даже handshake tls, а не то чтобы передать устаревший crl.
опять же, говорил ранее, что сам tls может работать и вообще без шифрования, может и на слабых ключах, может и на прегенеренных ключах без клиентского сертификата. эти все штуковины нужно отключать на сервере для такого случая. а у клиента должен быть готов сертификат, который сервер опознает валидным для целей обмена по tls.
это нормально, когда ваша система вводится в эксплуатацию, вы определяете круг источников сертификатов+crl и прописываете у себя их ca (напомню, есть еще ctl списки, их тоже нужно учитывать). просто тупо брать в инете чей-то crl и пытаться его использовать - это дыра в безопасности. с течением времени, безопасники добавляют новые источники и удаляют не действующие. обычная история в банке. сам делал такие процессы.
т.о. 1 задача здесь сводится к установлению НАДЕЖНОГО (не на словах) соединения к вполне конкретному источнику и уж потом ставится задача предачи в таком соединении списка crl.
что касается новых вариантов обмена. их надо изучать на предмет различных угроз. ввиду сложности новых механизмов, безопасники не спешат их разрешать, пока не появятся вменяемые исследования кибер-специалистов.
например, идея сшивки мне кажется очень подозрительной. и нужно долго моделировать ситуации, чтобы убедиться, что это будет работать не хуже
Не понятен наезд на crl. Это просто файл. Передавать его можно как по http, так и по https. Либо строго по https. Вопрос только в том, чтобы клиентская сторона tls всегда запрашивала сертификат сервера и проверяла его валидность. Чтобы так работал tls протокол, нужно его настроить соответствующим образом на клиенте и на сервере.
В итоге, клиент проверяет сертификат сервера и затем - подписанный crl уц. Первое - гарантирует, что crl пришел из правильного места. Второе- что сам crl валидный.
Т.о. при правильной настройке проблем с безопасностью для crl-нет.
Другое дело, что если УЦ и публикующий сервер- это разные информационные системы, то могут быть задержки со своевременной публикацией нового crl, какие-то проблемы с недонастроенными цепочками сертификатов уц и web-сервера. и т.д. Но это - уже тонкости конкретных реализаций и к общей концепции безопасности pki они отношения не имеют.
понятно. хотя доля таких - не велика. править один вордовый файл несколькими юзерами одновременно - сильно устаревший архитектурный подход. напомню, что сам пакет офиса уже переполз в облако. и уже сам производитель не рекомендует так делать. иначе, есть ненулевая вероятность просто запортить файл, даже если он хранится на надежном файл-сервере. были случаи.
у figma есть серверная часть. как и у git. как и у других подобных корпоративных продуктов. здесь проблем быть не должно.
спасибо, интересно.
не очень понятно, зачем в многоюзеровском режиме рассчитывать значение индекса параллельно для разных юзеров. очевидно, что речь идет об учетной системе, где количество юзеров далеко не бесконечно. в warehouse индексы можно сделать, если они вообще используются, на этапе загрузки данных - здесь конкуренция минимальна.
для учетной системы, думаю, лучше рассчитывать значение индекса под блокировкой. это позволит в каждый момент времени иметь только один расчет и сократит длину значения индекса до минимально возможной. потуги юзеров разрулит другой механизм - блокировка ресурса.
а то получается, сначала вели разговор про 1 бит на вставку и меньше, а потом - бах и 25 бит timestamp на вставку, и то не факт, что 2 юзера в одну и ту же миллисекунду не вставят свои значения. хотя, вероятность, конечно. не большая. но по закону подлости в промышленной системе она наступит.
из недавних моих исследований следует, что при нагрузке 5-10 запросов в сек на операцию, блокировки справляются очень хорошо. особенно, если их очень правильно сделать. но это уже другая история😄
не существует единого значения G на земле. на экваторе - одно значение (9.82), в других широтах - другое (до 9.78).
pi*pi=9.86 так что на земле нет места с таким g?
а че sys.com то не сработал? все-равно компилировал исходники, надо было проверку на версию dos отключить перед компиляцией. вроде, оно там все от mbr-а до файлов загрузки переносит.
чего вы кипятитесь? я вам на мозоль наступил? вы расставили акценты совсем не туда. Вы упираете на безразмерность потока. И говорите о том, что ничего не вечно и все конечно.
Поток данных - это просто концепция. Ну получит отправитель в какой-то момент ошибку и что? Отправка то все-равно идет блоками. Т.е. периодически клиент может получать ответ. Данные устаревают и теряются. Обычное дело.
Акцент нужно было делать на то, что файлы в ос сейчас хранят НЕ структурированную с точки зрения ос информацию. А предлагается хранить структурированную, много более сложную.
И все к этому идет. В той же винде для подобных целей уже есть stg хранилища, см. https://learn.microsoft.com/ru-ru/windows/win32/stg/structured-storage-start-page
Но все это все-равно хранится внутри одного файла.
Идея была в том, чтобы существенно усилить этот механизм. По тем направлениям, о которых рассказал. А вы все твердите про бесконечны поток. Можно на уровне ОС заменить все файлы вот такими хранилищами, откуда будет удобно доставать тот или иной тип ресурса.
Волшебства в мире нет и я это понимаю не хуже вас.
Нужно обращать внимание на более практические темы, а не вдаваться в утопии.
Новые веяния- это очень хорошо. но скорее, речь шла об известном в linux утверждении.
Но!!! Никто не заметил маленькую хитрость? Много позднее Торвальд исправил это изречение на "все есть файловый дескриптор". Уже даже по этой причине фраза "все - есть файл" - устарела.
А "знатоки" тут с пеной у рта доказывают обратное. Казино никогда не проигрывает?
Спасибо всем за комментарии.
ps вспомнил, что кто-то таки упомянул фразу торвальда. Прости, друг, подзабыл.
"все - есть файл". виртуальная память В ЯДРЕ - не есть файл или какие-то файловые операции. при этом, виртуальная память складируется на диск.
нарушение в логике не улавливаете? я пытаюсь донести до вас идею, что не все операции с диском, даже в ядре ос - есть файловые.
вы либо троллите меня, либо не очень сообразительны. фраза "все - есть файл" называет операции с виртуальной памятью файловыми. разве нет?
никто ни с кем не воюет, если вы про это? идеальную статью тоже нет смысла писать. тогда никто комментировать не будет?
уточните, на файловом дескрипторе или сокете? например, винда не рассматривает сокет как файловое устройство. там свое api чтения и записи в сокет. более того, в сокетах винды появились события. это-то кае укладывается на файловый ввод-вывод?
про io_uring и aio- ничего не знаю, не знаток архитектуры линухов. но если они древние, то почему древние?
не увидел, где я сказал, что мне oob не нравится. я сказал, что через файловый ввод-вывод нельзя протащить oob данные. это фишка только сокетов. с какого перепугу все решили, что файловый ввод-вывод так умеет?
ну так используется 2 дескриптора, а не один. пример не показателен. потому что внутри механизма существуют блокировки на параллельное использование каждого файлового хендла. А в вашем примере блокировка не сработает ввиду другого хендла.
в том же линухе (и тем более в винде) есть отдельное понятие потока данных. и это не файл. хотя он может быть связан неким образом с файлом.
так что просто назвать файл стримом - уже, де-факто, нельзя. приходится оперировать устоявшимися терминами.
ну, нередкость открыть 40 окон в браузере. каждое окно содержит ленту. если делать хендл на каждый элемент ленты, да еще те, которые скрыты вне экрана (а мы не знаем, так ли это, хотя такое- плохой паттерн), то легко вылезти за лимит хендлов.
любой поток винды, использующий com открывает скрытое окно, минимум одно. выяснил случайно. в винде есть функция переключения активных десктопов. она не работает, если в потоке было создано хоть одно окно. из потока, работающего с com объектами она тоже не работает. приходится запускать чистый поток и переключать оттуда. но эта фишка нигде в msdn не описана. отсюда - вывод: винда сама использует эти хендлы даже в вашем потоке, а не только в системных. и сколько из них она использует - фиг знает.
про хендлы: опытным путем проверял только хендлы кучи памяти и графические. но возможно, это на поток, а не на процесс. глубже не копал.
Проблема не была озвучена, потому что ее нет. Цель статьи - не описание проблемы и тем более вариантов ее решения.
Вы когда-нибудь видели такую поделку? смотришь на нее с одной стороны - видно одно слово, смотришь с другой - появляется совсем другое слово.
Точка зрения важна. Она формирует идею, которая потом воплощается в реализации.
Смотря на проблему хранения только с точки зрения файлов, разработка напрочь отвергает иные, иногда интересные и более прогрессивные, варианты реализаций.
Вы видите, какое сопротивление встречает простая идея замены файла стримом? Ну был хендл файла, станет хендл стрима. А чем проблема? Но нет! Нельзя покушаться на святое! Автор нифига не понимает ни в архитектуре и ни в абстрактном мышлении.
И ничего, что сокет только в линухе как-то совместим с файловыми операциями, а винда не рассматривает сокет как файловый дескриптор. Да класть на винду и мак! "Сокет- это файловый дескриптор!" - громогласно провозглашает линуксовод. Даже не пытаясь вникнуть в суть и природу этого сокета.
Криптооперации есть и в ядре. Но мне очень сложно представить, что имея на входе криптооперации 10 байт строки 'аааа...', на выходе получаем 15 байт билиберды - это какая-то файловая операция. И это часть механизма ядра.
Еще там есть виртуальная память. которая тоже складируется на диск. Без файловых хендлов. Совсем. Это для вас новость?
Если уже на то пошло, доля файловых операций в любом драйвере, любой программе начинается от 10—15%. А все остальное что? Реализация паттернов проектирования (по современным представлениям так должно быть): фабрики и фабричные методы, стратегии и фасады, синглтоны и машины состояний и т.д. Где здесь файловый ввод? Нету его там. Только где-то в играх доля файловых операций может подняться до 45%. Ну еще файл-сервера.
Автор "прыгает" в попытке показать несколько разных примеров. Т.е. что это не единичный случай. А не оттого, что где-то колет.
Очевидно, что просто мысли автора до вас не дошли по какой-то причине. Но как есть..