rienko

We tend to find Qwen3-Coder-Next better at coding at least on our anecdotal examples from our codebases. It's somewhat better at tool calling, maybe the current templates for Qwen3.5 are still not enjoying as "mature" support as Qwen3 on vllm. I can say in my team MiniMax2.5 is the currently favorite.

use a larger model like Qwen3.5-122B-A10B quantized to 4/5/6 bits depending on how much context you desire, MLX versions if you want best tok/s on Mac HW.

if you are able to run something like mlx-community/MiniMax-M2.5-3bit (~100gb), my guess if the results are much better than 35b-a3b.

the cpu is certified by AMD to be running up to 105 celsius, but it thermal throttles automatically at 95 celsius, so out of the box probably not enough to boil water, but just barely :P.

the fun fact, is that if you manually reduce the power limit to 65W the initial single thread results so virtually no loss in ST performance vs 170W, and it appears that the original AMD slides stating 75% more efficient cores at that level not too far off.

To me this happens when the CPU starts throttling due to high temperatures, if you don't have something like menumeters installed it probably won't show itself on any other native Mac GUI.

For a long time the workarounds I've used to deal with this issue:

1) Charge from the ports on the right! The charging circuit on the left aggravates the issue.

2) Disable turbo charge by setting the mac into low power mode inside system preferences -> Battery

3) Raise the computer from the table for increased air flow, and not be in contact with latent warm from the table. Which has been heated by the mac itself.

4) Lower AC temperature

5) Change the Fan Speed from Automatic (default) to fullblast, or make it sensor based but lower the min/max temperatures for the fans to start spinning faster 38-60 celsius

Ever since my team started using Splunk (circa 2012), we claimed for a more open version we could tinker with and not cost an arm and a leg to ingest multiple terabytes of daily data.

Positioning as an opensource Splunk would be an interesting play. Going through your docs the union() function looks like it returns a set, akin to splunk values(), is there the equivalent to list()?

Elastic is great in its lane, but it requires more resources and has a monolith weight, that has left a sour taste from our internal testing. Doing a minimal ElasticSearch compatible API would open up your target audience, are there any plans to do you it in a short term horizon (< 1 year)?

This, but with extra noise around the signature and with at least 4 unique copies, max number of times one has to sign full name a document (in my personal xp). Whomever is going to read it and check for digital, will probably check closer on the signed pages. Also make sure the signature isn't too perfect and not too regular on the ink :)

They are a small company with small revenue

Funding (1) $1.7M

Yearly Revenue (2) <$5M

How much funding can they realistic provide for those priorities? State grants from Horizon Europe projects or similar could be an alternative source for funding, probably with better recurring probabilities but it would require a champion to lead through the burocracy and in the end it's a coin toss (or lower) to get approved.

Sources: (1) https://www.crunchbase.com/organization/pine64 (2) https://www.zoominfo.com/c/pine64-inc/372007622

If you do a 'shards install --ignore-crystal-version', it should mostly work. There aren't many breaking changes from v0.36.1.

It's very good for CLI apps, and quick one programs, web dev is decent Lucky is an awesome framework, the compile times make the code-compile-reload cycle subpar, specially if you compare it to scripting languages. Performance is normally excellent but the GC is suboptimal for some workflows, it's not yet written in crystal and it's too conservative recouping memory. The nicest side effect of crystal is that it's programs are far more likely to work on first compiles than ruby scripts, and the type system makes refactoring a large code base much safer.

multithreading is working with the -Dpreview_mt option, it's decent if the units of work are large enough at least 0,01ms, otherwise the channel overhead will dominate.

I find the API nice and easy specially for those familiar with CSP or go. Performance should improve once it gets the necessary love for it to be released to be on by default.

Windows requires a lot of boring work, especially considering most of the core devs use Linux / MacOS. Once they make it as priority it should be doable within a few months of work.

This comes from my experience building a prototype cli application, the language itself fells very productive, and the stdlib is robust fast and useful.

Compiling isn't fast. By the language design it won't ever be possible to be in the same ballpark as golang. It's common for us that our 5k lines app, take >1m to build in release mode as we added more and more dependencies for integrations with different nosql databases (elastic, rocksdb etc).

Using LLVM as backend is great for getting top notch performance, but to generate multiple IR methods for each type signature consumes a lot of time, especially when doing optimisation in release mode builds. I guess it's a similar problem that cranelift is trying to fix in Rust.

Open classes makes it hard to cache compilation results from dependencies / libraries.

At our company we have a bunch of Macbook pro 13" with butterfly keyboards that nobody wants to use internally, that in combo with the new M1s really made the resale value drop, it did leave us with a bad taste in the mouth.

I’ve researched many moon ago, breaking symmetries dynamically by adding clause conflicts. You take the search space build a graph with it and pass it to a Graph homomorphism detector. Then you create adicional clauses that break the symmetry by stopping possible assignments that limit the search space. The overhead of searching for symmetries and the exposition of dynamic clauses, make it a difficult trade off against the ruthless efficiency of traditional CDCL. Also many competitions used to occur every year to find out the fastest solver, these things have been optimized far beyond you would do for “normal” software.