dryark

hace 4 mesesdiscuss

I'm against AI. I've written two books on the topic so far. I also use AI, as I must if my software company is going to make money. There is no choice any more.

If I had a choice I wouldn't use AI for anything, ever. It's a blight on humanity. But it is a blight everyone has chosen so we are stuck with it.

dryark

hace 4 mesesdiscuss

One important thing the article glosses over: even if you sign your binary with task_for_pid, that does NOT mean you can attach to arbitrary processes on modern macOS, especially on Apple Silicon machines.

There are two separate layers people often confuse:

1) Having the task_for_pid entitlement 2) Being allowed to obtain a task port for a target process

AMFI and the kernel enforce the second one.

Even if your binary has the entitlement, the kernel will still refuse task_for_pid() for many targets (Apple platform binaries, hardened runtime processes, protected tasks, etc). In those cases the call simply fails.

Older blog posts and guides often mention disabling AMFI with a boot argument like:

    amfi_get_out_of_my_way=1
    (also seen as amfi=0x80)

Historically that worked because AMFI behavior could be weakened via NVRAM boot arguments. The flag effectively disabled entitlement validation and allowed processes to obtain otherwise restricted capabilities. :contentReference[oaicite:0]{index=0}

That advice is now largely outdated on Apple Silicon.

On modern M-series Macs the boot chain is tied into Secure Boot and the Secure Enclave. The kernel image, boot policy, and security configuration are verified during boot, and the system enforces what boot arguments are allowed to affect security policy.

In practice this means:

• You cannot freely change security-sensitive boot args from a normal system. • Boot policy is enforced by the secure boot chain. • Root does not get to override it.

Changing these policies requires booting into Recovery and modifying the machine’s security mode (Reduced Security). Even then, many AMFI protections remain active.

So the old “just set amfi_get_out_of_my_way and reboot” trick that worked on older Intel systems does not translate cleanly to Apple Silicon machines.

As a result, signing a tool with task_for_pid does not magically give you the ability to attach to arbitrary system processes on modern macOS. Without weakening the system’s boot security policy or patching the kernel, AMFI-protected processes remain non-attachable by design.

dryark

hace 6 mesesdiscuss

I find this political mess to be interesting, but I'm not sure it's an appropriate topic of conversation for the "professional community."

It looks to me like people on both sides were bothering the other over and extended period of time and it got worse till it led to this.

Having seen similar over my career I don't understand what digging into this accomplishes besides making all sides more upset.

I do think it is wrong for the professional relationship ( continuing to sell technology ) to be ended over a personal dispute.

From where I stand it looks like Phil is attempting to defend himself by being open about what happened even though the whole situation seems unpleasant.

Besides that I think it is likely best if all sides in this just cease communicating or saying anything more and move on from the personal stuff.

My two cents.

dryark

hace 6 mesesdiscuss

I've been working on two projects recently. A video game titled TentFires, and letterpress book remastering.

TentFires is a variant of the puzzle game Camping / Tents-and-Trees, but with a huge overworld.

Creating the overworld led to some advancements in topology, which led to realizing those advancements can be used to accurately reconstruct a theoretical "metal die shape" that was used for a glyph to creation impressions in old letterpress books.

As a result, my current first application of that is to remaster and re-release the first book of the "Hardy Boys" series from 1927, "The Tower Treasure".

To do that, I've constructed a "macrogrammetry rig", which is essentially a 2d x y panning machine using 3d printer parts and stuff from my local hardware store, and a camera with a macro lens, in order to "scan" the pages of the book at the highest possible resolution I can reasonably do so at, which is currently around 6000dpi.

dryark

hace 7 mesesdiscuss

The initial input is high resolution images using a DSLR and a macro lens, or at least it will be soon. Initial testing of the method has been done using 200mp images taken casually with a standard modern cell phone.

The underlying new computational geometry method can be extended to 3d but that isn't necessary for this application unless we also extract a 3d image of the page itself. For now at least we are not doing that as it would be even more complicated and finicky. Possibly for soft enough pages the letterpress imprint will deform the page enough that the deformation can be detected and help figure out where the original metal pressed and where the ink is due to page bleed.

