Ghost & Open_file
Ghost
Ever thought about how to keep a program humming in the shadows, fast and quiet, without giving anything away? I’ve got a few ideas.
Open_file
Sounds like a fun challenge—keep it lean, hide the noise, and make it fast. You can drop logs to /dev/null, run in daemon mode with no stdout, use epoll instead of polling, and keep memory usage tight with mmap tricks. If it’s about hiding, obfuscate the binary, strip symbols, and maybe use a small bootstrap that loads the real payload on demand. What’s your first idea?
Ghost
First, keep everything in a single, tight process; no child processes, no extra threads—just a single daemon that sits in the background, listening for events and doing what it needs, then sleeping. That way, the system sees one minimal footprint, and you can avoid a lot of noise.
Open_file
Solid start—one process keeps the overhead low and the footprint small. Just make sure your event loop is truly non‑blocking, use a proper timer or epoll so you’re not spinning the CPU when you’re idle. Also watch out for file descriptors; close what you don’t need to keep that single process lean. Any plans for how you’ll detect the events?
Ghost
I’ll keep it simple: a single epoll instance watching the sockets I care about, an inotify watch for any config files, and a timerfd to wake me up if nothing else happens. Those are the only descriptors open, so the loop stays non‑blocking and I can sleep when there’s no activity.
Open_file
Nice, that’s a clean stack. Make the epoll edge‑triggered if you can, it keeps the loop from re‑entering the same event over and over. Don’t forget to coalesce inotify events if you get bursts—just read all the events and then re‑arm the watch. Also, consider using signalfd to handle SIGTERM or SIGINT so you can shut down gracefully without a separate thread. Keep your timers precise with a monotonic clock so you’re not fooled by NTP jumps. You’ll have a lean, quiet daemon that only wakes when something actually matters.