Hacker News Reader

fatherlinnuxon Acquacotta – A Pomodoro system using Google Sheets as a database

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.

fatherlinnuxon Red Hat cutting back RHEL source availability

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.

fatherlinnuxon Red Hat cutting back RHEL source availability

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!

fatherlinnuxon Podman: A Daemonless Container Engine

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.

fatherlinnuxon The CentOS Project Just Committed Suicide

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.

fatherlinnuxon Transitioning from Docker to Podman

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.

fatherlinnuxon Transitioning from Docker to Podman

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.

fatherlinnuxon Transitioning from Docker to Podman

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.

fatherlinnuxon Transitioning from Docker to Podman

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.

fatherlinnuxon A Cold Take on IBM, Red Hat and Their Hybrid Cloud

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)

fatherlinnuxon A Cold Take on IBM, Red Hat and Their Hybrid Cloud

fatherlinnuxon Red Hat Universal Base Image

That's pretty much dead on.

fatherlinnuxon Red Hat Universal Base Image

I do :-)

fatherlinnuxon Red Hat Universal Base Image

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

fatherlinnuxon Red Hat Universal Base Image

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...

fatherlinnuxon Red Hat Universal Base Image

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

fatherlinnuxon Red Hat Universal Base Image

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

fatherlinnuxon Red Hat Universal Base Image

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.

fatherlinnuxon Red Hat Universal Base Image

You get updates with UBI, free of charge.

fatherlinnuxon Red Hat Universal Base Image

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.

fatherlinnuxon Red Hat Universal Base Image

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.

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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...

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

+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...

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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)...

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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....

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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.

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

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...

fatherlinnuxon Goodbye Docker and Thanks for all the Fish

I agree that developed companies are doing what is described, but that is a completely separate thing than starting from scratch.

People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/19/2/linux-distributions-stil...

Even when you write a lot of software, environments always drag in existing tools and infrastructure (aka other open source). 99% it's easier to consume pre-built SME knowledge from. Linux distro #HailTheMaintainers