flat assembler
Message board for the users of flat assembler.

Index > Heap > Digital road sign - Runtime error

Goto page 1, 2, 3  Next
Author
Thread Post new topic Reply to topic
Picnic



Joined: 05 May 2007
Posts: 1288
Location: behind the arc
Picnic
Real photo, location city of Korinthos, Greece Razz

Image

original post
Post 19 Apr 2010, 15:47
View user's profile Send private message Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1154
ManOfSteel
I've seen many pictures exactly like that one and others with ATMs and airport or train-station screens displaying BSOD.

Well, I only hope your traffic lights don't run on Windows too! Shocked
Post 19 Apr 2010, 16:20
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
And to think, voting machines use windows...
Post 19 Apr 2010, 17:23
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
ManOfSteel



Joined: 02 Feb 2005
Posts: 1154
ManOfSteel
Bah, Windows-based voting machines = easily-hackable-by-design voting machines = easily riggable elections. Won't be the first time to happen.

But traffic lights?! No, THAT would be bad. I can't imagine Humanity going so low. It would really be PureEvil™.
Post 19 Apr 2010, 19:46
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4238
Location: 2018
edfed
if the hardware is under windows, it is maybe sure it is X86, then, it can be interresting to code specific stand alone applications for that hardwarre.

simply show it is possible to code efficient and secure standalone applications for X86, and the client will buy it more surelly than he buy a porsche cayenne. Very Happy

the market is still there ( how many X86 terminals are employed, for what applicatons?), we just have to take it.
Post 19 Apr 2010, 19:55
View user's profile Send private message Visit poster's website Reply with quote
Picnic



Joined: 05 May 2007
Posts: 1288
Location: behind the arc
Picnic
ManOfSteel wrote:
But traffic lights?! No, THAT would be bad. I can't imagine Humanity going so low. It would really be PureEvilâ„¢.

I have thought of a scenario like that, where a group of bad mood psycho/hackers group get traffic lights control on a big city.
I am not aware if this is possible, but it's gonna be a crazy and dangerous night, yes PureEvilâ„¢
Post 19 Apr 2010, 22:09
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
ManOfSteel wrote:
Bah, Windows-based voting machines = easily-hackable-by-design voting machines = easily riggable elections. Won't be the first time to happen.


Just imagine how many times this has happened without our knowing. The voting machines i've seen in my life time appear to use wireless networking. Windows aside, i heard about intel creating a new standard that will allow people on a LAN to remotely edit the RAM of a networked computer. I forget the name.

Quote:
But traffic lights?! No, THAT would be bad. I can't imagine Humanity going so low. It would really be PureEvilâ„¢.


IIRC, Germany uses Linux traffic lights.

EDIT: Now picture a small wifi device hidden in someone's pocket...
Post 19 Apr 2010, 22:18
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
ManOfSteel wrote:
Bah, Windows-based voting machines = easily-hackable-by-design voting machines = easily riggable elections. Won't be the first time to happen.
It is not the OS that matters, it is the motivation. Even terminals without any common OS, just a pure embedded single purpose app, have been hacked. Just see some history of casino machines being compromised. So even if you run Linux, or BSD, nothing, or anything, you will never be safe from motivated hackers.

However in this particular case, for this thread's topic, I don't think we can blame Windows (yeah, I know Windows fan blah blah blah). While it is easy and popular to blame the OS I think it is misplaced blame. Either the hardware being used is not rugged enough for the intended environment and gives errors, or the custom app/drivers is/are just plain written badly. Putting blame in the wrong place is not helpful towards actually solving the problem.

[rant] Too many times I have seen people blame the OS (any OS, not just Windows) for their crashes and errors only to later discover that they forgot to free memory, or the memory chip was bad, or some other non-OS failure. And blaming the OS only helped to direct attention in the wrong areas and impaired their ability to actually fix it. [/rant]
Post 20 Apr 2010, 03:34
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
revolution wrote:
ManOfSteel wrote:
Bah, Windows-based voting machines = easily-hackable-by-design voting machines = easily riggable elections. Won't be the first time to happen.
It is not the OS that matters, it is the motivation. Even terminals without any common OS, just a pure embedded single purpose app, have been hacked. Just see some history of casino machines being compromised. So even if you run Linux, or BSD, nothing, or anything, you will never be safe from motivated hackers.

