My ISP has IPv6 since years and I'm on 6 as well.

NAT-less network is really cool, I can serve content directly from anything from my LAN.

We should really leave IPv4 and move on.

I'm wondering which overcommit strategy this example referrs to.

Because If my bitcoin price checker built on electron will start allocating all memory on the machine, then (assuming no overcommitting takes place) some arbitrary process (e.g. systemd) can get malloc error. But it's not systemd's fault the memory got eaten; so why it's being punished for low memory conditions?

It's like choosing a random person to be ejected from the plane.

Well it's ASCII-themed but it's completely unreadable in terminal links/lynx.

This one is truly a gem:

https://httptoolkit.com

It even bypasses SSL pinning on Android using 1 click.

Why not COBOL?

Plankalkül or bust.

https://en.wikipedia.org/wiki/Plankalk%C3%BCl

Its niche. Lisp, Cobol, Fortran, Algol 58 - oldest and moat commons langs

COBOL is some five years newer than Fortran. You could try FLOW-MATIC.

Nah.

> Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable. Because management was too reactive and cancelled a project mid-flight. Because someone's ego wouldn't let them see a better way of doing things.

I mean true, technical debt is people's problem. Why it exists? Because there are not enough people in the team. Because they are not skilled enough. Because the devloper has promised they'll finish up the task before Christmas but failed to deliver.

I don't really like marketing, but they serve an important function: they convert code to money. Code itself isn't worth anything, only marketed code is worth something. That's why it's so hard to refactor.

Also there's this unofficial law in programming: code that is easy to refactor at some point is going to be replaced by code that is hard to refactor. Sometimes people misidentify what exactly is code debt and convert blocks of code that aren't code debt into exactly code debt which is later impossible to remove, because they thought they knew better.

Rust fork that works on this LLVM fork, for 6502, genering code that can be executed on a Commodore-64: https://github.com/mrk-its/rust-mos

Well, there was also Java on Amiga project:

https://www.mikekohn.net/micro/amiga_java.php

Doesn't work for me, and the account creation window itself is buggy with poor UX, throws a general error and requires me to retype password each time I try to use a different set of settings.

Tried to use Nim with VBCC to cross-compile to Amiga, but I failed. I think Nim does some pretty heavy assumptions about the C compiler that is used to compile the generated code.

Just in case you aren't in the loop, but there are gcc and llvm based Amiga cross compilers.

GCC cross-compiling for the Amiga is available from https://franke.ms/git/bebbo/amiga-gcc for a standalone toolchain, and https://github.com/BartmanAbyss/vscode-amiga-debug for one that requires VSCode.

I'm not aware of any working LLVM solution? All I know is that LLVM supports MC680x0 as a backend, can spit out 68k-but-non-amiga-objects and some brave souls have trying to use vlink or mold to produce Amiga executables. Have you seen any working LLVM-based Amiga (680x0 in hunk format) cross-compilers in the wild?

I probably just confused m68k support with HUNK support. Maybe one could use https://github.com/BinaryMelodies/RetroLinker

Or https://franke.ms/git/bebbo/elf2hunk/master/elf2hunk.c

Actually I wasn't able to do it also with Bebbo's GCC fork.

Never used Nim before so I might be doing something wrong though.

I wish retro Amiga had Rust support. I've briefly skimmed what would be necessary to do, based on the rust-mos (Rust for commodore-64 fork), but I'm too weak in LLVM internals to actually do it.

> Never used Nim before so I might be doing something wrong though.

With Nim on weird targets you usually want:

- OS target = any

- Memory Management = ARC

- malloc instead of default Nim allocator

- turn off signal handler (if not POSIX)

- disable threads (most of the time)

Then look at how C is compiled and copy all compiler+linker flags to your Nim configuration. Here's an absolute minimal `config.nims` I used to compile Nim for C64 with LLVM-MOS[1] toolchain:

    import std/strutils
    
    --cc:clang
    --clang.exe:"mos-c64-clang"
    
    --os:any
    --cpu:avr
    --mm:arc
    
    --threads:off
    --define:usemalloc
    --define:noSignalHandler
    
    let args = [
      "-isystem $PWD/../mos-platform/c64/include",
      "-I$PWD/../mos-platform/c64/asminc",
      "-L$PWD/../mos-platform/c64/lib",
      "-mlto-zp=110",
      "-D__C64__",
    
      "-isystem $PWD/../mos-platform/commodore/include",
      "-I$PWD/../mos-platform/commodore/asminc",
      "-L$PWD/../mos-platform/commodore/lib",
      "-D__CBM__",
    
      "-isystem $PWD/../mos-platform/common/include",
      "-I$PWD/../mos-platform/common/asminc",
      "-L$PWD/../mos-platform/common/lib",
      "--target=mos",
      "-flto",
      "-Os",
      ].join(" ")
    
    switch("passC", args)
    switch("passL", args)

Nim side was easy, because I have already compiled Nim to WASM at that point and the flags are similar. Hard part was figuring out the C compiler flags: e.g. cmake structure and why compiler complains about missing symbols, when they're not missing (answer: include/lib order is very important).

[1] https://github.com/llvm-mos/llvm-mos

Rust --> WASM --> Wasm2C --> Bob's your uncle. Maybe.