Pull to refresh
22
8.1
Send message

Я пишу такое. Сборка Ultimatum, пока умеет только кеши и hsts, favicons на подходе. Прям заморозки таба и его дальнейшей разморозки нет но вообще планирую. Статьи можно в профиле моем глянуть.

Ну про виртуалку соглашусь, но опять же - проще потому что ничего другого нет. Я об этом и говорю - отучить хромиум от вредных привычек - сложная но подьемная работа. А в момент когда пользователям будет доступен действительно надёжный браузер всё эти танцы с виртуалками будут выглядеть как костыль.

Вы между двумя цитатами пропустили момент когда Вы начали мне указывать о чем мне говорить а о чем нет.

Да я как нибудь сам решу о чем говорить а о чем нет.

Не соглашусь, я писал число дробилку на ноде (как proof of concept) народ с go посмотрел, почесал затылок и сказал что ускорить могут на десяток процентов, но не в разы. Но это холиварная тема, мы то тут не для этого собрались.

Может быть, надо на самом деле смотреть чем именно там js занят. В ноде например эта идея стрельнула вполне себе. Но да, вполне может быть что увлеклись и повесили на js то чем он заниматься не должен.

У них 80% income от гугля прилетает, это их собственный отчет. Их не убьют потому что в таком случае гугль попадает на размонополизацию, и при этом они так и будут на коротком поводке. Я лично по работе налетал на баги в лисе которые не фиксились 11 лет. Гугль выиграл, это надо признать и двигаться дальше. Исходники хромиума есть, всё не так уж и безнадёжно. Нужно набрать критическую массу программистов способных ориентироваться в нём и начать перетаскивать пользователей фишками которые гугль никогда у себя не впилит. А фишек таких нафантазировать можно.

Есть такой грешок, каюсь. Но на замечания реагирую адекватно, если что то прям сильно раздражающее - говорите, поправлю.

Дорогой, иди сюда, дай я тебя обниму, горько поплачем вместе.

На самом деле это те самые мысли которые по сути и привели меня в хромиум (в одной из своих первых статей я озвучивал) . И даже примерно план решения у меня есть, но проблема в том что в одиночку я его не смогу реализовать. Упрощать проект надо, однозначно, уровень сложности который задал гугль недостижим для большинства одиночек. И они будут поддерживать такой высокий уровень, это в их интересах. Моё мнение - в хромиум нужно вводить понятие привилегированного js (он там на самом деле уже есть), прокидывать ему низкоуровневыйдоступ в сеть и к fs, это покрывает 90% кейсов, и переносить код с с++ на этот привилегированный js. Таким образом мы получим очень лёгкий каркас на с++ и модульный браузер, при этом порог вхождения в его недра сильно снизится. Что то подобное было (и ещё есть) в Firefox, и в плане скорости сборки и простоты чтения кода лиса и хром конечно небо и земля. Но у лисы некошерная (с моей точки зрения) лицензия и они явно находятся под внешним управлением гугля. Так что да, я согласен полностью с этими мыслями, но не сейчас. Но очень надеюсь что этот день настанет и собственно над этим и работаю.

Да ничего не мешает. А что мешает делать то же самое расширениям без этого api?

Я правильно понимаю - запрос на то что бы отключать все кеши? Если да то интересно. Так то он из devtools отключается, но это только http. Хм, я подумаю, пока не готов ничего ответить. Мне попадалась сборка хромиума, вроде там что то похожее заявляли, но там не open source

ну в таком случае вы не понимаете что такое кэш

довольное сильное утверждение но ок.

В противном случае первое же расширение с нужными пермишнами будет сливать о вас много интересного

ну вот с этого надо было начинать, что из коробки - это для расширений. Сайты до api не дотянутся, расширения со сторов не встанут. А то что пользователь ставит в девелопер моде - ну либо он понимает что делает либо ССЗБ, я реально тут проблемы не вижу.

Какое отношение мой код к этому имеет? Он не замедляет и не ускоряет доступ.

а можно поподробней схему детекта?

Я извиняюсь за долгое молчание, ушел с головой в создание статьи по поводу chromium-а. Вопросы правильные, но что бы объяснить их придется отдельную статью выкатывать (что в общем то я и собираюсь сделать, но не сейчас) А если коротенько - суть в том что нам сиcтемы типов (каких бы их там навороченных не придумали) - не нужны, у нас есть язык описания функций и какой-то (постоянно пополняемый) инструментарий их анализа. И с этой точки зрения типом может быть любая функция которую мы уже умеем анализировать. И список таких функций постепенно расширяется. Там есть еще один заход с совсем другой стороны, это иерархия Хомского. Так вот, на нее можно посмотреть не как на описание грамматик а как на систему типов. То есть какой сложности должна быть функция для того что бы описать тип. Надо только разобраться с Тьюринг-полными грамматиками поскольку это слишком общая категория, там есть признаки по которым можно разбивать на подкатегории.

Спасибо! Да, там много неожиданных моментов, не только заголовок. Перечитал и понял что упустил целый абзац который сам по себе на целую статью тянет. Слишком много всего в голове, тяжело это оттуда доставать упорядоченным :) но ничего, со временем утрясется надеюсь.

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

Я извиняюсь за разметку, там в двух местах надо читать -> вместо - >
новый редактор себя ведет немного странно.

1
23 ...

Information

Rating
724-th
Registered
Activity