jrgd

If you take a look at it from the lens of distro maintainers, this would be an absolute nightmare. Distros package library versions, and currently tightly control the release of applications to given library versions. Allowing just any range of library versions for applications would loosen said requirement, but would require distros to then build and maintain a ton of versions of each library.

Flathub currently curbs this problem to a large extent by bundling explicit point release packages of common libraries, and expects the application to bundle uncommon ones themselves. This does mean that one cannot simply package an application without some thought put into the library versions used for release on Flathub still.

For distros, this style of packaging could somewhat be copied, but to little benefit. It would either be wasting time replicating congruence with an existing standard like Flathub's library bundles or do their own thing and further complicate things for developers wanting to get their app published to a distro's repos.

Overall, flatpaks make the process look a bit more seamless than things really are for developers and package maintainers. Flatpaks really only work as well as they do because everyone mostly agrees on adhering to the library packages published by Flathub. I don't really think adding even the sliding scale of library 'sets' for various distros would any benefit beyond what is currently done.

Adding to compatibility notes, it does seem that with the 2015 A1502's there won't be anything major in poor compatibility, beside the webcam not working out of the box. Found someone who documented their experience heavily tuning their Fedora install on their 2015 A1502. The author kitted out their Mac with a new SSD and better Wi-Fi card, which is worth mentioning. Some of the information is straight up helpful for even a standard A1502. Common stuff like installing the RPMFusion libva driver, EasyEffects equalizer presets, TLP are generally good ideas.

Mbpfan is also a good idea, but it looks like the package got dropped on 44 from a missing maintainer. May be recommended to install 43 for now if going with Fedora. I pulled the package source and built it on my computer, and it seems to work. Unfortunately I don't have an actual Macbook to test it on. I'll see about getting a COPR repo for it available soon, so that the package can be easily tested.

I have a Copr repo available (jrgd/mbpfan) for unofficial packages on Fedora 44.

Some stuff, like disabling mitigations, throttled, and installing the FacetimeHD drivers are not stuff I'd really recommend. You can still go with any of these noting the caveats listed for each tweak. The FacetimeHD drivers are required for getting the webcam to work, so going through the hassle of getting those drivers to behave or just not having a built-in webcam is a choice to make.

Probably your best bet for something similar in vein to MacOS would be any distro that ships with GNOME. Ubuntu, Fedora, Debian, OpenSUSE Tumbleweed all either ship explicitly with GNOME or have them as options within their live installers.

If you know which model and spec your Macbook is, I could give better compatibility insights. In short, the Broadcom chips used for Wi-Fi, Bluetooth in the 2014-2015 Macbooks used to be quite problematic for many Linux distros, but I do believe the in-tree bcm43xx driver in the kernel should handle them well enough nowadays. Depending on exact year and spec, your Macbook may come with an NVidia GPU, which will require additional post-installation steps to install the proprietary drivers on many distros. As it isn't the primary display device on those models, there shouldn't be too many issues in getting the cards to function and render offloading to work.

::: spoiler Ubuntu discourse

Ubuntu is not really spyware as people may claim it to be. The main spyware claim comes from two sources: the 14 year old once-integration for Amazon services that Ubuntu shipped around the 12.10 point release and that Ubuntu does utilize more telemetry than other distros.

Often though, it's not a recommended distro anymore for many reasons. One primary one is that Ubuntu used to be seen as user-friendly and had a lot of community forum posts to document how to use it. Nowadays, most major distros have caught up and surpassed Ubuntu in usability and reliability, and Ubuntu's once-positive of forum posts largely tend to clog up being able to find useful information when a problem does occur because of how out-of-date many of those forum posts that still show up in search results are.

Another big reason is Ubuntu is not recommended is Canonical's (the company the makes Ubuntu) makes regular missteps and often falls on the wrong side of development for progress of the Linux desktop. See Unity desktop, Mir, Upstart, and the current misstep of Snaps. Canonical has also additionally put less effort into keeping that once-polished experience the Ubuntu desktop had and moved a lot of their effort into their server offerings. There have been relatively recent Ubuntu LTS desktop releases that have shipped with some baffling and often showstopping bugs that should have been release blockers. It's to a point where the QC of releases is often worse than what is found on 6-month point release and even many rolling release distros to where many don't recommend Ubuntu anymore. :::

