Lite Linux Distros for a Digital Picture Frame?

bwy asks: "I'm building a digital picture frame, inspired by a story here at Slashdot. Currently, I'm using Red Hat 9 with GDM autologin, icewm, and a slideshow program autostarting. I've installed code to hide the mouse pointer and the 'powerswitch' kernel module to allow the frame to run a proper shutdown (instead of a suspend) when the ATX power switch is pressed. The hardware is an EPIA 5000 with a laptop drive. I think this is overkill, however, and I am a purist. Is there a lightweight distribution that is EPIA friendly? Such a distro shouldn't install GCC, so I'll need all the software as binaries. How would I go about booting from a ramdisk? This would make the 'powerwitch' kernel mod not so important since there is no worry of corrupting the file system." Does anyone have distribution suggestions, or pointers to other information that might be helpful for such a project?

Comments

You don't need binaries.

[Anaxagor]

"Such a distro shouldn't install GCC, so I'll need all the software as binaries."

Just get yourself another machine with a toolchain to build the binaries you need from source, particularly if you plan on taking binaries from untrusted sources.

Of course someone could give you dodgy code, but it's a lot less likely to happen, and at least you've got a fighting chance of checking the code for suspicious function calls etc.

Re:You don't need binaries.

[the_raptor]

Tad paranoid? I assume you audit every single line of code that runs on your system? Maybe check the BIOS to? Hell better make your own chips to, who knows what evil features could be built into them. ITS A PICTURE FRAME, NOT A BLOODY SERVER FULL OF CLASSIFIED MATERIAL.

Re:You don't need binaries.

[Anonymous Coward]

The parent poster seems to assume that the digital picture frame in question will be connected to the owner's home network. Another seemingly safe assumption is that said home network is connected to a much larger public network such as the global Internet. Using the addage that "a network is only as secure as its weakest link" then one can see why securing the digital picture frame would be considered necessary.

Re:You don't need binaries.

[Anaxagor]

There's nothing paranoid about it. In fact, it's probably not paranoid enough - ever installed anything from code yourself? Ever thought to check the configure script?

irssi 0.8.4 backdoor

If you blindly run stuff you pull from the net, sooner or later you will pull down some malware, and then the fun begins.

Re:You don't need binaries.

[Anonymous Coward]

Somebody's gonna root your picture frame. Beware of untrusted binaries!

Re:You don't need binaries.

[the_raptor]

I don't blindly run stuff I pull from the net, but I do run a commercial Linux distro. Do I have any real reason to trust them? Unless you can actually read C (or whatever language) looking at the binaries is pretty pointless. Rather then inserting backdoors it would be much easier to just install some buffer overflows. Since even experienced coders miss buffer overflows, casual checking of code is not going to pick them up.

Re:You don't need binaries.

[Anaxagor]

You are confused.

"Unless you can actually read C (or whatever language) looking at the binaries is pretty pointless"

No amount of C will help you read binaries. For that you need a disassembler, knowledge of assembly language, and a hell of a lot of spare time.

"Rather then inserting backdoors it would be much easier to just install some buffer overflows."

No.

It would not be easier.

Ever written code to bind a shell to a listening port? Ever coded a buffer overflow exploit? There are orders of magnitude of difficulty separating the two. Say you mess around with some printf() or strcpy() calls and introduce some overflows or format string bugs in an application which binds to a TCP port. What if the victim machine is behind a firewall? How do you take advantage of the BO's then? OK, you tell me, you write a BO which makes an outbound connection which *might* get through the firewall. But this is exactly what a backdoor like the irssi configure script does, but without all the fucking around overflowing the stack to get control of the execution path.

"Since even experienced coders miss buffer overflows, casual checking of code is not going to pick them up."

So projects like OpenBSD and Adamantix should just give up, because according to you code audits are a waste of time?

Re:You don't need binaries.

[the_raptor]

