• +1

    Ну, запуск 20-30 линтеров требует времени. Но никто не заставляет запускать их на каждый коммит, так что обычный цикл код-тесты-… работает в соответствии с хвалёной скоростью сборки. А вот когда открывается PR и тесты запускаются в CI — там можно и gometalinter прогнать. Кроме того, можно управлять тем, какие линтеры будут запускаться, и ограничиться теми, которые отрабатывают быстро (у gometalinter есть ключик --fast специально для этого случая).

    Go: 10 лет и растём дальше
  • 0

    Ну, одно дело перегибы, а другое когда люди тупо не получают адекватной обратной связи. Суть ведь не в том, чтобы сказать грубо, а в том, чтобы сказать честно! Потому что если ты объективно плохо делаешь свою работу а тебе говорят "отлично, хотя можно сделать чуть лучше" — это не стимулирует развитие и не даёт понимания того, насколько всё на самом деле плохо. Потому что всегда "можно сделать чуть лучше", по определению, так что это ничего не говорит о том, сейчас было сделано хорошо или плохо, и насколько хорошо или плохо.

    Go: 10 лет и растём дальше
  • +1

    Это может быть частично связано с тем, что у них в культуре вообще не особо принято честно говорить гадости. Там где у них "очень, очень хорошо, правда можно вот тут совсем немного улучшить" у нас "это полное говно, придётся всё переделывать чтобы оно хоть как-то заработало". И мне наш вариант нравится больше, включая жаркие перепалки на хабре.

    Go: 10 лет и растём дальше
  • +2

    Ну, не совсем так. Не знаю про ZurgInq, но Вам реально не хватает сдержанности (исключительно на мой вкус, безусловно), что вполне может отворачивать от Go часть интересующихся. И это при том, что мне как раз очень нравятся и Go и Ваши статьи. Так что в словах ZurgInq доля истины есть. Если хотите, попробуйте просто не отвечать на комментарии троллей и хейтеров, либо отвечать на них только по сути, чисто технически — это будет выглядеть намного более адекватно.

    Go: 10 лет и растём дальше
  • +1
    В добавок, если я забуду обработать ошибку, компилятор мне слова не скажет.

    Полно статических анализаторов, которые нереально дополняют компилятор. Включая и этот момент — посмотрите https://github.com/alecthomas/gometalinter

    Go: 10 лет и растём дальше
  • 0

    Если я правильно понимаю, то Вы говорите о том, что всё это — решаемая проблема, есть много разных подходов к её решению, что нужно задуматься о природе данных, присмотреться к тому, как они на самом деле используются, etc.


    Я же говорю о том, что всё это усложняет реализацию и в 2-3 раза увеличивает время (и, соответственно, стоимость) разработки среднего микросервиса. И поэтому в проектах, в которых нет необходимости масштабирования и/или HA для этого stateful сервиса — бизнесу не выгодно тратить в разы больше ресурсов на то, чтобы сделать этот сервис stateless.


    Вы поняли как вам это хотелось…
    Да синхронизация через базу даных это самообман и антипэттерн.

    Нет, я понял в контексте исходного обсуждения — т.е. как можно вынести данные из сервиса не увеличивая стоимость его разработки в разы.

    Эволюция DevOps
  • +6
    Через несколько часов я смог его закрыть

    А у меня, примерно в 1993, не было под рукой интернета. Так что я тупо перезагрузил систему. :)


    Впрочем, спустя лет 10, мы с vim всё-таки подружились, и с тех пор неразлучны.

    Как я использую git
  • +2

    Если данные тупо оторвать от сервиса переместив их в СУБД — stateless сервис мы не получим. Мы получим сервис, состоящий из двух сильно связанных частей, одна в виде как-бэ stateless сервиса, вторая в виде данных в БД.


    Это жизнь никоим образом не упростит, и возможность запускать более одного экземпляра этого сервиса не даст (в общем случае). Наоборот, всё станет только сложнее, и в реализации и в эксплуатации. Единственная причина делать такую фигню — необходимость формально отчитаться перед технически не разбирающимся начальством, что "у нас все сервисы — stateless", если вдруг оное начальство где-то прочитало про то, что stateless сервисы это дико круто, и потребовало немедленно внедрить ради галочки в отчётах.


    P.S. Что касается "набивания руки" и "луж" — я микросервисы пишу примерно с 2009 (да, этого термина тогда ещё не было). Так что рука уже давно отбита напрочь. Но описанную проблему это не решило.

    Эволюция DevOps
  • 0
    Быстрее произносятся слова — быстрее их воспринимаешь.

    Это не так. По крайней мере — для многих людей это не так, исключения всегда можно найти, возможно лично Вам в этом плане повезло.


    Читаем вы в разы быстрее чем говорим, но чтение же не вызывает вопросов. :)

    Это потому, что текст несёт значительно меньше информации, чем аудио, аудио меньше чем видео, а видео меньше чем личное общение. Поэтому скорость восприятия текста без потери информации кажется более высокой — но дело не в том, что скорость восприятия информации в текстовом виде выше, а в том, что информации в тексте меньше. Есть специальные техники скорочтения, эффект от них очень похож на просмотр видео на повышенной скорости: читаешь быстрее в разы, информацию вроде бы получаешь формально всю или почти всю, но на самом деле тонкие нюансы и разные мелочи теряются напрочь, вместе с (потенциальным) удовольствием от чтения.


    Так что я с вами в корне не согласен.

    А вот это как раз нормально, я и не настаиваю на том, что абсолютно прав вообще и лично для Вас в частности. Просто есть вполне конкретные аргументы в пользу моего мнения, я их привёл, если Вам они не кажутся убедительными — ничего плохого в этом нет.

    Разработка на скорости 450 слов в минуту
  • 0

    По-моему недавно пробегала новость, что какие-то ресурсы уже вполне можно и во внесудебном порядке блокировать. Зеркала заблокированных ресурсов вроде бы (а кто имеет экспертизу принимать решение, это зеркало или нет?), может ещё что-то, не помню.

    Анализ он-лайн конференций РКН на тему: «проблемные вопросы ограничения доступа к информации...»
  • +1

    Почему компилятор не знает всё про внутреннюю логику и побочные эффекты какой-то функции какого-то пакета и не заменяет её вызов на вызов другой функции? Ну, что Вам сказать… придётся признать, что разработчики компилятора невероятно ленивы и толком не умеют писать компиляторы.


    А если серьёзно, то, как уже упоминали выше, такого рода оптимизации во-первых зачастую преждевременные, во-вторых ухудшают читабельность, в-третьих в следующих версиях языка и/или пакета fmt более медленный вариант сейчас может оказаться более быстрым, в-четвёртых если уж очень хочется, то рекомендации по такого рода оптимизациям должны давать внешние утилиты вроде статических анализаторов кода (линтеров) или IDE.

    Как новичок в Go контрибьютил
  • +2

    Проблема не в скорости просмотра, а в наполненности контента.


    Если контент содержит много "воды", то текстовый можно быстро просканировать чтобы выхватить полезное (пусть даже что-то при этом может быть упущено), и даже не пытаться читать его целиком. С аудио/видео такой фокус не прокатит, и увеличение скорости проблему не решает — всё равно необходимо просмотреть всё, пусть это и займёт в 2-3 раза меньше времени. Вывод: контент с низкой наполненностью полезной информацией в аудио/видео лучше вообще не смотреть, если жалко переводить впустую время своей жизни.


    При этом привычка просматривать всё на повышенной скорости может привести к тому, что когда попадётся что-то действительно ценное — большая часть вкусненького будет потеряна из-за слишком поверхностного восприятия. А такие вещи попадаются, хоть и редко — и там нередко нужно смаковать каждый кадр, иногда даже ставя для этого на паузу или перематывая назад для повтора, потому что видео несёт очень много информации в каждом кадре, и даже аудио несёт заметно больше информации, чем текст.


    В общем, я к тому, что если у Вас возникает желание включить 2x — зачастую это признак того, что лучше вообще выключить, и поискать вместо этого контента что-то более наполненное.


    И уже не хватает…

    А вот это может быть признаком того, что из-за привычки к увеличенной скорости уже сформировалась привычка поверхностного восприятия. А значит, даже там где есть ценная информация, она воспринимается частично. И получается замкнутый круг: мало инфы — выше скорость — из-за скорости ещё меньше инфы — ещё выше скорость…

    Разработка на скорости 450 слов в минуту
  • +2

    Сложность реализации. Скорость и стоимость разработки страдают как следствие увеличившейся сложности.


    Когда у сервиса собственная БД под боком и он запущен в единственном экземпляре — открывается масса возможностей как написать его проще, быстрее и эффективнее:


    • сервис может использовать любой подходящий под его данные формат БД (от подключения к сторонней SQL/NoSQL СУБД до бинарных или json-файликов у себя на диске), что упрощает реализацию сервиса и позволяет сделать его более производительным
    • сервис может работать со своими данными не беспокоясь о блокировках, а транзакции используя только там, где это необходимо для сохранения целостности БД (напр. подменяя изменённые json-файлы атомарной операцией перемещения файла)
    • сервис может кешировать в памяти всё, что хочет, включая держать вообще всю БД в памяти если влазит (а она часто влазит — у "микро"сервисов зачастую и данных тоже "микро") и в этом есть смысл (a-la "memcached inside") и этот кеш очень легко поддерживать в актуальном состоянии
    • нет необходимости реализовывать одновременную поддержку двух версий структуры БД в одной версии сервиса — ведь миграцию БД можно делать между отключением старой версии сервиса и запуском новой
    • etc.

    А как только таких запущенных сервисов становится больше одного — всё резко усложняется. Приходится учитывать в коде необходимость синхронизации и координации между сервисами, приходится использовать менее удобные БД, распределённые/удалённые кеши и инвалидация устаревших данных в них это отдельная проблема, приходится поддерживать возможность одновременной работы двух разных версий сервиса и изменения формата БД в процессе работы сервиса, etc.


    Учитывая, что обычно микросервисы достаточно мелкие, объёмной и сложной бизнес-логики в них обычно нет, то основное время на их реализацию тратится именно на такого рода "служебные" задачи. И когда сложность этих служебных задач настолько увеличивается — скорость и стоимость разработки и тестирования сервиса ухудшаются в разы.

    Эволюция DevOps
  • +2
    Изменяются принципы проектирования программного обеспечения, удобство для использования в стандартизованных (на предыдущем этапе!) технологических и процессиях стеках становится обязательной основой в архитектуре и дизайне программного обеспечения.

    К сожалению, пока что разработка stateful микросервиса, не рассчитанного на запуск в облаке в более чем одном экземпляре, обходится в разы дешевле (и для многих проектов реальной необходимости в поддержке HA и/или масштабирования для этого сервиса просто нет). Что сильно осложняет автоматическое управление этим сервисом в стиле AWS ECS.


    Я к тому, что необходимые принципы проектирования уже есть, и давно (напр. https://12factor.net/ru/), но пока они не станут выгодны экономически описанного будущего нам не видать.

    Эволюция DevOps
  • 0
    Почему же, показывает то, что нам хотела донести администрация…

    Думаю, администрация всего-навсего пыталась сделать топ менее статичным, чтобы у новых авторов был шанс в него попасть быстрее чем за пару лет активной публикации статей — администрации это нужно как дополнительный механизм мотивации авторов. Если я прав, то администрация несколько перестаралась с динамичностью топа, это точно.

    Не виноватая я. Он сам пришел
  • +2

    А чем хуже вариант использовать существующие приложения?


    • в качестве надёжного супервизора взять что-то из семейства daemontools (напр. runit или s6)
    • аргументы запуска прописать в явном виде sh-скрипта, запускающего сервис
    • для регистрации в консуле тупо отправлять HTTP-запрос в консул любой тулзой из скрипта стартующего сервис
    • для репорта крешей опять же запускать что-то аналогичное (репорт по HTTP в какой-нить сервис вроде pushgateway для prometheus) из скрипта запускаемого супервизором при креше сервиса

    По сути, всё это разные задачи, которые нужны в разных комбинациях под разные ситуации. Тулзы, которые всё это делают — занимают ещё меньше, чем бинарник Go-приложения (супервизор из runit — runsv — занимает 30KB и не тянет никаких нестандартных динамических библиотек).

    Очень легкая система мониторинга с Телеграмом и Консулом
  • +3

    Я тоже задаюсь этими вопросами. Пока что, исключительно для себя, ответы такие:


    Какие проблемы оно решает?

    Мы не знаем, какие данные и в каком виде нам потребуются на клиенте завтра, но мы хотим получать их максимально просто, быстро и эффективно — т.е. одним запросом и без "лишних" полей в ответе. Примерно так, как бэкенд может получать данные через SQL. При этом мы не хотим открывать клиенту полный доступ к базе (это небезопасно), и хотим избежать необходимости вносить изменения на бэкенде под каждый новый тип запросов, который понадобился клиенту (это ограничивает свободу творчества на клиенте и скорость его разработки).


    Чем лучше старого-доброго RPC?

    Формально это и есть один такой универсальный вызов RPC "считать/записать (почти) любые данные". Но по сути это лучше старого-доброго RPC тем, что это один вызов, который достаточно реализовать один раз, и нет необходимости добавлять новые вызовы на бэкенде под каждый новый тип запросов клиента.


    Почему его сравнивают с REST?

    Потому что в REST нет возможности "считать/записать (почти) любые данные" одним запросом, и REST клиенты страдают, реализуя этот функционал вручную, через кучку отдельных запросов. <sarcasm>Так что GraphQL "это как REST, только лучше".</sarcasm> На самом деле, конечно, ничего общего между REST и GraphQL нет.


    Резюмируя всё это, моё личное мнение: корректно и полноценно реализовать GraphQL на сервере — крайне сложно. И я сейчас не про парсер GraphQL, который уже реализован в куче библиотек, а про бизнес-логику функций, которые получают/изменяют конкретные поля данных. В GraphQL слишком много от прямого доступа к данным, что сильно усложняет корректную реализацию бизнес-логики того, какие поля в каких ситуациях кому можно читать/писать. Так что требования к сложности, гибкости и разнообразию клиентских запросов должны быть поистине гигантскими (примерно масштабов фейсбука), чтобы вся эта сложность реализации GraphQL на бэкенде стала оправданной.


    P.S. Думаю, в будущем мы увидим очень много примеров дыр нового типа GraphQL-injection, когда через специальным образом сформированные GraphQL-запросы можно будет считывать и изменять данные, к которым доступа у этого юзера быть вообще не должно.

    Покойся с миром, REST. Долгих лет жизни GraphQL
  • 0

    Для FF это плагины Spidermonkey и Stylish. Когда-то для IE это был Trixie, а для Safari NinjaKit, возможно сейчас уже другие. Плюс есть сайты вроде https://greasyfork.org/ для обмена модами между юзерами.

    Пусть интернет прогнётся под нас
  • +1

    Ну, вообще-то банковские трояны именно этим и занимаются уже очень много лет. И да, долбодятлом, почему-то, при этом принято считать именно пострадавшего — не обновлял ОС, не поставил правильный антивирус, качал из инета игрушки на комп с ДБО, запускал аттачи к письмам, etc. Я не говорю, что случай из статьи идентичен, там всё-таки неясно, что могли предпринять пострадавшие для своей защиты (ну, кроме выделения средств на аудит безопасности этого кода), но определённые параллели между этими ситуациями определённо наблюдаются.

    Критическая уязвимость в multisig кошельке Parity, хакерами выведен $31 миллион в ethereum (обновлено)
  • +2

    Хотя в общем направление мысли адекватное, но в статье всё настолько идеализировано и упрощено, что описанное скорее напоминает модель для настольной игры в разработку качественного ПО для детей среднего школьного возраста, нежели реалии нашей работы.

    Стоимость качества в разработке программного обеспечения
  • 0

    Именно. И так же есть решения для других упомянутых в статье проблем (использовать привилегированные порты обычный юзер может через setcap CAP_NET_BIND_SERVICE=+eip, фильтровать какие процессы он видит можно через GrSecurity, etc.). Но — вряд ли это взлетит. Докер удобно прячет всё это под капот, а что до большого размера образов… ну, с одной стороны это не такая уж большая цена, с другой если сервисы писать на Go или просто линковать статически то образ докера может занимать несколько мегабайт, а не гигабайт.

    Привилегированные порты — причина глобального потепления
  • +1

    Т.е. кейс тут один: сервис за NAT, к которому по своей инициативе подключается клиент не за NAT? Причём для подключения клиенту нужно заранее знать, на какой неиспользуемый IP отправляет пакеты конкретно этот сервис (их ведь за NAT может быть несколько, так что нужно дополнительно обеспечить уникальность этих неиспользуемых IP для всех сервисов за этим NAT), плюс клиент должен знать адрес самого NAT. И всю эту информацию клиент должен получить без использования промежуточного сервера.


    Как по мне — всё это звучит крайне сомнительно. Для статических, штатных сервисов проще настроить форвардинг портов на NAT. Для динамических будет сложновато обеспечить распределение между ними на какие неиспользуемые IP они будут слать ICMP, плюс потребуется как-то доносить выбранный конкретным сервисом IP до клиентов, что ещё сложнее.


    Либо я по-прежнему что-то упускаю, либо это странный и малополезный в реальных задачах хак, которым крайне сложно оправдывать поддержку спуфинга IP.

    Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с
  • 0

    Если не ошибаюсь, когда-то amarao описывал в комментах почему провайдерам сложно реализовать защиту от IP-спуфинга. Если кто-нибудь найдёт этот коммент — добавьте ссылку сюда, плз.

    Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с
  • 0

    А в чём именно ценность этих применений?


    ReQrypt просто экономит немного скорости для пользователя и много трафика для своего сервера — это прикольно, но не настолько принципиально по сравнению с обычным прокси/VPN чтобы ради этого разрешать IP-спуфинг.


    В чём ценность такого способа обхода NAT я, возможно, просто не понял — есть ведь немало других способов, чем конкретно этот лучше?

    Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с
  • +2

    К сожалению, разумные разработчики не настолько разумные, как нам бы хотелось. И психология этих разумных разработчиков не отличается от других людей. И работают они каждый над своим участком кода, зачастую не имея ни времени ни желания вникать в то, как что-то устроено на другой стороне или в следующем слое абстракции. Так что когда они видят не просто обычный набор параметров, а подписанный набор параметров — они обычно считают, что раз подпись есть, то она должна что-то да значить, в частности что параметрам можно верить (ведь зачем-то такую необычную подпись кто-то добавил… а разработчики, как известно, разумные, так что добавлять совершенно бессмысленную подпись они бы не стали :)). Да и просто подсознательно подписанным данным доверия всегда больше. Так что проверять подписанные параметры разработчики если и будут вообще, то совсем не так тщательно, как обычно.


    Итого — вред есть, и значительный. Начиная с затрат времени на разработку и поддержку бессмысленного функционала, и заканчивая ослаблением безопасности из-за психологического фактора. А самое плохое то, что такой бессмысленный функционал часто со временем попадает в категорию "магическая хреновина, никто не знает зачем она нужна, но её нужно обязательно поддерживать в рабочем состоянии иначе неизвестно что может поломаться".

    Уязвимость ВКонтакте: отправляем сообщение с кодом восстановления страницы на чужой номер
  • +1

    Может, конечно. Я сам таким был. Но суть вопроса ведь не в этом. Всё описанное в статье по сложности реализации доступно и понятно начинающим разработчикам под андроид. Добавляем к этому желание взломать и хакерский склад ума — и всё, "защита" моментально обходится. Если начинающий разработчик может обойти эту защиту — зачем её вообще делали? Против кого, собственно? Где целевая аудитория хакеров, которые хотят это сломать, но не смогут этого сделать из-за недостатка квалификации/времени/средств? Кто и для чего придумывает глупости вроде этой "подписи" параметров HTTP, выполняемой кодом на клиенте, который контролирует хакер? Я бы ещё понял, если бы они этот код вынесли в C-шную библиотеку набитую антиотладочными приёмами — тоже не сильно поможет, но было бы видно, что они хотя бы пытались поднять планку требуемой квалификации для взлома. А в текущем виде это просто профанация.

    Уязвимость ВКонтакте: отправляем сообщение с кодом восстановления страницы на чужой номер
  • +13

    С чего Вы это взяли?


    Я говорю "школьник" потому, что судя по упоминанию ЕГЭ в статье это сделал именно школьник. И какими бы умными не были школьники, квалификация людей профессионально занимающихся безопасностью обычно намного выше. Так что мой вопрос вполне уместен — если эта "защита" не в состоянии сдержать школьника, то хакера она тем более не сдержит — и зачем она тогда нужна вообще? Все остальные и так не будут пытаться подделывать HTTP-запросы.


    Проблема в том, что от такой реализации "безопасности" больше вреда, чем пользы: на самом деле она ни от чего не защищает, но создаёт у разработчиков ложное чувство безопасности — якобы параметрам запроса можно доверять, раз они корректно подписаны. А доверять им, разумеется, нельзя, и код будет намного безопаснее, если об этом никто из разработчиков не будет забывать ни на секунду.

    Уязвимость ВКонтакте: отправляем сообщение с кодом восстановления страницы на чужой номер
  • –3

    И что, на масштабах mail.ru действительно дешевле потратить время и ресурсы на разработку и дальнейшую поддержку этого решения, вместо того чтобы просто воткнуть лишние 64GB памяти и ограничиться тривиальным идиоматическим кодом?

    Миллион WebSocket и Go
  • 0
    Эта библиотека сделана в лучших традициях security through obscurity, весь код надежно обфусцирован.

    OMG… кто-то ещё такое использует в наши дни. Чего ради??? Чтобы потом это сломал школьник и VK с Mail.ru стало стыдно?

    Уязвимость ВКонтакте: отправляем сообщение с кодом восстановления страницы на чужой номер
  • 0
    Если создать дополнительные издержки CA, за них заплатит конечный потребитель.

    Не обязательно. Издержки CA более-менее фиксированные (не зависят от количества выпущенных сертификатов), так что их вполне реально покрывать за счёт платных EV сертификатов для средних/крупных компаний. Кроме того, их издержки могут покрываться гигантами вроде Google или дотациями из гос.бюджета — теми, кто заинтересован в безопасном вебе.


    А вот если эти дополнительные издержки на обеспечивание высокого уровня защиты и контроля не создать, то какой в этих CA вообще смысл и чем они надёжнее моего собственного CA? По хорошему, используемый код и базовая инфраструктура CA должны быть выложены в открытый доступ для проведения публичного аудита. Поверх этого ядра они могут городить любые фичи/интерфейсы, но валидация того, можно ли выдать сертификат и сама выдача должна быть реализована одинаково у всех CA, и этот код должен лежать на гитхабе.

    Google в скором времени перестанет доверять всем сертификатам WoSign и StartCom
  • 0

    CA необходимо наказывать, причём максимально жёстко! И очень плохо, что это начинают делать только сейчас.


    Сейчас на доверии CA держится почти полностью весь https (исключая редко используемые pinned сертификаты), и если CA не будут максимально серьёзно относиться к своей репутации и безопасности своей инфраструктуры — надёжность https может сильно пострадать.


    Более того, я бы вообще список корневых сертификатов в браузерах сократил примерно на порядок — адекватно контролировать текущее количество должно быть очень сложно, поэтому стоит ужесточить требования к CA и отобрать корневые сертификаты у тех, кто будет не в состоянии выполнять эти требования.

    Google в скором времени перестанет доверять всем сертификатам WoSign и StartCom
  • 0

    Думаю, Вы правильно поняли автора статьи, но он ошибается. Дело в том, что Fog Creek — это очень «не репрезентативная выборка». Те плюсы, которые он описывает — не являются следствием работы с 9 до 5, дресскода или того, что такая "культура" позволяет брать на работу не только белых молодых хипстеров. Эти плюсы являются следствием того отношения к разработке, которое продвигает Джоэл Спольски.

    Чтобы ваша культура вмещала всех, попробуйте работать меньше
  • 0

    Всё так, но, тем не менее, это шаг в правильном направлении.


    По большому счёту сама идея CA не выдерживает никакой критики, особенно учитывая тот факт, что за нарушения эти CA зачастую не наказывают вообще, а если и наказывают, то недостаточно жёстко чтобы исключить такие нарушения в будущем. (Очень показательна история про WoSign и StartCom.)


    Тем не менее, существуют механизмы, которые смогут обеспечить необходимый уровень безопасности. Просто у них есть своя цена. Скорее всего, постепенно всё это будет реализовано в массовых масштабах, но надо с чего-то начинать, и https в любом виде это неплохой старт.

    Полное руководство по переходу с HTTP на HTTPS
  • 0

    Против отслеживания uBlock Origin и uMatrix вроде бы ставятся в любой браузер. Доверие у чистого chromium вроде примерно на том же уровне, что и у файрфокса.

    Вышел Firefox 54, который наконец получил поддержку многопроцессного режима
  • +2

    Проблема не в том, мелкие это разработчики или гиганты, а в том, что новое API в принципе не предоставляет необходимых возможностей для реализации многих плагинов. И эти плагины отвалятся в любом случае, вне зависимости от имеющихся ресурсов и желания их переписать под новое API. Вот пример мнения разработчика нужного мне плагина Tab Groups: http://fasezero.com/.

    Вышел Firefox 54, который наконец получил поддержку многопроцессного режима
  • +9

    Я думаю, что 57-я убьёт файрфокс.


    В том смысле, что сейчас файрфокс — это браузер из которого можно сделать то, что тебе нужно плагинами. А после 57-й файрфокс перестанет быть файрфоксом, а станет таким же браузером, как и все остальные — жри что дают, и, да, ты можешь поменять фоновую картинку строки меню. Лично для меня это, вероятно, будет означать переход на вивальди, или какой-то другой браузер, который в режиме "жри, что дают" будет более похож на 12-ю оперу (поведение, которое сейчас реализовано в моём файрфоксе плагинами, которые не будут работать с 57-й версии).


    В результате файрфокс потеряет свою основную изюминку, потеряет ещё больший процент юзеров, потеряет основных фанатов которые любили его тюнить под себя и советовали его за гибкость своим знакомым. И, в результате, через года три сдохнет совсем. Потому что новых юзеров взамен потерянных он этими изменениями не привлечёт.


    Я понимаю, что текущая модель плагинов создаёт кучку проблем с безопасностью, и их надо как-то решать. Но выбранное решение больше всего напоминает лечение насморка гильотиной.

    Вышел Firefox 54, который наконец получил поддержку многопроцессного режима
  • +2

    Отказ вполне обоснованный — психология и моральные качества кандидата важны, они влияют на качество работы, на соблюдение как устных договорённостей так и NDA, на психологический климат в коллективе, etc. Всё это влияет именно на "деловые качества работника", так что нарушения закона в этом нет. А моральные качества вполне разумно определять и по тому, за какую работу кандидат брался в прошлом.


    Я, например, не люблю нанимать людей, которые разрабатывали софт для спама. Если что-то такое всплывает — я стараюсь сначала выяснить, зачем он занимался такой работой, как долго и почему перестал, а уже потом принимаю решение.


    Кроме того, на практике дискриминация была, есть и будет — где-то не наймут из-за пола, где-то из-за возраста, много где из-за того что судимый. А чаще всего — тупо потому, что ты не понравился на собеседовании. Чисто эмоционально/интуитивно не понравился, хотя формально "по деловым качествам" вроде бы подходишь. И можно размахивать ТК до посинения, но заставить взять себя на работу Вы не сможете.


    Так что ничего нового/противозаконного мы там не обсуждали. На хабре полно статей о том, как проводить собеседования, как оценивать кандидатов — мы просто добавили ещё один пункт в список того, на что стоит обращать внимание при найме на работу. Более того, никто ведь в том обсуждении не предлагал как-то принуждать компании не нанимать людей работавших на роскомнадзор, речь шла только о том, что они должны иметь возможность сами решить, важно это для них или нет.

    Какого! закона вы ещё хотели? У меня есть их! Блокируем VPN
  • 0

    I2P/Tor лучше, чем тупо сервер зарубежом:


    • сервер быстро забанит роскомнадзор, а до блокирования I2P/Tor на практике доберутся не так быстро
    • сервер зарубежом даст повод обвинить участвующих в обсуждении что они продались врагу и вообще предатели родины
    • I2P/Tor дадут анонимность, без которой многие могут побояться участвовать
    • для упрощения доступа для остальных никто не мешает выставить статическое зеркало(а) сайта в обычном интернете, чтобы если не писать, то хотя бы читать могли все желающие
    Какого! закона вы ещё хотели? У меня есть их! Блокируем VPN
  • 0

    Как аудитория может быть меньше нуля? А на хабре её блокировкой сводят именно к нулю. Ну вот сейчас что произошло? Мы потрындели, статью забанили, мы разошлись. Выхлоп в результате равен нулю. Так что обсуждать надо там, где не банят. А вот рекламировать эти обсуждения и публиковать инструкции как в них поучаствовать — можно и на хабре, вполне себе ITшная тема — обсуждение IT-профсоюза в глубинах I2P.

    Какого! закона вы ещё хотели? У меня есть их! Блокируем VPN
  • 0

    Ну… я бы сказал, что неправильные темы надо обсуждать на правильных сайтах, где их не будут банить. Например, на внутренних сайтах I2P или Tor.

    Какого! закона вы ещё хотели? У меня есть их! Блокируем VPN