In reply to Jiri Baum - I think we need to distinguish between a purely "embedded" installation, and one which is more like a traditional "PC".

The practical difference between the two situations is that an embedded version of an OS is typically put together specifically for that hardware, while a PC version may simply be adapted from a desktop OS distribution.

I decided to conduct a few experiments to measure installed size of a destop OS, and came up with the following. Each experiment was conducted as a fresh install onto a hard drive using the standard installer. The distribution used was one of the heavier ones (Mandrake), so the numbers likely form an upper bounds rather than typical values.

The installation software offers several automatic options for installation. For each experiment I selected each of these in turn without attempting to customise the installation by excluding or including particular packages. The result probably includes some unnecessary software, but I wanted to see what could be done without too much effort.

1) Basic install as "KDE workstation" - 726 MB.

2) Basic install as "Gnome workstation" - 593 MB.

3) Basic install as "Other graphical enviroments" (Window Maker) - 501 MB.

4) Minimal install with X (IceWM) - 374 MB.

5) Console mode install only - 116 MB.

6) As a comparison, my normal installation has 2900MB of software (and documentation) installed.

A few additional observations are:

A) All the installations (except for console mode) included the GTK libraries by default. This means for example, that "KDE workstation" includes GTK as well as QT. We should not therefore conclude that KDE is necessarily larger than Gnome. I believe that the configuration and package management software uses GTK, which is what creates this dependency.

B) All of the above included several applications. They are not a bare OS and GUI installation. I didn't make any attempts to exclude any software. The above sizes could be trimmed down quite a bit by removing unused software.

C) All of the above included Perll, which I believe is used by the configuration and package management software. All except the console mode version included Python. The relevance of this is that if the intended application were to use Perl or Python, the sizes of these are already
included in the above figures.

The above is "as installed", and so cannot be compared directly to a compressed ISO. However, it is worth noting that DSL (Damn Small Linux) is about 50MB as an ISO. Usefull embedded systems can be made with less than 10MB.

On the other hand, the distribution I used for my experiments is noted for including a lot of software - this is one of its selling points. This means there would have been little effort made to trim it down for a minimal
install.

My conclusion is that if you are looking to create a light weight "PC" style installation (as opposed to an embedded system), it is probably better to start with a small distribution and add to it, than it is to start with a large one and try to take things out. One which accepts Debian packages might be the most promising approach as it would still allow you to add whatever you needed that wasn't included in the base install.

 

There is nothing wrong with a plastic case in the right application. What I call an "industrial style" case would be one that mounts in a machine easily. For something that should go inside an electrical panel, the case should mount on edge on a DIN rail, with the board connectors facing out . The main job of the case would be to project the board from damage from handling. or from short circuits due to accidental contact.

In low volumes though, getting a custom aluminum case fabricated would likely be cheaper than plastic. It would probably give better heat dissipation characteristics as well.

For non-DIN rail shelf mount applications though, I've seen an interesting mini-ITX case that has a 2 line by 20 character display, about a dozen keys, and slot for a flash card in the front. The connectors are on the back. It has some interesting possibilties though if it can be mounted somehow (perhaps sitting in the open if the enviroment is fairly clean). The display and keypad would allow some basic message display and configuration to take
place without needing to hook up a conventional monitor and keyboard. It could be useful for applications where you want to load the software by plugging in the memory card, and then set some basic parameters via the keypad and display. It might not be the best for a PLC type application, but it could be useful for applications like the printer interface we discussed a few weeks ago.

 

> Linux? Maybe... <

Straight from the horses mouth, and the recovery disk boots into Linux. I'm not sure how old the design is but the Perfect Binder is new.

> I'm probably 4-5 years out of date, but Heidlelberg's 'Sunday 3000'
> presses are (were?) run by multiple QN/X systems networked together.
>
> The printing plants I've been in _never_ ran any equipment based on MSWindows. <

Uptime requirements are too stringent on the presses to even consider Windows. And a crash on a large press does a lot of damage. I think our Sunday 2000 is all PLC exclusive of display. I've seen OS/9 and a few proprietary RTOS but the press folks are pretty conservative. The jobs
sometimes run for a week or more non-stop which is pretty impressive considering how much stuff is moving precisely and how many miles of paper are consumed.

> On May 8, 2005, Curt Wuollet wrote:
>>That sounds like PC control to me. And I'd love to hear why they
>
> didn't just use the NT:^) <
>
> Ask them -- I asked at a plant in Minnesota. You would enjoy their answer. <

I've always admired the engineering, sanity prevails.

Regards

cww