LINUX.ORG.RU

Вышла четвертая бета-версия ОС Haiku

 , , ,


3

5

Тихо и незаметно…

После полутора лет разработки опубликован четвёртый бета-выпуск операционной системы Haiku R1. Изначально проект был создан как реакция на закрытие ОС BeOS и развивался под именем OpenBeOS, но был переименован в 2004 году из-за претензий, связанных с использованием в названии торговой марки BeOS.

Для оценки работы нового выпуска подготовлено несколько загрузочных Live-образов (x86, x86-64). Исходные тексты большей части ОС Haiku распространяются под свободной лицензией MIT, исключение составляют некоторые библиотеки, медиа-кодеки и компоненты, заимствованные из других проектов.

ОС Haiku ориентирована на персональные компьютеры, использует собственное ядро, построенное на основе модульной архитектуры, оптимизированное для высокой отзывчивости на действия пользователя и эффективного выполнения многопоточных приложений. Для разработчиков представлен объектно-ориентированный API. Система напрямую базируется на технологиях BeOS 5 и нацелена на бинарную совместимость с приложениями для данной ОС. Минимальное требование к оборудованию: CPU Pentium II и 384 МБ ОЗУ (рекомендовано Intel Core i3 и 2 ГБ ОЗУ).

В качестве файловой системы используется OpenBFS, поддерживающая расширенные атрибуты файлов, журналирование, 64-разрядные указатели, поддержку хранения мета-тэгов (для каждого файла можно сохранить атрибуты в форме ключ=значение, что делает ФС похожей на БД) и специальных индексов для ускорения выборки по ним. Для организации структуры директорий используются «B+ tree» деревья. Из кода BeOS в состав Haiku включён файловый менеджер Tracker и панель Deskbar, исходные тексты которых были открыты после ухода BeOS со сцены.

Основные новшества:

  • Улучшена работа на экранах с высокой плотностью пикселей (HiDPI). Реализовано корректное масштабирование интерфейса, не ограничивающееся изменением размера шрифтов. При первой загрузке Haiku теперь пытается автоматически определить наличие HiDPI-экрана и выбрать необходимые размеры для масштабирования. Выбранные параметры могут быть изменены в настройках, но для их применения пока требуется перезагрузка. Параметры масштабирования поддерживаются в большинстве родных приложений и в некоторых портированнных, но не во всех. Примеры: Стандартное DPI и HiDPI (200%).

  • Предоставлена возможность использования внешнего вида с плоским декоратором окон и плоским оформлением кнопок, вместо оформления с активным использованием градиентов. Плоское оформление поставляется в пакте Haiku Extras и включается в разделе настроек внешнего вида. Примеры: Light Theme и Dark Theme.

  • Добавлена прослойка для обеспечения совместимости с библиотекой Xlib, позволяющая запускать X11-приложения в Haiku без запуска X-сервера. Прослойка реализована через эмуляцию функций Xlib при помощи трансляции вызовов в высокоуровневый графический API Haiku.

  • Подготовлена прослойка для обеспечения совместимости с Wayland, позволяющая запускать тулкиты и приложения, использующие данный протокол, в том числе приложения на базе библиотеки GTK. Прослойка предоставляет библиотеку libwayland-client.so, основанную на коде libwayland и совместимую на уровне API и ABI, что позволяет запускать приложения Wayland без изменений. В отличие от типовых композитных серверов Wayland, прослойка не запускается в форме отдельного серверного процесса, а загружается как плагин к клиентским процессам. Вместо сокетов в сервере используется нативный цикл обработки сообщений на основе BLooper.

  • Благодаря прослойкам для совместимости с X11 и Wayland удалось подготовить рабочий порт библиотеки GTK3. Из приложений, которые можно запустить при помощи порта отмечены GIMP, Inkscape, Epiphany (GNOME Web), Claws-mail, AbiWord и HandBrake. Пример: GTK приложения.

  • Добавлен рабочий порт с Wine, который можно использовать для запуска Windows-приложений в Haiku. Из ограничений отмечается возможность запуска только в 64-разрядных сборках Haiku и способность выполнения только 64-разрядных приложений Windows. Пример: Wine в Haiku.

  • Добавлен порт текстового редактора GNU Emacs, работающий в графическом режиме. Пакеты размещены в репозитории HaikuDepot. Пример: Gnu Emacs в Haiku.

  • В файловый менеджер Tracker добавлена поддержка генерации и показа миниатюр изображений. Миниатюры сохраняются в расширенных атрибутах файлов. Пример: Миниатюры в Tracker.

  • Реализован слой для совместимости с драйверами FreeBSD. Из FreeBSD портированы драйверы для поддержки беспроводных USB-адаптеров с чипами Realtek (RTL) и Ralink (RA). Из ограничений отмечается необходимость подключения устройства до загрузки (после загрузки устройство не определяется).

  • Из OpenBSD портирован беспроводной стек 802.11 с поддержкой 802.11ac и драйверы iwm и iwx с поддержкой беспроводных адаптеров Intel «Dual Band» и «AX».

  • Добавлен драйвер USB-RNDIS, позволяющий организовать работу точки доступа через USB (USB tethering) для использования в качестве виртуальной сетевой карты.

  • Добавлен новый драйвер NTFS, основанный на библиотеке от проекта NTFS-3G. Новая реализация более стабильна, поддерживает интеграцию со слоем для кэширования файлов и обеспечивает хорошую производительность.

  • Добавлен транслятор для чтения и записи изображений в формате AVIF.

  • Браузерный движок HaikuWebKit синхронизирован с актуальной версией WebKit и переведён на сетевой бэкенд на базе библиотеки cURL.

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

  • Улучшена совместимость со стандартами POSIX. Продолжена замена вызовов стандартной Си-библиотеки, ранее перенесённых из glibc, на варианты из musl. Добавлена поддержка потоков C11 и методов locale_t.

  • Улучшен драйвер для накопителей NVMe, добавлена поддержка операции TRIM для информирования накопителя об освобождённых блоках.

  • Обеспечена возможность сборки ядра и драйверов новыми версиями GCC (включая GCC 11), для сборки системы из-за привязок к старому коду для совместимости с BeOS по-прежнему требуется GCC 2.95.

  • Проведена общая работа по повышению стабильности всей системы.

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

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



Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 4)

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

