1. The best engineers are obsessed with solving user problems.

Ehh. Not sure I agree. I mean, I think that there is a valid insight that it’s important to keep track of what problem you’re actually trying to solve, and that that problem needs to translate to some real world, meaningful thing for a human.

But I also think that there are projects that are large enough that it’s entirely reasonable to be a perfectly good engineer who isn’t dealing with users much at all, where you’re getting requirements that are solid that have been done by up someone else. If you’re trying to, say, improve the speed at which Zip data decompression happens, you probably don’t need to spend a lot of time going back to the original user problems. Maybe someone needs to do so, but that doesn’t need to be the focus of every engineer.

3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.

I think I’d go with a more specific “It’s generally better to iterate”. Get something working, keep it working, and make incremental improvements.

There are exceptions out there, but I think that they are rare.

8. At scale, even your bugs have users.

With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.

This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.

This is one thing that I think that Microsoft has erred on in a number of cases. Like, a lot of the value in Windows to a user is a consistent workflow where they can use their existing expertise. People don’t generally want their workflow changed. Even if you can slightly improve a workflow, the re-learning cost is high. And people want to change their workflow on their own schedule, not to have things change underfoot. People don’t like being forced to change their workflow.

The fastest way to learn something better is to try teaching it.

I don’t know if it’s the fastest, but I do think that you often really discover how embarrassingly large the gaps in your own understanding are when you teach it.

A little kid asking “why” can be a humbling experience.

If you can make a useful MoE thing where each expert model has a small final layer in its neural net, so you don’t need to move much data between cards, then running each MoE on a different card might be viable. Regardless of whether the GPU vendor wants to segment up the gaming and AI markets.

I think that that’s one of the biggest unknowns as to where AI may wind up going. If you can get good results on gaming cards, then suddenly ordinary gaming hardware, run in parallel, may be quite capable of running the important models, and it’s going to be much harder for OpenAI or similar to obtain much of a barrier to entry. That may have dramatic impact on who has what degree of access to AI.

I haven’t used it, but from a quick skim, it sounds like input-remapper can do this.

https://github.com/sezanzeb/input-remapper/blob/main/readme/macros.md

hold

Runs the child macro repeatedly as long as the input is pressed.

Examples:

hold(key(space))

https://github.com/sezanzeb/input-remapper/blob/main/readme/examples.md

key(BTN_LEFT) a single mouse-click

Debian trixie, scanmem 0.17-5+b1.

The good news is that single-player games tend to age well. Down the line, the bugs are as fixed as they’re gonna be. Any expansions are done. Prices may be lower. Mods may have been created. Wikis may have been created. You have a pretty good picture of what the game looks like in its entirety. While there are rare cases that games are no longer available some reason or break on newer OSes with no way to make them run, that’s rare.

With (non-local) multiplayer games, one has a lot less flexibility, since once the crowd has moved on, it’s moved on.

It looks like it doesn’t support ARM architecture systems at all, or anything other than x86_64.

https://docs.bazzite.gg/Gaming/Hardware_compatibility_for_gaming/

Minimum System Requirements

• Architecture: x86_64

finishes installing Pillars of Eternity

Nah, scanmem seems to work here on it. I can search for, find, and modify the value for “Resolve” during character creation using exact value searches. It doesn’t print any errors about ranges of memory or anything, assuming that that was a relevant factor.

shrugs

Sorry; whatever you’re running into isn’t something that repros here. I hope that you can get it worked out, though.

I have Pillars of Eternity and Cyberpunk 2077. Let me go see if I can run scanmem on them successfully. Actually, I thought that Cyberpunk 2077 was a Linux-native build.

goes to look

Well, neither one is presently downloaded. This may take a bit.

And yeah, you’re right, Cyberpunk 2077 is a Windows binary. Huh.

thank you for your continuing generousity with your aid and help.

Yeah, no sweat. I’m kind of curious as to what could be disrupting it. Can’t promise that I can reproduce the same behavior locally on Debian, though.

