Hi, Yes dell memory is junk, replace it.

I would suggest running MemTest86

Ah, I see where this went into the Memtest86 discussion. But why not use Memtest86+ instead?

Memtest86 had its last release in 2007, Memtest86+ is the updated version, last updated 04/05/2010 and the next version coming in start 2011.

---

Memtest86 does not run on top of Linux kernel. It only borrows a few basic routines that help to bootstrap linux kernel to perform the same task for itself. Borrowing code from one project usually doesn't mean you need to call your project the same name as the other one (MS borrowed code of IP stack from netBSD IIRC at some time but nobody claimed that windows to run on top of netBSD).

Memtest86 distributions (bootable CD or USB or ... images) also use bootloader which happens to be common on Linux machines to bootload Memtest86. At least some bootloaders that are able to boot linux are not linux-only bootloaders, they can be used on a machine that doesn't have linux installed. So calling them linux bootloaders is a bit unfair at least.

We seem to agree on most things. We only don't agree if a single-purpose application (such as Memtest86) that is able to talk to hardware without help of external code (loadable drivers, OS; not counting BIOS functions, they are available if you want them or not) is an OS or not. I don't see a way for us to agree on that so let's stop stealing this thread.

---

Metod ...

The memtest86 cd that I am using is only just over a meg is size, could probably fit on a legacy floppy......it has some flavor of linux on it. Program ran through 9 cycles of testing w/o error.
chkdsk was clean...no errors. To clarify, the original memtest that I ran was on a hirens boot disk......it ran on top of the win7 os that rebooted.
Prime95 also ran on top of os. Puter is happily crunching 8 cpu +1 gpu seti atm.
I tend to agree about poor quality memory from dell.....they have already replaced 2 sticks......Suggestions for replacing memory? I have been thinking of some crucial.....they have direct replacement for the dell.

---

May the blessings of the Lord overtake you and run you down

We seem to agree on most things. We only don't agree if a single-purpose application (such as Memtest86) that is able to talk to hardware without help of external code (loadable drivers, OS; not counting BIOS functions, they are available if you want them or not) is an OS or not. I don't see a way for us to agree on that so let's stop stealing this thread.

Um k? http://www.memtest86.com/about.html --> The parts that make it work come from the 1.2.1 Linux kernel and are highly modified. These parts of the kernel are what makes it fully bootable and able to load items into memory to be ran. Then the memtest code gets loaded into ramdisk and ran against several different "bad ram patterns". So I guess you couldn't define that it's running off linux, but it is running because of the linux project.

As far as the OS versus not being an OS it depends on YOUR definition of an OS. If it allows hardware to work it's an OS. Memtest cause the memory to work and error check. So in essence yes it is an OS, maybe not in full fledge modern day definitions we all live by but it is....but again it depends on your definition of OS.

---

Traveling through space at ~67,000mph!

I would suggest running MemTest86

Ah, I see where this went into the Memtest86 discussion. But why not use Memtest86+ instead?

Memtest86 had its last release in 2007, Memtest86+ is the updated version, last updated 04/05/2010 and the next version coming in start 2011.

We linked to the same site. ;)

We seem to agree on most things. We only don't agree if a single-purpose application (such as Memtest86) that is able to talk to hardware without help of external code (loadable drivers, OS; not counting BIOS functions, they are available if you want them or not) is an OS or not. I don't see a way for us to agree on that so let's stop stealing this thread.

An OS is necessary to run a machine. That is the reason why the BIOS was included as the designers of the original PC needed something to load once the bootstrap was finished. Modern machines hand off the loading of software from the BIOS POST routine to the Master Boot Record which then points to the location of the OS (or a bootloader). Without an OS of some form, you cannot run the machine.

You may try as hard as you can not to see it that way, but it is an undeniable fact.

