https://github.com/rustdesk/rustdesk/wiki/Run-flatpak
https://github.com/rustdesk/rustdesk/releases/tag/1.2.0 -> rustdesk-1.2.0-x86_64.flatpak
I am not sure myself, so the following may be wrong.
In my understanding, the rewrite refers to the RustDesk desktop whose interface appears to have been created with Sciter, which was replaced by Flutter.
Same for arch. Don’t use it for a server. It deleted php 7 and upgraded to 8 which broke my WordPress website.
For example, I use several Raspberry Pi as servers and have Arch installed on all of them. And it simply works. I therefore do not consider such sweeping statements that Arch cannot be used for servers to be correct.
It depends on the individual use case.
For example, was Wordpress already compatible with PHP 8 at the time? Because I also use a webspace at uberspace.de. CentOS is used there and not Arch. Some time ago, I wanted to install Hedgedoc there, but it didn't work because node.js 20 was standard in my case, but Hedgedoc only supported version 18 or even 16 at the time. So it would only have helped to define a lower version as the default. This would have meant that another tool that required a higher version would no longer have worked.
That comes with disadvantages in that reading the PKGBUILD is inherently unsafe, and it was the cause of many concerns back in the days with tools like yaourt, which pretty much just blindly sourced it to get the variables out, which means immediate code execution just loading it from the AUR.
However, the AUR helpers in question, which are not official tools, were to blame. Some developers of these tools could not or did not want to solve the problem. According to https://wiki.archlinux.org/title/AUR_helpers, almost no AUR helper sources the files automatically nowadays.
I've either never dealt with RPM specs before or it's been so long that I can't remember. Therefore, I can only make a statement about PKBUILD files.
Such files are relatively easy to create and read, as they are basically shell scripts. Thus, if you use AUR, for example, you can easily check them before an installation or an update to see whether the creator has done everything correctly or whether he has changed the file with malicious intent.
For example, a typical PKBUILD file looks like this.
# Maintainer: Alad Wenter <https://github.com/AladW>
# Co-Maintainer: Cedric Girard <cgirard [dot] archlinux [at] valinor [dot] fr>
pkgname=aurutils
pkgver=17.2
pkgrel=1
pkgdesc='helper tools for the arch user repository'
url='https://github.com/AladW/aurutils'
arch=('any')
license=('custom:ISC')
source=("$pkgname-$pkgver.tar.gz::$url/archive/refs/tags/$pkgver.tar.gz")
changelog=aurutils.changelog
install=aurutils.install
sha256sums=('65efed873facf06ec73b012d94c110f35e45d3057eda2bc85983a3c8c6ce2c81')
depends=('git' 'pacutils' 'curl' 'perl' 'perl-json-xs' 'bash')
optdepends=('bash-completion: bash completion'
'zsh: zsh completion'
'devtools: aur-chroot'
'vifm: default pager'
'ninja: aur-sync ninja support'
'bat: view-delta example script'
'git-delta: view-delta example script'
'python-srcinfo: sync-rebuild example script')
build() {
cd "$pkgname-$pkgver"
make AURUTILS_VERSION="$pkgver"
}
package() {
cd "$pkgname-$pkgver"
make PREFIX=/usr ETCDIR=/etc DESTDIR="$pkgdir" install
}
In general, I would like to note that a rolling distribution does not necessarily always have to offer the latest packages as soon as possible. Rolling primarily only means that updates are offered gradually via the same package sources.
But this is just a general remark. :-)
https://github.com/martinrotter/rssguard
An important function of RSS Guard for me is the extensive filter function (https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#fltr).
Why should I use wezterm or alacritty and not Terminator?
The answer to your question and mine should be pretty much the same. Because everyone has different preferences and requirements.
Issues on Github consist not only of bug reports, for example, but also of feature requests. If, for example, you only display issues with the label "Enhancement" at https://github.com/Eugeny/tabby, there are already over 300 of them. In addition, I have made the experience that often reported issues arise from Layer 8 problems. And that some issues, unfortunately, are not closed when they are outdated. Generally speaking and not related to this terminal emulator.
By the way, according to https://github.com/vim/vim/issues, the editor vim has over 1,300 issues. Also in this case, not all of them are actual problems that need to be fixed.
Yes, and PKGBUILD files with bad intentions have been published there in the past (https://lists.archlinux.org/pipermail/aur-general/2018-July/034151.html).
But both Manjaro (https://wiki.manjaro.org/index.php/Arch_User_Repository) and vanilla Arch (https://wiki.archlinux.org/title/Arch_User_Repository) point out the possible dangers clearly enough in my opinion. Apart from that, it is definitely easier for users to check for example the PKBUILD files in the AUR than ready-made packages in a PPA for Ubuntu.
Therefore, from my point of view, they have done everything right. Just like other, non-Arch based distributions, which are also now only offered for x86_64.
Right. And all have more collaborators and more money. For example, according to https://nm.debian.org/members/, nearly 1000 people participate in Debian.
Arch's core development team, on the other hand, consists of just 28 people without being paid for it. In addition, there are some "trusted users" (a bit more than 60 iirc) and some people responsible for support (wiki and IRC moderators etc.).
Fragementation has always existed. Before Arch I had used Mandrake / Mandriva. With it I often could not use Redhat packages although they technically used the same format (RPM).
By the way, in the case of Arch or distributions based on it, you can in many cases use PKBUILD files for other platforms as well. Often it is sufficient to modify the line
arch=('x86_64')accordingly. I have done this in some cases where a software for Alarm (Arch Linux ARM) was not officially offered. I simply took the PKBGUILD file from Arch Linux and changed it accordingly. And yes, this does not always work.