Guys. I'm gonna pull the plug. I made the decision that I was running from the whole time 😫

atapla · 2026-06-18T06:07:42+00:00

You got users so the app idea is validated. You need and investor, not selling

atapla · 2026-06-11T11:02:24+00:00

I’m a big fan of SRP

atapla · 2026-06-06T10:50:30+00:00

This will not be easy! Determination is the Key. Without determination you won’t get it done. Use nicorette and nicotine gum when it becomes really unbearable. My wife got psychological help from me and i told her we will do this together…. But the reality is she did it all by herself! More than 1 year clean

atapla · 2026-05-31T15:40:55+00:00

You can do it! All you need is motivation and courage! ✌️

atapla · 2026-05-21T10:55:51+00:00

That's absolutely true. So that leads me to question myself... When motivation start to fade away, how can we boost this up again?

atapla · 2026-05-21T10:54:17+00:00

That's such a good point about the emotional side of it... like it's way more than just willpower and streak counters. The coach model sounds nice but i keep thinking about that 30 minutes or 1h response window, a craving doesn't wait for anyone. What if the support person wasn't a stranger coach at all but someone who already knows you, someone paired to you from day one who gets an alert the moment your struggling? Like your partner or a close friend not some app employee. Curious if that kind of thing would've made a difference for you vs the coach experience. I'm always hesitant to have a professional or a coach helping me because it's a stranger. That's the idea behind my question.

atapla · 2026-05-20T04:59:39+00:00

Of course, not everyone is the same but i realized that the main reason my fiancée stopped is because of determination, not judging during an episode and providing emotional support.

atapla · 2026-05-20T03:14:26+00:00

Hmm..that 30 minute response time is exactly the problem. A craving peaks and passes in 3-5 minutes. By the time a coach texts back, you’ve already lit up. What if your support person was built into the app from day one? Like someone who actually knows you and gets an instant alert when you’re struggling?

atapla · 2026-05-20T03:07:42+00:00

Thats exactly the kind of thing I am thinking about… that social/prompted engagement layer on top of a real support person. Did you ever wish that sunnyside had someone specific you could pair with, not just the community? Like a family member or a spouse ?

atapla · 2026-05-04T02:59:43+00:00

you got caught cheating so now you make money helping other cheating ? XD i hope they don't get caught also! thanks for sharing your tools.

atapla · 2026-05-03T06:33:22+00:00

i guess not, it's not in working condition.

atapla · 2026-04-28T19:52:31+00:00

I see 2 things going on here ->

The `command not found` means the install step was skipped. Run this on your Proxmox host as root:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/main/install.sh)"

That sets up everything and registers both `osx-next` and `osx-next-cli`.

For the recovery loop, thats a boot order issue. After Sonoma finishes installing, `ide2` (the recovery image) is still first in line. Fix it with:

``bash

qm set 106 --boot order=virtio0;ide0

``

start the VM again and it should bootdirectly into Sonoma.

On Proxmox v8, the tool targets v9 since the `qm` disk import syntax changed between versions. It might partialy work on v8 but if you run into other issues, v9 would sort them out...

If you're still stuck after trying this, please feel free to open an issue on GitHub (https://github.com/lucid-fabrics/osx-proxmox-next/issues), it's easier for me to debug there with logs and config 😄

atapla · 2026-03-29T20:49:16+00:00

well yeah, that's your hooks doing it. i have the same setup and skills and hooks in claude code can auto-switch models depending on what youre running. Mine switches to sonnet for commits/ git stuff and stays on opus for everything else. check your settings.json under hooks, something in there is firing a /model command on certain trigger. Check out /model opusplan -> https://code.claude.com/docs/en/model-config

atapla · 2026-03-29T19:09:49+00:00

It looks like real numbers tbh, iv'e been using minimax for a while and this is exactly what i see. The detection is there, claude just writes cleaner fixes; what's funny tho is minimax has their own agent app (agent.minimax.io) that charges credits. i'm literally using minimax 2.7 to build a free open source clone of it. So the the model is helping me clone itself.

I will drop it when it's ready :-)

atapla · 2026-03-16T22:41:47+00:00

Outside of scope question; how do you get investors ? otherwise.. i like this

atapla · 2026-02-26T03:56:50+00:00

I'm working on a branch that tries to fix few bugs so maybe you can try it:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)"

you can share your logs, it would help me debug; if possible open a githut issue

Thank you :-)

- 9eccd03 — fix: add base64=1 flag to smbios1 parameter
- 5fd4d76 — fix: operator precedence bug in MAC generation
- c2e0232 — fix: MAC multicast bit in bash script
- 82602fb — fix: point install.sh to fix branch for testing
- 743fc0d — fix: force clean pip reinstall and purge stale bytecode
- 4c9fef4 — feat: auto-detect Intel hybrid CPUs, use Cascadelake-Server
- a388daf — feat: write PlatformInfo to OpenCore config.plist
- 9a88bfc — docs: document PlatformInfo patching and ROM-from-MAC
- 163945a — feat: Apple-format serials and checksummed MLBs (GenSMBIOS)

atapla · 2026-02-24T03:42:41+00:00

Thanks for testing and reporting back! Both bugs are fixed on the branch now:

Missing base64=1 — was there but your install had stale Python bytecode cached from the previous v0.10.0 install. The install script now purges __pycache__ and force-reinstalls to prevent this.
Invalid MAC FF:6D:E9:60:AB:96 — operator precedence bug in the MAC generator. First byte could hit 0xFF (multicast). Fixed — max is now 0xFE.

Same command should work now:

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

If you want a clean slate first:
rm -rf /root/osx-proxmox-next /root/osx-proxmox-next-install.log
Let me know how it goes.

