При записи произошла ошибка но часть данных записалась а часть нет (усложненный кейс - вторая половина данных записалась а первая нет)
При сбросе буферов (при синке) произошла ошибка и часть кэша синкнулась а часть нет (усложненный случай - данные записанные позже чиркнули б а записанные раньше нет, бросив ошибку синка)
У вас "немного странные" представления о работе ФС, потому как сценарий "При попытке записи буфера в файл, вставляется заполненный нулями буфер такого же размера" является невозможным.
Сдается мне, что проблема с NVMe over TCP на стороне хранилки. В наших тестах NVMe/TCP показывал примерно на 5-10% лучшую производительность чем iSCSI, особенно в тестах рандомной записи (при использовании кернельных таргетов iSCSI и NVMe)
средняя желаемая заработная плата IT-специалистов, подготовленных этим ВУЗом, составляет
Слово "желаемая" в этом предложении первого абзаца статьи наводит на мысль, что в подарочный набор выпускников, подготовленных этим ВУЗом, забыли положить карандаш для закатывания губ.
А потом ВНЕЗАПНО пакеты с вредоносным кодом от любителей всего хорошего против всего плохого ВНЕЗАПНО приехали на сервера таких же любителей всего хорошего против всего плохого из организаций, ныне относимых к иноагентам, отчего получился милейший жабогадюкинг.
Ну 4 миллиона транзакций в день, ну ок. У меня во время одного инцидента была под временные данные создана таблица то ли на 200 миллионов записей, то ли на 600, не вспомню сразу. И после первичной набивки из нее только читали. Правильное шардирование (для горячих данных) и архитектура решает проблему ну не то чтобы легко, но без необходимости внеземных технологий и знаний.
В гугле внезапно вспомнили, что операционная система может быть многозадачной, а к серверу можно подключиться одновременно множеством подключений и обрабатывать данные в нескольки потоках? Прямо таки прорыв. Еще лет через десять наверное смогут сделать загрузку и обновление трех приложений одновременно!
В случае с мультипартом селектел действует абсолютно правильно. Если вы решили отменить мультипартовую загрузку - для этого в API S3 есть соответствующая функция.
Эммм... Ну вообще есть такое событие "новая" ("взрыв новой"), которое как раз и происходит с белыми карликами при некоторых условиях. Никаких противоречий - звезда старая, с ней происходит событие "взрыв новой" - вроде все нормально
И фактически этот флаг и станет тем самым "poison pill" который в этой статье и описан. Только это приведет еще к тому, что надо будет мониторить этот флаг. Добавляется также проблема с тем, что если consumer вошел в блокирующее ожидание на очереди, это ожидание нужно прервать при выставлении флага.
И вишенка на торте - когда система распределенная и publisher и consumer работают в разных процессах и на разных серверах, и тогда вы с флагом вообще задолбаетесь.
Чем это решение лучше просто переменной в объекте Consumer?
Тем, что Publisher не должен знать о реализации Consumer, о том есть ли у него эта магическая переменная, о том существует ли вообще Consumer, сколько экземпляров Consumer, какая структура очереди (например либо это очередь классическая, либо множество реплик очереди каждая из которых к своему экземпляру Consumer'а).
Поэтому Publisher просто отправляет событие EOF (End-Of-File/ End-Of-Stream / End-Of-Data) и всё.
У вас мессенджер. У вас нет нужды в общем сеансовом ключе - вы можете использовать шифрование открытым ключом респондента напрямую для каждого сообщения (ибо они короткие) и/или генерировать одноразовые ключи для каждого большого сообщения. Поэтому Диффи-Хеллман вам больше не нужен.
Это мессенджер, оба клиента могут сидеть за натом, могут быть в оффлайне по очереди и так далее - поэтому никакого соединения нет. Сообщения передаются в шифрованном виде через сервер - схема того же уровня что и S/MIME.
Поэтому все что в ваших «подозрениях» касается совместной выработки сеансового ключа, сразу можно игнорировать как «неприменимо»
Сливает куда-то ОС ключи или нет - это уже не зависит от самой телеги. Ставьте на доверенное устройство. Это в общем то стандартное правило, чем выше уровень требуемой защищенности - тем шире требования к оборудованию, поэтому опять вопрос «мимо кассы»
Неужели никто не пробовал
Главный вопрос и ответ - «а нафига»? Сервис требует регистрации по номеру телефона, номер присваивается через сотового оператора, у него есть привязка номера к IMEI, к базовым станциям и т.д., поэтому телеграм неприватен изначально. Зачем вкладываться в изначально проприетарное чужое поделие?
Если вам нужна приватность - ее должно реализовывать Е2Е шифрование. Которое, внезапно, реализуется только в клиенте с помощью ключей, хранимых сторонами обмена локально.
Поэтому, если
пара ключей генерируется на клиенте (что проверяется по коду клиента)
приватный ключ хранится на клиенте (что проверяется по коду клиента)
приватный ключ не передается никуда из клиента (что проверяется по коду клиента)
в Е2Е обмене используется переданный второй стороной (что также можно проверить в коде клиента)
То уже не важно что там на сервере, ибо сервер является той самой "третьей стороной" от которой Е2Е защищает. Это в общем то азы криптографии, которые преподают на профильных специальностях.
Единственное допустимое отступление от этих четырех правил правила - прямая передача приватного ключа между устройствами клиента минуя сервер - например через QR-код. Ну а если хоть один критерий нарушен - то ой, обмен скомпрометирован.
Если вместо того, чтобы задрейнить ноду, вам проще ее мигрировать, то возникает предположение, что у вас что-то не так в консерватории и вы храните стейт там, где ему не место.
Насчет линуксового ядра, которое "написано в императивной парадигме" вы очень сильно ошибаетесь.
Возьмите например struct file и struct file_operations. Это как раз классический пример ООП, когда собственно struct file это объект, file.file_operations - VMT (virtual methods table), а file->file_operations->write(file, ... ) это по сути развернутый вариант file->write( ... )
Поэтому, ядро линукса это как раз хороший пример ООП, без излишних абстракций.
Шифрование на паре открытый-закрытый ключ и всё. Надуманная проблема. Достаточно просто решить задачу передачи открытого ключа
Есть несколько сценариев базовых интересных:
При записи произошла ошибка но часть данных записалась а часть нет (усложненный кейс - вторая половина данных записалась а первая нет)
При сбросе буферов (при синке) произошла ошибка и часть кэша синкнулась а часть нет (усложненный случай - данные записанные позже чиркнули б а записанные раньше нет, бросив ошибку синка)
Ошибки чтения неинтересны
У вас "немного странные" представления о работе ФС, потому как сценарий "При попытке записи буфера в файл, вставляется заполненный нулями буфер такого же размера" является невозможным.
Сдается мне, что проблема с NVMe over TCP на стороне хранилки. В наших тестах NVMe/TCP показывал примерно на 5-10% лучшую производительность чем iSCSI, особенно в тестах рандомной записи (при использовании кернельных таргетов iSCSI и NVMe)
Слово "желаемая" в этом предложении первого абзаца статьи наводит на мысль, что в подарочный набор выпускников, подготовленных этим ВУЗом, забыли положить карандаш для закатывания губ.
А потом ВНЕЗАПНО пакеты с вредоносным кодом от любителей всего хорошего против всего плохого ВНЕЗАПНО приехали на сервера таких же любителей всего хорошего против всего плохого из организаций, ныне относимых к иноагентам, отчего получился милейший жабогадюкинг.
Ну 4 миллиона транзакций в день, ну ок. У меня во время одного инцидента была под временные данные создана таблица то ли на 200 миллионов записей, то ли на 600, не вспомню сразу. И после первичной набивки из нее только читали. Правильное шардирование (для горячих данных) и архитектура решает проблему ну не то чтобы легко, но без необходимости внеземных технологий и знаний.
В гугле внезапно вспомнили, что операционная система может быть многозадачной, а к серверу можно подключиться одновременно множеством подключений и обрабатывать данные в нескольки потоках? Прямо таки прорыв. Еще лет через десять наверное смогут сделать загрузку и обновление трех приложений одновременно!
В случае с мультипартом селектел действует абсолютно правильно. Если вы решили отменить мультипартовую загрузку - для этого в API S3 есть соответствующая функция.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/abort-mpu.html
То, что вы не знаете этого, это ваша проблема а не селектела.
Эммм... Ну вообще есть такое событие "новая" ("взрыв новой"), которое как раз и происходит с белыми карликами при некоторых условиях. Никаких противоречий - звезда старая, с ней происходит событие "взрыв новой" - вроде все нормально
И фактически этот флаг и станет тем самым "poison pill" который в этой статье и описан. Только это приведет еще к тому, что надо будет мониторить этот флаг. Добавляется также проблема с тем, что если consumer вошел в блокирующее ожидание на очереди, это ожидание нужно прервать при выставлении флага.
И вишенка на торте - когда система распределенная и publisher и consumer работают в разных процессах и на разных серверах, и тогда вы с флагом вообще задолбаетесь.
Тем, что Publisher не должен знать о реализации Consumer, о том есть ли у него эта магическая переменная, о том существует ли вообще Consumer, сколько экземпляров Consumer, какая структура очереди (например либо это очередь классическая, либо множество реплик очереди каждая из которых к своему экземпляру Consumer'а).
Поэтому Publisher просто отправляет событие EOF (End-Of-File/ End-Of-Stream / End-Of-Data) и всё.
У вас мессенджер. У вас нет нужды в общем сеансовом ключе - вы можете использовать шифрование открытым ключом респондента напрямую для каждого сообщения (ибо они короткие) и/или генерировать одноразовые ключи для каждого большого сообщения. Поэтому Диффи-Хеллман вам больше не нужен.
Это мессенджер, оба клиента могут сидеть за натом, могут быть в оффлайне по очереди и так далее - поэтому никакого соединения нет. Сообщения передаются в шифрованном виде через сервер - схема того же уровня что и S/MIME.
Поэтому все что в ваших «подозрениях» касается совместной выработки сеансового ключа, сразу можно игнорировать как «неприменимо»
Сливает куда-то ОС ключи или нет - это уже не зависит от самой телеги. Ставьте на доверенное устройство. Это в общем то стандартное правило, чем выше уровень требуемой защищенности - тем шире требования к оборудованию, поэтому опять вопрос «мимо кассы»
Главный вопрос и ответ - «а нафига»? Сервис требует регистрации по номеру телефона, номер присваивается через сотового оператора, у него есть привязка номера к IMEI, к базовым станциям и т.д., поэтому телеграм неприватен изначально. Зачем вкладываться в изначально проприетарное чужое поделие?
Ну так трекеры и телеметрии сами себя не соберут, понимать надо
Если вам нужна приватность - ее должно реализовывать Е2Е шифрование. Которое, внезапно, реализуется только в клиенте с помощью ключей, хранимых сторонами обмена локально.
Поэтому, если
пара ключей генерируется на клиенте (что проверяется по коду клиента)
приватный ключ хранится на клиенте (что проверяется по коду клиента)
приватный ключ не передается никуда из клиента (что проверяется по коду клиента)
в Е2Е обмене используется переданный второй стороной (что также можно проверить в коде клиента)
То уже не важно что там на сервере, ибо сервер является той самой "третьей стороной" от которой Е2Е защищает. Это в общем то азы криптографии, которые преподают на профильных специальностях.
Единственное допустимое отступление от этих четырех правил правила - прямая передача приватного ключа между устройствами клиента минуя сервер - например через QR-код. Ну а если хоть один критерий нарушен - то ой, обмен скомпрометирован.
Да, я тоже такой хочу. В основном ради клавиатуры с тачпадом (ну вот нравится мне когда руку за мышью тянуть не надо)
Если вместо того, чтобы задрейнить ноду, вам проще ее мигрировать, то возникает предположение, что у вас что-то не так в консерватории и вы храните стейт там, где ему не место.
Насчет линуксового ядра, которое "написано в императивной парадигме" вы очень сильно ошибаетесь.
Возьмите например struct file и struct file_operations. Это как раз классический пример ООП, когда собственно struct file это объект, file.file_operations - VMT (virtual methods table), а file->file_operations->write(file, ... ) это по сути развернутый вариант file->write( ... )
Поэтому, ядро линукса это как раз хороший пример ООП, без излишних абстракций.
... о всех тех десятках CVE которые за это время накопились?
book.setAuthor(author).save()
Не надо засорять пространство имен