It took me a while to start using canvases. But now I think they should be a much more common UI pattern. They really shine on large (40"+ non-retina 4k) screens. The simplicity at launch made me feel more confident in using them at all. I don't use most of the other obsidian features/plugins.
According to the EFF fingerprinting website, Firefox + uBlock Origin didn't really make my browser particularly unique.
But turning on privacy.resistfingerprinting in about:config (or was it fingerprintingProtection?) would break things randomly (like 3D maps on google for me. maybe it's related to canvas API stuff?) and made it hard to remember why things weren't working.
Not really sure how to strike a balance of broad convenience vs effectiveness these days. Every additional hoop is more attrition.
I use a 43" 4k tv at the standard non-retina 4k with an m1 pro. I tried your 8k supersampling but it doesn't seem to improve on the default 4:4:4 8bit rgb non-retina for me. (smoother but not as crisp outside terminals?)
The TV is unusable without BetterDisplay because the apple default negotiation preference. I hope waydabber can figure something out with you.
I think the poster is referencing that uBlock Origin does not work with browsers other than Firefox. And that while some sites work poorly (deliberately deprecating Firefox), other sites work very poorly (without uBlock Origin). Presumably spoofing user agents works for now but has its limits.
This was a little dense for me to grok. Are these well known results or is there an abstract-like summary?
The RYS (repeat yourself) hypothesis that duplicating (the right) layers is enough to improve performance (sorry for not reading closely enough, it's really just stacking the relevant layers?).
The ERD (encoding, reasoning, decoding) layer structure is a relatively robust observation? That the middle layers of the NN will reason in universal space, and this is kinda evidenced by cosine similarities of the hidden states at each layer given similar or dissimilar inputs. And that similar inputs converges by layer 5 and you can kinda watch that happen in the cosine similarities?
This post is incredible and I'm afraid it'll drop off the front page before people engage deeply with it. (The methodology was interesting, maybe there's other big ideas I'm missing.)
I find the RYS result far more surprising than the ERD result. Encode-Reasoning-Decode is after all a very popular way to design neural networks (even an autoencoder is just that without the reasoning step), the same structure emerging from optimization isn't that surprising.
But the methodology to measure it and put numbers on which layers are most involved in encoding/decoding and where the reasoning takes place is very valuable.
The finding that the phases are more cleanly separated in large-ish models is interesting. I wonder what this could mean for embedding models? Usually we take small LLMs and chop off the last couple layers to get an embedding model. But I wonder if you could get better embedding models using something like the first five layers of Qwen3.5-27B, or the first X layers of Kimi K2.5? The methodology in the article seems to give a straight forward way to find the optimal cutting point
Yeah the ERD result was known before I think, see "The Remarkable Robustness of LLMs: Stages of Inference?" https://arxiv.org/abs/2406.19384
But the fact that the intermediary circuits are generic and robust enough that you can just loop them is unexpected. I mean maybe it sort of makes sense in retrospect, the above and other papers showed the middle layers of an LLM behave more like "iterative refinement", so to use a signal processing analogy maybe you just keep applying filters and suppress the noise.
But by that same analogy, I'd predict that you can't just keep repeating layers, at some point you'll suppress the signal as well. Not sure if there was an experiment conducted with how many times you can repeat RYS layers before performance goes back down.
Perhaps not widely known but certainly known in LLM research. There was a bunch of these experiments done 2 years ago and what's interesting is that it still seems to work on the latest models.
Though beware that the increased score on math and EQ could lead to other areas scoring less well; would love to see how these models score on all open benchmarks.
The author claimed that the models he modified with this layer repetition method topped the huggingface open llm leaderboard in his first post: https://dnhkng.github.io/posts/rys/
Do you remember the names of the previous experiments done on this? Would love to take a look.
I think this is roughly true, but instead RAM will remain a discriminator even moreso. If the scaling laws apple has domain over are compute and model size, then they'll pretty easily be able to map that into their existing price tiers.
Pros will want higher intelligence or throughput. Less demanding or knowledgeable customers will get price-funneled to what Apple thinks is the market premium for their use case.
It'll probably be a little harder to keep their developers RAM disciplined (if that's even still true) for typical concerns. But model swap will be a big deal. The same exit vs voice issues will exist for apple customers but the margin logic seems to remain.
Is there any discussion somewhere about adding in the data that makes the x.com/twitter recommend/ranker so functional?
The "Grok-based Transformer"[0] that uses P(click/dwell/not_interested/photo_expand/video_view) seems pretty important and I can't tell how atproto is capturing it. I use @spacecowboy17.bsky.social's For You and from what I understand that feed wouldn't get that data?
(I also struggle with the omni-purpose likes - endorsement, approval, discover-algorithm-input. Maybe a more prominent more/less button addresses this, but then provides less network signal.)
Personally, I really like that my feeds aren't getting that level of granular detail. I prefer the explicit control I have with 'Show more like this' and 'Show less like this'.
I generally think that. But letting dwell time/clicks/open-rates expand the recommender and then (bound to swipe) 'disinterested'/'show less like this' to cull has been pretty efficient. I used to feel dumped into simclusters and now I see a more specific subset of posts I prefer (while still casting what feels like a wide net).
I really liked when bsky introduced the 'show more/less' and then expanded it to custom feeds. But I'm afraid the recommender systems work better with more data. And I think the feed operator alone gets sent a limited set of interactions?
I'm not exactly sure how it would work in atproto but I could imagine an enriched 'graph-interactivity' where you can turn on and off which/how much signal/privacy you want.
SBPL is great for filesystem controls and I haven’t hit roadblocks yet. I wish it offered more controls of outbound network requests (ie filtering by domain), but I understand why not.
Yes, Safehouse should work for xcodebuild workloads in the way you described - try to run it, watch for failures, extend the profile, try again. Your agent can do this in a loop by itself - just feed it the repo as there are many integrations that are not enabled by default that will help it.
I read a little from sandvault and they suggest sandbox-exec doesn't allow recursive sandboxing, so you need to set flags on xcodebuild and swift to not sandbox in addition to the correct SBPL policy.
(I don't think sandvault has a swift/xcode specific policy because they're dumping everything into a sandvault userspace. And it doesn't really concern itself with networking afaict either.)
This also applies to sandboxing an Electron app: Electron has its own built-in sandboxing via sandbox-exec, so if you're wrapping an Electron app in your own sandboxing, you have to disable that inner sandbox (with Electron's --no-sandbox or ELECTRON_DISABLE_SANDBOX=1). In the repo, I have examples for minimal sandbox-exec rules required to run Claude Code[1] and VSCode[2] (so you can do --dangerously-skip-permission in their destop app and VSCode extension)
I hadn't seen your site before (or been following SBC for a while) and just skimmed the article and was going to move on. (The post was very cool.)
It wasn't until this thread that I actually clicked through to the sbc.compare. I saw you complement the CIX P1 and Qualcomm in the post but it took looking at the Geekbench numbers on sbc.compare to understand the magnitude of the situation.
(I guess I'm saying the table might've helped me. But I still appreciate the post as is.)
The balancing of wanting to draw attention to sbc.compare and allow the post to stand on its own feet has failed it seems :D No worries, the feedback is good and I'll see if I get time to go back and add a summary for this, otherwise, I'll definitely take it on board for the next one(s).
It's more that definitions are made with an assumption of normal market conditions but what's happened in the DRAM market is extreme. Production of conventional DRAM package types has evaporated, while the demand is unchanged or increasing, because of new demand for HBM which is even more profitable.
So some common sense is required: yes under normal circumstances selling below the market price is dumping, but when the market price looks like a vertical line because of a sudden shock then you can't really take the market price too seriously. Mostly the price of DRAM is not set on the open market but is negotiated via contracts between the major players so there isn't really one price of DRAM at the moment. If you're a big customer like Apple you can get a price that is completely different from what you or I can get fighting for scraps on eBay.
reply