On this subject: I finally got around to reading Anandtech's very long article about the current crop of SSD drives. I feel like it was pretty educational, which is good because it took a long time to digest.
In its discussion of performance degradation as drives are used, the article explains that individual pages of NAND memory can't be rewritten. Early in a drive's life, page are remapped when they are rewritten by the OS. As the drive is used, the drive runs out of pages to remap and is forced to copy a block (typically a 512KiB collection of 4KiB pages) to cache, erase the block and then rewrite the block with the new pages. That explains pretty well why write performance degrades, since writing to a block that has data must perform a read and erase operation in addition to the write. However, that explanation also leaves open the question of how the drive prevents data loss if it loses power. Worst case, the OS issues a write and the drive copies a 512KiB block to cache and erases the block, and then loses power. Due to remapping, literally anything could be in that half a MiB. The data loss could corrupt the file that was being modified, obviously, but also any other file on the drive, or parts of the filesystem itself.
I figure there's got to be protection against data loss built-in, but I'm not able to find details regarding any individual drive or manufacturer's approach to solving that problem. Does anyone know more about this subject?
No, it's not. The only way growth would be exponential is if each new tab caused each of the existing tabs to increase in size according to the number of open tabs. It is not accurate to describe the growth of memory utilization in a browser relative to the number of tabs as exponential.
It's pretty difficult to see this story as representative of a legitimate concern, at least of any informed person. Among all of the major distributions of Linux, Red Hat is probably the most Free Software oriented (except perhaps for Debian). As a member of OIN, they contribute patents licensed to other members in order to create a defence against patent lawsuits. They've repeatedly and consistently put their money into Free Software by purchasing desirable products and re-licensing them under the GPL. They're one of the largest contributors of code to the Linux kernel, GNU libc, gcc, GNOME, and other core components of GNU/Linux distributions.
And after all of that, the very notion of Red Hat suiting up to sue Free Software developers is completely ridiculous, because doing so would void their license to distribute the software.
This article is just another troll painting one of the Free Software community's leaders in an undeserved poor light. Whether the author is completely ignorant of the subject matter, or is intentionally trolling, this story deserves a place in the dust bin.
Don't be stupid. Verizon is planning to block outbound port 25 like a lot of other ISPs do in order to prevent trojans from sending out email. It's not their business to impose a requirement that other mail providers use their choice of STARTTLS on 587 or SSL on 465.
If anyone is failing to do SSL, it has nothing to do with Verizon blocking outbound port 25, and Verizon should in no way be scolded for taking this step.
You do realize that SMTP on port 25 and MSA on port 587 are the same protocol, right? There's no way that one can be hokey and the other not. In both cases, STARTTLS can be used, and should be required before authentication is allowed.
Providers should universally provide service on 587 in order to allow other ISPs to block outbound port 25, but arguing that authentication on 25 is hokey is just silly. The only reason not to bother is that sooner or later, port 25 is going to be blocked by the ISPs of remote users, and you really ought to be providing service on 587.
However, the text of the GPL forbids you from (for instance) building an application which depends on a GPL licensed library and distributing that application under terms that are not compatible with the GPL. If you do so, you will soon find that you need a lawyer.
Specialized hardware will always be faster and use less power to do a specific job than general-purpose hardware like your CPU.
Not "always", and not "and".
Specialized hardware will usually be faster than the CPU, and will usually yield an overall faster system by virtue of the fact that the CPU is free from those tasks.
However (and purely as an example), Linux's software RAID is faster than many hardware RAID controllers, and a system lacking a dedicated hardware RAID controller very well may use less power than an equivalent system with one.
Not only that, but I used the wrong term entirely. The correct term was "based on". I apologize.
Does that mean that they've taken a derived work of Windows and made it LGPL?
No, but they have created a work that is arguably based on the Win32 interface. If the license for the Win32 interface stipulated the terms that were suitable for works based on it, then QT would have to comply. I don't believe that any such license requirements exist for the Win32 platform, which makes it an unsuitable analogy.
Whatever the case may be, what's to stop some company from reverse engineering the SDK and putting out a plugin with whatever license they choose?
A court, I'd assume. If you create a plugin to an application and believe that your work is not based on said application, you might have to defend that view before a judge.
Just give out your own work, alone, not linked to the GPL'ed work. Problem solved.
If your work, alone, doesn't do anything useful, then you probably will not be successful in convincing a judge that your work is not "based on" gcc, and subject to its license.
If the license for Microsoft's DLLs specified restrictions on the applications that used them, then the question would be more relevant. I don't believe that Microsoft places any such requirements on applications that use their platform.
You should note that this is a different situation than glibc on GNU/Linux. Applications using glibc are generally not considered to be based on that library, since its API is similar to other POSIX systems.
I apologize for not using the terminology from the appropriate license. Compiler plugins are definitely work "based on" GPL licensed code, and must be covered by a compatible license. Anyone who believes otherwise may have to defend that position in court.
Does this mean they want to force all plugins to use the GPL? How is that possible?
A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.
Some applications allow plugins or modules under incompatible licenses, but in those cases, it is the applications' authors prerogative to grant exceptions for plugins.
A programming language deserves a "cleanup" every now and then - this is such a thing. Hey, people have survived worse things, like gcc version changes, Qt3 => Qt4, Gtk 1 => Gtk2...
GNOME has a nice tool that allows you to configure the position, resolution, and rotation of your monitors. On a Fedora system, it's under System->Preferences->Hardware->Screen Resolution.
It seems to be conventional wisdom that Ubuntu is easier to use than other GNU/Linux distributions, but I have far fewer issues with my Fedora (GNOME) desktop (and laptop) than the Ubuntu users that I know. For that matter, I have fewer issues than the OS X and Windows users that I know.;)
"Psystar is accusing Apple of bricking generic PCs that are attempting to illegally run OS X"
It is not illegal to run OS X on generic PCs. It is a violation of the license, but the license does not carry the force of law. At this point, I'm not even sure that it's been settled that licenses are enforcible, given that their terms aren't available prior to the customer paying for the product, which makes it a sale or purchase.
Too bad they used Windows to show it performing about twice as fast as the Linux test...
The tests were nothing alike. The Linux demo was sending data to an actual storage device, not to a loopback device designed only to test throughput. The Linux driver also had a great deal of debugging code running which contributed to the relatively low throughput.
None of which is to say that Linux was or deserved to be the star of this show. It's nice, however, to see technology vendors demonstrating software on platforms other than Windows.
An awful lot of people are looking down their noses at USB 3 because it's not Firewire. Has everyone forgotten that Firewire grants devices DMA access to physical memory? Any physically connected device can be used to bypass the system's security. I'm grateful that USB isn't more like Firewire.
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
If you regularly need to install custom packages on remote hosts then the straightforward solution would be to setup a public package mirror. It isn't much work, you have to do it only once and it removes all these nasty dependency problems from your on-site workflow.
No, it doesn't "remove" the dependency problems at all. Yum and apt will both have to resolve the dependencies to install the package. Creating a repository only solves a problem that exists with apt and doesn't with yum.
In other words: I think you see this as a nasty dependency problem because it would be on a system using apt. On systems using yum, there is no nasty dependency problem.
Furthermore, when working with a package manager you should never have to know that a file by the name 'libstdc++.so.5' even exists on your system. The moment that this information is exposed to the user the package manager has failed to do its job. It is one of its primary purposes to hide these nasty details from the user, after all.
That's a fine sentiment, but it ignores the reality that people want to, and will install software that doesn't come from a vendor with a package repository. Lightning comes as an XPI for thunderbird, and if there's a dependency issue (not one reported by a package, but by a library that's not available), yum provides the tools to resolve it much more easily than apt. Other customers might run Mathematica or some other package that wasn't packaged conveniently. When that happens, you will see the name of the library that's required which you don't have, and will have to resolve the problem. Package managers can't hide that from you, but they can provide you the tools you need to handle it without a struggle.
Different story, same problem. Ever heard of CPAN? It's generally a bad idea to install perl- (/python-/ruby-, whatever) modules from a distro repository in order to satisfy a dependency for a file that is not *also* in the distro repository.
That's a ridiculous assertion with no argument to back it up. You actually made a more convincing argument for the opposite: you shouldn't install modules from CPAN to satisfy a dependency that is provided by your distribution's repository. You really want to use the distribution's packages whenever possible, and yum does a better job of resolving dependencies for scripts and programs that aren't in a repository.
Now you sound a bit like Darth Vader, advertising the dark side.;-)
If you think that yum is "the dark side", then you're probably not open to considering alternative points of view. You claimed not to be a zealot, but you're sure starting to sound like one.
The question to which I was responding was (paraphrased): "What advantages does yum have over apt?" I've answered that by pointing out capabilities that yum has which apt does not, and situations where they are useful. You haven't pointed out equivalent functionality in apt, or shown that I'm wrong. Instead you've argued that I shouldn't use the additional features of yum. Would you say that's a fair assessment of this conversation?
From my perspective, apt forces you to work with only packages that are in a repository. Yum will do that, and also help you work with packages that you received from a vendor who doesn't have a repository, and with scripts and programs that weren't packaged to begin with. I think that's a strong advantage, despite the fact that I agree with you and prefer not to install software without packaging it. If you disagree, consider this: Do you think that it would be an advantage to modify dpkg and rpm so that they were only usable by apt/yum? It would force administrators to do things "the right way", by packaging all of their software and putting it in repositories. Do you think administrators would favor that policy?
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
features that you mentioned seem pretty much useless to me.
That's probably because you don't have them. You've built a workflow around the tools you have; that's what people do.
I'm a consultant, so I work on a lot of hosts that were set up by someone else. They aren't going to have my own personal repositories set up on them, so working with packages that aren't in a repository is essential to me.
Using "provides" is non-trivial, too. Consider that if you install the Lightning extension to Thunderbird on a current (32 bit) machine, it won't work. Why? Well:
$ ldd.thunderbird/*/extensions/*/components/*.so | grep 'not found'/usr/lib/libstdc++.so.5 => not found
They built against an old version of libstdc++. We'll need that:
# yum install libstdc++.so.5
How else would I know that the library is provided by compat-libstdc++-33? Or that libcucul.so.0 is provided by a package named libcaca?
The same is true of perl. If I download a script and it complains that it can't find Date/Format.pm, I can ask yum to get it:
# yum install 'perl(Date::Format)'
How else would I know that Date/Format.pm is in perl-TimeDate rather than perl-DateTime or perl-Date-Simple?
If you live entirely within the repository, then apt is fine. If you ever want to use something that's not there yet, yum is a much superior tool.
Re:But does it run on .... shit that does not work
on
Fedora 10 Released
·
· Score: 1
Good god, like what? I haven't found *anything* yum does better than apt.
Off the top of my head, it can install packages based on filenames or "provides" if you don't know the package name. It can also install a local package and resolve dependencies from repositories. apt can't do any of those things.
In Phoronix's original test, Ubuntu 7.04 (and sometimes 7.10) performed twice as fast as later releases. When later compared to Fedora, they showed that Fedora's numbers were fairly consistent over the last two years, and close to the same as recent Ubuntu releases. It seems like either something was wrong with the benchmark run on the 7.04 release or there was a huge change after 7.04. Has anyone explained that?
Rather, GPL is incompatible with anything else that can't be re-licensed as GPL... May first we clear that mess, right ?
Please, let's.
First and foremost: only the original author or copyright holder may re-license any copyrighted work. Period. Including software under licenses like BSD in GPL copyrighted works does not re-license the BSD code. The BSD licensed code remains under the BSD license; it continues to allow re-use under the BSD terms.
Nvidia? That'd be just awesome. I can't think of any other way to make Apple hardware (already more prone to need warranty service than any other manufacturer's product that I can name) any less reliable. Go go gadget failure!
I don't know how many projects have asked Slashdot not to link to bugzilla. It makes the system unusable for the developers trying to get work done.
Here's the text currently in the bugzilla entry (edited to meet slashdot's filter requirements):
Bug 379791 - perl bless/overload performance problem Summary: perl bless/overload performance problem Status: VERIFIED Product: Red Hat Enterprise Linux 5 Component: perl (Show Red Hat Enterprise Linux 5/perl bugs) Version: 5.2 Platform: All Linux Priority: urgent Severity: high Target Milestone: rc Assigned To: Marcela Maslanova QA Contact: desktop-bugs@redhat.com URL: Whiteboard: GSSApproved Keywords: ZStream Depends on: Blocks:
Reported: 2007-11-13 07:14 EDT by Nigel Metheringham Modified: 2008-08-29 10:30 EDT (History) Fixed In Version: Release Notes:
Description From Nigel Metheringham 2007-11-13 07:14:04 EDT
RHEL5 perl shows the same performance issues as the Fedora 7 perl did - see Bug #196836 and Bug #253728
This has been demonstrated in the recent perl update perl-5.8.8-10.el5_0.2
Same fix needs taking across to RHEL, ideally as a update release rather than waiting for next major release cycle.
I do not have RHEL5.1 to test against right now, but the timing of the Fedora fixes leads me to believe these would be much too late for the 5.1 release cycle.
-- Comment #2 From Martin Kutter 2007-11-30 05:24:01 EDT -- The issue can be observed running the benchmark script from the recent SOAP::WSDL package.
To do so, download SOAP-WSDL-2.00_24 (and its dependencies) from CPAN, run perl Build.PL && perl Build, cd into benchmark and run perl -I../blib/lib 01_expat.t
This is the Output from RHEL4: perl -I../lib 01_expat.t Name "DB::packages" used only once: possible typo at 01_expat.t line 2. Benchmark: timing 5000 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD (SOAP::WSDL)... Hash (SOAP:WSDL): 4 wallclock secs ( 3.48 usr + 0.01 sys = 3.49 CPU) @1432.66/s (n=5000) XML::Simple (Hash): 7 wallclock secs ( 7.19 usr + 0.03 sys = 7.22 CPU) @692.52/s (n=5000) XSD (SOAP::WSDL): 6 wallclock secs ( 6.06 usr + 0.01 sys = 6.07 CPU) @823.72/s (n=5000)
And this (with reduced n) is from RHEL5 (different machine, perl-5.8.8-10):
Increasing the number of runs shows the O(n^2) nature of the performance problem - increasing the number of runs by a factor of 10 increases the runtime for the XSD bench by a factor of nearly 100:
-- Comment #3 From RHEL Product and Program Management 2007-12-03 15:47:35 EDT -- This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the cur
Slashdot Mirror
On this subject: I finally got around to reading Anandtech's very long article about the current crop of SSD drives. I feel like it was pretty educational, which is good because it took a long time to digest.
In its discussion of performance degradation as drives are used, the article explains that individual pages of NAND memory can't be rewritten. Early in a drive's life, page are remapped when they are rewritten by the OS. As the drive is used, the drive runs out of pages to remap and is forced to copy a block (typically a 512KiB collection of 4KiB pages) to cache, erase the block and then rewrite the block with the new pages. That explains pretty well why write performance degrades, since writing to a block that has data must perform a read and erase operation in addition to the write. However, that explanation also leaves open the question of how the drive prevents data loss if it loses power. Worst case, the OS issues a write and the drive copies a 512KiB block to cache and erases the block, and then loses power. Due to remapping, literally anything could be in that half a MiB. The data loss could corrupt the file that was being modified, obviously, but also any other file on the drive, or parts of the filesystem itself.
I figure there's got to be protection against data loss built-in, but I'm not able to find details regarding any individual drive or manufacturer's approach to solving that problem. Does anyone know more about this subject?
No, it's not. The only way growth would be exponential is if each new tab caused each of the existing tabs to increase in size according to the number of open tabs. It is not accurate to describe the growth of memory utilization in a browser relative to the number of tabs as exponential.
It's pretty difficult to see this story as representative of a legitimate concern, at least of any informed person. Among all of the major distributions of Linux, Red Hat is probably the most Free Software oriented (except perhaps for Debian). As a member of OIN, they contribute patents licensed to other members in order to create a defence against patent lawsuits. They've repeatedly and consistently put their money into Free Software by purchasing desirable products and re-licensing them under the GPL. They're one of the largest contributors of code to the Linux kernel, GNU libc, gcc, GNOME, and other core components of GNU/Linux distributions.
And after all of that, the very notion of Red Hat suiting up to sue Free Software developers is completely ridiculous, because doing so would void their license to distribute the software.
This article is just another troll painting one of the Free Software community's leaders in an undeserved poor light. Whether the author is completely ignorant of the subject matter, or is intentionally trolling, this story deserves a place in the dust bin.
If RedHat was really serious about the patents being defensive, wouldn't it make sense for them to donate them to an open source patent pool?
As Red Hat is a member of the Open Invention Network, a group dedicated to creating a pool of defensive patents, that is likely to happen.
Don't be stupid. Verizon is planning to block outbound port 25 like a lot of other ISPs do in order to prevent trojans from sending out email. It's not their business to impose a requirement that other mail providers use their choice of STARTTLS on 587 or SSL on 465.
If anyone is failing to do SSL, it has nothing to do with Verizon blocking outbound port 25, and Verizon should in no way be scolded for taking this step.
You do realize that SMTP on port 25 and MSA on port 587 are the same protocol, right? There's no way that one can be hokey and the other not. In both cases, STARTTLS can be used, and should be required before authentication is allowed.
Providers should universally provide service on 587 in order to allow other ISPs to block outbound port 25, but arguing that authentication on 25 is hokey is just silly. The only reason not to bother is that sooner or later, port 25 is going to be blocked by the ISPs of remote users, and you really ought to be providing service on 587.
I'm not a lawyer, that is true.
However, the text of the GPL forbids you from (for instance) building an application which depends on a GPL licensed library and distributing that application under terms that are not compatible with the GPL. If you do so, you will soon find that you need a lawyer.
Specialized hardware will always be faster and use less power to do a specific job than general-purpose hardware like your CPU.
Not "always", and not "and".
Specialized hardware will usually be faster than the CPU, and will usually yield an overall faster system by virtue of the fact that the CPU is free from those tasks.
However (and purely as an example), Linux's software RAID is faster than many hardware RAID controllers, and a system lacking a dedicated hardware RAID controller very well may use less power than an equivalent system with one.
You sir do not understand what "derived" means.
Not only that, but I used the wrong term entirely. The correct term was "based on". I apologize.
Does that mean that they've taken a derived work of Windows and made it LGPL?
No, but they have created a work that is arguably based on the Win32 interface. If the license for the Win32 interface stipulated the terms that were suitable for works based on it, then QT would have to comply. I don't believe that any such license requirements exist for the Win32 platform, which makes it an unsuitable analogy.
Whatever the case may be, what's to stop some company from reverse engineering the SDK and putting out a plugin with whatever license they choose?
A court, I'd assume. If you create a plugin to an application and believe that your work is not based on said application, you might have to defend that view before a judge.
Just give out your own work, alone, not linked to the GPL'ed work. Problem solved.
If your work, alone, doesn't do anything useful, then you probably will not be successful in convincing a judge that your work is not "based on" gcc, and subject to its license.
If the license for Microsoft's DLLs specified restrictions on the applications that used them, then the question would be more relevant. I don't believe that Microsoft places any such requirements on applications that use their platform.
You should note that this is a different situation than glibc on GNU/Linux. Applications using glibc are generally not considered to be based on that library, since its API is similar to other POSIX systems.
I apologize for not using the terminology from the appropriate license. Compiler plugins are definitely work "based on" GPL licensed code, and must be covered by a compatible license. Anyone who believes otherwise may have to defend that position in court.
Does this mean they want to force all plugins to use the GPL? How is that possible?
A plugin uses the host application's API. It is, therefore a derived work. In the case of the GPL, derived works must be distributed under compatible licenses.
Some applications allow plugins or modules under incompatible licenses, but in those cases, it is the applications' authors prerogative to grant exceptions for plugins.
A programming language deserves a "cleanup" every now and then - this is such a thing. Hey, people have survived worse things, like gcc version changes, Qt3 => Qt4, Gtk 1 => Gtk2...
Not to mention Perl4 -> Perl5.
GNOME has a nice tool that allows you to configure the position, resolution, and rotation of your monitors. On a Fedora system, it's under System->Preferences->Hardware->Screen Resolution.
It seems to be conventional wisdom that Ubuntu is easier to use than other GNU/Linux distributions, but I have far fewer issues with my Fedora (GNOME) desktop (and laptop) than the Ubuntu users that I know. For that matter, I have fewer issues than the OS X and Windows users that I know. ;)
"Psystar is accusing Apple of bricking generic PCs that are attempting to illegally run OS X"
It is not illegal to run OS X on generic PCs. It is a violation of the license, but the license does not carry the force of law. At this point, I'm not even sure that it's been settled that licenses are enforcible, given that their terms aren't available prior to the customer paying for the product, which makes it a sale or purchase.
Too bad they used Windows to show it performing about twice as fast as the Linux test ...
The tests were nothing alike. The Linux demo was sending data to an actual storage device, not to a loopback device designed only to test throughput. The Linux driver also had a great deal of debugging code running which contributed to the relatively low throughput.
None of which is to say that Linux was or deserved to be the star of this show. It's nice, however, to see technology vendors demonstrating software on platforms other than Windows.
An awful lot of people are looking down their noses at USB 3 because it's not Firewire. Has everyone forgotten that Firewire grants devices DMA access to physical memory? Any physically connected device can be used to bypass the system's security. I'm grateful that USB isn't more like Firewire.
If you regularly need to install custom packages on remote hosts then the straightforward solution would be to setup a public package mirror. It isn't much work, you have to do it only once and it removes all these nasty dependency problems from your on-site workflow.
No, it doesn't "remove" the dependency problems at all. Yum and apt will both have to resolve the dependencies to install the package. Creating a repository only solves a problem that exists with apt and doesn't with yum.
In other words: I think you see this as a nasty dependency problem because it would be on a system using apt. On systems using yum, there is no nasty dependency problem.
Furthermore, when working with a package manager you should never have to know that a file by the name 'libstdc++.so.5' even exists on your system. The moment that this information is exposed to the user the package manager has failed to do its job. It is one of its primary purposes to hide these nasty details from the user, after all.
That's a fine sentiment, but it ignores the reality that people want to, and will install software that doesn't come from a vendor with a package repository. Lightning comes as an XPI for thunderbird, and if there's a dependency issue (not one reported by a package, but by a library that's not available), yum provides the tools to resolve it much more easily than apt. Other customers might run Mathematica or some other package that wasn't packaged conveniently. When that happens, you will see the name of the library that's required which you don't have, and will have to resolve the problem. Package managers can't hide that from you, but they can provide you the tools you need to handle it without a struggle.
Different story, same problem. Ever heard of CPAN? It's generally a bad idea to install perl- (/python-/ruby-, whatever) modules from a distro repository in order to satisfy a dependency for a file that is not *also* in the distro repository.
That's a ridiculous assertion with no argument to back it up. You actually made a more convincing argument for the opposite: you shouldn't install modules from CPAN to satisfy a dependency that is provided by your distribution's repository. You really want to use the distribution's packages whenever possible, and yum does a better job of resolving dependencies for scripts and programs that aren't in a repository.
Now you sound a bit like Darth Vader, advertising the dark side. ;-)
If you think that yum is "the dark side", then you're probably not open to considering alternative points of view. You claimed not to be a zealot, but you're sure starting to sound like one.
The question to which I was responding was (paraphrased): "What advantages does yum have over apt?" I've answered that by pointing out capabilities that yum has which apt does not, and situations where they are useful. You haven't pointed out equivalent functionality in apt, or shown that I'm wrong. Instead you've argued that I shouldn't use the additional features of yum. Would you say that's a fair assessment of this conversation?
From my perspective, apt forces you to work with only packages that are in a repository. Yum will do that, and also help you work with packages that you received from a vendor who doesn't have a repository, and with scripts and programs that weren't packaged to begin with. I think that's a strong advantage, despite the fact that I agree with you and prefer not to install software without packaging it. If you disagree, consider this: Do you think that it would be an advantage to modify dpkg and rpm so that they were only usable by apt/yum? It would force administrators to do things "the right way", by packaging all of their software and putting it in repositories. Do you think administrators would favor that policy?
features that you mentioned seem pretty much useless to me.
That's probably because you don't have them. You've built a workflow around the tools you have; that's what people do.
I'm a consultant, so I work on a lot of hosts that were set up by someone else. They aren't going to have my own personal repositories set up on them, so working with packages that aren't in a repository is essential to me.
Using "provides" is non-trivial, too. Consider that if you install the Lightning extension to Thunderbird on a current (32 bit) machine, it won't work. Why? Well:
$ ldd .thunderbird/*/extensions/*/components/*.so | grep 'not found' /usr/lib/libstdc++.so.5 => not found
They built against an old version of libstdc++. We'll need that:
# yum install libstdc++.so.5
How else would I know that the library is provided by compat-libstdc++-33? Or that libcucul.so.0 is provided by a package named libcaca?
The same is true of perl. If I download a script and it complains that it can't find Date/Format.pm, I can ask yum to get it:
# yum install 'perl(Date::Format)'
How else would I know that Date/Format.pm is in perl-TimeDate rather than perl-DateTime or perl-Date-Simple?
If you live entirely within the repository, then apt is fine. If you ever want to use something that's not there yet, yum is a much superior tool.
Good god, like what? I haven't found *anything* yum does better than apt.
Off the top of my head, it can install packages based on filenames or "provides" if you don't know the package name. It can also install a local package and resolve dependencies from repositories. apt can't do any of those things.
In Phoronix's original test, Ubuntu 7.04 (and sometimes 7.10) performed twice as fast as later releases. When later compared to Fedora, they showed that Fedora's numbers were fairly consistent over the last two years, and close to the same as recent Ubuntu releases. It seems like either something was wrong with the benchmark run on the 7.04 release or there was a huge change after 7.04. Has anyone explained that?
Rather, GPL is incompatible with anything else that can't be re-licensed as GPL... May first we clear that mess, right ?
Please, let's.
First and foremost: only the original author or copyright holder may re-license any copyrighted work. Period. Including software under licenses like BSD in GPL copyrighted works does not re-license the BSD code. The BSD licensed code remains under the BSD license; it continues to allow re-use under the BSD terms.
Because confusion on this issue has been fairly common, the Software Freedom Law Center published a paper on the subject after the Linux ath5k debacle.
Nvidia? That'd be just awesome. I can't think of any other way to make Apple hardware (already more prone to need warranty service than any other manufacturer's product that I can name) any less reliable. Go go gadget failure!
I don't know how many projects have asked Slashdot not to link to bugzilla. It makes the system unusable for the developers trying to get work done.
Here's the text currently in the bugzilla entry (edited to meet slashdot's filter requirements):
Bug 379791 - perl bless/overload performance problem
Summary: perl bless/overload performance problem
Status: VERIFIED
Product: Red Hat Enterprise Linux 5
Component: perl (Show Red Hat Enterprise Linux 5/perl bugs)
Version: 5.2
Platform: All Linux
Priority: urgent Severity: high
Target Milestone: rc
Assigned To: Marcela Maslanova
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard: GSSApproved
Keywords: ZStream
Depends on:
Blocks:
Reported: 2007-11-13 07:14 EDT by Nigel Metheringham
Modified: 2008-08-29 10:30 EDT (History)
Fixed In Version:
Release Notes:
Description From Nigel Metheringham 2007-11-13 07:14:04 EDT
RHEL5 perl shows the same performance issues as the Fedora 7 perl did - see
Bug #196836 and Bug #253728
This has been demonstrated in the recent perl update perl-5.8.8-10.el5_0.2
Same fix needs taking across to RHEL, ideally as a update release rather than
waiting for next major release cycle.
I do not have RHEL5.1 to test against right now, but the timing of the Fedora
fixes leads me to believe these would be much too late for the 5.1 release
cycle.
-- Comment #2 From Martin Kutter 2007-11-30 05:24:01 EDT --
The issue can be observed running the benchmark script from the recent
SOAP::WSDL package.
To do so, download SOAP-WSDL-2.00_24 (and its dependencies) from CPAN, run perl
Build.PL && perl Build, cd into benchmark and run perl -I../blib/lib 01_expat.t
This is the Output from RHEL4:
perl -I../lib 01_expat.t
Name "DB::packages" used only once: possible typo at 01_expat.t line 2.
Benchmark: timing 5000 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
(SOAP::WSDL)...
Hash (SOAP:WSDL): 4 wallclock secs ( 3.48 usr + 0.01 sys = 3.49 CPU) @1432.66/s (n=5000)
XML::Simple (Hash): 7 wallclock secs ( 7.19 usr + 0.03 sys = 7.22 CPU) @692.52/s (n=5000)
XSD (SOAP::WSDL): 6 wallclock secs ( 6.06 usr + 0.01 sys = 6.07 CPU) @823.72/s (n=5000)
And this (with reduced n) is from RHEL5 (different machine, perl-5.8.8-10):
Benchmark: timing 500 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
(SOAP::WSDL)...
Hash (SOAP:WSDL): 1 wallclock secs ( 0.59 usr + 0.00 sys = 0.59 CPU) @847.46/s (n=500)
XML::Simple (Hash): 1 wallclock secs ( 1.06 usr + 0.00 sys = 1.06 CPU) @471.70/s (n=500)
XSD (SOAP::WSDL): 11 wallclock secs (11.34 usr + 0.01 sys = 11.35 CPU) @44.05/s (n=500)
Increasing the number of runs shows the O(n^2) nature of the performance problem
- increasing the number of runs by a factor of 10 increases the runtime for the
XSD bench by a factor of nearly 100:
Name "DB::packages" used only once: possible typo at 01_expat.t line 2.
Benchmark: timing 5000 iterations of Hash (SOAP:WSDL), XML::Simple (Hash), XSD
(SOAP::WSDL)...
Hash (SOAP:WSDL): 6 wallclock secs ( 6.19 usr + 0.03 sys = 6.22 CPU) @ 803.86/s (n=5000)
XML::Simple (Hash): 11 wallclock secs (11.20 usr + 0.02 sys = 11.22 CPU) @ 445.63/s (n=5000)
XSD (SOAP::WSDL): 851 wallclock secs (847.36 usr + 2.28 sys = 849.64 CPU) @ 5.88/s (n=5000)
-- Comment #3 From RHEL Product and Program Management 2007-12-03 15:47:35 EDT --
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the cur