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)
Ответ на: комментарий от BceM_IIpuBeT

В первые слышу и крайне сомневаюсь с учётом того насколько РМС принципиальный. Будет он пилить под проприетарщину редакторы дануда =) Или может там что-то про свободный клон. В любом случае не знаю от слова совсем. Даже гуглить лень я супчик ем =)

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

То есть оно засирает озу своим кешем монтированного squashfs, затем файлами разжатыми из zstd, а только затем программа грузится?

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

Если честно - ни та, ни другая не нужна, даже не на Лоре, a вообще. Как игрушка, вещь несомненно полезная, дальше детсада, кто её применять то будет?

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

Ну и отлично.
Я на патреоне его денежкой спонсирую, таки Андреас теперь фулл-тайм разрабатывает систему.

Ждём следующих крупных вех: многоядерность и селф-хостинг)

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

Также сообщество там весьма токсичное

Из сообщества ReactOS я сталкивался лишь с евангелистами обитающими здесь и на Хабре, поэтому у меня нет твёрдого мнения о нём и той тусовке.

Однако в контексте обсуждения тусовок различных IT-сообществ стоит заметить, что когда я три года назад вдохновившесь работой проделанной @threedeyes по части портирования фрейморка Qt на Haiku через QPA, решил самостоятельно более углубленно ознакомиться с этой OS и портировать пару приложений и игрушек под неё, то был очень приятно удивлён сообществом разработчиков и пользователей Haiku.

Прямо нахлынули всякие тёплые воспоминания о форумах на IPB, vBulletin и каких-то Perl-движках из начала нулевых. Позитивное, дружелюбное, всегда готовое помочь и ответить на твои вопросы комьюнити. Без какого-либо налёта элитаризма или спеси. Без попыток кому-либо что-то доказать или навязать. Я уже и забыл, как это бывает.

Действительно отчётливо прослеживается контраст с тем, что происходит в Linux-сообществах. И нет, я сейчас не про ЛОР. Достаточно заглянуть на OpenNET, Phoronix или r/linux.

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

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

Оно и вправду потребляет больше памяти, чем если просто распаковать, но это ерунда по сравнению со всякими Гномами. На скриншоте занято 167 МБ памяти, большинство современных десктопных Линуксов потребляют на порядок больше.

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

Из сообщества ReactOS я сталкивался лишь с евангелистами обитающими здесь и на Хабре, поэтому у меня нет твёрдого мнения о нём и той тусовке.

Там один EmuandCo чего стоит. Токсичен и аватар, и подпись, и сообщения.

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

Всегда было интересно, что это за программисты такие, у которых нет $500 на железо.

Разве есть что-то плохое в том, что кому-то компенсировали покупку железа?

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

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

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

Кстати BFS Be File System, используемая в Haiku, имеет довольно интересные особенности по части похожести на БД.

Like its predecessor, OFS (Old Be File System, written by Benoit Schillings - formerly BFS),[4] it includes support for extended file attributes (metadata), with indexing and querying characteristics to provide functionality similar to that of a relational database.

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

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

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

Он сам по себе отличный мотиватор для других :)

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

оно началось ещё 25 лет назад

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

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

И вот в случае RISC-V это всё не тщательно огороженные корпоративные мечты, а своё, «народное». В Европе/Америке свои чипы выпекают студенты старших курсов как дипломные работы, так как у университетов есть партнерские программы с заводами. Не так, чтобы всё это вдруг стало доступно условному Васе с дивана, но тут не просто порог вхождения в кастомный дизайн железа постоянно снижается, а сама физика диктует направление движения в гетерогенность. Нужно много разных, проблемно-специфичных ядер. Потому корпорации и «демократизируют» это всё.

Так что тот факт, что Haiku-навты приходят на эту площадку — очень хорошо и для Haiku, и для площадки. Что же касается использования акселераторов в дизайне ОС, появятся акселераторы, появятся и дизайнеры)

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

Да, я в курсе. И, более того, идея будет дальше развиваться.

