jonpalmisc

Eh, I kinda hope not. Codeberg's latency even for just browsing is pretty bad (in my experience) and also is only sporting a single 9 of uptime [1].

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

This still leaves your device in an AFU (after first unlock) state, with user data decrypted, and should not be treated as secure.

The only thing you can do (to protect your data from forensics, etc) is to return it to BFU by shutting it off.

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.

[1] https://support.apple.com/en-us/105120

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.

Going to take a guess the author is not a Spanish speaker :p

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.

Not using Emacs.app because you aren't on macOS, or using some other build/setup? If the latter, I'm curious.

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

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.

I think it's purely a pricing & supply chain thing. Certain iPads have M-series chips in them, now certain MacBooks have A-series chips in them.

Also, the chip used has no impact on the viability of merging macOS and iOS anyway.

The Developer Transition Kit (DTK) ran on the A12Z chip. I don't think this should be interpreted as a signal of iOS/macOS unification.

For a native macOS app, there is also Monodraw [1], which is great.

[1] https://monodraw.helftone.com

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.

This guy has a GitHub account [1] full of AI slop fake bug reports—this can be ignored.

[1] https://github.com/JGoyd

I also don't want to make the software network dependent in any way.

As a user of Monodraw in an airgapped environment: thank you!

Monodraw is great. If I could change one thing, I would make it more expensive. $10 feels like a steal, given the use I've gotten out of it.

Is it still not possible to use JUCE for free/open-source without the pesky "Made with JUCE" popup? Or did they remove that?

I don't think anyone is suggesting that the generated Rust is nicer than the original C.

It is auto-generated with the purpose of maintaining the exact same semantics as the C code, with no regard to safety, best practices, etc.—of course it is messier than actual, handwritten Rust.

As c2rust says in its documentation [1], it's meant to be the first step in an otherwise manual and incremental port of a codebase from C to Rust, and the author recognizes this in their closing remarks:

The next goal is to convert the codebase to safe Rust.

[1] https://github.com/immunant/c2rust/raw/master/docs/c2rust-ov...

Stubborn complaint (and maybe a hot take): I dislike CLIs that try to be overly pretty. I don't receive any tangible benefit as the user from the "fancy" (their words) help output. I'd much rather simple plain text output that looks like all the other tools I already use.

I can't believe it's even legal to sell those. That seems simply insane.

No. This is a myth, and while it does force you to enter your password instead of using biometrics on the next unlock, it is not the same as returning to BFU.

They have a long history of encrypting firmware. iBoot just stopped being decrypted recently with the launch of PCC, and prior to iOS 10 the kernel was encrypted too.

The operating theory is that higher management at Apple sees this as a layer of protection. However, word on the street is that members of actual security teams at Apple want it to be unencrypted for the sake of research/openness.

    ; which jq
    /usr/bin/jq
    ; jq
    jq - commandline JSON processor [version 1.6-159-apple-gcff5336-dirty]

cool site you linked there :)

Resources exist, but are only so helpful IMO.

One can't necessarily build an airplane after watching a documentary on it.

Even if there was some "bible" on it, reverse engineering is one of those things that you have to put the reps in for to get good at it and actually develop understanding.

The "bible" is tackling reverse-engineering related projects independently over the course of months/years and picking up knowledge along the way.

Starting with something like cracking software (and making increasingly-advanced cracks) is always my advice for beginners.