fatherlinnux

I’ve used the Pomodoro technique for over 20 years, from my time as an engineer at NASA to leading teams at Red Hat. Throughout that time, I’ve found that most timer apps are "data silos"—your focus history is locked behind a proprietary API or a subscription model.

I built Acquacotta to solve the "audit" problem. It’s a minimalist, open-source timer that treats your productivity like a data science project.

The Architecture: Instead of a traditional backend, Acquacotta logs every session in real-time directly to your own Google Sheet.

Offline-First: It uses a local SQLite cache so the UI is never blocked by network latency to the Google API.

Data Sovereignty: You own the infrastructure and the schema. You can run your own pivot tables, regressions, or pipe the data into an LLM for a performance audit without ever "exporting" a CSV.

No Commercial Version: This is purely a passion project. There is no "Pro" tier or tracking.

Key Features for Power Users:

Acoustic Focus: An optional "60 Minutes" style ticking sound that acts as a Pavlovian trigger for flow states.

Physical Timer Support: A dedicated mode to manually (but quickly) log sessions from tactile hardware like Hexagon timers.

Sustainability Metrics: Visual "Daily Minute Goals" designed to prevent the "heroics-to-burnout" cycle by helping you find your "Goldilocks zone" of output.

I built this because I wanted a professional-grade audit log of my career, not just a series of alarms.

GitHub: https://github.com/fatherlinux/Acquacotta

Hosted Web App: https://acquacotta.crunchtools.com:8443

I’d love to hear your thoughts on the "Sheets-as-a-backend" approach for small-scale personal telemetry.

I think I get the gist of your sentiment, and somewhat agree, but let me clarify.

GPL, only enforces redistribution of software you distribute, "to" the people you desteibute it to, aka customers.

Most other licenses (MIT, Apache, BSD, etc) don't require any code redistribution (though some require attribution).

GPL ~= redistribution to customers Other ~= no redistribution

Red Hat is complying with the GPL requirements even for BSD, Apache, and BSD licensed code, which I think is good.

I think a more sinister trend forming is around open core, and essentially proprietary code mixed with no code redistribution at all. This makes open core essentially closed source for all intents and purposes. Companies are using open core simply for free marketing and to drive technology adoption in the sales/marketing funnels.

I read this comment, said to myself hell yeah, this person gets it, then realized it was my friend JZB!!! On point my friend, on point!

That is correct. We're targeting that work for RHEL 8.5 in November-ish, so you'll likely see that drop in Fedora and other Linux distros sooner.

How is CentOS Stream not a binary compatible distro with RHEL. Technically, CentOS was NEVER binary compatible with RHEL, it's a re-compile, but EPEL works with it. The same is true with Stream. No change there.

The change is CS Stream is literally the same change our (Red Hat) customers have been absorbing for years.

CentOS users have this perception that they were getting stability by being behind paying RHEL users. Think about how ridiculous that logic is.

RHEL users weren't being bombarded by ridiculous instability. RHEL Betas were never that unstable and besides Stream literally passes the RHEL hatting tests.

See more #6/#7 here: http://crunchtools.com/before-you-get-mad-about-the-centos-s...

So many people were consuming CentOS without a fuzzy clue to how RHEL works. Makes it all the more frautrsting for people who get a paycheck from RHEL.

I've said this so many times, but we wanted to carry Docker in RHEL 8, but we couldn't. We would have been forced to use Moby and it's not a well contributed to project anymore. The whole Docker contributor community has fallen apart, and Red Hat needs to be able to support a container engine until the mid 2030s.

You can get access to Moby in Fedora, but it just wasn't viable to include docker in RHEL 8 for both legal and community risks.

I can explain this. Because docker-compose talks to the docker socket and uses the docker protocol. This was the last piece that we nailed with podman. As of Podman 2.0 with the new REST based API with a Docker compatibility layer, we are very close to just being able to use the docker-compose binary to talk to a socket (ran by systemd) which fires up podman.

It doesn't quite work yet today because we are still implementing some of the REST verbs, but it's close. It's definitely a strategic direction for the roadmap. Stay tuned.

We're working hard on docker-compose support. With the new Podman 2.0 REST API with a Docker compatibility layer, we are close. Not quite there, but definitely strategically on the roadmap.

Both of you are right. Red Hat pays for Fedora in a lot of ways, but does not control it. There are obviously a lot of personal and professional relationships that gives Red Hat influence over Fedora, but the purse strings are never used to control it.

Small correction, it's ALWAYS been hard to be a mid-sized software company. We were constantly talking about the 5 or so companies that reached 5B with software only. They are rare birds indeed. Red Hat didn't make it without getting bought... (full disclosure, I work at Red Hat)

+1

That's pretty much dead on.

I do :-)

Sorry about that. It's my corporate speak :-)

TallGuyShort1, you are awesome :-) Thank you for the defense. We will evaluate adding packages to UBI as necessary, but you are right, we can't give all of RHEL away for free...

If there is a particular package you need in UBI, we would be happy to evaluate it. Please file a BZ under RHEL 7 or 8 under the ubi-* Product Component at http://bugzilla.redhat.com

The exclusion of python36 from the UBI8 table is a mistake. I am working on getting it updated.

UBI lives in between community and product. It's a community thing if run without a subscription and a product if run on RHEL/OpenShift.

You get updates with UBI, free of charge.

Because "FROM centos:8" can't exist until after "FROM ubi8" exists. UBI will offer betas for RHEL 9, 10, 11, etc. It solves a chicken and egg problem for partners who need early access.

We are working on it. We provide the openjdk package in UBI now, you can build a container image from the base. I plan on publishing a blog entry soon, explaining how. Also, we are working on releasing a pre-built image.

Perhaps, you caught news of something I haven't seen, but AFAIK, "container" is still defined in user space. Talking to Eric Biederman, that's what the kennel team wants - people to experiment in user space, remixing kernel tech together...

Most people nothing about technology and don't want to. Not sure where that argument goes, but I am guessing jobless...

+1. Back in the day, we used to mirror all of CPAN, because even as a young buck, I saw the gap in rebuilding apps without the source copied...

I LOVE the junk drawer analogy. I will credit you on my next blog ;-)

See my three rules above. Engineering is a zero sum game, even in open source. Nomad has a very dark future. Single vendor, no community, very little usage, no competitors adopting the tech. If your competitors don't adopt your tech is dead (basic open source 101)...

I agree with your pragmatism (and admire it). I would only urge you to add a couple of tools to your toolbelt for analysis:

1. Open source politics aka is the project viable? 2. Where's the money coming from? Aka, what products/companies build solutions off the tech? 3. Look for growth, not survival. If a company is not growing, it is dying.

These extra three test "gates" help me select what technology I will use, learn, and bet my career on....

I agree, there was a gap, especially for about 2 years. But, even when that gap existed, it was pretty clear that the cloud providers (and other software companies) would build/enable a one click Kube distros.

As the cloud providers adopted Kube, I knew Swarm would loose. Now, the answer is, "use an API" don't run it local if you don't have to.

You could have if HashiCorp had beaten Docker to market with a simple VagrantHub and bud tool...

It could have easily been VMs instead of containers. IMHO, it was all the packaging...