I still haven't found a calculator that works like good old Kcalc from KDE 3.5 (yes I know there is TDE which probably has preserved it):

in Kcalc if I want to calculate the result of deducting 20% of a certain amount (for example 50) I type:

50

-

20

%

and I get 40, while in Galculator such a basic and frequently used calculation doesn't work which is a shame because galculator otherwise seems quite decent and lightweight without loads of dependencies on gnome or kde stuff.

I was about to write that I agree with steve_v that anubis makes git.devuan.org a torture to use as in the past weeks every time I tried to access it I had anubis running literally for 5 minutes or so before it granted me access, but I just tried again and I got past anubis in less than 1 second, not sure if it was just a fluke or if something has changed so that it will always be that quick.

So at the moment I reserve judgment.

That said, with regards to the DDOS by dodgy AI scrapers, I have that problem too on my websites and I solved it with IP address block lists implemented with ipset using the kernel firewall of linux. I don't block single IPs I block whole /24, /16 or even /12 network ranges of many hosting/cloud providers, as I found that these attacks predominantly come from very specific cheap/dodgy hosting/cloud providers, almost never from end customer (DSL/fiber/mobile) IP addresses.

If the admins of git.devuan.org are interested in my blocklist I can provide it, but only privately as sharing it publicly could induce the AI scrapers to adapt their strategies.

Well doesn't the iOS browser identify as Safari too? (I have no idea, I don't use Apple stuff)
It makes sense that Chrome and Safari were steadily growing in the last 10-15 years since in the last 10-15 years smartphones (therefore iOS and Android) have had phenomenal growth while PCs not so much.

@greenjeans since you already seem to have a sourceforge account why not just put the source code tarball on sourceforge?
There is no need for fancy version control for people to download your code and try it out.
And even if somebody wants to contribute patches this can be done the old fashioned way by sending you a patch via email.

@hunter0one during my researches about debian packaging I recently came across the following tool which could make life easier for those of us here who have RPM packaging experience (I have done some packaging for Mandriva, Mageia and Centos 6 in the past) and would like to package for Devuan:

https://github.com/macq/spec2deb

I have yet to find the time to try it out, but if it works as described it would allow to take a RPM spec file from which it generates automatically the various debian style packaging files. I guess the generated files will likely need further tweaking (for example the names of the dependencies) but it should still make the work easier.

I agree with @JWM-Kit, I find the RPM spec file format more logical and clearer structured and therefore easier to read (and write) than the collection of multiple Debian packaging configuration files.
The Arch pkgbuild file format is almost as good as the RPM spec file format, the only thing I really don't like about the Arch pkgbuild file format is that  it lacks a Changelog (for me this is a major negative point as sometimes I would like to be able to check what changed between package updates).

The RPM spec file format is one of the few really good things that Redhat has contributed to the Linux world (unlike pulseaudio, systemd, gnome3 and wayland).

BTW, using the RPM package format does not mean not being able to use the apt package management tools, in fact there is at least one Linux distro (PCLinuxOS) that uses RPM packages but uses apt and synaptic as their package manager.

Ok this is what I did to build the package (after reading the instructions from Igor and on the debian site):

mkdir gtk3-nocsd
cd gtk3-nocsd
dget --extract --allow-unauthenticated  https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/gtk3-nocsd/3-1ubuntu3/gtk3-nocsd_3-1ubuntu3.dsc
sudo apt build-dep gtk3-nocsd
sudo apt install markdown
cd gtk3-nocsd-3
dpkg-buildpackage --build=binary --no-sign
cd ..

these are the binary packages that got created:

ls -la *.deb
-rw-r--r-- 1 user user 47416 Jul  1 01:16 gtk3-nocsd_3-1ubuntu3_all.deb
-rw-r--r-- 1 user user 56524 Jul  1 01:16 libgtk3-nocsd0-dbgsym_3-1ubuntu3_amd64.deb
-rw-r--r-- 1 user user 16232 Jul  1 01:16 libgtk3-nocsd0_3-1ubuntu3_amd64.deb

To replace the standard Devuan packages with the freshly built ones I ran:

sudo apt remove gtk3-nocsd libgtk3-nocsd0
sudo dpkg -i gtk3-nocsd_3-1ubuntu3_all.deb libgtk3-nocsd0_3-1ubuntu3_amd64.deb

This how Ghex (a gtk4 app) looks like with the standard Devuan gtk3-nocsd packages:
http://pkgrepo.linuxtech.net/files/Ghex-original.png

And this is how it looks like with the packages rebuilt from Ubuntu sources:
http://pkgrepo.linuxtech.net/files/Ghex … -nocsd.png

Unfortunately the result is not what I hoped for, the Ubuntu sourced gtk3-nocsd packages simply remove the CSD (i.e. the program icon on the left and the three windowbar icons on the right) but the SSD doesn't get added, Does anyone know what needs to be done to add the SSD?

BTW, is there no way to attach images to a post on this forum?

Ok, I will try to build the Ubuntu package for Devuan Excalibur and report my findings but I will first have to figure out how to do this so it might take some time, as I'm a complete beginner with regards to building packages on Debian/Devuan (my experience of the last 30 years with Linux has been almost exclusively with various RPM based distros and more recently some Arch based distros).

That article seems like a collection of all the usual buzzwords and expressions a certain political fringe group likes to throw around when they are throwing a tantrum...

It makes me sad to see how immature and brainwashed some people are.

I thought I would add my question here as it's the same topic:
what are Devuans plans with regards to the minimum required x86-64 microarchitecture level? https://en.wikipedia.org/wiki/X86-64#Mi … ure_levels
I hope Devuan is not going to follow IBM/Rehat which introduced the x86-64-v2 requirement for RHEL8 and more recently the x86-64-v3 requirement for RHEL10.
AFAIK Suse has introduced similar requirements and Ubuntu is planning to do the same.

I still have multiple systems based on AMD Phenom II X4 and X6 processors (and one with an Intel Core2Quad cpu) which are all x86-64-v1 but are still perfectly usable (the are equipped with 8 GB and one with 16 GB of ECC RAM) so I hope that by migrating them to Devuan I can still continue using them for many years (not just with Excalibur but also after that).