anyfoo

You never saw any issues, but your systems might have been faster with swap. Even if you're nowhere any threshing threshold, RAM used for caches is better than RAM used for unused pages, which could have been paged out to swapspace.

Note that RAM is much, much more expensive than disk space. If I can sacrifice some of the latter to potentially get some of the former, it's usually a nice trade for me.

It highly depends on your specific workload, but freeing up RAM by paging out rarely or downright unused pages to swap can definitely give a performance advantage.

In consequence, I always give swap. Even on the off-chance it ends up unused, disk space is orders of magnitude cheaper than RAM, so I don't mind sacrificing it for potential gains.

This comes up every time swap is mentioned.

Even if you have plenty of ram, having swap can help with performance.

Why? Because the OS can page rarely used or seemingly downright unused dirty pages to swap, freeing up precious RAM for caches.

I'd hazard a guess that especially if you run a ton of containers this can help, as there's probably a lot of memory getting dirtied on initialization of containers and their processes, which ends up never read afterwards.

I always set up swap, because sacrificing some disk space in potential exchange of free RAM, which is orders of magnitudes more expensive, is a nice prospect.

> The SLED system does not feature numeric types. Yet natural numbers (non-negative integers) can be emulated using lists:

> '(nil nil nil) ; three

Pfsh, how pedestrian and unnecessarily high level. What you of course want to use instead is ♫ Church Numerals ♫!

    (define zero (lambda (f) (lambda (x) x)))
    (define (succ n) (lambda (f) (lambda (x) (f ((n f) x)))))

    (define one   (succ zero))
    (define two   (succ one))

    (define (add m n) (lambda (f) (lambda (x) ((m f) ((n f) x)))))
    (define (mul m n) (lambda (f) (n (m f))))
    (define (pow m n) (n m))          ; n applications of "multiply by m"

    ;; escape hatch back to the host numbers
    (define (church->int n) ((n (lambda (x) (+ x 1))) 0))

