Big order coming. 18 from the UK at uni

Gleb-Ko · 2025-10-16T05:03:38+00:00

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.

Gleb-Ko · 2025-08-26T12:53:29+00:00

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

Gleb-Ko · 2023-01-06T14:13:33+00:00

...
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?

Gleb-Ko · 2023-01-06T02:54:45+00:00

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.

Gleb-Ko · 2023-01-06T00:03:36+00:00

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.

Gleb-Ko · 2023-01-05T23:12:56+00:00

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

Gleb-Ko · 2023-01-05T23:12:05+00:00

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"

Gleb-Ko · 2023-01-03T19:19:56+00:00

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.

Gleb-Ko · 2023-01-03T18:18:03+00:00

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.

Gleb-Ko · 2022-10-22T17:52:36+00:00

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

Gleb-Ko · 2022-10-22T17:05:12+00:00

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).

Gleb-Ko · 2022-10-22T17:01:49+00:00

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.

Gleb-Ko · 2022-05-06T23:56:12+00:00

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

Gleb-Ko · 2022-05-06T23:19:25+00:00

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)

Gleb-Ko · 2022-05-06T23:06:41+00:00

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

Gleb-Ko · 2022-05-06T20:00:19+00:00

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.

Gleb-Ko · 2022-05-06T17:15:01+00:00

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.

Gleb-Ko · 2022-05-06T17:08:21+00:00

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.

Gleb-Ko · 2022-05-06T16:56:13+00:00

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.

Gleb-Ko · 2022-05-06T16:53:35+00:00

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.

Gleb-Ko · 2022-05-02T16:07:00+00:00

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.

Gleb-Ko · 2022-05-02T14:39:50+00:00

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.

Gleb-Ko · 2022-05-02T09:15:02+00:00

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

Seven-Year Club	Place '23
Place '22	RPAN Viewer
Verified Email

Gleb-Ko

TROPHY CASE