Like others here, I have trouble following your post, but one thing is instantly sticking out to me: you mentioned 10.0.0.0/8 and 10.20.20.0/24 networks being present.
Unless your 10.20.20.x are actually in a 10.0.0.0/8 network (so configured with addresses like 10.20.20.x/8), this is definitely gonna cause a lot of issues. Like most things in networking, it can probably be made to somewhat work for some specific setup with some voodoo magic, but you really need to understand what you're doing on a very deep level to do that.
The first issue you will probably encounter if you want to communicate between the two networks is that ARP cannot be forwarded, so your /8 network will never discover the /24 network (unless you just bridge them together - that will let the /8 network discover the the /24 devices, but not the other way around).
If you want to make your network routed, you will need to split it into non-overlapping networks. Otherwise give everything a 10.x.y.z/8 IP address and make sure that the whole network is connected via switches (hardware) / bridges (software).
I'm pretty sure all of those entries are in the same /12 network - 172.16.0.0/12. Apparently there's nothing wrong with it, but I think you can significantly simplify that config by just removing all the extra ones
That just uses normal fast charging to get to 80%, then stops the charge and finally resumes charging about an hour or two before the planned "charged by" time. No slowing down.
Oh, and it also has (or had on Android 13) a cool bug where it just stops charging if it fails to reach 80% by the time it wants to resume charging (for example if you put the phone on a slow charger late at night - that's how I woke up with 60% battery after 4 hour sleep).
So I just gave up on the idea of using a slow charger to better preserve the battery because the phone clearly wasn't expected to be used that way.
Does UEFI initialize all the cores? I know the OS always starts with only one core available, but I'm not sure if UEFI just disables the cores after it's done its thing, or if it doesn't touch them. Because if it stays on core 0 and never even brings the other ones up, then this issue with core 2 could let it boot this far just fine.
Only if you consider ROMs like LineageOS to be stock Android and ignore the many things they do to make the user's life easier.
AOSP never had internet access as a toggleable permission, and it never will as long as Google is calling the shots and wants ads to work the way they currently do.
Do you need other WiFi devices (like a phone or a laptop) to be able to access your servers? If not, you could just set up your desktop as a router, that would be the most painless way to go around this situation.
The basic steps are to enable IP forwarding on your desktop, configure a static IP address on the Ethernet interface (for example 192.168.1.1/24 - just make sure it is in a different network than what you get from the WiFi. For example if you get 192.168.0.x, the previous example address would be fine), then optionally set up a DHCP server on the Ethernet interface (otherwise you will have to manually give everything a static IP address), and then finally add a masquerade rule into the firewall (something like iptables -A FORWARD -o wlp0s1 -i enp0s1 -m conntrack --ctstate NEW -j ACCEPT; iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT; iptables -t nat -A POSTROUTING -o wlp0s1 -j MASQUERADE - the first two rules allow new connections from Ethernet to WiFi and replies in either way, and the final rule sets up the masquerade - it makes it look like all the traffic is coming from your desktop and hides the new network from your WiFi router; it wouldn't understand how to communicate with this new network otherwise)
It might sound pretty overwhelming, but it should be manageable if you go step by step.
Pretty sure you can't do that with standard WiFi. Or rather you kinda can, but you need to know how it's different from Ethernet so you understand why everything keeps breaking.
For example DHCP is absolutely out of the question, as it relies on the MAC address to assign IP addresses. So static IPs will be required. And you also need to make your "switch" aware of the fact that it now needs to route IP packets coming from WiFi, because everything on that side of the network will send the packets directly to the switch.
I kinda doubt there's going to be any outside contributions to this project, so any non-exclusive license would allow MS to rerelease this under a proprietary license - even the GPL. They own the copyright, so they can release it under as many licenses as they wish.
With software there's way lower barrier to entry and way higher chance of having the patches accepted. With art... Good luck convincing MS that your version of the emoji is worth the hassle of losing the ability to just change the license at any moment.
Maybe. To be clear the delay isn't that large (my very rough guesstimate is somewhere between 100 and 300 ms, probably more towards the lower end), and if I just click somewhere on the slider, it feels fine.
It only feels janky when I drag the slider and the screen brightness updates in very noticeable steps. But that is how I naturally interact with sliders, so it's hard not to notice it for me.
It's a very common feature for monitors, at least in my experience - both of my cheap AOC monitors support it, as well as all the other monitors I've ever connected my laptop to (a few HP and Samsung monitors iirc).
But it also feels kinda janky due to how long the display takes to change the brightness, so maybe that's why Microsoft decided not to support it?
Because of the built-in SSD, I could also sell the external SSD and buy an 8-12tb HDD instead.
If you're going for a 3.5" HDD, then you'll most likely have to look for a bit bigger form factor than TinyMiniMicro (Lenovo Tiny / HP Mini / Dell Micro series) - these computers can't fit a 3.5" HDD.
If size isn't a major concern, I'd go for the SFF variants of these computers - they are often cheaper than minis for same specs, but probably have a bit larger idle power draw and take up more space. As a bonus upside, you get some small PCIe slots in these computers, so yay for expansions.
Not really - report your issue on their issue tracker if you can and feel like spending your time on it, then move on (and maybe check back in some time). Flatpak are meant to fix dependency issues, there's not much you can do if they got it wrong for whatever reason.
If it's a Flatpak, then installing anything with APT shouldn't help you at all - it is possible to build a Flatpak that accesses host libraries, but it would defeat the point of using Flatpak in the first place. So your xapp issues are moot anyway.
As to the meaning of the output of apt policy: it says that the most up to date libxapp1 is from Linux Mint repos, and that there's also an older version in Ubuntu repos. That means that Linux Mint doesn't provide a xapp package at all, and the only one you could install is the old one from Ubuntu (which conflicts with the newer libxapp1 from LM)
The APT error is most likely a result of using PPAs - some PPA you use (probably the one with simple64) provides libxapp1 2.8, but doesn't provide happy at all, so you end up falling back to the much older version from your distro's repositories. But xapp needs an exact version of libxapp1, so you get this error.
That said, if the simple64 PPA doesn't provide the xapp package, then it perhaps isn't required and the module should be provided by libxapp1 (and the problem is something different). Or maybe it comes from a completely different PPA - I believe apt policy libxapp1 should tell you where it's coming from.
Yes, but they are asking how to set up FDE in the same way it works on Windows, where automatic unlocking works using TPM. They just don't know the technical details.
Yeah, but a lot of those things will trip the TPM module, so you will get a different decryption key if you for example try to use the single kernel parameter to boot into a root shell. And different decryption key means no access to the data.
If you boot the computer into the currently installed OS, you will be presented with a login screen and will have to enter the correct password to log in (kernel parameters are part of the checksums, so booting into single-user mode won't help you, that counts as a modified OS). If you boot a different OS, you won't get the key off the TPM.
The idea is to use TPM to store the keys - if you boot into a modified OS, TPM won't give you the same key so automatic unlock will fail. And protection against somebody just booting the original system and copying data off it is provided by the system login screen.
Voilà, automatic drive decryption with fingerprint unlock to log into the OS. That's what Windows does anyway.
Or is there any functional difference between the two methods?
Can't test right now, but I have a strong suspicion you will have trouble getting IP broadcast to work. Normally broadcast address is calculated by setting all bits after the network prefix to 1, but your computer believes to be in a /32 "network". It won't broadcast over routes that are not part of its network.
And even if you calculate the broadcast address successfully (maybe the software you use has /24 hardcoded for whatever reason), no computer configured with a /32 address will receive it - 192.168.0.255 is not within the 192.168.0.1/32 network, so it will probably get forwarded according to your routes if you have forwarding enabled (except it shouldn't in this case with one network interface, because you never send packets back the way they came from)
Well, Nvidia doesn't support OpenCL 2, so if you want your software to support the most commonly used cards, you're going to be limited to OpenCL 1.2, which is pretty crap compared to the shiny CUDA. There's also a lot of great tooling made or heavily sponsored by Nvidia that's only available for CUDA.
And yes, Nvidia now supports OpenCL 3, but that's pretty much just OpenCL 1.2 with all OpenCL 2 features marked as optional (and Nvidia doesn't support them, obviously).
Markaos @ Markaos @lemmy.one Posts 6Comments 217Joined 2 yr. ago
Like others here, I have trouble following your post, but one thing is instantly sticking out to me: you mentioned 10.0.0.0/8 and 10.20.20.0/24 networks being present.
Unless your 10.20.20.x are actually in a 10.0.0.0/8 network (so configured with addresses like 10.20.20.x/8), this is definitely gonna cause a lot of issues. Like most things in networking, it can probably be made to somewhat work for some specific setup with some voodoo magic, but you really need to understand what you're doing on a very deep level to do that.
The first issue you will probably encounter if you want to communicate between the two networks is that ARP cannot be forwarded, so your /8 network will never discover the /24 network (unless you just bridge them together - that will let the /8 network discover the the /24 devices, but not the other way around).
If you want to make your network routed, you will need to split it into non-overlapping networks. Otherwise give everything a 10.x.y.z/8 IP address and make sure that the whole network is connected via switches (hardware) / bridges (software).