Осторожнее. Ты вступаешь на скользкий путь. Даже очень объективные люди имеют границы своей объективности и по чувствительным местам она может быть очень избирательной. Подозреваю что у X512 она проходит где-то здесь ))

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

Подозреваю что у X512 она проходит где-то здесь ))

Я сказал что-то не то и на самом деле Windows портит содержимое не распакованных ZIP архивов чтоли?

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

Не представляю как люди на ЭТОМ работали

Win 2.x — плоскота и примитивизм, выглядит современно!
Win 3.x — выглядит отлично, это уже почти классика
CDE — страшненько но вполне юзабельно, всяко лучше адвайты и т.п. тем от дизайнеров-аутистов

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

А Toolbox уже не нужен. На X есть свои заменители для него - Carbon кажется или Cocoa - гуглить лень, но помню что один из них вроде как переходным был, как раз эмулируя Toolbox, а новые программы уже для второго писались. В базе при этом выглядели они одинаково. Это и есть эволюция, причем достаточно бескровная.

Пользы-то от xaw нет, поэтому нужность его нулевая, только тянут для абстрактной совместимости, как и многие другие куски Х11. Поэтому народ и шарахается от проекта, ибо кому интересно разбираться с фонтсервером или сервером печати, если ты знаешь что никто и никогда в здравом уме этим последние лет 20 не пользовался и в будущем тоже не будет. (Это я сейчас не в пользу Wayland, если что, просто мысли вслух куда-то потекли не в ту сторону)

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

Только вот с точки зрения дизайна API курит в сторонке как раз MacOS Toolbox.

Не, именно с точки зрения функциональности Toolbox был куда более продвинутым API, в т. ч. и в графическом плане позволял делать куда более высокоуровневые вещи. Первые версии Adobe Photoshop использовали как раз Macintosh Toolbox. Настолько плотно использовали, что даже в каком-нибудь Photoshop CS2 на Windows можно обнаружить его куски. То есть Adobe взял и перенёс какую-то часть Macintosh Toolbox на WinAPI дабы более быстро портировать своё ПО.

Athena Widgets можно нативно запустить и на современной ОС и железе, а с MacOS Toolbox с этим проблемы. Оно ещё в Mac OS X чере эмулятор работало.

