Да, у расширение Ghostery есть список того, что собирает Disqus — https://apps.ghostery.com/en/apps/disqus
И что они могут с этими данными сделать: «Aggregate data is shared with 3rd parties., Anonymous data is shared with 3rd parties., PII data is shared with 3rd parties.»
Я лично столкнулся с тем, что Disqus перехватывает клики на странице и перенаправляет их через левые сервера. То есть, при клике на ссылку, ведущую на сайт Samsung, браузер проходит через 5 редиректов, пока не попадёт наконец на официальный сайт Samsung. При заблокированном виджете Disqus никаких промежуточных редиректов нет. После этого Я удалил свой аккаунт на Disqus и навечно заблокировал его в Ghostery.
Насколько Я понимаю, преобразования Лоренца — это основа Специальной теории относительности. Но для объяснения теории гравитации они не подходят. Товарищ Эйнштейн при разработке ОТО опирался больше на тензорный анализ и дифференциальную геометрию.
Помогать или не помогать — это личное дело каждого. Никто не заставляет пользоваться Facebook, VK или Instagram. Всегда можно завести левый аккаунт на вымышленное имя для нерегулярного использования (например, чтобы залогиниться на каком-нибудь сайте). Люди добровольно пользуются социальными сетями и отдают им свои персональные данные, лайкают и комментируют, устанавливают Facebook на свои телефоны. Может быть со временем выработается базовая Интернет-гигиена и Ghostery будет установлен во всех браузерах…
Здорово, что разработчики смогли заставить работать «Hello world» сервер с такой производительностью. Только Я бы сравнил реализации какого-нибудь реального REST-сервиса, реализованного на разных языках программирования.
Вспоминается история проекта Pyston. Разработчики из Dropbox делали свою реализацию Python с JIT-компиляцией. На синтетических тестах Pyston на 95% быстрее чем стандартный CPython. Но на реальном web-сервере прирост составляет всего на 10%. Из-за этого Dropbox больше не финансирует этот проект (к моему величайшему сожалению).
Для меня плюсы LastPass в следующем: двухфакторная аутентификация, интеграция со всеми браузерами (даже Opera 12 была какое-то время), возможность делиться паролями и секретными заметками с другими пользователями, интеграция с Android приложениями. Мне, как пользователю, достаточно вовремя обновлять расширения в браузерах.
Косяки случаются у всех, но утечки секретных данных в LastPass ещё не было (по крайней мере публично никто об этом не заявлял :).
В любом случае можно сделать вывод, что атомарный инкремент/декремент не бывает бесплатным :(
А во вторых, хочу обратить ваше внимание на проект Gilectomy, в рамках которого программист Larry Hastings пытается избавиться от Python GIL. Вот его выступление на PyCon 2016: Larry Hastings — The Gilectomy. Чтобы не тратить время, перемотайте на сравнение производительности 25 мин 46 сек. Графики показывают что на текущий момент Python с вырезанным GIL работает в 10-18 раз хуже (в зависимости от количества ядер CPU) чем стандартный Python. И львиная доля падения производительности связанна именно с cache miss-ами.
Можете поискать в Интернете сравнения «reference counting» и «tracing garbage collection» подходов. Например Я нашёл развёрнутый ответ на quora: How do reference counting and garbage collection compare?. Проблемы с Reference Counting следующие:
Циклические ссылки всё равно нужно искать путём сканирования всех объектов в памяти;
Увеличение/уменьшение счётчика ссылок происходит очень часто, что приводит к частым cach miss даже если поля объекта не менялись;
В многопоточной среде могут возникнуть race condition из-за того, что операция инкремента/декремента не атомарная. В Python это решено с помощью GIL. Замена на атомарный инкремент/декремент сильно ухудшает общую производительность;
При уничтожении объекта могут использоваться деструкторы. А так как объект может быть уничтожет в любой момент, то и паузы вызванные деструктором совершенно непредсказуемы;
Ну и самое главное: нельзя просто так поменять один тип управления памятью на другой. Это повлияет на все аспекты работы виртуальной машины. Поэтому в Java не появится Reference counting, а Python врядли перейдёт на Tracing garbage collection.
Да, Я об этом и писал. И было бы гораздо удобнее перетягивать за пустое пространство заголовка (как в Chrome Developer Tools и XCode). Ведь гораздо проще попасть в широкий бледно-синий прямоугольник, чем целиться в узкую полоску шириной "± несколько пикселей".
Что не так с ресайзом? Вроде ресайзится без проблем.
Проблема в удобстве. Сейчас чтобы изменить размер нижней панели нужно попасть в узенькую полоску в три пикселя шириной. Сравните с XCode или Chrome Developer Tools: в них можно потянуть за свободное пространство заголовка нижней панели (+10 к удобству).
Если мешающий вам баг есть в Community версии, то можете попробовать исправить его самостоятельно. Это ли не круто?
Только вот Я сильно огорчился когда увидел, что разработчики не приняли один интересный патч «Resize tool window by draggin the header». Автор даже не поленился видео записать. Но разработчики отказали с формулировкой: «пользуйтесь хоткеями» :(
А ещё с сенсорным экраном стало намного удобнее скролить и масштабировать. Причём не важно, что именно: документы, сайты, фотографии, карты. Экран ноутбука гораздо точнее чем экран тачпада в силу своего размера (и уж в сто раз точнее мышки).
Да, это потребовало бы большой работы по полной переделке интерфейса MacOS в сторону пальцеориентированности.
Хочу отметить, что Microsoft уже много лет ведёт интерфейс своей настольной операционной системы к возможности работать пальцами. Началось всё это с интерфейса Ribbon, плиток в Windows 8, больших кнопок управления окнами («свернуть», «распахнуть», «закрыть»). Плоды этого можно ощутить уже сейчас: Я пользуюсь Windows 10 на ноуте с сенсорным экраном. Тут и экранная клавиатура, и окно системных параметров с большими иконками, и переработанные стандартные приложения Калькулятор, Почта, Музыка, др. Часто тыкаю пальцами в экран, так как это бывает быстрее чем мышкой.
Вы совершенно правы. Чарли Брукер (бессменный сценарист «Черного зеркала») рассказал в интервью историю о том, как родилась идея первого эпизода третьего сезона: Charlie Brooker at the Black Mirror Q&A
Мой вольный перевод:
Появился Uber. Однажды я ехал в Uber такси. И водитель сильно жаловался на посетителя, который поставил ему низкую оценку. Водитель даже вычислил, где этот человек работает. Я подумал: он вполне может найти и убить этого человека.
Зря вы называете lastpass.com «левым серваком». Основная идея этого сервиса — сильная криптография на стороне клиента. Сервера lastpass хранят ваши пароли и другие секретные данные в зашифрованном виде и не могут их расшифровать без главного пароля, который знает только пользователь. Кроме того поддерживается многофакторная аутентификация (SMS, отпечаток пальца, RSA токены, др.), автоматическая смена пароля для популярных сайтов. А недаво они прошли сертификацию SOC 2. Понятия не имею, что за SOC 2, но вроде это аудит, подтверждающий безопасность процессов внутри компании.
И что они могут с этими данными сделать: «Aggregate data is shared with 3rd parties., Anonymous data is shared with 3rd parties., PII data is shared with 3rd parties.»
Я лично столкнулся с тем, что Disqus перехватывает клики на странице и перенаправляет их через левые сервера. То есть, при клике на ссылку, ведущую на сайт Samsung, браузер проходит через 5 редиректов, пока не попадёт наконец на официальный сайт Samsung. При заблокированном виджете Disqus никаких промежуточных редиректов нет. После этого Я удалил свой аккаунт на Disqus и навечно заблокировал его в Ghostery.
Вспоминается история проекта Pyston. Разработчики из Dropbox делали свою реализацию Python с JIT-компиляцией. На синтетических тестах Pyston на 95% быстрее чем стандартный CPython. Но на реальном web-сервере прирост составляет всего на 10%. Из-за этого Dropbox больше не финансирует этот проект (к моему величайшему сожалению).
Косяки случаются у всех, но утечки секретных данных в LastPass ещё не было (по крайней мере публично никто об этом не заявлял :).
А во вторых, хочу обратить ваше внимание на проект Gilectomy, в рамках которого программист Larry Hastings пытается избавиться от Python GIL. Вот его выступление на PyCon 2016: Larry Hastings — The Gilectomy. Чтобы не тратить время, перемотайте на сравнение производительности 25 мин 46 сек. Графики показывают что на текущий момент Python с вырезанным GIL работает в 10-18 раз хуже (в зависимости от количества ядер CPU) чем стандартный Python. И львиная доля падения производительности связанна именно с cache miss-ами.
Ну и самое главное: нельзя просто так поменять один тип управления памятью на другой. Это повлияет на все аспекты работы виртуальной машины. Поэтому в Java не появится Reference counting, а Python врядли перейдёт на Tracing garbage collection.
Только вот Я сильно огорчился когда увидел, что разработчики не приняли один интересный патч «Resize tool window by draggin the header». Автор даже не поленился видео записать. Но разработчики отказали с формулировкой: «пользуйтесь хоткеями» :(
Мой вольный перевод: