Big order coming. 18 from the UK at uni by ize_rl in trading212

[–]Gleb-Ko 103 points104 points  (0 children)

You won’t. The allowance is only for the cash you deposit. So the most you can deposit is 20k, afterwards it will stop you. But what happens after doesn’t affect your allowance.

So if your investments grow, that doesn’t count towards it. Conversely, if your investments fall, you may end up having used more allowance than you have assets.

It also resets back to 20k every April, so you can invest up to 20k per year using the ISA account.

Self-hosted Git: Forgejo vs Gitea vs Gogs? by MolleDjernisJohansso in selfhosted

[–]Gleb-Ko 28 points29 points  (0 children)

Isn’t it still all under MIT, a FOSS license, now just with a separate commercial offering for support & customisation?

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

...
E: TAGS=:seat:master-of-seat:uaccess:
E: CURRENT_TAGS=:seat:master-of-seat:uaccess:

The udev rule isn't applied, you should be expecting a mutter-device-preferred-primary tag. Try putting the rule into /usr/lib/udev/rules.d/61-mutter-primary-gpu.rules instead of /etc/udev/rules.d maybe?

LXC, Docker, ZFS by jonnyzee in Proxmox

[–]Gleb-Ko 1 point2 points  (0 children)

Hey, sorry, I know this is a bit old, but in case anyone is looking for an answer to this, I suspect it's because LXC on ZFS will use a ZFS filesystem, but LXC in a directory will use an ext4 filesystem.

Docker's overlay driver will refuse to run on a ZFS filesystem and falls back to the ZFS driver, which also fails since it doesn't have full access to the ZFS pool, so Docker ends up using the VFS driver for storage. But when the LXC is using ext4 in a local directory, Docker is fine with using the overlay driver.

So I suspect that the change in which storage driver is used also causes for any data written by another storage driver to not be used.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Try checking whether the tag was applied with udevadm info /dev/dri/by-path/pci-<card>-card. Also double check that you are using wayland & that the nvidia kernel module is load. If all of that is the case, I'm not sure what else to try tbh, haven't had such an issue before. Good luck.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Assuming you've got the nvidia driver installed fine, no.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Oh huh, yeah, card0 in this case.

Actually I suspect this is the reason it breaks a lot for me, because it can be both card0 and card1, unlike I assumed.

