HN user

kmeaw

18 karma
Posts0
Comments9
View on HN
No posts found.

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.

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.

Knoppix 22 days ago

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?