kmeaw

86Box is just accurate enough to run the original unmodified firmware. It does not emulate cache and RAM behavior, so you won't get performance-related accuracy. You are likely to succeed in Spectre-like attacks against an emulated 386, which shouldn't be possible on a real thing.

If you don't care and just want to go faster on a modern x86 CPU, you can replace the CPU emulation part of 86Box with a hypervisor. I tried running a Socket 7 motherboard firmware on Linux's KVM - given the chipset emulation is correct, it works: it amusingly identifies an AMD Zen5 running at 3GHz as "Unknown-S CPU at M60MHz" and boots to a DOS prompt.

Sometimes having generic Linux capabilities on network equipment makes it hard to understand the configuration. On RouterOS you can just /export the configuration and read a single file. On Linux/SONiC there are multiple ways to do the same thing - you can do one part of configuration using ifupdown, then make some changes in systemd-networkd, a bunch of shell-script DHCP client hooks, rc.local, cron @reboot. Imagine being handed over a router that someone has fixed by doing some runtime reconfiguration (like `ip ro replace default via 192.168.0.1 advmss 1410`) that would vanish with almost no trace (except maybe .bash_histotry) when you reboot it - that won't be possible (without doing very special scheduler/script trickery) on RouterOS.

But if you still want it, MikroTik doesn't try too hard to prevent you from running modified software. You can port OpenWrt, and most modern MikroTik devices use modern enough Linux to use a device tree blob. Try pulling out a dtb from your firmware and ask an LLM to do the initial porting - just don't forget to backup your RouterOS license key first, they are device specific.

Sure, even @Autowired

Why Postgres should be doing this? Not every client creates a lot of connections and spinning up PgBouncer is easy. On the other hand, debugging async multithreaded complex code is hard.

If you give your agent a `bash` or `python -c` tool, it starts a separate process that produces some output and then exits. After that, only the output and the exit code are available.

In contrast, `eval` runs the code in the same execution context as the agent loop. When `eval` finishes, that execution context still exists. For example, any functions defined during an `eval` call remain available for later use.

I remember a cool implementation detail about the earliest Knoppix version (don't remember which one) I had that was documented somewhere on that disc - when constructing a release filesystem image, the boot process was instrumented to get an ordered list of files being read. Then that list was fed into an image building program so when written to a CD, the files will be organized in an optimal order so a linear read with some readahead would get you a better boot time.

Would it be legal to create similar incompatibilities if there is both a legal business justification (that particular solution can be implemented in X developer time and would cost us Y money which wins against a proper implementation) and an engineering justification (that particular solution would use X less bytes of disk/RAM and would run better on Y% of our customer's machines) for an implementation which heavily depends on undocumented internals of another product?

What is the INTR?

Then you would be fine if your VPN provider: a) either relies only on ISPs following Russian laws; b) or technically enforces restrictions specified in Russian blacklist.