OS Haiku вот прямо сейчас портируют на RISC-V

А реальное железо есть?

Уже было в ARM и RISC-V на десктопе. Если что интересно спрашивайте.

Есть бинарная сборка, можно попробовать запустить в эмуляторе. Используется немного пропатченный TinyEMU, в стандартной версии для Линукса нормально работать не будет (из важных изменений реализация CSR регистра utime (монотонный таймер в микросекундах) и увеличение размера очереди VirtIO до 32).

А реальное железо есть?

Скоро завезут.

Слушай, а можно сейчас Haiku поставить на M.2 SSD на реальное железо (UEFI, Ryzen 9)?

Haiku поставить на M.2 SSD на реальное железо (UEFI, Ryzen 9)?

Да, NVMe и UEFI работают. Только загрузчик UEFI надо руками копировать, установщик пока не научился.

Всякая дичь - уже есть.
реальное железо - на подходе: https://beagleboard.org/beaglev

Это очень хорошо, жаль только у Haiku сильная завязка на x86{_64} в плане инфраструктуры HPKG-пакетов.

Кстати, а пакеты или исполнительные файлы Haiku могут иметь код для разных архитектур CPU? Так, например, было в Classic Mac OS с FAT-версиями программ (Motorola 68000 + PowerPC) или в обычном NeXTSTEP/macOS которые используют Mach-O.

Я так понимаю такое можно замутить через какой-нибудь https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_binaries_for_Linux, но похоже он не оправдал ожидания.

Спецификация готова, но патчи в ядро Linux не приняли:

1. https://icculus.org/finger/icculus?date=2009-11-03&time=19-08-04
2. https://lwn.net/Articles/392862/

Далее, судя по реакции Ульриха Дреппера, патчи для glibc тоже не приняли бы.

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

Для Haiku аналогично, но мне интересна сама возможность и история. Было ли нечто подобное в том же BeOS, учитывая что он ориентировался на Classic Mac OS?

Кстати, в современном macOS (Mac OS X), например, FAT-версии программ на Mach-O что раньше, что сейчас действительно активно используются. Раньше они содержали код для PPC 32-bit, PPC 64-bit и x86, потом для x86 и x86_64, сейчас для arm64 и x86_64. Из-за закрытого кода ПО и постоянной смены архитектур в Apple использование FAT binary оправдано.

С другой стороны, в том же Windows с его PE, подобные FAT binaries не прижились и завезли лишь костыли: https://en.wikipedia.org/wiki/Fat_binary#Windows Я думаю это из-за монополии wintel на десктопах.

Насколько я помню, это не BeOS ориентировался на MacOS Classic, а это скорее Apple рассматривали возможность покупки BeOS, но в результате купили NextSTEP с Джобсом впридачу.

По поводу fat binaries на MacOS X — всё верно, ключом к востребованности формата является зоопарк аппаратных архитектур и закрытость кода прикладных программ.

Ровно по этой же причине в MacOS X, Solaris и Windows сохраняют бинарную совместимость, а в glibc (Linux) её ломали несколько раз.

Вот ещё интересная статья на тему: https://tenfourfox.blogspot.com/2020/06/the-super-duper-universal-binary.html.

P.S. А ещё есть проект Cosmopolitan.

Как интересно. 670 баксов – не на каждый карман, но сам факт того, что платы уже отгрузили, несомненно радует.

это не BeOS ориентировался на MacOS Classic, а это скорее Apple рассматривали возможность покупки BeOS, но в результате купили NextSTEP с Джобсом впридачу.

Это уже было после. Ранний BeOS ориентировался именно на «экосистему» и железо от Apple. Начиная с того, что выпускался сначала исключительно под PowerPC, а после и вовсе поставлялся с клонами Macintosh в дуалбуте с Classic Mac OS и заканчивая всякими схожими технологиями уже внутри самого BeOS, вроде аналога Resource fork:

Early versions of the BeOS implemented a database within the file system, which could be used in a manner analogous to a resource fork. Performance issues led to a change in later releases to a system of complex file system attributes. Under this system resources were handled in a fashion somewhat more analogous to the Mac

Или формата исполнительных файлов PEF, разработанного Apple:

BeOS on PowerPC systems also uses PEF, although x86 systems do not.

Даже раскладка и названия клавиш по умолчанию что в BeOS, что в Haiku до сих пор пересекаются с классическими Mac OS.

Это очень хорошо, жаль только у Haiku сильная завязка на x86{_64} в плане инфраструктуры HPKG-пакетов.

Сами пакеты к архитектуре не привязаны. В моём порте можно использовать пакеты для riscv64.

Кстати, а пакеты или исполнительные файлы Haiku могут иметь код для разных архитектур CPU?

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

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

Поддержку нескольких архитектур можно тоже добавить в мультипакет.

Поддержку нескольких архитектур можно тоже добавить в мультипакет.

Собственно, это путь Android. Когда структура APK-пакета примерно такая: https://exlmoto.ru/wp-content/Images/SPOUTDR/Ark.png

Да можно. Сейчас у меня Гайка стоит на NVMe SSD M.2 в платформе Hiper https://hiper-power.com/ru/catalog/kompyteri/barebony/nettop-platforma-hiper-ultion-b365-itx/

Там на маму еще ssd nvme и видеокарту нужно добавить… Рекомендую WD SN-750 посмотреть - у меня щас Haiku на нем стоит, с нее и пишу.

Haiku Inc. обещали подкинуть денег разработчикам для покупки мамок RISC-V

Полуофтоп: сайт https://discuss.haiku-os.org/ не работает в стареньком Firefox 40, скорее всего, в «немейнстримовых» браузерах тоже будут проблемы.

Понятно, что для сообщества Haiku это не ключевая проблема, но может, это можно поправить каким-либо не слишком сильным допилингом? Если сильным — то вопрос отпадает, у сообщества, разумеется, и так есть чем заняться.

https://discuss.haiku-os.org/

discuss

Забудь…

а на x86 (32 бита) там тоже действует ограничение по ram в 4гб?

нет. PAE поддерживается: https://imgur.com/a/87ajCu1

ага, понятно

Кстати в самой Haiku этот форум работает.

OS Haiku

Портировать это одно. А запилить дрова - совсем другое. Что там с этим делом?

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

Фларум должен работать.

Не очень работает - периодически пропадает текст (в WebPositive).

beos, подскажи пожалуйста, какой в Haiku нынче браузер лучшим считается? Лучше веб-позитива есть что?

Кстати в самой Haiku этот форум работает.

В WebPositive?

Используется готовый форумный движок

Какой, кстати?

https://www.discourse.org/

Есть два старых браузерных движка - оба на вебките.

HaikuWebKit для WebPositive

QtWebKit для кутешных Капзилла Оттер Дубль…

Порт QtWebEngine /Блинк - Хромиум/ в зачаточном состоянии.

Бага в свежей версии есть тикет в багтрекере - починят вскоре. В старом вебките баги нет, регрессия.

У меня сейчас одна из недавних ночных сборок, бага почти нет.

Есть два старых браузерных движка - оба на вебките.

Спасибо, понял. Про купзиллу помнил, но забыл название.

Есть два старых браузерных движка - оба на вебките.

В WebPositive используется довольно свежая версия WebKit часто синхронизируемая с upstream.

В QtWebKit более старая версия.

HaikuWebKit 1.8.1= WebKit 612.1.21