Crumb
c/selfhosted · by runwisp_com@lemmy.world · 16d

[AIP] I've been working on the perfect UI for cron and supervisor for several months now. Tell me what you think.

I created a tool that's easy to set up and gives you fast and beautiful web UI and TUI from a single Go binary.

It can serve both as a cron replacement, or just as a cron supplement - let's say, to version control your cron tasks in a small team. It also has an alert system that allows you to send slack/discord/telegram/email when something bad happens.

I want your feedback. You can help me shape this product into something people will find pleasant to use.

This daemon is copyleft GPL-3.0-or-later - completely free to use.

RunWisp is currently in pre-release phase but is slowly approaching its v1.0 stable release.

Website: https://runwisp.com/

GitHub repo: https://github.com/runwisp/runwisp - feel free to open an issue!

Quick start: https://docs.runwisp.com/getting-started/quick-start/

AI Disclosure

  • Design - Hint
  • Implementation - Pair
  • Testing - Assisted
  • Documentation - Pair
  • Review - Hint
-5 points · 33 comments · view on lemmy.world

33 Comments

possiblylinux127@lemmy.zip · 10 pts · 16d (1 reply)

You really should disclose this as AI slop

WhyJiffie@sh.itjust.works · 3 pts · 16d

it seems it has already been

AllNewTypeFace@leminal.space · 9 pts · 16d (8 replies)

Is this vibe-coded?

lime@feddit.nu · 64 pts · 16d (3 replies)

AGENTS.md, CLAUDE.md, copilot as contributor, an insanely long readme full of tables and emoji for a project that is just a couple of months old, solving a problem nobody who can read a man page has, posted by an account named after the project, with explicit disclosures in the post.

idk it's unclear

possiblylinux127@lemmy.zip · 5 pts · 16d

It'll be abandoned in 6 months

runwisp_com@lemmy.world · 1 pts · 16d (1 reply)

Copilot was listed as a contributor on an early commit because I used it to help draft that commit. that attribution overstates its role in the overall project. The disclosure in the post is the more accurate summary of how AI was used.

Andres4NY@social.ridetrans.it · 2 pts · 16d

@runwisp_com @lime Psst... it's not a "him", it's a piece of software. 😏

k_rol@lemmy.ca · 11 pts · 16d (1 reply)

I don't think so. He has been a developer for at least a decade. I did not find code smell or bad habits. He does cover his code with plenty of tests. Sonarcloud shows very little issues with the code. That is with all original measures and rules in place.

The dev seems to do all the right things including disclaiming the use of AI.

runwisp_com@lemmy.world · 3 pts · 16d

Thank you for the kind words.

curbstickle@anarchist.nexus · 9 pts · 16d

Vibe coding would mean writing no lines of code, just words to an LLM. In the disculosure here, that would be generated.

They have Pair in the disclosure, which is about a 50/50 split in code.

@runwisp_com@lemmy.world you have some formatting issues in the disosure, its all on the same line.

runwisp_com@lemmy.world · 4 pts · 16d

no. I am an experienced engineer that has been writing code for more than 10 years, way before AI. While AI definitely has been used to write code, the code architecture is actively designed and reviewed by me, a human.

helix@feddit.org · 7 pts · 16d (15 replies)

Looks good, but kind of superfluous if you just use systemd timers, lol

Systemd timers are the modern way of doing it which gives you everything you coded this tool for, logs and whatnot, in the journal.

And you can run them in a web UI like cockpit aswell.

This might be interesting in a business setting but lacks ACLs and user management in general.

It's probably also quite easy to hack the system with it if you can inject some malicious scripts.

kittenz@lemmy.blahaj.zone · 2 pts · 16d (1 reply)

Or just cron that calls a logger works well enough

runwisp_com@lemmy.world · -1 pts · 16d

if cron + logger covers your needs, you should keep that going. RunWisp is for cases where you also want searchable run history with retention and rotation, failure alerts, manual triggering and service supervision, all in one place without assembling those pieces yourself.

WhyJiffie@sh.itjust.works · 2 pts · 16d (5 replies)

I generally like some things that syatemd gives, but is there an easier way to create timed automations with systemd timers?

with cron, its just a single line with the recurrence pattern and the command. with systemd, you have to create a timer unit file with several lines, a service unit file with several lines, put them in the right directory, reload systemd, enable the timer. timers are not difficult, but much more convoluted than the crontab. if you have to make multiple pairs, or update something in them, it gets old fast.

helix@feddit.org · 3 pts · 16d (4 replies)

single line

here's a single line for you which creates a one-shot service+timer in one go, suspending the system in 4 hours:

