LINUX.ORG.RU

Haiku, Inc. проспонсировала приобретение RISC-V материнских плат для портирования системы Haiku

 , , ,

Haiku, Inc. проспонсировала приобретение RISC-V материнских плат для портирования системы Haiku

2

4

Изобретатели RISC-V создали компанию под названием SiFive, и эта компания недавно выпустила SoC под названием HiFive Unmatched. Задолго до этого релиза один из разработчиков Haiku - Alexander von Gluck IV (kallisti5) сделал предварительный заказ на эту плату и начал работу над переносом Haiku на RISC-V, добившись некоторого прогресса в работе над загрузчиком, поддержкой u-boot и маппингом памяти.

Примерно два месяца назад другой разработчик Haiku — Ilya Chugin ( X512) также начал работать над портом RISC-V для Haiku, но под другим углом. Подробностей слишком много для этого поста, но их можно прочитать в его теме на форуме Haiku. Подводя итог: он портировал небольшой эмулятор RISC-V под названием TinyEmu на Haiku, написал игрушечную операционную систему и другие инструменты для изучения платформы, затем он медленно заставил Haiku работать в этом эмуляторе с полной поддержкой графического интерфейса, постепенно получая все больше и больше работающих частей Haiku. Затем он начал проделывать аналогичную работу в QEMU, который более точно эмулирует реальное оборудование. Все это было сделано в самой Haiku, работающей на компьютере x86.

Несмотря на то, что все это было сделано в режиме эмуляции, портирование Haiku на RISC-V провиднулось значительно дальше, чем на какую-либо другую платформу, помимо x86.

Учитывая этот огромный прогресс, достигнутый Ilya Chugin (X512) в портировании Haiku, члены сообщества спросили, может ли Haiku, Inc. проспонсировать покупку платы HiFive Unmatched для X512, и после недолгих размышлений Haiku, Inc. согласилась сделать это. Ilya Chugin уже получил деньги для покупки платы и уже ее заказал. Ожидается, что плата прибудет к 6-7 июля 2021 года.

Вдобавок к этому, Haiku, Inc было решено возместить сумму, которую затратил ранее Alexander von Gluck IV (kallisti5) на приобретение материнской планы HiFive Unmatched, хоть он и этого не просил. Это было сочетание спонсорства, ровно также как и для X512, а также и благодарности Alexander за его преданность сообществу и его неустанные усилия по работе над инфраструктурой Haiku и многие другие заслуги, такие как его собственная работа над портом RISC-V.

Мы ожидаем, что и X512 и kallisti5 продолжат совместную работу над портом и, имея теперь одинаковое оборудование добьются отличных результатов.

Также стоит напомнить, что в конце июля ожидается очередной выход бета-версии операционной системы Haiku, на этот раз под номером 3.

Всех заинтересованных милости просим в наш уютный чатик в телеграмме.

>>> Подробности



Проверено: a1batross ()
Последнее исправление: CYB3R (всего исправлений: 9)
Ответ на: комментарий от beos

без лишнего наворота

То есть PCI — это уже наворот?! о_О

энергоэффективно

Это я знаю, потому периодически пускаю слюни на RISC-V, а железок как не было, так до сих пор и нет.

mord0d ★★★★★
()
Ответ на: комментарий от beos

Встроенного звука я так понимаю нет. Надо через USB подключать.

X512 ★★★★★
()
Ответ на: комментарий от beos

можно поставить pci-e x4 с вырезом в конце слота, чтобы x16 карты вставлялись, всё будет работать

anonymous
()
Ответ на: комментарий от mord0d

Это PCIe

PCI не express устарел и в новых платах его нет в том числе на x86.

смотри на крепление

Крепление плат расширения осуществятся за счёт корпуса.

X512 ★★★★★
()
Ответ на: комментарий от X512

PCI не express устарел и в новых платах его нет в том числе на x86.

Соболезную новому миру. ☺

смотри на крепление

Крепление плат расширения осуществятся за счёт корпуса.

Я про наличие "усов" с нижней стороны. У PCI их нет, они появились только на PCIe.

mord0d ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Визуально на картинке (если они не рядом установлены или изображения не 1:1) спутать можно только PCIe x16 с PCI. Потому я на крепления и смотрю в этих случаях.

mord0d ★★★★★
()
Ответ на: комментарий от EXL

Ога, вот только в реальности:

One of the huge advantages of KWin is the exchangeable compositor allowing to switch to software based XRender in case there are no proper drivers available. In fact KWin switches automatically to XRender if it detects a driver which recommends the XRender backend (e.g. software rasterizer).

https://blog.martin-graesslin.com/blog/2013/06/more-software-compositing/

Извиняюсь на оффтоп, но Xrender недавно выкинули из Kwin :)

Sunderland93 ★★★★★
()

Основную работу над портированием осуществляет X512? Зачет!

hateWin ★☆
()
Ответ на: комментарий от mord0d

