I've achieved this with a few lines of bash on the default Pi distro. I don't really see the benefit unless there's added advantage of Chromium being accelerated? (Last time I checked it was not. Not only that HTML5 Audio was missing too).
For anyone interested heres a dirty bash script I had:
matchbox-window-manager &
while true; do
sudo rm -r /etc/chromium
su -c "chromium-browser --kiosk --incognito http://localhost" -s /bin/sh pi
done
The script logs in and starts x with matchbox (better performance than LXDE default), opens Chromium to localhost (nginx would show a page).
I remember I added a few other things to 'sed' replace Pi config files to display a mp4 splash screen I made in AE (it looked marvelous). At one point I had a front end that could manage Wifi and do some other basic tasks. Using PHP and Nginx. Shamefully hackey.
Works well, Iceweasel has better HTML5 support on the Pi than Chromium.
Though struggled getting Iceweasel to start in full screen from command line, afaik there no flags, one way was to close in fullscreen state or install a plugin. Further IW shows first run dialogs. Annoying if your deploying several Pis, then theres the cursor which unclutter package helps to solve. Lastly matchbox x uses less ram than LXDE which was important in my use case.
Chromium is better if you want to seamlessly deploy Pi's without spending too much time configuring them, theres a trade off somewhere - the official Chromiums package is old and IW is newer with less API.
You may want to consider wrapping your command inside the while loop in the script above. I added did this after I experienced IW and Chromiums unexpectedly closing sometimes. Helped alot.
It's pretty common in the raspberry pi community to create single purpose pre-made SD card images that are all ready to use, this is just another one of those. It's neat, reminds me of popping in an boot floppy in ye olden days.
I used to do the same [0], quite a while ago now, until I discovered Screenly Open Source Edition [1]. There are a lot of tweaks to get right, and it does video, images and web pages. I made a fork with basic authentication to the web administration interface [2], in case the network is not private.
This project does look interesting though. Last time I did this the Pi was a bit underpowered for some JavaScript heavy dashboards and the Wi-Fi was really flaky. Perhaps the Pi 3 has fixed these things but I haven't tried it.
Sweet, I've been wanting to create an OS on a RasPi, and your project just made it easier. Thanks! I was going to use Electron, but I guess Chromium is good too. I'll have to change some things to make it work with my FeathersJS app.
Oh wow, this is neat, thanks for sharing! I want to add aspects of Desktop Neo to my OS project because I find it an interesting concept and it seems like the traditional method of desktop computing is undergoing a transition.
I was inspired by Firefox OS some time ago and found that I could access various parts of the filesystem via nodeJS. My plan is to run my node app and launch Electron fullscreen when the Pi boots.
I built something like this[0] at a past job based on Yocto Linux and Midori. I targetted at the SolidRun CuBox because shipping an RPi to customer site didn't communicate the level of professionalism we were looking for. :)
My goals were small size and building something very secure, and I think I pulled it off. The resulting disk image is on the order of a couple hundred megabytes, iirc (X is very big), and it does not permit interactive login by default (no ssh). It also runs the root filesystem in read-only mode. As a bonus, you get the entire Yocto ecosystem.
I have experimented a bit with the raspberry pi to drive some TV's around our office. Stock Raspberian OS with different browsers. Unfortunately I was kind of underwhelmed by the performance: tv.giphy.com already is kind of too heavy, and even geckoboard is to heavy to run on a raspberry..
Or am I missing some great performance tweaks?
Where I work, over the past 2-3 years we've used B+, Pi 2, and Pi 3 (all running Raspbian) for public display screens and browser performance is terrible on all of them. Even the Pi 3 is unable to play YouTube videos without freezing for 10-30 seconds while it buffers and skipping a ton of frames throughout.
If you have video files or use e.g. youtube-dl and then play video back with omxplayer it's nice and smooth (although using the --loop option seems to make the video freeze after several hours/days; memory leak?). Our solution was a 2-line bash script to start a new omxplayer instance when the previous one finishes ad infinitum until you Ctrl+C, and that's run for 7 or 8 months now without a hitch.
Oh wow. A while back I made a Raspi boot to Chromium full screen to load my Trello+Weather+StatusCake dashboard (https://gist.github.com/danroot/7610103). I felt it was way harder than it should have been, though to be fair much of the issue was that I had a line in the wrong place in some boot script. Still, I remember thinking at the time that I'd like a distro where I could easily put in Wifi and URLS, then boot directly to it. May have to revisit that now...
My company did something similar to this for our dashboards, great to see someone open source it. At the time the challenge was finding a new-ish version of Chromium, which at the time was years behind in the Raspbian distro. It looks like this one is Chromium 51?
Did a similar thing a few years back, with playlist support and uzbl as the browser (which is much faster and lighter than chromium) and omxplayer to play/stream full screen video.
Just a Python script with playlist support, really:
I wonder if something based on RISC OS [0] would be more lightweight and boot quicker? I believe NOOBS is based on this and it loads very quickly. Linux is great but Raspbian may be overkill for something like this.
I don't understand the effort here. Making an image implies supporting it; does the author really think it's going to be worth his time to "support" what is surely a couple of bash scripts wrapped up in 600MB of OS?
It seems like a simple how-to blog post would have been more appropriate.
They seem to have a goal they've completely forgotten to mention. Moving all the settings into a textfile in /boot means you can bring this up from a windows machine (/boot is fat rather than ext2/3/4 due to limitations in the firmware that seek the bootcode).
So on a windows or mac machine (or pretty much any OS that can handle an SD card in the first place), you can write the image, edit the settings on the card, then stick it in the pi & have it up and running. The methods that most of us would use to do this manually, are near impossible to preflight from an OS that doesn't support ext2/3/4.
Indeed, its what lets us release a new version in OctoPi within hours of announcements on raspberrypi.org. I am also working on adding other devices support using Armbian.
Developer here. Well, people are using it. And the power of this is that I can accept pull requests, and have nightly builds. OctoPi, my distro before this got 100k downloads because of this fact.
I made it because I needed it, and others need it too. I have three collaborators with me who made the dashboard app.
A bit disappointed since I read the headline (it has distro in the headline somehow my brain stopped at xxxxOS) and thought it was an OS developed from scratch (I was ready to get impressed by writing/porting a browser for it as well). Alas it seems to use Raspbian. Still a fun project but I'd probably tackle that with a startup script or something.
I was thinking of doing this, with the specific added feature of ensuring the page is displayed, and periodically refreshed.
In case of server returning non-200 response, it should wait a few seconds and refresh. In case of network disconnected (especially when using wifi), same thing - refresh the page.
The periodic refresh is necessary for pages that don't refresh, but even for wallboard-designed content that stays updated, scripts break and things go wrong. The browser itself refreshing is a fail-safe. You should never have to touch these things once they're installed, and that includes doing a hard reboot.
Another nice-to-have feature: turning off the display signal at night (letting the display sleep) and turning it back on in the morning. With computer monitors this is easy, with TVs it probably needs HDMI-CEC, but seems possible.
For anyone interested heres a dirty bash script I had:
1. Auto Login & Disable Screen Blanking: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=18200, http://elinux.org/RPi_Debian_Auto_Login
3. Adjust Overscan and force HDMI hotplug: nano /boot/config.txt disable_overscan hdmi_force_hotplug
4. Install Chromium, Matchbox, unclutter: sudo apt-get -y install unclutter matchbox chromium-browser
5. Add a start up script:
unclutter & xset -dpms xset s off
matchbox-window-manager & while true; do sudo rm -r /etc/chromium su -c "chromium-browser --kiosk --incognito http://localhost" -s /bin/sh pi done
The script logs in and starts x with matchbox (better performance than LXDE default), opens Chromium to localhost (nginx would show a page).
I remember I added a few other things to 'sed' replace Pi config files to display a mp4 splash screen I made in AE (it looked marvelous). At one point I had a front end that could manage Wifi and do some other basic tasks. Using PHP and Nginx. Shamefully hackey.