The cause of this is that the cost of creating plausible code contributions has gone down, so PR proposals can multiply, but flaws still threaten project security and LLMs can be confidently wrong. So human review is needed right now to maintain the integrity of the project, but it takes time and costs money. Ladybird's developers, and we as a community, can't easily evaluate "this is what we want" vs. "this is not what we want" without manual review, because we haven't settled upon a reliable representation of the meaning of our code and its side effects that is time-efficient, secure, and meaningfully interpretable at scale.
This is partly due to Ladybird building on low-level system-language primitives that make it harder to identify problems, and while they are porting to Rust it's not fair to say that C++ is single-handedly the cause of this, because regardless of the language, in a complicated interconnected codebase the complexity easily compounds. It's a real shame we don't have the option of a trust-graph filter stop-gap that can filter contributors with a social model of who is trusted for what, purely as a heuristic to reduce the risk of bad contributions (not as solid proof of soundness).
This whole situation shows the way that development has been done isn't nearly as transparent as just having the source code being available.
We haven't been able to say what we want the code to do in a way that can be tested robustly enough to make openly accepting contributions sustainable, and it's unfair to blame the team for that because on top of needing to develop and review their own changes, it's an incredibly difficult problem with only so many hours in the day. I hope we figure out the representation and social trust graph problems, and that people continue to build on their great work.
Bad actors pay good money for vulnerabilities and patient actors are invested in slowly introducing them. Agent loops like Codex or Claude, with Anthropic's Mythos model finding ~271 Firefox 0-days, and helping fix them shows both the problem and the promise.
It's bitter-sweet in a way that Ladybird is great at showing how the incidental complexity of web browsers could be vastly reduced. To protest being gagged, cryptographers made t-shirts with DeCSS DVD or RSA algorithms on them. Alan Kay suggests that t-shirt computing is actually a useful target, and STEPS by his Viewpoints Research Institute managed to really distill some parts of OS-level and desktop publishing software down into minimal, more understandable abstractions that encode the rules of the programs with more appropriate patterns for the problems at hand, that might more plausibly fit on a small wardrobe of t-shirts. Browsers really need this range of t-shirts making.
As a minority browser user (and someone wanting to build on them), I'm excited to see Ladybird get increasingly usable for real browsing, and I am hopeful that in time, the spec representation gaps, and social trust map heuristics are solvable problems that could restore the dream of open-source, or at least stop a trend of closing (with tldraw doing this much earlier, for a less risky but still thorny project).
I got a pocket-sized Bluetooth keyboard (also used for travel around Asia), 195mm x 85mm x 15mm, with a flap - NOT a foldable keyboard, though it does have a cover flap and a kickstand. Sold under a few brands, but the dimensions are quite specific. Mine was sold under a "Doohoeek" brand; "CACOE" is another. It doesn't have a touchpad, though.
Its size reminds me of my Psion Series 5 days many years ago. While it doesn't clamshell-mount my phone, my phone sits on the KB nicely, though it's still two things to carry around, not one (I miss the Psion still). I have bought loads of Bluetooth keyboards. Foldable keyboards have more parts to break and have to be unfolded to use them.
Previously I got the TECHGEAR Active Strike Pro MINI Slim (230mm x 149mm x 6mm), not pocket-sized, but it has a touchpad. The Geyes Foldable "tri-foldable" (223mm x 54mm x 18mm closed, 223mm x 170mm x 6mm open) got a broken hinge.
For comparison:
- Pocket keyboard ("Doohoeek", "CACOE", etc): 195 x 85 x 15 mm. Pocket-sized, flap/kickstand; no touchpad.
- TECHGEAR Active Strike Pro MINI Slim: 230 x 149 x 6 mm. Not pocket-sized; has touchpad.
- Geyes tri-foldable: 223 x 54 x 18 mm closed; 223 x 170 x 6 mm open. Foldable; hinge risk.
I'm not sure that copying a key after unlocking the system counts as a backdoor? If the OS promises to lock access to the key and fails to do so then I can see the logic that people might then call that a backdoor. But it's different from there being a key bypass, or a pre-shared key (or such), which it seems like the article suggests? For the record, I don't use Windows (so glad).
Would ADS-B Exchange heatmap files would be accessible at even DEFCON 2? Which raises the question of what it would show when the data sources are not available.
Yeah, though it's not great marketing. Especially for hiring interpretability researchers. Their own alignment research has reward model interpretability, personality features and so on (see https://alignment.openai.com ).
It just seems like a different department wrote it, which is a shame because I'd love to read about goblin feature vectors and functional emotions.
It's a funny detail to skim, but what's more surprising is how mechanistic interpretability and alignment science have much better tools and research than the goblin blog post suggests, including from OpenAI's own alignment team:
Will mandatory ID gatekeeping of developers have ecosystem effects? Surely the only question is how much? You may install apps over ADB every day, but APK installing is much more convenient and open-source F-Droid developers currently don't have to do a thing to be "allowed" to ship APKs.
`The entire point here is to prevent scam actors from using a false sense of urgency to defraud people.`
The proposed architecture is a general developer gate, it is not a proportionate response to the problem - it isn't even proposing to gate specific app permissions, it's being able to install the apps from APKs at all under a regime they administer, with users forced to have this change with no prior consent, only opt-out, and distribution limiting work-arounds (that harm reach).
If Android were to ask the user if they wanted to disable installing downloaded apps from developers who haven't shown Google IDs for their own safety, and let end users give informed consent about what self-protection behaviour level they want for their system, at the point of roll-out, or device setup, that would be quite different.
Why should Google be trusted to gate what apps can be easily shared, when stock Android won't even allow users to toggle Internet access per-app? It isn't proportionate compared to other permissions they could mediate, and worse, it's a centralised architecture vulnerable to authoritarian pressure, and afterwards they will be well positioned to lock it down more.
But the "opt-out" will not prevent ecosystem effects caused by the default shutdown of convenient app installs due to the policy. Not even for GrapheneOS users. It's a global policy by a body we never voted for. You can't opt-out of that different world by waiting 24-hours, the ecosystem could have permanent effects. This is coming from a company that doesn't even bother to expose a permission to disable Internet access per app. It's there underneath, but they just ... don't expose the choice.
Hey akshayka, I'm not that teacher, but I am a fan, and I notice that marimo sharing would be easier if export and import from normal boring Spyder/Jupyter percent formatted .py files worked by default, instead of indented `@app.cell` decorated functions, and same for for plain Markdown, where right now it has "{.python.marimo}" code blocks with triple backticks, that would normally just say Python. Import and export that used more normal metadata (like comments) would be amazing and would make pointing people to marimo easier. Any chance of this?
So we need a new standard problem due to the complexity of the last standard? Isn't unicode supposed to be a superset of ASCII, which already has control characters like new space, CR, and new lines? xD
Should we really buy the many months of switching difficulty argument?
Surely the main API surface is a HTTP API like ChatCompletions? If it's the exact shape of Anthropic's API, the difference is surely minor. There are likely up to 2 API surfaces, that's it. If the OpenAI model APIs are more flexible (esp. with the new 1M context of GPT-5.4), then it should have little difficulty adapting. Then there is LiteLLM and similar that make it even easier, half of their tooling should be using something that abstracts like that anyway. Yes it needs evals and prompt engineering work to optimise it, but they should be used to that by now. Presumably they could even clean-room fine-tune an OpenAI model to match the same Claude shape with low loss. So I don't buy it.
Currently it says they have released metadata and album art. Is archiving and sharing the textual track metadata alone (no images, no audio) legal in the US, or Europe? By what basis is it legal or illegal?
I had the same reaction as them many months ago, the Google Cloud and Vertex AI stuff namespacing is a too messy. The different paths people might take to learning and trying to use the good new models needs properly mapping out and fixing so that the UX makes sense and actually works as they expect.