We seem to agree on most things. We only don't agree if a single-purpose application (such as Memtest86) that is able to talk to hardware without help of external code (loadable drivers, OS; not counting BIOS functions, they are available if you want them or not) is an OS or not. I don't see a way for us to agree on that so let's stop stealing this thread.

An OS is necessary to run a machine. That is the reason why the BIOS was included as the designers of the original PC needed something to load once the bootstrap was finished. Modern machines hand off the loading of software from the BIOS POST routine to the Master Boot Record which then points to the location of the OS (or a bootloader). Without an OS of some form, you cannot run the machine.

You may try as hard as you can not to see it that way, but it is an undeniable fact.

All most all programs need an OS but not all. Stand alone programs do their own I/O and don't need an operating system. The largest stand alone program I know of ran the Airline Reservation system and was done that way to get every last processor cycle out of the hardware.

---

We seem to agree on most things. We only don't agree if a single-purpose application (such as Memtest86) that is able to talk to hardware without help of external code (loadable drivers, OS; not counting BIOS functions, they are available if you want them or not) is an OS or not. I don't see a way for us to agree on that so let's stop stealing this thread.

An OS is necessary to run a machine. That is the reason why the BIOS was included as the designers of the original PC needed something to load once the bootstrap was finished. Modern machines hand off the loading of software from the BIOS POST routine to the Master Boot Record which then points to the location of the OS (or a bootloader). Without an OS of some form, you cannot run the machine.

You may try as hard as you can not to see it that way, but it is an undeniable fact.

All most all programs need an OS but not all. Stand alone programs do their own I/O and don't need an operating system. The largest stand alone program I know of ran the Airline Reservation system and was done that way to get every last processor cycle out of the hardware.

I would surely bet that there was some sort of firmware that started the systems. Most DOS-based programs handled their own I/O too, yet DOS was still the OS.

And if the software is loaded directly after the firmware, it would be considered the OS if it is the control program of the computer.

We have about two pages of code that do the task swapping and we jokingly call that the operating system. It is a part of every application build used in the unit where as the other code is only included in a build if it contains features required by the board it will execute on.

Operating systems are very useful but their general nature introduces a good deal of overhead. Most of the time the advantages outweigh the overhead but in some applications the overhead is not worth the advantages the OS would offer. Take the word of someone who has spend almost 30 years writing code in an environment without one.

Then I'm afraid you've defined Operating Systems in the more traditional sense for the past 30 years and it never dawned on you what one exactly is. If the software you designed provides the same services as an OS, then it is the OS.

A OS supports applications. Some of the code I have written includes self contained diagnostic programs that only contains a program to test a device and a terminal driver to report test status. It would be a real stretch to call that an operating system.

That's where you're wrong. An OS does not have to support applications. An Operating System is merely a system of function calls that allow the machine to operate as the programmer intends.

[Edit]Or here's another way to look at it: If the application the OS supports is the OS and they are one and the same, then it is a self-supporting OS. The OS is, after all, just an application. The application is the OS and the OS is the application. Either way, the system still has an OS.

That's where you're wrong. An OS does not have to support applications. An Operating System is merely a system of function calls that allow the machine to operate as the programmer intends.

That's the point I was trying to make earlier. Problem is you have some thinking Windows type O/S, some thinking DOS type, some thinking BIOS type, and some thinking Real Time. And none of the definitions or realities or any of those systems equate out to the same definition. Anything that allows you to control the hardware in any way, by some standards, is considered an operating system. While some define it as a mediate layer that allows you to write apps. Each to his own, I know of one college professor I had that defined it as any system that allows you to execute and save code, along with accepting I/O from a keyboard and displaying it on a screen. So go figure, I think at this point it's an endless debate like many other debates that happen on this forum. (Fun until people start trying to throw punches)

---

Traveling through space at ~67,000mph!

I know of one college professor I had that defined it as any system that allows you to execute and save code, along with accepting I/O from a keyboard and displaying it on a screen.

The executing I'll agree with, saving code is optional and dependent on the desired operation of the machine. I know plenty of cell phones and robotics that use an OS but don't need to save anything.

