Comment by ____tom____
4 hours ago
Sounds like the second system effect. (The Mythical Man Month)
First one is simple and focused, the second one tries to be & do everything. And frequently never ships.
4 hours ago
Sounds like the second system effect. (The Mythical Man Month)
First one is simple and focused, the second one tries to be & do everything. And frequently never ships.
The odd thing is that this disguises as some bare metal, hackable device.
Their TUI[1] is planned to use react(!), to share logic with their BrowserUI[2]. In the repos you can see how they struggle to get anything gpu backed done (which is required by the browser). Then falling back to wayland to do it for them. (This all seems a mess that LLMs can't figure out.)
Anyway, it does seem to end up in a custom linux desktop environment, with lots of sharp edges that makes it less hackable.
[1] https://docs.flipper.net/one/cpu-software/flipctl [2] entirely unclear why a terminal is insufficient for networked TUIs
[dead]
> First one is simple and focused
First time I've heard anyone call the Flipper Zero "simple" and "focused", most people seemed to have considered it a "swiss-knife" meant to just house a bunch of features and radios, meanwhile the One has less features but more connectivity and I/O.
But apparently you're not alone in feeling this, but I don't understand what from the submission makes you and others believe so, what exactly gave you this impression?
Well the first one was a microcontroller.
And this one is an 8-core Arm computer and the project has ambitions of some notoriously difficult things: no binary blobs, full mainline support (including a NPU), reinventing small-screen UI for more serious handheld computing, and supporting a ton of high-bandwidth interfaces.
This is not a simple step up in difficulty.
Agreed. This will likely never ship with all the bloat. Custom AI model, custom OS, extremely custom architecture (2 "main" processors running independently...), barely reuses any of the previous work from Flipper Zero.
A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
The "custom os" part could also be done easilly enough with the correct approach.
Specifically systemd has a less-known feature known as system extensions intended for basically exactly these sort of scenarios. These system-extensions are basically disk images containing files in /usr and/or /opt that can be dynamically overlaid on the existing filesystem (the intent is that these are purely additive). Systemd also intends that all os provided configuration live in /usr, with /etc existing only for machine specific or admin applied configuration. (And which should enabling overriding anything specified by the package or OS.)
System extensions when used default /opt and /usr to be read-only, but you can enable mutability if you having write routing directories or symlinks in the right spot.
So for userland this whole os profiles things could literally just be a set a of system-extensions, a distinct /etc folder, and distinct set of write redirect directories for each. An initramfs can simply bind mount the /etc directory, and add the correct write redirection symlnks before systemd starts. Rolling back a profile is simply wiping its write redirection and /etc folders. If you also want each to potentially have distinct device trees and/or customized kernels, that would need additional bootloader work on top, but nothing that feels too extreme.
Now in reality, since not everything support systemd style configuration, these OS profiles would probably need to construct an initial /etc by copying files from a base-os template, and then copying in anything included in the system extension images (which can have these as systemd will ignore such folders), but that is straightforward enough.
> A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
Don't underestimate the value of that integration.
With the hybrid architecture chips you get the vendor controls for managing the MCU with supporting documentation. ST is good at this.
This isn't the same thing. It's two chips running side by side. It's possible to set it all up so that the Linux chip can control everything you need to manage the MCU, but it's not easy. There are a lot of edge cases to think about and things that need to be handled manually.
> A combined MPU and MCU architecture isn't that exotic. ST microelectronics currently sells a single chip with that contains a two core Cortex A7 Microprocessor combined with a microcontroller. Admittedly more tightly integrated with ability to communicate via shared memory.
Going with an SoC is much simpler than trying to set up custom communications between two processors, I'm not sure why they didn't think of that.
> 2 "main" processors running independently...
On the other hand, this has been working pretty well for the first few Raspberry Pis! (Although they had the benefit of leveraging an existing smart TV based platform for that.)
They're very explicit that Flipper 1 isn't a "v2", but a device that targets different use cases.