Поддержка Macintosh Toolbox практически полностью была реализована в Carbon API, который с концами выбросили по современным меркам совсем недавно, в macOS 10.15 Catalina. А так его тянули 30+ лет считай, прямо как иксовую Athena. Вот только на Toolbox и Carbon была куча приложений к которым имеется некоторый интерес до сих пор, и Toolbox постепенно развивался и не застрял на однобитности, а Athena Widgets… ну сам знаешь.

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

Ну, раз уж я сам ступил на этот путь, то придется объясниться ))

Нет, конечно ты это не сказал, однако на вопрос о судьбе этих атрибутов в другой ОС предложил архивы с такими файлами просто не распаковывать и вообще считать их, условно, новыми типами файлов. Похвально и по форме верно. А по существу - издевательство. Вот файл, можешь посмотреть на него… пока он зазипован. А пользоваться не вздумай! (Хотя последнее конечно тоже неверно, если у какого-то файла иконка пропадет или станет дефолтной, то содержимое-то не пострадает. Но если в атрибутах был какой-нибудь телефонный номер, тогда конечно про него придется забыть)

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

Поддержка Macintosh Toolbox практически полностью была реализована в Carbon API

Carbon хоть и создавался по мотивам Toolbox, но это другой API и на него надо портировать (Carbonize). Athena же досконально совместима.

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

А по существу - издевательство.

Я не понимаю что вы пытаетесь доказать. Если вам нужно перенести данные визитных карточек на другую систему, то их можно сконвертировать в какой-нибудь распространённый формат, например vCard. Если у вас есть ZIP с визитными карточками BeOS/Haiku но нет этих систем, то вы можете сделать импорт данных контактов из ZIP не распаковывая.

Аттрибуты в Haiku можно индексировать и тогда они будут искаться за доли секунд и быть постоянно в консистентном состоянии без вряких фоновых процессов наргужающих диск и процессор. Почему не пользоваться преимуществами системы когда они есть?

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

Эээ... И тут ты «изобрёл» файл без атрибутов и являющийся по сути контейнером. Какой смысл тогда держаться за атрибуты вообще? Держать распакованый файл и тут же запакованый? Ведь без запаковки их безопасно не перенести.

Если мы теряем линуксовые, или виндовсовые атрибуты -, это тьфу, фигня. А если теряем номер Дяди Васи из Гайки, то это реальная проблема. И держать файл в распакованом виде в Гайке и держать его запакованный вариант для передачи... Тут занятое место и рассинхрон и все ужасы. И при этом всём не дай бог распаковать на негайке... Ужос.

Тут нужен конкретный спец.

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

Carbon хоть и создавался по мотивам Toolbox, но это другой API и на него надо портировать (Carbonize).

Это не так. Вот, например, тривиальный код использующий Macintosh Toolbox, который будет собираться и работать начиная с Mac OS System 1.0 и заканчивая macOS 10.13 High Sierra:

Да, некоторые изменения кода потребуются как и вымазывание #ifdef’ами в некоторых местах, но это никак нельзя назвать другим API. В Carbon API полноценно реализован Macintosh Toolbox и потому «карбонизировать» классические приложения было довольно просто, чем собственно и пользовались некоторые ленивые разработчики по типу Adobe, из-за чего Apple приходилось тянуть этот Carbon чуть ли не вечность.

Athena же досконально совместима.

Вот только вся экосистема вокруг неё – нет.

Другими словами возьмёшь ты Athena’овский код тех дремучих лет, попытаешься собрать на современном Linux, что получишь? Ошибки конфигурирования, если там идиотские autotools’ы, по типу тех что нужны autocrap-генераторы определённых древних версий и прочее подобное. Но допустим тебе повезло и там обычный Makefile. Тогда тут уже полезут ошибки компиляции начиная с устаревшего стиля K&R в котором прототипы функций объявлялись по другим правилам и заканчивая всякими там -fcommon. Как ни крути, а некоторую «карбонизацию» тебе всё-равно нужно будет проводить, аналогичную той что существовала в мире классических Mac OS.

Допустим ты раздобыл древний бинарь использующий Athena Widgets. Запустишь ты его в современном Linux, учитывая что тогда были в ходу всякие a.out и даже COFF, а SO-name древних либ могут и не совпадать с существующими? А если запустишь, то будет ли оно нормально работать? Сильно сомневаюсь в этом.

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

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