Again, this shows that people think OSes are confined to microcomputers like the traditional PC or Mac. Operating Systems are many things to many devices. All of them allow devices to function and define the parameters of the system.

So go figure, I think at this point it's an endless debate like many other debates that happen on this forum. (Fun until people start trying to throw punches)

I once had a rather long discussion in trying to open the eyes of one individual who refused to see that a BIOS was nothing more than a rudimentary set of drivers for the hardware. He couldn't wrap his mind around it and insisted the BIOS was nothing more than firmware, and that drivers were distinctly different as they are loaded by the OS.

Professors and people who've been in the industry for 50 years can still be wrong from time to time. The problem is that too many people seem set in their views without ever seeing the "machine" from a different view.

The executing I'll agree with, saving code is optional and dependent on the desired operation of the machine. I know plenty of cell phones and robotics that use an OS but don't need to save anything.

Again, this shows that people think OSes are confined to microcomputers like the traditional PC or Mac. Operating Systems are many things to many devices. All of them allow devices to function and define the parameters of the system.

So go figure, I think at this point it's an endless debate like many other debates that happen on this forum. (Fun until people start trying to throw punches)

I once had a rather long discussion in trying to open the eyes of one individual who refused to see that a BIOS was nothing more than a rudimentary set of drivers for the hardware. He couldn't wrap his mind around it and insisted the BIOS was nothing more than firmware, and that drivers were distinctly different as they are loaded by the OS.

Professors and people who've been in the industry for 50 years can still be wrong from time to time. The problem is that too many people seem set in their views without ever seeing the "machine" from a different view.

I agree with you however cell phones do save information about the configuration of the network, address books, and text messages not to mention life timers etc. And robots while maybe not a permanent saving of information is required for each one is often saved on a ramdisk type system if they aren't being controlled from a remote machine that does save the information. I've had to load programs into CNC hole punch machines before that didn't save each program locally, but did save the current program in the machine until the execution was cleared. Obviously those machine were hooked to a pc system for permanent storage and transfer to the machine memory. That's a whole other bucket of worms lol.

But yes I whole heartedly agree than sometimes people don't take a step back and look at everything. Hence my mentioning of one of my professors.

---

Traveling through space at ~67,000mph!

We have about two pages of code that do the task swapping and we jokingly call that the operating system. It is a part of every application build used in the unit where as the other code is only included in a build if it contains features required by the board it will execute on.

Operating systems are very useful but their general nature introduces a good deal of overhead. Most of the time the advantages outweigh the overhead but in some applications the overhead is not worth the advantages the OS would offer. Take the word of someone who has spend almost 30 years writing code in an environment without one.

Then I'm afraid you've defined Operating Systems in the more traditional sense for the past 30 years and it never dawned on you what one exactly is. If the software you designed provides the same services as an OS, then it is the OS.

A OS supports applications. Some of the code I have written includes self contained diagnostic programs that only contains a program to test a device and a terminal driver to report test status. It would be a real stretch to call that an operating system.

That's where you're wrong. An OS does not have to support applications. An Operating System is merely a system of function calls that allow the machine to operate as the programmer intends.

But that's the part you are missing. What I am talking about doesn't have system or function calls. It is integrated into the code. There is not a clear line dividing the application from the I/O. I have run on operating systems with as little as 1E0 locations of memory operating system but I could see the division between application and operating system. In our unit the dividing line is not there because the application is built around the I/O. Another way of saying it is the I/O is the application.

The code used in our unit could be burned to prom as it functions like firmware defining our product. In older designs we did use proms. For the newer designs we decided to load it from battery backup memory to allow it to be upgraded over a phone line.

An operating system implies that it is able to be used by more than one application or some degree of general purpose. We don't have that.

---

Sure, some cell phones save things and so do some robotics programs, but they all don't have to. The ones that do not save things are still considered to be running an OS. :)

