Dombo <invalid@invalid.invalid> writes:

> jebblue wrote:
>> On Sun, 03 Aug 2008 21:39:06 +0200, Dombo wrote:
>>
>>
>>>Yeah, also Linux is not that a great choice in the reliability
>>>department, have seen more kernel panics than I care to remember. On the
>>>upside not many exploits will work on a Linux based solution.
>>
>> Kernel panics? What's that? 

When I moved my linux system onto a new motherboard, it started to
boot OK - then I saw my first kernel panic.

I was very disappointed with the supposedly "reliable" linux - until I
noticed I had left the heatsink off the CPU and it was starting to
smoke :)

> A kernel panic is the Linux equivalent of the blue screen of death of
> windows


-- 

John Devereux

jebblue wrote:
> On Sun, 03 Aug 2008 21:39:06 +0200, Dombo wrote:
> 
> 
>>Yeah, also Linux is not that a great choice in the reliability
>>department, have seen more kernel panics than I care to remember. On the
>>upside not many exploits will work on a Linux based solution.
> 
> Kernel panics? What's that? 

A kernel panic is the Linux equivalent of the blue screen of death of 
windows

> I've got Linux running on a variety of
> hardware, embedded to PC's and that isn't something I see.

Good for you. However I have seen quite a few for example when stressing 
the USB bus (this one eventually got solved), certain video cards and 
with the S3 mode.

On Sun, 03 Aug 2008 21:39:06 +0200, Dombo wrote:

> Yeah, also Linux is not that a great choice in the reliability
> department, have seen more kernel panics than I care to remember. On the
> upside not many exploits will work on a Linux based solution.

Kernel panics? What's that? I've got Linux running on a variety of
hardware, embedded to PC's and that isn't something I see.

-- 
// This is my opinion.

On Mon, 4 Aug 2008 11:51:39 -0500, "MikeWhy"
<boat042-nospam@yahoo.com> wrote:

>"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message 
>news:n1e*rHCjs@news.chiark.greenend.org.uk...
>> MikeWhy <boat042-nospam@yahoo.com> wrote:
>>> What a generally ignorant thing to say. These are examples of bad drivers
>>> in the first instance, bad application code in the second instance, and
>>> preemptive coverup of likely leaky RAD systems in the third instance. 
>>> None
>>> of these are problems of the OS. Are you claiming that Linux is somehow
>>> immune to development errors?
>>
>> My personal experience comes from Windows 2003 Servers as batch build 
>> boxes
>> on HP hardware using HP recommended versions of drivers with no thirdparty
>> drivers or system level software installed.
>>
>> We have found that we have to preemptively reboot them once a week 
>> otherwise
>> the incidence of "weird things" happening increases to levels which impact
>> on our build success rates. On the other hand most of our Linux boxes have
>> been up for hundreds of days without problems.
>>
>> Any embedded system need the ability to monitor itself and restart. 
>> Generally
>> you need hardware and software watchdogs, defensive coding and the ability
>> for the system to do something sensible in the case of catastrophic error.
>>
>> Regrettably I see far more Windows based embedded system which have "bad
>> drivers" "bad application code" and "leaky RAD systems" than embedded
>> systems based on other OSes.
>>
>> For example most theatrical lighting desks are embedded computers. People
>> don't like them to fail mid show, audiences tend to get upset. Strand, 
>> which
>> was the market leader for many used a protected mode environment using DOS
>> as a bootloader. Other companies tend to use things like VxWorks or QNX, 
>> or
>> how brewed RTOSes. There is approximately one XP Embedded based desk in 
>> the
>> market and very few people trust it as too many people have had it crash 
>> or
>> weirdly freeze etc.
>
>In the search for truth, the simpler answer usually prevails. I would 
>suspect application error and inadequate testing more readily than I would 
>accept excuses that the platform is fundamentally flawed. I've seen the 
>reverse situation as well. My Linux-based Toshiba DVD player reboots 
>occasionally during playback. Should I conclude that this reflects a 
>limitation of embedded Linux?

I do not know about Vista, but any other member of the Windows NT
family can run for months or even a year or two without a reboot,
provided that you are careful what hardware and software you are
using. 

A very large application package has been used on various platforms
(including Windows NT family) for more than a decade. On WinNT the
applications run in several console windows, the keyboard, mouse and
display are used only for maintenance and diagnostics and usually a
KVM switch is used to maintain multiple systems. Any loadable storage
devices (floppy/USB) are disabled and the system is running
stand-alone or with very strict firewall protection to the next well
protected area. The applications do not in general use malloc/free so
there are no dynamic memory fragmentation issues. New software and
hardware are typically tested for months before being released.