However in this particular case, for this thread's topic, I don't think we can blame Windows (yeah, I know Windows fan blah blah blah). While it is easy and popular to blame the OS I think it is misplaced blame. Either the hardware being used is not rugged enough for the intended environment and gives errors, or the custom app/drivers is/are just plain written badly. Putting blame in the wrong place is not helpful towards actually solving the problem.

[rant] Too many times I have seen people blame the OS (any OS, not just Windows) for their crashes and errors only to later discover that they forgot to free memory, or the memory chip was bad, or some other non-OS failure. And blaming the OS only helped to direct attention in the wrong areas and impaired their ability to actually fix it. [/rant]


Well, let's not discredit the source of problems either. Programmers are run by managers, managers are run by promises. Windows advertises as the magic box, so managers expect programmers to assume that everything in windows works properly.

Now that aside, it's quite possible that the hardware is bad, but why? Why does hardware (the kind that run on more than just windows) crash more in windows than in other OSes? Remember, programmers are controlled by managers. Oh right, every manager knows of windows' blue screen to shut down the computer in any situation a bug arises. Therefore, the mangers tell programmers to use it now and they'll fix bad code when the time comes to save time and work on other features and side programs to use with the hardware. Which never does because they always move on to the next latest and greatest thing where the cycle repeats. Now, who gave them the method to abuse..?
Post 20 Apr 2010, 03:42
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
BSODs are mostly hardware driver problems or hardware signal integrity problems (bad RAM bus routing etc.). It has been many years since I've had a BSOD in any of my systems. Once I started to buy reliable hardware and used properly tested drivers all my problems went away.
kohlrak wrote:
Why does hardware (the kind that run on more than just windows) crash more in windows than in other OSes?
Are you talking percentage-wise or absolute numbers? Perhaps drivers in Windows are harder to get right? I don't know the answer to this question but I would be interested to find out if we can really blame Windows for this of if the problem exists in other areas. Certainly my experience with XP is all positive so far (once I got the proper hardware and drivers sorted out). But my experience is simply anecdotal, it is possible that I don't use some buggy feature that others use often and that they get problems I would never see. Perhaps *nix and BSD have simpler driver models making it easier for developers to write good drivers? I know that drivers in Windows have free roam over the whole system, but does *nix and BSD also allow this level of control with system drivers?
Post 20 Apr 2010, 04:07
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
BSODs are mostly hardware driver problems or hardware signal integrity problems (bad RAM bus routing etc.). It has been many years since I've had a BSOD in any of my systems. Once I started to buy reliable hardware and used properly tested drivers all my problems went away.


Please define how you identify "reliable hardware" and "properly tested drivers."

Quote:
Are you talking percentage-wise or absolute numbers?


Even less reliable statistics: Both personal experience and testemony. I have 2 machines, both of which have experienced plenty BSoDs but nothing of the like with Linux installed. I highly doubt Linux is the magical OS where everything works which windows pretends to be.

Quote:
Perhaps drivers in Windows are harder to get right?


Drivers are drivers. You know your hardware. How does the OS make them harder to get right, unless the code of the OS that the drivers use is unreliable?

Quote:
I don't know the answer to this question but I would be interested to find out if we can really blame Windows for this of if the problem exists in other areas. Certainly my experience with XP is all positive so far (once I got the proper hardware and drivers sorted out). But my experience is simply anecdotal, it is possible that I don't use some buggy feature that others use often and that they get problems I would never see.


I've also found the OS to have some interesting inconsistencies as well. Unfortunately, when the OS is closed source, it's not really that easy to ensure that there aren't rediculous issues like the droid autofocus bug where a timestamp of installing windows or something determines how well it functions. However, i have found many windows installs to be oddly inconsistent, even on the same computer (without viruses present to boot!).

