This effect occurs because of discretization. Remember that there are only 255 choices for the level of each color chanel. The eye can easily distinguish 255 colors. When a picture is dominated by a single hue (e.g. blue sky, orange sunset) the borders between areas with different levels become quite clear.
I suspect you are being mocked for the several misconcentions your post reveals.
XP is not a server OS. Microsoft's server OS's are NT, Win2K, and Win2K3.
The NT code-base that runs Microsoft's server OSs was around long before Linux grew popular. It's roots go back to DEC VMS.
XP is desktop OS, not a server OS. It's Microsoft's first desktop OS based on the NT code-base. It's earlier desktop OS products (Win95, WinME) ran on a code-base that grew organically out of DOS.
CES is about products directed at consumers. So it's not surprising that Bill talks about the consumer-orientied features of his next desktop OS (Vista), instead of his next server OS.
That's probably true. On the other hand, that's mostly a marketing feature rather than a true technical feature. I mean, one could certainly draw a circle arround the APIs that are shared between the.NET library and the mono library and say "this is the standard multi-platform library". It's just not particularly in Microsoft's interest to highlight those APIs.
If you require that that the mono library and the.NET library are exactly one-to-one equivilent, then you're right: that will never happen. Of course, that isn't even the case for different C and C++ STL libraries, so I don't think that's a reasonable requirement.
The mono library implements the vast majority of.NET library APIs. In addition, in contains many useful GTK, LDAP, DB, and other bindings of its own that are missing from the.NET library. It is, on its own, an extensive and fully functional programming library that just happens to nearly be a compatible superset of the.NET library.
Thanks for the link. I read the document, and even sat on it for a while trying to wrap my head around its arguments.
As far as an ABI goes, the document basically says it's impossible and I agree entirely. That's why COM was invented and Linux doesn't have COM. (Well, it has CORBA, but that was never intended to be performant enough for something like communication between a device driver and the kernel.)
As far as an API goes, I think the documen't argument is rather unconvincing. (The document itself admits that opinions on this topic are "volitile" among driver coders.) Basically the document says that encapsulation is the enemy of performance. To whatever extent that argument is true, it applies to all software, and so is basically an argument against ever using abstraction layers.
Instead of the lines of responsibility that an API draws, the document argues for the virtues of a free-for-all pile of code where developers are stepping all over each other in the quest for improvement. Traditional software engineering wisdom is that this is a Bad Idea.
Still, the Linux kernel has obviously been a very successful project. Given these two apparently clashing facts, instead of just accepting one and rejecting the other, I'd hope someone could explain what's special about Linux kernel development practices that allows them to work so well without respecting the normal rules.
The kernel developers are against a standard kernel API/ABI for drivers because then it's easier for people to make closed-source drivers.
Wow, is this really the reason? I had no idea. Isn't that a bit over the top? I mean, I assume everyone would agree that, purely from a software design perspective, an having hardware abstraction layer is a good idea. So saying that you refuse to have one just in order to make the lives of people who would write non-GPL drivers difficult is just... wow.
I knew there were people in the world for whom the raison d'etre of Linux is to be a GPL OS, but I assumed that most actual kernel hackers were people for whom the raison d'etre of Linux is to be a good OS that happens to be GPL.
Drivers for just about any device that runs on an external bus are moving to user-land in Vista. This includes drivers for USB and firewire devices, which run in kernel-space in Linux. Video drivers are not moving to user-land in Vista, because Windows can achieve better graphics performance and GUI responsiveness by keeping them in kernel-space. You can read more about this stuff here.
In any case, given that Linux doesn't even have a driver abstraction layer analogous to the Windows HAL, it's a bit ridiculous for a Linux fanboy to complain about a lack of encapsulation in the Windows driver architecture.
Actually, I think the two usages are quite close. In my daily work as a programmer, we use the word "hack" to describe a clever piece of programming that enables something to be done that really wasn't forseen in the original design. For example, perhaps my subroutine is handed a file-reading stream for it to interrogate. Clearly the architect of the program did this so I could only read, but not write, to that file. But perhaps I figure out some neat to feature I can add if I can get around that restriction and nevertheless write to the file. I'd call that a "hack" -- in this case a good and useful one. Getting a system designed to read a media file to execute arbitrary code is a "hack" in a similiar way -- just an evil and destructive one.
In any case, whether you're against overoading the meanings of words is really immaterial. Many, perhaps even most, english words do have overloaded meanings. In any case, Webster's gives both our definitions: yours as #3 and mine as #4.
And supposing you were to convince English-speakers that overloading is bad -- why should your prefered defintion of "hacker" win instead of the one that you seem to agree is most common?
This post is pure flaimbait. You understood perfectly well what the writer meant by "hacker", and so did everyone else. You also understand perfectly well that one very commonly used definition of "hacker" is "a person who makes unauthorized use of another's computer". And the author probably understands perfectly well that there is a another definition "hacker" that means "a clever and dedicated programmer", although that happens not to be the one he employed. Lots of words have multiple definitions. Your objection is pure posturing and does no one any good.
Re:GTK is alright...but no raves
on
Why Use GTK+?
·
· Score: 1
I don't know about "not even close", but I'm certainly willing to grant that it doesn't do exactly what his code did. On the other hand, one could argue that having standardized dimensions and button text is better anyway, and, as another poster pointed out, having the library provide the code for standardized scenarios improves maintainability as well.
But really I wasn't trying to solve his exact coding problem. (Do any of us expect that he would switch to C# on Windows if it did?) I was trying to illustrate the point, which I still claim is valid, that Microsoft has historically done a better job of making GUI programming easy that most of the other players in that market.
Re:GTK is alright...but no raves
on
Why Use GTK+?
·
· Score: 5, Insightful
Um, you mean like this C# code?
DialogResult result = MessageBox.Show("Quit without saving?", "", MessageBoxButtons.YesNoCancel);
Many slashdotters like to drone on about how evil business practices got Microsoft where it is today. But one thing that definitely helped is that, for much of GUI history, it's been easier to write GUI code for Windows than for almost any other platform.
The problem with the "After 9/11, everything is different" justification is that it admits no limits. Tell me, after 9/11, is there any civil liberty that you are not willing to sacrifice?
Holding thousands of people indefinitely, without charge and without any judicial review? After 9/11, everything is different.
Torturing hundreds of suspects, and outsourcing the torture of hundreds more? After 9/11, everything is different.
Continuous monitoring and data-mining of essentially all communications? After 9/11, everything is different.
Individually tracking the movement, communication, and transactions of every person in the U.S. After 9/11, everything is different.
Keeping Americans in the dark about the details and sometimes even the existence of these actions being performed in their names? After 9/11, everything is different.
For manufacturers and users, there are real advantages to dealing with fewer suppliers. Because of that, if you want your office suite to be adopted, it can't be just marginally better than Microsoft's. It has to be phenomenally better. While that might feel "unfair" to you, it derives from the real, practical needs of manufacturers and users, and it certainly isn't "illegal".
There is no prosecutor! This is a civil suit. It's a matter between Paramount and the man in question. The government just supplies a judge.
Also, because this is a civil suit, the standard of proof is "by a preponderance of the evidence", not "beyond a reasonable doubt". That means that, even it's concievable that the guy is the victim of a drive-by uploader, as long as the court believes that it is more likely that he did the deed, it will rule for Paramount.
I believe this is a civil, not a criminal case. So the standard of proof is not "beyond a reasonable doubt", but only "by the preponderance of the evidence".
Suppose a court finds that the film was uploaded from his IP address (and he wiped a machine at a suspicious time). Then even though it's concievable that he's just the victim of a drive-by uploader (and the drive-wiping was pure coincidence), a court is likely to find it more propable that he's the uploader (and was trying to cover his tracks). It would then rule in favor of Paramount.
The idea of relativity is that no frame of reference is "special". Working this out for frames that differ by a constant velocity is pretty straightforward, but the situation with respect to rotation isn't so straightforward. If you spin yourself around you will quickly find that there does seem to be a special frame that doesn't make you dizy, which we call the non-rotating frame. To know that you are spinning, you don't appear to have to measure your rotation relative to anything else.
Einstein had the idea that really, rotation is relative, too, and this apparently special non-rotating frame is really just the frame in which you are not spinning relative to the other bodies in your region of space time. In other words, seen from a different region of the universe, maybe our region of the universe is spinning furiously, but we don't notice it because all the bodies near us are all spinning furiously together.
When you work out the math in the context of general relativity, the implication is that, near a big spinning body, for you to feel like you are not spinning you actually needs to be spinning slightly relative to what would fell like not spinning far away from the body. The effect is called frame-dragging. This experiment tried to measure the frame-dragging effect of the Earth on some extremely precise gyroscopes in orbiting satelites.
That's not quite right. It is true that Linux provides a very innovative and interesting forking model that allows you to say at fork-time which resouces are shared between a child and parent and which are not. It's true that you use this make the fork a "thread" or a "process", depending on which resources you choose to share. (And the theads of apps that use this look, confusingly, like a bunch of processes with the same PID and working set when you run ps.) But that doesn't mean that Linux beats the pants of Window's thread creation perf, because Windows creates threads faster than Linux does forks.
I didn't mean to say that there aren't some negative consequences to the choice of making threads performant and processes less so. There are, and your post correctly identifies one of them. But I think it's wrong to say that that design decision is therefore across-the-board wrong. There are times when a threaded architecture is appropriate, and that is harder to do in Unix (which is why Apache 1.x spawns processes, even though the 2.x codebase shows that threads are a better idea).
1. I have no idea what you mean by "an OS dependent language". Does that mean you believe that mono, which compiles C# in Linux, uses a little hidden copy of the windows OS? Anyway, that isn't right. C# can be compiled all the way down to the CPU's instruction set, and can therefore be used to write an OS.
2. Yes, the runtime makes things a little slower. As long as it isn't much slower, or the speed of your hardware is such that it doesn't matter for your application, this isn't a problem. (By the way, if you want your app to run really fast, you run it without an OS -- but for most people the convenience of the services the OS provides outweighs its perf hit.)
Processes in Unix are lightweight objects, and the OS spawns them left and right. Processes in Windows are heavyweight objects, and the OS creates only a handfull of them. The lightweight objects in windows are threads, and you'll notice that Windows thread creation is faster than Unix thread creation. These are just different OS design philosophies.
Slashdot Mirror
This effect occurs because of discretization. Remember that there are only 255 choices for the level of each color chanel. The eye can easily distinguish 255 colors. When a picture is dominated by a single hue (e.g. blue sky, orange sunset) the borders between areas with different levels become quite clear.
I suspect you are being mocked for the several misconcentions your post reveals.
That is one of the reasons for Java's success.
That's probably true. On the other hand, that's mostly a marketing feature rather than a true technical feature. I mean, one could certainly draw a circle arround the APIs that are shared between the .NET library and the mono library and say "this is the standard multi-platform library". It's just not particularly in Microsoft's interest to highlight those APIs.
If you require that that the mono library and the .NET library are exactly one-to-one equivilent, then you're right: that will never happen. Of course, that isn't even the case for different C and C++ STL libraries, so I don't think that's a reasonable requirement.
The mono library implements the vast majority of .NET library APIs. In addition, in contains many useful GTK, LDAP, DB, and other bindings of its own that are missing from the .NET library. It is, on its own, an extensive and fully functional programming library that just happens to nearly be a compatible superset of the .NET library.
And of course there's mono, too.
What makes it a worthless language is that it has all the bad parts of C++ and Java without any of the benefits.
Would you care to enlighten the rest of us which bad parts and benefits of C++ and Java you had in mind?
Thanks for the link. I read the document, and even sat on it for a while trying to wrap my head around its arguments.
As far as an ABI goes, the document basically says it's impossible and I agree entirely. That's why COM was invented and Linux doesn't have COM. (Well, it has CORBA, but that was never intended to be performant enough for something like communication between a device driver and the kernel.)
As far as an API goes, I think the documen't argument is rather unconvincing. (The document itself admits that opinions on this topic are "volitile" among driver coders.) Basically the document says that encapsulation is the enemy of performance. To whatever extent that argument is true, it applies to all software, and so is basically an argument against ever using abstraction layers.
Instead of the lines of responsibility that an API draws, the document argues for the virtues of a free-for-all pile of code where developers are stepping all over each other in the quest for improvement. Traditional software engineering wisdom is that this is a Bad Idea.
Still, the Linux kernel has obviously been a very successful project. Given these two apparently clashing facts, instead of just accepting one and rejecting the other, I'd hope someone could explain what's special about Linux kernel development practices that allows them to work so well without respecting the normal rules.
The kernel developers are against a standard kernel API/ABI for drivers because then it's easier for people to make closed-source drivers.
Wow, is this really the reason? I had no idea. Isn't that a bit over the top? I mean, I assume everyone would agree that, purely from a software design perspective, an having hardware abstraction layer is a good idea. So saying that you refuse to have one just in order to make the lives of people who would write non-GPL drivers difficult is just... wow.
I knew there were people in the world for whom the raison d'etre of Linux is to be a GPL OS, but I assumed that most actual kernel hackers were people for whom the raison d'etre of Linux is to be a good OS that happens to be GPL.
It was Spinlock, the original poster, to whom I was refering to, not you. Sorry not to be clearer.
Drivers for just about any device that runs on an external bus are moving to user-land in Vista. This includes drivers for USB and firewire devices, which run in kernel-space in Linux. Video drivers are not moving to user-land in Vista, because Windows can achieve better graphics performance and GUI responsiveness by keeping them in kernel-space. You can read more about this stuff here.
In any case, given that Linux doesn't even have a driver abstraction layer analogous to the Windows HAL, it's a bit ridiculous for a Linux fanboy to complain about a lack of encapsulation in the Windows driver architecture.
I'm going to make a wild guess, just based on probabilities, that you are a Linux fan.
You do know, don't you, that in Linux, device drivers run inside the kernel?
Actually, I think the two usages are quite close. In my daily work as a programmer, we use the word "hack" to describe a clever piece of programming that enables something to be done that really wasn't forseen in the original design. For example, perhaps my subroutine is handed a file-reading stream for it to interrogate. Clearly the architect of the program did this so I could only read, but not write, to that file. But perhaps I figure out some neat to feature I can add if I can get around that restriction and nevertheless write to the file. I'd call that a "hack" -- in this case a good and useful one. Getting a system designed to read a media file to execute arbitrary code is a "hack" in a similiar way -- just an evil and destructive one.
In any case, whether you're against overoading the meanings of words is really immaterial. Many, perhaps even most, english words do have overloaded meanings. In any case, Webster's gives both our definitions: yours as #3 and mine as #4.
And supposing you were to convince English-speakers that overloading is bad -- why should your prefered defintion of "hacker" win instead of the one that you seem to agree is most common?
This post is pure flaimbait. You understood perfectly well what the writer meant by "hacker", and so did everyone else. You also understand perfectly well that one very commonly used definition of "hacker" is "a person who makes unauthorized use of another's computer". And the author probably understands perfectly well that there is a another definition "hacker" that means "a clever and dedicated programmer", although that happens not to be the one he employed. Lots of words have multiple definitions. Your objection is pure posturing and does no one any good.
I don't know about "not even close", but I'm certainly willing to grant that it doesn't do exactly what his code did. On the other hand, one could argue that having standardized dimensions and button text is better anyway, and, as another poster pointed out, having the library provide the code for standardized scenarios improves maintainability as well.
But really I wasn't trying to solve his exact coding problem. (Do any of us expect that he would switch to C# on Windows if it did?) I was trying to illustrate the point, which I still claim is valid, that Microsoft has historically done a better job of making GUI programming easy that most of the other players in that market.
Um, you mean like this C# code?
Many slashdotters like to drone on about how evil business practices got Microsoft where it is today. But one thing that definitely helped is that, for much of GUI history, it's been easier to write GUI code for Windows than for almost any other platform.
The problem with the "After 9/11, everything is different" justification is that it admits no limits. Tell me, after 9/11, is there any civil liberty that you are not willing to sacrifice?
Holding thousands of people indefinitely, without charge and without any judicial review? After 9/11, everything is different.
Torturing hundreds of suspects, and outsourcing the torture of hundreds more? After 9/11, everything is different.
Continuous monitoring and data-mining of essentially all communications? After 9/11, everything is different.
Individually tracking the movement, communication, and transactions of every person in the U.S. After 9/11, everything is different.
Keeping Americans in the dark about the details and sometimes even the existence of these actions being performed in their names? After 9/11, everything is different.
For manufacturers and users, there are real advantages to dealing with fewer suppliers. Because of that, if you want your office suite to be adopted, it can't be just marginally better than Microsoft's. It has to be phenomenally better. While that might feel "unfair" to you, it derives from the real, practical needs of manufacturers and users, and it certainly isn't "illegal".
I would like to think the prosecutor...
There is no prosecutor! This is a civil suit. It's a matter between Paramount and the man in question. The government just supplies a judge.
Also, because this is a civil suit, the standard of proof is "by a preponderance of the evidence", not "beyond a reasonable doubt". That means that, even it's concievable that the guy is the victim of a drive-by uploader, as long as the court believes that it is more likely that he did the deed, it will rule for Paramount.
I believe this is a civil, not a criminal case. So the standard of proof is not "beyond a reasonable doubt", but only "by the preponderance of the evidence".
Suppose a court finds that the film was uploaded from his IP address (and he wiped a machine at a suspicious time). Then even though it's concievable that he's just the victim of a drive-by uploader (and the drive-wiping was pure coincidence), a court is likely to find it more propable that he's the uploader (and was trying to cover his tracks). It would then rule in favor of Paramount.
This is precisely what general relativity says.
The idea of relativity is that no frame of reference is "special". Working this out for frames that differ by a constant velocity is pretty straightforward, but the situation with respect to rotation isn't so straightforward. If you spin yourself around you will quickly find that there does seem to be a special frame that doesn't make you dizy, which we call the non-rotating frame. To know that you are spinning, you don't appear to have to measure your rotation relative to anything else.
Einstein had the idea that really, rotation is relative, too, and this apparently special non-rotating frame is really just the frame in which you are not spinning relative to the other bodies in your region of space time. In other words, seen from a different region of the universe, maybe our region of the universe is spinning furiously, but we don't notice it because all the bodies near us are all spinning furiously together.
When you work out the math in the context of general relativity, the implication is that, near a big spinning body, for you to feel like you are not spinning you actually needs to be spinning slightly relative to what would fell like not spinning far away from the body. The effect is called frame-dragging. This experiment tried to measure the frame-dragging effect of the Earth on some extremely precise gyroscopes in orbiting satelites.
That's not quite right. It is true that Linux provides a very innovative and interesting forking model that allows you to say at fork-time which resouces are shared between a child and parent and which are not. It's true that you use this make the fork a "thread" or a "process", depending on which resources you choose to share. (And the theads of apps that use this look, confusingly, like a bunch of processes with the same PID and working set when you run ps.) But that doesn't mean that Linux beats the pants of Window's thread creation perf, because Windows creates threads faster than Linux does forks.
T(Windows thread) < T(Linux thread) ~ T(Linux process) < T(Windows process)
I didn't mean to say that there aren't some negative consequences to the choice of making threads performant and processes less so. There are, and your post correctly identifies one of them. But I think it's wrong to say that that design decision is therefore across-the-board wrong. There are times when a threaded architecture is appropriate, and that is harder to do in Unix (which is why Apache 1.x spawns processes, even though the 2.x codebase shows that threads are a better idea).
1. I have no idea what you mean by "an OS dependent language". Does that mean you believe that mono, which compiles C# in Linux, uses a little hidden copy of the windows OS? Anyway, that isn't right. C# can be compiled all the way down to the CPU's instruction set, and can therefore be used to write an OS.
2. Yes, the runtime makes things a little slower. As long as it isn't much slower, or the speed of your hardware is such that it doesn't matter for your application, this isn't a problem. (By the way, if you want your app to run really fast, you run it without an OS -- but for most people the convenience of the services the OS provides outweighs its perf hit.)
Processes in Unix are lightweight objects, and the OS spawns them left and right. Processes in Windows are heavyweight objects, and the OS creates only a handfull of them. The lightweight objects in windows are threads, and you'll notice that Windows thread creation is faster than Unix thread creation. These are just different OS design philosophies.