binaryturtle

You could just use something like fd00:dead:beef::192:168:0:1 for your internal IPv4 host(s). Basically do a human-readable mapping of your IPv4 LAN IPs into a IPv6 private space. Now you only need to remember the ULA prefix and then can continue to use your IPv4 just with colons instead dots. Problem solved. :-)

Interestingly on a much older OS (Yosemite) cURL, etc. links to Security.framework which uses the system's trust store instead a separate .pem file in /etc/ssl (I can't find any .pem inside /etc/ssl)

I wonder why they stopped doing that and now just seem to do "standard" builds and end up with this (at least) 2 separate trust store situation.

Shouldn't it be easy to attach a sensor at the belly of the turtle that alarms staff when it happens. Sounds like an actual no-brainer use for modern technology.

Most of the stuff just seems/ feels to be (security) theatre. I actually disabled most of my OSCP, etc., for privacy reasons. No need to permanently send requests out to the web, when it won't help anyway when really required. I read HN to stay up-to-date and manually manage the certificates.

(Even with all the related options disabled, e.g., ocspd on OSX still regularly connects to random certificate related services to "check" on things. Something related to random root certificates I don't have in the system trust store or such, Not entirely sure what this is about and how to get rid of the requests in any other way than blocking things with Little Snitch)

I never heard of axel. Seems to be an interesting project. And it's coded in a properly supported language, so I can try it on my ageing OS X installation. :) Thanks for the tip.

Wouldn't it be even more ideal to have the webserver and app be one and the same binary, all bells and whistles included? No need for CGI at all. Just one static binary, no extra disk I/O needed to load resources (all compiled in statically). Basically you can make the OS deny this app any additional disk access for additional hardiness.

I like how the status reports are informative and rater detailed. I recently dealt with outages of my own German webhoster and they didn't even have a status page. I had to email their support to get some details (at least they replied very quickly :) )

Homebrew links everything by default (at least that's how it was), so you ended up with all kind of extra junk files all over the place you never needed that comes with some packages... all cluttering up things in the /usr/local main directories and the PATH.

Homebrew additionally also had bunch of other directories, a huge git checkout, etc. then add the weird permission restrictions/ limitations on top of it… many packages then stopped supporting the customisation options at some point, so you were forced to rebuild half of them yourself anyway, if you needed the respective options. Now you had even more mess in /usr/local. :-)

It may work for some, but it wasn't for me anymore (and I used Homebrew for many years before that.)

I don't think MacPorts users have those kind of problems.

Personally I was burnt by Homebrew many years ago already. I lost trust in any such package managers. Since then I went back to just compile everything myself (I manage about 300 packages like that in my installation.) It's not that a big of problem. Only initially when you need to bootstrap everything to replace Homebrew it was quite the time investment, of course. But now you compile like a package here or there… just follow the script. It's very quickly done.

The best thing… no clutter. Every package has its strict directory. I only symlink from that what I need into /usr/local/bin.

I don't see any advantage of any of the new formats over the good old and proven formats, so I stick with PNG and JPEG (properly optimized.) I can fire up any old browser and it will just work.

`man random` has no such disclaimer here on OS X. I guess this refers to a Linux man page?

For the fun of it: I asked Google Gemini and ChatGPT (OpenAI) "What is AWeb?" and they both gave me the amiga browser as answer. No idea if they just know, or did a similar lookup as I did? :)

They allow port scans?

I did use nmap on a Linux VM going over the free ProtonVPN for this purpose, but at some point Proton broke something (it may be related to their VPN accelerator feature) and checking any port always reports "Open" (even if it's not), so sadly that made this cool use case entirely useless for me. It definitely was nice to know you had no open ports other than the ones you purposefully opened. :)

Occasionally drag'n'drop failures —where it just stops working— I experienced already with Yosemite, so it may be a VERY old bug. :) Usually you would see "CoreDragError" codes popping up in the system.log

Rather than rebooting, I just kill "pboard" in Activity Monitor, and afterwards restart a few GUI programs that were directly affected (including Finder and Dock.)

My wild theory is that Firefox is the culprit. At least the issues happened more frequently once I had to switch to Firefox for proper content blocking extensions. Anyway… I have no idea how to prove that, so it's just a guess, not a blame.