• Браузер != Браузерный движок
    0
    Они как раз наоборот, они делают браузер, а не движок. Т.е. имеют аудиторию пользователей (что само по себе ценно). А движок у них то ли WebKit, то ли blink.
  • Браузер != Браузерный движок
    +1
    Очень трудно найти инвестора в ситуации, когда все три лидера рынка предлагают «такое же, но бесплатно и с отгрузкой в тот же день».

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

    Вот сделать что-то такое, где порог вхождения (не во «встроить движок в свой браузер») будет существенно ниже, чем для существующих проектов — это круто. Это реально киллер-фича, которой нет ни у одного из существующих браузеров.

    Более того, как показывает практика, академия медленно запрягает, зато потом получается круто.
  • Браузер != Браузерный движок
    –1
    Вероятность написать полноценный движок (такой, который будет нос-в-нос с FF/хромом) — маленькая.

    А вот разработать учебный движок (который ставит своей целью понятность исходников и удобность для написания) — очень даже.

    Кстати, для операционных систем уже случилось чудо, и учебная ОС (minix) — самая распространённая ОС в мире.
  • Больше бесплатных откликов на Фрилансим — больше денег
    +1
    И как вы боретесь с мультоводством?

    Ферма аккаунтов для откликов. Всё честно, никакого кидалова заказчика. Просто несколько аккаунтов у одного человека.
  • 10-гигабитный Ethernet: советы новичку
    0
    Не знаю. Мне на кипрском интернете, что гигабит, что десять, что сорок — всё равно пинг за пределы острова не меньше 80мс.
  • Снова EA, снова NFS, снова баги. Чиним
    +1
    Прикрылись. Если буквально — то «возражают». Если по духу — «можно, пока не начинаете тырить в свою проект наш код».

    Вероятнее всего, они имели в виду, что если вы будете кому-то давать код проекта (проект), то он не должен включать в себя саму игрушку.
  • Снова EA, снова NFS, снова баги. Чиним
    +1
    Но вы используете их IP.

    Возможно, речь идёт про «не используете их IP с коммерческими целями». Это совсем другое.
  • Снова EA, снова NFS, снова баги. Чиним
    0
    Кстати, если они откроют исходники под ограниченной лицензией, это всё равно будет лучше, чем просто закрытые.
  • Снова EA, снова NFS, снова баги. Чиним
    +2
    Круто. Патчить любой ценой.

    А на месте EA я бы открыл сырцы. Ресурсы — как были, за деньги. А сырцы доступны.
  • Многозадачность или марихуана?
    +1
    Копирайтеры упали до такого. Блог IT компании? Гуманитарные рассказульки про многозадачность и мозгов для офисного планктона? Фу.
  • Как я переехал в ЕС: легализация, изучение языка, поиск жилья и работы
    +1
    Жители СНГ едут в Польшу,
    поляки едут в UK
    UK сваливает из Евросоюза
  • От Amazon EC2 до Mail.ru Infra: Тестируем облачные VPS (Linux)
    +1
    Поправка: в servers.com (т.е. ru) для облачных серверов нет шпинделей. За большие деньги мы можем вам такое сделать в приватной инсталляции, но за обычные деньги в servers.com на облачных серверах только SSD (с соответствующими попугаями по IOPS).
  • Ложные срабатывания. Новая техника ловли двух зайцев
    –1
    Досмотр в аэропорту — это ярчайший пример «безопасности» в полный рост. Безопасности не добавляет, а вот геморроя и очередей — безусловно.
  • Замок или Город
    +5
    Есть два вида архитектуры проекта:
    * плохая — в ней трудно разобраться, она требует внимания, она сложная и старая
    * хорошая — в ней легко разобраться, она не требует внимания, она простая и молодая.

    Хорошая архитектура хорошая, плохая архитектура плохая. Важно делать хорошую архитектуру в проектах, иначе она будет плохой. Плохая архитектура плохая.

    Опрос: какой вид архитектуры вам больше нравится:
    * Хороший
    * Плохой

    А информативности от статьи — ноль.

    Ах, да! Подумайте о детях!
  • Ложные срабатывания. Новая техника ловли двух зайцев
    +3
    Вся область ИБ (особенно, с «офицерами безопасности») пропитана унынием даже больше, чем бухгалтерия со своей 1С/SAP. Причина? Основная задача ИБ — мешать работать. По мнению «офицеров безопасности» — мешать работать злым хакерам и ворам, по мнению всех окружающих — мешать всем окружающим.
  • Неявность
    +2
    Когда говорят про неявность, подразумевают ровно одно: сайд-эффект грамматики не очевиден читающему, его трудно сформулировать кратким правилом, или он сильно зависит от рантайм-значений.

    Пример плохой неявности — приведение типов при сравнении (==) в javascript.
    Пример хорошей неявности — подстановка в метод класса self первым аргументом в python. (В нём есть пример хорошей явности — self явно объявляют в списке аргументов).
  • R как спасательный круг для системного администратора
    0
    А вот тут кто-то предлагает писать скрипты на хаскеле. Ура, сисадмины, семигрупоидным моноидом ударим по сегфолтам!

    www.linux-magazin.de/ausgaben/2012/05/shell-scripting-with-type-safety-using-haskell

    Люди играются с тем, что знают. Это не повод остальным бросаться и учить маргинальные технологии* по первому чиху.

    * маргинальные для системного администрирования.
  • R как спасательный круг для системного администратора
    0
    bash, perl и python используются в системном администрировании для множества других вещей.

    Я с трудом себе представляю crontab, делающий бэкап и отсылающий результаты, написанный на однострочнике 'R'.
  • R как спасательный круг для системного администратора
    +2
    Главная проблема состоит в том, что освоение R и системное администрирование — разные задачи, причём в разных «билдах персонажей». Человек, который много и хорошо знает R, либо overqualified для работы сисадмином, либо у него компетенция в R, а не в системном администрировании.
  • Лекции Технополиса. Проектирование высоконагруженных систем (осень 2017)
    +2
    Кстати, я погорячился.

    Во вступительной лекции всё-таки есть такое байкоподобное привирание/упрощение (для красоты), но общее направление хорошее, и следующие лекции идут по делу.

    Как оно в целом — скажу после того, как досмотрю.
  • Лекции Технополиса. Проектирование высоконагруженных систем (осень 2017)
    +2
    Я опирался на свой опыт работы в классических ДЦ, где на охлаждение уходит до 50% электричества. Более того, без продвинутых трюков вроде freecooling'а, чиллеров и т.д., на чистом фреоне с воздушным продувом, легко понять как это происходит. Если у нас сервера в закрытом (почти герметичном) помещении, и генерируют мегаватты, то теплообменом через стены можно пренебречь. Остаются активные системы охлаждения.

    Сервера, упсы, блоки питания и т.д. съели мегаватт. Куда он ушёл? В воздух вокруг устройств. Кто этот воздух охлаждает? Кондиционеры. Дальше я помню жалобы инженеров, что фактический EER для кондиционеров оказывается в районе 1 (т.е. для охлаждения мегаватта нужно потратить мегаватт на кондеи).

    Я сейчас погуглил, гугль говорит, что EER для бытовых кондеев от 2 до 3. Даже если предположить, что в ДЦ EER 3, то это 300 киловатт на охлаждение мегаватта. С учётом, что процессоры всё-таки греются, а КПД среднего БП в сервере в районе 98-99%, то большая часть электричества уходит всё-таки на нагрев потрошков материнской платы (и диски и т.д.).

    Более того, я не совсем понимаю, в каком месте в ДЦ происходит преобразование 12-110В. (я пропущу 110В, пусть 230).

    У нас на входе высоковольтная линия. Она проходит (чёрный ящик энергетиков) и мы имеем трёхфазное напряжение, проходящее bypass-модуль и входящее в UPS. ИБП пускает напряжение напрямую, но в случае аварии на входе, переключает его на локальную генерацию с дизелей, а пока дизели стартуют, на батарейки. КПД питания с батареек я пропущу, а в контексте питания от 380В, за вычетом того, что ИБП на себя берёт и на зарядку батарей, электричество идёт напрямую.

    Дальше оно по-фазно расходится на линии питания, где и уходит в БП.

    Где тут конверсия 230->12->24->230? Я знаю, что у телекомовых людей очень любят использовать 24 или 48 вольт для питания техники, но в современных ДЦ телекомовых людей (с телековомым оборудованием) почти не осталось.

    Потому мне и показалось странным, что на первый план выводят преобразования электричества.
  • Лекции Технополиса. Проектирование высоконагруженных систем (осень 2017)
    –3
    Я начал смотреть — вводная лекция полна ошибок. Лектор привирает/перевирает для нарратива похлеще экскурсовода (например, часть про PUE — вообще ахинея, т.к. львиная доля потерь приходилась/приходится на охлаждение, а он рассказывает про конверторы).
  • Смерть микросервисного безумия в 2018 году
    0
    Это, на самом деле, крайне интересный вопрос. Я осознал, что раньше под оркестрацией подразумевали регламент/протокол/соглашение, полностью описывающее всё взаимодействие сервисов. То есть это был термин уровня проектирования.

    А потом пришли инструменты оркестрации, и оркестрация из идеи в голове превратилась в конкретные yaml'ы, и сейчас оркестрация — это не только идея, но и её практическое воплощение. Средство оркестрации, описание этого взаимодействия в машиночитаемых (машиноисполнимых!) формах, etc.

    Примерно то же самое случилось с configuration management. Начиналось оно с идеи, а потом превратилось в конкретные проявляения конкретных софтин.
  • DCShadow — новая техника атаки на Active Directory
    0
    А потом на установке эксчейнжа могут быть замечательные сюрпризы, если пользователь имеет право менять схему, но не является локальным админом. А если является — то именно эту учётку и будут компрометировать.

    Алсо, нормальные «Администратор»'ы не сидят с админскими правами на рабочих машинах.
  • DCShadow — новая техника атаки на Active Directory
    0
    Очень узкая и специфичная атака.

    С учётом, что админ домена чаще всего может менять схему AD, вфигачить в схему объект нового типа, который может «логиниться» на компьютеры куда проще, чем изображать ценый контроллер домена.
  • Смерть микросервисного безумия в 2018 году
    +2
    Абсолютно валидная причина. Мы снижаем безумные расходы на железо увеличением расходов на обслуживание. На обслуживание расходы выросли чуть-чуть, а стоимость «просто серверов» по сравнению с «чудо-мейнфреймом» упала кратно. Это причина, достаточная для внедрения мультисервисной архитектуры.

    Я ж как раз про это и говорил — должна быть веская причина. Микросервисы без причины — признак дурачины.
  • Смерть микросервисного безумия в 2018 году
    0
    Я понимаю, что «иногда оно того стоит». Моя мысль была в том, что мультисервисная архитектура — это не бесплатно, и ожидаемая выгода должна превышать резко увеличивающиеся расходы (времени, внимания) на сопровождение. Если есть причина — да, конечно. Если микросервисы во имя смузи и хайпа — спасибо, нет.
  • Смерть микросервисного безумия в 2018 году
    0
    Вот вы и попались. Споратические таймауты от переполнения буфера из-за microbursts «лечить» не получится (см про идеальную инфраструктуру), можно только менять архитектуру, чтобы уменьшать их влияние.

    А в «монолите» таймаутов такого рода не будет, потому что это чистый код. Работа с СУБД — разумеется, да, но это как раз «отдельные места для side effects».
  • Смерть микросервисного безумия в 2018 году
    0
    Программисты решили проблему: они корректно обрабатывают таймаут. Теперь у нас новая проблема: спорадические таймауты на ровном месте. Кому от этого легче?

    Поскольку IPC по своей сути — это целиком и полностью использование side effect'ов, то перевод из вызова силами языка в IPC, это перевод чистого кода в код с side effect'ами. Что, традиционно, вызывает боль и проблемы.

    Чем более код остаётся в чистом виде (без side effect'ов), тем легче его сопровождать. Чем меньше у кода точек соприкосновения с side effect'ами, тем легче его администрировать.
  • Смерть микросервисного безумия в 2018 году
    0
    Вот это «An orchestration shows the complete behavior of each service» — очень точно. А насчёт того, что это «способ взаимодействия» — меня очень смущает, потому что это выглядит как описание сетевого протокола.
  • Смерть микросервисного безумия в 2018 году
    0
    Первый раз такое слышу. Это откуда такое?
  • Смерть микросервисного безумия в 2018 году
    +1
    Скажите, а если на сетевом интерфейсе лимит очереди 1000 пакетов, а в какой-то момент времени пришло 1030 и 30 из них дропнулись — это баг в сетевом окружении или в ПО?

    Шапкозакидательный подход (разработчик пишет идеальный код для идеального окружения работающего на идеальном железе) в индустрии не работает.
  • Смерть микросервисного безумия в 2018 году
    +1
    Есть альтернативный вариант: уменьшать количество IPC если это возможно. Меньше IPC — меньше моментов, когда очередной программист с удивлением узнаёт, что «гарантированная доставка TCP» не означает гарантированного времени или самой доставки, а гарантируется либо доставка, либо ошибка (в самом конце отправки сообщения длинного).
  • Смерть микросервисного безумия в 2018 году
    +1
    orchestration в хорошей реализации следит за всем lifecycle — то есть не только деплоит (запускает и конфигурирует), но подчищает после. «Управление» — слишком общий термин.
  • Смерть микросервисного безумия в 2018 году
    +2
    Для борьбы с in process issues существуют более богатые инструменты.

    IPC же может сломаться по совершенно эзотерической причине — превышение unknown unicast лимита на свитче, изменение алгоритма выставления don't fragment на туннелях, etc. Эти штуки требуют отдельной компетенции (не связанной с приложением).

    Получается, что тыкая IPC всюду, возможные баги в приложениях вытаскиваются на тот же уровень, на котором находятся сайд-эффекты внешнего мира. Это не только усложняет отладку, но и резко повышает требования к программисту, который отлаживает свой (кривой) IPC — он должен думать уже не только про структуры данных и архитектуру, но и про посторонние вещи, вроде ERD на роутере, глюков на агрегированных линках, кешей DNS, etc.
  • Смерть микросервисного безумия в 2018 году
    +3
    В обсуждении «микросервисной архитектуры» (уберите «микро» — просто «многосервисной») пропускают одну важную деталь. Чем больше у вас компонент, тем сложнее IPC. Исключением может быть приложение, в котором каждая компонента сама по себе и с друг другом они не взаимодействуют (пример: фен для волос и чайник).

    Если же взаимодействие есть, то тут есть простое правило: Inter-process communication сложнее, чем in process Communication. Причём, если ошибка передачи параметров внутри программы часто ловится компилятором/интерпретатором, то ошибки в IPC ловятся в махровом рантайме и погружают администраторов в потрошки внутреннего мира программы.

    Утрируя: если фабрика DSL'ей содержит баг, приводящий в ошибке интерпретации некоторых инструкций некоторых DSL'ей, то это чисто баг в программе.

    Если же фабрика генерации версионированных сообщений на DSL для IPC содержит баг, то это проблема админов, потому что у них один сервис с другим больше общаться не может.

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

    Потому что администратору иногда очень трудно понять какие тараканы были в голове у разработчика, когда он сделал «ТАК» (когда оно работает, то всё сделано хорошо, мы же баг обсуждаем, правда?).
  • IT-инфраструктура штабов Навального и сбор подписей: Жнец-2018
    +1
    Выглядит круто. Вы планируете сырцы и чертежи выкладывать?
  • Об отличниках на трезвую голову
    0
    А мой сарказм относится к тому, что вы своё ИМХО выдали за утверждение.

    С тем же успехом я могу начать авторитетно обсуждать виды трастов в английском праве. Моё видение есть? Есть. Надо им поделиться? Надо. Делимся. А что там будет ахинея и бред профана — ну кого это волнует-то?
  • Об отличниках на трезвую голову
    0
    А, никакого исследования не было. Видимо, вы цитируете чью-то научную работу? Или… нет, я, конечно, вас сильно обижу подозрением, но, вдруг, вы это всё «просто так написали», в режиме свободного полёта фантазии?
  • Об отличниках на трезвую голову
    +1
    Это не «кг/ам». Это указание на проблему — свалено в кучу множество характеристик от совершенно разных психотипов. Ну как шизоид может быть соревновательным? И как эпилептоид может углубляться в детали ради самих деталей?

    Если хотите конструктивной критики: в публикации не указаны источники, не приведены статистические данные проведённого исследования, не указаны параметры исследования.