(The "escape hatch" at the end is in Scheme, and only shown for illustration. Converting it into SLED and its documented "list numbers" is left as an exercise for the reader. It's really trivial, try it.)

I don’t know, so is your brain?

And in the end it’s all elementary particles and four fundamental physical forces that even unify to one at high energy.

That sort of reductionism is kind of useless. “It’s cloudy outside, it makes me sad.” - “Oh bollocks, it’s just non-qualitative changes in wavelength and intensity.”

Are they open ear?

But it is? At least for AirPods. The AirPods Pro are not open-ear form factor. I do not know about other open-ear airbuds.

You're probably partly right (though I use the same context size for all models, so there still is a difference in the model/quantization itself), but I definitely see it "thinking itself into an extremely expensive and error-prone approach without backing out". A common "failure mode" of my benchmark with <Q6 is "okay, I will implement a simulator", and when I see that I think to myself "please, no, you don't need to do that at all, you just missed a tiny thing" (but if I would type that into the session, it would void the benchmark; the idea is that I wouldn't know the solution myself after all).

Especially because Qwen3.8 27B does not seem to be good enough to implement the simulator with all its intricacies and tiny subtleties correctly. So it's churning for hours with no real progress, where it just had to explore the initial problem space a tiny bit more.

And very interestingly, even with Q6, turning off reasoning entirely does not make it fall into that trap, or many others, and it more often solves the task in record time. Both because of what I just described, but also because the endless reasoning costs a lot of token, which significantly translates to time on a home rig...

I observed this as well. I have problems that get solved very quickly using non-thinking mode, but in thinking mode it digs itself into giant holes, that it sometimes doesn't manage to escape from.

Like wanting to implement an entire emulator to figure out something it could easily glean otherwise (and does, in non-thinking mode).

> As you may see, the scores are around the random guessing level, with the smallest model being below that threshold.

Err… can someone explain to me what is meant here? Surely the model wouldn’t consistently “guess wrong” compared to randomly, as that would be better. I guess some things like general coherency (i.e. is it even readable or gibberish) factor into that score?

Depends on the actual audience, I guess. My stated “wisdom” comes in part from /r/LocalLLaMa, and my impression is that the tasks that users there give their models to try them out lean towards rather simplistic, on the reasoning side.

But there I literally did read “you don’t need anything better than 4 bpw” a bunch of times.

Not for me. As stated elsewhere, even Q5 (!) seems to be enough to kill the model’s ability to solve a particular problem in reasonable time. But that might just be right at the edge of what the model can do in the first place.

I have another personal benchmark problem (of a very different nature) that Qwen3.8-27B usually can’t solve at all, while Opus and GLM-5.3-Flash solve it consistently and very beautifully.

I have a very interesting self-made coding benchmark, very intricate and technical, but 100% a real world problem I had to solve. I’m not going to further elaborate, since I don’t want future models to train on the solution.

To my own surprise, Q6_K_XL (from unsloth) comes up with a solution, anything Q5 doesn’t. To further surprise me, so far only the XL Q6 variant managed to solve it.

The problem, at least as stated, seems to be right on the edge of what the Q6 quantization can do.

Unfortunately even a successful run is rather long, so I don’t have a whole lot of data.

But the whole thing sure made me doubt the common idea that you wouldn’t perceive a difference until crossing past 4 bits quantization.

Nowadays, it's considered bad form to map anything at 0... you now know one of the reasons why!

In the case that I know that has a 1:1 identity mapping of the address space, the physical address space doesn't actually have anything at 0 either, so it still doesn't need to be mapped.

In the current betas, there's actually more entitlements that allow this, not just private ones.

ELI actually 5:

You have 10 food jars in your house. Your parents only allow you to grab food from, say, the jar on the far left, and the one next to it. Sadly, those jars only contain broccoli (ordinary OS memory) and lettuce (more ordinary OS memory).

But, you find out that you can just shuffle the jars around! You do a little bit of random shuffling, until you find that you have the jars with cookies (CPU microcode) and candy (SME firmware) as the leftmost ones on the shelf.

Your parents take their promise very literally, and still allow you access to the two left-most jars. Which is now cookies and candy.

> Her last day at the company was the day she promised she would book phone screens

And the emails you sent didn't bounce after that?

I work in "lowest level" kernel development, and we're certainly operating at that layer. As for those kind of hacky solutions, we do try to avoid them, because they are, well, hacky, and therefore often hard to understand, easy to break, etc... but it does happen. Especially in prototyping, were usually anything goes to make something work initially.

Try Haskell.

Sweet. What changes to Hercules have you been considering? I have had a long running (and maintained!) MVS instance in Hercules for quite a few years now, just for fun.

It's a simple word that does the job. No need to overthink it.

He's basically a rock star here. (And well deservedly so.)

There’s a bunch of free character roms as well.

Great project! Kudos for figuring out all that stuff on your own. Assuming you are actually reading these comments, a few suggestions:

* C compilers that can target 16 bit x86 usually have support for "far pointers", which are 32 bit wide pointers consisting of both a 16 bit segment and a 16 bit offset. You should be able to use that instead of your assembly wrappers. This allows you to directly access screen memory in C, i.e. letting the compiler do the job of setting up the segment registers, which also has the great benefit of not having to push, write, and pop ES for every byte (if you copy a block into screen memory for example, the compiler only needs to set up the destination register once).

* The IVT is correspondingly also a list of FAR pointers. It's a common 16 bit x86 concept. The CPU knows about them, they are also more generally used for far jumps and far calls.

* As others have said, just pick one of the many, many available text mode font ROMs.

* I'm curious how compatible that AMD Elan is to actual PCs. Probably a lot, since by that time PCs were kind of the x86 standard, though not necessarily. The earlier 80186 with its integrated peripherals (interrupt controller etc.) was very incompatible, for example. Shouldn't impede your project, just dictates how easily you can run DOS programs overall.

I did not mean it’s a trick users applied, I meant that the developers of the 1541 DOS implemented this very trick. You load a textual representation of the directory into memory as a BAISC program, that’s pretty funky.

And it was precisely done because the straightforward way, which would have been something like opening a sequential channel with a dedicated directory listing command and reading out from it, would have been immensely awkward under BASIC 2.0. Hence the magic “$” program.

No, that was BASIC 2.0, and using any DOS commands was extremely awkward.

With the notable exception of listing the directory, which was pretty easy through a trick from the disk drive’s DOS which meant you could load the disk directory “as a program” with a special name, “$”, and then just LIST it. But you see, the drive’s DOS had to sort of go out of its way to make that simple.

Yeah, but you can still talk to other hosts on the same link, not just the router, at any layer protocol. Link local addresses are not routable, but if you want to talk on the same network segment, that's fine.

Impressive, but I always wonder how much stability testing goes into these overclocks.

With just the stock tools, I can push my GeForce pretty far (relatively spoken, absolutely nowhere near what "professional" overclockers can achieve, of course), and it may appear stable for many hours, until suddenly it crashes anyway.

So what's the qualification of a "successful" overclock? Is it just passing a benchmark, and after that for all we care it can go up in flames?

You can use link local for whatever you want, I don't think there's a restriction, is there?

Even though it's rare, I actually do use it if I want to talk to another host on a very specific interface. Sometimes there's multiple paths.

Why don't you just use the IPv6 address directly then? Phrased differently, what's better about IPv4 in your particular case that makes it worthwhile to only use IPv6 for "bootstrapping" IPv4?

I must say, I rather enjoy both IPv6s autoconfiguration, and the fact that my non-link-local addresses are actually unique (and if I want to, routable).