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)

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

Тип демонстрационной доски: Рука

ААААА!!!

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

В Mac OS 1-9 подобные штуки назывались Resource fork и в них рядом с файлом хранились ресурсы и даже скомпилированный код.

Очень вредное свойство. Не, вроде как бы удобненько, но до тех пор пока не захочется grep использовать и прочие средства привычной автоматизации. Если что - https://stackoverflow.com/questions/55623324/what-does-creating-a-file-as-file-extfile-ext-really-do

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

А как это получилось, если Mac OS 9 вышла в октябре 1999, а BeOS Developer Release в январе 1996 уже выглядела плюс-минус как все последующие версии? MacOS 8 почти неотличима от 9, но и она вышла в июле 1997.

Еще для MacOS 7.5 было такое расширеньице под названием Aaron, которое делало классический интерфейс похожим на вид 8/9 Сам я его использовал году этак в 97 и уже тогда оно было не новым. Сейчас погуглил чуток:

Aaron 1.5.1 (September 9, 1996) by Greg Landweber and Edward Voas (c) 1996 Greg Landweber and Amargosa Software, Inc.

Т.е., в 96 уже была версия 1.5.1, значит было и раньше что посмотреть.

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

Не, фон терминала я предпочитал делать темно-серым, да и шрифтом Terminus указывать. А еще, файловым менеджером не надо пользоваться - он чудовищен. Есть же терминал, для администрирования этого вполне достаточно.

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

до тех пор пока не захочется grep использовать и прочие средства привычной автоматизации

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

Так-то не макосью единой, ЕМНИП, несколько потоков в одном файле были ещё и в полуосёвой HPFS, и даже в похожей на неё виндовой NTFS (только в винде этим мало кто пользовался, как и симлинками, которые в NTFS, внезапно, тоже есть — стандартными средствами эти фичи не поддерживались).

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

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

Кто-то да пользуется (возможно даже сама Винда) - согласно оправданиям майкрософта, это и тормозит внедрение ReFS как дефолтной.

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

В Mac OS X в свое время этот вопрос решили интересно. Там теперь в консоли (да и в GUI) все эти ресурсные дела файла выглядят примерно так, будто это не файл, а директория с набором файлов. Так что МС при желании сделать любого вида эмуляцию своих потоков. Темнят.

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

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

По-моему, это утверждение верно для любого «родного» файлового менеджера в любой операционной системе или DE. Не знаю, что там было в CDE, но ткнуть любую линуксовую оболочку, везде встроенные ФМы слизаны с виндового проводника (ну или маковского файндера). Главная идея которых состоит в нулевом пороге вхождения для впервые севшего за компьютер человека. Для тех, кто эффективно работал хотя бы с двухпанельниками, всерьёз пользоваться этим невыносимо.

Двухпанельники тоже, кстати, не идеал эргономики. Было бы интересно увидеть многооконный ФМ с продвинутым тайлингом. Или наоборот, однопанельный ФМ, хорошо интегрирующийся в какой-нибудь тайловый WM, чтобы иметь на экране несколько файловых окон, одно из которых можно было бы быстро хоткеем назначить «источником», другой «приёмником», и потом надо полученной парой, тоже хоткеями, проводить привычные «двухпанельные» операции: копирование, перенос, сравнение (включая рекурсивное, пример — плагин «Расширенное сравнение» для Far Manager), синхронизация.

Но нет, вместо развития годных идей имеем редукционизм к проводникоубожеству.

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

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

Неудобненько на самом деле. Там где этим широко пользовались, читай в той же классической Mac OS, из-за подобных фишек были проблемы с переносом файлов и приложений через тот же Интернет. Их требовалось заворачивать либо в архивы по типу *.sit, либо в образы дискет, чтобы всё корректно переносилось.

Где-то читал что программисты Mac OS решили активно использовать все эти Resource fork’и для приложений, чтобы у пользователей была возможность редактировать UI, формочки и строки, но на деле это вообще мало кто делал.

В BeOS/Haiku использование расширенных аттрибутов ФС гораздо более утилитарное и это как по мне правильно.

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

А еще, CDE не надо пользоваться - оно чудовищно. Есть же в Solaris ядерный терминал, для администрирования этого вполне достаточно.

Поправил.

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

вместо развития годных идей имеем редукционизм к проводникоубожеству

Если бы в линуксе был фм уровня виндового проводника, это был бы праздник. Во флагманском де, который пилят на деньги корпов, оставили 2 кнопки и полторы настройки. Теперь даже размер боковой панели не меняется. 😁

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

В Mac OS X в свое время этот вопрос решили интересно. Там теперь в консоли (да и в GUI) все эти ресурсные дела файла выглядят примерно так, будто это не файл, а директория с набором файлов. Так что МС при желании сделать любого вида эмуляцию своих потоков. Темнят.

В Apple A/UX который существовал во времена Mac OS System 7 разработчикам тоже приходилось решать задачу с поддержкой Resource forks, там сделали их поддержку отдельным файлом, имя которого должно было начинаться со знака % и далее соответствовать имени файла приложения, к примеру:

> ls
application
%application

