Tek DPO/MSO/MDO easter egg?

[Lukas]

Just for fun, I did some research on the firmware for the Tek DPO/MSO/MDO4000 'scopes. It basically is an ext2 image which contains the updater stuff, the kernel an the actual filesystem (squashfs). In the latter, I found the directory /usr/share/egg which contains some funny images, eastereggs obviously. The file names appear in the 'scope app, so there should be a way to activate the eastereggs. Has anyone figured out, how to do so?

BTW: There seems to be a relationship between the sluggishness of embedded devices an the use of linux...

[free_electron]

Make that ' a badly implemented linux'...
Linux can be fast. I have seen systems that boot in under half a second. But that requires a lot of work and know-how to set up.

Sadly, developing with linux as typically approached as 'slap it on'.

Here is a simple example of improvement that makes a tremendous difference.
Most linux systems halt during boot until they get an ip address or time out... Just the fact that no network cable is plugged in costs you 3 to 4 seconds ( if not more ). Setting timeout to zero , or running that in a separate thread gives the user a totally different perception of speed.

For a scope the network can come online once the main app is running and busy initializing the hardware.

Too many things are dynamically loaded. Every time you power up all the work is done over and over. There are versions that are statically built. It's like restoring a virtual machine. A small bootloader decompresses the image to ram , sets up the working environment and off it goes. You don't need anything dynamic in embedded systems like scopes. The hardware never changes. Nothing can be installed, changed or removed. There are no plug-in slots.

Problem is , making a static build is not easy. There are companies specializing in that but that costs money. The main motive of using linux is that its free. Free as in zero-paid...  Windows costs them 150$ a licence . Same for vxworks or anything else: money money money. And people that know how to code for  or a real embedded os need to be paid more than a pfy which will hammer out some linux code. Those you find on the corner of every street.  ( for people not knowing what a pfy is: go read simon travaglias columns on theregister. The ones about the bofh... Pfy = pimply faced youth . )

[Monkeh]

BTW: There seems to be a relationship between the sluggishness of embedded devices an the use of linux...

And a link between the unreliability and limited function of embedded devices and the use of VxWorks.

[Lukas]

Much of today's test equipment has a soft power switch. Turning off the instrument leaves oscillators and references and some other precision stuff powered. It would be logical to send the OS into some sort of suspend to RAM. I'm wondering why nobody does that...

[Monkeh]

Much of today's test equipment has a soft power switch. Turning off the instrument leaves oscillators and references and some other precision stuff powered. It would be logical to send the OS into some sort of suspend to RAM. I'm wondering why nobody does that...

Probably because it's a lot of effort to ensure their code can handle that. And the ancient 'embedded linux' packages they buy probably aren't even capable of it.

If they did things properly there wouldn't even be any point, the entire OS could be loaded and running in a matter of seconds.