мне RISC-V пригодился бы только как боевая машина

Этот Unmatched — вполне себе боевая машина. 16GB RAM, NVMe SSD, Eth, WiFi. 4 вполне себе неплохих 64-битных ядра. Видеокарты заводятся. Ценник, конечно, заоблачный для такой вещи. Но конфиг, сам по себе, борзый.

aist1 ★★★
()
Ответ на: комментарий от aist1

Конфиг для какого-нибудь ноута — вполне. В качестве домашнего сервера не годится никак. В PCI я бы ещё воткнул SATA, про PCIe вообще ничего не знаю (и знать не хочу, еретики!).

mord0d ★★★★★
()
Ответ на: комментарий от anonymous

Да, разумеется быстрее, да и dx9 позволяет намного лучшую графику чем openGL ES.

Но я точно не втирал, что «все игры» и «летают». Суть в том, что для выполнения базовых задач десктопа даже уровня mali 400 более чем достаточно. Есть конечно вопрос поддержки драйвера и данной конкретной технологии для данной конкретной задачи, но вычислительной мощности более чем.

kirill_rrr ★★★★★
()
Ответ на: комментарий от aist1

Как бы это всё могло выглядеть?

IBM сделал плату db/2 под as/400 (ну и os/400). Не знаю, как сейчас это живёт, и живёт ли.

beck ★★★★
()
Ответ на: комментарий от X512

Не совсем без проблем. 33MB/s линейной скорости и, скорее всего, нужны будут драйвера. Проще по USB подрубить диски, если уж очень надо.

aist1 ★★★
()
Ответ на: комментарий от beck

Не знаю, как сейчас это живёт, и живёт ли.

Ну, учитывая, что кобол живее всех живых, то скорее да, чем нет.

Тут дело в том, чего хотят программисты. А хотят они того, с чем привыкли работать. А привыкли работать они с базами данных. Они привыкли, что у них есть транзакции и что у них есть языки запросов. А файлы — это не просто «слишком низкоуровнево». Файловые системы не обеспечивают нужной операционной семантики. Что у нас там с конкуррентностью доступа? POSIX Locks? Oh yeah, baby!

Нишу, о которой я говорю сейчас занимают встраиваемые БД типа SQLite. И последняя, действительно, делает своё дело. Но есть нюансы...

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

Ну и, самое главное. У SQLite модель «один писатель, много читателей». Писать в каждый момент в БД может только один клиент. Т.е. транзакции, обновляющие БД должны быть короткими, чтобы другие писатели не ждали слишком долго своего слота. У файловых систем, на самом деле, оно точно так же (не у всех), просто параллельные писатели мультиплексируются еще на уровне VFS.

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

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

aist1 ★★★
()
Ответ на: комментарий от beck

Вдогонку...

Когда возникает новый класс вычислительных устройств, мы сначала пытаемся в нем реализовать привычный нам уже experience. Например, запихнуть Windows на наладонники. Или заапскейлить Линукс сразу на всё облако. Не 1-в-1, разумеется, хотя и такие эксперименты были. Но, рано или поздно, новое окружение для разработки приложений формируется, становится привычным, и мы уже хотим вернуть его «обратно». Мы уже хотим использовать на локалхосте те же техники и инструменты разработки приложений, которые у нас есть на том же AWS. S3 API уже становится де-факто стандартом для доступа к объектным хранилищам и много кто его уже эмулирует прямо из коробки.

Я не говорю про то, что есть смысл миниатюризировать конкретно AWS до уровня настольной OS. Хотя до уровня маленького частного облака — уже можно. Amazon предоставляет эту возможность именно из-за привязки приложений к своим API и парадигмам.

Я про то, что по факту уже идет унификация сред между десктопом, облаком, мобайлом и IoT. И там в качестве стораджа или базы данных, или объектные хранилища. ОС, которые хотят «быть в тренде», должны как-то этот тренд к унификации учитывать.

aist1 ★★★
()
Ответ на: комментарий от anonymous

Проверь, в штанах не подтекает ли случайно? Эстет ты наш.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anonymous

блендер использует

Очевидно, если тебе нужен полноускоренный Blender то Haiku точно не для тебя.

Но если посидеть в дистрибутиве Linux, позапускать все эти наши современные системные программы и современный UI написанный на Qt 5 и GTK+3 средствами Qt 5, а потом дуалбутнуться в Haiku, установленную на железо, и позапускать софт на местном Haiku API там, встанет другой вопрос – как же так получилось, что в Linux программы открываются настолько медленее, а GUI менее отзывчив.

libagg всё-таки очень быстрая штука.

EXL ★★★★★
()
Ответ на: комментарий от EXL

встанет другой вопрос – как же так получилось, что в Linux программы открываются настолько медленее,

Динамическая линковка?

aist1 ★★★
()
Ответ на: комментарий от Dark_SavanT

А ведь когда-то кубом на Beryl заманивали в линуксоиды…