As per the last part, It apparently can sometimes find the initial value, but not any changes in the value.

Well, you’d expect to find some matches, just because some values in memory will happen to have the same value as what you’re looking for.

Have you tried doing a “relative change” search in scanmem? Use “>” and “<” for “increased since last change” or “decreased since last change”. Some environments have nonstandard in-memory representations; for example, going from memory, there’s some environment — might be some Java VMs, though not sure…might be RPG Maker games of some sort, can’t recall — that stores values as double their actual value, uses one bit in the number for something else. A relative change search will still work there. I suppose that maybe if you updated the system and are using a newer JVM, that could impact the in-memory representation, but I can’t really think of anything else that updating the system would likely do.

If you don’t mind sharing the name of some game that previously worked and doesn’t now, I might have more-helpful suggestions, especially if it’s something that I can reproduce easily locally (and can maybe see whether the same memory range permission error shows up here…). I noticed that you didn’t post the name of the game; if it’s some game that you don’t want to post the name of publicly but don’t mind sending me, feel free to PGP/GPG-encrypt your message.

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBGf6kRMBDAD3qJIznSVVQZu092nTthUt8R8DNXS6eYNqgbpYHTY+6i+RSFMe
YDDnOz0cL3drxnWpNC37l9HouJGohua/Cjx2Iju/zd4A5mZkXchIt4lfZ3bbXx2k
p0eC1m9+B3Dc37lSLPgEpTnfPGtMfKJU4bNVBdwkFCyS9Mxc499uIrAUpjPQLmgP
1rQ2Wk1wzGfAh3VNCxg8xsHcOHWQZqSUzsLk/PeG1QtfGTVBG44tI6msGawwQct6
XVnVOk0DfEGmoru4dGuQDk+oZRVz/O4/wLOQzfAVCzsbv/RrCzywrcQM3WAoVBDI
awe9UG++Y4N6Eof46UQ1KnzA2ndkHFt35KybidaqxlWM4Sslx/Is+wCgqt+FpJRN
MPLsAet6Eg6vGB6ES3Fk/IXX5OEvtWMfKKrgSP88NwoP/VFr/BU7SsJW1Opo4Ccf
DDPuWlgMCmsVE9xsPS1oFMzxiHbJYj8gWgH7AOtl24NgYXVi/QdetYA6SZqonU0T
xnGmEw5JdcvWdmMAEQEAAbQPdGFsQGxlbW15LnRvZGF5iQHUBBMBCgA+FiEE7S76
Je3x/gWVtrNsdlwPXPfD8YIFAmf6kRMCGwMFCQWjmoAFCwkIBwIGFQoJCAsCBBYC
AwECHgECF4AACgkQdlwPXPfD8YJy+wv+JJ3MP+zZRy4pJZ+u7iiSOwVVwUboT8Pi
kX7rxLl6TF9wGuLPjl/P8Cfy0WMsZQ2Ab0S/84cE2bIVbcISwqeqkMZ1Puk6y5Nn
8uHK3qHrYb1n89uOwjgeBIC3XopdJpSPtaKBWHZn/s0AYQ3suqJt/BoJo+hTv4oJ
/8Rtcs2+YKnQtoLtM/0tKO3J4Qzvqrzi0F14R1Rv6kiFzePkEPQFSPN4uIR5CPJm
t6HuYWYcWNKhfIkKJH08GAV0jP+qrbe/yacO0tKt8gnxKBdpXLRwLePx5sDV14ch
Ay/3n1aVa7PbUGA4m51xOSl0Ro54s6K8uwJ2fz6z5fdjpOkbvDw51tPEdxQzW0JH
myyaC31j4h5YwzOAfGaK6lp3pAHStDFhDJXZPLYsDlcMGSPvV+qBMAh86t8mqIqd
tBPjNj60aIbps+mImBpRlO/xRvUWjjVsm1FKqxBq7QQR5SW0MLnkwvcnUMDCbOs/
wMN6ghyZp6RDhUXGgb9HJVSQhXLjaqf+uQGNBGf6kRMBDADFYNE00Rr2Ujm9+i7k
LsHz49xqJUNtv3b7pHWTOZNhkSFf/OieayE45lkBMQl1ZkuY56QjmcgYZWsOf7+y
kbrsQjdNE5lHl/hRAqGV13LUscTKPUCvTXnfFX+/p64Kgv1f74fAdfkQu663sGOM
xbFP9/3jOQLF9dI2M8H14TPF/JDhjXDZvvoMrMBxwFlRctvwbeS6Yar+XKxKZQvh
I63Ad2OyFc0p+pnJOnrWN3Q6iEqnAq0SA/EdsjVx3MWpqZW15YDyU0lIWrHAn/yD
PfMaAqcgXj2LLBDziYdfm1ACBceS+WAu6w7i07xMAbdypKOsPB2cL1PlX//WEiwW
55iBTJ7oRAW7Q0LRsk2k40mq61xfOLyOBT8gHJfEb7ked9KuSXQdBn9K2hT2SH+U
OT2E63ShPHL9F2F1yQSbjFbHJve2klIuqrMeJ21QtDWgz+Auzp7PPWZ59SN+XCVj
qzrueXIvzsK3Shfqf636/Buj1g5heIY3nBd3dtbq4gUBO90AEQEAAYkBtgQYAQoA
IBYhBO0u+iXt8f4FlbazbHZcD1z3w/GCBQJn+pETAhsMAAoJEHZcD1z3w/GCzXkL
/i1k5ra/YZPpiJgCOO61x6Iog5/hyL/APhHT/CMg1ZAYObfqCD0QT0f+n0qdZXhH
ALGXzCMsbFqr0oxqOFFccLGQzUxv9AkyrO94HLoL726fxi3gkF+UekHjWgcxkcXQ
PHZCOdHczxyCIGRB+mKn+tGweXpCwMNkymagdoyzOs+t+5cGUTv18ceun72Mqf1H
4vCZ4LLb94NLkSJqGKeQuzjVhopDVCJ8t/exRuk2ra2SkeChKPCpq5zJP+OpzAx3
hPNSL9v8xRD6D/NKQP/zYXvry1dfQaaOYUbw+GMgSxtVNsTyGMtDg2kE8ZSuvVKq
ZIoODdjZRZvTB90+UKFRF3st1MeBXGNskvcZJhit7K1eMGhUbjykNWrq0A8aoRAN
P0DBRg09Uumub1GNnJlHFNxAS5e0A686YHzA6AOify+lhscdrFKiv8GRFBZGK39W
vY5YDDdpY632O6w1Te1UFIhS7pIWXsm5AfffFPDc/UJd6ZaBOcnKH45R4y2qObS2
eA==
=ommg
-----END PGP PUBLIC KEY BLOCK-----

