если раст вообще и нужен зачем-то, то например написать асинхронные конечные автоматы на зелёных тредах и семантике владения. типа как в лекции роба пайка про парсер в компиляторе go на горутинах — тоже конечные автоматы, горутинами.

хотя кажется что всё тоже самое можно и на plain C сделать, например continuation-passed C с корутинами.

про то, что для его компиляции требуется кучу говна на комп тащить. и это типичное ненужно.

да, теперь юзерам полуоси или там plan9 нужно ещё до кучи портировать раст и портировать llvm и прочее. что сразу их отрубает. печалько.

они пытаются решить проблемы кривых рук анальным огораживанием в компиляторе. и это не просто маразм. это опасный, злостный и вредоносный маразм.

ну, справедливости ради, модель памяти ржавчины — некоторый шаг вперёд по сравнению с сишной. реализация зелёных тредов библиотеками из-за lock free из-за семантики владения — тоже. некоторый прогресс в плане составимости таких first class objects языка и моделей данных — имеется.

браузер на ржавчине тоже работает быстрее. но может, это просто просто что нет тех всех расширений?

другое дело, что:

1. ту же реализацию зелёных тредов выкинули. за что боролись?

2. конкретно в firefox отвалились все расширения. после чего без расширений браузер превращается в тыкву, например полезные Scrapbook и прочее MHTML, и прочее. полноценного аналога старых расширений тоже нет. в общем, нормальных разработчиков расширений это достало.

3. servo свежескачаный night builds зачастую просто не работает. под винду, например. а это уже просто напросто странно. причём файрфокс с серво — работает. сам отдельный отодранный движок — глючит и виснет.

4. кроссплатформенность теперь опирается на необходимость портировать зависимости всякого ненужно.

поэтому такие вещи надо сразу отсекать. криворукие неосиляторы в принципе не могут написать браузер.

браузер не могут написать по другой причине: это ad-hoc-щина во все поля с одной стороны, и overengineering с другой. например, изобрели свою компонентную модель, свою среду сборки «питонистая обёртка над gcc, который выглядит как cl.exe из msvc», и прочее.

и тут эти архитектурные астронавты пишут вроде бы паттерны, компоненты и прочее. а получается говно и аd-hoc-щина.

вместо каких-то композабельных решений: конечных автоматов, асинхронности, корутин, движка правил и понятных нормальных и работающих спеков.

какой-то стыкующей новой сильной идеи. язык такой идеей быть не может.

а метаязык может, наверное.

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

и вот чего бы не хранить теперь результаты парсинга в какой-то нормальной документоорирентированной БД, с персистентными объектами? нафига всё это держать в памяти?

sqlite добавляет ACID зайчатков поверх файловой системы. но вносит больше проблем, чем решает. почему бы теперь просто не хранить все промежуточные результаты кешированного DOM в нормальной СУБД? ACID нужен. sqlite — не нужен.

и далее реплицировать такую БД — и получать нечто типа IPFS. неважно, что транспорт http наполняет эту базу. её можно было бы и зашардить в чём-то распределённом.

для чего надо отойти от физического представления страничек типа файловой системы к логическому и мета логическому, концептуальному. к документо-ориентированной СУБД.

всё равно на всяких библиотеках к JS примерно это и пытаются сообразить. почему бы не продумать нормальную структуру *составимых* документов «времени компиляции», авторинга. типа literate programming.

а не run-time ad-hoc javascript noodle soup?

нормальные *составимые* в compile time гипертекстовые документы — нужны. javascript в run time — не нужен.

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

если современный веб это помойка, которая свистит как утка, пердит как утка и крякает как утка — то возможно, это вовсе не утка, а манок утки. потому что нет у него дао утки.

и ещё один браузер HTML 3.2 на форте Азамата Нигматулина. дипломная работа на форте.

Азамата Смагулова. про конечные автоматы

Chrom(e|ium) не использует GTK для отрисовки интерфейса, так что смело можешь пользоваться им.

