LINUX.ORG.RU

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 ()

Ответ на: комментарий от wandrien

В том же Windows такой же подход: используются крупные системные библиотеки kernel32.dll, user32.dll, gdi32.dll, advapi32.dll и т.д.. Мелочь вроде libz, libpng при динамической линковке обычно не применяется.

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

вот тут-то и и сел в лужу, в венде давно их разбили на тыщу мелких api-ms-win-*.dll

что показывет, что подход хайку - устаревший маразм

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

в венде давно их разбили на тыщу мелких api-ms-win-*.dll

4.2. Все эти api-ms-win-*.dll – это обёртки над обычными kernel32.dll и т.д. использующие import forwarding.

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

libpng куда только ни вкомпилирован. …статически.

Да. Потому что нормальных пакетных менеджеров нет.

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

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

В том же Windows такой же подход: используются крупные системные библиотеки kernel32.dll, user32.dll, gdi32.dll, advapi32.dll и т.д.

И правильно …

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

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

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

…статически. И в WinApi есть свои функции для чтения картинок и модули кодеков.

Кстати, разработчики графических форматов и разного tools за частую много «велосипедного» API разрабатывают.
А ведь «теоретически», хорошо бы иметь либу, предоставляющую наиболее часто используемый общий API.
А его МНОГО /например работа с цветами, …/ …

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

статически линкуются приложения, которым важна быстрая работа благодаря whole program optimization

Ну и это тоже, да. Даже и без WPO будет быстрее.

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

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

В этом случае разделяемый формат - «самое то».
Унификация-с и Стандартизация-с …

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

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

В Windows (как и в Haiku) есть своё API для чтения и записи картинок, использование libpng – ССЗБ.

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

В этом случае разделяемый формат - «самое то».

Вопросы, связанные с функциональностью динамических и статических библиотек очень важны.
Ныне ИМХО то что имеем больше похоже на - «Танцуют все».
А вот вопросов, связанных с развитием архитектуры статических b разделяемых библиотек не мало /впрочем вопросов не мало и по линковке …/ …

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

ссзб это для чтения картинок завязываться на не портабельные системные апи

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

В Windows ... использование libpng – ССЗБ.

Кроссплатформенность же! Это здорово, конечно, использовать предоставляемые платформой API, но это дополнительные затраты при разработке.

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

Кроссплатформенность же!

В Qt тоже есть своё API для чтения картинок. И вообще работа кроссплатформенных приложений находится за пределами ответственности ОС и лежит на авторах кроссплатформенных фреймворков и/или авторах программ.

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

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

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

А его МНОГО /например работа с цветами, …/ …

Здесь собственно и не разработка нужна как таковая.
Много хорошего API уже разработано в разных проектах.
Создание такой библиотеки скорее рутинная /но нужная/ работа, которая должна унифицировать уже разработанный кем-то API.
Понятно, что нужна систематизация, рефакторинг, документация, … вообщем ИМХО - НУЖНАЯ РУТИНА.

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

