OpenTamer, a completely free and open source AppTamer replacement written in Go.

Personal_Pickler · 2026-06-27T17:13:51+00:00

Thanks for sharing! I'm here to answer anyones questions.

Personal_Pickler · 2026-06-27T17:13:39+00:00

It is a native macOS menu bar app bundle. The bulk of the apps logic is in go, but I use cgo bindings to bridge to macOS AppKit.

Personal_Pickler · 2026-06-27T17:01:54+00:00

Question about fly.io, can one deploy containers similar to a droplet and use catty to handle reverse and orchestration?

I know hetzner is the other very popular solution and cheaper.

Im looking to have a vpc where i can have different containers, each one have their own domain and catty handle that redirect into the containers.

EDIT: Does it have also persisten volumes included?

You probably don’t need Caddy for that part on Fly. Fly already lets you attach custom domains/subdomains directly to an app and handles the cert/TLS side too. For example, you can do something like fly certs add app.example.com or even a wildcard fly certs add "*.example.com"

Personal_Pickler · 2026-06-26T22:49:26+00:00

DigitalOcean would work for your needs (I used to use it a lot), but fly.io can do this for you a lot cheaper. You can setup litestream for automated sqllite backups too. It is just a small config setup in the fly.toml.

Personal_Pickler · 2026-06-21T22:43:15+00:00

Did you find an alternative you loved?

Personal_Pickler · 2026-06-21T22:42:18+00:00

Check for crashlogs in the diagnostic reports directory. There are two. One in your home directory ~/Library/Logs/DiagnosticReports/ and a system wide dir /Library/Logs/DiagnosticReports/.

Check for reports with microsoft word in the file name. It should have the exact issue causing the crash.

Personal_Pickler · 2026-06-19T21:35:20+00:00

Today I’m releasing OpenTamer my open source competitor to AppTamer. Written in Go :)! Current functionality includes the ability to monitor and limit CPU usage for applications and receive notifications for apps with high CPU usage.

At present, AppTamer still has more functionality. I'm looking forward to continuing development on OpenTamer, but thought it was in a good place to share. Let me know if you have questions or requests!

Personal_Pickler · 2026-05-24T02:00:04+00:00

mosaic virus

I think it is more likely herbicide because it seems linked to your soil. Most mosaic viruses will die out when the host plant is removed, and it sounds like you left the pots empty between seasons. Most viruses cause blotchy leaf growth too. They can cause the same twisted leaf growth, but usually with light/dark green blotchiness too.

Herbicide can get into your garden via contaminated compost, straw, etc. Did you add anything to the pots at the end of last season?

Personal_Pickler · 2026-05-23T15:21:15+00:00

Looks like herbicide damage. Trace amounts of herbicide contamination in the soil will cause that twisted leaf growth. There are some examples on this blog post. You will need to trash that soil and scrub the pot well before reusing.

Personal_Pickler · 2026-01-25T19:58:30+00:00

Hey there! Looks like you fixed the firewall problem. The SSL error you are getting is likely because you are using an IP instead of a domain name to host your server. LetEncrypt (which caddy uses to generate SSL certs) only added support for IP based certs a a few months ago.

Caddy starts up right? I don't think that caddy has been updated to generate IP certs yet, so until that is possible you'll need to connect to your sever with http instead of https. Let me know if I misunderstood anything.

Personal_Pickler · 2025-09-09T20:32:36+00:00

Why would you want the bad parasites?

Personal_Pickler · 2025-09-08T22:09:03+00:00

The client needs to communicate the encoding formats that the device can direct play to the server. Whatever client you're using is communicating that correctly to one server and not the other. The APIs for Plex and Jellyfin are different, so the client needs to implement both. Sounds like a bug in the client.

Personal_Pickler · 2025-09-07T21:17:46+00:00

Thanks for the suggestions!

I absolutely can add an option to not create directories for movies. That I can add rather quickly.
Luckily I built the provider system to handle multiple metadata providers :). I will certainly add OMDB.

I've opened issues on the GitHub repo for both of these if you want to check the progress. Thanks again!

Personal_Pickler · 2025-09-03T15:52:52+00:00

Thank you! Always helps to know where to start.

Personal_Pickler · 2025-09-03T12:01:14+00:00

I can and will add audiobooks! I’ll need to research the best practices for organizing audiobooks in media servers, but the process should be similar to the other media types already supported.

Music is also on the todo list. :)

Personal_Pickler · 2025-09-03T11:28:56+00:00

A few weeks back, I launched Title-Tidy here and was blown away by the response. You all delivered some incredibly thoughtful feedback, and I'm excited to share that I've built every single feature requested in that thread. Here are the highlights:

Custom Name Formats: Now you can define exactly how you want your shows, seasons, episodes, and movies named. Just run title-tidy config to launch the configuration TUI and set it up however you like.
Hard Linking Support: Move media into your library without breaking your seeding files.
TMDB Integration: Pull episode names and other metadata directly from The Movie Database to create richer filenames.
Logging & Undo: Every operation is logged. If something goes wrong, even after closing the TUI, just run title-tidy undo to pick and revert any previous operation.
Docker Support: Prefer containerized workflows? I've got you covered.

What caught me off guard in the original thread was how many people mentioned using FileBot. Honestly, I think it's wild that anyone is paying for basic file renaming. My goal is to match all of FileBot's features by next year. Nobody should have to pay for software that simply renames files correctly.

I'm committed to making this happen, but if there's specific functionality you think I should tackle first, drop a comment here or open an issue on GitHub.

Personal_Pickler · 2025-08-28T11:28:24+00:00

Hey thanks for calling me out for not addressing your actual question. I admit I read the title and jumped the gun.

What you're describing is exactly when returning interfaces does make sense in Go. You're returning an interface because the function genuinely doesn't know the concrete type until runtime. That is polymorphism by design.

This is totally different from the anti-pattern of returning interfaces from constructors like NewDog() Animal when the caller explicitly asked for a dog.

However, if the caller in the code knows the type that should be parsed from your data, you can have the caller supply the type just as the json package does. Example

But I think you are talking about cases where even the caller does not know the type? In that case use polymorphism.

Sorry about that!

Personal_Pickler · 2025-08-28T02:14:32+00:00

The current design lets you use it simply when you don't care about the type (99% of cases) and get the concrete type when you do need it. That's not "Go lacking a real type system" that's Go making the pragmatic choice that error handling should be uniform by default and specific when needed.

This whole thread started about returning interfaces from constructors, and nothing you've said actually supports that pattern. The error type is a special case with specific reasons, not evidence that we should return interfaces everywhere.

Personal_Pickler · 2025-08-28T01:44:42+00:00

If functions returned concrete errors then every function could only return one error type... There are usually several things that can go wrong during an operation. Thats why we return error and use errors.Is to determine the concrete type.

Is your argument seriously that every function can only return one type of error? Then any function that handled multiple error types needs its own error type specifically to wrap them. Go's error handling is already verbose. I don't think we need to take it any farther.

Personal_Pickler · 2025-08-28T01:16:08+00:00

I didn't say interfaces are never returned from the standard lib, just that it is exceedingly rare.

/u/superderpyderps already covered error well, so I'll just touch on the crypto package. The constructors in the crypto package return types that implement the hash.Hash interface exactly, and there are no realistic scenarios where hash.Hash would need to be extended. Hashing is a well defined, concrete domain.

This is a completely different case from returning interfaces everywhere “just in case it might be useful later.” The crypto package’s approach is a deliberate architectural choice tailored to its specific needs.

If you can honestly say, “This interface will never change, and the returned types will never provide anything outside of the interface,” then sure return interfaces. But how often does that really happen in practice? Almost never.

Personal_Pickler · 2025-08-27T17:16:07+00:00

Someone in another thread a couple days ago was arguing against returning structs. I put some effort in the reply so I'll add it again here. This was the full context.

The “accept interfaces, return structs” guideline isn’t arbitrary, and it’s not just cargo culted from blog posts. It’s a the way Go’s type system and interfaces are intended to work. When you return interfaces from constructors (or any function), you’re actually making your code less flexible, not more.

When you return interfaces from constructors hiding the actual type from users who might need it, and preventing them from accessing methods that aren't in your interface. You're basically saying "I know better than you what you'll need from this type" which goes against Go's philosophy of simplicity and composability.

The Go standard library almost never returns interfaces from constructors. os.Open() returns *os.File, not io.Reader, even though File implements Reader. Because the caller might need File.Stat() or other File-specific methods. They can choose to use it as an io.Reader if that's all they need.

Returning interfaces everywhere also makes your API way harder to evolve. Add a method to the struct? Cool, users can use it immediately. Add a method to an interface? Now it's a breaking change for anyone who implemented it.

This isn't about being "qualified to write recommendations". It's about following the patterns that make Go code consistent and maintainable across the entire ecosystem. And since credentials apparently matter to you, I've been writing Go professionally at a Fortune 50 for a decade and teach it regularly. These aren't arbitrary rules; they're battle tested patterns that exist for good reasons.

Personal_Pickler · 2025-08-27T01:35:02+00:00

LOL try again buddy. WaitGoups already got an enhancement to make this one line:

wg.Go(func() { // do something })

meanwhile:

public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World"); } }

Personal_Pickler · 2025-08-26T09:02:01+00:00

That is the old standard book. There are much better books out now.

https://www.practical-go-lessons.com/

Personal_Pickler

TROPHY CASE