Чтобы можно было менять пароль, не перешифровывая все данные. Паролем шифруется ключ, ключом шифруются данные. При смене пароля перешифровываем только ключ. В luks так, например.
При этом интересно, что европейский испанский пошел по "обратному" пути — почти везде tu, почти нигде usted/ustedes.
Например, на сайте DHL везде обращаются на Sie. Сложно представить, чтобы там было написано du/dich/deine. А на сайте испанской почты (correos.es) — везде обращение на "ты" (sigue tu envio, quieres hacer un envio)
Проблема совершенно точно внутри самого ПО Logitech, потому что оно по-прежнему запускается, но зависает. Возможно, что у них есть какие-то дополнительные проверки своих компонентов или обновлений, которые реализованы некорректно и ломаются, когда сертификат истек.
Имеется в виду, две строки с одинаковым начертанием? В юникоде ровно точно такая же проблема присутствует (лат. С и кир. C). Я эту проблему не пытаюсь решить.
Символы — это не начертание. Один символ может иметь разные начертания, и наоборот, какие-то начертания разных символов могут быть похожи.
Так же, как не стоит смешивать символы и текст, также не стоит смешивать и символы с их начертанием.
Конкретно здесь имеются в виду строки с одними и теми же символами, например:
строка "hotel" с английским языком и слово "hotel" с французским языком,
некая строка с указанным языком и та же строка без указания языка.
А раз уж они начали отличать латинскую C и кириллическую, то что нам мешает отличать немецкую и французскую?
Не смешивайте символ и его визуальное представление — часть вопросов отпадет.
В чём проблема-то?
Один написал "привет" с русской раскладкой, другой с беларусской, третий вставил из веб-страницы — и у вас три одинаковых по символам строки, которые при сравнении дают false.
Например, для Rust нет раскладки клавиатуры. То есть, вы неявно добавили к нашему вопросу еще и некое соответствие между языком и раскладкой клавиатуры, которое, вообще говоря, не один-к-одному, и не всегда имеется.
Но нам ничего не мешает приписать им и какой-то произвольный язык...
А потом, внезапно, две строки с одинаковым текстом у вас оказываются не равны.
Вы обошли ключевое понятие — уровни абстракции.
Самый низкий: массив байтов. Он может обозначать символы, может бинарные данные. На этом уровне намеренно не задается семантика хранимых значений.
Более высокий: набор символов. Один и тот же символ ("ъ") может использоваться в разных языках, может вне языка, может хоть в роли части орнамента. На этом уровне намеренно не затрагиваются такие понятия как слово, текст, язык. Unicode задает только набор символов.
Еще более высокий — состоящий из символов текст, по отношению к нему уже можно применить понятия язык и слово.
Из того, что unicode является только набором символов, и намеренно создан, чтобы работать именно на этом уровне, не затрагивая другие, следует то, что он не определяет и не должен определять, как интерпретировать эти символы в тексте.
Давайте представим, что у нас уровни 2 и 3 смешались.
Вот текст:
fn main() {
println!("Привет!");
}
На каком он языке? Может показаться, что на английском, но нет, в английском нет таких знаков препинания и слова fn.
Ок, припишем ему язык Rust, как есть. И вдруг возникает куча вопросов:
Слово "привет" — это еще Rust или уже русский язык? Или надо приписать ему два кода языка?
А это точно русский, может быть другой славянский язык?
А кавычки — это русский язык или Rust?
А как терминал должен работать при выводе текстов на разных языках?
А как в текстовом редакторе отметить, что это русский язык?
И как вообще программы должны отображать, на каком языке написан фрагмент текста, и зачем им нужно это делать?
А если человек в мессенджере ввел "Привет", и мы получили это в нашей программе через API, то это на каком языке? А если он в следующим сообщением в этом же мессенджере отправил "добры дзень", то это на каком?
Все эти вопросы — следствие того, что мы попытались применить параметры, свойственные тексту, к уровню символов, где они неприменимы, и где нам даже неоткуда значения этих параметров получить.
Строка символов — это более низкий уровень абстракции, чем текст. Текст может быть репрезентирован в виде строки символов, но строка символов не обязательно представляет собой текст, например, это может быть произвольный набор букв или ASCII art. У текста же есть язык, грамматика, смысл, авторские права и еще множество вещей, которые относятся к тексту, но не относятся к произвольной строке символов.
Но у юникода нет такой задачи, и не очень понятно, почему она должна быть. В своем же ПО вы всегда можете иметь структуру данных, где у вас есть и строка, и любые метаданные.
А пользователь это решение на каком основании примет, если у него нет способа проверить подлинность файла?
Я же именно об этом и написал
Не понял про 30к. У Apple они бесплатные при наличии аккаунта разраба за 99 $/€ в год.
Просто откройте его в vs code, и синтаксис будет проверяться автоматически. Используйте с современными подходами современные инструменты :)
Потому что это какой-никакой механизм доверия.
В 2026 году ПО не должно распространяться по каналам, не имеющим такого механизма.
Да, это другой признак.
Вы пишете:
Это неверно. Для установки стороннего софта не надо отключать защиты
Так вы говорите не о стороннем софте, а о неподписанном. Подписанный сертификатом разработчика сторонний софт ставится беспрепятственно.
Тогда ему стоит устроиться на работу и купить, наконец, нормальный комп
Чтобы можно было менять пароль, не перешифровывая все данные. Паролем шифруется ключ, ключом шифруются данные. При смене пароля перешифровываем только ключ. В luks так, например.
При этом интересно, что европейский испанский пошел по "обратному" пути — почти везде tu, почти нигде usted/ustedes.
Например, на сайте DHL везде обращаются на Sie. Сложно представить, чтобы там было написано du/dich/deine. А на сайте испанской почты (correos.es) — везде обращение на "ты" (sigue tu envio, quieres hacer un envio)
Много всего делается и через option, также option работает как altgr, а ctrl нужен в терминале.
что?
Было бы очень интересно!
Работа лингвистов похожа на магию!
Удивительно, как вообще удалось что-то понять про фонетику, имея только образцы письменности?
Проблема совершенно точно внутри самого ПО Logitech, потому что оно по-прежнему запускается, но зависает. Возможно, что у них есть какие-то дополнительные проверки своих компонентов или обновлений, которые реализованы некорректно и ломаются, когда сертификат истек.
И супердревняя уязвимость в SMBv1.
Символы — это не начертание. Один символ может иметь разные начертания, и наоборот, какие-то начертания разных символов могут быть похожи.
Так же, как не стоит смешивать символы и текст, также не стоит смешивать и символы с их начертанием.
Конкретно здесь имеются в виду строки с одними и теми же символами, например:
строка "hotel" с английским языком и слово "hotel" с французским языком,
некая строка с указанным языком и та же строка без указания языка.
Не смешивайте символ и его визуальное представление — часть вопросов отпадет.
Один написал "привет" с русской раскладкой, другой с беларусской, третий вставил из веб-страницы — и у вас три одинаковых по символам строки, которые при сравнении дают false.
Например, для Rust нет раскладки клавиатуры. То есть, вы неявно добавили к нашему вопросу еще и некое соответствие между языком и раскладкой клавиатуры, которое, вообще говоря, не один-к-одному, и не всегда имеется.
А потом, внезапно, две строки с одинаковым текстом у вас оказываются не равны.
Вы обошли ключевое понятие — уровни абстракции.
Самый низкий: массив байтов. Он может обозначать символы, может бинарные данные. На этом уровне намеренно не задается семантика хранимых значений.
Более высокий: набор символов. Один и тот же символ ("ъ") может использоваться в разных языках, может вне языка, может хоть в роли части орнамента. На этом уровне намеренно не затрагиваются такие понятия как слово, текст, язык. Unicode задает только набор символов.
Еще более высокий — состоящий из символов текст, по отношению к нему уже можно применить понятия язык и слово.
Из того, что unicode является только набором символов, и намеренно создан, чтобы работать именно на этом уровне, не затрагивая другие, следует то, что он не определяет и не должен определять, как интерпретировать эти символы в тексте.
Давайте представим, что у нас уровни 2 и 3 смешались.
Вот текст:
На каком он языке? Может показаться, что на английском, но нет, в английском нет таких знаков препинания и слова fn.
Ок, припишем ему язык Rust, как есть. И вдруг возникает куча вопросов:
Слово "привет" — это еще Rust или уже русский язык? Или надо приписать ему два кода языка?
А это точно русский, может быть другой славянский язык?
А кавычки — это русский язык или Rust?
А как терминал должен работать при выводе текстов на разных языках?
А как в текстовом редакторе отметить, что это русский язык?
И как вообще программы должны отображать, на каком языке написан фрагмент текста, и зачем им нужно это делать?
А если человек в мессенджере ввел "Привет", и мы получили это в нашей программе через API, то это на каком языке? А если он в следующим сообщением в этом же мессенджере отправил "добры дзень", то это на каком?
Все эти вопросы — следствие того, что мы попытались применить параметры, свойственные тексту, к уровню символов, где они неприменимы, и где нам даже неоткуда значения этих параметров получить.
Строка символов — это более низкий уровень абстракции, чем текст. Текст может быть репрезентирован в виде строки символов, но строка символов не обязательно представляет собой текст, например, это может быть произвольный набор букв или ASCII art. У текста же есть язык, грамматика, смысл, авторские права и еще множество вещей, которые относятся к тексту, но не относятся к произвольной строке символов.
Но у юникода нет такой задачи, и не очень понятно, почему она должна быть. В своем же ПО вы всегда можете иметь структуру данных, где у вас есть и строка, и любые метаданные.