9:35 a.m.
On Wed, 8 Feb 2023 00:45:20 -0800
ToddAndMargo via users <users(a)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.
3:04 p.m.
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)
4:18 p.m.
On Wed, Feb 8, 2023 at 3:45 AM ToddAndMargo via users
<users(a)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
9:39 p.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.83.1.el7.x86_64 #1 SMP Wed Jan 25 16:41:43 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
6:51 p.m.
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.
2:09 a.m.
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.
--
uname -rsvp
Linux 3.10.0-1160.83.1.el7.x86_64 #1 SMP Wed Jan 25 16:41:43 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
7:31 a.m.
On Sat, Feb 18, 2023 at 4:09 AM Tim via users <users(a)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_transpar...
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.
--
George N. White III
8:53 p.m.
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!
455
days inactive
466
days old
9 comments
6 participants
participants (6)
-
George N. White III -
Jeffrey Walton -
Samuel Sieb -
stan -
Tim -
ToddAndMargo