I mean life is too complicated to arise by chance, right? I just don't want to believe I'm related to an animal renound for picking shit out of it's ass.
You feel that beeing releated to Slashdotter regulars is an improvement?
Never trust a DVD writer review that doesn't take into account burn quality and media compatibility. That's how DVD drives differentiate themselves today.
Indeed, and that goes for media as well. For better reviews that test write and read quality as well, I find
Optical Storage reviews useful. I've no interest in the fastest way to produce coasters when I'm making backups, so I do look at those reviews for both media and burners before I buy.
Re:With the bazillion GUI toolkits out there..
on
Why Use GTK+?
·
· Score: 5, Informative
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
You have QT Designer that is part of the
QT Toolkit.
Which cards are well supported for Linux. I use to think that my GForce 2 was until NVIDIA decided that it was too old to bother with anymore. 3D stopped working in Suse 10.0 because of it. I am told that I need to install the older NVIDIA drivers. What a hassle.
This happens with hardware where vendors only offers binary drivers but no documentation. With documentation it's much easier to make good open source drivers, but sadly the Linux crowd are way to eager to use binary only drivers. Recently OpenBSD has had several campaigns to get hardware documentation with great success, but with lackluster support from Linux users/developers/vendors.
Let's hope that NVIDIA will be kind enough to open source their old drivers. But not wanting to hold my breath I'm looking at going with a card from a different company that does have open source drivers.
NVIDIA does not release documentation for any it's hardware, be it 3D cards or network cards. Any NVIDIA open source drivers are reverse engineered. Sorry, binary only drivers does not cut it. After some time you have a forced obsolence of still usefull hardware.
According to
this post
there are cases where you often get much better results with rzip than bzip2. So testing also depends on the type of data one expect to compress.
Forgotten resource of information not mentioned...
on
Linux Troubleshooting
·
· Score: 2, Insightful
is the man pages and other system documentation. Correct, updated and relevant man pages/documentation is a gold mine for trouble shooting and configuration.
A kernel is just software and may crash (panic). To get some useful debugging info about the crash (panic message, traceback, and ps output, for instance) you use a kernel debugger. Of course, a kernel debugger is used to more things than just print a call stack in case of a crash, of you are a kernel developer.
On OpenBSD you'll automatically enter the kernel debugger in case of a crash. With output from the debugger it's possible to make a usefulbug rapport. I don't know if the usual Linux kernels have the kernel debugger enabled.
For the most part, the summary of the article seems to be the more time that a compressing application takes to compress your files, the smaller your files will be after compressing.
Not only time, but also how much memory the algorithm uses, though the author did not mention how much space each algorithm uses. gzip, for instance, does not use much, but others, like rzip (http://rzip.samba.org/) uses alot. rzip may use up to 900MB during compression.
I did a test with compressing a 4GB tar archive with rzip, wich result in a compressed file of 2.1 GB. gzip at max compression gave about 2.7 GB.
So one should choose an algorithm based upon need, and of course, availability of source code. Using a propetiary, closed source compression algorithm with no open source alternative implementation is begging for trouble down the road,
Slashdot Mirror
When you are Microsoft, everyone are your enemies, including your customers.
It's also most likely sounds like a vacum cleaner due to fans needed to cool components in that constrained space.
You feel that beeing releated to Slashdotter regulars is an improvement?
Optical storage reviews at www.cdrinfo.com does this.
Indeed, and that goes for media as well. For better reviews that test write and read quality as well, I find Optical Storage reviews useful. I've no interest in the fastest way to produce coasters when I'm making backups, so I do look at those reviews for both media and burners before I buy.
You have QT Designer that is part of the QT Toolkit.
This happens with hardware where vendors only offers binary drivers but no documentation. With documentation it's much easier to make good open source drivers, but sadly the Linux crowd are way to eager to use binary only drivers. Recently OpenBSD has had several campaigns to get hardware documentation with great success, but with lackluster support from Linux users/developers/vendors.
Let's hope that NVIDIA will be kind enough to open source their old drivers. But not wanting to hold my breath I'm looking at going with a card from a different company that does have open source drivers.
NVIDIA does not release documentation for any it's hardware, be it 3D cards or network cards. Any NVIDIA open source drivers are reverse engineered. Sorry, binary only drivers does not cut it. After some time you have a forced obsolence of still usefull hardware.
According to this post there are cases where you often get much better results with rzip than bzip2. So testing also depends on the type of data one expect to compress.
is the man pages and other system documentation. Correct, updated and relevant man pages/documentation is a gold mine for trouble shooting and configuration.
A kernel is just software and may crash (panic). To get some useful debugging info about the crash (panic message, traceback, and ps output, for instance) you use a kernel debugger. Of course, a kernel debugger is used to more things than just print a call stack in case of a crash, of you are a kernel developer.
On OpenBSD you'll automatically enter the kernel debugger in case of a crash. With output from the debugger it's possible to make a usefulbug rapport. I don't know if the usual Linux kernels have the kernel debugger enabled.
Not only time, but also how much memory the algorithm uses, though the author did not mention how much space each algorithm uses. gzip, for instance, does not use much, but others, like rzip (http://rzip.samba.org/) uses alot. rzip may use up to 900MB during compression.
I did a test with compressing a 4GB tar archive with rzip, wich result in a compressed file of 2.1 GB. gzip at max compression gave about 2.7 GB.
So one should choose an algorithm based upon need, and of course, availability of source code. Using a propetiary, closed source compression algorithm with no open source alternative implementation is begging for trouble down the road,