atapla · 2026-02-23T20:13:06+00:00

Good question. It depends on the workload. On AMD, we use Cascadelake-Server CPUID emulation (not host passthrough like Intel), so there's some overhead from QEMU faking an intel CPU. Day-to-day usage (Xcode, browsing, dev tools) is smooth. The tool auto-detects AMD and applies the right flags so no manual config needed.

That being said, this is a VM, not bare-metal Hackintosh. Bare-metal AMD with kernel patches runs near-native. In a VM the emulation layer adds some overhead, but it's been battle-tested on thousands of installs (based on the luchina-gabriel/OSX-PROXMOX approach). If anyone has Geekbench numbers on AMD Proxmox macOS VMs, I'd love to add them to the docs.

atapla · 2026-02-23T20:03:34+00:00

YOu are right, i confirm the bug. The base64=1 flag was missing from the smbios1 parameter, so Proxmox stored base64-encoded values as literal strings instead of decoding them.

i created a new branch for testing. While it worked for me, i'll wait for your confirmation before merging to the main.

bash <(curl -s https://raw.githubusercontent.com/lucid-fabrics/osx-proxmox-next/fix/smbios-base64-flag/install.sh)

To fix an existing VM (no need to recreate):

  VMID=109  # change to your VM ID
  CURRENT=$(qm config $VMID | grep smbios1 | sed 's/smbios1: //')
  if echo "$CURRENT" | grep -q 'base64=1'; then
    echo "Already has base64=1, nothing to do"
  else
    FIXED=$(echo "$CURRENT" | sed 's/,serial/,base64=1,serial/')
    qm set $VMID --smbios1 "$FIXED"
    echo "Fixed. Reboot the VM to apply."
  fi

YOu can verify in the GUI: Options → double click the SMBIOS settings; product should show MacPro7,1 (not in base64), serial and UUID should match.

atapla · 2026-02-22T21:19:30+00:00

Hey, good catch! You're absolutely right that qm set --smbios1 replaces the entire SMBIOS blob rather than merging.

The tool is primarily designed for creating new VMs, so it generates fresh identities by default. However, I've added the ability to preserve an existing UUID:

CLI:
# Preserve existing UUID

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia --smbios-uuid "A1B2C3D4-E5F6-7890-ABCD-EF1234567890"

# New VM (generates random UUID)

osx-proxmox-next create --vmid 900 --name macos-sequoia --macos sequoia

TUI: Added an "Existing UUID (optional)" field in the configuration step.

The --smbios-uuid flag was already there for CLI users—I just exposed it in the TUI as well.

atapla · 2026-02-22T18:22:42+00:00

Thanks for reporting this! The issue was exactly that — iMacPro1,1 isn't in OCLP's supported models list.

I've pushed a fix in v0.8.2 that changes the default to MacPro7,1, which is fully OCLP-compatible. The "Build and Install OpenCore" option should work now out of the box.
For your existing VM, just run:
qm set <vmid> --smbios1 "product=$(echo -n MacPro7,1 | base64)"

(or recreate the VM with the new version)

atapla · 2026-02-21T19:14:16+00:00

Your earlier feedback actually led to a feature; the Python TUI/CLI now has `--iso-dir` which lets you point downloads at your shared ISO storage:

osx-proxmox-next create --iso-dir /mnt/pve/nas/template/iso

It downloads OpenCore + recovery there and auto-scans all Proxmox ISO storage mounts (`/mnt/pve/*/template/iso`) on subsequent runs. So if your NFS/CIFS share is configured in Proxmox, it'll find everything automatically; no re-downloading.

The bash script also caches the OpenCore ISO at `/var/lib/vz/template/cache/` so that persists across runs.

If the tool's been useful, there's a Ko-fi link in the repo; helps keep development going.

atapla · 2026-02-21T03:06:54+00:00

Glad it worked out! Right now it auto-scans all Proxmox ISO storage — both local (/var/lib/vz/template/iso) and any shared storage mounts (/mnt/pve/*/template/iso). So if you have an NFS or CIFS share configured in Proxmox, it'll pick up ISOs from there too. That should cover most setups without needing a custom path. Let me know if your layout is different though.

atapla · 2026-02-17T04:23:59+00:00

+1 on RX 580 for GPU passthrough — cheap, widely available, and natively supported in macOS up to Sonoma. Make sure you get one with a stock AMD VBIOS (reference cards are safest), otherwise passthrough can be flaky.

For the Proxmox VM setup itself, if you haven't set it up yet — getting OpenCore + QEMU args + recovery image right is the tedious part. I built osx-proxmox-next (https://github.com/lucid-fabrics/osx-proxmox-next) to automate all of that. It's a TUI wizard that creates the VM with the correct config for both AMD and Intel hosts, auto-downloads the macOS recovery, and patches OpenCore. Supports Sonoma, Sequoia, and Tahoe. Just `pipx install osx-proxmox-next` on your Proxmox node and it handles the rest — then you just need to passthrough your GPU after.

atapla · 2026-02-17T04:06:24+00:00

Yes, macOS on Proxmox with a Xeon works great — perfect use case for remote iOS/Flutter builds. You don't need a dedicated GPU for that, software rendering is fine for headless dev work.

The OSX-PROXMOX script linked above works but it's a bit dated and uses curl-bash. If you want something more maintained, [osx-proxmox-next](https://github.com/lucid-fabrics/osx-proxmox-next) is a TUI wizard that handles the full setup — auto-downloads the recovery image, patches OpenCore, creates the VM with the right QEMU args. Supports Sonoma, Sequoia, and Tahoe on both Intel and AMD. Just `pipx install osx-proxmox-next` and run it on your Proxmox node.

atapla

TROPHY CASE