I meant unless you can read C looking at the *source* is pretty pointless (my bad).
And by buffer overflows being *easier* I meant more likely to escape detection. A shell being bound to a listening port is something that should *obviously* not be happening in most programs.
As you said it is not as good or as fool proof as a backdoor. But backdoors are much more obvious then buffer overflows. And considering script-kiddies seem to have plenty of tools already for attack buffers, I don't think you have to worry about whether they would attack such a vulnerability.
And no I don't think code auditing efforts are a waste of time, I never said that. I said it is a waste of time for someone to prefer source over binaries (and check some of the source) and somehow think this makes them invulnerable to malware. I doubt one individual could check even the kernel for such things in a reasonable time frame (assuming said individual is not a code god)
If you *need* secure systems you use old code that has been heavily audited, and I would actually recommend OpenBSD.
And the irrsi backdoor was in the source and *not* the binary ;)
Since I personally don't have the time to audit the code in my system, I listen out for security and bug reports and patch my system.
*DIRECTED AT GRAMMER NAZI'S* Oh and you grammer nazi's can go fuck yourselves. Not even man enough to insult my spelling without hiding behind AC status? You truly are a waste of energy.

Re:You don't need binaries.

[roju]

Grin. Depends on the pictures.

Re:You don't need binaries.

[Anonymous Coward]

Not everybody who links to the Goatse picture is a troll. If you build a picture frame, you REALLY don't want somebody to be able to show their choice of pictures. Don't believe me? Click on the link.

Re:You don't need binaries.

[Anonymous Coward]

"...checking the code..."

You make offensive assumptions. That Linux should never be installed from binaries. That it is always untrustable. That it is on every individual to audit the code they download. That every individual is capable of it.

Crap. I look both ways before I cross the street, but I don't hire crossing guards to stop traffic for me. I check to see if I trust the place/people I get binaries from, but I don't hire a programmer (since I don't program and who I'd have to trust) to audit the code.

You people talking about how everyone has to examine source code for security are idiots. It is *good* to have the ability, it is *good* to have people go over the code, it is *stupid* to say that normal people should *ever* see source code.

Guess what? I am not a programmer. I'm not ever going to audit source code. It is pointless for me to compile source for security. If I want snotty elitism I'll run OpenBSD. If you want to be a snotty elitist, go hang out on the OpenBSD maillists, a bigger collection of dicks is hard to find.

I don't *care* if you think Linux should only be for programmers, I'm going to run it anyway.

Re:You don't need binaries.

[Anonymous Coward]

You misspelled 'grammar'. HTH. HAND.

Re:You don't need binaries.

[Nonesuch]

If you *need* secure systems you use old code that has been heavily audited, and I would actually recommend OpenBSD.

Speaking of OpenBSD, they're heavily into systrace these days, which gives you some leeway to work with software from less audited sources.

Currently, Systrace is integrated in NetBSD and OpenBSD, with a Linux port also being maintained. Similar functionality is available in the Okena (now Cisco) Security Agent for MS-Windows and Solaris, for $$$$.

And by buffer overflows being *easier* I meant more likely to escape detection. A shell being bound to a listening port is something that should *obviously* not be happening in most programs.

Under systrace, I can take an X application binary which is intended to display a slideshow, and without any access to source, inspect the "normal" execution profile, and build a systrace profile that forbids the application from opening a listening port or exec'ing /bin/sh.

A real world example: I use systrace to run Opera. I cannot get source code for Opera, but by running it under a restricted profile, I can still have assurance as to the system calls which it can successfully make.

embedded linux

[cloudless.net]

Shouldn't you begin with embedded linux instead of redhat?

Re:embedded linux

[RevAaron]

That statement is close to being semantically null. RedHat can be used as "embedded Linux," and as far as a RT kernel, he certainly does not need one in this situation. As a rule, "embedded" doesn't mean much more than stripped libraries and an somewhat RT kernel- at least for Linux. Running a full distro rather than some "embedded" version probably means doing *a lot* less work. The thing has a harddrive, and he can install a pretty spartan system- so who cares? What difference would so-called "embedded" Linux make?

Different approach

[richie2000]

I used Gentoo on an old HP laptop with broken screen hinges. I also used the framebuffer stuff instead of a full windowing environment, partly because the laptop just had 64MB RAM and partly because I didn't feel like compiling X on a PII 266. :-)

