Sincere thanks for your always thoughtful reply. Regarding the first issue, managing daemons, I admitted to cheating and ignorance. I hope you and other unix gurus help the guy asking the question. Regarding the timers issue, the "time.7" is just what shows on the tkman (nice manpage reader) header. But yes, that's a great starting point. And yes, you C whizkids make it look easy. And further, yes C++ is the way to proceed. Please look next at manual page "timer_create.2" . This is all new Posix compliance tools. There is an example provided. Apparently, the call even allows you to define several types of clocks and event reporting. I don't understand "threads" and "virtual" stuff, but I do understand a "process." Using freepascal 3.0.0 to access C library calls isn't hard. But the timer_create manpage also indicates a needed link to "-lrt" . The freepascal team has added a lot of Unix and Linux calls over the years, but not this one yet. I've done this before, and that's why I got old. Understanding the XForms-toolkit somewhat, I do think this approach is much better precision than the legacy timeout functions used in the toolkit. And the XForms maintainer rightly criticized my using a system Sleep call to get better accuracy, since it blocked XWindow events too. So I think this is a very versatile feature to play with drawing complex functions on a screen stripchart. When I get a decent set of software I'll try put it on a little web site. Even try put up a few binary programs so you don't have to work so hard to figure what I'm talking about. Thanks for trying. Iznogoud wrote: > To the original question, I think there is nothing better than editing files > by hand when it comes to configuring things. This is one of the powerful things > about the unix (and Linux). Convenience, like using GUIs, comes at a price, and > you are relying on somebody else's idea of convenience, robustness and more > importantly security. Never take my advise, but it is to learn to do everything > properly and from the command-line. Keep unix unix and thank me later. > > There are many books on the subject. Get one and start reading and keep it as > a reference. If you want a quick start within the next few minutes, here is > your freebie: http://tldp.org/LDP/sag/sag.pdf The kernel has received updates, > and several more daemons and other system related components have been added > to Linux, and many more so on the more bleeding edge distributions. So, expect > that you will have to stay up-to-date and that it is a moving target. (I do > remember the day that "shadow" passwords were added to prevent hashed ones from > being visible to common users.) > > > As for high-resolution timers, it is not like anything has really changed in > terms of using them and programming with them. The manual page Rick mentioned > is here: http://man7.org/linux/man-pages/man7/time.7.html > It states that the _first_ update to jiffes was done by increasing the timer's > resolution by a lot, and then shortly after was given several possible modes > of operation, with multimedia applications in mind. But the high resolution > timers were added later, and in my mind they are in support of more time > critical applications, like real-time systems that perform data acquisition > for experiments and other real-life equipment. > > There is nothing crazy about using HRTs in programming. How about something > like clock_gettime() and so on? Here is an extract from the man pages from my > system (slackware 14.1): > > #include <time.h> > > int clock_getres(clockid_t clk_id, struct timespec *res); > > int clock_gettime(clockid_t clk_id, struct timespec *tp); > > int clock_settime(clockid_t clk_id, const struct timespec *tp); > > Nothing more bare-bones thant <time.h> in my opinion... > > The gospel by Robert Love is what I use for a linux system programming > reference book: > Love, Robert, "Linux System Programming," 2nd, Ed., O'Reily, 2013. > > I love that book. > > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list >