You're pretty close, but a couple of points to mention. First, while relocations are indeed minimized (by things like import and export tables), at least on the x86 (well, there is a way, but I know Windows doesn't use it, and I have no information on Linux, but I can make an educated guess that it doesn't) you cannot use relative pointers to data. This generally means that all global variable accesses are absolute, and must be relocated (but only if the module can't load at its preferred address). This can potentially drastically increase the amount of stuff that gets copied on write in the executable.
Also, the initialized data section is copy on write, at least on Windows. There's also a utility on Windows called Bind that can store the actual function addresses to linked modules in the executable, so that no import table fixups are necessary if the linked module loads at its preferred address (and is the same version you bound the executable to).
I think you're using a more rigid definition of "exactly" than the GP. On Windows, executables (I'm using this term interchangeably with 'modules', so as to include DLLs) are loaded as memory mapped files (pretty sure this is what the GP meant by 'exactly'). Any regions of the executable that require updating (such as import tables, code that requires pointer relocation, etc.) are set as copy on write, so that if they do get written to, it'll be saved. For multiple copies of the same process (here I am using the term to mean separate copies of the program, not multiple processes of the same program that have been forked), this is no less efficient than on Unix/Linux (read-only data segments on Windows are always memory mapped). For cases of a process forking to spawn a new thread of its own, Unix/Linux would be more efficient; but remember that Unix was designed to do this (as it lacked threads), whereas Windows was designed to use threads for this purpose, which are even more efficient than Unix forks.
You're right in that it's not exactly the same, as Windows typically does not use the forking process (I should note that there are indeed internal Windows APIs for forking). However, the only time forking provides a benefit over Windows process creation is when spawning a new thread of the same program, which I already discussed.
You know, yesterday I would have thought that was an apt analogy; but not today. See, today a debate on another forum demonstrated something I didn't anticipate learning: people react to the same thing very differently. Call a homosexual a fag and you'll get labeled a homophobe, and possibly charged with a hate crime. Draw blasphemous cartoons of Muhammad, and you get a number of Muslim countries boycotting your entire country, and widespread rioting. Say pretty much anything you want to about Christians (haha, homophobic, superstitious, clinically retarded crusaders) and... nothing happens. On occasion you might have a Christian complain about you, but nobody cares about them.
I can't really remember what point I was going to make with this post, but I suppose I'll still throw that fact into the fray:P
Re:Obesity comes from a simple condition...
on
Obesity Contagious?
·
· Score: 1
What I meant specifically was that there was a defect in an enzyme involved in either metabolizing fat or extracting fat molecules from adipose stores. The defect wouldn't have to be hit-or-miss - it could just make the process less efficient. Such a defect would probably never be noticed, if the person is well fed, other than obesity. The primary energy source would remain the carbohydrates and protein consumed in food, and occasional breakdown of tissues would probably be unnoticed, as it would be too minor, and reversible (at least until they go on a hardcore diet, where the energy intake is much lower than the energy consumption).
Re:Obesity comes from a simple condition...
on
Obesity Contagious?
·
· Score: 1
No, but it can (in theory) modify the ratio of food intake that is burnt for energy versus converted to fat and stored (or even just modify the rate of fat metabolism). I'd be surprised if a virus promoted obesity, but it's not biologically impossible.
Also, there's no guarantee that, if you eat less than your body metabolizes, what gets metabolized will be fat. If something is funky with your fat metabolism, you may be eating away your muscles (and other tissue), and keeping the flab.
You, my friend, may be on to something. If they can make Sparkle significantly easier to develop for than Flash, and only on Windows (by far the dominant end user OS, providing a favourable cost/benefit ratio), they might be able to lure those ungodly annoying banner ad makers to it, leaving other platforms free to revel in the banner-ad-less ecstasy.
Welcome to the corporate world; please continue to bend over, and enjoy your stay.
I seem to recall hearing a while back about the computer connected to one of my dad's machines (he operates analytical chemistry instruments - mass spectrometers, chromatographs, that kind of thing) dying, and it took them like a month for the IT department to get him a new one, built to their (the IT department's) specs and with exactly the right software installed; all this time that one machine was out of commission. I told him I could have gone shopping at my local (cheap) computer shop, and had a computer up for him in under a work day (but that would have gotten him in big trouble with the IT department). That's corporate bureaucracy for you.
You're making the assumption that the president is always right, and always doing the moral and ethical thing; I think Hitler and Stalin would like to have a chat with you (and can you say King George?). Line item veto has to be up there on the list of worst government ideas ever, as it almost completely destroys the balance of power between congress and the president; fortunately, the supreme court is still in the loop, but I think more than sufficient damage would still be done, even without the ability to make unlimited, unconstitutional laws.
What I want to know is whether Wine is vulnerable to this design flaw that allows hardware enforced data execution protection to be remotely disabled by a clever buffer overflow (one that injects no code of its own, so cannot be prevented by DEP). I should mention that I submitted this story to Slashdot, but it was rejected.
China has ICBM-equipped submarines, Iraq doesn't. Pick a fight with China and it's mutually assured destruction to the tune of a good 50 fusion missiles (each killing everything in about a 70 mile radius, and able to aim anywhere in your country; those 50 are just what China can throw at the US; the US has several times that). That's your military strategy 101 for today.
An oppressive facist police state is perfectly ok, as long as there are possibilities for making money from them. This makes a mockery of the argument that the US invaded Iraq to free the people from oppression.
Two words: ICBM-equipped submarines. Now, let's hear you repeat that laughable catch-phrase.
Obviously. The Win32 API was, in general (there are a few exceptions), created in NT before 9x existed, so obviously the API support was there. What I referred to (which is what really matters) is that the kernel did not support it - multiple users, file/object/registry permissions, etc. An API is nothing without an implementation.
The point is that with no concept of user separation, not only did the coders not need their programs to "ever" run on a system that enforced user separation, but they probably didn't even bother to learn how to deal with user separation at all (and even if they were to learn, they'd have to have special test computers set up running NT just to test their programs on, as obviously they weren't using NT themselves). This is what Raymond Chen referred to as the taxes of software: something that has little or no benefit to most users, but should be done, none the less. Would you like to take a guess whether most programmers pay their taxes? Here's a hint: no; if you don't force people to do something positive, most won't (and WHQL has proven that even if you do, they're just as liable to find loopholes as meet the requirements).
So very much anger. The reason for users defaulting to administrator on NT is actually not hard to grasp: the dreaded Windows 95. Though 2 major versions of Windows NT were released before, you could say that Windows 95 preceded NT in that it was not until XP that the NT line really overtook the 9x line, some 5 years after Windows 95.
If you recall, MS had dramatically different objectives with NT and 9x. NT was designed to be a stable, secure (at least 'secure' at that point in time), streamlined 32-bit kernel. 9x, on the other hand, was intended to be as much of NT as could be retrofitted onto the old DOS and Windows 3.1 architectures. Unlike with NT, MS wanted virtually all DOS and Windows 3.1 software to run on 95 at full speed without modification (with NT, they only desired as much compatibility as was feasible, given the totally new kernel). This placed massive restrictions on what could be done with 95.
One of the NT features 95 lacked was user isolation. That is, the concept of protecting one user's stuff from another user. This included any type of user/administrator distinction. All home applications were developed for 95, because nobody had NT on their home computers (which was due to NT's limited compatibility with DOS and Win16 programs). Thus, they never had to worry about anything security related. By the time NT overtook 9x, this practice was firmly established. In order to maintain compatibility with programs written on 9x, MS was forced to make administrator the default on NT.
So, that's the story. Nothing particularly remarkable or insightful.
That sounds like a hardware problem, to me. Only a couple times have I ever had Windows reboot my computer spontaneously. The first was when I was learning D3D. One of my first programs had a reference count leak that ended up causing the creation of many D3D devices. Well, it just so happened that the (non-WHQL) NVidia driver I was using had a rather unorthodox way of responding to that: it would hard-reset the whole computer (I would guess this was because it fed crap data to the video card, and the card blew up). Other than that, I've never (not even once) had my computer spontaneously reboot without one of the following also happening:
- the power went out (yay California rolling blackouts)
- a piece of hardware died
As for BSODs, I've had exactly 2 types (with multiple occurrances of each at various times):
- when playing games the computer would randomly BSOD with IRQL_NOT_LESS_THAN_OR_EQUAL. This was ultimately tracked to a Sound Blaster driver
- when I've needed to either make a different drive my boot drive, or replace the motherboard. NT likes to bind to your hardware (specifically motherboard, IDE controller, and boot drive) and refuse to boot if you change any of those, which can be remarkably annoying, and I really wish they'd fix it
Other than that, absolutely no BSODs, whatsoever. Although just last night I did find out that if you access several gigs of data via memory mapped files within a couple minutes, Windows will go into panic mode (due to running out of physical memory, using it all on buffers), and nearly die; although it does recover to full functionality, if you give it a couple minutes to catch its breath (and free the 900 megs of physical memory it was using for cache, out of my 1 gig of memory). I should also mention that I regularly leave my computer (XP) running for 1 or 2 months straight, although I haven't beat my friend's record of 121 days uptime with an NT system.
I've heard people say that Linux has a higher deployment base than Windows, before. While I don't particularly have a reason to doubt that's true, frankly I've never seen any serious evidence one way or another (only things like revenue comparisons, which are obviously of questionable value). Care to provide me with some?
Aren't you saying, then, that the study is correct in saying that Linux is more difficult to admin than Windows, while at the time saying the study is flawed in that very way?
So in other words, the fact that papers attempting to disprove intelligent design are starting to appear means that there's merit to intelligent design?
Also, the 2.6 kernels have an extra "preemptable kernel" option which makes desktop operations even smoother.
Ah, I see. I expected Linux always had that (NT always has).
Have you ever used a unix desktop extensively? It is really difficult to understand what I am talking about unless you have. It is quite easy to become accustomed to the quirks of one OS and not really notice just how bad it is until you try something else which does certain things much better.
I used CDE for a semester, and KDE a couple times. Besides being slower in general than XP/Explorer, I haven't noticed much difference. Anyway, I was trying to define the problem in concrete terms, as something which may be empirically verified, as opposed to "Windows bad!".
One more thing I should mention on the subject. Explorer is Gord-awful, as far as threading is concerned; it does WAY too much in too few threads, and consequently hangs a lot as long operations complete. That's old news. It's also known to suffer from retry multiplication problems, which frequently cause it to hang waiting for something that won't work (such as accessing a network drive when the network is down).
None of this is a problem with the NT kernel itself. At this point I cite my knowledgeable friend Continuity (who has done a substantial amount of programming on Linux, as well as several consoles), who is an ardent Linux supporter (and believes Linux is superior to Windows overall) and 'M$' hater. Yet he still admits the NT kernel is well made; it's the lower layers (APIs, drivers, apps) that are buggy and poorly made.
Slashdot Mirror
I'm almost positive that Linux does not use aforementioned method of relative addressing, as the only way to do that is using segmentation.
You're pretty close, but a couple of points to mention. First, while relocations are indeed minimized (by things like import and export tables), at least on the x86 (well, there is a way, but I know Windows doesn't use it, and I have no information on Linux, but I can make an educated guess that it doesn't) you cannot use relative pointers to data. This generally means that all global variable accesses are absolute, and must be relocated (but only if the module can't load at its preferred address). This can potentially drastically increase the amount of stuff that gets copied on write in the executable.
Also, the initialized data section is copy on write, at least on Windows. There's also a utility on Windows called Bind that can store the actual function addresses to linked modules in the executable, so that no import table fixups are necessary if the linked module loads at its preferred address (and is the same version you bound the executable to).
I think you're using a more rigid definition of "exactly" than the GP. On Windows, executables (I'm using this term interchangeably with 'modules', so as to include DLLs) are loaded as memory mapped files (pretty sure this is what the GP meant by 'exactly'). Any regions of the executable that require updating (such as import tables, code that requires pointer relocation, etc.) are set as copy on write, so that if they do get written to, it'll be saved. For multiple copies of the same process (here I am using the term to mean separate copies of the program, not multiple processes of the same program that have been forked), this is no less efficient than on Unix/Linux (read-only data segments on Windows are always memory mapped). For cases of a process forking to spawn a new thread of its own, Unix/Linux would be more efficient; but remember that Unix was designed to do this (as it lacked threads), whereas Windows was designed to use threads for this purpose, which are even more efficient than Unix forks.
You're right in that it's not exactly the same, as Windows typically does not use the forking process (I should note that there are indeed internal Windows APIs for forking). However, the only time forking provides a benefit over Windows process creation is when spawning a new thread of the same program, which I already discussed.
I nominate this discovery for the title of highest ratio of actual importance to perceived importance.
You know, yesterday I would have thought that was an apt analogy; but not today. See, today a debate on another forum demonstrated something I didn't anticipate learning: people react to the same thing very differently. Call a homosexual a fag and you'll get labeled a homophobe, and possibly charged with a hate crime. Draw blasphemous cartoons of Muhammad, and you get a number of Muslim countries boycotting your entire country, and widespread rioting. Say pretty much anything you want to about Christians (haha, homophobic, superstitious, clinically retarded crusaders) and... nothing happens. On occasion you might have a Christian complain about you, but nobody cares about them.
:P
I can't really remember what point I was going to make with this post, but I suppose I'll still throw that fact into the fray
What I meant specifically was that there was a defect in an enzyme involved in either metabolizing fat or extracting fat molecules from adipose stores. The defect wouldn't have to be hit-or-miss - it could just make the process less efficient. Such a defect would probably never be noticed, if the person is well fed, other than obesity. The primary energy source would remain the carbohydrates and protein consumed in food, and occasional breakdown of tissues would probably be unnoticed, as it would be too minor, and reversible (at least until they go on a hardcore diet, where the energy intake is much lower than the energy consumption).
No, but it can (in theory) modify the ratio of food intake that is burnt for energy versus converted to fat and stored (or even just modify the rate of fat metabolism). I'd be surprised if a virus promoted obesity, but it's not biologically impossible.
Also, there's no guarantee that, if you eat less than your body metabolizes, what gets metabolized will be fat. If something is funky with your fat metabolism, you may be eating away your muscles (and other tissue), and keeping the flab.
You, my friend, may be on to something. If they can make Sparkle significantly easier to develop for than Flash, and only on Windows (by far the dominant end user OS, providing a favourable cost/benefit ratio), they might be able to lure those ungodly annoying banner ad makers to it, leaving other platforms free to revel in the banner-ad-less ecstasy.
On the other hand, isn't this flagged as an attempt to execute code on a data page?
The problem that wasn't. See http://www.uninformed.org/?v=2&a=4 . Also, wasn't this "back door" created well before DEP/NX was around on x86?
Welcome to the corporate world; please continue to bend over, and enjoy your stay.
I seem to recall hearing a while back about the computer connected to one of my dad's machines (he operates analytical chemistry instruments - mass spectrometers, chromatographs, that kind of thing) dying, and it took them like a month for the IT department to get him a new one, built to their (the IT department's) specs and with exactly the right software installed; all this time that one machine was out of commission. I told him I could have gone shopping at my local (cheap) computer shop, and had a computer up for him in under a work day (but that would have gotten him in big trouble with the IT department). That's corporate bureaucracy for you.
You're making the assumption that the president is always right, and always doing the moral and ethical thing; I think Hitler and Stalin would like to have a chat with you (and can you say King George?). Line item veto has to be up there on the list of worst government ideas ever, as it almost completely destroys the balance of power between congress and the president; fortunately, the supreme court is still in the loop, but I think more than sufficient damage would still be done, even without the ability to make unlimited, unconstitutional laws.
What I want to know is whether Wine is vulnerable to this design flaw that allows hardware enforced data execution protection to be remotely disabled by a clever buffer overflow (one that injects no code of its own, so cannot be prevented by DEP). I should mention that I submitted this story to Slashdot, but it was rejected.
I know. Who the heck gave them the right to stick their own bigoted, hateful morality and beliefs in our faces, like they can say whatever they want?
China has ICBM-equipped submarines, Iraq doesn't. Pick a fight with China and it's mutually assured destruction to the tune of a good 50 fusion missiles (each killing everything in about a 70 mile radius, and able to aim anywhere in your country; those 50 are just what China can throw at the US; the US has several times that). That's your military strategy 101 for today.
An oppressive facist police state is perfectly ok, as long as there are possibilities for making money from them. This makes a mockery of the argument that the US invaded Iraq to free the people from oppression. Two words: ICBM-equipped submarines. Now, let's hear you repeat that laughable catch-phrase.
Obviously. The Win32 API was, in general (there are a few exceptions), created in NT before 9x existed, so obviously the API support was there. What I referred to (which is what really matters) is that the kernel did not support it - multiple users, file/object/registry permissions, etc. An API is nothing without an implementation.
The point is that with no concept of user separation, not only did the coders not need their programs to "ever" run on a system that enforced user separation, but they probably didn't even bother to learn how to deal with user separation at all (and even if they were to learn, they'd have to have special test computers set up running NT just to test their programs on, as obviously they weren't using NT themselves). This is what Raymond Chen referred to as the taxes of software: something that has little or no benefit to most users, but should be done, none the less. Would you like to take a guess whether most programmers pay their taxes? Here's a hint: no; if you don't force people to do something positive, most won't (and WHQL has proven that even if you do, they're just as liable to find loopholes as meet the requirements).
So very much anger. The reason for users defaulting to administrator on NT is actually not hard to grasp: the dreaded Windows 95. Though 2 major versions of Windows NT were released before, you could say that Windows 95 preceded NT in that it was not until XP that the NT line really overtook the 9x line, some 5 years after Windows 95.
If you recall, MS had dramatically different objectives with NT and 9x. NT was designed to be a stable, secure (at least 'secure' at that point in time), streamlined 32-bit kernel. 9x, on the other hand, was intended to be as much of NT as could be retrofitted onto the old DOS and Windows 3.1 architectures. Unlike with NT, MS wanted virtually all DOS and Windows 3.1 software to run on 95 at full speed without modification (with NT, they only desired as much compatibility as was feasible, given the totally new kernel). This placed massive restrictions on what could be done with 95.
One of the NT features 95 lacked was user isolation. That is, the concept of protecting one user's stuff from another user. This included any type of user/administrator distinction. All home applications were developed for 95, because nobody had NT on their home computers (which was due to NT's limited compatibility with DOS and Win16 programs). Thus, they never had to worry about anything security related. By the time NT overtook 9x, this practice was firmly established. In order to maintain compatibility with programs written on 9x, MS was forced to make administrator the default on NT.
So, that's the story. Nothing particularly remarkable or insightful.
That is the first time I've EVER seen somebody on Slashdot call some anti-MS sentiment 'FUD' :P
That sounds like a hardware problem, to me. Only a couple times have I ever had Windows reboot my computer spontaneously. The first was when I was learning D3D. One of my first programs had a reference count leak that ended up causing the creation of many D3D devices. Well, it just so happened that the (non-WHQL) NVidia driver I was using had a rather unorthodox way of responding to that: it would hard-reset the whole computer (I would guess this was because it fed crap data to the video card, and the card blew up). Other than that, I've never (not even once) had my computer spontaneously reboot without one of the following also happening:
- the power went out (yay California rolling blackouts)
- a piece of hardware died
As for BSODs, I've had exactly 2 types (with multiple occurrances of each at various times):
- when playing games the computer would randomly BSOD with IRQL_NOT_LESS_THAN_OR_EQUAL. This was ultimately tracked to a Sound Blaster driver
- when I've needed to either make a different drive my boot drive, or replace the motherboard. NT likes to bind to your hardware (specifically motherboard, IDE controller, and boot drive) and refuse to boot if you change any of those, which can be remarkably annoying, and I really wish they'd fix it
Other than that, absolutely no BSODs, whatsoever. Although just last night I did find out that if you access several gigs of data via memory mapped files within a couple minutes, Windows will go into panic mode (due to running out of physical memory, using it all on buffers), and nearly die; although it does recover to full functionality, if you give it a couple minutes to catch its breath (and free the 900 megs of physical memory it was using for cache, out of my 1 gig of memory). I should also mention that I regularly leave my computer (XP) running for 1 or 2 months straight, although I haven't beat my friend's record of 121 days uptime with an NT system.
I've heard people say that Linux has a higher deployment base than Windows, before. While I don't particularly have a reason to doubt that's true, frankly I've never seen any serious evidence one way or another (only things like revenue comparisons, which are obviously of questionable value). Care to provide me with some?
Aren't you saying, then, that the study is correct in saying that Linux is more difficult to admin than Windows, while at the time saying the study is flawed in that very way?
In other words, administering a Linux system is more difficult than administering a Windows system?
So in other words, the fact that papers attempting to disprove intelligent design are starting to appear means that there's merit to intelligent design?
Also, the 2.6 kernels have an extra "preemptable kernel" option which makes desktop operations even smoother.
Ah, I see. I expected Linux always had that (NT always has).
Have you ever used a unix desktop extensively? It is really difficult to understand what I am talking about unless you have. It is quite easy to become accustomed to the quirks of one OS and not really notice just how bad it is until you try something else which does certain things much better.
I used CDE for a semester, and KDE a couple times. Besides being slower in general than XP/Explorer, I haven't noticed much difference. Anyway, I was trying to define the problem in concrete terms, as something which may be empirically verified, as opposed to "Windows bad!".
One more thing I should mention on the subject. Explorer is Gord-awful, as far as threading is concerned; it does WAY too much in too few threads, and consequently hangs a lot as long operations complete. That's old news. It's also known to suffer from retry multiplication problems, which frequently cause it to hang waiting for something that won't work (such as accessing a network drive when the network is down).
None of this is a problem with the NT kernel itself. At this point I cite my knowledgeable friend Continuity (who has done a substantial amount of programming on Linux, as well as several consoles), who is an ardent Linux supporter (and believes Linux is superior to Windows overall) and 'M$' hater. Yet he still admits the NT kernel is well made; it's the lower layers (APIs, drivers, apps) that are buggy and poorly made.