my ptrace_scope file has 0 set inside it, which i assume is the least restricted from what i’m understanding and shouldnt be causing the issue?

Yeah, then that restriction isn’t the problem. Sorry; I guessed wrong.

but just on an off chance i tried to run the echo command, and even with sudo it says i dont have permission. so I dont know whats up with that.

It won’t help here, but for future reference, what you likely did is this:

$ sudo echo 0 >/proc/blah/whatever

sudo runs a command as root. The file redirection, however, is done by the current shell, which isn’t run as root, not by echo. So echo 0 is run as root, and then bash tries to open /proc/blah/whatever and doesn’t have permission to do so, and that’s what fails.

If you need to do this in the future, you can do this:

$ sudo -s
# echo 0 >/proc/blah/whatever

we currently have 14 matches

It might be okay to hit that, as I don’t know if scanmem avoids trying to scan all regions that it can’t read. That does mean that it is able to ptrace() it and find some matches. Did you try to keep going with additional searches to see if it could actually find the value and change it?

Issue is, not only do do my emulators not recognize these buttons, but is seems Linux Mint doesn’t know they exist at all. Even bringing up a program to map buttons to keys doesn’t show any input when those buttons are pressed.

Generally, USB HID permits lots of buttons to be reported. While I can’t say that it’s absolutely certain that 8bitdo requires some sort of proprietary protocol to expose the button events for some of those buttons, my bet is that they’re reporting them.

