

I guess it is like bicycling: there is a price to pay in blood 😉 My suggestion: in Romania, take a few hours of driving lessons with a professional teacher who can explain everything to you.
I guess it is like bicycling: there is a price to pay in blood 😉 My suggestion: in Romania, take a few hours of driving lessons with a professional teacher who can explain everything to you.
If you do not trust Tailscale as a company, here is an open source re-implementation of the server called headscale. Some/all clients are open source as well. So, you can review all components yourself or pay for a professional third-party review. Otherwise, if you take a binary blob from any origin, including Tailscale, and have it run with privileges on your server, there are few limits on what this blob can do. Yes, backdoors are technically possible, but probably bad for Tailscale’s business if that ever came to light.
My setup is smaller, but when my venerable old router died about a year ago, I acquired an Asus TUF-AX3000_V2 where I installed FreshTomato. One can login via SSH and dump all settings for backup. Likewise, individual or all settings can be done on the command line instead of the GUI. I have a script on my computer that reads CSV files with MAC addresses and more to apply changes in an automated way.
KDE Connect has been mentioned before. You can supplement this and other tools by using a VPN so that both endpoints can see each other even if the underlying network does not allow this. My preferred solutions are Tailscale (managed, cloud-based) or Headscale (for self-hosting).
Yes, XMPP with proper TLS on the server side and Conversations or one of its forks (preferably fetched from F-Droid) using OMEMO encryption should be good enough. If you are brave or paranoid, give Tox a try: https://tox.chat/
Maybe the first question is what your budget is, both regarding money and time. For example, you could buy a pre-configured NAS from Synology or QNAP, which requires less technical skills but more money, or a home-made solution reusing used components (but fresh disks for reliability). Depending on your electricity costs, you may want to choose a low-power solution or something which you power off when not used. For storage, maybe a three-disk RAID5 is a good compromise. For backups, plain S3 cloud storage encrypted via restic is a good idea.
Well, you have Finland in the north-east, Ireland in the north-west, and every land border faces a Euro-zone country. Few other countries can claim the latter.
If at all, you want to use Gentoo’s ebuild system, which can be seen as some kind of superset of PKGBUILDs. I guess one could write a Python script that “dumbs down” ebuild scripts to PKGBUILDs for simple packages (excluding complex stuff like kernel, KDE, …). The main challenge, as pointed to before, would be maintaining a table mapping package names between distributions in order to get the dependencies right.
The “C” in the progress bar is alternating between “c” and “C” to give the impression of munching.
There is some information missing in the problem description. For example, if you close the lid, does the computer suspend/sleep/hibernate? It may be that when the computer sleeps something “breaks” or it may be that the act of physically closing/opening the lid has an effect (e.g. because the WiFi antenna is embedded in the display frame).
Some time ago I had a similar problem with Tailscale and sleeping. When Tailscale initializes itself (at boot), it has to interact with another service to communicate which DNS servers have become available (e.g. 100.100.100.100). Several implementations of such services exist (resolvconf, openresolv), in my case systemd-resolved. During normal operation, resolvectl status
(if using systemd-resolved) shows which DNS servers and which search domains are configured for each network interface such as tailscale0
. Now, there is a bug (or feature) that systemd-resolved “forgets” the DNS configuration it got from Tailscale when the computer is put to sleep. So, when the computer wakes up, name resolution via Tailscale no longer works, giving you the impression that Tailscale itself is not working, although Tailscale’s low-level functions are still operational.
My “solution” was to write a small script that gets executed when the computer wakes up which sets again DNS server and search domain for network device tailscale0
.
ArchLinux’s pacman with ILoveCandy option enabled.
Many projects accept donations, for example for server costs or travel expenses (conferences, meetings). You can setup recurring monthly transfers to projects whose software you use most often. Examples are the Free Software Foundation for various GNU tools or the KDE project.
There was choice, but not enough volunteers: https://www.debian.org/ports/kfreebsd-gnu/
Most comments comments mention Brother, but for me, Oki is working like a charm. Using a B431dn (b/w, duplex) and a C531dn (color, duplex) with PPD files from OpenPrinting. Older models though, not sure if Oki dropped quality in favour of DRM since.
Rules of thumb:
I had a very similar problem as @Toralv@lemmy.world a few weeks ago. I repurposed a small, fanless x86 desktop computer as my new router. It has only one RJ45 port and due to its small size cannot be extended with a proper network card. As it has an unused USB3 port, I acquired a cheap Realtek-based USB3-to-RJ45 ‘adapter’ as the second network interface. It works without any further issues in Linux (Arch) and has no problems to handle Gbps traffic.
For the router configuration, I am using ‘nftables’ instead of ‘iptables’, as the former is supposed the successor of the latter. I only used the new nftables configuration, but there are wrappers available so that one can continue to use iptables syntax if desired.
For network configuration, I am using systemd’s networkd. Check systemd.network(5): Configuration option ‘IPMasquerade’ takes care of telling nftables/iptables to setup masquerading (rendering the iptables invocation @thebardingreen@lemmy.starlightkel.xyz exemplified unnecessary), options ‘IPv4Forwarding’ and ‘IPv6Forwarding’ renders manually changing ‘/proc/sys/net/ipv4/ip_forward’ unnecessary.
systemd’s networkd has a built-in DHCP server; check option ‘DHCPServer’ and section ‘DHCPServer’ for that (same man page as above). This way you can skip installing/configuring a separate DHCP server, but systemd’s DHCP server has some limitations, such as only supporting DHCPv4 and lack of proper command line tools. For example, to retrieve the list of current leases, you would have to make a dbus call to networkd, e.g. via busctl or dbus-send.
Bridges can also be configured with systemd’s networkd, making a separate bridge tool unnecessary. Rather straight-forward with three small configuration files, telling networkd that you want to have a bridge, its name (e.g. br0), its MAC address, which NICs will be part of the bridge, and the bridge’s configuration like a NIC itself (e.g. static IP address, that the networkd’s DHCP server shall listen here, …).