Package management and seperating stuff into name spaces are two different problems (but related).
An example: I have a program in my path called convert. If I query the system where it is located (which convert) I get the reply/usr/bin. This tells me nothing about the function of the program. Now if this would be organized into some namespace structure (like the name of the package it belongs to or better, something to to with its functionality) I would be much wiser. Sure, I can use the package system to query for this but thats just a hack created when the flat namespace got too large. I like to use the tools available to solve tasks, not write a new one for each problem. The filesystem structure and standard unix commands (such as which) solve this problem, no need for an extra database for this (the filesystem is a good database).
Backup is an important argument. A friend of mine had all his CD stolen. It would be nice if he had perfect backup of them. Same goes for DVDs. If someone steals my DVDs it would be nice if I could just write them back to new DVD disks from my backup storage.
Every report and every article written about Decode Genetics says that they have bought the rights to collect the genetic information about the whole population. This is just wrong.
What they have bought the rights to is to build a centralized database with the medical journals of the people of Iceland will be stored and use that database to figure out statistics about diseases and correlate that with genealogical database.
They will not have access to medical records of individuals, the can only look at statistics of anonymous groups.
This has absolutly nothing to do with the DNA of the people of Iceland.
Oh and "mere $200 million", don't forget that we get all the drugs that result from research done with the database for free, forever.
That's incorrect. If the signal is sampled at twice its highest frenquency, the signal can be reconstructed exactly. This assumes that the samples are recorded precisely without quantization, and that the signal is truly bandlimited.
You can reconstruct a signal sampled at the Nyquist rate ONLY by using sinc interpolation functions. These functions do not have compact support (that is they live on the whole real line) and therefore you can never create them and use them. You use something similar, something close but then you can't reconstruct exacly. The "solution"? Sample at a frequency higher than the Nyquist rate.
Intel has one very important thing AMD doesn't: Developer support. With that I mean that they provide optimized math and signal/image processing libraries and optimizing compilers. Using an Intel tuned BLAS library (standard number crunching library) instead of the reference implementation written in Fortran 77 is much much much faster. So while higher clock speeds might impress home users that play games that extra clock speed wont help in scientific computing if you can't use a good implementation of number crunching libraries. (I can't run the intel libs on my AMD K6).
Raph Leviens conclusions are interesting but they only tell half the story about Jpeg2000.
Getting better compression ratios is not the only objective of the Jpeg2000 standard. It has lots and lots of other features that make it attractive besides impressive compression ratios.
First a little overview of compression. Compression schemes can be fitted into a three step framework:
Transform->Quantization->Entropy Code.
The transform part is where the data is massaged into something that is more suitable for compressing. The aims of this step is to remove redundant information as much as possible. In images pixels are very redundant. Pixels close together have very often the same color. The transform part of the current Jpeg is the DCT transform.
The second step is quantization. This is where we throw away information that we can live without.
Finally comes Entropy coding. This is where the actual compression takes place. Common values in the data are here represented by short bitstrings and those who occur seldom get longer bitstrings. In current Jpeg this is Huffman coding.
Raph talks about downsampling the image before compressing. That is exactly what Jpeg2000 does. The transform part of Jpeg2000 is a multiresolution analysis of the image. It takes the original image and downsamples it to a very small image. Then it adds in layers the information needed to upsample it to a higher resolution and get a perfect reconstruction. This is nice for lots of reasons. We can tell the decoder to stop downloading more details of the image at any time. You don't have to download the whole image if you don't want to. Nice for low bandwith connections and mobile connections. You can also choose to progress to a compleatly lossless version.
But Jpeg2000 does even more. It segments the image into tiles. This gives you the possibility to download only the regions of the image you are interested in in high resolution (good for porno - you only get the tits!).
The current Jpeg has only one transform, the DCT transform. Jpeg2000 v1 will have two transforms to choose between: An floating point transform for high performance compression and an integer only transform for use on low-end devices. That transform also allows you to get a perfect reconstruction. In Jpeg2000 v2 you can even specify your own transform coefficients and by that adapt the transform step to the data you have.
So even though the Jpeg2000 standard has rate/distortion similar to current Jpeg (that is Raphs point) it offers other very attractive features such as progressive decoding (giving you almost any resolution you want), regions of interest and the possibility to only get parts of the image if you are on low-bandwidth links.
Now if I had a Palm I could port my wire antenna analyzer code to it that uses OpenGL to visualize the radiation pattern of the antenna. People working in the field could use that on a Palm to quickly sketch up an antenna and analyze/visualize its performance.
Sounds great. If the installer detects the package management system being used on the computer and registers the stuff to install into the package database it is great to the power of 2. If it doesn't, that is something that should be added IMHO. And to make the installer lightweight, each distribution could come with a loadable module that the installer could load to talk to the package management system.
This shows why it is important to keep the lid on computercases. Computers are a big source of radio frequency interference and make the life of radio operators difficult. Please put the lid on your computer if it isn't allready there.
Slashdot Mirror
An example: I have a program in my path called convert. If I query the system where it is located (which convert) I get the reply /usr/bin. This tells me nothing about the function of the program. Now if this would be organized into some namespace structure (like the name of the package it belongs to or better, something to to with its functionality) I would be much wiser. Sure, I can use the package system to query for this but thats just a hack created when the flat namespace got too large. I like to use the tools available to solve tasks, not write a new one for each problem. The filesystem structure and standard unix commands (such as which) solve this problem, no need for an extra database for this (the filesystem is a good database).
Backup is an important argument. A friend of mine had all his CD stolen. It would be nice if he had perfect backup of them. Same goes for DVDs. If someone steals my DVDs it would be nice if I could just write them back to new DVD disks from my backup storage.
Every report and every article written about Decode Genetics says that they have bought the rights to collect the genetic information about the whole population. This is just wrong.
What they have bought the rights to is to build a centralized database with the medical journals of the people of Iceland will be stored and use that database to figure out statistics about diseases and correlate that with genealogical database.
They will not have access to medical records of individuals, the can only look at statistics of anonymous groups.
This has absolutly nothing to do with the DNA of the people of Iceland.
Oh and "mere $200 million", don't forget that we get all the drugs that result from research done with the database for free, forever.
You can reconstruct a signal sampled at the Nyquist rate ONLY by using sinc interpolation functions. These functions do not have compact support (that is they live on the whole real line) and therefore you can never create them and use them. You use something similar, something close but then you can't reconstruct exacly. The "solution"? Sample at a frequency higher than the Nyquist rate.
Intel has one very important thing AMD doesn't: Developer support. With that I mean that they provide optimized math and signal/image processing libraries and optimizing compilers. Using an Intel tuned BLAS library (standard number crunching library) instead of the reference implementation written in Fortran 77 is much much much faster. So while higher clock speeds might impress home users that play games that extra clock speed wont help in scientific computing if you can't use a good implementation of number crunching libraries. (I can't run the intel libs on my AMD K6).
Raph Leviens conclusions are interesting but they only tell half the story about Jpeg2000.
Getting better compression ratios is not the only objective of the Jpeg2000 standard. It has lots and lots of other features that make it attractive besides impressive compression ratios.
First a little overview of compression. Compression schemes can be fitted into a three step framework:
Transform->Quantization->Entropy Code.
The transform part is where the data is massaged into something that is more suitable for compressing. The aims of this step is to remove redundant information as much as possible. In images pixels are very redundant. Pixels close together have very often the same color.
The transform part of the current Jpeg is the DCT transform.
The second step is quantization. This is where we throw away information that we can live without.
Finally comes Entropy coding. This is where the actual compression takes place. Common values in the data are here represented
by short bitstrings and those who occur seldom get longer bitstrings. In current Jpeg this is Huffman coding.
Raph talks about downsampling the image before compressing. That is exactly what Jpeg2000 does. The transform part of Jpeg2000 is a multiresolution analysis of the image. It takes the original image and downsamples it to a very small image. Then it adds in layers the information needed to upsample it to a higher resolution and get a perfect reconstruction. This is nice for lots of reasons. We can tell the decoder to stop downloading more details of the image at any time. You don't have to download the whole image if you don't want to. Nice for low bandwith connections and mobile connections. You can also choose to progress to a compleatly lossless version.
But Jpeg2000 does even more. It segments the image into tiles. This gives you the possibility to download only the regions of the image you are interested in in high resolution (good for porno - you only get the tits!).
The current Jpeg has only one transform, the DCT transform. Jpeg2000 v1 will have two transforms to choose between: An floating point transform for high performance compression and an integer only transform for use on low-end devices. That transform also allows you to get a perfect reconstruction. In Jpeg2000 v2 you can even specify your own transform coefficients and by that adapt the transform step to the data you have.
So even though the Jpeg2000 standard has rate/distortion similar to current Jpeg (that is Raphs point) it offers other very attractive features such as progressive decoding (giving you almost any resolution you want), regions of interest and the possibility to only get parts of the image if you are on low-bandwidth links.
Thanks
Hrafnkell
Now if I had a Palm I could port my wire
:)
antenna analyzer code to it that uses
OpenGL to visualize the radiation pattern of
the antenna. People working in the field
could use that on a Palm to quickly sketch
up an antenna and analyze/visualize its
performance.
Anybody want to send me a Palm?
Sounds great. If the installer detects the package management system being used on the computer and registers the stuff to install into the package database it is great to the power of 2.
If it doesn't, that is something that should be added IMHO. And to make the installer lightweight, each distribution could come with a loadable module that the installer could load to talk to the package management system.
This shows why it is important to keep the lid on computercases. Computers are a big source of radio frequency interference and make the life of radio operators difficult.
Please put the lid on your computer if it isn't allready there.