anyfoo

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).

Absolutely it is. But still, the colons and brackets often make things awkward, leading not only to such compatibility bugs, but to general usability issues. Colons and brackets are just too overloaded within both destination specifiers (e.g. for ports, paths...) and shell syntax, and probably other things, where as the dot '.' rarely is.

I'm an avid user of IPv6 by the way, I don't share a lot of the criticism. For me personally it's a net positive. But this is a wart where I wish they went a different direction.

Yeah. I think that's actually my one, biggest gripe about IPv6, those damn colons. And those damn brackets that were made to mitigate the colons, that just cause more problems:

Just yesterday I tried to use rsync (like I do all the time, in my mind there's no reason to use scp when rsync does everything better), but this time I needed to specify an IPv6 address. On the (admittedly ancient) rsync version that comes with macOS, this doesn't work:

rsync foo 'user@[fe80::4]:/tmp'

Note already, how I had to put the second argument in quotes, because otherwise the shell tries to expand the square brackets as filename expansion.

But even then rsync just complains, because rsync itself separates host from path through colon. I think the only workaround is to do something like `rsync -e 'ssh user@[fe80::4] ...'`... but I just used an updated rsync from homebrew, which is of course the saner method. Still, just another colon/bracket-caused issue.

I hear that a lot, but I familiarized myself with it once and ever since it makes a lot of sense to me.

Source ending in “/“: You want what’s inside. Source not ending in “/“: You want the thing (i.e. directory itself). For the destination, it does not matter whether it ends in “/“ or not, but for consistency I like adding a “/“ anyway (I want to put thing inside the directory).

You know better, as you have all the information and we merely have a shadow of it, but that in itself still sounds like “standard boilerplate” to me.

I remember from my friends who worked at Google at the time, that everyone’s always been told that “every new hire’s contract lands on Larry Page’s desk, he has to sign off on it”, and you can probably bet your bottom dollar that Larry Page didn’t spend a lot of time on each hiring package, if any.