браузеру нужно эти процессы поддерживать как единое целое
И что там поддерживать? HWND для отрисовки поделиться? Кукисы заброадкастить?
И какие данные там дублировать? Основное, что раздувает память, это DOM, JavaScript объекты и 400% мусора от них, а они не дублируются. К сожалению, отсутствие слабых ссылок усложняет задачу избавления от мусора, так что в JavaScript по принципу и так сойдёт остаётся даже больше мусора (формально достижимого), чем в других системах с TGC, но где слабые ссылки есть.
Кеш? Ну, может быть. shmem для кеша нетривиален. Могли недостаточно хорошо сделать.
Но мне кажется, они там не за безопасность думали, а как прикрыть свой зад. Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще. Падал сразу весь, с текстами недописанными в каких-то вкладках, и это мегафейл. Не считая переписывания на Аде и последующего прозрения, от чего ж там на самом деле падает, и исправления найденных косяков, запилить это в отдельные процессы, похоже было единственной альтернативой. Не решить проблему, а замести под ковёр.
Mozilla тут проще, у них нейтральный к языку XPCOM, разные компоненты по отдельности можно апгрейдить на Аду. В WebKit нет XPCOM, но есть Objective-C runtime, тоже потенциально многоязыковой движок.
Ну и давайте уже какие-то пруфы про трассирующую эту сборку. Ваши фантазии читать не особо интересно.
Что до Ады, беглый гуглинг говорит, что для данной задачи оно не подходит, т.к. безопасность уровня Rust не дает.
Сколько на ней пишу, даёт. И ещё даёт ООП внятное, сопоставимое с подмножеством, используемым в C++ и Delphi. Не такая эзотерика с типажами, как в Rust, под которую нужно всё через колено ломать. И исключения вменяемые. Растовские паники (а переполнения чисел и выходы за границы массивов производят именно их) — это почти как апокалипсис. Перехват паники — нештатная операция, и даже, если перехватить, то ещё штатный обработчик успеет нагадить в консоль своё бесполезное сообщение, и его тоже тогда надо перехватывать, чтоб не гадил. Я такую обработку ошибок последний раз в Turbo Pascal видел. Там галочки проверять диапазоны и переполнения были в настройках, но если их включить, происходили такие же апокалипсисы. В Delphi версии этак с четвёртой человеческие исключения возбуждаются, в языке Ада изначально по-человечески.
если бы webkit начали писать на этом языке, то можно было быть уверенным, что до наших дней он бы не дожил, т.к. его бы некому было писать
Да те же, кто пишут браузеры, и писали бы их на Аде. Чтоб спецы могли запрогать рендеринг не заточенного под это CSS в слои OpenGL, а с одного языка с RAII, шаблонами и ООП не могли перейти на другой язык с RAII, шаблонами и ООП, — да ну, бред какой-то. Кто бы стал там держать принципиально необучаемых. Всё они могут.
По существу процессы отнюдь не такое дорогое удовольствие. Операционные системы умеют shmem и mmap, и даже при ASLR умеют кешировать версии с релокациями. А вот трассирующая сборка мусора висит камнем на шее. Чтобы имело смысл проводить трассирующую сборку мусора, мусорить нужно обильно, в 5 раз больше, чем реально используется памяти. И без слабых ссылок всё ещё хуже.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
Под Windows проще всего собирать. Под Windows компоновщики не лезут в system32 убедиться, что там в DLL есть нужные входы. Под Windows это вообще, не их, компоновщиков, собачье дело, а существует ли вообще DLL в природе.
На macOS ты попробуй только не дай ld пощупать каждый dylib, и каждую зависимость каждого dylib. Всё, не хочу, не буду компоновать.
На Linux в бинарники зашивается rpath. На macOS в каждый dylib зашивается, «где меня искать», и когда ld щупает все dylib, он копирует это в те файлы, которые компонует. Они теперь будут искать по тому адресу, который увидели в dyld.
Таблица импорта в Windows и macOS двухэтажная, то есть, понятно, какой символ из какой библиотеки, на Linux одноэтажная.
Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.
Если б не было плевать, писали браузер на Аде. Что-то я такой реальной заботы о безопасности не наблюдаю. Больше похоже на симуляцию бурной деятельности.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Из немаркетинговых доводов, которые я видел, в браузере реализовано автоматическое открытие клавиатуры при навигации по полям с планшета типа Surface Pro, а на обычном GUI с osk.exe не смогли разобраться, или в чём-то таком проблема.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
Можно писать под GNUStep или Cocotron, а под Mac нативно. Лучше Mac-like на Win, чем Win-like на Mac. Яблочники довольны, а вендопользователям, а тем более линукс всё равно не привыкать. В среднем, всем хорошо.
Те, кто заботятся о безопасности, и те, кто пишут на C++, — это непересекающиеся множества.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.
Эмуляция x86 появилась гораздо раньше нативной Джавы
Когда в Унипро делали нативную Джаву, им долго не удавалось получить производительность выше, чем у Джавы в x86 эмуляторе
Оптимизированный JavaScript в Унипро сделали только после Java
А WebAssembly ещё не сделали
На примере Windows для ARM:
5 лет назад, Windows RT: да зачем эмуляция x86 на ARM? это убивает всю идею энергоэффективности
сейчас, Windows 10 для ARM, Always Connected PC: после того, как что-то не пошли продажи, и эмулятор сразу сделался, и кеширование транслированных цепочек на диске, и нативные срезы библиотечных функций, в общем, почти образцовая эмуляция x86 сделана (чтоб идеально, надо ещё кое-что)
Мне кажется, x86 исчезнет как родная архитектура процессоров, но останется как универсальный байткод. Objective PE, во всяком случае, имеет такую идеологию, хотя поддержка WebAssembly не исключена.
В том состоянии, как сейчас, WebAssembly требует довольно много костылей, и как пойдёт развитие, не понятно. Скажем, в Wasm все остановы (trap) полностью срывают стек. Значит, чтобы это обойти, нельзя пользоваться стеком Wasm, нужно размещать искусственный стек в памяти, чтоб можно было возвращаться, где остановились.
WA как родной набор команд? Вы в курсе для начала, что он стековый, а это как-то и раньше не прижилось.
Уязвимости переполнений на стеке — это потому что пишут не на Аде.
Где-то в параллельном мире всё ещё доминирует FAT32, и там обсуждают «интересные технологии» уменьшения критичности потери данных при отключении питания. Hitachi пока только обдумывает реализацию Shadow-HDD, — новости из параллельной Вселенной.
В принципе, есть сопоставимо защищённый CHERI, выпускается дольше. На уровне аппаратуры проверит, что программы правильно обращаются с 256битными указателями. Особенно хорошо подходит по менталитету для людей, хранящих данные на четырежды зеркальном RAID. Чего только ни сделаешь, чтоб FAT32 от выключения питания защитить.
Рыбин С.И. рассказал о методике тестирования диагностики транслятора (вообще, и языка Ада в частности), разрабатываемой в МГУ под руководством Кауфмана В.Ш. Приведены данные по оценке качества и диагностики трех трансляторов Лада, Ада-Эльбрус и венгерская Ада ЕС; из них видно, что качество диагностики Ада-Эльбрус – лучшее из трех систем.
И очень это интересно в связи с тем, что Эльбрус возрождается. И там есть защищённый режим, который, по всему видно, как раз заточен под такой язык программирования, как Ада. Например, там есть дескрипторы модулей, которые не дают чужому модулю залезть внутрь структуры, и это замечательно проецируется на адское «is private». Какой модуль не может семантически заглянуть внутрь private, тому и железо не должно это позволять. Проверка переполнения целого числа аппаратно поддерживает большую часть числовых типов языка Ада, но есть ещё модульные типы, у которых прокручивание при переполнении по стандарту, и компилятор Ады может инструктировать аппаратуру, где надо проверять, а где — нет.
Интересные книги про Эльбрус есть под авторством Запреева, но сканов в Интернете нет. Только в библиотеку в Москве ездить.
И что там поддерживать? HWND для отрисовки поделиться? Кукисы заброадкастить?
И какие данные там дублировать? Основное, что раздувает память, это DOM, JavaScript объекты и 400% мусора от них, а они не дублируются. К сожалению, отсутствие слабых ссылок усложняет задачу избавления от мусора, так что в JavaScript по принципу и так сойдёт остаётся даже больше мусора (формально достижимого), чем в других системах с TGC, но где слабые ссылки есть.
Кеш? Ну, может быть. shmem для кеша нетривиален. Могли недостаточно хорошо сделать.
Но мне кажется, они там не за безопасность думали, а как прикрыть свой зад. Я когда Safari пользовался, когда он ещё второй версии был, он падал, потому что не на Аде был написан. OmniWeb ещё пользовался, и он тоже был не на Аде написан, и поэтому падал, но ещё чаще. Падал сразу весь, с текстами недописанными в каких-то вкладках, и это мегафейл. Не считая переписывания на Аде и последующего прозрения, от чего ж там на самом деле падает, и исправления найденных косяков, запилить это в отдельные процессы, похоже было единственной альтернативой. Не решить проблему, а замести под ковёр.
Mozilla тут проще, у них нейтральный к языку XPCOM, разные компоненты по отдельности можно апгрейдить на Аду. В WebKit нет XPCOM, но есть Objective-C runtime, тоже потенциально многоязыковой движок.
Почему веб-приложения на мобильных платформах работают медленно
Сколько на ней пишу, даёт. И ещё даёт ООП внятное, сопоставимое с подмножеством, используемым в C++ и Delphi. Не такая эзотерика с типажами, как в Rust, под которую нужно всё через колено ломать. И исключения вменяемые. Растовские паники (а переполнения чисел и выходы за границы массивов производят именно их) — это почти как апокалипсис. Перехват паники — нештатная операция, и даже, если перехватить, то ещё штатный обработчик успеет нагадить в консоль своё бесполезное сообщение, и его тоже тогда надо перехватывать, чтоб не гадил. Я такую обработку ошибок последний раз в Turbo Pascal видел. Там галочки проверять диапазоны и переполнения были в настройках, но если их включить, происходили такие же апокалипсисы. В Delphi версии этак с четвёртой человеческие исключения возбуждаются, в языке Ада изначально по-человечески.
Да те же, кто пишут браузеры, и писали бы их на Аде. Чтоб спецы могли запрогать рендеринг не заточенного под это CSS в слои OpenGL, а с одного языка с RAII, шаблонами и ООП не могли перейти на другой язык с RAII, шаблонами и ООП, — да ну, бред какой-то. Кто бы стал там держать принципиально необучаемых. Всё они могут.
В книге Putting Metaclasses to Work на какой-то странице реальная диаграмма классов System Object Model. Там 4 уровня.
Альтернатива плюсам существует 23 года, ещё когда никакого Rust в проекте не было, и это Ада. Вообще, первый, кто задумался о безопасности в языках программирования, — это Никлаус Вирт. Это он первый придумал проверять границы и переполнения. И это был язык Паскаль. И естественным образом это унаследовано потомками Паскаля.
За слепошарых мозилловцев ничего не могу сказать. Ну, странные люди.
На macOS ты попробуй только не дай ld пощупать каждый dylib, и каждую зависимость каждого dylib. Всё, не хочу, не буду компоновать.
На Linux в бинарники зашивается rpath. На macOS в каждый dylib зашивается, «где меня искать», и когда ld щупает все dylib, он копирует это в те файлы, которые компонует. Они теперь будут искать по тому адресу, который увидели в dyld.
Таблица импорта в Windows и macOS двухэтажная, то есть, понятно, какой символ из какой библиотеки, на Linux одноэтажная.
Гораздо проще с Windows. Не зря полнятся фрисофты и софтпорталы экзешниками.
за глючную тормозную программу.
Ну и, может, как-то заказчикам консолидироваться, чтоб для Ады рынок надёжного и быстрого ПО был, тогда будет не редкой технологией.
Память там отъедается мощно трассирующей сборкой мусора. Про то, как надёжно запечатаны двери в светлое будущее, где счётчиками ссылок и слабыми ссылками сберегается память, я уже написал.
Но вообще проблема в том, что хочется всё и сразу, и веб, и не веб. И Электрон позволяет это, но тогда нужно прогнуться под правила веб. А нет такого решения, чтоб, наоборот, прогнуть веб, а на десктопе и сервере было всё хорошо, как обычно.
Что можно было брать QIP'ы и The Bat! ы, с многопоточностью на мониторах, а не на хоаровских сообщениях, и загонять в веб, каких бы костылей это ни стоило. Я пытаюсь сделать это темой своей магистерской работы.
К памяти можно было бы относиться более бережливо, если б были счётчики ссылок и слабые ссылки, и только на крайние случаи сборщики мусора. Но за столько лет в JavaScript так и не сделали слабые ссылки.
Плевать там все хотели и на безопасность, и на потребение памяти.
Эмуляция x86 появилась гораздо раньше нативной Джавы
Когда в Унипро делали нативную Джаву, им долго не удавалось получить производительность выше, чем у Джавы в x86 эмуляторе
Оптимизированный JavaScript в Унипро сделали только после Java
А WebAssembly ещё не сделали
На примере Windows для ARM:
5 лет назад, Windows RT: да зачем эмуляция x86 на ARM? это убивает всю идею энергоэффективности
сейчас, Windows 10 для ARM, Always Connected PC: после того, как что-то не пошли продажи, и эмулятор сразу сделался, и кеширование транслированных цепочек на диске, и нативные срезы библиотечных функций, в общем, почти образцовая эмуляция x86 сделана (чтоб идеально, надо ещё кое-что)
Мне кажется, x86 исчезнет как родная архитектура процессоров, но останется как универсальный байткод. Objective PE, во всяком случае, имеет такую идеологию, хотя поддержка WebAssembly не исключена.
В том состоянии, как сейчас, WebAssembly требует довольно много костылей, и как пойдёт развитие, не понятно. Скажем, в Wasm все остановы (trap) полностью срывают стек. Значит, чтобы это обойти, нельзя пользоваться стеком Wasm, нужно размещать искусственный стек в памяти, чтоб можно было возвращаться, где остановились.
WA как родной набор команд? Вы в курсе для начала, что он стековый, а это как-то и раньше не прижилось.
Где-то в параллельном мире всё ещё доминирует FAT32, и там обсуждают «интересные технологии» уменьшения критичности потери данных при отключении питания. Hitachi пока только обдумывает реализацию Shadow-HDD, — новости из параллельной Вселенной.
В принципе, есть сопоставимо защищённый CHERI, выпускается дольше. На уровне аппаратуры проверит, что программы правильно обращаются с 256битными указателями. Особенно хорошо подходит по менталитету для людей, хранящих данные на четырежды зеркальном RAID. Чего только ни сделаешь, чтоб FAT32 от выключения питания защитить.
И очень это интересно в связи с тем, что Эльбрус возрождается. И там есть защищённый режим, который, по всему видно, как раз заточен под такой язык программирования, как Ада. Например, там есть дескрипторы модулей, которые не дают чужому модулю залезть внутрь структуры, и это замечательно проецируется на адское «is private». Какой модуль не может семантически заглянуть внутрь private, тому и железо не должно это позволять. Проверка переполнения целого числа аппаратно поддерживает большую часть числовых типов языка Ада, но есть ещё модульные типы, у которых прокручивание при переполнении по стандарту, и компилятор Ады может инструктировать аппаратуру, где надо проверять, а где — нет.
Интересные книги про Эльбрус есть под авторством Запреева, но сканов в Интернете нет. Только в библиотеку в Москве ездить.
Я так понимаю, после 3го числа все, кто зелёные, если только сами не передумали, будут зачислены.