kixik

yes, but it's mostly for open source apks, the beauty of apkupdater is that it allows installing/upgrading some apks from apkpure and other sources (it was true for apkmirror directing to the right place to download and install from the browser, but on apkmirror most apks now days don't install/upgrade unless you install their own apkmirror app), avoiding google play and avoiding aurora store (which besides the issues with anonymous connections, it gets upgrades pretty late for some reason). That's something I don't see an alternative for. Yes, upkupdater also allowed to install/upgrade from github/gitlab/... but its major purpose to me, was to be able to install/upgrade some non open source stuff without the need to connect to google play, and using recognized and reputable mirrors like apkpure and when it was feasible apkmirror. For FLOSS I use f-droid (official repo, plus non official like "izzyondroid" and others). Unfortunately there are a few apps I'm forced to use, which are not open source...

First of all, it's been a while since it's no longer his code, and the contributions from whatever amount of people must be respected. That was used some time back as justification to never moving to GPL3 or latest.

Second, there's now a huge foundation behind it. Although he has gating approval for whatever he wants, the money coming from big enterprises would cease. Remember now MS already claims it loves linux.

Third, although it's pretty linked to second, the project is not an independent community project anymore. Even risc-v people took care not to create a so nation specific project (even though its origins are totally linked to the academy from a particular one), that it doesn't matter which country imposes sanctions to others, no country can prevent another from using its open ISA to build their own stuff. Linux, and its linux foundation failed on this, and as it's pretty dependent on the big tech and enterprise, now it has no options to be compliant. Which you could see recently from banning developers and the legal reasons involved (well done, as risc-v, that would have had minimal impact, or better yet, if a community project not linked to any country, then that would have gone differently).

All in all, linux's success has lead it to be a non community driven, non independent project, and I would guess the enterprise and big tech, which is pretty reliant on linux now a days, wouldn't let linux go away unless they already have an alternative.

Though never say never right? But my take on this is both, no single person owns linux, so no single person can take it away, and there's too much reliance on it from big tech and enterprises as to let such important project, and key on their software supply chain (years back thinking on software supply chain was in no one's mind) or so they say.

If ever getting to administrate non systemd boxes, and in need to deal with the system logging mechanism, then syslog-ng comes close to the most probable mechanism use. And no, non systemd gnu+linux distributions are not legacy, there are quite a few out there, just not the major or mainstream ones, like Artix, Void, Guix, and several others, not to count non gnu+linux OSs like BSDs...

I don't get this comment. Again, the virtio-win is an ISO that's easily mounted on a qemu (whether libvirt environment or not, which is not required, it just helps making the qemu configuration easier), which comes with several virtualized drivers that accelerate the windows experience quite a bit.

Changing the storage driver is complex on plain qemu (I don't think it's easier through libvirt just because the heck of it, the issue is the windows guest), first one need to run qemu with a dummy storage driver using virtualized driver, so that windows detects it. On the guest one needs to install the driver for the discovered storage from the ISO, then reboot and the dummy disk can go away and windows will find a driver for the main disk). Other drivers like the ethernet one, graphics cards, memory baloon, and other stuff need to change the corresponding driver manually, but no need for immediate reboots, but for sure several reboots are expecting while changing the windows drivers.

I no longer use a VM for windows, thankfully, but here it's a command line meant not to use a GUI qemu front end, but rather a Spice backend (requires virtualized special serial driver and special graphics driver):

qemu-system-x86_64                                                                                                                                                                           \
        -name win-10                                                                                                                                                                     \
        -enable-kvm                                                                                                                                                                          \
        -machine type=q35,accel=kvm                                                                                                                                                          \
        -cpu host,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time                                                                                                                            \
        -smp cores=1,threads=2,sockets=1                                                                                                                                                     \
        -m 4G                                                                                                                                                                                \
        -device intel-iommu                                                                                                                                                                  \
        -device virtio-balloon                                                                                                                                                               \
        -drive file=/home/vasqueja/.qemu/imgs/win10-coe.qcow2,index=0,media=disk,if=virtio,aio=native,cache.direct=on,l2-cache-size=10M         \
        -drive file=/usr/share/virtio/virtio-win.iso,index=1,media=cdrom                                                                                                                     \
        -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,index=2,media=cdrom                                                                                                   \
        -device virtio-net-pci,netdev=net0                                                                                                                                                   \
                -netdev tap,id=net0,ifname=tap0,script=no,downscript=no,vhost=on                                                                                                             \
        -usb                                                                                                                                                                                 \
                -device usb-tablet,bus=usb-bus.0                                                                                                                                             \
        -display none                                                                                                                                                                        \
        -vga qxl                                                                                                                                                                             \
        -device virtio-serial-pci                                                                                                                                                            \
                -chardev spicevmc,id=spice0,name=vdagent                                                                                                                                     \
                        -device virtserialport,chardev=spice0,name=com.redhat.spice.0                                                                                                        \
                        -spice unix,addr=/tmp/win10_spice.socket,disable-ticketing                                                                                                           \
                -chardev socket,path=/tmp/win10_qga.socket,server,nowait,id=qga0                                                                                                             \
                        -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0                                                                                                      \
        -device intel-hda -device hda-duplex                                                                                                \
        -rtc base=localtime                                                                                                                                                                  \
        -monitor stdio                                                                                                                                                                       \
        -k es                                                                                                                                                                                \
        -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...>                                                                                                                      \
        -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...>                                                                                                                      \
        -device usb-host,bus=usb-bus.<...>,vendorid=<...>,productid=<...>