Based on OP's edit, that looks correct. Unless OP checks the topology and can make the claim that drives from the main chipset are the slow ones, secondary chipset drives will tend to perform slower, and the ASMedia ASM1061 has several reports online of poor to trash performance compared to baseline.

Best bet if the full performance is necessary out of every drive would be finding a decent quality PCI-E SATA III riser card that doesn't use a known flawed driver chip rather use the two 'extra' ports on the motherboard.

You can absolutely swap the primary boot entry in the BIOS by hand, but as mentioned, GRUB can be made to show an entry for Windows 10 upon normal boot. You can select that entry rather than swap the primary target in the BIOS, which will be a time saver when switching OS. Some configuration to get GRUB to pick it up will likely need to be done however.

For that to work, one needs to uncomment a line in /etc/default/grub (#GRUB_DISABLE_OS_PROBER=false becomes GRUB_DISABLE_OS_PROBER=false). If the line simply isn't present in /etc/default/grub, just add it at the bottom.

::: spoiler For GPT, EFI installations On modern (EFI, GPT) systems, there is specifically one partition you will need to persistently mount from the Windows drive through fstab, being the Windows EFI partition. It does not matter particularly where it is mounted, as long as it is out of the way (a mount point like /windows is fine). You'll have to create an empty directory preferably somewhere under / and owned by root, and then add the Windows EFI partition as a line to /etc/fstab. The command line utilities lsblk and blkid can help to determine the disk partition layout and the EFI partition's UUID. The 'Disks' utility installed by default in Mint can also do this, and may be easier.

Before touching your /etc/fstab file, make a copy of it. The resulting line added to /etc/fstab will look roughly like UUID=ABCD-1234 /windows vfat umask=0077,nofail 0 2, replacing the ABCD-1234 with the actual UUID and /windows with the actual desired mount point, if different. Running mount -a with sudo is highly recommended after touching the fstab file to verify that everything is correct. The command should complete with no errors. If it errors, revert your /etc/fstab to the copied version. Rebooting with a broken fstab file can leave your system unbootable. :::

Finally, for systems like Linux Mint, run update-grub with sudo to rebuild the bootloader entries. With os-prober enabled in /etc/default/gruband the Windows EFI partition mounted if relevant, update-grub should show a warning about os-prober being enabled and among other entries, an entry for Windows 10 should be present. As long as the Windows drive continues to be installed in the system, a boot entry should be available next to your Linux Mint and bios entry options in GRUB going forward.

Generally, if they are fully on separate drives, things should be fine. When going to install Windows for the dual boot, physically unplug or uninstall the Linux drive. After Windows is installed and can boot, you can then reinstall the Linux drive.

On the Linux side, you may need to trigger a rebuild for GRUB or your preferred bootloader to get the appropriate Windows 10 entry to show in the boot menu. Some distros may need extra configuration to get this to work. Don't attempt to automount any partitions from the Windows 10 side and don't generally try to mount them unless necessary. The only exception to this is if using EFI partitions, then that partition will need to be mounted for GRUB to see it.

Also highly recommended to block Windows 10 from connecting to any network if possible, as it is end of life (unless using ESU releases).

EDIT: Somewhat incorrect information in regard to EFI partitions, missing GRUB configuration related to distro

Originally when I started the move to Linux in 2015, I did it because Windows 10 was wholly incompatible with my ISP. I lived through dial-up, HEO satellite, HSPA, LTE, fixed wireless, and currently fiber. During the period with dealing with HEO satellite, every provider at the time in the US (WildBlue/Exede/Viasat, Hughesnet) had alright speeds at best paired with a very aggressive soft monthly data cap (10 GB, eventually 26GB in like 2018), that would revert the speed capabilities back to 32-96kbps. Upgrading from Windows 7 to Windows 10 was largely a mistake for many reasons, but one of them was the sheer frequency, size, and aggressive nature of how Windows 10 tried to download and apply updates automatically. Windows 10's frequent auto updates would easily eat several gigabytes each month of the tiny data cap. The rest of the amount of idle networking Windows 10 did also didn't help during throttled periods, eating up most of the bandwidth available from just one workstation. Knowing that Windows 10 wouldn't be another Windows 8 and that Microsoft would go forward with 10, I decided to seriously look into alternatives.

Eleven years later, I have virtually no restrictions in hardware nor networking. Despite that, I still use Linux exclusively. Nowadays, there is little to no compromise in using a Linux-based system for many general tasks. Certain niches vary in usability on Linux, especially if the niche is cemented in certain proprietary software. Modern Linux-based systems (both distro and desktop environment) are just more polished than the experience to be had on Windows 10 or Windows 11. Many common frustrations when using Windows (device driver installation, printers, drawing tablets, HDR, system updates, software updates, system maintenance, lack of dark patterns, error message clarity, etc.) are things that a modern Linux system deals with a lot less, to a lesser extent, or just not at all. After spending many years learning both Windows and Linux, Linux systems are just more functional and easier to use.

Using the AUR largely expects users to understand the basics of shell/BASH scripts, which is what a PKGBUILD is. The most obvious source to check is what URL(s) the PKGBUILD is pulling in for a package's source(s). Are these URLs sourced from official or otherwise trusted sources for the application or component (such as from the app author's download site or their git forge)? Does the PKGBUILD make any claims of what is being downloaded and does the target URL's contents match that? If either of these checks fail, it's best to avoid that package.

