I have nothing against the Mac. In my experience with embedded platforms (which is not a lot), I've noticed that the issue with them is to find a platform that fits your specification like a glove without any extraneous features to bloat your price point. Very often we spend a lot of time making the hardware cheaper.
Now this is not true of defense related projects, where cost is never an issue. But in manufacturing even a few dollars can shave a whole lot off your price. So just having a platform with oodles of RAM and processing power is does not qualify the device for an embedded application.
You need a real time clock, a watch dog, non-volatile RAM (instead of hard-drives which depend on moving parts), no fans, etc.
Does the Mac mini give you these? Remember most embedded applications are generally computers that have been programmed to do a few tasks and to do them very well, with minimal failures and no human interaction.
Has anybody had any luck with Lutron? http://www.lutron.com/. According to some of the home automation dealers I've spoken to, their network is proprietary but it allows you to use wired devices in new constructions, wireless devices in retrofit constructions and a combination of the two if you really want it.
The Intel 386 processor implements protection bits in their segment descriptors. The OS can use this to mark a segment for read, write, execute or any combination, thereof. Windows, like a lot of Unix implementations, does not leverage the benefits of proper segmentation on the i386.
Each process is given 1 segment that is logically segregated into executable space and heap space. Since each process has a different segment, one cannot overwrite another -- voila! better inter-process separation and reliability (first seen in winnt for Windows).
To prevent a buffer overflow that results in the execution of malicious code, we need to separate the data and the executable code within a process. In order to implement this correctly, MS would have had to use more than one NON-overlapping segment. The code segments would have to be marked for execution/read only, while multiple data segments would have to be marked for read/write only. If this were done, the processor would raise an exception when a non-executable segment descriptor was loaded into the CS (code segment register). If the application/malign software tried to read/write to a code segment, which was did not have the read/write bits set, the processor would raise an exception. If the code and data segments pointed to non-overlapping regions in memory, code segments could be setup to prevent write access. The use of properly marked segments gives you tremendous power over what can be executed and what can be changed.
Windows uses virtual pages extensively and has separate pages for code and data. I bet that the NX bit that is mentioned in previous comments is a modifier for the page register. The i386 does not support execution protection at the page level. The i386 expects the OS to use segments properly to partition the logical address space (4GB most of which does not map to physical hardware), and page registers to implement virtual memory in limited physical memory.
Windows does not wield the power of segmentation correctly. We should not blame intel for it.
(Note: I am not in any way affiliated with Intel, though I did look for a job there when I got out of college.)
Slashdot Mirror
I have nothing against the Mac. In my experience with embedded platforms (which is not a lot), I've noticed that the issue with them is to find a platform that fits your specification like a glove without any extraneous features to bloat your price point. Very often we spend a lot of time making the hardware cheaper.
Now this is not true of defense related projects, where cost is never an issue. But in manufacturing even a few dollars can shave a whole lot off your price. So just having a platform with oodles of RAM and processing power is does not qualify the device for an embedded application.
You need a real time clock, a watch dog, non-volatile RAM (instead of hard-drives which depend on moving parts), no fans, etc.
Does the Mac mini give you these? Remember most embedded applications are generally computers that have been programmed to do a few tasks and to do them very well, with minimal failures and no human interaction.
-- Arya
Has anybody had any luck with Lutron? http://www.lutron.com/. According to some of the home automation dealers I've spoken to, their network is proprietary but it allows you to use wired devices in new constructions, wireless devices in retrofit constructions and a combination of the two if you really want it.
The Intel 386 processor implements protection bits in their segment descriptors. The OS can use this to mark a segment for read, write, execute or any combination, thereof. Windows, like a lot of Unix implementations, does not leverage the benefits of proper segmentation on the i386.
Each process is given 1 segment that is logically segregated into executable space and heap space. Since each process has a different segment, one cannot overwrite another -- voila! better inter-process separation and reliability (first seen in winnt for Windows).
To prevent a buffer overflow that results in the execution of malicious code, we need to separate the data and the executable code within a process. In order to implement this correctly, MS would have had to use more than one NON-overlapping segment. The code segments would have to be marked for execution/read only, while multiple data segments would have to be marked for read/write only. If this were done, the processor would raise an exception when a non-executable segment descriptor was loaded into the CS (code segment register). If the application/malign software tried to read/write to a code segment, which was did not have the read/write bits set, the processor would raise an exception. If the code and data segments pointed to non-overlapping regions in memory, code segments could be setup to prevent write access. The use of properly marked segments gives you tremendous power over what can be executed and what can be changed.
Windows uses virtual pages extensively and has separate pages for code and data. I bet that the NX bit that is mentioned in previous comments is a modifier for the page register. The i386 does not support execution protection at the page level. The i386 expects the OS to use segments properly to partition the logical address space (4GB most of which does not map to physical hardware), and page registers to implement virtual memory in limited physical memory.
Windows does not wield the power of segmentation correctly. We should not blame intel for it.
(Note: I am not in any way affiliated with Intel, though I did look for a job there when I got out of college.)
Shift + Right Click to get the Run As.. menu.