Skip to main content

[ninjaos] repo update. metadata-cleaner now has 1.x fork

Hash: SHA256

In this latest version bump of the [ninjaos] repo, we've forked the
metadata-cleaner package off into metadata-cleaner1 that follows the 1.x branch
that depends on gtk3. The mainline package following 2.x that depends on gtk4
will continue to be available as well.

This is pending this issue:

where upstream gtk4 doesn't handle drag and drop correctly anymore. While this
is planning on being fixed, in the meantime, we are just going to support
version 1.x until this feature lands

Also of note, log4j is in fact in the repo, and this latest update fixes
the vulerable version.


New GPG "Head Key"

Hash: SHA256

We are adding a new GPG key as part of a security strategy. We now have a "head
key" that functions as a CA. The sole purpose of this key is to sign other keys.
All Ninja OS keys will be signed with this key, and nothing else will be. Thus
it will allow creation of new ninjaos keys that can be verified only by looking
for this signature on the key. This key is kept offline, in an arrangement that
it will not be loaded in day to day operations.

Bullet points

* This key is used to prove other keys belong to Ninja OS
* All Ninja OS keys will be signed by this key, do not trust anything not
* It will do nothing else
* It is kept offline

The GPG page is updated with both headkey, and signed versions of existing keys


AMD ROCM now supported in [ninjaos]

Hash: SHA256

As of today, we are chosing to support the Raedeon Open Compute Module. I am
uncertain why this is unsupported upstream in ArchLinux, but I suspect quality
might have something to do with it. However, after some basic testing, it
appears to compile and run. What this means is there is an entire Free Open
Source GPGPU solution that includes an OpenCL solution, and allows you to use
AMDGPU compatible graphics cards for general compute purposes.

Also supported are the llvm-amdgpu and rocm-cmake for compiling things against
ROCm, as well as the OpenCL runtime.


Butt replaces Darksnow in [ninjaos] repo

Hash: SHA256

After a long time, darkice frontend "darksnow" is being replaced with the
package "butt" in the [ninjaos] Arch Linux repository. "darksnow" is being
removed entirely, and if you have this package installed it is recommended to

pacman -Rs darksnow

pacman -Syu butt

Butt stands for "Broadcast Using This Tool", has support for icecast and
shoutcast, and pulse audio. The GUI itself is superior and still maintained, and
is all around supperior to Darksnow. The "darkice" package will linger in the
[ninjaos] repository for now.


CHIRP, Ham Programming Tool Being Dropped From [ninjaos]

Hash: SHA256

The chirp-daily package is getting yeeted off [ninjaos] repository. Unforunately
there is nothing to replace it with, and this is unfortunate, as it is a rather
useful piece of software for sync'ing baofeng and other small portable ham
radios to the computer, editing settings and storing settings/frequencies on the
computer for later use.

CHIRP is written in python2, which as you know was finally EOL'd back in January
2020. The announcement to EOL it was made in 2010, and its original EOL date of
January 2015 was pushed back 5 years to give programmers time to port. Python3
was released originally in 2006. It is now 2021, 6 years after the original EOL
date for python, and a full 11 years after the announcement was made.

As such, upstream Arch has been removing unused python2 dependencies and slowly
depreciating removing python2 support. We have been actively seeking
replacements for all python2 software in use with the [ninjaos] repo and by
Ninja OS itself. Our policy being: If its not essential, it gets removed.

The final straw for CHIRP was that its two py2 dependencies python2-lxml, and
python2-pyserial have been dropped by upstream Arch Linux. to maintain them,
we'd have to pull an increasing amount of python2 packages previously been
purged, and pull in more packages we'd need to support.

When CHIRP gets ported to python3 it will be added back. We apologize for the


Kernel Update - 5.10.x

Hash: SHA256

After a lot of thinking, We've come to the conclusion that having aufs as a
seperate package gained absolutely nothing, so we merged it into the main 
kernel package. Configuration of this module is now in our kernel config. We
feel that since aufs will ALWAYS be in use with Ninja OS, this will make testing
development, and maintenance easier as there is now one less package, especially
one that needs to be recompiled every kernel update anyway. 

Also in this kernel, we discovered there is a Kconfig option for XATTRs, or
extended attributes if underlying filesystems support them. both squashfs and
tmpfs do, and future versions of Ninja OS should be able to use POSIX
capablities for networking tools like ordinary OSes.

New version will hit [ninjaos-kernel] shortly. After upgrade you should pacman
- -Rs aufs, as this is just the kernel object for
. PKGBUILD will be kept
around in git for a short time for posterity.

Version is also now centered around 5.10, and will continue to be adjusted
against newer longterm kernels. As always this the -ninja kernel is lts, with
- -hardened, and aufs patches, and kernel interrupt timer set at 1000hz


