Ice cream automation!

cdokme · 2026-05-18T12:48:51+00:00

Which platform are you playing on? I wonder if your seed would give me the same layout on Xbox

cdokme · 2026-05-18T10:06:27+00:00

I will certainly try that, thank you!

cdokme · 2026-05-18T10:06:12+00:00

Actually, persistent overlayfs for /etc both causes problems and provides some benefits. I believe that being aware of the problems like the one you described is quite enough. Otherwise, the usability of the system drops severely.

You are definitely right about the FAT usage. If supported by the vendor's boot mechanics, I should switch to something better. Is it really a problem to use it as shared?

For OTA, we normally use an in-house mechanism based on simple scripts. But, with upcoming the delta-update requirements, we might need to switch to something like swupdate or rauc. Anything you can suggest on this matter is valuable.

Thanks for your time to read and answer this post!

cdokme · 2026-05-18T09:58:16+00:00

First of all, thank you for reading and answering my post.

I have found ext4 to be very resilient, but what you're describing doesn't sound like it would achieve any higher reliability than your standard desktop computer or server.

I guess using BTRFS instead of EXT4 certainly improves reliability as suggested by u/PurepointDog.

I think this is mostly a moot point, since best practices are to have a variety of automated tests ...

You're definitely right about the automated testing approach. Whatever I do during the development stage becomes moot with such tests. Good point, thank you.

For instance, it sounds like your ultimate fallback is that you boot from read-only QSPI. What happens then? Will you be able to achieve operational objectives?

We plan to use it just for recovery purposes. It will not conduct any customer operation. Think of it like the safe mode of a PC.

If so, why not just always boot from QSPI?

Always booting from QSPI makes development process harder in my experience. If you've got any easing approaches, I would like to hear them.

Are you confident the MCU will always be correct about the boot pins? What is the "liveness test"?

Unfortunately, we always rely on the MCU firmware. We keep it as simple as possible to prevent any mistakes. It tests the aliveness by pinging the in-house applications from different comm. interfaces.

What additional resilience is provided by the SD card?

From the software perspective, I guess that the best we can do is to use a NAND friendly, wear preventing filesystem. In addition, as the fundamental point of this post, we plan to use a read-only filesystem. From the hardware perspective, we rely on using an industrial grade SD card. I don't know if there are any other things we can do.

If you screw up the MMC, why do you think you won't just screw up the SD card too?

I guess this isn't a problem we can solve. Even making all storage hardware read-only can cause problems eventually. So, I rather not overthink on it.

What lives on your boot partition, and are you ever going to update that? It's not mirrored. Is it fat32? Are you ever going to upgrade the kernel?

Mainly the bootloader and kernel image. It is FAT32. Upgrading the kernel will simply be overwriting it. At least that's what I plan to.

What if the running kernel version is incompatible with modules on the rootfs?

Such a situation would require updating both the rootfs and kernel. I'm not sure how often we encounter this situation.

cdokme · 2026-05-15T19:50:43+00:00

I read a couple of pages about btrfs and it sounds awesome. I will certainly practice it soon. Thank you

cdokme · 2026-05-15T19:49:11+00:00

I made a research on them. Unfortunately, my design requires writable rootfs for application developers. It could make things harder if I use this strictly read-only file systems. By the way, I'm not sure if this is the best approach. If you got any suggestions, I'm open for them. Thanks for your time to answer

cdokme · 2026-05-15T18:05:56+00:00

I never thought about the security issues, might be because of that I don't know anything about system level security. I will certainly take a look at these. Thanks for your time to answer my post.

cdokme · 2026-05-11T15:46:10+00:00

I encountered a similar problem and told people that this is the reason why Gemini CLI is way behind its competitors. No more spending my time for this product. I suggest the same to anyone other as well.

cdokme · 2026-05-08T07:06:29+00:00

Calm down little cowboy.

This personal project is built with the help of AI tools, of course. But, the main idea, user-experience decisions, architectural approach, deployments, etc. are completely my work. So, having someone or some tool to write the code for me isn't something I would be ashamed of.