But that's the part you are missing. What I am talking about doesn't have system or function calls. It is integrated into the code. There is not a clear line dividing the application from the I/O.

If the function calls exist within the code itself, then the application is the OS. The program defines the parameters of the system. I'm not missing any part.

An operating system implies that it is able to be used by more than one application or some degree of general purpose. We don't have that.

No, an Operating System does not imply that at all. That's the exact assumption I'm trying to show is incorrect, and that's the part you're missing.

Operating Systems within cell phones or robotics or DVD players do not support multiple applications (not all cell phones are smart phones that run multiple apps), and they are certainly not general purpose.

Sure, some cell phones save things and so do some robotics programs, but they all don't have to. The ones that do not save things are still considered to be running an OS. :)

All cell phone have to have storage to save the network settings for your phone number and local towers at a bare minimum. So that may not be a good example, but I understand your point.

Operating Systems within cell phones or robotics or DVD players do not support multiple applications (not all cell phones are smart phones that run multiple apps), and they are certainly not general purpose.

I agree completely. There are quite a number of things in the world that fit this description.

---

Traveling through space at ~67,000mph!

But that's the part you are missing. What I am talking about doesn't have system or function calls. It is integrated into the code. There is not a clear line dividing the application from the I/O.

If the function calls exist within the code itself, then the application is the OS. The program defines the parameters of the system. I'm not missing any part.

An operating system implies that it is able to be used by more than one application or some degree of general purpose. We don't have that.

No, an Operating System does not imply that at all. That's the exact assumption I'm trying to show is incorrect, and that's the part you're missing.

Operating Systems within cell phones or robotics or DVD players do not support multiple applications (not all cell phones are smart phones that run multiple apps), and they are certainly not general purpose.

You are thinking like a structured program programmer. A spaghetti program lacks that clear dividing line that you keep insisting exist. You have to pick application or OS in our units because only one exist. I pick application because the application talks to two interfaces and transforms the data from one to the form required by the other. My boss would fire me if I started writing operating systems because that is not what we do. We produce hardware devices that use software to replace some of the hardware logic. We could do it all in hardware and it was done in the past with hardware but we made the trade off to use some software. I have been all over the 100,000 lines of code and have yet to find anything I would call an operating system. We do have a library of useful functions but in no way would they be considered an operating system. When the application is issuing I/O's and handling interrupts, that is not your normal OS/application relationship.

---

We linked to the same site. ;)

Ah, so we did. Just made sure I was talking about the correct program as not everyone seems to know that those blue lines are direct links to other pages. And then they type things into a search engine...

---

You are thinking like a structured program programmer. A spaghetti program lacks that clear dividing line that you keep insisting exist.

Actually, I'm insisting that there is no "clear" dividing line. I'm insisting that an OS has many faces and many purposes and therefore isn't as narrowly defined as you keep insisting it is.

You have to pick application or OS in our units because only one exist.

There's no need to force one to choose. To paraphrase: "A rose by any other name" is still a rose. Just because your application is the OS, doesn't mean it's not an OS.

I pick application because the application talks to two interfaces and transforms the data from one to the form required by the other. My boss would fire me if I started writing operating systems because that is not what we do.

Your boss "firing" you for writing Operating Systems is purely politics (and an ill-attempt at overstating your point). You are indeed writing Operating Systems even if you refuse to see it or call it that. You wouldn't be fired because it wouldn't change what you do. It would only change how you look at it.

I have been all over the 100,000 lines of code and have yet to find anything I would call an operating system. We do have a library of useful functions but in no way would they be considered an operating system.

Again, that's because of your rather limited definition on Operating Systems which limits what you "see". You see OSes only as a "general purpose" thing, but I've already shown how this definition is inaccurate by way of specialized devices such as DVD players - and what you do is clearly another example.

When the application is issuing I/O's and handling interrupts, that is not your normal OS/application relationship.

It's perfectly normal depending on the device.