MAT1 is being retired from the Arch Repo

Hash: SHA256

MAT(Metadata Anonymization Tool) Version 1 is finally being retired from the
[ninjaos] Arch Linux repository along with its remaining python2 depedencies.
This program was maintained FAR longer than it really should have been, but
was kept in production because there was NO *suitible replacement for the GUI.
Suitable? Yes, its amazing that some people actually consider usability a show
stopping feature on GNU Plus Linux, but I am one of them. The workflow of MAT1
was very fast. Drag, Drop, Action button, and then click the X. bam. Version 2
released as a fork MAT2, was CLI only as their favorite python widgets had no
py3 fork. For whatever reason, this was not deemed essential, and replaced by
a KDE dolphin shortcut, because people actually use KDE or Dolphin.

Now supported in [ninjaos], and will be in future releases is the package
"metadata-cleaner", a 3rd party frontend for MAT2 written in python3 with gtk3
It is recommended anyone using this repo on an Arch system switch to this new
package. It supports most of the features of MAT with some new ones, and is
rather usable.

As per policy, Ninja OS will be sunsetting python2 as soon as possibe. All
packages that depend on python2 that aren't immediately nesseccary will be
dropped from the [ninjaos] repo. All upstream(as in Arch Linux) packages that
depend on python2 that aren't strictly vital will be uninstalled. Search will
begin for replacement applications that use python2 and if they aren't ported,
will be replaced with modern programs of similar function.


Focus on streaming packages

Hash: SHA256

Since the Beginning, we understood the value of media tools on the desktop.
We strive our best to have a relatively "complete" as set of tools for viewing
and editing media, even if we do prefer lightweight tools over the heavyweight
large project tools. For Audio, Video, and Still Pictures, we present tools
to both view and edit as many formats as reasonably possibly under linux.

To this end, today we re-shuffle some of our installed media packages. Up until
now, darkice and darksnow where explicitly supported for streaming to icecast
or shoutcast servers, while idjc was supported in the repo. While this might
have made sense in 2010 terms, its not only anarchronistic, but it reflects a 
reality that never truely existed: the popularity of icecast/shoutcast servers.

Its also jarring as darkice/snow doesn't have complete Pulse Audio support and
is still based largely around ALSA/OSS with pulse as an afterthought.

It is video, not audio streaming that is central to culture now. Darksnow and
Darkice will continue to be supported in the repo, but are no longer default
installs. OBS studio is now a thing we are looking at as a secondary target,
and is being considered for default install. StreamFX and Websocket plugins
are now in the repo.


Cloud, VM, Direction

When we started with what would ultimately become Ninja OS in early 2010, Live OSs where the latest hotness. Insperation came from previous generations of Live CD distributions. Mostly early versions of TAILs that left users wanting as well as AnonymOS, and other live Desktop OSes generally that got burned to Optical disks such as CD and DVD. Initially, we did in fact provide an ISO9660 image for use with what is now legacy technology.

In the modern world, the Live OS has lost its lustre as well. Increasingly people rely on virtual machines, and even distributions like Qubes which is a management interface for virtual machines. The Live USB stick is not completely worthless, and it will be kept.

As a concept, Ninja OS will move forward as a family of operating systems, and tooling. They will all use the same Arch install base and similar and/or complementory packages(such as client and server).

Conceptualized Components:

  • [ninjaos] - Arch Linux Repo
  • Ninja LiveUSB
  • Ninja VM Desktop
  • Ninja remote VDI
  • Ninja Cloud Server Template

i686 support being dropped

Its a long time comming, but we are discontinuing the last of i686 support, effectively immediately. i686 has been discontinued from upstream Arch Linux for some time, and we have been following the Archlinux32 project. The last two releases did not see an i686 release as the quality would be signifigantly less and some major packages like firefox-esr do not build at all. A direct port is no longer possible. a proper fork would require a lot of effort, for very little gain.

In addition there are errors like Archlinx32 not fully repackaging their perl packages for new versions, tripping errors. Many upstream repos and projects do NOT test for 32 bit x86 on linux anymore.

More and more PKGBUILDs start to fail.

Today, we hit OOM errors attempting to build packages, even with enough swap space installed, and the memory limit of the arch kernel with 4GB of ram is not enough to maintain this repo. To rememedy this, we would need to maintain a seperate kernel with PAE enabled, just for the build environment. While configuring a kernel is trivial, maintaining one is not. Especially when you maintain a seperate kernel for production.

All for less and less people actually using this obsolete archecture. We feel that 64-bit PC penetration is sufficient to make the change.

In the future, if Archlinux32 improves and we are able to make a full compile, we MIGHT, repeat MIGHT release a pentium4 fork. Pentium4 has the added benefit of SSE2 instructions, that might make this feasible to run on more modern 32-bit machines.