кстати, собрала Falkon на Void c musl. пришлось пару настроек подшаманить, плюс я вырезала зависимости от пистона. всё собралось, работает. зависимостей от гнома нет. тащит культю, GL, всякие там медийные библиотеки. но больше ничего такого особенного.

собирается чистенько, культурно. молодцы, постарались. никаких там древних компиляторов или тем более виртуальных машин для сборки не требует. даже почти не генерит варнинги, что редко бывает. а те, что были, связаны с вопросами сборки культи на моей машине, а не с самим Фальконом.

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

пока не разбиралась, как там обстоят дела с плагинами. в частности, чтобы резать баннеры (почему-то на ютубе вдруг вылез баннер, я его первый раз в жизни там увидела и он мне не понравился), но это можно на проксе сделать если что.

но главное, что ютуб, который в последнее время стал выпендриваться и временами сообщать мне, что «ваш браузер не умеет показывать видео» (видимо html5) в Falkon отрабатывает нормально. осталось зарезать все баннеры и вполне можно юзать. ещё бы тему тёмную, ночную прикрутить, а то белый фон дико режет глаз.

Fire(fox), впрочем, тоже.

кстати, к плюсам falkon могу отнести то, что он легко подключается к jack плагину альсы и не тащит пульсу.

Ну это пока, пульса в кедах вроде захардкожена. У меня нет пульсы в хромиуме и жирнолисе (и кде если уж на то пошло), достаточно собирать из исходников.

фалькон на основе хромиума. и по умолчанию там пульсы нет. вообще, сборка меня порадовала. обычно сборка браузера - это такой вынос мозга и правка багов, иногда на пару дней. а тут вдруг само практически без правок собралось. и это учитывая мои довольно нестандартные системные настройки. и контакты разработчиков - мыло и IRC! вот где кошер.

з.ы links/links2 не предлагать

wget

веб-браузер на форте

к этому

выложил сюда

нашёл в старых бекапах этот браузер Азамата Смагулова, на форте. скачал и схоронил у себя в 2008 году, ещё до того как оно пропало из этих ваших интернетов.

это дипломная работа студента (2006 год, ЕМНИП) — в архиве исходники (profit), пояснительная записка (diplom.pdf) и собранные бинарники (browser).

версия под винду, исходники на русском языке (и форте).

сам форт SP-Forth кроссплатформный, портировать под онтопик несложно — использована GUI библиотека, которая абстрагирует WinAPI как DSL.

вообще браузер в такой реализации можно рассматривать как набор DSL.

по степени соответствия стандартам: самый ранний HTML 3.2, не реализованы таблицы. нет JavaScript, DOM свой велосипедный. нет CSS. не реализованы фреймы.

некоторые HTML показываются неправильно (lavkraft.htm с артефактами, соседние слова налезают друг на друга. другие html с жёстко заданной структурой таблицами показываются нормально).

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

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

о чём подробнее см. пояснительную записку. по идее, далее можно вот этот PDF переписывать в стиле literate programming: хоть на noweb и latex, хоть на Emacs org-mode M-x org-babel-tangle и экспорт в ODT, HTML, PDF через latex (например, сборка portacle с portable Emacs позволят по быстрому, не заморачиваясь с настройками и компиляциями — получить под любую ОС последний Emacs с org-mode и SBCL, slime «из коробки»).

пояснительная записка и написана почти что в literate programming стиле: последовательно уточняются и раскрываются основные моменты архитектуры исходников.

основная идея: браузер это набор отдельных модулей, компонент:

• загрузчик HTML через HTTP
• парсер HTML в дерево тегов (простой DOM). в дереве тегов хранятся блоки текста (наподобие galleys в TeX): тег <p> при этом разбивается на несколько блоков (отсюда в текущей реализации артефакты в lavkraft.htm, по идее нужен нормальный алгоритм из того же TeX)
• обработчик дерева тегов в «макет страницы». макет страницы содержит абсолютные координаты и размеры всех блоков.
• просмотрщик. контроллер в MVC, показывает модель макета страницы, обрабатывает GUI и клавиатурный интерфейс с пользователем.

