Они искали оптимальный вариант. В любом случае это мне выгоднее чем искать единственный офлайн магазин в ближайшем городе, где продается то что мне нужно.
Если структура перестает помещаться в контексте восприятия (это ещё до ИИ придумано было) - нужно менять структуру или подход к ней.
Перепутать единственный итератор не с чем. Перепутать два итератора сложно. Три - тоже сложновато. Больше 7, да ещё с глобальными переменными - флагами - запросто, пора пересматривать алгоритм.
Ну это из серии "если покрасить панду в черный цвет - вы ее не узнаете" - потому что вы представляете себе панду как медведя в очках, а не вот это вот.
У ИИ могут быть другие ассоциации, если знать какие - можно обмануть.
Ну я же говорил, как только государство начинает что-то регулировать - "всё должно быть пострижено, покошено, и выкрашено зелёной краской!". А паспорт у вас с собой?!
От просто "красивого домена" до самого факта что-то там создать и зарегистрировать.
Это и называется развитие. Появляется что-то новое - старое страдает.
Но почему-то меня, как покупателя тех же смартфонов, мало волнуют страдания ретейлеров, которые теперь вынуждены оглядываться на дешёвые китайские модели, вместо того чтобы по прежнему извлекать больше из того факта, что я не могу лично поехать к производителю и купить что хочу, без наценок и сборов посредников
А вот государство с регулированием как раз наоборот, заинтересовано в сборе таможенных платежей и НДС , поэтому чем дороже будет оно продаваться - тем ему выгоднее. Не мне.
Везде, где государство начинает регулировать - начинаются неудобства и растут цены. Становится нельзя больше что-то купить - потому что где-то эти продажи мешали уважаемым людям делать бизнес, и теперь конкурентов прижали. Вводятся ограничения на то и на это, традиционно - для защиты детей. Укажите ваши данные с биометрией, лицензию с сертификатом и разрешение от надзирателя, на фоне паспорта - вот это всё.
Уже баланс телефона пополнить - проблема.
На словах, конечно, всё хорошо, а на деле с ностальгией вспоминаешь времена, когда было можно.
Мини-сервер с подключенным HDD, доступным через iscsi - подключается в компьютере через сеть, но как обычный диск. Не самое простое для обычного юзера решение, чисто ради интереса сделано.
Второй мини-сервер с парой SSD, подключенных по USB через хаб с внешним питанием 5в. Диски доступны по NFS как сетевые. В теории можно их так много в USB включить, и в raid собрать в один большой. И раздать через самбу, для виндовс.
Нагрузка там не требует мощного гудящего сервера с вентиляторами, для обычного юзера мог бы быть вариант применить старый ноутбук с пассивным охлаждением, для "необычного" - самодельная коробка с малинкой или аналогами.
Берём какой-нибудь достаточно большой криптоконтейнер, в широком смысле - шифрованный файл. У него будет достаточно неплохо со "случайными данными".
А целевое сообщение вписываем в середину, также шифрованное, в места, определяемые в процессе внедрения из пароля.
Тогда внешне это выглядит как криптоконтейнер, который невозможно полностью расшифровать, так как он испорчен, но на самом деле данные в нем не там, где их будут искать...
Как доказать их наличие? Ввести заведомо верный пароль криптоконтейнера, и предположить что проблема в стеганографии, но для этого пароль надо знать, а он может быть вообще любым, так как никому не нужен.
Затем, чтобы они и локально были шифрованные, независимо от rclone. Он - транспорт, с дополнительными возможностями, он передает некие данные - вот и пусть передает. Завтра вместо Google Drive будет что-то другое, и другой транспорт окажется лучше - это не должно влиять на данные.
А готовить данные - локальная задача. Их лучше не объединять.
Уже был опыт с какой-то вот такой программой (не помню, давно было), позволяла делать шифрованные бекапы в собственное облако Убунты. Сначала попал на какой-то баг в программе (иногда не расшифровывались обратно), а потом и облако это отключили.
Ну вот смотрите, ситуация: вам надо сохранить файл "Секретный рецепт сырников.doc", 123 кбайта.
У вас три варианта: 1 - encrypt "Секретный рецепт сырников.doc" - пароль для рецептов - upload 123 кб 2 - открыть криптоконтейнер Bigfile, внести рецепт туда, закрыть - upload 2Гб 3 - открыть криптоконтейнер для рецептов на 200 Мб, увидеть что в нем не осталось места, создать второй для рецептов еще на 200 Мб, - upload 200 Мб. И еще отдельно придумать каталог, что в каком контейнере лежит, чтобы не искать по разным.
Никак. Это персональный архив, который не предполагает периодической смены паролей и перешифрования. Более того, никто не обещает что пароли на все файлы одинаковые )
Но если поставить такую задачу: требуется перешифрование, значит, пишем скрипт, проходим по файлам и перешифровываем, перезаливаем.
А как еще вы предлагаете менять ключ? Мне правда интересно. Можно перешифровать симметричный ключ, спрятанный в файле - но это всё равно обновление файлов в облаке.
И в случае криптоконтейнера с возможностью замены ключа - тоже.
Уникальность подхода в том, что для добавления новой статьи нам даже не нужна админ-панель (хотя она и есть для удобства). Достаточно просто создать новый JSON-файл
Миленниалы изобрели index.html.json )
Не обижайтесь, просто забавно как история идет по кругу. Там еще были такие SSI, это когда часть сайта - footer-header etc. - вынесены в отдельные файлы, и подключаются автоматически при рендеринге страницы...
Ну а в принципе, почему нет? JSON вместо HTML, и свой веб-сервер вместо Апача...
Они искали оптимальный вариант. В любом случае это мне выгоднее чем искать единственный офлайн магазин в ближайшем городе, где продается то что мне нужно.
Если структура перестает помещаться в контексте восприятия (это ещё до ИИ придумано было) - нужно менять структуру или подход к ней.
Перепутать единственный итератор не с чем. Перепутать два итератора сложно. Три - тоже сложновато. Больше 7, да ещё с глобальными переменными - флагами - запросто, пора пересматривать алгоритм.
Ну это из серии "если покрасить панду в черный цвет - вы ее не узнаете" - потому что вы представляете себе панду как медведя в очках, а не вот это вот.
У ИИ могут быть другие ассоциации, если знать какие - можно обмануть.
Ну я же говорил, как только государство начинает что-то регулировать - "всё должно быть пострижено, покошено, и выкрашено зелёной краской!". А паспорт у вас с собой?!
От просто "красивого домена" до самого факта что-то там создать и зарегистрировать.
Это и называется развитие. Появляется что-то новое - старое страдает.
Но почему-то меня, как покупателя тех же смартфонов, мало волнуют страдания ретейлеров, которые теперь вынуждены оглядываться на дешёвые китайские модели, вместо того чтобы по прежнему извлекать больше из того факта, что я не могу лично поехать к производителю и купить что хочу, без наценок и сборов посредников
А вот государство с регулированием как раз наоборот, заинтересовано в сборе таможенных платежей и НДС , поэтому чем дороже будет оно продаваться - тем ему выгоднее. Не мне.
Не знаю кто это был, но несомненно примат
Везде, где государство начинает регулировать - начинаются неудобства и растут цены.
Становится нельзя больше что-то купить - потому что где-то эти продажи мешали уважаемым людям делать бизнес, и теперь конкурентов прижали.
Вводятся ограничения на то и на это, традиционно - для защиты детей.
Укажите ваши данные с биометрией, лицензию с сертификатом и разрешение от надзирателя, на фоне паспорта - вот это всё.
Уже баланс телефона пополнить - проблема.
На словах, конечно, всё хорошо, а на деле с ностальгией вспоминаешь времена, когда было можно.
Использую свой вариант NAS, точнее даже два:
Мини-сервер с подключенным HDD, доступным через iscsi - подключается в компьютере через сеть, но как обычный диск. Не самое простое для обычного юзера решение, чисто ради интереса сделано.
Второй мини-сервер с парой SSD, подключенных по USB через хаб с внешним питанием 5в. Диски доступны по NFS как сетевые. В теории можно их так много в USB включить, и в raid собрать в один большой. И раздать через самбу, для виндовс.
Нагрузка там не требует мощного гудящего сервера с вентиляторами, для обычного юзера мог бы быть вариант применить старый ноутбук с пассивным охлаждением, для "необычного" - самодельная коробка с малинкой или аналогами.
Вспомнился древний анекдот про "японскую лесопилку": - ага! - сказали мужики и сунули в нее лом...
Как бы отучить людей поддаваться на манипуляции...
Берём какой-нибудь достаточно большой криптоконтейнер, в широком смысле - шифрованный файл. У него будет достаточно неплохо со "случайными данными".
А целевое сообщение вписываем в середину, также шифрованное, в места, определяемые в процессе внедрения из пароля.
Тогда внешне это выглядит как криптоконтейнер, который невозможно полностью расшифровать, так как он испорчен, но на самом деле данные в нем не там, где их будут искать...
Как доказать их наличие? Ввести заведомо верный пароль криптоконтейнера, и предположить что проблема в стеганографии, но для этого пароль надо знать, а он может быть вообще любым, так как никому не нужен.
Почему-то хочется увидеть это не в виде смартфона, а в виде мини-пк с линуксом на борту...
Ну, технически это несложно. Пишем скрипт, который считывает JSON, добавляет поле, сохраняет обратно, и так по группе файлов.
Та же CMS, только оффлайн и возможно оффсайт. Попробуй сломай такое...
Linux/Unix - это и есть куча велосипедов, где одни и те же задачи можно решить разными инструментами и разными способами )
Технически - очень интересно, не технически - ну, хм, "определяем VPN-трафик", "блокируем запрещенные сайты", "идентификация человека по походке"...
Так-то тоже интересные технические задачи...
Затем, чтобы они и локально были шифрованные, независимо от rclone.
Он - транспорт, с дополнительными возможностями, он передает некие данные - вот и пусть передает. Завтра вместо Google Drive будет что-то другое, и другой транспорт окажется лучше - это не должно влиять на данные.
А готовить данные - локальная задача. Их лучше не объединять.
Уже был опыт с какой-то вот такой программой (не помню, давно было), позволяла делать шифрованные бекапы в собственное облако Убунты.
Сначала попал на какой-то баг в программе (иногда не расшифровывались обратно), а потом и облако это отключили.
Ну вот смотрите, ситуация: вам надо сохранить файл "Секретный рецепт сырников.doc", 123 кбайта.
У вас три варианта:
1 - encrypt "Секретный рецепт сырников.doc" - пароль для рецептов - upload 123 кб
2 - открыть криптоконтейнер Bigfile, внести рецепт туда, закрыть - upload 2Гб
3 - открыть криптоконтейнер для рецептов на 200 Мб, увидеть что в нем не осталось места, создать второй для рецептов еще на 200 Мб, - upload 200 Мб. И еще отдельно придумать каталог, что в каком контейнере лежит, чтобы не искать по разным.
Как-то так.
Никак. Это персональный архив, который не предполагает периодической смены паролей и перешифрования. Более того, никто не обещает что пароли на все файлы одинаковые )
Но если поставить такую задачу: требуется перешифрование, значит, пишем скрипт, проходим по файлам и перешифровываем, перезаливаем.
А как еще вы предлагаете менять ключ? Мне правда интересно. Можно перешифровать симметричный ключ, спрятанный в файле - но это всё равно обновление файлов в облаке.
И в случае криптоконтейнера с возможностью замены ключа - тоже.
Миленниалы изобрели index
.html.json )Не обижайтесь, просто забавно как история идет по кругу.
Там еще были такие SSI, это когда часть сайта - footer-header etc. - вынесены в отдельные файлы, и подключаются автоматически при рендеринге страницы...
Ну а в принципе, почему нет? JSON вместо HTML, и свой веб-сервер вместо Апача...
И потом иконку "это наш компьютер!“ на рабочий стол.