Возможно что в современной macOS и APFS все эти костыли давным-давно убрали.

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

были проблемы с переносом файлов и приложений через тот же Интернет

Да куча проблем была в смешанных сетях. Я сейчас как вспомню так и плохеет, и это уже в благословенное время, когда были в т.ч. и Mac OS X Server - т.е. не надо было устраивать пляски с бубном вокруг Netatalk хотя бы. То с бэкапом проблемы какие-то вылезали, когда rsync надо было хитро патчить чтобы ему крышу не форках не рвало, то еще что-то.

Чур меня, короче! Спасибо что закопали это счастье.

BydymTydym
()

Когда был школьником, упоролся и пробовал переехать на Beos. Завелось всё железо, работал интернет, но когда обновился с селерона на семпрон, эта затея провалилась, тк беос не запускался на амд.

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

Возможно что в современной macOS и APFS все эти костыли давным-давно убрали.

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

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

Было бы интересно увидеть многооконный ФМ с продвинутым тайлингом.

Так а было же во времена KDE 3.5, называлось Konqueror:

В Konqueror был неограниченный Split (тайлинг), ты мог наделать на каждой вкладке кучу сплитов как тебе удобно, а не только два как в сегодняшнем Dolphin.

Плюс никто не запрещал использовать со всеми этими сплитами вкладки. Плюс – режим двухпанельности тоже никто не отключал.

Dolphin до сих пор не догнал по функциональности Konqueror эпохи середины нулевых.

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

В Apple A/UX который существовал во времена Mac OS System 7

Во времена конца 90-х и начала 00-х я был знаком, наверное, с половиной российской мак-тусовки из европейской части страны. Просто в силу того что было нас мало и сбивались в стаю, чтобы как-то выжить. Так вот, кажется не видел ни одного, кто тем сервером бы пользовался. Какие-нибудь SGI Indy у народа были для определенных задач, а этого чуда не было.

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

Насколько я помню, классические Resource fork поддерживались в Mac OS X, но постольку/поскольку, а после Mac OS X 10.4 и вовсе отвалились.

К примеру, консольными BSD-утилитами они не поддерживались. И перепаковав древний SIT-архив каким-нибудь TAR’ом получалась тыква.

EXL ★★★★★
()

Миниатюры сохраняются в расширенных атрибутах файлов.

Это опционально?

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

И перепаковав древний SIT-архив каким-нибудь TAR’ом получалась тыква.

В Haiku до сих пор упаковка TAR приводит к потерям аттрибутов, а наиболее полная поддержка особенностей ФС Haiku у формата ZIP.

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

Я вообще не уверен, что A/UX хоть как-то был распространён на территории ex-USSR.

Кстати, у меня скриншоты из эмулятора остались, вот как-то так A/UX выглядел:

https://github.com/EXL/2048/blob/master/image/Vi-AUX-Finder-3_0-Screenshot-1.png

По сути няшный GUI от System 7 натянутый на UNIX-like рельсы. Иксовый сеанс там тоже был:

https://github.com/EXL/2048/blob/master/image/Vi-AUX-X11-3_0-Screenshot-2.png

Но иксы даже в сравнении с Macintosh Toolbox выглядели уже устаревшими.

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

Линукс тем и хорош, что тут можно настроить под себя практически всё: расположение элементов на рабочем столе, их внешний вид, темы оформления.

Нет. Если ты не дизайнер интерфейсов, ты не сможешь кастомизировать линукс так, как тебе хочется. Например, я хочу выпуклые элементы управления и стиль окон и иконок а ля Windows 95 в KDE. Вот хрен оно там настраивается.

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

В Haiku до сих пор упаковка TAR приводит к потерям аттрибутов, а наиболее полная поддержка особенностей ФС Haiku у формата ZIP.

А перепаковка вида:

  • Запаковали ZIP в Haiku.
  • Распаковали ZIP в Windows.
  • Сделали изменение и запаковали ZIP в Windows.
  • Распаковали ZIP в Haiku.

Всё сломает?

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

Распаковали ZIP в Windows.

Это приведёт к потере аттрибутов. Также это приведёт к потере символьных ссылок и UNIX аттрибутов вроде исполняемого флага так что в Haiku придётся заново chmod +x делать.

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

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

Пока нет, но в следующем году скорее всего будет.

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

Более того, там и досовские драйвера работали как родные.

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

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

Хм, нет, пожалуй нет. То есть я хотел сказать оформление ужасно и… Не представляю как люди на ЭТОМ работали… И ты мне должен новые глаза… Х__Х

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

Но иксы даже в сравнении с Macintosh Toolbox выглядели уже устаревшими.

Да xlib вообще никогда нельзя было смотреть без содрогания. Эта концептуальная ошибка, кстати, до сих пор пользователям боком выходит. Нужно было какой-нибудь фреймворк сделать и тащить его, как во МакОси поступили или в Амиге какой-нибудь. Не сделали и в итоге веревка оказалась слишком длинной, собачка на ней умудрилась запутать все четыре лапы и хвост, теперь имеем десяток фреймворков, а точнее - они имеют нас.

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