systemd-run --on-active=4h --unit=suspend-after-4h /usr/bin/systemctl suspend

If you want it to run repeatedly, simply replace --on-active with --on-calendar="*-*-* 04:00:00" for example.

WhyJiffie@sh.itjust.works · 3 pts · 15d (3 replies)

thank you. this creates it, but is there a way to view or edit its current configuration in a similar format? and this is not persisted, is it?

helix@feddit.org · 1 pts · 15d (2 replies)

If you inspect the generated timer you see the same format in the OnCalendar line.

What do you mean by persisted? The service and timer will both be there as long as the timer doesn't end. Which it won't in my example.

If you want to copy it for later reference, you can simply copy the files.

WhyJiffie@sh.itjust.works · 1 pts · 14d (1 reply)

If you inspect the generated timer you see the same format in the OnCalendar line.

but without the command

What do you mean by persisted? The service and timer will both be there as long as the timer doesn't end. Which it won't in my example.

I mean saved to a file so that it will still be there after reboot

helix@feddit.org · 1 pts · 14d

but without the command

Yeah, but that's an easy one to parse, if you really need it.

I'm pretty sure if you use OnCalendar it will still be there after a reboot. Let me check.

EDIT: oh damn!! It doesn't persist on reboots. Sorry for this oversight.

runwisp_com@lemmy.world · 1 pts · 16d (6 replies)

If systemd timers, journald and cockpit already cover your needs, RunWisp probably isnt for you. RunWisp is aimed at people who want portable TOML-defined tasks and services with unified history, logs and alerts. you’re right that ACLs are currently missing, but access is protected by password authentication and the UI can only trigger commands already defined on the host.

helix@feddit.org · 3 pts · 16d (5 replies)

Yes but... Systemd timers are INI-defined tasks and services with unified history and logs, the alerts can be easily added with any alerting system.

runwisp_com@lemmy.world · 2 pts · 16d (4 replies)

yeah, thats fair, systemd + cockpit with alerts can cover pretty much the same ground. What RunWisp brings is the integrated cross-platform package and UX. Nobody is claiming that those underlying capabilities are impossible to assemble elsewhere.

helix@feddit.org · 2 pts · 16d (3 replies)

But why does it need a cross platform package when systemd is available everywhere? What UX is better than the already existing cockpit?

WhyJiffie@sh.itjust.works · 0 pts · 16d (2 replies)

is systemd available for windows and mac?

awelo@tuiter.rocks · 1 pts · 16d
[ removed ]
helix@feddit.org · 1 pts · 16d

windows, yes: https://learn.microsoft.com/windows/wsl/systemd

for Mac you should probably use macOS's launchd services: https://www.launchd.info/

panda_abyss@lemmy.ca · 7 pts · 16d (4 replies)

I hope this doesn’t come off as too harsh, but the text reads as very AI generated, and I think if you rewrote the main text you could do a much better job.

It’s not clear to me why to use it, the pitch today is that it makes failures loud, which is nice, but very poorly described.

The tool itself looks good, but the website looks very “Claude”, especially the text at the top saying “ONE BINARY · LINUX · MACOS · WSL · 25 MB RAM IDLE”

Those are great pros, but are they the guest thing the user should see?

Honestly the first paragraph of the quick start is a much better pitch:

RunWisp is one small Go binary. You list the shell commands you want to run in a runwisp.toml, and RunWisp takes care of the rest — firing jobs on cron, restarting services when they crash, and capturing every line of stdout and stderr so you can go back and look at what happened. There’s a TUI in your terminal and a Web UI in your browser for poking around. No external database, no agent, no sidecar

This tool looks decent, but for me I find nix helps manage the complexity of systemd well

runwisp_com@lemmy.world · -3 pts · 16d (3 replies)

actually not harsh

this is exactly the kind of concrete feedback I was hoping for. You're right that the quick-start paragraph explains the actual value better than the current pitch.. Thank you for taking the time to look at this.

possiblylinux127@lemmy.zip · 17 pts · 16d (1 reply)

Why did you use Claude to write this comment

cenariodantesco@lemmy.world · 4 pts · 15d

😆

panda_abyss@lemmy.ca · 12 pts · 16d

No problem.

The other thing with AI stuff is it conveys very little trust. It’s easy-come easy-go, so it’s hard to tell how much maintenance the owner will has put in or will put into the project.

Scheduling is high risk, so it’s important that it feels safe

hperrin@lemmy.ca · 2 pts · 16d (1 reply)

How much of this is written by AI?

curbstickle@anarchist.nexus · 5 pts · 16d

See disclosure at the bottom - Implementation lists pair.

Thats 50/50 per our rules here.