mattdw

My M4 Pro 48GB gets about 13tok/s, in both 3.6 and 3.8 27b Qwens. Qwen A3B and Gemma get closer to 100tok/s from memory but the results are pretty poor for coding tasks.

Edited to add: for agentic workflow I’m running omlx which tells me it has about a 90% cache hit rate (tradeoff is some disk and mem space) - that noticeably changes the felt speed.

Podman can run compose - either its own, or docker-compose if you tell Podman to listen on the docker socket.

I use Podman on both macos and Windows, with compose files, so I'm a bit perplexed by this whole comment.

This is really great - great style, charming little world. Love it!

New Zealander here, really thrilled to see our national medical testing service (primarily blood tests) in here. I've sent a note to them to make sure they're aware of this.

Also I feel like I took the wrong path, trying to be a serious and responsible software developer - seems like all the money is in throwing shit together and making wild claims about it.

For events that have happened, absolutely. Events in the future are often slightly more ambiguous though!

I do agree that "with attached Timezone" or "as UTC" are absolutely the sensible defaults, I'm just suggesting that sometimes "plain" datetimes are semantically the correct choice.

For sure, but for future events to be correct I still have to store that as (plain datetime, pacific/auckland), not translated to utc at the point of creation/saving. If I store only a UTC datetime I have unrecoverable lost important information.

Calendar events often want to be interpreted according to whatever the local timezone currently is. For instance "10am every second Sunday" shouldn't adjust to 9am during Daylight-Savings time. And my 7am alarm clock should definitely not change to 7pm because I flew from Aotearoa to England.

I'm sure it's been discussed here before, but for calendar events you don't necessarily want a timezone attached, you want a location - "this event happens at 9am according to whatever timezone is currently in effect in Auckland, NZ". That's a thing that UTC or timezone-aware Datetimes can't help with.

When it’s a library of code, the language it is written in is pretty pertinent information as that’s the language it has to be consumed from…

I found the Scanner API (1) to be pretty handy for the more complex parsing in past years.

It’s Foundation so hopefully also on Linux/Windows, but if not there’s also one on GitHub called SwiftScanner.

1: https://developer.apple.com/documentation/foundation/scanner

I'm a some-time Django developer and... I caught the bug instantly. Once I saw it was model/ORM code it was the first thing I looked for.

I say that not to brag because (a) default args is a known python footgun area already and (b) I'd hope most developers with any real Django or SQLAlchemy experience would have caught this pretty quick. I guess I'm just suggesting that maybe domain experience is actually worth something?

Natron is essentially a clone of Nuke, the ~standard compositing software for the VFX industry. It's impressive that it exists and competes with some very expensive alternatives.

Its maths and colour science is good and it seems to operate correctly on images. Unfortunately usability and performance are pretty weak. I've managed to replace Nuke or Resolve with it for the parts of my workflow that are colour conversions from e.g. ACEScg to sRGB, or for encoding videos (it wraps ffmpeg), but I'd hesitate to use it for anything creative and it definitely doesn't approach the animation facilities of After Effects.

I've only played with Nim a little, but I found it really compelling and honestly quite fun to write. It's quite elegant and economical and the performance is impressive for the lack of ceremony.

However, the language itself still seems to be a little in flux (v2.0 is nearly out, and my impression is that v3.0 might finally be a nice stable language) and the BDFL makes some language decisions (and holds some opinions) that I'm not fully on board with, and I think make the language a little less than it could be. Obviously that's subjective though.

I'll definitely keep an eye on it and check back in periodically, but I'm also not going to write any non-disposable code in it for now.

`ptr`, `addr` and `cast` are the only ways to introduce unsafety, as I understand it. You have to run three greps, but you can definitely grep.

NZ isn't currently issuing visas outside of a few categories of "special worker in shortage". (In order to citizens and residents a better chance at getting a quarantine spot.) So this introduces a new special exception for the very wealthy.

He's pretty clear in the article that it's the "title-description-body" model that doesn't work -- tweets don't generally benefit from a title or a summary.

In the VFX industry you don't roundtrip lossy codecs; first step is to decode to something lossless like EXR or TIFF, and those are what you pipe through your workflows. (With maybe lowres JPEG "proxies" to make iteration a bit quicker.)

Film/TV more generally I think tolerates slightly lossy codecs like RED or Pro Res, as there's often only 1-2 intermediate steps that could cause extra loss. (E.g. the part of editing that is just 'cutting' is pass-through, but color-grading would require a second encoding step.)

It's essentially the same process to begin with (I think), but every time the ray hits something you fire off secondary rays probabilistically from the hit point to see what that point is receiving light from, and so on ad infinitum. Usually you're calculating a BSDF[1] for each surface you hit, which tells you where to cast your next set of rays.

[1] https://en.wikipedia.org/wiki/Bidirectional_scattering_distr...

BS corporate red tape is a reality, though. So why not offer workarounds that help them give you money?

Let's maybe also consider the role of e.g. US interference and sanctions in your two examples, before we decide capitalism good, socialism bad.

The point is that you're not expecting people to ever pay it, because you've set it high enough to be a solid disincentive. If people are actually paying it regularly, you obviously haven't set it high enough.

This is also common when quoting freelance projects you don't really want to do.

A New Zealand bank has made this one: https://cleverkash.asb.co.nz

Obvious there's a certain advantage to already being a bank for projects like this.

Really? connection.exec_, .map, .build – there's a lot more non-SQL going on in the second example than the first. The first may be syntactically far from SQL, but the use of familiar vocabulary makes it pretty understandable from a SQL point-of-view.

There are tools to go between the two (from http://cubic-bezier.com/ to Flash's HTML5 export), but I don't think there's any general solution to go from a UI like that, to code. What if one of your points is a programmatic parameter that varies over time? What if you're changing ground level with every iteration? How does the bezier-based editing UI help with that?

Surely the right to the drug was only worth $11B in the first place because of $84k possibilities at the other end? If it was only ever going to be $1500, that $11B would have been adjusted accordingly.

I would have expected the vast majority of the killing was of animals e.g. hunting. You don't seem to have left any room for that possibility.

Betteridge's Law of Headlines states (roughly) that "headlines in the form of a question can usually be answered with 'no'".

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

And that's the problem with systemised bad incentives.

Because poor people are not stupid. They're often actually pretty damn rational within their constraints. Smarts alone does not equip one to handle a windfall.

Swift seems to distinguish 'mutating' from 'changing'. The name 'array' in your example remains pointing to the same object, it's just that that object is being internally mutated. Not sure that there'd be a foolproof way to catch all possible mutations, so that may be the best they can do.

But with a completely different set of sensory input, and under a whole different set of constraints.