• Business Insider: Microsoft ведет переговоры о покупке GitHub
    +1
    Даже на не бюджетном Samsung Galaxy S9+ хорошо заметно, что Skype самый задумчивый.
  • Laurel/Yanny: аудиоверсия сине-золотого платья
    0
    После нескольких минут в этом эквалайзере я одновременно слышу оба варианта в обычной записи, будто одновременно два разных человека говорит. Изначально было только «Яни». Любопытненько.
  • habrahabr.ru → habr.com
    +11
    Ох, как же мне не хватает аналога Хабра на английском. Буду болеть чтобы у вас всё получилось.
  • Устройство спецэффектов для игр под NES. Часть 1
    0
    Большое спасибо за статью. Приятно видеть статьи по такой исключительно гиковской тематике. Это вам не блокчейн, о котором и так везде говорят!
  • Устройство спецэффектов для игр под NES. Часть 1
    +1
    Ага, на dendy.migera.ru отличный справочник для начинающих программировать под Dendy. Я как раз им (наряду с wiki.nesdev.com) пользовался когда делал Unchained Nostalgia.


    Надеялся, что меня отпустит после этого, но нет, тянет иногда поковыряться. Есть что-то в низкоуровневом программировании под такие старые архитектуры что-то манящее =)
  • Особенности использования вещественных регистров x86 архитектуры
    0
    Интересно было бы почитать какие варианты предлагались, какие были у них плюсы или минусы по сравнению с тем что в итоге реализовал Intel.
  • Firefox Gecko, «который мы потеряли»
    0
    Собственно, весь интерфейс Firefox всегда и был сделан на том что вы сказали (JS, CSS для стилей, только XUL вместо HTML). Какого-то специального API для расширений не было, плагины просто лезли напрямую в код интерфейса, полностью опираясь на то как оно там устроено. Где-то какая-то переменная изменила своё название или смысл — и всё, расширение, которое на это опиралось, уже работает не совсем корректно. Это ещё половина проблемы. Вторая половина — изначально старые внутренние API браузера были синхронными. Например, можно было простым синхронным кодом залезть в DOM страницы в открытой вкладке. Такой код совершенно несовместим с подходом, когда вкладки и интерфейс выполняются в разных процессах. Реализовать совместимый синхронный API, конечно, можно — но это будет очень медленно. Ещё медленнее чем было, из-за появившейся необходимости меняться данными между процессами.
  • Прощание с «Небесным дворцом»
    +4
    Скорее всего алгоритм сжатия с потерями решил что эта звезда (рядом со станцией) не очень заметна глазу, и сжал весь блок как «тот же что и на предыдущем кадре, но со сдвигом», и так несколько раз.
  • Теория дряхлого ноутбука
    +3
    То-то я смотрю Skype долю свою теряет уже который год кряду. Мобильная версия всегда была ужасно тормозной. Десктопная версия была ещё терпимой, но тут они выкатывают свеженькую 8.x, которая — такой же тормозящий монстр, как и мобильная версия. Я то надеялся, что они пилят новую версию — это оптимизируют, хотят сделать быстрой и удобной. Но нет, похоже что руководство Microsoft думает, что люди бегут со Skype не из-за тормозов и багов, а из-за недостаточно яркой раскраски сообщений.

    Slack не использовал никогда. Судя по Google Trends, Telegram в 2 раза популярнее Slack. В моём окружении популярностью пользуются Viber (среди мам, пап и других родственников) и Telegram (среди более продвинутой аудитории). Некоторые контакты в Skype уже всегда неактивны. Чем-то напоминает ICQ, откуда когда-то люди активно мигрировали в Skype. Многие используют Skype только потому что он используется на работе, поэтому достучаться до человека через Skype можно только в рабочее время.

    Вы упомянули Netscape. Это тоже хороший пример. Он проиграл войну браузеров не потому что IE был встроен в систему (как много людей использует встроенный IE/Edge сейчас?), а потому что Netscape был тормозящим и глючащим монстром, а IE версий 5 и 6 был прорывным (сильно опережающим время, соответственно и станадрты) и быстрым браузером для своего времени, у которого просто не было адекватных конкурентов.
  • Boston Dynamics научила роботов помогать друг другу
    +1
    Другое видео (где человек мешает роботу открыть дверь) показывает, что степень автоматизма высока.
    Вы не сможете никак с джойстика управлять всеми сервоприводами робота чтобы он так двигался и сопротивлялся помехам.
  • Снова EA, снова NFS, снова баги. Чиним
    0
    Уже существует OpenNFS — попытка сделать открытый движок для The Need For Speed. К сожалению, до финиша проект так и не доведён (например, вообще нет обработки коллизий).

    Также можно вспомнить про Cry for Speed (и ещё вот) — попытка сделать ремейк Need For Speed III. К сожалению, проект совсем заглох, хотя и трудилось над ним несколько человек.
  • Снова EA, снова NFS, снова баги. Чиним
    0
    А куда вы вообще пишете? Я вот Need For Speed III: Hot Pursuit долгое время занимался. Я пытался связаться с разработчиками на предмет может у кого завалялись ранние беты с лучшим качеством ресурсов или отладочная информация. Без результата. Те кто ответили сказали что ничего от тех времён (1998 год) не осталось =) Заполучить исходники было бы пределом мечтаний.
  • Теневой бан и с чем его едят
    0
    Хм, теперь понятно почему мои сообщения всегда игнорировались на этом сайте. Остаётся разобраться чем я так провинился 5 лет назад при регистрации и можно ли снять этот «бан» без заведения новой учётки.
  • Я разработчик с 9 до 17 (и ты можешь стать таким)
    0
    Я вот ещё более странный типчик. Больше всего мне нравится взять бинарник игрушки или какой-нибудь древней софтины, расковырять его, изучить как оно работает, доработать, привести ближе к идеалу. Исследование бинарного кода (программы которая мне уже в чём-то симпатична) по эмоциям для меня сравнимо с тем как спелеолог находит и исследует совершенно новую и неизведанную ранее пещеру. Во время активной разработки Need For Speed III Modern Patch я полностью отказался от всякой коммерческой разработки на пару лет и жил исключительно за счёт своих сбережений. Потому что такое развлечение требует ну очень много времени. Было так увлекательно, что я часто забывал даже просто поесть. Два года пролетело будто всего неделя прошла. Кажется, потратил бы ещё лет 10 с удовольствием, да вот только сбережения закончились, пришлось остановить разработку и вернуться к работе :)
  • Основы кодирования аудио с потерями. Тестирование бета-версии Opus 1.3
    0
    Хоть и место жрет, но на больших колонках отчетливо слышно разницу между мп3-320 и лосслесс. И чем больше колонки, тем сильнее слышно.
    Исключая наличие у вас экстрасенсорных способностей, напрашивается предположение, что вы неправильно провели тест. MP3 320kbps (при верном кодировании) должно быть прозрачным, то есть неотличимым от оригинала на слух. Тест должен проводиться «в слепую», то есть вы не должны знать, в каком именно формате записано то, что вы слышите. При этом MP3 320kbps должен быть получен (при помощи LAME) из того же исходного файла, с которым потом будет производиться сравнение, чтобы гарантировать что используется одна и та же аранжировка, и что этот MP3 320kbps получен не из какого-нибудь MP3 128kbps, что встречается повсеместно в сети.
  • 640 КБ на самом деле хватит всем
    +1
    У вас в системе может быть некая софтина, которая внедряется во все процессы, и уже от их имени может что-нибудь запрашивать. Не так уж и много смысла писать вот такие вот заявления без подробного разбора «а что там было в адресном пространстве, что за данные передавались» и т.д., желательно с указанием на конкретный код, который что-то там передаёт (калькулятор не такой большой, можно и отреверсить).
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +3
    Вчитался в доку Spectre. 100% рабочего кода на JS там нет, но описания достаточно, чтобы его повторить. Тем более, что в конце дока есть рабочий код на C, демонстрирующий основную идею.

    Итого у нас есть возможность узнавать содержимое байтиков за пределами выделенного JS-массива. Его физический адрес мы не знаем, но изучив как JS-движок хранит переменные в куче, возможно где-то рядом с массивом мы сможем найти какой-нибудь указатель, который подскажет где мы вообще физически находимся. С этим, возможно, дальше будет немного проще плясать.

    Но вообще активная эксплуатация всё ещё выглядит сомнительной. Скорость «чтения» будет очень маленькой. Как я понимаю, даже пример на C читает где-то 1000-2000 байт в секунду. Всё адресное пространство не прочитаешь с такой скоростью за разумное время, явно нужно точно знать куда смотреть относительно того куда в памяти попал этот JS-массив.

    Плюс на 64-битных системах у нас вырисовывается ограничение, что мы можем «смотреть» только в окошко размером в 4 гигабайта, поскольку инты в JS 32-битные. Таким образом, использование Meltdown из браузера также сильно осложнено — весьма вероятно, что до интересных системных структур мы просто не сможем дотянуться, даже если сможем прикинуть где они относительно нашего массива находятся.

    Не в курсе как там в JS, а для выполнения WebAssembly на 64-разрядных системах слышал что намеренно резервируется адресное пространство размером в 4 гигабайта, потому что указатели внутри WebAssembly 32-разрядные, и уверенность что они не могут выйти за пределы своего окошка позволяет делать меньше проверок во время выполнения.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +4
    Проблема же не в JS.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +4
    Спасёт от теоретической возможности утечки данных чужих сайтов с использованием атаки Spectre из JS на каком-нить сайте. Разве что сам у себя сайт сможет что-то подглядеть случайно :)
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +3
    Meltdown и Spectre — разные уязвимости. Возможность что-то сделать из JS заявлена только для Spectre (и то, судя по всему, целенаправленно получить какие-то полезные данные именно с использованием JS там практически нереально). Для Meltdown такого не заявлено.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +7
    В моём изначальном сообщении, на которое вы ответили, я указал, что JS не даёт возможности обратиться за данными по произвольному указателю. Нет такой операции как класс. Вы привели пример совершенно не в тему, поскольку у вас запускается нативный код, у которого проблем с использованием произвольных указателей нет.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +3
    Во-первых, рабочего кода там нет. Там есть только вот эти 5 строк, которые лишь маленький кусочек необходимого кода (содержимое остального кода там описано словами и очень примерно):
    if (index < simpleByteArray.length) {
        index = simpleByteArray[index | 0];
        index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0;
        localJunk ^= probeTable[index|0]|0;
    }
    Во-вторых, чтение памяти своего процесса (где живёт вкладка) и получение дампа всей системной памяти — разные вещи. В-третьих, не заявлено, что можно целенаправленно прочитать всю память своего процесса из JS. Как я вижу, с использованием этой методики максимум могут быть сделаны выводы о содержимом каких-то случайных блоков памяти своего процесса, в зависимости от того куда при выполнении JS была физически помещена переменная массива.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +3
    Ваш пруф явно выполняется не в браузере.
  • CPU сдаст вас с потрохами: самая серьезная дыра в безопасности за всю историю наблюдений?
    +4
    Пожалуй, самое вероятное и неприятное применение на данный момент — получение дампа системной памяти во время выполнения JavaScript.
    Больше похоже на заявление от представителей жёлтой прессы. Низкоуровневые операции (типа получения данных по произвольному указателю), которые скорее всего будут нужны для эксплуатации уязвимости, из JS недоступны. В общем, или покажите рабочий пруф, или не распространяйте сомнительную информацию и не нагнетайте бесполезную панику.
  • Как писать на ассемблере в 2018 году
    +3
    Обычно (если явно не указано) подразумевается x86. Это как Default City =)
  • Как писать на ассемблере в 2018 году
    0
    FASMG в принципе можно обучить собирать под любую платформу, потому что набор инструкций там — это просто макросы. То есть x86 и всё остальное там реализовано просто наборами макросов. PE-файлы и таблицы релоков тоже формируются на макросах.
  • Как писать на ассемблере в 2018 году
    +1
    Дешевеет уже давно не так стремительно как раньше, и со временем будет дешеветь всё меньше.

    Впрочем соглашусь, что за исключением очень редких случаев, писать прямо на асме нет смысла.
  • Rust vs. C++ на алгоритмических задачах
    +6
    Вы опять мимо. Quantum Render — это не про поддержку каких-то свойств в CSS. Это более низкоуровневый компонент, который браузер использует для «сборки» конечной картинки. Цитата:
    The goal of the Quantum Render project is to take the WebRender compositor in Servo and embed it in Firefox. It will replace Gecko's existing compositor, interfacing with Gecko's main-thread layout code. As WebRender is written in Rust and uses a very different design approach, we expect to get stability and performance benefits from this switch.
    Вам стоило бы немного немного разобраться в тех вещах, о которых вы пытаетесь говорить. На этом я завершаю разговор с вами, ибо уже очевидно, что продолжать его нет смысла.
  • Rust vs. C++ на алгоритмических задачах
    +2
    UTF-8 как локаль для консоли не работает по-моему до сих пор. Но утверждать не буду.
    Кстати, в Microsoft рассматривают вариант обучения рантайма работать в UTF-8. И вы можете поставить свой голос там (и тут тоже). Идеальным был бы вариант, если бы ещё и все *A функции из Win32 API научились бы понимать UTF-8 как одну из локалей (которую программа выбирает сама себе при загрузке, например). К сожалению, сильно надеяться на такой вариант расширения Win32 API не приходится.
  • Rust vs. C++ на алгоритмических задачах
    +6
    Во-первых, по ссылки ничего не написано про firefox — и это ясно и понятно, ведь вы ничего мне не показали, и не покажете. Во-вторых, что за привычка такая — болтать и не показывать?
    Похоже, что вы всё же не читали что там написано. А там чётко сказано:
    This is the first big technology transfer of Servo tech to Firefox. Along the way, we’ve learned a lot about how to bring modern, high-performance code written in Rust into the core of Firefox.
    We’re very excited to have this big chunk of Project Quantum ready for users to experience first-hand. We’d be happy to have you try it out, and let us know if you find any issues.
    Более того, в описании новшеств Firefox 57 также чётко упоминается, что Quantum CSS уже в Firefox:
    Firefox's new parallel CSS engine — also known as Quantum CSS or Stylo — is enabled by default in Firefox 57 for desktop, with Mobile versions of Firefox to follow later on. Developers shouldn't notice anything significantly different, aside from a whole host of performance improvements.

    По второй ссылке, где описывается следующий компонент, почти готовый к внедрению (Quantum Render), чётко сказано, что оно ещё не в релизе, но войдёт в него в скором времени:
    But there’s another big piece of Servo technology that’s not in Firefox Quantum quite yet, though it’s coming soon.
    Не вижу причин не верить Mozilla и здесь.

    Я уже сказал, что серво не умеет в css
    Как же он тогда работает? Quantum CSS не занимается рендерингом вообще. Он занимается разбором CSS и быстрыми ответами на вопрос какие из правил применимы к каждому из тысяч элементов на каждой странице. Это всё что он делает. Если демка Servo (которая действительно очень сыра) не может отрендерить какое-то правило правильно — это не вина этого компонента. Он не отвечает за это.
  • Rust vs. C++ на алгоритмических задачах
    +1
    Думаю, если задаться целью, то можно станцевать как-нибудь так, и таки получить возможность устанавливать старые расширения в обычных релизных версиях браузера.
  • Rust vs. C++ на алгоритмических задачах
    +2
    Это всё равно не скажется на производительности.

    Во-первых, менеджер памяти может выгружать из RAM неиспользуюмую память только страницами, по 4 килобайта. То есть если по коду разбросано много вот таких вот блоков «if», и все они не слишком велики — то большая часть этого кода всё равно будет оставаться в памяти.

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

    К слову, этот код загрузки старых расширений на самом деле даже не отключён. Это я дезинформировал вас. Он работает. Ему просто запретили загружать пользовательские расширения. А вот расширения, подписанные самой Mozilla (не addons.mozilla.org!) — работают, и Mozilla этим пользуется для расширений, которые нельзя сделать средствами WebExtensions. Подробности вот тут, смотрите «legacy extension», как видите даже в обычных релизах они доступны, но только для расширений от самой Mozilla.
  • Rust vs. C++ на алгоритмических задачах
    +9
    Обе ссылки про Firefox. Mozilla переносит некоторые наработки из Servo в Gecko, и обозвали этот проект Quantum. Если бы вы прочитали хоть немного то что по ссылке, то поняли бы, что это это не только про парсинг. Это ещё и про быстрый ответ на вопрос «нужно ли применять это правило для этого вот элемента?», которое браузер задаёт этому движку CSS каждый раз при каждом рендеринге любого элемента на странице. Там же объясняется почему этот процесс не так тривиален, как кому-то могло бы показаться.
  • Rust vs. C++ на алгоритмических задачах
    +1
    Ну да, 65535 кодпоинов оказалось маловато. В последнем стандарте уже 136755 символов. Текущая схема кодирования UTF-16 позволяет использовать до 1112064 кодпоинтов.
  • Rust vs. C++ на алгоритмических задачах
    +6
    Вы не следите за развитием Firefox, поэтому делаете такие неверные выводы. Они переделывают движок.

    hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo
    hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank

    Старые расширения имели доступ ко всем потрохам браузера (никакого стабильного внешнего API не было), и это связывало разработчикам браузера руки. Поэтому сейчас, во время больших внутренних изменений в браузере, они отключили поддержку старых расширений. На самом деле она ещё имеется в браузере, и в ночнушках (и Developer Edition) можно активировать её обратно. Но разработчики сейчас активно выпиливают старые технологии из браузера. Например, вот прогресс по выпиливанию XBL-компонентов из браузера. Как видите, подавляющее большинство всё ещё на месте. Такие изменения не делаются за одну ночь. Тут возможно на несколько лет работы. Но на данный момент поддержка старых расширений отключена искусственно. Код их поддержки и всех соответствующих технологий (XUL, XBL) всё ещё в браузере. Впрочем, это не они замедляли работу браузера. Их выпиливают просто для унификации и упрощения движка. XBL заменяют на стандартные Web Components, а XUL заменяют на HTML. Вот когда XBL и XUL не останется внутри кода интерфейса браузера — тогда их поддержку можно будет убрать из кода движка. Но это случится не так скоро.
  • Rust vs. C++ на алгоритмических задачах
    +3
    А вот 50% времени разработки на 50% скорости — редкость. Тому же скайпу 50% не помогут — он все равно будет тормозить.
    Если прирост производительности будет 50% за год разработки даже с 75% замедлением появления новых фишечек из-за этого, то глядишь за столько лет сколько он тормозит — им стало бы приятно пользоваться. И кто-то даже может быть начал бы рассматривать его как адекватный мобильный IM. А тормозит он с самого появления в 2010 (говорю про версию под Android).
  • Rust vs. C++ на алгоритмических задачах
    +6
    Не вижу причин, почему UTF-16 мог бы быть оптимальнее. С первыми версиями стандарта Unicode казалось, что UTF-16 удобнее, потому что один кодпоинт гарантированно занимал 2 байта. Можно было легко получить длину строки из количества занимаемых ей байт, нельзя было случайно обрезать строку посреди символа. Но так как теперь один кодпоинт в UTF-16 может занимать и 4 байта, то эти преимущества исчезают. Зато появляется зависимость от порядка байт и повышенный расход памяти.
  • Rust vs. C++ на алгоритмических задачах
    +1
    Я лично сравнивал Firefox 52, PaleMoon и Firefox 57. Всё без расширений. Firefox 57 был ощутимо проворнее. Обратное, думаю, можно будет увидеть на слишком старых машинах — требования к RAM, конечно же, несколько подросли. Накладные расходы на поддержку нескольких процессов.
  • Rust vs. C++ на алгоритмических задачах
    +6
    Если важно именно как можно скорее выкатить продукт — то можно оптимизацию отложить на потом. Если же продукт уже на рынке, и выполняет свои задачи, то можно потратить время и на оптимизацию. Facebook писался сразу на обычном PHP, а потом они начали вкладывать деньги штуки типа HHVM для оптимизации. Последние версии PHP также гораздо быстрее предыдущих — разработчики потратили немало времени на оптимизацию. Правда, конечные веб-разработчики часто съедают возросшую проворность PHP использованием тяжёлых фреймворков.

    Хороший антипример: Skype на мобильных платформах. Он похож на неповоротливого монстра. В итоге этим IM я практически не пользуюсь на телефоне. Только при крайней необходимости запускаю, и каждый раз это боль. Кажется, я не один такой: на мобильных платформах популярны совершенно другие IM, которые гораздо более шустры. И все они появились гораздо позднее Skype.
  • Rust vs. C++ на алгоритмических задачах
    +8
    Сама Mozilla, которая развивает Rust, сейчас тратить немало денег на оптимизацию и переписывание своего браузера. Firefox 57 реально ощутимо проворнее Firefox 52. Впереди ещё много работы в этом направлении. Может быть, это поможет Mozilla предотвратить потерю пользователей, которая происходит уже много лет. Браузер пишет, скажем, 50 разработчиков. А пользуются миллионы.

    Любой код, который выполняется на миллионах машин, имеет смысл оптимизировать даже на самом низком уровне, под конкретные архитектуры и наборы инструкций. Например, libjpegturbo — оптимизированный декодер JPEG — спонсируется и используется Mozilla, Google и рядом других компаний. Наблюдаю за разработкой Opus. Периодически вижу, что разработчики (помимо повышения качества кодирования) отдельно занимаются оптимизацией кодека даже для конкретных наборов инструкций конкретных процессоров (SSE, AVX и т.д.), сейчас проект спонсируется Mozilla. В разработке видеокодек AV1 — более десятка гигантов мира IT собралось для того, чтобы сделать самый лучший в мире видеокодек. И уж поверьте, без вкладывания денег в оптимизацию оно не обойдётся. Миру нужен эффективный кодек, который и жмёт хорошо, и за разумное время.

    Всё зависит от задачи. Если вы пишете сайтик — его можно и на PHP написать, и то что код на этом языке, грубо говоря, в 100 раз медленнее — не так страшно, так как основной тяжёлый код (та же БД), который будет выполняться — всё равно достаточно оптимальный код на C/C++. Вот код той же MySQL имеет смысл оптимизировать. Если бы её можно было бы магически ускорить на 50% — этим стоило бы заняться. Потому что 50% ускорение для такой штуки — это реально очень много и ощутимо. Выигрыш от такой оптимизации сложно оценить в цифрах, потому что от неё по сути выиграли бы вообще все. Проспонсировать такую оптимизацию мог бы кто-нибудь, кто сам очень активно использует эту БД, и хотел бы в первую очередь сократить свои расходы на сервера, а польза для остального мира — это уже как бонус.