Additionally, does the PKGBUILD attempt to do things like obfuscate data such as URLs or tokens for downloading? Does it attempt to recklessly delete or modify files/directories (rm -rf, other recursive functions)? Does the PKGBUILD make use of any arbitrary execution statements such as exec or spawning subshells? If any of these check true, the package should seriously be revised before attempting to install it. System-level software installs on Linux systems should never be complicated enough to need fancy execution techniques nor reckless file management.

Starting with confirmation of what others have said, yes you can use compose tools with Podman and Podman can hook directly with Docker Compose (the tool), but it really isn't recommended. Compatibility with compose now is better than it used to be, but there are still edge cases. For a lot of projects that just pre-write a compose file that they expect to cover the general use case of their container, you're best to take the compose file and write it out to Quadlet unit(s).

Other differences not mentioned can include:

• Podman alongside containers has optional pods, which let you wrap multiple containers together, sharing the same IP internally. Useful for having a service and their sidecar containers (e.g. Valkey, Postgres, Meilisearch, etc.) be bundled under the same IP address and simply reference each other as localhost, 127.0.0.1, or ::1. If you utilize pods for certain split-container applications, you may need to remap certain service ports as they can overlap and cause binding failures.
• Podman has multiple networking modes. If you use Podman at the system level (rootful) like Docker expects you to, you're not really going to encounter any quirks with the default networking setup. Per-user Podman (rootless) defaults to using the Pasta backend for networking, which is still very highly performant, but is a bit clunky to configure (if ever actually necessary) and inter-pod communication can be difficult to get right. Alternatively, registering rootless pods with a bridge network makes inter-pod communication easy, but can cause problems if accurate source IPs are needed (e.g. upstream reverse proxies, accurate client IP logging, etc.).
• Because Podman is daemonless, there is also no persistent API socket loaded by default (an intentional security choice). For both rootful and rootless containers, you can enable this manually and mount it to containers that need it. For containers that expect docker.sock explicitly for API manipulation, your mount will need to reflect the name change of the podman.socket to what the container expects.
• Podman by default won't shorthand container pulls from docker.io by default: a sin I see constantly done in so many compose files. When pulling a container from DockerHub, you need to put the docker.io/ prefix, just as you would but the appropriate prefix with Quay, Github, Gitlab, or any other distributor.
• Podman can optionally let you auto-update containers based on the release tag specified for the container.
• Because of Podman's integration with SystemD, a lot of oddball integrations (external cron jobs, one-shot services, etc.) can be pulled together with extra SystemD units (services, timers, etc.).

Might take a little bit of effort to do a conversion if you're locked into explicitly how Docker interacts with OCI containers, but over in the Podman camp you have two options.

