Looks like the SoC (CIX P1) has Cortex-A720/A520 cores which are Armv9.2, nice.
I've still been on the hunt for a cheap Arm board with a Armv8.3+ or Arvm9.0+ SoC for OSDev stuff, but it's hard to find them in hobbyist price range (this board included, $700-900 USD from what I see).
The NVIDIA Jetson Orin Nanos looked good but unfortunately SWD/JTAG is disabled unless you pay for the $2k model...
There is a documented list of things that Lockdown Mode affects [1], this is not one of the advertised ones. There are a bunch of other (undocumented) things it affects (some of which are bugs :/), but I don't believe it has any affect on notification storage.
Settings > Notifications > Notification Content > Show: "Name Only" or "No Name or Content"
I've had this enabled to prevent sensitive messages from appearing in full whilst showing someone something on my phone, but I guess this is an added benefit as well.
The licenses (from major foundries/vendors) are indeed usually quite restrictive; however, the hard part has always been enforcing them. It's not surprising to me that Google hasn't built any guardrails around this.
After all, gating by IP address? What happens if someone from the marketing team logs on from an airport? All of the slides revert to Arial?
> You seem to think that the interface obliges a program into a certain performance pattern.
I think all software (or at least, any text editor) regardless of interface type should launch instantly. But it's more unjustifiable with TUI programs.
Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow.
Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.
Tangential, but I really wish there would be a performance renaissance with Emacs.
Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config:
$ time emacs -Q -e kill-emacs
/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total
$ time nvim -es --cmd 'vim.cmd("q")'
nvim -es --cmd 'vim.cmd("q")' 0.02s user 0.01s system 82% cpu 0.034 total
Even with a very minimal set of packages, text insertion, etc. is slower, and opening Magit (when it hasn't been loaded yet) takes about a second due to slow package loading.
Emacs is my favorite editor, full stop.
But every time I open Neovim or Sublime for quick tasks, it's always painfully apparent how much faster they are when I CMD+Tab back to Emacs.
There is a setting as of iOS 26 under "Privacy & Security > Wired Accessories" in which you can make data connections always prompt for access. Not that there haven't been bypasses for this before, but perhaps still of interest to you.
Not bad, but different DAWs cater to different workflows. To me (and most), Bitwig feels much more optimized for creating electronic music than recording guitar or drums. It wouldn't be my first choice for the latter workflow, where I'd prefer REAPER or Logic. You also still have the issue with plugin compatibility and that 99% of commercial plugin vendors don't support Linux.
For me: pro & creative apps. GIMP/Inkscape will never replace Photoshop/Illustrator/Affinity. Ableton, Logic, Pro Tools, etc. are not available on Linux and with the exception of REAPER, the alternatives are awful. And even with a Linux-compatible DAW, very few plugins are available on Linux.
On macOS, I can work on hobby software & graphics/music.
The times of browsers having weirdly different rendering behavior are mostly gone, in my experience. I'm sure ~98% of Electron apps that expect Chromium would render just fine/same under WebKit as well.
I wish Codeberg the best, but I thought it was a questionable choice for Zig and feel similarly for Ghostty—doesn't seem like a strict improvement.
[1] https://status.codeberg.eu/status/codeberg