Quote:
Perhaps *nix and BSD have simpler driver models making it easier for developers to write good drivers?


I can't see how. Especially when it comes to BSoDs... I can't see how it could possibly make sense where on *nix machines that drivers suddenly don't have to make the computer do an emergency shutdown like with the BSoD in windows.

Quote:
I know that drivers in Windows have free roam over the whole system, but does *nix and BSD also allow this level of control with system drivers?


I don't know for sure for drivers, but for other things these OSes have built their security on keeping programs and users from harming each other. Windows, on the other hand, even has a thing where programs can ask for permission to mess with the ram of other programs (Hooks anyone?).
Post 20 Apr 2010, 04:22
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
Please define how you identify "reliable hardware" and "properly tested drivers."
Oh, I thought this would self-evident.

Reliable hardware simply means hardware that does not give bad data to the CPU and does give good power supplies with stable voltages even under sudden load changes.

And properly tested drivers means that the drivers are run through series of tests under various real and simulated conditions to check the operation.

Cheap boards with the driver CDs (I'm sure we have all seen them) are not what I consider reliable hardware with properly tested drivers.

ECC capable and enabled boards with industrialised mobos and driver test spec sheets are what I consider reliable hardware with properly tested drivers.

Anyhow, does *nix even have a BSOD equivalent screen? What happens in *nix when you have a bad RAM chip? Does it just freeze, or auto-reboot, or what?

Another thing that is perhaps the cause is that Windows tends to have everything on by default (I guess this a consequence of the intended market). I think it is the general culture of *nix use that if you want something turned-on then you have to do it manually (I guess this also a consequence of the intended market)? I'm not sure there, just guessing.
Post 20 Apr 2010, 04:38
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
revolution wrote:
kohlrak wrote:
Please define how you identify "reliable hardware" and "properly tested drivers."
Oh, I thought this would self-evident.

Reliable hardware simply means hardware that does not give bad data to the CPU and does give good power supplies with stable voltages even under sudden load changes.

And properly tested drivers means that the drivers are run through series of tests under various real and simulated conditions to check the operation.

Cheap boards with the driver CDs (I'm sure we have all seen them) are not what I consider reliable hardware with properly tested drivers.

ECC capable and enabled boards with industrialised mobos and driver test spec sheets are what I consider reliable hardware with properly tested drivers.


Elaborate. Say i was to build a new computer right now from scratch using newegg.com. Give me an example piece of reliable hardware and unreliable hardware and how you went ahead and determined which is which.

Quote:
Anyhow, does *nix even have a BSOD equivalent screen?


Not that i know of. In theory, it shouldn't need it. If something becomes a problem, it should shut down that piece of hardware and make a note of it in the syslog and either start it up again or keep it off.

Quote:
What happens in *nix when you have a bad RAM chip? Does it just freeze, or auto-reboot, or what?


I've never had a bad chip to test, so i don't know. Embarassed

However, in my experience most BSoDs have been due to lazy graphic card programmers who take advantage of the BSoD's availability or due to an actual bug with windows (Remember the deadly MessageBox of death?).

Quote:
Another thing that is perhaps the cause is that Windows tends to have everything on by default (I guess this a consequence of the intended market). I think it is the general culture of *nix use that if you want something turned-on then you have to do it manually (I guess this also a consequence of the intended market)? I'm not sure there, just guessing.


Hardware wise, everything is pretty much turned on by default (out of the things it knows how to use) with most *nixes, at least the linuxes i've tested. As for features, it depends on the distro on whether or not things are turned on by default. I, personally, am lazy enough to use ubuntu so things tend to be turned on.
Post 20 Apr 2010, 04:51
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
Elaborate. Say i was to build a new computer right now from scratch using newegg.com. Give me an example piece of reliable hardware and unreliable hardware and how you went ahead and determined which is which.
Pretty simple. If you are buying cheap hardware from an online store then it is almost certainly not reliable hardware.

If you can find a board with ECC support, some ECC RAM, onboard graphics chip, onboard network, matched PSU, and manufacturers MTBF figures for it all, then you are a good way on the path to a reliable system.
Post 20 Apr 2010, 05:02
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Pretty simple. If you are buying cheap hardware from an online store then it is almost certainly not reliable hardware.


Then where do you suggest i buy hardware? How does the price compare to the "cheap" hardware?

Quote:
If you can find a board with ECC support, some ECC RAM, onboard graphics chip, onboard network, matched PSU, and manufacturers MTBF figures for it all, then you are a good way on the path to a reliable system.


In other words, if i go ahead an buy Dell's brand new Dell Xon Y, i have a reliable computer?
Post 20 Apr 2010, 05:15
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
Then where do you suggest i buy hardware? How does the price compare to the "cheap" hardware?
Oh, it is not cheap. But most people don't need this type of reliability so are not willing to pay for it. They just have to put up with occasional unexplained problems and reboot (and probably blame the OS for it all).
kohlrak wrote:
In other words, if i go ahead an buy Dell's brand new Dell Xon Y, i have a reliable computer?
I don't know, is marketed as a reliable system? Many systems marketed towards servers are in the class of ECC and have published MTBFs, but not all, be careful before you spend the money.

Some more anecdotal "evidence" from me, hehe. I have been reading a few Linux forums over the last year or so just to get the feel for things. I generally find that Linux users do not blame the OS for problems, instead they ask for solutions and keep trying until solved or they give up. Whereas instead, Windows users are very quick to blame the OS and cry foul. I wonder if this is because of a genuine poorer quality of Windows or because it is the feeling of no control over how Windows is developed? I can't comment on this quantitatively because I have no figures. But then again the level of market penetration is vastly different, the level of user expectancy is vastly different and the level of user tolerance of problems is vastly different, so perhaps any figures wouldn't be meaningful anyway.
Post 20 Apr 2010, 05:30
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
I've never had a bad chip to test, so i don't know. Embarassed
Maybe not a bad RAM chip but I would bet that you certainly have had RAM errors, it is almost impossible to avoid them, everyone gets them.

If Linux (or any OS) has a smaller memory footprint then it is less likely to be subject to a bit change in some vital part of the kernel. Perhaps the answer to your original Q up there is that Windows crashes more often simply because it is bigger. It would certainly make sense in a system without ECC that a larger OS would be more likely to suffer from random memory bit changes.

The only fair test would be to put each OS into a reliable box and see what happens.
Post 20 Apr 2010, 05:37
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Oh, it is not cheap. But most people don't need this type of reliability so are not willing to pay for it. They just have to put up with occasional unexplained problems and reboot (and probably blame the OS for it all).


Well, if I may invert the question, how often is this really the hardware itself? Remember that in situations where you can't simply break down as an easy solution to the problem, even unreliable hardware seemingly becomes reliable. Don't get me wrong, i'm not about to say that any hardware (even with ECC and all that stuff) is reliable, but it is certainly the OS's fault for allowing that sort of behavior. Why can't we just shut off (or reboot) that particular piece of hardware rather than the whole computer? To be specific, this isn't so much a software or hardware flaw so much as a design flaw. And who's at fault for this design flaw? Honestly, it's not like Windows has made any attempt to prevent getting blamed for this, therefore until it works towards fixing this obvious flaw, it deserves the flack it takes. That's like making a free open proxy on your network, going as far as advertising it, then expecting not to get blamed for breaking the law when someone uses it for illegal things.

Quote:
I don't know, is marketed as a reliable system? Many systems marketed towards servers are in the class of ECC and have published MTBFs, but not all, be careful before you spend the money.


Everything is marketed as reliable, last time i checked. Windows itself is marketed as fast, reliable, and secure.

Quote:
Some more anecdotal "evidence" from me, hehe. I have been reading a few Linux forums over the last year or so just to get the feel for things. I generally find that Linux users do not blame the OS for problems, instead they ask for solutions and keep trying until solved or they give up. Whereas instead, Windows users are very quick to blame the OS and cry foul. I wonder if this is because of a genuine poorer quality of Windows or because it is the feeling of no control over how Windows is developed? I can't comment on this quantitatively because I have no figures. But then again the level of market penetration is vastly different, the level of user expectancy is vastly different and the level of user tolerance of problems is vastly different, so perhaps any figures wouldn't be meaningful anyway.


Well, it also helps to be both a windows and linux user at the same time to help notice the significant difference. The most condemning evidence is that same hardware run by the same user using 2 different OSes yields different results. Although correlation does not imply causation, it's safe enough to point out the evident design flaw. Clearly there's something to be said about these sorts of errors and the great varience in gracefulness in handling errors.

I won't disagree, though, that there is definitely negligence and stupidity out there that can lead to illegitimate claims against windows. However, we should not assume that these bad claims make up even so much as 90% of all claims. Do not forget that there have still been bugs in the past (and still may be bugs) that have resulted in BSoDs that aren't even hardware related (and i don't mean crappy drivers by this, either).

revolution wrote:
kohlrak wrote:
I've never had a bad chip to test, so i don't know. Embarassed
Maybe not a bad RAM chip but I would bet that you certainly have had RAM errors, it is almost impossible to avoid them, everyone gets them.

If Linux (or any OS) has a smaller memory footprint then it is less likely to be subject to a bit change in some vital part of the kernel. Perhaps the answer to your original Q up there is that Windows crashes more often simply because it is bigger. It would certainly make sense in a system without ECC that a larger OS would be more likely to suffer from random memory bit changes.

The only fair test would be to put each OS into a reliable box and see what happens.


Then wouldn't this be Windows' fault? It certainly has the option to make itself smaller, and I don't think it would be a large jump to suggest that some optimizations could be possible without sacrificing functionality.
Post 20 Apr 2010, 06:12
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17287
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
Why can't we just shut off (or reboot) that particular piece of hardware rather than the whole computer?
How will you "shut off" the RAM?
kohlrak wrote:
Then wouldn't this be Windows' fault? It certainly has the option to make itself smaller, and I don't think it would be a large jump to suggest that some optimizations could be possible without sacrificing functionality.
Well that is like blaming the car you bought for using too much fuel per distance unit. You get the OS knowing that is needs some amount of memory, and then present it with lousy hardware and expect it to run perfectly?

If you know you have not-so-perfect hardware then best to use a really tiny OS that does only exactly what you need and no more. But it still won't solve the problem, you merely reduce the likelihood of it occurring. In this case a custom Linux build could be the answer. Make it small and lean to reduce the random crashes. This is something I have wanted to do for myself but unfortunately I have no time to pursue it Sad
Post 20 Apr 2010, 06:30
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
revolution wrote:
kohlrak wrote:
Why can't we just shut off (or reboot) that particular piece of hardware rather than the whole computer?
How will you "shut off" the RAM?
kohlrak wrote:
Then wouldn't this be Windows' fault? It certainly has the option to make itself smaller, and I don't think it would be a large jump to suggest that some optimizations could be possible without sacrificing functionality.
Well that is like blaming the car you bought for using too much fuel per distance unit. You get the OS knowing that is needs some amount of memory, and then present it with lousy hardware and expect it to run perfectly?


You can't, however compared to the vast number of other BSoD reasons? Or are you suggesting almost every BSoD is the result of bad ram?

Quote:
If you know you have not-so-perfect hardware then best to use a really tiny OS that does only exactly what you need and no more. But it still won't solve the problem, you merely reduce the likelihood of it occurring. In this case a custom Linux build could be the answer. Make it small and lean to reduce the random crashes. This is something I have wanted to do for myself but unfortunately I have no time to pursue it Sad


I have yet to have Linux itself crash, so i wouldn't work on it too hard.
Post 20 Apr 2010, 06:47
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2, 3  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.