I don’t know what program you’re using, but there are at least three APIs that I can think of that they might be using.

• (Old) Linux joystick API. $ jstest /dev/input/js0 to see what’s going on there (assuming a single game controller on the system). In the joystick package on Debian. I have seen systems before that have this disabled to try to deal with programs that double-report button events for joysticks visible both under the joystick API and the libevent one.

• (New) event API. $ evtest. All of your other stuff, like mice and keyboards, will also be visible here, and you’ll have to tell evtest which device you want to see events from. In the evtest package on Debian.

• Steam has its own input API, Steam Input. Steam Input will internally be using one of the above, but it could be fiddling with things, like, not sending button events or something, and a lot of games on Linux under Steam will be using Steam Input.

There are also other (thinner) libraries that will map one of the two kernel APIs to their own API, like SDL. Couldn’t advise what your emulator might be using without knowing what emulator you’re trying to use.

I also have an old Logitech F710 around here somewhere that has a switch on it to cause the controller to report (on Windows) via (old Windows) DirectX or (old Windows) XInput. In the DirectX mode, it doesn’t report as much information. Probably not what you’re seeing, but thought I’d mention it as a possibility.

$ man 2 ptrace

/proc/sys/kernel/yama/ptrace_scope
   On  systems  with  the  Yama  Linux  Security Module (LSM) installed (i.e., the kernel was configured with CONFIG_SECU‐
   RITY_YAMA), the /proc/sys/kernel/yama/ptrace_scope file (available since Linux 3.4) can be used to restrict the ability
   to trace a process with ptrace() (and thus also the ability to use tools such as strace(1) and gdb(1)).   The  goal  of
   such  restrictions  is  to prevent attack escalation whereby a compromised process can ptrace-attach to other sensitive
   processes (e.g., a GPG agent or an SSH session) owned by the user in order to gain additional credentials that may  ex‐
   ist in memory and thus expand the scope of the attack.

   More precisely, the Yama LSM limits two types of operations:

   •  Any operation that performs a ptrace access mode PTRACE_MODE_ATTACH check—for example, ptrace() PTRACE_ATTACH.  (See
      the "Ptrace access mode checking" discussion above.)

   •  ptrace() PTRACE_TRACEME.

   A process that has the CAP_SYS_PTRACE capability can update the /proc/sys/kernel/yama/ptrace_scope file with one of the
   following values:

   0 ("classic ptrace permissions")
          No  additional  restrictions  on  operations that perform PTRACE_MODE_ATTACH checks (beyond those imposed by the
          commoncap and other LSMs).

          The use of PTRACE_TRACEME is unchanged.

   1 ("restricted ptrace") [default value]
          When performing an operation that requires a PTRACE_MODE_ATTACH check, the calling process must either have  the
          CAP_SYS_PTRACE  capability in the user namespace of the target process or it must have a predefined relationship
          with the target process.  By default, the predefined relationship is that the target process must be  a  descen‐
          dant of the caller.

          A  target  process can employ the prctl(2) PR_SET_PTRACER operation to declare an additional PID that is allowed
          to perform  PTRACE_MODE_ATTACH  operations  on  the  target.   See  the  kernel  source  file  Documentation/ad‐
          min-guide/LSM/Yama.rst (or Documentation/security/Yama.txt before Linux 4.13) for further details.

          The use of PTRACE_TRACEME is unchanged.

   2 ("admin-only attach")
          Only  processes  with  the  CAP_SYS_PTRACE  capability  in  the user namespace of the target process may perform
          PTRACE_MODE_ATTACH operations or trace children that employ PTRACE_TRACEME.

   3 ("no attach")
          No process may perform PTRACE_MODE_ATTACH operations or trace children that employ PTRACE_TRACEME.

          Once this value has been written to the file, it cannot be changed.