Essentially what we are doing is taking high resolution photos, using computational geometry methods on those to extract the shapes, and then refining those shapes through a mixture of automation and manual labor.

The entire thing is called "Donkey Free" and will have information online in the near future. I just bought the domain ( donkeyfree.com ) for this 2 days ago; this is all extremely new. I'd like to release the resulting fonts under a license allowing free use for many purposes but we still need to think through that to figure out how to make that sustainable.

dryark

hace 7 mesesdiscuss

Great questions — and you’re absolutely right that Latin vs. CJK is effectively two different universes in terms of reconstruction.

1. Latin vs. CJK differences Latin glyphs are structurally simple: limited stroke vocabulary, mostly predictable modulation, and relatively low topological variation. Once you can recover outlines and stroke junctions accurately, mapping to Unicode is almost trivial.

That can be done with standard OCR methods for Latin.

CJK is the opposite. Each character is effectively a miniature blueprint with dozens of micro-decisions: stroke order, brush pressure artifacts, serif style, shape proportion, and even regional typographic conventions. Treating it like Latin “but bigger” doesn’t work. So the workflow for CJK has extra normalization steps and more constraints, especially when reconstructing consistent glyph families rather than one-offs.

From a simple perspective, CJK has many characters with disconnected pieces that are still part of the same character.

2. How we match scans to Unicode entities We don’t rely on conventional OCR at all. OCR engines are optimized for reading text, not recovering the underlying design intent. Our process is closer to forensic glyph analysis — reconstructing stable structural signatures, then mapping those signatures to references.

This ends up being a hybrid: • deterministic structural matching • limited supervised correction when ambiguity exists • and zero reliance on any off-the-shelf OCR models

It’s not “OCR first, match later.” It’s “reconstruct the letterpress structure, then Unicode becomes a lookup.” OCR quality literally doesn’t limit us because OCR isn’t part of the critical path.

3. What determines coverage Coverage is defined by what we can physically access and reconstruct cleanly. For Latin, coverage is straightforward. For CJK, coverage is shaped by: • typeface completeness in the source material • the consistency of impression depth • survivability of fine strokes in early printings • and the practical question of how many thousand characters the original font designer actually cut

There’s no need for the entire Unicode set per book. The historical font only ever covered a finite subset. It is unfortunate that every book doesn't use every glyph, but not catastrophic because we can source many public domain books from the same era and eventually find enough characters matching the style.

In short: Latin is an engineering challenge. CJK is an archaeological one. OCR is not a bottleneck because we don’t use it. Coverage follows the historical material, not Unicode completeness.

dryark

hace 7 mesesdiscuss

Yes. I did see that other article. No the process we are using is not using AI. We are not using OCR either. We are using computational geometry and forensics methodology. No flatbed scanners. No sheet fed scanners.

This isn't like anything ever done before. It's entirely different and higher quality than any result you can get through AI or OCR.

I do agree that detailed work is required to do it correctly and produced high quality results. I'm not offhandedly saying "just do these simple things and bam perfection."

dryark

hace 7 mesesdiscuss

The Monotype pricing change is brutal, but there’s a workaround. Derive new Japanese font families directly from public-domain sources.

I’ve been working on doing exactly that. Reconstructing clean vector glyphs from old metal-type Japanese books. The quality of those prints is surprisingly high, and they include thousands of kanji in consistent style. With some new technological innovations and a reasonable amount of hard work, you can produce a completely new, fully legal font family without touching any commercial IP.

The method I've devised is proprietary, but I’ll say this: it’s absolutely possible, and the output rivals modern JP fonts.

Given the sudden jump from ~$300/year to ~$20k/year for some devs, I expect more people to go down the “rebuild from PD artifacts” route instead of staying locked to a monopoly.

Submissions

AI Copyright Truth

Show HN: Minibrew – Run Homebrew packages without Homebrew

comments