This is smart but harder than it needs to be.

Do we have a wrapper available that can let native Zoom launch and only have access to ~/.config/zoom and some USB input devices but not the rest of the machine?

Somehow building a custom MAC profile is expert-level stuff two decades on and not an end user's job.

An on-demand screen sharing permission popup should be achievable.

It's silly that a browser sandbox is better than any native sandbox available.

Perhaps such a tool readily exists and just needs to be mainstreamed into existing distros.

I know there was a Debian project a while back that aimed for all services to pass systemd strict security by default but nobody wanted to do the work.

That's the right mindset but separate from user apps.

There's some interesting stuff going on trying to understand more of the atomic structure beyond the current models.

The math on gluons has worked quite well but for some reason questions like, "OK, but what are gluons?" has been derided as "crank science" in Pergamon Press-gated Academia.

Such a diversion from Science from the beginning of Human history through the 1960's.

Structures like DeLay-Bendebury Fibers and other models of what's going on behind the math are happening outside of Academia where Physics PhD's are discarded and PhysEd BA's are celebrated.

Whichever model comes next will likely happen adjacent to the podcaster sphere and be reduced to useful engineering before Academics take a look at it.

There are plenty of good researchers working in institutions but for fundamental revisions at this point they all seem to need to leave Academia and go out on their own seeking private investment.

Which is fine except that we're all paying for the uninterested remainder. The great advancements that make our lives better always begin in fundamental science generating new models that better describe this reality. We don't get much from a jobs program for Mathematicians playing Physicists and it's very expensive.

It's quite strange that most people find the status quo completely acceptable and are willing to throw another $100B at a higher energy collider but are unwilling to grant base-layer investigations that are nearly free in comparison.

If we believe the former head of Skunkworks they've recruited the best and brightest since the 1970's and had made breakthroughs by the early 90's in at least topological physics. So we get to pay for that but aren't allowed to use it which is intolerable. But it's also understanble in a pre-Internet era where the only feasible choices were String Theory or black projects.

1) 30B, dense. Optimized to fit Q4 quantized in a 24GB card with a speculative decoding model as well.

2) Because reporters don't know what weights are and assume you don't know either.

3) Way better than Gemma 4 on text tasks, slightly better on multimodal. Numbers below are all: Benchmark: Muse Glimmer score Gemma 4 31B score difference

Artificial Analysis Intelligence Index: Muse Glimmer: 35 30 +5
MCP Atlas (Public): 75.5 54.2 +21.3
DeepSearch QA: 74.6 61.7 +12.9
SWE-Bench Pro: 51.2 36.9 +14.3
SWE-Bench Verified: 76.0 66.6 +9.4
OSWorld-Verified: 65.9 58.5 +7.4
GAIA2: 43.3 36.4 +6.9
WildClawBench: 47.6 37.6 +10.0
TerminalBench 2.1: 51.7 43.4 +8.3
Tau3-Banking: 23.5 15.1 +8.4
MMMU Pro: 74.0 73.0 +1.0
Charxiv Reasoning: 78.8 77.7 +1.1
OmniDocBench v1.5: 75.8 72.5 +3.3
ScreenSpot Pro: 75.4 75.9 -0.4

4) 128k tokens

5) No, sadly.

What you want is a DGX Spark.

It costs $4000.

And yes, there are fundamental advantages to cloud services, such as large-scale batching, little idle downtime, high speed, and hardware optimized to the specific models / serving needs. That said, one can weigh that off against sovereign control over your server...

Define "tolerable".

The model in question - Muse Glimmer - with DFlash/speculative decoding - will probably get you ~60 to 124 tok/s on a 3090 (a quite dated GPU). For a 5090, it's said to clock in at 233,4 tok/s. On CPU you're looking at maybe 3-5 tok/s.

If you call that "tolerable", I guess you're more patient than me? And as mentioned, you're not just wasting time, but also wasting a lot of power too - CPU is a very power-inefficient way to run ML models.

If you insist on CPU, this isn't the right kind of model anyway. You want to take advantage of the fact that you probably have lots of (comparably cheap) RAM, and compensate for the fact that you have (comparably) terrible memory bandwidth, and for that, you want a MoE with a high total parameters but a low active parameters. Not a dense model like this.

Then I was basically aiming at Mac Minis

That's very much a special case which you didn't mention in your post that I responded to, but still the answer is "meh". You couldn't run it at all on a 16GB Mac Mini, and I think you'd struggle to run it at all on a 24GB (because you have to share the ram with the OS, the inference server, etc). For the base Mini you might get 10-12 tok/s, and for the M2 Pro / M4 Pro, maybe 25-35 tok/s. Still pretty far from a GPU, though.

This model is designed for >= 24GB GPUs.

MoEs don't save RAM (for a given quality), they increase it. You have to store all of the parameters in memory, not just the active params. But inference only uses a subset of the total params for each token, so it reduces the memory bandwidth requirements and improves token generation rate. But this comes at the cost of a higher total param count for a given quality.

Meta has always been releasing open models (Llama was famously the first powerful open model). The change has actually been in the opposite direction, with Muse Spark *not* being open.

Zuck descrbed his motivation way back when, about how they got burned with Facebook on app stores, in that Apple and Google could basically bully them however they wanted, on whatever extractive terms they wanted, and there was nothing Meta could do about it. He's now paranoid about "others controlling the platform", and wanted to make sure that doesn't happen with AI, that they have their own AI base to work with.

I mean, if you want your model to be terribly slow and terribly power inefficient, sure, go ahead and run it on CPU.

This really isn't a good model for CPU. For CPU, you want a MoE with a large number of total params but a tiny number of active params. Something like DeepSeek V4 Flash 0731 if you have at least 128GB of RAM - you might get 2-3 tok/s or so on that. The goal is to minimize the memory bandwidth requirements per token, at the cost of a greater total RAM footprint.

For GPU, you're highly VRAM limited but not bandwidth limited, so your best option is generally a dense model (non-MoE) with speculative decoding to make up for the performance limitations.

You can use it fine on 24GB with a good size context with KV cache compression. They've also designed it to use speculative decoding to boost performance instead of a MoE, so that they can pack as much capability as possible into a dense model. Seems like a winner.

By complete coincidence I recently purchased this cordless angle grinder kit after watching a glowing review from one of my regular channels and wondering how good it could be for $75. It's not as good as a Milwaukee but I've been using it around the house and I'm going to modify a shoe rack with it this evening.

Of course this has nothing to do with the story and surely these aren't the types of arms the Framers envisioned when they set the foundation of upholding the Constitution upon the duties of the Citizenry.

Anybody remember Dubbya going on and on about gasoline made from switchgrass?

Somehow growing succulents in fragile desert ecologies and irrigating them seems like a dead end.

Maybe they got a government grant.

As someone alluded to above the forest litter causing all these fires may be a good source of cellulose. Betcha robots could make it economical.

Probably LRO vs. Danuri

Except instead of pursuing policies that would help open models at the expense of Big AI, anti-AI people pursue just the opposite - policies that can cripple open source AI but have no realistic ability to meaningfully hurt big AI. It's so short sighted.

Actually, no, what they usually do is much more insidious: fingerprinting rather than watermarking. The fingerprint isn't actually included in the audio, it's included in a database. If they want to tell if the track was generated, they just try to match the fingerprint in the database. Can't filter it out of the track like you can with a watermark.