TL; DRA: Haiku is an operating system specifically designed for PCs, so it has a few tricks to make it a much better desktop environment than others. But how does it work?
I discovered Haiku, an unexpectedly good system. I'm still amazed at how smoothly it runs, especially when compared to Linux desktop environments. Today I'll take a look under the hood. Where necessary for in-depth understanding, I will make comparisons with the original Macintosh, Mac OS X, and Linux desktops (XDG standard from freedesktop.org).
Resources in ELF files
Yesterday I found out that IconOMatic can store icons in rdef resources in ELF executable files. Today I want to see how it actually works.
Resources? from , the original author of the Macintosh Finder and the father of the Macintosh Resource Manager:
I'm concerned about the rigid nature of traditional coding. For me, the very idea of ββββan application frozen in code, without the ability to change anything dynamically, is the wildest wildness. It should be possible to change as much as possible at runtime. Of course, the application code itself cannot be changed, but can something be changed without recompiling the code?
The original Macintosh made these files have a "data section" and a "resource section", which made it extremely easy to save things like icons, translations, and so on. in executable files.
On the Mac, this applies , a graphical program for - suddenly - editing resources.
ResEdit on original Macintosh
As a result, it became possible to edit icons, menu items, translations, and so on. easy enough, but they still "travel" with applications.
In any case, this approach had a big drawback: it only worked on Apple file systems, which was one of the reasons why Apple abandoned the "resource section" when moving to Mac OS X.
On Mac OS X, Apple wanted a file system-independent solution, so they adopted the concept of packages (from NeXT), directories that are treated as "opaque objects" by the file manager, like files, not directories. Any package with an application in the format .app has, among other things, the file Info.plist (in some analogue of JSON or YAML from Apple) containing application metadata.
Info.plist file keys from the Mac OS X application package.
Resources, such as icons, UI files, and others, are stored in the package as files. The concept actually went back to its roots at NeXT.
Mathematica.app on NeXTSTEP 1.0 in 1989: appears as a file directory in the terminal, but as a single object in the graphical file manager.
Let's go back to BeOS, on which Haiku is based. Its developers, when moving from PEF (PowerPC) to ELF (x86) (the same one used on Linux), decided to add a resource section to the end of ELF files. This did not use its own proper ELF section, it was simply added to the end of the ELF file. As a result of the program strip and others in binutils who don't know about it just cut it off. Therefore, after adding resources to an ELF file on BeOS, it is best not to work with it with Linux tools.
And what is happening now with Haiku? Basically, more or less the same.
In theory, it would be possible to place resources in the desired section of the ELF. According to the developers on the #haiku channel on irc.freenode.net:
With ELF, the section would make more sense... the only reason we don't do that is because we did it in BeOS."
And it doesn't need to change now.
Resource management
Resources are written in a structured "resource" format: in fact, this is a list of resources with sizes and then their contents. remembered .
How to check resources in Haiku? Is there something like ResEdit?
According to :
You can drag and drop the executable onto a program such as . You can also go to the terminal and run the command
listres ΠΈΠΌΡ_ΡΠ°ΠΉΠ»Π°.
Resourcer is in HaikuDepot, but it just crashes for me.
So how do you manage resources in ELF files? Using rsrc ΠΈ rdef. rdef files are collected in rsrc. File rdef stored in plain text format, so it's much easier to work with. File format rsrc appended to the end of the ELF file. Let's try to play:
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and licenseYou can use the program xres to check and manage:
/> xres
Usage: xres ( -h | --help )
xres -l <file> ...
xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)Okay, let's try?
/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type ID size name
------ ----------- ----------- --------------------
'MIMS' 1 36 BEOS:APP_SIG
'APPF' 1 4 BEOS:APP_FLAGS
'MSGG' 1 421 BEOS:FILE_TYPES
'VICN' 101 7025 BEOS:ICON
'VICN' 201 91 kActionBack
'VICN' 202 91 kActionForward
'VICN' 203 300 kActionForward2
'VICN' 204 101 kActionStop
'VICN' 206 243 kActionGoStart
'MSGG' 205 1342 kActionGo
'APPV' 1 680 BEOS:APP_VERSIONMore about resources and format rdef you can read .
Standard resource types
While you can put anything in resources, there are a few defined standard types:
app_signature: MIME type of the application, to match opened files, startup, IPC, etc.app_name_catalog_entry: Since the application name is usually in English, you can specify the places where the translated names are located here, so that users of different languages ββ\uXNUMXb\uXNUMXbwill see the translated application name if desired.app_version: Exactly what you thoughtapp_flags: indicatesregistrarhow to handle the application. I think there is more to it than meets the eye. For example, there isB_SINGLE_LAUNCH, which causes the system to start a new application process every time the user requests it (the same principle is used for most applications on Linux). EatB_MULTIPLE_LAUNCH, causing the process to run for each file. Finally thereB_EXCLUSIVE_LAUNCH, which forces the system to start only one process at a time, no matter how often users start it (for example, this is how Firefox on Linux starts; the same result can be achieved in Qt applications using the function ). Applications withB_EXCLUSIVE_LAUNCHare notified when the user tries to run them again: for example, they get the path of the file that the user wishes to open with them.vector_icon: Application vector icon (BeOS did not have vector icons, most applications had two bitmap icons in their executable files instead).
Of course, you can add resources with any desired IDs and types, and then read them in the application itself or other applications using the class BResources. But first, let's focus on the fascinating theme of icons.
Vector icons in Haiku style
Of course, not only Haiku chose the best icon format, in this part the situation with Linux desktops is far from ideal:
me@host:~$ ls /usr/share/icons/hicolor/
128x128 256x256 512x512 index.theme
160x160 28x28 64x64 scalable
16x16 32x32 72x72 symbolic
192x192 36x36 8x8
22x22 42x42 96x96
24x24 48x48 icon-theme.cacheLooking at this, you can already feel what this piece is.
Of course, there is a scalable containing, as you can see, vector icons. Why then is there anything else? Because the result of drawing vector graphics in small sizes can be less than ideal. I would like to have different options, optimized for different sizes. In Linux desktop environments, this is achieved by scattering icons of various sizes throughout the file system.
me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.pngNote that there is no concept of different versions of Firefox. Thus, it is not possible to gracefully handle the situation with the presence of several versions of the application in the system.
Different Firefox icons in different versions. So far, it is impossible to handle this in Linux without various crutches.
Mac OS X handles a little more refined:
Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icnsIt can be seen that there is one file firefox.icns in the package Firefox.app, containing all sizes, so that different versions of the same application have different icons.
Much better! Icons travel with the application, all resources are in one file.
Let's get back to Haiku. A mind-blowing decision, no exceptions. According to :
A special HVIF format, highly optimized for small sizes and fast rendering, was developed. Therefore, our icons are for the most part much smaller than bitmaps or the widely used SVG format.
And they are still optimized:
Icon sizes in HVIF compared to other formats.
An order of magnitude difference!
But the magic doesn't end here. The same HVIF may show different levels of detail depending on the displayed size, even though it is a vector format.
Different levels of detail (LOD) based on render size
Now about the disadvantages: you cannot take SVG, throw it into ImageMagick and finish it, you have to go through several cycles to create an icon in HVIF format. explanations. However, IconOMatic can be quite imperfect at importing SVGs; about 90% of the SVG details are imported with some probability, the remaining 10% will need to be configured and changed manually. Read more about how HVIF does its magic on the blog
Adding an Icon to an Application
Now I can add an icon to the package created , taking into account all the information received.
Well, since I'm not particularly eager to draw my own icon for my βHello Worldβ QtQuickApp right now, I pull it out of Qt Creator.
/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator -o /Haiku/home/QtQuickApp/QtQuickApp -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt CreatorLet's check that the icon is copied:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONLooks good, but why is it that when the new icon is copied, it doesn't show up?
The copied VICN:101:BEOS:ICONs is not currently used as an application icon in the file manager
What did I miss?
Developer comment:
Need to create a file
rdefwith all resources, then run the commandrc ΠΈΠΌΡ.rdef, this will create a file.rsrc. Then you need to run the commandresattr -o ΠΈΠΌΡ_Π±ΠΈΠ½Π°ΡΠ½ΠΈΠΊΠ° ΠΈΠΌΡ.rsrc. At a minimum, I use similar commands to add icons to my scripts.
Well, I wanted to create a resource, not an attribute. I'm downright confused.
Smart caching using the file system
Opening and reading ELF attributes is slow. As I wrote above, the icon is written as a resource in the file itself. This method is more reliable, it allows you to survive copying to another file system. However, then it is also copied to a file system attribute, for example BEOS:ICON. This only works on certain filesystems, such as BFS. Icons shown by the system (in the Tracker and Deskbar) are read from this extended attribute because this solution is fast. In some places (where speed is not important, for example, a typical "About" window), the system receives an icon directly from a resource in a file. But this is not the end. Remember, on the Mac, users could replace the icons of applications, folders, documents with their own, because on the Mac it is possible to do these "important" things, for example . On Haiku, think of a resource (in a file) as the original icon that comes with an application, and an attribute (in a BFS filesystem) as something that allows the user to make changes at will (although, hint, a GUI for inserting a custom icon on top of the icon is optional). not yet implemented by default).
Checking File System Attributes
With resaddr it is possible to check and set file system attributes.
/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]
Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)It's essentially the "glue" that does the back-and-forth conversion between (reliable) resources and (fast) file system attributes. And since the system assumes resource acquisition and does the copying automatically, I won't worry about that any further.
The magic of hpkg packages
Currently (most often) packages are used to get programs on Haiku .hpkg. Don't be fooled by the simple name: the .hpkg format works very differently than other similarly named formats you've come across, it has real superpowers.
With traditional package formats, I was upset for a long time because of this fact: you download one thing (package), and another one is installed in the system (files inside the package). It is quite difficult to manage files (eg remove them) when installing a package in the traditional way. And all because the contents of the package scattered throughout the file system, including places where a normal user might not have write access. This gives rise to a whole class of programs - package managers. But transferring already installed software, for example, to another machine, removable disk or file server becomes even more difficult, if not impossible. On a typical Linux-based system, hundreds of thousands to millions of separate files can easily exist. Needless to say, this is both fragile and slow, for example during the initial installation of the system, when installing, updating and removing ordinary packages, and when copying the boot volume (root partition) to another medium.
I'm working on an AppImage project, a partial crutch for end user applications. This is a software distribution format that collects an application and all of its dependencies into a single file system image that is mounted when the application starts. It greatly simplifies things, since the same ImageMagick suddenly turns into a single file managed in a file manager by mere mortals. The suggested method only works for software, as reflected in the project name, and also has its own set of bugs, since Linux software vendors always point to me.
Let's get back to Haiku. Have you found the right balance between traditional packaging systems and image-based software delivery? Her packages .hpkg actually compressed file system images. When the system boots, the kernel mounts all installed and active packages with something like the following kernel messages:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"Cool, yeah? Hang in there, it's going to get even worse!
There is a very special package:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"It contains a very minimalistic operating system, including the kernel. Believe it or not, even the kernel itself is not extracted from the boot volume (root partition), but is neatly loaded into its place from the package. .hpkg. Wow! I mentioned earlier that, to me, part of the overall sophistication and consistency of Haiku comes from the fact that the entire system, from the kernel and the underlying userspace, to package management and the desktop infrastructure, is developed collaboratively by one team. Imagine how many different groups and teams it would take to run something like this on Linux. [I imagine the PuppyLinux project, - approx. translator]. Then imagine how long it will take for this approach to be implemented in distributions. They say: take a simple task, divide it among different performers, and it will become so complicated that it will no longer be solved. Haiku opened my eyes in this case. I think this is exactly what is happening on Linux now (Linux in this case is a collective term for the Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu stack).
System rollback using hpkg
How often does the following situation happen: the update was successful, and then it turns out that something is not working as it should? If you use regular package managers, it's hard to revert the state of the system to a point in time before installing new packages (for example, when something went wrong). Some systems offer workarounds in the form of filesystem snapshots, but these are cumbersome and not applicable on all systems. In Haiku this is solved with packages .hpkg. Whenever packages in the system change, the old packages are not removed, but are stored in the system in subdirectories like /Haiku/system/packages/administrative/state-<...>/ constantly. Pending operations store their data in subdirectories /Haiku/system/packages/administrative/transaction-<...>/.
Content /Haiku/system/packages/administrative. The "state ..." directories contain text files with the names of active packages, "transaction ..." - the packages themselves.
"Old active state", i.e. list .hpkg packages active before changes are written after each operation in the file manager in a text file /Haiku/system/packages/administrative/state-<...>/activated-packages. Similarly, a new "active state" is written in a text file /Haiku/system/packages/administrative/activated-packages.
Catalog /Haiku/system/packages/administrative/state-<...>/ contains only a text file with a list of active packages of this state (in case of installing packages without removing them), and if packages were removed or updated, the state directory contains old versions of packages.
When the system boots, based on the list of packages, a decision is made to activate (mount) the packages. It's so simple! If something goes wrong during the download, you can tell the download manager to use a different, older list. Problem solved!
Haiku bootloader. Each entry point displays a corresponding "active state"
I like the approach of using plain text files as a "active state" list with easy-to-understand names .hpkg. This is in stark contrast to the built-for-machine-not-for-humans from OSTree or Flatpak in the file system (in the same level as the Microsoft GUID).
List of active packages for each point in time
Configuration Data
Apparently the catalog /Haiku/system/packages/administrative/writable-files contains configuration files for packages, but writable. After all, as you remember, .hpkg are mounted read-only. Thus, these files must be copied from the packages before being written. Has the meaning.
GUI integration for .hpkg system
Let's now see how these shiny packages .hpkg cope with integration into the user's work environment (UX). After all, Haiku is meant for personal use, after all. Personally, I have set the bar high by comparing user experience to packages. .app on Macintosh with the same experience on .hpkg. I won't even compare the situation with Linux desktop environments, because it's absolutely terrible compared to any other.
The following scenarios come to mind:
- I want to view the contents of the package
.hpkg - I want to install a package
- I want to remove a package
- I want to delete something that came into the system as part of a package
- I want to copy something that came into the system as part of a package
- I want to download all package dependencies that can't be part of every Haiku installation (for example, I have a physically isolated machine with no Internet access.)
- I want to move my packages (well, part of them) separately to another place, separate from the boot volume (root partition) (because, for example, I don't have enough space on it).
This should cover most of the main cases from my daily work. Well, let's get started.
Checking the Package Contents
On Mac I just right-click on a package to open it and view the contents in the Finder. It's really just a directory in disguise! (I know there are packages .pkg for a part of the system that is not applications, but ordinary users most often do not interact with them).
On Haiku I right click on the package, then click on "Contents" to see what's inside. But it's just a list of files without the ability to double-click to open them.
It would be much better if there was a way to (temporarily) mount a package .hpkg to view through a file manager, and the user would not have to worry about implementation details. (By the way, you can open .hpkg package in Expander, which can unpack it like any other archive).
In the interface of HaikuDepot, you can view the list of package files, but there is no way to view the contents, for example, by double-clicking on README.md
In this category, the Mac wins, but adding the right functionality to HaikuDepot shouldn't be a big deal.
Installing a package via the GUI
On Mac, most disk images .dmg contain packages .app. Open the disk image by double-clicking, and then copy the package, for example, by dragging it to /Applications in Finder. For me it goes without saying, but I heard that some beginners may not be able to handle this. By default, Apple "suggests" a system-wide directory /Applications (on NeXT it was networked as well as individual), but you can easily place your applications on a file server or in a subdirectory $HOME/Applicationsif you like it so much.
On Haiku, double click on the package, then click on "Install", it couldn't be easier. I'm wondering what happens if a package has dependencies available in HaikuPorts, but not yet installed. On Linux they don't really know what to do in this situation, but the solution is obvious - ask the user if the dependencies need to be downloaded and installed. Exactly what Haiku does.
I downloaded the 'sanity' package manually and clicked on it, the package manager knows where to get its dependencies from (assuming the repositories are already on the system). Not every Linux distribution can do this.
Another way is to use the file manager, just drag and drop .hpkg package or in /Haiku/system/packages (for a system-wide installation, by default), or in /Haiku/home/config/packages (for individual setting; not available by double-clicking - I'm still annoyed by the word "config" in this place, which for me in this case is a synonym for "settings"). And the concept of multiple users isn't even available to Haiku yet (maybe that's why it's so simple - I don't know, maybe the multi-user capabilities will complicate things unnecessarily for a desktop desktop environment).
In this category, Haiku wins, because it can work not only with applications, but also with system programs.
Removing a package from the GUI
On Mac, you need to drag the application icon to the trash, and that's it. Easily!
On Haiku, firstly, you need to find where the package is located in the system, because you rarely install it in the right place (the system does everything). Usually you need to look for /Haiku/system/packages (in a system-wide default installation), or in /Haiku/home/config/packages (Did I mention that "config" is the wrong name?). Then the application is simply dragged to the trash, and that's it.
Easily! However, I wouldn't say so. Here's what's really going on:
This is what happens when you drag an app to the trash from /Haiku/system/packages
Just tried moving my yesterday's "Hello world" app on QtQuickApp to the trash. I didn't try to move the system directory, and since all packages are installed in the system directory - it is impossible to remove the package .hpkg without change "its content". An ordinary user would be scared, would press the "Cancel" button assigned by default.
Explains :
This post is over 10 years old. Most likely, we need to configure it so that the warning comes out only when the package itself is moved. Ordinary users don't need to do this anyway.
Okay, maybe you should do it using HaikuDepot? Double click on the package /Haiku/system/packages, waiting for the "Uninstall" button to show up. Nope, there is (only) "Install". Uninstall, where are you?
For fun, I tried to see what happens if I click "Install" on an already installed package. It turns out like this:
This happens if you try to install an already installed package.
It appears next:
If you click "Apply changes" in the previous window, it will turn out like this
I assume that this is a software error, the link to the application is already there. [the author did not provide a link, - approx. translator]
Quick fix: Add an "Uninstall" button if the package is already in
/Haiku/system/packages, or in/Haiku/home/config/packages.
When viewing the list of packages installed in HaikuDepot, I can see my package in the list and can remove it.
Mac wins this category. But I can imagine that with proper setup, the user experience on Haiku will be better than on Mac. (One of the developers rated it like this: βLess than an hour to add the specified functionality to HaikuDepot if you know a little C ++β, any volunteers?)
Removing something from a package
Let's try to uninstall the app itself, not the package .hpkg, from which it appeared (I doubt that for "mere mortals" there is any difference).
On Mac, the user actually works with the file normally .dmgwhere the application package comes from .app. Usually images .dmg are accumulated in the downloads directory, packages are copied by the user to /Applications. It is believed that many users themselves do not know what they are doing, this hypothesis is confirmed by a former Apple employee. (One of the things I don't like on a Mac. And with AppImage, for example, there's no difference between the app and the package it was in. Drag the icon to the trash = that's it. Easy!)
On Haiku, there is also a division between apps/ ΠΈ packages/, so I doubt that this made it any clearer to users. But what happens if you drag the application from apps/ Add to cart:
This is what happens when you try to remove an application taken from a file .hpkg
It's technically correct (after all, the application is hosted on a read-only file system, in the first place), but it's not particularly useful to the user.
Quick fix: Suggest via GUI to delete instead
.hpkg
For fun, I tried to duplicate the application by pressing Alt + D. Got the message "Unable to move or copy objects on a read-only volume." And all because /system (besides /system/packages ΠΈ /system/settings) is the packagefs mount point (remember how it appears in the output df?). Unfortunately, the output of the command mount does not clarify the situation (as was said in one of the previous articles), mountvolume does not show what you are looking for (apparently packages mounted via loop .hpkg are not considered "volumes"), and also I forgot the alternative commands.
In this category, no one won, except for AppImage (but this, to be completely honest, is a biased opinion). However, one can imagine that after tweaking, the user experience on Haiku will be better than on Mac.
Note: you need to figure out what "volume" is in relation to "partition". This is probably akin to a "folder" to "directory" relationship: most directories appear as folders in the file manager, but not all of them (eg packages treated as files). Does this sort of thing make me officially a nerd?
Copying the contents of a package to another system
On Mac, stupidly pulling the package .app, and since the dependencies are inside the package, they move together.
On Haiku, I drag the application, but the dependencies are not processed at all.
Quick fix: Instead, suggest dragging the entire "`.hpkg" package, along with dependencies, if any.
In this category, the Mac clearly wins. At least for me, a lover of their paradigm. Haiku should be copied .hpkg instead of an application, but the system does not offer me this ...
Downloading a package with all its dependencies
Not every machine is online all the time. On the contrary, some machines (yes, I'm looking at you, modern Windows, Mac and Linux) forget about it. It is important for me that I can go to an Internet cafe, for example, download software to removable media, insert this media into my home computer and be sure that everything will work [risk guy, do this on Windows ... - approx. translator].
As a result, a little more often than usual, I usually end up with unmet dependencies on Windows and Linux.
On Mac this is usually one file, all you need is to download .dmg. Most often, it has no dependencies other than those provided by MacOS itself by default. An exception is complex applications that require an appropriate runtime environment, such as java.
On Haiku download package .hpkg for, say, the same java application, may not be sufficient, since java may or may not be present on the target machine. Is there a way to download all dependencies for a given package .hpkgother than those that are installed by default in Haiku and therefore should be on every Haiku system?
In this category, the Mac wins by a small margin.
Commented by mr. waddlesplash:
To write a program to collect all the dependencies of an application as a set of packages
.hpkgfor someone familiar with Haiku's internals, about 15 minutes is sufficient. It's not that hard to add support for this if there's a real need for it. But for me this is rare.
Let's hold our breath until the next article in this series.
Moving packages to a separate location
As I wrote earlier, I want to put my packages .hpkg (well, or part of them) to a special place, separate from the usual placement on the boot volume (root partition). In the usual (not so theoretical) case, the reason for this is that my (built-in) drives are constantly running out of free space, no matter how big they are. And I usually map external drives or network shares where my applications reside.
On Mac i just move packages .app to a removable drive or network directory in Finder, and that's it. I can still double-click to open the app as I normally do from the boot volume. Just!
On Haiku, as I was told, this can be achieved by moving my .hpkg packages to a removable drive or network directory, but then you need to use some undocumented commands in the console in order to mount them on the system. I don't know how to do it using GUI only.
Mac wins this category.
According to mr. waddlesplash:
This is an optimization based on normal use. If there is a demand for more than one user, we will implement it. In any case, there is the possibility of a third-party implementation.
We will talk about this in the next article.
Speaking of network directories: it would be great (I'm guessing LAN parties) to have simple, discoverable, network-wide applications (eg by Zeroconf) that can be copied to a local computer or run directly from the local network. Of course, developers have the option of opting out via app_flags.
Final report on the integration of the hpkg system with the GUI
I think that primarily because of the relative novelty of the integration .hpkg with the GUI still leaves a lot to be desired. Anyway, there are a few things that could be improved in terms of UXβ¦
One more thing: Kernel Debug Land
It would be great to be able to enter commands during kernel panic, for example syslog | grep usb. Well, on Haiku it's possible thanks to Kernel Debug Land. How can you see this magic in action if everything works as it should for you without getting into a kernel panic? Easily by pressing Alt+PrintScn+D (Debug mnemonic). I immediately remember , which allowed the original Macintosh developers to enter the debugger (if one was installed, of course).
Conclusion
I'm beginning to realize that the sophistication of the Haiku system comes from the fact that the work is done by one small team with a clear focus on the working environment, with access to all layers of the system.
A sharp contrast to the world of Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, where everything is broken into small pieces to such an extent that abstraction sits on abstraction and drives crutches.
There was also an understanding of how the system .hpkg combines the best practices of traditional package managers, Snappy, Flatpak, AppImage, even btrfs, and mixes them with Mac's "just works" approach.
It was as if something βswitchedβ in my head, and I understood how the system .hpkg knows how to roll away, just by looking at her. But this is not me, but the beauty and simplicity of the system. Much here is imbued with the spirit of the original Mac.
Yes, browsing in the browser can be jerky and work like a snail, applications can be lacking (no Gtk, Electron - the developers concluded that they do not go well with sophistication), video and 3d acceleration may be completely absent, but still I like it this system. After all, these things can be corrected and sooner or later they will appear. It's only a matter of time and perhaps a little red eye.
I can't offer help, but I think it will start from now on. year of haiku on desktop.
Random Issues
Maybe there are applications already, or should I open them?
- BeScreenCapture should be able to export to GIF like Peek. This can be done with ffmpeg already available for Haiku. .
- Screenshot tool fails to take a screenshot of a modal window, instead capturing the entire screen
- You can't crop screenshots with WonderBrush's crop tool and then save the result to a file
- I don't particularly like the hand cursor in Haiku, but I think it has a warm nostalgic feel to it. This is especially annoying when using the crop tool in Krita, as it results in an inaccurate crop (see screenshots of the modal dialogs in this article). A crosshair cursor would be great. .
Try it yourself! After all, the Haiku project provides images for booting from DVD or USB, generated . To install, just download the image and burn it to a USB flash drive using
Got questions? We invite you to the Russian-speaking .
Error overview:
From Translation: This is the sixth article in the Haiku series.
List of articles:
Source: habr.com