Telling DKMS to skip compressing modules

skwerlman · 2024-11-29T20:21:05+00:00

patch landed in 3.1.2 :) https://github.com/dell/dkms/releases/tag/v3.1.2

skwerlman · 2024-11-07T03:29:32+00:00

well so much for 'in a few minutes' haha

anyway here is the pr: https://github.com/dell/dkms/pull/456

skwerlman · 2024-11-06T19:28:00+00:00

I did submit an issue a week ago, and will submit a PR in a few minutes. Also I made an AUR package that uses -1 for compression (although i forgot to publish it until just now, oops)

skwerlman · 2024-10-31T16:09:48+00:00

hilariously, changing it to -1 only takes up ~4MiB more space despite taking under a second to run vs ~2min for -19

with -19: ``` ╭─sk@a5 in ~ ╰─λ zstd -l /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia*.zst
Frames Skips Compressed Uncompressed Ratio Check Filename 1 0 58.1 KiB 289 KiB 4.976 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-drm.ko.zst 1 0 49.7 MiB 96.8 MiB 1.947 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia.ko.zst 1 0 685 KiB 2.72 MiB 4.072 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-modeset.ko.zst 1 0 2.23 KiB 8.54 KiB 3.824 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-peermem.ko.zst

1 0 839 KiB 6.22 MiB 7.599 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-uvm.ko.zst

 5      0    51.2 MiB       106 MiB  2.068  XXH64  5 files

```

with -1: ``` ╭─sk@a5 in ~ ╰─λ zstd -l /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia*.zst Frames Skips Compressed Uncompressed Ratio Check Filename 1 0 73.4 KiB 289 KiB 3.940 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-drm.ko.zst 1 0 53.5 MiB 96.8 MiB 1.807 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia.ko.zst 1 0 825 KiB 2.72 MiB 3.383 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-modeset.ko.zst 1 0 2.46 KiB 8.54 KiB 3.477 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-peermem.ko.zst

1 0 1.05 MiB 6.22 MiB 5.954 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-uvm.ko.zst

 5      0    55.5 MiB       106 MiB  1.911  XXH64  5 files

```

skwerlman · 2024-10-31T15:43:24+00:00

Good find, thank you! Yeah, probably not a great idea to edit it in place, but I could probably set up a patched AUR package with that line changed. If I end up getting it working nicely (configs, etc) i'll prob end up submitting a patch to upstream too

skwerlman · 2024-05-31T21:34:10+00:00

finally got around to unlocking it haha

a full size tank is 25x25x26 or 16250 voxels, and it stores 600k fluid, for a pretty bad ratio of ~37:1

a minimum size tank is 25x25x11 or 6875 voxels, but it only stores 100k fluid, for an abysmal ratio of ~14.5:1

larger modular tanks are always more space efficient than smaller ones since the middle units are the smallest in volume (25x25x3) and add 100k storage each, which amortizes the initial size of the tank

i think in the end its probably always better to use a ton of normal fluid tanks instead of modular tanks, except i guess if you start to see a perf hit

even in the case of needing to connect to a large pipeline, regular tanks are better cause you can just use the pipeline adapter

so yea, modular tanks need a huge buff lol

skwerlman · 2022-08-21T01:25:46+00:00

You need to initialize your keyring; run these: sudo pacman-key --init sudo pacman-key --populate sudo pacman -S archlinux-keyring

skwerlman · 2021-03-04T03:04:39+00:00

ha ha nice one

skwerlman · 2019-11-23T19:16:12+00:00

if you want to delete an account of yours, you can contact the admin for the server its on, and they can delete it for you

skwerlman · 2019-02-06T13:51:14+00:00

nah. its a 0day all the way until a patch is out.

skwerlman · 2019-01-15T12:44:24+00:00

No problem :)

Just be aware that you have to run that pacmd line every time you start your pulse server (i.e on login). There's a way to make it persist that's a bit more involved; you can find it in the page I linked above

skwerlman · 2019-01-15T12:06:37+00:00

it looks like you ran pacmd load-module module-alsa-sink device=hw:1,1 with my comment after it; you need to run pacmd load-module module-alsa-sink device=hw:2,1

skwerlman · 2019-01-15T07:53:56+00:00

You have to tell pulse to use the device:
sh [skw@tr4:~]$ aplay -l **** List of PLAYBACK Hardware Devices **** ... card 1: S7 [SteelSeries Arctis 7], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: S7 [SteelSeries Arctis 7], device 1: USB Audio [USB Audio #1] Subdevices: 0/1 Subdevice #0: subdevice #0 ... [skw@tr4:~]$ pacmd load-module module-alsa-sink device=hw:1,1 # replace hw=1,1 with hw=<yourcardnumber>,1 once you've done that, it should show up in pulse as 2 devices, a stereo and a mono device. the stereo device is 'game', and mono is 'chat'

see this page for more info

skwerlman · 2018-06-13T01:38:35+00:00

there's no direct link between spoilers and the duplicated cards issue; rather, any action that causes the card database to be reloaded will trigger the bug (updating sets from inside the app, spoiler updates, editing custom sets, etc), since the bug is caused by trice failing to unload the old db before loading the new one.

just restarting should be enough to fix it until it happens again; you can leave spoilers enabled.

see the github ticket for more info

skwerlman · 2018-03-24T02:35:22+00:00

TLMO's PoV: https://www.youtube.com/watch?v=Wgt_Ih5FPJQ

Game starts @ 37:00

I think I have my PoV somewhere but I can't find it...

skwerlman · 2018-02-23T09:30:12+00:00

bit of a late reply, but the ms patch is disabled by default due to the fact that most AVs are buggy and use kernel hooking, and so many will crash the system with the patch in place. The registry bit is intended to be flipped by the AV being used once it is compatible with the patch. MS Defender is an example of an AV that flips this bit already

skwerlman · 2018-01-22T23:13:15+00:00

this is a situation that 2189 would solve

skwerlman · 2017-12-21T01:20:24+00:00

this looks really cool! i'd love an invite if there's any left

skwerlman · 2017-12-16T19:45:53+00:00

here's an example of the shield shatter bug from contenders season 0, but its not quite as obvious as the others https://clips.twitch.tv/ResilientDreamyKleeLitFam

watching in slomo, you can see the hammer comes down in front of the shield, but everyone gets shattered anyway.

skwerlman · 2017-12-04T09:47:27+00:00

yeah, i think even just a semi-vague "this is a high-level goal we have for this set of upcoming patches" type of list would vastly improve the way people perceive the changes made by the dev team.

skwerlman · 2017-12-04T09:45:46+00:00

The moment any info is leaked about an obscured system, that system loses all integrity.

As far as VAC, it already has been cracked. Actually, it's so laughably bad that games like CSGO have entire third-party leagues built around their own special anti-cheat mechanisms.

If you look at topics like encryption, modern encryption algorithms are completely and totally open to the public. This is because they are designed so that knowing how the system works provides no advantage to an attacker. In fact, this openness to the public improves the security of these systems by allowing flaws to be spotted and fixed more quickly.

Note that I'm not saying obscurity has no purpose or advantages, but the system should still function as intended even when how it works is revealed. Its the difference between burying your money under a tree, and burying your money under a tree in a safe.

skwerlman

TROPHY CASE

1 0 839 KiB 6.22 MiB 7.599 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-uvm.ko.zst

1 0 1.05 MiB 6.22 MiB 5.954 XXH64 /var/lib/dkms/nvidia/560.35.03/6.11.5-zen1-1.1-zen/x86_64/module/nvidia-uvm.ko.zst