So it is definitively possible to run WinNT systems without reboot for
a very long time if you can accept such limitations.  

Paul

In article <4uGlk.6300$np7.5702@flpi149.ffdc.sbc.com>, boat042-
nospam@yahoo.com says...
> "Paul Gotch" <paulg@at-cantab-dot.net> wrote in message 
> news:n1e*rHCjs@news.chiark.greenend.org.uk...
> > MikeWhy <boat042-nospam@yahoo.com> wrote:
> >> What a generally ignorant thing to say. These are examples of bad drivers
> >> in the first instance, bad application code in the second instance, and
> >> preemptive coverup of likely leaky RAD systems in the third instance. 
> >> None
> >> of these are problems of the OS. Are you claiming that Linux is somehow
> >> immune to development errors?
> >
> > My personal experience comes from Windows 2003 Servers as batch build 
> > boxes
> > on HP hardware using HP recommended versions of drivers with no thirdparty
> > drivers or system level software installed.
> >
> > We have found that we have to preemptively reboot them once a week 
> > otherwise
> > the incidence of "weird things" happening increases to levels which impact
> > on our build success rates. On the other hand most of our Linux boxes have
> > been up for hundreds of days without problems.
> >
> > Any embedded system need the ability to monitor itself and restart. 
> > Generally
> > you need hardware and software watchdogs, defensive coding and the ability
> > for the system to do something sensible in the case of catastrophic error.
> >
> > Regrettably I see far more Windows based embedded system which have "bad
> > drivers" "bad application code" and "leaky RAD systems" than embedded
> > systems based on other OSes.
> >
> > For example most theatrical lighting desks are embedded computers. People
> > don't like them to fail mid show, audiences tend to get upset. Strand, 
> > which
> > was the market leader for many used a protected mode environment using DOS
> > as a bootloader. Other companies tend to use things like VxWorks or QNX, 
> > or
> > how brewed RTOSes. There is approximately one XP Embedded based desk in 
> > the
> > market and very few people trust it as too many people have had it crash 
> > or
> > weirdly freeze etc.
> 
> In the search for truth, the simpler answer usually prevails. I would 
> suspect application error and inadequate testing more readily than I would 
> accept excuses that the platform is fundamentally flawed. I've seen the 
> reverse situation as well. My Linux-based Toshiba DVD player reboots 
> occasionally during playback. Should I conclude that this reflects a 
> limitation of embedded Linux?

In my 'limited experience' ALL platforms have problems.

However I tend to find that MS Windows platform and applications
have what is sometimes classed as 'consumer grade' (that is being 
unkind to consumer grade), applications and drivers.

Boss sees he can get Windows 'programmers' ten a penny, so chooses
Windows and gets more sloppy practices and so called 'professionals'
who are normally "more worried about the paint job, than the engine".
Internal politics drive the product development not the spec (if there
ever was one). Then the products get sold into places where the customer
worries about the brand name and contract and rarely checks the specs
or test the items. Then the items become the 'inhouse standard'.

Seems a lot of equipment is going this way to drive down costs at the 
front end not the back end (selling to consumer). too many companies
always trying to be first with the next great thing that nobody actually
NEEDS!

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message 
news:n1e*rHCjs@news.chiark.greenend.org.uk...
> MikeWhy <boat042-nospam@yahoo.com> wrote:
>> What a generally ignorant thing to say. These are examples of bad drivers
>> in the first instance, bad application code in the second instance, and
>> preemptive coverup of likely leaky RAD systems in the third instance. 
>> None
>> of these are problems of the OS. Are you claiming that Linux is somehow
>> immune to development errors?
>
> My personal experience comes from Windows 2003 Servers as batch build 
> boxes
> on HP hardware using HP recommended versions of drivers with no thirdparty
> drivers or system level software installed.
>
> We have found that we have to preemptively reboot them once a week 
> otherwise
> the incidence of "weird things" happening increases to levels which impact
> on our build success rates. On the other hand most of our Linux boxes have
> been up for hundreds of days without problems.
>
> Any embedded system need the ability to monitor itself and restart. 
> Generally
> you need hardware and software watchdogs, defensive coding and the ability
> for the system to do something sensible in the case of catastrophic error.
>
> Regrettably I see far more Windows based embedded system which have "bad
> drivers" "bad application code" and "leaky RAD systems" than embedded
> systems based on other OSes.
>
> For example most theatrical lighting desks are embedded computers. People
> don't like them to fail mid show, audiences tend to get upset. Strand, 
> which
> was the market leader for many used a protected mode environment using DOS
> as a bootloader. Other companies tend to use things like VxWorks or QNX, 
> or
> how brewed RTOSes. There is approximately one XP Embedded based desk in 
> the
> market and very few people trust it as too many people have had it crash 
> or
> weirdly freeze etc.

