Дальше Вас уже не остановить: "Не существует алгоритма, который сжимает любые данные."
Теперь Ваша очередь доказать свои слова, я же напротив - показал обратное.
Нет, не показали. Более того, вы сами и в статье указали, что есть теоретический предел сжатия. То есть никакие данные сжать дальше предела не получится. Ниже в комментариях вы ещё раз явно это указываете: https://habr.com/ru/articles/825536/comments/#comment_26987138
Этот портал для людей думающих, а не для выражения своих голых негативных эмоций, если кто-то что-то не понял. Вы кинули какое-то доказательство не подумавши. В нем формула, выраженная "2 в степени n". А это характеристика позиционных систем счисления, а не суперпозиционных.
Всё правильно. Формула 2^n применима как раз для двоичной системы счисления, которая является и исходной для кодирования сжимаемой информации, и целевой. Опять таки, цитируя вашу статью, «так как он в ЭВМ будет записан в бинарной системе».
Это означает, что после работы вашего алгоритма получится двоичная последовательность, которая, скорее всего, уже не подвергнется сжатию повторно. То есть на выходе получится последовательность не короче получившейся на первом шаге. Именно об этом теорема и её доказательство, поскольку любой алгоритм сжатия без потерь даёт ваимно однозначное соответствие между двоичными последовательностями.
А это не сайт определяет железо, а браузер Хром передаёт в Гугл сведения о системе. Если пользоваться другим браузером, то в предупреждении о подозрительном входе будет показываться только user agent.
Фингерпринтинг в браузере обычно отслеживает не уникальные особенности железа (скрипт вряд ли до низкого уровня доберётся), а программную среду: браузер, операционную систему, системное время, часовой пояс и так далее. Но тут есть нюанс, что если какое-либо расширение пытается заблокировать фингерпринтинг по какому-либо параметру, то обнаружение этой блокировки — само по себе маркер пользователя, потому что такими расширениями пользуются единицы.
И что же делать разработчикам стандартной библиотеки, которые заранее не знают, в консоли, в иксах, вейланде или условном фрейбуфере будет запускаться приложение? Кроме того, в системах может быть ещё и разнообразие устройств и интерфейсов ввода, это тоже заранее нельзя учесть.
В стандартной библиотеке даже поддержки сети нет, а это унифицировать значительно проще.
Просто для части аудитории "вы" строчными буквами будет восприниматься чуть ли не как оскорбление, а потому, по теории игр, меньшим из зол будет ярлык "странного".
На самсунге кстати работает: по зажатию центральной кнопки появляется ассистент, но нужно не отпуская палец протянуть вверх — тогда Lens сразу начинает работать по текущему экрану.
Вероятно, это можно было бы реализовать дублированием ключа между клиентами. Либо использованием отдельных ключей для каждого клиента, но тогда нужно было бы внедрить протокол секретного многопользовательского чата.
И где ссылка на issue?
Вот нашёл удалённые статьи:
https://archive.ph/2015.04.03-101515/http://habrahabr.ru/post/254809/
https://sohabr.net/habr/post/344754/
Так показали бы хотя бы на примере 64-битной последовательности. Теоретически должно 63 бита как раз получиться.
Всё по классике гениальных алгоритмов, которые уже не единожды были тут на Хабре:
Нет, не показали. Более того, вы сами и в статье указали, что есть теоретический предел сжатия. То есть никакие данные сжать дальше предела не получится. Ниже в комментариях вы ещё раз явно это указываете: https://habr.com/ru/articles/825536/comments/#comment_26987138
Всё правильно. Формула 2^n применима как раз для двоичной системы счисления, которая является и исходной для кодирования сжимаемой информации, и целевой. Опять таки, цитируя вашу статью, «так как он в ЭВМ будет записан в бинарной системе».
Это означает, что после работы вашего алгоритма получится двоичная последовательность, которая, скорее всего, уже не подвергнется сжатию повторно. То есть на выходе получится последовательность не короче получившейся на первом шаге. Именно об этом теорема и её доказательство, поскольку любой алгоритм сжатия без потерь даёт ваимно однозначное соответствие между двоичными последовательностями.
Только не в России же, а в Польше: https://en.wikipedia.org/wiki/Asymmetric_numeral_systems
А это не сайт определяет железо, а браузер Хром передаёт в Гугл сведения о системе. Если пользоваться другим браузером, то в предупреждении о подозрительном входе будет показываться только user agent.
Фингерпринтинг в браузере обычно отслеживает не уникальные особенности железа (скрипт вряд ли до низкого уровня доберётся), а программную среду: браузер, операционную систему, системное время, часовой пояс и так далее. Но тут есть нюанс, что если какое-либо расширение пытается заблокировать фингерпринтинг по какому-либо параметру, то обнаружение этой блокировки — само по себе маркер пользователя, потому что такими расширениями пользуются единицы.
Для начала давайте разберёмся как вообще сайт может определить материнку. У вас есть образец такого сайта или скрипта?
И что же делать разработчикам стандартной библиотеки, которые заранее не знают, в консоли, в иксах, вейланде или условном фрейбуфере будет запускаться приложение? Кроме того, в системах может быть ещё и разнообразие устройств и интерфейсов ввода, это тоже заранее нельзя учесть.
В стандартной библиотеке даже поддержки сети нет, а это унифицировать значительно проще.
А на системах с голой консолью или в эмбеддеде как оно будет работать?
Просто для части аудитории "вы" строчными буквами будет восприниматься чуть ли не как оскорбление, а потому, по теории игр, меньшим из зол будет ярлык "странного".
А как сделать универсальный GUI API для любой системы, в которой доступен компилятор?
На самсунге кстати работает: по зажатию центральной кнопки появляется ассистент, но нужно не отпуская палец протянуть вверх — тогда Lens сразу начинает работать по текущему экрану.
там ещё важная деталь: я прочитал несколько книжек на английском, теперь я знаю английский и буду учить вас — пройдите в тг
оперировать :)
А почему за миллион пользователей только миллион дают, а не три?
Не знаю как на iOS, но на Андроиде этот бекап крайне нестабильно и ненадёжно работает.
Кстати да, больше разработчиков — больше вероятность вербовки кого-либо из них.
Вероятно, это можно было бы реализовать дублированием ключа между клиентами. Либо использованием отдельных ключей для каждого клиента, но тогда нужно было бы внедрить протокол секретного многопользовательского чата.