Oh it's real. When coding an app inside the web editor, you can click a button that effectively sends your code to the GPT4 API, along with some instructions on what it should be. It then displays back the response.
I used to have an iPad (3rd gen) on the wall, then it died. I bought the cheapest new one to replace it, but the old Android tablet I had around had better bluetooth reach, so it went on the wall instead.
Old android tablets are notoriously unpatched against all kinds of things. It's easy to be paranoid that some passing foot traffic will infect it with a bluetooth worm, and you'll be none the wiser.
I'm accepting the risk for now, as I do enjoy configuring Home Assistant on it, and looking at the rainmap, but there are times when when a full tablet is overkill. FrameOS is for those cases.
You're technically right (the best kind?), but there's some nuance to the question.
FrameOS is a compiled binary that runs on top of Linux. At present you need to install the "Raspberry Pi OS Lite" (without the desktop environment) on a SD card before you can install FrameOS itself on top of that. So it's "just an application".
However, this is mostly because it's an early project, and this was the fastest way to get going. The next step is to see how much can be removed. Since FrameOS is a statically compiled single binary, it shouldn't need that much more than the Linux kernel? Will FrameOS be a true OS then? Android seems to be considered its own OS despite using the Linux kernel.
Once activated, FrameOS takes over your entire system, has its own `apps/` and `drivers/` folders, and in many ways already behaves like an Operating System. I'm also pondering about getting it running on an ESP32 (will need to add `drivers/wifi/`?). Without any OS below it, will it then be worthy of being called an OS? You all tell me. :shrug:
Thus is it an Operating System? It is to me, but you can choose to disagree.
At my actual job (PostHog), we sometimes call ourselves the "Product OS". This annoys me more, as a suite of webapps definitely isn't an "Operating System" in its traditional sense. I've seen -OS at the end of other things as well that aren't pure Operating Systems. It slightly bothers me, but mostly because I was around when "what OS you're using" was a defining question. Language is evolving, and "operating system" seems to describe more things to different people, than it does to you and me.
I definitely do not want anyone to manually crop, dither and color index images. This should be done by the FrameOS software. It's already working if you use e.g. Inky Impression 7 color frames, but mostly because I just defer to their software/drivers, which already handle this...
Our crude (actually Pillow’s IIRC) dither has a certain nostalgic appeal to it, but can definitely be bested by other algorithms. I’m still not totally convinced we have a great perceptual match for the colours either. The approach to get them - take a photo of the screen, use a colour dropper and a bit of eye balling - was crude.
(Hi, I wrote most of the Inky driver and your project is the kind of awesome I wish the Pico/RP2040-based Inky Frame devices could pull off.)
I always say "if it's stupid and it works, it's not stupid". Your approach to get the dithering right sounds brilliant to me :D.
The current inky driver works great, and that fact that it's in Python is what made me develop the original FrameOS software in Python. However now that I rewrote it in Nim, the Python driver is a bit of a crutch. While I could use the C drivers for the Waveshare displays, I'm forced to install a python wrapper on the Pi as a workaround to get the Inky drivers working.
Do you have any idea if there are any C, or even Nim drivers available for the Inky Impression boards? The Python workaround works, but isn't really elegant. If not, I'm considering porting them myself at some point...
I'm also lurking on the Pimoroni discord, and was meaning to ask there about it as well.
I have written drivers for Pimoroni's Inky Frames (based on Raspberry Pi Pico W) in Nim, but I don't own an Inky Impression. The code should be pretty similar once it hits the SPI bus.
I have planned to write GPIO/SPI/I2C "drivers" in Nim that interfaces with the Linux drivers. So far I have made a wrapper for libgpiod. https://github.com/daniel-j/nim-gpiod
The editor/controller itself is just a React+Kea app using React Flow for the diagramming part, and Flask for the backend.
For now to test that the app you built works, you must deploy it on a frame. I have a fast RPi 5 for testing, and the feedback loop is typically ~30sec. It's about a minute with a Zero W2, and about 2min with a Zero W. This is not ideal, and I'd like to improve that.
Ideally I'd like to use Nim's JS backend to build a "frame" that can be run directly in the browser for testing.
As for the other questions, the FrameOS system runs at boot, and all the apps are compiled in to that one binary and run as the scene dictates. New frames get rendered when a render event is dispatched, which can happen automatically on an interval, or as requested. Frames send logs back to their controller, but can otherwise operate completely independently.
I'd love it to work on the RP2040, and perhaps even an ESP32, but we're not there yet. Just yesterday I converted FrameOS from being an interpreted python app to a 3MB compiled binary, so we're half of the way there. I'm not sure what changes I must do to get it working (e.g. integrate a wifi driver, remove GC and threads, etc), but it's in the realm of the possible.
There's nothing built in now, but a common technique would be to make the image e.g. ~10px larger in each direction, and then choose a random crop every other second.
It should be really easy to build a FrameOS app that does this. Add one node at the start of the render loop to increase the image accordingly, and one at the end to crop it back down. I was planning to use a similar technique to display smooth scrolling animations/slideshows, but it can definitely be used to prevent burnin.
I'd love for FrameOS to support ESP32. Two days ago FrameOS was a slow and interpreted Python app. Today it's a 3MB statically linked binary. The margins are tight, and I'll likely need to cut out some features (e.g. threading), but theoretically it should be possible to get it to run. However I'm not planning on taking this on any time soon, as there's still a lot of work left to make the Raspberry version great. :)
First, it's 2 rewrites. Second, those were all 98% backwards compatible for the users (might need to upgrade plugins), and just refactored the internals.
But sure, let's all write perfect code on day 0, taking into account all the ways libraries you depend on (React) can develop in the future. It's not like "frontend" is a moving target or anything...
Well, in PostHog (I'm a colleague of Twixes), we just decided here [1] to go with Kea, as I had more experience with it.
Had Redux Toolkit been around when I started with Redux in 2016, I probably wouldn't have needed to write Kea. However I'm glad I did, as I now do consider Kea to be the better toolkit for the same job. :D. I know you disagree, and that's all fine of course :).
In my mind Kea fills in all the missing parts from React, while Redux Toolkit is still a set of utility functions for state management. You still need to find another set of tools for data loading (I see this has improved), complex data or form management, app routing, scene handling, etc. Redux Toolkit doesn't bother with most of that, and I don't think it should.
Kea however comes with solutions for all of those. The only thing missing from being able to build a complete app is a JS module bundler. Just sit down and start writing your actual app with the least amount of syntax possible to explain things in a redux'y way. Many people have told me that with Kea, the framework basically gets out of the way and disappears.
Now with the Kea 3.0 Logic Builder syntax, Kea is suddenly like lego for state management. I'm curious to see if this picks up or not. I can't unfortunately link Kea from redux.js.org to drive traffic :).
Haha, nice, that does explain why PostHog adopted Kea! :)
I know I've said this in a couple issue threads, but just to re-state it publicly:
As Redux maintainer and RTK creator, I do feel RTK is the best approach for using Redux, and that's why we now teach it as default.
But it's great that you've been able to build out an alternate toolset on top of the Redux core that suits your needs and share that, and it's _also_ my job as maintainer to make sure that you still have the tools available to keep that working. (which is why even though I've marked `createStore` as deprecated per our prior issue threads, we're not going to _remove_ it - too many apps and libs depend on it as-is.)
And yeah, agreed that Kea and RTK have different areas of focus. We don't _want_ to handle routing or forms :)
It's really basic, but has already been useful: https://frameos.net/blog/gpt4-support