> Traditionally, programs will place their code into non-writeable memory, and store variable data in memory that is writeable but not executable. And that's definitely the safer way to do things, but we can't be bothered with all that.
Woah, I have a feeling this does something even more. If the program modifies its own instructions, the kernel will probably save those modifications in the file too.
That would be the behavior with the mmap(2) flag MAP_SHARED. The module built in the article uses MAP_PRIVATE. Any changes to the contents of a private mapping do not effect other processes or the file.
This is a little extra. What you can generally do is immediatelly after chroot just run 'mount -a' to mount everything from the chroot's fstab. The empty `/boot` probably already exists.
arch-chroot [1], despite its name pretty much does all the `mount -t proc` stuff the post says. It's also available on other distros like debian [2]. I have used it in the past to chroot into fedora as well.
It can go higher actually, just that when I setup my test devices I had a "ought to be enough for everyone" moment when typing `options amdgpu gttsize=110000`. I guess this number spread too far, heh.
I've found the MiSTer community to generally be pretty helpful, but there are definitely exceptions. The fact that its a project that aims to perfectly match the behavior of the original hardware leads to some strange arguments.
It's infuriating how the client must be stateful and have local storage, for both the access_token and the last message recieved. That's right you must remember as the client where the last events [1] you've seen (even if you already told the server to mark it as read) was or else the server will happily send you the same messages over and over again across restarts of your client.
I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).
> Multiple View Geometry in Computer Vision, Richard Hartley and Andrew Zisserman, [117] (some sample chapters are available here, CVPR Tutorials are available here)
Heh, about 10 years ago I read that book and figured out a few things:
* triangulate position in 3d space of an object given a few 2d pictures (from known camera locations, ie: camera intrinsic and extrinsic matrices)
* how to instruct my friend to make a simple 3d rendering "engine"
Nice to see the same stuff distilled into an article.
reply