Skip to content

Releases: ivan-hc/AM

"AM" 9.7

13 Apr 11:18
96e523d

Choose a tag to compare

Endless...

In this new release, support for torsocks has been removed in favor of proxies!

By default, the one provided by the PkgForge team will be used to update and install apps from this site, but it will be possible to set your own proxy by exporting the ALT_GH variable (HTTPS domain). In order not to force the proxy, an uncrossable limit of API calls will be granted for installations (10) and updates (5).

For the occasion, it is suggested to install the new fork of appimageupdatetool provided by the PkgForge team, as an alternative to the original one. The installation script will suggest you to install it by pressing 1 or to choose the original by pressing 2. The choice is yours.

Full Changelog: 9.6.2...9.7


Conclusions

For you who read this... try to hold on to the important things. Nothing is forever, except the regret of not having done enough...

If there is something I always have cared about, it is honesty, and what I do not lack is the desire to do things well, and the ever-increasing anger when I see things not going as they should.

After all, we all grew up with different stories, developing different characters and nuances... we are children of what we have learned.

I, personally, owe the desire to do things and the possibility of doing them to a single great person, who taught me to be humble. An honest, sociable person, loved by everyone... especially by me. A person with whom I spent most of my time and who now more than ever I miss, and I know I will miss him in the future.

A person, who I still struggle to believe I will never see again, since that damned April 7th in which, unexpectedly, he left an unfillable void in my life, and in that of my family.

That man was my father.

Ciao papà, ti voglio bene

Nothing will be the same again now that you are no longer here.


"AM" 9.6.2

04 Apr 02:27
19d80c1

Choose a tag to compare

Various improvements

Since "AM" is a modular program, modules can receive updates separately, independently of changes in the main CLI "APP-MANAGER"... which is why three-digit releases can bring with them much more news than two- or one-digit ones, and vice versa.

This three-digit release brings with it the following.


New option -HC (or -CH if you prefer)

This new option is nothing more than the combination of the options -H/--home and -C/--config, useful to set dedicated $HOME and $XDG_CONFIG_HOME directories for one or more AppImages, this time in one go.

You will need to run

am -HC {PROGRAM}

instead of

am -H {PROGRAM} && am -C {PROGRAM}

Istantanea_2025-04-04_02-42-44

...and of course you can use multiple arguments at once.

DISCLAIMER: AppImage dotfile isolation works in most cases, but it all depends on the default settings wanted by the upstream developer/packager. Please use --sandbox to ensure dotfile isolation, as well as improve security.

In this sense, the above-mentioned -C and -H options have been moved from the sandboxes.am module to the management.am module, and the former will be completely dedicated to actual sandboxing via Aisap and BubbleWrap.


"Limited" Type 1 AppImage support

Installation scripts for obsolete, optionless Type 1 AppImages have all been removed. However, they will still be manageable using the --launcher option.

"AM" discourages the use of Type 1 AppImage packages and encourages users to contact upstream developers to upgrade to a more recent and widely supported runtime, for security reasons.

