Hi All,
Anyone know of a kitchen timer that has an rpm in the repo?
Many thanks, -T
On Wed, 8 Feb 2023 00:45:20 -0800 ToddAndMargo via users users@lists.fedoraproject.org wrote:
Anyone know of a kitchen timer that has an rpm in the repo?
I'm not sure what a kitchen timer requires, but there is an application called gnome-clocks that can time things. I'm not sure if you need gnome installed to use it, it might.
If you just need a quick timer for a set time, you can use sleep 1h && date && xterm -bg red -fg yellow -g 80x40 This will sleep for the period set, and at the end of the time open a red xterm in the current window in focus.
On 2/8/23 00:45, ToddAndMargo via users wrote:
Anyone know of a kitchen timer that has an rpm in the repo?
There's "kteatime" or if you're using Gnome, there is https://extensions.gnome.org/extension/5115/simple-timer/ (not an RPM)
On Wed, Feb 8, 2023 at 3:45 AM ToddAndMargo via users users@lists.fedoraproject.org wrote:
Anyone know of a kitchen timer that has an rpm in the repo?
Fedora 37 offers some timer programs. See below.
If you are willing to go to the source, then GitHub has several projects: https://duckduckgo.com/?q=kitchen+timer+site:github.com
Jeff
-----
$ dnf search timer Last metadata expiration check: 0:00:44 ago on Wed 08 Feb 2023 05:16:05 PM EST. ======================== Name & Summary Matched: timer ========================= boost-timer.i686 : Run-time component of boost timer library boost-timer.x86_64 : Run-time component of boost timer library ghc-timerep.x86_64 : Haskell timerep library ghc-timerep-devel.x86_64 : Haskell timerep library development files ghc-timerep-doc.noarch : Haskell timerep library documentation ghc-timerep-prof.x86_64 : Haskell timerep profiling library gnome-break-timer.x86_64 : Break timer application for GNOME perl-Template-Timer.noarch : Template::Timer Perl module perl-Test-Timer-tests.noarch : Tests for perl-Test-Timer python3-nose-timer.noarch : A timer plugin for nosetests rubygem-timers.noarch : Pure Ruby one-shot and periodic timers rubygem-timers-doc.noarch : Documentation for rubygem-timers rust-micro-timer+default-devel.noarch : Dumb tiny logging timer rust-micro-timer-devel.noarch : Dumb tiny logging timer rust-micro-timer-macros+default-devel.noarch : Macros for the micro-timer crate rust-micro-timer-macros-devel.noarch : Macros for the micro-timer crate rust-timer+default-devel.noarch : Simple timer to schedule execution of closures rust-timer-devel.noarch : Simple timer to schedule execution of closures rust-timerfd+default-devel.noarch : Rust interface to the Linux kernel's timerfd : API rust-timerfd-devel.noarch : Rust interface to the Linux kernel's timerfd API rust-tokio-timer+default-devel.noarch : Timer facilities for Tokio rust-tokio-timer-devel.noarch : Timer facilities for Tokio xfce4-timer-plugin.x86_64 : Timer for the Xfce panel ============================= Name Matched: timer ============================== ktimer.x86_64 : Task Scheduler perl-Devel-Timer.noarch : Track and report execution time for parts of code perl-Test-Timer.noarch : Test module to test/assert response times php-phpunit-PHP-Timer.noarch : PHP Utility class for timing php-phpunit-php-timer2.noarch : PHP Utility class for timing php-phpunit-php-timer3.noarch : PHP Utility class for timing php-phpunit-php-timer5.noarch : PHP Utility class for timing, version 5 php-react-promise-timer.noarch : Trivial timeout implementation for Promises rust-brotli+disable-timer-devel.noarch : Brotli compressor and decompressor with : no_std support rust-brotli-decompressor+disable-timer-devel.noarch : Brotli decompressor with : no_std support rust-futures-timer+default-devel.noarch : Timeouts for futures rust-futures-timer-devel.noarch : Timeouts for futures rust-tokio-compat+tokio-timer-02-devel.noarch : Compatibility between tokio 0.2 : and legacy versions rust-tokio0.1+timer-devel.noarch : Platform for writing asynchronous I/O backed : applications rust-tokio0.1+tokio-timer-devel.noarch : Platform for writing asynchronous I/O : backed applications ============================ Summary Matched: timer ============================ dieharder.i686 : Random number generator tester and timer dieharder.x86_64 : Random number generator tester and timer erlang-chronos.noarch : Timer utility for Erlang tests erlang-cosTime.x86_64 : Orber OMG Timer and TimerEvent Service ghc-time-manager.x86_64 : Scalable timer golang-github-cloudflare-backoff-devel.noarch : Backoff timer shared between : several projects idle3-tools.x86_64 : Manipulate the value of the idle3 timer found on recent WD : Hard Disk Drives kteatime.x86_64 : Handy timer for steeping tea perl-Test-Mock-Time.noarch : Deterministic time & timers for event loop tests perl-Time-HiRes.x86_64 : High resolution alarm, sleep, gettimeofday, interval : timers rubygem-hitimes.noarch : A fast, high resolution timer library for recording : performance metrics rust-async-io+default-devel.noarch : Async I/O and timers rust-async-io-devel.noarch : Async I/O and timers
On 2/8/23 00:45, ToddAndMargo via users wrote:
Hi All,
Anyone know of a kitchen timer that has an rpm in the repo?
Many thanks, -T
I gave up and bought a $15 wind up timer. At least I can hear it. Well hear it rattle for 4 seconds. It may have a bell sound, but I can't hear it.
ToddAndMargo:
I gave up and bought a $15 wind up timer. At least I can hear it. Well hear it rattle for 4 seconds. It may have a bell sound, but I can't hear it.
Sometimes the old-fashioned ways are best. We got something like 25 years out of a wind-up timer before the bell fell off the back.
I just use the one in my phone, since it's nearly always nearby, I'll hear it go off (unlike the wind-up timer on the stove, which I probably won't hear at the other end of the house). I wish mine only did go off for a few seconds and quit.
Others have suggested things like gnome-clock (the desktop toolbar gadget, I believe), and the equivalent for other desktop systems.
I notice that Mate has a timer app that can be put on the toolbar, it pops up a dialogue when done, but is silent.
On 2/16/23 19:39, Tim via users wrote:
Sometimes the old-fashioned ways are best. We got something like 25 years out of a wind-up timer before the bell fell off the back.
It is the better part of wisdom to realize when computers are not the proper tool for the job.
I hope this catches up to the cloud soon. Somethings are great on the cloud; others are better on the edge. And I am seeing a lot of the "are not" going to the cloud anyway.
On Fri, 2023-02-17 at 16:51 -0800, ToddAndMargo via users wrote:
It is the better part of wisdom to realize when computers are not the proper tool for the job.
I hope this catches up to the cloud soon. Somethings are great on the cloud; others are better on the edge. And I am seeing a lot of the "are not" going to the cloud anyway.
Years ago, my former webhost decided they'd shift their serving over the cloud (a cost-cutting/profit-increasing exercise). After a week they went back to their previous system. It was slow, dead slow, had serious bugs, and their cloud service provider gave no evidence that they could resolve any of them. In essence, they lost control of their service, outsourcing the entire thing to substandard people. If they were hoping to just rake-in money without actually doing anything, themselves, that pipe-dream evaporated real quick.
Going further back to my programming days, the notion of putting things inside sub-routines, inside sub-routines, calling further sub-routines, was incredibly sub-optimal. It was tedious, error prone, and noticeably slower. There's a point where it's far more optimal to do a most things directly.
I never got into modern GUI system programming. The notion of having to frankenstein your program from a plethora of other people's libraries, with unknown problems, unfixable problems, inadequate information, and an ever-changing landscape of libraries and OS was more than I was willing to get involved in.
On Sat, Feb 18, 2023 at 4:09 AM Tim via users users@lists.fedoraproject.org wrote:
On Fri, 2023-02-17 at 16:51 -0800, ToddAndMargo via users wrote:
It is the better part of wisdom to realize when computers are not the proper tool for the job.
I hope this catches up to the cloud soon. Somethings are great on the cloud; others are better on the edge. And I am seeing a lot of the "are not" going to the cloud anyway.
[...] I never got into modern GUI system programming. The notion of having to frankenstein your program from a plethora of other people's libraries, with unknown problems, unfixable problems, inadequate information, and an ever-changing landscape of libraries and OS was more than I was willing to get involved in.
Yes. A lot of software follows the same practices as the automobile industry -- adding tailfins and other "features" to keep people buying new versions when the old version did the job. Many people seem to enjoy twiddling with new interfaces to figure how they work when the older interface provided nearly all the necessary functionality (and both old and new interfaces neglecting needs of users with disabilities).
Software is all that and worse due to the ongoing lack of remedies for reliance by huge software stacks on a library developed by one person ( https://xkcd.com/2347/).
Todays case in point: https://www.theregister.com/2023/02/16/google_delays_certificate_transparenc...
There are useful innovations in all fields, but most people can't sort of the useful from the useless, and the best innovations are often made by small groups that don't have name recognition.
Sandy Munro has a good insights, based on years working in the industry, into these issues for the automobile industry -- we need people who can do the same for software. One of Sandy's current complaints is the auto EV makers who use an array of 3rd party controller models, each requiring a case, power, and data cables, instead of putting all the functions in one module. All those added cables and connectors are potential failure points and added cost for every vehicle sold.
In the linux world, with X11 provided users could work in a terminal and start the GUI from the command line, but over the years, features were added using libraries of varying quality and complicating the interfaces. Wayland et al addressed many of the shortcomings, but was tied to efforts that appear to be aimed at providing a GUI that would be familiar to users whose only experience with computers was with smartphones.
My field (ocean remote sensing) revolves around geolocated images. The NetCDF4-CF file format was developed with inputs from diverse communities, and is used for much of data I encounter. Many users, however, rely on internet searches to "learn" that they need geoTIFF files. Unfortunately, geoTIFF lacks the comprehensive metadata support you can get using NetCDF4-CF files. When I provide files to users who insist on geoTIFF files, I need to translate the NetCDF4-CF metadata into text documents, and the end user has to figure out how to enter the information into their GIS package.
I find I'm getting sucked into using Windows, macOS, and Wayland on linux because that is what colleagues in large enterprises are using. Certainly in my former work, IT was build around a call-center model with no regard for the impacts on actual workflows.
On 2/16/23 14:21, ToddAndMargo via users wrote:
On 2/8/23 00:45, ToddAndMargo via users wrote:
Hi All,
Anyone know of a kitchen timer that has an rpm in the repo?
Many thanks, -T
I gave up and bought a $15 wind up timer. At least I can hear it. Well hear it rattle for 4 seconds. It may have a bell sound, but I can't hear it.
And the stinker broke in a week!