kernalix7
Show HN: AIPS – A Claude Code plugin to stop re-doing AI setup every project
Show HN: One Markdown File to Set Up Claude, Codex, Cursor and Copilot
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Tuesday May 12, 2026 @08:14PM (#48116287)
Now it supports reverse-open
Show HN: Rdprrap – Rust Port of RDPWrap (Multi-Session RDP for Windows Desktop)
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Sunday May 03, 2026 @10:33AM (#47997334)
maybe it runs, but gpu hardware accel doesn't support now.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @03:37AM (#47972172)
yeah from user side it feels like that. but technically its more like extremely user-friendly way of using VMs.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @03:36AM (#47972165)
For now single container runs all softwares. tradeoff with dockur/windows limits, saves ram and disk. planning multi container later for better isolation.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @02:45AM (#47971885)
Just at the planning stage, needs careful consideration first.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:56AM (#47971429)
yeah.. I also agreed with that. so I'll optimize the code continuously and lower the dependency on python. but for now I'll keep it because of some benefits.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:32AM (#47971322)
Thanks for your opinion, i ll try my best!
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:30AM (#47971310)
God it, i ll follow the guidelines, Thanks for the pointer. Apologies..
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:23AM (#47971268)
That's my mistake. I just focused on the functionally working, so I missed that point.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:20AM (#47971257)
The Korean intent is mine, but I run it through an LLM to phrase in English. That's where the pattern comes from. Will skip the LLM step from here.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Friday May 01, 2026 @12:15AM (#47971229)
Fair, English isn't my first language and I've been leaning on tooling. I'll dial it back.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Thursday April 30, 2026 @11:47PM (#47971100)
Fair point. Working on it now — will push a screenshot and short clip soon.
Re:Show HN: Winpodx – run Windows apps on Linux as native windows
on Thursday April 30, 2026 @11:40PM (#47971073)
Right, I had WinApps pinned to dockur in that comparison and missed the IP-based flexibility part. That's an actual difference, will fix the README.
On Python: fair pushback. Picked it for stdlib coverage (zero runtime deps on 3.11+, one tomli fallback for 3.9/3.10) and iteration speed. Heavy lifting is in the container and FreeRDP so perf hasn't been the bottleneck, but yeah the language choice is a tradeoff.
Reverse file association is interesting, hadn't thought about that direction. The v0.3.0 agent could probably handle it but I'd want to look at the security model first. Marking it TBD. If you open an issue with the use case that'd help me scope it.
Show HN: Winpodx – run Windows apps on Linux as native windows
Re:Noctua releases official 3D CAD models for its cooling fans
on Thursday April 30, 2026 @02:02AM (#47958733)
Good to know, didn't realize Mikrotik did this too. Useful for homelab planning where rack space and airflow actually matter.
Re:Noctua releases official 3D CAD models for its cooling fans
on Thursday April 30, 2026 @01:55AM (#47958678)
The fan body itself follows standard 120/140mm dimensions, but I needed the smaller details for my design, the rubber dampers, anti-vibration corners, cable routing clips. Those don't show up cleanly in the datasheet, so I ended up using a caliper. That's the part the official CAD would have helped most with.
Re:Noctua releases official 3D CAD models for its cooling fans
on Thursday April 30, 2026 @01:31AM (#47958537)
Would have saved me time on a 3D printer I designed a while back. I integrated Noctua fans and ended up measuring mounting dimensions by hand. Having the official CAD models would have made fan integration a lot cleaner.
Re:Have You Seen the New Excel?
on Thursday April 30, 2026 @12:42AM (#47958191)
The Excel flip lands. AI is a tool. People could adapt and use it, instead a lot of the panic sounds like resistance dressed up as analysis.
Re:HardenedBSD Is Now Officially on Radicle
on Thursday April 30, 2026 @12:34AM (#47958148)
Codeberg / Forgejo are also out there as less radical alternatives, so the choice space isn't binary. But the discoverability gap is real, and so is the loss of all the surrounding infrastructure people don't always think about. CI runners, release hosting, container registry, security advisories. You can replace each of those individually, but doing it all at once is a significant maintenance burden for projects with limited maintainer time.
Re:Mike: open-source legal AI
on Thursday April 30, 2026 @12:27AM (#47958104)
Self-hostable legal AI as open source is a useful direction in principle. Hard to tell how mature the actual implementation is though, the repo is pretty fresh and the marketing site is doing a lot of heavy lifting compared to what's in the code right now. Will be more interesting to revisit in a few weeks.
Re:GitHub Copilot is moving to usage-based billing
on Monday April 27, 2026 @08:28PM (#47929004)
Annual Pro+ subscriber here, mostly using it as a fallback when my Claude Max plan hits limits. The request-based pricing was genuinely the appeal, I could spill over from Max into Copilot without thinking about token costs. Going from 3x to 27x on Opus on annual plans is rough. The newer reasoning models with variable thinking budgets probably made per-request pricing untenable in the long run, but the way this lands on existing annual subscribers feels harsh. Going to look into the prorated refund.
Re:FreeBSD Device Drivers Book
on Monday April 27, 2026 @08:10PM (#47928906)
Hadn't actually heard of either, thanks for the pointers. Will start with the Handbook.
Re:FreeBSD Device Drivers Book
on Monday April 27, 2026 @08:09PM (#47928897)
That's a really compelling workflow. On the Linux side I've heard of openSUSE's MicroOS doing something conceptually similar with BTRFS snapshots and atomic transactional updates, though I haven't actually run it. Different mechanism but it sounds like the same instinct. Never let the running system get into an inconsistent state during an upgrade. The "boot just once" plus jail-the-clone-to-upgrade combo you described sounds genuinely clever, hadn't realised the bectl integration was that smooth. Void Linux is just a name to me at this point, might be time to actually look it up.
Re:FreeBSD Device Drivers Book
on Monday April 27, 2026 @03:01AM (#47918546)
My exposure to FreeBSD has been mostly through routers and firewalls, plus reading about jails and finding the concept genuinely impressive. Always wanted to dig deeper but the existing material assumes you already know the things I was hoping to learn. A book that explicitly starts before that wall sounds like exactly what's been missing. Going to give it a real shot.
Re:A.I. is creating engineers who can't think without it
on Monday April 27, 2026 @02:56AM (#47918506)
Caught myself in this one. The dependency creeps in faster than I'd noticed and the laziness becomes the justification. Reviewing what comes out of the machine is the part I keep skipping. Useful read, thanks.