Разработчики проекта Mozilla объявили (https://groups.google.com/forum/#!topic/mozilla.dev.servo/dc...) о намерении сформировать в июне первый альфа-выпуск нового браузерного движка Servo (https://servo.org/), написанного на языке Rust, а также построенного на базе данного движка web-браузера Browser.html (https://github.com/browserhtml/browserhtml) с интерфейсом на базе технологий HTML5. В качестве основных критериев готовности Servo рассматривается обеспечение качественной обработки сайтов github, duckduckgo, hackernews и reddit, которые в целом уже работоспособны в Servo, но полностью не лишены отдельных нерешённых проблем с отрисовкой и функциональностью.
Напомним, что браузерный движок Servo (https://github.com/servo/servo/) развивается проектом Mozilla в сотрудничестве с компанией Samsung. Движок написан на языке Rust и отличается поддержкой многопоточного рендеринга web-страниц, а также распараллеливанием операций с DOM (Document Object Model). Текущий браузерный движок Firefox не может в полной мере задействовать потенциал современных многоядерных систем из-за изначального использования однопоточных схем обработки контента. В частности, при обработке одной страницы однопоточным остается связанный с DOM (Document Object Model) внутренний API, функции формирования содержимого окна, парсинга HTML и выполнения JavaScript. Использование Rust позволяет разбить код DOM и рендеринга на более мелкие подзадачи, которые могут выполняться параллельно и более эффективно использовать ресурсы многоядерных CPU. Кроме эффективного распараллеливания операций, используемые в Rust технологии безопасного программирования позволяют кардинально поднять уровень безопасности, решив текущие проблемы с безопасностью.
Интерфейс Browser.html примечателен отказом от использования традиционных панелей со вкладками и адресной строкой. Страница занимает всё экранное пространство. В верхней части выводится небольшая панель с базовыми управляющими элементами, адаптивно меняющая своё назначение - например, при подведении курсора предоставляется возможность ввода нового адреса, а в остальное время показывается заголовок текущей страницы. При прокрутке страницы панель исчезает из области видимости. Информация о вкладках выводится в форме блока кнопок с пиктограммами сайтов, всплывающих только при подведении курсора к верхней части экрана.
Дополнительно можно отметить появления ещё одного крупного проекта на языке Rust - компания Dropbox внедрила (http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz.../) новое распределенное облачное хранилище Magic Pocket, в которое уже перенесена (https://blogs.dropbox.com/tech/2016/03/magic-pocket-infrastr.../) основная масса данных Dropbox, ранее хранимых в облачном сервисе Amazon S3. Главными целями миграции являются желание увеличит производительность (обращение к публичному облаку рассматривается как узкое место) и снизить издержки за счёт поддержания собственной оптимизированной для своих нужд серверной инфраструктуры. Изначально реализация хранилища была написана на языке Go, но показала низкую эффективность с точки зрения потребления памяти при больших нагрузках. Переход на Rust позволил существенно сократить потребление памяти.
URL: https://groups.google.com/forum/#!topic/mozilla.dev.servo/dc...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44044
Хорошая новость. А разработческие сборки есть, чтобы уже сейчас посмотреть? Пусть даже неработоспособные.
https://github.com/browserhtml/browserhtml
Только смотреть там откровенно не на что
а запускаться без открытия слущающего socket-порта -- оно умеет ли?
ХЗ, спроси у девелоперов. Писать интерфейс на node.js - верх маразма
Ну vivaldi же работает, работает. Atom работает, работает. Вполне себе рабочее решение. Так что маразмом это уже не назовёшь.
Вот только ни вивальди, ни атом не используют ноду...
Тыц https://atom.io/, читаем Under the hood и тыц https://vivaldi.com/, читаем веб-технологии...
Лучше иной раз промолчать, чем лепить что не знаешь.
>web-браузера Browser.htmlА в каком браузере будет открываться этот html-браузер?
Ну так firefox :D
Как я понял, от собственно браузера остаётся только ядро на Rust. А весь GUI строится на HTML5 и JS.
Интересно поглядеть, что из этого получится, т.к. ИМХО позволит Mozilla сосредоточится на Servo как таковом, не напрягаясь с XUL и т.д. плюсом получается практически даром одинаковую работу на любой платформе (HTML жеж).
одинаково плохую работу на любой платформе (HTML жеж)
> одинаковую работу на любой платформеА что -- HTML через магию чтоль показывается на экране?
А -- загрузка файлов, webgl, desktop нотификации , ды хоть даже отрисовка шрифтов!
А всем вот этим не движок занимается, которым предполагает быть servo? Интерфейс предполагается сделать на html, не весь же браузер в самом деле. Будем посмотреть, что из этого получится.
В самом себе
>интерфейсом на базе технологий HTML5Vivaldi
>Страница занимает всё экранное пространство. В верхней части выводится небольшая панель с базовыми управляющими элементами, адаптивно меняющая своё назначение
Yandex.Труселя
Натырили идей из других браузеров.
Ты что в яндексе целая команда трудилась год над фишками и идеи сами придумывали.
Теперь ждём когда клиент Dropbox перепишут на Rust.
На самом деле, они просто не хотят платить хостеру за перерасход траффика и вычислительных мощностей, который получается из-за роста аппетитов при копании в пользовательских данных.
Привет Кандализе Райз :)
>>Интерфейс Browser.html примечателен отказом
>адаптивно меняющая своё назначение
>всплывающих только при подведении курсораЯ тут долго расписывал маты, а потом подумал: "А кому они нужны?".
Остаётся надеяться,что из-за html-ной сущности интерфейса нормальные люди быстро приведут его в юзабельное состояние когда одни и те же кнопки отвечают за одни и те же действия и находятся в одних и тех же местах. И когда ничего не мигает, перерисовывая страницу из-за вечно уезжающих панелей с важной информацией.
>>Изначально реализация хранилища была написана на языке Go, но показала низкую эффективность с точки зрения потребления памяти при больших нагрузках. Переход на Rust позволил существенно сократить потребление памяти.Вот это новость :)
Тоже удивило. Ещё б деталей бы. Какая версия Go была? Сколько смогли памяти сэкономить? Насколько изменилась производительность?
Для большинства программистов и решаемых ими задач выигрыша у Rust по сравнению с Go не будет. Причины использования:
Primarily, for this particular project, the heap size is the issue. One of the games in this project is optimizing how little memory and compute you can use to manage 1GB (or 1PB) of data. We utilize lots of tricks like perfect hash tables, extensive bit-packing, etc. Lots of odd, custom, inline and cache-friendly data structures. We also keeps lots of things on the stack when we can to take pressure off the VM system. We do some lockfree object pooling stuff for big byte vectors, which are common allocations in a block storage system.
It's much easier to do these particular kinds of optimizations using C++ or Rust.
In addition to basic memory reasons, saving a bit of CPU was a useful secondary goal, and that goal has been achieved. The project also has a fair amount of FFI work with various C libraries, and a kernel component. Rust makes it very easy and zero-cost to work closely with those libraries/environments.Также новость скромно умалчивает о том, что Dropbox использовала Rust для одной единственной подсистемы:
Actually, full disclosure, we really just rewrote a couple of components in Rust. Most of Magic Pocket (the distributed storage system) is still written in golang.
При этом
- Python is our primary development language for most stuff at Dropbox.
- Mobile development and UI code use whatever is appropriate for each platform.
- Go is the primary language for Infrastructure, meaning fairly deep-backend stuff: databases, storage systems, message pipelines, search indices etc.
- Rust is used on Magic Pocket (which is within Infrastructure).
То есть Rust - это новый c++? Однако круто.
Также как Go, Swift и D
Ни один из них не является универсальной заменой, но каждый хорош по-своему. Вряд ли один из них заменит С++ полностью, скорее каждый из них потеснит С++ и Java в одной из занимаемых ими ниш, но друг другу они при этом особо мешать не будут.
Отдельно стоит заметить, что в отличии от трех других Rust может быть заменой не только плюсам, но и чистому С.
>Ни один из них не является универсальной заменой, но каждый хорош по-своему.Правильный вариант:
>Ни один из них не является универсальной заменой, но каждый плох по-своему.
Ну начни с рассказа о том, чем плох Rust в сравнении с плюсами.
Когда Rust++ выпустите, тогда и сравним.
> Когда Rust++ выпустите, тогда и сравним.Ответ пустозвона и демагога
> Ну начни с рассказа о том, чем плох Rust в сравнении с плюсами.На плюсах можно программировать даже микроконтроллеры, чем ардуина и занимается. Покажешь такое на rust? Универсальность и масштабируемость инструмента - это хорошо.
Ну да, такого полно на Rust.
Я этим сам не занимаюсь, но в обсуждениях постоянно пробегает успешная работа чуваков в этой области. Вот, например, про ардуину: https://github.com/jensnockert/dueboot/blob/master/README.md
Вот операционка: https://github.com/redox-os/redox
Вот страничка-коллектор проектов: https://github.com/flosse/rust-os-comparisonНадеюсь, я не зря перед вами это расписываю и вы действительно интересуетесь.
golang - не оттуда. В отличие от других - упор на простоту, а не мощь.
Ну если плюсы для тебя это только complexity, которую ты именуешь мощь, то мои соболезнования.
> Ну если плюсы для тебя это только complexity, которую ты именуешь мощь,
> то мои соболезнования.Это и есть мощь. На C++ можно написать что-нибудь требовательное к латенси и скорости. Например, игровой движок. На go нельзя - сборщик мусора не отключается, что гарантирует море удовольствия при борьбе с внезапными лагами. Программированием требовательных вещей занимаются люди с высокой квалификацией, им c++ как раз по руке.
> Это и есть мощь.Мощь - это единственное число слова "мощи".
в отличие от swift? ну-нуgolang и правда не оттуда но из-за csp model
>>golang и правда не оттуда но из-за csp modelЕго скорее к Джаве, относить/сравнивать
"Go" не уникален - https://www.cs.kent.ac.uk/projects/ofa/jcsp и у него так же есть GC
От go они не отказывались, есть ответ от разработчиков на hn. Просто переписали пару мест на расте, где критична работа с памятью. Вся остальная инфраструктура как и была на Go, на нем и останется, ничего переписывать разработчики не собираются.
Похоже пришла пора обратить внимание на Rust.
У него чудовищный синтаксис и логика работы с памятью.
Rust такое же ненужно как и Go, если Firefox и в самом деле когда-нибудь на него переведут, то этот день станет последним днём когда я использовал Firefox.
Ох ну твое мнение очень ценное для Mozilla. А еще они спят и видят, как бы сделать так, чтобы ты пользовался их браузером.
>если Firefox и в самом деле когда-нибудь на него переведутТо это уже будет не firefox, будем рнадееться что palemoon не загнется иначе один гобный браузер(Opera) мы уже потеряли, потеряем firefox и останется только qupzilla, которая не умеет нормальный adblock и vim-like управление
Ну про паленную лисицу смешно упоминать - это пары фурфагов проект, полностью зависящий от основного проекта фурифокса. Не загнуться он по определению не может.
Они движок форкнули, кабыла, в результате загнутся только если не кому будет его поддерживать.
> Они движок форкнули, кабыла, в результате загнутся только если не кому будет его поддерживать.Сам по себе форк - это элементарное действие.
Поддерживать форкнутый проект, когда есть Большой Брат, у которого можно 'тырить' код - посложнее, но вполне нормально.
Самому тянуть лямку по развитию движка - кхе, кхе...
Так что в недалеком будущем у паленной лисицы просто нет вариантов кроме загибания.
PS: Хотя у некоторых понятие живости отличается, некоторые и opera presto вполне себе щас пользуются.
Он загнется, т.к. его изначально "некому" поддерживать.
https://github.com/MoonchildProductions/Pale-Moon/issues/154
Хорош трындеть, иди ищи утечки в плюсовом коде.
> Хорош трындеть, иди ищи утечки в плюсовом коде.Сборка с -fsanitize=address поймает неправильную работу с памятью, -fsanitize=leaks - утечки. Си++ языка такая сложная, насяльника.
И будет браузер на Servo ещё активнее выжирать системные ресурсы. Лучше уж lynx.
Что лучше - отжирание одного ядра на 100% в течение 4 секунд, или отжирание 4 ядер по 25% в течение одной секунды? Это если не учитывать, что рендеринг в серве весь полностью на гпу, что даст ещё больший выигрыш. В итоге, оно ещё и жрать меньше ресурсов будет.
Такая математика справедлива в случае относительно статических страниц, когда браузер отрендерил страницу - и всё. А если контент на странице динамический и активно обновляет те или иные части страницы? Теперь же его распараллелят и у него будет больше возможностей жрать системные ресурсы.
Просто не заходи на такие сайты, и всё, логика предельно проста. Браузер должен выводить информацию, которую запросил пользователь с максимальной эффективностью. Не устраивает, можешь сам ограничить число потоков. Это делается в диспетчере задач в 3 клика.
> Просто не заходи на такие сайты, и всёЯ-то могу и не заходить. А вот другие юзеры потом будут плакать над трупами железа, которое склеило ласты раньше времени от того, что параллельно рядом с ресурсоёмкими сайтами в браузере на движке Servo работала куча других ресурсоёмких задач: DE, LibreOffice, Scilab, systemd, pulseaudio, Network Manager,... и т.д. Всё это вместе теперь сможет разогреть разного рода ноута до таких температур, что никакие системы охлаждения не помогут.
Нефиг покупать непонятно какое оборудование или заниматься моддингом не имея бошки и прямых рук из правильного места.
> Что лучше - отжирание одного ядра на 100% в течение 4 секунд,
> или отжирание 4 ядер по 25% в течение одной секунды?А еще лучше уроки не прогуливать ...
1 * 100/100 * 4 = 400/100 = 4
4 * 25/100 * 1 = 100/100 = 1
Так зайди в школу на урок информатики, пусть тебе объяснят, что такое распараллеливание задач. 100% на 4 секунды = 25% за 1 секунду в одном потоке. Если по 25% раскидать на каждое ядро, то эти задачи будут выполняться одновременно, то есть все 100% будут исполнены за время, обратно пропорциональное количеству ядер.
> Так зайди в школу на урок информатики, пусть тебе объяснят, что такое
> распараллеливание задач. 100% на 4 секунды = 25% за 1 секунду
> в одном потоке. Если по 25% раскидать на каждое ядро, то
> эти задачи будут выполняться одновременно, то есть все 100% будут исполнены
> за время, обратно пропорциональное количеству ядер.Ты не юли – речь шла о
> отжирание одного ядра на 100% в течение 4 секунд,
> или отжирание 4 ядер по 25% в течение одной секунды?Объясняю на пальцах:
Допустим, ядро может делать 100 операций в секунду.
100 * 4 = 400. И того: всего 400 операций за 4 секунды на одном ядре.Ежели раскидать эти 400 операций на 4 ядра, получим 100 операций на ядро.
Очевидно же, что при выполнении 100 операций в секунду 4 ядра смогут сделать в сумме 400 операций за эту самую секунду. Но только при полной "загрузке" .
Если 4 ядра будут "делать" (уделять этой задаче) только 25 операций в секунду, то за 1 секунду, в сумме это будет 100 (сто) операций, а значит, делая по 25 (из 100 возможных) операций в секунду 4м ядрам понадобятся 4е секунды для выполнения той же работы (400 операций).
А теперь марш уроки делать.
> Что лучше - отжирание одного ядра на 100% в течение 4 секунд,
> или отжирание 4 ядер по 25% в течение одной секунды?Вот извините, но будет нагрузка 400% на 1 секунду. Т.е. 4 ядра занятых на 100%.
> что даст ещё больший выигрыш. В итоге, оно ещё и жрать меньше ресурсов будет.
Как бы не так. Кривые или просто наглые сайты озадачат все 4 ядра и GPU, по поводу чего система превратится в отопитель воздуха или на ноуте - батареи хватит на 2 часа браузинга вместо 8.
Хром уже создает новый процесс под каждую новую вкладку, нагрузка в которых естественно может пойти на другое CPU-ядро и GPU.
Servo же просто уменьшит время на обработку новой вкладки браузера распаралелив её обработку, что судя по тестам в 2 - 2,5 раза быстрее Хрома, и ресурсы быстрее будут особожденны.
Звучит так, как будто бы это плохо
Vivaldi бы вливались тоже, уже два года бьются над блинком, а показатели по памяти и скорости не сдвигаются абсолютно..., может только в худшую сторону
Што. Откуда два года?
Плюс ты бы за проектом последил, прежде чем ныть. Разработчики открыто заявляли что оптимизациями не занимаются на текущей фазе разработки. Man преждевременные оптимизации.
>Man преждевременные оптимизацииАга, у некоторых они по жизни преждевременные.
> Ага, у некоторых они по жизни преждевременные.Выпадение генов - случается, увы.
> преждевременные оптимизации."Преждевременные оптимизации" - баян, общепризнанный брехней и давно устаревший, как и сам баян. Из всех, кто писал мне эту фразу в интернете, никто не понимал её истинный смысл. Все воспринимают ее поверхностно, включая Вас. А ведь актуальна она <u>только в единичных</u>, частных ситуациях. И эти ситуации сконцентрированы на стадии проектирования, которую все браузеры на блинке давно прошли.
А ничего, что Вивальди еще на стадии проектирования? Может это ты все-таки не понимаешь, а не я?
> Man преждевременные оптимизации.Man преждевременные
Кто-нибудь знает, на что в блинке память уходит?
Я так понимаю на безопасность и многопоточность. Каждая страница имеет свою песочницу с высокой степенью изоляции, что накладывает ограничения на совместно используемые страницы.
По логике большая часть ресурсов (по объему) абсолютна безопасна и такие ресурсы не должны дублироваться, а должны шариться между потоками. Например зачем теже изображения и шрифты дублировать в памяти?
>В качестве основных критериев готовности Servo рассматривается обеспечение качественной обработки сайтов github, duckduckgo, hackernews и redditНу юмористы
А чего смешного. Типичный повседневный набор сайтов обычного пользователя. Все остальные -- либо на safari, либо на edge
Слишком тонко)
Как обычно, что-то пошло не так:
http://rghost.net/8mtnHyBl5/image.png
> http://rghost.net/8mtnHyBl5/image.pngКонечно же виноват servo, который находится в зачаточном виде и который просто обязан знать, что в soviet russia опеннет вместо православного юникода отдаётся в koi8-r.
Конечно
>> http://rghost.net/8mtnHyBl5/image.png
> просто
> обязан знать, что в soviet russia опеннет вместо православного юникода отдаётся
> в koi8-r.Content-Type? -- Не, не слышал.
$ curl -I opennet.ru
HTTP/1.1 200 OK
Server: nginx/1.0.9
Date: Tue, 15 Mar 2016 09:10:47 GMT
Content-Type: text/html; charset=koi8-r
Connection: keep-alive
Vary: Host
Accept-Ranges: bytes
То есть это чудо даже самых базовых вещей толком не умеет. Однако успех.
А они базовые? Разрабы считают, что сайты не в utf-8 должны страдать.
> То есть это чудо даже самых базовых вещей толком не умеет. Однако успех.Защищенный язык защищает от ошибок жеш.
А ещё и код сам собою пишется...
> То есть это чудо даже самых базовых вещей толком не умеет. Однако успех.Потому что движок рендеринга и парсинга дома, который находится в состоянии глубокой преальфы не должен обладать способностями полноценного браузера, чтобы исполнять свою задачу - рендерить и парсить дом.
Ну так для них это очень второстепенная задача. Им github и остальные сайты (utf-8) хочется сделать. Если пришлёшь патчи - они будут рады.
> Content-Type? -- Не, не слышал.Здрасьте. Этих кодировок несколько сотен
http://www.iana.org/assignments/character-sets/character-set...
Браузер не обязан их всех поддерживать. Тем более для такого сырого браузера вполне простительна не поддержка маргинальной koi8-r (есть куда важные задачи для разработчиков, чем это)
>Mozilla в сотрудничестве с компанией SamsungСодом и Гоморра
>Интерфейс Browser.html примечателен отказом от использования традиционных
Ценностей, таких как управление клавиатурой и горячие клавишы.
Теперь будете работать
>...только при подведении курсора
если ты не в курсе, то можно слушать ивенты и от ввода с клавиатуры, и даже тач. обработку.
сделают хоткеи. - пиши тикет на какую комбинацию и проверяй
>использования однопоточных схем обработки контентаОблажались.
GTK+ использует? Если да, то супер!
Спешу тебя разочаровать.
в тексте, или на форумах пишут что будут выкладывать в opensource свои наработки со временем.
Надеюсь, вы не о Servo? https://github.com/servo/servo
> Изначально реализация хранилища была написана на языке Go, но показала низкую эффективность с точки зрения потребления памяти при больших нагрузках, после чего хранилище было переписано на Rust.Эх, жаль, что не open source. Так был бы неоценимый бенчмарк из реальной жизни! И можно было бы спрофайлить, где подпилить Go.
>> Изначально реализация хранилища была написана на языке Go, но показала низкую эффективность с точки зрения потребления памяти при больших нагрузках, после чего хранилище было переписано на Rust.
> Эх, жаль, что не open source. Так был бы неоценимый бенчмарк из
> реальной жизни! И можно было бы спрофайлить, где подпилить Go.в тексте, или на форумах их сотрудники пишут что будут выкладывать в opensource свои наработки со временем. (речь о RUST)
Hello world очень толсто компилирует Rust в отличии от C
Там всё std статически линкуется. Между прочем libc 1мб с лишним весит, с той лишь разницей что он статически почти никогда не линкуется.
> Hello world очень толсто компилирует Rust в отличии от CЕсли тебе для твоего "Hello World" не нужен libstd, то без него разницы в размере с "C" не будет.
> Hello world очень толсто компилирует Rust в отличии от Crustc -C prefer-dynamic
> Кроме эффективного распараллеливания операций, используемые в Rust технологии безопасного программирования позволяют кардинально поднять уровень безопасности, решив текущие проблемы с безопасностью.Безопасность, безопасность, безопасность