Какой смысл тогда держаться за атрибуты вообще?

Повторяю: чтобы можно было мгновенно искать по атрибутам в Haiku. По содержимому файлов искать долго. А фоновые сервисы индексирования очень ресурсозатратны и не обеспечивают консистентность индекса (файл поменялся, а ипдекс всё ещё старый и т.п.).

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

Тут нужен конкретный спец.

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

Аналогично тому как это было сделано в KDE. Ведь тебе не нужно разворачивать MySQL-базу на Windows, чтобы перенести контакты из KDE PIM в какой-нибудь MS Outlook.

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

Это я понимаю. И если бы это стало стандартом везде - я был бы просто счастлив (наверное). Но в реальном мире эти файлы будут жить нормальной жизнь тольков Гайке. И это проблема. Да, хорошо бы, хоть бы, линукс приобрёл такие атрибуты. Мне бы уже хватило. Но ты даже в письме не перешлёшь человеку файл. Он его не прочитает нормально и дальше передаст уже испорченный (без атрибутов)

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

Так и MS в своё время пытались в WinFS такое сделать, чтобы ФС была этаким индексом по содержимому.

Не полетело, к сожалению.

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

И если бы это стало стандартом везде - я был бы просто счастлив (наверное).

Систем наверное существует больше одной штуки именно потому что они разные. По такой логике надо винить GIMP что он не использует формат Photoshop и т.д.. Это абсурдно. Системы разные и форматы разные. Для передачи данных между разными системами придумали импорт/экспорт.

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

В чём проблемя сконвертировать файл например в vCard перед передачей если известно что получатель не использует Haiku?

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

Не, тут крепко думать нужно. Всё не то.

Да, автоимпорт/экспорт при переносе н во вне и извне. Но как? В каком виде, чтобы не потерялось?

И сторонние приложения, типа кутешных, гткшных, умеют использовать эти атрибуты? Допустим, портируем кдешный Kontact, он же всё равно будет требовать Аконадю и плевать хотел на атрибуты. А если прикрутить атрибуты вместо Аконади, то это останется Гайка онли фича. Очень жаль. Очень очень жаль.

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

Так я понял аьрибуты у вас практически произвольные, нет? Если же проблема только в контактных данных, то всё проще, конечно.

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

Набор используемых аттрибутов зависит от типа файла (тип файла – тоже аттрибут). Так что при желании не составляет проблем написать конвертер.

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

В чём проблемя сконвертировать файл например в vCard перед передачей если известно что получатель не использует Haiku?

Только в том, что это лишнее телодвижение, о котором надо вспомнить.

Визитные карточки, в том виде в котором они были сделаны во времена оные, по нынешним временам таки атавизм по большому счёту. Разве что делать синк между локальным и гугло/эпло-хранилищем контактов для телефона.

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

И сторонние приложения, типа кутешных, гткшных, умеют использовать эти атрибуты? Допустим, портируем кдешный Kontact, он же всё равно будет требовать Аконадю и плевать хотел на атрибуты. А если прикрутить атрибуты вместо Аконади, то это останется Гайка онли фича. Очень жаль. Очень очень жаль

Haiku, GNOME, KDE, Windows, macOS – всё это системы и самодостаточные окружения с наборами прикладных приложений, в которых базовая функциональность по типу хранения контактов реализована по разному. Вот в Haiku это сделано на уровне расширенных аттрибутов ФС. В KDE за каким-то хреном решили притянуть целый MySQL-сервер, который по сути для 99% пользователей бесполезен и даже вреден. В GNOME и macOS наверное используют БД в файле по типу SQLite, в Windows – собственные костыли. Всё это лишь вопрос реализации, только и всего.

Плюсом подхода Haiku является прозрачное копирование файлов с расширенными аттрибутами (контактов, e-mail писем) внутри самой системы, только и всего. Для внешнего мира нужно использовать импорты в удобоваримые форматы. Ещё раз повторюсь, чтобы импортировать базу писем из KMail в MS Outlook тебе не нужно разворачивать MySQL на винде.

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

Мне очень win 3.11/win nt 3* нравятся, даже сейчас смотрятся просто шикарно, имхо.

Что-то мне вспомнились эти древние ссылки, где какие-то германцы кастомизировали Windows 3.11:

На ЛОРе вроде как мелькали.

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

AWT сделано напрямую через нативное Haiku API.

А heavyweight компоненты поддерживаются?
И есть ли vlc?
Если да/да то есть шанс что заработает vlcj с аппаратной отрисовкой в видео слое?

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

А тяжеловесные компоненты

Какие из? Я лично запускал IDEA на Haiku, оно работало. Достаточно тяжеловесно? Свои скриншоты правда найти не могу, но вот кто-то снял:

Дефолтные GUI-тулкиты в Java, а речь идёт про AWT и Swing, к счастью не используют никакие иксовые или GTK+’шные кишки. Поэтому всё что базируется на них выше – типа фреймворка который использует IDEA или такое вот что использует NetBeans – https://github.com/JFormDesigner/FlatLaf всё это максимально кросс-платформенно и переносимо. В т. ч. и на Haiku.

Проблемы по очевидным причинам будут с SWT-based приложениями по типу Eclipse.

И есть ли vlc?

https://depot.haiku-os.org/#!/pkg/vlc/haikuports/haikuports_x86_64/3/0/17.3/-/1/x86_64?bcguid=bc2-LJCC

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

А heavyweight компоненты поддерживаются?

Вроде да, но подробно не смотрел.

И есть ли vlc?

Да ещё со времён BeOS.

Если да/да то есть шанс что заработает vlcj с аппаратной отрисовкой в видео слое?

Аппаратные видео слои поддерживаются на довольно узком наборе железа и в VLC вроде не поддерживаются, но поддерживаются в нативном MediaPlayer.

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

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

Я то же самое про Windows Phone слышал. Типа, если появится инстаграм и игори - взлетит. Программировать просто, C#, плюс, ядро от винды. Не взлетел.

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

Вот это оформление заголовка окон в CDE/Motif?

http://toastytech.com/guis/solcdeapps.png

Оно, кстати было слизано с Microsoft Win 2.x – Win 3.x:

http://toastytech.com/guis/win203.html

Не трррожжь Win 2.x – Win 3.x, там святая плоскота! Под которую пытается закосить дисяточка-11 винда, но, не канон!

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

Я понимаю. Но получается, что приложения на кутях/гтк в самой гайке уже не могут, не умеют использовать эти атрибуты. Доя них это полный ноль. Так? Мир атрибутоисполбзования ещё сократился.

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

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

А Haiku и не опирается на приложения на Qt и GTK+, у неё там собственный весьма неплохой графический тулкит и собственный набор приложений на нём. Следует отличать приложения стандартной поставки системы и порты. А то так можно договориться до того, что если Rhythmbox из GNOME не использует MySQL базу Amarok, то мир использования жирных баз сократился.

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

Я не понимаю что вы пытаетесь доказать.

Только то, что взаимодействие с внешним миром будет наполнено болью. Пока Гайкой пользуются только энтузиасты, понимающие с какой стороны у клавиатуры вход, а с какой - выход, вообще проблем нет. Как только, допустим, попрет и на неё сядет типовой домашний пользователь, так сразу боль и начнется. Я просто проходил уже это, как и все пользователи старых маков. Ладно бы сам страдал - мне как раз было пофиг, для простых случаев и конвертер могу написать побыстрому, но когда я стал админить несколько тысяч маков (не один конечно же), то ад заиграл новыми красками.

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

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

Да, хорошо бы, хоть бы, линукс приобрёл такие атрибуты. Мне бы уже хватило

man xattr

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

По лоровским меркам тут собрались какие-то задроты, подбирающие аргументы и что-то даказывающие. Нет, господа, так у нас качественного срача не выйдет…

BydymTydym
()

Не, гайка не кошерно. Нулевая ниша, никаких преимуществ перед имеющимися решениями и всратые архитектурные решения.

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

Какие из?

Дефолтные GUI-тулкиты в Java, а речь идёт про AWT и Swing, к счастью не используют никакие иксовые или GTK+’шные кишки

«Тяжеловесные» это как раз все awt и пара из swing (типа jframe) которые как раз используют системные кишки для отрисовки себя.
«Легковесные» это те которые рисуются чисто программно (у свинга это почти все)

