So I get very tired of hearing people badmouthing nVidia without giving an adequate reason why.
Here's mine: Times have changed. The Free Software community has successfully convinced the large majority of those other vendors to support Free Software properly by releasing specifications. Once upon a time, NVidia's support was "good" relative to other vendors (but, to be clear, no good in terms of the Free Software community's goals), but today better support is available from the other vendors. Since NVidia's support for Linux and the Free Software community's goals is less good then their competitors, it is absolutely appropriate for users to say so.
I saw this the other day. What struck me most is that Sony and Apple have historically had the highest failure rates in the industry (maybe other than HP), and Dell has had among the lowest. Toshiba appears to have consistently low failure rates. I'm glad to see that Apple and Sony have improved (assuming the accuracy of the report), and very disappointed at Dell's slide.
Still, as an IT support guy, those numbers don't jive with what I see. Apple laptops need warranty service far more often than this study indicates, in my experience. I'd like to know more about the methodology of the survey.
I don't see how most of those quote could be considered trolling, but especially this:
# "There are other, *easier*, ways of rooting the system. "
That's totally accurate. The policy previously allowed users who were logged in to the local console to install signed packages from a repository. No one would claim that there are no security vulnerabilities in packages within the default repositories, but they tend to be fixed very quickly after they are found, so the window for exploit using this mechanism is extremely small. People do have legitimate reasons why they wouldn't want this policy (in shared PC environments), but security is hardly one of them. Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.
I'd hate to see the guy who calls his co-opetition "masturbating monkeys" get a peace prize.:)
That aside, I firmly believe that the GPL is the reason for the success of the Linux kernel and of GNU/Linux. Compare the success of Linux and GNU/Linux to other systems which are more stable and have better documentation (like OpenBSD). There are many reasons why this might be, but I think that there would have been far fewer contributions to the Linux kernel if its license did not provide equal access for all contributors. A substantial part of Linux was written by commercial entities who would undoubtedly not be willing to invest in a product which their competition could build upon without contributing likewise in return.
We all owe a tremendous debt to RMS that I doubt will ever be repaid.
Well, actually, no it's not. Go check the definition at OSI's page.
The parent didn't say anything about the OSI definition. He said "generally taken to mean". I still assert that if you asked a substantial number of people whether access to the source code meant that an application was "open source", you would find that they generally believed that it did.
Most of the Linux users I know insist that Ubuntu "just works", and is far easier to manage than other distributions. None of them have any real experience with other distributions to support those assertions, and the help I've lent to users of the system has certainly convinced me that it's not true. If often-repeated, empty promises aren't hype, then what is?
Just like users on every other distro and platform, and if you Google problems, you will find a tonne of users for any platform, distro complaining about problems.
I'm not sure I follow you, but that's actually a point I frequently make. Ubuntu made a very positive impression on people who hadn't used it long enough to have had any problems with it. Like any complex software, it's going to have problems. My point is that Ubuntu isn't really any better than other distributions, and I'm becoming more convinced that it's not even as good.
Eating a system? What does that mean? The install failing?
In one case it was the NTFS resizer corrupting a friend's filesystem which he'd shrunk to make room for Ubuntu. Plenty of people thought that was included too early, and I have to agree. Another friend had a RAID array that he instructed the installer not to change. The installer reinitialized the array, and he lost everything therein.
I don't think you researched the distribution much and thus wouldn't know the difference between the LTS and non-LTS versions to be honest.
You could always ask. As a matter of fact, I'm quite familiar with the LTS process. However, supporting a distribution for a longer period of time isn't the same as putting the engineering and testing resources into getting the initial release right. In fact, the as the number of actively supported LTS releases increases, resources available for the new releases decrease. That brings me back to my original question: Has Canonical bitten off more than they can chew? Are releases really getting less good as time goes on? If so, what can they do to turn that around?
I wouldn't be surprised if a lot of other cars had similar problems. I was on the freeway a couple of years ago in my 2005 VW Jetta. The cruise control was still on, but was not active after I'd braked to slow down while passing through relatively denser traffic. For no apparent reason, the car began accelerating as if the "resume" button had been pressed. I didn't collide with any other drives, but it spooked me pretty good. I still use the cruise control, but I always turn it off entirely as soon as I decide to slow down.
I never really bought in to the Ubuntu hype. A lot of users had good things to say about their early releases, but I never actually saw a reason to believe that they were better or easier than other distributions. I did, however, see their installer eat several friends' systems, which gave me a lot of reason to believe the opposite.
With each release of Ubuntu, I hear a larger number of complaints. I've mostly come to the conclusion that Canonical took their time to get the first release right, but has bitten off more than they can chew with the 6 month release cycle. They don't seem to have the resources to keep up the quality that they managed with their early releases.
I would agree with you, except that your range of motion tends to be greater left to right than it is forward and back. That means that it's easier to move your mouse along horizontal controls.
Rotating your screen solves the problem much better. You maintain the horizontal mouse-friendly controls and get more vertical viewing area.
You mean section 6b. There are no subsections to section 3. Section 6 provides five options for conveying non-source forms of the software. Any one is allowed. One of them allows you to convey a non-source form if you include a written offer to give the source code to anyone who possesses the object code (subject to a fee if the conveyance is via physical media).
For someone lecturing people on reading the GPL, you've done a poor job of it yourself. The AC you were lecturing was correct, more or less. You are required to offer the source code only to the parties to whom you've given the object code, or possibly parties to whom they've given the code. You are not required to publish the code to "any third party" who requests it.
Which must be either "0" or "(void *) 0".... There are indeed some platforms where a null pointer is not an all-bits-zero value, but this is achieved by compiler magic behind the scenes. It is still created by assigning the constant value 0 to a pointer, and can be checked for by comparing a pointer with a constant 0.
What you've said is technically true, but doesn't contradict or clarify the post to which you replied in any way, so I'm not sure what your point is.
As you point out, a NULL pointer is a pointer which is represented by "(void *) 0" in the C language. However, where you may be confused is that "(void *) 0 != (int) 0". At least, not always. The compiler is responsible for determining if any "0" is used in a pointer context and casting it to the appropriate value, which may not be the same as numeric "0". So, while it's always possible to check for a NULL pointer by comparing a pointer to 0 in code, the machine may use a different value for NULL pointers. When you check "if(p)", the binary code that is produced will be comparing the value of "p" to the NULL address which is appropriate for the machine on which it is running.
There are certainly benchmarks that indicate so, but they're primarily javascript benchmarks, not graphics intensive benchmarks. The consensus among the experts is that this is because the compilers used on Windows are generally better at producing fast code than gcc, and also that the Windows builds of Firefox used guided optimizations, while the Linux builds do not. This has nothing at all to do with X11.
Flash runs faster on Windows
I don't know if that's true or not, but pointing out that a program which was ported to X11 and is generally known best for poor quality is not an indication of problems in X11. Flash isn't well done on GNU/Linux.
As I've been pointing out in this entire conversation, you seem to be blaming X11 for perceived slowness in desktop applications. Despite what you've heard, X11 isn't the cause.
This is just details, the fact of the matter is that Microsoft, Apple, and even Be had much faster methods of accessing video hardware and displaying things on the screen.
Unless you have numbers to back it up, that is an assertion, and not "the fact of the matter". Many benchmarks have shown that OpenGL on Linux is faster than Windows in some configurations. I can't say "most", since I don't have numbers either, but objective benchmarks of both native OpenGL applications and even applications running under Wine do show that X11 is not only acceptable, but faster than Windows. Do you have anything to back up your assertions, or are you just spouting off about your subjective experience that the GNU desktop software feels slow? The latter is something a lot of people complain about, but it's not actually X11's fault.
Whether or not it's constrained to a single socket, it's constrained to a socket model and thus the filesystem IO interface.
1: You completely missed what I said. Locally run processes don't use the sockets; they use shared memory. 2: While file IO and socket IO both use read() and write(), there's no "filesystem" layer involved in socket IO. 3: There's nothing actually wrong with socket IO, even if it were being used. Which it's not.
DRI/DRM are not really broad enough for modern graphics hardware, anyway.
Again, do you have any idea why not, or are you just repeating complaints that you've heard other people make? Did they have any details about why DRI wouldn't be a suitable design?
Any graphical application from video playback to 3d will always perform better on Windows than Linux on the same hardware.
That is far from true. I won't say that X11 is always faster than Windows, and I don't have enough data to say that it's usually faster than Windows, but there are many benchmarks that show that it is sometimes after than Windows. Your belief sounds like it's founded on "common knowledge" rather than actual measurements. You're way off base.
most things on Linux UI are X-based which means most communication is serialized through a single socket and much information is stored redundantly in the app and the X-server.
You say "single socket" as if all of the X clients were contending for a resource. Every connection accepted by a server (any server) creates a new file descriptor in that process. There's no more a problem with a "single socket" in X11 than there is in any other server.
Moreover, unless all of your applications are running over the network, they're almost certainly using shared memory rather than file IO (through the socket) for display. Your entire characterization of X11 shows how little you know about how it works.
Hell there's dedicated VGA mode for games in existing Linux.
What, you mean framebuffer? Yes, it exists, but it's extremely slow. If there are games that use it, I still wouldn't characterize it as being "for games". OpenGL under X11 is definitely the preferred setup for accelerated video.
I don't think so... It's recommended that you compress things before you encrypt them if you plan to do both (usually for network transmission). If you encrypt and then compress, your compression will not be very effective. Good encryption produces very few patterns, and patterns are what compression applications need in order to function.
1: The financial impact in this case was a result of Katzer's refusal to comply with the license. It was not an automatic result of his use of the code in question, but his failure to take corrective action when notified of his infringement.
2: Proprietary code may include proprietary components in violation of their license just as easily as it can contain Free Software components in violation of their license. The risk involved in using code licensed from a third party carries exactly the same risks whether or not it is Free Software.
Slashdot Mirror
So I get very tired of hearing people badmouthing nVidia without giving an adequate reason why.
Here's mine: Times have changed. The Free Software community has successfully convinced the large majority of those other vendors to support Free Software properly by releasing specifications. Once upon a time, NVidia's support was "good" relative to other vendors (but, to be clear, no good in terms of the Free Software community's goals), but today better support is available from the other vendors. Since NVidia's support for Linux and the Free Software community's goals is less good then their competitors, it is absolutely appropriate for users to say so.
Hilarious, until she finds out that you've advised shoving an RF transceiver in your ear canal in order to reduce RF exposure, then things get ugly...
People frequently point that out without acknowledging that a Bluetooth headset transmits at about 1% the power of a cell phone.
Not only do those explode quite spectacularly, but the shards are amazingly sharp. I don't envy the person who had to clean up that mess.
That all sounds nice, but have they built a system that draws less power than a comparable Athlon 64 system?
In other news, thousands of corporate gpl users reevaluate violating the license.
Fixed that for you.
I feel dirty.
I thought slashdot ran a story on the Dunning-Kruger effect fairly recently. Am I imagining things?
I saw this the other day. What struck me most is that Sony and Apple have historically had the highest failure rates in the industry (maybe other than HP), and Dell has had among the lowest. Toshiba appears to have consistently low failure rates. I'm glad to see that Apple and Sony have improved (assuming the accuracy of the report), and very disappointed at Dell's slide.
Still, as an IT support guy, those numbers don't jive with what I see. Apple laptops need warranty service far more often than this study indicates, in my experience. I'd like to know more about the methodology of the survey.
I don't see how most of those quote could be considered trolling, but especially this:
# "There are other, *easier*, ways of rooting the system. "
That's totally accurate. The policy previously allowed users who were logged in to the local console to install signed packages from a repository. No one would claim that there are no security vulnerabilities in packages within the default repositories, but they tend to be fixed very quickly after they are found, so the window for exploit using this mechanism is extremely small. People do have legitimate reasons why they wouldn't want this policy (in shared PC environments), but security is hardly one of them. Users who have physical access to a computer can compromise it far more easily than waiting for a vulnerability to be found in a package that isn't installed, installing that package before an update is issued, and exploiting the vulnerability.
The announcement is correct. PackageKit requires the root password, not the user's own, to add or update packages from the local console.
I'd hate to see the guy who calls his co-opetition "masturbating monkeys" get a peace prize. :)
That aside, I firmly believe that the GPL is the reason for the success of the Linux kernel and of GNU/Linux. Compare the success of Linux and GNU/Linux to other systems which are more stable and have better documentation (like OpenBSD). There are many reasons why this might be, but I think that there would have been far fewer contributions to the Linux kernel if its license did not provide equal access for all contributors. A substantial part of Linux was written by commercial entities who would undoubtedly not be willing to invest in a product which their competition could build upon without contributing likewise in return.
We all owe a tremendous debt to RMS that I doubt will ever be repaid.
Well, actually, no it's not. Go check the definition at OSI's page.
The parent didn't say anything about the OSI definition. He said "generally taken to mean". I still assert that if you asked a substantial number of people whether access to the source code meant that an application was "open source", you would find that they generally believed that it did.
I do not think that that is what "Open Source" is generally taken to mean.
Well, yes, it is. That's why you will so frequently see people insist that "Free Software" is a better term.
There was hype? Where?
Most of the Linux users I know insist that Ubuntu "just works", and is far easier to manage than other distributions. None of them have any real experience with other distributions to support those assertions, and the help I've lent to users of the system has certainly convinced me that it's not true. If often-repeated, empty promises aren't hype, then what is?
Just like users on every other distro and platform, and if you Google problems, you will find a tonne of users for any platform, distro complaining about problems.
I'm not sure I follow you, but that's actually a point I frequently make. Ubuntu made a very positive impression on people who hadn't used it long enough to have had any problems with it. Like any complex software, it's going to have problems. My point is that Ubuntu isn't really any better than other distributions, and I'm becoming more convinced that it's not even as good.
Eating a system? What does that mean? The install failing?
In one case it was the NTFS resizer corrupting a friend's filesystem which he'd shrunk to make room for Ubuntu. Plenty of people thought that was included too early, and I have to agree. Another friend had a RAID array that he instructed the installer not to change. The installer reinitialized the array, and he lost everything therein.
I don't think you researched the distribution much and thus wouldn't know the difference between the LTS and non-LTS versions to be honest.
You could always ask. As a matter of fact, I'm quite familiar with the LTS process. However, supporting a distribution for a longer period of time isn't the same as putting the engineering and testing resources into getting the initial release right. In fact, the as the number of actively supported LTS releases increases, resources available for the new releases decrease. That brings me back to my original question: Has Canonical bitten off more than they can chew? Are releases really getting less good as time goes on? If so, what can they do to turn that around?
I wouldn't be surprised if a lot of other cars had similar problems. I was on the freeway a couple of years ago in my 2005 VW Jetta. The cruise control was still on, but was not active after I'd braked to slow down while passing through relatively denser traffic. For no apparent reason, the car began accelerating as if the "resume" button had been pressed. I didn't collide with any other drives, but it spooked me pretty good. I still use the cruise control, but I always turn it off entirely as soon as I decide to slow down.
I never really bought in to the Ubuntu hype. A lot of users had good things to say about their early releases, but I never actually saw a reason to believe that they were better or easier than other distributions. I did, however, see their installer eat several friends' systems, which gave me a lot of reason to believe the opposite.
With each release of Ubuntu, I hear a larger number of complaints. I've mostly come to the conclusion that Canonical took their time to get the first release right, but has bitten off more than they can chew with the 6 month release cycle. They don't seem to have the resources to keep up the quality that they managed with their early releases.
I would agree with you, except that your range of motion tends to be greater left to right than it is forward and back. That means that it's easier to move your mouse along horizontal controls.
Rotating your screen solves the problem much better. You maintain the horizontal mouse-friendly controls and get more vertical viewing area.
Oh fuck, and shame on me. I'm looking at a copy of v3 that I was sure was v2. Reading comprehension failure. Hilarious.
All the same, 3b is one of three options. You are not required to publish the code to any third party unless you opt not to follow either 3a or 3c.
You mean section 6b. There are no subsections to section 3. Section 6 provides five options for conveying non-source forms of the software. Any one is allowed. One of them allows you to convey a non-source form if you include a written offer to give the source code to anyone who possesses the object code (subject to a fee if the conveyance is via physical media).
For someone lecturing people on reading the GPL, you've done a poor job of it yourself. The AC you were lecturing was correct, more or less. You are required to offer the source code only to the parties to whom you've given the object code, or possibly parties to whom they've given the code. You are not required to publish the code to "any third party" who requests it.
Which must be either "0" or "(void *) 0". ...
There are indeed some platforms where a null pointer is not an all-bits-zero value, but this is achieved by compiler magic behind the scenes. It is still created by assigning the constant value 0 to a pointer, and can be checked for by comparing a pointer with a constant 0.
What you've said is technically true, but doesn't contradict or clarify the post to which you replied in any way, so I'm not sure what your point is.
As you point out, a NULL pointer is a pointer which is represented by "(void *) 0" in the C language. However, where you may be confused is that "(void *) 0 != (int) 0". At least, not always. The compiler is responsible for determining if any "0" is used in a pointer context and casting it to the appropriate value, which may not be the same as numeric "0". So, while it's always possible to check for a NULL pointer by comparing a pointer to 0 in code, the machine may use a different value for NULL pointers. When you check "if(p)", the binary code that is produced will be comparing the value of "p" to the NULL address which is appropriate for the machine on which it is running.
The C FAQ has more information.
Firefox runs faster on Windows
There are certainly benchmarks that indicate so, but they're primarily javascript benchmarks, not graphics intensive benchmarks. The consensus among the experts is that this is because the compilers used on Windows are generally better at producing fast code than gcc, and also that the Windows builds of Firefox used guided optimizations, while the Linux builds do not. This has nothing at all to do with X11.
Flash runs faster on Windows
I don't know if that's true or not, but pointing out that a program which was ported to X11 and is generally known best for poor quality is not an indication of problems in X11. Flash isn't well done on GNU/Linux.
As I've been pointing out in this entire conversation, you seem to be blaming X11 for perceived slowness in desktop applications. Despite what you've heard, X11 isn't the cause.
This is just details, the fact of the matter is that Microsoft, Apple, and even Be had much faster methods of accessing video hardware and displaying things on the screen.
Unless you have numbers to back it up, that is an assertion, and not "the fact of the matter". Many benchmarks have shown that OpenGL on Linux is faster than Windows in some configurations. I can't say "most", since I don't have numbers either, but objective benchmarks of both native OpenGL applications and even applications running under Wine do show that X11 is not only acceptable, but faster than Windows. Do you have anything to back up your assertions, or are you just spouting off about your subjective experience that the GNU desktop software feels slow? The latter is something a lot of people complain about, but it's not actually X11's fault.
Whether or not it's constrained to a single socket, it's constrained to a socket model and thus the filesystem IO interface.
1: You completely missed what I said. Locally run processes don't use the sockets; they use shared memory.
2: While file IO and socket IO both use read() and write(), there's no "filesystem" layer involved in socket IO.
3: There's nothing actually wrong with socket IO, even if it were being used. Which it's not.
DRI/DRM are not really broad enough for modern graphics hardware, anyway.
Again, do you have any idea why not, or are you just repeating complaints that you've heard other people make? Did they have any details about why DRI wouldn't be a suitable design?
Any graphical application from video playback to 3d will always perform better on Windows than Linux on the same hardware.
That is far from true. I won't say that X11 is always faster than Windows, and I don't have enough data to say that it's usually faster than Windows, but there are many benchmarks that show that it is sometimes after than Windows. Your belief sounds like it's founded on "common knowledge" rather than actual measurements. You're way off base.
most things on Linux UI are X-based which means most communication is serialized through a single socket and much information is stored redundantly in the app and the X-server.
You say "single socket" as if all of the X clients were contending for a resource. Every connection accepted by a server (any server) creates a new file descriptor in that process. There's no more a problem with a "single socket" in X11 than there is in any other server.
Moreover, unless all of your applications are running over the network, they're almost certainly using shared memory rather than file IO (through the socket) for display. Your entire characterization of X11 shows how little you know about how it works.
Hell there's dedicated VGA mode for games in existing Linux.
What, you mean framebuffer? Yes, it exists, but it's extremely slow. If there are games that use it, I still wouldn't characterize it as being "for games". OpenGL under X11 is definitely the preferred setup for accelerated video.
Fedora 11 has been out for two hours. You've already downloaded it, evaluated it, and switched some of your servers to a different distribution?
You work faster than anyone I've ever met. I am humbled by your awesome ability.
I don't think so... It's recommended that you compress things before you encrypt them if you plan to do both (usually for network transmission). If you encrypt and then compress, your compression will not be very effective. Good encryption produces very few patterns, and patterns are what compression applications need in order to function.
It's important to bear two things in mind:
1: The financial impact in this case was a result of Katzer's refusal to comply with the license. It was not an automatic result of his use of the code in question, but his failure to take corrective action when notified of his infringement.
2: Proprietary code may include proprietary components in violation of their license just as easily as it can contain Free Software components in violation of their license. The risk involved in using code licensed from a third party carries exactly the same risks whether or not it is Free Software.