Тут проблема не в том, чтобы сделать «ФС похожей на БД», и даже не в том, что раньше железо для этого не подходило, да и сейчас не очень еще (нужны NVRAM для кэширования SSD). А в том, что данными нужно управлять, и это не тривиальная задача.

У данных постоянно «плывет» схема, и пока что разработчики ОС изящно сбрасывают все эти проблемы на разработчиков приложений, предоставляя им в лучшем случае плохо синхронизированные BLOB-ы. А так проблемы управления данными лягут на них, а они к этому совершенно не готовы.

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

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

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

В контексте этих рассуждений непонятен твой оптимистичный настрой на тему того, что эти идеи получат дальнейшее развитие. Считаешь, что независимые разработчики смогут между собой договориться? По Linux’у это как-то не особо заметно.

И кстати при подходе «File System like Data Base» ещё ведь всплывают чудовищные проблемы сожительства с остальными уже существующими экосистемами, которые не разделяют подобные подходы. Миграция «файлов» или «объектов» из одного в другое будет чертвоски усложнена, а сами компании-основатели экосистем будут цепляться за собственные несовместимые реализации до последнего.

За примерами ходить далеко не надо – Classic Mac OS и технология в древнем HFS называемая Resource Fork.

The rigid nature of traditional programming bothered me. The idea of an application frozen in code, with no way to change anything dynamically, was anathema to my ideals. I wanted to be able to change as much as possible at runtime. Of course, the application code itself couldn’t be changed, but what could be changed without having to recompile the code? (c) Bruce Horn

The solution was that files on the original Macintosh had a “data fork” and a “resource fork”, something that made it incredibly easy to store things like icons, translations etc. along with binary files.

Идея вроде как интересная, здравая и разумная. Но во что это вылилось на практике? В то, что когда пользователь Mac OS пытался залить куда-нибудь или перенести на какую-нибудь другую ФС (вроде тех, что использовались в Windows или MS-DOS) свои файлы из-за потери resource forks он получал неработающую тыкву с куском безвозвратно потерянной инфы. В итоге эта неплохая идея стоила пользвателю больших потерь по удобству, из-за которых пользователи должны были добывать и даже покупать специальное стороннее ПО (созданное даже не Apple) и хранить файлы, предназначенные для переноса в сложных архивах специальных форматов, дабы вся нужная информация для работы программы сохранялась.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 3)

x86 и windows всё!111

anonymous
()

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

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

было

ты не очень умён, видимо

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

реактось исключение, на лоре обычно форсят всякое маргинальное говно как какое-то «будущее»

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

там графика полностью на процессоре. так что нет

У тебя в GTK+3 и Qt 5 графика тоже «на процессоре».

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

gtk3 например небыстро ворочается на дерьмовом процессоре или в венде

blender в хайку тормозит - в линуксе нет

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

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

Образно говоря, если бы я хотел внедрить что-то этакое в России, то надо было бы сначала внедрить в Америке, а русские потом и сами к себе утащат. Если бы я хотел внедрить что-то в Америке, то я бы пошел в Google и оттуда бы продвигал.

И тут надо разделять проблемы технического характера (софт и железо) и характера социально-экономического (улыбаемся и машем). Корпорации легко могут построить народ улыбаться и махать, но вот инновации им даются довольно таки тяжело. Тут нужны стартапы или просто независимые разработчики. Нужно придумывать пототипы и выходить с ними. Применительно к конкретно этой задаче, FUSE сейчас есть под Windows. И можно, например, базу данных экспортировать как файловую систему для неадаптированных приложений, и это будет кроссплатформенным.

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

Что же касается линуксовых разработчиков, то VFS чисто технически не получится дотянуть до БД, так как хотя бы просто семантика конкуррентности у БД совсем другая. В Linux даже просто блокировки файлов толком нельзя сделать. Расширять существующий IO-стек не имеет смысла, IMHO. Поэтому и интересны такие проекты, как Haiku.

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

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

blender - реальное приложение, Haiku GUI - маргинальное ненужно

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

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