In the search for truth, the simpler answer usually prevails. I would 
suspect application error and inadequate testing more readily than I would 
accept excuses that the platform is fundamentally flawed. I've seen the 
reverse situation as well. My Linux-based Toshiba DVD player reboots 
occasionally during playback. Should I conclude that this reflects a 
limitation of embedded Linux?

On Aug 3, 3:56 pm, Dombo <do...@disposable.invalid> wrote:

> It depends on the nature of your device, but you will never be
> absolutely safe, certainly not with Windows XP, even if you do update
> regularly. But you could improve safety a lot when let your application
> run under a user account with minimum privileges, optionally in a
> sandbox (e.g.http://www.sandboxie.com). You could also use a less
> popular OS to reduce the chance you device gets affected by some kind of
> exploit.

You can also boot your device from read-only media, and have a
clockwork timer that
does this every morning at 1am.  Or if you use fast booting tricks,
perhaps even after every usage.

But of course that means you can't do remote updates.  Or you can make
something that can be written to, but only by a tricky sequence of
events to unlock the hardware (programmable logic gate keeper) that's
done by code that's only downloaded to the device during an update.
This is attackable by someone who spies on and update cycle, but not
casually by running generic scripts using known O/S vulnerabilities.

MikeWhy <boat042-nospam@yahoo.com> wrote:
> What a generally ignorant thing to say. These are examples of bad drivers
> in the first instance, bad application code in the second instance, and
> preemptive coverup of likely leaky RAD systems in the third instance. None
> of these are problems of the OS. Are you claiming that Linux is somehow
> immune to development errors?

My personal experience comes from Windows 2003 Servers as batch build boxes
on HP hardware using HP recommended versions of drivers with no thirdparty
drivers or system level software installed.

We have found that we have to preemptively reboot them once a week otherwise
the incidence of "weird things" happening increases to levels which impact
on our build success rates. On the other hand most of our Linux boxes have
been up for hundreds of days without problems.

Any embedded system need the ability to monitor itself and restart. Generally
you need hardware and software watchdogs, defensive coding and the ability
for the system to do something sensible in the case of catastrophic error.

Regrettably I see far more Windows based embedded system which have "bad
drivers" "bad application code" and "leaky RAD systems" than embedded
systems based on other OSes.

For example most theatrical lighting desks are embedded computers. People
don't like them to fail mid show, audiences tend to get upset. Strand, which
was the market leader for many used a protected mode environment using DOS
as a bootloader. Other companies tend to use things like VxWorks or QNX, or
how brewed RTOSes. There is approximately one XP Embedded based desk in the
market and very few people trust it as too many people have had it crash or
weirdly freeze etc.

-p
-- 
"Unix is user friendly, it's just picky about who its friends are."
 - Anonymous
--------------------------------------------------------------------

"Paul Gotch" <paulg@at-cantab-dot.net> wrote in message 
news:VWi*Nfyjs@news.chiark.greenend.org.uk...
> I've seen far too many airport and railway displays with blue screens of
> death on them and far too many ATMs and ticket kiosks with modal error
> dialog boxes on them to ever think Windows is a good idea in an embedded
> situation.
>
> Not to mention the Windows based self service checkouts at my local 24 
> hour
> Tesco which reboot themselves at 1am every day.

What a generally ignorant thing to say. These are examples of bad drivers in 
the first instance, bad application code in the second instance, and 
preemptive coverup of likely leaky RAD systems in the third instance. None 
of these are problems of the OS. Are you claiming that Linux is somehow 
immune to development errors?

On Sun, 03 Aug 2008 09:34:02 -0500, Legrandin
<dawpeelsiq@farifluset.mailexpire.com> wrote:

>Hi,
>
>Have you had any experience with WinXP Embedded?
>
>I am considering it for a new kiosk-like project,
>for a FLASH based device, but I am mostly concerned
>about the security aspect.
>
>Tipically, WinXP requires regular updates in order
>to be kept one step ahead the current exploits.
>Is it safe to keep it unpatched instead?
>
>Regards,
>
>Legrandin

Interesting answers so far. I have used both XP Embedded and Linux in
simiar situations. Regardless of what anyone here claims to be better,
both need to be patched for vunerablilities if they are to be network
attached. Leaving an unpatched OS is plain stupid and a security risk.

In saying that, a lot of functionality can be switched off in EMbedded
XP meaning there is a lot less requirement for patching. Same goes for
linux.

The security aspect is relevant to both linux and windows.