At the end of my "tech career" developers intoxinated with youtube tutorials and medium articles were writing stuff only for Chrome. After my comments that it fails in Firefox, everyone knew I'm the toxic non team player.
I hate the implication that apple is doing anything to stop you from booting windows like how phones prevent you from installing custom roms. The boot loader is unlocked, there is nothing stopping you from installing windows, apple just (rightfully so IMO) doesn't invest money in maintaining windows drivers for their custom silicon because... why would they?
I'm pretty sure bootcamp was only a thing specifically because the intel macs were essentially white box windows laptops with a nicer than average trackpad for the time. Trackpad drivers is a much smaller lift when everything else practically works out of the box
It's clique at this point I know, but "If steve jobs were still alive" he wouldn't give people the option to get a 14 with M5 Pro/Max or M6 while the 16 can only have a M5 Pro/Max. Yes, I know the 16 will get it, but I'm point out this weird recent trend where there isn't a clear choice for the non tech savvy person.
The major thing I notice about modern apple is they definitely rush to meet a deadline instead of just waiting for the product to be ready
Although I assume the actual disks will stop being produced soon, this is a good reminder that LibreDrive[0] exists and is unfortunately still the best way to watch blu rays
I feel like there has been a few takes on this (atuin desktop comes to mind[0] but apparently it's not a going concern anymore?) why hasn't it caught on?
I'm curious about this too. Org-babel, Jupyter, Atuin Desktop, etc. have explored similar ideas, but none became a mainstream way of working.
For people who used these tools long-term: what held them back? UX/accessibility, or do people simply prefer keeping documents separate from the actual work?
we saw a bunch of issues with desktop, in no particular order
1. authoring runbooks is difficult, most people barely document their work let alone make it executable
2. keeping runbooks up to date is difficult, they are error-prone across systems
3. agents are now pretty good at a number of the tasks these ideas solve for, and are good at working around issues caused by docs becoming out of date/etc
all these tools are great for your own notes, but are very difficult to scale
1. Ledge's bet is it shouldn't feel like authoring at all. I've always had markdown docs chock full of commands and docs so making them runnable was the next logical step for me.
2. True. Keeping any kind of documentation up to date is difficult
3. Also true. I'm hoping Ledge's built-in agent support will bridge that gap and allow agents to help keep the docs up-to-date
And yes, a "Team" notebook is a challenge. Technically anyone with SSH access can all share a Ledge notebook. But that probably doesn't get us all the way there.
Thanks again for providing your thoughts. This by no means is a solved problem but I'm interested to see where it goes!
Thanks for answering. That's really interesting.
Maybe agents flip this around. Instead of humans maintaining executable docs, the actual work generates the document.
It could become something like a PR-style review layer for agent work. You don't necessarily need to understand the underlying code or tooling, but you can inspect what changed, why it changed, and approve or reject it.
Do you think that would address any of the scaling problems you saw?
Ellie, I’ve greatly appreciated your work and your talks! Thanks for sharing your insights.
To give a bit more discouraging advice to Ledge, these tldr insights have made me run circles to resolve. My experience is that one will start getting into build system and dependency mapping to make this sustainable. And then if one wants something more universal, one ends up building something like homebrew, which doesn’t even cover all OSs for good reason.
As you dig deep across system dependency and updates and configurations, there are crazy, crazy, crazy cascading bugs that popup from personal experience. As an example of how this comes up in practice, this is why many teams end up building on Electron as a common cross-platform bug fixer (Tauri has catching up to do although generally works well).
I've used org-babel in big and small contexts for more than a decade. I generally reach for the patter for a few goals:
- Keep diagram source (eg Graphviz dot) with the document.
- Write software developer manuals that can reference code robustly as the code changes (eg include code snippets from source based on regex).
- Literate Coding / Reproducible Research pattern. Eg, org file explains and generates/builds/runs code and graphs/figures which then get included back into the document.
Some of the problems
- At some scale, one needs a DAG (eg make) or to make every command idempotent with fast no-op. Otherwise, each little change to a source block takes too long and there is a worry that something didn't update which should.
- At some scale, the document becomes the size of a library/package and it does not compose and/or I want to run the code outside of the document.
- The unenlightened around me do not use Emacs so an org file is a "me" file. In some ways this is a plus as it keeps others fingers out of my pie but it also means no way to share the baking.
That was in the days before LLMs. As ellieh's #3 points out, things are different now (we all know that). I now have an LLM externalize org-babel. The LLM maintains an org or LaTeX document describing bits of work, an external library/CLI which runs to produce content including putting numerical results into LaTeX macros, a Makefile or Snakemake to regenerate content and figures. When things are found to change prior understanding the LLM remakes a section of prose in the LaTeX document. I then write my own notes or another LaTeX document so that the trip through eyeballs to fingers on the keyboard assures I keep some level of understanding.
Likewise, in the software documentation goal, it's far better to give a good LLM access to the source and have it generate documentation targeting some learning goal with follow exploration via Q&A than it is to read some prepared document that assumes my goal. Software documentation is kind of a relic useful only for those people that have not yet taken up LLM tools.
> Because Opus 5.5 is comparable to Claude Mythos 5.1 in biology and cybersecurity, we’re deploying it with safeguards similar to those on Claude Fable 5.1.
Considering fable gives me a refusal at least once a day on my very mundane reasonable requests (in a funny example - one of the subagents suggested bypassing the rate limit for running a report inside my own cluster and that caused a refusal) and my only solution is to switch to opus - seems like my next step will be switching to Astra or K3/GLM
Heavily biased a kube admin but make kube clusters is easy now - its literally one command (aws eks create-cluster/gcp ... something something haven't done it in awhile after doing it multiple times a day in a past life) - I think its more familiarity with the tools that is the challenge - creating a vm is also easy if you know how, brew/apt/yum install is easy if you know how, setup.exe is easy etc)
reply