Чтобы было понятнее.

БД = хранилище + система типов. Это достаточно широкое определение, и по нему ФС базой данных считаться не будет из-за отсутствия системы типов. Точно по этой же причине же K/V store называется хранилищем, а не базой данных. Хотя в названии может иметь DB на конце.

Если же говорить в более узком, современном, смысле, то БД характерны тем, что «вычисления идут к данным», тогда как объектные хранилища и файловые системы работают в противоположной модели: «данные идут к вычислениям».

Т.е., очень образно говоря, структурированная файловая система, если хочет стать именно БД, должна уметь выполнять запросы внутри себя. В пределе, если есть smart storage (например, SSD может исполнять внешние программы внутри контроллера), то уметь делать pushdown туда. С точки зрения обычного линукс-разработчика это будет звучать как «запихнуть MySQL прямо в ядро, затащив туда же за одно С++». Потому что ФС в ядре живут.

Как бы это всё могло выглядеть? В Linux можно блочные устройства эффективно пробрасывать в юзерспейс через io_uring. Пусть будет «системная база данных», доступная для новых приложений по сокету, а для старых — через FUSE. Там же event bus протянуть для реактивности, и через него к данным и ходить. Туда же и акселераторы будет хорошо встраивать, чтобы запросы к данным ускорять и специальные типы данных поддерживать.

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

ожидаю виртуозное маняврирование на лоре на тему что лучше - халосый riscv от плахова intel, или плахой x86 от халосей amd xD

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

Это всё ещё менее жруче чем современный gtk или qt.

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

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

В первую очередь ради API и ABI(gcc 2.95 не просто так тянут). При этом принципы по которым строится Haiku, мне нравятся сильно больше чем те по которым строятся GNU/linux-based дистрибутивы.

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

Быструю - в смысле на быстрой памяти и высокой частоте чипа, которая по максимуму использует шину PCI-E

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

Можно только ванговать… самый вероятный вариант - в настройках виртуалки вместо pcnet нужно выставить intel1000pro

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

Да, я переустановлю Haiku начисто когда выйдет Beta 3. Спасибо. В настройках VirtualBox действительно стояло pcnet. Выставил intel1000pro

Я обновился с pkgman update (там был Webpositive с 1.7.1 до 1.8.0) и теперь у меня вообще перестало запускаться. Хотя Otter ещё работает…

https://imgur.com/a/fkAPWgj

Кстати, а есть какой-нибудь pgkman update --force, чтобы заставить вообще всё перекачать, если когда-то до этого была какая-то неудача при обновлении, если это только у меня такая проблема…

Или хотя бы заставить перекачать так:

pkgman uninstall webpositive_x86
pkgman install webpositive_x86

А то пишет

Reusing download from previous state

И не качает заного webpositive :(

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

«по максимуму использует шину PCI-E» это уже провал, она в тыщу раз медленнее видеокарты. данные один раз при старте заливают в память видеокарты и затем работают с ними на ней, только изредка отправляя команды с процессора, минимально используя pci-e

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

Reusing download from previous state

Удалить /boot/system/packages/administrative/state_*.

Ещё возможно это поможет.

WebPositive пока ещё не обновили, надо ждать следующий релиз-кандидат.

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

Вангую, что у Вас бета2 ??

Это уже не работает, так как репу мастер /ночные билды перевели на бета3/, и добавили репу бета3

Рецепт /инетсоединение обязательно!/ Предварительно очистим административную папку полностью от всего ненужного хлама - /boot/system/packages/administrative

  1. добавить в настройках репозиторий бета3 /в урле циферку изменить/

2 отключить в настройках репозиторий бета2

3 включить в настройках репозиторий бета3

В Терминале pkgman full и ребут…

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

Да, современные игори не пойдут. На средних настройках на встройке UHD630 i5-8400 можно поиграться в StarWars Jedi Knight 2 или Return to Castle Wolfenstein - они есть в репозиториях пакетов.

beos ★★★
()
Последнее исправление: beos (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.