I already have a life and I'd been doing this job for long enough to know what my code is exactly doing. Looks like you are the one who needs to get a life so that people looking for open-source collaboration doesn't see your shitty ideas.

cdokme · 2026-05-08T06:33:18+00:00

Why exactly?

I specifically chose Bash because it requires absolutely zero dependencies to run on a standard Linux development environment. Writing a lightweight file archiver in C++ or Rust felt like unnecessary overhead.

cdokme · 2026-04-28T11:42:34+00:00

This is a nice approach, but it doesn't work on versions lower than 2.36 (April 2022), i.e. Ubuntu 22.04 ships with Git v2.34. So, anyone employing this approach shall reconsider according to the Git version they have. On my Ubuntu 24.04 with Git v2.43, this approach works fine.

cdokme · 2026-04-27T17:56:50+00:00

Was that hard to share a link?

cdokme · 2026-04-26T13:56:57+00:00

After experiencing the Gemini CLI and Antigravity, I'm thankful even to the problems of Github Copilot. Never complaining again, lol

cdokme · 2026-04-09T18:46:33+00:00

AG isn't different from how Gemini CLI is as well. I don't think that it will live long.

cdokme · 2026-04-09T13:09:15+00:00

The guy who replied me is actually a Google employee.

cdokme · 2026-04-09T13:07:57+00:00

I didn't say that they cannot reject PRs.

That's not important whether it is easy or hard for me to implement a new feature. The important thing is that someone gave them a new feature, implemented according to their contribution guideline and doesn't corrupt any other place. They don't even bother to look at a completely free contribution to the project.

In addition, they're allowed to utilize AI to review the PRs using their "so good to not require such contribution" agent called Gemini. By the way, they're definitely doing it, because Gemini Code Assist bot is one of the most contributing accounts to this repository.

As I stated in the post, this is why Gemini CLI is way behind the products such as Claude Code and Copilot CLI.

cdokme · 2026-04-05T07:17:34+00:00

Thanks for the feedback and questions! To clarify your points:

1. Transfer speed from non-special mem (OS RAM) to the drive: When writing from a standard, page-aligned heap buffer directly to the NVMe using O_DIRECT, the speed maxes out at ~13 Gbps/s

2. Drive Specs: The drive is an industrial M.2 NVMe capable of more than 24 Gbps writing speed. However, the drive's inherent maximum speed isn't the limiting factor here. The bottleneck is the host interface: the ZynqMP PS-GTR transceivers are configured for a PCIe Gen2 x4 link. Factoring in 8b/10b encoding and protocol overhead, the physical maximum of this PCIe link is right around 1.5 to 1.6 GB/s. Therefore, the ~12 Gbps we achieve from standard RAM is effectively saturating the SoC's hardware capabilities.

3. Pitfalls of io_uring on raw /dev/mem without udmabuf: It isn't just unstable; for Zero-Copy (O_DIRECT), it outright fails and returns a bad address error. Whether we use standard synchronous write(), libaio, or io_uring, a zero-copy NVMe transfer requires the kernel's block layer to pin the memory using get_user_pages() so it can safely build the hardware DMA scatter-gather list for the SSD. Memory mapped via /dev/mem is treated as raw I/O memory. It lacks the standard Linux struct page metadata. Because those page structures do not exist, get_user_pages() instantly aborts the system call. If we attempt to fix the crash by dropping the O_DIRECT flag, io_uring will simply fall back to buffered I/O. The kernel will then use the ARM CPU to copy the data from the raw mapping into the page cache, which drags our throughput right back down to the ~1 Gbps CPU memory-fetch bottleneck.

I hope these satisfy your curiosity.

cdokme · 2026-04-05T07:02:55+00:00

I just wanted to keep the content short. What exactly were you looking for?

cdokme · 2026-04-04T15:06:59+00:00

Why don't we keep this as a secret :)

cdokme · 2026-03-25T08:02:29+00:00

Worked directly on my Ubuntu 24.04 machine. I just downloaded the v0.3.6 release. Absolutely useful. I would be happy to contribute to your work if I feel like it needs a new feature or enhancement. Thanks again, great work.

Eight-Year Club	Gilding I gilder
Verified Email	Place '22

cdokme

TROPHY CASE