Show HN: Marathono – A GUI tool for managing long-running processes in macOS
marathono.com
marathono.com
Launchd is solid and full-featured:
* Good process management (failure retries with backoff)
* Supports watching folders
* Decent command-line client for when you want to script or work fast in the shell
* Supports starting daemons on login
* Can start/stop based on whether certain things (network, paths, mounts, etc.) are up/down
* Supports calendar-based scheduling (replaces cron)
* Can redirect logging
* Can enforce resource limits (RAM, CPU, I/O, number of processes etc.) + nice level
I run all my daemons (Homebrew apps as well as personal development stuff) under Launchd, and I would love a convenient menu-bar GUI like this.
No, it's a train wreck of bad design, lack of backwards compatibility and sharp edges:
* Tracks PIDs only, so make sure that your process doesn't double fork (as many unix daemons do by default) or it'll lose track of them.
* No real documentation from Apple (man page is useless). The best resource is http://launchd.info.
* No feedback to commands: launchctl doesn't give any useful output about whether a command worked or not.
* Even something as simple as disabling a daemon may require manually editing one of the many `overrides.plist` XML files somewhere on the system.. though check your OS version because this changed between 10.9 and 10.10 without notice.
* ...I could go on.
Due to the chronic lack of documentation, many operations are totally trial and error. In fact, it is so bad that there's a market for a GUI tool (LaunchControl) which, to its credit, does manage to make launchd less painful than a trip to the dentist.
The only feature it adds that sysv didn't have is socket activation, and it doesn't do anything that xinetd didn't.
Makes it easy to set up your own launchd entries and manage existing ones, both user and system. I set up an rsync script to sync my photos with my NAS when I'm on my home wifi automatically.
I like it so much I bought it. There is no registration or serials or copy protection (IOW paying is optional) but after using it for a few weeks I felt like the asking price of $10 was more than justified for the utility I received from this utility.
I understand why some people may prefer a simpler tool.
2. I love lunchy [1] (now ported to Go [2]), it's a simple launchctl wrapper that you can install with brew cask.
Having Marathono popup function as a proxy for Homebrew-managed services would give me a single dashboard for my development daemons, including infrastructure and my own app codes.
Consider using Docker/Docker Compose for this. It then becomes as easy as defining the image name and version, pulling it, and then starting the container. No brew, no version conflicts, it just works.
In defence of the team, the Docker value prop on macOS is fundamentally undermined by the broken shared volumes. Folders that are shared with the hosts are still unusably slow for larger projects, so we can't use them (docker-sync makes it better, but adds another layer of complexity). Further, a lot of tooling and IDEs still expect local files and a local interpreter for step-debugging. So if the files are on the host, and so is node/php, then docker adds no dev value for app-level work. CI, yes, local dev - not so much. From there, it's a slippery slope - if I already have app stuff on the host, might as well install infrastructure stuff too because it doesn't really change so why should I deal with another virtualisation layer. It'll be an uphill battle until Docker volumes work at native speeds on mac out of the box.
Either charge me money so we have a legal bond, or open source it.
Free closed source is untrustworthy software that may just disappear/break with no respite.
If it's open source and you stop maintaining it, I can fix it myself or at least try to. It if isn't, I'm screwed. I won't become dependent on software I can't trust to work years from now - I don't need that in my life.
Or atleast, that is how I handle free software that I create. As long as I'm the only maintainer and can maintain it, I'll keep it closed source. However if I can't or don't want to maintain it anymore I'll opensource it.
Not saying this is the case here, but just trying to say free and closed source software isn't always bad. :)
Have you seen the absurd number of 'Go download the latest version of this dep from some 3rd party remote host' steps in the build processes of modern software (oss or not)? Or my favorite 'Just use this image we pushed to dockerhub as your startingpoint for building our software'.
I've had a fair number apps in recent years, particularly those sold in the App Store that had become vital parts of my workflow entirely stop working after OS upgrades, and the author no where to be found.
I feel a bit discouraged from trying it by the uncertainty about the eventual price. I guess they're going to start charging for it at some point and that's ok. But I'd like to know a broad range before I start depending on it.
I'm the developer of PSequel (a popular PostgreSQL client, http://www.psequel.com/) and it has been free since it came out two years ago. I got people asking for open sourcing it almost every single day. Many people assume free == open source.
And actually I'm curious, what would you say is your main reason for keeping the source code of your free tools private? (ugly code being a totally acceptable answer to which I can relate :))
Is anyone else using tmux (backgrounded) for this use case today?
I'm not arguing that tmux is without tradeoffs, but the tmux integration in iTerm is pretty good.
The major annoyance I was having is when a long-running process dies, I might waste a couple minutes trying to figure out what's going on, only to realize that a gulp build stopped or some service crashed. Even if it only wastes a couple minutes here and there, the time and frustration add up.
Thank you for taking the time to make this available to everyone!
Will definitely upgrade to your future paid version if you retain the simplicity and promise to respect privacy.
Cheers!
As for the logo, it's clever but too complex. It wouldn't bother me if it weren't prominent in the menu bar. Something more simple for the menubar icon could just be a ">" logo.
For reference on logos, compare with iTerm and Prompt: https://www.iterm2.com/ https://panic.com/prompt/
Prompt especially has a great logo IMO.
/joke
The only thing I don't really like is the icon. I find it a bit cluttered.
I'll gladly pay a few bucks to keep this in my toolbelt.
On OS X 10.11 using a dark theme causes the menulet to color the padding of the UI elements which makes it difficult to see the entries in the list.
[1]: Microsoft Windows Services console.
If I'm not mistaken, the infamous systemd was influenced by launchd.
>Marathono is a small GUI tool that helps you manage long-running processes in macOS, so you don't have to maintain multiple windows/tabs/tmux sessions in your Terminal.
How about one tmux session and a couple of windows? You could name the windows perhaps. I could see how this might not scale, but I bet my socks someone else has found a way to script this and make it easy.
I know we don't want to be overly negative on HN, but this doesn't sound like a problem that needed a completely newly rolled solution.
So you have GUI output. What if I want to grep or save it to a file? I can see how this will be usable for people who aren't comfortable with a terminal--as a someone who transplated linux-to-mac, I know how terrible the terminal experience is on mac.
EDIT: below I was corrected that Marathono does all manipulating text output, +1.
Also, I have to disagree with the terminal experience on the mac being terrible. Between iTerm and brew, I've never come across anything I couldn't do, but that could be done on linux.
I mean, you are of course free to do what ever you want to do and have which ever workflow you feel comfortable with.
There might be cases where I would find it useful but overall its usefulness is subjective and dependent on what you're looking for in your workflow/workspace.
Which seems like it would be a Big Deal, for a Mac user. The entire appeal of the Mac (for a developer) is that it layers a friendly GUI over a Unix-ey foundation. Presumably a user who values that GUI would also value GUI-oriented ways to do things that were previously terminal-only.
If "just use screen" was an answer that would make that user happy, they wouldn't have spent the extra money to buy a Mac in the first place.
I wouldn't mind if this used launchd under the hood though.