The main reason for using Gentoo was that it let me decide exactly what to install. No servers in the background, no rxtra nothing. I was thinking of just deleting gcc and the source after I was done but I never got around to it, thinking I might need it later.

Re:Different approach

[Anonymous Coward]

why not just compile the pieces from Linux from scratch?

Woah! Overkill!

[Kevin Burtch]

I'd recommend building yourself a simple "run from RAM" setup using Knoppix (or something similar), and install it on a CompactFlash card.
CompactFlash has several data transfer modes, one of which is essentially IDE.
Yes, you can take one of those ultra-cheap PCMCIA->CompactFlash adaptors, rip it apart and solder on a parallel IDE cable (google for it, it's common), and plug it right into your motherboard. I just googled for it myself, and found that CompactFlash-IDE adaptors are now being sold, so you don't even need to get your soldering iron out.

Now you've eliminated the hard drive, so you don't have to worry about the various issues associated with them, and you've eliminated the issue with powering off the device while it's running.

Re:Woah! Overkill!

[zoloto]

www.damnsmalllinux.org and a Compact FLASH to IDE Adapter. install it, make no swap, point all logs to /dev/null and adjust as neccicary.

bingo, I did this with spare parts sans iso reauthoring in less than an hour.

Re:Woah! Overkill!

[RevAaron]

There is a decent chance that a CF-card equipped setup would not be enough- though if it were my project, I'd rather have that than a hard drive. But, who knows- this guy may have a lot of photos, enough that it is a waste of money to go out and buy a 512 MB-4 GB CF card when he already has a laptop HD sitting around. I know that I have more than a 256 MB CF card of photos I'd like up if I were making one of therse things...

Re:Woah! Overkill!

[bmsleight]

I'd recommend building yourself a simple "run from RAM" setup using Knoppix (or something similar)

Try Morphix You take a basic image then just add a minimodule, using the mminimodule generator (See HowTos).

Then you have you operating system, and photos all on the CD. Very low power and if you have enought memory to hold all the photos in ram it will run cool.

thoughts, ideas...

[rusty0101]

since you are concerned about the mouse pointer, I presume you are running a full X implementation. Have you considered running this as a framebuffer applicaiton, and not loading X? fbv, fbi and DFBSee are all projects on Freshmeat that may provide you a way to bypass the running of X.

You could also do bootable CD-RWs that you can update the contents of your image library at any time, with any cdrw capable computer.

Just a couple thoughts to kick around.

-Rusty

Re:thoughts, ideas...

[WhiteDragon]

also, don't forget zgv...

Bootp

[ADRA]

If your On-board NIC supports it, run everything on another PC with BOOTP/NFS if you really want to. You'd be able to change everything on the fly.

Mind you, if everything's setup already, i'd just let it be.

Gentoo or Pebble?

[Anonymous Coward]

Red Hat seems really stuffy for this kind of thing...

I have some teeny boxes (Soekris 4501 and EPIA something) .. one uses Pebble (http://www.nycwireless.net/pebble/) and the other gentoo.

I'm not sure if Pebble has GUI or X stuff, but it is based on Debian. It is actually optimized for wireless use. It runs read-only off the CF card so it is safe to just cut the power. You can probably hammer that into shape.

Gentoo is something else I'm playing with, using distcc for compiling (i.e., no compiling on the local host, just over the network). The supercoolness of Gentoo is that you can build your own custom profile with all the settings and packages just the way you like them, and reinstall the whole thing from scratch whenever you want. Throw in a wireless card so you can pull the images off a server as well as locally and you've got a cool project.

Re:Gentoo or Pebble?

[mmonkey]

I second the Gentoo suggestion: it's remarkably adaptable. I run it on a P120 laptop with 24MB ram and not much HDD by NFS-mounting /usr/portage whenever necessary and distcc-ing the compiles to whatever else is switched on in the house at the time.

My thoughts for the picture-frame: absolutely compactflash and an IDE adapter; make it as read-only as possible so as not to wear-out the CF card (although they're not too expensive anyway).

Make a custom Gentoo install inside a chroot on a more powerful computer, and get it to cross-compile everything for you rpicture frame. Then just copy your new setup to the CF card, put it into the picture-frame, and you're good-to-go.

And yes, an EPIA seems like overkill...

Are you using a TFT? What sort, how much, and where from?

A distro? for this?!!

[zcat_NZ]

Take any one of the single floppy rescue bootdisks.

Add a copy of "zgv" (statically compiled, or you'll need to include vgalib and jpeglib)

Write a script that launches zgv with the appropriate parameters. Once you know it works, reinstall lilo so that your script gets run as init.

Total footprint will be perhaps two meg. Make an 'installer' for Linux or windows that dumps this at the start of a bootable CD and then lets the user fill the rest with pictures?

If you really have to have the fancy screen-merges and stuff, you can make up a system with JUST the linux kernel, XFree86, xscreensaver, and the very few libs that these depend on, basically the same way.

Re:A distro? for this?!!

[phorm]

Have you seen any pre-makes for this that are easily configurable? I've got a base system with most files in bzip'ed format... would like a small CD-bootable GUI that would allow for the user to choose various options during the install to unzip/configure the various packages.

Re:A distro? for this?!!

[zcat_NZ]

You want me to build this for you?

Am I getting paid?

I did have another thought about this; base it on damn small linux. It's a 50M bootable CD image which probably includes xscreensaver already.

That gives you a nice GUI and some basic toolkits for doing menus (I think it includes python, etc), leaves 600+M for images, and it designed to run from a read-only filesystem, so you don't need to worry about shutting down cleanly.

If you're serious about this hire a comp-sci student during the holidays, they can probably throw the thing together in a couple of days.

Re:A distro? for this?!!

[phorm]

Nay, Nay... having somebody else build it would take away all the fun - I'm just looking for info on how others got started :-)

I've used small CD distros such as "Timos rescue CD set" (no X11 though), but I've not tried Damn Small... though I think I remember hearing about it. I'll give that one a shot - thanks for the advice.

Corrupting the filesystem

[dougmc]

How would I go about booting from a ramdisk? This would make the 'powerwitch' kernel mod not so important since there is no worry of corrupting the file system.

Actually, booting off a ramdisk would have the same worries of corrupting the filesystem as booting off a hard disk. Well, I guess it depends on what kind of ram disk you're referring too -- flash ram would have the same problem, but a ram disk that's loaded from boot media at bootup would not.

What you probably want to do is just never open the disk for read/write access -- make it read only. Then you can turn it off at will with no problems, because the disk is never written to.

Slackware?

[dimss]

You can use minimal Slackware installation without Gnome and KDE. You need only X, Gtk and image viewer like qiv. You don't need even window manager. Simply put images to root window.

There must be only one rw filesystem for images. Use ReiserFS (or any other fs) in sync mode and don't care about proper shutdown anymore :)

Since there's no binary-only programs, one can use the same do-it-yourself approach almost on any hardware supported by Linux or NetBSD.

Re:Slackware?

[RdsArts]

GTK? WTF?

Grab eFiji. It's a small, slightly buggy root window image setter I wrote as a random background setting program. No GTK, no big requirements, just X11 and ImLib. Hell, you could probably find one that's been maintained more that'd do the same job.

This is funny

[Anonymous Coward]

Building a picture frame out of a computer more powerful that the early supercomputers.

Next we should make an WiFi enabled toothbrush that can run SETI@Home when idle.

Picture frame with Media reader & NAS

[TheMysteriousFuture]

I've been considering building a Digital Picture frame also.

I want to be able to insert my CF (SmartMedia, MMC, etc) Card into a "52,000-in-one" USB reader, hit a Transfer button and have the images transfered to my RAID'ed network attached storage (probably a samba share). Then have the option to erase the CF card

Have files renamed based on the EXIF information imbedded in the JPEG headers when they are transfered to the storage server
(for example, 2004-05-25_021544b YYYY-MM-DD_HHmmss and if that already exists append a letter), or perhaps the creation date of the image file depending on how hard it proves to read the EXIF info.

A simple interface to go through the pictures would be nice (not sure exactly what's already out there)

I was thinking something along the lines of Hardware buttons along the bottom of the frame, one each for going forward and back a year, month, day, and then per image.

Also maybe a dial to vary the speed of the slide show mode, and a "bookmark image" button...hrm yeah that'd be nice.

The general idea is to end up with a device that even grandma can use to view her pictures, and stick her camera card in and hit one button to transfer the pictures to a automagically backed up, raid'ed server.

Does this sound doable (without an insane amount of work :p)? Anybody have any sugestions, comments, want to tell me I'm an idiot, etc?

Some Rights Reserved, (C) 2004 TheMysteriousFuture

Re:Picture frame with Media reader & NAS

[wimbor]

Well, If you are planning to do all that, I would at a touch screen LCD instead of normal buttons. Nicer design... :-)

Good Luck!

Re:Picture frame with Media reader & NAS

[TheMysteriousFuture]

The thing is I have a bunch of old laptops laying around (who doesn't) which I can just fold the screen back on it self and build a frame around it.

But if I need a touch screen then I have to use a Mini-itx board ($$$) and the touch screen ()

I was figuring if I used hardware buttons it wouldn't be too hard to hook them up to the parallel port or something like that.

Perhaps I should could remove the eraser style mouse pointer from the keyboard and attach it to the frame...Thing is I'm trying to go for simplicity and those stupid things are hard to use.

Re:Picture frame with Media reader & NAS

[TheMysteriousFuture]

As far as planning to do all that, What I mentioned is just what I thought would be nice. I doubt most of it will happen.

The main thing that is important to me is the insert CF card and hit the BIG RED BUTTON(TM) to transfer to NAS. "Should" be doable with shell scripts I reckon. Never done shell scripting so we'll see how it goes :p

Re:Picture frame with Media reader & NAS

[commanderfoxtrot]

I've had some experience with hardware buttons. It's fairly easy to use the control lines on the parallel or serial ports, but it is far easier to adapt a standard keyboard.

If you have the space, just pull a key off the keyboard and wire in a switch instead. Or, you can do what I have done and just rip the keyboard controller out of the case; they are very simple devices really.

Geexbox

[webhat]

GeexBox has a similar feature.

http://www.geexbox.com

Re:Geexbox

[webhat]

So I'm an idiot, it's http://www.geexbox.org/.

I know: (Use the Preview Button! Check those URLs!)

My Pictureframe

[superid]

I started down this same road shortly after seeing the /. article mentioned by the poster. I have nearly identical hardware too with an EPIA 800 and a laptop drive. Since drive space and memory were not at a premium I decided to not go with an anorexic installation but rather just a trim one.

I chose to use Fedora. I did not load X Windows and instead used fbv from an autologin console. I found it very useful to have lots of console tools (lynx, wget, gcc) available to me. And basically there was no benefit in trying to trim disk usage by a few hundred Meg.

You might give Damn Small Linux a try

[LWATCDR]

It is a small 50meg linux distro. You could get rid of a lot of the apps and get it down even smaller. Are you including a network connection> you could then use you network drive to store the pictures.

ROCK Linux

[cbcbcb]

Configure and cross-compile a customised installation using Rock Linux http://www.rocklinux.org/

If you had purchased an i-Opener instead

[drinkypoo]

Then you would have had a 10" TFT LCD, 16MB flash which you could put M4I or Jailbait Linux into, and it would have come with an application to do picture frame stuff, M4I supports some usb wifi nics, and it would have been like $99 for the unit itself.

Tell you what, I have an i-Opener with a USB hub and a 3com USB 10/100 TP NIC, I'll trade you for your setup. If you have an LCD to go with it, that is.

IMO you should look into USB boot capabilities in your hardware. Then you should pick up the cheapest USB flash drive you can find for your system (get it from someplace with a good return policy in case for some reason you can't boot from it) and just stick a linux kernel with autoconfiguration on the flash drive and load it however... lilo, grub, freedos with loadlin, whatever. Then mount root on nfs someplace, you don't need much of linux.

I'd start with Jailbait or M4I, they're both extremely minimal systems that do this kind of thing. Then build the kernel that suits your needs and you're off and running. I'm getting ready to roll my own autoconfiguring kernel for my i-Opener because I want a dramatically newer X server than what comes with M4I and I have a linux system that is always running.

One small tip for the beginner :)

[in10d]

Currently, I'm using Red Hat 9 with GDM autologin...
You can drop GDM and its autologin.
RTF:
man xinit
man su
( hint: su - anon xinit session )

Puppy Linux

[agendi]

Puppy linux might be what you're looking for (the flash version).. then again maybe it isn't. Your mileage may vary - good luck

eMoviX/MoviX

[t4k1s]

eMoviX/Movix are minidistros which are focused on multimedia display. You can boot and and it'll show audiofiles and movies which are on the same medium. I assume it can also show pictures, but haven't tried it though... I could be interesting as it is rather small and they describe setting up CompactFlash in their tutorials/docs.

Re:eMoviX/MoviX

[t4k1s]

Oh yes, and basically, it is based on Linux and MPlayer and displays using the framebuffer device (so no X needed). MoviX2 uses X though and has a bigger footprint.

Damn Small Linux

[GamerGeek]

http://www.damnsmalllinux.org/

50 meg live cd, based on knoppix/debian
It can be installed on as little as a 250-300MB drive.
At one point they had people who sucessfully installed in on a 486-33? 66? something like that. It has xzgv which should do the picture viewing you want.

save yourself the headache

[Anonymous Coward]

get one of these and hook it up to a LCD that has video inputs.

Linux might be overkill...

[gozar]

I recently finished putting together a digital picture frame. I bought an old IBM thinkpad from eBay ($10) and a power adapter (another $10 from eBay).

This is a 486 with 2 MB of ram and only a floppy drive. A DOS boot disk boots the machine, sets up a ramdisk, copies the pictures to the ramdisk, and then runs a slideshow with pictures from the ramdisk. Totally silent and heat issues are non-existant.

I haven't had time, but I'm just going to make up a couple of disks with different categories of pictures. A nature disk, family disk, etc. I just have to reboot the machine when I want to a different category. I resize all the pictures to 640X480 (resolution of the screen) so they are pretty small (50k) and I can fit quite a few on a floppy.

My next project will be to wire a timer into the display switch that detects movement. Once movement is detected it switches on the display for a preset time. That way I don't have to worry about the screen being on for the 16 hours a day I'm at work or asleep.

My biggest complaint is that I didn't do my research on the laptop. The passive matrix screen really blows.

Other Options

[seanyboy]

Why the reliance on Linux. FreeDos should fit into 2 Mb, and (according to the interweb) DVPeg will fit into 120k. No network support, but it'll be really simple to set up.

Damn Small Linux

[mschiller]

I used Damn Small Linux for my picture frame. I took his debian package list and liberal use of the rm command to strip it down to a command line only version. Then I found a frame buffer picture viewer [with slideshow mode]. The os weighed in at about 20MB, so even a 64MB or 128MB CF card was plenty for a decent amount of pictures (remember to prescale them to screensize to save space). The OS also implements Wireless support for a Symbol CF card Wireless card. Since my target had a two CF slots (one of which was bootable).. With Samba client installed. I made everything work off a FAT filesystem so if I was being lazy I could pop it directly into my WinXP computer or even my digital camera (see note about prescaling the images to size though, saves processor time and disk space!) I could probably scrounge up the disk image if you wanted to start from my work... Though not sure I have the image with the development tools installed still to add/remove stuff. So if you wanted full flexibility you'd want to start from Damnsmall and work back.. Knoppix is definitely your friend here, but I'd start with something already on the small size, so you aren't removing Openoffice etc... -- Matthew

wrong RAMdisk

[phorm]

Actually, I think that what he's probably talking about is a ramdisk similar to the ones used by knoppix. Essentially it's a section of memory initialized with a filesystem and mounted as a drive. Kernel initrd (Initial Ramdisk) is basically that in that part of the kernel is uncompressed from an image into a small "ramdisk."

Basically the way you would work this is to have the base kernel/system loaded off a hard-disk/card/CD, and put all your working space in memory. Again, bootCD's often use this approach to have writable "space" even without a physical disk present. And of course, since the RAM is cleared on reboot, so is the RAMdisk.