Pull to refresh

Comments 33

А хром, например, нельзя использовать? Или он не запустится на калибри?
KolibriOS — любительская операционная система для x86-совместимых компьютеров, ядро которой полностью написано на языке ассемблер… использует собственные стандарты и не является POSIX или UNIX совместимой
архив всех программ, написанных под эту ОСь, весит меньше хрома раза в 2 :)
Замечу, что портирование Chromium теоретически возможно, но ресурсов для этого у проекта нет — в частности, человеческих.
Зато возможно практически портирование другого браузера, поменьше.
Netsurf сейчас дорабатывается.
image

А когда (если) портируют/выйдет NetSurf для KolibriOS, разработка WebView будет приостановлена?
Вряд ли. Хотя в WebView много архитектурных проблем, NetSurf значительно массивней. Размер бинарника Netsurf раз в 70 больше, и он использует очень много чужеродных для Колибри библиотек — freetype, libjpeg и так далее.
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
разве Chrome/Firefox «убили» разработку текстовых браузеров?

Если честно, то похоже на то, ибо я не могу вот сейчас навскидку назвать более одного (теперь — двух) текстовых браузеров.
Это lynx/Links и теперь WebView. Да и Links тоже умеет картинки выводить на самом деле.
WebView тоже умеет выводить картинки, но пока не умеет загружать их из сети.
Добавьте к своему списку w3m, netrik, zen, debris, edbrowse. Кстати, lynx, links, elinks, links2 — разные браузеры.
w3m, netrik, zen, debris, edbrowse. Кстати, lynx, links, elinks, links2 — разные браузеры

Ладно, убедили o_O
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
А разве нет? Вы тут перечислили целую кучку браузеров, но когда у них что-то новое выходило? w3m — три года назад, netrik — пять, debris — десять, zen прямо на своей старнице пишет «Please note that this project is no longer in development»… Разработка lynx'а/links'а вроде теплится — но тоже едва-едва: на то, чтобы вышла предыдущая минорная версия lynx'а ушло три года, на версию 2.8.8, похоже, лет 10 понадобится. Links, правда держится (последней версии всего полгода!), но он уже и не совсем текстовый.
Всё верно. Но, с другой стороны, а что ещё им добавлять? CSS Transitions? WebGL? Стандарты, которые могут быть поддержаны в текстовых браузерах, сильно ограничены. Разве что поддержку DOM/JS можно улучшать до бесконечности.
Также замечу, что возможно создание имплементации Linux ABI и эмуляции окружения POSIX, портирование иксов и запуск хромиума ^_^
короче, возможно всё :)
Конечно, возможно. Я вот этими своими кривыми руками *смотрит на руки* добавлял обработчик int 0x80 в ядро, писал два десятка основных POSIX-функций, и запускал несложные elf-бинарники из Колибри. Аналогичный проект для PE/WinApi позволяет даже запускать TASM.
JavaScript в отрыве от DOM — штука для браузера малополезная.
Можно попросить скриншот Хабра или Википедии для примера?
А, ведь, весьма неплохо! Даже хорошо, что нет ничего лишнего, только контент!
Заметил, что у вас выводятся машинописные кавычки, а не ёлочки. Это особенности шрифта или проблема с кодировками?
Проблема и в том, и в другом. В шрифте «ёлочек» нет — в Колибри используется модификация CP866, с некоторыми символами для европейских языков. Полная поддержка UTF в системе — задача прелюбопытнейшая, но пока что ей никто не занимался.
А войти и написать что-нибудь получится?
Нет, пока что поддержка форм в WebView отключена (вероятно, из-за нефункциональности), а POST и cookies не поддерживаются. Автор программы, разумеется, знает о том, что это очень нужно и важно.
Мне кажется, что с целью еще большей минимизации используемого места, стоило бы все же допилить Downloader, т.к. нечто умеещее работать с HTTP уже есть. В общем по-моему unix-подход «1 программа для 1 задачи» в вашем случае оптимален.
Интересное мнение.

К сожалению, в downloader можно передавать только адрес, но нельзя передавать заголовки. Плюс IPC было через файл /rd/1/.download (на рамдрайве, размер которого ограничен).
Одно из возможных решений: действительно расширить функционал downloader. Чтобы он понимал заголовки и тип запроса в качестве параметров; чтобы обмен данными вёлся через именнованную общую память.
Другое решение, которое и было использовано: программа downloader была разделена на библиотеку libhttp и интерфейс к ней. API библиотеки прост и понятен, а сам механизм взаимодействия проще, чем в случае с shared memory. Сам downloader стало проще расширять, улучшать и модфицировать.

О преимуществах разных подходов можно спорить вечность. Если бы Колибри была ОС с UNIX-корнями, то, я думаю, предпочтение отдавалось бы первому решению. Однако, Колибри действительно далека от *NIX; можно сказать, что какие-то несколько лет назад она была почти полной противоположностью. До появления в относительно недавнем прошлом shared memory и локальных сокетов взаимодействие между процессами было возможно только через файлы или очень-очень медленную функцию обмена сообщениями через ядро, которая носит гордое имя «IPC». Каналов в Колибри нет до сих пор (что очень мешает переносу консольных POSIX-совместимых приложений). Однако, Колибри интересна, на мой взгляд, именно своей самобытностью. Позволяет иначе взглянуть на «привычные» вещи.
UFO just landed and posted this here
Насколько мне известно, есть. Колибри может быть интересным суповым набором, если требуется очень быстрый доступ к «железу» и графика. Порты линуксовых драйверов ATI/AMD и Intel этому способствуют. Приятные «бонусы» — BSD-совместимые sockets, стек USB OHCI/EHCI/UHCI (мышки-клавы-флешки) и звуковая подсистема с поддержкой Intel HDA.
Я имел в виду, что unix-подход вам бы подошел по той причине, которая ведет в некоторых случаях (например как этот) к уменьшению количества кода — а значит и размеров бинарников. Думаю в ОС которая влезает на дискету это очень важный момент.
Я не говорю что, мол, «давайте делайте все как в никсах», я говорю что это же логично — если какой-то функционал используется не только в одном месте, то можно его отделить и немного сэкономить :)

Если сам downloader уже тоже использует общую библиотеку, то все ок. Просто из статьи я лично этого не понял.
«New Downloader» использует libhttp практически с рождения. И вот почему.

В Колибри за последние два-три года изменилось очень многое. Так, была выброшена на обочину истории сетевая подсистема MenuetOS. Героическими усилиями разработчика hidnplayr в Колибри появилась новая сетевая подсистема, с BSD Sockets и поддержкой одновременной работы нескольких сетевых интерфейсов. Все сетевые приложения превратились в тыкву. Многие были написаны практически «с нуля», включая downloader/libhttp. И жить стало лучше, жить стало веселее.
Чувствую меня уже не раз поминали дурным словом, за то что проект начинался на C--. Да и честно говоря он не планировался как полноценный браузер. Чисто документацию к системе в html чтоб можно было смотреть.
Там же еще проблема в том, что не строится DOM-дерево, а сразу рисуется, из-за чего полноценный css и js невозможен.

Но надо отдать должное Leency (Кириллу) и всем кто дальше поддерживал этот проект, получилось весьма неплохо
Sign up to leave a comment.