Typically, Type 1 AppImages are the kind of files that, once downloaded, cannot be extracted using --appimage-extract nor respond to the other options commonly found on most Type 2 AppImages (both the older ones that depend on libfuse2 and the newer ones that don't)... and instead, the program is launched directly.

That's why I preferred to remove that type of AppImage.

Anyway, if you really rely on an old type 1 AppImage of 2018 or older, install 7z and manage it with --launcher as I said above.


Workflows

Scripts are now tested at 250 at a time every hour, every day, to ensure control and review of the applications that can be installed from the "AM" database.

While the workflow is currently disabled in this repository, it is still active in our test repository maintained by @zen0bit

See https://github.com/ivan-hc/amcheck/actions/workflows/test-apps.yml for all results.


Option apikey

Fixed an issue with updating outdated ghapikeys, by @nazdridoy


Options -l/list and -q/query, new --portable flag

It is now possible to list and search for only portable apps (not AppImages) in the "AM" database using the --portable flag

Istantanea_2025-04-04_03-43-34


Options -o/overwrite and -b/backup

Both backup/restore options and other options of the same type that use selection can be undone by pressing ZERO, no undo with CTRL+C is needed.


Options -a/about and -f/files

Apps outside of supported databases, i.e. AppImages installed with the -e or extra option, can now be referenced as being from the extra database (which does not exist) in -f, just like programs installed from supported third-party databases.


Conclusions

I know that bombarding a release with information like this is difficult and may seem confusing (especially for some sites that specialize in reporting releases and that, in an attempt to rework a text with AI, write something completely different from what I wrote here... in fact, unlike Agent Smith in the Matrix, I say "never let a machine do a human's job")... but I have my logic on how releases should be. They should describe real changes... and they should not be aimed at attracting attention and visibility by pushing your project to the top of search results with every commit... just to appear high in a site or catalog (like Flathub, for example).

I prefer that each release is like an updated "guide" to what changes in my project. Users need to know what I did and what has changed. So much so that even my AppMan repository has a link connected to this release, to every AppMan release (and probably you who are reading this came from there too).

Today some developers prefer to attract attention instead of focusing on how to improve their project to consequently supporting an ecosystem by externalizing its dormant potential. Well, I prefer to be boring, and reveal to the people that AppImages evolve and that they have internal options capable of isolating dotfiles while keeping the system clean... or that they support delta updates... that they can be closed in a sandbox or that they can be converted so as not to depend on libfuse2!

This is how you support an ecosystem: revealing its best, and involving the community to improve it!

There are those who work to support a community idea... and those who work for themselves (begging for donations), causing only damage to that community... pushing users towards another community, even if unconsciously.

I took AppImage as something to save, and there are those who have followed my idea by setting up interesting projects supported by entire communities. But as expected, there are always some leeches ready to make all this fail, disguising their project as something extremely useful (while not proposing anything new, but using "trendy" tools that create nice apps... and that's it), but which in fact belongs to a mainstream ecosystem opposite to the one we support as a community.

We who truly love AppImage, want to warn you about false idols: Beware of appearances!

If you really want to support AppImages and those who work to improve them... do it properly! Support all those projects that work directly on AppImage packages! Support whoever builds your favorite AppImage packages! It doesn't matter how (donations, bug reports, pull requests...)... as long as it's directly with those who really understand AppImages.

It's the only way to keep this ecosystem alive.

Many people believe that all AppImages still depend on the old and obsolete libfuse2, and some developers mask their inability to package AppImages by saying "it's hard to make them" but ignoring those who offer to help them, or by saying that "most AppImages are Electron-based applications", when a quick look through my repositories shows that VLC, GIMP, Bottles, VirtualBox, OBS Studio... are anything but Electron apps. Here, be wary of these clichés and of those who tell you these phrases... especially those who elevate their solutions as "definitive" by inventing excuses, lies and cowardly supporting their theses for vile money!

AppImage is many things. Let's support its ecosystem! For real!

What's Changed

Read more

"AM" 9.6.1

14 Mar 12:58
d1f3dd0

Choose a tag to compare

Various improvements related to the management of applications external to the "AM" database

This release fixes some issues related to the management of apps installed via the -e or extra option, and removes some variables specific to third-party databases delegating them to a file to be used as a source.

Let's proceed in order.

-e or extra option

From this release onwards, AppImages installed with this option will have their own category in -f or files...

Istantanea_2025-03-14_13-16-57

...if there is a duplicate, it will be reported in -a or about...

Istantanea_2025-03-14_13-17-53

...also, the problems of reporting changed scripts in -s or sync and the problems of their removal in the brand new reinstall option (see https://github.com/ivan-hc/AM/releases/tag/9.6) have been fixed

simplescreenrecorder-2025-03-14_10.51.06.mp4

...all these issues have been fixed by adding an .extra extension to locally hidden scripts, relating AppImages installed via the -e option to those programs installed from external databases (for example soarpkg/toolpack).

The only difference is that for applications with the extension .extra there is no description...

Istantanea_2025-03-14_13-18-37

...which is fair, since they are not "classified".


A "banner" for -e in your repository?

I added a small paragraph to the README in which I suggest users who have their own AppImage package not listed in "AM" and who would like to help users get all the benefits (updating, integration, sandboxing...) enjoyed by those listed here

To install and update my AppImage using "AM", simply run the following command:

am -e https://github.com/user/project appname keyword

if you want to install and update it locally, run

am -e --user https://github.com/user/project appname keyword

...or if you use AppMan

appman -e https://github.com/user/project appname keyword

...the idea came to me after I came across a similar instruction in another repository.

It could be an idea for all those who, for one reason or another, cannot or do not want to submit their AppImage hosted on github in the "AM" database.

See https://github.com/ivan-hc/AM#do-you-own-a-repository-for-appimages-external-to-this-database-follow-these-instructions


External databases

I moved all the supported databases into this file that I named "am-extras", like the repository that hosts it:

https://github.com/ivan-hc/am-extras/blob/main/am-extras

The file will be placed in $HOME/.local/share/AM together with the lists.

The new variable $AM_EXTRA_SOURCES is exportable! You can attach it to the .bashrc file in case you want to use a different list.


"Test-100" Workflow

As the days go by, I'm improving the workflow provided by @zen0bit , so that I can constantly keep an eye on existing scripts, ensuring their highest quality.

You can also keep an eye on those flows, here

https://github.com/ivan-hc/AM/actions/workflows/test-apps.yml

For now, each new test starts automatically every two hours, thus completing all tests in less than two days (also ensuring that I have enough time to fix broken scripts... and do other things).


Mass update of AppImage scripts

All AppImage scripts are now fairly uniform.

All include support for appimageupdatetool, while zsync support has been removed as it is not always reliable.

In addition, many scripts have been improved, eventually making them more similar, making them easier to debug.


Repology.org

Yesterday, the repology.org site that about sixty installation scripts rely on, had problems, many workflows (see above) were abruptly interrupted.

While waiting to further resolve the dependency on repology.org, I moved all references to an alternative API kindly provided by the amazing Package Forge team, at https://github.com/pkgforge

The change has been applied:

  • to about 60 applications
  • to the "install.am" module (the new API has no geographical restrictions, so the torsocks patch has been completely removed)
  • to the "template.am" module

Bug in the -t option

A nasty bug in the -t option that led to the creation of a wrong AM-updater if an AppImage was hosted on a site other than github has finally been fixed.

The bug was introduced months ago, with the addition of appimageupdatetool in the AppImage template. This change made the script longer, which resulted in the command being placed on the wrong line.

Fortunately, not too many AppImages had been added since then... we had already added a ton of them since then, and most of the new ones had the "$version" variable above that line... so it was a problem with 5-6 scripts.

It wasn't a major bug, fortunately, but it did prevent apps from updating.

Just run am reinstall if you haven't already.


What's Changed

  • Add appimageupdatetool to my AppImages by @ivan-hc in #1390
  • Add appimageupdatetool support / remove zsync by @ivan-hc in #1394
  • Add appimageupdatetool support / remove zsync (pt2) by @ivan-hc in #1395
  • Add appimageupdatetool support and remove zsync (i686) by @ivan-hc in #1397
  • Update some installation scripts for aarch64 by @ivan-hc in #1398
  • Check the connection during installation by @zen0bit in #1399
  • Replace repology.org with api.rl.pkgforge.dev by @ivan-hc in #1401

Full Changelog: 9.6...9.6.1

"AM" 9.6

09 Mar 23:39
619a533

Choose a tag to compare

New option to reinstall the apps!

To introduce the new changes, here is a premise on how the AM-updater script works.

Premise

As you well know, portable apps (not only AppImages) hosted on various official and non-official sites, can have different methods to be downloaded and installed.

The diversity of these sites and download methods involves constant maintenance of existing scripts, as many links can disappear for reasons ranging from the removal of a repository by the developer to the removal of a domain.

The scripts are tested automatically (or manually) 100 at a time through our workflows, see https://github.com/ivan-hc/AM/actions/workflows/test-apps.yml

When one of these scripts fails, manual control is triggered, where I go to investigate the causes of such failure... until this script is modified to fix the problem.

This means that the scripts already installed prior to this change, lack new features or even just new online references to be updated.

To suppress this problem, running the command am -s (to update AM, modules and check for changes in scripts) or am -u (which includes am -s and updating all installed apps) will notify you if the online scripts have changed, so you can be warned that you may need to remove and reinstall the application.

If you used to have to run am -R {PROGRAM} && am -i {PROGRAM} manually on all reported scripts... now it's easier!


New reinstall option

With the following command

am reinstall

or if you use AppMan

appman reinstall

the scripts will be checked one by one as in -s, but will also be removed and reinstalled the apps that require such an update.

In this test I installed lxtask and platform-tools system-wide, while brave-appimage, firefox-appimage and anydesk are installed locally, per AppMan

I will do a test without modifying any scripts, then I will simulate a change in the scripts by adding some lines in the local scripts... here's what happens

simplescreenrecorder-2025-03-09_16.43.07.mp4

...the 5 apps were removed and reinstalled one by one, respecting the installation level, be it system or local.

NOTE, the simple -i is executed using the local script name as argument, to avoid installing the wrong counterpart. In case you have set a .home (option -H) or .config (option -C) directory or in case you have set a sandbox (option --sandbox) you will have to do it again using the dedicated options later.

How to check when to use the command?

An app installed with an old script is in the worst case broken (in the sense that the wrong file is downloaded, see #1364) or not updatable.

To know when to use this command, simply start an update with -u or a sync with -s. I also added a final message as a reminder, in case you forget the new command (I'll do a simulation in this video too)

simplescreenrecorder-2025-03-09_20.58.19.mp4

Why not add the command directly in -s?

For transparency. The user needs to know when the script was changed and what was changed, before proceeding with the installation. He can then decide whether to install or remove the application altogether. I don't do things without your consent... I'm not Mozilla (the new terms of service which they say will be applied "at any time" are the reason why I abandoned Firefox after 20 years of use... I moved to a fork).


Among other changes

  • references to third-party databases have been further reduced, they can now be safely exported to a variable
  • various improvements to third-party database support
  • removal, addition and correction of various database applications

New Contributors

Full Changelog: 9.5...9.6

"AM" 9.5

21 Feb 02:10
0c9b0cc

Choose a tag to compare

Improved support and extensibility with third-party databases

Third-party database support has never been so extensive, free and secure!

Istantanea_2025-02-21_05-54-46 Istantanea_2025-02-21_02-26-30

Read to the end, you'll see some great things!


-i or install

It will now be possible to install multiple applications "per family" from supported external databases (in the example, SoarPKGS (ex Toolpacks):

simplescreenrecorder-2025-02-21_02.29.24.mp4

...a security check has also been added to check whether applications are actually available online

Istantanea_2025-02-20_04-15-33


flags and extensions

Each third-party database will have its own dedicated flag and list.

The flag is unique for each database, you cannot install applications from different databases if it is in use.

For BASH/ZSH/FISH completion, program names with and without extension are available

Istantanea_2025-02-21_02-37-10


-a or about

If applications are detected from third-party databases but not installed, it will notify that an extension is needed. On the contrary, for those installed the info will report the need for an extension to see the details. All details:

Istantanea_2025-02-21_03-49-04

The variants and their number will also be listed, as well as details on the installed binary.


-l or list

The usage of the flag or the extension is suggested in the description of the app in -l

Istantanea_2025-02-21_02-38-06 png


-q or query

Third-party flags have been removed from -q, but can be used as a keyword after the --all flag. A hint has also been added in case there are no search results.

Istantanea_2025-02-21_02-45-25

EXTENSIVENESS

If you thought that the existing databases were too ingrained, well... you were right.

This release has undergone a deep refactoring that reduces the addition of third-party databases... to just three lines.

Below are the existing ones (from APP-MANAGER):

#################################
#	APPBUNDLEHUB		
#################################
export appbundle_repo="https://github.com/xplshn/AppBundleHUB"
#export appbundle_readme="https://raw.githubusercontent.com/xplshn/dbin-metadata/master/misc/cmd/AM-support/AM.txt"
#[ -n "$appbundle_readme" ] && third_party_flags="$third_party_flags --appbundle"

#################################
#	TOOLPACKS/SOARPKGS
#################################
export toolpack_repo="https://github.com/pkgforge/soarpkgs (ex toolpacks)"
export toolpack_readme="https://raw.githubusercontent.com/ivan-hc/am-extras/main/soarpkgs-toolpacks/${ARCH}.md"
[ -n "$toolpack_readme" ] && third_party_flags="$third_party_flags --toolpack"

export toolpack_missing_file_msg="\nIt appears that the selected file is not available.\n\nThis happens due to pkgforge's mirror Issue.\nLearn more: https://docs.pkgforge.dev/repositories/bincache/cache\n\nAlternatively, install \"soar\" or \"dbin\" and use those.\n\n"

#################################
#	ALL THE ABOVE
#################################
third_party_lists="appbundle toolpack"

It is enough to set $yourflagname_repo, $yourflagname_readme and then add a flag in $third_party_flags

As you can see from the code and while I write, AppBundleHUB is currently down, as it is undergoing maintenance... it will be up as soon as the list is restored.

To ensure the security and up-to-dateness of the lists, they will be published at https://github.com/ivan-hc/am-extras

In the modules you will not find functions dedicated to Toolpacks or AppbundleHUB (for the latter only the checks for "AppBundle" as a packaging format are left, to have a dedicated installation script)... but you will find all the functions and references related to third-party flags and extensions concentrated in one place, and without ever mentioning the third-party database.

Example, option -h or help

Here's how easy it is to add a new flag or extension to AM, this is what will happen to AppBundleHUB when it's ready:

simplescreenrecorder-2025-02-21_03.52.25.mp4

To AppBundle users

Already installed apps will show up as coming from Toolpacks, due to the old identification method.

New installations will have their own flag and list.

The same will be true for all future third-party databases that may be added in the future.


Conclusions

With the renewed support for Toolpacks, the available applications have almost doubled, especially now that they are available in groups of families.

I invite you to also take a look at the following package managers, without whose developers, such a quantity of software would not be possible:

...I hope you like this release!

What's Changed

  • "AM" 9.5 - Rewrite of third-party databases support by @ivan-hc in #1358

Full Changelog: 9.4.4...9.5

"AM" 9.4.4

14 Feb 11:00
afc3d06

Choose a tag to compare

Hide installed apps

Do you have any installed applications that you would rather keep the version so much that you don't even want to list them in -f? Do you want to hide any installed applications from the reach of "AM"/"AppMan"?

This release brings with it two new options:

  • hide, to prevent your CLI from seeing, listing, updating and managing the selected apps
  • unhide, to reverse hide

In this video I will hide two system-wide installed apps and two locally installed apps

simplescreenrecorder-2025-02-14_09.14.17.mp4

This can also help if you have a lot of fixed version apps (in my case baobab-gtk3 and system-monitor-gtk3) and you want to limit updating them, calling github APIs unnecessarily.

There is already a lock option for this, yes, but if you don't need to list them, you can hide them now.

When you use the command

am hide $APP1 $APP2 $APP3

the remove script is renamed to remove.old, thus preventing the installed app from being identified as belonging to "AM"/"AppMan" and effectively making it a "system" or "independent" app.

You can however update it manually by running the related AM-updater script (if it exists) and remove it manually by running the remove.old script.

It has its uses, you may need to hide an application from view sometimes.


What's Changed

  • Improve Test random 💯 by @zen0bit in #1326 #1329 #1330
  • Remove workaround in nolibfusesince the appimagetool PR was merged by @Samueru-sama in #1335
  • Update management.am, option "nolibfuse", if the command "appimagetool" exists, don't download the Appimage again, by @ivan-hc in #1338
  • gittyup: Add version 1.4.0 by @FlawlessCasual17 in #1339
  • Update & rename gnome-system-monitor3 to system-monitor-gtk3 by @ivan-hc in #1346
  • "AM" 9.4.4 - Add options "hide" and "unhide" by @ivan-hc in #1347

New Contributors

  • @FlawlessCasual17 made their first contribution in #1339

Full Changelog: 9.4.3...9.4.4

"AM" 9.4.3

03 Feb 20:42
c9c3312

Choose a tag to compare

Fix TOR usage where it was prevented

This release allows the end user to verify if app updates from github.com were actually successful, given the API limitations.

During the update, a green message will remind you that you need to restart the TOR service

Istantanea_2025-02-03_21-06-02

...on classic GNU/Linux distros with systemd run sudo systemctl restart tor.service to fix the issue.


Use of torsocks with appimageupdatetool

Another issue has been fixed, regarding the coexistence between torsocks and appimageupdatetool. The configuration file for Torsocks will be copied locally and configured on the fly to be used during the process, before being removed.

For more details, see AppImageCommunity/AppImageUpdate#244


Among other changes

  • fixed some bugs in database.am module
  • improved speed of -l and -q options
  • option -a gained processing time
  • expanded text margins in -l, -q and -a
Istantanea_2025-02-03_21-32-29 Istantanea_2025-02-03_21-32-04

Website

Icons on pages now load "lazily", allowing for faster and more painless navigation.

To try it out https://portable-linux-apps.github.io/apps


What's Changed

Full Changelog: 9.4.2...9.4.3

"AM" 9.4.2

24 Jan 19:20
2476797

Choose a tag to compare

Add support for FISH-shell autocompletion

First major release of 2025, after exactly one month from the previous one.

As title says, BASH completion has been extended not only to ZSH, but also to FISH. Users of the latter will be able to benefit from it through the appropriate file automatically created in the ~/.config/fish directory.

See #1300 for more.


Among other changes

  • -f option, versions locked with the lock option will have a 🔒 next to the version number
  • added a -fi option to show only installed apps and not also those integrated with --launcher (already shown in the normal -f)
  • added an automated action system in github actions to keep in sync the AppImages lists with the apps lists and to check for problematic scripts, so the review is now weekly if not daily, to ensure the correct functioning of the scripts needed to install the applications. Thanks @zen0bit
  • securing third-party databases support, in case of any errors

Full Changelog: 9.4.1...9.4.2

"AM" 9.4.1

24 Dec 20:09
b6ab149

Choose a tag to compare

Customize/change the database by exporting variables

One thing I care a lot about is continuity, and as I have seen over the years, not all open source developers are able to maintain a project. This could happen to me in the future. I don't want it to be that way.

Because of this, I have made some essential variables "customizable":

it is enough to export the variables above and respect the destination file format (follow the URLs in parentheses) in case you decide to open a new community-driven database that can make up for the lack of support in this repository.


Motivation

I did this to not tie users to this database and to allow them to use AM and all its features if I, Ivan, am unable to intervene for any reason.

There are many discontinuous projects. Should this become one too, it will not be obsolete.

PS: consider this my Christmas present


What's Changed

Full Changelog: 9.4...9.4.1

"AM" 9.4

16 Dec 20:04
69c889a

Choose a tag to compare

Initial support for *BSD

This version of "AM" brings with it a refactoring that allows it to run on freeBSD and derivatives.

Istantanea_2024-12-16_17-34-23

Please note that at the moment, "AM" supports the installation of portable applications for GNU/Linux only.

On BSD-based systems, it is necessary to perform the necessary configurations to allow both binary programs and AppImages to be executed, by installing the appropriate Linux compatibility layout.

There are several guides on this subject, the main one is https://docs.freebsd.org/en/books/handbook/linuxemu/

A simplification of the above guide, oriented to the use of debootstrap is also available here. Thanks to it, I was able to run some test AppImages on GhostBSD

Istantanea_2024-12-16_18-37-37 Istantanea_2024-12-16_18-44-06 Istantanea_2024-12-16_18-38-22
google-chrome AppImage brave AppImage lxtask AppImage

Note that Chromium-based AppImages require the --no-sandbox flag.


All that glitters is not gold

Please note that "AM" is not responsible for the failure of programs, whether they are on Linux or BSD, and that all "AM" does is download and integrate/install programs into the system, taking them from the source.

In fact, this release allows you to use all aspects of "AM" on BSD, but the failure to run programs has nothing to do with "AM".

BSD systems require additional configuration to run programs written for Linux. In my experiments in virtual machines, I can't help but show failures. For example, running "Archimages" (Arch Linux containers inside Appimages) as in the screenshot below, with gimp and bottles

Istantanea_2024-12-16_18-50-20

It's just a matter of configuring the right settings, following the guides.


Toolpacks on BSD

Several programs from the Toolpacks database appear to be BSD-compatible, as they are static binaries. To see a list and install them, see the --toolpack flag reference (command am -h for more information).


Future

This release is just an introduction to BSD support. Experts are encouraged to participate in improving this support on "AM".

There are two possible ways:

  • add a directory to this database that contains only installation scripts for BSD-compatible programs. You can also select those that work in tests. At the moment, "AM" only has installation scripts for x86_64, aarch64 and i686 architectures on Linux. It would be nice to add another one that works for BSD https://github.com/ivan-hc/AM/tree/main/programs
  • add a script that can automate the creation of a compatibility layout for Linux, based on the official guides, so as to allow, in a single command, the addition or removal of this support, a guide is available here https://github.com/ivan-hc/AM/blob/main/docs/guides-and-tutorials/bsd.md

Other changes

  • less is now an "optional" dependency (but suggested in -h and -l) by @Samueru-sama
  • fixed several bugs related to versioning
  • removed other basic dependencies, such as strings by @Samueru-sama
  • improved table generation speed in -f by @Samueru-sama
  • better versioning for self-updating applications, through permission levels
  • ported a good part of the code to POSIX by @Samueru-sama
  • new functions to use and switch between sed on a per-implementation basis (default is GNU) by @Samueru-sama

What's Changed

Full Changelog: 9.3...9.4