maybe i understand this a little differently, the argument i am most familiar with is this one from lecun, where the error accumulation in the prediction is the concern with autoregression https://drive.google.com/file/d/1BU5bV3X5w65DwSMapKcsr0ZvrMR...

The error accumulation thing is basically without any ground as regressive models correct what they are saying in the process of emitting tokens (trivial to test yourself: force a given continuation in the prompt and the LLMs will not follow at all). LeCun provided an incredible amount of wrong claims about LLMs, many of which he now no longer accepts: like the stochastic parrot claim. Now the idea that there is just a statistical relationship in the next token prediction is considered laughable, but even when it was formulated there were obvious empirical hints.

i think the opposite, the error accumulation thing is basically the daily experience of using LLMs.

As for the premise that models cant self correct that's not the argument i've ever seen, transformers have global attention across the context window. It's that their prediction abilities are increasingly poor as generation goes on. Is anyone having a different experience than that?

Everyone doing some form of "prompt engineering" whether with optimized ML tuning, whether with a human in the loop, or some kind of agentic fine tuning step, runs into perplexity errors that get worse with longer contexts in my opinion.

There's some "sweet spot" for how long of a prompt to use for many use cases, for example. It's clear to me that less is more a lot of the time

Now will diffusion fare significantly better on error is another question. Intuition would guide me to think more flexiblity with token-rewriting should enable much greater error correction capabilities. Ultimately as different approaches come online we'll get PPL comparables and the data will speak for itself

>force a given continuation in the prompt and the LLMs will not follow at all

They don't? That's not the case at all, unless I am misunderstanding.

I'm not talking about the fine tuning that make them side with the user even when they are wrong (anyway, this is less and less common now compared to the past, but anyway it's a different effect). I'm referring if in the template you make the assistant reply starting with wrong words / directions, and the LLM finds a way to say what it really meant saying "wait, actually I was wrong" or other sentences that allow it to avoid following the line.

we've got a tailscale integration that takes care of the security concerns. set policy to decide what can talk out to the tailscale node and what the tailscale gateway is granted access to. this is especially important when you can't run a tailscale client on the devices you want to connect

https://github.com/spr-networks/spr-tailscale

yeah, nobody can claim scaling without having the error to prove it. SPAM + coherence time + gate fidelity are the limiting factors to scaling, not the concept of an idea of how to build it at scale :-)

Given that Microsoft has been a heavy research collaborator ( Atom and Quantinuum), is there a possibility that the cross pollination would make it harder to deliver a farcical majorana chip since microsoft isn't all in on their home rolled hardware choice?

I've held the same view that this stuff was sketchy because of the previous mistakes in recent history but I do not work in the field

-p 127.0.0.1: might not offer all of the protections the way you would expect, and is arguably a bug in dockers firewall rules they're failing to address. they choose to instead say hey we dont protect against L2, and have an open issue here: https://github.com/moby/moby/issues/45610.

this secondary issue with docker is a bit more subtle, it's that they don't respect the bind address when they do forwarding into the container. the end result is that machines one hop away can forward packets into the docker container.

for a home user the impact could be that the ISP can reach into the container. depending on risk appetite this can be a concern (salt typhoon going after ISPs).

more commonly it might end up exposing more isolated work related systems to related networks one hop away

What about cloud VMs? I would love to read more about "they don't respect the bind address when they do forwarding into the container" and "machines one hop away can forward packets into the docker container" if you could be so kind!

Upd: thanks for a link, looks quite bad. I am now thinking that an adjacent VM in a provider like Hetzner or Contabo could be able to pull it off. I guess I will have to finally switch remaining Docker installations to Podman and/or resort to https://firewalld.org/2024/11/strict-forward-ports

i cant speak to hetzner, contabo. i have tested this attack on aws, gcp a while back and their L2 segmentation was solid. VMs/containers should be VLANd across customers/projects on most mature providers. On some it may not be though.

if theres defense in depth it may be worth checking out L2 forwarding within a project for unexpected pivots an attacker could use. we've seen this come up in pentests

I work on SPR, we take special care in our VPN to avoid these problems as well, by not letting docker do the firewalling for us. (one blog post on the issue: https://www.supernetworks.org/pages/blog/docker-networking-c...).

as an aside there's a closely related issue with one-hop attacks with conntrack as well, that we locked down in October.

We (https://supernetworks.org/) have a Tailscale integration https://github.com/spr-networks/spr-tailscale and support Site destinations for devices. For our hardware products one thing we do need is to source a good carrying case for travel.

On Azure -- they've been playing catch up this year after repeated congressional inquiries from breaches. It's only in 2024 that Azure has started to build a better device inventory on their infrastructure networks and started doing appropriate employee access control mechanisms.

Here is Satya's May Post, https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...

OpenBSD is an admirable operating system. We reported a local privilege escalation vulnerability in cron on openbsd due to a memory corruption flaw. Our research got surprisingly close to a reliable exploitation path and we opened up a contest for someone to demonstrate a working exploit, https://www.supernetworks.org/crontab-challenge

you should know that docker doesnt make firewalling containers easy

1) devices one hop away can route directly to the container network, for example the WAN interface can make requests to 172.17.0.2

2) INPUT firewall rules won't help. with docker's defaults the DOCKER-USER chain needs to filtering

3) container networks have access to private subnets upstream of the container. this is a common problem in many homelab setups

4) browsers can be a springboard for malicious websites to attempt to exploit testing docker containers on adjacent networks with default credentails

Plugging https://www.supernetworks.org/ -- when on wifi/vpn all DNS will go up over DNS over HTTPS as plaintext DNS is DNAT'd to CoreDNS which is by default configured to use DoH.