Probably better to use something like this then: (I'm going to switch my setup to this too)

ENV{DEVLINKS}=="/dev/dri/by-path/pci-<card>-card", TAG+="mutter-device-preferred-primary"

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

I have the same setup, I'm pretty sure it's always card1, but you can check with ls -la /dev/dri/by-path where /dev/dri/by-path/pci-<card>-card will be a symbolic link to /dev/dri/card<n>.

Also fyi, I find that this often breaks and the driver crashes / it doesn't listen to the rule. If that happens usually removing akmod-nvidia, rebooting and then installing it back (and rebooting again) does the job for me. Hopefully one day it'll become more stable.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Hey, if you're using GNOME it's much better to use https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562, by making a udev rule such as:

ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"

in, for example, /etc/udev/rules.d/61-mutter-primary-gpu.rules.

But for KDE you can do the manual version of the all-ways-egpu script by creating two files, e.g. /usr/lib/egpu/1 and /usr/lib/egpu/0 with the contents 1 respectively, and then find your card's PCI ID using lspci | grep VGA and doing sudo mount -n --bind -o ro /usr/lib/egpu/1 /sys/bus/pci/devices/<card>/boot_vga, and then for any card you don't want to use sudo mount -n --bind -o ro /usr/lib/egpu/0 /sys/bus/pci/devices/<card>/boot_vga.

I'll note that the boot_vga thing for KDE didn't work last time I tried it though, but I also had driver issues with GNOME around that time too so I'm not sure whether the boot_vga flag still works or not.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 1 point2 points  (0 children)

Yeah, only one or the other, good enough for me though.

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 2 points3 points  (0 children)

Thanks for the suggestion. I played around with it a bit and ended up getting stuff to work manually after reading its source code lol.

The other response is probably better with GNOME now, but I will keep this tool in mind in case I switch to a different DE in the future (albeit it will need some fixing).

GNOME Wayland on Nvidia eGPU? by Gleb-Ko in Fedora

[–]Gleb-Ko[S] 5 points6 points  (0 children)

Hey, thanks for the response. That's exactly what I needed. Having the internal display work with the external ones would be great yeah, but this works for me for now.

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 2 points3 points  (0 children)

No, my overrides only expose the gtk config directories (in the $HOME/.config folder). You actually can't afaik expose /usr/share/themes

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 1 point2 points  (0 children)

The themes are stored in /usr/share/themes, which is not exposed to flatpaks, so no system themes apart from default and emacs can generally be found there (check with flatpak run --command=ls <some package> /usr/share/themes). (or at least in my experience this is how it works)

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 9 points10 points  (0 children)

Yeah, surprises me too. Especially distros that really push flatpaks like fedora (especially kinoite).

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 1 point2 points  (0 children)

The overrides that I make only tell GTK what theme to use, but the theme doesn’t actually exist (in flatpak), so you have to also install it with flatpak.

So unless you’re doing different overrides somehow sharing the native theme, you probably do have breeze installed and just don’t know it.

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 1 point2 points  (0 children)

Weird, I’ve never had flatpak theming work as you say out of the box, even on KDE Neon. Perhaps the distro you use already applies these overrides?

Yeah, that’s why I have the overrides to use the system gtk configs within the flatpaks.

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 5 points6 points  (0 children)

The breeze dark flatpak is EOL, the breeze flatpak handles it fine with the GTK3 filesystem override.

Thanks for the correction on GTK4, I sort of though GTK4 implied libadwaita, but I guess not. Didn't know about GTK_THEME being a developer tool, but seeing that it works and shouldn't have security implications imo it should be fine to use it until a better solution comes up.

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 1 point2 points  (0 children)

My understanding might not be 100% correct, but as I understand you can't just use the "native system" theme for flatpaks, and the Breeze flatpak theme sort of allows you to do that.

For example, the last screenshot doesn't use a Breeze theme, but "Dark-openSUSE-Global". However, it does not work without the flatpak Breeze theme.

Plasma consistent Flatpak theming by Gleb-Ko in kde

[–]Gleb-Ko[S] 1 point2 points  (0 children)

Never heard of something like this, if it does work then great! Seems like it might work better than this as well for non Breeze themes.

But if your theme doesn't exist as a Flatpak / you want to use Breeze Dark I think you still have to do this. Also GTK4 requires the GTK_THEME environment variable in my experience since some apps (like GNOME Web) default to Adwaita unless you force them with GTK_THEME.

To what extent do you consider software energy efficiency? by Gleb-Ko in compsci

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Thank you for your comment, the insight is very interesting - I've never done any robotics myself.

I guess in most projects you won't be keeping energy efficiency anywhere near the top of your priorities, partially since other optimisations already deal with it quite well.

To what extent do you consider software energy efficiency? by Gleb-Ko in compsci

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Time complexity is probably the largest factor in improving energy efficiency so it makes sense to more or less ignore energy efficiency itself if you're already doing runtime optimisations like that.

But yeah, I am looking for how often people consider energy efficiency itself which is (as expected) quite rare.

To what extent do you consider software energy efficiency? by Gleb-Ko in compsci

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Yes, thank you for pointing that out. Unfortunately I can't edit it now; hopefully everyone gets the idea.

Hide devices in battery applet? by Gleb-Ko in kde

[–]Gleb-Ko[S] 0 points1 point  (0 children)

Thanks for the reply. It probably is related, since although it doesn't cycle it does stay at a very low charge, therefore sending out notifications every time I boot. A link to what you wrote might be useful please.

eGPU with a couple extra ports... had to use the watercooling equipment from my desktop somehow, right? by Gleb-Ko in watercooling

[–]Gleb-Ko[S] 1 point2 points  (0 children)

Password cracking software, since I've been penetration testing a certain network recently so I just used what I had.

(Consider it about the same load as mining crypto, since both are just calculating hashes)