ivan4th

From my experience Claude Code is not that bad with Common Lisp and can do REPL-style development. I've been using this MCP server (an older version with some tweaks): https://github.com/cl-ai-project/cl-mcp (even though I'd probably prefer some MCP-to-swank adapter if it existed) And this MCP server works quite well for Emacs https://github.com/rhblind/emacs-mcp-server

There are some issues of course. Sometimes, Claude Code gets into "parenthesis counting loop" which is somewhat hilarious, but luckily this doesn't really happen too often for me. In the worst case I fix the problematic fragment myself and then let it continue. But overall I'd say Claude Code is not bad at all with Lisps

Helm is an abomination, as the whole idea of using a text template engine to generate YAML is. And this vulnerability adds insult to injury ;)

Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)

Urartu is missing as well: https://en.wikipedia.org/wiki/Urartu

I used OpenMPTCPRouter to aggregate 3 LTE connections (via routers connected to directional antenna, with SIM cards from different operators) when I was living in a house in the woods before the war has started I had to leave Russia. Worked like a charm, giving me up to 180 Mbps or so. May not be that good for aggregating different types of links together, but for using multiple cellular connections it's nearly a perfect solution. BTW 5G 3GPP specs include MPTCP support, IIRC for aggregating connections going via different gNodeBs (base stations)

Common Lisp has CLOS (Common Lisp Object System), which is quite sophisticated object system with metaobject protocol and multiple dispatch, as a part of its spec. Not that it's smth people need to invent on their own each time

Others mention autonomous mode thing being overhyped somewhat. But besides, that starts to remind me of home automation in Ray Bradbury's "There Will Come Soft Rains"... There was also a Soviet animation film based on that short story https://www.youtube.com/watch?v=5LNHYz89sNc

Yep. Many complain that with Lisp, you need to count parentheses (spoiler: you don't need to). And then proceed to count spaces for indent/nindent in the charts... That's somehow ok with almost everyone

I grew up in Russia, and ES-1841 was my first computer, too. Also with a printer, yet no HD. That was 1990 and I was 10 y.o... Once printed a caricature of one of school bullies using (a Soviet clone of) Turbo Pascal and its turtle graphics facility, resulting in a fight. My favorite pastime was writing DOS viruses in asm, though... I didn't spread them, just wrote some for fun. Found some of my virus code written down a couple of years ago https://pbs.twimg.com/media/E-jP39nXEAAve0O?format=jpg&name=...

The top shows that single-core performance is the bottleneck, and all CPU is consumed by ksoftirqd.

Trying out VPP instead of Linux kernel networking might make some sense: https://fd.io

It will likely reach the target performance, although the NIC requirements need to be rechecked.

But... well, this software is not for the faint of heart ;)

BTW, there was an accident in Ukraine (Soviet Union at the time) related to a radioactive capsule that ended up in the wall of an apartment building https://en.wikipedia.org/wiki/Kramatorsk_radiological_accide...

I find this syntax argument a bit strange nowadays. There's this extremely popular Kubernetes tool called Helm, which uses go-templated YAML to generate Kubernetes resources. The template syntax is nothing short of horrible. An endless maze of {{ ... }}s, where it's just too easy to shoot oneself in the foot by using {{- or -}} in wrong place, etc. And on top of that, you literally need to count spaces for nindent (mind you, you don't need to count parentheses while writing Lisp code).

I'd say Lisp syntax is clear as day when compared to your average Helm template.

An example is here:

https://github.com/kubernetes/ingress-nginx/blob/main/charts...

https://github.com/kubernetes/ingress-nginx/blob/main/charts...

And yet, all of this somehow doesn't prevent Helm from being popular...

This might help with some of the issues with go statement mentioned in the article:

https://blog.labix.org/2011/10/09/death-of-goroutines-under-... https://github.com/go-tomb/tomb/tree/v2

This company literally makes 1984 possible in Russia, being of tremendous help to the Putin's effort to stifle any internal dissent [1]. Yet the company itself is Cyprus-based [2] and also their employees advertise their involvement with Russian surveillance tech on LinkedIn [3] as if it's some perfectly normal IT activity. Can be something done about it?

[1] https://archive.ph/Nc8jl https://www.europarl.europa.eu/doceo/document/E-9-2021-00368...

[2] https://www.dnb.com/business-directory/company-profiles.n-te...

[3] https://www.linkedin.com/search/results/people/?keywords=nte...

BTW they're about to impose (almost) total ban on crypto in Russia exactly b/c of FSB complaints that it's being used to fund the opposition, such as Navalny's followers

Somewhat related: if you're using Common Lisp, and SBCL in particular, please consider sponsoring Stas Boukarev, who is an important SBCL contributor https://www.patreon.com/stassats JS is here to stay regardless of the sponsorships, but lispers are few and far between ;)

I did write some DOS viruses back when I was a kid, including a "stealth" one (invisible when reading the infected files via int 21h) and another one polymorphic (encrypted with dynamically generated decoder). I've never spread them, although I did upload another simpler one to an antivirus vendor BBS as a "new virus", so now it's known as "Areopag-480" and such. I thought all of the sources of things I wrote back then were lost when I typed an extra space in "rm -rf ~/something" back around 2000, but recently, while looking through some old books, I've found a piece of code of the stealth virus I wrote around 1992-1993: https://twitter.com/ivan4th/status/1434625057553330178/photo... I didn't have a PC at my grandparents' dacha back then, so I was writing code on paper instead during the summer

Posted a detailed explanation slightly above... Glorytun will not work to well with TCP b/c it doesn't provide separate congestion control for each path like MPTCP does.

OpenMPTCPRouter uses shadowsocks [1] and its ss-redir as a kind of a transparent TCP proxy. The advantage of shadowsocks is that it creates separate outgoing TCP connection for each one it proxies, resulting in substantially better performance than SOCKS. And, of course, shadowsocks has MPTCP[2] support.

The problem OpenMPTCPRouter solves is this: you do

curl -O https://somewhere.example.com/largefile.tar.gz

(just a single TCP flow) with 3x50Mbps LTE links, or, better, 80Gbps+40Gbps+30Gbps links and you get a bit less than 150Mbps download speed.

LACP doesn't solve it at all for several reasons.

1) LACP assigns each flow to a single network interface so as to avoid packet reordering

