Как-то никто не смог объяснить как RMS мешает "покосу бабла" :)
А исчезновение GNU видимо и так произойдет, просто ввиду не релевантности оного. Можно долго спорить, виноват ли в этом лично RMS, напоминающий "Федорино горе" в последнее время или просто звёзды так сложились. Но GNU compiler практически везде вытеснен LLVM и отстаёт по всем фронтам все дальше и дальше. Остались core utils, посмотрим приживется ли мозилловский вариант на Rust, он безопаснее и быстрее. Что там ещё от GNU останется?
Придется RMS вспомнить про GNU/Hurd, правда какие шансы, если за 20 лет ничего не вышло?
На странице FSFE у RedHat нет даже звёздочки, то есть меньше 10% бюджета. Наряду с Luca Bonissi, отсудившим у Леново 20 тысяч и передавшим из них кажется 15к в FSFE. Вот такая очень влиятельная организация, просто завалившая всех баблом и заставившая плясать под свою дудку. Но да, если обвинить всех остальных в заговоре, на пути которого стоит один RMS как Д'Артаньян, то получается вполне стройная картина всемирного заговора :)
То есть все аргументы за сводятся к "RMS лучше Гитлера"? Я под этим тоже подпишусь, но к счастью для free software этого маловато нынче для лидера.
А про Red Hat — повторяю, они не делают ничего, что не сделали до них десятки независимых от RMS организаций и фондов, даже FSF Europe. Фокусирование на вынужденном акте RH, а не проблеме RMS, это как раз оппортунизм и перевод стрелок.
Вынесение компании (red hat) в заголовок статьи тоже "интересное решение". В реальности за удаление Столлмана выступают множество организаций open source & free software. Да и часть директоров самого FSF. Сложнее найти кто за него. Не знаю уж какие у них у всех корыстные интересы :). Избегая теорий заговора, что все коррумпированные оппортунисты, и один RMS Д'Артаньян, думаю правильнее более простое объяснение — устав пытаться исправить RMS, решили что дальше продуктивнее будет без него.
удобный, выгодный — политика соглашательства, ухода от резкого противостояния, конфронтации, конформизм. Принесение в жертву принципиальных требований ради удовлетворения второстепенных.
Противников Сталлмана в таком упрекнуть сложно. У них как раз есть принципы, от которых они не отходят, не взирая на лица.
Как сторонний наблюдатель, для меня "Для репликации данных в реальном времени… много разных инструментов" (далее 6 разных вариантов) не реклама Кафки, а большое предостережение. Я бы задумался что заставило Убер, ЛинкедИн и Сейслфорз тратить свое время на создание велосипедов, почему не воспользовались существующими? Что так кардинально плохо в официальных решениях, что вместо использования открытости и исправления существующих решений, все они делают полностью своё?
Сообщая такую новость, нельзя пропускать особенности Техасского патентного "правосудия" (под видом которым *** организовали фабрику обслуживания патентных троллей), и что большинство местных решений опровергаются судом высшей инстанции.
С (целочисленными) последовательностями и Фибоначчи в частности есть засада, они быстро выходят за размер целого числа. Сотое число Фибоначчи уже не влезает в 64 бита. Так что если считать сложность алгоритма честно, то нужно учитывать что умножение чисел выполняется не за константу, а становится дороже при росте чисел :). Получится уже не логарифм.
Исправьте пункт насчёт Теслы и Убера. В оригинале идёт речь про две разные аварии, в одной оператор Убера сбил пешехода, в другой водитель Теслы разбился. Никакого "автомобиля Tesla из автопарка Uber" нет, у Убера была Вольво, как раз она и на фото помятая.
Спасибо, хороший обзор.
Совет: использовать одни и те же единицы измерения. Скажем, читателя может испугать "колоссальное давление – более 400 ГПа", но это "всего лишь" 4 миллиона атмосфер, что конечно очень много, но уже близко к встречавшимся в статье, скажем, 2.6 миллиона атмосфер.
Интересно, ClickHouse такие выражения оптимизирует?
Тот же SUM поверх окна вроде ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW всеми движками вычисляется инкрементально, то есть весь результат будет вычислен за линейное время. sumArray(arrayMap(arraySlice)) если делать "по простому" создаст N массивов, будет считать сумму по каждому заново, и общая стоимость будет квадратичной. Теоретически и такое можно распознать и оптимизировать, но поскольку выражения более общие, то гораздо сложнее.
Да, типичный fang :) Только несколько поправок по опыту МС и Гугла.
У microsoft нет монорепо, и подразделения слишком не доверяют друг другу чтобы использовать общий репо. Мода на монорепо пришла из Гугла, но там большая команда занимается его поддержкой и тулзами по автоматическому рефакторингу таких репозиториев.
Обилие собственных «велосипедов» тоже пришло из Гугла. В Майкрософте, благодаря тому что у каждой группы свой репо, каждая группа может изобрести конечное количество велосипедов. Когда репо общее, то и велосипеды общие, так что их много :)
А вот «засунут на проект, где у тебя меньше всего опыта, а область, где у тебя есть знания, отдадут человеку, который в ней не разбирается» — это уже типичный Майкрософт.
Переработки это тоже Майкрософт (хотя зависит от группы). В Гугле переработки не приняты, а за дежурства всегда платят.
К счастью, Эппл не совсем удалила субпиксельное сглаживание из macOS в 2018 году :). А то уже слишком привык подключать к маку 4k, а из-за короны пришлось пока работать на 1440. Они удалили это только из настроек в UI, внутри пока все есть, и включается из командной строки. Моя теория заговора, удалили чтобы продать кучу новых фирменных мониторов (стоят они у Эппла не дешево). Вот чудо команда:
А над тем, чтобы регулярно обновлять bigquery snapshot тоже вы работаете?
Они писали что планируют регулярно обновлять базу OSM в bigquery,
но пока там та же версия что опубликовали изначально.
Насчёт применения кнопки, у сигнализации Nest есть удобная функция. Для установленных внутри датчиков можно разрешить краткосрочное именно этого отключение датчика кнопкой. То есть чтобы открыть дверь не надо идти отключать всю сигнализацию, достаточно нажать кнопку и открыть дверь. Конечно это trade-off безопасности за удобство, но удобный :)
Дополнительные параметры вряд-ли подойдут, придется при добавлении каждого нового параметра модифицировать все существующие определения., Скорее надо добавить макро — XMACRO, YMACRO и так далее, все с разным числом аргументов. Это по крайней мере можно поддерживать.
Но перед включением заголовка надо будет определять их всех. Выглядеть всё равно будет ужасно.
То есть для узкой задачи как у вас — макро подходит и наверное что-то улучшает. Для общей задачи, стоявшей перед МС — они сделали более менее правильный выбор.
Майкрософтовский XML поддерживает гораздо больше возможностей — множественные counter sets, разные типы счётчиков, дополнительная информация, скажем description. Макросы ОК для ограниченного случая, но использование внешнего описания даёт гораздо больше функциональности ценой всего-то запуска генератора при добавлении счётчика (что обычно довольно редко).
Я бы в укор МС поставил только использование XML вместо создания простенького DSL для счётчиков. Но время такое было, XML использовался где надо и не надо :)
Это, кстати, соответствует майкрософтовской документации (см мой коммент выше), что ^0 это индекс за-концом массива (а не последний как в статье), ^1 это последний элемент, а ^2 предпоследний.
Не, это как раз нормальное и ожидаемое поведение в С-подобных языках.
Вот если бы было как описал автор, то последнее значение в Range не включено, если индекс с начала, то включено, если индекс с конца — я бы решил что что-то не так.
Как-то никто не смог объяснить как RMS мешает "покосу бабла" :)
А исчезновение GNU видимо и так произойдет, просто ввиду не релевантности оного. Можно долго спорить, виноват ли в этом лично RMS, напоминающий "Федорино горе" в последнее время или просто звёзды так сложились. Но GNU compiler практически везде вытеснен LLVM и отстаёт по всем фронтам все дальше и дальше. Остались core utils, посмотрим приживется ли мозилловский вариант на Rust, он безопаснее и быстрее. Что там ещё от GNU останется?
Придется RMS вспомнить про GNU/Hurd, правда какие шансы, если за 20 лет ничего не вышло?
На странице FSFE у RedHat нет даже звёздочки, то есть меньше 10% бюджета. Наряду с Luca Bonissi, отсудившим у Леново 20 тысяч и передавшим из них кажется 15к в FSFE. Вот такая очень влиятельная организация, просто завалившая всех баблом и заставившая плясать под свою дудку. Но да, если обвинить всех остальных в заговоре, на пути которого стоит один RMS как Д'Артаньян, то получается вполне стройная картина всемирного заговора :)
То есть все аргументы за сводятся к "RMS лучше Гитлера"? Я под этим тоже подпишусь, но к счастью для free software этого маловато нынче для лидера.
А про Red Hat — повторяю, они не делают ничего, что не сделали до них десятки независимых от RMS организаций и фондов, даже FSF Europe. Фокусирование на вынужденном акте RH, а не проблеме RMS, это как раз оппортунизм и перевод стрелок.
Вынесение компании (red hat) в заголовок статьи тоже "интересное решение". В реальности за удаление Столлмана выступают множество организаций open source & free software. Да и часть директоров самого FSF. Сложнее найти кто за него. Не знаю уж какие у них у всех корыстные интересы :). Избегая теорий заговора, что все коррумпированные оппортунисты, и один RMS Д'Артаньян, думаю правильнее более простое объяснение — устав пытаться исправить RMS, решили что дальше продуктивнее будет без него.
Интересное использование слова "оппортунисты".
Оппортунизм.
Противников Сталлмана в таком упрекнуть сложно. У них как раз есть принципы, от которых они не отходят, не взирая на лица.
Как сторонний наблюдатель, для меня "Для репликации данных в реальном времени… много разных инструментов" (далее 6 разных вариантов) не реклама Кафки, а большое предостережение. Я бы задумался что заставило Убер, ЛинкедИн и Сейслфорз тратить свое время на создание велосипедов, почему не воспользовались существующими? Что так кардинально плохо в официальных решениях, что вместо использования открытости и исправления существующих решений, все они делают полностью своё?
Сообщая такую новость, нельзя пропускать особенности Техасского патентного "правосудия" (под видом которым *** организовали фабрику обслуживания патентных троллей), и что большинство местных решений опровергаются судом высшей инстанции.
Вот про Маршалл, Техас, как раз где нынешний случай:
https://www.bloomberg.com/opinion/articles/2017-05-25/the-texas-town-that-patent-trolls-built-j34rlmjc
Правда недавно появился конкурент, тоже техасский конечно:
https://www.ipwatchdog.com/2019/02/18/newest-patent-rocket-docket-waco-texas/id=106453/
С (целочисленными) последовательностями и Фибоначчи в частности есть засада, они быстро выходят за размер целого числа. Сотое число Фибоначчи уже не влезает в 64 бита. Так что если считать сложность алгоритма честно, то нужно учитывать что умножение чисел выполняется не за константу, а становится дороже при росте чисел :). Получится уже не логарифм.
Исправьте пункт насчёт Теслы и Убера. В оригинале идёт речь про две разные аварии, в одной оператор Убера сбил пешехода, в другой водитель Теслы разбился. Никакого "автомобиля Tesla из автопарка Uber" нет, у Убера была Вольво, как раз она и на фото помятая.
Спасибо, хороший обзор.
Совет: использовать одни и те же единицы измерения. Скажем, читателя может испугать "колоссальное давление – более 400 ГПа", но это "всего лишь" 4 миллиона атмосфер, что конечно очень много, но уже близко к встречавшимся в статье, скажем, 2.6 миллиона атмосфер.
Интересно, ClickHouse такие выражения оптимизирует?
Тот же SUM поверх окна вроде
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROWвсеми движками вычисляется инкрементально, то есть весь результат будет вычислен за линейное время.sumArray(arrayMap(arraySlice))если делать "по простому" создаст N массивов, будет считать сумму по каждому заново, и общая стоимость будет квадратичной. Теоретически и такое можно распознать и оптимизировать, но поскольку выражения более общие, то гораздо сложнее.У microsoft нет монорепо, и подразделения слишком не доверяют друг другу чтобы использовать общий репо. Мода на монорепо пришла из Гугла, но там большая команда занимается его поддержкой и тулзами по автоматическому рефакторингу таких репозиториев.
Обилие собственных «велосипедов» тоже пришло из Гугла. В Майкрософте, благодаря тому что у каждой группы свой репо, каждая группа может изобрести конечное количество велосипедов. Когда репо общее, то и велосипеды общие, так что их много :)
А вот «засунут на проект, где у тебя меньше всего опыта, а область, где у тебя есть знания, отдадут человеку, который в ней не разбирается» — это уже типичный Майкрософт.
Переработки это тоже Майкрософт (хотя зависит от группы). В Гугле переработки не приняты, а за дежурства всегда платят.
defaults write -globalDomain CGFontRenderingFontSmoothingDisabled -bool NOdefaults write -globalDomain AppleFontSmoothing -int 1
Последний параметр подобрать по вкусу, после этого перезагрузиться, и можно наслаждаться очень неплохой (почти как на виндоусе) картинкой на 1440.
Они писали что планируют регулярно обновлять базу OSM в bigquery,
но пока там та же версия что опубликовали изначально.
Насчёт применения кнопки, у сигнализации Nest есть удобная функция. Для установленных внутри датчиков можно разрешить краткосрочное именно этого отключение датчика кнопкой. То есть чтобы открыть дверь не надо идти отключать всю сигнализацию, достаточно нажать кнопку и открыть дверь. Конечно это trade-off безопасности за удобство, но удобный :)
Дополнительные параметры вряд-ли подойдут, придется при добавлении каждого нового параметра модифицировать все существующие определения., Скорее надо добавить макро — XMACRO, YMACRO и так далее, все с разным числом аргументов. Это по крайней мере можно поддерживать.
Но перед включением заголовка надо будет определять их всех. Выглядеть всё равно будет ужасно.
То есть для узкой задачи как у вас — макро подходит и наверное что-то улучшает. Для общей задачи, стоявшей перед МС — они сделали более менее правильный выбор.
Майкрософтовский XML поддерживает гораздо больше возможностей — множественные counter sets, разные типы счётчиков, дополнительная информация, скажем description. Макросы ОК для ограниченного случая, но использование внешнего описания даёт гораздо больше функциональности ценой всего-то запуска генератора при добавлении счётчика (что обычно довольно редко).
Я бы в укор МС поставил только использование XML вместо создания простенького DSL для счётчиков. Но время такое было, XML использовался где надо и не надо :)
Это, кстати, соответствует майкрософтовской документации (см мой коммент выше), что ^0 это индекс за-концом массива (а не последний как в статье), ^1 это последний элемент, а ^2 предпоследний.
0..^0 это тоже весь массив.
Тогда уже 0..^1.
Вот если бы было как описал автор, то последнее значение в Range не включено, если индекс с начала, то включено, если индекс с конца — я бы решил что что-то не так.