$ cat /proc/sys/kernel/yama/ptrace_scope
0
$

If you don’t have 0 there, you might try, as root, echo 0 > /proc/sys/kernel/yama/ptrace_scope and see if everything starts magically working.

If it does, to make said setting persist, you might want to add “kernel.yama.ptrace_scope=0” to /etc/sysctl.conf to apply that setting at boot.

Also, probably won’t address your issue alone, but I use scanmem, a Linux CLI program, for memory-modifying cheating. If there’s some failure in trying to do its ptrace thing, it might display an error message in the console. If you want, rather than changing the systemwide ability to use ptrace, you could also just run scanmem as root (you could also do the same with GUI programs, but more hassle, and honestly, I’ve never gone to look up how to make that work under Wayland, just Xorg, where # xauth merge ~/.Xauthority will do it).

EDIT: It looks like the Fedora guys were thinking about changing their default away from 0, and if the Nobara people just did so, that might be what’s triggering that.

EDIT2: I thought that Debian did it too, since I remember smacking into that at one point, but I don’t see anything in my sysctl.conf, and I can still happily scanmem; it’s 0 on my system. Sounds like what happened was that they changed it to 1, decided that that was a bad idea, and then put it back to 0, so I probably tried using it during that window.

EDIT3: Just to clarify, ptrace() is the system call that most processes use to access another process’s memory, and is probably what your memory-cheat program is using to try to look at (and modify) the memory of that other process.

Last I looked, I believe that elinks was the most-sophisticated of that family.

Lead image seems a cyanide and happiness cartoon,

It doesn’t claim to be a Cyanide and Happiness cartoon anywhere in the cartoon.

Systemd is unnecessary bloat. Actually, having an init system is unnecessary bloat. All one really needs is the Linux kernel and emacs.

http://informatimago.free.fr/i/linux/emacs-on-user-mode-linux.html

deleted by creator

The fanboying to the point of blinders is maddening to deal with among Linux users.

Alien who has arrived on Earth: “I’ve heard that you humans drive motor vehicles to get around. I should get a motor vehicle. Could someone tell me the best type to get?”

Human A: “You want a Prius.”

Human B: “No, that’s for tree-hugging, probably-homosexual hippies. You need a proper truck, a Ford.”

Human C: “Actually, Ford trucks are trash, what you need is a Chevy truck.”

https://www.youtube.com/watch?v=ZgeIiREvafQ

Frankly, the right answer is that pretty much any non-specialized distribution (e.g. don’t use OpenWRT, a Linux distribution designed specifically for very small embedded devices) will probably work fine. That doesn’t mean that they all work the same way, but a lot of the differences are around things that honestly aren’t that big a deal for most potential end users. Basically, nobody has used more than at most a couple of the distros out there sufficiently to really come up to speed on their differences anyway. Most end users can adapt to a given packaging system, don’t care about the init system, are aren’t radically affected by mutability/immutability, can get by with different update schedules, etc. In general, people tend to just recommend what they themselves use. The major Linux software packages out there are packaged for the major distros.

I linked to a timeline of Linux distros in this thread. My own recommendation is to use an established distro, one that has been around for some years (which, statistically, indicates that it’s got staying power; there are some flash-in-the-pan projects where people discover that doing a Linux distro is larger than they want).

I use Debian, myself. I could give a long list of justifications why, but honestly, it’s probably not worth your time. There are people who perfectly happily use Fedora or Ubuntu or Arch or Gentoo or Mint or whatever. A lot of the differences that most end users are going to see comes down to defaults — like, there are people in this thread fighting over distro because of their preferred desktop environment. Like, Debian can run KDE or GNOME or Cinnamon or XFCE or whatever, provides options as to default in the installer, and any of them (or multiple of them) can be added post-initial-installation. You wouldn’t say that a car is good or bad based on the setting of the thermostat as it comes from the dealer, like.

…having their own things to tend to.

“NetBSD!” “No, OpenBSD!” “No, FreeBSD!”