Как минимум в названии статьи я бы развернул CRM как Crew resource management, потому что в бизнесе уже известна аббериатура CRM, которая означает Customer relationship management.
Это не дефолтное поведение. По дефолту транкейт не удаляет ничего в связанных таблицах.
Ирония ещё и в том, что и PostgreSQL, и MySQL, и MariaDB, и MS SQL Server, и (вероятно) даже SQLite не могут транкейтить таблицы, на которые через внешние ключи ссылаются другие таблицы. При этом, похоже, только у постгреса есть опция каскадного транкейта. Ей-то они и воспользовались.
Судя по всему, они столкнулись с багом транкейта для постгреса, но не проанализировали, что аналогичное может случиться и с другими СУБД. По-хорошему, им нужно было бы сделать дополнительную опцию truncate, а при отсутствии поддержки или эмулировать каскадный транкейт, или выбрасывать ошибку. То решение, которое они приняли — самое опасное и архитектурно непродуманное, но и самое лёгкое.
сделать IDE для веб-интерфейса для возможности встраивания в Azure DevOps и подобные сервисы.
Если первое теоретически можно было реализовать на Qt, то для встраивания в веб придётся в любом случае использовать веб-технологии. Побочным эффектом стала лёгкая расширяемость, из-за чего VSCode быстро захватила большую долю рынка.
Дальше Вас уже не остановить: "Не существует алгоритма, который сжимает любые данные."
Теперь Ваша очередь доказать свои слова, я же напротив - показал обратное.
Нет, не показали. Более того, вы сами и в статье указали, что есть теоретический предел сжатия. То есть никакие данные сжать дальше предела не получится. Ниже в комментариях вы ещё раз явно это указываете: https://habr.com/ru/articles/825536/comments/#comment_26987138
Этот портал для людей думающих, а не для выражения своих голых негативных эмоций, если кто-то что-то не понял. Вы кинули какое-то доказательство не подумавши. В нем формула, выраженная "2 в степени n". А это характеристика позиционных систем счисления, а не суперпозиционных.
Всё правильно. Формула 2^n применима как раз для двоичной системы счисления, которая является и исходной для кодирования сжимаемой информации, и целевой. Опять таки, цитируя вашу статью, «так как он в ЭВМ будет записан в бинарной системе».
Это означает, что после работы вашего алгоритма получится двоичная последовательность, которая, скорее всего, уже не подвергнется сжатию повторно. То есть на выходе получится последовательность не короче получившейся на первом шаге. Именно об этом теорема и её доказательство, поскольку любой алгоритм сжатия без потерь даёт ваимно однозначное соответствие между двоичными последовательностями.
А это не сайт определяет железо, а браузер Хром передаёт в Гугл сведения о системе. Если пользоваться другим браузером, то в предупреждении о подозрительном входе будет показываться только user agent.
Фингерпринтинг в браузере обычно отслеживает не уникальные особенности железа (скрипт вряд ли до низкого уровня доберётся), а программную среду: браузер, операционную систему, системное время, часовой пояс и так далее. Но тут есть нюанс, что если какое-либо расширение пытается заблокировать фингерпринтинг по какому-либо параметру, то обнаружение этой блокировки — само по себе маркер пользователя, потому что такими расширениями пользуются единицы.
И что же делать разработчикам стандартной библиотеки, которые заранее не знают, в консоли, в иксах, вейланде или условном фрейбуфере будет запускаться приложение? Кроме того, в системах может быть ещё и разнообразие устройств и интерфейсов ввода, это тоже заранее нельзя учесть.
В стандартной библиотеке даже поддержки сети нет, а это унифицировать значительно проще.
Просто для части аудитории "вы" строчными буквами будет восприниматься чуть ли не как оскорбление, а потому, по теории игр, меньшим из зол будет ярлык "странного".
У этого решения проблема с accessibility.
Как минимум в названии статьи я бы развернул CRM как Crew resource management, потому что в бизнесе уже известна аббериатура CRM, которая означает Customer relationship management.
Ирония ещё и в том, что и PostgreSQL, и MySQL, и MariaDB, и MS SQL Server, и (вероятно) даже SQLite не могут транкейтить таблицы, на которые через внешние ключи ссылаются другие таблицы. При этом, похоже, только у постгреса есть опция каскадного транкейта. Ей-то они и воспользовались.
Судя по всему, они столкнулись с багом транкейта для постгреса, но не проанализировали, что аналогичное может случиться и с другими СУБД. По-хорошему, им нужно было бы сделать дополнительную опцию
truncate, а при отсутствии поддержки или эмулировать каскадный транкейт, или выбрасывать ошибку. То решение, которое они приняли — самое опасное и архитектурно непродуманное, но и самое лёгкое.VSCode написали на Электроне в двух целях:
сделать кросс-платформенное приложение;
сделать IDE для веб-интерфейса для возможности встраивания в Azure DevOps и подобные сервисы.
Если первое теоретически можно было реализовать на Qt, то для встраивания в веб придётся в любом случае использовать веб-технологии. Побочным эффектом стала лёгкая расширяемость, из-за чего VSCode быстро захватила большую долю рынка.
Так это даже не в БД настройка, а явный SQL, порождаемый ларавелевским ORM. То есть переопределение дефолта, к сожалению, не спасло бы.
Making developers happy
truncate здорового человека:
https://github.com/illuminate/database/blob/master/Query/Grammars/Grammar.php#L1397
truncate курильщика:
https://github.com/illuminate/database/blob/master/Query/Grammars/PostgresGrammar.php#L631
Зато всё по науке — переопределение базового метода в наследнике :)
Это что-то не то
И где ссылка на 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.
Фингерпринтинг в браузере обычно отслеживает не уникальные особенности железа (скрипт вряд ли до низкого уровня доберётся), а программную среду: браузер, операционную систему, системное время, часовой пояс и так далее. Но тут есть нюанс, что если какое-либо расширение пытается заблокировать фингерпринтинг по какому-либо параметру, то обнаружение этой блокировки — само по себе маркер пользователя, потому что такими расширениями пользуются единицы.
Для начала давайте разберёмся как вообще сайт может определить материнку. У вас есть образец такого сайта или скрипта?
И что же делать разработчикам стандартной библиотеки, которые заранее не знают, в консоли, в иксах, вейланде или условном фрейбуфере будет запускаться приложение? Кроме того, в системах может быть ещё и разнообразие устройств и интерфейсов ввода, это тоже заранее нельзя учесть.
В стандартной библиотеке даже поддержки сети нет, а это унифицировать значительно проще.
А на системах с голой консолью или в эмбеддеде как оно будет работать?
Просто для части аудитории "вы" строчными буквами будет восприниматься чуть ли не как оскорбление, а потому, по теории игр, меньшим из зол будет ярлык "странного".