Generally yes. The Fn key is usually handled either by the keyboard itself or by the BIOS, and the OS just sees the resulting key presses as if the keyboard had all the buttons. Can you not find such a switch in your BIOS? Saying what vendor it is might also help someone help you.

But AOSP already is “Android without proprietary Google code”, simply because “Android” means AOSP + Google Play Services + compatibility certification. It’s getting increasingly more and more barebones as Google moves functionality into Google Play Services, but it is what the vast majority of third party ROMs are based on.

How they manage to then improve compatibility differs. Truly ungoogled ROMs just don’t - either the app works with AOSP, or it’s not welcome on the system because it would require Google services. Some use MicroG, a small open-source reimplementation that is good enough to replace the real Google Play Services for most apps (but it does communicate with Google servers similarly to the real one, so all it does from degoogling perspective is limit the amount of extra data your phone sends to Google). Then there are also ROMs that support installing the official Google Play Services and related apps. LineageOS can do that (or it can use MicroG, or just not have GPS at all), for example.

And then there is GrapheneOS which has managed to turn the Play Services into a mostly regular app that doesn’t have overreaching access to the whole system and lets you configure how much data you’re willing to leak to it.

Drivers also don’t seem to be that big of a deal nowadays, Google’s effort to simplify Android updates for OEMs has done a lot to help third party ROMs as a side effect. The biggest problem now is the various security attestation mechanisms that are available through Google Play and which Google spends a lot of time and money to convince developers to use. These are very hard / currently impossible to implement in a way that doesn’t trip security checks on the affected apps - want mobile banking? Well, that’s too bad because it will simply refuse to work if Google Play says your system has been tampered with. Workarounds exist, but they’re not reliable over time.

I’m a bit confused about the emphasis you put in the quote… GrapheneOS is built on AOSP (the open-source part of Android), it’s definitely not some OS built from ground up (look no further than the various Linux phone projects to see how terrible those are as Android replacements atm).

Technically it isn’t Android, because Google owns the trademark and has some requirements for stuff that wants to call itself Android - it needs to pass a compatibility test and more importantly, include Google Play Services. But it is as much Android as any other custom ROM.

This is a very useful way to remember it, but nowadays it’s better to drop the z (which immediately makes the mnemonic more forgettable, of course). tar can autodetect compression now, so tar -xf should work on anything from plain tar archives over tar.gz to more unusual compression algorithms like tar.xz or tar.bz2.

(the z is specifically for gzip)

Interesting to hear that people consider Android, AOSP + proprietary bits.

Google owns the Android trademark, and they won’t let you officially call any OS that doesn’t meet their requirements Android. And their requirements include Gapps among other things. That means AOSP is not Android.

I believe a USB WiFi dongle will be a better idea than modifying live images of various distros, and others are already pointing you in the correct way for that, but I feel the need to correct one thing:

Okay, so maybe I can add some driver files to the LiveUSB or something? . . . nope. Not a good idea, because the other part of the whole fix is installing firmware, which has to be in place before the drivers will work – but this chip is also still being used by the onboard Mac OS.

The WiFi module doesn’t have any persistent memory for firmware, which is why the system needs to bring its own firmware - it is uploaded to the chip on every boot as part of driver initialization. So there is no risk of interfering with macOS here.

The installation in the guide refers to putting the firmware in a place where the driver will be able to find it. In other words, you would be installing the firmware on the Linux system, not onto the WiFi module.

Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

There’s no limit on the number of concurrent connections on a single port, and SSH runs completely on the one port it is configured to use. Otherwise allowing just the port 22 in firewall wouldn’t be enough to have a functional SSH connection with default settings.

You can verify that quite easily for example by spinning up three barebone Debian VMs connected to a single virtual network, configuring the firewall on the “server” VM to drop everything other than port 22 and then connecting from both client VMs - it will work just fine.

Maybe you’re confusing it with the fact that only one process can listen on a given port at a time? But that’s only for establishing new connections. Existing connections can be passed off to another running process or a child process just fine, and that’s how SSH handles separation between connections.

Edit: oh, you’re talking about the high port OP is wondering about. That’s just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH “moving connections over”

you might want to maybe try a different distro image to verify, maybe a simple kernel with a net image or something.

This part actually makes me wonder… Do you think SerenityOS uses the Linux kernel? Because it does not, it’s its own completely separate thing. And the hardware support for anything other than the standard emulated machine is very iffy, so it doesn’t seem too surprising that it would get tripped up by something on an old computer.

If anything went wrong with its USB stack for example, the kernel would have no way to find the root filesystem that’s stored on a USB drive.

I haven’t done that, lemmy.one doesn’t even have downvotes