Круто! Дайте два! (%

Но я всё же подожду, ценник уж сильно кусается. ☺

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

Кто мне возместит замену рабочих девайсов на новомодные?

mord0d ★★★★★ ()

Плата пришла прямо сейчас, но другие части (корпус, блок питания, видеокарта, NVMe SSD) заказанные через Амазон пока нет.

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

Плата пришла прямо сейчас, …

Шутка

Вы станете Юрием Гагариным, на просторах вселенной RISC-V …

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

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

в х..у вообще нет никаких крупных библиотек собственного производства, что там для кодирования/декдирования видео ?

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

Дело было вечером, делать было нечего …

Экспромтом.

Исследователи, вот вам задача /кстати не сложная и полезная/.
И так имеем N репозиториев, которые как-то там взаимосвязаны.

Задача

Проанализировать все связи репозиториев и перестроить их таким образом, чтобы минимизировать количество зависимостей.  
anonymous ()
Ответ на: комментарий от X512

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

Linux на голову выше и гибче - всю корневую ФС можно слинковать статически вместе с ядром, разместить на NOR flash и исполнять прямо с носителя. На RISC-V линукс появился когда ещё реального железа не было. Х..ки пересобирают линуксовые тулзы и как бсд-ки ведут себя очень недружелюбно по отношению к оригиналу.

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

Linux на голову выше и гибче - всю корневую ФС можно слинковать статически вместе с ядром, разместить на NOR flash и исполнять прямо с носителя.

БуханкаХлебаТроллейбус.jpeg.

В Линуксе всё время возникает нездоровая тенденция прибить систему гвоздями к железу как можно покрепче. То его напрямую из CoreBoot запускают, то его вместе с таблицей FDT поставляют. Это как припаивать электроприборы к сети вместо подключения с помощью стандартных вилок и розеток.

Благо сейчас везде UEFI со стандартным интерфейсом так что система может запускаться на разном железе без доработки напильником. В том числе сабж (HiFive Unmatched) поддерживает UEFI.

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

В Линуксе всё время возникает нездоровая тенденция

Linux это майнстримная ОС в промышленности и дорабатывается под её нужды. Нездоровая тенденция - приписвать х..ку свойства которыми она не обладает в принципе

Благо сейчас везде UEFI

найди UEFI на своей плате которую тебе подарили

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

Команда bootefi в u-boot

я знаю что такое u-boot (загрузчик для Linux под GPL), там есть эмуляция UEFI, на плате или в процессоре нет встроенного UEFI

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

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

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

@X512, как разработчик по хорошему завидую вам.
Не вашим лаврам, а интереснейшей и нужной работе.

Ну да ничего.  
Интересной и НУЖНОЙ работы ОКЕАН!
anonymous ()
Ответ на: комментарий от ixrws

Тогда дизайн выключателя устарел

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

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

Так устроена жизнь у шизофреников. В реальном мире даже колесо не имеет «окончательного» вида.

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

В реальном мире даже колесо не имеет «окончательного» вида.

Но всё-таки есть некоторый, явно выраженный, аттрактор, вокруг которого возникают вариации.

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

Он император?

«Царь, просто царь».

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

А я, дурак, им ONTAP грузил

что это меняет ? первичная цель - загрузчик для embedded Linux. Это не UEFI ниразу, хоть и имеет частичную реализацию его спецификации для загрузки. TianoCore, coreboot - вот это про UEFI для пека, для embedded UEFI срань не нужна в принципе.

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

Это не UEFI ниразу, хоть и имеет частичную реализацию его спецификации для загрузки.

Для Haiku хватит. По крайней мере в QEMU запускается.

coreboot - вот это про UEFI

В Coreboot нет UEFI, его надо прикручивать сторонними библиотеками.

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

В Линуксе всё время возникает нездоровая тенденция прибить систему гвоздями к железу как можно покрепче. То его напрямую из CoreBoot запускают, то его вместе с таблицей FDT поставляют

Для Haiku хватит. По крайней мере в QEMU запускается.

вот видишь - запускаешь свою х..у линуксовым загрузчиком который основан на коде линукса (драйверы с device tree и целые подсистемы почти без изменений переносят из Linux в u-boot) и несёшь чушь что в Linux что-то прибито а по сути без Linux х..у просто пшик - даже не загрузится.

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

Соглашусь только с первым пунктом. Всё остальное — заскорузлые мифы.

Про «распилы и откаты». Насколько я помню, был ровно один случай, когда команда ReactOS попала в число призёров некоего конкурса (вместе с альтлинуксом, кстати) и то ли получила, то ли не получила грант аж в 100 тысяч рублей. За проект, которому на тот момент уже было что-то около 15 лет, ага. Ну да, можно покричать про распилы, если самому не смешно, конечно.

Про евангелиста. Да, он себя кое-где вёл не лучшим образом. Однако не надо путать причину и следствие. Долгое время каждая новость про реактос сопровождалась кампанией массированной клеветы со стороны анонимных (да и не только анонимных) шавок. Шавки на голубом глазу тявкали, что никакой разработки не существует, что весь реактос то ли украден из wine, то ли пишется студентами на попиленные деньги. Когда я их тыкал мордочкой в репозиторий (в котором самые старые коммиты импортированы аж из cvs, а чуть позже из svn), они, естественно, сливались, потом всё начиналось по новому разу. Одно время новости про реактось приходилось просто огораживать от анонимусов. Не совсем красиво выдвигать евангелисту претензии, что он не на все вопросы отвечал с улыбкой и приветствием (хотя да, евангелист должен обладать выдержкой).

Про мутные истории — да, это именно «мутные истории». Про линукс тоже были «мутные истории», которые SCO рассказывала. Чем кончилась, надеюсь, помнишь.

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

Я бы, если б выбирал с чистого листа, в какой проект вложиться из этих двух — выбрал бы наверняка Хайку. Реактос решает определённый круг задач, который с каждым годом становится всё менее актуальным. Как проницательные товарищи подмечали — подрастает поколение, для которого дефолтная ось это вообще не Windows, а Android…

P.S. Hurd почему-то никто не вспомнил, даже обидно как-то.

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

Над реактосью же довлеет проклятие винды.

Никакого проклятия. Там царит карго культ и токсичность (постоянное упоминание как они никому ничего не обязаны, ответы в грубой форме, избыточная бюрократия). Под карго культом я понимаю доскональное воспроизводство Windows там где в этом нет технической необходимости. Например вслед за Windows повторяют ошибку с графической подсистемой в ядре (win32k.sys). Это имело смысл только для совсем слабого железа, сейчас графика прекрасно работает в отдельном процессе пользователя. В том же Wine никаких модулей ядра не требуется. В Windows NT 3.x графика тоже была в процессе пользователя.

Haiku не воспроизводит все внутренние API и протоколы BeOS, например GUI сервер app_server в BeOS и Haiku несовместимы между собой и используют разные протоколы, но кроме системных библиотек этот протокол никто не использует так что несовместимость проблем не вызывает. В ReactOS же зачем-то пытаются воспроизвести все внутренние API и протоколы которые нигде кроме внутренних компонентов Windows не используются и на совместимость приложений с драйверами не влияют.

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

Тестовые сборки зачем-то настроены как релизные. Кому нужен BSOD в альфа версии нестабильной системы, из которого ничего понять невозможно? Очередное проявление карго культа. Надо сразу при kernel panic показывать на экране отладчик ядра с автоматическим выводом стека как это делает Haiku. Это позволяет сделать фото экрана и отправить разработчикам и не требует от пользователя навыков отладки ядра.

Иногда у меня возникает впечатление что если начать новый проект клона Windows с нуля другой командой разработчиков, то он будет готов раньше ReactOS. ReactOS оттягивает ресурсы и не даёт сделать нормальный клон. В этом смысле ReactOS даже выгоден Microsoft.

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

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

По железу, использовались три разные флешки (2Гб), и готовились на двух разных компьютерах (разных ОС). Целевой компьютер под это было с барахолки 2 ядра/4 гига/etc.

Возможно, Вы можете дать какой-то совет?

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

В том же Wine никаких модулей ядра не требуется

просадка по производительности ещё заметна В том же Wine

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

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

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

просадка по производительности ещё заметна В том же Wine

У меня Wine летает по сравнению с последней Windows 10, которая тот ещё тормоз. GDI рисуется быстрее в Wine.

Многие приложения и некоторые игры работают быстрее в Wine.

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

Может обсудим тему запуска установки этих систем с USB-накопителя? Что там надо для реактоси, чтобы «работала»?

Хайку у меня по «официальным» докам не запускается даже :(

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