Vlcj (байндинги для libvlc) позволяет работать в трёх режимах:

  • натянуть аппаратный видеослой на «тяжеловесный» компонент без доп затрат - по сути то что может отрисовать libvlc на системном видео слое просто прибивается по х/у/ш/в к «тяжику» которого рисует «системная кишка» (вообще под линухом свинг вроде не прибит к гтк, но я особо не лазял, меня гтк устраивает)
  • взять из буфера libvlc итоговый кадр и нарисовать его на любом (по сути «легковесном» ибо на «тяжеловесном» рисовать проблемней) компоненте - это самое технически простое но самое медленное ибо надо целиком перекрашивать всю область вывода программно с темпом видео - для 30к/с соотв 30 раз в секунду
  • третий вариант аналогичен второму но вывод идёт через аппаратно ускоренный буфер - т.е. «легковесный» компонент рисуется на гпу. По скорости почти как вариант 1 и при этом гораздо гибче (можно изменять размер в мЕньшую сторону без проблем, вмешиваться в отрисовку) и стабильней (нет нужды следить чтоб видео слой не упал если вдруг он стал невидимым или произошёл какой-то рассинхрон) НО работает это только с Явой FX притом относительно свежих версий ибо работу с аппаратно ускоренными буферами туда вкинули недавно

Вообщем это довольно заковыристый костыль, надо будет глянуть вдруг заработает и тут :-)
А в кему лучше загонять 32 или 64 битную версию (хост арм64 так что один фиг эмулировать)?

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

вспоминается реактос, в который кажется даже бабки вливать пытались, толку-то

ReactOS пилить намного сложнее ведь. Столько всего надо делать, да ещё и гнаться за новым функционалом из современных версий винды хотя бы просто ради совместимости нужного софта и дров.

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

Я согласен. Но нахрена это корпорациям? Они теперь главная сила в линуксе, а не «сообщество» неспособное ни о чем договориться.

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

У ReactOS и Haiku разные подходы к совместимости. ReactOS пытается сделать доскональный клон Windows с воспроизведением внутренних часто недокументированных интерфейсов. А Haiku обеспечивает совместимость только публичных интерфейсов, а внутренние интерфейсы отличаются и несовместимы с BeOS.

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

Нет. Как я понял, на гайковских туллкитах уже практически не пишут нового. Только портируют. И портки эти, одноразовые, не используют Гайку никак. Я про это. Сфера где применяются атрибуты и так мала, а ещё в будущем, того и гляди, сократится.

Но это я так, ною

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

Уж лучше бы отправку сигналов по этим Ctrl+Shift+C замутили, а Ctrl+C не трогали.

Лучше бы на ibm pc была кнопка command в дополнение к control и alt.

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

PC — это неинтересный, на грани рентабельности, не будоражащий воображение молодых технарей рынок. Это, конечно же, не означает, что PC исчезнут — не исчезли же шариковые ручки после возникновения электронных устройств.

Молодые технари разные бывают. Поделенные рынки - неплохой старт карьеры, а если в компании понравится - отличная кормушка до старости.

А шариковые ручки - зло. Идеальная ручка:

  • имеет стальное перо;
  • имеет легкий корпус из пластика или тонкого металла;
  • позволяет использовать стандартные картриджи и картриджи двойной емкости;
  • поставляется с перезаправляемым поршневым флаконом, которым можно заменить одноразовые картриджи.

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

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

Да, хорошо бы, хоть бы, линукс приобрёл такие атрибуты.

В Doplhin-e есть метки, которые суть user xattr, и baloo умеет их индексировать, и в итоге искать по ним в кедах можно.

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

А шариковые ручки - зло. Идеальная ручка:

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

Чувствуется линукс-вей и выбор железа под ось. 🤡

А идеальная ручка - это механический карандаш. Японцы не дадут соврать. Ну или божественный трёхкопеечный BIC.

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

Поделенные рынки - неплохой старт карьеры

Чтобы что?

А шариковые ручки - зло. Идеальная ручка: имеет стальное перо...

Много Вы видите вокруг себя людей, мечтающих перевернуть мир новой моделью ручки, хоть шариковой, хоть перьевой?

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

Много Вы видите вокруг себя людей, мечтающих перевернуть мир новой моделью ручки, хоть шариковой, хоть перьевой?

Сильно недооцениваете покупательскую способность хипстеров 8-)

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

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