Yep

Usually the problem isn’t that the changes are big, but that the new way simply isn’t compatible with the old way to do things, and you can’t just make a change that will break existing applications in minor versions (well, there’s nothing technically stopping you, and unintentional compatibility breaking bugs have definitely happened in the past, but people are gonna get real mad at you if you do that). Even if you break that change up into thousand tiny changes over many minor versions, the end result is that at some point, you break old apps.

The solution is to take note of all the things that are either badly designed or became obsolete and once in a while go “hey, let’s make a new major version and fix all of this crap”. With a new major version, you don’t have to worry about old applications and are free to improve your library in any way you wish, and you also get the option to keep updating the old major version with some maintenance bugfixes so that the old apps keep working well enough.

Yes in the sense that the APIs were made because of flatpak, but not in the sense that devs would need to keep two separate code paths for flatpak vs non-flatpak - portals work everywhere.

No, kernel immediately stops execution of all normal processes once it gets into a kernel panic, and there’s no way for processes to hook into this functionality. It is intended to be the emergency stop state when the kernel realizes it doesn’t know what’s going on and it would be dangerous to continue executing. So it does the bare minimum to report the issue and then stops even its own execution.

There’s also a softer variant of the kernel panic called kernel oops that should let the user choose to continue if they think the risk of data corruption doesn’t outweigh losing all data currently in memory. But just like the kernel panic, it is handled completely inside the kernel and userspace is frozen until the user chooses to continue.

This is intended for situations where systemd runs into an unrecoverable issue while booting (for example you have misconfigured fstab and a required disk is missing). Without this, you just get thrown into the terminal with some error messages that might not make much sense to you if you don’t have a decent understanding of Linux. Now, you get a more newbie friendly message and a QR code that should bring you somewhere you can learn more about possible causes and troubleshooting steps.

sfp might be an issue for my since my modem and Ap don’t have that port

SFP is something like a port for ports - you buy an SFP module based on what port you need, so you can just buy a network device with SFP cages that can handle your required speed and then pick a combination of Ethernet / optical SFP modules that match your needs. But the modules aren’t exactly cheap, even the Ethernet ones.

other than to outright disable dxvk

That’s exactly what you want. DXVK is the “new” DirectX to Vulkan translation layer (that’s where the name comes from), and if you disable it you will be using the DirectX translation layer from Wine which uses OpenGL

And there will likely be many distros that compile this server as a kernel module and package it separately, so even inclusion in the kernel doesn’t necessarily save you from defaults that don’t fit you well.

Also looks like it’s removing an important visual affordance (i.e., which areas you can click to drag the window), unless I’m misinterpreting it

The top bar has been full of buttons with no whitespace for a year or more now, that’s not new (you can still drag the window using the whole bar, but it’s definitely not intuitive and made me subconsciously do Win+drag to be safe many times).

This seems to be a relatively minor visual update to have the left sidebar fill the whole window - maybe they want more space for shortcuts at a given window height? No clue.

Edit: never mind, checked again and it’s literally just a tiny visual update with no change to the actual content of the sidebar, but it takes some space away from the top bar.

(…) systemd is linux only. Ask why?

It is well known that systemd’s service management is built around cgroups, which is a Linux-only concept for now. Other OSs have their own ways to accomplish similar things, but adapting to that would require huge changes in systemd.

Am I able to run system-journal without any other systemd components running?

No, the only part of systemd project that doesn’t depend on systemd core is systemd-boot. And there’s also elogind, which is an independent project to lift systemd-logind out of systemd.

But honestly, I don’t see the issue here. You can’t use systemd’s components elsewhere, but your previous complaint was the opposite - that systemd is everywhere, as if you were forced to use networkd, resolved (which pretty much no distro uses AFAIK because it’s way worse than other DNS resolvers), homed, timedated etc. when you use systemd as init.

Also, I have a correction for my previous comment: systemd-journald is not an optional dependency, as it’s used as a fallback if the configured log daemon fails. I’ve only learned after writing that comment.

From this point of view is systemd disaster because it is almost everywhere in the system - boot, network, logs, dns, user/home management…

That’s almost like complaining that GNU coreutils is a disaster from KISS point of view because it includes too many things in a single project - cat, grep, dd, chown, touch, sync, base64, date, env… Not quite, because coreutils is actually a single package unlike systemd.

The core systemd is big (IMHO it needs to be in order to provide good service management, and service management is a reasonable thing to include in systemd), but everything you listed are optional components. If your distro bundles them into one package, that’s on them.

Yup, it’s dead. Here’s the Internet Archive’s snapshot: https://web.archive.org/web/20230626075444/https://manjarno.snorlax.sh/