Да, это всё типичные проблемы подобных расширенных атрибутов. Но с классическими Mac OS было куда эпичнее. Если провернуть похожую процедуру там, то исполняемый файл потеряет исполняемый код и станет 0 байт.

А всё потому что в M68K версии Mac OS почему-то решили хранить исполняемый код в Resource fork тоже. По сути вообще всё там хранили, а сам исполняемый файл был пустой записью в файловой таблице ФС.

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

Не, не забывай что это однобитные скрины. На них и KDE будет выглядеть страшно. Но у Классики Toolbox даже в однобитном режиме выглядел пристойно, а уж в серой гамме так и вообще спокойно воспринимался и до появления красивостей 8-й версии системы.

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

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

В Haiku в худшем случае для программ слетит исполняемый бит а также иконка. Иконка также хранится в ресурсах (ресурсы – часть файла а не аттрибуты), а иконка в аттрибутах – это по сути кэш и восстанавливается при первом запуске.

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

Нужно было какой-нибудь фреймворк сделать и тащить его, как во МакОси поступили или в Амиге какой-нибудь.

Так-то пытались сделать, вот тот же Motif (Xm) в CDE он работает ведь поверх Xlib и Xt. В Solaris был OpenWindows, а то на что ты говоришь что нельзя смотреть без содрогания – это Athena Widgets (Xaw).

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

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

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

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

Он про скрины солярки с CDE писал. А однобитный оригинальный Toolbox действительно офигенный, лучших B&W интерфейсов наверное и не было, просто для истории пару скриншотов:

Разве что поддержка монохромных экранов в более современных Windows могла с ними сравниться:

https://www.youtube.com/watch?v=A0VS9gqCAqE

Ну а угрёбищная вырвиглазная иксовая Athena Widgets действительно курит в сторонке в сравнении с вылизанным Toolbox’ом из System Software.

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

это Athena Widgets (Xaw)

А, точно, я уже подзапамятовал. Лет 20 назад по приколу на нем gvim собрал - очень уж с похмелья хотелось проблеваться.

Так-то пытались сделать

Оно так не вышло примерно по той же причине, по которой с юниксами вообще не вышло. Насколько я помню, Motif долгое время по лицензионным соображениям в Линуксе нельзя было использовать. Было бы можно - может и подровняли бы все его кривости, да utf-8 прикрутили бы, да скины какие-нибудь. В коммерческих юниксах все-таки Motif определенную упорядоченность давал, но они же его никак ни развивали далее, а энтузиасты - не могли.

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

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

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

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

Ну а угрёбищная вырвиглазная иксовая Athena Widgets действительно курит в сторонке в сравнении с вылизанным Toolbox’ом из System Software.

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

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

Да. Пока ты сидишь в Гайке и не передаёшь данные наружу. Но как только передал, всё теряет смысл. Идея «индексации без индексации» классная, но в сугубо замкнутом мирке. И что надо сделать с этими данными чтобы не потерять - ума не приложу. Сохранять рядом файл с расширением .attr чтобы не пропало всё?

Повторюсь, сама идея мне нравится.

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

Ну вот опыт показывает что в гетерогенной среде с этим жить сложно. Идея вроде как и хорошая, но… Проще уже тогда какой-нибудь аналог grep, понимающий форматы файлов написать, чтобы искал по требуемым атрибутам. По EXIF, к примеру или по id3 tags. Тоже тот еще геморрой, зато заведомо портабельно и ничего не потеряется. Правда, тоже не универсально, свой кастомный атрибут на файл не навесишь.

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

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

Пытались не плодить сущности. Если у тебя ФС имеет возможность создавать для объектов произвольные аттрибуты, то почему бы и не использовать эти возможности чтобы превратить ФС в подобие простенькой БД.

Вот в Linux популярные ФС подобных фич не имели и проекту KDE пришлось накручивать такие убогие и жирные костыли, за которые его матерят до сих пор. Да-да, я про всякие там MySQL базы данных которые тянули и наверное до сих пор тянут за собой простенькие PIM-программки типа Kontacts, KMail и даже плееры вроде Amarok. В Haiku эти вещи решили на уровне ФС, что может и не так гибко, зато быстро и легко.

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

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

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

И что надо сделать с этими данными чтобы не потерять - ума не приложу.

Передавать в ZIP архивах.

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

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

Я таких людей не припомню, которым нужно нативно это убожество пускать. Просто не востребовано оно в силу своей убогости. А вот годноту можно на следующей ступени эволюции и эмулировать - не велик грех и накладные расходы, со временем все на новую версию библиотеки (или api) переползут, как это в реальности в МакОСХ и произошло, но при этом сохранят преимущества единой библиотеки.

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

Так есть и сейчас попытки родить ФС в форме БД, но данные из них не переносимы на простую ФС.

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

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

Убожество не убожество, но оно до сих пор работает. А MacOS Toolbox мёртв и работает только в виртуальных машинах. Мёртв он потому что там нет необходимых абстракций и программы лезут во внутренние структуры оконного менеджера.

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

Если не распаковывать, то не пропадут. При желании этот ZIP можно рассматривать как самостоятельный тип файла как например это сделано с DOCX или ODF.

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