Да ладно, тот же Compiz с кубом и эффектом огня и прочими свистоперделками был куда как популярнее :)

О Beryl даже тогда слышали немногие, а Compiz до сих вспоминают и форкают.

EXL ★★★★★
()
Ответ на: комментарий от aist1

Динамическая линковка?

Она и в Haiku используется. Тут скорее играет роль общая раздутость GTK+3, Qt 5 и всего того, что работает под их слоем. Пока развернётся в память зависимость от какого-нибудь libicu на 30 МБ в Qt 5, пока развернутся в память ~60 штук мелких либ от которых зависит даже Hello World на GTK+3, пока прочитается километровая тема для угрёбищной мимикрии приложения под Breeze-gtk или Adwaita, пока переинициализируются и настроются контексты через всякие там прослойки Xlib/XCB/XWayland/libwayland и т. д. пройдёт куча времени и приложение запустится с задержкой.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Всё верно. Либы очень большие + их много и из каждой берется по копеечке. Их все пока только с диска собрать, уже будет долго. Когда Haiku разрастется, в ней будет то же самое :)

aist1 ★★★
()
Ответ на: комментарий от aist1

У меня в данный момент установлено 1505 пакетов в Haiku. Изменений в отзывчивости приложений и скорости их загрузки я не наблюдаю.

threedeyes
()
Ответ на: комментарий от EXL

встанет другой вопрос – как же так получилось, что в Linux программы открываются настолько медленее

У тебя Pentium 4?

wandrien ★★
()
Ответ на: комментарий от threedeyes

Поправлюсь))

Когда API Haiku разрастется, там приложения тоже будут грузиться долго. Просто потому что так работают разделяемые библиотеки. Хочешь быстрой загрузки -> компилируешь в статике или предзагружаешь библиотеки (сильно помогало на HDD).

aist1 ★★★
()
Ответ на: комментарий от anonymous

и как же число установленных пакетов может на это влиять, гений?

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

threedeyes
()
Ответ на: комментарий от threedeyes

У тебя есть какие-нибудь числа, сколько пакет занимает «в среднем»? Не буду утверждать, но думаю, что немного относительно типовых объемов памяти. Условно, мегабайты.

aist1 ★★★
()
Ответ на: комментарий от aist1

Хорошо, а теперь давай глянем на зависимости QPA-XCB линуксового (libfontconfig1,libfreetype6,libx11,libx11-xcb,libxext,libxfixes, libxi,libxrender,libxcb1,libxcb-glx0,libxcb-keysyms1,libxcb,image0,libxcb-shm0,libxcb-icccm4,libxcb-sync0,libxcb-xfixes0,libxcb-shape0,libxcb-randr0,libxcb-render-util0,libxcd-xinerama,libxkbcommon,libxkbcommon-x11) - https://doc.qt.io/qt-5/linux-requirements.html

И глянем сколько зависимостей в QPA-Haiku - (libbe,libroot,libtracker,libgame) - https://github.com/threedeyes/qthaikuplugins/blob/master/platforms/qhaikuplatform/haiku/haiku.pro#L11

Угадай с трёх попыток где будут быстрее загружаться (и загружаются) Qt-приложения?

threedeyes
()
Последнее исправление: threedeyes (всего исправлений: 1)
Ответ на: комментарий от aist1

Просто потому что так работают разделяемые библиотеки.

Хотелось бы добавить к этому чудному посту - «Лучше вообще ничего не грузить».
Работать будет много быстрее.

anonymous
()
Ответ на: комментарий от threedeyes

Так я ж говорю. Если (когда) Haiku станет популярной, и под неё тоже будет писаться/портироваться много софта, то там тоже зависимости начнут «расползаться».

Но я не думаю, что сейчас, на современных процессорах и на SSD есть какие-то ощутимые проблемы со стартом динамически слинкованных приложений. Проблемы были 10 лет назад и на HDD.

Есть еще проблема с инициализацией приложений, и она от линкера мало зависит. А больше от того, какой аллокатор. В Линуксе штатный — тормоз тот еще, как только память начинает выделяться в 2 и более потока.

aist1 ★★★
()
Ответ на: комментарий от anonymous

И эшо.

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

anonymous
()
Ответ на: комментарий от aist1

Если (когда) Haiku станет популярной, и под неё тоже будет писаться/портироваться много софта, то там тоже зависимости начнут «расползаться».

Нет. В Haiku принято использовать крупные системные библиотеки своего производства вместо кучи мелких от разных авторов. Например весь тулкит реализован в libbe.so, вся libc включая libm, libpthread, в libroot.so.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

$ ldd soffice.bin |wc -l
130

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

aist1 ★★★
()
Ответ на: комментарий от X512

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

Нет авторов, нет и библиотек.

wandrien ★★
()
Ответ на: комментарий от X512

когда будете использовать крупный libVulkan.so своего производства?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.