• Cockpit with the Podman containers interface: a graphical web-based solution for managing podman containers and the rest of the system.
• Podman Quadlets: a config file-based way to manage Podman containers, volumes, pods, networks with custom SystemD units. Great if you want to version control your deployments.

Other than that, the more usable solutions I've tried of graphical Docker container management interfaces would be the ones in Unraid and Proxmox, though those solutions may not be suitable depending on your use case and have their own caveats to be aware of.

If Google kills AOSP, a lot more than just GrapheneOS will stop being able to exist lest some entity maintains a fork that diverges from Google's path. Vendors that aren't shipping in line with Play Services and the rest of the ecosystem as well as LineageOS and other custom ROM development teams will suffer as well.

This kind of decision would essentially kill adoption of Android in a good number of countries within a few years as well as be the end of Android adoption for anyone that cares about security and/or privacy. Yes, It would either kill or put a large burden upon GrapheneOS as a project, but that is also true for so many other projects in the ecosystem. If the developers shutter their AOSP usage due to upstream abandonment, the users will likely follow in the same pattern.

It's probably not a case for everyone due to the obvious limitations, but I primarily use KeepassXC from my main workstation. I have backup scripts that periodically run for my user on said workstation that capture my Keepass database among other user files and backup to external storage, cloud storage as dictated.

For my laptops, mobile devices; I periodically push the database from either the main workstation or pull from a backup to these devices. I do not write new entries from these devices in order to avoid having to handle writeback to the main instance of my Keepass db. This can be done, but inherently starts to hinge on needing network access all the time to ensure an up-to-date copy of the DB is present as well as being explicitly a single-user db to prevent a syncing protocol from accidentally writing over new entries from any given device. Obviously, if network sync and the potential for multi-user is important to you, continue using Bitwarden. It is a perfectly fine solution.

I'll list a few of my regularly-used tools, both CLI and GUI.

CLI:

• ncdu: An interactive TUI variant of du, for tracing disk usage across targeted directories.
• podman: An alternative runtime to Docker that is arguably just better at this point. Can handle rootless containers with ease, works with SELinux, can handle Docker compose files with add-on tool podman-compose, can automatically update containers intelligently, can integrate well with SystemD, and more.
• mtr: Another network tool. Effectively traces network routes to a given IP. Great for diagnosing faults in latency or major packet loss.
• ffmpeg: A very complicated, but powerful tool for converting, manipulating video and audio files in all sorts of ways. FFMpeg can essentially be the answer to any 'do X to Y file' question.

GUI:

• Kdenlive: A powerful video editor developed by KDE. For free and open source, it is impressive how little you can't do when editing videos with this tool. A bit buggy at times, but has gotten significantly more reliable over years.
• Handbrake: A FFMpeg frontend that allows for mass transcodes of video files based on created profiles. Great for archiving, finalizing videos down for web upload, or just converting content to a more efficient format. Specializes in lossy/destructive operations.
• LosslessCut: A FFMpeg frontend that allows for trimming videos, stripping and/or exporting tracks from videos, editing mkv metadata, editing video chapters, and any other lossless/non-destructive operations that can be done on video files.
• Subtitle Composer: An outright semi-professional-grade subtitle editor developed by KDE. Supports and can convert between pretty much any subtitle format you might encounter. Great for creating, editing, timing, and translating subtitles for videos.
• KeepassXC: My password manager of choice. Has browser autofill integration, though requires some holepunch work to function with Flatpak browsers. Explicitly is based on local files. Does not rely on cloud providers.
• Limo, R2Modman: Native mod-managers that allow for modding various Steam games (native and Proton) on Linux.
• Blender: A powerful 3D editor. Capable of hard and soft 3D modeling, character rigging, animation, material creation and UV mapping, compositing and rendering. Pretty much an all-in-one tool for 3D art and design.
• FreeCAD: A somewhat daunting, but functional 3D CAD software. Has received a lot of recent (~3 years) patches to improve on a lot of long-standing pain points in the software.

