Это стандартный прием — достаточно просто подставить ее на сайт посещаемый как капчу или ее часть. Пользователь введет капчу — вот и картинка расшифрована.
Авторизация через сторонние сайты — далеко не всегда применимый способ. Например, в той же авторизации через фейсбук иногда хотят слишком много прав, которые неясно для чего нужны. Давать эти права не хотелось бы. Поэтому, часто я отказываюсь авторизоваться через фб.
И так уже многим лень регистрировать аккаунты, а со сложными капчами этот процесс вообще превращается в ад. Пора уже придумать что-нибудь принципиально другое, что-то на замену капчи.
Настоящий прорыв будет, когда цена альтернативной энергии станет неособо выше цены традиционной.
Пока это все годится как решения для дачи, где традиционной энергетики просто нет и не предвидется.
У меня следующий вопрос. Вот поставили на крышу дома такую панель. Как она переносит град? Обледенение?
Этот аппарат не подключен напрямую к интернету, т.е. загрузить в него деструктивный код, запрограммированный гораздо позже производства этого аппарата — малореально. А запрограммировать все заранее, предугадав ситуации на все случаи жизни тоже нельзя. Загрузите деструктивный код в устройство, произведенное 30 лет назад, например в «игру на экране» где волк ловит яйца или расстреливает уток. Вы не найдете ни среды ни документации. А если найдете, вам понадобится вникать в нее месяц и еще месяц писать этот деструктивный код, тогда как такие решения, как отключение, должны приниматься и исполняться оперативно. И кроме того, для аппарата терапии это малоэффективно — несколько пациентов он угробит, потом его снимут с эксплуатации.
Единственно более-менее реализуемое технически решение — это блокировка использования. Это то, что можно заложить в программу и то, что можно заложить в некоторые сложные системы.
Загружать заведомо деструктивную программу в такие аппараты терапии вряд ли будут, а вот закрыть доступ к базе — вполне реально могут. Например, станки с привязкой к местности — не выдумка.
И такой подход вполне закономерен и логичен. Хочешь чтобы все было подконтрольно только тебе — пожалуйста — нанимай специалистов, трать 30 лет на разработки и делай свою систему так как хочешь. Пользуешься чужой — уважай чужой труд, давший работу.
Захватом изображения с камеры никого сейчас не удивишь, и не удивишь функциями статистической обработки. Основное отличие, насколько я понял, — это крупнейшая база знаний, с которой это язык может работать из коробки. Плюс экспертная система, которая правильно (автоматически или с минимальным вмешательством программиста) эти знания связывает друг с другом. Вот это действительно магия.
Сейчас больше всего интересно, есть ли возможность хранить на своих серверах нужные мне знания, и насколько сложно их модифицировать. Хранить в облаке конечно хорошо — но не всегда выход.
Интересно было бы нагрузить систему какой-нибудь реальной задачей и сравнить с решением этой задачи на других системах. Обычно как только дело доходит до реальных задач — от многих специализированных программ приходится отказываться, не подходят по той или иной причине.
Такой велосипед делался на той же технологии, на которой сделана основная часть софта. Дабы не устраивать холивар — не говорю на какой.
А буст — монтруозная либа. Даже если проект плюсовый, все равно ее тяжело тащить с проектом, неудобно компилить под разные платформы, дорого поддерживать. Как то раз мы в один проект интегрировали буст, поподдерживали, а потом его оттуда радостно убирали. Впечатления от него остались плохие.
RRDtool кроме описаного, имеет еще 1 большой недостаток — он не позволяет, хранить данные, которые приходят чаще, чем раз в секунду. Он «под капотом» оперирует time_t, 32-битным. Этим недостатком, так же, обладает jRobin. Как-то раз понадобилось логгировать сотни датчиков, выдающих 20отсчетов/сек на датчик. В итоге пришлось делать свой велосипед, т.к. ни одно нагуглевшееся стандартное решение не подошло.
Проверял на некотором количестве небольших фраз. Для фраз более длинных (там где алгоритм sha256 будет делать больше 1 раза update, это, насколько помню, длиней 56 байт) код, вероятно, потребует доработки. Это просто в той версии, что на гитхабе, в коде явно прописана фраза про лисицу и нахождение первой буквы. Т.е, фразу можно изменить и кол-во неизвестных бит можно несильно(пока озу будет достаточно) увеличить, так же можно изменить позицию неизвестных бит, т.е. буква может быть и не первой. Все это не должно сломать работоспособность кода. Для всего этого, ясно дело, придется подредактировать исходник. Поэтому проще всего изменить фразу, остальное тоже делается, но чуть сложней. Хуже будет если мы нарвемся на коллизию (когда найдено будет несколько прообразов). Мой код этого не учитывает и может сглючить, так что там его надо «доработать напильником» для обработки такого случая (этот момент — абсолютно технический, и в нем нет ничего исследовательского). Я исхожу из того, что коллизии — не такое частое явление, чтобы на данном этапе брать их в учет.
А у меня одно регулярное выражение покрывает группу значений. Иногда — очень большую группу. Например, 128 звездочек это, в рамках моих соглашений, Set из 2^128 элементов, записаный одной строкой в 128 символов.
По этой причине явного перебора нет, и мне видится невозможным влоб посчитать эти ксоры и судить по ним о обьеме работ. Это уже посфактум так рассуждать можно.
Это уже лучше. Теперь ответтье на следующий вопрос. Что если степень провальности способа становится окончательно известной только после окончательного выведения этого способа?
Применительно к данному способу. На начальном этапе была идея комбинировать списки, и была идея группы результатов представлять звездочками. Была мысль, что размер списков получится велик, но оценить насколько велик я не мог. Почему не мог — у меня одно регулярное выражение представляет целую группу значений, величина которой может быть огромной. Была так же некоторая изначально малореальная надежда, что при комбинированнии списков, приходящих от разных ветвей, их размер будет минимизироваться (оправдалось частично). Но насколько сильно минимизироваться — я тоже оценить не мог. Ну и кроме того, просто хотелось проверить идею.
И поэтому я пришел к выводу, что это как раз тот случай, когда мне, чтобы оценить размер, проще это сделать и напрямую посмотреть какой вышел размер, чем пытаться математически его вывести.
Таким образом, это способ — провальный постфактум, а не «заведомо». Заведомо он был предполжительно провальным.
Ну, я знаю. Приведенное решение — далеко не первая попытка, но первая в которой хоть что-то вышло. Одной из первых попыток было засунуть sha256 в карту Карно. Но там даже до проб не дошло, т.к. очень быстро стало ясно, что вот так просто это сделать не получится.
Что именно? И почему вы решили, что я этого не сделал? Если вы о том, что в биткоине используется двойной sha256, то я это знаю. Но особой разницы нет — тем же способом можно взять двойной, теоретически. Если вы про вычислительную сложность — это тоже мне было известно, но я решил, что то, что проведение полномаштабного эксперимента технически невозможно — это не причина не проводить мелкий эксперимент.
Пока это все годится как решения для дачи, где традиционной энергетики просто нет и не предвидется.
У меня следующий вопрос. Вот поставили на крышу дома такую панель. Как она переносит град? Обледенение?
Единственно более-менее реализуемое технически решение — это блокировка использования. Это то, что можно заложить в программу и то, что можно заложить в некоторые сложные системы.
И такой подход вполне закономерен и логичен. Хочешь чтобы все было подконтрольно только тебе — пожалуйста — нанимай специалистов, трать 30 лет на разработки и делай свою систему так как хочешь. Пользуешься чужой — уважай чужой труд, давший работу.
Сейчас больше всего интересно, есть ли возможность хранить на своих серверах нужные мне знания, и насколько сложно их модифицировать. Хранить в облаке конечно хорошо — но не всегда выход.
Интересно было бы нагрузить систему какой-нибудь реальной задачей и сравнить с решением этой задачи на других системах. Обычно как только дело доходит до реальных задач — от многих специализированных программ приходится отказываться, не подходят по той или иной причине.
А буст — монтруозная либа. Даже если проект плюсовый, все равно ее тяжело тащить с проектом, неудобно компилить под разные платформы, дорого поддерживать. Как то раз мы в один проект интегрировали буст, поподдерживали, а потом его оттуда радостно убирали. Впечатления от него остались плохие.
По этой причине явного перебора нет, и мне видится невозможным влоб посчитать эти ксоры и судить по ним о обьеме работ. Это уже посфактум так рассуждать можно.
Применительно к данному способу. На начальном этапе была идея комбинировать списки, и была идея группы результатов представлять звездочками. Была мысль, что размер списков получится велик, но оценить насколько велик я не мог. Почему не мог — у меня одно регулярное выражение представляет целую группу значений, величина которой может быть огромной. Была так же некоторая изначально малореальная надежда, что при комбинированнии списков, приходящих от разных ветвей, их размер будет минимизироваться (оправдалось частично). Но насколько сильно минимизироваться — я тоже оценить не мог. Ну и кроме того, просто хотелось проверить идею.
И поэтому я пришел к выводу, что это как раз тот случай, когда мне, чтобы оценить размер, проще это сделать и напрямую посмотреть какой вышел размер, чем пытаться математически его вывести.
Таким образом, это способ — провальный постфактум, а не «заведомо». Заведомо он был предполжительно провальным.