No... that website is not helpful. If you take it at face value, it is claiming that the previous Qwen3-Omni-Flash wasn't open either, but that seems wrong? It is very common for these blog posts to get published before the model weights are uploaded.
Based on things I had read over the past several months, Qwen3-Flash seemed to just be a weird marketing term for the Qwen3-Omni-30B-A3B series, not a different model. If they are not the same, then that is interesting/confusing.
What are you talking about, there has been a AWS client forever and I've never had a problem. It's not something you really need an official sdk for they are anyway often just reference because you might want different performance characteristics.
I've usually not seen more than 3 or so official SDK for most services and there are a lot more programming languages than that. For example Microsoft's Graph API doesn't have an official Ruby client, they have one that sort of works.
The main lib everyone uses, :ex_aws, has been actively maintained for literally over a decade[1]. Official or not, it's used by literally the entire community, since even non-AWS services often will support its API.
I still don't understand this. If you are big enough then you get Amazon to make an official sdk, if you aren't then what exactly are you looking for?
The official aws cli used to talk to the soap interface and used regex instead of actually doing correct error handling and that was used by so many tools. Even though it used to break horrible.
It's quite a niche you are talking about, not big enough to debug open source code but still big enough to require SLA for SDK and not being able to talk Amazon into creating it. It's generated code, it's not rocket science.
What I have experienced is that software licence, where you are sending data to, where you are hosting it and having access to audit the code has usually been a bigger concern.
But then again big organisations often have really specific concerns. So I'm not doubting your statement it's just that I have never heard it before.
Very exciting, there are so many things happening in the Elixir Machine Learning space, with all of it focusing on being easy to deploy and test yourself.
I just love that you can create robust ML services. Which for me, isn't as easy to do in Python, even though I've created async service with core Tornado before asyncio was a thing.
I don't understand how this is a difference between stacked diffs and feature branches. Github allows you to use feature branches. I can see there might be some convenience with tooling
It's a fair question! There are a lot of perks to splitting up your change into multiple PRs rather than one feature branch. You can parallelize getting reviewed while writing more code. If CI fails, it fails on a more narrowly scoped change and is easier to debug. If something about one of your changes is unmergable, you may still be able to merge in half of your stack, rather than your change being all-or-nothing.
A lot of the benefits remind me of other dag-based workflows, like CI, data pipelines, or build systems. Does that make sense?
tl;dr the difference is a stack is merged partially as it's built out (that reduces merge conflicts, allows you to revert individual parts as found) and a feature branch is long-lived. Hope that helps :)
So the question is why a project created in a language that has been around since before the devices being emulated are more mature than ones in a language that is 8 years old?
Sorry to be so snarky. It probably depends on people's time working on it and their familiarity with async processes. This is an inherent problem with any media like that. With sound, it's primarily that it can't come before the image but can lag behind the image. Stuff like this.
I don't think any programming language is going help with that because it's how we perceive things, not just how correct your code is.
I feel like the biggest problem is most COBOL code is heavily tied to the mainframe it's running on [1]. There are already ways of compiling COBOL code with a modern compiler [2].
There are also multiple other translation projects:
