pastaq

joined 2 years ago
[–] pastaq@lemmy.world 54 points 3 weeks ago (4 children)

My feed contains a problem, then the solution immediately after.

[–] pastaq@lemmy.world 36 points 1 month ago (1 children)

It's still weird to see articles about my work on Phoronix. Neat though, thanks for posting.

[–] pastaq@lemmy.world 29 points 2 months ago

I was called a communist at work a few years ago because I said, factually, that a lot of the memes about AOC being dumb were of entirely fabricated quotes.

[–] pastaq@lemmy.world 1 points 3 months ago

At the very minimum, I need a house with a yard + garage (I'm tired of condo/apartment living) and affordable gigabit internet. No legal weed is a deal breaker as well. Can't eat or sleep without it.

You're discussing servival and all your examples of why you can't leave are that it seems inconvenient to adjust. Either you're not actually worried about the outcome of staying or your priorities are backwards.

[–] pastaq@lemmy.world 3 points 3 months ago

Whamp whamp What's new pussycat...

[–] pastaq@lemmy.world 7 points 5 months ago

Then they should say they hate flatpak, or they are frustrated/disappointed when something they are interested in is only on flatpak.

Instead of doing that, they said they hate people who only use flatpak. Words matter, and that kind of entitlement needs to be shut down. The devs don't owe them anything and they certainly don't deserve hatred for their packaging solution. There are many constructive ways OP could resolve the issue. Open a feature request issue on the bug tracker, build it locally, send an email, offer to maintain another packaging method, etc.

[–] pastaq@lemmy.world 93 points 5 months ago (5 children)

You hate people who spend hundreds of ours of their free time developing software, who then release that software for free, under no obligation to you or anyone else, and your reasoning is because they provide it in a packaging solution you don't find ideal?

Maybe fuck off and write your own software.

[–] pastaq@lemmy.world 1 points 5 months ago

Yes, but not on SIPRNet, which was my point. Even inside a SCIF "SIPRNet" is too low a classification network for this discussion, and SIPRNet can be accessed outside of SCIFs in spaces cleared for up to Secret.

[–] pastaq@lemmy.world -2 points 5 months ago (2 children)

Well, ish... SCIFs are used for the collection, dissemination, and storage of Top Secret/SCI material. Secret Internet Protocol Router Network (SIPRNet) is only cleared for up to secret level material. There are higher classification networks they should have been using instead.

[–] pastaq@lemmy.world 3 points 6 months ago* (last edited 6 months ago)

Udev is the best way to add persistent values for pretty much everything in the sysfs. That being said, it can be a bit obtuse when first learning about it. Here are some tips

udevadm test /sys/path/to/device will tell you if your rule is running and what the state is at each step. You'll want to look at this before you start so you can see when your rule should run

udevadm info /sys/path/to/device will tell you what the PROPERTIES of a device are. These are usually set by hwdb files to inform userspace programs about the details of a device.

udevadm info /sys/path/to/device --attribute-walk will tell you about the ATTRIBUTES of a device and all it's parent devices. These correspond to the character file endpoints you are setting currently. You'll want to use these to write your match rules and set the values.

udevadm monitor can be used to watch for udev events to let you know if you should match on add, change, and/or remove.

Udev rules work as a cascading match system and they run in numerical and directory order. E.g. /usr/lib/udev/rules/60-keyboard.rules will run before /etc/udev/rules.d/62-keyboard.rules but after /etc/udev/rules.d/60-keyboard.rules

For user defined rules you will want to put them in /etc/udev/rules.d/ and keep in mind any state that needs to be set before or after your rule.

Matching happens with == or !=, setting attributes is done with =, +=, -=, or :=. := is really cool because you can use that to block changes from downstream rules. E.g. MODE:="666" will make the matched attribute r/w from unprivileged users, even if a later rule tries to set 400.

Udev rules will run in order in a file, but each rule must be a single line. Each attribute will also be set in order of the rule if setting multiple attributes in a rule. Multiple rules can be useful if you need to set attributes on multiple levels of a device, or in sibling directories.

For a complete breakdown of everything, see the udev manual: https://man.archlinux.org/man/udev.7

I also have a guide on one of my (currently out of tree) drivers that has some examples. https://github.com/ShadowBlip/ayn-platform?tab=readme-ov-file#changing-startup-defaults

Let me know if you have questions.

[–] pastaq@lemmy.world 2 points 2 years ago (1 children)

The game studio only has one game...

view more: next ›