2) Even if you use other bonding mode that can spread the flows over several network interfaces, you'll get low throughput due to the aforementioned reordering and also due to the congestion control, more on that below.

Bonding works well when you have several "equal" links, which is not the case with LTE, where the speed may be quite different across the links and also vary with time.

Last but far from least, there is congestion control mechanism which is present both in QUIC and (MP)TCP, which makes sure the transfer is as fast as possible without harming other connections on the same link(s). This mechanism as it is used in QUIC and plain TCP is not very good at handling multiple aggregated unequal links, so no matter which way you do the aggregation on L2 (bonding) or L3 (things like glorytun), the performance is going to be suboptimal.

What MPTCP does is establishing a separate subflow (think TCP subconnection) for each of the available paths, with its own separate congestion control, and spreading the main flow over multiple subflows byte-by-byte in an optimal way. This gives maximum possible utilization of all of the available links, and prevents the congestion in an optimal way, too.

[1] https://shadowsocks.org/

[2] https://www.multipath-tcp.org/

Sorry for incorrect wording. I don't need multipath to be present in the same spec as the QUIC core. What I meant is when I will be able to have slightly less then 150Mbps over QUIC for e.g. a single file if I have 3x50Mbps connections. MPTCP can do that for me, even if the server doesn't support it as I can use something like OpenMPTCPRouter [1]. I hope multipath QUIC will be able to do that too, but it's not ready for production use yet, if I understand correctly.

[1] https://www.openmptcprouter.com/

I use OpenMPTCPRouter [1]. It's a bit of kitchen sink so I'm thinking of replacing it with something simpler, but the basic idea is that you have a TCP->MPTCP converter running on your router and MPTCP->TCP converter running on some cloud instance.

[1] https://www.openmptcprouter.com/

Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)

There are several possibilities of dealing with UDP traffic in OMR.

1) Multipath VPN (glorytun). Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control. The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.

2) UDP-over-TCP. In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]

[1] https://en.wikipedia.org/wiki/TCP_congestion_control

[2] http://sites.inka.de/bigred/devel/tcp-tcp.html

I have recently improved my rural multi-LTE setup by means of OpenMPTCPRouter [1]. MPTCP does a really great job at aggregating multiple paths for better throughput and reliability. Problem is, QUIC can’t do this, and while multipath QUIC exists [2], right now it’s more of a research project.

I’m afraid I’ll have to block UDP/443 at some point to prevent browsers from downgrading to 1/3 of available throughput...

[1] https://www.openmptcprouter.com/ [2] https://multipath-quic.org/

Hmm, cool project. Making it work over MPTCP [1] could also make it a kind of replacement for shadowsocks [2] for the purpose of converting plain TCP to Multipath TCP, as it is used in OpenMPTCPRouter [3]. Shadowsocks is used for MPTCP proxying instead of plain socks exactly b/c it uses separate connections for separate flows.

[1] https://www.multipath-tcp.org

[2] https://shadowsocks.org/en/index.html

[3] https://www.openmptcprouter.com

Docker is not using chroot and iptables aren’t the most important part of “creating the perception”. The primary tools are Linux namespaces and cgroups. For many purposes, these abstractions aren’t too leaky (and sometimes quite useful without Docker, too)

I wonder if irradiating by say 10 MeV electron beam could work for raw milk. Perhaps with the right dose, the taste shouldn't be altered significantly, yet the bacteria should be gone

Proper ARM SBCL with threads yay

For me there's very good reason for running home k8s cluster: dogfood factor. I run my smarthome and home surveillance (zoneminder) stuff, along with UniFi controller on k8s, and I must say that helps me a great deal with SRE part of my job. I do learn some important things before I encounter them in the work setting, such as: https://twitter.com/ivan4th/status/1236481744477532171

While this is not directly related to being a proper Lisp, one of the reasons (not the only one, of course) some people may prefer CL is CLOS.

kubectl port-forward my-lisp-pod 4005:4005

then M-x slime-connect localhost 4005