From the project's site, an eBlockerOS-powered device allegedly uses ARP spoofing to hijack as the default gateway and serving as a second hop in the internal network. Behaving as an NGFW can have some benefits over just DNS filtering that services like PiHole achieve. Things the project lists it is capable of include global VPN tunneling, DNS request masking, parental controls, content blocking.

It could be technically better than just PiHole (assuming the project is legitimate), but I will argue so would a router running OpenWRT or similar. Depending on the SBC used with it, I would be concerned with network throughput performance (both Ethernet link speed limits and CPU utilization from certain services). Additionally, its configuration would mean it being a full second-hop device on the local network, which may cause its own category of issues. The main use case I could see for this project is if you're completely stuck with your ISP's router and cannot touch much about it.

Coming back and checking the values file posted. Not sure why your authentik block won't get used in your values file. Your current issue of non-starting is likely the Authentik server container starting successfully, but failing liveness while waiting for the worker container(s) that is definitely not spooling up with your current configuration.

Something to denote about Authentik itself that won't be well-explained by the quickstart for the Helm chart itself is that Authentik is split into two containers: server and worker. For most environment variabless and mounted secrets, both the server and worker definitions should have them applied. The chart tends to handle most of the essential shared stuff in the authentik block to prevent the duplication, but secrets will likely need to be mounted for both volumes if using file or env references in the shared config, as well as most env overrides will need to be applied for both.

In my case I'm running an external Postgres DB and external cache plus a handful of other settings. As such, I have a decently sized values file. All of the env vars I was looking for in my case are provided in the chart, so I didn't need to set any directly, but just through their counterparts in the values file.

I don't use ArgoCD in my case, so I couldn't really say if it would affect your deployment strategy in any way.

When I did my authentik setup through helm chart a while back, the only real problems I had were with learning blueprints and not so much with getting Authentik to do its thing.

The main things you should be checking given a liveliness probe failure is kubectl -n <namespace> describe pod <podname> to check the reason for failure. Additionally, kubectl logs -p -n <namespace> <podname> [container]. Will get you logs of the last run of the pod that has already failed, rather than the current run that may be soon to fail. Those two commands should point you pretty directly where your chart config has gone wrong. I can likely help as well if you are unsure what you are looking at.

Additionally, once you get things working, please go back and usw secrets properly with the chart. Authentik lets you sub many values for env vars or files, which combined with mounting secrets is how you can use them.

Iproute2 definitely does write things a bit compact. ip address show and shorthands state the routed local address space (192.168.1.x/24) and the actual /32 address (192.168.1.214) you are assigned as one unit. Additionally, it shows the broadcast address for the space. Ironically, ip route show may genuinely give you less confusing information, clearly splitting the actual route and showing your straight IPv4 address as src.

Typically in firewalling, you'd use /32 to target a singular IPv4 host. This is analogous to using /128 for IPv6 hosts. You can absolutely use /24, /16, /8, or any other mask really if you need to target a range of IP addresses for a rule to apply to. Technically, /32 is a range itself, just with a size of 1. There are CIDR calculators available to play around and see what different CIDR masks actually target.

The routing and firewalling is a bit different in terms of why certain CIDR masks are used. For the router, the /24 suffix is usually defined for itself on the LAN interface to denote the address space it may send route information to, and what addresses are controlled by the device. Almost certainly, (unless using a lower CIDR range and actually handing out /24 blocks to subsequent routers,) you are granting /32 IPv4 addresses to your devices from your router.

For your system firewall, 192.168.1.135/24 is identical to 192.168.1.0/24 as they are the same address space. You're simply allowing from a subnet of hosts to accept from. Given the /24 mask is 255.255.255.0, it does not matter what the last number of the IPv4 address is, but the lowest possible number to match the mask is standard form. Without knowing what rule(s) specifically is being applied, I couldn't tell you if your firewall rules are something that would affect hostname resolution of other hosts from your system or not.

In addition to the other reply on the fundamentals of why not in general, maybe we don't recommend daily driving one of DHH's pet projects.

If anyone is out of the loop of who DHH is, tons of people have covered the topic but I think Niccolò Venerandi has quite comprehensive and digestible coverage. If anyone cares to read or watch Nicco's coverage.