Компания Google объявила (https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...) о переводе технологии PNaCl (Portable Native Client) в разряд устаревших. Поддержка PNaCl в Chrome будет прекращена в первом квартале 2018 года, но возможность использования PNaCl в дополнениях к Chrome и приложениях Chrome Apps ещё какое-то время будет сохранена.
Разработчикам рекомендуется перейти на использование технологии WebAssembly (http://webassembly.org/), предоставляющей (https://www.opennet.me/opennews/art.shtml?num=46117) не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования. WebAssembly рассматривается как более перспективная и переносимая между браузерами технология создания высокопроизводительных web-приложений, в то время как PNaCl не вышел за пределы нишевого продукта, привязанного к одному браузеру. Для упрощения перевода приложений с PNaCl на WebAssembly подготовлена серия рекомендаций (https://developer.chrome.com/apps/migration).
По своим задачам WebAssembly во многом напоминает PNaCl (Portable Native Client), но отличается тем, что промежуточный код WASM не изолирован в отдельной виртуальной машине, а выполняется с похожим на JavaScript уровнем изоляции. В PNaCl приложение компилируется в универсальный биткод LLVM и поставляется в непривязанном к конкретной платформе исполняемом формате ".pexe". В процессе запуска приложения промежуточный биткод LLVM транслируется в машинный код текущей платформы на стороне локальной системы пользователя. WebAssembly претендует на роль универсальной и общепринятой технологии, поддержка которых уже включена по умолчанию в Chrome 57+ и Firefox 52+, и входит в состав экспериментальных сборок Safari и Edge (https://blogs.windows.com/msedgedev/tag/webassembly/).Компания Google дополнительно опубликовала план (https://wasmdash.appspot.com/) развития поддержки WebAssembly в браузере Chrome, в соответствии с которым в Chrome 60 появятся поддержка фоновой компиляции WebAssembly и средства для работы с разделяемой памятью в JavaScript (SharedArrayBuffers). В Chrome 61 будет обеспечена трансляция кода asm.js в WebAssembly, поддержка сериализации WebAssembly.Module в IndexedDB и возможность компиляции WebAssembly по мере загрузки. В Chrome 62 ожидается появление средства для многопоточного выполнения. В Chrome 63 появится поддержка векторных инструкций SIMD и быстрая обработка исключений. В Chrome 64 будут добавлены средства для кэширования машинного кода для WebAssembly.
URL: https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webass...
Новость: http://www.opennet.me/opennews/art.shtml?num=46629
...и опять вспоминается Джоэл с его "технология на технологии заменяет технологию"...
Не знаю, на что именно отсылка, но что делаются шаги по постепенному уходу от JS - логично. И на сейраз шевеления довольно осмысленные
Это не просто "уход" - это повторение ВСЕГО, что прошла Жаба от "браузерного плагина" до серверов приложений. Гугл очень тупо выглядит со всеми этими ассемблями в свете давно существующих технологий.
"Ну уж в этот раз мы всё сделаем как надо!"))
> "Ну уж в этот раз мы всё сделаем как надо!"))Silverlight vs Flash
Вообще у них ведь уже есть успешный V8, который вместе с node.js на серверах себя тоже прекрасно чувствует. И они всё одно делают пре-компиляцию JS в байткод, и у них уже есть виртуальная машина, в которой он исполняется или докомпилируется в машинный. У них уже есть своя виртуальная машина в браузере. Зачем им тащить туда ещё одну? Причём им придётся её значительно перерабатывать под себя и просто под работу с объектами, предоставляемыми браузером. Причём им пришлось бы делать DOM одновременно совместимым как с JS, так и с Java, а это уже отдельная разновидность безумия. Да, у них в планах есть возможность предоставить прямой доступ к DOM для WASM-приложений. И практически наверняка опять разгорится скандал с Oracle. Им это надо?
Так что Гугл вполне разумно не хочет трогать Java даже двухметровой палкой.
Даже обфусцированный жабаскрипт дает простую возможность реверса. С WA все капитально усложнится.
Это таки аргумент в пользу чего?
И кстати, заниматься реверсом asm.js вообще ни разу не проще, чем WA.
На большом объёме кода - сложнее :-) Визуального мусора больше.
Ну давай, декомпилируй (это часть живого js проекта):
if (!($385)) {
$387 = $384;
while(1) {
$386 = (($362) + ($387<<2)|0);
$388 = HEAP32[$386>>2]|0;
$389 = (((($0)) + 24|0) + ($387<<2)|0);
HEAP32[$389>>2] = $388;
$390 = (($387) + -1)|0;
$391 = ($390|0)==(0);
if ($391) {
break;
} else {
$387 = $390;
}
}
> это повторение ВСЕГО, что прошла ЖабаShocking news: java и javascript это очень разные вещи.
Жаба в "браузерном плагине" вообще, считай, случайно оказалась, совершенно боковое применение.При чём здесь WebAssembly - я не знаю, они вообще ничем не похожи - с одной стороны контролируемая одним вендором ВМ, предоставляющая крайне ограниченный набор возможностей, но для довольно широкого рынка, с другой - фактически "кроссплатформенный ассемблер", чётко ориентированный на браузеры и подвигаемый четвёркой гуглом и мозиллой при поддержке МС и эппла - то есть вообще всеми производителями хоть как-то значимых браузеров.
Можно ли считать это доказательством отсутствия зондов в PNaCl?
Это что за формула такая?
> Это что за формула такая?Гадание по гуще между строк камметов на опенете. Ай, ромалэ!!
Фтор, натрий, хлор
>ФторНет, фосфор.
Фосфор же.
В основном это доказательство силы NIH-синдрома мозиллы. В те времена Майкрософт они бы совместно с гуглом продавили, но мозилловцы рогом упёрлись и наляпали asm.js
> ...но мозилловцы рогом упёрлись и наляпали asm.js...который НУ-НАКОНЕЦ-ТО не нужно засовывать внутрь embed-объекта.. АЛЛИЛУЯ!
хочешь сказать что PNaCl использует офигительные идеи быстрого выполнения кода? возможно! но кто просил гугловцев использовать embed-объекты? правильно! ни кто! но зачем-то они сделали всё через Ж^ embed. и вот мы видим к чему это привело.
разумеется Мозиловци рогом упёрлись -- а что им оставалось в этом случае делать? потому-что говно в бочке мёда -- портит ВСЮ бочку мёда.
ды ты хоть даже придумай космичскую технологию ИЗБАВЛЯЮЩУЮ ЧЕЛОВЕЧЕСТВО ОТ РАКА И СПИДА -- но если эта технология бдет работать через embed-объект -- то вполне естественно ожидать что на твою технологию будут смотреть как на какашку (и упираться рогом).
я перефразирую: ды лeчше умереть от рака и спида -- чем запускать скрипты через embed-объекты... -- так тебе яснее стало?
И чем именно тебе Embed-объекты не угодили? Как минимум, там была необходиомсть явно прописывать API для доступа к нужным кускам DOM, что хотя бы позволяло встраивать всякое third-party чётко контролируя, что оно может, что - нет. Мне вообще идея скрипта, который может сделать со страницей что угодно, кажется глубоко порочной. Примерно как от рута или администратора сидеть.
Меняю свой рак на embed-объекты.
Portable Native Client
> В PNaCl приложение компилируется в универсальный биткод... и поставляется в непривязанном к конкретной платформе исполняемом формате... В процессе запуска приложения промежуточный биткод... транслируется в машинный код текущей платформы на стороне локальной системы пользователя.И снова от "java-апплетов" отказались. Кто знает, почему так получается уже в который раз?
> И снова от "java-апплетов" отказались. Кто знает, почему так получается уже в
> который раз?Внимание, знатоки! Отвечает телезритель Пушкин А.С.:
Он в другой раз закинул невод,
Пришел невод с травой морскою.[...]
Уж не хочет быть она царицей,
Хочет быть владычицей морскою;[...]
Глядь: опять перед ним землянка;
На пороге сидит его старуха,
А пред нею разбитое корыто.
во ты сегодня в ударе :)
>> И снова от "java-апплетов" отказались. Кто знает, почему так получается уже в
>> который раз?
> Внимание, знатоки! Отвечает телезритель Пушкин А.С.:
> Он в другой раз закинул невод,
> Пришел невод с травой морскою.Не хватает:
> И продавал он втихаря траву морскую опеннетчикам.это многое бы объясняло.
Не думаю, что есть общая причина. Джава-апплеты не прижились из-за общей тормознутости и вечных дыр, ро это второстепенно - "апплеты" на флеше терпели довольно долго, хотя дыр было не меньше.Конкретно PNaCl гугл просто не сумел протолкнуть как общее решение по причинам скорее техническим, сам подход там хорош (практически обычный нативный код, в который довольно тривиально компилируется что угодно). Так что отказ в пользу консесусного варианта логичен.
> Не думаю, что есть общая причина. Джава-апплеты не прижились из-за общей тормознутости
> и вечных дыр, ро это второстепенно - "апплеты" на флеше терпели
> довольно долго, хотя дыр было не меньше.Что касается дыр в Java-апплетах, то их практически не было. Вы их с чем-то попутали, с ActiveX, наверное.
Там просто всплывал запрос "разрешить доступ к локальной ФС", на который почти все отвечали "да".
Приснились, угу.
> Джава-апплеты не прижились из-за общей тормознутости и вечных дыр, ро это второстепенно - "апплеты" на флеше терпели довольно долго, хотя дыр было не меньше.вы что -- реально обкурились? причём тут дыры и тормознуость? тормознутость ни кого не беспокоит (купи себе новый комп уже!), а дыры были всегда и везде и будут -- это вообще в расчёт не берём.
все эти flash, applets, moonlight -- не прижились потому что были реализованы КАК ТЕХНОЛОГИЧЕСКИЙ КОСТЫЛЬ...
...вместо того чтобы иметь ГЛУБОКУЮ ИНТЕГРАЦИЮ (в браузерный движёк и web) в основе своей реализации.
ды ёлки-палки -- неужели это кому-то может быть неочевидно?
embed-объект внутри document-object-model -- как-будто просто скотчем приклеен (на соплях) к web-приложению!
сделать flash, applets, moonlight -- по другому (не скотчем) -- не могли, так как для этого пришлось бы:
1. производить большую работу внутри самого браузерного web движка.
2a. отказаться от портируемости на другие web браузеры (решение сугубо для одного web браузера).
2b. обсуждать с другими производителями web браузеров как нужно поменять web стандарты. и придти к единому мнению (считаться со всеми, "разработка комитетом").
для WASM -- наконец-таки смогли осилить пункты "1" и "2" ("1,2b")...
но в одиночку (без объединения) -- производители плагин-гоовница могли-бы осилить-бы только ветку "1,2a".
ни кто из этих производителей "... , flash, applets, moonlight, ..." -- ни за что в жизни не принял бы для себя факт "2a" -- ИЗ-ЗА СВОЕЙ ЖАДНОСТИ (хитрые манагеры, такие хитрые манагеры, аж хитрожпсть из ушей лезет). а факт отказа от "1" -- просто удешивлял разработку (опять жадность?).
а отказ от "2b" -- позволял как минимум не иметь дел в стиле этого-ненавистного-манагерами open source метода разработки..
ТЕХНОЛОГИЧЕСКИЙ КОСТЫЛЬ (ввиде скотча с соплями) -- это палочка выручалачка для этих тупорылых проприетарных компаний, как они думали!
то есть -- они думали: "хренак хренак и в продакши.. и мы первые на рынке супер-мега-бизнесс-решений!!" (а скотч и сопли -- якобы просто ни кто не заметит)..
"вот! поглядите на эту ppt-презентацию, и на этот график который показывает увеличение наших доходов"
# P.S.: PNaCl мало чем отличается от "... , flash, applets, moonlight, ...". с точки зрения "компиляции выполняемого кода" -- PNaCl конечно же бесспорно лучше чем например Java-Applets. но с точки зрения "соплей и скотча" это тоже самое. разумеется PNaCl был уже первым шажком в нужную сторону (но очень далеко от выхода из нишы сырых решений на коленке). а AsmJs (от Mozilla) было реально революцонно более качественное решение с точки зрения своей идеи. а Wasm это работа над ошибками AsmJs (с учётом объединения сил).
> Target: Chrome M61 - September 12, 2017
> Wasm - CSP Support
> Allows pages that have locked down security policies to use WebAssembly.
> A Content Security Policy can be used to limit the scripting resources used by your Web App. The Response based API will allow WebAssembly to run inside a strict CSP that forbids "unsafe-eval".uMatrix соснёт? Привет неотключаемый WASM?
uMatrix работает на уровне сетевых запросов, ему всё равно, что именно их инициирует
Я тебе уже отвечал на эту неграмотность. Не читал? Коротко: работает на заголовках CSP и сетевых запросах.
Ну так и я о том. Сетевые запросы как были, так и есть. Для картинок же он без csp обходится.
uMatrix на это наплевать - он блокирует не скрипты, а web-запросы
И какие же веб-запросы у инлайн-скриптов, умник?
> И какие же веб-запросы у инлайн-скриптов, умник?XMLHttpRequest
fetch(url)
navigator.serviceWorker.register(url)
WebSocket и WebRTC
И ещё огромное множество других способов запросить данные извне.
И это не говоря о манипуляциях с DOM.
Я так понимаю, товарища тревожит возможность отрубить сами WASM-скрипты.
Как ты себе представляешь инлайн-скрипт в виде бинари в текстовом HTML-документе? И, кстати, uMatrix отродясь с инлайновыми скриптами ничего делать не умел, это не его проблемы. А NoScript/uBlock так и так страницу сканируют.
> И, кстати, uMatrix отродясь с инлайновыми скриптами ничего делать не умелОтдельно не умел. Вообще все скрипты выключать умел и умеет, включая инлайновые.
Только при условии, если запросы, порождаемые WASM, пустят напрямую, в обход расширений. Как это уже случилось с WebSocket и WebRTC. ABP/uBO пришлось через CSP резать вообще все соединения такого рода, устанавливаемые проблемными сайтами. Я так до сих пор и не посмотрел нормально ли у WASM с этим всё или опять «забыли».
Считай, что это джаваскрипт в другой форме, никаких "особенных" соединений у него нет.
> WebAssembly, предоставляющей не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программированияЯ так понимаю, на твоём компьютере будут запускать программы извне и без твоего участия?
>> WebAssembly, предоставляющей не зависящий от браузера универсальный низкоуровневый промежуточный код для выполнения в браузере приложений, скомпилированных из различных языков программирования
> Я так понимаю, на твоём компьютере будут запускать программы извне и без
> твоего участия?Ну да, ровно так же, как много лет происходит с джаваскриптом. Ограничения тоже одинаковые.
> запускать программы извне и без твоего участия?JavaScript, запускается сам, без спроса, во всех браузерах и уже очень давно. В WebAssembly уровень изоляции точ такой же.
Так и сейчас уже запускают. Только сейчас эти программы прилетают в форме javascript, который браузер копмилит в нативный для системы код и запускает. А теперь будут прилетать в форме LLVM, который браузер будет так же компилить в нативный код и запускать. Т.е. концепция остается та же, и с точки зрения безопасности ничего не меняется. А меняется производительность в лучшую сторону и появляется возможность писать для веба на других языках.
>>с точки зрения безопасности ничего не меняетсякроме одной малости -- прощай открытый интернет, привет бинарные зонды в качестве стандарта
Ну это с какой стороны посмотреть...
>>>с точки зрения безопасности ничего не меняется
> кроме одной малости -- прощай открытый интернет, привет бинарные зонды в качестве
> стандартавам андроид с япплом оба-два в точке зондирования не жмут?
>>>>с точки зрения безопасности ничего не меняется
>> кроме одной малости -- прощай открытый интернет, привет бинарные зонды в качестве
>> стандарта
> вам андроид с япплом оба-два в точке зондирования не жмут?Жмут, а почему вы спрашиваете?
И что ты с нынешним "текстовым" минифицированным джаваскриптом делать собрался?Для справки - asm.js (который вполне можно назвать текстовым представлением этих самых "бинарных зондов") уже года два как нормально работает во всех основных браузерах. Единственное отличие этой штуки - более высокая скорость запуска и более компактное представление.
Рассказываю. Надо спроксировать http одной приблуды в интернеты, а чтобы ее там не поломали проксируем через https и на проксе рисуем запрос пользользовательского сертификата, и вроде все работает, но как-то криво, открываем консольку, а там часть запросов ajax через http прет, находим искомую js-ку и поправляем там на как надо, а проксе говорим заменять оригинальную на поправленную, и вуаля, нет необходимости цепляться по rdp к машине и с нее идти к преблуде.
Варианты (в порядке возрастания безумия):
0) Пофиксить скрипт изначально
1) использовать JS как и использовали - лет десять с ним точно ничего не случится
2) врубить редирект с 80 на 443 на сервере с подходящими рерайтами
3) если там не ад внутри WASM - разбираешь в текстовое представление (это не декомпиляция те же команды, просто сериализованные в текст), s/http/https/g или что там надо - запаковываешь обратно и делаешь то, что и делал.А вообще - в ближайшие три жизни оно JS для подобных штук не заменит, те же API для доступа к DOM даже не начали пилить ещё. Пока - это для специфических тяжёлых приложений, игрушек прежде всего.
0) нельзя, железка, гарантия, да и долго это все расковыривать в прошивке, а там неверняка еще и защита какая-нибудь, да и железок таких на самом деле тьма не одинаковых, проблемы только у одной модели.
1) ну так и меня вполне устраивает
2) лучше использовать слово - проксирование, его щас даже даже комерсы пользуют в своих контекстах. Так так и есть, если я правильно понял.
3) что и как там будет, хз, гадать глупо, а ломать то, что есть и вполне работает, ради чего?> ближайшие три жизни
да ну, я бы не поверил 5 лет назад во много из того что сейчас есть, ..и подумав, я бы сказал ОЧЕНЬ много.
> это для специфических тяжёлых приложений
Ой, яндекс-маркет, алиэкспресс, кое-кто из интернет-банкинга, все остально заменяемо и можно найти вариант, который позубам своей системе, мне ли с моим атомом не знать.
> игрушек прежде всего
а игрули в браузерах еще есть? вот это поворот
Ну тогда из предложенных осталось два живых варианта.На сейчас - ничего не трогать, благо из железки JS никуда не денется, а JS в браузерах ту железку явно переживёт.
На будущее, если таки нарвётесь на подобное с WASM - заворачивать дополнительно там, куда оно на HTTP ломится. Как ни крути, это куда менее кривой костыль, чем скрипты подменять на хаченые.Ну и насчёт ада в WASM я имел в виду какую-нибудь обфускацию в коде или подобную чушь. Это, собственно, и в JS накрутить не то чтобы сложно, так что тут я разницы не вижу. А сам формат WASM финализирован уже - и бинарное, и текстовое представление, инструменты преобразования есть, так что строки поправить не проблема.
Насчёт игр и приложений - ну, примерно такой набор на данный момент, да. А такой он, а не что-то большее - в том числе и по причине ограниченности JS, которыую и пытаются преодолеть и засунуть в браузер вообще всё. Лучше бы обломались, честно говоря, но это в любом случае дальнее будущее.
И? И то и другое — плохо.
И - смысл нервничать, если ничего не меняется? А так - плохо, конечно. Как и веб-приложения и проприетарщина в принципе.
>промежуточный код WASM не изолирован в отдельной виртуальной машиневот вам, пользователишки, дырявая ложка
> вот вам, пользователишки, дырявая ложкаДа ладно, все знают, что нет никакой ложки...
Будущее не за горами. Ждем полноценные версии фотошопа, 3дс макса, солидворкса и т.д. прямиком в браузере, с вполне допустимыми потерями в производительности. Это бизнес, это удобно пользователям. Не исключаю, что подобный расклад идет в разрез с ванильными мечтами классических обитателей опеннета... им бы я посоветовал не переставать мечтать лежа на своем диване :)
И будет тебе "софт по подписке", который без широкого интернет-канала ничего не может
Да и пофиг. Проприетарщина так и так ядовита и сней связываться не надо. А кто свободный софт писал - те и продолжат.
>это удобно пользователямТы это, за всех не говори. Прежде всего это удобно корпорациям. Им удобно, когда ты хранишь работу в облаке. Это же так чудесно и удобно, что все кому не лень в этих корпорациях могут читать твои счета, переписку, а также отдавать третьим лицам "на анализ" твои работы!
И ты не забывай, что гугл все предоставляет спецслужбам, если по бумагам все сходится. Рано или поздно, но полицаи научатся предоставлять такие бумаги, что не отвертишься. Да, пока таких спецов у них мало, но стоит им только появится...
до сих пор не могут запилить html5 видео, чтобы работало примерно как на смотрелке, а вы тут уже размечтались. Все опять сведется к убожествам вроде флаппи берд.
Кто и что компилит в WebAssembly? Есть реальные примеры сайтов или приложений? Когда уже начнется бум?
Как минимум - когда выйдут (и заменят предыдущие версии) Edge и Safari с егод поддержкой. Выйти-то должны скоро, а вот насчёт "заменят"... поглядим.
Господи, во что они превратили подобие гипертекста (но кривую реализацию) содранное с XANADU.
В штуку, которой пользуются миллиарды и которая приносит триллионы?
> В штуку, которой пользуются миллиарды и которая приносит триллионы?Это скорее вопреки нежели благодаря :-)
Это именно благодаря. Потому что тот "чистый" гипертекст - штука довольно ограниченная, в нём в интернет-шахматы не поиграешь, интернет-магазин не сделаешь и так далее. Сфекрические кони - они в вакууме хороши, а на практике всегда есть и плюсы и минусы.