Why do we even want to pay $500 per device for something that is easily replicated by a $1 paper notebook? The only people that benefit from forcing classrooms to adopt these devices is big tech relying on corporate welfare to juice their books.
I recall some research in the TV age. They observed, if the subject is looking into a light source, (be it a camp fire, a screen or a bulb) they go into a kind of sleepwalking mode. They also mentioned the phenomenon was already well documented by hypnotists.
In the early internet days I couldn't help but notice people who read zero books now spend the whole day reading.
I think it means the tool is used the wrong way? Interactive should be e-paper or real paper. Dull cramming or basic reading skills would be a good fit for glowing displays.
You also don't get the physicality as part of recall with eInk over real books. When reading technical books, as an example, I often would look back when going to review something based on where it was physically in the book... I completely lose that with ebooks.. I still mostly use ebooks and online docs these days all the same because moving hundreds of pounds of books when you move sucks.
At least with OLED, the light output can be auto-adjusted to match the reflecting light of the environment. This can be quite convincing, looking like a purely reflective surface. And a dedicated app doesn’t need to use any distracting animations or highlights.
I friend of mine once made an observation that really stuck with me: a kindle is not a book: it is simultaneously all books at once. If you lock it to a single book, its still all books at once, but with a lock on all the others. Also, why not use paper?
I’m not an advocate of using tablets in class, I was just curious where the parent is seeing unavoidable distractions, compared to traditional tools like for example textbooks and calculators.
Blue light changes the way you think. Makes it easier to focus on the thing emitting the light, than the rest of the room. Just having a screen, with perfectly locked down control, can distract.
It's just not as good as a notebook. I've tried to make it as good. It sleeps, there's too much fumbling around with it to get to what you want. You lose the muscle memory of where something is in the book, you can't quickly flip to anything. You notice you used to do certain things, like flip to two different pages at once. Everything is just immediate and tactile.
I’ve read this article every time it’s gotten posted here and it’s always gone a little over my head. I was able to follow how he used 8 x86_64 registers for the VM’s stack slots and how the VM instructions were implemented. How the padding and alignments of each version of the instructions was calculated is impressive and I can imagine how much of a chore it would be to figure out with a normal assembler.
Using SBCL as a macro-assembler is extremely cool, and then allowing CL code to call into the VM is where it really blows my mind.
Obviously it’s been over a decade since this article was written. For someone less familiar with SBCL internals (or CL in general), would something like AsmJit or Iced be a good way to achieve similar things?
> Using SBCL as a macro-assembler is extremely cool, and then allowing CL code to call into the VM is where it really blows my mind.
Absolutely. I think TFA is hooking into the actual code emitter used by SBCL's evaluator-compiler, since it's not actually primitive, but implemented in Lisp and loaded into the image itself.
My guess at context: from the earliest days of Lisp, I think there was an expectation that Lisp systems would expose as much of their internals as possible... including their internal JIT, which is being plugged into here. I think the name for it was the "LISP Assembly Program" (LAP).
This is basically how bare metal Lisps used to work, all the way when Lisp based OSes from various vendors happened (aka Lisp Machines / Interlisp-D / StarLisp...).
The approach is similar to Forth.
You have a few key forms that provide the required integration points with the hardware, those are the few ones written in Assembly.
Including the reader and at least some of the macro capabilities.
Then everything else is built from them.
For a time travel into those days see the recovered Interlisp-D system from Xerox PARC, https://interlisp.org/
In the early 1990s I worked on a couple of different projects at Apple that were done mainly in Common Lisp. When I was working on one of those, another of them hired a guy named Dave Vronay a young skater and assembly-language game-machine hacker to work on graphics and UI stuff. The Lisp we were using is the one that started as Coral Lisp, became Macintosh Allegro Common Lisp, then Macintosh Common Lisp, then OpenMCL, and more recently Clozure Common Lisp.
I remember stopping with a friend to chat with Dave one day not too long after he joined the team and he was over the moon about how the Lisp exposed not just an assembler, but an interactive assembler: he could write assembly routines, evaluate them, and see them run immediately, and also inspect the in-memory data that they operated on. He seemed so happy.
Try pair reading it with a good thinking LLM like GPT 5.5 or Claude Opus. I found it help me a lot.
I have started learning SBCL internal from the beginning of this year with the help of GPT, and I really want to contribute to SBCL compiler someday in future.
The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.
It's not just Xen, it also relies on the hardware-assisted virtualization (VT-d), which is virtually unbreakable compared to anything else. Most Xen vulnerabilities do not even affect Qubes: https://www.qubes-os.org/security/xsa/#statistics
I just tested this in the U.S. with a toaster plugged into my outlet and there was a 40 Hz peak in the graph. I had a hard time telling where the wires were in the wall, though, maybe because the toaster itself was too close.
As I understood it, Memory Integrity Enforcement adds an additional check on heap dereferences (and it doesn’t apply to every process for performance reasons). Why does it crush hacking rather than just adding another incremental roadblock like many other mitigations before?
I'm not certain there is a performance hit since there is dedicated silicon on the chip for it. I believe the checks can also be done async which reduces the performance issues.
It also doesn't matter that it isn't running by default in apps since the processes you really care about are the OS ones. If someone finds an exploit in tiktok, it doesn't matter all that much unless they find a way to elevate to an exploit on an OS process with higher permissions.
MTE (Memory Tagging Extension) is also has a double purpose, it blocks memory exploits as they happen, but it also detects and reports them back to Apple. So even if you have a phone before the 17 series, if any phone with MTE hardware gets hit, the bug is immediately made known to Apple and fixed in code.
An exploit in TikTok is bad if your goal is to gain access to a TikTok account. And there is a performance hit it’s just largely mitigated through selective application
Thanks! I wonder how they enforce retention of personal data if a user adds identifying data and they use a model from anthropic or wtv like others said. maybe that is the wrong question at all if they are using their own models but i thought they didn't. Apple's AI strategy on the whole sounds coherent to me but the specifics are super confusing.
reply