regularfry

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.

Lots of tech money is demonstrably wrong, at least in the general case. Microsoft's whole business model is to be the second mover. Patents exist because first mover advantage alone isn't enough to hold onto a win.

If AI is different, the onus is on AI folk to explain why, not the reverse.

The frontier labs are racing as hard as they can right now because they know as well as anyone else that they're at best 6 months, probably closer to 3 months, ahead of the generic commodity AI market. The majority of the tech money currently boosting them is a bet that either they can stay that far ahead without tripping, or that a moat can be engineered. It's not at all clear that it can - or, if it can, that it will before the money runs out.

I got a pixel 4 after some surgery basically for the fall detection. Otherwise it's mainly doing what the Fitbit I had 8(?) years ago did for me, with added GPS. Pulse, steps.

As an ADHD-haver it's good to get notifications to the watch so that I can avoid unlocking the phone and risk falling down a rabbit-hole. I think that's under-sold.

What I want is a decent (by which I mean SIMPLE) pomodoro app for it, and I'll probably have to write that myself. Does that make me a power user? I was surprised that finding such a thing would be difficult.

I tend not to use it for payment because the ergonomics are terrible. Someone needs to tell that team that having the face on the inside of your wrist is entirely valid (especially if you don't want to be whacking your shiny watch face into every passing door handle), but that makes you do contortions if you want to get it close to a card reader. Not only that but the way screen locking works is ungainly enough that the fact you need to use it more with the face towards your body makes it a constant annoyance. I've unknowingly reorganised my widget order far too often because of this.

I found that explicit instructions to keep nesting depth below a limit helps limit the damage. That limit was 5 in my case, which can be inconveniently tight in some situations.

It's more opportunities for a screw-up to lead to a vulnerability in ways the tooling won't catch by default, in a system where P(screw-up) > 0.

I have a hunch (based on using the Kimi models to write some clojure) that the article's AST point is exactly wrong. I had to spend a lot of time cleaning up when it miscounted closing parens, which implies that while the LLM may be operating on the AST, mapping to and from the token stream is harder, not easier, when the individual tokens carry less information.

If the author is finding that it works well, I suspect there's something else (code or comment style, maybe) that's compensating for it which didn't seem worth mentioning.

The article makes reference to this being expected from the physics, but I don't think it's particularly intuitive why it should be the case. Unless it's as simple as smaller swept areas needing higher tip speeds for the same lift? That would make the energy loss to drag worse for multirotors.

Making a stupid idea more convenient does not make it less stupid.