Plaid is the main risk - if they were hacked, that's way worse than a log of my AI queries. What's exciting with LLMs is the possibility to do classification much better.
Dr. Sandra Kooij is a good person to look up if you are interested in adult ADHD and sleep. She has a book about it. From what I remember, there are a few things that are known:
1. a large majority of ADHD sufferers are phase-delayed and struggle with insomnia
2. you can induce ADHD-like symptoms in normal people by restricting sleep
3. Some of the interventions that improve sleep timing and quality affect ADHD (but it isn't a total cure)
I love the codec and am glad to see it supported again. They overcame the security issues using a rust SIMD port. I wonder what "approximately as fast as the best non-memory-safe alternative" means - the wording suggests they didn't beat the C++ implementation, but how close is it?
The main outcome of the original papers is RR (relative risk) and the main number discussed in this article is "people living near a landmark" which is obviously nonsensical. You'd need to compute your "Costco risk index" using epidemiological risk compared with a baseline, and there's not one place here where they claim to do it. As written, this does not appear to be a serious effort.
I have two NVIDIA GPUs (16GB+16GB) here, and it detects them each twice (says I have 4 GPUs). But then, it says most models are too big (anything >8GB?) and seems to run only on one GPU (5070ti).
Unfortunately even with my 5070ti, llama.cpp seems to be about 20-30% faster at decode, running as:
set CUDA_VISIBLE_DEVICES=0
build\bin\Release\llama-server -hf google/gemma-4-12B-it-qat-q4_0-gguf -ngl 99 --no-mmproj-offload -mg 0 -c 262144 -fa on --host 0.0.0.0
AIs are no better than their training data, and there aren't high-quality cues everywhere - go ask advice for some highly-spammed topic like "mattresses".
Good post - the UV index is related to how short the "column of air" that the sun traverses to get to your skin - noon is the shortest distance. Scattering is a density function (more air, more scattering), so this is why it looks like cos^p when compared to normal irradiance (cos). It also explains why it is hard to get a sunburn in the temperate winter, since the sun always appears at an angle, it doesn't go directly overhead.
My MacBook has an external 1440p monitor (@1x) which has been adequate for Sequoia, but macOS 26 and 27 look awful for bold text, like the list of users in Messages looks really bad. The AppleFontSmoothing fixes seem to make you pick between "bold text looks ok" or "everything else looks ok" - and macOS 27 doesn't fix it.
I've been hearing a lot of "Amdahl's law" regarding AI - the rule that says the slowest part of a system sets the speed of what you can accomplish. On one hand, this means that AI has sped up software (so there is more software news because you can make a 20-page blog post in one prompt now), but it doesn't speed up, say, shipping hardware products that much. I guess we need to re-weight the news to include how hard it is, not just how many tokens it makes.
One problem is that the core-years for RSA-250 were in 2017 Skylake Xeon single core terms.
If you can rent a dedicated 96-core Epyc for $1/hour (cheap dedicated host), the combination of IPC improvements (>2x) and core count make 7,010 "skylake core-years" cost only $175k, not $5M. On-demand cloud servers (which cost more than $1, maybe $5/hour) probably make the GPU cheaper, but it's closer than the author says.
I remember thinking the Matrox cards in the 90s (Millennium, G400) had super-solid drivers, and their 2-D image quality was amazing. Interestingly, at the time, we were doing software 3-D rendering and NVIDIA RIVA TNT was much slower for bitblt. I guess they've fixed that by now. ;)
We know the typical LMS responses for human cones (e.g., Stockman-Sharpe) that could easily be plotted instead of the bell-curve-like things they use here - why? Is it good enough for illustration? You could say, kind of but then all the colors are kind of wrong too. For example, D65 is very blue here.
The article takes a really long time to get to the thing everyone should know: which is that our cones responses overlap a lot, and we get color sensations by (kind of) differencing them. Doing a matrix transform after ten pages to get to chromaticity is technically correct, but it's not the most accessible/intuitive way to teach this.
Nice effort but it would be better if it were closer to "real" color math.
No - there is a huge difference between "this AI created this image" and "this user did it" - the first we need more of, and the second is a big privacy concern. The article does not say anything about identifying a user.
Not telling someone you used AI is a perversion of writing. Also agree that an AI proofreader should not claim authorship, but in most other cases, the AI is not reading your mind, it's only watermarking its own usage, and we kind of need more of that.
It's fine for installing, but uninstalling is madness: Windows uninstallers try to clean up all the registry and user profile stuff they install. Mac apps seem to just leave stuff behind in Local Settings or Caches forever? Containers are not such a bad idea.
This seems to do XYZ->RGB without any gamma correction. XYZ is linear, as is the transform to RGB, so we usually convert linear RGB to (gamma-encoded) sRGB at the end.
The JS code seems to output linear RGB directly to the webpage (missing gamma). I guess the difficulty with "adding gamma" to it is this: if the training data were also gamma encoded, then it might need to be refit with linear values.
So if this Mac uses 30-50W, that's 40-60 tok/Wh...vs maybe 80k for a modern GPU cluster? So that's about 1000-2000x more power for the SSD streaming, unfortunately.
Nicely illustrated, and only one criticism: our preference for luminance (using more bits for "Y" vs "Cr/Cb") isn't due to the number of rods in the eye - there are so many rods so that we can capture more photons at night, and they are usually saturated at daylight illuminances.
The effectiveness of the YCbCr encoding is much more related to the predominant pathway to the LGN (80-90% of the "number of bits" used) encoding luminance and center-surround, so those things both map well to using more bits for "Y".
I think portability is very confusing: they rolled out passkeys with no device portability (device-bound) and only recently added it (CXP). So for anyone with multiple devices it was a relative disaster - why should my Windows PC hold a device-bound passkey to anything? How do I login on Linux or macOS?
Picking a password manager to do portability also means another kind of lockin, though maybe you can live with that kind if you really trust the company. Even so, the password managers all seem to be competing to have relaxed security, so that vault and account passwords are the same, or you are asked to type your master password into a webpage - surely we didn't replace per-site passwords with this?
Yes, I think part of it was the "dark fiber" at the time, made bandwidth relatively cheap. But most personal photos don't use that much bandwidth - being able to use them anywhere online (which iCloud and Instagram don't allow) was a big idea. We went from "my content hosted in the cloud" to "Instagram's content" in a lot of ways. That is only partly a pricing issue.