CyberShadow

Using CMOV vs. branching seems like a strategic decision which does make sense to fall under the programmer's decision making, as there is a trade-off of always calculating a value which may be unused vs. the cost of the conditional branch.

Would using compiler intrinsics instead of raw assembler have any benefits here, such as being applicable to more architectures?

I think it's more likely due to that native-Wayland windows are not visible to XWayland clients. XWayland clients, however, see all other XWayland clients' windows.

Unfortunately, with Wayland's growing popularity, such programs will not be able to run on the Linux desktop for much longer.

Git can be very performant if you use a good interface to it. Unfortunately, the CLI interfaces are slow, and e.g. libgit2 is a bit awkward to use. However, there is the object reader and writer interface, which allows reading and writing raw Git objects to its database - with it, you can build some nice high-performance tools.

For example, here is a program which, given a file's SHA1 and path, finds the last commit to have that file version at that path: https://github.com/cybershadow/misc/blob/master/git-find-fil...

I believe Matrix spaces are very much like Discord "servers".

In this case it is not parsed by the shell. Double quotes disable parsing just as well as single quotes for ~. Try running the command in the video and then run "env".

Not to be confused with https://github.com/CyberShadow/DFeed (admittedly poorly named) :)

You can use ~ in PATH? This seems to go beyond normal shell expansion - even `which` returns a path with ~ in it, so it must be aware of the syntax.

The video on the main page is amazing. Rare that a product demo video is both entertaining and informative with a high information density!

I found a different solution to the "getting around the screen" problem: set your keyboard repeat rate to 100 keys/s.

Upside: works anywhere, much lighter mental load, relatively easy to learn and adjust to.

Downside: some programs (ironically, mainly Emacs) can't keep up, and scrolling becomes choppy.

On Linux this is quite easy. When I was using Windows, there was no good solution for USB keyboards, so I hacked up a driver to do it: https://github.com/CyberShadow/KeyboardEmperor (signing keys not included).

This is subjective to my non-native English skill, but I found the editorialized title much more misleading. "Voluntarily" to me meant with zero obligation or coercion, explicit or implied, from any authority, i.e. doing it out of their sense of duty or something like that.

Happy to compromise on that both titles are not ideal :)

Title is editorialized by submitter. Actual title: "Google Removes Pirate Bay Domains from Search Results Citing Dutch Court Order".

I think having it produce good output on nonsensical / obviously wrong code would be a very different target than explaining commonly found code, so your expectation is a little unreasonable at this point.

Unfortunately you can't do ioctls with io_uring, so you can't use it for cloning ranges...

Copy-on-write and hard links are different things. A file clone would, though (as in cp --reflink).

What is copy_regular_files? All I found is some Rust code which does not use a single syscall as claimed (it takes file descriptors, so you need to open/close it anyway).

> uses copy acceleration when the file system supports it

I thought that refers to clone_file_range, but that doesn't seem to be the case. As such, I would recommend looking into that, I believe it's supported on btrfs and XFS currently in Linux.

There is also sendfile, but it's probably the same as copy_file_range.

Good to know. Perhaps the US law makes more sense here, because banning reverse engineering by itself is not really enforceable.

For Europe there is the EU Directive 2009/24/EC, and I think I remember reading something almost like that predating it by many years in some country's (possibly mine) legislation.

Sorry, that's off the mark.

> The kind of reverse engineering ZRET do is made legal because the fans involved did not use any leaked content.

IANAL, but - there's no way that can be true. Reverse engineering of machine code is generally forbidden except for very specific exemptions, like compatibility with other systems. Furthermore, even under such exemptions, you are still generally not allowed to share the results.

Even putting reverse engineering aside, they are still distributing code that was written by Nintendo (although meticulously transformed in a way that makes reading and modification much easier), and which still belongs to them.

What would have been legal is if either this was a black box reverse engineering effort, in which all code was written without ever looking at the original machine code, or releasing a tool which fully automatically decompiles the ROM (which is not included with the tool, and must be acquired separately, probably from dumping a cartridge).

(Had to research this subject a bit as part of my collaboration on https://github.com/Davidebyzero/Snipes)

The site does not send a Content-Type header for the main web page, so I get a download dialog when trying to open it.

From the title, I thought this was about finding the implementation for various components in the Linux kernel.

There will always be 100 pixels, however, they will no longer be arranged in a perfectly straight and consistent line any more.

> new_image(x,y) = old_image(y, old_height - x)

If you implement this as a view (rather than imperatively), you can get the compiler to optimize out four successive rotations to nothing :)

https://blog.cy.md/2014/03/21/functional-image-processing-in...

There is an algorithm to rotate an image by any angle (not just multiple of 90), and without adding, duplicating or deleting pixels, using three shear operations (which only move rows/columns along one orthogonal axis).

https://www.ocf.berkeley.edu/~fricke/projects/israel/paeth/r...

> To be fair though, the freeze was probably caused by a xul extension.

No, it's still there even in the most recent version. (Maybe I just have too much mail?)

Perhaps odd, but I've had the opposite experience.

I switched to Thunderbird at the same time I switched to Linux; after some tweaking, I was mostly happy with it.

Then, in some major version, it started frequently freezing up for thirty seconds at a time. Authoring emails in it became impossible. I could not downgrade it because it was version-locked with some system libraries (libnss OSLT). I could not debug it because that was blocked by a bug filed on Bugzilla ten years ago with no fixes or workarounds.

Then, in another major version, they killed XUL extensions.

I still hope to stop depending on Google services some day, but at that point I would probably switch to or write some webmail with a similar-enough UI to Gmail.

I <3 magit.

I believe I was the first to implement a major feature in it which was rejected upstream! So now I maintain a fork :)

https://github.com/magit/magit/issues/4285

Thankfully, package managers such as straight.el make it very easy to configure using a fork of some repository, without breaking dependencies.

CPUs already adjust their own frequency based on load and temperature (maybe with some help from kernel drivers). It would be nice if the README explained how this tool is different from that.

> I just can’t go back to Debian or Arch after this, I’ve tried.

I tried to solve many of the same problems in Arch Linux with aconfmgr. It attempts to achieve reproducibility by using a model where the state of the entire system must be represented in the configuration file, and it helps transcribe any changes back to the configuration (unlike classic configuration managers, which only manage what is declared).