Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)FR
Posts
12
Comments
81
Joined
2 yr. ago

  • I can’t really use NTFS because Linux can’t write to it.

    This is not correct.

    For example, there is the driver ntfs-3g. This allows read and write access to NTFS partitions. The disadvantage is that it uses FUSE and is therefore slower in some cases.

    Since kernel 5.15, read and write access is also offered by the drivers provided by Paragon (ntfs3).

    https://wiki.archlinux.org/title/NTFS

    Because I personally use btrfs as file system for Linux, I use WinBtrfs under Windows.

    ExtFAT would also be a possibility. However, one should be aware that the file system was originally designed only for flash memory storage such as USB sticks.

  • For me, this is the main reason why I use micro. And because I don't like the handling of vim. Funnily enough, I've been playing around with Helix for a while now and I really like the editor, even though it's a modal editor, just like vim. Maybe because of the selection → action model. The question is, do I like Helix better than micro? I still have to answer that question for myself at some point.

  • Unfortunately, as always, the best solution does not exist. Everything has its advantages and disadvantages.

    For example, I like Chezmoi for managing configuration files. But the tool is only for the configuration files in /home.

    Ansible, on the other hand, can be used for / and /home. But already the basic functions are more complex which requires some training time.

  • according to StatCounter's data

    Our tracking code is installed on more than 1.5 million sites globally.

    Source: https://gs.statcounter.com/faq#methodology

    Such statistics are always to be taken with a grain of salt.

    There are more than 1.5 billion websites worldwide. Statcounter therefore covers only a small fraction of them. So chances are good that you as a Linux user do not use any of these 1.5 million websites that Statcounter uses to create their statistics.

    Furthermore, I suspect that many Linux users use tools like uBlock Origin or Pi-Hole, so that the things that are used to track users are blocked.

    Apart from that, I have several Linux installations with which I never access a website. Sometimes they have no direct connection to the Internet. Thus, they are also not recorded.

    But now to the most important. 3 percent of what? Percentage numbers don't tell anything if you don't know the number of users behind them. Let's assume that there were 2.8 percent Linux users in May. In June, only 2.6 percent. Nevertheless, it is possible that there were more actual users in June if the total number of all users increased accordingly.

  • If I understood it right, the author of the proposal even writes that that opt-in is useless, because nobody is going to enable it, which kinda makes it sound like they know that they’re trying to push something on users that they don’t want.

    The question is, why don't users want it? I have already had a few discussions on the subject of telemetry and telemetry has almost always been portrayed as evil. Even when, for example, the transmission is encrypted and only the most necessary data is transmitted in such a way that no conclusion can be drawn about a specific user.

    Is opt-out therefore a good solution? Not in my opinion. But I can understand the developers who use opt-out, for the reasons I mentioned. Because yes, telemetry can help to improve a program.

  • You can follow the submissions via an RSS feed.

    For example, if you use the link Https://lemm.ee/feeds/u/Corr.xml?sort=New, all your previous posts will be displayed.

    Instead of lemm.ee you need to specify the instance where the user in question is registered. And instead of Corr you have to enter the username. For example https://discuss.tchncs.de/feeds/u/fryboyter.xml?sort=New. That would be in this case my contributions.

  • As far as AUR is concerned, one should be fair. The things that are offered in AUR can be problematic in general. No matter if you use vanilla Arch or a distribution based on Arch. Because not everyone who offers something in the AUR cares about updates in a timely manner or at all.

    There is definitely a reason why https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/ exists. Just as there is a reason why there is a general warning about the AUR (https://wiki.archlinux.org/title/Arch_User_Repository).

    With Manjaro, I rather see the problem that the team responsible for it apparently does not learn from its mistakes, so that, for example, the SSL certificate of the website has not been renewed several times (https://web.archive.org/web/20230706060943/https://manjarno.snorlax.sh/). That may not be a big problem in itself, but if even such little things go wrong, then I personally cannot trust an entire distribution.

  • I have several virtual machines here with Arch that I often don't use for months. And when I do use them, I proceed as I do with every update. So before an update, I check if something has been published at https://archlinux.org/news/ that affects the installation in question. This is done automatically with the help of the tool informant. If something has been published that affects my installations, I take that into account. Otherwise I run pacman -Syu as usual. And that's it.

  • To go x86_64-only was a mistake for Arch.

    • The development team of Arch is comparatively small compared to other distributions.
    • To support platforms other than x86_64 one should have access to appropriate hardware to test the packages. I for one have not had i686 hardware for a while. This is probably true for many other users as well.

    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.

    Distros like Fedora or Debian, or openSUSE have universal building systems and infrastructure for building packages for different architectures.

    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.).

    Arch just creates unnecessary fragmentation for the GNU/Linux landscape: software need to be packaged for the distro and for the same time PKGBUILDs cannot be reused in general for anything to go full Arch Linux.

    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.

  • 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. :-)