так реализованы почти все браузеры, но у этого есть ряд любопытных особенностей реализации:

1. строки релизованы слайсами массивов (в дипломе: накопители) — ничего не копируется, хранятся указатели на начало и конец слайса. то есть, при построении дерева тегов не жрётся лишняя память. вообще, браузер в текущей реализации довольно компактный (267 кб), другое дело что практически ничего не умеет. частично множества строк реализованы чем-то наподобие интернированных символов в лиспе (в дипломе: наборы (sets))
2. эти модули, компоненты можно рассматривать как узлы в графе  — композабельных конечных автоматов. то есть: композиция конечных автоматов есть новый конечный автомат. парсер текста, парсер дерева тегов, обработка дерева, обработка GUI взаимодействия — это всё такие составимые конечные автоматы.
3. графы переходов конечных автоматов расписаны на картинках, за что отдельное спасибо. теперь можно перевести это вот в тот же libero DSL.
4. для GUI используется библиотека WinLib, реализующая на форте DSL чем-то напоминающий tk из tcl/tk, правда сильно недопиленный. по идее, портировать под иксы эту библиотеку должно быть несложно.

   GRID layout в этом DSL реализует декларативный GUI наподобие tk:

   WINDOWS...
   0 create-window TO окно
   окно TO winmain
   GRID
     " Метка" label -xfixed 
   | edit -xspan
   | === " Нажать" button ['] BYE this -command! -center
   | ===
   GRID;
   окно -grid!
   окно winshow
   ...WINDOWS
   

5. в дипломе: таблицы состояний и решений конечных автоматов — массив векторов. в качестве замены развесистого switch/case.

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

в общем, реализация довольно любопытна:

1. форт, DSLи и Thinking Forth.
2. составимые конечные автоматы для всего
3. понятная наглядная модульная структура
4. накопители, наборы, таблицы состояний и решений КА

сам диплом написан в стиле подробного walkthrough, который руки просто напрашиваются переписать в literate programming стиле, по возможности лайвкодингово (C-c C-c в блоках кода Emacs org-mode, разработка в REPL а не окончательный M-x org-babel-tangle).

в общем, тут есть ясная и наглядная структура, пара сильных стержневых идей. это вполне себе можно довести до ума, до нормальной реализации.

в итоге двигаясь в направлении, указанном hv3 из tkHTML: движок правил для реализации CSS, JS парсер и интерпретатор, доведение своего велосипедного DOM дерева тегов до чего-то более стандартизированного и функционального.

теоретически, в форте или лиспе с мультиметодами, CLOS и MOP и ненужно делать полноценный DOM, нужно делать какой-то полноценный протокол родовых функций.

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

как я себе вижу прогресс различных языков описания макета страницы:

1. простой макет с абсолютными координатами, и по-возможностями, слоями. например, в фидокаде FidoCadJ схема представляется примерно таким кодом:

   [FIDOCAD]
   MC 95 65 0 0 280
   FCJ
   TY 115 60 4 3 0 0 0 * Q1B
   TY 115 65 4 3 0 0 0 * LM394
   MC 55 65 0 1 280
   FCJ
   TY 20 60 4 3 0 0 0 * Q1A
   TY 20 65 4 3 0 0 0 * LM394
   LI 55 65 95 65 0
   LI 40 75 40 95 0
   LI 110 75 110 95 0
   LI 40 40 40 55 0
   MC 40 30 0 0 115
   LI 40 15 40 30 0
   LI 30 15 40 15 0
   MC 30 15 2 0 010
   LI 40 50 60 50 0
   LI 60 50 60 65 0
   SA 60 65 0
   SA 40 50 0
   LI 110 45 110 55 0
   LI 110 35 110 40 0
   LI 110 25 110 30 0
   MC 40 95 0 0 040
   MC 110 95 0 0 040
   TY 45 30 4 3 0 0 0 * 10 k
   TY 115 50 4 3 0 0 0 * I
   MC 110 50 1 0 074
   

   скачиваем один fidocadj.jar, запускаем, в нём нажимаем Ctrl-G и копипастим сей текст. получаем схему. что может быть проще? вот и итальянские радиолюбители постят свои схемы в форумах наподобие LaTeX-разметки (см. мануал fidocadj).

сиё же суть понѣже вѣкторный гипертѣкстовый фидонѣтъ!

если посмотреть вооружённым взлядом (и прочитать раздел 3 в мануале): команда TY text markup TY 115 60 4 3 0 0 0 * Q1B содержит явные координаты и размеры текстового блока обозначения, а команда LINE LI 110 45 110 55 0 — координаты прямоугольного extent линии. один из нулей здесь — номер слоя. то есть, координаты трёхмерны.

и это только начало: въ истинно многомѣрномъ гипертѣксте они вполне себе могут быть четырёх- и поболее многомерны.

могут ли они быть банаховы и адресоваться через tumblers? вообще, речь идёт о протоколах макета страниц для отрисовки и парсера гипертекста, вычисляющегося в экстенты. количество координат тут ни при чём — нужен протокол.

HTML навязывает свою структуру, что партриарх Тед Нельсон считает вредным: встроенная разметка вредна и в итоге приходит к чему-то вроде CSS только по-другому: вместо навязывания как в SGML DTD жёсткой структуры, иерархии и онтологии тегов — сделать три слоя, слой контента, слой структуры и слой спецэффектов. примерно похоже на text view DOM, сам DOM и CSS. но соответствие не 1-в-1 — таких возможных вариантов может быть несколько, можно к одному контенту прикрутить другие представления структур и стилей. например, генерировать автоматически. для контента и структуры изначально предполагался структурный редактор, то есть невозможно создать неправильную структуру. по сути, тут не нужен DOM и паттерны, тут нужны MOP, родовые функции и мультиметоды.

если в HTML пытаются задать жёсткую структуру, в Xanadu эти блоки текста, galleys накладывались оверлеями несколько слоёв в один — и пытались вычислить композитор только нужных частей на лету.

1. вариант — простой язык описания макета страницы как в FidoCadJ, со слоями.
2. следующий вариант — DVI из TeX. здесь как можно понять из dviasm.py тоже простой командный язык. насколько я понял, нет матрицы трансформаций. DVI вполне можно генерировать руками (через dviasm.py, см. PDF на гитхабе)
3. следующий вариант — разные page description language, например PostScript или PDF. если в PS макет страницы — это команды на форте (со строками, сборкой мусора и матрицей трансформаций) как линейный поток текста, в PDF уже появляется какая-то структура и какой-то DOM (а также возможность представить как выглядит страница, не интерпретируя весь исходник макета).
4. далее отрисовку макета страницы пытаются оптимизировать поиском видимых экстентов по дереву. чем-то напоминает BSPtree в 3D графике и движках DOOM, Quake. здесь тоже есть где развернуться, и на мой взгляд, двигаться нужно в направлении, указанной Е. Кирпичёвым в статье про моноидами, измеримые верёвками — строятся структуры «верёвка, всегда знающая свою агрератную функцию», и подобрать функцию для поиска видимых экстентов.
5. далее: такие модули не обязательно должны быть в одной программе, браузере-всё-в-одном. в духе LaTeX или noweb подхода, вполне себе можно генерировать отдельные промежуточные файлы — или, лучше не файлы, а сразу документы. и хранить их в нормальной СУБД, поддерживающей графы и деревья, например MUMPS.

   потенциальный браузер может работать напрямую с БД уже с макетом, построенным предыдущей стадией из гиперструктуры и не держать в памяти нераспарсенное на предыдущих стадиях, кешировать только минимально необходимое.

   весь этот кеш можно зашардить, реплицируя БД аналогично тому как фидопочту передавали чем угодно, хоть флоппiнѣтомъ.

6. далее, если про composable gui. в языке factor, в отличие от форта — функциональном есть встроенный gui, который тоже задаётся декларативной разметкой. ещё там есть макросы и комбинаторы, мультиметоды и прочее. на этом можно изобразить какой-то FRP, паттерн реактор — функционально-объектный, поточный.
7. далее, логично ожидать каких-то composable моноидов высшего порядка, например — гипертекст высшего порядка (дважды косвенные ссылки, ссылки на отнологию, типизированные ссылки и корректность типов, model checking (вот например, Play Engine — симулятор с книжкой. язык LCS расширяющий диаграмму последовательностей UML, с контекстами, состяниями, циклами. и симулятор под винду, с примерами. в тему SWITCH-технологии и составимыхъ конечныхъ автоматовъ.

FINALLY: веб-браузер на форте

в общем, идея этой реализации браузера из диплома — годная, есть основа архитектуры движка.

можно дополировать до нормальной реализации стандартов, но задолбаешься.

при этом нужно использовать не букву, но дух этой реализации — например, заменить форт фактором и поковываться со схемами Libero для генерации конечных автоматов отдельным инструментом, а не пилить свой велосипед на форте.

что забавно, в Tamarin в Firefox была реализация форта. JS vm была написана на таком вот форте. можно было бы написать и весь браузер целиком.

форт, конечно тот ещё язычок (хотя вот книжка Креншоу «Let's make compiler» про рекурсивный нисходящий парсер и кодогенератор языка типа паскаля — переписанная на форте стала, ИМХО, понятнее и нагляднее :))

нужно использовать не букву форта, но дух. например, подход про метакомпиляторы форта: META, forth-metacompiler, или вот целую реализацию lbForth раскрученного в таком вот виде.

forthMacs — emacs на форте в исходниках openfirmware я думаю, может для этого пригодиться

Тед Нельсон, встроенная разметка вредна

fix link

вообще он всю дорогу про то как отвязаться от искусственных, навязанных реализацией онтологий и иерархий — в многомерные фасетные классификации и ZigZag гиперкубы гиперпространств.

midipix

musl это да. находка месяца: midipix.org

ребята пытаются сделать наконец нормальную posix libc под винду. в отличие от cygwin, в котором через cygwin1.dll или от mingw, который зависит от msvcrt и в котором posix подсистема не допилена --- это вот больше напоминает SUA Interix, posix подсистему в винде.

SUA сдохло, что-то взамен есть в win10 для запуска паравиртуализованных elf бинарников, но это не то. неправильно это.

в midipix пытаются реализовать поверх musl нормальную posix подсистему (уже есть форк и сигналы) через Windows Native API. наиболее идеологически правильным способом.

занятно, вроде бы всё собирается и работает.

аналогично msys2 здесь пытаются допилить на основе Arch ебилды арчбилды (простые скрипты на шелл) пакетами: midipix-packages

пока для пакетов работает кроссборка из линукса, самосборку из винды в новой подсистеме x86_64-nt64-midipix не вполне допилили.

находка месяца

nixcpkgs — кросскомпиляция musl функциональным пакетным менеджером Nix.

меня оффтопик вообще не интересует никак. у меня его нигде нет. и я его даже не видела ни разу уже лет десять. даже у знакомых и родственников нет нигде :) так что библиотеки и сборки под него мне как-то ни к чему.

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

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

и да, этот хостинг не хочет отдавать файл: говорит, что включен адблок. но я его никогда не отключаю и к тому же у меня почти все рекламные сайты блочатся на моей проксе. а это вообще отключить проблематично.

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

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

и да, я всё же сторонник максимального огораживания браузера от системы и всякие прямые записи в видеобуфер меня не привлекают. я считаю браузер потеницально опасным софтом, который надо запускать в отдельной песочнице, чтобы он ничем не управлял вообще и имел только очень лимитированный доступ к ресурсам системы.

в общем, лучше такие хостинги не юзать. чтобы скрипты не писать :)

сорри, ткнул в первый попавшийся :)

может, гляну код на досуге. я форт не знаю, хотя там не должно быть ничего особо сложного.

язык несложный, хотя надо в уме держать стек, что не совсем удобно. в этом смысле фактор функциональный конкатенативный удобнее, потому что есть цитирование, квазицитирование и комбинаторы — и получается мыслить более крупными блоками. поэтому на фактор, на мой взгляд, программировать проще.

в коде любопытна не то, чтобы конкретная реализация (хотя есть моменты), сколько то, что можно написать такой DSL, в духе Thinking Forth

меня больше интересует принцип написания браузеров.

как работает браузер (современный, с инкрементальной компоновкой)

меня тут интересует вопрос: почему он так жрёт память. то ли на DOM, то ли на песочницу JS, то ли на кеширование. и как эти затраты сократить. кеширование кажется вообще нормально не работает (хотя и современный веб тоже плохо кешируется) — много всего и сразу обновляется, мало повторно используется.

я считаю браузер потеницально опасным софтом, который надо запускать в отдельной песочнице, чтобы он ничем не управлял вообще и имел только очень лимитированный доступ к ресурсам системы.

аналогично. вообще то что в современном вебе куча JS — не от хорошей жизни. моя гипотеза в том, что это изъян самой изначального ППП (а не гипертекста вообще, в нормальной его реализации) — не достаточно полно задана сама модель составимых документов, в результате из DOM+JS+jQuery+... получается буханка и троллейбус, и велосипед с квадратными колёсами у каждого второго.

меня тут интересует вопрос: почему он так жрёт память.

я как-то на одной конференции по плюсам пристала с этим вопросом к одному из разработчиков браузеров. и он сказал, что главная проблема - это песочницы для js и разделение данных между страницами. учитывая возможные утечки и умышленные атаки, надо очень тщательно всё огораживать. из-за этого тратится туева хуча ресурсов. я не знаю, как реализована js-машина, но подозреваю, что корень проблемы может оказаться именно в ней. я полагаю, что при грамотном выделении памяти в самой машине таких проблем возникать не должно. однако, они возникают. ну и плюс современные веб-макаки, которые шлёпают жуткие скрипты. при грамотном использовании js (по крайней мере, меня так заверяли спецы в js) он не жрёт много ресурсов. а сейчас просто вообще не задумываются о качестве скриптов, поэтому они жрут много просто сами по себе. ну и DOM - это та ещё зараза. а SAX-парсеры в браузере невозможны, опять же, из-за скриптов: скрипты обращаются к элементам и однопроходным (и даже многопроходным) рендерингом там всё не решается. надо хранить всё барахло в памяти. если бы не было динамической генерации контента на стороне юзера, было бы всё значительно проще и оптимальнее. по идее, скрипты можно было бы оставить на запросы в бэкграунде, на какие-то вычисления. но не на генерацию контента.

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

кстати, Мозилла тут собралась убить хранилище XUL-аддонов в ближайшем будущем:
https://www.bleepingcomputer.com/news/software/mozilla-to-remove-legacy-firef...
может, это даже потянуло бы на мини-новость, но мне лень оформлять. так что есть подозрение, что многие браузеры, которые основаны на XUL, и старые версии типа ESR могут остаться без аддонов. копировать мозилловское хранилище к себе очень затратно.

пипец котёнку

от файрфокса был смысл только в плагинах. сейчас старые не работают, новых толком нет. ещё и старые убьют, ну и какой тогда смысл в файрфоксе?

может, это даже потянуло бы на мини-новость, но мне лень оформлять

Я не поленился Mozilla удалит все устаревшие дополнения

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

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

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

Да, соглашусь, наконец из жирнолиса нормальный браузер сделали. Однако удалять старые поддоны? Это какая-то дичь. Но ghacksuserjs в других браузерах работать не будет, так что никаких вариантов.

Поддоны на плюсах это самый шик, зачем нам песочницы, зачем нам безопасность? Нет, лучше будет использовать нативщину в вебе.

браузер нативный. я это называю «нормальный». всё остальное - подгузники для неосиляторов. и да, макаки не должны писать плагины. они должны подметать дворы.

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

Ну, не так уж затратно, всего-то 30 гигов, уже есть проект по спасению: https://github.com/JustOff/ca-archive/issues/8

Ну, и Mozilla многие из них не убирает насовсем, переносит в другое место: https://www.opennet.ru/opennews/art.shtml?num=48946

Falkon напоминает мне midori, такое ощущение, что midori с gtk на qt переписали. В убунте и федоре falkon часть kde тянет. Кстати, midori ещё жив, судя по активности на https://code.launchpad.net/midori, и у меня даже собрался без ошибок на современной системе вот с этим патчем https://forum.altlinux.org/index.php?action=dlattach;topic=40662.0;attach=22673

вот, кстати, Мидори я не пробовала собирать из сорцов. я его помню из какого-то маленького и лёгкого дистра: то ли из Slitaz, то ли из Raspbian. вроде ничо так, работал. но они пишут, что он базируется на Gtk. причём со всяким барахлом типа иконок и прочего ненужно. у Фалькона иконки тащатся из темы для браузера (там CSS-ки, иконки и мелкий файл настроек). я не люблю третий гном и опасаюсь зависимостей от Gtk в любом виде. потому что он сам по себе монстрозен и ставится как огромное жирное скопление библиотек, специфических утилит и всяких ненужных погремух. я гном не использую и такие зависимости мне менее всего нужны. культя, конечно, тоже изрядный жир. но она всё же компактнее гнома, пока что.

будь моя воля, я бы переписала графику браузера на Enlightenment (EFL). пока что это самая изящная и шустрая реализация графики из всех, что я видела.

Ну, и Mozilla многие из них не убирает насовсем, переносит в другое место

ну, это они для начала «переносят» (и то только отдельные самые популярные аддоны, заметь). у них весь смысл этого действа, как я понимаю, впарить насильно юзерам новую версию. юзеры не хотят эту новую версию, в ней нифига полезного нет, большинство плагинов не работают. поэтому Мозилла педалирует своё поделие таким нехитрым способом.

юзеры не хотят эту новую версию

Вот прям Мозиле сильно важно эту пару маргиналов сидящих на протухшей версии, в пересчете на проценты долю стремящуюся к нулю, пересадить на новую версию... Клоунада засчитана.

судя по всему, да. клоунада не моя, а мозилловская. все претензии/восторги - к ним.

Мне кажется SeaMonkey 2.48 более душевный браузер. Я сейчас приладил Pale Moon как легкую альтернативу, но все равно скучаю по SeaMonkey. Говорят она скоро RIP.

з.ы links/links2 не предлагать

Предлагаю lynx

Предлагаю w3m.

qutebrowser предлагали?

Да, я смотрел протоколы митингов --- настроения там пессимистичные. Ещё и на WaterFox огрызаются: мол, раз у нас ничего не получится, то и у них тоже. Впрочем, основная цель проекта Seamonkey --- комбайн, а не сохранение классических технологий; в таком виде оно может прожить ещё долго, даже если вообще движок сменит, как хропера — там тоже вон встроенный почтовик возвращают.

Да мне в общем-то все равно на развитие, использую с отключенным JS, в таком виде еще долго проживет, даже если забросят. Главное внешний вид и легкость. Я бы может старую добрую оперу престо оставил, но под линуксом у нее проблемы с сертификатами и мне не нравится поведение вкладок.

Вот только пусть не на qt curve полученный от гтк гнома с помощью списывания мною цветовых настроек к qt 4онфиг , а то тут все умничают , как на корявом кью те 5 так сразу не умеем в кустики

с отключенным JS
долго проживет

Лолнет. Уже даже документацию на JS завязывают. О сайтах и говорить нечего.

Я не жалуюсь. Ну, конечно, основной браузер у меня Firefox Quantum.

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

и да, есть Netsurf, который никакого говна в систему вообще не тащит.