regularfry

Yeah, but speakers aren't the whole system. Even if you've got perfectly flat speakers, the room they're in won't be.

Can confirm. When I was in that world we'd have a shitty boom-box on a shelf that got pulled out for exactly that purpose. But you'd always start from the studio kit and work down, never the other way.

The little Sonos bluetooth speakers do something like this. I went in search of a teardown to figure out how on earth they get any sort of bass response from that size enclosure, and the innards turn out to be kinda boring. The trick is almost entirely from shoving the real-time room response through software correction. If that could be packaged up for Linux laptops, it would be amazing.

Yes, they should be discoverable. There are platform conventions for this: on Windows you'll see underlined letters; menus show you the shortcuts. Tab is a pretty much universal "move to next field" shortcut and I don't think that's particularly discoverable if you don't already know it.

There's nothing wrong with a keyboard driven UI having buttons as long as they advertise their key, though. That's one way discoverability is supposed to work. It means you can fall back to the mouse when it makes sense.

Minor point, but a few years ago there was noise about waxworms being able to break down PE into ethylene glycol somehow, which would mean enzymatically breaking C-C bonds. No idea where that research ended up.

In theory so does AWS, but the Bedrock model selection is badly in need of a refresh.

There's a non-small contingent who lucked into the periodic games machine upgrade at the right time to snag a {3,4,5}090 rig just before everything exploded. It's a small contingent now but it was less so then. And now those people can add a second card for roughly what that whole system would have cost new originally.

I don't think this is there to satisfy "need".

But "automation" with this could legitimately (well, mostly) be based on a git repo with an s3files mount inside it. And a cron job, if you really want to get fancy.

The easiest route is probably to have it sit with its back to a Qi charger pad, with the coils in a sort of cape over the battery. Not much added weight for the coils, and quite a neat little intro project to get it to align itself and sit correctly.

Which makes it a great product in a comparatively small niche, and a "meh" premature optimisation pretty much everywhere else. Except for right at the bottom end where it's a step up from a JSON file in an S3 bucket.

I suspect you are dramatically overestimating how fast humans can climb. I hope I'm wrong.

Actual cooling was from industrial emissions, but that was over by the 1970s. It being something to panic about at that point was a media amplification or a contrarian position, precisely because it was contrarian, not representative of scientific opinion at the time.

I did this on one project but things moved fast enough (and I've had too much going on) that I couldn't go round the review cycle fast enough and keep it architecturally aligned to get it merged.

With agents like headlong knocking about, "why" is "because it convinces itself that it should".

I found snikket to be pretty much perfect for the use case I wanted, which was something locally-hosted I could drop in a VM so I had a channel for talking to bots that didn't need API keys for third party services.

The only downsides I've experienced are:

1. Images and accompanying text get separated, which turn-based bots get confused by. I seem to recall there's a standard for this but it's not implemented.

2. XMPP support isn't common in claw-type agents so I've had to patch it in. Not a terrible experience overall.

I had a look at Matrix but bounced off Element, hard.

If, in my outbound package, I include a prepaid return envelope with instructions to post the packaging back to me, does that get me out of registration requirements?

I didn't have this idea exactly but I did play around with sqlite as an embedded database for packing ruby apps into a single file a while ago. It was less direct than this: you basically compiled all the dependencies (including .so's) into a fake filesystem that an overridden `require` loaded from, which was unpacked to a `:memory:` database at runtime from a `.data` section that got bolted onto the interpreter. It died when 1.8->1 9 changed how the build system works and I never got round to updating.

A version based on this which carries around an overlay filesystem would be comparatively straightforward, the hard work is already done.

> very rarely one can see a keyboard driven one

Not so. GUIs absolutely should be keyboard-drivable, if they're written to the human interface specs of whichever platform they're hosted on. That doesn't mean they don't support being mouse-driven or even that mouse isn't the default, but in my experience if the developer has taken any sort of care with the interface then keyboard interaction will be at least as good, if not better, with the keyboard.

> And TUIs are only keyboard driven.

Not true either. There's a line in my .vimrc saying "set mouse-=a" specifically because I want to turn off the mouse in that particular TUI app. If a TUI app doesn't support the mouse they've just not added that support, it's not that it's not possible.

One version of this is "every application is actually a repl with ideas". I do wish the lisp community cared more about GUIs because it feels like there's a huge gap where exactly this sort of extensibility could be merged with precisely the richer sort of visual interaction the article wants.

Meh. You asked why, I suggested a possible reason, you them said you don't care about why. Congratulations, I now regret engaging.

Apologies, you asked a question. I assumed that meant you were interested.

Behind on architecture, ahead on training? It seemed pretty obvious to me that the opus 4.7 and 4.8 releases were more about trying to retain 4.6-level capabilities while being cheaper to run, which would fit. And they can burn so much money on training.

It's a fine canary for the question "is this model Chinese?" Which is pretty much where this thread started.

Now do plasmas

The valuations of the hyperscalars won't sustain just being more efficient than something you can run locally. There's a market there, but it's for margin on a commodity. They're priced for oligopoly on unique, premium products.

What you're arguing for is that the deviation from true randomness is worse than the PRNGs that are already used, and that the deviation is anticorrelated with some notion of quality. You need both. I don't think you've got either.

It doesn't, though. From the outside, without access to the parameters, you can't distinguish the watermarking system from a random number generator.

We already use an RNG at inference precisely because it leads to higher-quality output. Changing what function is generating our random numbers changes the sequence, not the randomness from the point of view of a user.

Fundamentally the article is railing against --temp > 0.0. He doesn't know what he's talking about.

Look for `heretic` fine-tunes in the next couple of days.

Having the previous boot can get you out of a hole if you're dealing with dodgy drivers.

The question mark in my mind over the technological superiority is whether the additional volume of data they see due to capturing the top of the market allows them to do recursive self-improvement in a way nobody else can match, before any of the other labs can figure it out. That's the only runaway outcome I can see.