They are pretty big in Australia, and have spread through TikTok, Snapchat and IG. I doubt there's many people here who are across all of these circles and I only found out when it was mainstream news
Looking forward to giving this a try. I have tried MLX using Rapid MLX however the LLM (Qwen) would always have hiccups and get stuck repeating itself.
Moving onto llama.cpp I was able to get faster tokens with MTP and a more reliable llm.
I wonder what other people's experiences are using MLX vs llama.cpp
FWIW on my M1 Max I have not really seen any advantage at all from MLX.
I am fully prepared to believe the benefits accrue more to the M3 and up (because of changes to the Apple Neural Engine).
But with the models I've tested, unless I am missing something, the performance of GGUFs in llama.cpp has been better in some cases.
I still have not had results from Gemma 4's MTP be really worth it, to be honest; but with the Qwen 3.6 MoE it is measurable. Maybe with newer kit it is more meaningful.
(There is every chance that the above is not the experience of anyone who really deeply knows what they are doing; it feels like I am a perpetual novice at this stuff)
I think one difference is that it also provides the service of being a production environment you can serve from at the same time as development. There's more information about this thought in the fly io blog post.
I just use Docker devcontainers using Anthropic's own Dockerfile as a base, and it gives me a persistent sandbox that have ports opened and work in any container environment (be it remote or local), and work in any IDE that supports devcontainers...
So what if Claude Code makes a mistake and tears up the sandbox? What happens to all the persisted state (aside from the container image)?
The linked fly.io article discusses why containers aren't a good fit for sandboxes that need persistent state and how sprites.dev addresses the challenges.
I read the linked fly article and didn't see where it's mentioned why containers aren't a good fit for sandboxes that need persistent state. You can definitely do all the same snapshoting directly on your local docker volumes, although granted you'd need zfs or lvm backed volumes (which is probably what sprites do under the hood).
I think there are tradeoffs here. Maybe your one person vibe coded app doesn't need any change management, IaC, any of that. No docker file, start with whatever docker file fly wrote for you, beat it with an agent until it works enough. And it's pretty cool that you can then just serve it directly. Is it dev or prod? Yes.
On the other hand, I really don't think editing php files over ftp in prod was ahead of it's time -- I was there, man, and it sucked. I just know I'll be really confused about why something doesn't work eventually and wish I had some tracking of what changed over time. I want my IDE. I want VCS!
Definitely. Shout out to the effort they've put into their api's as well. I've integrated them into a product and raise awareness of sustainable fishing for several major retail outlets.
I really resonate with this post after working with Jenkins for ages. In my experience I wasn't very happy with Bash in the end either and moved to Javascript for reliability, performance and tighter integration with the Cloud were deploying to. It also allowed us to run locally and avoid having to deploy to Jenkins to test.
The discoverability issue is also a massive issue, declarative pipelines massively over promise its capability. Pipeline configuration was mostly still done in the UI because extensions had 0 documentation about how to declaratively define its configuration. Searching on the internet for the magic incantations as the author puts it is such a waste of time and I just compromised to get it running.
I'm glad this post is out there to articulate these common challenges when you invest so much into Jenkins.
I use drone self hosted (which is what Woodpecker CI was forked from in one of the other replies). It's an alright system and it works with my Gitea instance to build executables and docker images.
I think though ironically my take away after setting everything up, was that I didn't really need to spend a lot of time to get it perfect, rather just getting it working was enough for me.
Yeah I definitely agree, wasting time figuring out how to get to the save and apply your changes is the worst obstacle there, in most cases the saves are encrypted and have a check sum applied. Although I've found some games that allow you access the save data without messing around with this stuff, mainly the Shin Megami Tensei line of JRPG games in my experience.
Granted, the saves are binary blobs but once you find the value you want you can find an entire struct of data along side it. There are tools like imHex which help the process and help you define the structure of the save file. It's become a common project of mine to save hack and then build a save editor when I'm confident my changes work.
I've skim read through it, and it reads vastly too weak.
They used a blockchain haskell implementation on a fringe blockchain technology, and wrote nearly all their business logic in it.
If I were them, I'd immediately sue whoever built it. This level of gross incompetence reads to me like they were scammed, used as patsies to integrate blockchain into a client.
It is paid for and reads like it was paid for by ASX - damning enough to say the solution is woeful, but knows that the person paying their consulancy fee green lit the vision to jam a square peg into a round hole.
It bends over backwards to say that somehow this approach meets some non-functional reqs. But it cannot plausibly meet any such requirements well. Even praising the "quality" of the haskell code whose job it is to provide a casio-watch level of compute power over an immutable distributed ledger. For $250m!
It would be fascinating if, eg., the Australian gov forced Accenture to release their internal docs. I imagine there are several versions of me with with much much more strongly-worded things to say.
This feels like it would go well in a netflix documentary retrospective on the "blockchain con" and how it duped gen-z and ceos.
Major IT projects are a graveyard for executives, anyone who could reasonably succeed knows they are destined to fail, and they fail so often that big co's now have so much legacy chewing-gum holding together their systems that implementing any system is destined to fail.
The most likely to work solution - rip out everything in the company and start from scratch. Short of that you are looking at - $50mil to modernise with a drop in (fully functioning) component in a 2 week install + 5 years and $100mil to write translation layers to all the other systems which will still fail on edge cases.
Every now and then the executive that believes in sunshine, rainbows and unicorns comes along, slaps down a stupid budget and tries, with good intentions I might add. They however, are predisposed to buy into the people and vendor that sell magic beans. And they cycle continues...
If you interpret it from a different angle, it would be much clearer.
1. Those made the decisions are smart, really really smart people. If they were dumb, there is no way they can get to where they are now. So if the decisions look questionable, they probably are indeed questionable. But that does not mean they made a mistake. Smart people don't do obvious stupid moves, if they do, there must be some reasons we don't know.
2. If the budget is not used, at best it lapses or worse will be used by someone else. So do whatever they can if they have nothing better to do with it.
3. If you do something for someone-else with someone-else's money, neither the price nor the quality would be much of your concern.
4. After handling meat, you know, there is oil on your hands.
Yeah. I’m pretty familiar with the history of their tech, and the problems with DAML and how they architected everything predate the surface syntax being Haskell.
Source: I was the evaluator of DAML for Jpmorgan.
The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols. But where you have to write your own db and interpreter tooling to ingest the commands if you want all the usual nice things you’d expect from a database
And a very patient and curious evaluator you were too (I was one of your counterparts at DA).
> The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols.
Yes, well said. I think that's quite fair. It's wrong to look at it through the lens of Haskell (or any other FP language), it's really a declarative language for describing process flow and actor rights and obligations. Not something you could write a complete program in. A better way to think of it is as a big DSL for controlling state machines; you still need all the machinery around the outside to advance execution, handle IO, trigger events and transitions etc.
It's syntactically similar to Haskell because the people who created it were Haskell heads out of ETH Zürich. That's the only connection.
The intial surface language for the dsl was actually not Haskell! But I think eventually shifted to using ghc as a frontend library?
I’m not sure if I was the most patient of evaluators ;). If I was despite that one of the more patient evaluators, wow!
I kinda view everything in this space from the lens of tools I want to build for myself. Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees. I did build a preliminary version of the core of that at jpmorgan, though for various reasons it never saw the light of day
> But I think eventually shifted to using ghc as a frontend library?
That's right. It happened fairly quickly, part of the efforts to formally verify the language. I think when you were poking at it was around the time it was changing underneath. But, that was years ago!
> Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees.
I mean that's largely what Daml was trying to do. But of course it lacked the transactional DB system once we tossed out our in-house DLT. The approved answer back then was, deploy it over someone else's blockchain/DLT. Well, we all know about those. So before I moved on I spun up a successful skunkworks effort to integrated it into some relational databases; you'd be surprised what _that_ implementation ended up at the heart of.
Well, patient is maybe not the right word :) You weren't ever a dick though and that put you in a small club. You can draw your own conclusions about the space I'm talking about (Haskellers, JPMorgan, enterprise DLT...)
(I'll ping you separately as I have you at a disadvantage. For various reasons I won't put my name in this thread.)
lol “Greater consideration is required regarding the purpose of the consensus layer given
ASX’s position as the central market operator for the CHESS use case.”
And
“ From a participant standpoint in the current design and architecture (not withstanding future use cases), there is little value to processing all the business logic on-ledger as ASX maintain data integrity as the market operator and participants receive a point-in-time view via API contracts.”
This really points to the complete ridiculousness of the project. The ASX is in the business of being a central market operator. The only advantage of a blockchain is to be distributed. So the ASX spent all that money on a project, that if it had worked, would provide no benefit to them. If successful it would pave the way to putting them out of business.
I don't _think_ Accenture were the original or primary contractor. I'm Australian and interviewed with Digital Asset for that project - as far as I'm aware, DA were the main company responsible, although from what I've heard from people working on it, a lot of the failure stems from mismanagement on the ASX side.
They failed to architect the project properly by trying to run everything on the blockchain smart contracts instead of leveraging something off chain. Similarly there was mismanagement from DA (the developers) and ASX with no clear goal of what the end product looked like or how progress was being made.
Accenture even call out that a blockchain solution might not have been the best one considering the ASX centrally settles trades anyway.
The pdf is a good read into the technical and management failings of the project
reply