Some investigation on your side is required if wanting to use spice (to add copy/paste cabalities on the guest, but perhaps that's not needed anymore with libvirt and some of the popular forntends from GTK/QT), and the QLX dirver needs to be chosen correctly since it depends on the windows version (there was one for windows 10, not sure if there's a 11 one).

Again, all this just to improve the windows guest experience. Some of this might have been made easier through libvirt, but the windows side of the drivers is a manual windows process, one driver at a time, and using virtualized storage is tricky on windows guests...

BTW I was setting a tap interface, with IP tables, because I found it to be the easier way to share my host VPN connection with the guest, without the need to establish a host and a guest VPN connection...

virtio-win allow for much better performance using virtualized drivers rather than plain emulation from qemu. Virt Manager doesn't offer windows guest paravirtualized drivers, that's on the guest side, and virtio-win ISO helps a lot with this.

Upgrades happen a different times it seems, depending on the phone, :( Yes, I notice exactly the same... I'm trying to ditch signal any ways, perhaps the right time. But the instructions someone share seem the appropriate ones.

Thanks !

I don't see that, neither I see a note on its github repo. The only thing I noticed is something I haven't paid attention before:

Currently, UnifiedPush is unavailable for linked devices.

Which is totally counter productive, and explains why even by setting unifiedPush through ntfy molly keeps draining battery, :(

The official F-Droid doesn't offer Molly, not even the so called FOSS by its author. And the Molly-FOSS repo from the author still offers Molly (Unified Push). Am I missing something from the "Molly-UP deprecation" referred? I'm not seeing such a thing.

There's no need to jump into conclusions when it's too early to tell.

If later, it so happens it gets removed, and you don't want use out of tree stuff, which is still possible through several means, including building your own linux (your own kernel), then you can back all contents of your partitions up, create new partitions with the FS of your preference (ext4, btrfs, whatever), and finally copying over the contents of that last backup. No need to stress out this early, :)

Arch and Arch based distros like Artix have linux-libre available from AUR if one doesn't have an issue with building from source. Also see my other comment about Guix, there's a non official repo with ucode and hardware firmware...

Not sure why you mentioned this. At least on Arc, or any distro based on it like Artix, the ucode per CPU is offered as a separate package:

% pacman -Ss ucode
system/amd-ucode 20241111.b5885ec5-1
    Microcode update image for AMD CPUs
world/intel-ucode 20241112-1 [installed]
    Microcode update files for Intel CPUs
world/iucode-tool 2.3.1-5
    Tool to manipulate Intel
galaxy/amd-ucode-xz 20230625.ee91452d-4
    Microcode update image for AMD CPUs
extra/intel-ucode 20241112-1 [installed]
    Microcode update files for Intel CPUs
extra/iucode-tool 2.3.1-5
    Tool to manipulate Intel

If your distro doesn't help with ucode packages, you can ultimately download it from intel/amd/whatever. And the same applies for the hardware firmware in general.

So it's true that some hardware won't properly work out of the box by using libre-linux, but nothing prevents you from getting the required firmware from other packages or sources. Granted that doesn't make things easier. And granted that might defeat the purpose of using linux-libre, but you might at least only add only strictly required binary blobs for your current hardware.

linux-libre is harder because if you want cpu ucode plus hardware firmware support in general so that you can make your bad citizen hardware work, you'll need to add it out of the linux package.

Someone mentioned Guix as a gnu + linux distribution was hard, and in general that's true, but not because of linux-libre since there's a non official Guix repository providing non libre/free cpu ucode plus hardware firmware, see:

https://gitlab.com/nonguix/nonguix

The complex part of Guix comes from it being a inmutable distribution based on the ideas from NixOS, though it's not a fork from Nix since it's even based on Guile rather than the Nix language, but their packages and configurations are quite different than any other distribution, the same as its inmutable system and I believe on both reproducibility is a thing...

But bottom line, for Guix you can even get packages to make linux-libre work with your hardware provided you find the corresponding firmware in the non official repo, and in general (not just Guix) as long as you find the firmware somewhere else (not in linux-libre) you would be OK, and depending on your distro that might be a really hard task.

I use Artix, and though I haven't explored it yet, I've been wondering how hard it'd be to install linux-libre, and get the strictly required firmware from the AUR, perhaps it's possible. The package is actually offered from AUR:

% aur search linux-libre
aur/linux-libre 6.11.9-1 (+37 0.35%)
    The Linux Libre kernel and modules
aur/linux-libre-docs 6.11.9-1 (+37 0.35%)
    Documentation for the Linux Libre kernel
aur/linux-libre-firmware 1.4-1 (+3 0.00%) (Orphaned)
    Firmware files for Linux-libre
aur/linux-libre-headers 6.11.9-1 (+37 0.35%)
    Headers and scripts for building modules for the Linux Libre kernel
aur/linux-librem5 6.6.57-1 (+0 0.00%)
    The Linux kernel for Purism Librem 5
aur/linux-librem5-docs 6.6.57-1 (+0 0.00%)
    The Linux kernel for Purism Librem 5 (documentation)

wow:

We use specifically crafted messages that trigger delivery receipts allowing any user to be pinged without their knowledge or consent

That makes think that 1st, perhaps it would be a good idea to avoid "return receipts" on any messenger, though that breaks ability to know if the destination has actually received, and if the destination has actually read the message.

Perhaps another thing, even though your messenger doesn't identify users with phone numbers at all, still block the messenger to have access to your contact list. Not sure if this affects, for example if a xmpp client has access to a broader contact list, if it can only relate to xmpp addresses it wouldn't pay attention to phone numbers, but I can't really tell.

And of course, don't use any messenger which tights users with phone numbers, no matter if to share among contacts now usernames are used instead of the phone number, when the phone number is still the way to identify the user.