It's a custom fork of plain Lua, not LuaJIT, so indeed there's no LuaJIT support. They first open sourced it this November and supposedly they're planning to implement their own JIT. There's no timeframe or estimate for that though, just mentions of plans to here and there.
Sounds good. I won't cycle back to finish Lanarts for a while so I look forward to a JIT in this space. LuaJIT was a marvel but it probably needed a few more years of Mike Pall's time to smooth out difficult to anticipate optimization
I'm actually curious about this since I've never uploaded to youtube myself. Do the creators get statistics on segments that are commonly skipped, or is all information like that hidden?
I used to have a setup similar to this, where I had a Windows 10 install and a Linux install on different partitions, both being able to boot into the other through I think VMWare?
Had the same experience, it worked surprisingly good and was easily good enough for daily use.
Naturally that's also the regular way you can also boot into either partition bare metal when you want.
Unmounted or hidden, an additional separate specialized FAT32 boot partition has been common for Windows since long before UEFI & GPT partitioning became mainstream.
Usually the first active primary partition on a Windows 7 BIOS PC, a few hundred megabytes of FAT32 were there specifically to hold the BOOTMGR file and its associated BOOT folder, (where you could build a Windows bootmenu) which would point from there to any of your main NTFS partitions that had a version of Windows installed.
That regular Windows bootmenu (in BIOS) could also be used to point to the GRUB-based bootsector from a type 83 EXTx Linux partition on the same HDD. This would boot the Linux like normal. Even though Windows would not mount nor access the Linux partition. But Linux could mount and access the Windows partition.
Alternatively, on a fresh BIOS partitioning layout, the FAT32 Boot partition can be upsized to a few GB (instead of mere MB) and then a copy of an entire live Linux fileset from the bootable Linux DVD can be placed there right next to the Windows BOOT folder. The contained live Linux squash filesystem is then booted into memory from the FAT32 volume using the Windows bootmenu, with GRUB, or even Syslinux which can boot the Isolinux-launchable DVD fileset when the fileset is stored on a FAT32 volume.
An advantage of this arrangement is so (live) Linux is avaiable bare metal when needed on an otherwise unchanged Windows PC, without having any EXTx partitions. As more distros gained access to NTFS it became possible to place the Linux live folderset right there on the NTFS volume alongside Windows, so there was another option.
In BIOS mode Windows 10 (and even Windows 11 in BIOS for extra credit) works just like Windows 7 for this.
For UEFI a FAT32 ESP is almost always in use but Windows bootloader will not boot Linux in UEFI. But the /EFI/BOOT folder in the UEFI ESP is not dedicated to Windows like the BOOT folder was under BIOS. /EFI/BOOT contains the key BOOTX64.EFI file which is basically a renamed OS-specific bootfile placed there by the most recent OS that was installed or had its bootfiles updated in common ways.
BOOTX64.EFI then points hardcodedly to one of the associated /EFI/Microsoft or /EFI/ubuntu, etc folders there on the boot partition which will contain a Windows or Linux bootmenu accordingly.
The /EFI/Microsoft folder contains the regular Windows bootmenu which accesses any of the Windows OS's that are installed on any of the NTFS[0] partitions that are unhidden at the time.
The /EFI/ubuntu folder contains the GRUB bootmenu which accesses any of the Linux OS's that are installed on any of the EXTx[0] partitions. Additionally the GRUB bootmenu can be configured to have a Windows bootentry which then chains to the regular Windows bootmenu in /EFI/Microsoft/Boot/BCD. Also in GRUB a bootentry can be added to launch a live Linux fileset stored on a sizable enough ESP FAT32 boot volume similarly to how it's done in BIOS.
Interestingly, on a Windows XP PC to begin with you could install to a different folder than the default WINDOWS (such as WINNT or WINXP). Afterward if you protectively renamed Documents and Settings & Program Files from the command line of the NT6 install DVD, you could then install NT6 into its own default WINDOWS folder alongside XP on the same partition without conflicts. The real Documents and Settings can then be unveiled and an NTLDR entry added to the NT6 bootmenu. BOOT.INI can then handle the NT5 & DOS booting as before and NT5 when booted can share the Program Files folder with NT6 as long as you are careful, since NT5 does not need to run anything in the Program Files folder when you boot. Often you can install an NT5 program into the same Program Files folder shared with NT6 this way and there is no conflict whatsoever.
[0] a wider variety of filesystems are becoming supported as years go by.
Rust almost does the exact same thing, so I'd say it's fair. Dependencies (crates) are grabbed in source format and compiled locally as part of the build process, and installing Rust programs through Cargo also compiles them (and their dependencies) locally.
Some crates have the same issue where build scripts rely on outside tooling being installed, but it's definitely not common to (unless you're relying on compiling C/C++ code for FFI for example, in which case it's somewhat frequent).
I think there needs to be a distinction between fetching crates as source at _build time_ and what happens with Python. Python's "build time" will still require the source to be present on the target machine it's deployed to -- unfortunately these tools are complex because "packaging" is only half of the issue, it's also the distribution and _deployment_ which makes things messy.
Consider that, even if you want to use packages only from your application's virtualenv, the default (footgun warning!) is that Python will still use the "system" packages -- this means you may have installed Ansible or some other tool that relies on Python and many packages from the distro package manager. But your app could pick up one of those dependencies! At best, this will work fine. But in the worse cases, perhaps it subtly behaves differently or simply does not work at all.
My understanding is that Rust will, by default, statically link all of these dependencies. This, in Python, would be like a "pex" or "par" (or one of the many other options :^)), which does make the distribution aspect much simpler. (At the cost of build-time complexity, slowdowns, and occasional incompatibility.)
Valorant specifically actually does this to a degree, and there was a quick article written by one of their anti-cheat developers that roughly explains their approach.
I've successfully used Fiddler Classic as alternative to Charles to look at live websocket traffic when debugging things before. Websocket support in general is a bit of a hidden feature though since you need to go to the request that established the connection and double-click the websocket logo to the left on it, which opens a new panel showing its traffic.
The newer "Fiddler Everywhere" might also be able to do it, possibly even better, but I dislike the UI and I'm used to Classic so I've stuck to that.
